Orinoco testing + ARM (Byte-alignment problems, it seems)

[David Gibson]

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
> packets.

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
http://www.ozlabs.org/people/dgibson