r8169 ethernet MAC address changes in 2.6.32 kernel

Bug #562742 reported by Jane Atkinson on 2010-04-14
86
This bug affects 14 people
Affects Status Importance Assigned to Milestone
Debian
New
Undecided
Unassigned
linux (Fedora)
Won't Fix
Medium
linux (Ubuntu)
High
Tim Gardner
Lucid
High
Tim Gardner

Bug Description

When I boot with the 2.6.32 kernel, the ethernet MAC address is incorrectly read. The first four pairs of characters are rendered as zeros. The system then reports it as eth1 instead of eth0.

The ethernet connection to the router is still made and internet access works, but the router assigns the computer a different IP number. This is a nuisance because I'm running an ntp server and apt-cacher-ng on this computer.

Occasionally, the ethernet adapter doesn't register at all and the light on the ethernet switch blinks slowly on and off, about once per second.

The error persists after rebooting into Hardy or any other version or distro with an earlier kernel than 2.6.32. The only way to eliminate it and reset the MAC address is to power off completely for a minute or so.

The same problem occurs on the Debian testing 2.6.32 kernel. I haven't tested other distros with 2.6.32 kernels.

I don't have this problem with the Karmic kernel.

The driver used is r8169.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: linux-image-2.6.32-20-generic 2.6.32-20.30
Regression: Yes
Reproducible: No
ProcVersionSignature: Ubuntu 2.6.32-20.30-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-20-generic i686
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.21.
Architecture: i386
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: VT82xx [HDA VIA VT82xx], device 0: AD198x Analog [AD198x Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: ja 1498 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'VT82xx'/'HDA VIA VT82xx at 0xcfffc000 irq 17'
   Mixer name : 'Analog Devices AD1986A'
   Components : 'HDA:11d41986,1043818f,00100500'
   Controls : 37
   Simple ctrls : 21
Date: Wed Apr 14 15:00:25 2010
Frequency: Once a day.
HibernationDevice: RESUME=UUID=323c5223-0a1a-4f9f-9428-15182a8c030f
IwConfig:
 lo no wireless extensions.

 eth1 no wireless extensions.
MachineType: System manufacturer System Product Name
ProcCmdLine: root=/dev/sda6 ro
ProcEnviron:
 LANG=en_NZ.utf8
 SHELL=/bin/bash
RelatedPackageVersions: linux-firmware 1.33
RfKill:

SourcePackage: linux
dmi.bios.date: 03/25/2008
dmi.bios.vendor: Phoenix Technologies, LTD
dmi.bios.version: ASUS P5VD2-VM ACPI BIOS Revision 1302
dmi.board.name: P5VD2-VM
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: 1.XX
dmi.chassis.asset.tag: 123456789000
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: 1111
dmi.modalias: dmi:bvnPhoenixTechnologies,LTD:bvrASUSP5VD2-VMACPIBIOSRevision1302:bd03/25/2008:svnSystemmanufacturer:pnSystemProductName:pvr:rvnASUSTeKComputerINC.:rnP5VD2-VM:rvr1.XX:cvnChassisManufacture:ct3:cvr1111:
dmi.product.name: System Product Name
dmi.sys.vendor: System manufacturer

Description of problem:
When I soft-reboot my fedora host the mac addresses change. This machine is:
Jetway J7F2 Fanless 1.2GHz Eden C7 Mini-ITX Motherboard &
Jetway 3xGigaLAN Daughterboard Module

When cold booted, host mac addresses:
eth0 00:30:18:AC:C8:D5
eth1 00:30:18:AC:C8:D6
eth2 00:30:18:AC:C8:D7
eth3 00:30:18:A6:11:E0
(the labels are as discovered on first install)

When soft-rebooted, mac addresses are:
00:00:00:00:C8:D5
00:00:00:00:C8:D6
00:00:00:00:C8:D7
00:30:18:A6:11:E0

OS history - started life as an FC10 last april, has since been upgraded to FC11, then FC12.
First noticed with kernel-2.6.32.9-70 (2010-03-10), but also exhibited it with kernel-2.6.32.9-67 once noticed.

I first thought it was bug 557771, but I now think the NICs are not resetting/initialised/queried properly following a soft reboot.

udev (145-15) went a bit mad and adds pertitent rules to 70-persistent-net.rules which match the mac addresses seen, but using these the driver seems ineffective, it can't see link state changes and tcpdump can't see a thing.

lspci, dmesg, udevinfo attached (cold and soft booted)

Version-Release number of selected component (if applicable):
Pertinent package history:
Jan 15 19:45:53 Updated: kernel-firmware-2.6.27.41-170.2.117.fc10.noarch
Jan 15 19:47:48 Installed: kernel-2.6.27.41-170.2.117.fc10.i686
Jan 15 19:47:57 Installed: kernel-2.6.27.41-170.2.117.fc10.i686
Feb 26 22:04:41 Erased: libudev0
Feb 26 22:48:05 Updated: kernel-firmware-2.6.30.10-105.2.23.fc11.noarch
Feb 26 22:50:10 Installed: libudev0-141-8.fc11.i586
Feb 26 22:54:58 Installed: udev-extras-20090226-0.5.20090302git.fc11.i586
Feb 26 22:55:37 Updated: udev-141-8.fc11.i586
Feb 26 23:00:05 Installed: kernel-2.6.30.10-105.2.23.fc11.i586
Feb 26 23:13:08 Installed: kernel-2.6.30.10-105.2.23.fc11.i586
Mar 03 20:24:47 Updated: kernel-firmware-2.6.31.12-174.2.22.fc12.noarch
Mar 03 20:26:10 Installed: libudev-145-15.fc12.i686
Mar 03 20:30:02 Installed: libgudev1-145-15.fc12.i686
Mar 03 20:33:39 Installed: udev-145-15.fc12.i686
Mar 03 20:46:43 Erased: libudev0
Mar 03 20:48:01 Erased: udev-extras
Mar 03 20:59:36 Installed: kernel-2.6.31.12-174.2.22.fc12.i686
Mar 06 09:08:15 Updated: kernel-firmware-2.6.32.9-67.fc12.noarch
Mar 06 09:12:28 Installed: kernel-2.6.32.9-67.fc12.i686
Mar 10 19:37:10 Updated: kernel-firmware-2.6.32.9-70.fc12.noarch
Mar 10 19:39:36 Installed: kernel-2.6.32.9-70.fc12.i686

How reproducible:
On demand.

Steps to Reproduce:
1.Reboot host - fails to recognise or initialise network devices.
2.
3.

Actual results:
NICs are discovered, but renumbered and not working.

Expected results:
No change.

Additional info:

Created attachment 399829
dmesg of machine in fault condition

Created attachment 399830
lspci -vvnn of machine in fault condition

Created attachment 399832
eth3 udevinfo in fault condition

Created attachment 399833
eth4 udevinfo in fault condition

Created attachment 399834
eth5 udevinfo in fault condition

Created attachment 399835
eth6 udevinfo in fault condition

Created attachment 399836
dmesg of machine after cold boot

Created attachment 399837
lspci -vvnn of machine after cold boot

Created attachment 399838
eth0 udevinfo of machine after cold boot

Created attachment 399839
eth1 udevinfo of machine after cold boot

Created attachment 399840
eth2 udevinfo of machine after cold boot

Created attachment 399841
eth3 udevinfo of machine after cold boot

So the low 4 bytes of the MAC address get zero'd on warm reboot for some
reason.
2.6.32 writes the MAC address to the card on shutdown. It calls rtl_rar_set()
which does:
...
        RTL_W32(MAC0, low);
        RTL_W32(MAC4, high);
...

And the card loses the 'low' part. Wild guess - perhaps the card wants to have
the high half written first.

Anyway, the writing of the MAC address on shutdown was introduced by the
commit:

commit cc098dc705895f6b0109b7e8e026ac2b8ae1c0a1
Author: Ivan Vecera
Date: Sun Nov 29 23:12:52 2009 -0800

    r8169: restore mac addr in rtl8169_remove_one and rtl_shutdown

Gavin, could you test if reverting the commit would fix your problem?

Putting Ivan to CC... Ivan, any ideas?

Sure, which kernel do you need me to test ?

I suggest you download the latest stable vanilla kernel, build it from source, and see if the bug is still reproducible with it. Then we can add some test patches to it.

But before you do that, let's try a couple of easy experiments first with your current Fedora kernel:
 1. What happens when you remove the module (rmmod r8169) and then load it back (modprobe r8169)? Does the MAC address get corrupted in this case also?
 2. What if you rmmod the module and then reboot? Is the MAC address read correctly then?

And just in case - you are not using kexec to reboot quickly, are you?

1. If I unload the driver and reload it, it comes back with the invalid mac address (either after a bring in a working state, or soft booted with the invalid MACs prior to unloading the driver)

2. If I unload the driver and reboot, it comes back with the invalid mac addresses.

Going to try and compile and build this: http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.34-rc2.tar.bz2

Assuming you will manage to reproduce the problem with 2.6.34-rc2 ...

I'm going to attach two short patches for r8169 against 2.6.34-rc2 and I would like to know if any one of them helps. Do not try to apply both of them at the same time, they are mutually exclusive.

Created attachment 401815
write the high half of the MAC address first

With this patch I expect one of the following results after a cold start+rmmod+modprobe cycle:
1. The MAC address will appear correct.
2. The MAC address will be invalid, but in a different way than before. Perhaps the first 4 bytes will be good and the other 2 bytes will be zeros.
3. The MAC address will be invalid in the same way as before.

Created attachment 401816
flush after each write

This is the other patch that might help.

Urgh - I'm rusty. Can't get what I've built to boot yet and I'm not getting much time to look at it. Will persevere (the reason I use FC12 is so I don't need to build kernels by hand any more)

Great, so it seems my original "wild guess" was correct.
Ivan, do you know if the patch is considered for -stable ?

AFAIK not yet but IMHO it should be

(In reply to comment #23)
> AFAIK not yet but IMHO it should be

I have the exact same bug with RedHat 5.5 (Tikanga)
and the latest kernel, eg: 2.6.18-194.el5

Xtian.

For RHEL the new bugzilla report should be opened. Christian, could you do it?

Jane Atkinson (irihapeti) wrote :
Thomas Jarosch (thomas-jarosch) wrote :

Though I don't use Ubuntu, I've been hit by the same issue. Luckily the redhat bug report (https://bugzilla.redhat.com/show_bug.cgi?id=573201) contains a link to the kernel fix.

Kernel fix is here:
http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commitdiff;h=78f1cd02457252e1ffbc6caa44a17424a45286b8

The fix is not in -stable yet.

Jane Atkinson (irihapeti) wrote :

@Thomas
I know that Debian is also affected. Somewhere (I don't recall exactly) I saw a similar message, to the effect that a fix had been committed upstream. No indication was given as to when it would make it to the repositories.

@anyone
Maybe there won't be a fix in time for the Lucid release. If that's the case, is there a workaround? (Apart from compiling one's own kernel, that is)

Jane Atkinson (irihapeti) wrote :

I've tested the fully-updated install with the latest mainline kernel, 2.6.34-020634rc5-i386 (should have thought of this sooner).

The problem shows no signs of occurring while using this kernel, even after several reboots.

tags: added: cherry-pick
Changed in linux (Ubuntu):
status: New → Triaged
importance: Undecided → High
Changed in linux (Ubuntu Lucid):
milestone: none → lucid-updates
Jane Atkinson (irihapeti) wrote :

After behaving well for a couple of days or so, the mainline kernel has been throwing errors on this over the last several hours, particularly not activating the ethernet chip at all (lights on switch blink slowly). I had noticed that my working ethernet connection was labelled "eth1" instead of "eth0". I altered that in /etc/udev/rules.d/70-persistent-net.rules, removed dhcp3 leases and rebooted. That's when the problem started.

Whether that's what caused it, or whether that was a coincidence and a buggy update was the culprit, I have no idea. I'll do a reinstall later today and see what the result is.

Changed in linux (Ubuntu Lucid):
assignee: nobody → Canonical Kernel Team (canonical-kernel-team)
Tim Gardner (timg-tpi) on 2010-04-29
Changed in linux (Ubuntu Lucid):
assignee: Canonical Kernel Team (canonical-kernel-team) → Tim Gardner (timg-tpi)
status: Triaged → In Progress
Tim Gardner (timg-tpi) wrote :

Irihapeti - please try linux_2.6.32-22.33~lp562742 in my PPA at http://launchpad.net/~timg-tpi/+archive/ppa

Jane Atkinson (irihapeti) wrote :

@Tim:

Sorry, the machine is still exhibiting the same behaviour with your kernel.

First boot: OK
Subsequent reboots, whether into the same kernel or another one, setting the MAC address to 00:00:00:00:BD:D1
Reset by complete power off (at the wall or the back of the PC case).

Incidentally, I installed the mainline kernel 2.6.34-rc5 and it handles the MAC address correctly again. I've had plenty of opportunity to test this with all the live CD/install testing of the last 48 hours or so.

Tim Gardner (timg-tpi) wrote :

Irihapeti - try linux_2.6.32-22.33.lp562742.2 at the same PPA. This kernel contains what is essentially the r8169.c from 2.6.34-rc5. If it still doesn't work reliably, then there must be something external to the driver causing your problems.

Jane Atkinson (irihapeti) wrote :

@TIm
The package is labelled "building" and isn't available. I'll get it as soon as I can.
Should I also be using the updated firmware from your ppa, or not?

Gard Spreemann (gspreemann) wrote :

Unless I've misunderstood this bug report, for example if it only applies to very specific hardware, I'm not affected by this. My hardware is
  04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02),
which uses the r8169 driver. I have upgraded to Lucid, and my MAC address has stayed the same (in particular, it's non-zero for several of the first four pairs) after many reboots. I'm using kernel 2.6.32-21-generic.

I also have the exact same problem using a RTL8169sc/8110sc on an Asus A7V-333X mainboard and first noticed this with 2.6.32.11-99.fc12.i686.PAE. I tried updating with updates-testing enabled which resulted in 2.6.32.12-114.fc12.i686.PAE being installed, but I see no improvement. I haven't reviewed the changelog to see if that should be expected or not.

Jane Atkinson (irihapeti) wrote :

@Tim
The new kernel has failed to build, according to Launchpad. I'll check back later and install it when it's ready.

madbiologist (me-again) wrote :

Kernel 2.6.34-rc6 contains some additional fixes similar to those referenced above.

From the changelog:

commit 908ba2bfd22253f26fa910cd855e4ccffb1467d0
Author: françois romieu
Date: Mon Apr 26 11:42:58 2010 +0000

    r8169: more broken register writes workaround

    78f1cd02457252e1ffbc6caa44a17424a45286b8 ("fix broken register writes")
    does not work for Al Viro's r8169 (XID 18000000).

    Signed-off-by: Francois Romieu
    Signed-off-by: David S. Miller

Mark T. Voelker (mvoelker) wrote :

I can say that this hardware *is* affected (this is from a Jetway J7F4K1G2E-PB motherboard with integrated Realtek NICs):

00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)

Brendon Colby (brendoncolby) wrote :

Confirming same behavior on Jetway J7F4K1G5S-LF motherboard with integrated Realtek NICs:

00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)

I just upgraded from Hardy. The first few reboots were fine, then udev renamed my interfaces because for some reason the MAC addresses were changed:

HWaddr 00:00:00:00:29:85
HWaddr 00:00:00:00:29:86

Brendon Colby (brendoncolby) wrote :

As suggested in the Debian bug report (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573007), I am doing this as a workaround:

In /etc/udev/rules.d/70-persistent-net.rules, map the broken MAC addresses to eth0 and eth1.

So far this works between reboots, although when I tested the previous Lucid alpha, it would rename my interfaces constantly between reboots. Fortunately, this is my network router so I don't reboot that often.

I finally read the instructions :)

Have built and have booting a 2.6.34-rc6 kernel which is still exhibiting the problem.

The line numbers have changed - trying to apply the patches above are failing:

# cat patch.401815 | patch -p1
patching file drivers/net/r8169.c
Hunk #1 FAILED at 2821.
1 out of 1 hunk FAILED -- saving rejects to file drivers/net/r8169.c.rej

Can you re-issue the same patches (and how I should apply them properly) for 2.6.34-rc6 ?

Dmesg information for the cards with this kernel soft booted:
kernel: r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
kernel: r8169 0000:00:09.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
kernel: r8169 0000:00:09.0: (unregistered net_device): no PCI Express capability
kernel: r8169 0000:00:09.0: eth0: RTL8169sc/8110sc at 0xf805e000, 00:00:00:00:c8:d5, XID 18000000 IRQ 18
kernel: r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
kernel: r8169 0000:00:0b.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
kernel: r8169 0000:00:0b.0: (unregistered net_device): no PCI Express capability
kernel: r8169 0000:00:0b.0: eth1: RTL8169sc/8110sc at 0xf80ac000, 00:00:00:00:c8:d6, XID 18000000 IRQ 19
kernel: r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
kernel: r8169 0000:00:0c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
kernel: r8169 0000:00:0c.0: (unregistered net_device): no PCI Express capability
kernel: r8169 0000:00:0c.0: eth2: RTL8169sc/8110sc at 0xf8110000, 00:00:00:00:c8:d7, XID 18000000 IRQ 16
kernel: via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
kernel: via-rhine: Broken BIOS detected, avoid_D3 enabled.
kernel: via-rhine 0000:00:12.0: PCI INT A -> Link[ALKD] -> GSI 23 (level, low) -> IRQ 23
kernel: eth3: VIA Rhine II at 0xfdffa000, 00:30:18:a6:11:e0, IRQ 23.
kernel: eth3: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000.
kernel: udev: renamed network interface eth0 to eth6
kernel: udev: renamed network interface eth1 to eth5
kernel: udev: renamed network interface eth2 to eth4

ok, so I made the same edits as per http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commitdiff;h=78f1cd02457252e1ffbc6caa44a17424a45286b8

(Because I couldn't work out how to generate a patch myself)

This has fixed the problem.

-Cold boot into 2.6.34-rc6. Devices report predicted mac addresses (and work)
-Soft reboot into 2.6.34-rc6. Devices report predicted mac addresses (and work)

dmesg of discovery:
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:00:09.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
r8169 0000:00:09.0: (unregistered net_device): no PCI Express capability
r8169 0000:00:09.0: eth1: RTL8169sc/8110sc at 0xf810e000, 00:30:18:ac:c8:d5, XID 18000000 IRQ 18
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:00:0b.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
r8169 0000:00:0b.0: (unregistered net_device): no PCI Express capability
r8169 0000:00:0b.0: eth2: RTL8169sc/8110sc at 0xf8112000, 00:30:18:ac:c8:d6, XID 18000000 IRQ 19
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:00:0c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
r8169 0000:00:0c.0: (unregistered net_device): no PCI Express capability
r8169 0000:00:0c.0: eth3: RTL8169sc/8110sc at 0xf8116000, 00:30:18:ac:c8:d7, XID 18000000 IRQ 16
r8169 0000:00:09.0: eth0: link up
r8169 0000:00:09.0: eth0: link up
r8169 0000:00:0b.0: eth1: link up
r8169 0000:00:0b.0: eth1: link up
r8169 0000:00:0c.0: eth2: link up

This appears to have fixed it - what other tests should I do ?

Jane Atkinson (irihapeti) wrote :

@Tim:
I've installed the kernel linux-image-2.6.32-22-generic_2.6.32-22.33.lp562742.3_i386 and rebooted several times.

So far, it's behaving fine, but I'd like to test it for a couple of days before making a definite statement.

Jane Atkinson (irihapeti) wrote :

PS: That is without using the firmware from the PPA; just the standard Ubuntu version.

Tim Gardner (timg-tpi) wrote :

Irihapeti - Thanks for your feedback. The r8169 driver does not use firmware, so no worries there.

Jane Atkinson (irihapeti) wrote :

After further testing, I finally encountered an error: the ethernet chip not being activated at all (slow blink on ethernet switch, no connection).

However, to my surprise, I was able to fix it by issuing the commands:

sudo rmmod r8169
sudo modprobe r8169

No turning off at the wall, or even rebooting needed. (The first command may not have been necessary.)

It's kept the correct MAC address throughout.

I wonder if this is connected with booting between other distros. I've had it happen occasionally in the past when I was playing with Puppy linux and running Hardy as my main OS.

Mark T. Voelker (mvoelker) wrote :

Still seeing this in 2.6.32-22:

mtvoelke@hostname:~$ uname -a
Linux smokies 2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:27:30 UTC 2010 i686 GNU/Linux
mtvoelke@hostname:~$ ifconfig | grep HWaddr
eth3 Link encap:Ethernet HWaddr 00:00:00:00:bc:49
mtvoelke@hostname:~$
mtvoelke@hostname:~$ lspci | grep thernet
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
mtvoelke@hostname:~$

The patch "r8169: fix broken register writes" and one more related patch ("r8169: more broken register writes workaround") are now included in the -stable release 2.6.32.13.

You can download a RPM for F-12 from Koji:
http://koji.fedoraproject.org/koji/buildinfo?buildID=173221

The build has not yet been submitted as a Fedora update, but eventually it (or a later one) will be.

Jane Atkinson (irihapeti) wrote :

I have seen no incorrect ethernet addresses during the past week, and I've been rebooting regularly between various linux versions.

As far as I am concerned, the problem is solved.

I just ran into this on my Asterisk box. (The wife loves it when the
phones stop working!) Seems to be fixed by 2.6.32.13-118.fc12.i686.PAE.

More info available on request.

The patches Tim has submitted to the kernel-team mailing list are already included in the actively developed Maverick kernel. As a result, I'm marking the current linux task as Fix Released. The Lucid task for SRU still remains open and under consideration. Thanks.

Changed in linux (Ubuntu):
milestone: lucid-updates → none
status: In Progress → Fix Released
avdheiden (alain-tomatenplein) wrote :

Same here. I'm running Ubuntu Lucid, 32 bit with 2.6.32-20
Replaced my NIC with a TP-Link Gigabit card based on a r8169 chip.

The card was sometimes not recognized by the kernel driver. I compiled the driver from the realtek site and got the card to work at 100baseTx-FD

I set up the DHCP server for a fixed address but this fails. Random adresses are assigned because apparently the drivers fails to send the correct MAC.

Also, I'm unable to get the card to 1000baseT-HD or 1000baseT-FD which are supported. An ethtool eth0 shows the mode as available. I've tried all the usual stuff like ethtool -s eth0 autoneg off speed..... etc.etc.etc
Did depmod -a and made a new initrd, etc.etc.

I also tried to manipulate the card with mii-tool but got the same result. I'm unable to switch the card in ANY mode. Not even to 10base-T, no autoneg or another duplexing mode.

The Switch is from the same brand and works fine with other 1000baseT equipment like my laptop and NAS. I've tried Cat5e and Cat6 cables but no results either.

My conclusion is that the driver is locked somehow to 100baseTx-FD

On the internet I read about people getting their r8169 devices to work with r1000 or r8168 drivers but I didn't get good results.

Jane Atkinson (irihapeti) wrote :

I was using Tim Gardner's patched kernel successfully. Of course, there's been a kernel update recently (two of them, actually) and therefore Tim's kernel has been replaced with a standard Ubuntu version - with the error in it.

For the moment, I've gone back to using a mainline kernel: 2.6.35-020635rc1-generic, which doesn't have this error.

However, if the fix isn't going to be released for lucid any time soon, how would be go about compiling either a whole kernel (gulp!) or just the r8169 driver so that we can get the functionality in the standard Ubuntu kernel?

avdheiden (alain-tomatenplein) wrote :

@Irihapeti # 24

That's exacly what I did. The kernel r8169 driver seldomly worked *at all* so I compiled the driver from source. I had to donwload the latest sources from realtek because the source code included with the card didn't compile on lucid.

I got the card to work, but only at speed 100.

I should have just bought the more expensive Intel card.. stupid...stupid...

Tim Gardner (timg-tpi) wrote :

Can y'all try the pre-proposed kernel 2.6.32-23.37~pre201006081000 at http://ppa.launchpad.net/kernel-ppa/pre-proposed/ubuntu ? It has the stable updates required to fix this bug.

Stefan Bader (smb) wrote :

This bugfix is part of the upstream stable update for Lucid to 2.6.32.13 (see Bug #583414).

Changed in linux (Ubuntu Lucid):
status: In Progress → Fix Committed
Jane Atkinson (irihapeti) wrote :

@Tim Gardner:
The pre-proposed kernel is working correctly.

avdheiden (alain-tomatenplein) wrote :

@Tim. I could download the package after adding "deb http://ppa.launchpad.net/kernel-ppa/pre-proposed/ubuntu lucid main" to my /etc/apt/sources.list but don't know what to do next. I'm a virgin when it comes to compiling a kernel :)

So I can't tell if the fix works or not.

Tim Gardner (timg-tpi) wrote :

avdheiden - run 'sudo apt-get update; sudo apt-get -u dist-upgrade'. That should install the latest kernel from either the archive or the kernel-pre-proposed PPA.

Accepted linux into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

tags: added: verification-needed
avdheiden (alain-tomatenplein) wrote :

@Tim & Martin

Added the kernel from pre-proposed, no results. I added proposed and downloaded the latest kernel, no results. In both cases, I got a card in ifconfig -a but not in network-manager. The r8169 driver appeared in lsmod | grep r81 but no connection at all.

Thanks for your help so far and I hope you have more suggestions. If you need more info about my system, please ask. My card is a TP-Link TG-3269 (realtek r8169 based).

Tim Gardner (timg-tpi) wrote :

avdheiden - I'm thinking you likely have a different bug then Irihapeti since the pre-proposed kernel did solve his problem, and he was the original reporter. I suggest you file a new bug with your relevant information using 'ubuntu-bug linux', though you'll have to do it using a different ethernet interface.

After today's kernel upgrade (2.6.32-23-generic #37) the bug appears to
be fixed. No more weird MAC addresses after reboots! :-)

Many thanks to all the people who worked to fix this bug!

:-)

Frank

Jane Atkinson (irihapeti) wrote :

@Tim Gardner

Thought I'd better set the record straight - I'm not a "he".

No need to apologise. You weren't to know.

Martin Pitt (pitti) on 2010-06-16
tags: added: verification-done
removed: verification-needed
avdheiden (alain-tomatenplein) wrote :

@Tim

I've posted bug 596825, as suggested, to find a solution for my ongoing problem. Thanks for your help and suggestions.

MadFranky (madfranky) wrote :

Update after my message wrote on 2010-06-15

> the ethernet MAC address is incorrectly read.
> The first four pairs of characters are rendered as zeros.

I confirm that this part of the bug seems to be fixed. I never had weird MAC addresses anymore! That's fine!

However...

> Occasionally, the ethernet adapter doesn't register at all and the
> light on the ethernet switch blinks slowly on and off, about once per second.

This still happens occasionally. Rarely, but it happens. The only solution is a "cold restart" of the machine.

Jane Atkinson (irihapeti) wrote :

@MadFranky:

I've found that I can deal with the ethernet not registering (lights blinking) error by issuing the two following commands:

sudo rmmod r8169
sudo modprobe r8169

Launchpad Janitor (janitor) wrote :
Download full text (25.2 KiB)

This bug was fixed in the package linux - 2.6.32-23.37

---------------
linux (2.6.32-23.37) lucid-proposed; urgency=low

  [ Alex Deucher ]

  * SAUCE: drm/radeon/kms/atom: fix dual-link DVI on DCE3.2/4.0
    - LP: #564559

  [ Andy Whitcroft ]

  * [Config] ports -- build in dm-mod to enable LVM boot
    - LP: #560717
  * tools -- fix perf version extraction for multi-part flavours
    - LP: #555130
  * SAUCE: ACPI: EC: Allow multibyte access to EC (v3)
    - LP: #526354
  * [Config] enforce -- ensure dm_mod is built-in for LVM
    - LP: #560717
  * update to ubuntu-debian:7e708d33054c373faf41da23b73e8b48c342d958
    - LP: #570500, #576274

  [ Chase Douglas ]

  * Revert "(pre-stable): input: ALPS - Add signature for HP Pavilion dm3
    laptops"
    - LP: #550625
  * Enable ftrace function profiler
    - LP: #570389
  * enforce CONFIG_TMPFS_POSIX_ACL=y
    - LP: #575940

  [ Leann Ogasawara ]

  * Revert "staging/comdi -- disable"
    - LP: #563436
  * [Config] Enable multicast routing for sparc
    - LP: #416266
  * [Config] Add ahci.ko to virtual sub-flavour
    - LP: #570542

  [ Stefan Bader ]

  * Revert "SAUCE: drm/i915: Disable FBC on 915GM and 945GM"
    - LP: #588832

  [ Tim Gardner ]

  * ubuntu: rtl8192se -- update to version 0015.0127.2010
    - LP: #567016
  * [Config] Add atl1c to nic-modules udeb
    - LP: #557130

  [ Upstream Kernel Changes ]

  * Revert "(pre-stable) iwlwifi: fix nfreed--"
    - LP: #575853
  * Revert "backlight: mbp_nvidia_bl - add five more MacBook variants"
    - LP: #575853
  * Revert "(pre-stable) pata_via: Add VIA VX900 support"
    - LP: #575853
  * Revert "(pre-stable) x86-32, resume: do a global tlb flush in S4
    resume"
    - LP: #575853
  * Revert "x86: disable IOMMUs on kernel crash"
    - LP: #575853
  * Revert "sunrpc: fix peername failed on closed listener"
    - LP: #575853
  * Revert "sunrpc: move the close processing after do recvfrom method"
    - LP: #575853
  * Revert "(pre-stable) drm/edid: allow certain bogus edids to hit a fixup
    path rather than fail"
    - LP: #575853
  * Revert "drm/radeon/kms: don't print error on -ERESTARTSYS."
    - LP: #575853
  * Revert "ath9k: fix lockdep warning when unloading module" on stable
    kernels
    - LP: #588832
  * Staging: comedi: removed "depricated" from COMEDI_CB_BLOCK
    - LP: #483343
  * fat: fix buffer overflow in vfat_create_shortname()
    - LP: #575853
  * xfs: simplify inode teardown
    - LP: #575853
  * xfs: fix mmap_sem/iolock inversion in xfs_free_eofblocks
    - LP: #575853
  * xfs: I/O completion handlers must use NOFS allocations
    - LP: #575853
  * xfs: Wrapped journal record corruption on read at recovery
    - LP: #575853
  * xfs: Fix error return for fallocate() on XFS
    - LP: #575853
  * xfs: check for not fully initialized inodes in xfs_ireclaim
    - LP: #575853
  * xfs: fix timestamp handling in xfs_setattr
    - LP: #575853
  * xfs: Don't flush stale inodes
    - LP: #575853
  * xfs: Ensure we force all busy extents in range to disk
    - LP: #575853
  * xfs: reclaim inodes under a write lock
    - LP: #575853
  * xfs: Avoid inodes in reclaim when flushing from inode cache
    - LP: #575853
  * xfs: recla...

Changed in linux (Ubuntu Lucid):
status: Fix Committed → Fix Released
MadFranky (madfranky) wrote :

Today I had another "blinking lights" error.

On Fri, 2010-06-25 at 21:38 +0000, Irihapeti wrote:

> I've found that I can deal with the ethernet not registering (lights
> blinking) error by issuing the two following commands:
>
> sudo rmmod r8169
> sudo modprobe r8169

That has helped, indeed! Thanks for your help! :-)

Frank

sven (post-svennielsen) wrote :
Download full text (7.4 KiB)

I have the same behaviour since upgrade to Lucid, and this bug is not fixed for me with current kernel 2.6.32-24-generic. Still getting broken MAC address after reboot.

# lspci -v

00:00.0 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
 Subsystem: VIA Technologies, Inc. K8T800Pro Host Bridge
 Flags: bus master, 66MHz, medium devsel, latency 8
 Memory at <ignored> (32-bit, prefetchable)
 Capabilities: [80] AGP version 3.0
 Capabilities: [50] Power Management version 2
 Capabilities: [60] HyperTransport: Slave or Primary Interface
 Capabilities: [58] HyperTransport: Interrupt Discovery and Configuration
 Kernel driver in use: agpgart-amd64

00:00.1 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
 Flags: bus master, medium devsel, latency 0

00:00.2 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
 Flags: bus master, medium devsel, latency 0

00:00.3 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
 Flags: bus master, medium devsel, latency 0

00:00.4 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
 Flags: bus master, medium devsel, latency 0

00:00.7 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
 Flags: bus master, medium devsel, latency 0

00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South]
 Flags: bus master, 66MHz, medium devsel, latency 0
 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
 I/O behind bridge: 0000d000-0000dfff
 Memory behind bridge: f0000000-f00fffff
 Prefetchable memory behind bridge: e0000000-efffffff
 Capabilities: [80] Power Management version 2
 Kernel modules: shpchp

00:0a.0 Multimedia controller: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1)
 Subsystem: Hauppauge computer works Inc. Device 6701
 Flags: bus master, medium devsel, latency 32, IRQ 18
 Memory at f0122000 (32-bit, non-prefetchable) [size=2K]
 Capabilities: [40] Power Management version 2
 Kernel driver in use: saa7134
 Kernel modules: saa7134

00:0b.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)
 Subsystem: Creative Labs Device 8061
 Flags: bus master, medium devsel, latency 32, IRQ 19
 I/O ports at e000 [size=32]
 Capabilities: [dc] Power Management version 1
 Kernel driver in use: EMU10K1_Audigy
 Kernel modules: snd-emu10k1

00:0b.1 Input device controller: Creative Labs SB Live! Game Port (rev 07)
 Subsystem: Creative Labs Device 0020
 Flags: bus master, medium devsel, latency 32
 I/O ports at e100 [size=8]
 Capabilities: [dc] Power Management version 1
 Kernel driver in use: Emu10k1_gameport
 Kernel modules: emu10k1-gp

00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
 Subsystem: Micro-Star International Co., Ltd. Device 094c
 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
 I/O ports at e200 [size=256]
 Memory at f0120000 (32-bit, non-prefetchable) [size=256]
 [virtual] Expansion ROM at 60000000 [disabled] [size=128K]
 Capabilities: [dc] Power Management version 2
 Kernel driver in use: r8169
 Kernel modules: r8169

00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) (prog-if 8f [Master Se...

Read more...

sven (post-svennielsen) wrote :

Looks like a regression in 2.6.32-24-generic. Doing a few reboots with packaged kernel 2.6.32-23-generic MAC address seems to stay intact on my machine, too.

Jane Atkinson (irihapeti) wrote :

I accepted the update to the 2.6.32-24-generic kernel with some trepidation, in the light of the last two messages. However, I've rebooted several times and the correct MAC address has loaded each time. My hardware is a little different from Sven's, though.

04:07.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet [10ec:8167] (rev 10)
 Subsystem: ASUSTeK Computer Inc. Device [1043:820d]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 64 (8000ns min, 16000ns max), Cache Line Size: 32 bytes
 Interrupt: pin A routed to IRQ 20
 Region 0: I/O ports at a800 [size=256]
 Region 1: Memory at dfdff000 (32-bit, non-prefetchable) [size=256]
 [virtual] Expansion ROM at 5c200000 [disabled] [size=128K]
 Capabilities: [dc] Power Management version 2
  Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
  Status: D0 PME-Enable- DSel=0 DScale=0 PME-
 Kernel driver in use: r8169
 Kernel modules: r8169

Broken again. Regression from 2.6.32-23 to 2.6.32-24. Needs fixing...

Paolo Maero (fabrica64) wrote :

Updated to 2.6.32-24-generic-pae: r8169 MAC addresses issue fixed, but DHCP server stopped distributing IP addresses

lsof -i show:
dhcpd3 2504 dhcpd 5u IPv4 6485 0t0 UDP *:bootps

but dhcpd3 is not responding to any request from the clients...

Rebooting to 2.6.32.23-generic-pae everything works fine again...

MadFranky (madfranky) wrote :

On Sun, 2010-07-25 at 02:50 +0000, Kristian Erik Hermansen wrote:

> Broken again. Regression from 2.6.32-23 to 2.6.32-24. Needs fixing...

I can not confirm! I never had any weird MAC addresses anymore!

> Occasionally, the ethernet adapter doesn't register at all

On the other hand, I still occasionally have the annoying "adapter not
registering" problem.

*** Bug 583223 has been marked as a duplicate of this bug. ***

I too am affected by this bug, but on Fedora 13, with kernel:
2.6.33.6-147.fc13.i686.PAE

Is there a way to flag this bug for Fedora 13 as well as 12?

(In reply to comment #32)
> I too am affected by this bug, but on Fedora 13, with kernel:
> 2.6.33.6-147.fc13.i686.PAE
>

All of the r8169 patches that went into 2.6.32.13 also went into 2.6.33.4 at the same time. So why they would fix one kernel and not the other is a mystery.

> Is there a way to flag this bug for Fedora 13 as well as 12?

The only way to do that is to report the bug separately against each release, but you just closed the Fedora 13 bug as a duplicate of this one.

>> Is there a way to flag this bug for Fedora 13 as well as 12?

>> The only way to do that is to report the bug separately against each release,
but you just closed the Fedora 13 bug as a duplicate of this one.

Should I re-open it (or re-create another one)?

> All of the r8169 patches that went into 2.6.32.13 also went into 2.6.33.4 at
the same time. So why they would fix one kernel and not the other is a mystery.

What can we do to make sure that the patches are applied to 2.6.33.*, as well as 2.6.34 and 2.6.35 (and the future new ones)?

Download full text (3.3 KiB)

This problem has re-appeared.

It's not exactly the same, it did it after a cold boot and I had a fight getting it working. Interfaces have unique mac addresses, but one or all of them remained unresponsive after a boot or a down/up.

Uname now: 2.6.32.16-141.fc12.i686
Picked this up in dmesg:
Aug 4 19:35:18 turnstile kernel: ------------[ cut here ]------------
Aug 4 19:35:18 turnstile kernel: WARNING: at net/sched/sch_generic.c:261 dev_watchdog+0xc6/0x158()
Aug 4 19:35:18 turnstile kernel: Hardware name:
Aug 4 19:35:18 turnstile kernel: NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
Aug 4 19:35:18 turnstile kernel: Modules linked in: xt_multiport ipt_LOG act_nat ebt_dnat ebt_snat ebtable_nat ebtables iptable_nat nf_nat_snmp_basic nf_nat_proto_udplite nf_nat_sip nf_nat_irc nf_nat_ftp nf_nat_pptp nf_nat_proto_gre nf_nat_proto_dccp nf_nat_amanda nf_nat_proto_sctp libcrc32c nf_nat_tftp nf_nat_h323 nf_nat nf_conntrack_irc nf_conntrack_ftp nf_conntrack_netbios_ns ts_kmp nf_conntrack_amanda nf_conntrack_proto_udplite nf_conntrack_proto_sctp nf_conntrack_sip nf_conntrack_netlink nfnetlink nf_conntrack_tftp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_sane nf_conntrack_proto_dccp nf_conntrack_h323 nf_conntrack_ipv6 ip6t_LOG ip6table_filter ip6_tables cpufreq_ondemand acpi_cpufreq sit tunnel4 ipv6 dm_multipath uinput i2c_viapro i2c_core via_rhine r8169 mii pata_acpi ata_generic firewire_ohci sata_via firewire_core crc_itu_t [last unloaded: scsi_wait_scan]
Aug 4 19:35:18 turnstile kernel: Pid: 0, comm: swapper Not tainted 2.6.32.16-141.fc12.i686 #1
Aug 4 19:35:18 turnstile kernel: Call Trace:
Aug 4 19:35:18 turnstile kernel: [<c043a779>] warn_slowpath_common+0x6a/0x81
Aug 4 19:35:18 turnstile kernel: [<c071b7e1>] ? dev_watchdog+0xc6/0x158
Aug 4 19:35:18 turnstile kernel: [<c043a7ce>] warn_slowpath_fmt+0x29/0x2c
Aug 4 19:35:18 turnstile kernel: [<c071b7e1>] dev_watchdog+0xc6/0x158
Aug 4 19:35:18 turnstile kernel: [<c04475ae>] ? __mod_timer+0x115/0x120
Aug 4 19:35:18 turnstile kernel: [<c04410f8>] ? local_bh_enable_ip+0xd/0xf
Aug 4 19:35:18 turnstile kernel: [<c0795303>] ? _spin_unlock_bh+0x13/0x15
Aug 4 19:35:18 turnstile kernel: [<f7e423cd>] ? fib6_run_gc+0xb7/0xbe [ipv6]
Aug 4 19:35:18 turnstile kernel: [<c0447277>] run_timer_softirq+0x16d/0x1f0
Aug 4 19:35:18 turnstile kernel: [<c071b71b>] ? dev_watchdog+0x0/0x158
Aug 4 19:35:18 turnstile kernel: [<c0440e72>] __do_softirq+0xb1/0x157
Aug 4 19:35:18 turnstile kernel: [<c0440f4e>] do_softirq+0x36/0x41
Aug 4 19:35:18 turnstile kernel: [<c0441041>] irq_exit+0x2e/0x61
Aug 4 19:35:18 turnstile kernel: [<c0404e3d>] do_IRQ+0x86/0x9a
Aug 4 19:35:18 turnstile kernel: [<c0403c90>] common_interrupt+0x30/0x38
Aug 4 19:35:18 turnstile kernel: [<c0617074>] ? acpi_idle_enter_simple+0x10f/0x142
Aug 4 19:35:18 turnstile kernel: [<c0616da5>] acpi_idle_enter_bm+0xc7/0x287
Aug 4 19:35:18 turnstile kernel: [<c06e785c>] cpuidle_idle_call+0x73/0xcb
Aug 4 19:35:18 turnstile kernel: [<c0402728>] cpu_idle+0x96/0xb2
Aug 4 19:35:18 turnstile kernel: [<c0782a1c>] rest_init+0x58/0x5a
Aug 4 19:35:18 turnstile kernel: [<c09da8dd>] start_kernel+0x33c/0x341
Aug 4 19:35:18 turnstile kern...

Read more...

Alvin (alvind) wrote :

MAC adresses are still wrong in 2.6.32-24 (confirmed on 6 identical machines.)
Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)

Jane Atkinson (irihapeti) wrote :

A possibly relevant piece of information on this issue:-

I installed Windows Vista to a spare drive in order to test some stuff. Among the zillions of Windows updates was one for the ethernet driver. I discovered that the updated Windows driver was causing similar problems - changing the MAC address so that I had to turn the computer off completely before restarting, if I wanted the original address back. Reverting to the earlier driver solved the problem.

If any of you folk having problems are running Windows, it could be something to be aware of.

Jane Atkinson (irihapeti) wrote :

In case it's not quite clear, I'm talking about a dual-boot configuration in the message above.

Alvin (alvind) wrote :

Is this bug still under investigation? MAC addresses on kernel 2.6.32-24-generic are wrong, even after cleaning /etc/udev/rules.d/70-persistent-net.rules

MadFranky (madfranky) wrote :

On Mon, 2010-09-06 at 09:59 +0000, Alvin wrote:

> Is this bug still under investigation? MAC addresses on kernel
> 2.6.32-24-generic are wrong,

I never again had any weird MAC address.

However...

> Occasionally, the ethernet adapter doesn't register at all and the
> light on the ethernet switch blinks slowly on and off, about once per
second.

This still happens occasionally. The only solution is a "cold restart"
of the machine. And that's quite annoying. :-(

Jane Atkinson (irihapeti) wrote :

@ MadFranky

Try the commands:

sudo rmmod r8169 && sudo modprobe r8169

Works for me, and is a lot less inconvenient than a cold restart.

MadFranky (madfranky) wrote :

Hi Irihapeti

On Sun, 2010-09-12 at 16:06 +0000, Irihapeti wrote:

> Try the commands:
>
> sudo rmmod r8169 && sudo modprobe r8169

Thanks for the suggestion. I tried the commands, but...

> Works for me, and is a lot less inconvenient than a cold restart.

...sometimes it works; unfortunately, mostly there is no effect. The
LEDs on the switch continues to blink and the only way is to completely
power-off and then to restart.

Thanks anyway! :-)

Frank

poloshiao (poloshiao) wrote :

my eth0 ethernet r8169 with MAC, e.g., ab:cd:ef:gh:ij:kl, normal before 9.10, but abnormal when installed 10.04.
There was a new eth1 item, eth1, in /etc/udev/rules.d/70-persistent-net.rules with MAC, 00:00:00:00:ij:kl.
It became normal after updating about one month later.
But It became 00:00:00:00:ij:kl once again after updating today.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 12 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Gerad Munsch (unforgiven512) wrote :

I believe this same bug is affecting Ubuntu 11.04, kernel 2.6.38-8-generic -- my r8169 interface is now eth1, and it has been assigned MAC address 00:E0:12:34:56:78

This is quite an odd bug, I must say.

Changed in linux (Fedora):
importance: Unknown → Medium
status: Unknown → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.