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

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.


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



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.


* 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?


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.

--
Alexandre "Sunny" Kovalenko (Олександр Коваленко)

_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"