Re: Serial related oops

On Mon, Feb 19, 2007 at 04:29:39PM +0000, Jose Goncalves wrote:
Russell King wrote:
On Tue, Feb 20, 2007 at 02:48:14PM +0000, Frederik Deweerdt wrote:

(trimmed tie-fei.zang from the CC, added by mistake)
On Mon, Feb 19, 2007 at 02:35:20PM +0000, Russell King wrote:

Neither did I, but introducing printk's through the function, we narrowed
the problem to this part of the code. And removing it makes the problem
go away. We inserted 37 printk's in the function body, and Jose bisected
those until the problem went away.

Well, there's still little clue about why this is causing a NULL pointer
dereference. The only thing I can think is that somehow performing
this test is causing a power glitch to your CPU, causing its registers
to get corrupted, and which results in it doing a NULL pointer deref.

That may be the case, indeed.


But if the problem was a power glitch I should get Oops with or without
printk() inserted, shouldn't I?

That depends if the printk() changes the timing such that it doesn't occur.
Don't know, I'm only grasping at straws due to the lack of any concrete
information.

If you see other tests to be performed...

Maybe adding some delays in that bit of code? I'm sure you've already
thought of that though. Since no one has a proper understanding of the
problem, the only suggestions possible are mere shots in the dark.

I'm no kernel expert, but it's not possible to trace what is the
instruction that is causing the NULL pointer dereference?

The reported dump shows that the kernel tried to access virtual address 0,
and the instruction pointer seems to be the cause of that - it has a value
of zero in that dump.

The call trace indicates that the last function was called from around
"uart_startup+0x63/0xf4" which is probably the indirect function call
to serial8250_startup(). That's unconfirmed - the only way to get it
confirmed is if you could dump the entire uart_startup() function.

$ grep uart_startup System.map
(address) T uart_startup
$ objdump -r -d vmlinux --start-addr=0x<address> --stop-addr=0x<address+256>

The grep should get you the address of uart_startup. Replace <address>
with that value and <address+256> with the value plus 256 (0x100) and
mail the result.

I have no clue on what is causing this problem but, what I know, is
that I can always reproduce it, and it always happens in the same code
section of serial8250_startup().

We're both at the same level of clue about the problem then.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Serial related oops
    ... there's still little clue about why this is causing a NULL pointer ... The reported dump shows that the kernel tried to access virtual address 0, ... The grep should get you the address of uart_startup. ...
    (Linux-Kernel)
  • Re: Serial related oops
    ... particular Jose Goncalves reportedan oops in 2.6.16.38 reproducible ... there's still little clue about why this is causing a NULL pointer ... maintainer a while ago, ...
    (Linux-Kernel)
  • Re: Serial related oops
    ... there's still little clue about why this is causing a NULL pointer ... and which results in it doing a NULL pointer deref. ... maintainer a while ago, ...
    (Linux-Kernel)
  • Re: Problem with Marshal.SizeOf in CF 2.0
    ... pointer, which is causing the marshaler grief. ... int a1 = Marshal.SizeOf; ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: A NULL pointer changed after returned?
    ... > This is in the FAQ. ... I got you, so that means if I change the content in the struct, ... changed, but if I point it to NULL, I am actually changing the pointer ... so it reverts to the original value outside the function body. ...
    (comp.lang.c)