@67GTA, To me it feels strange should the _WAK method have any effect there. I
believe this is called on resume from suspend not when transitioning from a C
level. What I noticed when comparing the DSDTs you posted was the following:
- Scope (\_PR)
+ Scope (_PR)
{
- Processor (CPU0, 0x00, 0x00001010, 0x06) {}
- Processor (CPU1, 0x01, 0x00001010, 0x06) {}
+ Processor (CPU0, 0x00, 0x00000000, 0x06) {}
+ Processor (CPU1, 0x01, 0x00000000, 0x06) {}
}
This might relate to processor feature. Unfortunately I do not understand yet
what the ACPI spec says about this. But if the effect is a change of the C
states the processor goes, this would explain why this helps. It seems HPET and
C3 might be an evil combination depending on some hardware.
The background here is that when running a tickless kernel (which we do) then
it can happen that all CPUs go into a low power state which turns of external
clocks. The HPET (or the PIT if there is no HPET) is used a trigger to wake the
CPU(s) again. However if there is anything wrong with the connection, the
waking interrupt never arrives. So what you do by pressing a key is just
generating an IRQ and that wakes the CPU.
--
System freezes during boot, unless I hold a key down
https://bugs.launchpad.net/bugs/272247
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
