Intrepid Ibex 2.6.27-7: r8169 driver does not work with Realtek RTL8111B gigabit ethernet chip in Ubuntu 8.10 BETA

I experience the same problem with this kernel, using a Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01) on a Acer TravelMate 4000. Works fine with the previous kernel.

Same problem here, with Realtek RTL8168C/8111C ethernet adapter.
System is ASUS X56T laptop with 4 GB RAM and Turion ZM82 CPU.
Kernel boot parameters are noapic, nolapic, and acpi=ht; otherwise it will not boot.

Vanilla Hardy install (original 8.04 CD) --> works
Hardy with all updates --> still works

Hardy upgrade to Intrepid with update-manager -d --> ceases to work after reboot with new system
Intrepid beta CD install --> does not work

The network card does not get an IP address via DHCP. Manually assigning one does not help. No address in the same network (e.g. computer 192.168.2.16, gateway 192.168.2.1, netmask 255.255.255.0) can be pinged.

Already reported in https://bugs.launchpad.net/bugs/212497, but bug is closed and reported as fixed. The problem persists however.

If you need any logs please say so, as I am not very experienced in reporting bugs, and, as I cannot work on the broken installation (no network and no graphics), I'll have to reboot to that partition to check.

Patrick

Sorry, I forgot:
This seems to affect 32 bit and 64 bit alike. The upgraded and then dysfunctional Hardy->Intrepid installation was 32 bit, and the fresh Intrepid CD installation not working from the beginning was 64 bit.

Patrick

Just tested with Intrepid final live CD (AMD64). Network still not working. lspci attached.

And here comes lsmod output

Tested with a live DVD with two other distros. The problem is also present in openSuse 11.1 beta, but *not* in Fedora 10 beta (all with 2.6.27 kernels). In Fedora everything is fine, the network card works, DHCP works, internet works, every thing. Strange.

Patrick

Hey Patrick, thanks for your tests. Did you use live DVDs for 64bit architecture?

I'm thinking about compiling the module myself, at this point, even though I already tried when 8.10 was still in Alpha and didn't succeed.
There were some hints and links on another and older bug report, the one about RTL8168/8111C that refers mainly to older Ubuntu versions.
Anyway, I'll post anything good that comes out of it.

Emanuele

Emanuele, I think I used the 64 bit variants (the CD contains both) since my main motive was to have an operating system that can use the full 4 GB that I have.

The thing with the older Ubuntu versions is, it looks as if it did not work in Gutsy. It definitely works in Hardy on my machine. It definitely does not work in any variant of Intrepid (32 or 64 bit, beta or final, live CD, upgrade or clean install). And the fact that it is a r816*9* driver dealing with an r816*8* card is not the sole cause, since this constellation is in Hardy also, and it works there.

May be a regression.

Patrick

s/CD/DVD/

I have made a strange observation, maybe it helps anyone to find out what the problem is.

I now work on Hardy, since I can't use Intrepid without network. Because otherwise my machine hangs during boot, I use the kernel parameter "acpi=off" (or "acpi=ht"). With these parameters, the network card works fine under Hardy (kernel 2.6.24-21-generic).

BUT... if I remove "acpi=off" and add "nosmp", the same symptoms occur with Hardy (no network, no DHCP, also no network with manual IP config) as reported here for Intrepid. This is reproducible.

I will now make a final test and see if the Intrepid live CD has network if booted with "acpi=off".

Patrick

So, back from rebooting...

Intrepid live CD with "acpi=off" --> network OK
Intrepid live CD without "acpi=off" (but with "noapic nolapic", otherwise it hangs) --> no network

So: probably a problem with ACPI. The card seems to have a sleep mode, see the Realtek page:

"Features
[...]
    * Supports power down/link down power saving"

Patrick

I believe I'm suffering from the variant of this bug on kernel 2.6.27-7-generic with a Realtek RTL8111B on an ASUS P5B

During boot, just after Activating Swapfile Swap [OK], boot hangs, and must be restarted with control-alt-delete before it
will move to Loading ACPI Modules....

After boot, the network is down, although running /etc/init.d/networking restart after boot seems to bring the networking back up.

I have a solution :-)

Following a tip from news://de.comp.os.unix.linux.misc, I tried various kernel parameters, and *for me* it seems to be an ACPI bug. With the parameter "pci=nomsi", my Realtek RTL8111/8168B network adapter now works under both Hardy and Intrepid.

Please tell if this helps you also or if there are different bugs leading to a nonfunctioning Realtek network adapter.

Patrick

I have a DELL Vostro 1510, with an Intel 3945 Pro (Wifi) and a Realtek RTL8111/8168B (Wired), I've tried to fix my wiredcard, but it doesn't work under Hardy or Intrepid. When I read what Patrick posted about Fedora 10, I was exited to try it, so I gave it a try. And my wiredcard WORKS EXCELLENT under Fedora 10. Can anyone tell me why's that?

I also have a Dell Vostro 1510 with the RTL8111/6168B and I have the same problem too. I tried to use acpi=off or pci=nomsi as boot parameters (with 2.6.27-7 and 2.6.27-9) but it didn't seem to change anything. The network stays unavailable either using the Network Manager either disabling it completely. In the last case, you can still get an eth0 up, put an IP to it (module r6169 is loaded, eth0 appears) but nothing more (no ping, etc...).

I'm having the same problem on a gigabyte board with built-in realtek nic. I've found numerous bugs for the same issue, not sure which is the main one and if ubuntu team is checking for duplicates.

I have created a script on another machine that emails me when the link is down. I then crosschecked against all my logs and could not find anything related to the network going down.

This problem seems to be happening since 2.26.24 on r8169 (as per bugs I found).

My machine has two cards (second is a different brand), only the Realtek stops working.

==============================================================================

OS: Ubuntu Intrepid AMD64

Problem:
Card stops working for a period of time (usually 5-15 minutes)

Bugs I found: 76489, 212497, 256331, 286489, 293661, 205374, 141343

=>lspci -vvv | less
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
        Subsystem: Giga-byte Technology Device e000
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 2300
        Region 0: I/O ports at c000 [size=256]
        Region 2: Memory at f6000000 (64-bit, non-prefetchable) [size=4K]
        [virtual] Expansion ROM at fa100000 [disabled] [size=128K]
        Capabilities: <access denied>
        Kernel driver in use: r8169
        Kernel modules: r8169

=>cat /proc/version_signature
Ubuntu 2.6.27-7.16-server

=>ifconfig
RX bytes:10506838810 (10.5 GB) TX bytes:1987163061 (1.9 GB)

=>dmesg
[169782.011271] ------------[ cut here ]------------
[169782.011278] WARNING: at /build/buildd/linux-2.6.27/net/sched/sch_generic.c:219 dev_watchdog+0x272/0x280()
[169782.011281] NETDEV WATCHDOG: eth0 (r8169): transmit timed out
[169782.011283] Modules linked in: vmnet vmci vmmon ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp bridge stp kvm ppdev ipv6 iptable_filter ip_tables x_tables ac lp loop snd_hda_intel parport_pc snd_pcm snd_timer pcspkr snd evdev shpchp iTCO_wdt parport intel_agp button soundcore iTCO_vendor_support pci_hotplug snd_page_alloc ext3 jbd mbcache sr_mod cdrom ata_generic sd_mod crc_t10dif pata_jmicron sg ata_piix pata_acpi pata_it821x via_rhine mii libata r8169 scsi_mod dock ehci_hcd uhci_hcd usbcore raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 multipath linear md_mod dm_mirror dm_log dm_snapshot dm_mod thermal processor fan fbcon tileblit font bitblit softcursor fuse [last unloaded: vmnet]
[169782.011353] Pid: 0, comm: swapper Not tainted 2.6.27-7-server #1
[169782.011355]
[169782.011356] Call Trace:
[169782.011358] <IRQ> [<ffffffff8024e91c>] warn_slowpath+0xbc/0xf0
[169782.011366] [<ffffffff803a23ba>] ? __next_cpu+0x1a/0x30
[169782.011371] [<ffffffff8024535c>] ? find_busiest_group+0x1dc/0x970
[169782.011375] [<ffffffff80219d26>] ? read_tsc+0x16/0x40
[169782.011380] [<ffffffff80273f44>] ? timer_stats_update_stats+0x24/0x370
[169782.011383...

Confirmed: Intrepid Ibex server on ASUS M2N - CM DVI, 2 NIC's (on-board NVIDIA MCP67 and PCI Sundance IP+ IP1000, both 1000-base-T)

 On this board I have (ASUS M2N - CM DVI) there was no way I could make it work as a DHCP-client on 1000-base-T (100-base-T worked well)

The option pci=nomsi did the trick...it works flawlessly....
Patrick Schueller, thank you very much for the invaluable tip.

No problems here any more with kernel 2.6.29 (using sidux or Debian testing with 2.6.29 kernel from sid). No kernel parameters needed any more for booting correctly, everything works, even 2 cores (which didn't work before). Several problems with the ASUS motherboard have vanished with this kernel. So the problems seem to have been corrected upstream. As far as I am concerned, the bug may be closed. Any comments?

Patrick

I use a home-compiled r8169 module now, and everything works perfectly (on debian testing, kernel 2.6.26). So for me too the bug doesn't apply anymore... Probably an unlucky combination of kernel and module versions. At least, I can confirm that the r8169 module does work with the 8168 card.

Yes Patrick,

it looks like it can be closed: no more problems here as well, starting with 2.6.29. Everything is working right out of the box. Thank you!

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.