Date: Wed, 2 Apr 2008 14:00:02 +0200 From: Mel <fbsd.questions@rachie.is-a-geek.net> To: freebsd-mobile@freebsd.org Cc: Yousif Hassan <yousif@alumni.jmu.edu>, Sam Leffler <sam@freebsd.org>, Benjamin Close <Benjamin.Close@clearchain.com>, Alphons Fonz van Werven <a.j.werven@student.utwente.nl>, freebsd-net@freebsd.org Subject: Re: [Wireless] Can't connect to wlan Message-ID: <200804021400.04442.fbsd.questions@rachie.is-a-geek.net> In-Reply-To: <47E1088A.8090203@clearchain.com> References: <47C078EC.4020907@student.utwente.nl> <D148E5EB841844D393DBB58285CEA4BF@alderaan> <47E1088A.8090203@clearchain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 19 March 2008 13:35:22 Benjamin Close wrote:
> Yousif Hassan wrote:
> > Benjamin Close wrote:
> >> Sam Leffler wrote:
> >>> Yousif Hassan wrote:
> >>>> On Wed, 2008-03-12 at 08:06 +1030, Benjamin Close wrote:
> >
> > <snip>
> >
> >>>> The slightly wonky:
> >>>> - As reported by someone else:
> >>>> wpi0: timeout resetting Tx ring 1
> >>>> wpi0: timeout resetting Tx ring 3
> >>>> wpi0: timeout resetting Tx ring 4
> >>>> appear on startup and occasionally on kldload - however they don't
> >>>> appear to adversely affect too much
> >
> > <snip>
> >
> >>> wpi doesn't yet support background scan so doing an explicit scan
> >>> from the command line will disconnect you from any ap you care
> >>> connected to. It shouldn't be hard to add bgscan--but that's easy
> >>> for me to say :)
> >>
> >> It's certainly on my todo list!
> >
> > Thanks for reminding me about the bgscan thing. I had read that
> > somewhere before and completely forgotten!
> >
> > Ben, are the
> > wpi0: timeout resetting Tx ring 1
> > wpi0: timeout resetting Tx ring 3
> > wpi0: timeout resetting Tx ring 4
> > (and other variants thereof)
> > messages anything to be concerned about? It doesn't seem to affect
> > stuff but it does show up on initial startup and every other scan I do.
> >
> > Thanks to everyone who worked on wpi for a most excellent driver.
>
> The timeouts are related to the firmware not being able to reset the tx
> ring. Normally this isn't too bad as the first thing after resetting the
> tx rings is to stop the firmware and reinit it. Whilst it won't cause a
> crash, it still a bug that needs fixing.
I think I finally found the issue with the connection dropping. It is related
to a beacon miss and the driver not getting back to authenticated state.
The /root/bin/testwpi.sh script mentioned below pings the AP 50 times sends it
to syslog and does it again.
Apr 1 09:20:30 laptop kernel: Beacon miss: 20 >= 7
Apr 1 09:20:30 laptop kernel: Beacon miss: 21 >= 7
Apr 1 09:20:30 laptop kernel: wpi_newstate: RUN -> ASSOC
Apr 1 09:20:30 laptop kernel: wpi0: link state changed to DOWN
Then this Beacon miss continues incrementing until:
Apr 1 09:20:56 laptop kernel: Beacon miss: 274 >= 7
At this point the packet loss is still 100%:
Apr 1 09:21:04 laptop /root/bin/testwpi.sh: 50 packets transmitted, 14
packets received, 72.0%
packet loss round-trip min/avg/max/stddev = 0.513/0.599/1.046/0.131 ms
Apr 1 09:22:05 laptop /root/bin/testwpi.sh: 50 packets transmitted, 0 packets
received, 100.0%
packet loss
Apr 1 09:23:06 laptop /root/bin/testwpi.sh: 50 packets transmitted, 0 packets
received, 100.0%
packet loss
Then for no apparent reason, it tries again:
Apr 1 10:49:41 laptop kernel: Beacon miss: 20 >= 7
Apr 1 10:49:41 laptop kernel: Beacon miss: 21 >= 7
Apr 1 10:49:41 laptop kernel: Beacon miss: 22 >= 7
...
Apr 1 10:50:07 laptop kernel: Beacon miss: 273 >= 7
Apr 1 10:50:37 laptop /root/bin/testwpi.sh: 50 packets transmitted, 0 packets
received, 100.0% packet loss
Apr 1 10:51:38 laptop /root/bin/testwpi.sh: 50 packets transmitted, 0 packets
received, 100.0% packet loss
Apr 1 10:53:40 laptop last message repeated 2 times
Apr 1 11:03:51 laptop last message repeated 10 times
...
Then for no apparent reason (as far as I know, no one was near the machine at
the time):
Apr 1 16:34:00 laptop kernel: wpi_newstate: ASSOC -> AUTH
Apr 1 16:34:00 laptop kernel: wpi_ops: command: 16
Apr 1 16:34:00 laptop kernel: config chan 1 flags 8035 cck f ofdm 15
Apr 1 16:34:00 laptop kernel: wpi_ops: command: 1
Apr 1 16:34:00 laptop kernel: wpi_ops: command: 8
Apr 1 16:34:00 laptop kernel: Ignoring WPI_SET_CHAN
Apr 1 16:34:00 laptop kernel: wpi_ops: command: 2
Apr 1 16:34:00 laptop kernel: Scanning Essid: "MYSSID"
Apr 1 16:34:00 laptop kernel: Scanning 1 Passive: 0
Apr 1 16:34:00 laptop kernel: wpi_newstate: AUTH -> AUTH
Apr 1 16:34:00 laptop kernel: wpi_ops: command: 16
Apr 1 16:34:00 laptop kernel: config chan 1 flags 8035 cck f ofdm 15
Apr 1 16:34:00 laptop kernel: scanning channel 1 status 1
Apr 1 16:34:00 laptop kernel: scan finished nchan=0 status=2 chan=0
Apr 1 16:34:00 laptop kernel: wpi_ops: command: 4
Apr 1 16:34:36 laptop /root/bin/testwpi.sh: 50 packets transmitted, 0 packets
received, 100.0% packet loss
Apr 1 16:35:37 laptop /root/bin/testwpi.sh: 50 packets transmitted, 0 packets
received, 100.0% packet loss
Apr 1 16:36:38 laptop /root/bin/testwpi.sh: 50 packets transmitted, 0 packets
received, 100.0% packet loss
Apr 1 16:46:49 laptop last message repeated 10 times
And then my girl came home from work and did the "down and list scan trick":
Apr 1 17:53:06 laptop sudo: rachie : TTY=ttyp1 ; PWD=/home/rachie ;
USER=root ; COMMAND=/sbi
n/ifconfig wpi0 down
Apr 1 17:53:06 laptop kernel: Disabling Firmware execution
Apr 1 17:53:06 laptop kernel: wpi_newstate: AUTH -> INIT
Apr 1 17:53:10 laptop sudo: rachie : TTY=ttyp1 ; PWD=/home/rachie ;
USER=root ; COMMAND=/sbi
n/ifconfig wpi0 up list scan
Apr 1 17:53:11 laptop kernel: wpi0: timeout resetting Tx ring 1
Apr 1 17:53:11 laptop kernel: wpi0: timeout resetting Tx ring 3
Apr 1 17:53:11 laptop kernel: wpi0: timeout resetting Tx ring 4
Apr 1 17:53:11 laptop kernel: Disabling Firmware execution
Apr 1 17:53:11 laptop kernel: wpi_newstate: INIT -> INIT
Apr 1 17:53:11 laptop kernel: Resetting the card - clearing any uploaded
firmware
Apr 1 17:53:11 laptop kernel: Attempting Loading Firmware from wpi_fw module
Apr 1 17:53:11 laptop kernel: Firmware Version: Major 2, Minor 14, Driver 4,
Apr 1 17:53:11 laptop kernel: runtime (text: 80524, data: 32768) init (text:
2668, data 32768)
boot (text 900)
Apr 1 17:53:11 laptop kernel: rtext 0xf802020
Apr 1 17:53:11 laptop kernel: rdata 0x0
Apr 1 17:53:11 laptop kernel: itext 0xf802020
Apr 1 17:53:11 laptop kernel: idata 0x0
Apr 1 17:53:11 laptop kernel: btext 0xf802020
Apr 1 17:53:11 laptop kernel: Loading microcode size 0x384
Apr 1 17:53:11 laptop kernel: firmware status=0xffff0000, val=0x40400000,
result=0x40400000
Apr 1 17:53:11 laptop kernel: Status Match! - ntries = 0
Apr 1 17:53:11 laptop kernel: microcode alive notification version 10e02
alive 1
Apr 1 17:53:11 laptop kernel: microcode alive notification version 10e02
alive 1
Apr 1 17:53:11 laptop kernel: Firmware loaded to driver successfully
Apr 1 17:53:11 laptop kernel: wpi_newstate: INIT -> SCAN
Apr 1 17:53:11 laptop kernel: wpi_ops: command: 1
Apr 1 17:53:11 laptop kernel: wpi_ops: command: 8
<snipped lots of scanning>
Apr 1 17:53:13 laptop kernel: scan finished nchan=1 status=1 chan=165
Apr 1 17:53:13 laptop kernel: wpi_newstate: SCAN -> AUTH
Apr 1 17:53:13 laptop kernel: wpi_ops: command: 4
Apr 1 17:53:13 laptop kernel: wpi_ops: command: 8
Apr 1 17:53:13 laptop kernel: Ignoring WPI_SET_CHAN
Apr 1 17:53:13 laptop kernel: wpi_ops: command: 8
Apr 1 17:53:13 laptop kernel: Ignoring WPI_SET_CHAN
Apr 1 17:53:13 laptop kernel: wpi_ops: command: 16
Apr 1 17:53:13 laptop kernel: config chan 1 flags 8005 cck f ofdm 15
Apr 1 17:53:13 laptop kernel: wpi_newstate: AUTH -> ASSOC
Apr 1 17:53:13 laptop kernel: wpi_newstate: ASSOC -> RUN
Apr 1 17:53:13 laptop kernel: wpi_ops: command: 32
Apr 1 17:53:13 laptop kernel: config chan 1 flags 8035
Apr 1 17:53:13 laptop kernel: wpi0: link state changed to UP
At this point it's working again, connection is flakey with packet loss
ranging from 0 to 50% but it's working.
This is wpi from 7-RELEASE with patch mentioned in this thread.
--
Mel
Problem with today's modular software: they start with the modules
and never get to the software part.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200804021400.04442.fbsd.questions>