saa7134 broken in 2.6.15-rc2

saa7134 broken in 2.6.15-rc2

[Marco d'Itri]

[I am not subscribed anymore to the v4l list, please Cc me.]

If I remove the card=2 parameter then it loads without errors (but
obviously it will not work).

Nov 28 14:34:52 wonderland kernel: saa7130/34: v4l2 driver version 0.2.14 loaded
Nov 28 14:34:52 wonderland kernel: ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 16 (level, low) -> IRQ 20
Nov 28 14:34:52 wonderland kernel: saa7134[0]: found at 0000:00:0a.0, rev: 1, irq: 20, latency: 32, mmio: 0xd6000000
Nov 28 14:34:52 wonderland kernel: saa7134[0]: subsystem: 1131:0000, board: LifeView FlyVIDEO3000 [card=2,insmod option]
Nov 28 14:34:52 wonderland kernel: saa7134[0]: board init: gpio is 31000
Nov 28 14:34:52 wonderland kernel: saa7134[0]: there are different flyvideo cards with different tuners
Nov 28 14:34:52 wonderland kernel: saa7134[0]: out there, you might have to use the tuner=<nr> insmod
Nov 28 14:34:52 wonderland kernel: saa7134[0]: option to override the default value.
Nov 28 14:34:52 wonderland kernel: Unable to handle kernel NULL pointer dereference at virtual address 000006d0
Nov 28 14:34:52 wonderland kernel:  printing eip:
Nov 28 14:34:52 wonderland kernel: c0259b1b
Nov 28 14:34:52 wonderland kernel: *pde = 00000000
Nov 28 14:34:52 wonderland kernel: Oops: 0000 [#1]
Nov 28 14:34:52 wonderland kernel: Modules linked in: saa7134 radeon drm binfmt_misc af_packet lp nfsd exportfs lockd ipt_MASQUERADE sunrpc iptable_nat ip_nat ip_conntrack nfnetlink ipt_REJECT ipt_multiport iptable_filter ip_tables pppoatm ppp_generic slhc cxacru firmware_class usbatm atm it87 hwmon_vid hwmon i2c_dev i2c_isa usbhid snd_seq_midi snd_seq_midi_event snd_seq snd_via82xx snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi psmouse snd_seq_device serio_raw parport_pc parport 8250_pnp 8250 snd serial_core soundcore video_buf v4l2_common v4l1_compat ir_kbd_i2c ir_common videodev i2c_viapro evdev i2c_core skge crc32 ehci_hcd uhci_hcd sata_via libata usbcore ide_cd scsi_mod via_agp agpgart cdrom
Nov 28 14:34:52 wonderland kernel: CPU:    0
Nov 28 14:34:52 wonderland kernel: EIP:    0060:[<c0259b1b>]    Not tainted VLI
Nov 28 14:34:52 wonderland kernel: EFLAGS: 00010296   (2.6.15-rc2) 
Nov 28 14:34:52 wonderland kernel: EIP is at input_register_device+0xb/0x190
Nov 28 14:34:52 wonderland kernel: eax: 00000000   ebx: d0954a38   ecx: 00000000   edx: cc76d800
Nov 28 14:34:52 wonderland kernel: esi: 00000000   edi: ce872000   ebp: cc57ddec   esp: cc57ddd8
Nov 28 14:34:52 wonderland kernel: ds: 007b   es: 007b   ss: 0068
Nov 28 14:34:52 wonderland kernel: Process modprobe (pid: 5554, threadinfo=cc57c000 task=d37af540)
Nov 28 14:34:52 wonderland kernel: Stack: e0c540c0 00000200 d0954a38 d0954a38 d0954800 cc57de28 e0c431c5 00000000 
Nov 28 14:34:52 wonderland kernel:        d0954804 00000063 e0c540c0 d0954a18 cc76d800 e0c540c0 0ec00000 00040000 
Nov 28 14:34:52 wonderland kernel:        00000000 ce872000 dff0c000 000001e0 cc57de3c e0c3a448 ce872000 e0c448ae 
Nov 28 14:34:52 wonderland kernel: Call Trace:
Nov 28 14:34:52 wonderland kernel:  [<c01039ec>] show_stack+0x9c/0xe0
Nov 28 14:34:52 wonderland kernel:  [<c0103baf>] show_registers+0x15f/0x1f0
Nov 28 14:34:52 wonderland kernel:  [<c0103dad>] die+0xcd/0x150
Nov 28 14:34:52 wonderland kernel:  [<c030cd59>] do_page_fault+0x209/0x67b
Nov 28 14:34:52 wonderland kernel:  [<c010369f>] error_code+0x4f/0x54
Nov 28 14:34:52 wonderland kernel:  [<e0c431c5>] saa7134_input_init1+0x1d5/0x420 [saa7134]
Nov 28 14:34:52 wonderland kernel:  [<e0c3a448>] saa7134_hwinit1+0x98/0x110 [saa7134]
Nov 28 14:34:52 wonderland kernel:  [<e0c3ab35>] saa7134_initdev+0x2f5/0x7d0 [saa7134]
Nov 28 14:34:52 wonderland kernel:  [<c01ddd89>] pci_call_probe+0x19/0x20
Nov 28 14:34:52 wonderland kernel:  [<c01ddde1>] __pci_device_probe+0x51/0x60
Nov 28 14:34:52 wonderland kernel:  [<c01dde1f>] pci_device_probe+0x2f/0x50
Nov 28 14:34:52 wonderland kernel:  [<c02424f1>] driver_probe_device+0x41/0xc0
Nov 28 14:34:52 wonderland kernel:  [<c024265f>] __driver_attach+0x4f/0x60
Nov 28 14:34:52 wonderland kernel:  [<c0241a84>] bus_for_each_dev+0x54/0x80
Nov 28 14:34:52 wonderland kernel:  [<c0242698>] driver_attach+0x28/0x30
Nov 28 14:34:52 wonderland kernel:  [<c0241f6d>] bus_add_driver+0x7d/0xe0
Nov 28 14:34:52 wonderland kernel:  [<c0242abd>] driver_register+0x3d/0x50
Nov 28 14:34:52 wonderland kernel:  [<c01de0a2>] __pci_register_driver+0x72/0x90
Nov 28 14:34:52 wonderland kernel:  [<e0c3b322>] saa7134_init+0x52/0x60 [saa7134]
Nov 28 14:34:52 wonderland kernel:  [<c0130fed>] sys_init_module+0xcd/0x1c0
Nov 28 14:34:52 wonderland kernel:  [<c0102c09>] syscall_call+0x7/0xb
Nov 28 14:34:52 wonderland kernel: Code: 44 24 04 a8 13 37 c0 e8 24 15 f3 ff 83 c4 10 5b 5e 5f c9 c3 8d b6 00 00 00 00 8d bf 00 00 00 00 55 89 e5 56 53 83 ec 0c 8b 75 08 <8b> 96 d0 06 00 00 85 d2 0f 84 4e 01 00 00 8d 86 3c 06 00 00 c7 

-- 
ciao,
Marco

Re: saa7134 broken in 2.6.15-rc2

[Duncan Sands]

There seems to be something rotten in v4l land; here's one I got with 2.6.15-rc1-git1
(I get this one a lot, but I've seen all kinds of other oopsen with recent
kernels - memory corruption? - perhaps DMA is still writing to freed memory?).

Ciao,

Duncan.

[4294993.999000] Unable to handle kernel paging request at virtual address cf81f000
[4294994.024000]  printing eip:
[4294994.033000] e0b6f738
[4294994.041000] *pde = 0003e067
[4294994.051000] *pte = 0f81f000
[4294994.060000] Oops: 0002 [#1]
[4294994.060000] DEBUG_PAGEALLOC
[4294994.060000] Modules linked in: af_packet md5 ipv6 usblp radeon drm tun video thermal processor fan button ipt_TOS ipt_MASQUERADE ipt_REJECT ipt_LOG ipt_state ipt_pkttype ipt_owner ipt_iprange ipt_multiport ipt_conntrack iptable_mangle ip_nat_irc ip_nat_tftp ip_nat_ftp iptable_nat ip_nat ip_conntrack_irc ip_conntrack_tftp ip_conntrack_ftp ip_conntrack iptable_filter ip_tables generic i2c_viapro uhci_hcd usbcore snd_bt87x tuner tvaudio bttv video_buf firmware_class i2c_algo_bit v4l2_common btcx_risc tveeprom i2c_core videodev snd_cs46xx snd_rawmidi snd_seq_device snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc via_agp agpgart nls_cp437 ntfs ide_cd cdrom mousedev psmouse unix
[4294994.060000] CPU:    0
[4294994.060000] EIP:    0060:[<e0b6f738>]    Not tainted VLI
[4294994.060000] EFLAGS: 00210202   (2.6.15-rc1-git1)
[4294994.060000] EIP is at bttv_risc_packed+0x168/0x190 [bttv]
[4294994.060000] eax: 14000008   ebx: 00000408   ecx: cf81f000   edx: d17f5800
[4294994.060000] esi: 00000008   edi: d17f5800   ebp: d184ce6c   esp: d184ce54
[4294994.060000] ds: 007b   es: 007b   ss: 0068
[4294994.060000] Process xawtv (pid: 7506, threadinfo=d184c000 task=d5ba6ab0)
[4294994.060000] Stack: d059cfbc e0b83560 000000ff 000d8000 00000c00 d059cef8 d184ced4 e0b70fca
[4294994.060000]        00000c00 00000c00 00000c00 00000120 00000008 000001b1 d059cf1c d059cf1c
[4294994.060000]        c1753bf8 d184ceb4 e0b83560 aeaf0000 00000000 d059cef8 e0b72598 000d8000
[4294994.060000] Call Trace:
[4294994.060000]  [<c01039a7>] show_stack+0x97/0xd0
[4294994.060000]  [<c0103b55>] show_registers+0x155/0x1f0
[4294994.060000]  [<c0103d72>] die+0xe2/0x170
[4294994.060000]  [<c02c08cc>] do_page_fault+0x1ec/0x648
[4294994.060000]  [<c0103643>] error_code+0x4f/0x54
[4294994.060000]  [<e0b70fca>] bttv_buffer_risc+0x61a/0x640 [bttv]
[4294994.060000]  [<e0b667bb>] bttv_prepare_buffer+0xab/0x1a0 [bttv]
[4294994.060000]  [<e0b66958>] buffer_prepare+0x38/0x40 [bttv]
[4294994.060000]  [<e0a2a3cd>] videobuf_read_zerocopy+0x5d/0x100 [video_buf]
[4294994.060000]  [<e0a2a622>] videobuf_read_one+0x1b2/0x210 [video_buf]
[4294994.060000]  [<e0b69575>] bttv_read+0x115/0x120 [bttv]
[4294994.060000]  [<c0155923>] vfs_read+0x93/0x150
[4294994.060000]  [<c0155c8d>] sys_read+0x3d/0x70
[4294994.060000]  [<c0102b2f>] sysenter_past_esp+0x54/0x75
[4294994.060000] Code: 8d 5f 2c 0d 00 00 00 10 89 01 8b 42 08 89 41 04 2b 72 0c 83 c1 08 8b 03 83 c2 10 83 c3 10 39 c6 77 e1 89 f0 89 d7 0d 00 00 00 14 <89> 01 8b 42 08 89 41 04 83 c1 08 89 f0 e9 5f ff ff ff 0f 0b 6b
[4294994.060000]  <4>mtrr: 0xc0000000,0x10000000 overlaps existing 0xc0000000,0x8000000

Re: saa7134 broken in 2.6.15-rc2

[Marco d'Itri]

On Nov 28, Duncan Sands <duncan.sands@math.u-psud.fr> wrote:

> There seems to be something rotten in v4l land; here's one I got with 2.6.15-rc1-git1
Yes, I should have STFW better: http://lkml.org/lkml/fancy/2005/11/24/194 .

video-buf is still broken for me in -rc2, I can make xawtv work if I set
capture to "overlay", but it still complain about no input sources other
than "default".

-- 
ciao,
Marco

Re: saa7134 broken in 2.6.15-rc2

[Mike Krufky]

Marco d'Itri wrote:

>On Nov 28, Duncan Sands <duncan.sands@math.u-psud.fr> wrote:
>
>>here seems to be something rotten in v4l land; here's one I got with 2.6.15-rc1-git1
>>    
>>
>Yes, I should have STFW better: http://lkml.org/lkml/fancy/2005/11/24/194 .
>
>video-buf is still broken for me in -rc2, I can make xawtv work if I set
>capture to "overlay", but it still complain about no input sources other
>than "default".
>
Please try again, using the current -git snapshot.... The memory 
problems have been fixed by Hugh Dickins in 2.6.15-rc2-git3 , and Dmitry 
has submitted some input fixes after that.....

I am running 2.6.15-rc2-git6 with no problems.

If you are still having problems, please let us know, being sure to cc 
the v4l mailing list.

Cheers,

Michael Krufky

Re: saa7134 broken in 2.6.15-rc2

[Gene Heskett]

On Monday 28 November 2005 10:17, Mike Krufky wrote:
>Marco d'Itri wrote:
>>On Nov 28, Duncan Sands <duncan.sands@math.u-psud.fr> wrote:
>>>here seems to be something rotten in v4l land; here's one I got with
>>> 2.6.15-rc1-git1
>>
>>Yes, I should have STFW better:
>> http://lkml.org/lkml/fancy/2005/11/24/194 .
>>
>>video-buf is still broken for me in -rc2, I can make xawtv work if I
>> set capture to "overlay", but it still complain about no input
>> sources other than "default".
>
>Please try again, using the current -git snapshot.... The memory
>problems have been fixed by Hugh Dickins in 2.6.15-rc2-git3 , and
> Dmitry has submitted some input fixes after that.....
>
>I am running 2.6.15-rc2-git6 with no problems.
>
Whats the patch sequence to arrive at rc2-git6 please?

>If you are still having problems, please let us know, being sure to cc
>the v4l mailing list.
>
>Cheers,
>
>Michael Krufky
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: saa7134 broken in 2.6.15-rc2

[Mike Krufky]

Gene Heskett wrote:

>On Monday 28 November 2005 10:17, Mike Krufky wrote:
>  
>
>>Marco d'Itri wrote:
>>    
>>
>>>On Nov 28, Duncan Sands <duncan.sands@math.u-psud.fr> wrote:
>>>      
>>>
>>>>here seems to be something rotten in v4l land; here's one I got with
>>>>2.6.15-rc1-git1
>>>>        
>>>>
>>>Yes, I should have STFW better:
>>>http://lkml.org/lkml/fancy/2005/11/24/194 .
>>>
>>>video-buf is still broken for me in -rc2, I can make xawtv work if I
>>>set capture to "overlay", but it still complain about no input
>>>sources other than "default".
>>>      
>>>
>>Please try again, using the current -git snapshot.... The memory
>>problems have been fixed by Hugh Dickins in 2.6.15-rc2-git3 , and
>>Dmitry has submitted some input fixes after that.....
>>
>>I am running 2.6.15-rc2-git6 with no problems.
>>
>>    
>>
>Whats the patch sequence to arrive at rc2-git6 please?
>

Umm... If I am understanding your question correctly:

Start with 2.6.14
    http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.14.tar.bz2

Apply 2.6.15-rc2
    http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.15-rc2.bz2

Apply 2.6.14-rc2-git6
    
http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.15-rc2-git6.bz2

Is this what you're asking???

Hope this helps,

Michael Krufky

Re: saa7134 broken in 2.6.15-rc2

[Randy.Dunlap]

On Mon, 28 Nov 2005 10:55:41 -0500 Mike Krufky wrote:

> Gene Heskett wrote:
> 
> >On Monday 28 November 2005 10:17, Mike Krufky wrote:
> >  
> >
> >>Marco d'Itri wrote:
> >>    
> >>
> >>>On Nov 28, Duncan Sands <duncan.sands@math.u-psud.fr> wrote:
> >>>      
> >>>
> >>>>here seems to be something rotten in v4l land; here's one I got with
> >>>>2.6.15-rc1-git1
> >>>>        
> >>>>
> >>>Yes, I should have STFW better:
> >>>http://lkml.org/lkml/fancy/2005/11/24/194 .
> >>>
> >>>video-buf is still broken for me in -rc2, I can make xawtv work if I
> >>>set capture to "overlay", but it still complain about no input
> >>>sources other than "default".
> >>>      
> >>>
> >>Please try again, using the current -git snapshot.... The memory
> >>problems have been fixed by Hugh Dickins in 2.6.15-rc2-git3 , and
> >>Dmitry has submitted some input fixes after that.....
> >>
> >>I am running 2.6.15-rc2-git6 with no problems.
> >>
> >>    
> >>
> >Whats the patch sequence to arrive at rc2-git6 please?
> >
> 
> Umm... If I am understanding your question correctly:
> 
> Start with 2.6.14
>     http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.14.tar.bz2
> 
> Apply 2.6.15-rc2
>     http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.15-rc2.bz2
> 
> Apply 2.6.14-rc2-git6
>     
> http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.15-rc2-git6.bz2
> 
> Is this what you're asking???

Gene,
I expect that lots of people use 'ketchup' to keep their kernel
trees up to date (those not using 'git', I mean).
If ketchup isn't to your liking, you could try my grab-kernel-rc
script:
  http://www.xenotime.net/linux/scripts/grab-kernel-rc

I have to run somewhere now, but I can explain it and help you
with it later if you are interested.

---
~Randy

Re: saa7134 broken in 2.6.15-rc2

[Duncan Sands]

On Monday 28 November 2005 16:17, Mike Krufky wrote:
> Marco d'Itri wrote:
> 
> >On Nov 28, Duncan Sands <duncan.sands@math.u-psud.fr> wrote:
> >
> >>here seems to be something rotten in v4l land; here's one I got with 2.6.15-rc1-git1
> >>    
> >>
> >Yes, I should have STFW better: http://lkml.org/lkml/fancy/2005/11/24/194 .
> >
> >video-buf is still broken for me in -rc2, I can make xawtv work if I set
> >capture to "overlay", but it still complain about no input sources other
> >than "default".
> >
> Please try again, using the current -git snapshot.... The memory 
> problems have been fixed by Hugh Dickins in 2.6.15-rc2-git3 , and Dmitry 
> has submitted some input fixes after that.....
> 
> I am running 2.6.15-rc2-git6 with no problems.
> 
> If you are still having problems, please let us know, being sure to cc 
> the v4l mailing list.
> 
> Cheers,
> 
> Michael Krufky

OK, I've found the cause of this oops (which occurs with 2.6-git of today):

[4294787.157000] Unable to handle kernel paging request at virtual address d0337000
[4294787.181000]  printing eip:
[4294787.191000] e0b4e8a8
[4294787.199000] *pde = 00040067
[4294787.208000] *pte = 10337000
[4294787.218000] Oops: 0002 [#1]
[4294787.218000] DEBUG_PAGEALLOC
[4294787.218000] Modules linked in: usblp radeon drm tun video thermal processor fan button md5 ipv6 ipt_TOS ipt_MASQUERADE ipt_REJECT ipt_LOG ipt_state ipt_pkttype ipt
_owner ipt_recent ipt_iprange ipt_multiport ipt_conntrack iptable_mangle ip_nat_irc ip_nat_tftp ip_nat_ftp iptable_nat ip_nat ip_conntrack_irc ip_conntrack_tftp ip_conntr
ack_ftp ip_conntrack iptable_filter ip_tables generic i2c_viapro cdc_ether usbnet uhci_hcd usbcore snd_bt87x tuner tvaudio bttv video_buf firmware_class i2c_algo_bit v4l2
_common btcx_risc tveeprom i2c_core videodev snd_cs46xx snd_rawmidi snd_seq_device snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore s
nd_page_alloc via_agp agpgart nls_cp437 ntfs mousedev psmouse unix
[4294787.218000] CPU:    0
[4294787.218000] EIP:    0060:[<e0b4e8a8>]    Not tainted VLI
[4294787.218000] EFLAGS: 00210202   (2.6.15-rc4-gb3c6aeb3)
[4294787.218000] EIP is at bttv_risc_packed+0x1b8/0x1e0 [bttv]
[4294787.218000] eax: 14000008   ebx: 00000408   ecx: d0337000   edx: d0f15800
[4294787.218000] esi: 00000008   edi: d0f15800   ebp: d11e4e6c   esp: d11e4e30
[4294787.218000] ds: 007b   es: 007b   ss: 0068
[4294787.218000] Process xawtv (pid: 7277, threadinfo=d11e4000 task=d85f1ab0)
[4294787.218000] Stack: e0b55b00 d0336000 00000fd0 00000c00 00000120 000001fa 00000ff8 d0f14000
[4294787.218000]        d0178fbc e0b62860 000000ff d0336ff8 000d8000 00000c00 d0178ef8 d11e4ed4
[4294787.218000]        e0b5013a 00000c00 00000c00 00000c00 00000120 00000008 000001b1 d0178f1c
[4294787.218000] Call Trace:
[4294787.218000]  [<c01039b7>] show_stack+0x97/0xd0
[4294787.218000]  [<c0103b65>] show_registers+0x155/0x1f0
[4294787.218000]  [<c0103d82>] die+0xe2/0x170
[4294787.218000]  [<c02c8d9c>] do_page_fault+0x1ec/0x648
[4294787.218000]  [<c0103653>] error_code+0x4f/0x54
[4294787.218000]  [<e0b5013a>] bttv_buffer_risc+0x61a/0x640 [bttv]
[4294787.218000]  [<e0b457bb>] bttv_prepare_buffer+0xab/0x1a0 [bttv]
[4294787.218000]  [<e0b45958>] buffer_prepare+0x38/0x40 [bttv]
[4294787.218000]  [<e0a2b393>] videobuf_read_zerocopy+0x63/0x110 [video_buf]
[4294787.218000]  [<e0a2b5f4>] videobuf_read_one+0x1b4/0x210 [video_buf]
[4294787.218000]  [<e0b48625>] bttv_read+0x115/0x120 [bttv]
[4294787.218000]  [<c01555c3>] vfs_read+0x93/0x150
[4294787.218000]  [<c015592d>] sys_read+0x3d/0x70
[4294787.218000]  [<c0102b3f>] sysenter_past_esp+0x54/0x75
[4294787.218000] Code: 2c 89 f6 0d 00 00 00 10 89 01 8b 42 08 89 41 04 2b 72 0c 83 c1 08 8b 03 83 c2 10 83 c3 10 39 c6 77 e1 89 f0 89 d7 0d 00 00 00 14 <89> 01 8b 42 08
 89 41 04 83 c1 08 89 f0 89 4d f0 e9 4f ff ff ff

bttv_risc_packed writes off the end of the risc->cpu buffer.  The problem is
that the length of the buffer is calculated wrongly.  The allocated size was
4048 bytes, but bttv_risc_packed wrote more than one page (the oops occurred
when it started over-writing the next page).  The length is instructions*8:

int
bttv_risc_packed(struct bttv *btv, struct btcx_riscmem *risc,
                 struct scatterlist *sglist,
                 unsigned int offset, unsigned int bpl,
                 unsigned int padding, unsigned int lines)
{
        u32 instructions,line,todo;
        struct scatterlist *sg;
        u32 *rp;
        int rc;

        /* estimate risc mem: worst case is one write per page border +
           one write per scan line + sync + jump (all 2 dwords) */
        instructions  = (bpl * lines) / PAGE_SIZE + lines;
        instructions += 2;
        if ((rc = btcx_riscmem_alloc(btv->c.pci,risc,instructions*8)) < 0)
                return rc;

But "instructions" is calculated wrong.  First of all, notice the division by
PAGE_SIZE?

        instructions  = (bpl * lines) / PAGE_SIZE + lines;

If sg_dma_len(sg) was constant (and bpl > 0), then a correct estimate seems
to be:

	instructions = (1 + (bpl - 1) / sg_dma_len(sg)) * lines - 1 + lines;
        instructions += 2;

Unfortunately sg is modified during the action of bttv_risc_packed, so I
guess sg_dma_len(sg) cannot be assumed to be constant.  Presumably PAGE_SIZE
is used because it is supposed to be a lower bound for sg_dma_len(sg).  Well,
this is wrong: for example when my oops occurs, the parameters are:

bpl: 3072; lines: 288; instructions: 506; sg_dma_len: 4088

and here sg_dma_len < PAGE_SIZE (this is the size of the first element in
sglist).  This is not however the cause of my oops: because bpl is smaller
than sg_dma_len(sg) and smaller than PAGE_SIZE, this error makes no difference
in the calculation of the buffer size.  It should be fixed of course, but if
sg_dma_len(sg) can be less than PAGE_SIZE, it is not clear to me how to fix it.

The other mistake in the buffer size calculation, and the one that hits me, is
that 2 * lines should be added, not lines: assuming that sg_dma_len(sg) >= PAGE_SIZE,
it looks to me like the calculation should be

        instructions  = (bpl * lines) / PAGE_SIZE + 2 * lines;
        instructions += 1;

The reason is that at least two instructions are written for every line in the case
when the scanline needs to be split:

                } else {
                        /* scanline needs to be splitted */
                        todo = bpl;
                        *(rp++)=cpu_to_le32(BT848_RISC_WRITE|BT848_RISC_SOL|
                                            (sg_dma_len(sg)-offset));
                        *(rp++)=cpu_to_le32(sg_dma_address(sg)+offset);
                        todo -= (sg_dma_len(sg)-offset);
                        offset = 0;
                        sg++;
                        while (todo > sg_dma_len(sg)) {
                                *(rp++)=cpu_to_le32(BT848_RISC_WRITE|
                                                    sg_dma_len(sg));
                                *(rp++)=cpu_to_le32(sg_dma_address(sg));
                                todo -= sg_dma_len(sg);
                                sg++;
                        }
                        *(rp++)=cpu_to_le32(BT848_RISC_WRITE|BT848_RISC_EOL|
                                            todo);
                        *(rp++)=cpu_to_le32(sg_dma_address(sg));
                        offset += todo;
                }

This means that instructions needs to be at least 2 * lines.

Of course it is possible that my estimate for instructions could be tightened.

Comments?

All the best,

Duncan.