Hi Paolo Thanks a lot for your response and suggestions! I think the handling of the fpx registers' absence is the key - see attached patch. But please read on...
On Sun, 2005-04-24 at 17:12 +0200, Blaisorblade wrote: > 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). ;-) > [...] > 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 > buffers. I have "CONFIG_STDERR_CONSOLE=y" in .config. Running: emden2:/home/fwumlusr# ./linux-2.6.11-bs4 stderr=1 mem=32M ubd0=./fwumlfs.img con=pts eth1=tuntap,tap1 Checking for /proc/mm...found Checking for the skas3 patch in the host...found still only gives the previous two lines of output unfortunately. > [...] > Is there any difference in the host distro? Nope, it's Debian Sarge on both the VIA and the Athlon64 box updated daily. > > ptrace(PTRACE_GETFPXREGS, 7197, 0, 0xa02aac80) = -1 EIO (Input/output > > error) > 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). Excellent point! I've done that and am getting this: init_registers BELOW ZERO: have_fpx_regs=0, err=-1, errno=5, EIO=5 So, the value of have_fpx_regs is correct but the 'if' clause checks (err != EIO) which is not correct according to the ptrace manpage and the above values: ptrace always returns -1 on error, the actual cause is provided via errno. My attached little patch 'no_fpx_regs_handling.patch.gz' fixes this. With this patch applied, UML starts up fine on my VIA box. The patch is against vanilla linux 2.6.11. It would be great if it could get included upstream. What I don't understand, though, is why panic didn't just kill the process rather than spinning in some endless loop. Any ideas? > [...] > > [1] /proc/cpuinfo: > > [...] > > 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. From what I've read elsewhere, CMOV is not part of Intel's PentiumPro spec although Intel's PentiumPro implements it. So, the Samuel 2 is a true PentiumPro clone according to the specs but not in practice. > > [...] > 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. Hm, I've downloaded kernel 2.6.11 and skas patch v8 again and indeed the patch applies cleanly. I had another look at file skas-2.6.11-v8.patch I was using before and it turned out to be the skas v8 patch for 2.6.10. I am puzzled but assume that I got things mixed up. Sorry about that! > [...] Thanks a lot again & best regards Andree -- Andree Leidenfrost Sydney - Australia
no_fpx_regs_handling.patch.gz
Description: GNU Zip compressed data
signature.asc
Description: This is a digitally signed message part
