I recently acquired a USB HardDisk and it seems that the drivers for USB
load after attempts to mount the root partition. I saw one patch that
just put the root mount code into an endless loop, but didn't like this
solution.
What I've done here is add another kernel config option which indicates
if you have a USB device you with to boot. If you do then it changes
the module_init's in drivers/usb/usb.c and drivers/usb/storage/usb.c to
__initcall's. The config option is only enabled when you've selected
"Y" for the USB Mass Storage Device.
My tests show that it seems to work, and I haven't noticed any odd side
affects by initcall-ing the usb devices (concern over this topic is why
I enabled it for static USB MSD only).
Does this seem a reasonable solution, or does anyone have something more
elegant?
-- Wes
On Thu, 2003-01-30 at 17:27, Wesley Wright wrote:
> My tests show that it seems to work, and I haven't noticed any odd side
> affects by initcall-ing the usb devices (concern over this topic is why
> I enabled it for static USB MSD only).
>
> Does this seem a reasonable solution, or does anyone have something more
> elegant?
Is there a reason for not using initrd for this. That should let you
use any kind of root device even ones requiring user space work before
the real root is mounted.
Alan Cox wrote:
>On Thu, 2003-01-30 at 17:27, Wesley Wright wrote:
>
>
>>My tests show that it seems to work, and I haven't noticed any odd side
>>affects by initcall-ing the usb devices (concern over this topic is why
>>I enabled it for static USB MSD only).
>>
>>Does this seem a reasonable solution, or does anyone have something more
>>elegant?
>>
>>
>
>Is there a reason for not using initrd for this. That should let you
>use any kind of root device even ones requiring user space work before
>the real root is mounted.
>
>
The problem I've seen is there is a several second delay before the
usb device is availble. My solution was to stick a sleep in my initrd
before attempting to mount /. A more rational patch might be to retry
mounting / after a few seconds delay before giving up. I think I saw
patch doing this on the usb list.
--
There is no such thing as obsolete hardware.
Merely hardware that other people don't want.
(The Second Rule of Hardware Acquisition)
Sam Flory <[email protected]>
> > My tests show that it seems to work, and I haven't noticed any odd side
> > affects by initcall-ing the usb devices (concern over this topic is why
> > I enabled it for static USB MSD only).
> >
> > Does this seem a reasonable solution, or does anyone have something more
> > elegant?
>
> Is there a reason for not using initrd for this. That should let you
> use any kind of root device even ones requiring user space work before
> the real root is mounted.
Yes, I believe there is. IMO initrd is too much of an annoyance to setup.
I also have a usb hdd and the only thing I did was read from the keyboard
waiting for an <ENTER> like it does when it waits on the floppy. Worked
quite well for me and USB Hard disks don't really need user space if
everything's compiled in (from what I've seen).
--
Lab tests show that use of micro$oft causes cancer in lab animals
>> Is there a reason for not using initrd for this. That should let you
>> use any kind of root device even ones requiring user space work before
>> the real root is mounted.
>
> Yes, I believe there is. IMO initrd is too much of an annoyance to setup.
I believe it's going to be mandatory anyway, perhaps not as initrd,
but as initfs, but the result is the same. Besides, it's not
that big a deal if rpm -i makes initrd for you automagically.
-- Pete
On Thu, Jan 30, 2003 at 02:35:01PM -0800, Samuel Flory wrote:
> The problem I've seen is there is a several second delay before the
> usb device is availble. My solution was to stick a sleep in my initrd
> before attempting to mount /. A more rational patch might be to retry
> mounting / after a few seconds delay before giving up. I think I saw
> patch doing this on the usb list.
Hello !
I'm personnaly using this simple patch with success with an usb disk on
key. It adds an option "setuptime" which waits the requested amount of ms
before booting. I use it with "setuptime=2500" and my USB works fine.
I think it could be of a more general use, and perhaps it could be
accepted into mainstream if it doesn't break anything ?
Cheers,
Willy
--- linux-21pre/init/main.c Sat Dec 21 16:53:09 2002
+++ linux-21pre-usb/init/main.c Sat Dec 21 17:35:50 2002
@@ -126,6 +126,7 @@
static char * argv_init[MAX_INIT_ARGS+2] = { "init", NULL, };
char * envp_init[MAX_INIT_ENVS+2] = { "HOME=/", "TERM=linux", NULL, };
+static int setuptime; /* time(ms) to let devices set up before root mount */
static int __init profile_setup(char *str)
{
@@ -136,6 +137,15 @@
__setup("profile=", profile_setup);
+static int __init setuptime_setup(char *str)
+{
+ int par;
+ if (get_option(&str,&par)) setuptime = par;
+ return 1;
+}
+
+__setup("setuptime=", setuptime_setup);
+
static int __init checksetup(char *line)
{
struct kernel_param *p;
@@ -546,11 +556,25 @@
extern void prepare_namespace(void);
+static int finish_setup()
+{
+ int tleft;
+ if (setuptime) {
+ printk("Waiting %d ms for devices to set up.\n", setuptime);
+ tleft = setuptime * HZ / 1000;
+ while (tleft) {
+ set_current_state(TASK_INTERRUPTIBLE);
+ tleft = schedule_timeout(tleft);
+ }
+ }
+}
+
static int init(void * unused)
{
lock_kernel();
do_basic_setup();
+ finish_setup();
prepare_namespace();
/*
> I'm personnaly using this simple patch with success with an usb disk on
> key. It adds an option "setuptime" which waits the requested amount of ms
> before booting. I use it with "setuptime=2500" and my USB works fine.
>
> I think it could be of a more general use, and perhaps it could be
> accepted into mainstream if it doesn't break anything ?
The reason I took the other approach is that I didn't want to introduce
an arbitrary delay into my startup. I have varying speed machines
(ranging from P90 up to Athlon 1800) and wanted a solution consistent
across all of them. I think that you can accomplish the delay startup
through initrd without a kernel change.
Delay solutions don't directly deal with the race between mounting and
detecting the USB device though. If I select a value to small then I
still don't get a successful mount.
Maybe this isn't a major concern for this area of the kernel though...
at this point there really aren't any other tasks so the delay should
have very consistent results.
Thanks,
-- Wes