Re: Current Git: BUG: unable to handle kernel paging request at 0000000001a40ca0

[Vegard Nossum]

On Wed, Jul 23, 2008 at 11:53 PM, Dieter Ries <clip3@xxxxxx> wrote:
>>> Dieter: If this is reproducible, it would probably help quite a bit to
>>> configure the kernel with CONFIG_SLUB_DEBUG and boot with
>>> slub_debug=FZPUT (unless you already have CONFIG_SLUB_DEBUG_ON set, in
>>> which case you are already running with the SLUB debugging at boot).
>>> It might catch the corruption before it becomes fatal, or give us some
>>> more clues anyway.
>
> I tried to bisect the bug, which failed because there were too many kernels
> not booting with other problems, I guess bisecting just fails in the merge
> window.
>
> With CONFIG_SLUB_DEBUG_ON the output looks different, unfortunately
> netconsole stops before those are transmitted.
>
> As there are always some lines about e1000 in the backtraces, I tried to
> boot without LAN cable connected, and it worked, and crashed afterwards when
> I plugged the cable in, with a bug in net/core/dev.c.
>
> I will search on tomorrow, as it is getting quite late now.
>
> Should I copy the messages with CONFIG_SLUB_DEBUG_ON by hand, or are just
> some parts important?

There were some e1000 patches in flight on LKML recently; you might be
able to find them and see if it helps you. It also seems that some
changes were just committed to -git, so I guess you should try the
very latest from there.

You also Cced netdev from the start, so somebody from there should be
able to help you more from here than I. :-)


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036
--
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/