Note: Tulip-specific bug reports should be sent to the tulip mailing list,
not to linux-net.
On Mon, 8 Nov 1999, Christoph Dworzak wrote:
> Summary
> -------
> I get transmission-errors on the Ethernet and system lockups
> when using this 4-Port Adaptec NIC.
What kind of transmission error?
System lock-ups are not a typical Tulip problem.
> -IRQs reported by /proc/pci (9,10,11,5) and tulip (9,9,9,9)
> do not match (see attached outputs)
The Tulip driver has explicit code to convert all multiport card IRQs to the
IRQ of the first device. This is to work around a very common BIOS bug with
assigning IRQs.
This is done around line 783 with #if defined(__386__)
You can verify that this is a correct setting for your system by monitoring
/proc/interrupts and comparing it to the packet Tx and Rx counts.
This might seem like a bogus fix-up, but the problem is almost ubiquitous on
x86 BIOSes.
> -ping shows checksum-errors (see log below)
This is a bug in 'ping'. (I get *lots* of bogus bug reports about this.)
> -nfs-transfers of small files sometimes work, big files crash
> the machine for shure.
Hmmm, this points to a hardware problem rather than a driver problem.
> -/var/log/messages shows sometimes garbled messages such as:
> [date..] kernel: ng interrupt, csr5=0xfc660000.
> [date..] kernel: interrupt, csr5=0xfc660000.
> [date..] kernel: rupt, csr5=0xfc660000.
> [date..] kernel: pt, csr5=0xfc660000.
> [date..] kernel: r5=0xfc660000.
> (sorry, this is copy&paste by eye, brain, finger as using a
> floppydisk to transfer things gets old real quick... :)
Are you running with debug set to a high setting? That will put a *very*
heavy load on the machine and could cause packet drops during periods of
heavy activity.
> Adaptec ANA-6944A/TX Quartet NIC (4xDEC 21140 + 1xDEC 21152)
...
> RH6.1
> kernel 2.2.13+tulip0.91g
> (I first tried kernel-2.2.12-20 as provided by RH with
> tulip0.89H)
> # ping -n a.b.c.d
> PING a.b.c.d (a.b.c.d) from a.b.c.e : 56(84) bytes of data.
> 64 bytes from a.b.c.d: icmp_seq=0 ttl=255 time=3.1 ms (BAD CHECKSUM!)
> wrong data byte #14 should be 0xe but was 0x2
This is the 'ping' bug.
The hardware CRC and IP checksum will prevent corrupted packets from being
seen.
Donald Becker
Scyld Computing Corporation, and
USRA-CESDIS, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
