Am 18.10.2010 14:14, Takuya Yoshikawa wrote: > (2010/10/15 15:41), Takuya Yoshikawa wrote: >> (2010/10/14 21:38), Avi Kivity wrote: >>> On 10/14/2010 02:36 PM, Jan Kiszka wrote: >>>>> >>>>>> and this commit just makes the >>>>>> corruptions more likely. This may even be a QEMU issue in the cirrus/vga >>>>>> model (both qemu-kvm and upstream show the effect). >>>>>> >>>>> >>>>> What about -no-kvm? >>>> >>>> Just booted it (took ages), and the result was actually a completely >>>> black screen. Kind of persistent corruption. This really looks like a >>>> qemu issue now, maybe even a regression as I don't remember running into >>>> such effects a while back. >>> >>> Worked fine for me (though yes it was slow - did tcg regress?). >>> >> >> I reread my commit but could not find any reason to make this corruption >> in kernel side. >> >> But at least, I want to make it clear whether my commit was just a magnifier >> of this problem, I know that magnifier itself is bad, or not. >> >> Though I'm now trying some debugging but have not got a way to show >> kvm_vm_ioctl_get_dirty_log() is 100% correct yet. >> > > I tried some tests and found another issue. > > I opened a terminal in one workspace and did "find /" on it. Then I switched > to another workspace. When I switched back to the first one, the display of > "find /" result was frozen. > > I also replaced kvm_vm_ioctl_get_dirty_log() with the version before my patch was > applied and got the same result. > > I don't know this is related to your report, but something seems wrong. Besides corruptions, I'm getting those freezes from time to time as well (fairly annoying now). Once that happened, (SDL) display updates can only be achieved by pressing CTRL-ATL-1 (ie. switching qemu consoles). Thanks for looking into this. I also think your patch is not guilty. But we still need to understand the real issue. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
