Bug 36252
Summary: | hwclock: select() to /dev/rtc to wait for clock tick timed out | ||
---|---|---|---|
Product: | Timers | Reporter: | Thomas Jarosch (thomas.jarosch) |
Component: | Realtime Clock | Assignee: | john stultz (john.stultz) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | avi, john.stultz |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 3.0.0-rc1 / 2.6.38 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Attachments: |
Dmesg output of working box
Dmesg output of broken box |
Description
Thomas Jarosch
2011-05-30 13:26:25 UTC
Thanks for the bug report! I'm looking into it. Thomas: Are the two virtual machines identical? Maybe could you provide full guest dmesg output from the VM using the same guest kernel on both the working and non-working hosts? Another clarification: Is the guest kernel x86_64 or i686? So far I'm unable to reproduce on actual x86_64 hardware. Trying to see if I can trigger it under kvm. So far, I've not been able to reproduce with x86_64 guest on x86_64 host (with recent kvm). It def seems like it could be a kvm/qemu triggered issue (which makes reproducing it somewhat more difficult). Thomas: Could you also provide the "kvm -version" output? Created attachment 62042 [details]
Dmesg output of working box
Created attachment 62052 [details]
Dmesg output of broken box
Both systems are installed from the same .iso image. Guest system kernel is i686 + PAE, the VM hardware is set to "x86_64" on both boxes. *** Working box *** KVM version: 0.13.0 Host system kernel: 2.6.35.13-92.fc14.x86_64 dmesg output in "dmesg.working.kvm_0.13.0" *** Broken box *** KVM version: 0.10.50 Host system kernel: 2.6.35.8-59.x86_64 dmesg output in "dmesg.broken.0.10.50" Hope this helps. My apologies, the last few weeks have been busy and I forgot to follow up here. So one interesting detail between the broken and working virtual machines is the broken one doesn't seem to have hpet functionality. I'll try to look through the code to see how the hpet may be involved. Also, on the guest kernel, is CONFIG_RTC_INTF_DEV_UIE_EMUL enabled? (In reply to comment #9) > Also, on the guest kernel, is CONFIG_RTC_INTF_DEV_UIE_EMUL enabled? This option is not set. Ok, so I've reproduced this by using qemu-0.10.5 as you described above with fedora15. I suspect its a kvm issue, where kvm didn't properly support AIE (Alarm) mode alarms from the RTC. So now that the kernel uses emulates periodic update interrupts (UIE mode irqs) via AIE, we're missing the irq. I'll be working on a debug patch to narrow down if my theory is correct. So yea. Unfortunately my theory is right. Apparently kvm/qemu did not support AIE/alarm mode RTC interrupts in older 0.10.5 releases. It did seemingly support UIE mode (and likely PIE mode as well). So with the RTC virtualization changes, the kernel now uses AIE mode for all RTC interrupts. Since kvm/qemu doesn't support those, the bug described here manifests. So I've bisected the fix down on the qemu side to: eeb7c03c0f49a8678028a734f1d6575f36a44edc (Add rtc reset function) which showed up in 0.11. Unfortunately it depends on numerous earlier patches and won't likely be easy to back-port to 0.10.5. So now I'm trying to weigh how valid it is to add hackish fixes to the kernel in order to support old and incomplete emulation environments. CC'ing Avi Kivity to give him a heads up. Some more info on this: The affected server is running Centos 5, so basically this will affect RHEL 5, too. Also the ancient VMware server 1.x shows the same issue (found while testing the upgrade to 2.6.39.3 on it). Talked with Avi Kivity and I think the right approach here is to get the qemu/kvm AIE mode enablment from 0.11 backported to the RHEL5 version(0.10) of qemu/kvm. RHEL5 bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=725876 Thomas Jarosch: According to the RH bug, as of kvm-83-246.el5 and 2.6.38.6-26.rc1.fc15.x86_64 the issue should be fixed by an updated kvm. I'm marking this as resolved, but let me know if it continues to be an issue. |