Sorry for spamming about gentoo.. :-)

I'm now stuck at getting a functional system up and running. The problem I have is a catch 22: I cannot run an athlon-xp tarball in skas0 because it complains with the dreaded "cannot set up LDT for thread-local storage", and I don't want to run a tarball compiled in i386 mode because then I might as well run in TT mode for speed issues.

Having read similar posts on the subject, I've tried:

- Adding LD_ASSUME_KERNEL=2.4.1 to command line (didn't make any difference) - Inserting export LD_ASSUME_KERNEL=2.4.1 in start scripts (didn't make any difference)
- Move /lib/tls (can't since it doesn't exist)

Further I've dug into the glibc ebuild. It seems it automatically enables the configure flag "--with-tls" if the machine is detected as being anything higher than i386.

This leads me to conclude I have to compile a new system from scratch to get optimizations working under skas0.

Questions are thus:

- Which software packets cause this crash? Is it only glibc?
- How should glibc be compiled (it with which configure flags?)

I am guessing "--without-tls --without-nptl". Anything else?

Or is there a guest kernel patch which might enable me to run an unmodified gentoo tarball (compiled for athlon-xp) under skas0?

  // Joel


On Tue, 27 Sep 2005, Joel Palmius wrote:

As an addition: The stage tarball is a x86 (i386) one. Trying to use for example an athlon-xp stage tarball crashes with "cannot set up LDT for thread-local storage"

 // Joel


On Tue, 27 Sep 2005, Joel Palmius wrote:

 Lengthy.. Summary is that on an amd64 host, uml hangs on skas0 mode if the
 host kernel has been patched with -v9-pre7. Using an unpatched vanilla
host kernel, skas0 boots. Why this is so I have no clue, ask someone else. : -)

 Further, 2.6.12-bs11 refuses to attempt running in skas0 on an unpatched
 host.

 For getting a working gentoo uml on my amd64 host, I now use: unpatched
 2.6.13.2 host and 2.6.13.2-bs2 guest with TT mode disabled. The guest
 kernel had to be compiled in a 32-bit chroot.

 Read on for my fumbling attempts at debugging:

 ---

 I've tried to get SKAS0 to work with a gentoo root, but with limited
 success. TT mode works fine, but SKAS0 hangs at:

  ..
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
    ubda: unknown partition table
    ubdb: unknown partition table
   VFS: Mounted root (ext2 filesystem).

 Top says:

   ..
   16686 root      17   0  128m 5396 5200 R 87.4  0.3   0:27.07 linux
   16690 root      15   0    64   64   64 T 12.3  0.0   0:03.86 linux

 Strace says:

 ...
 waitpid(16690, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSEGV}], WSTOPPED) =
 16690
 ptrace(PTRACE_GETREGS, 16690, 0, 0xa0a6f884) = 0
 ptrace(PTRACE_GETFPXREGS, 16690, 0, 0xa0a6f934) = 0
 ptrace(0x34 /* PTRACE_??? */, 16690, 0, 0xa0a6fb34) = 0
 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0
 rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM IO], NULL, 8) = 0
 rt_sigprocmask(SIG_SETMASK, NULL, [], 8) = 0
 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0
 rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM IO], [ALRM VTALRM IO], 8) = 0
 rt_sigprocmask(SIG_BLOCK, [], NULL, 8)  = 0
 rt_sigprocmask(SIG_SETMASK, NULL, [], 8) = 0
 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0
 rt_sigprocmask(SIG_SETMASK, NULL, [ALRM VTALRM IO], 8) = 0
 rt_sigprocmask(SIG_SETMASK, NULL, [ALRM VTALRM IO], 8) = 0
 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0
 rt_sigprocmask(SIG_UNBLOCK, [], [ALRM VTALRM IO], 8) = 0
 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0
 rt_sigprocmask(SIG_SETMASK, NULL, [ALRM VTALRM IO], 8) = 0
 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0
 rt_sigprocmask(SIG_UNBLOCK, [], [ALRM VTALRM IO], 8) = 0
 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0
 rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM IO], [ALRM VTALRM IO], 8) = 0
 rt_sigprocmask(SIG_BLOCK, [], NULL, 8)  = 0
 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0
 rt_sigprocmask(SIG_SETMASK, NULL, [ALRM VTALRM IO], 8) = 0
 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0
 rt_sigprocmask(SIG_UNBLOCK, [], [ALRM VTALRM IO], 8) = 0
 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0
 rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM IO], NULL, 8) = 0
 ptrace(PTRACE_SETREGS, 16690, 0, 0xa0a6f884) = 0
 ptrace(PTRACE_SETFPXREGS, 16690, 0, 0xa0a6f934) = 0
 ptrace(PTRACE_SYSCALL, 16690, 0, SIG_0) = 0
 --- SIGCHLD (Child exited) @ 0 (0) ---
 ...(repeated)

 So far I've tried these things, all on 2.6.13.1-skas3-v9-pre7 amd64 host:

 2.6.13.1+bs2, TT mode, 2005.1 gentoo root: works
 2.6.13.1+bs2, TT mode, 2004.0 gentoo root: works
 2.6.13.1+bs2, TT mode, slackware 8.1 root from uml homepage: works
 2.6.13.1+bs2, SKAS0 mode, 2005.1 gentoo root: hangs
 2.6.13.1+bs2, SKAS0 mode, 2004.0 gentoo root: hangs
 2.6.13.1+bs2, SKAS0 mode, slackware 8.1 root from uml homepage: works

 (skas0 works on slackware, but hangs on gentoo, trying gentoo's
 usermode-sources for guest instead)

 2.6.12-r2-bs11, TT mode, 2005.1 gentoo root: works
 2.6.12-r2-bs11, TT mode, 2004.0 gentoo root: works
 2.6.12-r2-bs11, TT mode, slackware 8.1 root: works
 2.6.12-r2-bs11, SKAS0 mode, 2005.1 gentoo root: hangs
 2.6.12-r2-bs11, SKAS0 mode, 2004.0 gentoo root: hangs
 2.6.12-r2-bs11, SKAS0 mode, slackware 8.1 root: works

 (same results as with patched vanilla kernel as guest)

 Having tried with different roots and different guest kernels, I now try
 an unpatched host kernel, thinking maybe there's a problem with having
 applied the host patch. Dropping 2004.0 test case since it didn't make any
 difference. Host kernel is now unpatched 2.6.13.2:

 2.6.12-r2-bs11, TT mode, 2005.1 gentoo root: works
 2.6.12-r2-bs11, TT mode, slackware 8.1 root: works

 However, now the guest kernel refuses to switch to SKAS0 mode. It runs in
 TT despite that I have set mode=skas0 on arg line.

 Compiling new kernel tree to be sure I didn't choose any strange options.
 This time I simply exclude the TT mode (it isn't enabled by default).

 2.6.13.2-bs2, SKAS0 mode, 2005.1 gentoo root: WORKS!!

 Okidoki.. It's possible to get skas0 and gentoo to work together after
 all. Why gentoo needs an unpatched host kernel, while slackware dont, I
 have no clue.

 Apart from the above, I also tested a few cases on a 32-bit host. This was
 a bit unstructured, but my impression was that the results are the same,
 ie gentoo guest won't boot in skas0 on a patched host.

 Please suggest more test cases.

  // Joel



 -------------------------------------------------------
 SF.Net email is sponsored by:
 Tame your development challenges with Apache's Geronimo App Server.
 Download
 it for free - -and be entered to win a 42" plasma tv or your very own
 Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
 _______________________________________________
 User-mode-linux-user mailing list
 [email protected]
 https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
User-mode-linux-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
User-mode-linux-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user

Reply via email to