[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