I tried the mmio-fix version and it works like a charm... almost :-). The card now detects properly on boot. But the problem of getting no data is still there...
I have not updated the driver in a few weeks and I could always try the latest version, but I'm not sure if the mmio fix is merged with the official version yet. Are there any other things I could try to get this working? I'm out of ideas (which is why I gave up on it for a few weeks :-) ). Thanks for the help so far, - Oystein Andy Walls wrote: > 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 > _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
