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.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
