Forward progress

["Gregory Haskins" <ghaskins-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>]

Hi Guys,
  I am pleased to announce some forward progress in tracking a few of the issues I have mentioned before, as follows:

Solved Issue 1) #UD exception in grub under 64 bit SLED guest.  This turn out to be the Intel vs AMD syscall/sysenter under 32 bit compat mode problem that was patched between 15 and 16.  I applied this fix to kvm-12 and 13 and was able to verify that the #UD went away.  Note that grub now segfaults instead ;)  Still havent looked into that one.

Solved Issue 2) "exception 12" during BIOS real-mode execution on kvm-15.  I bisected this down to svn revision 4423.  When I backed out the bios.bin to the previous version, I am now able to get the later code to boot (14-16).  Note that the CDROM is now inaccessible (to be discussed below).  I am not sure how best to permanently fix this, as im sure 4423 was made for a reason.

New problems:

New Issue 1) Now that the #UD is fixed (under 12 and 13 at least), grub is still craping out on me).  I have not investigated this further, but perhaps it is another 32 bit compat mode issue.  TBD

New Issue 2) I think the QEMU 0.9.0 stuff is causing problems for me w.r.t. devices, specifically the CDROM.  I had played around in the 0.9.0 branch back before the merge to the trunk (and before the 4423 checkin) and saw the same problem.   However, I didnt report it then because I knew things were wildly in flux in the branch.  I am sad to report that whatever I was seeing in those early days still seems to  be an issue however.  Here is the behavior I see:

I am using a SLED-10-x86_64.iso for the --cdrom.  When the guest powers up,  I get the standard suse SYSLINUX boot choices.  This means that at a fundamental level (e.g. eltorito, int13, etc) the BIOS is functioning.  However, if I then try to boot the kernel (e.g. with "rescue mode") it complains that it cannot find the CDROM (from within the linux kernel itself).  Without digging deeper, I would guess that the drivers in linux (ATAPI, etc) are probably either erroneously not seeing the device, or are getting a false "empty" report from the drive.  Any tips on any good facilities that exist in qemu/kvm on how to debug this would be appreciated.  Otherwise I will try to see if I can come up with an easy way to get a debug kernel loaded to report what the problem is in more detail.

Note that in all cases I am running on 64 bit 2.6.16 based suse kernels, on C2D machines (a dual core T7600 Thinkpad, and a dual socket+core Xeon 5130 Dell 490) 

Regards,
-Greg

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV