RTL8102EL / Ubuntu 8.04 intermitent failure
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
This is probably related to bug #223656. I just finished building a new system with the Atom-based D945GCLF motherboard, which includes a Realtek RTL8102EL Ethernet chip. (Actually, it's just the motherboard and a hard drive for now.)
I managed to install Ubuntu Hardy Server on it, with the kernel 2.6.24-19.33/amd64. (I hacked the kernel by hand into the server NetBoot image, since I don't have a CD drive in that computer. Incidentally, this means that the network card itself works perfectly when it's running, as I installed the entire system through it; but see below.)
The problem now is that sometimes the network works perfectly, but sometimes it doesn't seem to work at all: there are no messages I can see in /var/log or dmesg, ifconfig shows the network as usually, the leds light up in the network connectors, but no packet passes by. I have it setup to get an address via DHCP from my laptop (the two are connected directly via ethernet cable), and when this happened I thought perhaps my server was misconfigured. So I fired up Wireshark and it shows _nothing_ passing through that cable; when the network works, I can see everything working beautifully.
I can't figure it out at all; nothing seems to be wrong, I can't see any errors anywhere, but nothing seems to go through the cable... I can't figure out a pattern exactly either. It seems that it depends on whether I used "shutdown -r now" or "shutdown -h now" last time I shut down the Atom, but I can't decide on an exact pattern.
Any ideas where to look next? What debug info should I post?
[Tue Jun 17 00:11:46 CEST 2008 – Edited to add that I'm using the amd64 edition of Ubuntu.]
description: | updated |
Changed in linux: | |
status: | Fix Released → Confirmed |
I just realized I didn't mention this explicitly: the kernel that comes in the installer images (the netboot ones at least) broke during boot, exactly as it's described in the bug I linked above. That's why I needed to use the -19.33 kernel.