dom0 is stalled until keypress (or other event)

[marmarek]

Reported by rafal on 15 Aug 2011 19:29 UTC
On one [old] test system, the dom0 boot "stops" after printing "Starting udev". Then nothing seems to happen. I need to press any key to observe progress - I need to do it tens of times for the boot to finish. After X starts fine, then there is no need for keypressing anymore .
Particularly disturbing fact is that qrexec_daemon parent, that basically does
for (;;) { sleep(1); fprintf(stderr, "."); }
does not print dots, until a keypress arrives.
Somehow similarly, pm-suspend sometimes hangs at the end - after detaching power cord, machine enters S3 immediately.
This is vaguely similar to the issue described in
https://lkml.org/lkml/2008/9/14/122
but this time, "nohz=off" does not help.
This issue does not happen in beta2. It is present with xen4.1+kernel-2.6.38.

Migrated-From: https://wiki.qubes-os.org/ticket/325

[marmarek]

Modified by rafal on 15 Aug 2011 19:45 UTC

[marmarek]

Modified by rafal on 15 Aug 2011 19:45 UTC

[marmarek]

Comment by rafal on 30 Aug 2011 08:30 UTC
This problem does not occur when adding "cpufreq=domo-kernel" to xen cmdline in grub.conf.

[marmarek]

Comment by rafal on 30 Aug 2011 08:30 UTC
This problem does not occur when adding "cpufreq=domo-kernel" to xen cmdline in grub.conf.

[marmarek]

Comment by joanna on 8 Sep 2011 09:23 UTC
Apparently this problem is related to buggy power management and specifically C-state management of the processor. Seems like Xen 4.x either doesn't correctly read info about available C states, while Xen 3.4 did, or the previous Xen had some kind of patch to know that some older hardware is perhaps buggy and should not be put into some deep C-states.

In any case, because 1) there is a workaround (cpufreq=dom0-kernel), and 2) this bug has been observed on one machine only, and finally 3) this is really NOTOURBUG, we're closing it.

[marmarek]

Comment by joanna on 8 Sep 2011 09:23 UTC
Apparently this problem is related to buggy power management and specifically C-state management of the processor. Seems like Xen 4.x either doesn't correctly read info about available C states, while Xen 3.4 did, or the previous Xen had some kind of patch to know that some older hardware is perhaps buggy and should not be put into some deep C-states.

In any case, because 1) there is a workaround (cpufreq=dom0-kernel), and 2) this bug has been observed on one machine only, and finally 3) this is really NOTOURBUG, we're closing it.