Hard(?) lock when reassociating ath with wpa_supplicant
on RELENG_7
Alexandre "Sunny" Kovalenko
alex.kovalenko at verizon.net
Tue May 13 16:53:42 UTC 2008
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 (Олександр Коваленко)
More information about the freebsd-stable
mailing list