Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7

[Sam Leffler]

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
> now:
> 
> http://members.verizon.net/~akovalenko/Misc/reassoc.log.gz

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 
>> like:
>>
>> athdebug +intr; sleep 1; athdebug -intr
>>
>> or
>>
>> 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
>>> switch?
>> 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.
>