Orinoco Wireless driver bugs in 2.5.17

Orinoco Wireless driver bugs in 2.5.17

[Peter Chubb]

Hi,
	I see two undesireable behaviours with the Orinoco drivers in
2.5.17.

1.  With a compaq WL110 in a WL210 PCI<->PCMCIA bridge, I see many 

    NETDEV WATCHDOG: eth1: transmit timed out
    Tx timeout! Resetting card. ALLOCFID=00c0, TXCOMPLFID=00bf, EVSTAT=808a

messages, and see no activity on any other stations.

2.  With a Netgear MA401, every now and then the card goes into bozo
mode, when iwconfig reports:

eth0      IEEE 802.11-DS  Nickname:"piggle"
          Mode:Managed  Frequency:42.9497GHz  Tx-Power=15 dBm   
          RTS thr:off   
          Link Quality:241  Signal level:136  Noise level:107
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0


Note the Frequency there.  A `cardctl reset' fixes the problem.

Peter C

Re: Orinoco Wireless driver bugs in 2.5.17

[David Gibson]

On Wed, May 22, 2002 at 10:06:36AM +1000, Peter Chubb wrote:
> 
> Hi,
> 	I see two undesireable behaviours with the Orinoco drivers in
> 2.5.17.
> 
> 1.  With a compaq WL110 in a WL210 PCI<->PCMCIA bridge, I see many 
> 
>     NETDEV WATCHDOG: eth1: transmit timed out
>     Tx timeout! Resetting card. ALLOCFID=00c0, TXCOMPLFID=00bf, EVSTAT=808a
> 
> messages, and see no activity on any other stations.

I've had one similar report, on a vaguely similar PCI<->PCMCIA
bridge.  It looks very much as if we're not receiving any interrupts.
That would appear to be a low-level problem with routing of interrupts
through the bridge.  It may well be a PCMCIA subsystem problem rather
than a driver problem.

> 2.  With a Netgear MA401, every now and then the card goes into bozo
> mode, when iwconfig reports:
> 
> eth0      IEEE 802.11-DS  Nickname:"piggle"
>           Mode:Managed  Frequency:42.9497GHz  Tx-Power=15 dBm   
>           RTS thr:off   
>           Link Quality:241  Signal level:136  Noise level:107
>           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>           Tx excessive retries:0  Invalid misc:0   Missed beacon:0
> 
> 
> Note the Frequency there.  A `cardctl reset' fixes the problem.

Other than the bogus frequecy reported, does the card still work?

-- 
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson

Re: Orinoco Wireless driver bugs in 2.5.17

[Alan Cox]

> I've had one similar report, on a vaguely similar PCI<->PCMCIA
> bridge.  It looks very much as if we're not receiving any interrupts.
> That would appear to be a low-level problem with routing of interrupts
> through the bridge.  It may well be a PCMCIA subsystem problem rather
> than a driver problem.

The Compaq WL1xx orinoco simply doesn't work on 2.4.18 anyway. The older
driver works, the newer one fails totally.

Re: Orinoco Wireless driver bugs in 2.5.17

[Jean Tourrilhes]

Alan Cox wrote :
> The Compaq WL1xx orinoco simply doesn't work on 2.4.18 anyway. The older
> driver works, the newer one fails totally.

	Alan,
	Could you be more precise and point out which kernel start
failing ?

	David,
	If I remember properly my debug session with Alan (that was a
long while ago), the COR reset was screwing up the firmware (well, how
many time did I told you to not make it mandatory ?).
	Alan has an old Compaq card (the Intersil PrismII variety, not
the new Lucent one) and his firmware is probably not very fresh.

	Good luck...

	Jean

Re: Orinoco Wireless driver bugs in 2.5.17

[Jean Tourrilhes]

On Wed, May 22, 2002 at 07:24:37PM +0100, Alan Cox wrote:
> > 	Alan,
> > 	Could you be more precise and point out which kernel start
> > failing ?
> 
> Certainly in 2.4.18 (and I've seen a pile of other similar reports).

	2.4.18 did upgrade the driver from 0.06f to 0.09b. The bug
with 0.09b is a race condition in Tx code. This was fixed in version
0.11.
	Have you tried 2.4.19-pre8-acX (well, I mean the Orinoco
driver in 2.4.19-pre8 ;-). It contains the new version of the driver
(v11) that fixes the race condition (but introduce the potential COR
problem).
	If 2.4.19-pre8-acX fails, that would be for an entirely
different reason (even if the failure might look similar).

> Any specific info/debug/traces that would help ?

	I'll defer that to David.

> Alan

	Good luck...

	Jean

Re: Orinoco Wireless driver bugs in 2.5.17

[Alan Cox]

> 	Alan,
> 	Could you be more precise and point out which kernel start
> failing ?

Certainly in 2.4.18 (and I've seen a pile of other similar reports).

> 	If I remember properly my debug session with Alan (that was a
> long while ago), the COR reset was screwing up the firmware (well, how
> many time did I told you to not make it mandatory ?).

Long time ago -its been behaving well until fairly recently

> 	Alan has an old Compaq card (the Intersil PrismII variety, not
> the new Lucent one) and his firmware is probably not very fresh.

Oldish firmware definitely. The newer driver finds the card registers
it but fails on all tx/rx and reports no signal and noise of
130/150 or so (as opposed to db). Flipping back to the older kernel it
works happily. 

Any specific info/debug/traces that would help ?


Alan

Re: Orinoco Wireless driver bugs in 2.5.17

[David Gibson]

On Wed, May 22, 2002 at 07:24:37PM +0100, Alan Cox wrote:
> > 	Alan,
> > 	Could you be more precise and point out which kernel start
> > failing ?
> 
> Certainly in 2.4.18 (and I've seen a pile of other similar reports).

Ah, bugger.

> > 	If I remember properly my debug session with Alan (that was a
> > long while ago), the COR reset was screwing up the firmware (well, how
> > many time did I told you to not make it mandatory ?).
> 
> Long time ago -its been behaving well until fairly recently
> 
> > 	Alan has an old Compaq card (the Intersil PrismII variety, not
> > the new Lucent one) and his firmware is probably not very fresh.
> 
> Oldish firmware definitely. The newer driver finds the card registers
> it but fails on all tx/rx and reports no signal and noise of
> 130/150 or so (as opposed to db). Flipping back to the older kernel it
> works happily. 

The signal/noise bit is probably a red herring.  We have problems with
the reporting of this, but it's mostly cosmetic.  I seem to have
confusing and contradictory information about how to interpret the
values the firmware reports.

> Any specific info/debug/traces that would help ?

Specific error messages on Tx/Rx and also the firmware version as
reported on module load would be very helpful.

-- 
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson

Re: Orinoco Wireless driver bugs in 2.5.17

[David Gibson]

On Wed, May 22, 2002 at 11:17:51AM -0700, Jean Tourrilhes wrote:
> On Wed, May 22, 2002 at 07:24:37PM +0100, Alan Cox wrote:
> > > 	Alan,
> > > 	Could you be more precise and point out which kernel start
> > > failing ?
> > 
> > Certainly in 2.4.18 (and I've seen a pile of other similar reports).
> 
> 	2.4.18 did upgrade the driver from 0.06f to 0.09b. The bug
> with 0.09b is a race condition in Tx code. This was fixed in version
> 0.11.

Yes.  Unfortunately a bunch of the bug fixes we made between 0.06f and
0.09b uncovered other, even worse, bugs - at least on some
hardware/firmware.

It also would have helped if I'd been pushing to the kernel more
frequently, but I got slack.

> 	Have you tried 2.4.19-pre8-acX (well, I mean the Orinoco
> driver in 2.4.19-pre8 ;-). It contains the new version of the driver
> (v11) that fixes the race condition (but introduce the potential COR
> problem).
> 	If 2.4.19-pre8-acX fails, that would be for an entirely
> different reason (even if the failure might look similar).

Yes checking 0.11b, which is in Marcelo's latest -pres (and in
2.5.17), would be very helpful

-- 
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson

Re: Orinoco Wireless driver bugs in 2.5.17

[Erik McKee]

Hello!

Been using the plx driver in 2.4.19pre sucessfully, but just recently started
misbehaving....see my previous post about kernel bug in 2.4.19-pre8-ac1 for
info on this at the end of that mail ;)

TIA
Erik

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

Re: Orinoco Wireless driver bugs in 2.5.17

[Peter Chubb]

>>>>> "David" == David Gibson <hermes@gibson.dropbear.id.au> writes:

David> On Wed, May 22, 2002 at 07:24:37PM +0100, Alan Cox wrote:
>> > Alan, > Could you be more precise and point out which kernel
>> start > failing ?
>> 
>> Certainly in 2.4.18 (and I've seen a pile of other similar
>> reports).

David> Ah, bugger.

FWIW, with 2.4.17 the orinoco driver in the Compaq PCI bridge works.

In 2.4.18 it does not.  I see no interrupts for the device in
/proc/interrupts.

This is from v2.4.17:
May 27 11:49:20 wombat kernel: Linux Kernel Card Services 3.1.22
May 27 11:49:20 wombat kernel:   options:  [pci] [cardbus] [pm]
May 27 11:49:20 wombat kernel: Yenta IRQ list 0000, PCI irq17
May 27 11:49:20 wombat kernel: Socket status: 10000011
May 27 11:49:20 wombat kernel: cs: IO port probe 0x0c00-0x0cff: clean.
May 27 11:49:20 wombat kernel: cs: IO port probe 0x0800-0x08ff: clean.
May 27 11:49:20 wombat kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x290-
0x297 0x3f0-0x3ff 0x4d0-0x4d7
May 27 11:49:20 wombat kernel: cs: IO port probe 0x0a00-0x0aff: clean.
May 27 11:49:20 wombat kernel: cs: memory probe 0xa0000000-0xa0ffffff: clean.
May 27 11:49:21 wombat kernel: hermes.c: 3 Oct 2001 David Gibson <hermes@gibson.dropbear.id.au>
dropbear.id.au>
May 27 11:49:21 wombat kernel: orinoco.c 0.08a (David Gibson <hermes@gibson.dropbear.id.au> and others)
May 27 11:49:21 wombat kernel: orinoco_cs.c 0.08a (David Gibson <hermes@gibson.dropbear.id.au> and others)
May 27 11:49:21 wombat kernel: eth1: Station identity 001f:0001:0006:0010
May 27 11:49:21 wombat kernel: eth1: Looks like a Lucent/Agere firmware version 6.16
May 27 11:49:21 wombat kernel: eth1: Ad-hoc demo mode supported.
May 27 11:49:21 wombat kernel: eth1: IEEE standard IBSS ad-hoc mode supported.
May 27 11:49:21 wombat kernel: eth1: WEP supported, "128"-bit key.
May 27 11:49:21 wombat kernel: eth1: MAC address 00:02:A5:2E:10:BA
May 27 11:49:21 wombat kernel: eth1: Station name "HERMES I"
May 27 11:49:21 wombat kernel: eth1: ready
May 27 11:49:21 wombat kernel: eth1: index 0x01: Vcc 5.0, irq 17, io 0x0100-0x013f

Re: Orinoco Wireless driver bugs in 2.5.17

[Jean Tourrilhes]

On Wed, May 29, 2002 at 07:40:27PM +0100, Alan Cox wrote:
> On Thu, 2002-05-23 at 02:25, David Gibson wrote:
> > The signal/noise bit is probably a red herring.  We have problems with
> > the reporting of this, but it's mostly cosmetic.  I seem to have
> > confusing and contradictory information about how to interpret the
> > values the firmware reports.
> 
> Ok the old driver gets the noise level right, the newer one got it
> wrong, the current one gets it wrong. The good news is the old one
> works, the new one didnt, the current 2.4.19pre one does...
> 
> Alan

	David,

	In the linux-wlan-ng, I did implement a different algorithm to
report signal/noise in /proc/net/wireless, based on various info on
the list. Mark Matthews did check with some people and told me it was
the right algorithm for the Intersil firmware.
	Note that I'm not sure we ever got it right.
	Also, in the past, we had the min/max wrapper that avoided
"strange" values, and I think that's what people are mostly
complaining about. So, maybe we should reintroduce the min/max.
	Regards,

	Jean

Re: Orinoco Wireless driver bugs in 2.5.17

[Alan Cox]

On Thu, 2002-05-23 at 02:25, David Gibson wrote:
> The signal/noise bit is probably a red herring.  We have problems with
> the reporting of this, but it's mostly cosmetic.  I seem to have
> confusing and contradictory information about how to interpret the
> values the firmware reports.

Ok the old driver gets the noise level right, the newer one got it
wrong, the current one gets it wrong. The good news is the old one
works, the new one didnt, the current 2.4.19pre one does...

Alan

Re: Orinoco Wireless driver bugs in 2.5.17

[David Gibson]

On Wed, May 29, 2002 at 07:40:27PM +0100, Alan Cox wrote:
> On Thu, 2002-05-23 at 02:25, David Gibson wrote:
> > The signal/noise bit is probably a red herring.  We have problems with
> > the reporting of this, but it's mostly cosmetic.  I seem to have
> > confusing and contradictory information about how to interpret the
> > values the firmware reports.
> 
> Ok the old driver gets the noise level right, the newer one got it
> wrong, the current one gets it wrong. The good news is the old one
> works, the new one didnt, the current 2.4.19pre one does...

Um, ok, now I'm a bit lost.  I'm guessing by "old driver" you mean the
pre 2.4.18 one (0.06f?) by "new driver" you mean the one in 2.4.18 and
"current driver" means the one in 2.4.19pre (0.11b) - i.e. newer than
the "new" one.  Is that right?

-- 
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson

Re: Orinoco Wireless driver bugs in 2.5.17

[Alan Cox]

On Mon, 2002-06-03 at 00:38, David Gibson wrote:
> 
> On Wed, May 29, 2002 at 07:40:27PM +0100, Alan Cox wrote:
> > On Thu, 2002-05-23 at 02:25, David Gibson wrote:
> > > The signal/noise bit is probably a red herring.  We have problems with
> > > the reporting of this, but it's mostly cosmetic.  I seem to have
> > > confusing and contradictory information about how to interpret the
> > > values the firmware reports.
> > 
> > Ok the old driver gets the noise level right, the newer one got it
> > wrong, the current one gets it wrong. The good news is the old one
> > works, the new one didnt, the current 2.4.19pre one does...
> 
> Um, ok, now I'm a bit lost.  I'm guessing by "old driver" you mean the
> pre 2.4.18 one (0.06f?) by "new driver" you mean the one in 2.4.18 and
> "current driver" means the one in 2.4.19pre (0.11b) - i.e. newer than
> the "new" one.  Is that right?

It is right.