On Mon, 19 Jan 2004, Gerd Knorr wrote:

> > > CONFIG_PREEMPT=y
> >
> > Bug reproducable with this one turned off?
>
> Hmm, running -mm4 with CONFIG_PREEMPT now, box loaded with bttv capture
> + parallel kernel builds, no problems so far ...
>

yes
bug is reproduceable with preempt turned off

Transcode uses threads to capture and encode the movie. However i don't
know how many threads are allocated for capturing.

I tried to run transcode with only one thread for encoding and one buffer
for capturing (option -u 1,1 )

When  writing this email (after the oops) i also got this:

MCE: The hardware reports a non fatal, correctable incident occurred on
CPU 0.
Bank 1: 9400000000000151

> > > Slab corruption: start=c57c2000, len=4096
>                            ^^^^^^^^
> > > 000: 6e 72 6d 71 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > > bttv0: skipped frame. no signal? high irq latency? [main=b030000,o_vbi=b030018,o_field=5378000,rc=537801c]
>
> Who is this?  Is this allocated by bttv?  Or someone else corrupts
> memory here?
>
> btcx-risc and video-buf have a "debug=1" insmod option, bttv has
> "bttv_debug=1".  Those make bttv verbose (*plenty* of log, so better
> don't try all three at the same time ...) and also log addresses of
> (some) allocated memory blocks.
>
> btcx-risc calls pci_alloc_consistent() and thus does PAGE_SIZE
> allocations, that one likely is a good candidate to start with.
>

see atachment
this is with btcx-risc and video-buf with debug=1

i tried also with bttv_debug=1 when loadijng bttv module but haven't
noticed anything strange.
I can send the debug messages from bttv if you want.

>   Gerd
>

--
"A mouse is a device used to point at
the xterm you want to type in".
Kim Alm on a.s.r.