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][r...@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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
