Orinoco testing + ARM (Byte-alignment problems, it seems)
david at gibson.dropbear.id.au
Wed Apr 17 15:18:33 EST 2002
On Tue, Apr 16, 2002 at 06:13:50PM -0700, Ben Greear wrote:
> David Gibson wrote:
> >On Tue, Apr 16, 2002 at 08:12:26PM -0400, Pavel Roskin wrote:
> >>Hi, Ben!
> >>>Have you done any lengthy tests...like 24hours+? I had a .9 driver
> >>>working good enough to last for about 24 hours before screwing up,
> >>>I may have to revert back to that one.
> >>No. I tried 10000 packets, which took about 1 minute. It's another sign
> >>that we are dealing with a race condition.
> >Yes, a problem that only shows up after 24 hours is unlikey to be an
> >ARM-specific alignment problem.
> Agreed. I didn't mean to imply that was an alignment problem, only
> that there are several problems, not necessarily related.
> For my particular NIC (XI-825 CF), the problems seem to be:
> Byte alignment: Probably fixed, at least in the 'normal' paths.
> Various timeouts after slow lengthy runs: With the .11 (testing) code,
> I see the -110 BAP errors using ping (not ping -f) after about 2k
Yes, we seem to get these on quite a lot of cards - although yours
seems to be particularly susceptible to this bug. I'm still working
on fixing this.
> Timeouts after short fast runs: ping -f kills it in about 5 seconds.
That being a case in point.
> If there is an attempt to reset the card, it fails. The only way
> to recover, that I have found, is to pull out the NIC and wait
> a few seconds (maybe 20) to allow the modules to detect removal and
> clean everything up. This lengthy time may be due to dhcp trying to
> release it's lease I believe.
> Is there any reason not to try to reset the card after 3 consecutive -110
> errors? If the soft-reset fails, can we programatically drop power to it
> through the CF system so we can guarantee a reset?
I do plan to add something like this, but it's slightly fiddly so I
haven't had time to do it yet. There are couple of potential issues:
first there seem to be quite a lot of circumstances in which a normal
firmware reset is insufficient to fix the problem, and even some where
a PCMCIA COR reset is insufficient. Secondly it would be nice to know
why we're getting these timeouts in the first place rather than just
patching around it - it seems the Intersil firmware is falling over,
which probably means we're doing something to it that we shouldn't,
but I don't know what.
David Gibson | For every complex problem there is a
david at gibson.dropbear.id.au | solution which is simple, neat and
| wrong. -- H.L. Mencken
More information about the wireless