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 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.