#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

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

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.

Note: See TracTickets for help on using tickets.