Re: 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
Reply to: