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@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org