Kernel Firmware Loading
Hello,
I have a SpeedTouch USB modem and I use the kernel driver. I used to build the speedtch driver into the kernel and with 2.6.14 that worked well. As the system booted it detected the modem, generated a hotplug event and udev called /sbin/firmware_helper to load the firmware into the modem.
But with the 2.6.14-git2 kernel that no longer works. It seems that the kernel is asking for the firmware before /lib/firmware has been mounted so the process fails. If I build the speedtch driver as a module and modprobe it with a boot script then it works as normal.
However, I would prefer to be able to build a completely monolithic kernel. Then I can then use the same kernel to boot into several different distros installed on different partitions. If the speedtch driver is compiled as a module I have to remember to copy /lib/modules onto several different partitions every time I recompile the kernel (which is every day).
So what I'd like to know is, is there some command I can use to get the kernel driver to load the firmware? Some way of generating a hotplug event for the modem (without unplugging it) after /lib/firmware has been mounted?
Andy
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 11 lines · Andrew Benton
Hello,
I have a SpeedTouch USB modem and I use the kernel driver. I used to build the speedtch driver into the kernel and with 2.6.14 that worked well. As the system booted it detected the modem, generated a hotplug event and udev called/sbin/firmware_helperto load the firmware into the modem.But with the 2.6.14-git2 kernel that no longer works. It seems that the kernel is asking for the firmware before
/lib/firmwarehas been mounted so the process fails. If I build the speedtch driver as a module and modprobe it with a boot script then it works as normal.
Create an initramfs and load firmware from there.
Signature · 12 lines
Alexander E. Patrakov ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines · Alexander E. Patrakov
Create an initramfs and load firmware from there.
C'mon Alexander, behave yourself...
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
It would be nice if the driver was more helpful here, by trying to load the firmware more than once. It's a bit tricky though. For example, you could say: "if the firmware wasn't found, then try to load it when someone opens a connection". Unfortunately, while this is possible with the speedtch modem, this isn't possible with the connexant access runner: you can't correctly create an ATM device unless the firmware was already loaded into the modem, which means it's impossible to even try to open a connection before the firmware is loaded. Another possibility is to try to load the firmware every couple of seconds. I could certainly do that, but it's not very elegant.
In any case, I too am interested in hearing what the hotplug people have to say.
Ciao,
Duncan.
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 4 lines · You
Quoted 1 line · Alexander E. Patrakov
Create an initramfs and load firmware from there.
C'mon Alexander, behave yourself...
Unfortunately, this is the official upstream answer so far. This has popped up several times, see e.g. this message:
http://lkml.org/lkml/2005/6/9/17
If you disagree, please do so publicly (BTW I also don't like this situation, but let's see what happens if there appears some cheap-but-well-advertised SCSI card that requires firmware).
Signature · 12 lines
Alexander E. Patrakov ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 4 lines · Duncan Sands
open a connection before the firmware is loaded. Another possibility is to try to load the firmware every couple of seconds. I could certainly do that, but it's not very elegant.
Please do not even think about such an ugly thing.
Quoted 2 lines
In any case, I too am interested in hearing what the hotplug people have to say.
There is nothing wrong with modular drivers or initramfs and I would hate to see silly workarounds hacked in random drivers.
Signature · 13 lines
ciao, Marco ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Hi Marco,
Quoted 5 lines
Quoted 4 lines
open a connection before the firmware is loaded. Another possibility is to try to load the firmware every couple of seconds. I could certainly do that, but it's not very elegant.
Please do not even think about such an ugly thing.
Too late, I already thought about it!
Quoted 4 lines
Quoted 2 lines
In any case, I too am interested in hearing what the hotplug people have to say.
There is nothing wrong with modular drivers or initramfs and I would hate to see silly workarounds hacked in random drivers.
Well, don't you need to have the firmware both in the initramfs and in the (root) filesystem? If the device is already plugged in on boot, than the firmware will need to be loaded out of the initramfs. However, if the device is plugged in after boot, it will need to come off some other filesystem. Or am I confused (I don't know anything about initramfs)? Isn't having to keep multiple copies of the firmware
(a) annoying, and (b) error prone?
Ciao,
Duncan.
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 7 lines · Duncan Sands
Well, don't you need to have the firmware both in the initramfs and in the (root) filesystem? If the device is already plugged in on boot, than the firmware will need to be loaded out of the initramfs. However, if the device is plugged in after boot, it will need to come off some other filesystem. Or am I confused (I don't know anything about initramfs)? Isn't having to keep multiple copies of the firmware
(a) annoying, and (b) error prone?
You need multiple copies of the modules too, this is not a big deal. We may just need slightly smarter initrams building tools.
Signature · 13 lines
ciao, Marco ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 14 lines · Duncan Sands
It would be nice if the driver was more helpful here, by trying to load the firmware more than once. It's a bit tricky though. For example, you could say: "if the firmware wasn't found, then try to load it when someone opens a connection". Unfortunately, while this is possible with the speedtch modem, this isn't possible with the connexant access runner: you can't correctly create an ATM device unless the firmware was already loaded into the modem, which means it's impossible to even try to open a connection before the firmware is loaded. Another possibility is to try to load the firmware every couple of seconds. I could certainly do that, but it's not very elegant.
Quoted 2 lines
In any case, I too am interested in hearing what the hotplug people have to say.
I like to see the stupid timeout in the request_firmware to completely go away. It doesn't make any sense. The drivers should use the async version of request_firmware() anyway and the so called syncronous version should be removed.
If the kernel sends the request out and it gets lost during early boot, you can just fulfill it any time later by looking at the outstanding requests in sysfs.
If you manage it in 10 seconds from kernel init to the mounted root, you may be able to do this today... :)
Kay
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Hi Kay,
Quoted 15 lines · Kay Sievers
Quoted 14 lines · Duncan Sands
It would be nice if the driver was more helpful here, by trying to load the firmware more than once. It's a bit tricky though. For example, you could say: "if the firmware wasn't found, then try to load it when someone opens a connection". Unfortunately, while this is possible with the speedtch modem, this isn't possible with the connexant access runner: you can't correctly create an ATM device unless the firmware was already loaded into the modem, which means it's impossible to even try to open a connection before the firmware is loaded. Another possibility is to try to load the firmware every couple of seconds. I could certainly do that, but it's not very elegant.
Quoted 7 lines
Quoted 2 lines
In any case, I too am interested in hearing what the hotplug people have to say.
I like to see the stupid timeout in the
request_firmwareto completely go away. It doesn't make any sense. The drivers should use the async version ofrequest_firmware()anyway and the so called syncronous version should be removed.
that's fine with me, even though the loading in the speedtouch driver is fundamentally synchronous (no useful work can be done until the firmware is loaded): it is easy to build what I want on top of the async version.
Quoted 3 lines
If the kernel sends the request out and it gets lost during early boot, you can just fulfill it any time later by looking at the outstanding requests in sysfs.
But isn't the problem different: the request did not get lost: it reached the script (or whatever), the script couldn't find the firmware file and cancelled the load? This has nothing to do with timeouts and events getting lost...
Quoted 4 lines
If you manage it in 10 seconds from kernel init to the mounted root, you may be able to do this today... :)
Kay
Best wishes,
Duncan.
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 28 lines · Duncan Sands
Quoted 15 lines · Kay Sievers
Quoted 14 lines · Duncan Sands
It would be nice if the driver was more helpful here, by trying to load the firmware more than once. It's a bit tricky though. For example, you could say: "if the firmware wasn't found, then try to load it when someone opens a connection". Unfortunately, while this is possible with the speedtch modem, this isn't possible with the connexant access runner: you can't correctly create an ATM device unless the firmware was already loaded into the modem, which means it's impossible to even try to open a connection before the firmware is loaded. Another possibility is to try to load the firmware every couple of seconds. I could certainly do that, but it's not very elegant.
Quoted 7 lines
Quoted 2 lines
In any case, I too am interested in hearing what the hotplug people have to say.
I like to see the stupid timeout in the
request_firmwareto completely go away. It doesn't make any sense. The drivers should use the async version ofrequest_firmware()anyway and the so called syncronous version should be removed.that's fine with me, even though the loading in the speedtouch driver is fundamentally synchronous (no useful work can be done until the firmware is loaded): it is easy to build what I want on top of the async version.
Quoted 8 lines
Quoted 3 lines
If the kernel sends the request out and it gets lost during early boot, you can just fulfill it any time later by looking at the outstanding requests in sysfs.
But isn't the problem different: the request did not get lost: it reached the script (or whatever), the script couldn't find the firmware file and cancelled the load? This has nothing to do with timeouts and events getting lost...
Well, just check with the firmware script and never cancel a request if you are in initramfs.
Kay
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 11 lines
Quoted 8 lines
Quoted 3 lines
If the kernel sends the request out and it gets lost during early boot, you can just fulfill it any time later by looking at the outstanding requests in sysfs.
But isn't the problem different: the request did not get lost: it reached the script (or whatever), the script couldn't find the firmware file and cancelled the load? This has nothing to do with timeouts and events getting lost...
Well, just check with the firmware script and never cancel a request if you are in initramfs.
But who will do the actual firmware loading when the root filesystem is mounted? And how will they know that the filesystem is mounted?
Ciao,
Duncan.
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 9 lines · Duncan Sands
Quoted 9 lines
Quoted 8 lines
Quoted 3 lines
If the kernel sends the request out and it gets lost during early boot, you can just fulfill it any time later by looking at the outstanding requests in sysfs.
But isn't the problem different: the request did not get lost: it reached the script (or whatever), the script couldn't find the firmware file and cancelled the load? This has nothing to do with timeouts and events getting lost...
Quoted 5 lines
Quoted 2 lines
Well, just check with the firmware script and never cancel a request if you are in initramfs.
But who will do the actual firmware loading when the root filesystem is mounted?
The usual event replay we do for all other devices too. "Coldplug" or whatever you can call it. The thing we did with old hotlug *.rc scripts and we tried with udevsysnthesize and do now with the "uevent" triggers in sysfs...
Quoted 1 line
And how will they know that the filesystem is mounted?
Well its not magic, you mounted it, right? So you should know it. :) Get it from the fs itself, get it from /proc, remember the state, put a different script in initramfs, ...
Kay
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
(Offtopic)
On Mon, Oct 31, 2005 at 12:08:52PM +0100, Marco d'Itri was heard to remark:
Quoted 1 line
There is nothing wrong with modular drivers or initramfs and I would
There's plenty wrong with initramfs. It makes life more complicated for any normal sysadmin on any normal server system. Typical sysadmin tasks involve recovering a server after a failed drive, failed cable, failed disk controller. This might not be too hard if the sysadmin has exactly the same kind of part which will be plugged into exactly the same slot. But if jiggering is required for other reasons, then life can get very difficult. In particular, creating custom initramfs's is just adding insult to injury. It takes an already complicated and delicate situation and adds a whole new layer of complexity. As a practical sysadmin issue, initramfs should be avoided for normal, operational systems.
--linas
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 4 lines · linas
But if jiggering is required for other reasons, then life can get very difficult. In particular, creating custom initramfs's is just adding insult to injury. It takes an already complicated and delicate situation and adds a whole new layer of complexity.
It looks like you need a distribution with better tools.
Signature · 2 lines
ciao, Marco
Quoted 10 lines · Duncan Sands
Hi Marco,
Quoted 5 lines
Quoted 4 lines
open a connection before the firmware is loaded. Another possibility is to try to load the firmware every couple of seconds. I could certainly do that, but it's not very elegant.
Please do not even think about such an ugly thing.
Too late, I already thought about it!
Well thanks for considering it Duncan.
Perhaps the simplest answer is to change the kernel so that the speedtch driver can only be built as a module? All the distros ship it as a module, it's only weirdos like me who try to build it into the kernel. Andy
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 2 lines
Well thanks for considering it Duncan.
Perhaps the simplest answer is to change the kernel so that the speedtch driver can only be built as a module? All the distros ship it as a module, it's only weirdos like me who try to build it into the kernel.
Why do you think building it as a module helps?
If the module is in the initramfs, then the
firmware will need to be there too.
Ciao,
D.
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 4 lines · Duncan Sands
Why do you think building it as a module helps?
If the module is in the initramfs, then the
firmware will need to be there too.
I've never built an initramfs and don't know how to. I will try, but it may take some time and I'm not confident it will work.
Building the speedtch driver as a module solves the problem because if /lib/modules can be read then so can /lib/firmware
Andy
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines · Andrew Benton
If I wanted to build an initramfs with the SpeedTouch firmware into the kernel, how much else will I need to include to get this to work? Surely to load the firmware I'll also need to include
/sbin/udevsend,/etc/udev/rules.d/10-udev.rules,/sbin/firmware_helper...andwhat else? Won't these things need a whole load of other things? This is looking very complicated.
The general case is indeed very complicated, SUSE's script for creating initramfs is more than 64K long. But since you are interested only in firmware loading, the following stupid hack may work for you. The hack is to put a firmware hotplug handler into initramfs, but still rely upon the (obsolete) builtin kernel mechanism for creating and mounting the root device.
I do use an initramfs because my root filesystem is on LVM2, and also because of suspend2 with swap on LVM2. But it doesn't load any firmware because my devices don't need that.
Details for firmware-loading initramfs (untested, since none of my devices generate firmware hotplug events):
1) Compile klibc, for small-sized "cat", "mount", "sleep", "sh" and "umount" programs, as follows:
Download and unpack
http://www.kernel.org/pub/linux/libs/klibc/Stable/klibc-1.1.1.tar.bz2
Replace "flag = 0" with "flag = MNT_DETACH" in utils/umount.c, line 15, so that umount is lazy.
ln -s /lib/modules/uname -r/build linux
make
and optionally "make install"
Find those small statically linked programs in ash/sh, utils/static/{cat,mount,sleep,umount}.
Alternatively, use glibc-based utils from your existing system, but then you should copy the required libraries into /lib at step (3) below.
2) Install cpio
3) Make a directory and populate it with the following files:
dev/{console,null} (you should know how to mknod them) bin/{sh,cat,mount,sleep,umount} (from klibc) sys (empty directory)
sbin/hotplug (see the contents below) lib/firmware (copy your firmware files there)
The /sbin/hotplug script should contain the following:
#!/bin/sh
[ "$1" != "firmware" ] || [ "$ACTION" != "add" ] || [ ! -f "/lib/firmware/$FIRMWARE" ] || exit 0
mount -t sysfs sysfs /sys
# FIXME: still needed?
if [ ! -e /sys/$DEVPATH/loading ]; then
sleep 1
fi
echo 1 > /sys/$DEVPATH/loading
cat "/lib/firmware/$FIRMWARE" >/sys/$DEVPATH/data echo 0 > /sys/$DEVPATH/loading
umount /sys # racy, see below
Then cd to this directory and create the initramfs:
find . | cpio -o -H newc | gzip -9 > /boot/initramfs_data.cpio.gz
4) modify your boot loader configuration in order to load initramfs_data.cpio.gz as an initrd.
5) Reboot. Please report if firmware loading from this initramfs actually worked for you.
------------------------------
Now about my initramfs.
As you have noticed, the simple initramfs above doesn't include the /init file and thus relies on the obsolete in-kernel mechanism for mounting the root fs. This is racy because mounting/unmounting of /sys in the hotplug handler and in the kernel (or in two instances of hotplug handler) can clash. Also this doesnn't work in my case because there's some non-trivial work required in order to activate LVM2 and resume from swsusp2 when swap is on LVM2.
Thus, I have to use the /init file. It is just a shell script. If this script is present in initramfs, it is executed instead of mounting the root fs. It's then the responsibility of the script to parse the kernel command line and mount the filesystem.
My initramfs is glibc-based, doesn't use udev, and contains all device nodes needed for the "vgchange -ay" command to run. The contents of the /init script:
#!/bin/sh
mount -n -t proc proc /proc
mount -n -t sysfs sysfs /sys
# Needed in order to activate LVM2
# Relies upon /dev/mapper/control and /dev/hda being present vgchange -ay
init=/sbin/init
ro="ro"
read CMDLINE </proc/cmdline
for ARG in $CMDLINE
do
case "$ARG" in
init=*)
init=${ARG#init=}
;;
root=*)
root=${ARG#root=}
;;
ro)
ro="ro"
;;
rw)
ro="rw"
;;
esacdone
echo >/proc/suspend2/do_resume
# We get here when we are not resuming.
mount -n -o "$ro" "$root" /root
umount -n /sys
umount -n /proc
# run-init is a program from klibc, but it compiles fine against glibc too. exec run-init /root "$init" "$@" </root/dev/console >/root/dev/console
Isn't that simple enough? :)
Also this /init file helps avoiding the /sys mounting race: just don't unmount it in the hotplug handler. This /init file will do that for you at the very end.
Signature · 13 lines
Alexander E. Patrakov ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
On Mon, Oct 31, 2005 at 05:33:29PM +0100, Marco d'Itri was heard to remark:
Quoted 7 lines · linas
Quoted 5 lines
But if jiggering is required for other reasons, then life can get very difficult. In particular, creating custom initramfs's is just adding insult to injury. It takes an already complicated and delicate situation and adds a whole new layer of complexity.
It looks like you need a distribution with better tools.
These problems are distribution-independent. When a machine is down, usually all you have is a serial port, and maybe the option to netboot, or maybe a cd-rom drive. Sometimes, one starts playing the game of trying to create a hard disk in one machine, and hoping it boots in another. Better distros won't solve the hard-disk-shuffle game.
--linas
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines · Alexander E. Patrakov
Details for firmware-loading initramfs (untested, since none of my devices generate firmware hotplug events):
<snip>
Hi Alexander,
thanks for taking the time to type such a long message. Unfortunately it isn't working. It boots OK but the firmware doesn't load and I get some rather ominous messages in the sys.log
Nov 1 20:52:31 hame kernel: usb 3-2: reset full speed USB device using uhci_hcd and address 3 Nov 1 20:52:31 hame kernel: Badness in kref_get at lib/kref.c:32 Nov 1 20:52:31 hame kernel: usbcore: registered new driver speedtch Nov 1 20:52:31 hame kernel: [<c01f3394>] kref_get+0x3d/0x3f Nov 1 20:52:31 hame kernel: [<c01f2b8f>] kobject_get+0xf/0x13 Nov 1 20:52:31 hame kernel: [<c027b2db>] class_get+0xe/0x1e Nov 1 20:52:31 hame kernel: [<c027b9ef>]<6>ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 17 Nov 1 20:52:31 hame kernel: nvidiafb: nVidia device/chipset 10DE0322 Nov 1 20:52:31 hame kernel: class_device_add+0x3c/0x210 Nov 1 20:52:31 hame kernel: [<c01f2b8f>] kobject_get+0xf/0x13 Nov 1 20:52:31 hame kernel: [<c01f295d>] kobject_init+0x23/0x36 Nov 1 20:52:31 hame kernel: [<c027e6e0>] fw_register_class_device+0xfe/0x12d Nov 1 20:52:31 hame kernel: [<c027e730>] fw_setup_class_device+0x21/0xca Nov 1 20:52:31 hame kernel: [<c027e82c>] _request_firmware+0x53/0x180 Nov 1 20:52:31 hame kernel: [<c027e968>] request_firmware+0xf/0x13 Nov 1 20:52:31 hame kernel: [<c0222af6>] speedtch_find_firmware+0x54/0x130 Nov 1 20:52:31 hame kernel: [<c0222bed>] speedtch_heavy_init+0x1b/0x5f Nov 1 20:52:31 hame kernel: [<c02247b7>] usbatm_do_heavy_init+0x32/0x69 Nov 1 20:52:31 hame kernel: [<c0224785>] usbatm_do_heavy_init+0x0/0x69 Nov 1 20:52:31 hame kernel: [<c0101099>] kernel_thread_helper+0x5/0xb Nov 1 20:52:31 hame kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000000c Nov 1 20:52:31 hame kernel: printing eip: Nov 1 20:52:31 hame kernel: c017d34a Nov 1 20:52:31 hame kernel: *pde = 00000000 Nov 1 20:52:31 hame kernel: Oops: 0000 [#1] Nov 1 20:52:31 hame kernel: SMP Nov 1 20:52:31 hame kernel: CPU: 0 Nov 1 20:52:31 hame kernel: EIP: 0060:[<c017d34a>] Not tainted VLI Nov 1 20:52:31 hame kernel: EFLAGS: 00010286 (2.6.14-git4) Nov 1 20:52:31 hame kernel: EIP is at create_dir+0xd/0x16e Nov 1 20:52:31 hame kernel: eax: dff0e988 ebx: dff0e988 ecx: dff0e98c edx: 00000000 Nov 1 20:52:31 hame kernel: esi: dff0e98c edi: c045a6bc ebp: 00000000 esp: dfc8be90 Nov 1 20:52:31 hame kernel: ds: 007b es: 007b ss: 0068 Nov 1 20:52:31 hame kernel: Process speedtch (pid: 215, threadinfo�c8a000 task�5ee530) Nov 1 20:52:31 hame kernel: Stack: 00000000 ffffffff ffffffff dff0e988 00000000 c045a6bc c045a6a0 c017d4ef Nov 1 20:52:31 hame kernel: dfc8beb4 00000000 dff0e988 c01f2841 dff0e988 fffffffe c01f2a03 dff0e9f0 Nov 1 20:52:31 hame kernel: dff0e980 00000000 c027ba35 dff0e988 c0418099 dff0e9f0 dff0e988 c01f295d Nov 1 20:52:31 hame kernel: Call Trace: Nov 1 20:52:31 hame kernel: [<c017d4ef>] sysfs_create_dir+0x2c/0x66 Nov 1 20:52:31 hame kernel: [<c01f2841>] create_dir+0x13/0x37 Nov 1 20:52:31 hame kernel: [<c01f2a03>] kobject_add+0x5e/0x98 Nov 1 20:52:31 hame kernel: [<c027ba35>] class_device_add+0x82/0x210 Nov 1 20:52:31 hame kernel: [<c01f295d>] kobject_init+0x23/0x36 Nov 1 20:52:31 hame kernel: [<c027e6e0>] fw_register_class_device+0xfe/0x12d Nov 1 20:52:31 hame kernel: [<c027e730>] fw_setup_class_device+0x21/0xca Nov 1 20:52:31 hame kernel: [<c027e82c>] _request_firmware+0x53/0x180 Nov 1 20:52:31 hame kernel: [<c027e968>] request_firmware+0xf/0x13 Nov 1 20:52:31 hame kernel: [<c0222af6>] speedtch_find_firmware+0x54/0x130 Nov 1 20:52:31 hame kernel: [<c0222bed>] speedtch_heavy_init+0x1b/0x5f Nov 1 20:52:31 hame kernel: [<c02247b7>] usbatm_do_heavy_init+0x32/0x69 Nov 1 20:52:31 hame kernel: [<c0224785>] usbatm_do_heavy_init+0x0/0x69 Nov 1 20:52:31 hame kernel: [<c0101099>] kernel_thread_helper+0x5/0xb Nov 1 20:52:31 hame kernel: Code: 00 00 00 00 c7 80 9c 00 00 00 00 6c 44 c0 31 c0 c3 c7 80 98 00 00 00 a0 6d 44 c0 31 c0 c3 55 57 56 53 83 ec 0c 89 c3 89 d5 89 ce <8b> 52 0c f0 ff 4a 74 0f 88 7c 0b 00 00 31 c0 b9 ff ff ff ff 89
But at least it boots.
All my attempts to build an initramfs into the kernel end in Kernel panic:( Andy
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 11 lines · Andrew Benton
Quoted 3 lines · Alexander E. Patrakov
Details for firmware-loading initramfs (untested, since none of my devices generate firmware hotplug events):
<snip>Hi Alexander,
thanks for taking the time to type such a long message. Unfortunately it isn't working. It boots OK but the firmware doesn't load and I get some rather ominous messages in the sys.log
Then it looks like the idea of mounting /sys inside the hotplug helper (before /init starts) is currently bad. This definitely needs investigation, because otherwise timeouts happen in firmware loading.
Could you please check that a simple /init-only initramfs (i.e. without the hotplug handler) doesn't crash for you? Take the /init file from my previous mail and replace the vgchange with something like "echo we are in initramfs", in order to really see that initramfs is activated.
Signature · 12 lines
Alexander E. Patrakov ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines · I wrote:
The
/sbin/hotplugscript should contain the following:#!/bin/sh
[ "$1" != "firmware" ] || [ "$ACTION" != "add" ] || [ ! -f "/lib/firmware/$FIRMWARE" ] || exit 0
The first term probably should be [ "$SUBSYSTEM" != "firmware" ], sorry.
Signature · 12 lines
Alexander E. Patrakov ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines · I wrote:
The
/sbin/hotplugscript should contain the following:#!/bin/sh
[ "$1" != "firmware" ] || [ "$ACTION" != "add" ] || [ ! -f "/lib/firmware/$FIRMWARE" ] || exit 0
This was wrong, sorry. Should be:
[ "$SUBSYSTEM" != "firmware" ] || [ "$ACTION" != "add" ] || [ ! -f "/lib/firmware/$FIRMWARE" ] && exit 0
Signature · 12 lines
Alexander E. Patrakov ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · Alexander E. Patrakov
Quoted 3 lines · I wrote:
The
/sbin/hotplugscript should contain the following:
Quoted 9 lines
Quoted 3 lines
#!/bin/sh
[ "$1" != "firmware" ] || [ "$ACTION" != "add" ] || [ ! -f "/lib/firmware/$FIRMWARE" ] || exit 0This was wrong, sorry. Should be:
[ "$SUBSYSTEM" != "firmware" ] || [ "$ACTION" != "add" ] || [ ! -f "
/lib/firmware/$FIRMWARE" ] && exit 0
It doesn't matter, it makes no difference, the kernel seems to just ignore the initrd and boot as normal. The error I posted from the logs is there whether I use the initrd or not. I did look for errors before, but not very well so I didn't notice it (sorry).
I don't have any more time to waste working on this initramfs nonsense at the moment. I may return to it later if nothing else turns up, but I don't want to. I don't see why the kernel can't wait until userspace has been mounted before it tries to load the firmware. Andy
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 1 line
... I don't see why the kernel can't wait until userspace has been mounted before it tries to load the firmware.
Me neither. I mean, why do coldplugging of all devices (rather than just an essential few) before the root filesystem is mounted?
D.
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines · Duncan Sands
Quoted 3 lines
... I don't see why the kernel can't wait until userspace has been mounted before it tries to load the firmware.
Me neither. I mean, why do coldplugging of all devices (rather than just an essential few) before the root filesystem is mounted?
Please propose how are you going to tell the kernel the list of "essential" devices.
Signature · 12 lines
Alexander E. Patrakov ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines · Alexander E. Patrakov
Quoted 4 lines · Duncan Sands
Quoted 3 lines
... I don't see why the kernel can't wait until userspace has been mounted before it tries to load the firmware.
Quoted 6 lines
Quoted 4 lines
Me neither. I mean, why do coldplugging of all devices (rather than just an essential few) before the root filesystem is mounted?
Please propose how are you going to tell the kernel the list of "essential" devices.
Hopefully the list of essential devices needing coldplugging is empty. I had in mind:
just what's needed to mount the root filesystem. What's the problem with that?
D.
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 18 lines · Duncan Sands
Quoted 15 lines · Alexander E. Patrakov
Quoted 11 lines · Duncan Sands
Quoted 5 lines
... I don't see why the kernel can't wait until userspace has been mounted before it tries to load the firmware.
Me neither. I mean, why do coldplugging of all devices (rather than just an essential few) before the root filesystem is mounted?
Quoted 9 lines
Quoted 4 lines
Please propose how are you going to tell the kernel the list of "essential" devices.
Hopefully the list of essential devices needing coldplugging is empty. I had in mind:
just what's needed to mount the root filesystem. What's the problem with that?
E.g., you want to specify that only /dev/sda is needed because you have your root filesystem on your SCSI disk. But your SCSI controller is a PCI device. So we need to walk over all PCI devices and bind drivers to them. One of them will register itself as a SCSI controller driver. But all PCI devices before that one will also be initialized then, and may (or may not) want firmware or other initialization!
And now suppose that after hardware upgrade your PCI cards were shuffled, how would you handle that?
Signature · 12 lines
Alexander E. Patrakov ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 11 lines · Alexander E. Patrakov
Quoted 11 lines
Quoted 4 lines
Please propose how are you going to tell the kernel the list of "essential" devices.
Hopefully the list of essential devices needing coldplugging is empty. I had in mind:
just what's needed to mount the root filesystem. What's the problem with that?
Quoted 6 lines
E.g., you want to specify that only
/dev/sdais needed because you have your root filesystem on your SCSI disk. But your SCSI controller is a PCI device. So we need to walk over all PCI devices and bind drivers to them. One of them will register itself as a SCSI controller driver. But all PCI devices before that one will also be initialized then, and may (or may not) want firmware or other initialization!
So the proposed (or current?) hotplug firmware interface can block other PCI (or other) devices from binding?
-- Patrick Mansfield
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 4 lines · Patrick Mansfield
So the proposed (or current?) hotplug firmware interface can block other PCI (or other) devices from binding?
I am not sure what exactly you mean. Attempting to answer anyway for the current firmware implementation.
For an experiment, I created a simple "driver" for a PCI device, that only calls request_firmware() in its probe() function and does nothing else. I built this driver as a non-module and booted the resulting kernel.
The boot process was indeed delayed by 10 seconds while this driver waited for its "firmware". After that delay, the kernel proceeded as usual. If I provide the "firmware" in initramfs, no delay occurs.
Looks like this problem (calling request_firmware() from probe() and the associated useless delay) does exist in the current drivers/char/isicom.c file. This problem can be "solved" by not calling request_firmware() in the probe() function of a PCI driver. E.g., drivers for wireless cards call request_firmware() only when they actually want to reset the card.
Note that all of the above is for PCI drivers. USB may be different.
The preferred solution for the future seems to be the conversion to request_firmware_nowait() which doesn't sleep. However, the only driver in 2.6.14-mm1 actually using this function is drivers/firmware/dell_rbu.c.
Signature · 12 lines
Alexander E. Patrakov ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines · Alexander E. Patrakov
The preferred solution for the future seems to be the conversion to
request_firmware_nowait()which doesn't sleep. However, the only driver in 2.6.14-mm1 actually using this function isdrivers/firmware/dell_rbu.c.
Yes, that is the proper solution, all uses of the request_firmware() call should go away, and I'm trying to prevent any new uses of that call from going into the kernel tree.
Delaying 10 seconds in the probe() callback is not acceptable.
thanks,
greg k-h
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 9 lines · Alexander E. Patrakov
Quoted 4 lines · Patrick Mansfield
So the proposed (or current?) hotplug firmware interface can block other PCI (or other) devices from binding?
I am not sure what exactly you mean. Attempting to answer anyway for the current firmware implementation.
Quoted 7 lines
For an experiment, I created a simple "driver" for a PCI device, that only calls
request_firmware()in itsprobe()function and does nothing else. I built this driver as a non-module and booted the resulting kernel.The boot process was indeed delayed by 10 seconds while this driver waited for its "firmware". After that delay, the kernel proceeded as usual. If I provide the "firmware" in initramfs, no delay occurs.
Thanks, I was wondering what happens in the above scenario, that and Greg's email explain it.
-- Parick Mansfield
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel