kernel oops!

kernel oops!

[ierdnah]

Jan 22 13:27:59 warsheep Unable to handle kernel NULL pointer dereference at virtual address 00000000
Jan 22 13:27:59 warsheep printing eip:
Jan 22 13:27:59 warsheep 00000000
Jan 22 13:27:59 warsheep *pgd = cde9ddb400000000
Jan 22 13:27:59 warsheep *pmd = cde9ddb400000000
Jan 22 13:27:59 warsheep Oops: 0000 [#1]
Jan 22 13:27:59 warsheep SMP
Jan 22 13:27:59 warsheep CPU:    0
Jan 22 13:27:59 warsheep EIP:    0060:[<00000000>]    Not tainted VLI
Jan 22 13:27:59 warsheep EFLAGS: 00010282   (2.6.10-hardened-r2-warsheep62)
Jan 22 13:27:59 warsheep EIP is at 0x0
Jan 22 13:27:59 warsheep eax: 00000000   ebx: de455000   ecx: c02c60e0   edx: c6b41000
Jan 22 13:27:59 warsheep esi: de455000   edi: 00000000   ebp: dd0a2680   esp: cde9de9c
Jan 22 13:27:59 warsheep ds: 007b   es: 007b   ss: 0068
Jan 22 13:27:59 warsheep Process pptpctrl (pid: 16689, threadinfo=cde9c000 task=d112ca20)
Jan 22 13:27:59 warsheep Stack: c02c97bc c6b41000 00000000 c02c895c de455000 04949168 c03d0106 de455000
Jan 22 13:27:59 warsheep de45500c dd0a2680 00000000 c02c4141 de455000 dd0a2680 00000000 c01c7d49
Jan 22 13:27:59 warsheep dd0a2680 00000020 00000005 00000005 c01da72f dd0a2680 00000000 00000000
Jan 22 13:27:59 warsheep Call Trace:
Jan 22 13:27:59 warsheep [<c02c97bc>] pty_chars_in_buffer+0x2c/0x50
Jan 22 13:27:59 warsheep [<c02c895c>] normal_poll+0xfc/0x16b
Jan 22 13:27:59 warsheep [<c03d0106>] schedule_timeout+0x76/0xc0
Jan 22 13:27:59 warsheep [<c02c4141>] tty_poll+0xa1/0xc0
Jan 22 13:27:59 warsheep [<c01c7d49>] fget+0x49/0x60
Jan 22 13:27:59 warsheep [<c01da72f>] do_select+0x26f/0x2e0
Jan 22 13:27:59 warsheep [<c01da2f0>] __pollwait+0x0/0xd0
Jan 22 13:27:59 warsheep [<c01daabb>] sys_select+0x2db/0x4f0
Jan 22 13:27:59 warsheep [<c0173049>] sysenter_past_esp+0x52/0x79
Jan 22 13:27:59 warsheep Code:  Bad EIP value.



The oops ocures only when the kernel is build with SMP and HT support, in UP mode the oops doesn't occur!
I have a 2.6.10 kernel with SMP and HT compiled kernel, I have a P4 3GHz with HT
a have a VPN server with pppd and pptpd(poptop) and and average of 130
simultanious connections, the oops doesn't occur at a particular number
of simulationus VPN connection.I can build a kernel with debugging enabled or something to help to track th
source of the problem. Please CC as I am not subscribed to this mailing list.

-- 
ierdnah <ierdnah@go.ro>

Re: kernel oops!

[Linus Torvalds]

Interesting. That last call trace entry is the call in 
pty_chars_in_buffer() to

        /* The ldisc must report 0 if no characters available to be read */
        count = to->ldisc.chars_in_buffer(to);

and it looks like it has jumped to address zero.

However, we _just_ compared the fn pointer to zero immediately before, and 
while there could certainly have been a race that cleared it in between 
the test and the call, normally we wouldn't even have re-loaded the value 
at all, but kept it in a register instead.

That said, it does act like a race. Somebody clearing the ldisc and racing 
with somebody using it?

Can you do a 

	gdb vmlinux

	disassemble pty_chars_in_buffer

to show what it looks like (whether it reloads the value, and what the 
registers are - it looks like either %eax or %edi is all zeroes, but I'd 
like to verify that it matches your code generation).

Alan? Any ideas? The tty_select() path seems to take a ldisc reference, 
but does that guarantee that the ldisc won't _change_? What happens if the 
line discipline is reset from ppp to regular (or set to ppp) 
asymchronously? You've been deep in this area lately..

			Linus

On Sun, 23 Jan 2005, ierdnah wrote:
> 
> Jan 22 13:27:59 warsheep Unable to handle kernel NULL pointer dereference at virtual address 00000000
> Jan 22 13:27:59 warsheep printing eip:
> Jan 22 13:27:59 warsheep 00000000
> Jan 22 13:27:59 warsheep *pgd = cde9ddb400000000
> Jan 22 13:27:59 warsheep *pmd = cde9ddb400000000
> Jan 22 13:27:59 warsheep Oops: 0000 [#1]
> Jan 22 13:27:59 warsheep SMP
> Jan 22 13:27:59 warsheep CPU:    0
> Jan 22 13:27:59 warsheep EIP:    0060:[<00000000>]    Not tainted VLI
> Jan 22 13:27:59 warsheep EFLAGS: 00010282   (2.6.10-hardened-r2-warsheep62)
> Jan 22 13:27:59 warsheep EIP is at 0x0
> Jan 22 13:27:59 warsheep eax: 00000000   ebx: de455000   ecx: c02c60e0   edx: c6b41000
> Jan 22 13:27:59 warsheep esi: de455000   edi: 00000000   ebp: dd0a2680   esp: cde9de9c
> Jan 22 13:27:59 warsheep ds: 007b   es: 007b   ss: 0068
> Jan 22 13:27:59 warsheep Process pptpctrl (pid: 16689, threadinfo=cde9c000 task=d112ca20)
> Jan 22 13:27:59 warsheep Stack: c02c97bc c6b41000 00000000 c02c895c de455000 04949168 c03d0106 de455000
> Jan 22 13:27:59 warsheep de45500c dd0a2680 00000000 c02c4141 de455000 dd0a2680 00000000 c01c7d49
> Jan 22 13:27:59 warsheep dd0a2680 00000020 00000005 00000005 c01da72f dd0a2680 00000000 00000000
> Jan 22 13:27:59 warsheep Call Trace:
> Jan 22 13:27:59 warsheep [<c02c97bc>] pty_chars_in_buffer+0x2c/0x50
> Jan 22 13:27:59 warsheep [<c02c895c>] normal_poll+0xfc/0x16b
> Jan 22 13:27:59 warsheep [<c03d0106>] schedule_timeout+0x76/0xc0
> Jan 22 13:27:59 warsheep [<c02c4141>] tty_poll+0xa1/0xc0
> Jan 22 13:27:59 warsheep [<c01c7d49>] fget+0x49/0x60
> Jan 22 13:27:59 warsheep [<c01da72f>] do_select+0x26f/0x2e0
> Jan 22 13:27:59 warsheep [<c01da2f0>] __pollwait+0x0/0xd0
> Jan 22 13:27:59 warsheep [<c01daabb>] sys_select+0x2db/0x4f0
> Jan 22 13:27:59 warsheep [<c0173049>] sysenter_past_esp+0x52/0x79
> Jan 22 13:27:59 warsheep Code:  Bad EIP value.
> 
> The oops ocures only when the kernel is build with SMP and HT support, in UP mode the oops doesn't occur!
> I have a 2.6.10 kernel with SMP and HT compiled kernel, I have a P4 3GHz with HT
> a have a VPN server with pppd and pptpd(poptop) and and average of 130
> simultanious connections, the oops doesn't occur at a particular number
> of simulationus VPN connection.I can build a kernel with debugging enabled or something to help to track th
> source of the problem. Please CC as I am not subscribed to this mailing list.
> 
> -- 
> ierdnah <ierdnah@go.ro>
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: kernel oops!

[ierdnah]

(gdb) disassemble pty_chars_in_buffer
Dump of assembler code for function pty_chars_in_buffer:
0xc02c9790 <pty_chars_in_buffer+0>:     sub    $0x8,%esp
0xc02c9793 <pty_chars_in_buffer+3>:     xor    %eax,%eax
0xc02c9795 <pty_chars_in_buffer+5>:     mov    %ebx,0x4(%esp,1)
0xc02c9799 <pty_chars_in_buffer+9>:     mov    0xc(%esp,1),%ebx
0xc02c979d <pty_chars_in_buffer+13>:    mov    0xd0(%ebx),%edx
0xc02c97a3 <pty_chars_in_buffer+19>:    test   %edx,%edx
0xc02c97a5 <pty_chars_in_buffer+21>:    je     0xc02c97ae
<pty_chars_in_buffer+30>
0xc02c97a7 <pty_chars_in_buffer+23>:    mov    0x28(%edx),%ecx
0xc02c97aa <pty_chars_in_buffer+26>:    test   %ecx,%ecx
0xc02c97ac <pty_chars_in_buffer+28>:    jne    0xc02c97b6
<pty_chars_in_buffer+38>
0xc02c97ae <pty_chars_in_buffer+30>:    mov    0x4(%esp,1),%ebx
0xc02c97b2 <pty_chars_in_buffer+34>:    add    $0x8,%esp
0xc02c97b5 <pty_chars_in_buffer+37>:    ret
0xc02c97b6 <pty_chars_in_buffer+38>:    mov    %edx,(%esp,1)
0xc02c97b9 <pty_chars_in_buffer+41>:    call   *0x28(%edx)
0xc02c97bc <pty_chars_in_buffer+44>:    mov    %eax,%edx
0xc02c97be <pty_chars_in_buffer+46>:    mov    0x4(%ebx),%eax
0xc02c97c1 <pty_chars_in_buffer+49>:    cmpw   $0x2,0x76(%eax)
0xc02c97c6 <pty_chars_in_buffer+54>:    je     0xc02c97d5
<pty_chars_in_buffer+69>
0xc02c97c8 <pty_chars_in_buffer+56>:    xor    %eax,%eax
0xc02c97ca <pty_chars_in_buffer+58>:    cmp    $0x800,%edx
0xc02c97d0 <pty_chars_in_buffer+64>:    cmovge %edx,%eax
0xc02c97d3 <pty_chars_in_buffer+67>:    jmp    0xc02c97ae
<pty_chars_in_buffer+30>
0xc02c97d5 <pty_chars_in_buffer+69>:    mov    %edx,%eax
0xc02c97d7 <pty_chars_in_buffer+71>:    jmp    0xc02c97ae
<pty_chars_in_buffer+30>
0xc02c97d9 <pty_chars_in_buffer+73>:    lea    0x0(%esi,1),%esi
End of assembler dump.

this is another compiled kernel, but is compiled with the same .config
file and same gcc version...because I only have the bzImage, how do I
convert it to vmlinux?

On Sat, 2005-01-22 at 22:43 -0800, Linus Torvalds wrote:
> Interesting. That last call trace entry is the call in 
> pty_chars_in_buffer() to
> 
>         /* The ldisc must report 0 if no characters available to be read */
>         count = to->ldisc.chars_in_buffer(to);
> 
> and it looks like it has jumped to address zero.
> 
> However, we _just_ compared the fn pointer to zero immediately before, and 
> while there could certainly have been a race that cleared it in between 
> the test and the call, normally we wouldn't even have re-loaded the value 
> at all, but kept it in a register instead.
> 
> That said, it does act like a race. Somebody clearing the ldisc and racing 
> with somebody using it?
> 
> Can you do a 
> 
> 	gdb vmlinux
> 
> 	disassemble pty_chars_in_buffer
> 
> to show what it looks like (whether it reloads the value, and what the 
> registers are - it looks like either %eax or %edi is all zeroes, but I'd 
> like to verify that it matches your code generation).
> 
> Alan? Any ideas? The tty_select() path seems to take a ldisc reference, 
> but does that guarantee that the ldisc won't _change_? What happens if the 
> line discipline is reset from ppp to regular (or set to ppp) 
> asymchronously? You've been deep in this area lately..
> 
> 			Linus
> 
> On Sun, 23 Jan 2005, ierdnah wrote:
> > 
> > Jan 22 13:27:59 warsheep Unable to handle kernel NULL pointer dereference at virtual address 00000000
> > Jan 22 13:27:59 warsheep printing eip:
> > Jan 22 13:27:59 warsheep 00000000
> > Jan 22 13:27:59 warsheep *pgd = cde9ddb400000000
> > Jan 22 13:27:59 warsheep *pmd = cde9ddb400000000
> > Jan 22 13:27:59 warsheep Oops: 0000 [#1]
> > Jan 22 13:27:59 warsheep SMP
> > Jan 22 13:27:59 warsheep CPU:    0
> > Jan 22 13:27:59 warsheep EIP:    0060:[<00000000>]    Not tainted VLI
> > Jan 22 13:27:59 warsheep EFLAGS: 00010282   (2.6.10-hardened-r2-warsheep62)
> > Jan 22 13:27:59 warsheep EIP is at 0x0
> > Jan 22 13:27:59 warsheep eax: 00000000   ebx: de455000   ecx: c02c60e0   edx: c6b41000
> > Jan 22 13:27:59 warsheep esi: de455000   edi: 00000000   ebp: dd0a2680   esp: cde9de9c
> > Jan 22 13:27:59 warsheep ds: 007b   es: 007b   ss: 0068
> > Jan 22 13:27:59 warsheep Process pptpctrl (pid: 16689, threadinfo=cde9c000 task=d112ca20)
> > Jan 22 13:27:59 warsheep Stack: c02c97bc c6b41000 00000000 c02c895c de455000 04949168 c03d0106 de455000
> > Jan 22 13:27:59 warsheep de45500c dd0a2680 00000000 c02c4141 de455000 dd0a2680 00000000 c01c7d49
> > Jan 22 13:27:59 warsheep dd0a2680 00000020 00000005 00000005 c01da72f dd0a2680 00000000 00000000
> > Jan 22 13:27:59 warsheep Call Trace:
> > Jan 22 13:27:59 warsheep [<c02c97bc>] pty_chars_in_buffer+0x2c/0x50
> > Jan 22 13:27:59 warsheep [<c02c895c>] normal_poll+0xfc/0x16b
> > Jan 22 13:27:59 warsheep [<c03d0106>] schedule_timeout+0x76/0xc0
> > Jan 22 13:27:59 warsheep [<c02c4141>] tty_poll+0xa1/0xc0
> > Jan 22 13:27:59 warsheep [<c01c7d49>] fget+0x49/0x60
> > Jan 22 13:27:59 warsheep [<c01da72f>] do_select+0x26f/0x2e0
> > Jan 22 13:27:59 warsheep [<c01da2f0>] __pollwait+0x0/0xd0
> > Jan 22 13:27:59 warsheep [<c01daabb>] sys_select+0x2db/0x4f0
> > Jan 22 13:27:59 warsheep [<c0173049>] sysenter_past_esp+0x52/0x79
> > Jan 22 13:27:59 warsheep Code:  Bad EIP value.
> > 
> > The oops ocures only when the kernel is build with SMP and HT support, in UP mode the oops doesn't occur!
> > I have a 2.6.10 kernel with SMP and HT compiled kernel, I have a P4 3GHz with HT
> > a have a VPN server with pppd and pptpd(poptop) and and average of 130
> > simultanious connections, the oops doesn't occur at a particular number
> > of simulationus VPN connection.I can build a kernel with debugging enabled or something to help to track th
> > source of the problem. Please CC as I am not subscribed to this mailing list.
> > 
> > -- 
> > ierdnah <ierdnah@go.ro>
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> 
-- 
ierdnah <ierdnah@go.ro>

Re: kernel oops!

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1498 bytes --]

On Sat, 22 Jan 2005 22:43:50 -0800 (PST) Linus Torvalds wrote:

> Interesting. That last call trace entry is the call in 
> pty_chars_in_buffer() to
> 
>         /* The ldisc must report 0 if no characters available to be read */
>         count = to->ldisc.chars_in_buffer(to);
> 
> and it looks like it has jumped to address zero.
> 
> However, we _just_ compared the fn pointer to zero immediately before, and 
> while there could certainly have been a race that cleared it in between 
> the test and the call, normally we wouldn't even have re-loaded the value 
> at all, but kept it in a register instead.
> 
> That said, it does act like a race. Somebody clearing the ldisc and racing 
> with somebody using it?
> 
> Can you do a 
> 
> 	gdb vmlinux
> 
> 	disassemble pty_chars_in_buffer
> 
> to show what it looks like (whether it reloads the value, and what the 
> registers are - it looks like either %eax or %edi is all zeroes, but I'd 
> like to verify that it matches your code generation).
> 
> Alan? Any ideas? The tty_select() path seems to take a ldisc reference, 
> but does that guarantee that the ldisc won't _change_?

tty_poll() grabs ldisc reference for the tty it was called with;
however, in this case pty_chars_in_buffer() accesses another ldisc
(tty->link->ldisc) without grabbing a reference to it.  BTW, many other
pty_* functions do the same thing.

Is calling tty_ldisc_ref(tty->link) safe here?  There is a comment
warning about possible deadlocks before pty_write().

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: kernel oops!

[Linus Torvalds]

On Sun, 23 Jan 2005, ierdnah wrote:
> 
> (gdb) disassemble pty_chars_in_buffer
...
> 0xc02c97a7 <pty_chars_in_buffer+23>:    mov    0x28(%edx),%ecx **
> 0xc02c97aa <pty_chars_in_buffer+26>:    test   %ecx,%ecx
> 0xc02c97ac <pty_chars_in_buffer+28>:    jne    0xc02c97b6
> 0xc02c97ae <pty_chars_in_buffer+30>:    mov    0x4(%esp,1),%ebx
> 0xc02c97b2 <pty_chars_in_buffer+34>:    add    $0x8,%esp
> 0xc02c97b5 <pty_chars_in_buffer+37>:    ret
> 0xc02c97b6 <pty_chars_in_buffer+38>:    mov    %edx,(%esp,1)
> 0xc02c97b9 <pty_chars_in_buffer+41>:    call   *0x28(%edx) **

Ahh, indeed. When I compiled this function, it kept 0x28(%edx) in a 
register. Your config/compiler combination does not, so there actually is 
a race condition if somebody changes the function pointer.

> this is another compiled kernel, but is compiled with the same .config
> file and same gcc version...because I only have the bzImage, how do I
> convert it to vmlinux?

Don't worry, it clearly shows that it's at least possible, and worth 
looking at. 

For testing, a patch like this might get rid of the problem by hiding the
race (but for all I know, gcc ends up re-loading it anyway) - you might 
want to check the disassembly. 

However, this patch is just for testing, to verify that your problem 
really is that particular race. It's not a proper fix.

I suspect that pty's should always lock each others line disciplines too, 
not just their "own" side.

		Linus

----
--- 1.32/drivers/char/pty.c	2005-01-10 17:29:36 -08:00
+++ edited/drivers/char/pty.c	2005-01-23 09:49:16 -08:00
@@ -149,13 +149,15 @@
 static int pty_chars_in_buffer(struct tty_struct *tty)
 {
 	struct tty_struct *to = tty->link;
+	ssize_t (*chars_in_buffer)(struct tty_struct *);
 	int count;
 
-	if (!to || !to->ldisc.chars_in_buffer)
+	/* We should get the line discipline lock for "tty->link" */
+	if (!to || !(chars_in_buffer = to->ldisc.chars_in_buffer))
 		return 0;
 
 	/* The ldisc must report 0 if no characters available to be read */
-	count = to->ldisc.chars_in_buffer(to);
+	count = chars_in_buffer(to);
 
 	if (tty->driver->subtype == PTY_TYPE_SLAVE) return count;
 

Re: kernel oops!

[Linus Torvalds]

On Sun, 23 Jan 2005, Sergey Vlasov wrote:
> 
> tty_poll() grabs ldisc reference for the tty it was called with;
> however, in this case pty_chars_in_buffer() accesses another ldisc
> (tty->link->ldisc) without grabbing a reference to it.  BTW, many other
> pty_* functions do the same thing.

Yes, I think you put the finger on it.

> Is calling tty_ldisc_ref(tty->link) safe here?  There is a comment
> warning about possible deadlocks before pty_write().

I think it's only the tty_ldisc_ref_wait() thing that can deadlock (and 
even that is likely safe if you just specify an order - "masters first" or 
something). Adding a nonblocking "tty_ldisc_ref()" looks safe, ie 
something like the appended.

This has the problem (apart from the fact that it's obviously totally
untested ;) that it looks like every single pty function would need to do
it, so it would be nicer if "tty_ldisc_ref_wait()" would just always get
both references (ie do the ordering). Alan?

		Linus
----
--- 1.32/drivers/char/pty.c	2005-01-10 17:29:36 -08:00
+++ edited/drivers/char/pty.c	2005-01-23 10:21:04 -08:00
@@ -149,13 +149,17 @@
 static int pty_chars_in_buffer(struct tty_struct *tty)
 {
 	struct tty_struct *to = tty->link;
-	int count;
+	int count = 0;
 
-	if (!to || !to->ldisc.chars_in_buffer)
-		return 0;
-
-	/* The ldisc must report 0 if no characters available to be read */
-	count = to->ldisc.chars_in_buffer(to);
+	if (to) {
+		struct tty_ldisc *ld = tty_ldisc_ref(to);
+		if (ld) {
+			if (ld->chars_in_buffer) {
+				count = ld->chars_in_buffer(to);
+				tty_ldisc_deref(ld);
+			}
+		}
+	}
 
 	if (tty->driver->subtype == PTY_TYPE_SLAVE) return count;
 

Re: kernel oops!

[Alan Cox]

On Sul, 2005-01-23 at 13:15, Sergey Vlasov wrote:
> On Sat, 22 Jan 2005 22:43:50 -0800 (PST) Linus Torvalds wrote:
> tty_poll() grabs ldisc reference for the tty it was called with;
> however, in this case pty_chars_in_buffer() accesses another ldisc
> (tty->link->ldisc) without grabbing a reference to it.  BTW, many other
> pty_* functions do the same thing.

Correct - the pty code still relies on all sorts of "lock_kernel"
assumptions so its probably very very racy. It can't however easily use
tty_ldisc_()
functions that wait because the lock ordering is indeterminate. 

Re: kernel oops!

[Alan Cox]

On Sul, 2005-01-23 at 18:22, Linus Torvalds wrote:
> I think it's only the tty_ldisc_ref_wait() thing that can deadlock (and 
> even that is likely safe if you just specify an order - "masters first" or 
> something). Adding a nonblocking "tty_ldisc_ref()" looks safe, ie 
> something like the appended.

Yes.

> This has the problem (apart from the fact that it's obviously totally
> untested ;) that it looks like every single pty function would need to do
> it, so it would be nicer if "tty_ldisc_ref_wait()" would just always get
> both references (ie do the ordering). Alan?

Almost every user of tty_ldisc_ref_* doesn't need to lock two objects
and
the code at that layer has no knowledge of pty/tty pairs. The needed
info is exposed however in order to do this since the tty knows if its a
tty/pty pair. I'll take a look - chances are it can be buried in
tty_ldisc_ref.

I'm dubious this is the actual bug although vhangup on a pty might
trigger it I guess.

Alan

Re: kernel oops!

[Linus Torvalds]

On Mon, 24 Jan 2005, Alan Cox wrote:
> 
> Almost every user of tty_ldisc_ref_* doesn't need to lock two objects and
> the code at that layer has no knowledge of pty/tty pairs.

Hmm.. It looks different to me - almost all users of the xxx_ref_wait() 
that act on pty's _do_ seem to use tty->link->ldisc.*()". The one counter- 
example seems to be pty_set_termios().

But I only did a quick grep in drivers/char, so there might be other users 
out there I didn't even think of.

While doing that, I did notice that all the other tty ops do take the 
kernel lock still - both read() and write() do. I wonder if we should just 
make poll() consistent, regardless of other issues (obviously, the nicest 
way to make it consistent would be to remove the kernel lock from the 
read/write paths, but I assume nobody wants to go through the locking).

> I'm dubious this is the actual bug although vhangup on a pty might
> trigger it I guess.

ierdnah - can you verify whether either of my silly patches seems to have 
made any difference? 

And I don't think it can be vhangup - that wouldn't clear the
chars_in_buffer function pointer (it might change it to the 
n_tty_chars_in_buffer or something by resetting to N_TTY).

I'd assume that it's when the other end is changed to using the
"ppp_[sync_]ldisc", both of which do actually have a NULL
"chars_in_buffer". (Alternatively, maybe "chars_in_buffer" isn't actually
NULL at all - the backtrace might be confused by either some really
strange memory corruption or a tail-call to a NULL function pointer by
some other line discipline thing, although quite frankly I think that 
sounds extremely unlikely).

So another potential fix is to just make all tty line disciplines always 
have a valid "chars_in_buffer" pointer. We could even do automatically in 
"tty_set_operations()", ie just do a

	driver->chars_in_buffer = op->chars_in_buffer ? : default_chars_in_buffer;

(where the default just returns zero) thing or something.

That would even speed up the normal cases (no need to test the pointer for 
NULL).

		Linus

Re: kernel oops!

[Alan Cox]

On Llu, 2005-01-24 at 17:58, Linus Torvalds wrote:
> On Mon, 24 Jan 2005, Alan Cox wrote:
> While doing that, I did notice that all the other tty ops do take the 
> kernel lock still - both read() and write() do. I wonder if we should just 
> make poll() consistent, regardless of other issues (obviously, the nicest 
> way to make it consistent would be to remove the kernel lock from the 
> read/write paths, but I assume nobody wants to go through the locking).

The lock is needed for the console at least and for some driver level
bits.

> And I don't think it can be vhangup - that wouldn't clear the
> chars_in_buffer function pointer (it might change it to the 
> n_tty_chars_in_buffer or something by resetting to N_TTY).

True - that would need an ldisc.close and the vhangup no longer does
that.

> So another potential fix is to just make all tty line disciplines always 
> have a valid "chars_in_buffer" pointer. We could even do automatically in 
> "tty_set_operations()", ie just do a

Not really. I'm in n_tty ->chars_in_buffer and the race occurs -> I'm
dead
as I'm already running the wrong chars_in_buffer function on CPU #0 when
CPU #1
comes along and flips ldisc. Holding the right locks matters here. We
also
need both locks holding really for tty/pty pairs because pty_write wants
to
output to the ldisc of the other side. Treating no ldisc as no
characters
seems very sane however and is easy to code up - if the ldisc_get fails
we
can sleep on the ldisc level wait queue then retry. Ugly enough to want
to
hide the contents in tty_io.c but doable. (When I get time - likely to
be 
a couple of weeks if nobody does it first)

Alan

Re: kernel oops!

[ierdnah]

On Sun, 2005-01-23 at 09:51 -0800, Linus Torvalds wrote:

I applied the patch and the uptime is 1 day and no oops, i will wait 2
more days too see if the oops appears, then I will compile the kernel
with CONFIG_PREEMPT. Before, when PREEMPT was enabled, the oops appeared
immediatly after booting and more often.

> ----
> --- 1.32/drivers/char/pty.c	2005-01-10 17:29:36 -08:00
> +++ edited/drivers/char/pty.c	2005-01-23 09:49:16 -08:00
> @@ -149,13 +149,15 @@
>  static int pty_chars_in_buffer(struct tty_struct *tty)
>  {
>  	struct tty_struct *to = tty->link;
> +	ssize_t (*chars_in_buffer)(struct tty_struct *);
>  	int count;
>  
> -	if (!to || !to->ldisc.chars_in_buffer)
> +	/* We should get the line discipline lock for "tty->link" */
> +	if (!to || !(chars_in_buffer = to->ldisc.chars_in_buffer))
>  		return 0;
>  
>  	/* The ldisc must report 0 if no characters available to be read */
> -	count = to->ldisc.chars_in_buffer(to);
> +	count = chars_in_buffer(to);
>  
>  	if (tty->driver->subtype == PTY_TYPE_SLAVE) return count;
>  
> 
-- 
ierdnah <ierdnah@go.ro>

Re: kernel oops!

[ierdnah]

On Sun, 2005-01-23 at 09:51 -0800, Linus Torvalds wrote:


with this patch the oops is gone(also tested with PREEMPT and no oops)
> 
> ----
> --- 1.32/drivers/char/pty.c	2005-01-10 17:29:36 -08:00
> +++ edited/drivers/char/pty.c	2005-01-23 09:49:16 -08:00
> @@ -149,13 +149,15 @@
>  static int pty_chars_in_buffer(struct tty_struct *tty)
>  {
>  	struct tty_struct *to = tty->link;
> +	ssize_t (*chars_in_buffer)(struct tty_struct *);
>  	int count;
>  
> -	if (!to || !to->ldisc.chars_in_buffer)
> +	/* We should get the line discipline lock for "tty->link" */
> +	if (!to || !(chars_in_buffer = to->ldisc.chars_in_buffer))
>  		return 0;
>  
>  	/* The ldisc must report 0 if no characters available to be read */
> -	count = to->ldisc.chars_in_buffer(to);
> +	count = chars_in_buffer(to);
>  
>  	if (tty->driver->subtype == PTY_TYPE_SLAVE) return count;
>  

is this patch better? should i test this too?

--- 1.32/drivers/char/pty.c     2005-01-10 17:29:36 -08:00
+++ edited/drivers/char/pty.c   2005-01-23 10:21:04 -08:00
@@ -149,13 +149,17 @@
 static int pty_chars_in_buffer(struct tty_struct *tty)
 {
        struct tty_struct *to = tty->link;
-       int count;
+       int count = 0;
 
-       if (!to || !to->ldisc.chars_in_buffer)
-               return 0;
-
-       /* The ldisc must report 0 if no characters available to be read
*/
-       count = to->ldisc.chars_in_buffer(to);
+       if (to) {
+               struct tty_ldisc *ld = tty_ldisc_ref(to);
+               if (ld) {
+                       if (ld->chars_in_buffer) {
+                               count = ld->chars_in_buffer(to);
+                               tty_ldisc_deref(ld);
+                       }
+               }
+       }
 
        if (tty->driver->subtype == PTY_TYPE_SLAVE) return count;
 




-- 
ierdnah <ierdnah@go.ro>

Re: kernel oops!

[Linus Torvalds]

On Fri, 28 Jan 2005, ierdnah wrote:
> 
> is this patch better? should i test this too?

You probably should. The patch you've tested is really ugly, and not a fix 
at all - it's really just depending on the compiler generating a specific 
code sequence that will hide the race.  As such, it's a patch I would only 
accept in the standard kernel as an absolute last resort.

In contrast, the second patch I tested may actually _fix_ the race. 

The fact that the first patch makes the oops go away is a good thing, 
though: it shows that your oops really was due to that small race window, 
and as such it helps validate that it wasn't anything else.

Thanks,

		Linus

Re: kernel oops!

[ierdnah]

On Thu, 2005-01-27 at 15:35 -0800, Linus Torvalds wrote:

the last patch works, but the load increases very much (normally with
200 VPN connections I have a load of maximum 10, with this patch I have
a load of 50-100 - after 30 min of uptime)

> You probably should. The patch you've tested is really ugly, and not a fix 
> at all - it's really just depending on the compiler generating a specific 
> code sequence that will hide the race.  As such, it's a patch I would only 
> accept in the standard kernel as an absolute last resort.
> 
> In contrast, the second patch I tested may actually _fix_ the race. 
> 
> The fact that the first patch makes the oops go away is a good thing, 
> though: it shows that your oops really was due to that small race window, 
> and as such it helps validate that it wasn't anything else.

--- 1.32/drivers/char/pty.c     2005-01-10 17:29:36 -08:00
+++ edited/drivers/char/pty.c   2005-01-23 10:21:04 -08:00
@@ -149,13 +149,17 @@
 static int pty_chars_in_buffer(struct tty_struct *tty)
 {
        struct tty_struct *to = tty->link;
-       int count;
+       int count = 0;
 
-       if (!to || !to->ldisc.chars_in_buffer)
-               return 0;
-
-       /* The ldisc must report 0 if no characters available to be read
*/
-       count = to->ldisc.chars_in_buffer(to);
+       if (to) {
+               struct tty_ldisc *ld = tty_ldisc_ref(to);
+               if (ld) {
+                       if (ld->chars_in_buffer) {
+                               count = ld->chars_in_buffer(to);
+                               tty_ldisc_deref(ld);
+                       }
+               }
+       }
 
 
       if (tty->driver->subtype == PTY_TYPE_SLAVE) return count;
 
-- 
ierdnah <ierdnah@go.ro>

Re: kernel oops!

[Linus Torvalds]

On Fri, 28 Jan 2005, ierdnah wrote:
> 
> the last patch works, but the load increases very much (normally with
> 200 VPN connections I have a load of maximum 10, with this patch I have
> a load of 50-100 - after 30 min of uptime)

Yeah, that "tty_ldisc_try()" is pretty expensive, and it really would be 
worth trying to get both sides of the tty at the same time, since with my 
patch in place it has to get that "tty_ldisc_lock" four times (and disable 
interrupts etc - twice for getting the lock, twice for releasing it).

I'm surprised that it makes _that_ much of a difference, but it sounds
like you used to be borderline on CPU usage before, and this just made it
much worse.

One option is to instead of locking both master and slave on use in the 
pty side, lock both when _changing_ the ldisc instead. That's the rare 
case. Much more complex, though.

Alan, any clever ideas?

		Linus

Re: kernel oops!

[ierdnah]

On Fri, 2005-01-28 at 12:28 -0800, Linus Torvalds wrote:


> I'm surprised that it makes _that_ much of a difference, but it sounds
> like you used to be borderline on CPU usage before, and this just made it
> much worse.

it's musch worst, I had a load of 5 with 250 VPN connections, and now, I
have a load of 200 with 150 connections

-- 
ierdnah <ierdnah@go.ro>

Re: Kernel Oops?

[Jesper Juhl]

On 09/01/2008, Stoyan Gaydarov <stoyboyker@gmail.com> wrote:
> On Jan 8, 2008 9:02 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > > Except this time when rebooting the machine i got a kernel oops
> > > message and it didn't boot completely. I could not copy it but I did
> > > take a picture and now I have re-written the screen here(sorry about
> >
> > That is interesting - that sort of error usually points at memory
> > corruption and early on tends to point at hardware (but not always). What
> > hard is in this system  and does it have over 4GB of RAM ?
> >
> >
>
> There are 2GB of RAM and the motherboard is DFI and it has a duel core
> intel cpu. If you need to specifics I could look them up.

cat /proc/cpuinfo
cat /proc/scsi/scsi
cat /proc/interrupts
lspci -vvx

should give you most of the details :)

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Kernel Oops?

[Stoyan Gaydarov]

On Jan 8, 2008 9:02 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > Except this time when rebooting the machine i got a kernel oops
> > message and it didn't boot completely. I could not copy it but I did
> > take a picture and now I have re-written the screen here(sorry about
>
> That is interesting - that sort of error usually points at memory
> corruption and early on tends to point at hardware (but not always). What
> hard is in this system  and does it have over 4GB of RAM ?
>
>

There are 2GB of RAM and the motherboard is DFI and it has a duel core
intel cpu. If you need to specifics I could look them up.

Re: Kernel Oops?

[Alan Cox]

> Except this time when rebooting the machine i got a kernel oops
> message and it didn't boot completely. I could not copy it but I did
> take a picture and now I have re-written the screen here(sorry about

That is interesting - that sort of error usually points at memory
corruption and early on tends to point at hardware (but not always). What
hard is in this system  and does it have over 4GB of RAM ?

Re: Kernel Oops?

[Stoyan Gaydarov]

On Jan 7, 2008 5:30 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Mon, 7 Jan 2008 17:15:01 -0600
> "Stoyan Gaydarov" <stoyboyker@gmail.com> wrote:
>
> > Today I upgraded my kernel from 2.6.23.9 to 2.6.23.12 and in the past
> > 30 minutes I have had to restart my computer twice.
> > I believe its a kernel oops or a kernel panic because when the
> > computer freezes it blinks the caps and scroll lock LEDs.
> > I don't know what is causing the problem but I am willing to help, I
> > can provide you with any information you need.
> > The only problem is that I don't know how to debug the system myself.
> > If anyone can tell me what to do to I can do it and give back the
> > information.
>
> When the machine hangs in graphical mode its quite hard to get the data
> out - one of the long term todo items is to fix that.
>
> Boot the machine and leave it in text mode (or if it boots to graphical
> mode then switch to a text console/text mode) and wait.. with "luck" it
> will show the same problem in text mode and give you a meaningful screen
> dump you can then write down (or grab with a digital camera)
>
> Alan
>

I reverted back to a clean install of slackware 12.0 after trying to
get it to fail again without luck, then i installed the 2.6.23.9
kernel and continued to use it regularly. Then a few minutes ago it I
restarted the computer because it had frozen again, the same way.
Except this time when rebooting the machine i got a kernel oops
message and it didn't boot completely. I could not copy it but I did
take a picture and now I have re-written the screen here(sorry about
the formating):

Stack: 00000010 000000d0 00000001 000000d0 c20fb980 c2104000 c2103e00 00000246
          c0a32fc0 47807ae8 00000000 c23eeaa0 000000d0 00000282
c20fb980 c026661b
          c23eeaa0 00000000 f586df04 c23eeaa0 c02227f2 00000246
00000000 c225c480
Call Trace:
[<c026661b>] kmem_cache_alloc+0x6b/0x90
[<c02227f2>] dup_fd+0x22/0x2c0
[<c023cc26>] getnstimeofday+0x36/0xc0
[<c0222ad1>] copy_files+0x41/0x60
[<c0223218>] copy_process+0x488/0x11a0
[<c0235a62>] alloc_pid+0x152/0x280
[<c0224196>] do_fork+0x76/0x230
[<c022e7fb>] recalc_sigpending+0x5d/0xe0
[<c022e86d>] sigprocmask+0x5d/0xe0
[<c0202252>] sys_clone+0x32/0x40
[<c02041e6>] syscall_call+0x7/0xb
[<c07f0000>] __mutex_lock_interruptible_slowpath+0xb0/0xc0
=======================
Code: 5b 5e 5f 5d c3 8b 7a 10 89 d0 c7 42 34 01 00 00 00 83 c0 10 39 c7 74 b6 8b
 4c 24 10 8b 77 10 3b b1 98 00 00 00 0f 82 1d ff ff ff <0f> 0b eb fe 8b 4c 24 18
 8b 54 24 18 8b 41 08 83 c2 08 89 78 04
EIP: [<c02667fd>] cache_alloc_refill+0x1bd/0x540 SS:ESP 0068:f586de7c
INIT: Entering runlevel: 4
Going multiuser...
Updating shared library links:  /sbin/ldconfig &


Hope that someone can find the problem and fix it

Re: Kernel Oops?

[Jesper Juhl]

On 08/01/2008, Stoyan Gaydarov <stoyboyker@gmail.com> wrote:
> Today I upgraded my kernel from 2.6.23.9 to 2.6.23.12 and in the past
> 30 minutes I have had to restart my computer twice.
> I believe its a kernel oops or a kernel panic because when the
> computer freezes it blinks the caps and scroll lock LEDs.
> I don't know what is causing the problem but I am willing to help, I
> can provide you with any information you need.
> The only problem is that I don't know how to debug the system myself.
> If anyone can tell me what to do to I can do it and give back the
> information.
>

Here are some things for you to try :


Try looking in your log files. look for things like "Oops", "BUG()"
and similar. If you find anything that looks relevant, post it here.

If you can trigger the problem without X running - try that. Sometimes
an Oops makes it to the local console but doesn't make it to the logs.
Being logged into a plain console without X running when the problem
triggers can sometimes enable you to capture it with a digital camera.

Try building your kernel with magic sysrq support (if you haven't
already). Then you can sometimes manage to get a backtrace to the
console after the hang. See Documentation/sysrq.txt for details.

Try building your kernel with some (or all) of the debug options found
under the 'Kernel hacking' menuconfig menu to get more debug info.

Make sure you have no proprietary modules that taint your kernel
loaded (like the NVidia driver for example). The presence of any such
modules makes the kernel pretty much un-debugable.

If nothing makes it to your logs nor to your local console, then try
attaching a second PC via serial console or netconsole and see if you
can manage to log the Oops that way. See
Documentation/serial-console.txt and
Documentation/networking/netconsole.txt for details.


That should do it for a few starting points.  :-)


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Kernel Oops?

[Alan Cox]

On Mon, 7 Jan 2008 17:15:01 -0600
"Stoyan Gaydarov" <stoyboyker@gmail.com> wrote:

> Today I upgraded my kernel from 2.6.23.9 to 2.6.23.12 and in the past
> 30 minutes I have had to restart my computer twice.
> I believe its a kernel oops or a kernel panic because when the
> computer freezes it blinks the caps and scroll lock LEDs.
> I don't know what is causing the problem but I am willing to help, I
> can provide you with any information you need.
> The only problem is that I don't know how to debug the system myself.
> If anyone can tell me what to do to I can do it and give back the
> information.

When the machine hangs in graphical mode its quite hard to get the data
out - one of the long term todo items is to fix that.

Boot the machine and leave it in text mode (or if it boots to graphical
mode then switch to a text console/text mode) and wait.. with "luck" it
will show the same problem in text mode and give you a meaningful screen
dump you can then write down (or grab with a digital camera)

Alan

Kernel Oops?

[Stoyan Gaydarov]

Today I upgraded my kernel from 2.6.23.9 to 2.6.23.12 and in the past
30 minutes I have had to restart my computer twice.
I believe its a kernel oops or a kernel panic because when the
computer freezes it blinks the caps and scroll lock LEDs.
I don't know what is causing the problem but I am willing to help, I
can provide you with any information you need.
The only problem is that I don't know how to debug the system myself.
If anyone can tell me what to do to I can do it and give back the
information.

The system I am running is a slackware 12.0 with the new kernel.
root@SlaxDesk:~# uname -a
Linux SlaxDesk 2.6.23.12 #1 SMP Sat Jan 5 06:58:19 CST 2008 i686
Intel(R) Core(TM)2 Duo CPU     E4500  @ 2.20GHz GenuineIntel GNU/Linux

Thank you ahead of time for any help.

Re: kernel Oops!!!!

[Gene Heskett]

On Friday 17 September 2004 10:05, Jysuis Parla wrote:
>Hello,
>My name is biggeek, from Microsoft, and I find a
>mistake in the code of the kernel : /kernel/sched.c
>line 1023 col 21, a 'n' is
>missing. So when i boot my computer, there is kernel
>message that say:
>
> KERNEL PANIC !!!!!!!!!!
>
>please help me ..  because without my computer I have
>no life :(
>
>But i solved he problem and i made a patch.
>Yoopy!!!!!!
>
>PS: I want to unsubscribe this mailing list.

For a troll from M$, you're doing pretty good, but that french accent 
had mne fooled for a minute.

Anyway, WRT your problem, not in the latest kernel, so its possile the 
unpacker sneezed.  Nuke the dir and unpack it again.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.26% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

kernel Oops!!!!

[Jysuis Parla]

Hello,
My name is biggeek, from Microsoft, and I find a
mistake in the code of the kernel : /kernel/sched.c
line 1023 col 21, a 'n' is
missing. So when i boot my computer, there is kernel
message that say:

 KERNEL PANIC !!!!!!!!!!

please help me ..  because without my computer I have
no life :(

But i solved he problem and i made a patch.
Yoopy!!!!!!

PS: I want to unsubscribe this mailing list.



	

	
		
Vous manquez d’espace pour stocker vos mails ? 
Yahoo! Mail vous offre GRATUITEMENT 100 Mo !
Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/

Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis. A télécharger gratuitement sur http://fr.messenger.yahoo.com

kernel Oops!!!!

[Jysuis Parla]

Hello,
My name is biggeek, from Microsoft, and I find a
mistake in the code of the kernel : /kernel/sched.c
line 1023 col 21, a 'n' is
missing. So when i boot my computer, there is kernel
message that say:

 KERNEL PANIC !!!!!!!!!!

please help me ..  because without my computer I have
no life :(

But i solved he problem and i made a patch.
Yoopy!!!!!!

PS: I want to unsubscribe this mailing list.



	

	
		
Vous manquez d’espace pour stocker vos mails ? 
Yahoo! Mail vous offre GRATUITEMENT 100 Mo !
Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/

Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis. A télécharger gratuitement sur http://fr.messenger.yahoo.com

Re: Kernel oops!

[Venky]

Hi,

> > I am getting a whole lot of kernel oops, and I am not able to detect any
> > pattern.  The only thing common is the machine is pretty heavily loaded
> > at that time.  Am I having a hardware problem here, or is it something
> > else?

> looks like a memory problem, but i might be wrong.

Thanks for the tip.  I think it is a memory problem too.  Anyway, I ran
the oops text thru ksymoops (thanks, Tom).  Maybe this will give a
clearer picture.  

[ Am cross-posting this to the linux-kernel list.  Anyone replying from
that list, please include my address in the reply.  I am not on the
list. ]

========================================================================

ksymoops 0.7c on i586 2.2.16-3.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.2.16-3/ (default)
     -m /boot/System.map (specified)

Call Trace: [<c0109f0c>] 
Code: 8b 54 20 24 be 00 fe ff ff 83 7a 08 00 75 12 e8 50 96 ff ff 
Using defaults from ksymoops -t elf32-i386 -a i386

Trace; c0109f0c <system_call+34/38>
Code;  00000000 Before first symbol
00000000 <_EIP>:
Code;  00000000 Before first symbol
   0:   8b 54 20 24               mov    0x24(%eax,1),%edx
Code;  00000004 Before first symbol
   4:   be 00 fe ff ff            mov    $0xfffffe00,%esi
Code;  00000009 Before first symbol
   9:   83 7a 08 00               cmpl   $0x0,0x8(%edx)
Code;  0000000d Before first symbol
   d:   75 12                     jne    21 <_EIP+0x21> 00000021 Before first symbol
Code;  0000000f Before first symbol
   f:   e8 50 96 ff ff            call   ffff9664 <_EIP+0xffff9664> ffff9664 <END_OF_CODE+3779b740/????>

Unable to handle kernel NULL pointer dereference at virtual address 00000024
current->tss.cr3 = 03e97000, %cr3 = 03e97000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c0117c48>]
EFLAGS: 00010246
eax: 00000000   ebx: 00000000   ecx: 00000001   edx: c2a66000
esi: 00000000   edi: bfffeec8   ebp: ffffffff   esp: c2a67f98
ds: 0018   es: 0018   ss: 0018
Process wnlaunch (pid: 12823, process nr: 65, stackpage=c2a67000)
Stack: 00000000 bfffee78 c2a66000 40013ed0 c2a66000 c2a67fb8 c2a67fb8 c2a66000 
       c2a66000 c2a6608c c0109f0c ffffffff bfffeec8 00000000 00000000 00000000 
       bfffee78 00000072 0000002b 0000002b 00000072 400b28e9 00000023 00000202 
Call Trace: [<c0109f0c>] 
Code: 8b 54 24 24 be 00 fe ff ff 83 7a 08 00 75 12 e8 50 96 ff ff 

>>EIP; c0117c48 <sys_wait4+2ac/304>   <=====
Trace; c0109f0c <system_call+34/38>
Code;  c0117c48 <sys_wait4+2ac/304>
00000000 <_EIP>:
Code;  c0117c48 <sys_wait4+2ac/304>   <=====
   0:   8b 54 24 24               mov    0x24(%esp,1),%edx   <=====
Code;  c0117c4c <sys_wait4+2b0/304>
   4:   be 00 fe ff ff            mov    $0xfffffe00,%esi
Code;  c0117c51 <sys_wait4+2b5/304>
   9:   83 7a 08 00               cmpl   $0x0,0x8(%edx)
Code;  c0117c55 <sys_wait4+2b9/304>
   d:   75 12                     jne    21 <_EIP+0x21> c0117c69 <sys_wait4+2cd/304>
Code;  c0117c57 <sys_wait4+2bb/304>
   f:   e8 50 96 ff ff            call   ffff9664 <_EIP+0xffff9664> c01112ac <schedule+0/280>

Unable to handle kernel NULL pointer dereference at virtual address 00000024
current->tss.cr3 = 03920000, %cr3 = 03920000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c0117c48>]
EFLAGS: 00010246
eax: 00000000   ebx: 00000000   ecx: 00000001   edx: c2a66000
esi: 00000000   edi: bfffeec8   ebp: ffffffff   esp: c2a67f98
ds: 0018   es: 0018   ss: 0018
Process wnlaunch (pid: 14468, process nr: 65, stackpage=c2a67000)
Stack: 00000000 bfffee78 c2a66000 40013ed0 c2a66000 c2a67fb8 c2a67fb8 c2a66000 
       c2a66000 c2a6608c c0109f0c ffffffff bfffeec8 00000000 00000000 00000000 
       bfffee78 00000072 0000002b 0000002b 00000072 400b28e9 00000023 00000202 
Call Trace: [<c0109f0c>] 
Code: 8b 54 20 24 be 00 fe ff ff 83 7a 08 00 75 12 e8 50 96 ff ff 

>>EIP; c0117c48 <sys_wait4+2ac/304>   <=====
Trace; c0109f0c <system_call+34/38>
Code;  c0117c48 <sys_wait4+2ac/304>
00000000 <_EIP>:
Code;  c0117c48 <sys_wait4+2ac/304>   <=====
   0:   8b 54 20 24               mov    0x24(%eax,1),%edx   <=====
Code;  c0117c4c <sys_wait4+2b0/304>
   4:   be 00 fe ff ff            mov    $0xfffffe00,%esi
Code;  c0117c51 <sys_wait4+2b5/304>
   9:   83 7a 08 00               cmpl   $0x0,0x8(%edx)
Code;  c0117c55 <sys_wait4+2b9/304>
   d:   75 12                     jne    21 <_EIP+0x21> c0117c69 <sys_wait4+2cd/304>
Code;  c0117c57 <sys_wait4+2bb/304>
   f:   e8 50 96 ff ff            call   ffff9664 <_EIP+0xffff9664> c01112ac <schedule+0/280>

Unable to handle kernel NULL pointer dereference at virtual address 00000024
current->tss.cr3 = 02fca000, %cr3 = 02fca000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c0117c48>]
EFLAGS: 00010246
eax: 00000000   ebx: 00000000   ecx: 00000001   edx: c2b84000
esi: 00000000   edi: bfffeeb8   ebp: ffffffff   esp: c2b85f98
ds: 0018   es: 0018   ss: 0018
Process wnlaunch (pid: 32164, process nr: 65, stackpage=c2b85000)
Stack: 00000000 bfffee68 c2b84000 40013ed0 c2b84000 c2b85fb8 c2b85fb8 c2b84000 
       c2b84000 c2b8408c c0109f0c ffffffff bfffeeb8 00000000 00000000 00000000 
       bfffee68 00000072 0000002b 0000002b 00000072 400b28e9 00000023 00000202 
Call Trace: [<c0109f0c>] 
Code: 8b 54 20 24 be 00 fe ff ff 83 7a 08 00 75 12 e8 50 96 ff ff 

>>EIP; c0117c48 <sys_wait4+2ac/304>   <=====
Trace; c0109f0c <system_call+34/38>
Code;  c0117c48 <sys_wait4+2ac/304>
00000000 <_EIP>:
Code;  c0117c48 <sys_wait4+2ac/304>   <=====
   0:   8b 54 20 24               mov    0x24(%eax,1),%edx   <=====
Code;  c0117c4c <sys_wait4+2b0/304>
   4:   be 00 fe ff ff            mov    $0xfffffe00,%esi
Code;  c0117c51 <sys_wait4+2b5/304>
   9:   83 7a 08 00               cmpl   $0x0,0x8(%edx)
Code;  c0117c55 <sys_wait4+2b9/304>
   d:   75 12                     jne    21 <_EIP+0x21> c0117c69 <sys_wait4+2cd/304>
Code;  c0117c57 <sys_wait4+2bb/304>
   f:   e8 50 96 ff ff            call   ffff9664 <_EIP+0xffff9664> c01112ac <schedule+0/280>

Unable to handle kernel NULL pointer dereference at virtual address 00000024
current->tss.cr3 = 02fca000, %cr3 = 02fca000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c0117c48>]
EFLAGS: 00010246
eax: 00000000   ebx: 00000000   ecx: 00000001   edx: c3cbe000
esi: 00000000   edi: bfffeeb8   ebp: ffffffff   esp: c3cbff98
ds: 0018   es: 0018   ss: 0018
Process wnlaunch (pid: 9060, process nr: 65, stackpage=c3cbf000)
Stack: 00000000 bfffee68 c3cbe000 40013ed0 c3cbe000 c3cbffb8 c3cbffb8 c3cbe000 
       c3cbe000 c3cbe08c c0109f0c ffffffff bfffeeb8 00000000 00000000 00000000 
       bfffee68 00000072 0000002b 0000002b 00000072 400b28e9 00000023 00000202 
Call Trace: [<c0109f0c>] 
Code: 8b 54 20 24 be 00 fe ff ff 83 7a 08 00 75 12 e8 50 96 ff ff 

>>EIP; c0117c48 <sys_wait4+2ac/304>   <=====
Trace; c0109f0c <system_call+34/38>
Code;  c0117c48 <sys_wait4+2ac/304>
00000000 <_EIP>:
Code;  c0117c48 <sys_wait4+2ac/304>   <=====
   0:   8b 54 20 24               mov    0x24(%eax,1),%edx   <=====
Code;  c0117c4c <sys_wait4+2b0/304>
   4:   be 00 fe ff ff            mov    $0xfffffe00,%esi
Code;  c0117c51 <sys_wait4+2b5/304>
   9:   83 7a 08 00               cmpl   $0x0,0x8(%edx)
Code;  c0117c55 <sys_wait4+2b9/304>
   d:   75 12                     jne    21 <_EIP+0x21> c0117c69 <sys_wait4+2cd/304>
Code;  c0117c57 <sys_wait4+2bb/304>
   f:   e8 50 96 ff ff            call   ffff9664 <_EIP+0xffff9664> c01112ac <schedule+0/280>

Unable to handle kernel NULL pointer dereference at virtual address 00000024
current->tss.cr3 = 077c6000, %cr3 = 077c6000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c0117c48>]
EFLAGS: 00010246
eax: 00000000   ebx: 00000000   ecx: 00000001   edx: c3cbe000
esi: 00000000   edi: bfffeeb8   ebp: ffffffff   esp: c3cbff98
ds: 0018   es: 0018   ss: 0018
Process wnlaunch (pid: 9240, process nr: 65, stackpage=c3cbf000)
Stack: 00000000 bfffee68 c3cbe000 40013ed0 c3cbe000 c3cbffb8 c3cbffb8 c3cbe000 
       c3cbe000 c3cbe08c c0109f0c ffffffff bfffeeb8 00000000 00000000 00000000 
       bfffee68 00000072 0000002b 0000002b 00000072 400b28e9 00000023 00000202 
Call Trace: [<c0109f0c>] 
Code: 8b 54 20 24 be 00 fe ff ff 83 7a 08 00 75 12 e8 50 96 ff ff 

>>EIP; c0117c48 <sys_wait4+2ac/304>   <=====
Trace; c0109f0c <system_call+34/38>
Code;  c0117c48 <sys_wait4+2ac/304>
00000000 <_EIP>:
Code;  c0117c48 <sys_wait4+2ac/304>   <=====
   0:   8b 54 20 24               mov    0x24(%eax,1),%edx   <=====
Code;  c0117c4c <sys_wait4+2b0/304>
   4:   be 00 fe ff ff            mov    $0xfffffe00,%esi
Code;  c0117c51 <sys_wait4+2b5/304>
   9:   83 7a 08 00               cmpl   $0x0,0x8(%edx)
Code;  c0117c55 <sys_wait4+2b9/304>
   d:   75 12                     jne    21 <_EIP+0x21> c0117c69 <sys_wait4+2cd/304>
Code;  c0117c57 <sys_wait4+2bb/304>
   f:   e8 50 96 ff ff            call   ffff9664 <_EIP+0xffff9664> c01112ac <schedule+0/280>

Unable to handle kernel NULL pointer dereference at virtual address 00000024
current->tss.cr3 = 04016000, %cr3 = 04016000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c0117c48>]
EFLAGS: 00010246
eax: 00000000   ebx: 00000000   ecx: 00000001   edx: c3c94000
esi: 00000000   edi: bfffe8a8   ebp: ffffffff   esp: c3c95f98
ds: 0018   es: 0018   ss: 0018
Process word (pid: 18238, process nr: 77, stackpage=c3c95000)
Stack: 00000000 bfffe858 c3c94000 0809dd50 c3c94000 c3c95fb8 c3c95fb8 c3c94000 
       c3c94000 c3c9408c c0109f0c ffffffff bfffe8a8 00000000 00000000 00000000 
       bfffe858 00000072 0000002b 0000002b 00000072 400b28e9 00000023 00000202 
Call Trace: [<c0109f0c>] 
Code: 8b 54 20 24 be 00 fe ff ff 83 7a 08 00 75 12 e8 50 96 ff ff 

>>EIP; c0117c48 <sys_wait4+2ac/304>   <=====
Trace; c0109f0c <system_call+34/38>
Code;  c0117c48 <sys_wait4+2ac/304>
00000000 <_EIP>:
Code;  c0117c48 <sys_wait4+2ac/304>   <=====
   0:   8b 54 20 24               mov    0x24(%eax,1),%edx   <=====
Code;  c0117c4c <sys_wait4+2b0/304>
   4:   be 00 fe ff ff            mov    $0xfffffe00,%esi
Code;  c0117c51 <sys_wait4+2b5/304>
   9:   83 7a 08 00               cmpl   $0x0,0x8(%edx)
Code;  c0117c55 <sys_wait4+2b9/304>
   d:   75 12                     jne    21 <_EIP+0x21> c0117c69 <sys_wait4+2cd/304>
Code;  c0117c57 <sys_wait4+2bb/304>
   f:   e8 50 96 ff ff            call   ffff9664 <_EIP+0xffff9664> c01112ac <schedule+0/280>

Unable to handle kernel NULL pointer dereference at virtual address 00000024
current->tss.cr3 = 06274000, %cr3 = 06274000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c0117c48>]
EFLAGS: 00010246
eax: 00000000   ebx: 00000000   ecx: 00000001   edx: c7314000
esi: 00000000   edi: bfffeef8   ebp: ffffffff   esp: c7315f98
ds: 0018   es: 0018   ss: 0018
Process wnlaunch (pid: 672, process nr: 60, stackpage=c7315000)
Stack: 00000000 bfffeea8 c7314000 40013ed0 c7314000 c7315fb8 c7315fb8 c7314000 
       c7314000 c731408c c0109f0c ffffffff bfffeef8 00000000 00000000 00000000 
       bfffeea8 00000072 0000002b 0000002b 00000072 400b28e9 00000023 00000202 
Call Trace: [<c0109f0c>] 
Code: 8b 54 20 24 be 00 fe ff ff 83 7a 08 00 75 12 e8 50 96 ff ff 

>>EIP; c0117c48 <sys_wait4+2ac/304>   <=====
Trace; c0109f0c <system_call+34/38>
Code;  c0117c48 <sys_wait4+2ac/304>
00000000 <_EIP>:
Code;  c0117c48 <sys_wait4+2ac/304>   <=====
   0:   8b 54 20 24               mov    0x24(%eax,1),%edx   <=====
Code;  c0117c4c <sys_wait4+2b0/304>
   4:   be 00 fe ff ff            mov    $0xfffffe00,%esi
Code;  c0117c51 <sys_wait4+2b5/304>
   9:   83 7a 08 00               cmpl   $0x0,0x8(%edx)
Code;  c0117c55 <sys_wait4+2b9/304>
   d:   75 12                     jne    21 <_EIP+0x21> c0117c69 <sys_wait4+2cd/304>
Code;  c0117c57 <sys_wait4+2bb/304>
   f:   e8 50 96 ff ff            call   ffff9664 <_EIP+0xffff9664> c01112ac <schedule+0/280>

Unable to handle kernel NULL pointer dereference at virtual address 00000024
current->tss.cr3 = 06eb3000, %cr3 = 06eb3000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c0117c48>]
EFLAGS: 00010246
eax: 00000000   ebx: 00000000   ecx: 00000001   edx: c59d8000
esi: 00000000   edi: bfffe30c   ebp: ffffffff   esp: c59d9f98
ds: 0018   es: 0018   ss: 0018
Process word (pid: 9897, process nr: 64, stackpage=c59d9000)
Stack: 00000000 bfffe2bc c59d8000 080a1170 c59d8000 c59d9fb8 c59d9fb8 c59d8000 
       c59d8000 c59d808c c0109f0c ffffffff bfffe30c 00000000 00000000 00000000 
       bfffe2bc 00000072 0000002b 0000002b 00000072 400b28e9 00000023 00000202 
Call Trace: [<c0109f0c>] 
Code: 8b 54 20 24 be 00 fe ff ff 83 7a 08 00 75 12 e8 50 96 ff ff 

>>EIP; c0117c48 <sys_wait4+2ac/304>   <=====
Trace; c0109f0c <system_call+34/38>
Code;  c0117c48 <sys_wait4+2ac/304>
00000000 <_EIP>:
Code;  c0117c48 <sys_wait4+2ac/304>   <=====
   0:   8b 54 20 24               mov    0x24(%eax,1),%edx   <=====
Code;  c0117c4c <sys_wait4+2b0/304>
   4:   be 00 fe ff ff            mov    $0xfffffe00,%esi
Code;  c0117c51 <sys_wait4+2b5/304>
   9:   83 7a 08 00               cmpl   $0x0,0x8(%edx)
Code;  c0117c55 <sys_wait4+2b9/304>
   d:   75 12                     jne    21 <_EIP+0x21> c0117c69 <sys_wait4+2cd/304>
Code;  c0117c57 <sys_wait4+2bb/304>
   f:   e8 50 96 ff ff            call   ffff9664 <_EIP+0xffff9664> c01112ac <schedule+0/280>

======================================================================

Thanks,
Venky.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/