Update from latest svn. I've reverted the use of GFP_DMA32 in kmallocs,
I think that's the cause of this. I don't really understand it, but
it's not important enough to spend time on this.
Hans
On Sunday 27 August 2006 18:34, Michael Zanetti wrote:
> Hi Hans,
>
> FYI,
> I just got this in my kernel log while watching live-tv:
>
> BUG: unable to handle kernel paging request at virtual address
> 00057ae9 printing eip:
> c018014f
> *pde = 00000000
> Oops: 0000 [#1]
> PREEMPT
> Modules linked in: nvidia snd_bt87x tvaudio bttv video_buf ir_common
> btcx_risc lirc_i2c lirc_dev wm8775 cx25840 msp3400 saa7127 saa7115
> tda9887 tuner ivtv tveeprom acx firmware_class snd_via82xx
> snd_ac97_codec snd_ac97_bus snd_mpu401_uart snd_rawmidi skge
> CPU: 0
> EIP: 0060:[<c018014f>] Tainted: P VLI
> EFLAGS: 00010202 (2.6.17-gentoo-r3 #9)
> EIP is at ext3_new_inode+0x4da/0x5b0
> eax: d09de000 ebx: 00057a95 ecx: 0000a000 edx: 00057a95
> esi: cbae1cec edi: 00000000 ebp: dfe4e5b4 esp: d09dfeb8
> ds: 007b es: 007b ss: 0068
> Process ln (pid: 2416, threadinfo=d09de000 task=d4b3d070)
> Stack: dfc86b80 c1725400 00057a95 00000016 ca5b4e70 dfe35400 dfe4e5b4
> cb7e5314
> cd405440 d5c06005 cb7e5314 c0186920 cb26e3ec cd405440
> 0000a1ff 00000005
> cb26e3ec 00000000 cb7e5314 cd405440 d5c06000 cb7e5314
> c0157683 cd405440
> Call Trace:
> <c0186920> ext3_symlink+0x91/0x185 <c0157683> vfs_symlink+0x51/0xad
> <c015775a> sys_symlinkat+0x7b/0xb6 <c01577a4> sys_symlink+0xf/0x13
> <c0102aa7> sysenter_past_esp+0x54/0x75
> Code: 01 00 00 41 74 08 8b 5c 24 38 80 4b 10 01 ff 76 20 56 e8 c2 f6
> fd ff 59 5b b8 00 e0 ff ff 21 e0 ff 40 14 8b 54 24 08 8b 5c 24 08
> <8b> 4a 54 8d 51 01 89 53 54 89 8e fc 00 00 00 ff 48 14 8b 40 08
> EIP: [<c018014f>] ext3_new_inode+0x4da/0x5b0 SS:ESP 0068:d09dfeb8
> <6>note: ln[2416] exited with preempt_count 1
> bttv0: OCERR @ 170d4000,bits: HSYNC OFLOW OCERR*
> bttv0: OCERR @ 170d401c,bits: HSYNC OFLOW FBUS OCERR*
> bttv0: OCERR @ 170d401c,bits: HSYNC OFLOW OCERR*
> bttv0: OCERR @ 170d401c,bits: HSYNC OFLOW OCERR*
> bttv0: OCERR @ 170d401c,bits: HSYNC OFLOW OCERR*
> bttv0: OCERR @ 170d401c,bits: HSYNC OFLOW OCERR*
> ivtv-enc: page allocation failure. order:4, mode:0xd0
> <c0134892> __alloc_pages+0x259/0x26b <c0146212>
> kmem_getpages+0x39/0x8d <c0146ca4> cache_grow+0xb3/0x158 <c0146e89>
> cache_alloc_refill +0x140/0x177
> <c0147158> __kmalloc+0x56/0x61 <e0a1346c> ivtv_init_buffer+0x4c/
> 0x16f [ivtv]
> <e0a13e37> enc_gather_free_buffers+0x8d/0x1a7 [ivtv] <e0a1eb1b>
> ivtv_sched_DMA+0x5a4/0x875 [ivtv]
> <c0126f97> hrtimer_run_queues+0x14/0xd0 <c0111a13>
> default_wake_function+0x0/0x12
> <c0111a13> default_wake_function+0x0/0x12 <e0a230ad> ivtv_enc_thread
> +0x139/0x1ae [ivtv]
> <c0357829> schedule+0x493/0x538 <e0a21cd6> enc_work_handler
> +0x21/0x2c [ivtv]
> <e0a23109> ivtv_enc_thread+0x195/0x1ae [ivtv] <c01249ca>
> autoremove_wake_function+0x0/0x3a
> <c03580ea> schedule_timeout+0x6f/0x8e <c01249ca>
> autoremove_wake_function+0x0/0x3a
> <e0a22f74> ivtv_enc_thread+0x0/0x1ae [ivtv] <c01012dd>
> kernel_thread_helper+0x5/0xb
> Mem-info:
> DMA per-cpu:
> cpu 0 hot: high 0, batch 1 used:0
> cpu 0 cold: high 0, batch 1 used:0
> DMA32 per-cpu: empty
> Normal per-cpu:
> cpu 0 hot: high 186, batch 31 used:155
> cpu 0 cold: high 62, batch 15 used:61
> HighMem per-cpu: empty
> Free pages: 19048kB (0kB HighMem)
> Active:67647 inactive:36866 dirty:50 writeback:0 unstable:0 free:4762
> slab:14668 mapped:60119 pagetables:286
> DMA free:2080kB min:88kB low:108kB high:132kB active:6512kB inactive:
> 3008kB present:16384kB pages_scanned:0 all_unreclaimable? no
> lowmem_reserve[]: 0 0 495 495
> DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB
> present:0kB pages_scanned:0 all_unreclaimable? no
> lowmem_reserve[]: 0 0 495 495
> Normal free:16968kB min:2800kB low:3500kB high:4200kB active:264076kB
> inactive:144456kB present:507584kB pages_scanned:1 all_unreclaimable?
> no lowmem_reserve[]: 0 0 0 0
> HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:
> 0kB present:0kB pages_scanned:0 all_unreclaimable? no
> lowmem_reserve[]: 0 0 0 0
> DMA: 76*4kB 12*8kB 1*16kB 0*32kB 0*64kB 1*128kB 0*256kB 1*512kB
> 1*1024kB 0*2048kB 0*4096kB = 2080kB
> DMA32: empty
> Normal: 3682*4kB 192*8kB 6*16kB 1*32kB 1*64kB 0*128kB 0*256kB 1*512kB
> 0*1024kB 0*2048kB 0*4096kB = 16968kB
> HighMem: empty
> Swap cache: add 113, delete 113, find 2/3, race 0+0
> Free swap = 987568kB
> Total swap = 987988kB
> Free swap: 987568kB
> 130992 pages of RAM
> 0 pages of HIGHMEM
> 3284 reserved pages
> 72823 pages shared
> 0 pages swap cached
> 50 pages dirty
> 0 pages writeback
> 60119 pages mapped
> 14668 pages slab
> 286 pages pagetables
> ivtv0 warning: No memory on buffer alloc!
> ivtv0 warning: Needed 20480 bufs for encoder MPEG stream, received 0
> (buffers free 0, dma 0, full 164)
>
>
> Not sure if this has got to do something with your patch but its
> something with ivtv and DMA.
>
> I have to say that the patch is a good improvement. The systems looks
> a lot more stable than before. Since turning off commflagging I
> haven't seen any new DMA error 0x000000000b.
> Thank you again!
>
> Michael
>
> Am 25.08.2006 um 18:49 schrieb Hans Verkuil:
> > Hi all,
> >
> > As promised, here is the patch that should fix the DMA errors:
> >
> > http://www.xs4all.nl/~hverkuil/ivtv-dma.0.4.diff
> > http://www.xs4all.nl/~hverkuil/ivtv-dma.0.6.diff
> >
> > The first is the patch for ivtv-0.4.6, the second is the patch for
> > ivtv-0.6.3 and ivtv-0.7.0 (and also applies to the ivtv trunk).
> >
> > The patches were made in the driver directory of the ivtv source,
> > so you
> > have to apply it there.
> >
> > I have personally only tested it for the trunk (bleeding edge
> > development), but I expect no problems with the other versions
> > since the code touched by this patch is pretty much unchanged since
> > ivtv-0.2.
> >
> > Please test this thoroughly. Especially in combination with MythTV.
> > If you can, also combine it with MPEG decoding, VBI recording,
> > X-driver, etc.
> >
> > Some background information:
> >
> > There are several possible DMA errors. One in particular is causing
> > all
> > the problems. When a DMA write error occurs it seems the DMA engine
> > of the card gets confused as to what the start address is of the
> > card's buffers. After the DMA error the start of a buffer is set
> > between 0 and
> > 128 bytes before the actual start. Luckily for me it is not
> > trashed, but always limited between 0 and 128 bytes.
> >
> > So my solution is to write a special 32-bit start marker value at
> > the start of the buffer on the card (taking care to first read the
> > original
> > value), then start the DMA, but making the total size 256 bytes
> > more than is strictly necessary.
> >
> > When the DMA is finished I check whether I detect the marker value
> > at the expected place. If not, then I look for it in the first 128
> > bytes. The place where I find the marker is the new offset. I now
> > replace the marker with the original value I saved earlier and I
> > have a complete buffer. Because I actually DMA a bit more than is
> > needed, I still have all data, even if it is shifted the maximum of
> > 128 bytes. Without the extra DMA length the latter 128 bytes might
> > never be copied by the DMA engine, so that's the reason for the
> > extra length.
> >
> > This solution is very fast so there is no performance penalty.
> >
> > During stress testing (lots of CPU frequency changes) you will see
> > these
> > DMA errors occurring, but rather than giving you a broken MPEG
> > stream the DMA will be retried and the new offset found to keep the
> > MPEG stream uncorrupted. If you get a burst of these DMA errors
> > (again, we're talking continuous CPU frequency changes here, not a
> > normal situation), then some corruption may occur but it should be
> > only for a few frames.
> >
> > As far as I can tell this particular DMA error is now handled
> > correctly.
> >
> > Unfortunately there is still a 'ENC: REG_DMAXFER 2 wait failed'
> > error where it looks like the complete DMA engine is stalled.
> > Again, reboot is the only option. It only occurs during a very
> > heavy load and I don't
> > think it will happen during normal operation.
> >
> > I'm not sure whether this can be fixed at the moment. There are
> > still some problems with the way the current DMA handling is done
> > with possible race conditions. I need more research and testing to
> > determine
> > whether this is something that can be solved.
> >
> > Please keep me informed on how this works, if the test results are
> > positive then I'll make new releases next week.
> >
> > Enjoy (I hope :-),
> >
> > Hans
> >
> > _______________________________________________
> > ivtv-users mailing list
> > [email protected]
> > http://ivtvdriver.org/mailman/listinfo/ivtv-users
>
> _______________________________________________
> ivtv-users mailing list
> [email protected]
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users
