RTL8111/8168B does not work in Hardy

Bug #221499 reported by Jan Frybort on 2008-04-24
This bug affects 8 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Nominated for Hardy by Kjell Braden

Bug Description

Ubuntu Hardy final release. My NIC RTL8111/8168B does not receive an IP address. After starting the computer, icon of the NetworkManager is animated. When it stops the wired network is reported as connected but there are all zeros (IP address, gateway, etc.) I booted from Gutsy CD and the NIC worked correctly.

Output from lspci -vvnn from Hardy

01:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 01)
 Subsystem: ASUSTeK Computer Inc. Unknown device [1043:11f5]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR+ <PERR-
 Latency: 0, Cache Line Size: 64 bytes
 Interrupt: pin A routed to IRQ 509
 Region 0: I/O ports at c800 [size=256]
 Region 2: Memory at dcfff000 (64-bit, non-prefetchable) [size=4K]
 Expansion ROM at dcfe0000 [disabled] [size=64K]
 Capabilities: <access denied>

Output from lspci -vvnn from Gutsy

01:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 01)
        Subsystem: ASUSTeK Computer Inc. Unknown device [1043:11f5]
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR+ <PERR-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 18
        Region 0: I/O ports at c800 [size=256]
        Region 2: Memory at dcfff000 (64-bit, non-prefetchable) [size=4K]
        Expansion ROM at dcfe0000 [disabled] [size=64K]
        Capabilities: <access denied>

ifconfig from Hardy

eth0 Link encap:Ethernet HWaddr 00:1b:fc:9d:72:9f
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:63 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

ifconfig from Gutsy

eth0 Link encap:Ethernet HWaddr 00:1B:FC:9D:72:9F
          inet addr: Bcast: Mask:
          inet6 addr: 2001:718:2:21:21b:fcff:fe9d:729f/64 Scope:Global
          inet6 addr: fe80::21b:fcff:fe9d:729f/64 Scope:Link
          RX packets:1267 errors:0 dropped:0 overruns:0 frame:0
          TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:128133 (125.1 KB) TX bytes:6628 (6.4 KB)
          Interrupt:18 Base address:0x8000

1. find the card in lspci
2. notice that ifconfig lists the interface
3. check your connection (eg. sudo dhclient3)
4. notice that you don't receive any packets at all

Regression since 2.6.24-16, still does not work in 2.6.24-19.33.
Works with 2.6.26-2.6. Did not test 2.6.26-1.*

Kjell Braden (afflux) wrote :

Can confirm this on my friend's system. The same chipset, the same symptoms: works in 2.6.22, does not work in 2.6.24. I'm working on gathering the information meantioned in the KernelTeamBugPolicy.

Changed in linux:
status: New → Confirmed
Kjell Braden (afflux) wrote :
Kjell Braden (afflux) wrote :
Kjell Braden (afflux) wrote :
Kjell Braden (afflux) wrote :
Changed in linux:
importance: Undecided → Medium
fauzone (gianluca-smpe) wrote :

In Hardy 8.04 kernel 2.6.24 Same chipset and same symptoms....LAN receives address alone ip some times and to every start of the PC once it works and once no..
with live cd of 7.10 gutsy does not works .. :(((((
Good work to resolve !!

Niclas Andersson (niclasa) wrote :

I can confirm this.

This card worked in Feisty/Gutsy on this computer, but not in Hardy. Seems to be related to the 2.6.24 kernel:
 - When booting using the latest SystemRescueCD, choosing kernel 2.6.24, the card does _not_ work (as in Hardy)
 - When booting using the latest SystemRescueCD, choosing kernel 2.6.19, the card _does_ work.
 - Also, booting my system with the old Gutsy kernel makes the card work.

In Gutsy it was possible to attach the network cable at any time, and NetworkManager would configure the card right away. In Hardy the "Wired Network" option is grayed out unless the network cable is plugged in at boot time. Even if it is attached at boot, it does not work (not able to get an ip address via dhcp, does not work when configured manually etc).

The card also switched from eth1 to eth4 when I upgraded from Gutsy to Hardy.

My two network interfaces are these:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
03:03.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)

Mark (m-a-r-knos) wrote :


I would just like to add I have the same problem. In searching the bug reports I have spotted more then one bug report that could be identical. I have tried with kernels 2.6.24-16 and 2.6.24-17 with no success. The gusty kernel (2.6.22-16) worked but I could not load the Nvidia graphics driver. I am running on a Asus A6T notebook and I have had load of problems with it so I am re-loading Gusty so that I have a working system.



Raptor Ramjet (ramjet) wrote :

I too am unable to use networking with Hardy (kernel version 2-6-24-17) on my machine which features an Asrock AliveDual-eSATA2 motherboard with a Realtek RTL8111B/RTL8111C on board LAN controller.

However this hardware works fine if I boot from either a Feisty CD, a Gutsy CD or a Knoppix 5.1 CD.

After this experimentation I tried installing Gutsy 32bit and this worked o.k. After this I installed Gutsy 64 bit, which again worked o.k., which I followed by doing a distribution upgrade to Hardy. Once again the machine cannot now connect to the network.

Following this I failed to find this post (I was very tired at the time) so raised another bug (#236287) which should get marked as a duplicate of this.

As I have tremendous problems with X under Gutsy I am therefore leaving this machine in it's current knackered state until a patch becomes available (I can always boot from Knoppix when I need to use it to do some work)

Raptor Ramjet (ramjet) wrote :

Just to say that having just managed to install the 2.6.24-18 kernel networking still doesn't work. I've also tried compiling Realteks driver myself but this fails with "shed loads" of compilation errors (function template mismatches plus missing constants)

So I can still only boot this box using the 2.6.22-14 kernel and use it as a file server (X is totally unusable with this earlier kernel) Looks like I'll have to go back to Gutsy and skip Hardy altogether.

Kjell Braden (afflux) on 2008-06-18
Changed in linux:
assignee: nobody → ubuntu-kernel-team
Kjell Braden (afflux) on 2008-06-18
description: updated
Kjell Braden (afflux) wrote :

Marking as high importance as it is "A problem with an essential hardware component"

Changed in linux:
importance: Medium → High
Kjell Braden (afflux) wrote :

2.6.24-19.33 does not work either. Will try to test 2.6.26 as soon as possible.

description: updated
Jan Frybort (jan.frybort) wrote :

I can only add that I tried the recent Fedora 9 and OpenSuSE 11 releases with 2.6.25 kernel and this network card worked correctly.

Kjell Braden (afflux) wrote :

I backported the current 2.6.26-2.6 kernel to hardy and the network card works correctly.

Changed in linux:
status: Confirmed → Fix Released
Kjell Braden (afflux) on 2008-06-23
description: updated
sfikas (sfikas07) wrote :

I can also confirm this problem with tis card at kubuntu hardy. Just see this:

p.s I didn't know that there was a post about this problem, so i made one also

Francesco Pretto (ceztko) wrote :

Confirmed. I may have further information: first, the card works perfectly with Ubuntu 7.10.

The card binds to strange IRQs in 8.04 (where it's completely unfunctional). This is from /proc/interrupts in 8.04:

220: 0 0 PCI-MSI-edge eth0

IRQ 220??? Isn't this STRANGE? Even logs from Kjell Braden shows the same bad IRQ. And something is strange even with that PCI-MSI-edge.

Now, let see /proc/interrups from 7.10. Here the card works perfectly:

 23: 0 659 IO-APIC-fasteoi eth0

This seems more SANE to me.

I'll attach /proc/interrupts output.

Francesco Pretto (ceztko) wrote :

Changed from Fix Released to Confirmed. Backporting 2.6.26 is not an option for an LTS release!

Changed in linux:
status: Fix Released → Confirmed
Kjell Braden (afflux) wrote :

I am closing it because the bug has been fixed in the latest development version of Ubuntu - the Intrepid Ibex.

If you need a fix for the bug in previous versions of Ubuntu, please do steps 1 and 2 of the SRU Procedure [1] to bring the need to a developer's attention.

[1]: https://wiki.ubuntu.com/StableReleaseUpdates

Changed in linux:
status: Confirmed → Fix Released
Mark (m-a-r-knos) wrote :

So let me get this right. The bug is in the Hardy Kernel and the fix is to use a new kernel from an unstable release? May be we should change it from "LTS" to "LTS except RTL8111/8168 users". I am sorry if I sound ironic but I was waiting for Hardy LTS so that I could settle on one version for a year or two and not keep updating.
I appreciate the need for the SRU procedures but when the fix involves the replacement of the broken part (i.e. the kernel) is it really going to happen in LTS.

Francesco Pretto (ceztko) wrote :

Agreed with Mark, as this is clearly a regression. Ubuntu 7.10 worked and Gentoo 2008 (has kernel 2.6.24) works.

Kjell Braden (afflux) wrote :

Mark, feel free to extract a patch which fixes this issue and provide it as a debdiff, or wait until this bug is brought to attention to the developers and they have an idea about how to fix this. The SRU procedure does *not* say that we backport the whole 2.6.26 kernel, but it says that we cherry-pick the fix from the 2.6.26 kernel and apply it to the hardy kernel. In case you know where to find the fix, please let us know.

Raptor Ramjet (ramjet) wrote :

I'm sorry but I have to agree with Mark that this is very poor. For me this bug makes my machine unusable as I either have to take out my PCI audio card so I can network with a PCI card or I can use the audio card but have no networking (not room for both as the audio card has a daughter card).

I wouldn't mind but this box is *supposed* to be an Ubuntu multimedia box so neither solution is satisfactory.

Sadly, coupled with the fact that the latest Xorg simply does not work properly with my monitor, means I think this latest release of Ubuntu has been of poor quality.

I also don't find it acceptable to close a bug which is not going to be fixed. By all means don't fix it but don't close the bug. Setting it to "fix released" is simply being untruthful.

Still I didn't pay for Ubuntu and I don't develop for it so I'm not *really* complaining too much.

Oh well where did I put my XP Pro, Logic Audio and Sound Forge discs ?

Francesco Pretto (ceztko) wrote :

Kjell, you pointed out how to nominated bugs using the SRU procedure and ironically you were the one to nominate this one for Hardy :)
Let's hope for a fix...just to repeat it for the umpteenth time: this is *regression* . Gutsy worked flawlessly, as gentoo 2008.0, with a close kernel (slightly modified 2.6.24), works as well.

sfikas (sfikas07) wrote :

I am in a better situation than the others because i use kubuntu hardy which is not an LTS edition, so i can wait for the kubuntu 8.10. But i have to agree with the ubuntu users and their complaints, because ubuntu suppose to be an LTS edition and for them is completely useless. So this problem remains and isn't solved. It is not a solution to say them that they have to upgrade their ubuntu to 8.10. I hope that the developers will see this bug and really fix it.

Kjell Braden (afflux) wrote :

This is not a forum, but a bugtracker. For discussing please use the ubuntuforums [1] or the mailinglists [2].

To repeat it: "Fix released" means that this issue does not occur in intrepid anymore. "Nominated for hardy" means that this is still a issue in hardy and someone (me included!) wants to see this fixed there. I'm currently investigating the issue (though I'm not a kernel developer).

[1] http://ubuntuforums.org
[2] https://lists.ubuntu.com

For the record: Just using the sourcecode of the r8169 module in 2.6.26
and compiling it with the 2.6.24 kernel did not help.

dariosicily (dariosicily) wrote :

Hi guys, I'm one more admist those who struggle with this bug.... exactly the same problem, and the noly solution seems to be using Vista and just silly "playing" with ubuntu till the enw version comes out.... if you get to an end with it please let me know !!!! I'm so disapopinted.....

Stefan Bader (smb) wrote :

Something to try: pci=nomsi as a boot option

This might be a case where the card/bus claim to be able to use msi but fail to do in reality.

Kjell Braden (afflux) wrote :

pci=nomsi seems to work.

dariosicily (dariosicily) wrote :

Hey guys..... I followed the instructions from http://forum.ubuntu-it.org/index.php/topic,199308.0.html

setting pci=nomsi.

Apparently it's working, I'll keep monitoring....
This should be solved, and sorry for my complaints....

A big thanks anyway !!!!!

Francesco Pretto (ceztko) wrote :

2008/7/28 Stefan Bader <email address hidden>:
> Something to try: pci=nomsi as a boot option
> This might be a case where the card/bus claim to be able to use msi but
> fail to do in reality.

Eventually an help from a dev! (sorry Kjell, but I don't think your
playing with launchpad helped in solving this soon) So I was correct
in observing strangeness with that "PCI-MSI-edge" and that suspicious
IRQ in my logs. Unless ubuntu 7.10 and 8.10 ship with "pci=nomsi" by
default, and I don't think so, there's a regression somewhere, maybe
not in the r8169 module code. Is there any way we, users, can help
with dealing of this regression?

Stefan Bader (smb) wrote :

Using pci=nomsi is not a real solution. As many as there are with problems, there are probably more that have none and would like this enabled. But yes you all can help. As it seems to be certain combinations of hardware that cause problems information needed (and a bit of time to think about a solution). If you could provide "sudo dmidecode", "lspci -t" and "sudo lspci -vvnn" for a start, this would be great. Given enough of them there might be a pattern visible.

Francesco Pretto (ceztko) wrote :

> Using pci=nomsi is not a real solution.

Agreeed. Following are output of the commands you pointed.

Francesco Pretto (ceztko) wrote :
Francesco Pretto (ceztko) wrote :
Francesco Pretto (ceztko) wrote :
Stefan Bader (smb) wrote :

Thank you Francesco. Just to be bullet proof, your network works with the nomsi option but not without.
And just as a bit more information from my side: the high IRQ number is not a problem but just an indication that a device is using MSI instead of "normal" interrupts. Which is not bad. You avoid shared interrupts for one thing. The problem seems to be either the device (or some versions of that) or the board which indicate with their capabilities to support this, have some flaws. Well, you can't rule out drivers but somehow I believe that if code is added with the comment that a certain card has been proved to work, that it worked at least for one instance (call me optimistic). Now I hope that with the help of those that have problems, it is possible to get some sort of pattern on which combinations work and which don't.

sfikas (sfikas07) wrote :
Francesco Pretto (ceztko) wrote :

2008/7/29 Stefan Bader <email address hidden>:
> Thank you Francesco. Just to be bullet proof, your network works with the
> nomsi option but not without.

works with pci=nomsi, don't works without

> The problem seems to be either the device (or some versions of that) or the
> board which indicate with their capabilities to support this, have some flaws.

IMHO, this is a regression since:

- Ubuntu 7.10 works (kernel 2.6.22);
- Gentoo 2008.1 works (kernel 2.6.24);
- Ubuntu 8.10 alpha 3 works (kernel 2.6.26).

Don't know the component which could be broken as I dunno who is
responsible of detecting MSI capable cards.

Raptor Ramjet (ramjet) wrote :

Sorry if this is late but in response to Stefan asking for some diagnostic output here's the output from "sudo
dmidecode", "lspci -t" and "sudo lspci -vvnn" on my machine.

At this point I must also point out that I've temporarily installed a borrowed LAN card (D-Link RTL8139 so I can use my network.

Hope it's of use.

Stefan Bader (smb) wrote :

If that is no coincidence. This seems to be the common setup:

00:13.0 PCI bridge [0604]: ALi Corp. PCI Express Root Port [10b9:524d]
             02:00.0 RTL8111/8168B PCIE Gb Ethernet ctrl. [10ec:8168] (rev 01)
             SUB: ASRock Incorporation Unknown device [1849:8168]

Now the question would be whether it is the card or the bridge... But I fear nobody that has a working setup will read the bug report. :-P

sfikas (sfikas07) wrote :

In response to Stefan, these are the outputs of those 3 commands in kubuntu 8.04 with kernel from gutsy (, where the problem doesn't exist. Hope that this will help...

dariosicily (dariosicily) wrote :

Guys, just to alert that the bug is not solved, even with the pci=nomsi procedure. As a matter of fact, I've been playing a bit with emerald, now everything works fine but my internet connection.... I'm writing thru Vista now, after 4 or 5 attempts to get connected by Ubuntu.... The gedit still gives me the pci=nomsi, but again..... Thanks !! Please help me.

Stefan Bader (smb) wrote :

That is not much to work with. Please gather the output of these comands:
lspci -t
sudo lspci -vvnn
sudo dmidecode

Put them somewhere you can access with network and post them here.

dariosicily (dariosicily) wrote :

Ok, sorry :

dario@dario-desktop:~$ lspci -t

the rest is a lot, here attached.
Thanks in advance !!!

dariosicily (dariosicily) wrote :

and the dmidecode one, don't know how to do it in one shot....

dariosicily (dariosicily) wrote :

just to comunicate that I apparently solved the issue, installing module r8168 replacing r8169.
I followed a guide to download relevant module, unfolded it in my home directory, and gave codes :

cd /home/dario/r8168-8.008.00
make clean modules
make install
depmod -a
insmod ./src/r8168.ko

then removed r8169, and updated the blacklist and boot options.


cipher_neo (lee-farrell6) wrote :

Hey guys, just to follow up.

Has there been a fix for this bug yet?

Im having the same problem here. What has everybody done as a temporary resolve?

dariosicily (dariosicily) wrote :


I did solve the problem follpwing the procedure you can read right above, the original guide is in italian but if you need I can post something more accurate in english.
It's been a while now I don't suffer the bug anymore.


Carsten Agger (agger) wrote :

I'm having this problem and I just tried the pci=nomsi fix, but unfortunately it doesn't work :-(

My wired network worked until two days ago and then it suddenly stopped working with this exact problem. Has an update been sent out which might introduce this problem? And is a fix forthcoming in Hardy?


UeB (moritz-nadler) wrote :

I am having this problem on BOTH freshly installed Ubuntu 8.04.1 AND a freshly installed Ubuntu 8.10 Alpha 5. (both installed form the corresponding normal 32 bit live CD). So from my point of view this bug is NOT fixed.

It even seems to get stranger on the Alpha 5 instead better.
I bought a new HP Pavilion dv7-1001eg 2 days ago and a fighting with this bug since then.

What the 8.10 Alpha 5 tells me is very strange:

lspic looks good:
0a:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
also lshw:
                description: Ethernet interface
                product: RTL8111/8168B PCI Express Gigabit Ethernet controller
                vendor: Realtek Semiconductor Co., Ltd.
                physical id: 0
                bus info: pci@0000:0a:00.0
                logical name: eth0
                version: 02
                serial: 00:1e:ec:a4:b0:f3
                capacity: 1GB/s
                width: 64 bits
                clock: 33MHz
                capabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
                configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=half latency=0 link=no module=r8169 multicast=yes port=twisted pair

ifconfig says eth0 is up:

eth0 Link encap:Ethernet Hardware Adresse 00:1e:ec:a4:b0:f3
          UP BROADCAST MULTICAST MTU:1500 Metrik:1
          RX packets:0 errors:0 dropped:251142602 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

but I cannot ping anything.

now if I try this I get a strange answer
moritz@skynet:~/Desktop$ sudo ifup eth0
Ignoring unknown interface eth0=eth0.

moritz@skynet:~/Desktop$ dmesg /var/log | grep 816
[ 0.936816] pci 0000:00:07.0: PREFETCH window: 0x000000d1000000-0x000000d10fffff
[ 3.506633] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 3.506656] r8169 0000:0a:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[ 3.506694] r8169 0000:0a:00.0: setting latency timer to 64
[ 3.507036] eth0: RTL8168c/8111c at 0xf89d0000, 00:1e:ec:a4:b0:f3, XID 3c4000c0 IRQ 218
[ 14.604816] [<c0291d6d>] acpi_device_probe+0x47/0x89
[ 31.888741] r8169: eth0: link down

is interesting there are 2 different names for the wired lan device: r8168C and r8169 both differ from the names that lspci and lshw tell which is r8168B.

another thing:
moritz@skynet:~/Desktop$ lsmod | grep r816
r8169 35972 0

Now what piece of hardware do I really have?
why is ifconfig telling the eth0 is up when says /var/log link down?
why does ifup not know eth0?

Another point:
also seems to be a dublicate of this bug. Can someone check this?

UeB (moritz-nadler) wrote :

Problem solved with this guide:
(this is the same solution that was proposed by dariosicily on this site)

The Problem is a r8168 ethernet device is correctly found but the r8169 driver gets loaded, a driver that cannot handle the r8168 chip.

The solution is to download an install the linux driver from realtek for the r8168 chip and blacklist the r8169 driver that does not get loaded again.
Location of realtek driver:

From my point of somebody involved in the kernel developement made this mistake by loading the r8169 driver for the r8168 ethernet interface. Either by accident or by (wrongly) thinking the r8169 driver can handle the r8168 ethernet interface.

As I said in the post above the same error is present in ubuntu 8.04 AND 8.10, although a working GPL driver in available from Realtek (the one I have linked to).

It is interesting to mention that in the readme of the Realtek driver r8168 one can read:

<Quick install with proper kernel settings>
 Check whether the built-in driver, r8169.ko (or r8169.o for kernel 2.4.x), is installed.
  # lsmod | grep r8169

 If it is installed, please remove it.
  # rmmod r8169

...(more instuctions)

So the people at Realtek seem to know that lots of linux users have problems because the wrong driver gets installed by default.

matli (ml-launchpad) wrote :

I don't agree that it is an acceptable solution to have to download and compile your own driver, which I suppose will have to be redone for every kernel update that is released.

The r8169 driver should normally be able to handle the r8168 interface, which it does fine in Gutsy.

Igor Lopez (igor-lopez) wrote :

I can confirm this bug on my HP Pavilion DV7-1120EO.

The hard fix described in:
is not acceptable. How do I follow that procedure without a working network?
In order to compile I need to apt-get linux-headers (or whatever) but this is impossible.

This fault is both in 8.04 and 8.10 both for i386 and AMD64.
Fedora 10 works however.

Igor Lopez (igor-lopez) wrote :

I went back and tested Fedora 10 and it was only wifi that worked so they have the same problem.

The solution I found here is to set kernel parameter: pci=nomsi
which makes the network to function.

Francesco Pretto (ceztko) wrote :

After all, this may be a motherboard bios configuration issue. I own a Asrock ALiveDual-eSATA2 [1] : with the last bios update (version 1.40, changelog "Modify code for PCI function." [2]), it seems the issue disappeared with ubuntu 8.10. This won't explain why the device worked with different distributions and kernel versions, but I hope it can help someone.

[1] http://www.asrock.com/mb/overview.asp?Model=ALiveDual-eSATA2&s=n
[2] http://www.asrock.com/mb/download.asp?Model=ALiveDual-eSATA2

sfikas (sfikas07) wrote :

I also own the Asrock ALiveDual-eSATA2 and i haven't problems with kubuntu 8.10, but i had with kubuntu 8.04

Francesco Pretto (ceztko) wrote :

2008/12/18 sfikas <email address hidden>:
> I also own the Asrock ALiveDual-eSATA2 and i haven't problems with
> kubuntu 8.10, but i had with kubuntu 8.04

Nice to hear: I had problems with ubuntu 8.04 me too. I should test it
with the newer bios, to see if this fixed the problem or something
changed in ubuntu between 8.04 -> 8.10. Will do it later.

Francesco Pretto (ceztko) wrote :

2008/12/18 Francesco Pretto <email address hidden>:
> I had problems with ubuntu 8.04 me too. I should test it
> with the newer bios, to see if this fixed the problem or something
> changed in ubuntu between 8.04 -> 8.10. Will do it later.

Nope, the newer bios didn't fixed the ethernet in ubuntu 8.04.1
livecd: my supposition was wrong! At least, I can confirm this bug is
fixed for Asrock ALiveDual-eSATA2 users with ubuntu 8.10.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

UeB (moritz-nadler) wrote :

As I wrote in here I had this Bug in Ubuntu 8.04 and 8.10 ALPHA. Since I installed the official 8.10 release the bug disappeared for me. After I installed 8.10 from CD my realtek wired lan adapter works "out of box".

John Ward (automail) wrote :

I find it hard to believe this still isn't fixed. After a slightly up and down time with Karmic I came back to installing Hardy thinking the stability will be a big plus.

To begin with it couldn't detect correct monitor resolution but I didn't mind as it wanted to install nVidia drivers, and ethernet doesn't even work. The interesting thing is that it detects all types of network on my machine (I have a Vostro 1520) - wired and wireless (at least lshw shows them as detected). Wireless doesn't work so I was hoping at least I could get the 300MB of updates from ethernet, in the hope that those other problems would be rectified by that.

Are we giving up on this driver?

John Ward (automail) wrote :

It says fix released:Since I can't get any network connectivity from my laptop is there a deb package available anywhere?

aalhadsaraf (aalhad) on 2010-08-16
Changed in linux (Ubuntu):
status: Fix Released → Incomplete
status: Incomplete → Fix Released
isuftin (isuftin) wrote :

This bug is still occurring in Ubuntu 10.10 pre-release.

 dmesg : http://pastebin.com/2Tz65xT6
 lspci -t : http://pastebin.com/ZN8WuJnU
 lspci -vvvnn : http://pastebin.com/zWMm4KCi
 dmidecode : http://pastebin.com/krKserBN

Johan (ignesia) wrote :

r8169 does not work properly on 2.6.32-27-generic #49-Ubuntu SMP x86_64 GNU/Linux

Drops connection constantly.

felixrising (matt-mu) wrote :

The incorrect module is detected and loaded, unfortunately this bug has existed for around 4+ years now.

Currently does not work on Ubuntu 11.04 (GNU/Linux 2.6.38-8-server x86_64)

These are the same bug:

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers