Re: scan stuck with if_iwi(4)
On Thu, Jul 27, 2006 at 04:47:16PM -0700, Sam Leffler wrote: Andrew Thompson wrote: On Wed, Jul 26, 2006 at 01:28:12PM -0700, Sam Leffler wrote: Henrik Brix Andersen wrote: Oh? Sounds interesting, where can I find these patches? The work has always been in perforce.freebsd.org; look in the sam_wifi branch. The code will not hit head until folks show up to fix legacy drivers that use net80211. I got stuck holding the bag when I committed the wpa support and it ain't going to happen again. Do you have a list of drivers that are stalling this? The changes decouple scanning from the net80211 state machine so any driver that uses ieee80211_new_state is affected: tubby% grep -l ieee80211_new_state */*.c ath/if_ath.c awi/awi.c ipw/if_ipw.c iwi/if_iwi.c ral/rt2560.c ral/rt2661.c usb/if_ural.c wi/if_wi.c I know how to convert ath and ral. iwi and ipw might not be too bad now that they've been changed to not abuse the state machine so much. awi, ural, and wi will break. ural might be ok after the new usb stack comes in but that's not clear. So I guess I'd take responsibility for ath and ral and want help with all other drivers. IMO, losing awi in the process wouldn't be a big deal. We'll be maintaining 6.x until well into 2008 and all the awi cards are defunct. -- Brooks pgplprNnsvXkH.pgp Description: PGP signature
Re: scan stuck with if_iwi(4)
Sam Leffler wrote: Andrew Thompson wrote: On Wed, Jul 26, 2006 at 01:28:12PM -0700, Sam Leffler wrote: Henrik Brix Andersen wrote: Oh? Sounds interesting, where can I find these patches? The work has always been in perforce.freebsd.org; look in the sam_wifi branch. The code will not hit head until folks show up to fix legacy drivers that use net80211. I got stuck holding the bag when I committed the wpa support and it ain't going to happen again. Do you have a list of drivers that are stalling this? The changes decouple scanning from the net80211 state machine so any driver that uses ieee80211_new_state is affected: tubby% grep -l ieee80211_new_state */*.c ath/if_ath.c awi/awi.c ipw/if_ipw.c iwi/if_iwi.c ral/rt2560.c ral/rt2661.c usb/if_ural.c wi/if_wi.c I know how to convert ath and ral. iwi and ipw might not be too bad now that they've been changed to not abuse the state machine so much. awi, ural, and wi will break. ural might be ok after the new usb stack comes in but that's not clear. So I guess I'd take responsibility for ath and ral and want help with all other drivers. I forgot the other key item missing from the above list: ndis. It bypasses the net80211 api's lots of places and frobs things directly so converting may be a big job--hard to say until someone tries it. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scan stuck with if_iwi(4)
On Thu, Jul 20, 2006 at 04:01:20PM -0700, Sam Leffler wrote: The basic problem is your card is losing sync w/ the ap. I don't know what the local conditions are but I've seen this a lot w/ iwi; there's nothing we can do in the driver if you want to be able to roam. Update: this was just fixed in iwi(4) in -CURRENT (by increasing the beacon miss threshold for the iwi(4) driver from 7 to 10). Should 10 not be enough, it is now also possible to set the beacon miss threshold using ifconfig. Thanks to Sam for helping and for applying my patches to -CURRENT. This functionality should be MFC'd in two weeks. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpv5kuFIG9T8.pgp Description: PGP signature
Re: scan stuck with if_iwi(4)
Henrik Brix Andersen wrote: On Thu, Jul 20, 2006 at 04:01:20PM -0700, Sam Leffler wrote: The basic problem is your card is losing sync w/ the ap. I don't know what the local conditions are but I've seen this a lot w/ iwi; there's nothing we can do in the driver if you want to be able to roam. Update: this was just fixed in iwi(4) in -CURRENT (by increasing the beacon miss threshold for the iwi(4) driver from 7 to 10). Should 10 not be enough, it is now also possible to set the beacon miss threshold using ifconfig. Thanks to Sam for helping and for applying my patches to -CURRENT. This functionality should be MFC'd in two weeks. Thanks for your help but understand this is not necessarily a solution; just the addition of a knob. The linux driver already used 7 consecutive beacon misses to trigger roaming so I'm not sure why 10 is an improvement but given that adding 300ms (typical) lag makes you happy I wasn't going to argue :) Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scan stuck with if_iwi(4)
On Wed, Jul 26, 2006 at 09:10:03AM -0700, Sam Leffler wrote: Thanks for your help but understand this is not necessarily a solution; just the addition of a knob. I know. The linux driver already used 7 consecutive beacon misses to trigger roaming so I'm not sure why 10 is an improvement but given that adding 300ms (typical) lag makes you happy I wasn't going to argue :) Actually, it seems the linux driver uses a threshold of 8 missed beacons for roaming and a threshold of 24 for disassociation. But you're correct - this only solves the issue of being disassociated every 3 minutes; it doesn't solve the problem behind scan stuck, but this problem is not present here anymore since the station is not disassociated all the time. I'll try to address the scan stuck problem when I find some more time. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpSfwF9fbvoh.pgp Description: PGP signature
Re: scan stuck with if_iwi(4)
Henrik Brix Andersen wrote: On Wed, Jul 26, 2006 at 09:10:03AM -0700, Sam Leffler wrote: Thanks for your help but understand this is not necessarily a solution; just the addition of a knob. I know. Sure, it was for others. The linux driver already used 7 consecutive beacon misses to trigger roaming so I'm not sure why 10 is an improvement but given that adding 300ms (typical) lag makes you happy I wasn't going to argue :) Actually, it seems the linux driver uses a threshold of 8 missed beacons for roaming and a threshold of 24 for disassociation. Which version are you looking at? The numbers in iwi are from the code in linux-2.6.17; maybe it's been changed again in the code on sourceforge? The one thing the linux driver does differently is scan for a new ap _before_ roaming which the current net80211 code cannot do. Unfortunately the code to do that has been sitting outside the tree for a long time and it's unclear if it'll ever come in... But you're correct - this only solves the issue of being disassociated every 3 minutes; it doesn't solve the problem behind scan stuck, but this problem is not present here anymore since the station is not disassociated all the time. I'll try to address the scan stuck problem when I find some more time. Thank you. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scan stuck with if_iwi(4)
On Wed, Jul 26, 2006 at 11:07:36AM -0700, Sam Leffler wrote: Sure, it was for others. Ah :) Which version are you looking at? The numbers in iwi are from the code in linux-2.6.17; maybe it's been changed again in the code on sourceforge? I was looking in the ipw2200.h header file from ipw2200-1.1.2 - but the values are the same in version 1.1.1 of the driver, which is present in linux-2.6.17. #define IPW_MB_ROAMING_THRESHOLD_DEFAULT8 #define IPW_MB_DISASSOCIATE_THRESHOLD_DEFAULT 3*IPW_MB_ROAMING_THRESHOLD_DEFAULT The one thing the linux driver does differently is scan for a new ap _before_ roaming which the current net80211 code cannot do. Unfortunately the code to do that has been sitting outside the tree for a long time and it's unclear if it'll ever come in... Oh? Sounds interesting, where can I find these patches? Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpoFWY6qokxS.pgp Description: PGP signature
Re: scan stuck with if_iwi(4)
Henrik Brix Andersen wrote: On Wed, Jul 26, 2006 at 11:07:36AM -0700, Sam Leffler wrote: Sure, it was for others. Ah :) Which version are you looking at? The numbers in iwi are from the code in linux-2.6.17; maybe it's been changed again in the code on sourceforge? I was looking in the ipw2200.h header file from ipw2200-1.1.2 - but the values are the same in version 1.1.1 of the driver, which is present in linux-2.6.17. #define IPW_MB_ROAMING_THRESHOLD_DEFAULT8 #define IPW_MB_DISASSOCIATE_THRESHOLD_DEFAULT 3*IPW_MB_ROAMING_THRESHOLD_DEFAULT If I recall the first is used to trigger a bg scan to look for a better ap. If that fails and the 2nd number is seen then the driver shuts down. So I guess this amounts to disconnecting from the current ap on the 2nd number but I'm not sure how you can do the bg scan and still get the firmware to keep counting up to the larger number (it resets it's internal counter on channel change from what I recall). But it's been a while. Regardless you've got a knob now so you can set it to whatever you want. You shouldn't be missing beacons in such large numbers; it's a likely indicator of some other problem but since we don't know what exactly a bmiss means it's hard to say (e.g. the firmware may report a bmiss when the rssi of the received beacon frame is below a threshold in which case there may be a problem with the threshold setting). The one thing the linux driver does differently is scan for a new ap _before_ roaming which the current net80211 code cannot do. Unfortunately the code to do that has been sitting outside the tree for a long time and it's unclear if it'll ever come in... Oh? Sounds interesting, where can I find these patches? The work has always been in perforce.freebsd.org; look in the sam_wifi branch. The code will not hit head until folks show up to fix legacy drivers that use net80211. I got stuck holding the bag when I committed the wpa support and it ain't going to happen again. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scan stuck with if_iwi(4)
On Wed, Jul 26, 2006 at 01:28:12PM -0700, Sam Leffler wrote: Henrik Brix Andersen wrote: Oh? Sounds interesting, where can I find these patches? The work has always been in perforce.freebsd.org; look in the sam_wifi branch. The code will not hit head until folks show up to fix legacy drivers that use net80211. I got stuck holding the bag when I committed the wpa support and it ain't going to happen again. Do you have a list of drivers that are stalling this? Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scan stuck with if_iwi(4)
On Fri, Jul 21, 2006 at 09:00:06AM +1000, Mark Andrews wrote: The iwi code was recently MFC and it required a port change iwi-firmware - iwi-firmware-kmod. Depending on when you upgraded the src and ports you may not have seen the ports change. Yeah, I know - I have the new iwi-firmware-kmod installed. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgp7buIBqnpP2.pgp Description: PGP signature
Re: scan stuck with if_iwi(4)
On Thu, Jul 20, 2006 at 04:01:20PM -0700, Sam Leffler wrote:
You will not be able to reproduce the problem because the code in 6.1R
ignored beacon misses (and a lot of other things).
I see.
The stuck scan is not fatal; the driver just resets the card. It's
caused by a firwmare problem that I never got around to dealing with
('cuz it wouldn't change the overall operation of the driver).
Well, losing the connection for 30 seconds every 3 minutes is rather
annoying - if not fatal.
The basic problem is your card is losing sync w/ the ap. I don't know
what the local conditions are but I've seen this a lot w/ iwi; there's
nothing we can do in the driver if you want to be able to roam.
The problem should be solvable in software - the Linux ipw2200 driver
doesn't have these problems when using the same AP.
Regards,
Brix
--
Henrik Brix Andersen [EMAIL PROTECTED]
pgpAKmEJ6LBCu.pgp
Description: PGP signature
scan stuck with if_iwi(4)
Hi, I recently upgraded my IBM ThinkPad X31 from 6.1-RELEASE to 6.1-STABLE after which the if_iwi(4) driver started dropping the connection at regular intervals when connected to my hostapd-based AP using WPA2 PSK CCMP. The dmesg output with debug.iwi=4 is listed below - it fails regularly (every 3 mins or so) with the message scan stuck after which the adapter is reinitialized and the connection lost for some seconds. The connection drop seems to be caused by the adapter suddently entering the SCAN state. I have been unable to reproduce this problem with 6.1-RELEASE. $ uname -a FreeBSD fangorn.brixandersen.dk 6.1-STABLE FreeBSD 6.1-STABLE #2: Tue Jul 18 11:16:02 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Jul 20 23:38:04 fangorn kernel: iwi0: Intel(R) PRO/Wireless 2915ABG mem 0xc020-0xc0200fff irq 11 at device 2.0 on pci2 Jul 20 23:38:04 fangorn kernel: iwi0: Ethernet address: 00:0e:35:fd:81:94 ... Jul 21 00:19:26 fangorn kernel: Beacon miss: 7 = 7 Jul 21 00:20:24 fangorn kernel: Beacon miss: 7 = 7 Jul 21 00:20:24 fangorn kernel: iwi_newstate: RUN - SCAN flags 0x11 Jul 21 00:20:24 fangorn kernel: iwi0: link state changed to DOWN Jul 21 00:20:24 fangorn kernel: iwi_newstate: INIT - SCAN flags 0x11 Jul 21 00:20:24 fangorn kernel: iwi_newstate: SCAN - SCAN flags 0x13 Jul 21 00:20:24 fangorn kernel: Start scanning Jul 21 00:20:24 fangorn kernel: sending command idx=5 type=26 len=96 Jul 21 00:20:24 fangorn kernel: Beacon miss: 8 = 7 Jul 21 00:20:24 fangorn kernel: Beacon miss: 9 = 7 Jul 21 00:20:30 fangorn kernel: iwi0: scan stuck Jul 21 00:20:30 fangorn kernel: iwi_newstate: SCAN - INIT flags 0x0 Jul 21 00:20:31 fangorn kernel: Setting MAC address to 00:0e:35:fd:81:94 Jul 21 00:20:31 fangorn kernel: sending command idx=0 type=11 len=6 Jul 21 00:20:31 fangorn kernel: Configuring adapter Jul 21 00:20:31 fangorn kernel: sending command idx=1 type=6 len=20 Jul 21 00:20:31 fangorn kernel: Setting power mode to 0 Jul 21 00:20:31 fangorn kernel: sending command idx=2 type=17 len=4 Jul 21 00:20:31 fangorn kernel: Setting RTS threshold to 2346 Jul 21 00:20:31 fangorn kernel: sending command idx=3 type=15 len=4 Jul 21 00:20:31 fangorn kernel: Setting fragmentation threshold to 2346 Jul 21 00:20:31 fangorn kernel: sending command idx=4 type=16 len=4 Jul 21 00:20:31 fangorn kernel: Setting .11bg supported rates (12) Jul 21 00:20:31 fangorn kernel: sending command idx=5 type=22 len=16 Jul 21 00:20:31 fangorn kernel: Setting .11a supported rates (8) Jul 21 00:20:31 fangorn kernel: sending command idx=6 type=22 len=16 Jul 21 00:20:31 fangorn kernel: Setting initialization vector to 1069254139 Jul 21 00:20:31 fangorn kernel: sending command idx=7 type=34 len=4 Jul 21 00:20:31 fangorn kernel: Setting wep key index 0 len 0 Jul 21 00:20:31 fangorn kernel: sending command idx=8 type=18 len=20 Jul 21 00:20:31 fangorn kernel: Setting wep key index 1 len 0 Jul 21 00:20:31 fangorn kernel: sending command idx=9 type=18 len=20 Jul 21 00:20:31 fangorn kernel: Setting wep key index 2 len 0 Jul 21 00:20:31 fangorn kernel: sending command idx=10 type=18 len=20 Jul 21 00:20:31 fangorn kernel: Setting wep key index 3 len 0 Jul 21 00:20:31 fangorn kernel: sending command idx=11 type=18 len=20 Jul 21 00:20:31 fangorn kernel: Enabling adapter Jul 21 00:20:31 fangorn kernel: sending command idx=12 type=2 len=0 Jul 21 00:20:31 fangorn kernel: iwi_newstate: INIT - SCAN flags 0x5 Jul 21 00:20:31 fangorn kernel: iwi_newstate: SCAN - SCAN flags 0x3 Jul 21 00:20:31 fangorn kernel: Start scanning Jul 21 00:20:31 fangorn kernel: sending command idx=13 type=26 len=96 Jul 21 00:20:31 fangorn kernel: Scan of channel 5180 complete (36) Jul 21 00:20:31 fangorn kernel: Scan of channel 5200 complete (40) Jul 21 00:20:31 fangorn kernel: Scan of channel 5220 complete (44) Jul 21 00:20:31 fangorn kernel: Scan of channel 5240 complete (48) Jul 21 00:20:31 fangorn kernel: Scan of channel 5260 complete (52) Jul 21 00:20:31 fangorn kernel: Scan of channel 5280 complete (56) Jul 21 00:20:31 fangorn kernel: Scan of channel 5300 complete (60) Jul 21 00:20:31 fangorn kernel: Scan of channel 5320 complete (64) Jul 21 00:20:32 fangorn kernel: Scan of channel 5745 complete (149) Jul 21 00:20:32 fangorn kernel: Scan of channel 5765 complete (153) Jul 21 00:20:32 fangorn kernel: Scan of channel 5785 complete (157) Jul 21 00:20:32 fangorn kernel: Scan of channel 5805 complete (161) Jul 21 00:20:32 fangorn kernel: Scan of channel 5825 complete (165) Jul 21 00:20:32 fangorn kernel: Scan of channel 2412 complete (1) Jul 21 00:20:32 fangorn kernel: Scan of channel 2417 complete (2) Jul 21 00:20:32 fangorn kernel: Scan of channel 2422 complete (3) Jul 21 00:20:32 fangorn kernel: Scan of channel 2427 complete (4) Jul 21 00:20:33 fangorn kernel: Scan of channel 2432 complete (5) Jul 21 00:20:33 fangorn kernel: Scan of channel 2437 complete (6) Jul 21 00:20:33 fangorn kernel: Scan of channel 2442 complete (7) Jul 21 00:20:33 fangorn kernel: Scan
Re: scan stuck with if_iwi(4)
The iwi code was recently MFC and it required a port change iwi-firmware - iwi-firmware-kmod. Depending on when you upgraded the src and ports you may not have seen the ports change. Mark B.T.W. the new code is more stable for me. No more complete machine lockups. The WiFi led now binks though if you turn the radio off it stays lit / off depending apon the state it was in at the time. This is still better than not lighting at all. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scan stuck with if_iwi(4)
Henrik Brix Andersen wrote:
Hi,
I recently upgraded my IBM ThinkPad X31 from 6.1-RELEASE to 6.1-STABLE
after which the if_iwi(4) driver started dropping the connection at
regular intervals when connected to my hostapd-based AP using WPA2 PSK
CCMP.
The dmesg output with debug.iwi=4 is listed below - it fails regularly
(every 3 mins or so) with the message scan stuck after which the
adapter is reinitialized and the connection lost for some seconds.
The connection drop seems to be caused by the adapter suddently
entering the SCAN state.
I have been unable to reproduce this problem with 6.1-RELEASE.
You will not be able to reproduce the problem because the code in 6.1R
ignored beacon misses (and a lot of other things).
The stuck scan is not fatal; the driver just resets the card. It's
caused by a firwmare problem that I never got around to dealing with
('cuz it wouldn't change the overall operation of the driver).
The basic problem is your card is losing sync w/ the ap. I don't know
what the local conditions are but I've seen this a lot w/ iwi; there's
nothing we can do in the driver if you want to be able to roam.
Sam
$ uname -a
FreeBSD fangorn.brixandersen.dk 6.1-STABLE FreeBSD 6.1-STABLE #2: Tue Jul 18
11:16:02 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386
Jul 20 23:38:04 fangorn kernel: iwi0: Intel(R) PRO/Wireless 2915ABG mem
0xc020-0xc0200fff irq 11 at device 2.0 on pci2
Jul 20 23:38:04 fangorn kernel: iwi0: Ethernet address: 00:0e:35:fd:81:94
...
Jul 21 00:19:26 fangorn kernel: Beacon miss: 7 = 7
Jul 21 00:20:24 fangorn kernel: Beacon miss: 7 = 7
Jul 21 00:20:24 fangorn kernel: iwi_newstate: RUN - SCAN flags 0x11
Jul 21 00:20:24 fangorn kernel: iwi0: link state changed to DOWN
Jul 21 00:20:24 fangorn kernel: iwi_newstate: INIT - SCAN flags 0x11
Jul 21 00:20:24 fangorn kernel: iwi_newstate: SCAN - SCAN flags 0x13
Jul 21 00:20:24 fangorn kernel: Start scanning
Jul 21 00:20:24 fangorn kernel: sending command idx=5 type=26 len=96
Jul 21 00:20:24 fangorn kernel: Beacon miss: 8 = 7
Jul 21 00:20:24 fangorn kernel: Beacon miss: 9 = 7
Jul 21 00:20:30 fangorn kernel: iwi0: scan stuck
Jul 21 00:20:30 fangorn kernel: iwi_newstate: SCAN - INIT flags 0x0
Jul 21 00:20:31 fangorn kernel: Setting MAC address to 00:0e:35:fd:81:94
Jul 21 00:20:31 fangorn kernel: sending command idx=0 type=11 len=6
Jul 21 00:20:31 fangorn kernel: Configuring adapter
Jul 21 00:20:31 fangorn kernel: sending command idx=1 type=6 len=20
Jul 21 00:20:31 fangorn kernel: Setting power mode to 0
Jul 21 00:20:31 fangorn kernel: sending command idx=2 type=17 len=4
Jul 21 00:20:31 fangorn kernel: Setting RTS threshold to 2346
Jul 21 00:20:31 fangorn kernel: sending command idx=3 type=15 len=4
Jul 21 00:20:31 fangorn kernel: Setting fragmentation threshold to 2346
Jul 21 00:20:31 fangorn kernel: sending command idx=4 type=16 len=4
Jul 21 00:20:31 fangorn kernel: Setting .11bg supported rates (12)
Jul 21 00:20:31 fangorn kernel: sending command idx=5 type=22 len=16
Jul 21 00:20:31 fangorn kernel: Setting .11a supported rates (8)
Jul 21 00:20:31 fangorn kernel: sending command idx=6 type=22 len=16
Jul 21 00:20:31 fangorn kernel: Setting initialization vector to 1069254139
Jul 21 00:20:31 fangorn kernel: sending command idx=7 type=34 len=4
Jul 21 00:20:31 fangorn kernel: Setting wep key index 0 len 0
Jul 21 00:20:31 fangorn kernel: sending command idx=8 type=18 len=20
Jul 21 00:20:31 fangorn kernel: Setting wep key index 1 len 0
Jul 21 00:20:31 fangorn kernel: sending command idx=9 type=18 len=20
Jul 21 00:20:31 fangorn kernel: Setting wep key index 2 len 0
Jul 21 00:20:31 fangorn kernel: sending command idx=10 type=18 len=20
Jul 21 00:20:31 fangorn kernel: Setting wep key index 3 len 0
Jul 21 00:20:31 fangorn kernel: sending command idx=11 type=18 len=20
Jul 21 00:20:31 fangorn kernel: Enabling adapter
Jul 21 00:20:31 fangorn kernel: sending command idx=12 type=2 len=0
Jul 21 00:20:31 fangorn kernel: iwi_newstate: INIT - SCAN flags 0x5
Jul 21 00:20:31 fangorn kernel: iwi_newstate: SCAN - SCAN flags 0x3
Jul 21 00:20:31 fangorn kernel: Start scanning
Jul 21 00:20:31 fangorn kernel: sending command idx=13 type=26 len=96
Jul 21 00:20:31 fangorn kernel: Scan of channel 5180 complete (36)
Jul 21 00:20:31 fangorn kernel: Scan of channel 5200 complete (40)
Jul 21 00:20:31 fangorn kernel: Scan of channel 5220 complete (44)
Jul 21 00:20:31 fangorn kernel: Scan of channel 5240 complete (48)
Jul 21 00:20:31 fangorn kernel: Scan of channel 5260 complete (52)
Jul 21 00:20:31 fangorn kernel: Scan of channel 5280 complete (56)
Jul 21 00:20:31 fangorn kernel: Scan of channel 5300 complete (60)
Jul 21 00:20:31 fangorn kernel: Scan of channel 5320 complete (64)
Jul 21 00:20:32 fangorn kernel: Scan of channel 5745 complete (149)
Jul 21 00:20:32 fangorn kernel: Scan of channel 5765 complete (153)
Jul 21 00:20:32 fangorn kernel: Scan of channel 5785
Re: scan stuck with if_iwi(4)
Mark Andrews wrote: The iwi code was recently MFC and it required a port change iwi-firmware - iwi-firmware-kmod. Depending on when you upgraded the src and ports you may not have seen the ports change. Mark B.T.W. the new code is more stable for me. No more complete machine lockups. The WiFi led now binks though if you turn the radio off it stays lit / off depending apon the state it was in at the time. This is still better than not lighting at all. There are some sysctl you can tweak to play w/ the led's. I only had a dell d610 to test with. The more important issue w/ the radio on/off switch is that it doesn't hookup properly to wpa_supplicant. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
