[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
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
On Nov 28, Duncan Sands <[email protected]> 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
Marco d'Itri wrote:
>On Nov 28, Duncan Sands <[email protected]> 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
On Monday 28 November 2005 10:17, Mike Krufky wrote:
>Marco d'Itri wrote:
>>On Nov 28, Duncan Sands <[email protected]> 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 [email protected]
>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.
Gene Heskett wrote:
>On Monday 28 November 2005 10:17, Mike Krufky wrote:
>
>
>>Marco d'Itri wrote:
>>
>>
>>>On Nov 28, Duncan Sands <[email protected]> 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
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 <[email protected]> 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
On Monday 28 November 2005 16:17, Mike Krufky wrote:
> Marco d'Itri wrote:
>
> >On Nov 28, Duncan Sands <[email protected]> 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.