From: Bryan Andersen <bryan@bogonomicon.net>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: 2.4.21-pre3-ac4 oops in free_pages_ok
Date: Sun, 19 Jan 2003 05:01:55 -0600 [thread overview]
Message-ID: <3E2A85A3.4090402@bogonomicon.net> (raw)
In-Reply-To: <3E289A53.40203@bogonomicon.net>
As I thought and others felt too. It looks like the -ac4
patch for 2.4.21-pre3 has some error in it that causes an
oops. I've tested a 2.4.21-pre3 with only the nvidia2
related patches from -ac4 added to it and it appears to be
stable. A few kernel comples and 53 mke2fs with bad block
scan runs and it stayed up. I'm now running memtest86 over
night to be pedantic that it isn't a memory error. Sofar
it passed the first pass of the tests, we'll see what
happens over night.
What are some good system abuse test suites? In the past
I've used kernel compiles in an endless loop. I'd do one
run then compare the outputs from each run to the first
run. Any difference constitutes a failure.
Bryan Andersen wrote:
> I too have been seeing this oops crash problem. I can
> consistantly reproduce mine by running:
>
> $ mke2fs -c -j -i 16768 /dev/hdc6
>
> The interesting thing is running:
>
> $ mke2fs -j -i 16768 /dev/hdc6
>
> does not cause an oops crash. The only difference being
> the bad block scan.
>
> These are the outputs of ksymoops for the stack trace part
> of the oops output from. Kernel version is
> linux-2.4.21-pre3-ac4.
>
> Adhoc c013f4b7 <try_to_free_buffers+c7/140>
> Adhoc c013d8c9 <try_to_release_page+49/50>
> Adhoc c01348ac <__free_pages+1c/20>
> Adhoc c0133863 <shrink_cache+383/3b0>
> Adhoc c01339f6 <shrink_caches+56/80>
> Adhoc c0133a5c <try_to_free_pages_zone+3c/60>
> Adhoc c013452e <balance_classzone+5e/1d0>
> Adhoc c01347b2 <__alloc_pages+112/160>
> Adhoc c012ebc1 <generic_file_write+3f1/710>
> Adhoc c01344c6 <_alloc_pages+16/20>
> Adhoc c012ebdd <generic_file_write+40d/710>
> Adhoc c013b316 <sys_write+96/110>
> Adhoc c0106f8b <system_call+33/38>
>
> Adhoc c0134239 <__free_pages_ok+279/2a0>
>
> I'm going to do further tests with the generic IDE
> driver instead of the NVIDIA one. Then I plan on
> teasing out the NVIDIA2 specific stuff from the ac4
> patch and only applying them to a pre3 patched kernel.
>
> - Bryan
>
> -
> 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/
>
next prev parent reply other threads:[~2003-01-19 10:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-18 0:05 2.4.21-pre3-ac4 oops in free_pages_ok Bryan Andersen
2003-01-19 11:01 ` Bryan Andersen [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-01-16 16:28 Phil Oester
2003-01-16 19:13 ` Tupshin Harper
2003-01-17 7:47 ` Ralf Hildebrandt
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=3E2A85A3.4090402@bogonomicon.net \
--to=bryan@bogonomicon.net \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox