On Tue, 2008-09-16 at 00:34 -0400, test wrote:
> Andy Walls wrote:
> >
> >>> Here's how to fix assuming you've got the latest version from the
> >>> v4l-dvb repository at linuxtv.org:
> >>>
> >>> # modprobe -r cx18
> >>> # modprobe cx18 mmio_ndelay=31
> >>>
> >>> or use a value of 61, 91, 121, 152 or some higher multiple of 30.3 ns
> >>> until the CX23418 always responds reliably. (The lowest value that
> >>> works at first may not be reliable; then again, it migh
> I thank all of you guys for responding.
>
> If I wasn't so darn frustrated and a little more patient I could have
> figured that out myself. Drat!!
>
> Both commands returned no errors. But dmesg | grep cx18 still shows
> problems. I also tried 'modprobe cx18 mmio_ndelay=31' and replaced 31
> with 61, 91, 121, 152, 182 and 212.
> It is the same as before but this time it looks like it ran twice....
OK. Just so we don't wind up chasing ghosts, I need some
clarification:
1. Prior to every attempt to use a different mmio_ndelay value, did you
use 'modprobe -r cx18' to unload the module first?
2. Make sure that '/sbin/modinfo cx18' show mmio_ndelay as a valid
module parameter (is it in the list?).
3. Did modprobe gripe about failures to load (it looks like you're short
on chunks of vmalloc address space)?
4. grepping on cx18 may hide some valuable troubleshooting information.
If providing subsequent reports, do your best to provide all the
messages between "Start initialization" and "End initialization" and
lines outside of that that look wrong.
You said you made six attempts to load the module with different values,
but your log only shows the system loading it automatically at boot up
and then only one other manual load (and no manual unloads since every
load failed?) ... At least I think, with the available information.
> [EMAIL PROTECTED]:~$ dmesg | grep cx18
> [ 33.418449] cx18: Start initialization, version 1.0.0
> [ 33.418517] cx18-0: Initializing card #0
> [ 33.418521] cx18-0: Autodetected Hauppauge card
> [ 33.418838] cx18-0: Unreasonably low latency timer, setting to 64
> (was 32)
> [ 33.419976] cx18-0: cx23418 revision ffffffff (A)
> [ 33.574880] cx18-0: Invalid EEPROM
> [ 33.574882] cx18-0: VBI is not yet supported
> [ 33.915868] cs5345 2-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
> [ 33.917806] cx18-0: Disabled encoder IDX device
> [ 33.917834] cx18-0: Registered device video0 for encoder MPEG (2 MB)
> [ 33.917837] DVB: registering new adapter (cx18)
> [ 34.039046] cx18-0: frontend initialization failed
> [ 34.039200] cx18-0: DVB failed to register
> [ 34.039233] cx18-0: Registered device video32 for encoder YUV (2 MB)
> [ 34.039249] cx18-0: Registered device video24 for encoder PCM audio
> (1 MB)
> [ 34.039267] cx18-0: Registered device radio0 for encoder radio
> [ 34.039430] cx18-0: Error -12 registering devices
> [ 34.040903] cx18-0: Error -12 on initialization
> [ 34.040923] cx18: probe of 0000:01:06.0 failed with error -12
> [ 34.040951] cx18: End initialization
The above load happened 33 seconds after boot up, so it's what the
kernel/system did automatically. This defaults to "mmio_ndelay=0" and
we know that won't ever work in this system.
The log also indicates an error -12 (-ENOMEM) on trying to get enough
memory space for transfer buffers. This is a separate problem, To fix
this we'll need to add a 'vmalloc=xxxM' to your kernel command line.
PLease perform
$ grep -i vmalloc /proc/meminfo
Figure out how many MiB of address space is used currently for
VmallocTotal, add 128M to that value, and use the result for your
'vmalloc=xxxM' option on your kernel command line.
That will burn up some page table entries in the MMU, but it'll give you
the address space you need for dynamic allocations in the kernel. The
CX23418 chip needs at least one 64 MB continuous chunk of addresses for
all it's memory and registers.
> [ 1328.767724] cx18: Start initialization, version 1.0.0
> [ 1328.767783] cx18-0: Initializing card #0
> [ 1328.767786] cx18-0: Autodetected Hauppauge card
> [ 1328.768920] cx18-0: cx23418 revision 01010000 (B)
This is the second load attempt of the cx18 module at 33 minutes later.
Things are better as the chip revision could be read, so this is likely
mmio_ndelay=?? which is not 0,
> [ 1328.840479] cx18-0: Invalid EEPROM
but the mmio_ndelay value used on this one attempt was not high enough
to get reliable operation out of the CX23418.
> [ 1328.840481] cx18-0: VBI is not yet supported
> [ 1328.885352] cs5345 2-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
> [ 1328.892069] cx18-0: Disabled encoder IDX device
> [ 1328.892451] cx18-0: Registered device video0 for encoder MPEG (2 MB)
> [ 1328.894814] DVB: registering new adapter (cx18)
> [ 1328.895522] cx18-0: frontend initialization failed
> [ 1328.895670] cx18-0: DVB failed to register
> [ 1328.895694] cx18-0: Registered device video32 for encoder YUV (2 MB)
> [ 1328.895710] cx18-0: Registered device video24 for encoder PCM audio
> (1 MB)
> [ 1328.895726] cx18-0: Registered device radio0 for encoder radio
> [ 1328.895884] cx18-0: Error -12 registering devices
> [ 1328.897348] cx18-0: Error -12 on initialization
> [ 1328.897375] cx18: probe of 0000:01:06.0 failed with error -12
> [ 1328.897393] cx18: End initialization
And again -12 is -ENOMEM. A vmalloc option on the kernel commandline
should fix this.
Keep at it. We should be able to get this working.
Regards,
Andy
_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users
