Forward progress

Forward progress

[Gregory Haskins]

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

Re: Forward progress

[Avi Kivity]

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?

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
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

Re: Forward progress

[Gregory Haskins]

>>> 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

Re: Forward progress

[Gregory Haskins]

>>> 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: 
>
> Does the problem also occur with stock qemu- 0.9.0?

I confirmed that the KVM variant of qemu has the problem both with and without the KVM driver.  However, the stock 0.9.0 QEMU codebase works fine.  I saw there was a checkin recently where some files were found to have not merged correctly?  I will pull down the latest and see if that makes a difference.

-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

Re: Forward progress

[Avi Kivity]

Gregory Haskins wrote:
>>>> 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: 
>   
>> Does the problem also occur with stock qemu- 0.9.0?
>>     
>
> I confirmed that the KVM variant of qemu has the problem both with and without the KVM driver.  However, the stock 0.9.0 QEMU codebase works fine.  

Okay, looks like 4423 was a bad idea.  I don't see exactly why yet.


> I saw there was a checkin recently where some files were found to have not merged correctly?  I will pull down the latest and see if that makes a difference.
>   

These were files that aren't used on x86 targets, I just added them to 
reduce the noise when diffing vs qemu.


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
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