From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Gregory Haskins" Subject: Re: Forward progress Date: Mon, 12 Mar 2007 07:49:01 -0400 Message-ID: <45F505F7.BA47.005A.0@novell.com> References: <45F0A836.BA47.005A.0@novell.com> <45F3CBC7.2020406@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: "Avi Kivity" Return-path: In-Reply-To: <45F3CBC7.2020406-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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 >>> On Sun, Mar 11, 2007 at 5:28 AM, in message <45F3CBC7.2020406-atKUWr5tajBWk0Htik3J/w@public.gmane.org>, Avi Kivity wrote: > Gregory Haskins wrote: >> 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. >> >> > > 4423 is a hack, and a bad one. I would love to see it go away. Proper > real mode support would eliminate it, but maybe there's a better hack to > real mode segmentation we can apply in the meantime. > >> 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. >> > > Does the problem also occur with stock qemu- 0.9.0? Im not sure. I will find out and get back to you. ------------------------------------------------------------------------- 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