From: Rob L. <ro...@la...> - 2005-07-13 04:46:50
|
So: I apply Blaisorblad's 2.6.12-bb2-skas0 rollup patch, build with skas support, and it crashes (as mentioned earlier) with: VFS: Mounted root (hostfs filesystem) readonly. Kernel panic - not syncing: get_skas_faultinfo : failed to wait for SIGUSR1/SIGTRAP, pid = 7944, n = 7944, errno = 0, status = 0xb And then a dump (which I pasted in a few messages back...) Is there an obvious way to track this down further? I ran it under strace and filtered out the setsigmask stuff, but unfortunately the result's not very interesting. Lots of stuff happens, then: waitpid(7944, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSEGV}], WUNTRACED) = 7944 ptrace(PTRACE_GETREGS, 7944, 0, 0x88e1804) = 0 ptrace(PTRACE_GETFPXREGS, 7944, 0, 0x88e18b4) = 0 ptrace(PTRACE_CONT, 7944, 0, SIGSEGV) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(7944, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGUSR1}], WUNTRACED) = 7944 getpid() = 7939 ptrace(PTRACE_SETREGS, 7944, 0, 0x88e7764) = 0 ptrace(PTRACE_CONT, 7944, 0, SIG_0) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(7944, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGTRAP}], WUNTRACED) = 7944 ptrace(PTRACE_SETREGS, 7944, 0, 0x88e1804) = 0 ptrace(PTRACE_SETFPXREGS, 7944, 0, 0x88e18b4) = 0 ptrace(PTRACE_SYSCALL, 7944, 0, SIG_0) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(7944, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSEGV}], WUNTRACED) = 7944 ptrace(PTRACE_GETREGS, 7944, 0, 0x88e1804) = 0 ptrace(PTRACE_GETFPXREGS, 7944, 0, 0x88e18b4) = 0 ptrace(PTRACE_CONT, 7944, 0, SIGSEGV) = 0 waitpid(7944, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}], WUNTRACED) = 7944 --- SIGCHLD (Child exited) @ 0 (0) --- ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x88e793c) = -1 ENOTTY (Inappropriate ioctl for device) write(1, "Kernel panic - not syncing: get_"..., 131) = 131 And so on through a ptrace of it dumping stack. Am I doing it right? Is there anything I can do to help track this down? Rob |
From: Bodo S. <bst...@fu...> - 2005-07-13 12:11:17
|
Rob Landley wrote: > Am I doing it right? Is there anything I can do to help track this down? > > Rob The value of EIP reported in your earlier mail is quite surprising. Could you please "objdump" vmlinux and send the part of "stub_segv_handler"? Bodo |
From: Rob L. <ro...@la...> - 2005-07-13 21:51:21
|
On Wednesday 13 July 2005 07:11, Bodo Stroesser wrote: > Rob Landley wrote: > > Am I doing it right? Is there anything I can do to help track this down? > > > > Rob > > The value of EIP reported in your earlier mail is quite surprising. > Could you please "objdump" vmlinux and send the part of > "stub_segv_handler"? > > Bodo In fact I just put a bzip of the complete dump at: http://www.landley.net/linux.S.bz2 And the executable at linux-skas0 in the same place. Rob |
From: Jeff D. <jd...@ad...> - 2005-07-13 12:21:31
|
On Tue, Jul 12, 2005 at 11:46:40PM -0500, Rob Landley wrote: > VFS: Mounted root (hostfs filesystem) readonly. > Kernel panic - not syncing: get_skas_faultinfo : failed to wait for > SIGUSR1/SIGTRAP, pid = 7944, n = 7944, errno = 0, status = 0xb A bunch of people are seeing this. What's supposed to happen when the segfault hits is that it's supposed to continue into the segfault handler. The fact that it is terminating with SIGSEGV immediately after stopping with SIGSEGV means that the signal handler couldn't be delivered for some reason. Either the signal stack or handler aren't present, or the stack isn't writable. So, maybe the stubs aren't being set up properly. Can you gdb the thing, put a breakpoint in get_skas_faultinfo, and look at /proc/<pid>/maps, where pid is the pid being ptraced? The last two pages, at 0x7fffe000 and 7ffff000 are the stubs. The first should be mapped in from the temp VM file with permissions r-x, and the second should be anonymous with permissions rwx. Jeff |
From: Rob L. <ro...@la...> - 2005-07-13 21:48:11
|
On Wednesday 13 July 2005 07:11, Bodo Stroesser wrote: > Rob Landley wrote: > > Am I doing it right? Is there anything I can do to help track this down? > > > > Rob > > The value of EIP reported in your earlier mail is quite surprising. > Could you please "objdump" vmlinux and send the part of > "stub_segv_handler"? > > Bodo I'm guessing you want objdump -d, and here's stub_segv_handler from that: 081020b0 <stub_segv_handler>: 81020b0: 8b 44 24 5c mov 0x5c(%esp),%eax 81020b4: a3 04 f0 ff bf mov %eax,0xbffff004 81020b9: 8b 44 24 3c mov 0x3c(%esp),%eax 81020bd: a3 00 f0 ff bf mov %eax,0xbffff000 81020c2: 8b 44 24 38 mov 0x38(%esp),%eax 81020c6: a3 08 f0 ff bf mov %eax,0xbffff008 81020cb: b8 14 00 00 00 mov $0x14,%eax 81020d0: cd 80 int $0x80 81020d2: 89 c3 mov %eax,%ebx 81020d4: b8 25 00 00 00 mov $0x25,%eax 81020d9: b9 0a 00 00 00 mov $0xa,%ecx 81020de: cd 80 int $0x80 81020e0: 58 pop %eax 81020e1: 58 pop %eax 81020e2: 58 pop %eax 81020e3: b8 77 00 00 00 mov $0x77,%eax 81020e8: cd 80 int $0x80 81020ea: c3 ret Rob |
From: Rob L. <ro...@la...> - 2005-07-13 21:56:52
|
On Wednesday 13 July 2005 07:15, Jeff Dike wrote: > On Tue, Jul 12, 2005 at 11:46:40PM -0500, Rob Landley wrote: > > VFS: Mounted root (hostfs filesystem) readonly. > > Kernel panic - not syncing: get_skas_faultinfo : failed to wait for > > SIGUSR1/SIGTRAP, pid = 7944, n = 7944, errno = 0, status = 0xb > > A bunch of people are seeing this. What's supposed to happen when the > segfault hits is that it's supposed to continue into the segfault handler. > > The fact that it is terminating with SIGSEGV immediately after stopping > with SIGSEGV means that the signal handler couldn't be delivered for some > reason. > > Either the signal stack or handler aren't present, or the stack isn't > writable. > > So, maybe the stubs aren't being set up properly. Can you gdb the thing, > put a breakpoint in get_skas_faultinfo, and look at /proc/<pid>/maps, where > pid is the pid being ptraced? > > The last two pages, at 0x7fffe000 and 7ffff000 are the stubs. The first > should be mapped in from the temp VM file with permissions r-x, and the > second should be anonymous with permissions rwx. > > Jeff It broke with SIGUSR1 in __kernel_vsyscall(), which I assume is close enough. (I typed "go" until it reached the end and it never broke in get_skas_faultinfo, but then my gdb is a bit shaky so I'm possibly doing something wrong.) Here's the maps: landley@driftwood:/proc/7972$ cat maps 08048000-08132000 rwxp 00000000 03:05 2801050 /home/landley/linux-2.6.12.2/linux 08132000-08165000 rw-p 08132000 00:00 0 08800000-0a000000 rw-s 00800000 03:05 4922001 /tmp/vm_file-gYGr1Q (deleted) b7eb7000-b7eb9000 rw-p b7eb7000 00:00 0 b7eb9000-b7fdb000 r-xp 00000000 03:05 2371242 /lib/tls/i686/cmov/libc-2.3.2.so b7fdb000-b7fe4000 rw-p 00121000 03:05 2371242 /lib/tls/i686/cmov/libc-2.3.2.so b7fe4000-b7fe6000 rw-p b7fe4000 00:00 0 b7fe6000-b7fe8000 r-xp 00000000 03:05 2371260 /lib/tls/i686/cmov/libutil-2.3.2.so b7fe8000-b7fe9000 rw-p 00001000 03:05 2371260 /lib/tls/i686/cmov/libutil-2.3.2.so b7fe9000-b7feb000 rw-p b7fe9000 00:00 0 b7feb000-b8000000 r-xp 00000000 03:05 2371080 /lib/ld-2.3.2.so b8000000-b8001000 rw-p 00015000 03:05 2371080 /lib/ld-2.3.2.so bffeb000-c0000000 rwxp bffeb000 00:00 0 ffffe000-fffff000 ---p 00000000 00:00 0 Rob |
From: Jeff D. <jd...@ad...> - 2005-07-13 23:35:46
|
On Wed, Jul 13, 2005 at 04:56:37PM -0500, Rob Landley wrote: > Here's the maps: > > landley@driftwood:/proc/7972$ cat maps > 08048000-08132000 rwxp 00000000 03:05 2801050 /home/landley/linux-2.6.12.2/linux > 08132000-08165000 rw-p 08132000 00:00 0 > 08800000-0a000000 rw-s 00800000 03:05 4922001 /tmp/vm_file-gYGr1Q (deleted) > b7eb7000-b7eb9000 rw-p b7eb7000 00:00 0 > b7eb9000-b7fdb000 r-xp 00000000 03:05 2371242 /lib/tls/i686/cmov/libc-2.3.2.so > b7fdb000-b7fe4000 rw-p 00121000 03:05 2371242 /lib/tls/i686/cmov/libc-2.3.2.so > b7fe4000-b7fe6000 rw-p b7fe4000 00:00 0 > b7fe6000-b7fe8000 r-xp 00000000 03:05 2371260 /lib/tls/i686/cmov/libutil-2.3.2.so > b7fe8000-b7fe9000 rw-p 00001000 03:05 2371260 /lib/tls/i686/cmov/libutil-2.3.2.so > b7fe9000-b7feb000 rw-p b7fe9000 00:00 0 > b7feb000-b8000000 r-xp 00000000 03:05 2371080 /lib/ld-2.3.2.so > b8000000-b8001000 rw-p 00015000 03:05 2371080 /lib/ld-2.3.2.so > bffeb000-c0000000 rwxp bffeb000 00:00 0 > ffffe000-fffff000 ---p 00000000 00:00 0 This is the maps for the UML kernel, I think, rather than the maps for the process under ptrace. Was 7292 the value of pid at the point of the panic? Jeff |
From: Rob L. <ro...@la...> - 2005-07-14 02:03:09
|
On Wednesday 13 July 2005 18:29, Jeff Dike wrote: > This is the maps for the UML kernel, I think, rather than the maps for the > process under ptrace. > > Was 7292 the value of pid at the point of the panic? There's only one pid, the ./linux process gdb fired off. The breakpoint you mentioned was accepted (it said breakpoint set and gave me an address), but it was never reached. It broke several times on SIGUSR1 (I continued each time) but that was before it had printed out anything at all. After a dozen or so continues, it printed out all the init stuff at once and the panic stuff, all at once. I typed "ps" in another window before each "cont" (for the SIGUSR1's), but no child process had been spawned yet. > Jeff Rob |
From: Bodo S. <bst...@fu...> - 2005-07-14 10:59:53
|
Rob Landley wrote: > On Wednesday 13 July 2005 07:11, Bodo Stroesser wrote: > >>Rob Landley wrote: >> >>>Am I doing it right? Is there anything I can do to help track this down? >>> >>>Rob >> >>The value of EIP reported in your earlier mail is quite surprising. >>Could you please "objdump" vmlinux and send the part of >>"stub_segv_handler"? >> >> Bodo > > > I'm guessing you want objdump -d, and here's stub_segv_handler from that: > > 081020b0 <stub_segv_handler>: > 81020b0: 8b 44 24 5c mov 0x5c(%esp),%eax > 81020b4: a3 04 f0 ff bf mov %eax,0xbffff004 > 81020b9: 8b 44 24 3c mov 0x3c(%esp),%eax > 81020bd: a3 00 f0 ff bf mov %eax,0xbffff000 > 81020c2: 8b 44 24 38 mov 0x38(%esp),%eax > 81020c6: a3 08 f0 ff bf mov %eax,0xbffff008 > 81020cb: b8 14 00 00 00 mov $0x14,%eax > 81020d0: cd 80 int $0x80 > 81020d2: 89 c3 mov %eax,%ebx > 81020d4: b8 25 00 00 00 mov $0x25,%eax > 81020d9: b9 0a 00 00 00 mov $0xa,%ecx > 81020de: cd 80 int $0x80 > 81020e0: 58 pop %eax > 81020e1: 58 pop %eax > 81020e2: 58 pop %eax > 81020e3: b8 77 00 00 00 mov $0x77,%eax > 81020e8: cd 80 int $0x80 > 81020ea: c3 ret > > Rob Hi Jeff, stub_segv_handler misses the "push ebp" at the beginning. As you do the normally corresponding "pop eax" explicitly, I think stack pointer is wrong on call of sigreturn. I have no idea, what makes happen this. Maybe it depends on compiler version? Bodo P.S.: Normally, stub_segv_handler should look like this: a02090d0 <stub_segv_handler>: a02090d0: 55 push %ebp a02090d1: 89 e5 mov %esp,%ebp a02090d3: 8b 45 60 mov 0x60(%ebp),%eax a02090d6: a3 04 f0 ff bf mov %eax,0xbffff004 a02090db: 8b 45 40 mov 0x40(%ebp),%eax a02090de: a3 00 f0 ff bf mov %eax,0xbffff000 a02090e3: 8b 45 3c mov 0x3c(%ebp),%eax a02090e6: a3 08 f0 ff bf mov %eax,0xbffff008 a02090eb: b8 14 00 00 00 mov $0x14,%eax a02090f0: cd 80 int $0x80 a02090f2: 89 c3 mov %eax,%ebx a02090f4: b8 25 00 00 00 mov $0x25,%eax a02090f9: b9 0a 00 00 00 mov $0xa,%ecx a02090fe: cd 80 int $0x80 a0209100: 58 pop %eax a0209101: 58 pop %eax a0209102: 58 pop %eax a0209103: b8 77 00 00 00 mov $0x77,%eax a0209108: cd 80 int $0x80 a020910a: 5d pop %ebp a020910b: c3 ret |
From: Bodo S. <bst...@fu...> - 2005-07-14 12:05:49
Attachments:
fix-stub_segv-stack.patch
|
Bodo Stroesser wrote: > stub_segv_handler misses the "push ebp" at the beginning. As you > do the normally corresponding "pop eax" explicitly, I think stack > pointer is wrong on call of sigreturn. > > I have no idea, what makes happen this. Maybe it depends on compiler > version? > I hope, the attached patch fixes the problem. The patch is tested in my 2.6.12-rc4 + skas0, where I didn't see the problem. It still works fine for me. Rob, could you please test whether the patch fixes the problem for you? Bodo |
From: Jeff D. <jd...@ad...> - 2005-07-14 13:49:38
|
On Thu, Jul 14, 2005 at 02:05:11PM +0200, Bodo Stroesser wrote: > I hope, the attached patch fixes the problem. The patch is tested in > my 2.6.12-rc4 + skas0, where I didn't see the problem. It still works > fine for me. You're too quick for me sometimes :-) I was just about to write up something essentially the same... Jeff |
From: Bodo S. <bst...@fu...> - 2005-07-14 14:13:11
|
Jeff Dike wrote: > On Thu, Jul 14, 2005 at 02:05:11PM +0200, Bodo Stroesser wrote: > >>I hope, the attached patch fixes the problem. The patch is tested in >>my 2.6.12-rc4 + skas0, where I didn't see the problem. It still works >>fine for me. > > > You're too quick for me sometimes :-) I was just about to write up > something essentially the same... > > Jeff BTW: no problem to be faster, as I can start my work some hours before you wake up :-) Bodo |
From: Rob L. <ro...@la...> - 2005-07-14 18:03:23
|
On Thursday 14 July 2005 07:05, Bodo Stroesser wrote: > Bodo Stroesser wrote: > > stub_segv_handler misses the "push ebp" at the beginning. As you > > do the normally corresponding "pop eax" explicitly, I think stack > > pointer is wrong on call of sigreturn. > > > > I have no idea, what makes happen this. Maybe it depends on compiler > > version? > > I hope, the attached patch fixes the problem. The patch is tested in > my 2.6.12-rc4 + skas0, where I didn't see the problem. It still works > fine for me. > > Rob, could you please test whether the patch fixes the problem for you? > > Bodo I think it did. Alas, it still dies: VFS: Mounted root (hostfs filesystem). cannot set up thread-local storage: cannot set up LDT for thread-local storage But that's a failure I can understand. Rob |
From: Jeff D. <jd...@ad...> - 2005-07-14 14:22:40
|
On Thu, Jul 14, 2005 at 12:59:39PM +0200, Bodo Stroesser wrote: > stub_segv_handler misses the "push ebp" at the beginning. As you > do the normally corresponding "pop eax" explicitly, I think stack > pointer is wrong on call of sigreturn. > > I have no idea, what makes happen this. Maybe it depends on compiler > version? Yes, nice spotting. I had forgotten about that bit of nastiness. Let me think about that. Jeff |
From: Rob L. <ro...@la...> - 2005-07-14 17:58:51
|
On Thursday 14 July 2005 05:59, Bodo Stroesser wrote: > Hi Jeff, > > stub_segv_handler misses the "push ebp" at the beginning. As you > do the normally corresponding "pop eax" explicitly, I think stack > pointer is wrong on call of sigreturn. > > I have no idea, what makes happen this. Maybe it depends on compiler > version? > > Bodo It's the current ("Hoary Hedgehog", I think) ubuntu/kbuntu gcc 3.3: landley@driftwood:~/busybox_stable$ gcc -v Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2) |
From: Jeff D. <jd...@ad...> - 2005-07-14 12:43:35
|
On Wed, Jul 13, 2005 at 09:02:46PM -0500, Rob Landley wrote: > There's only one pid, the ./linux process gdb fired off. No, there's the pid that's being ptraced, and I need the maps for it. > The breakpoint you > mentioned was accepted (it said breakpoint set and gave me an address), but > it was never reached. Then put a while(1) ; just before the panic and kill -INT uml-pid when it freezes. That will get you a gdb prompt where you need it. Jeff |
From: Bodo S. <bst...@fu...> - 2005-07-14 14:11:26
|
Jeff Dike wrote: > On Thu, Jul 14, 2005 at 02:05:11PM +0200, Bodo Stroesser wrote: > >>I hope, the attached patch fixes the problem. The patch is tested in >>my 2.6.12-rc4 + skas0, where I didn't see the problem. It still works >>fine for me. > > > You're too quick for me sometimes :-) I was just about to write up > something essentially the same... > > Jeff Do you know _what_ makes the problem happen? Is it depended on the compiler version (gcc 3.3.5) or is there any CONFIG_XXXXX, that lets make use some special compiler option? Bodo |
From: Jeff D. <jd...@ad...> - 2005-07-14 15:22:42
|
On Thu, Jul 14, 2005 at 04:11:14PM +0200, Bodo Stroesser wrote: > Do you know _what_ makes the problem happen? Is it depended on the > compiler version (gcc 3.3.5) or is there any CONFIG_XXXXX, that lets > make use some special compiler option? CONFIG_FRAME_POINTER (or maybe CONFIG_DEBUG_INFO enables frame pointers) would be my guess. Jeff |
From: Rob L. <ro...@la...> - 2005-07-14 18:20:35
Attachments:
.config
|
On Thursday 14 July 2005 09:23, Jeff Dike wrote: > On Thu, Jul 14, 2005 at 04:11:14PM +0200, Bodo Stroesser wrote: > > Do you know _what_ makes the problem happen? Is it depended on the > > compiler version (gcc 3.3.5) or is there any CONFIG_XXXXX, that lets > > make use some special compiler option? > > CONFIG_FRAME_POINTER (or maybe CONFIG_DEBUG_INFO enables frame pointers) > would be my guess. > > Jeff My config, if it helps. Rob |
From: Rob L. <ro...@la...> - 2005-07-14 18:16:56
|
On Thursday 14 July 2005 07:37, Jeff Dike wrote: > On Wed, Jul 13, 2005 at 09:02:46PM -0500, Rob Landley wrote: > > There's only one pid, the ./linux process gdb fired off. > > No, there's the pid that's being ptraced, and I need the maps for it. > > > The breakpoint you > > mentioned was accepted (it said breakpoint set and gave me an address), > > but it was never reached. > > Then put a while(1) ; just before the panic and kill -INT uml-pid when it > freezes. That will get you a gdb prompt where you need it. > > Jeff Bodo's patch seems to have fixed the problem (albeit in a way that reveals ubuntu is using thread-local storage, so I can't use it anyway). But just in case this helps, I added the for loop, and here's the maps for the second pid: landley@driftwood:/proc/8793$ cat maps 08000000-08048000 rw-s 00000000 03:05 4921999 /tmp/vm_file-oxis26 (deleted) 08048000-08132000 rwxp 00000000 03:05 2801042 /home/landley/linux-2.6.12.2/linux 08132000-08165000 rw-p 08132000 00:00 0 08165000-081b0000 rw-s 00165000 03:05 4921999 /tmp/vm_file-oxis26 (deleted) 081b0000-081b1000 rwxs 001b0000 03:05 4921999 /tmp/vm_file-oxis26 (deleted) 081b1000-0b000000 rw-s 001b1000 03:05 4921999 /tmp/vm_file-oxis26 (deleted) b7eb7000-b7eb9000 rw-p b7eb7000 00:00 0 b7eb9000-b7fdb000 r-xp 00000000 03:05 2371242 /lib/tls/i686/cmov/libc-2.3.2.so b7fdb000-b7fe4000 rw-p 00121000 03:05 2371242 /lib/tls/i686/cmov/libc-2.3.2.so b7fe4000-b7fe6000 rw-p b7fe4000 00:00 0 b7fe6000-b7fe8000 r-xp 00000000 03:05 2371260 /lib/tls/i686/cmov/libutil-2.3.2.so b7fe8000-b7fe9000 rw-p 00001000 03:05 2371260 /lib/tls/i686/cmov/libutil-2.3.2.so b7fe9000-b7feb000 rw-p b7fe9000 00:00 0 b7feb000-b8000000 r-xp 00000000 03:05 2371080 /lib/ld-2.3.2.so b8000000-b8001000 rw-p 00015000 03:05 2371080 /lib/ld-2.3.2.so bffeb000-c0000000 rwxp bffeb000 00:00 0 ffffe000-fffff000 ---p 00000000 00:00 0 |
From: Rob L. <ro...@la...> - 2005-07-14 20:30:19
|
On Thursday 14 July 2005 13:16, Rob Landley wrote: > Bodo's patch seems to have fixed the problem (albeit in a way that reveals > ubuntu is using thread-local storage, so I can't use it anyway). Hang on a sec, if TLS is screwing up -skas0, then why does -tt mode work? Is this expected? Rob |
From: Blaisorblade <bla...@ya...> - 2005-07-15 16:03:16
|
On Thursday 14 July 2005 22:30, Rob Landley wrote: > On Thursday 14 July 2005 13:16, Rob Landley wrote: > > Bodo's patch seems to have fixed the problem (albeit in a way that > > reveals ubuntu is using thread-local storage, so I can't use it anyway). > > Hang on a sec, if TLS is screwing up -skas0, then why does -tt mode work? > > Is this expected? Hmm, I've seen TLS falling back on modify_ldt() at times, and it's surely a bit bogus in current trees (although I have a partial fix for it, but not sure whether it will work). Do you think init=/usr/bin/strace /bin/ls would work? Uncomprehensible kernel params are passed to init, so it could. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
From: Bodo S. <bst...@fu...> - 2005-07-15 16:25:24
|
Blaisorblade wrote: > On Thursday 14 July 2005 22:30, Rob Landley wrote: > >>On Thursday 14 July 2005 13:16, Rob Landley wrote: >> >>>Bodo's patch seems to have fixed the problem (albeit in a way that >>>reveals ubuntu is using thread-local storage, so I can't use it anyway). >> >>Hang on a sec, if TLS is screwing up -skas0, then why does -tt mode work? >> >>Is this expected? > > Hmm, I've seen TLS falling back on modify_ldt() at times, and it's surely a > bit bogus in current trees (although I have a partial fix for it, but not > sure whether it will work). Do you think init=/usr/bin/strace /bin/ls would > work? Uncomprehensible kernel params are passed to init, so it could. Testing SKAS0 some month ago, I had problems with TLS in LDT, too. It didn't print any message, but the processes looped on a segfault. Debugging this, I changed SKAS0 to use the full faultinfo, so in the newer versions it detects that the fault isn't fixable and generates SIGSEGV. But I also had to add some code to make sys_modify_ldt work in SKAS0 (reading and writing). Most of this is in skas-hold-own-ldt, but further patches (e.g. skas0-clone) might be necessary. The patches can be found in Jeff's incrementals. Bodo |
From: Rob L. <ro...@la...> - 2005-07-15 19:40:25
Attachments:
out-tt.txt
out-skas.txt
|
On Friday 15 July 2005 11:10, Blaisorblade wrote: > On Thursday 14 July 2005 22:30, Rob Landley wrote: > > On Thursday 14 July 2005 13:16, Rob Landley wrote: > > > Bodo's patch seems to have fixed the problem (albeit in a way that > > > reveals ubuntu is using thread-local storage, so I can't use it > > > anyway). > > > > Hang on a sec, if TLS is screwing up -skas0, then why does -tt mode work? > > > > Is this expected? > > Hmm, I've seen TLS falling back on modify_ldt() at times, and it's surely a > bit bogus in current trees (although I have a partial fix for it, but not > sure whether it will work). Do you think init=/usr/bin/strace /bin/ls would > work? Uncomprehensible kernel params are passed to init, so it could. Here's the output of that under both -tt mode and -skas0 mode. Exact same command line both times, except for the name of the output file being redirected to. Only .config change was switching from tt to skas mode. Rob |