Make prepare_namespace() wait for devices
RFC PATCH 1/1 Make prepare_namespace() wait for devices
Testing and/or comments welcome.
Signature · 5 lines
-- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org
commit 7c542a5a027caa95bb00f8a8223c7e4aef88c931
Author: Pierre Ossman <[email protected]> Date: Mon May 14 14:15:46 2007 +0200
init: wait for asynchronously scanned block devices
Some buses (e.g. USB and MMC) do their scanning of devices in the background, causing a race between them and prepare_namespace(). In order to be able to use these buses without an initrd, we now wait for the device specified in root= to actually show up.
If the device never shows up than we will hang in an infinite loop. Previously we panic:ed instead, so this behaviour should be no worse.
init/do_mounts.c +15 -2
@@ -438,11 +438,24 @@ void __init prepare_namespace(void) root_device_name +=5 ; } - is_floppy =MAJOR (ROOT_DEV ) ==FLOPPY_MAJOR ; -if (initrd_load ()) goto out; +/* wait for any asynchronous scanning to complete */ +if (ROOT_DEV ==0 ) { +printk ("Waiting for root device %s...\n" , saved_root_name); +do { +while (driver_probe_done () !=0 ) +msleep (100 ); +ROOT_DEV =name_to_dev_t (saved_root_name); +if (ROOT_DEV ==0 ) +msleep (100 ); + }while (ROOT_DEV ==0 ); + } + + is_floppy =MAJOR (ROOT_DEV ) ==FLOPPY_MAJOR ; + +if (is_floppy && rd_doload &&rd_load_disk (0 ))ROOT_DEV = Root_RAM0;
On Mon, May 14, 2007 at 02:19:37PM +0200, Pierre Ossman wrote:
First of all, please do not put patches in attachments.
As for the patch, an infinite loop is *much* worse than a panic. When one is installing a new kernel on remote box, having it booted with reboot on panic and loader falling back to old kernel on the next boot is a bloody good idea - gives you extra safety. With your patch it will get the box stuck.
Quoted 5 lines · Al Viro
On Mon, May 14, 2007 at 02:19:37PM +0200, Pierre Ossman wrote:
First of all, please do not put patches in attachments.
My mailer tends to fsck them up if I just paste them. And it's attached without any base64 silliness, so most people can usually read it directly.
Quoted 6 lines
As for the patch, an infinite loop is *much* worse than a panic. When one is installing a new kernel on remote box, having it booted with reboot on panic and loader falling back to old kernel on the next boot is a bloody good idea - gives you extra safety. With your patch it will get the box stuck.
Ok. So a timeout or having the entire thing Kconfig optional?
Rgds
Signature · 5 lines
-- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org
Quoted 8 lines · On Mon, 14 May 2007 15:56:15 +0200 Pierre Ossman <[email protected]> wrote:
Quoted 6 lines
As for the patch, an infinite loop is *much* worse than a panic. When one is installing a new kernel on remote box, having it booted with reboot on panic and loader falling back to old kernel on the next boot is a bloody good idea - gives you extra safety. With your patch it will get the box stuck.
Ok. So a timeout or having the entire thing
Kconfigoptional?
How about command-line optional?
Haavard
RFC PATCH 1/1 Make prepare_namespace() wait for devices (v2)
New suggestion.
Signature · 5 lines
-- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org
commit bb8c44ee8b4d584295add58a4ea2f03b9938fc3c
Author: Pierre Ossman <[email protected]> Date: Mon May 14 14:15:46 2007 +0200
init: wait for asynchronously scanned block devices
Some buses (e.g. USB and MMC) do their scanning of devices in the background, causing a race between them and prepare_namespace(). In order to be able to use these buses without an initrd, we now wait for the device specified in root= to actually show up.
If the device never shows up than we will hang in an infinite loop. In order to not mess with setups that reboot on panic, the feature must be turned on via the command line option "rootwait".
init/do_mounts.c +24 -2
@@ -25,6 +25,7 @@ int __initdata rd_doload; /* 1 = load RAM disk, 0 = don't load */int root_mountflags =MS_RDONLY |MS_SILENT ;char *__initdata root_device_name;static char __initdata saved_root_name[64 ]; +int __initdata root_wait;dev_t ROOT_DEV ;
@@ -216,6 +217,14 @@ static int __init root_dev_setup(char *line)__setup ("root=" , root_dev_setup); +static int __init rootwait_setup (char *line) +{ + root_wait =simple_strtol (line,NULL ,0 ); +return 1 ; +} + +__setup ("rootwait=" , rootwait_setup); +static char *__initdata root_mount_data;static int __init root_data_setup (char *str) {
@@ -438,11 +447,24 @@ void __init prepare_namespace(void) root_device_name +=5 ; } - is_floppy =MAJOR (ROOT_DEV ) ==FLOPPY_MAJOR ; -if (initrd_load ()) goto out; +/* wait for any asynchronous scanning to complete */ +if ((ROOT_DEV ==0 ) && root_wait) { +printk (KERN_INFO "Waiting for root device %s...\n" , + saved_root_name); +do { +while (driver_probe_done () !=0 ) +msleep (100 ); +ROOT_DEV =name_to_dev_t (saved_root_name); +if (ROOT_DEV ==0 ) +msleep (100 ); + }while (ROOT_DEV ==0 ); + } + + is_floppy =MAJOR (ROOT_DEV ) ==FLOPPY_MAJOR ; +if (is_floppy && rd_doload &&rd_load_disk (0 ))ROOT_DEV = Root_RAM0;
Re: [RFC][PATCH] Make prepare_namespace() wait for devices (v2)
Quoted 1 line · On Mon, 14 May 2007 17:18:06 +0200 Pierre Ossman <[email protected]> wrote:
New suggestion.
Works wonderfully here:
Waiting for root device /dev/mmcblk0p1...
<inserts card>
mmcblk0: mmc0:a95c SD128 123008KiB
mmcblk0: p1
VFS: Mounted root (ext2 filesystem).
Of course, it also fixes the case where the card _is_ inserted at bootup :-)
Haavard
Re: [RFC][PATCH] Make prepare_namespace() wait for devices (v2)
Quoted 7 lines · Haavard Skinnemoen
Quoted 1 line · On Mon, 14 May 2007 17:18:06 +0200 Pierre Ossman <[email protected]> wrote:
New suggestion.
Works wonderfully here:
Quoted 8 lines
Waiting for root device
/dev/mmcblk0p1...
<inserts card>
mmcblk0: mmc0:a95c SD128 123008KiB
mmcblk0: p1
VFS: Mounted root (ext2 filesystem).Of course, it also fixes the case where the card _is_ inserted at bootup :-)
Seconded. Love your work Pierre :)
Tested across 4 different brands of SD/MMC/RS-MMC card and 2 different configurations (both AVR32 arch) just for the hells of it. All plays nice.
Thanks,
--Ben.
Quoted 4 lines · Pierre Ossman
If the device never shows up than we will hang in an infinite loop. Previously we panic:ed instead, so this behaviour should be no worse.
Actually that's not correct. With panic=30 and lilo -R and a working backup kernel a system can recover from this. With your endless loop it can't.
Always add some kind of timeout.
-Andi
Hi there brave visitor from the future ;)
Quoted 6 lines · Andi Kleen
Actually that's not correct. With panic=30 and lilo -R and a working backup kernel a system can recover from this. With your endless loop it can't.
Always add some kind of timeout.
Did you check the second version? Is that sufficient or is a timeout a must in your book?
Rgds
Signature · 5 lines
-- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org