Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 May 2008 12:37:56 -0400
From:      "Alexandre \"Sunny\" Kovalenko" <alex.kovalenko@verizon.net>
To:        Sam Leffler <sam@freebsd.org>
Cc:        stable@freebsd.org
Subject:   Re: Hard(?) lock when reassociating ath with wpa_supplicant on	RELENG_7
Message-ID:  <1210696676.985.18.camel@RabbitsDen>
In-Reply-To: <4828FDE5.8090409@freebsd.org>
References:  <1210640542.1008.33.camel@RabbitsDen>	<4828FDE5.8090409@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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 (Олександр Коваленко)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1210696676.985.18.camel>