Date: Sun, 13 Jul 2008 15:19:34 -0700 From: Sam Leffler <sam@freebsd.org> To: "Alexandre \"Sunny\" Kovalenko" <gaijin.k@gmail.com> Cc: stable@freebsd.org, Martin <nakal@web.de> Subject: Re: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7 Message-ID: <487A7F76.7000709@freebsd.org> In-Reply-To: <1215952634.1731.3.camel@RabbitsDen> References: <20080713112117.7d3ff6c6@web.de> <1215952634.1731.3.camel@RabbitsDen>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexandre "Sunny" Kovalenko wrote: > On Sun, 2008-07-13 at 11:21 +0200, Martin wrote: >> Hi Sam, >> >> do you know if there is anything done about cbb(4)? I have many >> wireless adapters with ath(4), but only the one based on PCMCIA is >> making problems on FreeBSD. >> >> I cannot boot my notebook with the device inserted into the port, or it >> will render the system unusable (100% load on cbb(4)). >> >> And all I can see is the following: >> Jul 12 14:58:39 link kernel: ath0: ath_chan_set: unable to reset channel 1 (2412 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:58:40 link kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 >> Jul 12 14:58:41 link kernel: ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 >> Jul 12 14:58:42 link kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:58:43 link kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:58:44 link kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 >> Jul 12 14:58:45 link kernel: ath0: ath_chan_set: unable to reset channel 5 (2432 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:58:45 link kernel: ath0: ath_chan_set: unable to reset channel 8 (2447 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:58:46 link kernel: ath0: ath_chan_set: unable to reset channel 9 (2452 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:58:47 link kernel: ath0: ath_chan_set: unable to reset channel 10 (2457 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:58:52 link kernel: ath0: device timeout >> Jul 12 14:58:52 link kernel: ath0: ath_reset: unable to reset hardware; hal status 3231908395 >> Jul 12 14:58:58 link kernel: ath0: ath_chan_set: unable to reset channel 1 (2412 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 >> Jul 12 14:58:59 link kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:00 link kernel: ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:01 link kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:01 link kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0), hal status 3289233408 >> Jul 12 14:59:02 link kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:03 link kernel: ath0: ath_chan_set: unable to reset channel 5 (2432 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:04 link kernel: ath0: ath_chan_set: unable to reset channel 8 (2447 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:05 link kernel: ath0: ath_chan_set: unable to reset channel 9 (2452 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:06 link kernel: ath0: ath_chan_set: unable to reset channel 10 (2457 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:10 link kernel: ath0: device timeout >> Jul 12 14:59:10 link kernel: ath0: ath_reset: unable to reset hardware; hal status 3231908395 >> Jul 12 14:59:11 link kernel: ath0: ath_chan_set: unable to reset channel 1 (2412 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 >> Jul 12 14:59:12 link kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:13 link kernel: ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 >> Jul 12 14:59:14 link kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:15 link kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:16 link kernel: ath0: unable to reset hardware; hal status 3868687084 >> Jul 12 14:59:16 link kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:17 link kernel: ath0: ath_chan_set: unable to reset channel 11 (2462 Mhz, flags 0x480 hal flags 0xc0), hal status 3828804624 >> Jul 12 14:59:22 link kernel: ath0: unable to reset hardware; hal status 3868539700 >> Jul 12 14:59:32 link kernel: ath0: unable to reset hardware; hal status 3868539700 >> Jul 12 14:59:42 link kernel: ath0: unable to reset hardware; hal status 3868539700 >> Jul 12 15:00:22 link last message repeated 4 times >> Jul 12 15:00:32 link kernel: ath0: unable to reset hardware; hal status 3868539700 >> Jul 12 15:00:42 link kernel: ath0: unable to reset hardware; hal status 3868539700 >> Jul 12 15:00:52 link kernel: ath0: unable to reset hardware; hal status 3868539700 >> >> >> wpa_supplicant is trying to access the card and switching channels, I >> suppose. >> >> A workaround that I'm using all the time is: >> 1) boot the notebook without the PCMCIA card >> 2) after gdm appears, insert the card >> >> Also see: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120376 >> >> In this PR I also described that you can panic the system, >> while trying to fix the situation by reinserting the card. >> But I found out, that you can always panic the system when >> ejecting the card and wpa_supplicant is running. >> > You can panic the box by unloading if_ath.ko while wpa_supplicant is > running on any form factor, so this one is not specific to the removable > devices. > The wpa_supplicant issue is due to the ioctl path racing against detach. I have a hack for this. The root cause is the ifnet code not handling ifdetach correctly. It doesn't happen in HEAD because of a slightly more general hack. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?487A7F76.7000709>