On Tue, 2008-09-23 at 17:08 -0400, Oystein Thorsen wrote:
> It has taken me some time to respond to this because I have three 
> different (wrong) outcomes when loading the driver and I can't figure 
> out what the cause is, but I'll give you my guesses. I'll start with the 
> one most similar to your suggestion; debug output when module loads, but 
> no output.
> 
> /proc/interrupts:
>            CPU0       CPU1      
>   0:        194          0   IO-APIC-edge      timer
>  21:     480319          0   IO-APIC-fasteoi   cx18-0

Hmm.  The card is generating interrupts.  That's good, but that means
you should be getting video data too, hmmm.

> dmesg:
> cx18:  Start initialization, version 1.0.0
> cx18-0: Initializing card #0
> cx18-0: Autodetected Hauppauge card
> cx18-0 info: base addr: 0xe8000000
> cx18-0 info: Enabling pci device
> cx18-0 info: cx23418 (rev 0) at 02:01.0, irq: 21, latency: 64, memory: 
> 0xe8000000
> cx18-0 info: attempting ioremap at 0xe8000000 len 0x04000000
> cx18-0: cx23418 revision 01010000 (B)
> cx18-0 info: GPIO initial dir: 0000cffe/0000ffff out: 00003001/00000000
> cx18-0 info: activating i2c...
> cx18-0 i2c: i2c init
> cx18-0 info: Active card count: 1.
> tveeprom 1-0050: Hauppauge model 74541, rev C6B6, serial# 3484150
> tveeprom 1-0050: MAC address is 00-0D-FE-35-29-F6
> tveeprom 1-0050: tuner model is Philips FM1236 MK5 (idx 116, type 43)
> tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08)
> tveeprom 1-0050: audio processor is CX23418 (idx 38)
> tveeprom 1-0050: decoder processor is CX23418 (idx 31)
> tveeprom 1-0050: has radio
> cx18-0: Autodetected Hauppauge HVR-1600
> cx18-0 info: NTSC tuner detected
> cx18-0: VBI is not yet supported
> cx18-0 info: Loaded module tuner
> cx18-0 info: Loaded module cs5345
> cx18-0 i2c: i2c client register
> tuner 5-0043: chip found @ 0x86 (cx18 i2c driver #0-1)
> tda9887 5-0043: creating new instance
> tda9887 5-0043: tda988[5/6/7] found
> tuner 5-0061: chip found @ 0xc2 (cx18 i2c driver #0-1)
> cx18-0 i2c: i2c client register
> cs5345 1-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
> tuner-simple 5-0061: creating new instance
> tuner-simple 5-0061: type set to 43 (Philips NTSC MK3 (FM1236MK3 or 
> FM1236/F))
> cx18-0 info: Allocate encoder MPEG stream: 63 x 8192 buffers (504kB total)
> cx18-0 info: Allocate TS stream: 63 x 8192 buffers (504kB total)
> cx18-0 info: Allocate encoder YUV stream: 8 x 131072 buffers (1024kB total)
> cx18-0 info: Allocate encoder PCM audio stream: 63 x 6144 buffers (378kB 
> total)
> cx18-0: Disabled encoder IDX device
> cx18-0: Registered device video0 for encoder MPEG (63 x 8192 bytes)
> DVB: registering new adapter (cx18)
> MXL5005S: Attached at address 0x63
> DVB: registering frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)...
> cx18-0: DVB Frontend registered
> cx18-0: Registered device video32 for encoder YUV (8 x 131072 bytes)
> cx18-0: Registered device video24 for encoder PCM audio (63 x 6144 bytes)
> cx18-0: Registered device radio0 for encoder radio
> cx18-0: Initialized card #0: Hauppauge HVR-1600
> cx18:  End initialization
> firmware: requesting v4l-cx23418-apu.fw
> cx18-0 info: load segment a00000-a07fff
> cx18-0 info: load segment ae0000-ae00ff
> cx18-0 info: load segment b00000-b1a65f
> cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000 (141200 bytes)
> firmware: requesting v4l-cx23418-cpu.fw
> cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes)
> cx18-0 info: 1 MiniMe Encoder Firmware 0.0.74.0 (Release 2007/03/12)
> cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
> firmware: requesting v4l-cx23418-apu.fw
> cx18-0 info: load segment a00000-a07fff
> cx18-0 info: load segment ae0000-ae00ff
> cx18-0 info: load segment b00000-b1a65f
> firmware: requesting v4l-cx23418-cpu.fw
> cx18-0 info: 1 MiniMe Encoder Firmware 0.0.74.0 (Release 2007/03/12)

All that looks good.  It looks like you're using a recent change from my
~awalls/v4l-dvb repository.  Can you please use instead the latest from:

http://linuxtv.org/hg/~awalls/cx18-mmio-fixes

as this should get rid of the need for using mmio_ndelay and you also
then shouldn't have problems when unloading and reloading the module.



> cx18-0 info: Changing input from 1 to 0
> cx18-0 info: Mute
> cx18-0 info: cmd 4008646f triggered fw load
> firmware: requesting v4l-cx23418-dig.fw
> cx18-0: loaded v4l-cx23418-dig.fw firmware (16382 bytes)
> cx18-0 info: decoder set video input 7, audio input 8
> cx18-0 i2c: call_i2c_client addr=4c
> cx18-0 info: decoder set video input 7, audio input 8
> cx18-0 api: CX18_APU_RESETAI
> cx18-0 api: mailbox error 200800ff for command CX18_APU_RESETAI

I've seen errors like this when mmio_ndelay wasn't quite fixing things.
PLease try the repo I suggested above.

> Also, when trying to capture video I get hundreds of these (in dmesg):
> cx18-0 info: ff DMA busy when it shouldn't
> 
> After loading, unloading, uninstalling and installing a few times I got 
> an error message (in dmesg) about increasing vmalloc (I haven't been 
> able to reproduce this). But I thought I would try to increase the 
> vmalloc space.

There's a memory leak when the driver fails to initialize a card.  I
know where it is.  I need to fix it.  But you need not wait for that fix
(it doesn't leak memory, if the card initializes properly every
time).   

> Vmalloc space before:
> VmallocTotal:   110584 kB
> VmallocUsed:     96088 kB
> VmallocChunk:     9048 kB
> 
> Vmalloc with 'vmalloc=256M':
> VmallocTotal:   241656 kB
> VmallocUsed:     37540 kB
> VmallocChunk:   199156 kB
> 
> Now I'm unable to recognize the card (I stopped at mmio_ndelay=606). 

That happens when the "mmio_ndelay" hack isn't effective (I found this
out on Saturday).  The only way to recover is a hardware reset (e.g.
shutdown and reboot).

>Usually the module would crash (making it impossible to unload the 
> module) after loading/unloading the module once or twice (in addition
> to 
> the load on boot).

The 'mmio_ndelay' hack obviously isn't working.  Please try the 

http://linuxtv.org/hg/~awalls/cx18-mmio-fixes

repo and let me know if it works for you.

'mmio_ndelay' was a rather passive method (give some idle time on the
bus) to attempt to get more reliable communication with the CX23418.

the 'retry_mmio' parameter, enabled by default in the above repo
agressively checks and retries communications with the CX23418 to ensure
reliability.


Regards,
Andy


> 
> Andy Walls wrote:
> > On Wed, 2008-09-17 at 22:13 -0400, Oystein Thorsen wrote:
> >   
> >> Hi,
> >> I bought the HVR-1600 card about a week ago, but I've been unable to get 
> >> it working on my mythtv server. I've tried it on a different computer 
> >> where it worked in Vista. It also worked on Fedora 9 (same as the mythtv 
> >> server) with the same drivers as on the mythtv server. I also have a 
> >> PVR-150 card in the mythtv server from before. The PVR-150 been working 
> >> the whole time while I've been playing around with the HVR-1600.
> >>
> >> I'm using the latest v4l-dvb drivers (from the official mercurial 
> >> repository).
> >>
> >> Initially I had problems detecting the card, but it looks like the 
> >> mmio_ndelay setting (152) corrected that:
> >>     
> >
> > All,
> >
> > I'm trying to figure out a good value for the driver to use as a default
> > for this parameter, so I can stop repeating the mmio_ndelay answer on
> > the list :) .  I'm sure users expect the driver to "just work" out of
> > the box and I'd certainly like to make it that way.
> >
> > So far various people have reported that 91, 121, and 152 fix their
> > respective problems.  So that means I'll need to check in a value of 152
> > as a default.  Has anyone else found they need to use a even higher
> > value for correct operation?
> >
> >
> >
> >   
> >> cx18-0: Initializing card #0
> >> cx18-0: Autodetected Hauppauge card
> >> ACPI: PCI Interrupt 0000:02:01.0[A] -> GSI 21 (level, low) -> IRQ 21
> >> cx18-0: cx23418 revision 01010000 (B)
> >> tveeprom 4-0050: Hauppauge model 74541, rev C6B6, serial# 3484150
> >> tveeprom 4-0050: MAC address is 00-0D-FE-35-29-F6
> >> tveeprom 4-0050: tuner model is Philips FM1236 MK5 (idx 116, type 43)
> >> tveeprom 4-0050: TV standards NTSC(M) (eeprom 0x08)
> >> tveeprom 4-0050: audio processor is CX23418 (idx 38)
> >> tveeprom 4-0050: decoder processor is CX23418 (idx 31)
> >> tveeprom 4-0050: has radio
> >> cx18-0: Autodetected Hauppauge HVR-1600
> >> cx18-0: VBI is not yet supported
> >> tuner 5-0043: chip found @ 0x86 (cx18 i2c driver #0-1)
> >> tda9887 5-0043: creating new instance
> >> tda9887 5-0043: tda988[5/6/7] found
> >> tuner 5-0061: chip found @ 0xc2 (cx18 i2c driver #0-1)
> >> cs5345 4-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
> >> tuner-simple 5-0061: creating new instance
> >> tuner-simple 5-0061: type set to 43 (Philips NTSC MK3 (FM1236MK3 or 
> >> FM1236/F))
> >> cx18-0: Disabled encoder IDX device
> >> cx18-0: Registered device video0 for encoder MPEG (2 MB)
> >> DVB: registering new adapter (cx18)
> >> firmware: requesting v4l-cx23418-apu.fw
> >> MXL5005S: Attached at address 0x63
> >> DVB: registering frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)...
> >> cx18-0: DVB Frontend registered
> >> cx18-0: Registered device video32 for encoder YUV (2 MB)
> >> cx18-0: Registered device video24 for encoder PCM audio (1 MB)
> >> cx18-0: Registered device radio0 for encoder radio
> >> cx18-0: Initialized card #0: Hauppauge HVR-1600
> >> cx18:  End initialization
> >> cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000 (141200 bytes)
> >> firmware: requesting v4l-cx23418-cpu.fw
> >> cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes)
> >> cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
> >> firmware: requesting v4l-cx23418-apu.fw
> >> firmware: requesting v4l-cx23418-cpu.fw
> >> firmware: requesting v4l-cx23418-dig.fw
> >> cx18-0: loaded v4l-cx23418-dig.fw firmware (16382 bytes)
> >>
> >> When I try to capture some data (cat /dev/video0 > test.mpg) I get 
> >> nothing (filesize is 0). The same happens if I try to record something 
> >> on mythtv (The PVR-150 still records fine).
> >>
> >> Let me know if there is any other information that would be useful.
> >>     
> >
> > Look in /proc/interrupts and see what devices are sharing IRQ lines with
> > ivtv and cx18, and look in dmesg or /var/log/messages for any messages
> > about the kernel disabling/ignoring IRQ lines (i.e. "nobody cared").
> >
> >
> > Use the cx18 debug module parameter to turn on Warning, Info,
> > Mailbox/API, and IRQ debug messages.  See what gets logged especially
> > when you try to do a capture.  If nothing jumps out at you, also turn on
> > the high volume debug flag.
> >
> > Regards,
> > Andy
> >
> >   
> >> Thanks,
> >>
> >> Oystein Thorsen
> >>     
> >
> >
> >
> > _______________________________________________
> > ivtv-users mailing list
> > [email protected]
> > http://ivtvdriver.org/mailman/listinfo/ivtv-users
> >   
> Thanks for any feedback so far.
> 
> _______________________________________________
> 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

Reply via email to