Date: Fri, 16 May 2008 12:23:26 -0400 From: Sam Leffler <sam@freebsd.org> To: "Alexandre \"Sunny\" Kovalenko" <alex.kovalenko@verizon.net> Cc: stable@freebsd.org Subject: Re: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7 Message-ID: <482DB4FE.3010300@freebsd.org> In-Reply-To: <1210696676.985.18.camel@RabbitsDen> References: <1210640542.1008.33.camel@RabbitsDen> <4828FDE5.8090409@freebsd.org> <1210696676.985.18.camel@RabbitsDen>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?482DB4FE.3010300>