On Wed, Oct 10, 2007 at 12:16:30PM -0700, Zachary Amsden wrote:
> On Wed, 2007-10-10 at 15:37 +0800, Fengguang Wu wrote:
> > Hi Zachary,
> >
> > One of my friends' vmware "hangs" on booting Linux 2.6.23, and then get
> > it to work by applying your patch at http://lkml.org/lkml/2007/8/4/72.
> >
>
On Wed, Oct 10, 2007 at 03:18:42PM +0200, Andi Kleen wrote:
> On Wednesday 10 October 2007 09:37:39 Fengguang Wu wrote:
>
> > One of my friends' vmware "hangs"
>
> It should just be a little slow. VMware seems to do something fishy
> here -- KVM or Xen using VT don't have this issue.
Yeah, it's
On Wed, 2007-10-10 at 15:37 +0800, Fengguang Wu wrote:
> Hi Zachary,
>
> One of my friends' vmware "hangs" on booting Linux 2.6.23, and then get
> it to work by applying your patch at http://lkml.org/lkml/2007/8/4/72.
>
> It would be nice to see your fix going into mainline :-)
I thought that pa
On Wednesday 10 October 2007 09:37:39 Fengguang Wu wrote:
> One of my friends' vmware "hangs"
It should just be a little slow. VMware seems to do something fishy
here -- KVM or Xen using VT don't have this issue.
> on booting Linux 2.6.23, and then get
> it to work by applying your patch at ht
Hi Zachary,
One of my friends' vmware "hangs" on booting Linux 2.6.23, and then get
it to work by applying your patch at http://lkml.org/lkml/2007/8/4/72.
It would be nice to see your fix going into mainline :-)
Thank you,
Fengguang
---
PS. the original patch:
VT is very picky about when it can
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 was loaded
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 t
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 normal
s
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
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
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 this time, the VM
proces
12 matches
Mail list logo
