On 26.04.2012 12:24, Vugar Dzhamalov wrote: > > Thank you for doing this. I am very appreciate and sorry for wasting your > time > with this. > Lets be honest here I've reported it more than a week ago and so far no one > else joined the discussion. I guess it is quite obvious that there is > something wrong with my setup rather than anything else...
I'm not sure I understand. You have a problem which looks very much like a bug. The fact that no one else joined this discussion tell exactly nothing, since at this state, bugs are much more difficult to hit, since most obvious bugs which are hit by all users are fixed ages ago. Again, the fact I can't reproduce it does not mean it does not exist, but it most likely means my setup is (slightly) different than yours and something which we overlooked does not let me to hit this bug. Lack of other users hitting this bug does not mean the bug does not exist. We should actually find what is going on - either a real bug in the code or something "wrong" in your setup or something else, before deciding what to do next. > I've launched 64 bit CentOS 6.2 as two guests in the same manner as I did > with > two 64bit Debian testing (wheezy) guests in the previous attempt and got the > same issues with the virtio NIC. There is something wrong with my setup... > > I've found following in my /var/log/syslog > > > kernel: [201326.063213] kvm: 17363: cpu0 unhandled rdmsr: 0xc001100d > kernel: [201326.063226] kvm: 17363: cpu0 unhandled rdmsr: 0xc0010112 > kernel: [201326.193885] kvm: 17363: cpu0 unhandled rdmsr: 0xc0010001 These are accesses by the guest to model-specific CPU registers (MSRs). Qemu must emulate these but it does not emulate all of them (and we can't even know all of them since CPUs are different). What you see here are: 0xC001100d CPU_ID_HYPER_EXT_FEATURES (information about extended features of hypervisor) 0xc0010112 MSR_K8_TSEG_ADDR (some AMD K8-specific register) 0xC0010001 MSR_K7_EVNTSEL1 (some AMD K7-specific register) Guest just probes various features of the CPU to know what a CPU can do, poking around what it knows. Qemu merely reports it didn't know what to do with these, and returned some sort of failure to the guest, which, at this stage, was fully prepared to handle. So these are all harmless. > I can't see anything else I can do at this stage. I can use e1000 - it is > more than sufficient for my current needs. Thank you. This is very good that you have a workaround - it means I can do some more urgent work before I'll take a look at this again. But the probleb appears to be here and we need to find it and fix it or at least understand why and where it happens. (And yes I'd be very glad to close this bugreport so I'd have less bugs to deal with :) Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
