Further to the previous post, I noticed, after posting, that the SKAS3 patch is not recognized by the kernel compiled on the x336.
However, here are a couple of lines from the linux kernels from RH73 and FC4/32 booting up (both of which recognize SKAS3 on FC4-x86_64). I just copied the binaries over and ran them: Checking for the skas3 patch in the host...found Checking for /proc/mm...found Checking for /dev/anon on the host...Not available (open failed with errno 2) Linux version 2.4.24-1um ([EMAIL PROTECTED]) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Fri May 7 23:50:37 EST 2004 Checking for /proc/mm...found Checking for the skas3 patch in the host...found Checking PROT_EXEC mmap in /tmp...OK Linux version 2.6.12-bs7 ([EMAIL PROTECTED]) (gcc version 4.0.0 20050519 (Red Hat 4.0.0-8)) #1 Sun Jul 17 20:51:06 EST 2005 Cheers Phill. On Mon, 2005-07-18 at 17:49 +1000, Phill Bertolus wrote: > Hi list, > > I've compiled up a kernel using FC4 x86_64 patched with > skas-2.6.12-rc4-v9-pre4 after jigging the FC4 rpm spec file. > > I think it should be OK because I can run an FC4 UML (with a few > things *fixed* in the rootfs) on the 32 bit version of the FC4. (NPTL > can be worked around for the moment in FC4). > > I have kernel.org 2.6.12 patched with uml-2.6.12-bs7 running on both > 32 bit and 64 bit machines. > > While I can get the UML booting and working on 32 bit, the 64 bit > machine produces: > > Last login: Fri Jul 15 07:44:47 2005 from 10.1.1.199 > [EMAIL PROTECTED] ~]# cd /uml/shared > [EMAIL PROTECTED] shared]# /home/phill/linux-2.6.12/linux mem=160m > ubda=cow,root_fs.2005062201 ubdb=swap root=/dev/ubda con=pty > con0=fd:0,fd:1 > Checking for /proc/mm...found > Checking for the skas3 patch in the host...not found > Checking PROT_EXEC mmap in /tmp...OK > tracing thread pid = 15676 > Linux version 2.6.12-bs7 ([EMAIL PROTECTED]) (gcc version > 4.0.0 20050519 (Red Hat 4.0.0-8)) #1 Mon Jul 18 16:45:19 EST 2005 > Built 1 zonelists > Kernel command line: mem=160m ubda=cow,root_fs.2005062201 ubdb=swap > root=/dev/ubda con=pty con0=fd:0,fd:1 > PID hash table entries: 1024 (order: 10, 32768 bytes) > Dentry cache hash table entries: 32768 (order: 6, 262144 bytes) > Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) > Memory: 154368k available > Mount-cache hash table entries: 256 > Checking that ptrace can change system call numbers...OK > Checking syscall emulation patch for ptrace...missing > Checking that host ptys support output SIGIO...Yes > Checking that host ptys support SIGIO on close...No, enabling > workaround > Checking for /dev/anon on the host...Not available (open failed with > errno 2) > NET: Registered protocol family 16 > mconsole (version 2) initialized on /root/.uml/FnGuhh/mconsole > ubd: Synchronous mode > VFS: Disk quotas dquot_6.5.1 > Dquot-cache hash table entries: 512 (order 0, 4096 bytes) > io scheduler noop registered > io scheduler anticipatory registered > io scheduler deadline registered > io scheduler cfq registered > NET: Registered protocol family 2 > IP: routing cache hash table of 1024 buckets, 8Kbytes > TCP established hash table entries: 8192 (order: 4, 65536 bytes) > TCP bind hash table entries: 8192 (order: 4, 65536 bytes) > TCP: Hash tables configured (established 8192 bind 8192) > NET: Registered protocol family 1 > NET: Registered protocol family 17 > Initialized stdio console driver > Console initialized on /dev/tty0 > Initializing software serial port version 1 > Creating "cow" as COW file for "root_fs.2005062201" > ubda: unknown partition table > ubdb: unknown partition table > kjournald starting. Commit interval 5 seconds > EXT3-fs: mounted filesystem with ordered data mode. > VFS: Mounted root (ext3 filesystem) readonly. > request_module: runaway loop modprobe binfmt-464c > request_module: runaway loop modprobe binfmt-464c > request_module: runaway loop modprobe binfmt-464c > request_module: runaway loop modprobe binfmt-464c > request_module: runaway loop modprobe binfmt-464c > > So I Google about somewhat and all I can find is some references to > ELF files not being recognized. This in turn causes the OS to modprobe > for the above mentioned module which is meant to gobble up the ELF and > load it. > > There are lots and lots of threads running at this point. It's easy to > kill just the parent and everything dies and goes away. > > More Googling produces references to AMD x86_64 Opterons not having 32 > bit mode compiled in.... Anyway it's somewhat beyond my understanding > at this stage. The IBM x336 is a Xeon with EM64T. > > FYI, the rootfs is 32 bit not x86_64. At this stage I don't want 64 > bit UMLs. > > HELP.... > > Cheers > Phill. > > ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
