From owner-freebsd-stable@FreeBSD.ORG Fri May 16 16:23:29 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 761AB1065671 for ; Fri, 16 May 2008 16:23:29 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 32C778FC20 for ; Fri, 16 May 2008 16:23:29 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from Macintosh-4.local ([137.122.73.36]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m4GGNRxp086221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 May 2008 09:23:28 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <482DB4FE.3010300@freebsd.org> Date: Fri, 16 May 2008 12:23:26 -0400 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: "Alexandre \"Sunny\" Kovalenko" References: <1210640542.1008.33.camel@RabbitsDen> <4828FDE5.8090409@freebsd.org> <1210696676.985.18.camel@RabbitsDen> In-Reply-To: <1210696676.985.18.camel@RabbitsDen> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: stable@freebsd.org Subject: Re: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2008 16:23:29 -0000 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. >