I've encountered this problem before and I believe it may affect other drivers (I could test but I don't have time). This was happening on my custom Linux system with the pcnet32 driver.
pcnet32: eth0: transmit timed out, status 97fb, resetting
(and some other kernel module tracing in dmesg)
Basically it means the card is connected (it shows connected in full duplex etc.. and recognized if the cable is disconnected too) but no packets can be sent or received. I've read people say they think it's a bad card (I've actually threw some of these cards away in the past, thining the same thing!, others commented they believed the card was dead/bad or that it wasn't seated properly in their situation but I think it is likely the IOAPIC issue they found) but it's a driver/IOAPIC issue.
This was tested with a VBOX/Virtualbox machine but it seems to apply equally to physical machines (based on what I've read elsewhere). If you have IOAPIC enabled, this driver won't work until it's disabled.
Now, the tricky thing is that with some computers and in VBOX, Centos 5 and possibly other Linux/OS won't boot successfully.
1.) Disable IOAPIC in the motherboard (but some OS's won't boot without IOAPIC enabled).
2.) Specify the kernel option "pci=noapic" and it will work.
I hope this helps others out as I believe I've run into this issue unknowingly in many situations over the years.
One more comment is that on the very same system, I changed the NIC to an Intel and this issue did not happen with the Intel NIC (even with IOAPIC enabled), so this appears to mean that the pcnet32 driver is garbage/has an issue with IOAPIC on systems.
pcnet, eth, transmit, timed, fb, resetting, nic, solutioni, ve, encountered, drivers, custom, linux, kernel, module, tracing, dmesg, duplex, etc, disconnected, packets, thining, commented, wasn, seated, ioapic, vbox, virtualbox, equally, elsewhere, enabled, disabled, tricky, centos, os, successfully, solutions, disable, motherboard, specify, quot, pci, noapic, unknowingly, intel,