On Sunday 24 April 2005 05:20, Andree Leidenfrost wrote:
> Hi all
> I've been banging my head against this one for a while now, so I finally
> figured I could do with some help (and it might even be a bug in
> UML). ;-)
> I am trying to set up a 2.6 UML instance on a VIA C3 Samuel2  based
> system running a freshly installed Debian Sarge. In TT mode, everything
> works fine. However, in SKAS mode, the guest kernel starts up and
> outputs only:
> Checking for /proc/mm...found
> Checking for the skas3 patch in the host...found
Can you add stderr=1 to the boot process (after enabling the stderr console in
the configuration)? There's possibly some kernel message stuck in the
> then nothing happens, but the guest kernel process uses 100% of the CPU.
> The same setup works fine on my Athlon64 system (IA32 mode) with
> identical host and guest kernels.
Is there any difference in the host distro?
> I am not sure whether it provides additional insight, but here is the
> strace on the VIA box:
> ptrace(PTRACE_GETFPXREGS, 7197, 0, 0xa02aac80) = -1 EIO (Input/output
Well, this one *is* strange. And yes, it's specific to your processor (it
happens because the "fxsr" CPU feature is missing, as reported
by /proc/cpuinfo). However, the UML code seems prepared to cope with this
(see arch/um/os-Linux/sys-i386/registers.c, in init_registers; maybe you can
add some printk's to verify that have_fpx_regs is actually set to 0).
For the rest I've not checked, but I've not seen anything strange.
> (The SIGINT towards the end is me killing the guest kernel with Ctrl-C.)
> The above is with skas3-v9-pre1  for the host and bs4 for the guest
> kernel which were applied to Debian's 2.6.11 sources.
> I've tried this with 2.6.10 and 2.6.11 kernels, both Debian and vanilla
> with and without the bs patch, all with the same result. I've tried
> compiling both the host and guest kernel on the VIA box, with no
> difference. The guest kernel is compiled with "ARCH=um SUBARCH=i386", so
> I hope I have excluded the CMOV on VIA C3 problem.
No, SUBARCH=i386 does not do any difference, if you build on a x86 system (it
makes sense on a x86_64 one). Anyhow, the UML kernel has no specific
optimization enabled for processors >= i386 (the cmov problem is probably for
some root filesystems)
> Also, the guest
> kernel is statically linked, so it shouldn't have anything to do with
> TLS either (I think).
Hmm, yes, and beyond that TLS support on the host is well tolerated since many
releases. The only problem can be with guests filesystems.
> Any help would be hugely appreciated. Also, I am more than happy to run
> additional tests and/or provide debugging information. (I've never done
> kernel debugging, so a hint or two would certainly be great.)
>  /proc/cpuinfo:
> processor : 0
> vendor_id : CentaurHauls
> cpu family : 6
> model : 7
> model name : VIA Samuel 2
> fpu : yes
> fpu_exception : yes
> cpuid level : 1
> wp : yes
> flags : fpu de tsc msr cx8 mtrr pge mmx pni 3dnow
It hasn't cmov?? Well, I didn't expect this. Still, no problem with UML, as
long as the root_fs you use is not compiled to expect cmov. And even then,
the problem would be later.
> bogomips : 1187.84
>  Patch skas-2.6.11-v8.patch.bz2 doesn't apply cleanly to neither
> vanilla nor Debian 2.6.11 kernel for me, so I'm using
> skas-2.6.11-v9-pre1.patch.bz2. The problem is the same with 2.6.10 using
> skas-2.6.10-v8.patch.bz2, though.
Well, v9-pre1 shouldn't create problems, but it's strange that -v8 does not
apply to a vanilla kernel (for the Debian one it already can make a bit more
sense). Here -v8 applies perfectly! Can you verify you were using a vanilla
tree? Also, for -v8-rc5 (which is identical apart the version number) is
*reported* to work on vanilla 2.6.11.
Paolo Giarrusso, aka Blaisorblade
Skype user "PaoloGiarrusso"
Linux registered user n. 292729