From: "Jay L. T. Cornwall" <jay@esuna.co.uk>
To: Oleg Verych <olecom@flower.upol.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Chuck Ebbert <cebbert@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: (Last oops is Tainted: P) Re: 2.6.22-rc5: pdflush oops under heavy disk load
Date: Sun, 24 Jun 2007 11:10:09 +0100 [thread overview]
Message-ID: <467E4301.2010009@esuna.co.uk> (raw)
In-Reply-To: <E1I2OqK-0005VK-JF@flower>
Oleg Verych wrote:
>> That sounds like a good theory: you're getting easily-hit oopses in one of
>> the kernel's most-used codepaths which hasn't chanbged much in a long
>> time. So Something Odd Has Happened.
> Maybe this time it's just "Tainted: P"?
That'sthe NVIDIA module, which isn't doing much with X shut down
regardless. It was bad form to forget this, of course, but is unrelated
to the problem.
> And oops have no ext3, like prev. one.
I know. This isn't ext3 related and I'm fairly certain drivers/net/atl1
is trashing... something. Perhaps the page table because:
[ 153.785325] Bad page state in process 'scp'
[ 153.785327] page:ffff81000308d020 flags:0x0040ad41dc050845
mapping:53dfe57d17cc59cf mapcount:16885953 count:292554304
[ 153.785329] Trying to fix it up, but a reboot is needed
This one dismisses a reference counting issue because the page data here
looks like garbage. And a panic in VLC, playing a video across the
network hits a similar problem:
[ 9194.281809] [<ffffffff802849e3>] page_remove_rmap+0x53/0x110
[ 9194.281819] [<ffffffff8027c32c>] unmap_vmas+0x4ec/0x7c0
[ 9194.281852] [<ffffffff802807ac>] unmap_region+0xcc/0x170
[ 9194.281867] [<ffffffff8028160a>] do_munmap+0x22a/0x2f0
[ 9194.281877] [<ffffffff80439ee2>] __down_write_nested+0x12/0xb0
[ 9194.281892] [<ffffffff802ef936>] sys_shmdt+0xb6/0x150
[ 9194.281903] [<ffffffff80209e8e>] system_call+0x7e/0x83
[ 9194.281921]
[ 9194.281924]
[ 9194.281925] Code: 48 2b ba 98 21 00 00 48 c1 ff 03 48 0f af f8 48 03
ba a8 21
[ 9194.281973] RIP [<ffffffff80271f99>] page_to_pfn+0x19/0x40
> Jay, check your oops against "Tainted: P" flag, which is not supported
> here, and not drop persons, who assisted you from the CC list.
My apologies, I had thought the etiquette was to only include
maintainers on the CC list.
I'll try and locate a maintainer for the Attansic driver a bit later,
but I've only seen people loosely related to it. In any case we may as
well let this thread die because it's not related to a filesystem bug
(which the CC list is presumably interested in).
--
Jay L. T. Cornwall, http://www.esuna.co.uk/~jay/
PhD Student
Imperial College London
next prev parent reply other threads:[~2007-06-24 10:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-22 0:07 2.6.22-rc5: pdflush oops under heavy disk load Jay L. T. Cornwall
2007-06-22 14:47 ` Chuck Ebbert
2007-06-22 15:04 ` Jay L. T. Cornwall
2007-06-23 12:14 ` Jay L. T. Cornwall
2007-06-23 17:23 ` Andrew Morton
2007-06-24 9:57 ` (Last oops is Tainted: P) " Oleg Verych
2007-06-24 10:10 ` Jay L. T. Cornwall [this message]
2007-06-24 10:57 ` Oleg Verych
2007-06-24 17:59 ` Jay Cliburn
2007-06-24 20:31 ` Jay L. T. Cornwall
2007-06-24 21:45 ` Jay Cliburn
2007-06-25 12:16 ` Attansic L1 page corruption (was: 2.6.22-rc5: pdflush oops under heavy disk load) Jay L. T. Cornwall
2007-06-25 12:42 ` Attansic L1 page corruption Jay Cliburn
2007-06-25 21:18 ` [PATCH] atl1: disable 64bit DMA Luca Tettamanti
2007-06-25 21:36 ` Chris Snook
2007-06-25 21:51 ` Jay L. T. Cornwall
2007-06-25 21:57 ` Chris Snook
2007-06-25 23:00 ` Jay Cliburn
2007-06-25 23:17 ` Jeff Garzik
2007-06-25 23:40 ` Chris Snook
2007-06-26 21:12 ` Luca
2007-06-27 0:16 ` Jay Cliburn
2007-06-25 12:58 ` Attansic L1 page corruption (was: 2.6.22-rc5: pdflush oops under heavy disk load) Luca
2007-06-24 22:51 ` 2.6.22-rc5: pdflush oops under heavy disk load Jesper Juhl
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=467E4301.2010009@esuna.co.uk \
--to=jay@esuna.co.uk \
--cc=akpm@linux-foundation.org \
--cc=cebbert@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=olecom@flower.upol.cz \
/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.