Messages in this thread | | | Subject | Re: eth0 CU wedged - just prior to full lock | Date | Sat, 03 Apr 1999 17:54:32 +1000 | From | Brian May <> |
| |
In article <Pine.LNX.3.96.990401185301.462H-100000@red.prv> you write: >I've been seeing lines in my syslog similar to the following: > >Mar 30 12:49:27 meteng kernel: eth0: CU wedged, status 0040 0000, resetting... > >There are several entries like this at various times in the day. >Today the machine froze solid for no apparent reason just after >displaying the above message on the console. > >The machine is using an EtherExpress 16 (ISA) currently. Is this >card or driver flawed?
I have had very similar results with a computer with the same card. Right now, I can't find the same message you quoted above (I am accessing it via a congested Internet connection), although I am sure I have seen it, but I do get ones like the following:
Mar 29 10:01:21 share kernel: eth0: tx interrupt but no status Mar 29 10:01:21 share last message repeated 3 times Mar 29 15:45:50 share kernel: eth0: transmit aborted, too many collisions Mar 29 16:06:22 share kernel: eth0: transmit aborted, too many collisions Mar 29 16:23:50 share kernel: eth0: transmit aborted, too many collisions
I don't trust that particular computer one bit, so I wouldn't have mentioned it but it sounds a little bit similar to the problems you describe.
The "too many collisions" might be network congestion. I haven't bothered to investigate yet. Is this normal?
(Off-topic: On startup I get the following errors, first three repeated x3: Mar 29 21:17:13 share kernel: hda: drive not ready for command Mar 29 21:17:13 share kernel: hda: status error: status=0x01 { Error } Mar 29 21:17:13 share kernel: hda: status error: error=0x04 { DriveStatusError } Mar 29 21:17:13 share kernel: hda: drive not ready for command Mar 29 21:17:13 share kernel: ide0: reset: success - the harddisk appears to work OK however I am very suspicious and don't trust it or the computer).
However, in my case, these messages haven't had any noticable affect on system useability. The computer does seem slow, but it is only a 40MHz 486 with 16Mb ram (I think)...
>Any help would be greatly appreciated. The machine required >manual fsck after rebooting, and contained a corrupt superblock.
I haven't had this computer crash on me. Apart from rather serious looking messages, it seems rather reliable ;-).
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |