Kernel Firmware Loading

Kernel Firmware Loading

[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_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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Alexander E. Patrakov]

Andrew Benton wrote:
> 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.

Create an initramfs and load firmware from there.

-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Andrew Benton]

Alexander E. Patrakov wrote:
> 
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[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.

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Alexander E. Patrakov]

You wrote:
> Alexander E. Patrakov wrote:
> > 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).

-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Marco d'Itri]

On Oct 31, Duncan Sands <duncan.sands@math.u-psud.fr> wrote:

> 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.

> 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.

-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Duncan Sands]

Hi Marco,

> > 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!

> > 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Marco d'Itri]

On Oct 31, Duncan Sands <duncan.sands@math.u-psud.fr> wrote:

> 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.

-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Kay Sievers]

On Mon, Oct 31, 2005 at 11:59:05AM +0100, Duncan Sands wrote:
> 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.

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Duncan Sands]

Hi Kay,

On Monday 31 October 2005 14:10, Kay Sievers wrote:
> On Mon, Oct 31, 2005 at 11:59:05AM +0100, Duncan Sands wrote:
> > 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.
> 
> 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.

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.

> 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...

> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Kay Sievers]

On Mon, Oct 31, 2005 at 02:27:35PM +0100, Duncan Sands wrote:
> On Monday 31 October 2005 14:10, Kay Sievers wrote:
> > On Mon, Oct 31, 2005 at 11:59:05AM +0100, Duncan Sands wrote:
> > > 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.
> > 
> > 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.
> 
> 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.
> 
> > 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Duncan Sands]

> > > 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Kay Sievers]

On Mon, Oct 31, 2005 at 03:41:59PM +0100, Duncan Sands wrote:
> > > > 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?

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...

> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[linas]

(Offtopic)

On Mon, Oct 31, 2005 at 12:08:52PM +0100, Marco d'Itri was heard to remark:
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

On Oct 31, linas <linas@austin.ibm.com> wrote:

> 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.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Kernel Firmware Loading

[Andrew Benton]

Duncan Sands wrote:
> Hi Marco,
> 
>>> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Duncan Sands]

> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Andrew Benton]

Duncan Sands wrote:
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Alexander E. Patrakov]

Andrew Benton wrote:

> 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...and what 
> 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"
                        ;;
        esac
done

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.

-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[linas]

On Mon, Oct 31, 2005 at 05:33:29PM +0100, Marco d'Itri was heard to remark:
> On Oct 31, linas <linas@austin.ibm.com> wrote:
> 
> > 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Andrew Benton]

Alexander E. Patrakov wrote:
> 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, threadinfoflc8a000 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Alexander E. Patrakov]

Andrew Benton wrote:

> Alexander E. Patrakov wrote:
>
>> 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.

-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Alexander E. Patrakov]

I wrote:

>
> The /sbin/hotplug script 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.

-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Alexander E. Patrakov]

I wrote:

>
> The /sbin/hotplug script 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

-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Andrew Benton]

Alexander E. Patrakov wrote:
> I wrote:
> 
>>
>> The /sbin/hotplug script 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
> 

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Duncan Sands]

> ... 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Alexander E. Patrakov]

Duncan Sands wrote:

>>... 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.

-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Duncan Sands]

On Friday 4 November 2005 15:46, Alexander E. Patrakov wrote:
> Duncan Sands wrote:
> 
> >>... 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.

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Alexander E. Patrakov]

Duncan Sands wrote:

>On Friday 4 November 2005 15:46, Alexander E. Patrakov wrote:
>  
>
>>Duncan Sands wrote:
>>
>>    
>>
>>>>... 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.
>>    
>>
>
>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?

-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Patrick Mansfield]

On Fri, Nov 04, 2005 at 08:14:40PM +0500, Alexander E. Patrakov wrote:

> >>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!

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Alexander E. Patrakov]

Patrick Mansfield wrote:

>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.

-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Greg KH]

On Tue, Nov 08, 2005 at 01:16:25PM +0500, Alexander E. Patrakov wrote:
> 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.

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Kernel Firmware Loading

[Patrick Mansfield]

On Tue, Nov 08, 2005 at 01:16:25PM +0500, Alexander E. Patrakov wrote:
> Patrick Mansfield wrote:
> 
> >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.

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel