So, what changed so you were able to boot from IDE without errors? As far as I understand, your initial prob was I/O errors on IDE (virtual) drive, but now you can boot it without errors. Or was it always SATA not IDE?
The rdmsr/wrmsr are unrelated, I already told you that, it is accessing optional CPU features which has nothing to do with disk access. The segfaults during mkinitrd are unrelated too _unless_ you're running it from "failing" virtual drive. If you run it from failing virtual drive, it is remotely possible to have errors due to some file not read properly due to errors, but even this is a very remote possibility. The time it takes to start mounting root is most likely also unrelated, it depends on the guest. It _looks_ like the whole prob is due to FLUSH CASHE command not working correctly with SATA and IDE, but you confused me here - I don't understand where you were and are getting errors and where you don't. Besides, you never answered to this: do you have enough free space in the host filesystem where your disk image(s) are located? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1204697 Title: guest disk accesses lead to ATA errors + host vcpu0 unhandled wrmsr/rdmsr Status in QEMU: New Status in “qemu” package in Debian: Confirmed Bug description: Hi. This is from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717724. Using Debian sid with 1.5.0-5 my Linux VMs (also Debian sid) are broken. When they boot I get gazillions of ATA errors inside the guest, as well as: [ 242.479951] kvm [7790]: vcpu0 unhandled rdmsr: 0x345 [ 242.483683] kvm [7790]: vcpu0 unhandled wrmsr: 0x680 data 0 [ 242.483687] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c0 data 0 [ 242.483689] kvm [7790]: vcpu0 unhandled wrmsr: 0x681 data 0 [ 242.483691] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c1 data 0 [ 242.483693] kvm [7790]: vcpu0 unhandled wrmsr: 0x682 data 0 [ 242.483696] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c2 data 0 [ 242.483698] kvm [7790]: vcpu0 unhandled wrmsr: 0x683 data 0 [ 242.483700] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c3 data 0 [ 242.483702] kvm [7790]: vcpu0 unhandled wrmsr: 0x684 data 0 [ 242.483704] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c4 data 0 [ 242.988307] kvm [7790]: vcpu0 unhandled rdmsr: 0xe8 [ 242.988312] kvm [7790]: vcpu0 unhandled rdmsr: 0xe7 [ 242.988314] kvm [7790]: vcpu0 unhandled rdmsr: 0xce [ 242.988316] kvm [7790]: vcpu0 unhandled rdmsr: 0xce [ 242.988318] kvm [7790]: vcpu0 unhandled rdmsr: 0x1ad [ 242.988320] kvm [7790]: vcpu0 unhandled rdmsr: 0xce [ 242.988322] kvm [7790]: vcpu0 unhandled rdmsr: 0xe8 [ 242.988324] kvm [7790]: vcpu0 unhandled rdmsr: 0xe7 [ 242.988598] kvm [7790]: vcpu0 unhandled rdmsr: 0xce in the host. Please have a look at the Debian bug, for screenshots and more info. The problem didn't occur in 1.5.0-4 and there were basically no changes inside the VM (i.e. no kernel upgrade or so). Thanks, Chris. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1204697/+subscriptions
