Re: Hardware for Debian-68k
> > I see what you mean :-) There's a few obvious things like these:
> >
> > - sonic_write(dev, SONIC_ISR,0x7fff);
> > - sonic_write(dev, SONIC_IMR,0);
> > + SONIC_WRITE(SONIC_IMR, 0);
> > + SONIC_WRITE(SONIC_ISR, 0x7fff);
>
> It's funny you chose those lines. I still can't figure out if that change
> is better or not :-) I just found it more readable, but I almost persuaded
> myself to leave it unchanged.
If you first clear the status register, an interrupt may come in before
you mask (but that should not matter if interrupts are off). That
interrupt is still going to be seen after unmasking. So it should be OK.
> > and the transmit timeout handling, but the driver has been largely
> > rewritten. I'll have to look at it some more to see what might be used.
>
> I think that the bug that bit Wouter's 950 was a race between the tx code
> and the interrupt handler (though it was a while ago that I looked at
> this). If so, the 2.6 version could need a complete back-port, since both
> algorithms changed significantly to get zero-copy in the present version
> (and to adopt the DMA API, which isn't in 2.2). There is probably a
> quicker fix.
If you could remember what the nature of the race was, I could perhaps
find a way to prevent it. Note that the transmit function now only stops
the queue if the ring is full; that may be important.
> > Seeing how 2.2 is largely more of a problem than a solution these days,
> > I won't give it high priority either.
>
> Sonic is a real pain to test major changes on (like that rewrite). There
> are onboard variants, nubus and comm-slot, 16 and 32 bit DMA variants, and
I'd hope the changes do not need to be major. But it's perhaps eight years
since I tested code on the sonic :-)
Michael
Reply to: