From: Gerd Knorr <kraxel@bytesex.org>
To: linux-kernel@vger.kernel.org
Subject: Re: Fw: Slab coruption and oops with 2.6.1-mm4
Date: 20 Jan 2004 12:51:26 +0100 [thread overview]
Message-ID: <877jzmn8ht.fsf@bytesex.org> (raw)
In-Reply-To: Pine.LNX.4.53.0401200219170.293@grinch.ro
caszonyi@rdslink.ro writes:
> yes
> bug is reproduceable with preempt turned off
Ok. Makes a locking flaw less likely as those tend to trigger with
preemp or smp only.
> MCE: The hardware reports a non fatal, correctable incident occurred on
> CPU 0.
> Bank 1: 9400000000000151
That pretty much looks like it is really a hardware issue.
> > > > Slab corruption: start=c57c2000, len=4096
> > ^^^^^^^^
> > Who is this? Is this allocated by bttv? Or someone else corrupts
> > memory here?
> [ bttv load messages ]
> btcx: riscmem alloc size=2320 [2]
That isn't a fresh booted box, is it? Please reboot the machine after
every oops and before continuing testing. With known-corrupted memory
it can oops basically everythere and those oops reports don't help
much.
> btcx: skips line 0-9999:
> btcx: riscmem free [1]
> vbuf: init user [0x43267008+0x6c000 => 109 pages]
> btcx: riscmem alloc size=3184 [2]
> btcx: riscmem free [1]
> btcx: riscmem alloc size=2320 [2]
> btcx: skips line 0-9999:
> btcx: riscmem free [1]
> vbuf: init user [0x43267008+0x6c000 => 109 pages]
> btcx: riscmem alloc size=3184 [2]
> btcx: riscmem free [1]
That was xawtv I guess? Now transcode starting?
> vbuf: mmap setup: 32 buffers, 2129920 bytes each
> vbuf: mmap c9cfc96c: 422fd000-463fd000 pgoff 00000000 bufs 0-31
> vbuf: init user [0x42505000+0x208000 => 520 pages]
> btcx: riscmem alloc size=7820 [2]
> btcx: riscmem alloc size=7820 [3]
Oh, doesn't print the riscmem addresses. The blocks are two-page
sized through, so the one-page allocation slab complains about above
likely doesn't come from this.
> Unable to handle kernel paging request at virtual address 25262e29
^^^^^^^^
strange value for a kernel address, probably some corrupted pointer.
> EIP is at videobuf_dma_free+0x33/0xc0 [video_buf]
> eax: 00000000 ebx: c45a7000 ecx: 00000208 edx: 25262e29
> esi: 00000000 edi: c817cf54 ebp: d0a35720 esp: c4135c18
in edx. "objdump -Sd video-buf.o" should help finding the instruction
and corrospending source line, but I fear that wouldn't help much as
that isn't the source of the problem but the place where it shows up.
> btcx: riscmem free [64]
> [ ... ]
> btcx: riscmem free [3]
cleanups due to transcode being killed ...
> Unable to handle kernel paging request at virtual address 25262e29
... and here it hits the very same corrupted pointer again.
Gerd
--
"... und auch das ganze Wochenende oll" -- Wetterbericht auf RadioEins
prev parent reply other threads:[~2004-01-20 12:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20040118220051.3f3d8420.akpm@osdl.org>
2004-01-19 12:15 ` Fw: Slab coruption and oops with 2.6.1-mm4 Gerd Knorr
2004-01-19 16:05 ` Gerd Knorr
2004-01-20 0:27 ` caszonyi
2004-01-20 1:22 ` Mike Fedyk
2004-01-20 11:51 ` Gerd Knorr [this message]
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=877jzmn8ht.fsf@bytesex.org \
--to=kraxel@bytesex.org \
--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