Opened 22 months ago
Closed 21 months ago
#325 closed defect (wontfix)
dom0 is stalled until keypress (or other event)
| Reported by: | rafal | Owned by: | joanna |
|---|---|---|---|
| Priority: | major | Milestone: | Release 1 Beta 2 |
| Component: | xen | Keywords: | |
| Cc: |
Description
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.
Change History (3)
comment:1 Changed 22 months ago by rafal
- Milestone set to Release 1 Beta 2
comment:2 Changed 21 months ago by rafal
comment:3 Changed 21 months ago by joanna
- Resolution set to wontfix
- Status changed from new to closed
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.

This problem does not occur when adding "cpufreq=domo-kernel" to xen cmdline in grub.conf.