Hard(?) lock when reassociating ath with wpa_supplicant
sam at freebsd.org
Fri May 16 16:23:29 UTC 2008
Alexandre "Sunny" Kovalenko wrote:
> On Mon, 2008-05-12 at 19:33 -0700, Sam Leffler wrote:
>> Alexandre "Sunny" Kovalenko wrote:
>>> I seem to be able to lock my machine by going into wpa_cli and asking it
>>> to 'reassoc'. The reason for question mark after "hard" is that debug
>>> information (caused by wlandebug and athdebug) is being printed on the
>>> console. The only way to get machine's attention is to hold power button
>>> for 8 seconds.
>> So this is just livelock due to console debug msgs.
> I am not sure, I have parsed this well enough, so I will try to clarify:
> machine becomes unresponsive *without* any debugging turned on, to an
> extent that pressing the power button twice *does not* generate ACPI
> console message (something to the tune of "going into S5 already --
> gimme a break"). If I turn ath debugging on, I do see those messages,
> and only them, scrolling on the console.
Guess I misunderstood you.
>>> Note: manual reassociation is just the handy way to reproduce the
>>> problem -- I have had machine locking up on me the whole day long
>>> completely on its own.
>>> Below are, what I think, relevant pieces of information. If anything is
>>> missing, please, chastise me appropriately and will do my best to
>>> provide. I have rigged firewire console, but am unable to break into the
>>> debugger locally or remotely.
>> I see no log msgs.
> I am sorry -- mailman must have eaten it up -- I have posted them here
All I see in the log is normal scanning.
>>> While I am on the subject, I would appreciate couple of the
>>> troubleshooting suggestions:
>>> * is there any way to get sysctl dev.ath.0.debug to appear, other then
>>> defining ATH_DEBUG in something like /usr/src/sys/dev/ath/ah_osdep.h?
>> options ATH_DEBUG
> That does not seem to work for if_ath built as the module, sorry for not
> being clear in that respect.
If you are build a module then you must edit the Makefile to add the
option. Feel free to provide a patch to improve this situation.
>>> * is there minimal, but still usable mask for athdebug and wlandebug? I
>>> have started with 0xFFFFFFFF and kept trimming likely high-volume
>>> settings until output slowed down to the reasonable pace.
>> Why do you want debug msgs from ath? The debug msgs from wlandebug
>> depend on what you're trying to debug.
> Because neither wpa_supplicant (quoted below), nor wlandebug (in the URL
> above) gave me the answer -- it looks like we are going into the scan
> with the specific SSID in mind and never come back, so I went for the
> next level. However, could you, please, clarify that I understood you
> correctly -- you *do not* want to see mix of wlandebug and athdebug
> messages in the report, and I should turn wlandebug off before turning
> athdebug on, right?
wlandebug msgs are typically low duty and can be left enabled when you
add driver-level debug msgs. But I can't see from the log you sent what
is going on. Try reducing the noise by eliminating all the ath debug
msgs; maybe provide one log w/ only wlan msgs and one w/ wlan+ath.
>> I suggest that when debugging you start from the highest layer and move
>> downward. If you can't find what you need in a wpa_supplicant log then
>> turn on msgs in net80211 with wlandebug. If that doesn't tell you what
>> you need then move to the driver. Blindly turning everything on can
>> easily livelock your system.
> That's what I did -- what I have posted is the end result of the walking
> down that chain, and I assumed, possibly incorrectly, that you would
> want result of all three to put things in context. I do apologize for
> the misunderstanding.
>> For high volume msgs I often do something
>> athdebug +intr; sleep 1; athdebug -intr
>> athdebug +intr; read x; athdebug -intr
>> so a carriage return will disable msgs.
> Thank you for the suggestion.
>>> * what facility does wpa_supplicant use, when forced to syslog by -s
>> trouble% cd /data/freebsd/head/contrib/wpa_supplicant/
>> trouble% grep openlog *.c
>> common.c: openlog("wpa_supplicant", LOG_PID | LOG_NDELAY, LOG_DAEMON);
> Thank you, should have done this myself, sorry.
More information about the freebsd-stable