Re: kernel oops!

[ierdnah <ierdnah@go.ro>]

(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>