Re: Forward progress

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

>>> On Sun, Mar 11, 2007 at  5:28 AM, in message <45F3CBC7.2020406-atKUWr5tajBWk0Htik3J/w@public.gmane.org>,
Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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