On Mon, 2015-01-12 at 11:27 -0600, Paul Clarke wrote:
> On 01/12/2015 03:48 AM, Michael Ellerman wrote:
> > We get way too many bug reports that say "the kernel is hung in
> > prom_init", which stems from the fact that the last piece of output
> > people see is "returning from prom_init".
> >
> > The kernel is almost never hung in prom_init(), it's just that it's
> > crashed somewhere after prom_init() but prior to the console coming up.
> >
> > The existing message should give a clue to that, ie. "returning from"
> > indicates that prom_init() has finished, but it doesn't seem to work.
> > Let's try something different.
> >
> > This prints:
> >
> >    Calling quiesce...
> >    Shutting down Open Firmware, booting Linux via __start() ...
> >
> > Which hopefully makes it clear that prom_init() is not the problem, and
> > although __start() probably isn't either, it's at least the right place
> > to begin looking.
> 
> I'm very much in favor of anything that increases usability or decreases 
> confusion.
> 
> I worry about confusion caused by any phrase that begins "Shutting 
> down.."  Even if accurate, I wonder if something more positive that 
> indicates that, at least at this point, things are continuing to proceed 
> along would be preferred.

True.

> Perhaps something like "Transferring control from Open Firmware to 
> kernel (via __start) ...".

Yeah, that's not quite accurate either :)

Linux already has control, but up until that point it is running alongside OF
and using its services. After prom_init() returns we take over the machine
entirely.

Maybe "Leaving Open Firmware, booting Linux ..."

Or just "Booting Linux ...".

> (Do we know for certain that what is about to be invoked is "Linux" 
> per-se, or can it be something else that has a "__start"?)

Yes it's Linux.

Although we treat prom_init() as a separate thing, it's just linked into the
regular kernel binary. So the "transfer" here is really just a function call.
But it signifies a switch from code that runs alongside Open Firmware
(prom_init()), to code that doesn't (the rest of the kernel).

We have talked about actually linking them separately but we've never bothered,
it wouldn't buy us much.

cheers


_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Reply via email to