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