Hey y'all A quick question with linux 2.4 (various flavours). I've been working with 2.4 since the 2.4.0test3 release, and here's an issues that I've seen with 2.4.2 and later. I'm working with a box (and Intel ISP 2150) using 2 3COM 905B PCI cards and 1 built-in NIC, which is an Intel Etherexpress 10/100 Here's my issues: 1) This issue seems to be fixed with 2.4.3, and i think it has to do with the PCI pnp support -> I was having all these cards and one of the PCI NICS was picking up the same IRQ as the built-in NIC, and I got this message reliably: --- Apr 24 15:47:49 colo-firewall kernel: NETDEV WATCHDOG: eth0: transmit timed out Apr 24 15:47:49 colo-firewall kernel: eth0: transmit timed out, tx_status 00 status e601. Apr 24 15:47:49 colo-firewall kernel: diagnostics: net 0cfa media 8880 dma 0000003a. Apr 24 15:47:49 colo-firewall kernel: eth0: Interrupt posted but not delivered -- IRQ blocked by another device? Apr 24 15:47:49 colo-firewall kernel: Flags; bus-master 1, dirty 432239(15) current 432239(15) ---- It would happen randomly and be fixed by a reboot. The symptom was the listed ethernet card shutting down. Anyways, I upgraded to 2.4.3, and this seemed to go away. However, the other day, I started having a similar problem, with the same end result hapenning: ----- May 4 12:52:28 colo-firewall kernel: NETDEV WATCHDOG: eth2: transmit timed out May 4 12:52:28 colo-firewall kernel: eth2: Transmit timed out: status f048 0c00 at 517424/517452 command 200ca000. May 4 12:54:12 colo-firewall kernel: NETDEV WATCHDOG: eth2: transmit timed out May 4 12:54:12 colo-firewall kernel: eth2: Transmit timed out: status f048 0c00 at 517452/517480 command 0001a000. May 4 12:55:00 colo-firewall kernel: NETDEV WATCHDOG: eth2: transmit timed out May 4 12:55:00 colo-firewall kernel: eth2: Transmit timed out: status f048 0c00 at 517480/517508 command 0001a000. May 4 12:57:40 colo-firewall kernel: NETDEV WATCHDOG: eth2: transmit timed out ----- Any clues? Eth2 is the EEPro 100 Card. It shares an IRQ with Eth1, but eth1 isn't actually in use, so it shouldn't, technically, matter. (they use a different IO address, so the same IRQ shouldn't be an issue). A reboot fixes the issue temporarily, but not on a permanent basis. I've put the full (edited) logs up on our website: http://www.voyus.com/watchdog.txt Cheers, Liam - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
