From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Udo van den Heuvel <udovdh@xs4all.nl>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: possible BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
Date: Sat, 1 Dec 2007 15:12:20 +0300 [thread overview]
Message-ID: <20071201121220.GA28875@cvg> (raw)
In-Reply-To: <47513EE5.30703@xs4all.nl>
[Udo van den Heuvel - Sat, Dec 01, 2007 at 12:00:53PM +0100]
| Hallo Cyrill,
|
| Cyrill Gorcunov wrote:
| > | I made a do while loop doing make bzImage modules and a make clean.
| > | Should be OK?
| > |
| >
| > well, test the patch enveloped. if the bug is really heppens then
| > BUG message should appear. and the thing is much important - does
| > that bug appears on the same actions (make bzImage and etc..) on pure
| > kernel? or that happened from time to time?
|
| I only had teh bug once, that was the reason for my post.
| Since then the system has been busy, with intervals, doing kernel
| compiles and no repeat of the BUG yet...
| It's a VIA EN12000 with 1GB of RAM. How could I increase the chances of
| hitting it?
|
|
| Kind regards,
| Udo
|
Hi Udo,
if my guessing is right - the only chance to hit it faster - is to increase
files' activity i.e. compiling the kernel involves a lot of file being readed
thru dcache system. First we have to locate the bug on a pure kernel
and 'case it's a rare thing to happen... well I don't really know how to
get it up to known point. So i think you could play with a pure kernel
by compiling it or run several copies of 'grep' thru kernel searching
the same pattern like "grep -r -n for ./*" in kernel sources. But Udo,
I'm not a kernel specialist so my suggestions could be not really usefull ;)
And as only you have found "approximated events" when the bug happend -
then we could try the same actions with my latest patch applied to find
if it happening exactly in dcache system. (damn, so many *if* there ;)
if you will not find that bug being reproducible in a simple way - just
leave all as it is, i'm trying to find problems in dcache system by code
reading.
P.S.
Lets CC LKML - that could help us ;)
Cyrill
next prev parent reply other threads:[~2007-12-01 12:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-24 12:14 possible BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000 Udo van den Heuvel
2007-11-24 18:51 ` Rafael J. Wysocki
2007-11-24 18:44 ` Udo van den Heuvel
[not found] ` <aa79d98a0711270340q5fd6b8a0o5076052a4411e6b2@mail.gmail.com>
[not found] ` <474C3659.600@xs4all.nl>
2007-11-27 16:49 ` Cyrill Gorcunov
2007-11-27 17:41 ` Udo van den Heuvel
[not found] ` <20071127175503.GC7279@cvg>
[not found] ` <47513EE5.30703@xs4all.nl>
2007-12-01 12:12 ` Cyrill Gorcunov [this message]
2007-12-01 12:47 ` Udo van den Heuvel
2007-12-01 13:11 ` Cyrill Gorcunov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071201121220.GA28875@cvg \
--to=gorcunov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=udovdh@xs4all.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.