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
process is eating all the CPU time during the decompression, like an
infinite loop.
Between these 2 strings is the gunzip() function at
boot/compressed/misc.c which does the real job, and the problem seemed
to appear since commit 1ab60e0f72f71ec54831e525a3e1154f1c092408.
(2.6.22-rc1 hangs, 2.6.21.6 works). The problem occurs with or without
CONFIG_RELOCATABLE enabled.
What are the possible solutions to confirm where the problem is coming
from ?
Thanks,
Gabriel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
LKML is not the right place for this question. You are running on Intel
hardware?
Bring the discussion over to http://www.vmware.com/community forums
Zach
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 speed, and
taking minutes to decompress the kernel, which is nearly instantaneous
otherwise.
To get back into VT in this case, not only do we need to load FS and GS,
we also need to setup an initial LDT and task. Can you try the attached
patch and see that it does the right thing?
I've also cc'd the KVM developers, as the same problem will affect them,
and hopefully the same patch will fix it.
Thanks, Zach
Zach
It Works (tm) ! Tried compiling with and without the patch, with exactly
the same config, just to be sure. Decompressing the kernel is now
lightning fast.
Thanks !
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 to make the state comprehensive, I opted to reload everything.
Zach
Ah. Maybe we didn't have an exit while we were in long mode with the
16-bit tss, so VT didn't notice the illegal combination.