Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Alexander Nyberg]

> I can crash a host repeatedly just by running a UML instance
> (and causing some load on that instance - like running gcc)
> I captured these messages from the serial console after it crashed:
> 
> Host: Linux x86_64 2.6.11.8 (built with selinux but not enforcing)
> Guest: 2.6.12-rc3-uml
> The UML patch applied on top of rc3 is available here:
> http://213.228.237.37/uml/2.6.12-rc3/uml-x86_64-2.6.12-rc3.patch.bz2
> It was built using the instructions from Jeff Dike at:
> http://user-mode-linux.sourceforge.net/patches.html
> The thread 'kernel-4' is the UML instance, running as a nobody user.
> This was reported to the UML ML and Jeff Dike who advised me to
> post it here too.
> Let me know if you need anything else / testing / etc.
> I am not subscribed to LKML, so please CC me on all emails.


I never get uml to compile around here, 2.6.12-rc3 + that patchkit from
the link you sent blows up with defconfig any my minimal config. Please
attach your guest .config and if you can you might aswell put your guest
vmlinux somewhere where i can download it too.

> general protection fault: 0000 [1]
> CPU 0
> Pid: 26926, comm: kernel-4 Not tainted 2.6.11.8
> RIP: 0010:[<ffffffff8010ca47>] <ffffffff8010ca47>{__switch_to+311}
> RSP: 0018:ffff8100a7635d48  EFLAGS: 00010016
> RAX: 0000c8e816000002 RBX: ffff8100b895f320 RCX: 00000000c0000102
> RDX: 000000000000c8e8 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: 0000000000000000 R08: ffff810090db3a00 R09: 0000000000006933
> R10: 0000000000000000 R11: 0000000000000202 R12: ffff8100a827b890
> R13: ffff8100b895f010 R14: ffff8100a827b580 R15: ffff8100a827b7f8
> FS:  000000006025212c(0000) GS:ffffffff80785a00(0000)
> knlGS:0000000000000d7e
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 000000006880d010 CR3: 00000000a2321000 CR4: 00000000000006e0
> Process kernel-4 (pid: 26926, threadinfo ffff810060884000, task
> ffff8100a827b580)
> Stack: ffff8100dc37e180 ffff8100b895f010 ffffffff806b6d50
> ffff8100b895f010
>        000003595b049ed6 ffffffff804f4de4 ffff8100a7635de8
> 0000000000000086
>        0000007500000020 ffff8100b895f010
> Call Trace:<ffffffff804f4de4>{thread_return+0}
> <ffffffff8013cb08>{ptrace_stop+280}
>        <ffffffff8013cde6>{get_signal_to_deliver+358}
> <ffffffff8010d4e3>{do_signal+163}
>        <ffffffff8010e905>{error_exit+0}
> <ffffffff8010de67>{sys_rt_sigreturn+535}
>        <ffffffff8010dee9>{sys_rt_sigreturn+665}
> <ffffffff8010e2b6>{int_signal+18}
> 

2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Antoine Martin]

I can crash a host repeatedly just by running a UML instance
(and causing some load on that instance - like running gcc)
I captured these messages from the serial console after it crashed:

Host: Linux x86_64 2.6.11.8 (built with selinux but not enforcing)
Guest: 2.6.12-rc3-uml
The UML patch applied on top of rc3 is available here:
http://213.228.237.37/uml/2.6.12-rc3/uml-x86_64-2.6.12-rc3.patch.bz2
It was built using the instructions from Jeff Dike at:
http://user-mode-linux.sourceforge.net/patches.html
The thread 'kernel-4' is the UML instance, running as a nobody user.
This was reported to the UML ML and Jeff Dike who advised me to
post it here too.
Let me know if you need anything else / testing / etc.
I am not subscribed to LKML, so please CC me on all emails.

general protection fault: 0000 [1]
CPU 0
Pid: 26926, comm: kernel-4 Not tainted 2.6.11.8
RIP: 0010:[<ffffffff8010ca47>] <ffffffff8010ca47>{__switch_to+311}
RSP: 0018:ffff8100a7635d48  EFLAGS: 00010016
RAX: 0000c8e816000002 RBX: ffff8100b895f320 RCX: 00000000c0000102
RDX: 000000000000c8e8 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: ffff810090db3a00 R09: 0000000000006933
R10: 0000000000000000 R11: 0000000000000202 R12: ffff8100a827b890
R13: ffff8100b895f010 R14: ffff8100a827b580 R15: ffff8100a827b7f8
FS:  000000006025212c(0000) GS:ffffffff80785a00(0000)
knlGS:0000000000000d7e
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000006880d010 CR3: 00000000a2321000 CR4: 00000000000006e0
Process kernel-4 (pid: 26926, threadinfo ffff810060884000, task
ffff8100a827b580)
Stack: ffff8100dc37e180 ffff8100b895f010 ffffffff806b6d50
ffff8100b895f010
       000003595b049ed6 ffffffff804f4de4 ffff8100a7635de8
0000000000000086
       0000007500000020 ffff8100b895f010
Call Trace:<ffffffff804f4de4>{thread_return+0}
<ffffffff8013cb08>{ptrace_stop+280}
       <ffffffff8013cde6>{get_signal_to_deliver+358}
<ffffffff8010d4e3>{do_signal+163}
       <ffffffff8010e905>{error_exit+0}
<ffffffff8010de67>{sys_rt_sigreturn+535}
       <ffffffff8010dee9>{sys_rt_sigreturn+665}
<ffffffff8010e2b6>{int_signal+18}


Code: 0f 30 66 41 89 6c 24 2e 65 48 8b 04 25 20 00 00 00 49 89 44
RIP <ffffffff8010ca47>{__switch_to+311} RSP <ffff8100a7635d48>
 <0>general protection fault: 0000 [2]
CPU 0
Pid: 3, comm: events/0 Not tainted 2.6.11.8
RIP: 0010:[<ffffffff8010ca47>] <ffffffff8010ca47>{__switch_to+311}
RSP: 0018:ffff8100a7635d48  EFLAGS: 00010016
RAX: 0000c8e816000002 RBX: ffff8100b895f320 RCX: 00000000c0000102
RDX: 000000000000c8e8 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000000d
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8100fbf909f0
R13: ffff8100b895f010 R14: ffff8100fbf906e0 R15: ffff8100fbf90950
FS:  000000006025212c(0000) GS:ffffffff80785a00(0000)
knlGS:0000000000000d7e
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000006880d010 CR3: 00000000a2321000 CR4: 00000000000006e0
Process events/0 (pid: 3, threadinfo ffff8100fbfaa000, task
ffff8100fbf906e0)
Stack: ffff8100dc37e180 ffff8100b895f010 ffffffff806b6d50
ffff8100b895f010
       00000359c1aeb8da ffffffff804f4de4 ffff8100a7635de8
0000000000000086
       0000007500000020 ffff8100b895f010
Call Trace:<ffffffff804f4de4>{thread_return+0}
<ffffffff8013cb08>{ptrace_stop+280}
       <ffffffff8013cde6>{get_signal_to_deliver+358}
<ffffffff8010d4e3>{do_signal+163}
       <ffffffff8010e905>{error_exit+0}
<ffffffff8010de67>{sys_rt_sigreturn+535}
       <ffffffff8010dee9>{sys_rt_sigreturn+665}
<ffffffff8010e2b6>{int_signal+18}


Code: 0f 30 66 41 89 6c 24 2e 65 48 8b 04 25 20 00 00 00 49 89 44
RIP <ffffffff8010ca47>{__switch_to+311} RSP <ffff8100a7635d48>
 <1>Unable to handle kernel NULL pointer dereference at 0000000000000278
RIP:
<ffffffff804f4c99>{schedule+873}
PGD c8175067 PUD 31aea067 PMD 0
Oops: 0002 [3]
CPU 0
Pid: 3, comm: events/0 Not tainted 2.6.11.8
RIP: 0010:[<ffffffff804f4c99>] <ffffffff804f4c99>{schedule+873}
RSP: 0018:ffff8100a7635b68  EFLAGS: 00010007
RAX: 0000000002d3ca44 RBX: 0000000000000000 RCX: ffff810090db3a00
RDX: 000000003b9ac880 RSI: ffff8100b895f010 RDI: ffff8100fbf906e0
RBP: ffff8100a7635bc8 R08: 0000000000000000 R09: 000000000000000d
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff806b6d50
R13: ffff8100b895f010 R14: 0000035a27fb7d77 R15: ffff8100fbf90950
FS:  000000006025212c(0000) GS:ffffffff80785a00(0000)
knlGS:0000000000000d7e
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000278 CR3: 00000000a2321000 CR4: 00000000000006e0
Process events/0 (pid: 3, threadinfo ffff8100fbfaa000, task
ffff8100fbf906e0)
Stack: 0000007300000000 ffff8100fbf906e0 0000000000000180
ffff8100b895f010
       ffffffff806a6fc0 0000000000000000 ffff8100fbf906e0
ffff8100a7635be8
       ffff8100fbf906e0 ffff8100fbf91440
Call Trace:<ffffffff801347a7>{do_exit+2535} <ffffffff8010f5ac>{oops_end
+28}
       <ffffffff8010f6e5>{die+69}
<ffffffff801100fe>{do_general_protection+270}
       <ffffffff8010e905>{error_exit+0} <ffffffff8010ca47>{__switch_to
+311}
       <ffffffff804f4de4>{thread_return+0}
<ffffffff8013cb08>{ptrace_stop+280}
       <ffffffff8013cde6>{get_signal_to_deliver+358}
<ffffffff8010d4e3>{do_signal+163}
       <ffffffff8010e905>{error_exit+0}
<ffffffff8010de67>{sys_rt_sigreturn+535}
       <ffffffff8010dee9>{sys_rt_sigreturn+665}
<ffffffff8010e2b6>{int_signal+18}


Code: 0f ba b3 78 02 00 00 00 0f ba a9 78 02 00 00 00 48 8b 51 38
RIP <ffffffff804f4c99>{schedule+873} RSP <ffff8100a7635b68>
CR2: 0000000000000278
 <1>Unable to handle kernel NULL pointer dereference at 0000000000000000
RIP:
<ffffffff8012e134>{dequeue_task+4}
PGD c8175067 PUD 31aea067 PMD 0
Oops: 0002 [4]
CPU 0
Pid: 3, comm: events/0 Not tainted 2.6.11.8
RIP: 0010:[<ffffffff8012e134>] <ffffffff8012e134>{dequeue_task+4}
RSP: 0018:ffff8100a76358c8  EFLAGS: 00010006
RAX: 0000000000000020 RBX: ffff8100fbf906e0 RCX: ffff8100fbf90718
RDX: ffff8100fbf906e0 RSI: 0000000000000000 RDI: ffff8100fbf906e0
RBP: ffff8100a76358d8 R08: 0000000000000000 R09: 000000000000000d
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8100fbf906e0
R13: ffff8100fbf91440 R14: 0000035aa7f554c4 R15: ffff8100fbf90950
FS:  000000006025212c(0000) GS:ffffffff80785a00(0000)
knlGS:0000000000000d7e
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 00000000a2321000 CR4: 00000000000006e0
Process events/0 (pid: 3, threadinfo ffff8100fbfaa000, task
ffff8100fbf906e0)
Stack: ffffffff8012e3d4 ffff8100a7635968 ffff8100a7635948
ffffffff804f4ae2
       0000000000000000 ffff8100fbf906e0 00000000069f6bc7
ffffffff801301bf
       00000000ffffff01 0000000000000000
Call Trace:<ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8010e905>{error_exit+0} <ffffffff804f4c99>{schedule+873}
       <ffffffff804f4ae2>{schedule+434} <ffffffff801347a7>{do_exit+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8010f6e5>{die+69}
       <ffffffff801100fe>{do_general_protection+270}
<ffffffff8010e905>{error_exit+0}
       <ffffffff8010ca47>{__switch_to+311}
<ffffffff804f4de4>{thread_return+0}
       <ffffffff8013cb08>{ptrace_stop+280}
<ffffffff8013cde6>{get_signal_to_deliver+358}
       <ffffffff8010d4e3>{do_signal+163} <ffffffff8010e905>{error_exit
+0}
       <ffffffff8010de67>{sys_rt_sigreturn+535}
<ffffffff8010dee9>{sys_rt_sigreturn+665}
       <ffffffff8010e2b6>{int_signal+18}

Code: ff 0e 55 48 8b 47 38 48 8b 51 08 48 89 e5 48 89 02 48 89 50
RIP <ffffffff8012e134>{dequeue_task+4} RSP <ffff8100a76358c8>
CR2: 0000000000000000
 <1>Unable to handle kernel NULL pointer dereference at 0000000000000000
RIP:
<ffffffff8012e134>{dequeue_task+4}
PGD c8175067 PUD 31aea067 PMD 0
Oops: 0002 [5]
CPU 0
Pid: 3, comm: events/0 Not tainted 2.6.11.8
RIP: 0010:[<ffffffff8012e134>] <ffffffff8012e134>{dequeue_task+4}
RSP: 0018:ffff8100a7635628  EFLAGS: 00010002
RAX: 0000000000000020 RBX: ffff8100fbf906e0 RCX: ffff8100fbf90718
RDX: ffff8100fbf906e0 RSI: 0000000000000000 RDI: ffff8100fbf906e0
RBP: ffff8100a7635638 R08: 0000000000000000 R09: 000000000000000d
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8100fbf906e0
R13: ffff8100fbf91440 R14: 0000035b3fc7d274 R15: ffff8100fbf90950
FS:  000000006025212c(0000) GS:ffffffff80785a00(0000)
knlGS:0000000000000d7e
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 00000000a2321000 CR4: 00000000000006e0
Process events/0 (pid: 3, threadinfo ffff8100fbfaa000, task
ffff8100fbf906e0)
Stack: ffffffff8012e3d4 ffff8100a76356c8 ffff8100a76356a8
ffffffff804f4ae2
       0000000000000000 ffff8100fbf906e0 00000000069f6bc7
ffffffff801301bf
       00000000ffffff01 0000000000000000
Call Trace:<ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8010e905>{error_exit+0} <ffffffff804f4c99>{schedule+873}
       <ffffffff804f4ae2>{schedule+434} <ffffffff801347a7>{do_exit+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8010f6e5>{die+69}
       <ffffffff801100fe>{do_general_protection+270}
<ffffffff8010e905>{error_exit+0}
       <ffffffff8010ca47>{__switch_to+311}
<ffffffff804f4de4>{thread_return+0}
       <ffffffff8013cb08>{ptrace_stop+280}
<ffffffff8013cde6>{get_signal_to_deliver+358}
       <ffffffff8010d4e3>{do_signal+163} <ffffffff8010e905>{error_exit
+0}
       <ffffffff8010de67>{sys_rt_sigreturn+535}
<ffffffff8010dee9>{sys_rt_sigreturn+665}
       <ffffffff8010e2b6>{int_signal+18}

Code: ff 0e 55 48 8b 47 38 48 8b 51 08 48 89 e5 48 89 02 48 89 50
RIP <ffffffff8012e134>{dequeue_task+4} RSP <ffff8100a7635628>
CR2: 0000000000000000
 <1>Unable to handle kernel NULL pointer dereference at 0000000000000000
RIP:
<ffffffff8012e134>{dequeue_task+4}
PGD c8175067 PUD 31aea067 PMD 0
Oops: 0002 [6]
CPU 0
Pid: 3, comm: events/0 Not tainted 2.6.11.8
RIP: 0010:[<ffffffff8012e134>] <ffffffff8012e134>{dequeue_task+4}
RSP: 0018:ffff8100a7635388  EFLAGS: 00010006
RAX: 0000000000000020 RBX: ffff8100fbf906e0 RCX: ffff8100fbf90718
RDX: ffff8100fbf906e0 RSI: 0000000000000000 RDI: ffff8100fbf906e0
RBP: ffff8100a7635398 R08: 0000000000000000 R09: 000000000000000d
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8100fbf906e0
R13: ffff8100fbf91440 R14: 0000035bf2d22de7 R15: ffff8100fbf90950
FS:  000000006025212c(0000) GS:ffffffff80785a00(0000)
knlGS:0000000000000d7e
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 00000000a2321000 CR4: 00000000000006e0
Process events/0 (pid: 3, threadinfo ffff8100fbfaa000, task
ffff8100fbf906e0)
Stack: ffffffff8012e3d4 ffff8100a7635428 ffff8100a7635408
ffffffff804f4ae2
       0000000000000000 ffff8100fbf906e0 00000000069f6bc7
ffffffff801301bf
       00000000ffffff01 0000000000000000
Call Trace:<ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8010e905>{error_exit+0} <ffffffff804f4c99>{schedule+873}
       <ffffffff804f4ae2>{schedule+434} <ffffffff801347a7>{do_exit+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8010f6e5>{die+69}
       <ffffffff801100fe>{do_general_protection+270}
<ffffffff8010e905>{error_exit+0}
       <ffffffff8010ca47>{__switch_to+311}
<ffffffff804f4de4>{thread_return+0}
       <ffffffff8013cb08>{ptrace_stop+280}
<ffffffff8013cde6>{get_signal_to_deliver+358}
       <ffffffff8010d4e3>{do_signal+163} <ffffffff8010e905>{error_exit
+0}
       <ffffffff8010de67>{sys_rt_sigreturn+535}
<ffffffff8010dee9>{sys_rt_sigreturn+665}
       <ffffffff8010e2b6>{int_signal+18}

Code: ff 0e 55 48 8b 47 38 48 8b 51 08 48 89 e5 48 89 02 48 89 50
RIP <ffffffff8012e134>{dequeue_task+4} RSP <ffff8100a7635388>
CR2: 0000000000000000
 <1>Unable to handle kernel NULL pointer dereference at 0000000000000000
RIP:
<ffffffff8012e134>{dequeue_task+4}
PGD c8175067 PUD 31aea067 PMD 0
Oops: 0002 [7]
CPU 0
Pid: 3, comm: events/0 Not tainted 2.6.11.8
RIP: 0010:[<ffffffff8012e134>] <ffffffff8012e134>{dequeue_task+4}
RSP: 0018:ffff8100a76350e8  EFLAGS: 00010006
RAX: 0000000000000020 RBX: ffff8100fbf906e0 RCX: ffff8100fbf90718
RDX: ffff8100fbf906e0 RSI: 0000000000000000 RDI: ffff8100fbf906e0
RBP: ffff8100a76350f8 R08: 0000000000000000 R09: 000000000000000d
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8100fbf906e0
R13: ffff8100fbf91440 R14: 0000035cc114f6cf R15: ffff8100fbf90950
FS:  000000006025212c(0000) GS:ffffffff80785a00(0000)
knlGS:0000000000000d7e
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 00000000a2321000 CR4: 00000000000006e0
Process events/0 (pid: 3, threadinfo ffff8100fbfaa000, task
ffff8100fbf906e0)
Stack: ffffffff8012e3d4 ffff8100a7635188 ffff8100a7635168
ffffffff804f4ae2
       0000000000000000 ffff8100fbf906e0 00000000069f6bc7
ffffffff801301bf
       00000000ffffff01 0000000000000000
Call Trace:<ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8010e905>{error_exit+0} <ffffffff804f4c99>{schedule+873}
       <ffffffff804f4ae2>{schedule+434} <ffffffff801347a7>{do_exit+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8010f6e5>{die+69}
       <ffffffff801100fe>{do_general_protection+270}
<ffffffff8010e905>{error_exit+0}
       <ffffffff8010ca47>{__switch_to+311}
<ffffffff804f4de4>{thread_return+0}
       <ffffffff8013cb08>{ptrace_stop+280}
<ffffffff8013cde6>{get_signal_to_deliver+358}
       <ffffffff8010d4e3>{do_signal+163} <ffffffff8010e905>{error_exit
+0}
       <ffffffff8010de67>{sys_rt_sigreturn+535}
<ffffffff8010dee9>{sys_rt_sigreturn+665}
       <ffffffff8010e2b6>{int_signal+18}

Code: ff 0e 55 48 8b 47 38 48 8b 51 08 48 89 e5 48 89 02 48 89 50
RIP <ffffffff8012e134>{dequeue_task+4} RSP <ffff8100a76350e8>
CR2: 0000000000000000
 <1>Unable to handle kernel NULL pointer dereference at 0000000000000000
RIP:
<ffffffff8012e134>{dequeue_task+4}
PGD c8175067 PUD 31aea067 PMD 0
Oops: 0002 [8]
CPU 0
Pid: 3, comm: events/0 Not tainted 2.6.11.8
RIP: 0010:[<ffffffff8012e134>] <ffffffff8012e134>{dequeue_task+4}
RSP: 0018:ffff8100a7634e48  EFLAGS: 00010002
RAX: 0000000000000020 RBX: ffff8100fbf906e0 RCX: ffff8100fbf90718
RDX: ffff8100fbf906e0 RSI: 0000000000000000 RDI: ffff8100fbf906e0
RBP: ffff8100a7634e58 R08: 0000000000000000 R09: 000000000000000d
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8100fbf906e0
R13: ffff8100fbf91440 R14: 0000035daaa6e647 R15: ffff8100fbf90950
FS:  000000006025212c(0000) GS:ffffffff80785a00(0000)
knlGS:0000000000000d7e
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 00000000a2321000 CR4: 00000000000006e0
Process events/0 (pid: 3, threadinfo ffff8100fbfaa000, task
ffff8100fbf906e0)
Stack: ffffffff8012e3d4 ffff8100a7634ee8 ffff8100a7634ec8
ffffffff804f4ae2
       0000000000000000 ffff8100fbf906e0 00000000069f6bc7
ffffffff801301bf
       00000000ffffff01 0000000000000000
Call Trace:<ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8010e905>{error_exit+0} <ffffffff804f4c99>{schedule+873}
       <ffffffff804f4ae2>{schedule+434} <ffffffff801347a7>{do_exit+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8010f6e5>{die+69}
       <ffffffff801100fe>{do_general_protection+270}
<ffffffff8010e905>{error_exit+0}
       <ffffffff8010ca47>{__switch_to+311}
<ffffffff804f4de4>{thread_return+0}
       <ffffffff8013cb08>{ptrace_stop+280}
<ffffffff8013cde6>{get_signal_to_deliver+358}
       <ffffffff8010d4e3>{do_signal+163} <ffffffff8010e905>{error_exit
+0}
       <ffffffff8010de67>{sys_rt_sigreturn+535}
<ffffffff8010dee9>{sys_rt_sigreturn+665}
       <ffffffff8010e2b6>{int_signal+18}

Code: ff 0e 55 48 8b 47 38 48 8b 51 08 48 89 e5 48 89 02 48 89 50
RIP <ffffffff8012e134>{dequeue_task+4} RSP <ffff8100a7634e48>
CR2: 0000000000000000
 <1>Unable to handle kernel NULL pointer dereference at 0000000000000000
RIP:
<ffffffff8012e134>{dequeue_task+4}
PGD c8175067 PUD 31aea067 PMD 0
Oops: 0002 [9]
CPU 0
Pid: 3, comm: events/0 Not tainted 2.6.11.8
RIP: 0010:[<ffffffff8012e134>] <ffffffff8012e134>{dequeue_task+4}
RSP: 0018:ffff8100a7634ba8  EFLAGS: 00010002
RAX: 0000000000000020 RBX: ffff8100fbf906e0 RCX: ffff8100fbf90718
RDX: ffff8100fbf906e0 RSI: 0000000000000000 RDI: ffff8100fbf906e0
RBP: ffff8100a7634bb8 R08: 0000000000000000 R09: 000000000000000d
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8100fbf906e0
R13: ffff8100fbf91440 R14: 0000035eaf57d638 R15: ffff8100fbf90950
FS:  000000006025212c(0000) GS:ffffffff80785a00(0000)
knlGS:0000000000000d7e
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 00000000a2321000 CR4: 00000000000006e0
Process events/0 (pid: 3, threadinfo ffff8100fbfaa000, task
ffff8100fbf906e0)
Stack: ffffffff8012e3d4 ffff8100a7634c48 ffff8100a7634c28
ffffffff804f4ae2
       0000000000000000 ffff8100fbf906e0 00000000069f6bc7
ffffffff801301bf
       00000000ffffff01 0000000000000000
Call Trace:<ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8010e905>{error_exit+0} <ffffffff804f4c99>{schedule+873}
       <ffffffff804f4ae2>{schedule+434} <ffffffff801347a7>{do_exit+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8010f6e5>{die+69}
       <ffffffff801100fe>{do_general_protection+270}
<ffffffff8010e905>{error_exit+0}
       <ffffffff8010ca47>{__switch_to+311}
<ffffffff804f4de4>{thread_return+0}
       <ffffffff8013cb08>{ptrace_stop+280}
<ffffffff8013cde6>{get_signal_to_deliver+358}
       <ffffffff8010d4e3>{do_signal+163} <ffffffff8010e905>{error_exit
+0}
       <ffffffff8010de67>{sys_rt_sigreturn+535}
<ffffffff8010dee9>{sys_rt_sigreturn+665}
       <ffffffff8010e2b6>{int_signal+18}

Code: ff 0e 55 48 8b 47 38 48 8b 51 08 48 89 e5 48 89 02 48 89 50
RIP <ffffffff8012e134>{dequeue_task+4} RSP <ffff8100a7634ba8>
CR2: 0000000000000000
 <1>Unable to handle kernel NULL pointer dereference at 0000000000000000
RIP:
<ffffffff8012e134>{dequeue_task+4}
PGD c8175067 PUD 31aea067 PMD 0
Oops: 0002 [10]
CPU 0
Pid: 3, comm: events/0 Not tainted 2.6.11.8
RIP: 0010:[<ffffffff8012e134>] <ffffffff8012e134>{dequeue_task+4}
RSP: 0018:ffff8100a7634908  EFLAGS: 00010002
RAX: 0000000000000020 RBX: ffff8100fbf906e0 RCX: ffff8100fbf90718
RDX: ffff8100fbf906e0 RSI: 0000000000000000 RDI: ffff8100fbf906e0
RBP: ffff8100a7634918 R08: 0000000000000000 R09: 000000000000000d
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8100fbf906e0
R13: ffff8100fbf91440 R14: 0000035fcf41c4f5 R15: ffff8100fbf90950
FS:  000000006025212c(0000) GS:ffffffff80785a00(0000)
knlGS:0000000000000d7e
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 00000000a2321000 CR4: 00000000000006e0
Process events/0 (pid: 3, threadinfo ffff8100fbfaa000, task
ffff8100fbf906e0)
Stack: ffffffff8012e3d4 ffff8100a76349a8 ffff8100a7634988
ffffffff804f4ae2
       0000000000000000 ffff8100fbf906e0 00000000069f6bc7
ffffffff801301bf
       00000000ffffff01 0000000000000000
Call Trace:<ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8010e905>{error_exit+0} <ffffffff804f4c99>{schedule+873}
       <ffffffff804f4ae2>{schedule+434} <ffffffff801347a7>{do_exit+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8010f6e5>{die+69}
       <ffffffff801100fe>{do_general_protection+270}
<ffffffff8010e905>{error_exit+0}
       <ffffffff8010ca47>{__switch_to+311}
<ffffffff804f4de4>{thread_return+0}
       <ffffffff8013cb08>{ptrace_stop+280}
<ffffffff8013cde6>{get_signal_to_deliver+358}
       <ffffffff8010d4e3>{do_signal+163} <ffffffff8010e905>{error_exit
+0}
       <ffffffff8010de67>{sys_rt_sigreturn+535}
<ffffffff8010dee9>{sys_rt_sigreturn+665}
       <ffffffff8010e2b6>{int_signal+18}

Code: ff 0e 55 48 8b 47 38 48 8b 51 08 48 89 e5 48 89 02 48 89 50
RIP <ffffffff8012e134>{dequeue_task+4} RSP <ffff8100a7634908>
CR2: 0000000000000000
 <1>Unable to handle kernel NULL pointer dereference at 0000000000000000
RIP:
<ffffffff8012e134>{dequeue_task+4}
PGD c8175067 PUD 31aea067 PMD 0
Oops: 0002 [11]
CPU 0
Pid: 3, comm: events/0 Not tainted 2.6.11.8
RIP: 0010:[<ffffffff8012e134>] <ffffffff8012e134>{dequeue_task+4}
RSP: 0018:ffff8100a7634668  EFLAGS: 00010002
RAX: 0000000000000020 RBX: ffff8100fbf906e0 RCX: ffff8100fbf90718
RDX: ffff8100fbf906e0 RSI: 0000000000000000 RDI: ffff8100fbf906e0
RBP: ffff8100a7634678 R08: 0000000000000000 R09: 000000000000000d
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8100fbf906e0
R13: ffff8100fbf91440 R14: 000003610a89cc6d R15: ffff8100fbf90950
FS:  000000006025212c(0000) GS:ffffffff80785a00(0000)
knlGS:0000000000000d7e
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 00000000a2321000 CR4: 00000000000006e0
Process events/0 (pid: 3, threadinfo ffff8100fbfaa000, task
ffff8100fbf906e0)
Stack: ffffffff8012e3d4 ffff8100a7634708 ffff8100a76346e8
ffffffff804f4ae2
       0000000000000000 ffff8100fbf906e0 00000000069f6bc7
ffffffff801301bf
       00000000ffffff01 0000000000000000
Call Trace:<ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8013218c>{__call_console_drivers+76}
<ffffffff8032d55b>{scrup+123}
       <ffffffff8010e905>{error_exit+0} <ffffffff8012e134>{dequeue_task
+4}
       <ffffffff8012e3d4>{deactivate_task+20}
<ffffffff804f4ae2>{schedule+434}
       <ffffffff801301bf>{mm_release+47} <ffffffff801347a7>{do_exit
+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8011f4cf>{do_page_fault
+1855}
       <ffffffff8010e905>{error_exit+0} <ffffffff804f4c99>{schedule+873}
       <ffffffff804f4ae2>{schedule+434} <ffffffff801347a7>{do_exit+2535}
       <ffffffff8010f5ac>{oops_end+28} <ffffffff8010f6e5>{die+69}
       <ffffffff801100fe>{do_general_protection+270}
<ffffffff8010e905>{error_exit+0}
       <ffffffff8010ca47>{__switch_to+311}
<ffffffff804f4de4>{thread_return+0}
       <ff

Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Jeff Dike]

On Sat, May 07, 2005 at 05:57:48PM +0200, Alexander Nyberg wrote:
> I never get uml to compile around here, 2.6.12-rc3 + that patchkit from
> the link you sent blows up with defconfig any my minimal config. Please
> attach your guest .config and if you can you might aswell put your guest
> vmlinux somewhere where i can download it too.

Start with -rc3, and all the patches from
	http://user-mode-linux.sf.net/patches.html
up to and including skas0.  You'll see a note to x86_64 users on that patch.

				Jeff

Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Antoine Martin]

> I never get uml to compile around here, 2.6.12-rc3 + that patchkit from
> the link you sent blows up with defconfig any my minimal config. Please
> attach your guest .config and if you can you might aswell put your guest
> vmlinux somewhere where i can download it too.
ok, here it is:
http://213.228.237.37/uml/2.6.12-rc3/
kernel and config.

Note: you will need a pure 64bit root fs, ie: gentoo 2005 works fine.

Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Al Viro]

On Sat, May 07, 2005 at 02:03:56PM -0400, Jeff Dike wrote:
> On Sat, May 07, 2005 at 05:57:48PM +0200, Alexander Nyberg wrote:
> > I never get uml to compile around here, 2.6.12-rc3 + that patchkit from
> > the link you sent blows up with defconfig any my minimal config. Please
> > attach your guest .config and if you can you might aswell put your guest
> > vmlinux somewhere where i can download it too.
> 
> Start with -rc3, and all the patches from
> 	http://user-mode-linux.sf.net/patches.html
> up to and including skas0.  You'll see a note to x86_64 users on that patch.

Hrm...
	a) stub.S handling breaks on O= builds.   Actually, your unprofile
breaks there - it's bypassing the machinery that deals with include path.
	b) stub_segv.c on amd64 includes <signal.h>.  Not a good idea...
	c) sysdep-x86_64/checksum.h in -rc4 has csum_partial_copy_from_user()
that needs updating (AFAICS, you have that in your patchset, but it hadn't
reached Linus)
	d) ip_compute_csum() prototype is missing (same file)
	e) #define UPT_SYSCALL_RET(r) UPT_RAX(r) is needed in amd64 ptrace.h
	f) take a good look at UPT_SET() in the same file ;-)
	g) CFLAGS_csum-partial.o := -Dcsum_partial=arch_csum_partial in
sys-x86_64/Makefile needs to be removed.
	h) Makefile.rules should be included _after_ SYMLINKS = in the same
file.
	i) sys-x86_64/delay.c needs exports of __udelay() and __const_udelay(),
include of linux/module.h and barriers in your delay loop bodies (or games
with volatile - anything that would guarantee that gcc won't decide to optimize
the entire loop away).  The last part applies to i386 as well.
	j) ip_compute_csum should be exported on amd64.
	k) sys-x86_64/syscalls.c needs include "kern.h"
	l) elf-i386.h should include <asm/user.h>, not "user.h"
	m) elf-x86_64.h lacks R_X86_64_... definitions
	n) WTF _is_ that #ifdef TIF_IA32 in there?  Aside of the trailing \,
we could as well put #error there - free-floating clear_thread_flag(TIF_IA32);
outside of any function body will have that effect anyway.
	o) in drivers/chan_kern.c we have several printf(KERN_ERR "...");
these should become printk, as they clearly had been intended.  As it is,
they give instant panic if we ever call them.
	p) TOP_ADDR in Kconfig_x86_64 got lost in transmission - your patchset
has it, but same patch in Linus' tree does not.

I've got patches for everything except (a); that one is really nasty.  I hope
to sort it out by tonight; if not, I'll just send what I've got by now.

Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Al Viro]

On Sun, May 08, 2005 at 01:18:32AM +0100, Al Viro wrote:
> 	a) stub.S handling breaks on O= builds.   Actually, your unprofile
> breaks there - it's bypassing the machinery that deals with include path.

Solved.

> 	p) TOP_ADDR in Kconfig_x86_64 got lost in transmission - your patchset
> has it, but same patch in Linus' tree does not.

	q) skas/mmu.c is calling pte_alloc_map() without ->page_table_lock.
Trivially fixed, needed if you want spinlock debugging to produce something
useful.
	r) when built static, kernel dies ugly death with
#0  0x00000000601e4178 in ptmalloc_init () at swab.h:134
#1  0x00000000601e4034 in malloc_hook_ini () at swab.h:134
#2  0x00000000601e1698 in malloc () at swab.h:134
#3  0x00000000602068ee in _dl_init_paths () at swab.h:134
#4  0x00000000601eba45 in _dl_non_dynamic_init () at swab.h:134
#5  0x00000000601ebc60 in __libc_init_first () at swab.h:134
#6  0x00000000601cfa4f in __libc_start_main () at swab.h:134
#7  0x000000006001202a in _start () at proc_fs.h:183
as stack trace.  Buggered offsets in uml.lds, perhaps?

Dynamically built it works; for i386 the same tree works both with both
static and dynamic.  It _might_ be libc difference, in theory (i386 libc
is 2.3.2.ds1-18, amd64 - 2.3.2.ds1-21, both from sarge), but I wouldn't
bet on it.  Anyway, I'm going down right now; carving the fixes into
sane patch series + experimenting with static/amd64 breakage will have
to wait until the morning...

Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Andi Kleen]

Antoine Martin <antoine@nagafix.co.uk> writes:
>
> general protection fault: 0000 [1]
> CPU 0
> Pid: 26926, comm: kernel-4 Not tainted 2.6.11.8
> RIP: 0010:[<ffffffff8010ca47>] <ffffffff8010ca47>{__switch_to+311}
> RSP: 0018:ffff8100a7635d48  EFLAGS: 00010016
> RAX: 0000c8e816000002 RBX: ffff8100b895f320 RCX: 00000000c0000102
> RDX: 000000000000c8e8 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: 0000000000000000 R08: ffff810090db3a00 R09: 0000000000006933
> R10: 0000000000000000 R11: 0000000000000202 R12: ffff8100a827b890
> R13: ffff8100b895f010 R14: ffff8100a827b580 R15: ffff8100a827b7f8
> FS:  000000006025212c(0000) GS:ffffffff80785a00(0000)
> knlGS:0000000000000d7e
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 000000006880d010 CR3: 00000000a2321000 CR4: 00000000000006e0
> Process kernel-4 (pid: 26926, threadinfo ffff810060884000, task
> ffff8100a827b580)
> Stack: ffff8100dc37e180 ffff8100b895f010 ffffffff806b6d50
> ffff8100b895f010
>        000003595b049ed6 ffffffff804f4de4 ffff8100a7635de8
> 0000000000000086
>        0000007500000020 ffff8100b895f010
> Call Trace:<ffffffff804f4de4>{thread_return+0}
> <ffffffff8013cb08>{ptrace_stop+280}
>        <ffffffff8013cde6>{get_signal_to_deliver+358}
> <ffffffff8010d4e3>{do_signal+163}
>        <ffffffff8010e905>{error_exit+0}
> <ffffffff8010de67>{sys_rt_sigreturn+535}
>        <ffffffff8010dee9>{sys_rt_sigreturn+665}
> <ffffffff8010e2b6>{int_signal+18}
>
>
> Code: 0f 30 66 41 89 6c 24 2e 65 48 8b 04 25 20 00 00 00 49 89 44

That is a wrmsr to 0x00000000c0000102 (KERNEL_GS_BASE), the code 
is trying to write 0x0000c8e816000002 into it. That is a non canonical
address, which causes the GPF.

The strange thing is that the kernel should have rejected it in
the first place. The code to allow user space to set kernel gs 
checks for the address being > TASK_SIZE and TASK_SIZE is 0x800000000000.
It should have rejected it in the first place.

Are you sure you did not apply any strange UML related patches
to the host kernel? Maybe those are buggy.

-Andi

Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Andi Kleen]

Antoine Martin <antoine@nagafix.co.uk> writes:

>> (..)
>> That is a wrmsr to 0x00000000c0000102 (KERNEL_GS_BASE), the code 
>> is trying to write 0x0000c8e816000002 into it. That is a non canonical
>> address, which causes the GPF.
>> 
>> The strange thing is that the kernel should have rejected it in
>> the first place. The code to allow user space to set kernel gs 
>> checks for the address being > TASK_SIZE and TASK_SIZE is 0x800000000000.
>> It should have rejected it in the first place.
>> 
>> Are you sure you did not apply any strange UML related patches
>> to the host kernel? Maybe those are buggy.
> The only extra patch applied on top of what is on the web page (as per
> Jeff's instructions) is the mconsole-exec patch, and AFAIK it wouldn't
> affect the code above.
>
> Alexander Nyberg is also experiencing crashes, aren't you?


Ok, the bug is found now. It is a kernel bug that it allows to set
non canonical addresses in 64bit segment registers through ptrace.

But even if I fixed that then it will not help you run UML, because
UML needs to set correct addresses of course, not illegal ones.

I will submit a patch later for the crash problem.

-Andi

Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Jeff Dike]

On Sun, May 08, 2005 at 01:18:32AM +0100, Al Viro wrote:
> Hrm...

I had a lot of these fixed already.  These will be mostly in the fixlets
patch.

> 	a) stub.S handling breaks on O= builds.   Actually, your unprofile
> breaks there - it's bypassing the machinery that deals with include path.

This?
	$(patsubst -pg,,$(patsubst -fprofile-arcs -ftest-coverage,,$(1)))

I don't see any connection to include paths there.


> 	b) stub_segv.c on amd64 includes <signal.h>.  Not a good idea...

x86_64 doesn't, but i386 does.  Fixed now.

> 	c) sysdep-x86_64/checksum.h in -rc4 has csum_partial_copy_from_user()
> that needs updating (AFAICS, you have that in your patchset, but it hadn't
> reached Linus)

Fixed.

> 	d) ip_compute_csum() prototype is missing (same file)
> 	j) ip_compute_csum should be exported on amd64.

OK, I need to look at this a bit more.

> 	e) #define UPT_SYSCALL_RET(r) UPT_RAX(r) is needed in amd64 ptrace.h

Fixed.

> 	f) take a good look at UPT_SET() in the same file ;-)

Sigh.  Fixed now.

> 	g) CFLAGS_csum-partial.o := -Dcsum_partial=arch_csum_partial in
> sys-x86_64/Makefile needs to be removed.

Fixed.

> 	h) Makefile.rules should be included _after_ SYMLINKS = in the same
> file.

Fixed.

> 	i) sys-x86_64/delay.c needs exports of __udelay() and __const_udelay(),
> include of linux/module.h and barriers in your delay loop bodies (or games
> with volatile - anything that would guarantee that gcc won't decide to optimize
> the entire loop away).  The last part applies to i386 as well.

Looks to me like it all applies to i386 too, except that __delay looks 
unoptimizable.

It also looks to me like I could implement __udelay as n=... ; __delay(n);

And also never mind the fact that __udelay and __const_udelay are identical.

> 	k) sys-x86_64/syscalls.c needs include "kern.h"

Fixed now.

> 	l) elf-i386.h should include <asm/user.h>, not "user.h"

Fixed now.

> 	m) elf-x86_64.h lacks R_X86_64_... definitions

Fixed now.

> 	n) WTF _is_ that #ifdef TIF_IA32 in there?  Aside of the trailing \,
> we could as well put #error there - free-floating clear_thread_flag(TIF_IA32);> outside of any function body will have that effect anyway.

The trailing \ aside, which is fixed, that's a reminder for me when I add
the 32-bit compatibility code.

> 	o) in drivers/chan_kern.c we have several printf(KERN_ERR "...");
> these should become printk, as they clearly had been intended.  As it is,
> they give instant panic if we ever call them.

Oops.  This requires a bit of thought.  Offhand, I think they need to be 
printf, because that early in boot, printk'd stuff may not reach the screen
if UML exits then.

> 	p) TOP_ADDR in Kconfig_x86_64 got lost in transmission - your patchset
> has it, but same patch in Linus' tree does not.

Fixed

> 
> I've got patches for everything except (a); that one is really nasty.  I hope
> to sort it out by tonight; if not, I'll just send what I've got by now.

OK, send me what you have, and if we've fixed the same thing differently,
I choose one or the other.

				Jeff

Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Antoine Martin]

> (..)
> That is a wrmsr to 0x00000000c0000102 (KERNEL_GS_BASE), the code 
> is trying to write 0x0000c8e816000002 into it. That is a non canonical
> address, which causes the GPF.
> 
> The strange thing is that the kernel should have rejected it in
> the first place. The code to allow user space to set kernel gs 
> checks for the address being > TASK_SIZE and TASK_SIZE is 0x800000000000.
> It should have rejected it in the first place.
> 
> Are you sure you did not apply any strange UML related patches
> to the host kernel? Maybe those are buggy.
The only extra patch applied on top of what is on the web page (as per
Jeff's instructions) is the mconsole-exec patch, and AFAIK it wouldn't
affect the code above.

Alexander Nyberg is also experiencing crashes, aren't you?
Just un-compressing portage (20MB .tar.bz2) on the root_fs image posted
earlier caused a different kind of mis-behaviour, the guest lost network
connectivity, cpu usage shot up on the host (load > 10 now), and I found
this in the host log:
kernel: segfault at 00000000df2948d0 rip 00000000601e5beb
rsp00000000df2948d0 error 4
(same kernel as earlier crashes...)
That's on a different box, running a different host kernel (FC3 2.6.9-?)

The really weird thing is that the processes are still running, but ps
-ef shows an empty string in place of the process name:
(and the terminal which launched the instance got control back)
I am now rebuilding a new kernel on another test box, let me know what
to do to provide better debug information.

# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 13:27 ?        00:00:00 init [3]
root         2     1  0 13:27 ?        00:00:00 [ksoftirqd/0]
root         3     1  0 13:27 ?        00:00:00 [events/0]
root         4     3  0 13:27 ?        00:00:00 [khelper]
root         5     3  0 13:27 ?        00:00:00 [kacpid]
root        27     3  0 13:27 ?        00:00:00 [kblockd/0]
root        28     1  0 13:27 ?        00:00:00 [khubd]
root        40     3  0 13:27 ?        00:00:00 [pdflush]
root        41     3  0 13:27 ?        00:00:00 [pdflush]
root        43     3  0 13:27 ?        00:00:00 [aio/0]
root        42     1  0 13:27 ?        00:00:00 [kswapd0]
root       115     1  0 13:27 ?        00:00:00 [kseriod]
root       183     3  0 13:27 ?        00:00:00 [ata/0]
root       185     1  0 13:27 ?        00:00:00 [scsi_eh_0]
root       186     1  0 13:27 ?        00:00:00 [scsi_eh_1]
root       202     1  0 13:27 ?        00:00:00 [kjournald]
root      1025     1  0 13:27 ?        00:00:00 udevd
root      1261     1  0 13:27 ?        00:00:00 [khpsbpkt]
root      1290     1  0 13:27 ?        00:00:00 [knodemgrd_0]
root      1453     1  0 13:27 ?        00:00:00 [kjournald]
root      1454     1  0 13:27 ?        00:00:00 [kjournald]
root      1693     1  0 13:28 ?        00:00:00 syslogd -m 0
root      1697     1  0 13:28 ?        00:00:00 klogd -x
nobody    1737     1  0 13:28 ?        00:00:00 mDNSResponder
root      1755     1  0 13:28 ?        00:00:00 /usr/sbin/acpid
root      1770     1  0 13:28 ?        00:00:00 /usr/sbin/sshd
root      1779     1  0 13:28 ?        00:00:00 gpm -m /dev/input/mice
-t imps2
root      1809     1  0 13:28 ?        00:00:00 crond
dbus      1833     1  0 13:28 ?        00:00:00 dbus-daemon-1 --system
root      1842     1  0 13:28 ?        00:00:00 hald
root      1849     1  0 13:28 ?        00:00:00 login -- root
root      1850     1  0 13:28 tty2     00:00:00 /sbin/mingetty tty2
root      1851     1  0 13:28 tty3     00:00:00 /sbin/mingetty tty3
root      1852     1  0 13:28 tty4     00:00:00 /sbin/mingetty tty4
root      1853     1  0 13:28 tty5     00:00:00 /sbin/mingetty tty5
root      1854     1  0 13:28 tty6     00:00:00 /sbin/mingetty tty6
root      2270  1849  0 13:31 tty1     00:00:00 -bash
root      2312  1770  0 13:31 ?        00:00:00 sshd: root@pts/0
root      2314  2312  0 13:32 pts/0    00:00:00 -bash
root      2363  2314 19 13:36 pts/0    00:30:19 ./setiathome
root      4346  1770  0 15:03 ?        00:00:00 sshd: root@pts/1
root      4350  4346  0 15:03 pts/1    00:00:00 -bash
root      5291  4350  0 15:14 pts/1    00:00:00 tail
-f /var/log/messages /var/log/secure
root      6179     1  0 15:16 pts/0    00:00:35
root      7231     1  0 15:16 pts/0    00:00:35
root      7252     1  0 15:16 pts/0    00:00:35
root      7345     1  0 15:17 ?        00:00:00 /usr/sbin/dhcpd
root      7352     1  0 15:17 pts/0    00:00:34
root      7485     1  0 15:17 pts/0    00:00:34
root      7509     1  0 15:17 pts/0    00:00:34
root      7520  1770  0 15:18 ?        00:00:00 sshd: root@pts/2
root      7522  7520  0 15:18 pts/2    00:00:00 -bash
root      7561  7522  0 15:18 pts/2    00:00:00 ssh -v root@10.0.0.250
root      7563     1  1 15:18 pts/0    00:00:35
root      7571     1  1 15:18 pts/0    00:00:35
root     10302  1770  0 15:57 ?        00:00:00 sshd: root@pts/3
root     10304 10302  0 15:57 pts/3    00:00:00 -bash
root     10422     1  8 16:08 pts/0    00:00:38
root     10424     1  9 16:08 pts/0    00:00:42
root     10445  2314  0 16:16 pts/0    00:00:00 ps -ef

Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Jeff Dike]

> Are you sure you did not apply any strange UML related patches
> to the host kernel? Maybe those are buggy.

No, stock x86_64 kernel is horribly unstable running UML.  I haven't seen
anything but output-free hangs, so I haven't had much information to 
contribute.  Antoine is actually getting capturable oopses.

I've tried every recent FC3 kernel, plus stock 2.6.10, and none of them
survive very long with UML running.  Haven't tried stock 2.6.11 or anything
later yet.

				Jeff

Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Jeff Dike]

On Sun, May 08, 2005 at 05:15:36PM +0200, Andi Kleen wrote:
> Antoine Martin <antoine@nagafix.co.uk> writes:
> Ok, the bug is found now. It is a kernel bug that it allows to set
> non canonical addresses in 64bit segment registers through ptrace.
> 
> But even if I fixed that then it will not help you run UML, because
> UML needs to set correct addresses of course, not illegal ones.

True, but if the host stays up, and maybe printks something (or even returns
 -EIO), that would help track down the UML problem.

				Jeff

Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Jeff Dike]

On Sun, May 08, 2005 at 05:35:02PM +0100, Antoine Martin wrote:
> The only extra patch applied on top of what is on the web page (as per
> Jeff's instructions) is the mconsole-exec patch, and AFAIK it wouldn't
> affect the code above.

mconsole-exec, if it's the patch I'm thinking of, is a patch to the UML
kernel, not to the host.

> The really weird thing is that the processes are still running, but ps
> -ef shows an empty string in place of the process name:
> (and the terminal which launched the instance got control back)
> I am now rebuilding a new kernel on another test box, let me know what
> to do to provide better debug information.

It's not unusual for UML processes to have strange names (including empty
ones) on the host.

				Jeff

Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Antoine Martin]

> Ok, the bug is found now. It is a kernel bug that it allows to set
> non canonical addresses in 64bit segment registers through ptrace.
Is this going to be part of 2.6.11.9 or just 2.6.12?
I've got a good test environment now if you need testers.

Antoine

Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Antoine Martin]

On Sun, 2005-05-08 at 12:45 -0400, Jeff Dike wrote:
> On Sun, May 08, 2005 at 05:35:02PM +0100, Antoine Martin wrote:
> > The only extra patch applied on top of what is on the web page (as per
> > Jeff's instructions) is the mconsole-exec patch, and AFAIK it wouldn't
> > affect the code above.
> 
> mconsole-exec, if it's the patch I'm thinking of, is a patch to the UML
> kernel, not to the host.
Yep, that's the one, I thought the question was about the guest.
The host is running 2.6.11.8 - no extra patches at all.

> > The really weird thing is that the processes are still running, but ps
> > -ef shows an empty string in place of the process name:
> > (and the terminal which launched the instance got control back)
> > I am now rebuilding a new kernel on another test box, let me know what
> > to do to provide better debug information.
> 
> It's not unusual for UML processes to have strange names (including empty
> ones) on the host.
Strange thing is, they had names up to the point where I got the
segfault.

Antoine

Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Al Viro]

On Sun, May 08, 2005 at 07:10:44AM +0100, Al Viro wrote:
> 	r) when built static, kernel dies ugly death with
> #0  0x00000000601e4178 in ptmalloc_init () at swab.h:134
> #1  0x00000000601e4034 in malloc_hook_ini () at swab.h:134
> #2  0x00000000601e1698 in malloc () at swab.h:134
> #3  0x00000000602068ee in _dl_init_paths () at swab.h:134
> #4  0x00000000601eba45 in _dl_non_dynamic_init () at swab.h:134
> #5  0x00000000601ebc60 in __libc_init_first () at swab.h:134
> #6  0x00000000601cfa4f in __libc_start_main () at swab.h:134
> #7  0x000000006001202a in _start () at proc_fs.h:183
> as stack trace.  Buggered offsets in uml.lds, perhaps?

Apparently solved by adding .tdata and .tbss to uml.lds.S.  That change does
not give any visible regression on i386.

	s) i386 TT-only won't compile, due to mispaced include in
sysdep/ptrace.h (under ifdef for skas).  Trivial fix apparently gets it
to work correctly.  Which is surprising - when running that sucker on
amd64 we get zero from
        *host_size_out = ROUND_4M((unsigned long) &arg);
Of course, the real size rounded up to 4M is 4Gb there - 32bit tasks do not
have to share the lower 4Gb of address space with the kernel.  Looks like
we survive, though - it boots and apparently works both on i386 and (as
32bit process) on amd64.
	t) amd64 TT-only builds just fine, but gets buggered due to
mismatch between CONFIG_TOP_ADDR and start address - we get *both* set
to 0x60000000, which is obviously b0rken and doesn't match the old
code, while we are at it.  We want TOP_ADDR at 0x80000000 to match start
address.
	u) amd64 TT is _still_ buggered due to unmap_fin.o attempts at
magic.  errno sits in TLS for amd64, so unmap_fin.o gets very interesting
stuff leaking from libc and messing the link.  IMO that should be dealt
with by brute force; namely, unmap-$(SUBARCH).S instead of trying to
play games with pulling stuff from libc.a.  For fsck sake, we are just
making 3 syscalls there and switcheroo() is as low-level as it gets...
Will post once that's done...

Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Al Viro]

On Mon, May 09, 2005 at 10:07:53PM +0100, Al Viro wrote:
> 	u) amd64 TT is _still_ buggered due to unmap_fin.o attempts at
> magic.  errno sits in TLS for amd64, so unmap_fin.o gets very interesting
> stuff leaking from libc and messing the link.  IMO that should be dealt
> with by brute force; namely, unmap-$(SUBARCH).S instead of trying to
> play games with pulling stuff from libc.a.  For fsck sake, we are just
> making 3 syscalls there and switcheroo() is as low-level as it gets...
> Will post once that's done...
	OK, actually - C with use of _syscall(); still, per-architecture
due to different calling conventions (mmap() has enough arguments to
trigger irregularities).  That deals with errno / __libc_errno getting
screwed, but there's more...

	v) phys_mappings rbtree gets screwed in fixrange_init() - no
surprise, seeing what it does in
        for ( ; (i < PTRS_PER_PGD) && (vaddr < end); pgd++, i++) {
                pmd = (pmd_t *)pgd;
                for (; (j < PTRS_PER_PMD) && (vaddr != end); pmd++, j++) {
Note that here PTR_PER_PGD and PTRS_PER_PMD are both 512.  Fun...  Liberal
stealing from arch/i386/mm/init.c deals with that one, AFAICS.  Now we have
the following:
	uml/i386 - all variants work
	uml/amd64 TT-only - panics in execve() on /sbin/init (hey, a progress)
	uml/amd64 other variants - work
Now to figure out WTF is happening in that execve()...

Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Jeff Dike]

On Tue, May 10, 2005 at 03:26:31AM +0100, Al Viro wrote:
> Now we have
> the following:
> 	uml/i386 - all variants work
> 	uml/amd64 TT-only - panics in execve() on /sbin/init (hey, a progress)
> 	uml/amd64 other variants - work

Nice, send patches when you get a chance?

				Jeff

Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Al Viro]

On Mon, May 09, 2005 at 11:50:52PM -0400, Jeff Dike wrote:
> On Tue, May 10, 2005 at 03:26:31AM +0100, Al Viro wrote:
> > Now we have
> > the following:
> > 	uml/i386 - all variants work
> > 	uml/amd64 TT-only - panics in execve() on /sbin/init (hey, a progress)
> > 	uml/amd64 other variants - work
> 
> Nice, send patches when you get a chance?

ftp.linux.org.uk/pub/people/viro/UM*-RC12-rc4.  The first one is your skas0
rediffed to -rc4, the rest - fixes (matching the bug list upthread; the
last two are actually older than the rest, missed them in the original list
of bugs; one is obvious missing include, another is dereferencing userland
pointer instead of dealing with copied value + missing chunk in amd64/tt
sc_copy_...).

[uml-devel] Re: Problems applying patches to 2.6.12-rc5-mm1

[antoine]

Note: this is an attempt at running it on x86_64 host, so the errors
may or may not be the same...

I applied the patches on the website to 2.6.12-rc5 (mm1 and mm2: most
patches apply cleanly to both, some have been merged in mm2 obviously),
I got an error here:

gcc   -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -ffreestanding -O2 -fno-omit-frame-pointer
-fno-optimize-sibling-calls -g -U__x86_64__ -fno-builtin -D__arch_um__
-DSUBARCH=\"x86_64\" -Iarch/um/include
-I/usr/src/linux-2.6.12-rc5-mm2-uml/arch/um/kernel/tt/include
-D__x86_64__ -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -c -o
arch/um/sys-x86_64/stub_segv.o arch/um/sys-x86_64/stub_segv.c
In file included from /usr/include/asm/ucontext.h:2,
                 from arch/um/sys-x86_64/stub_segv.c:8:
/usr/include/asm/../asm-x86_64/ucontext.h:4: error: redefinition of
`struct ucontext'

I removed the #include "ucontext", and added #include "uml-config.h" to
stub_segv.c. Then it got stuck on:
fixdep: arch/um/sys-x86_64/.stub_segv.o.d: No such file or directory
Re-running the build as suggested by Jeff did not help, but
creating an empty file to make it proceed seems to work...
`touch arch/um/sys-x86_64/.stub_segv.o.d`
(I haven't tried removing the av-skas patch yet)

Then it builds and almost runs:
(...)
[42949373.260000] kjournald starting.  Commit interval 5 seconds
[42949373.260000] EXT3-fs: mounted filesystem with ordered data mode.
[42949373.260000] VFS: Mounted root (ext3 filesystem) readonly.
[42949373.260000] Kernel panic - not syncing: Kernel mode fault at addr
0x0, ip 0x0
[42949373.260000]
[42949373.260000] Pid: 1, comm: bash Not tainted 2.6.12-rc5-mm2
[42949373.260000] RIP: 0000:[<0000000000000000>]
[42949373.260000] RSP: 0000000060453c30  EFLAGS: 00010202
[42949373.260000] RAX: 0000000000000001 RBX: 0000000000000000 RCX:
0000000060194ec1
[42949373.260000] RDX: 000000006002840d RSI: 0000000000000001 RDI:
0000000060453ad0
[42949373.260000] RBP: 0000000000000000 R08: 0000000000000000 R09:
0000000000000000
[42949373.260000] R10: 0000000000000008 R11: 0000000000000246 R12:
0000000000000000
[42949373.260000] R13: 0000000000000001 R14: 000000000000000a R15:
0000000000000000
[42949373.260000] Call Trace:
[42949373.260000] 604536d8:  [<6001575f>] panic_exit+0x2f/0x50
[42949373.260000] 604536f8:  [<60040c2b>] notifier_call_chain+0x2b/0x50
[42949373.260000] 60453728:  [<6002fe24>] panic+0xe4/0x180
[42949373.260000] 60453768:  [<60194ec1>] __sigprocmask+0x11/0x40
[42949373.260000] 60453788:  [<6010e0b3>] __up_read+0xb3/0xf0
[42949373.260000] 604537a8:  [<60014908>] handle_page_fault+0xc8/0x280
[42949373.260000] 604537d8:  [<6002a1ef>] __do_user_copy+0x4f/0xd0
[42949373.260000] 60453818:  [<60014caa>] segv+0x1ea/0x2b0
[42949373.260000] 60453828:  [<60194f85>] sigemptyset+0x15/0x40
[42949373.260000] 60453838:  [<60028d71>] change_sig+0x61/0x80
[42949373.260000] 604538a8:  [<60194f85>] sigemptyset+0x15/0x40
[42949373.260000] 604538b8:  [<60028de1>] change_signals+0x51/0x80
[42949373.260000] 60453928:  [<60015056>] segv_handler+0x106/0x120
[42949373.260000] 60453958:  [<60014f50>] segv_handler+0x0/0x120
[42949373.260000] 60453968:  [<60017fc9>] sig_handler_common_tt
+0x119/0x1b0
[42949373.260000] 604539d8:  [<60028a80>] sig_handler+0x10/0x20
[42949373.260000] 604539e8:  [<60194c40>] __restore_rt+0x0/0x10
[42949373.260000] 60453a78:  [<6002840d>] run_kernel_thread+0x2d/0x50
[42949373.260000] 60453a88:  [<60194ec1>] __sigprocmask+0x11/0x40
[42949373.260000] 60453ae0:  [<6000f1b0>] init+0x0/0x100
[42949373.260000] 60453b08:  [<6002840d>] run_kernel_thread+0x2d/0x50
[42949373.260000] 60453b88:  [<6000f1b0>] init+0x0/0x100
[42949373.260000] 60453b98:  [<60028e2e>] unblock_signals+0xe/0x10
[42949373.260000] 60453ba8:  [<60016456>] new_thread_handler+0x166/0x1a0
[42949373.260000] 60453cd8:  [<60194ec1>] __sigprocmask+0x11/0x40
[42949373.260000]
[42949373.260000]

Now, I am really stuck.
Any ideas?

Cheers
Antoine


On Sat, 2005-05-28 at 20:07 +0100, antoine wrote:
> Hi Jeff,
> 
> Now that the ptrace host bug has been fixed in 2.6.11.11, I can run
> tests on shared systems without taking too many risks, but I am a little
> bit lost as to which patches I would need to apply, between your
> patches, Blaisorblade's, al's,.. Which all seem to contain x86_64
> patches. Let me know what I can do to help testing. I am sure I can find
> some new bugs, in fact I am working on a Java VM bug atm.
> 
> Cheers
> Antoine
> 
> 
> On Mon, 2005-05-09 at 01:57 +0100, Antoine Martin wrote:
> > Crashing it is quite easy in fact, reiserfs as root_fs just won't work.
> > I don't think this trace is going to help, but here it is anyway:
> > 
> > [42949381.990000] REISERFS: panic (device Null superblock):
> > reiserfs[175]: assertion !( comp_keys( &MAX_KEY, p_s_key ) && !
> > key_in_buffer(p_s_search_path, p_s_key, p_s_sb) ) failed at
> > fs/reiserfs/stree.c:685:search_by_key: PAP-5130: key is not in the
> > buffer
> > [42949381.990000] Kernel panic - not syncing: BUG!
> > [42949381.990000]  [42949381.990000]
> > 
> > 
> > On Sun, 2005-05-08 at 23:20 +0100, Antoine Martin wrote:
> > > All good, builds fine and hasn't crashed yet!
> > > I'll get back to you with (hopefully) more useful debugging information
> > > as soon as Andi Kleen comes up with a patch for the host bug.
> > > 
> > > Antoine
> > > 
> > > On Sun, 2005-05-08 at 14:35 -0400, Jeff Dike wrote:
> > > > I uploaded a new set of patches which patches, builds, and runs on both
> > > > i386 and x86_64.
> > > > 
> > > > On Sun, May 08, 2005 at 06:37:19PM +0100, Antoine Martin wrote:
> > > > > I noticed that you updated the website with patches against -rc4 so I
> > > > > built the beast, As before, I had to do this to fix it:
> > > > > cd include/asm
> > > > > ln -sf elf-x86_64.h elf.h
> > > > 
> > > > I get an empty elf.h which obviously causes build problems.  Removing it
> > > > and rebuilding fixes it.  I haven't looked at this yet.
> > > > 
> > > > > I also had a reject on:
> > > > > arch/um/sys-x86_64/Makefile
> > > > 
> > > > This should be OK now.
> > > > 
> > > > 				Jeff



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Jeff Dike]

On Thu, Jun 02, 2005 at 06:51:22AM +0100, antoine wrote:
> I applied the patches on the website to 2.6.12-rc5 (mm1 and mm2: most
> patches apply cleanly to both, some have been merged in mm2 obviously),
> I got an error here:

I pushed out a fixed set of patches (against -mm2) that work for me.

There were some include changes in stub_segv.c.

The .d file thing is still there.  That seems to have been caused by my 
changing stub_segv.c to a userspace file.

				Jeff


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[antoine]

Thanks, almost all applied cleanly - I skipped the s390 ones for now.
Compiling still requires a `touch arch/um/sys-x86_64/.stub_segv.o.d` to
make it proceed. Works for me! (tm)
But I can't get it to boot into init properly, I can only boot with
init=/bin/bash. (then remount root rw, mount proc)

Every time I run a command, I get something like:
bash: child setpgid (15484 to 15484): No such process
(I remember seeing this one before - but I can't remember the
solution :-(

I can bring the network up manually (ifconfig) and ping (in and out),
but running any of the /etc/init.d/ scripts locks up, same goes for
starting sshd or even "Hello World" in hello.sh

Sometimes when it goes into a spin, it loos on this (to infinity):
"[42949450.500000] fix_range_common: failed, killing current process"

Not sure where do go from here... Maybe patching with just the minimum?
It needs roughly at least up to fix-tt-USR1-handlers to be able to boot
(otherwise you get the error I posted yesterday).

Antoine




On Thu, 2005-06-02 at 17:06 -0400, Jeff Dike wrote:
> On Thu, Jun 02, 2005 at 06:51:22AM +0100, antoine wrote:
> > I applied the patches on the website to 2.6.12-rc5 (mm1 and mm2: most
> > patches apply cleanly to both, some have been merged in mm2 obviously),
> > I got an error here:
> 
> I pushed out a fixed set of patches (against -mm2) that work for me.
> 
> There were some include changes in stub_segv.c.
> 
> The .d file thing is still there.  That seems to have been caused by my 
> changing stub_segv.c to a userspace file.
> 
> 				Jeff



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
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] Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Jeff Dike]

On Fri, Jun 03, 2005 at 03:33:36AM +0100, antoine wrote:
> Thanks, almost all applied cleanly - I skipped the s390 ones for now.

I wouldn't cherry-pick patches.  You may be right, but it also means you're
running different code than me.

> I can bring the network up manually (ifconfig) and ping (in and out),
> but running any of the /etc/init.d/ scripts locks up, same goes for
> starting sshd or even "Hello World" in hello.sh

Dunno, it works here, and I've beat on it a bunch.  If you can get stack
traces or anything from the hangs, that might help.

				Jeff


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
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] Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Jeff Dike]

On Fri, Jun 03, 2005 at 08:28:10PM +0100, antoine wrote:
> I think there is still a memory leak lurking, OOM seems to kick in (see
> bottom of this email)

Yeah, it's a page leak, I think from page tables, which I haven't tracked
down yet.

> Very minor thing: I noticed that the TT threads generally do not show
> which process they are running inside the UML (as it used to), any way
> to restore this?

Those aren't tt threads, they are skas0 threads, and we could probably restore 
the command names, but I haven't bothered doing so.

				Jeff


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
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] Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Bodo Stroesser]

Jeff Dike wrote:
> On Fri, Jun 03, 2005 at 08:28:10PM +0100, antoine wrote:
> 
>>I think there is still a memory leak lurking, OOM seems to kick in (see
>>bottom of this email)
> 
> 
> Yeah, it's a page leak, I think from page tables, which I haven't tracked
> down yet.
> 
> 
>>Very minor thing: I noticed that the TT threads generally do not show
>>which process they are running inside the UML (as it used to), any way
>>to restore this?
> 
> 
> Those aren't tt threads, they are skas0 threads, and we could probably restore 
> the command names, but I haven't bothered doing so.
I thought about doing so, as the output of ps really looks bad.
Unfortunately, I found only very nasty ways.
On older host's, we could try to expand or strip down the environment in a similar
way as is used it tt. Then, names could be placed into stub-(stack?)-page.
Nasty, but it could work.
An even worse case is a host using stack-randomization. We need a pointer in the
host poining to stub-pages. If the host has left a "hole" above the stack, would
we have to "exec" until accidentally we get a stack starting at upper address-range
limit?
		Bodo
> 
> 				Jeff
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
> a projector? How fast can you ride your desk chair down the office luge track?
> If you want to score the big prize, get to know the little guy.  
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> User-mode-linux-devel mailing list
> User-mode-linux-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
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] Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[antoine]

On Thu, 2005-06-02 at 22:38 -0400, Jeff Dike wrote:
> On Fri, Jun 03, 2005 at 03:33:36AM +0100, antoine wrote:
> > Thanks, almost all applied cleanly - I skipped the s390 ones for now.
> 
> I wouldn't cherry-pick patches.  You may be right, but it also means you're
> running different code than me.
I wouldn't normally do that, but there is a patch that does not apply
cleanly: fp-state (can't find file to patch at input line 28 ...)
So I started thinking that there were things I did not necessarily need
or want (s390, x11fb, audio, etc) - I guess I was wrong...

I started again, applying everything else, some files complained about
missing skas.h or proc_mm.h, another case of empty file, easy fix:
rm ./arch/um/kernel/skas/include/skas.h

I got tired of doing the same steps over and over again (to be sure I
wasn't reporting my own mistakes) so I made this very simple script to
untar kernel source + apply MM + apply UML patches:
http://213.228.237.37/uml/2.6.12-rc5-mm2/make-uml64.sh
I've also dumped the compile errors, kernel binary, .config in the same
directory.

Everything kinda works now! And it is *very* fast (compared to TT x86
guest) And this time it is a bit more stable.
I think there is still a memory leak lurking, OOM seems to kick in (see
bottom of this email)

Very minor thing: I noticed that the TT threads generally do not show
which process they are running inside the UML (as it used to), any way
to restore this?

Thanks
Antoine


> 
> > I can bring the network up manually (ifconfig) and ping (in and out),
> > but running any of the /etc/init.d/ scripts locks up, same goes for
> > starting sshd or even "Hello World" in hello.sh
> 
> Dunno, it works here, and I've beat on it a bunch.  If you can get stack
> traces or anything from the hangs, that might help.
> 
> 				Jeff
*********
* OOM
* 128RAM + 128swap should be enough to emerge things...
*********

[42951416.180000] oom-killer: gfp_mask=0xd2
[42951416.180000] DMA per-cpu:
[42951416.180000] cpu 0 hot: low 30, high 90, batch 15
[42951416.180000] cpu 0 cold: low 0, high 30, batch 15
[42951416.180000] Normal per-cpu: empty
[42951416.180000] HighMem per-cpu: empty
[42951416.180000]
[42951416.180000] Free pages:        1432kB (0kB HighMem)
[42951416.180000] Active:166 inactive:333 dirty:0 writeback:0 unstable:0
free:358 slab:999 mapped:82 pagetables:9547
[42951416.180000] DMA free:1432kB min:1448kB low:1808kB high:2172kB
active:664kB inactive:1332kB present:131072kB pages_scanned:1301
[42951416.180000] lowmem_reserve[]: 0 0 0
[42951416.180000] Normal free:0kB min:0kB low:0kB high:0kB active:0kB
inactive:0kB present:0kB pages_scanned:0
[42951416.180000] lowmem_reserve[]: 0 0 0
[42951416.180000] HighMem free:0kB min:128kB low:160kB high:192kB
active:0kB inactive:0kB present:0kB pages_scanned:0
[42951416.180000] lowmem_reserve[]: 0 0 0
[42951416.180000] DMA: 0*4kB 5*8kB 1*16kB 1*32kB 1*64kB 0*128kB 1*256kB
0*512kB 1*1024kB 0*2048kB 0*4096kB = 1432kB
[42951416.180000] Normal: empty
[42951416.180000] HighMem: empty
[42951416.180000] Swap cache: add 314384, delete 314009, find
48066/104534, race 0+0
[42951416.180000] Free swap  = 112048kB
[42951416.180000] Total swap = 131064kB
[42951416.180000] Out of Memory: Killed process 978 (emerge).
[42951416.180000] oom-killer: gfp_mask=0xd2
[42951416.180000] DMA per-cpu:
[42951416.180000] cpu 0 hot: low 30, high 90, batch 15
[42951416.180000] cpu 0 cold: low 0, high 30, batch 15
[42951416.180000] Normal per-cpu: empty
[42951416.180000] HighMem per-cpu: empty
[42951416.180000]
[42951416.180000] Free pages:        1432kB (0kB HighMem)
[42951416.180000] Active:166 inactive:333 dirty:0 writeback:0 unstable:0
free:358 slab:1000 mapped:82 pagetables:9519
[42951416.180000] DMA free:1432kB min:1448kB low:1808kB high:2172kB
active:664kB inactive:1332kB present:131072kB pages_scanned:1301
[42951416.180000] lowmem_reserve[]: 0 0 0
[42951416.180000] Normal free:0kB min:0kB low:0kB high:0kB active:0kB
inactive:0kB present:0kB pages_scanned:0
[42951416.180000] lowmem_reserve[]: 0 0 0
[42951416.180000] HighMem free:0kB min:128kB low:160kB high:192kB
active:0kB inactive:0kB present:0kB pages_scanned:0
[42951416.180000] lowmem_reserve[]: 0 0 0
[42951416.180000] DMA: 0*4kB 5*8kB 1*16kB 1*32kB 1*64kB 0*128kB 1*256kB
0*512kB 1*1024kB 0*2048kB 0*4096kB = 1432kB
[42951416.180000] Normal: empty
[42951416.180000] HighMem: empty
[42951416.180000] Swap cache: add 314384, delete 314009, find
48066/104535, race 0+0
[42951416.180000] Free swap  = 123236kB
[42951416.180000] Total swap = 131064kB
[42951416.180000] Out of Memory: Killed process 5713 (portageq).




-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel