From: Nix <ni...@es...> - 2003-11-19 20:23:40
|
Using unmodified 2.4.22-6. sshed in through the firewall on the UML instance, with tty logging enabled: typing exit on the last sshed-in console froze the box yielded this on the console before UML died: Kernel panic: switch_mm_skas - PTRACE_SWITCH_MM failed, errno = 9 Kernel panic: switch_mm_skas - PTRACE_SWITCH_MM failed, errno = 9 Kernel panic: Kernel mode fault at addr 0x4, ip 0x400e64ce Kernel panic: Kernel mode fault at addr 0x4, ip 0x400e64ce Kernel panic: Kernel mode fault at addr 0x4, ip 0x400e64ce Kernel panic: Kernel mode fault at addr 0x4, ip 0x400e64ce Kernel panic: switch_mm_skas - PTRACE_SWITCH_MM failed, errno = 9 Kernel panic: Kernel mode fault at addr 0x4, ip 0x400e64ce Kernel panic: Kernel mode fault at addr 0x4, ip 0x400e64ce Kernel panic: Kernel mode fault at addr 0x4, ip 0x400e64ce Kernel panic: Kernel mode fault at addr 0x4, ip 0x400e64ce Kernel panic: Segfault with no mm Kernel panic: Segfault with no mm Kernel panic: Segfault with no mm Kernel panic: Segfault with no mm Kernel panic: Segfault with no mm Kernel panic: Segfault with no mm Kernel panic: Segfault with no mm Kernel panic: Segfault with no mm Kernel panic: Segfault with no mm Kernel panic: Segfault with no mm Kernel panic: Segfault with no mm Kernel panic: Segfault with no mm In idle task - not syncing <0>Kernel panic: Segfault with no mm In idle task - not syncing EBADF is a rather odd error to get from ptrace(): I wonder if this has the same root cause as the EMFILE error I got a couple of weeks ago? It looks like the error came from proc_mm_get_mm(), so something like running out of fhs might explain it. Whatever it is, it's pretty persistent: it looks like it panic-kills every process in turn until it runs out. As before, post-crash the box isn't remotely close to running out of fhs: 1437 208 8192 (Now that the instance has crashed, I have an excuse to rebuild it with debugging turned on, so the next report like this should have backtraces.) -- `Me, I want exploding spaceships and pulverized worlds and clashes of billion-year-old empires *and* competently written sentences.' --- Matt Austern |
From: Nuno S. <nun...@vg...> - 2003-11-19 20:59:12
|
Hi!! Nix wrote: > Using unmodified 2.4.22-6. sshed in through the firewall on the UML > instance, with tty logging enabled: typing exit on the last sshed-in > console froze the box yielded this on the console before UML died: > > Kernel panic: switch_mm_skas - PTRACE_SWITCH_MM failed, errno = 9 > > Kernel panic: switch_mm_skas - PTRACE_SWITCH_MM failed, errno = 9 > I got these some weeks ago. Didn't have time to investigate at the time :( The odd thing is that this seems to happen only with UMLs running redhat. Debian UMLs never showed this... The host is running debian stable. I'll try to test UML with a RH filesystem again. Regards, Nuno Silva |
From: Nix <ni...@es...> - 2003-11-19 21:42:31
|
On Wed, 19 Nov 2003, Nuno Silva stipulated: > The odd thing is that this seems to happen only with UMLs running > redhat. Debian UMLs never showed this... My UML is running a self-built-from-source stripped-down system with handwritten boot scripts and firewall; no RH in sight. So there might be some commonality between that FS and the RH root filesystems that isn't shared by the Debian ones, but I'm not sure what it could be. -- `Me, I want exploding spaceships and pulverized worlds and clashes of billion-year-old empires *and* competently written sentences.' --- Matt Austern |
From: Nuno S. <nun...@vg...> - 2003-11-19 23:54:38
|
Nix wrote: > On Wed, 19 Nov 2003, Nuno Silva stipulated: > >>The odd thing is that this seems to happen only with UMLs running >>redhat. Debian UMLs never showed this... > > > My UML is running a self-built-from-source stripped-down system with > handwritten boot scripts and firewall; no RH in sight. > > So there might be some commonality between that FS and the RH root > filesystems that isn't shared by the Debian ones, but I'm not sure what > it could be. > Maybe it's just a coincidence... I'll try to reproduce this. Regards, Nuno Silva |
From: Nuno S. <nun...@vg...> - 2003-11-20 11:34:40
|
Nuno Silva wrote: > Hi!! > > Nix wrote: > >> Using unmodified 2.4.22-6. sshed in through the firewall on the UML >> instance, with tty logging enabled: typing exit on the last sshed-in >> console froze the box yielded this on the console before UML died: >> >> Kernel panic: switch_mm_skas - PTRACE_SWITCH_MM failed, errno = 9 >> >> Kernel panic: switch_mm_skas - PTRACE_SWITCH_MM failed, errno = 9 >> I've found a log with the error, it's a bit different from yours: Kernel panic: save_registers - saving registers failed, errno = 3 Kernel panic: switch_mm_skas - PTRACE_SWITCH_MM failed, errno = 3 In idle task - not syncing -------------------------------- From the screen(1) logs this was a few minutes after the boot and this UML should be mostly idle. I only have this log and no backtraces... not very helpfull :( Regards, Nuno Silva |
From: Jeff C. <je...@si...> - 2003-11-20 12:59:25
|
try uml-patch-2.4.22-5. I couldn't get 2.4.22-6 to work yet. Linux is 2.4.23-rc2. Thanks, Jeff [ jc...@fe... ] On Thu, 20 Nov 2003, Nuno Silva wrote: > > > Nuno Silva wrote: > > Hi!! > > > > Nix wrote: > > > >> Using unmodified 2.4.22-6. sshed in through the firewall on the UML > >> instance, with tty logging enabled: typing exit on the last sshed-in > >> console froze the box yielded this on the console before UML died: > >> > >> Kernel panic: switch_mm_skas - PTRACE_SWITCH_MM failed, errno = 9 > >> > >> Kernel panic: switch_mm_skas - PTRACE_SWITCH_MM failed, errno = 9 > >> > > I've found a log with the error, it's a bit different from yours: > > Kernel panic: save_registers - saving registers failed, errno = 3 > > Kernel panic: switch_mm_skas - PTRACE_SWITCH_MM failed, errno = 3 > > In idle task - not syncing > > -------------------------------- > > From the screen(1) logs this was a few minutes after the boot and this > UML should be mostly idle. I only have this log and no backtraces... not > very helpfull :( > > Regards, > Nuno Silva > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > User-mode-linux-devel mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel > |
From: Nix <ni...@es...> - 2003-11-20 15:24:13
|
On Thu, 20 Nov 2003, Nuno Silva stated: > I've found a log with the error, it's a bit different from yours: > > Kernel panic: save_registers - saving registers failed, errno = 3 That's ESRCH, `No such process'. Looks like the user process died :( > Kernel panic: switch_mm_skas - PTRACE_SWITCH_MM failed, errno = 3 Manipulating the memory mappings of a process that no longer exists is kind of hard... -- `Me, I want exploding spaceships and pulverized worlds and clashes of billion-year-old empires *and* competently written sentences.' --- Matt Austern |
From: Jeff D. <jd...@ad...> - 2003-11-21 02:19:17
|
ni...@es... said: > That's ESRCH, `No such process'. Looks like the user process died :( That also happens when the child isn't stopped. There used to be races in UML where it wouldn't make sure that a child had stopped (by returning from wait with such an indication) and would start ptracing it. This resulted in sporadic -ESRCHs before I figured that out. There may be some more of these floating around. Jeff |
From: Christopher S. A. <ca...@th...> - 2003-11-21 03:42:10
|
Hello, For what it's worth... Testing with 2.6.0-test9-bk24 with the skas3 2.6 patch that was posted a while ago, I'm able to get the following oops on the host with a 2.4.22-6um kernel. Interestingly, it only happens on a few of the virtual machines on the host, but it happens every time with the ones that do it. Reading Oops report from the terminal Oops: 0002 [#2] Oops: 0002 [#2] CPU: 2 EIP: 0060:[<c01112ff>] Not tainted EFLAGS: 00010202 EIP is at write_ldt+0x1a4/0x240 eax: 00000000 ebx: 000f0000 ecx: 40cff202 edx: 00000001 CPU: 2 EIP: 0060:[<c01112ff>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 00000000 ebx: 000f0000 ecx: 40cff202 edx: 00000001 esi: 70a0ffff edi: f57e1928 ebp: f57e1800 esp: f580df2c esi: 70a0ffff edi: f57e1928 ebp: f57e1800 esp: f580df2c ds: 007b es: 007b ss: 0068 Process 2.4.22-linode12 (pid: 5279, threadinfo=f580c000 task=f584c080) Stack: f654bba4 00000001 00000001 eda4607e 00000000 00000000 400270a0 000fffff ds: 007b es: 007b ss: 0068 Stack: f654bba4 00000001 00000001 eda4607e 00000000 00000000 400270a0 000fffff 00000051 a5b801e0 f65626b0 f580dfa0 f65626b0 c01113f3 f65626b0 a5b801e0 00000051 a5b801e0 f65626b0 f580dfa0 f65626b0 c01113f3 f65626b0 a5b801e0 00000010 00000001 fffffffb 00000000 c011033f f65626b0 00000001 a5b801e0 Call Trace: 00000010 00000001 fffffffb 00000000 c011033f f65626b0 00000001 a5b801e0 Call Trace: [<c01113f3>] modify_ldt+0x58/0x88 [<c011033f>] sys_ptrace+0x7d7/0x840 [<c012e6d7>] sys_rt_sigprocmask+0xb4/0x180 [<c01113f3>] modify_ldt+0x58/0x88 [<c011033f>] sys_ptrace+0x7d7/0x840 [<c012e6d7>] sys_rt_sigprocmask+0xb4/0x180 [<c010ad9f>] syscall_call+0x7/0xb [<c010ad9f>] syscall_call+0x7/0xb Code: 89 30 89 48 04 31 f6 89 f9 f0 ff 85 28 01 00 00 0f 8e 70 01 Code: 89 30 89 48 04 31 f6 89 f9 f0 ff 85 28 01 00 00 0f 8e 70 01 >>EIP; c01112ff <save_i387_fxsave+3f/140> <===== Trace; c01113f3 <save_i387_fxsave+133/140> Trace; c011033f <sys_ipc+25f/260> Trace; c012e6d7 <vmtruncate_list+27/70> Trace; c010ad9f <handle_IRQ_event+f/b0> Code; c01112ff <save_i387_fxsave+3f/140> 00000000 <_EIP>: Code; c01112ff <save_i387_fxsave+3f/140> <===== 0: 89 30 mov %esi,(%eax) <===== Code; c0111301 <save_i387_fxsave+41/140> 2: 89 48 04 mov %ecx,0x4(%eax) Code; c0111304 <save_i387_fxsave+44/140> 5: 31 f6 xor %esi,%esi Code; c0111306 <save_i387_fxsave+46/140> 7: 89 f9 mov %edi,%ecx Code; c0111308 <save_i387_fxsave+48/140> 9: f0 ff 85 28 01 00 00 lock incl 0x128(%ebp) Code; c011130f <save_i387_fxsave+4f/140> 10: 0f 8e 70 01 00 00 jle 186 <_EIP+0x186> -Chris |