Mailinglist Archive: opensuse-factory (508 mails)

[Kay Sievers <kay.sievers@xxxxxxx>]

On Tue, 2010-12-14 at 11:59 +0100, Peter Czanik wrote:
> On 12/14/2010 11:42 AM, Kay Sievers wrote:

> > > Without systemd the same system easily survives stress testing (cd
> > > /usr/src/linux && make -j 100 :-) ) without locking up.
> > >     
> > Yeah, isolated computational load is a very different situation from
> > booting up -- where we have heavy parallel kernel module load, device
> > initialization, and service startup going on.
> >
> > If possible, try, if removing:
> >   quiet
> > and adding:
> >   systemd.log_level=debug systemd.log_target=kmsg
> > to the kernel commandline reveals something on the console.
> >
> > It might slow down the bootup enough, so that it works-- or it might
> > show where it hangs.
> >   
> Hehe. Once I use the above settings, systemd seems to boot perfectly, at
> least for the last two boots. Without it the machine hangs with or
> without a kernel panic message on screen during the boot or right after
> the login: prompt is printed.

Yeah, a few people have seen this. It's likely a bug in the kernel in
combination with some specific hardware.

Seems, the massive parallel work uncovers some races here, which we
didn't trigger with the old bootup logic.

Is there any output on the console when the kernel panic happens? Can
you take a picture with a camera of the screen? Would be good to find
out which kernel module makes the machine crash.

Might also worth trying to add:
  systemd.unit=multi-user.target
which will be "runlevel 3", and check if that already crashes.

Kay

-- 
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx