FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 02-08-2010, 02:38 AM
Frank Miles
 
Default eth0 - eth1 confusion vs. local network

... ok, started...


[snip]


I fail to see what it's doing, but I cannot see any reference to "eth1",
it's like only one interace is being recognized :-?

What is the output of "dmesg | grep eth"?


[ 6.317161] eth1: RTL8168d/8111d at 0xffffc90000c4e000,xx:xx:xx:xx:xx:xx, XID 083000c0 IRQ 32
[ 6.384830] eth1: unable to apply firmware patch
[ 7.190453] udev: renamed network interface eth1 to eth0
[ 7.229390] udev: renamed network interface eth0_rename to eth1
[ 11.276999] r8169: eth0: link up

[ 11.277005] r8169: eth0: link up
[ 12.215716] eth1: setting full-duplex.
[ 21.531029] eth0: no IPv6 routers present
[ 22.599867] eth1: no IPv6 routers present


Again, eth1 is working fine; eth0 seems completely
blocked/nonfunctional, despite all the configuration files and netstats
looking fine.


Errr, sir... something goes wrong here.

As per your "/etc/udev/rules.d/70-persistent-net.rules":

eth0 -> realtek
eth1 -> 3com

But that is not what dmesg says above.


That's the reason for my earlier fact-free speculation , based on a kern.log entry:
> Perhaps the kernel brings eth1 into existence by first establishing it as
> eth0, then renaming it to eth1; then bringing the "real" eth0 into existence.
The kern.log entries don't appear in the dmesg output.

Also, there is no "link up" or "link down" for eth1 but *both" eth0 going
up. Not sure how to interpret that.


I don't know how to interpret that either, but the message is completely
unchanged other than time - why assume it is referring to the 3com card

in either case? And in any event, the 3com card is functioning - it's
the realtek that isn't.


I made a minor effort earlier to suppress the IPv6 modules, but [a]
didn't succeed; and [b] hadn't suppressed them earlier with the
one-interface system so wasn't convinced it was worth trying - why
shouldn't this cause eth1 to quit as well as eth0? Also the previous
system showed some indications of IPv6 in its reports, and it worked
fine.


I don't think this issue can have any relation with ipv6 :-?.

How about your "/etc/network/interfaces"?

Besides, you can make a quick probe by disabling "eth1" and test if the
network works as expected ("ping" et al) and then disable "eth0" and
perform the same test. I mean, test the network adapters "separately".


Greetings,

--
Camale??n


Tom H:

Thanks for your queries also. I agree that the ipv6 warning is probably
not an issue. What follows may help answer the questions that both of
you have raised:

-----------------------------------------
...and diverted and continued...

I decided to go back and re-establish the system when it only had a single NIC.
Unfortunately this is the r8169, which has the possible firmware issue. I was
_unable_ to get that working, though it had worked at one time. In the hopes
of satisfying your curiousity, here are some reports from that experiment:

puffin:~# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

puffin:~# arp -a
grebe (192.168.0.4) at xx:xx:xx:xx:xx:xx [ether] on eth0

puffin:# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.0.10 0.0.0.0 UG 0 0 0 eth0
puffin:# ping 192.168.0.4
PING 192.168.0.4 (192.168.0.4) 56(84) bytes of data.
^C
--- 192.168.0.4 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2016ms

puffin:~# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
puffin:~# /sbin/ifconfig

eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet addr:192.168.0.10 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::6ef0:49ff:fe08:a40/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:18 errors:0 dropped:0 overruns:0 frame:0
TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1080 (1.0 KiB) TX bytes:594 (594.0 B)
Interrupt:32 Base address:0x6000

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
RX packets:69 errors:0 dropped:0 overruns:0 frame:0
TX packets:69 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:18577 (18.1 KiB) TX bytes:18577 (18.1 KiB)

puffin:~# dmesg | fgrep eth
[ 0.534289] Driver 'rtc_cmos' needs updating - please use bus_type methods
[ 6.658237] eth0: RTL8168d/8111d at 0xffffc90000c56000, xx:xx:xx:xx:xx:xx, XID 083000c0 IRQ 32
[ 6.808657] eth0: unable to apply firmware patch
[ 11.283432] r8169: eth0: link up
[ 11.283438] r8169: eth0: link up
[ 21.431334] eth0: no IPv6 routers present

puffin:~# ping 192.168.0.4
PING 192.168.0.4 (192.168.0.4) 56(84) bytes of data.
^C

puffin:# route add default gw puffin
puffin:# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.0.10 0.0.0.0 UG 0 0 0 eth0

puffin:# ping 192.168.0.4
PING 192.168.0.4 (192.168.0.4) 56(84) bytes of data.
^C
--- 192.168.0.4 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2016ms

-----------------------------------------
Briefly, my thinking now is that I somehow managed to mess up the NIC firmware
situation that had originally been set up, probably when I updated the system.
Before this change, I'd loaded the whole system using eth0 - tens of GB - with
no problem!

There are several bug reports associated with the r8169 - and its (lack of)
firmware associated with the 2.6.32 kernel [see, for example, #561309].
I'll have to see if I can scrounge another NIC as a temporary work-around.

Thanks again for your diagnostic tips, it has prodded my thinking. Any
other ideas welcome!

Frank


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-08-2010, 06:15 AM
Stan Hoeppner
 
Default eth0 - eth1 confusion vs. local network

Hi Frank, sorry you're going through such pains here. Did the same myself not
long ago.

Frank Miles put forth on 2/7/2010 12:41 PM:

> Feb 7 04:51:22 puffin kernel: [ 6.156559] r8169 Gigabit Ethernet
> driver 2.3LK-NAPI loaded
> Feb 7 04:51:22 puffin kernel: [ 6.156573] r8169 0000:02:00.0: PCI
> INT A -> GSI 17 (level, low) -> IRQ 17
> Feb 7 04:51:22 puffin kernel: [ 6.157040] eth0: RTL8168d/8111d at
> 0xffffc90000c78000, x:x:x:x:x:x, XID 083000c0 IRQ 32
> Feb 7 04:51:22 puffin kernel: [ 6.161239] r8169 0000:02:00.0:
> firmware: requesting rtl8168d-2.fw
> Feb 7 04:51:22 puffin kernel: [ 6.234448] eth0: unable to apply
> firmware patch
>
> Perhaps the kernel brings eth1 into existence by first establishing it as
> eth0, then renaming it to eth1; then bringing the "real" eth0 into
> existence.

The above can happen when you add NICs to the system. I hate UDEV for this, and
it took me the better part of a day to figure this out a few months ago. UDEV
names the devices based on PCI bus slot number order. If you add a new PCI NIC
into an empty slot with a lower number than that of the NIC already in the
system, UDEV makes the lowest slot number eth0 and the higher slot number eth1.
The solution is to change the PCI slot order or create a UDEV static naming
rule based on MAC address that overrides the slot number ordering. This is a
far cry from the root of your problems at this point. Solve the problem below,
then look here if you still have device naming issues:

http://www.debianhelp.co.uk/udev.htm

> The "unable to apply firmware patch" seems potentially alarming, but it
> used to work as a single-interface system. lspci -v indicates both
> NICs have "Kernel driver in use".

This is the kicker here. Changing kernels likely broke your firmware blobs. I
ran into this myself not two months ago with a Compaq NC3121 and an Intel Pro
100, based on the Intel 82558 and 82559 respectively. I was compiling a new
kernel as I was adding a SATA card and some other hardware, and needed new
drivers. Both these NICs need firmware blobs. I didn't think the blobs were
needed, at that time, so I unchecked the "include firmware blobs" option in make
menuconfig thinking it might shrink my kernel down a little (I'm an efficiency
freak). After compiling and installing the kernel, this was 2.6.31.1 from
kernel.org, neither of my NICs worked. I had the same dmesg errors as yours.
If I'm not mistaken, the kernel.org source config defaults to include the
firmware blobs in the kernel (as it should). I took a gamble and paid the
price, having to recompile with the option enabled to get the NICs working again.

> firmware: requesting xxxxx.xx
> unable to apply firmware patch

To fix this problem, one option is to include the firmware blobs in the kernel,
as I do. So you'd end up with this in /usr/src/linux-x.xx.xx/.config before you
make your kernel package:

CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_FIRMWARE_MEMMAP=y

Read this from kernel.org 2.6.31.1 menuconfig help:

The kernel source tree includes a number of firmware 'blobs' which are used by
various drivers. The recommended way to use these is to run "make
firmware_install" and to copy the resulting binary files created in
usr/lib/firmware directory of the kernel tree to the /lib/firmware on your
system so that they can be loaded by userspace helpers on request. Enabling
this option will build each required firmware blob into the kernel directly,
where request_firmware() will find them without having to call out to userspace.
This may be useful if your root file system requires a device which uses such
firmware, and do not wish to use an initrd. This single option controls the
inclusion of firmware for every driver which uses request_firmware() and ships
its firmware in the kernel source tree, to avoid a proliferation of 'Include
firmware for xxx device' options.

This may also be worth a read for some background on the implications leading to
missing firmware blobs. This is from the kernel.org 2.6.31.1 source zip file.
Pay particular attention to what the author says in 3) below.

[01:07:16][root@greer]/usr/src/linux-2.6.31.1/Documentation/firmware_class$ cat
README

request_firmware() hotplug interface:
------------------------------------
Copyright (C) 2003 Manuel Estrada Sainz

Why:
---

Today, the most extended way to use firmware in the Linux kernel is linking
it statically in a header file. Which has political and technical issues:

1) Some firmware is not legal to redistribute.
2) The firmware occupies memory permanently, even though it often is just
used once.
3) Some people, like the Debian crowd, don't consider some firmware free
enough and remove entire drivers (e.g.: keyspan).

High level behavior (mixed):
============================

kernel(driver): calls request_firmware(&fw_entry, $FIRMWARE, device)

userspace:
- /sys/class/firmware/xxx/{loading,data} appear.
- hotplug gets called with a firmware identifier in $FIRMWARE
and the usual hotplug environment.
- hotplug: echo 1 > /sys/class/firmware/xxx/loading

kernel: Discard any previous partial load.

userspace:
- hotplug: cat appropriate_firmware_image >
/sys/class/firmware/xxx/data

kernel: grows a buffer in PAGE_SIZE increments to hold the image as it
comes in.

userspace:
- hotplug: echo 0 > /sys/class/firmware/xxx/loading

kernel: request_firmware() returns and the driver has the firmware
image in fw_entry->{data,size}. If something went wrong
request_firmware() returns non-zero and fw_entry is set to
NULL.

kernel(driver): Driver code calls release_firmware(fw_entry) releasing
the firmware image and any related resource.

High level behavior (driver code):
==================================

if(request_firmware(&fw_entry, $FIRMWARE, device) == 0)
copy_fw_to_device(fw_entry->data, fw_entry->size);
release(fw_entry);

Sample/simple hotplug script:
============================

# Both $DEVPATH and $FIRMWARE are already provided in the environment.

HOTPLUG_FW_DIR=/usr/lib/hotplug/firmware/

echo 1 > /sys/$DEVPATH/loading
cat $HOTPLUG_FW_DIR/$FIRMWARE > /sysfs/$DEVPATH/data
echo 0 > /sys/$DEVPATH/loading

Random notes:
============

- "echo -1 > /sys/class/firmware/xxx/loading" will cancel the load at
once and make request_firmware() return with error.

- firmware_data_read() and firmware_loading_show() are just provided
for testing and completeness, they are not called in normal use.

- There is also /sys/class/firmware/timeout which holds a timeout in
seconds for the whole load operation.

- request_firmware_nowait() is also provided for convenience in
user contexts to request firmware asynchronously, but can't be called
in atomic contexts.


about in-kernel persistence:
---------------------------
Under some circumstances, as explained below, it would be interesting to keep
firmware images in non-swappable kernel memory or even in the kernel image
(probably within initramfs).

Note that this functionality has not been implemented.

- Why OPTIONAL in-kernel persistence may be a good idea sometimes:

- If the device that needs the firmware is needed to access the
filesystem. When upon some error the device has to be reset and the
firmware reloaded, it won't be possible to get it from userspace.
e.g.:
- A diskless client with a network card that needs firmware.
- The filesystem is stored in a disk behind an scsi device
that needs firmware.
- Replacing buggy DSDT/SSDT ACPI tables on boot.
Note: this would require the persistent objects to be included
within the kernel image, probably within initramfs.

And the same device can be needed to access the filesystem or not depending
on the setup, so I think that the choice on what firmware to make
persistent should be left to userspace.

--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-08-2010, 03:32 PM
Frank Miles
 
Default eth0 - eth1 confusion vs. local network

Thanks so much to Stan, Tom H, and Cameleon!

It seems that the consensus is that it's a NIC problem. In case
it wasn't previously clear, the RealTek 8169 is part of the Gigabyte
motherboard.

I thought that I'd escaped non-free-firmware hell by getting a MB
with the graphics based on an Intel chip. Never had a problem before,
but then I usually stand far back from the bleeding edge.

Stan, like you I usually use my own-build kernels. But I'd had
problems getting my own kernels to run with full graphics
capabilities, so had fallen back on the Debian 2.6.32-trunk.

What I'm going to be doing in the short term is turning the
RealTek off (BIOS setting), and installing another NIC. I should
be able to get things running this way. I will post again once
I've done this. Longer term, I'll try to get the RealTek running.
All this flailing about has put me behind on other things, so that

may not be right away.

Thanks again to you all... it's been real educational.

-Frank


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-08-2010, 06:19 PM
Stan Hoeppner
 
Default eth0 - eth1 confusion vs. local network

Frank Miles put forth on 2/8/2010 10:32 AM:
> Thanks so much to Stan, Tom H, and Cameleon!
>
> It seems that the consensus is that it's a NIC problem. In case
> it wasn't previously clear, the RealTek 8169 is part of the Gigabyte
> motherboard.
>
> I thought that I'd escaped non-free-firmware hell by getting a MB
> with the graphics based on an Intel chip. Never had a problem before,
> but then I usually stand far back from the bleeding edge.
>
> Stan, like you I usually use my own-build kernels. But I'd had
> problems getting my own kernels to run with full graphics
> capabilities, so had fallen back on the Debian 2.6.32-trunk.
>
> What I'm going to be doing in the short term is turning the
> RealTek off (BIOS setting), and installing another NIC. I should
> be able to get things running this way. I will post again once
> I've done this. Longer term, I'll try to get the RealTek running. All
> this flailing about has put me behind on other things, so that
> may not be right away.
>
> Thanks again to you all... it's been real educational.

You're welcome Frank. I'm sure the Debian kernel team with get the 8169
driver/firmware issue worked out within a point release or two.

Worth a look:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561309
http://www.linux-archive.org/debian-kernel/283643-2-6-32-experimental.html
http://www.newegg.com/Product/Product.aspx?Item=N82E16833180026
http://www.newegg.com/Product/Product.aspx?Item=N82E16833106123
http://www.newegg.com/Product/Product.aspx?Item=N82E16833106033

--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-08-2010, 07:29 PM
Andrei Popescu
 
Default eth0 - eth1 confusion vs. local network

On Mon,08.Feb.10, 01:15:43, Stan Hoeppner wrote:

> > Perhaps the kernel brings eth1 into existence by first establishing it as
> > eth0, then renaming it to eth1; then bringing the "real" eth0 into
> > existence.
>
> The above can happen when you add NICs to the system. I hate UDEV for this, and
> it took me the better part of a day to figure this out a few months ago. UDEV
> names the devices based on PCI bus slot number order. If you add a new PCI NIC
> into an empty slot with a lower number than that of the NIC already in the
> system, UDEV makes the lowest slot number eth0 and the higher slot number eth1.

I seem to recall such issues in the (quite distant) past.

> The solution is to change the PCI slot order or create a UDEV static naming
> rule based on MAC address that overrides the slot number ordering.

This is already done in /etc/udev/rules.d/70-persistent-net.rules (which
is actually generated by another rule).

Regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
 
Old 02-08-2010, 09:33 PM
Stan Hoeppner
 
Default eth0 - eth1 confusion vs. local network

Andrei Popescu put forth on 2/8/2010 2:29 PM:
> On Mon,08.Feb.10, 01:15:43, Stan Hoeppner wrote:
>
>>> Perhaps the kernel brings eth1 into existence by first establishing it as
>>> eth0, then renaming it to eth1; then bringing the "real" eth0 into
>>> existence.
>>
>> The above can happen when you add NICs to the system. I hate UDEV for this, and
>> it took me the better part of a day to figure this out a few months ago. UDEV
>> names the devices based on PCI bus slot number order. If you add a new PCI NIC
>> into an empty slot with a lower number than that of the NIC already in the
>> system, UDEV makes the lowest slot number eth0 and the higher slot number eth1.
>
> I seem to recall such issues in the (quite distant) past.
>
>> The solution is to change the PCI slot order or create a UDEV static naming
>> rule based on MAC address that overrides the slot number ordering.
>
> This is already done in /etc/udev/rules.d/70-persistent-net.rules (which
> is actually generated by another rule).

So, are you saying it didn't happen? Couldn't have happened? Shouldn't have
happened? I'm imagining things? Are you kidding?

It broke. I fixed it by manually editing the precise file you list above.
Maybe it happened because I have ACPI disabled on this old (1998) 440BX MB due
to its ACPI implementation being buggy. Maybe it's because I have power
management disabled. Maybe it's a BIOS bug. Maybe it happened because both
cards use the 8255x chip (though one was an NC3121 with 82558 and the other an
actual Intel Pro 100 Server Adapter with an 82559). The cause could have been
any number of things.

Regardless, it happened. I fixed it manually. It did not properly
auto-reconfigure.

--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-09-2010, 03:07 AM
Frank Miles
 
Default eth0 - eth1 confusion vs. local network

I won't belabor this.

Putting in a different NIC fixed things. No fuss, though interesting that it
(presumably udev) wanted to call it eth2. I can live with that.

Thanks again, everyone!

-Frank


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-09-2010, 08:37 AM
Andrei Popescu
 
Default eth0 - eth1 confusion vs. local network

On Mon,08.Feb.10, 16:33:39, Stan Hoeppner wrote:

> So, are you saying it didn't happen? Couldn't have happened? Shouldn't have
> happened? I'm imagining things? Are you kidding?

No, I'm saying that under normal circumstances it should work.

> It broke. I fixed it by manually editing the precise file you list above.
> Maybe it happened because I have ACPI disabled on this old (1998) 440BX MB due
> to its ACPI implementation being buggy. Maybe it's because I have power
> management disabled. Maybe it's a BIOS bug. Maybe it happened because both
> cards use the 8255x chip (though one was an NC3121 with 82558 and the other an
> actual Intel Pro 100 Server Adapter with an 82559). The cause could have been
> any number of things.
>
> Regardless, it happened. I fixed it manually. It did not properly
> auto-reconfigure.

It could be that you encountered a bug in the auto-reconfigure scripts
or maybe even deeper (reminds me of the nvidia adapters that had a
different MAC on each reboot).

Since your bug is quite unique (or at least no reports here on d-u) I
doubt it's good advice to tell someone having troubles with networking
to edit udev rules, especially since the OP mentioned the interface
names were ok and consistent.

Regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
 
Old 02-09-2010, 08:39 AM
Andrei Popescu
 
Default eth0 - eth1 confusion vs. local network

On Mon,08.Feb.10, 20:07:36, Frank Miles wrote:
> I won't belabor this.
>
> Putting in a different NIC fixed things. No fuss, though interesting that it
> (presumably udev) wanted to call it eth2. I can live with that.

Of course it did, eth0 and eth1 were already taken

Regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
 
Old 02-10-2010, 04:06 AM
Stan Hoeppner
 
Default eth0 - eth1 confusion vs. local network

Andrei Popescu put forth on 2/9/2010 3:37 AM:
> On Mon,08.Feb.10, 16:33:39, Stan Hoeppner wrote:
>
>> So, are you saying it didn't happen? Couldn't have happened? Shouldn't have
>> happened? I'm imagining things? Are you kidding?
>
> No, I'm saying that under normal circumstances it should work.

I don't recall the exact circumstances. I know I added a SATA card and the 2nd
NIC during an upgrade. I had to shuffle cards around for cable routing and
airflow reasons. I'm not sure at this point what slot I had the original NIC in
and what slot I moved it to, or what slot the 2nd NIC ended up in. It
"shouldn't" make a different as to eth0 and eth1 naming, but it did. It made
the original NIC eth1 and the new NIC eth0. The first thing I tried was
rebooting, which didn't solve the problem. I went Googling and found the udev
rules solution. I didn't post a bug report or anything about it because I fixed
the problem rather quickly using the info I found. I didn't think it was a bug,
just an unfortunate oddity of UDEV, especially after reading the Debian document
I reference below.

> It could be that you encountered a bug in the auto-reconfigure scripts
> or maybe even deeper (reminds me of the nvidia adapters that had a
> different MAC on each reboot).

I don't know anything about these scripts. When do they run? And are they
supposed to pin a mac addr to eth* name? That obviously didn't work if that's
the case. Both these NICs have hard MAC addresses, as is required by the 802
standard for any add-in ethernet card. It seems clear that the cause of the
UDEV device naming problem was me swapping cards around.

> Since your bug is quite unique (or at least no reports here on d-u) I
> doubt it's good advice to tell someone having troubles with networking
> to edit udev rules, especially since the OP mentioned the interface
> names were ok and consistent.

The mere existence of this Debian doc (and others) suggests that this UDEV
eth0/eth1/etc naming problem is fairly common. Common enough for people to take
the time to write a lengthy help document.
http://www.debianhelp.co.uk/udev.htm

This was a pretty lengthy thread, many suggestions were made, and I was not the
only one looking at udev device naming as potentially part of the OP's problem,
yet you singled me out....hmm. I find it interesting that you single me out for
this, given that in one post I firmly identified the root cause of the OP's
problem, and recommended a solution, whilst telling the OP to come back and look
at udev _only_ if he had device naming issues _after_ the root problem was solved.

Are you a UDEV developer or maintainer by chance Andrei? Did my statement below
"I hate UDEV for this" strike a nerve and prompt your entry into this thread?
If so please accept my apologies. I was merely stating _my_ perspective on my
experience with my udev issue, not making any blanket statement about the
quality of UDEV. I save that kind of remark for later, in the event I have
problems with UDEV in the future.

Note how little text I devote to UDEV below, but how much I devote to the
firmware issue which I correctly identified as the root cause of the OP's
problem? I think your jumping on my UDEV comments is unjustified given the
facts in the thread.


I said on Mon, 08 Feb 2010 01:15:43 -0600:

> The above can happen when you add NICs to the system. I hate UDEV for this, and
> it took me the better part of a day to figure this out a few months ago. UDEV
> names the devices based on PCI bus slot number order. If you add a new PCI NIC
> into an empty slot with a lower number than that of the NIC already in the
> system, UDEV makes the lowest slot number eth0 and the higher slot number eth1.
> The solution is to change the PCI slot order or create a UDEV static naming
> rule based on MAC address that overrides the slot number ordering. This is a
> far cry from the root of your problems at this point. Solve the problem below,
> then look here if you still have device naming issues:
>
> http://www.debianhelp.co.uk/udev.htm
>
>> The "unable to apply firmware patch" seems potentially alarming, but it
>> used to work as a single-interface system. lspci -v indicates both
>> NICs have "Kernel driver in use".
>
> This is the kicker here. Changing kernels likely broke your firmware blobs. I
> ran into this myself not two months ago with a Compaq NC3121 and an Intel Pro
> 100, based on the Intel 82558 and 82559 respectively. I was compiling a new
> kernel as I was adding a SATA card and some other hardware, and needed new
> drivers. Both these NICs need firmware blobs. I didn't think the blobs were
> needed, at that time, so I unchecked the "include firmware blobs" option in make
> menuconfig thinking it might shrink my kernel down a little (I'm an efficiency
> freak). After compiling and installing the kernel, this was 2.6.31.1 from
> kernel.org, neither of my NICs worked. I had the same dmesg errors as yours.
> If I'm not mistaken, the kernel.org source config defaults to include the
> firmware blobs in the kernel (as it should). I took a gamble and paid the
> price, having to recompile with the option enabled to get the NICs working again.
>
>> firmware: requesting xxxxx.xx
>> unable to apply firmware patch
>
> To fix this problem, one option is to include the firmware blobs in the kernel,
> as I do. So you'd end up with this in /usr/src/linux-x.xx.xx/.config before you
> make your kernel package:
>
> CONFIG_FIRMWARE_IN_KERNEL=y
> CONFIG_FIRMWARE_MEMMAP=y
>
> Read this from kernel.org 2.6.31.1 menuconfig help:
>
> The kernel source tree includes a number of firmware 'blobs' which are used by
> various drivers. The recommended way to use these is to run "make
> firmware_install" and to copy the resulting binary files created in
> usr/lib/firmware directory of the kernel tree to the /lib/firmware on your
> system so that they can be loaded by userspace helpers on request. Enabling
> this option will build each required firmware blob into the kernel directly,
> where request_firmware() will find them without having to call out to userspace.
> This may be useful if your root file system requires a device which uses such
> firmware, and do not wish to use an initrd. This single option controls the
> inclusion of firmware for every driver which uses request_firmware() and ships
> its firmware in the kernel source tree, to avoid a proliferation of 'Include
> firmware for xxx device' options.
>
> This may also be worth a read for some background on the implications leading to
> missing firmware blobs. This is from the kernel.org 2.6.31.1 source zip file.
> Pay particular attention to what the author says in 3) below.
>
> [01:07:16][root@greer]/usr/src/linux-2.6.31.1/Documentation/firmware_class$ cat
> README
>
> request_firmware() hotplug interface:
> ------------------------------------
> Copyright (C) 2003 Manuel Estrada Sainz
>
> Why:
> ---
>
> Today, the most extended way to use firmware in the Linux kernel is linking
> it statically in a header file. Which has political and technical issues:
>
> 1) Some firmware is not legal to redistribute.
> 2) The firmware occupies memory permanently, even though it often is just
> used once.
> 3) Some people, like the Debian crowd, don't consider some firmware free
> enough and remove entire drivers (e.g.: keyspan).
>
> High level behavior (mixed):
> ============================
>
> kernel(driver): calls request_firmware(&fw_entry, $FIRMWARE, device)
>
> userspace:
> - /sys/class/firmware/xxx/{loading,data} appear.
> - hotplug gets called with a firmware identifier in $FIRMWARE
> and the usual hotplug environment.
> - hotplug: echo 1 > /sys/class/firmware/xxx/loading
>
> kernel: Discard any previous partial load.
>
> userspace:
> - hotplug: cat appropriate_firmware_image >
> /sys/class/firmware/xxx/data
>
> kernel: grows a buffer in PAGE_SIZE increments to hold the image as it
> comes in.
>
> userspace:
> - hotplug: echo 0 > /sys/class/firmware/xxx/loading
>
> kernel: request_firmware() returns and the driver has the firmware
> image in fw_entry->{data,size}. If something went wrong
> request_firmware() returns non-zero and fw_entry is set to
> NULL.
>
> kernel(driver): Driver code calls release_firmware(fw_entry) releasing
> the firmware image and any related resource.
>
> High level behavior (driver code):
> ==================================
>
> if(request_firmware(&fw_entry, $FIRMWARE, device) == 0)
> copy_fw_to_device(fw_entry->data, fw_entry->size);
> release(fw_entry);
>
> Sample/simple hotplug script:
> ============================
>
> # Both $DEVPATH and $FIRMWARE are already provided in the environment.
>
> HOTPLUG_FW_DIR=/usr/lib/hotplug/firmware/
>
> echo 1 > /sys/$DEVPATH/loading
> cat $HOTPLUG_FW_DIR/$FIRMWARE > /sysfs/$DEVPATH/data
> echo 0 > /sys/$DEVPATH/loading
>
> Random notes:
> ============
>
> - "echo -1 > /sys/class/firmware/xxx/loading" will cancel the load at
> once and make request_firmware() return with error.
>
> - firmware_data_read() and firmware_loading_show() are just provided
> for testing and completeness, they are not called in normal use.
>
> - There is also /sys/class/firmware/timeout which holds a timeout in
> seconds for the whole load operation.
>
> - request_firmware_nowait() is also provided for convenience in
> user contexts to request firmware asynchronously, but can't be called
> in atomic contexts.
>
>
> about in-kernel persistence:
> ---------------------------
> Under some circumstances, as explained below, it would be interesting to keep
> firmware images in non-swappable kernel memory or even in the kernel image
> (probably within initramfs).
>
> Note that this functionality has not been implemented.
>
> - Why OPTIONAL in-kernel persistence may be a good idea sometimes:
>
> - If the device that needs the firmware is needed to access the
> filesystem. When upon some error the device has to be reset and the
> firmware reloaded, it won't be possible to get it from userspace.
> e.g.:
> - A diskless client with a network card that needs firmware.
> - The filesystem is stored in a disk behind an scsi device
> that needs firmware.
> - Replacing buggy DSDT/SSDT ACPI tables on boot.
> Note: this would require the persistent objects to be included
> within the kernel image, probably within initramfs.
>
> And the same device can be needed to access the filesystem or not depending
> on the setup, so I think that the choice on what firmware to make
> persistent should be left to userspace.
>

--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 07:23 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org