sleep before boot panic

sleep before boot panic

[Bernd Schubert]

Hi,

I just switched to libata (pata) on my laptop and the immediate panic made it 
impossible to figure out why my boot partition wasn't available.
After applying this little patch I could check boot printk output and then saw 
everything was properly recognized and only scsi-disk support was missing.


Signed-off-by: Bernd Schubert <bernd-schubert@gmx.de>

Index: zd1211rw.git.beno/init/do_mounts.c
===================================================================
--- zd1211rw.git.beno.orig/init/do_mounts.c	2008-01-06 18:44:23.000000000 
+0100
+++ zd1211rw.git.beno/init/do_mounts.c	2008-01-06 18:45:44.000000000 +0100
@@ -330,6 +330,7 @@
 		printk("Please append a correct \"root=\" boot option; here are the 
available partitions:\n");
 
 		printk_all_partitions();
+		msleep(60 * 1000);
 		panic("VFS: Unable to mount root fs on %s", b);
 	}
 


Cheers,
Bernd

Re: sleep before boot panic

[Ingo Oeser]

Hi Bernd,

On Sunday 06 January 2008, you wrote:
> Index: zd1211rw.git.beno/init/do_mounts.c
> ===================================================================
> --- zd1211rw.git.beno.orig/init/do_mounts.c	2008-01-06 18:44:23.000000000 
> +0100
> +++ zd1211rw.git.beno/init/do_mounts.c	2008-01-06 18:45:44.000000000 +0100
> @@ -330,6 +330,7 @@
>  		printk("Please append a correct \"root=\" boot option; here are the 
> available partitions:\n");
>  
>  		printk_all_partitions();
> +		msleep(60 * 1000);

ssleep(60);

>  		panic("VFS: Unable to mount root fs on %s", b);
>  	}

Better would be for this and similiar panic()s
(fatal user/admin errors on boot) to NOT print a stack trace+registers,
since it is useless and actually hides useful information.


Best Regards

Ingo Oeser

Re: sleep before boot panic

[Bernd Schubert]

Hello Ingo,

On Sunday 06 January 2008, Ingo Oeser wrote:
> Hi Bernd,
>
> On Sunday 06 January 2008, you wrote:
> > Index: zd1211rw.git.beno/init/do_mounts.c
> > ===================================================================
> > --- zd1211rw.git.beno.orig/init/do_mounts.c	2008-01-06 18:44:23.000000000
> > +0100
> > +++ zd1211rw.git.beno/init/do_mounts.c	2008-01-06 18:45:44.000000000
> > +0100 @@ -330,6 +330,7 @@
> >  		printk("Please append a correct \"root=\" boot option; here are the
> > available partitions:\n");
> >
> >  		printk_all_partitions();
> > +		msleep(60 * 1000);
>
> ssleep(60);

feel free to replace it replace it :)

>
> >  		panic("VFS: Unable to mount root fs on %s", b);
> >  	}
>
> Better would be for this and similiar panic()s
> (fatal user/admin errors on boot) to NOT print a stack trace+registers,
> since it is useless and actually hides useful information.

There is no dump_stack() here, but disc detection is relatively early in boot 
process and on all these information are already scrolled off screen when the 
panic is done. For this and any other panic it would be optimal if scrolling 
still would work, but scrolling also requires kernel code, so I see there's a 
reason not to this for all panics. However, for this boot problem I tend to 
say there's no need to panic at all...

Btw, not all stack straces are useless, *most* of them are actually very 
useful.

Cheers,
Bernd

Re: sleep before boot panic

[Ingo Oeser]

Hi Bernd,

CC'ed hpa, since I'm sure he can give useful advise on that :-)

On Sunday 06 January 2008, Bernd Schubert wrote:
> On Sunday 06 January 2008, Ingo Oeser wrote:
> > Hi Bernd,
> >
> > On Sunday 06 January 2008, you wrote:
> > > Index: zd1211rw.git.beno/init/do_mounts.c
> > > ===================================================================
> > > --- zd1211rw.git.beno.orig/init/do_mounts.c	2008-01-06 18:44:23.000000000
> > > +0100
> > > +++ zd1211rw.git.beno/init/do_mounts.c	2008-01-06 18:45:44.000000000
> > > +0100 @@ -330,6 +330,7 @@
> > >  		printk("Please append a correct \"root=\" boot option; here are the
> > > available partitions:\n");
> > >
> > >  		printk_all_partitions();
> > > +		msleep(60 * 1000);
> >
> > ssleep(60);
> 
> feel free to replace it replace it :)

Not that urgent, but if you resubmit please do it :-)

> There is no dump_stack() here, but disc detection is relatively early in boot 
> process and on all these information are already scrolled off screen when the 
> panic is done. For this and any other panic it would be optimal if scrolling 
> still would work, but scrolling also requires kernel code, so I see there's a 
> reason not to this for all panics. However, for this boot problem I tend to 
> say there's no need to panic at all...

But the kernel cannot continue from that position. You would need a "soft" panic,
which allows behavior of panic=X, but let the kernel continue.

Even better is to continue with the init in the builtin ramfs. That should always
be available and can implement any behavior desired (like droping into a dash).

> Btw, not all stack straces are useless, *most* of them are actually very 
> useful.

I didn't say that. Just if you cannot continue due to admin error, 
but the kernel is in a perfect valid state otherwise,
dumping stack is next to useless.


Best Regards

Ingo Oeser

Re: sleep before boot panic

[Andi Kleen]

Bernd Schubert <bernd-schubert@gmx.de> writes:

> Hi,
>
> I just switched to libata (pata) on my laptop and the immediate panic made it 
> impossible to figure out why my boot partition wasn't available.
> After applying this little patch I could check boot printk output and then saw 
> everything was properly recognized and only scsi-disk support was missing.

The correct fix would be to make scroll back (and sysrq) still work
after panic.  It's a little more complicated, but possible (essentially
it needs a polled keyboard handler)

-Andi

Re: sleep before boot panic

[Ingo Oeser]

On Monday 07 January 2008, Andi Kleen wrote:
> Bernd Schubert <bernd-schubert@gmx.de> writes:
> 
> > Hi,
> >
> > I just switched to libata (pata) on my laptop and the immediate panic made it 
> > impossible to figure out why my boot partition wasn't available.
> > After applying this little patch I could check boot printk output and then saw 
> > everything was properly recognized and only scsi-disk support was missing.
> 
> The correct fix would be to make scroll back (and sysrq) still work
> after panic.  It's a little more complicated, but possible (essentially
> it needs a polled keyboard handler)

Customer: "This system could not find the root fs."
Support: "Oh, yeah, just connect a (USB-) keyboard and scroll back."

Hmm, device detection works after panic?

I really like the "soft" panic better, where you still can operate the 
kernel debugging features, but just have no user space supporting it.

One better hopes, that keyboards never need external firmware to be loaded
at this stage :-)

Best Regards

Ingo Oeser, who just hit the same problem yesterday...

Re: sleep before boot panic

[H. Peter Anvin]

Ingo Oeser wrote:
> On Monday 07 January 2008, Andi Kleen wrote:
>> Bernd Schubert <bernd-schubert@gmx.de> writes:
>>
>>> Hi,
>>>
>>> I just switched to libata (pata) on my laptop and the immediate panic made it 
>>> impossible to figure out why my boot partition wasn't available.
>>> After applying this little patch I could check boot printk output and then saw 
>>> everything was properly recognized and only scsi-disk support was missing.
>> The correct fix would be to make scroll back (and sysrq) still work
>> after panic.  It's a little more complicated, but possible (essentially
>> it needs a polled keyboard handler)
> 
> Customer: "This system could not find the root fs."
> Support: "Oh, yeah, just connect a (USB-) keyboard and scroll back."
> 
> Hmm, device detection works after panic?
> 
> I really like the "soft" panic better, where you still can operate the 
> kernel debugging features, but just have no user space supporting it.
> 

Of course, if we'd been using kinit, "soft panic" would have been done 
exclusively in userspace...

	-hpa

Re: sleep before boot panic

[Pavel Machek]

Hi!

> >>>I just switched to libata (pata) on my laptop and the 
> >>>immediate panic made it impossible to figure out why 
> >>>my boot partition wasn't available.
> >>>After applying this little patch I could check boot 
> >>>printk output and then saw everything was properly 
> >>>recognized and only scsi-disk support was missing.
> >>The correct fix would be to make scroll back (and 
> >>sysrq) still work
> >>after panic.  It's a little more complicated, but 
> >>possible (essentially
> >>it needs a polled keyboard handler)
> >
> >Customer: "This system could not find the root fs."
> >Support: "Oh, yeah, just connect a (USB-) keyboard and 
> >scroll back."
> >
> >Hmm, device detection works after panic?
> >
> >I really like the "soft" panic better, where you still 
> >can operate the kernel debugging features, but just 
> >have no user space supporting it.

ACK. 'scheduling in interrupt' is very different from 'cant mount
root'.

> Of course, if we'd been using kinit, "soft panic" would 
> have been done exclusively in userspace...

What's the status of kinit, btw?
							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: sleep before boot panic

[Andi Kleen]

> I really like the "soft" panic better, where you still can operate the 
> kernel debugging features, but just have no user space supporting it.

There is no specific reason many kernel debugging features (sysrq, scrollback) 
cannot work in the hard panic -- except that nobody coded it yet.

-Andi

Re: sleep before boot panic

[H. Peter Anvin]

Pavel Machek wrote:
> 
>> Of course, if we'd been using kinit, "soft panic" would 
>> have been done exclusively in userspace...
> 
> What's the status of kinit, btw?
> 							Pavel

It's bitrotted a bit since it was first rejected.  It wouldn't take too 
much work to bring it back up to speed, however.  klibc, and some of the 
kinit components, are used for the initramfs in Debian.

	-hpa

kinit (was: sleep before boot panic)

[Ingo Oeser]

On Wednesday 09 January 2008, H. Peter Anvin wrote:
> Pavel Machek wrote:
> > 
> >> Of course, if we'd been using kinit, "soft panic" would 
> >> have been done exclusively in userspace...
> > 
> > What's the status of kinit, btw?
> > 							Pavel
> 
> It's bitrotted a bit since it was first rejected.  It wouldn't take too 
> much work to bring it back up to speed, however.  klibc, and some of the 
> kinit components, are used for the initramfs in Debian.

Yes, and I like most of it. The only thing really missing for me 
is LVM support. Debian (?) did a evil hack to make it work.
Maybe one day this itches soo much, I'll even scratch it :-)

Then I'll be able to test kernels on a standard LVM installation again.

So please keep up the good work!


Best Regards

Ingo Oeser

Re: sleep before boot panic

[Andrew Morton]

On Sun, 6 Jan 2008 19:08:42 +0100 Bernd Schubert <bernd-schubert@gmx.de> wrote:

> Hi,
> 
> I just switched to libata (pata) on my laptop and the immediate panic made it 
> impossible to figure out why my boot partition wasn't available.
> After applying this little patch I could check boot printk output and then saw 
> everything was properly recognized and only scsi-disk support was missing.
> 
> 
> Signed-off-by: Bernd Schubert <bernd-schubert@gmx.de>
> 
> Index: zd1211rw.git.beno/init/do_mounts.c
> ===================================================================
> --- zd1211rw.git.beno.orig/init/do_mounts.c	2008-01-06 18:44:23.000000000 
> +0100

Your email client is wordwrapping things.

> +++ zd1211rw.git.beno/init/do_mounts.c	2008-01-06 18:45:44.000000000 +0100
> @@ -330,6 +330,7 @@
>  		printk("Please append a correct \"root=\" boot option; here are the 
> available partitions:\n");
>  
>  		printk_all_partitions();
> +		msleep(60 * 1000);
>  		panic("VFS: Unable to mount root fs on %s", b);
>  	}

We could borrow the existing pause_on_oops stuff and use it in panic().

Or we could copy it into a new pause_on_panic, but it's hard to see a use
case where they need to be separate.