[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: eth1_rename: transmit timed out



On Mon, May 07, 2007 at 19:05:06 -0700, jason.public wrote:
> On 5/7/07, Florian Kulzer wrote:
> >On Sat, May 05, 2007 at 14:01:45 -0700, jason.public wrote:
> >> Every once in a while, my eth1 interface dies with the following 
> >messages.

[...]

> >> NETDEV WATCHDOG: eth1_rename: transmit timed out
> >> eth1_rename: transmit timed out, tx_status 00 status 6000.

[...]

> >> eth1_rename: Resetting the Tx ring pointer.
> >>
> >> Either I have to restart it with "/etc/init.d/networking restart", or
> >> it restarts by itself after a minute or so.  Any idea what the problem
> >> is?

[...]

> There are two ethernet cards, but it's the 3Com that has been causing
> problems.  When eth1_rename dies, it usually causes eth0 (the Realtek)
> to stop working as well.
> 
> # lspci|grep Ethernet
> 00:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169
> Gigabit Ethernet (rev 10)
> 00:0a.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]
> 
> Here's the output of ifconfig:
> 
> # ifconfig
> eth0      Link encap:Ethernet  HWaddr 00:08:54:B3:70:2E
>          inet addr:192.168.1.5  Bcast:192.168.1.255  Mask:255.255.255.0
>          inet6 addr: fe80::208:54ff:feb3:702e/64 Scope:Link
>          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

[...]

> eth1_rena Link encap:Ethernet  HWaddr 00:60:97:7D:43:37
>          inet addr:192.168.0.3  Bcast:192.168.0.255  Mask:255.255.255.0
>          inet6 addr: fe80::260:97ff:fe7d:4337/64 Scope:Link
>          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

[...]

> lo        Link encap:Local Loopback
>          inet addr:127.0.0.1  Mask:255.0.0.0
>          inet6 addr: ::1/128 Scope:Host
>          UP LOOPBACK RUNNING  MTU:16436  Metric:1

[...]

> And the contents of /etc/udev/rules.d/z25_persistent-net.rules:
> 
> # This file was automatically generated by the /lib/udev/write_net_rules
> # program, probably run by the persistent-net-generator.rules rules file.
> #
> # You can modify it, as long as you keep each rule on a single line.
> 
> # PCI device 10b7:9050 (3c59x)
> SUBSYSTEM=="net", DRIVERS=="?*", SYSFS{address}=="00:60:97:7d:43:37",
> NAME="eth0"
> # PCI device 0x10ec:0x8169 (r8169)
> SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:08:54:b3:70:2e",
> NAME="eth0"
> 
> The "_rename" suffix used to bother me (it doesn't make sense for a
> developer to assume that a user will want to figure out how to rename
> a device), but I've gotten used to it.
> 
> I've searched google for this error, and a lot of discussions about
> bugs in a recent kernel come up.  Maybe the solution will be to
> upgrade my kernel once the bug is fixed.  Any other ideas?

Udev is probably getting confused because it is told to assign the same
name ("eth0") to two different devices. I am not sure if this is causing
your problem, but it will surely increase the stability of your system
if you correct /etc/udev/rules.d/z25_persistent-net.rules. I think
something like this should work better:

# PCI device 10b7:9050 (3c59x)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:60:97:7d:43:37", NAME="eth0"
# PCI device 0x10ec:0x8169 (r8169)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:08:54:b3:70:2e", NAME="eth1"

Note that I changed "SYSFS" to "ATTRS" for the first rule. You can of
course decide yourself which device should become "eth0". (You can give
them completely different names as well, such as "3com" and "realtek",
or "bob" and "grant", or whatever.)

You should also make sure that ATTRS{address} is actually correct in
both cases. (It corresponds to "HWAddr" in the ifconfig output.) If you
want to check what udev did then you can use the following lengthy
command to get an overview of all your network devices, their HW
addresses and their associated drivers:

for D in /sys/class/net/*; do echo "${D##*/}"; udevinfo -a --path "$D" | egrep 'address|DRIVERS==".+"'; done

(This should all be in one line.)

Once you have decided on the permanent names of the devices, you might
have to update /etc/network/interfaces, your firewall rules and the
configuration files of some other network-related programs.

-- 
Regards,            | http://users.icfo.es/Florian.Kulzer
          Florian   |



Reply to: