Since I own a USB Pen Drive, which is perfectly working under Linux, I
wanted to put a linux rescue system on it. But for some reason it wont
work.
I linked in everything neccesary to boot from it: CONFIG_USB,
CONFIG_USB_DEVICEFS, CONFIG_USB_UHCI, CONFIG_USB_STORAGE, CONFIG_SCSI,
CONFIG_BLK_DEV_SD, CONFIG_EXT2_FS. I'm using kernel 2.4.15-pre4.
The problem is that the pendrive gets detected AFTER the kernel tries to
mount the root fs. Checking init/main.c and entering some debug lines
learns that the USB device gets detected when, in function init(), the
console gets opened: 'open("/dev/console", O_RDWR, 0)'. Immediately after
that, the 'init' program will be exec-ed. At the time of the 'open()'
call, the kernel printk()'s "hub.c: USB new device connect on bus1/1,
assigned device number 2", which is obviously the pendrive. It is
correctly registered, and a SCSI disk is emulated. But too late..
Does anybody have a clue as to what the USB bus has to do with
/dev/console?
Thanks for any help,
Jos Nouwen.
On Thu, Nov 15, 2001 at 04:22:33AM +0100, Jos Nouwen wrote:
>
> Does anybody have a clue as to what the USB bus has to do with
> /dev/console?
It's a timing issue, and has nothing to do with /dev/console. If you
sit and spin before you try to mount the root fs, the USB subsystem will
have enough time to find the drive. There's a few patches that do this
in the lkml archives.
thanks,
greg k-h
On Wed, 14 Nov 2001, Greg KH wrote:
> On Thu, Nov 15, 2001 at 04:22:33AM +0100, Jos Nouwen wrote:
> >
> > Does anybody have a clue as to what the USB bus has to do with
> > /dev/console?
>
> It's a timing issue, and has nothing to do with /dev/console. If you
> sit and spin before you try to mount the root fs, the USB subsystem will
> have enough time to find the drive. There's a few patches that do this
> in the lkml archives.
>
> thanks,
>
> greg k-h
It does not seem so. I included several seconds of mdelay() (and lots of
printk()'s) while I was debugging, and that didnt change a thing. I added
a.o. 4 seconds of mdelay() right before the open(), and 2 seconds right
after the open() and the two dup()'s. The storage device was detected at
the beginning of that last delay. Me thinks this is related to the open().
I added a total of 10 seconds of mdelay() between do_basic_setup() (where
the usb is initialized) and the open(). That is much more time than it
takes to init the USB storage device.
> > > Does anybody have a clue as to what the USB bus has to do with
> > > /dev/console?
> >
> > It's a timing issue, and has nothing to do with /dev/console. If you
> > sit and spin before you try to mount the root fs, the USB subsystem will
> > have enough time to find the drive. There's a few patches that do this
> > in the lkml archives.
> >
> > greg k-h
>
> It does not seem so. I included several seconds of mdelay() (and lots of
> printk()'s) while I was debugging, and that didnt change a thing. I added
> a.o. 4 seconds of mdelay() right before the open(), and 2 seconds right
> after the open() and the two dup()'s. The storage device was detected at
> the beginning of that last delay. [...]
I think khubd needs to run to complete whole process and mdelay()
locks it out. You need something that calls schedule() for USB
detection to work. Try to use schedule_timeout() instead of mdelay().
-- Pete
On Thu, 15 Nov 2001, Pete Zaitcev wrote:
> I think khubd needs to run to complete whole process and mdelay()
> locks it out. You need something that calls schedule() for USB
> detection to work. Try to use schedule_timeout() instead of mdelay().
This patch works for me.
Eric
--- linux-2.4.14-pre8-ext3/fs/super.c.orig Fri Nov 16 00:59:18 2001
+++ linux-2.4.14-pre8-ext3/fs/super.c Fri Nov 16 01:07:26 2001
@@ -1009,11 +1009,13 @@
* Allow the user to distinguish between failed open
* and bad superblock on root device.
*/
- printk ("VFS: Cannot open root device \"%s\" or %s\n",
+ printk ("VFS: Cannot open root device \"%s\" or %s, retrying in 1s.\n",
root_device_name, kdevname (ROOT_DEV));
- printk ("Please append a correct \"root=\" boot option\n");
- panic("VFS: Unable to mount root fs on %s",
- kdevname(ROOT_DEV));
+
+ /* wait 1 second and try again */
+ current->state = TASK_INTERRUPTIBLE;
+ schedule_timeout(HZ);
+ goto retry;
}
check_disk_change(ROOT_DEV);
> Date: Fri, 16 Nov 2001 14:21:04 +0100 (CET)
> From: Eric Lammerts <[email protected]>
> To: Pete Zaitcev <[email protected]>
> cc: [email protected], Greg KH <[email protected]>,
> <[email protected]>
> > I think khubd needs to run to complete whole process and mdelay()
> > locks it out. You need something that calls schedule() for USB
> > detection to work. Try to use schedule_timeout() instead of mdelay().
>
> This patch works for me.
Looks like a well done patch but what does happen if root= was
indeed incorrect? I wish there was a way to print something
meaningful for the operator.
-- Pete
P.S. - quoting the patch, saved for future reference
> --- linux-2.4.14-pre8-ext3/fs/super.c.orig Fri Nov 16 00:59:18 2001
> +++ linux-2.4.14-pre8-ext3/fs/super.c Fri Nov 16 01:07:26 2001
> @@ -1009,11 +1009,13 @@
> * Allow the user to distinguish between failed open
> * and bad superblock on root device.
> */
> - printk ("VFS: Cannot open root device \"%s\" or %s\n",
> + printk ("VFS: Cannot open root device \"%s\" or %s, retrying in 1s.\n",
> root_device_name, kdevname (ROOT_DEV));
> - printk ("Please append a correct \"root=\" boot option\n");
> - panic("VFS: Unable to mount root fs on %s",
> - kdevname(ROOT_DEV));
> +
> + /* wait 1 second and try again */
> + current->state = TASK_INTERRUPTIBLE;
> + schedule_timeout(HZ);
> + goto retry;
> }
>
> check_disk_change(ROOT_DEV);