From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Gregory Haskins" Subject: Forward progress Date: Fri, 09 Mar 2007 00:19:52 -0500 Message-ID: <45F0A836.BA47.005A.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Return-path: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.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