On Thu, Jul 10, 2008 at 4:48 PM, Mohammed Gamal <[EMAIL PROTECTED]> wrote: >>> It's true indeed, the patch did increase the likelihood of the >>> problem with me (although it occurs every few runs). I modified >>> invalid_guest_state() to call kvm_report_emulation_failure() in all >>> cases and I noticed that whenever the crash happens it happens here: >>> >>> rip 6e10 66 b8 20 00 >>> >>> It's too late at night here, so I'll not lookup the opcode map now :) >>> . I'll further look into it later. >>> >> >> Another thing, I tried -no-kvm-pit switch and it tremendously increase >> the likelihood of the crash to almost a 100%. >> > > I updated to the latest kvm-userspace git tree, and now the failure is > happening at completely random instructions whether or not we are > using -no-kvm-pit. >
I didn't have the gfxboot source code in hand, but now that I've got it. It clears out that the failure always occurs in the switch_to_pm_20 routine. However, the failure doesn't happen at one particular instruction, but either doesn't happen at all or happens at any instruction between addresses 6e10 and 6e27. I'm suspecting it might be some kind of a race condition, although I don't see where in the code - kernel side to specific - that this race exactly might occur. Maybe the locking changes in the userspace side helped some underlying issue to come up to the surface just like what happened with FreeDOS. I'll look further into it, any pointers/help/suggestions are appreciated. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
