Zachary Amsden wrote:
> Avi Kivity wrote:
>>
>> We haven't seen any issue with the 2.6.22 boot decompressor. Which
>> of the four (fs, gs, ldt, or tr) were proving problematic and why?
>
> It was tr that was affecting Workstation, since we boot through normal
> BIOS path, and only a 16-bit task
Avi Kivity wrote:
>
> We haven't seen any issue with the 2.6.22 boot decompressor. Which of
> the four (fs, gs, ldt, or tr) were proving problematic and why?
It was tr that was affecting Workstation, since we boot through normal
BIOS path, and only a 16-bit task was loaded at this point.
Just
Zachary Amsden wrote:
>
> Since I was just involved in the boot decompressor for another bug, I
> took a look at this. 2.6.22 switches it to be 64-bit code. VT is
> very picky about what state it can run in. Not using VT on Intel
> 64-bit hardware cripples performance, running at far below no
On 08/04/2007 6:23:00 PM +0200, Zachary Amsden <[EMAIL PROTECTED]> wrote:
Gabriel Barazer wrote:
Hi,
After upgrading kernel to 2.6.22 on a Vmware workstation guest version
5.5 and 6 , the kernel decompression stage ("Decompressing Linux...")
is hanging for a very long time (~5 minutes) before
Gabriel Barazer wrote:
Hi,
After upgrading kernel to 2.6.22 on a Vmware workstation guest version
5.5 and 6 , the kernel decompression stage ("Decompressing Linux...")
is hanging for a very long time (~5 minutes) before finally
succeeding (displaying "done.\nBooting the kernel.\n"). During t
