[uml-devel] 2.6.9-bb3 on 2.6.9 host problem - triggering a host bug?

[uml-devel] 2.6.9-bb3 on 2.6.9 host problem - triggering a host bug?

[Blaisorblade]

Checking for the skas3 patch in the host...found
Checking for /proc/mm...found
Checking PROT_EXEC mmap in /tmp...OK
Linux version 2.6.9-skas3-v7-bb3nobodo-rework-hang (paolo@zion) (gcc version 
3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)) #9 FriNov 26 03:51:10 CET 2004
Built 1 zonelists
Kernel command line: ubd0s=slack90.rootfs rootfs=/dev/ubd0 ubd7=slack90.swapfs 
mem=64m eth0=tuntap,,,192.168.0.100 UML_XDISPLAY=192.168.0.100:0 
UML_IP=192.168.0.3 con=xterm con0=fd:0,fd:1 root=98:0
PID hash table entries: 512 (order: 9, 8192 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 61792k available
Kernel panic - not syncing: Segfault with no mm

EIP: 0000:[<00000000>] CPU: 0 Not tainted EFLAGS: 00000000
    Not tainted
EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000
ESI: 00000000 EDI: 00000000 EBP: 00000000 DS: 0000 ES: 0000
Call Trace:
 [<080791d3>] printk+0x13/0x20
 [<0808bbd6>] notifier_call_chain+0x26/0x50
 [<08078468>] panic+0x58/0xc0
 [<0805f2a2>] segv+0x192/0x1d0
 [<081e2157>] sigemptyset+0x17/0x30
 [<0805d483>] change_signals+0x43/0x70
 [<0805f673>] segv_handler+0xc3/0xd0
 [<0805d4cd>] unblock_signals+0xd/0x10
 [<08061cc4>] sig_handler_common_skas+0xa4/0xc0
 [<080616a0>] start_kernel_proc+0x0/0x30
 [<0805f6a3>] sig_handler+0x13/0x20
 [<081e1e88>] __restore+0x0/0x8
 [<080616a0>] start_kernel_proc+0x0/0x30
 [<0804871d>] start_kernel+0xfd/0x1b0
 [<0805d509>] enable_mask+0x39/0x50
 [<081e2157>] sigemptyset+0x17/0x30
 [<081e1e88>] __restore+0x0/0x8
 [<08071158>] file_io+0x28/0x80
 [<08071158>] file_io+0x28/0x80
 [<0805d509>] enable_mask+0x39/0x50
 [<081e2157>] sigemptyset+0x17/0x30
 [<0805d509>] enable_mask+0x39/0x50
 [<081e2157>] sigemptyset+0x17/0x30
 [<08071158>] file_io+0x28/0x80
 [<0805d509>] enable_mask+0x39/0x50
 [<081e2157>] sigemptyset+0x17/0x30
 [<0805d5f0>] set_signals+0x80/0x180
 [<08079727>] release_console_sem+0x1f7/0x270
 [<080795f5>] release_console_sem+0xc5/0x270
 [<080793a5>] vprintk+0x1c5/0x2e0
 [<080791d3>] printk+0x13/0x20
 [<0804cfb0>] free_all_bootmem+0x10/0x20
 [<0805969a>] mem_init+0xfa/0x110
 [<08059662>] mem_init+0xc2/0x110
 [<080616c7>] start_kernel_proc+0x27/0x30
 [<0805ad0a>] run_kernel_thread+0x3a/0x50
 [<080616a0>] start_kernel_proc+0x0/0x30
 [<0805acef>] run_kernel_thread+0x1f/0x50
 [<080616a0>] start_kernel_proc+0x0/0x30
 [<080613c7>] new_thread_handler+0x67/0xa0
 [<080616a0>] start_kernel_proc+0x0/0x30
 [<081e1e88>] __restore+0x0/0x8
 [<081e20e1>] kill+0x11/0x20

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] 2.6.9-bb3 on 2.6.9 host problem - triggering a host bug?

[Bodo Stroesser]

Blaisorblade wrote:
> Checking for the skas3 patch in the host...found
> Checking for /proc/mm...found
> Checking PROT_EXEC mmap in /tmp...OK
> Linux version 2.6.9-skas3-v7-bb3nobodo-rework-hang (paolo@zion) (gcc version 
> 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)) #9 FriNov 26 03:51:10 CET 2004
> Built 1 zonelists
> Kernel command line: ubd0s=slack90.rootfs rootfs=/dev/ubd0 ubd7=slack90.swapfs 
> mem=64m eth0=tuntap,,,192.168.0.100 UML_XDISPLAY=192.168.0.100:0 
> UML_IP=192.168.0.3 con=xterm con0=fd:0,fd:1 root=98:0
> PID hash table entries: 512 (order: 9, 8192 bytes)
> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> Memory: 61792k available
> Kernel panic - not syncing: Segfault with no mm
> 
> EIP: 0000:[<00000000>] CPU: 0 Not tainted EFLAGS: 00000000
>     Not tainted
> EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000
> ESI: 00000000 EDI: 00000000 EBP: 00000000 DS: 0000 ES: 0000
Meanwhile, I have some experience analyzing the call trace.
It's very difficult, when not even impossible, since the output lacks the
stack-addresses. Could you please insert a additional address-field in
the output?

Bodo
> Call Trace:
>  [<080791d3>] printk+0x13/0x20
>  [<0808bbd6>] notifier_call_chain+0x26/0x50
>  [<08078468>] panic+0x58/0xc0
>  [<0805f2a2>] segv+0x192/0x1d0
>  [<081e2157>] sigemptyset+0x17/0x30
>  [<0805d483>] change_signals+0x43/0x70
>  [<0805f673>] segv_handler+0xc3/0xd0
>  [<0805d4cd>] unblock_signals+0xd/0x10
>  [<08061cc4>] sig_handler_common_skas+0xa4/0xc0
>  [<080616a0>] start_kernel_proc+0x0/0x30
>  [<0805f6a3>] sig_handler+0x13/0x20
>  [<081e1e88>] __restore+0x0/0x8
>  [<080616a0>] start_kernel_proc+0x0/0x30
>  [<0804871d>] start_kernel+0xfd/0x1b0
>  [<0805d509>] enable_mask+0x39/0x50
>  [<081e2157>] sigemptyset+0x17/0x30
>  [<081e1e88>] __restore+0x0/0x8
>  [<08071158>] file_io+0x28/0x80
>  [<08071158>] file_io+0x28/0x80
>  [<0805d509>] enable_mask+0x39/0x50
>  [<081e2157>] sigemptyset+0x17/0x30
>  [<0805d509>] enable_mask+0x39/0x50
>  [<081e2157>] sigemptyset+0x17/0x30
>  [<08071158>] file_io+0x28/0x80
>  [<0805d509>] enable_mask+0x39/0x50
>  [<081e2157>] sigemptyset+0x17/0x30
>  [<0805d5f0>] set_signals+0x80/0x180
>  [<08079727>] release_console_sem+0x1f7/0x270
>  [<080795f5>] release_console_sem+0xc5/0x270
>  [<080793a5>] vprintk+0x1c5/0x2e0
>  [<080791d3>] printk+0x13/0x20
>  [<0804cfb0>] free_all_bootmem+0x10/0x20
>  [<0805969a>] mem_init+0xfa/0x110
>  [<08059662>] mem_init+0xc2/0x110
>  [<080616c7>] start_kernel_proc+0x27/0x30
>  [<0805ad0a>] run_kernel_thread+0x3a/0x50
>  [<080616a0>] start_kernel_proc+0x0/0x30
>  [<0805acef>] run_kernel_thread+0x1f/0x50
>  [<080616a0>] start_kernel_proc+0x0/0x30
>  [<080613c7>] new_thread_handler+0x67/0xa0
>  [<080616a0>] start_kernel_proc+0x0/0x30
>  [<081e1e88>] __restore+0x0/0x8
>  [<081e20e1>] kill+0x11/0x20
> 



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] 2.6.9-bb3 on 2.6.9 host problem - triggering a host bug?

[Blaisorblade]

On Monday 29 November 2004 23:15, Blaisorblade wrote:

I pressed Enter before filling in details - this is what I get on some UML 
versions at startup. Specifically, I get it on -bb3, and on versions based on 
it, on startup. I've tried removing the patches I've added to -bb3 and it 
still does not work, which is not nice.

However, I've now discovered that it only happens when CONFIG_STATIC_LINK is 
enabled - that makes the kernel die. The interesting thing is that it becomes 
unkillable - but at least we have some clue that this one is not a new bug in 
-bb3 (at least it seems). I'll go reproducing it in vanilla 2.6.9 if I have 
time.

> Checking for the skas3 patch in the host...found
> Checking for /proc/mm...found
> Checking PROT_EXEC mmap in /tmp...OK

> Linux version 2.6.9-skas3-v7-bb3nobodo-rework-hang (paolo@zion) (gcc
> version 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)) #9 FriNov 26 03:51:10 CET
> 2004

> Built 1 zonelists 
> Kernel command line: ubd0s=slack90.rootfs rootfs=/dev/ubd0
> ubd7=slack90.swapfs mem=64m eth0=tuntap,,,192.168.0.100
> UML_XDISPLAY=192.168.0.100:0
> UML_IP=192.168.0.3 con=xterm con0=fd:0,fd:1 root=98:0
> PID hash table entries: 512 (order: 9, 8192 bytes)
> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> Memory: 61792k available
> Kernel panic - not syncing: Segfault with no mm
>
> EIP: 0000:[<00000000>] CPU: 0 Not tainted EFLAGS: 00000000
>     Not tainted
> EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000
> ESI: 00000000 EDI: 00000000 EBP: 00000000 DS: 0000 ES: 0000
> Call Trace:
>  [<080791d3>] printk+0x13/0x20
>  [<0808bbd6>] notifier_call_chain+0x26/0x50
>  [<08078468>] panic+0x58/0xc0
>  [<0805f2a2>] segv+0x192/0x1d0
>  [<081e2157>] sigemptyset+0x17/0x30
>  [<0805d483>] change_signals+0x43/0x70
>  [<0805f673>] segv_handler+0xc3/0xd0
>  [<0805d4cd>] unblock_signals+0xd/0x10
>  [<08061cc4>] sig_handler_common_skas+0xa4/0xc0
>  [<080616a0>] start_kernel_proc+0x0/0x30
>  [<0805f6a3>] sig_handler+0x13/0x20
>  [<081e1e88>] __restore+0x0/0x8
>  [<080616a0>] start_kernel_proc+0x0/0x30
>  [<0804871d>] start_kernel+0xfd/0x1b0
>  [<0805d509>] enable_mask+0x39/0x50
>  [<081e2157>] sigemptyset+0x17/0x30
>  [<081e1e88>] __restore+0x0/0x8
>  [<08071158>] file_io+0x28/0x80
>  [<08071158>] file_io+0x28/0x80
>  [<0805d509>] enable_mask+0x39/0x50
>  [<081e2157>] sigemptyset+0x17/0x30
>  [<0805d509>] enable_mask+0x39/0x50
>  [<081e2157>] sigemptyset+0x17/0x30
>  [<08071158>] file_io+0x28/0x80
>  [<0805d509>] enable_mask+0x39/0x50
>  [<081e2157>] sigemptyset+0x17/0x30
>  [<0805d5f0>] set_signals+0x80/0x180
>  [<08079727>] release_console_sem+0x1f7/0x270
>  [<080795f5>] release_console_sem+0xc5/0x270
>  [<080793a5>] vprintk+0x1c5/0x2e0
>  [<080791d3>] printk+0x13/0x20
>  [<0804cfb0>] free_all_bootmem+0x10/0x20
>  [<0805969a>] mem_init+0xfa/0x110
>  [<08059662>] mem_init+0xc2/0x110
>  [<080616c7>] start_kernel_proc+0x27/0x30
>  [<0805ad0a>] run_kernel_thread+0x3a/0x50
>  [<080616a0>] start_kernel_proc+0x0/0x30
>  [<0805acef>] run_kernel_thread+0x1f/0x50
>  [<080616a0>] start_kernel_proc+0x0/0x30
>  [<080613c7>] new_thread_handler+0x67/0xa0
>  [<080616a0>] start_kernel_proc+0x0/0x30
>  [<081e1e88>] __restore+0x0/0x8
>  [<081e20e1>] kill+0x11/0x20

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] 2.6.9-bb3 on 2.6.9 host problem - triggering a host bug?

[Bodo Stroesser]

Blaisorblade wrote:
> On Monday 29 November 2004 23:15, Blaisorblade wrote:
> 
> However, I've now discovered that it only happens when CONFIG_STATIC_LINK is 
> enabled - that makes the kernel die. The interesting thing is that it becomes 
> unkillable
Have found the reason for the task to become unkillable, i.e. state 'D'.

There is a bug in 2.6.9 and up in fs/exec.c

If the kernel does coredump_wait(), it tries to kill all other threads, that are
running on the same mm. Therefore it calls "force_sig_specific(SIGKILL, p)".
But if one of the threads is on a ptrace-stop, SIGKILL has no effect.
The killing thread will wait forever in "D".

Bodo


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] 2.6.9-bb3 on 2.6.9 host problem - triggering a host bug?

[Bodo Stroesser]

Blaisorblade wrote:
> On Monday 29 November 2004 23:15, Blaisorblade wrote:
> 
> However, I've now discovered that it only happens when CONFIG_STATIC_LINK is 
> enabled - that makes the kernel die. The interesting thing is that it becomes 
> unkillable
Have found the reason for the task to become unkillable, i.e. state 'D'.

There is a bug in 2.6.9 and up in fs/exec.c

If the kernel does coredump_wait(), it tries to kill all other threads, that are
running on the same mm. Therefore it calls "force_sig_specific(SIGKILL, p)".
But if one of the threads is on a ptrace-stop, SIGKILL has no effect.
The killing thread will wait forever in "D".

Bodo

Re: [uml-devel] 2.6.9-bb3 on 2.6.9 host problem - triggering a host bug?

[Bodo Stroesser]

Blaisorblade wrote:
> On Monday 29 November 2004 23:15, Blaisorblade wrote:
> 
> I pressed Enter before filling in details - this is what I get on some UML 
> versions at startup. Specifically, I get it on -bb3, and on versions based on 
> it, on startup. I've tried removing the patches I've added to -bb3 and it 
> still does not work, which is not nice.
> 
Have started to analyze the crash. If I did it right, the crash occurs at the
beginning of kmem_cache_alloc(). It seems to be called with argument NULL as the
pointer to the cache --> segfault.

Hope, this helps.

Bodo


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] 2.6.9-bb3 on 2.6.9 host problem - triggering a host bug?

[Blaisorblade]

On Wednesday 01 December 2004 20:05, Bodo Stroesser wrote:
> Blaisorblade wrote:
> > On Monday 29 November 2004 23:15, Blaisorblade wrote:
> >
> > I pressed Enter before filling in details - this is what I get on some
> > UML versions at startup. Specifically, I get it on -bb3, and on versions
> > based on it, on startup. I've tried removing the patches I've added to
> > -bb3 and it still does not work, which is not nice.
>
> Have started to analyze the crash. If I did it right, the crash occurs at
> the beginning of kmem_cache_alloc(). It seems to be called with argument
> NULL as the pointer to the cache --> segfault.

> Hope, this helps.

> Bodo

Well, this crash (or something such) is easily repeatable if you disable TT 
mode when building and enable CONFIG_STATIC_LINK.

It is related, probably, either to some patches which went in *after* 
2.6.7-1um (at that time, there was still a separate patch to apply on top of 
the corrisponding kernel), or to some problems with the toolchain. I should 
build a 2.6.7-1um kernel with STATIC_LINK to verify that it works (and then 
that we broke it) or that it doesn't (and then it's the toolchain/build env), 
but I keep forgetting to do it.

Bye
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel