[vortex] reproducable pci bus errors (905c-tx, target abort)

Sven Golchert golchert@uni-bremen.de
Thu, 16 Aug 2001 02:01:23 +0200


Donald Becker wrote:
> 
> On Tue, 14 Aug 2001, Sven Golchert wrote:
> 
> > whenever i route traffic over the 3c905C-TX (eth1 in my
> > configuration), it will break with a
> >   PCI bus error, bus status 40000020
> 
> PCI target abort when operating as a bus master.
> Bad news.
> 
> It can only be cleared with a TotalReset/GlobalReset while leaving bit
> 0x100 clear.
> My driver does a different reset than LK1.1.12.
> You might give it a try.
>  http://www.scyld.com/network/vortex.html
>     ftp://ftp.scyld.com/pub/network/3c59x.c
> 
> Please send a report so we know if this version of the reset code works.

i tried to use the newer driver, but it didn't access the NICs at their correct I/O port addresses and thus didn't find the transceivers. i forgot my notes in office, but the newer driver tried to find the NICs at an I/O port address around 0x0c23???? (the exact addresses changed every time i removed and re-inserted the module, seemingly following a regular pattern...), while lspci and pci-diag still reported the correct addresses, 0x4000 and 0x4080 - only 3c59x.o doesn't think so. i took 3c59x.c and pci-scan.c from the same ftp-dir, along with kern_compat.h and pci-scan.h  -  could the problem arise from compiling the module on a different workstation and only moving the object code to my firewall? i chose not to install a compiler on my firewall...

if i can make the driver work, i will happily report whether the reset code recovers the error.
 
> Even if this driver version recovers, this isn't a fix.  A PCI bus error is
> still a major, performance-impacting problem.

well yeah, obviously. i don't know whether the LK1.1.12 doesn't recover at all or trying but failing to come up again: once the eth1-connection is down it's repeatedly (20 times a second) messaging the pci bus error while trying to negotioate the link configuration. 

> Something can help with finding a work-around for the '486 is the value
> of Up/DnMaxBurst, which reports the maximum successful PCI burst length
> for Tx and Rx (16 bits for each).
> This register is at offset 0x78.

i haven't understood how i would have to apply this work-around. i assume i can read the registers using pci-diag, but what would i do with the reported values? code them into 3c59x.c somewhere?

is the 3c905B more tolerant to the faulty pci implementation of older motherboards? after all, the 3c905B-FX is working to my full convenience, and at the moment i consider upgrading the motherboard or replacing 3c905C with a 3c905B-Tx to make it work.

and if you could answer a stupid question please: i overwrote the working 3c59x.c:LK1.1.12 with the new module - so silly, i know. unfortunately i am not able to compile the old driver version from the /usr/src/linux tree (using the same compiler command as suggested in the newer version throws lots of errors, like missing statements and definitions). i can't use the existing 3c59x.o from the "compile" linux box in my office either, because that one on insertion says it were compiled for linux-2.4.0-4GB, not linux-2.4.0. :( could you please tell me how to compile the old driver? my knowledge of linux isn't that far as of yet.

thanks for your help
sven