On Thu, 2008-10-16 at 00:23 -0400, daryl wrote: > Thanks for your attempt to help me. I have just one more question at > this time... > > I had loaded the cx18 driver twice before and dmesg did show that the > card was recognized. In fact, I actually did have video at one time. But > after making a mess out of my system I reinstalled everything and have > not been able to get the card recognized since. > > So now after the information you gave me about pci buses, I tend to > believe that I have a hardware issue or something related to packages. > It now seems obvious to me that I did something to change my system that > is causing the problem. Does this sound reasonable to you?
Sure. The card is functioning - it's just that comms to the card are suffering a high error rate. The CX23418 itself is a contributor to the error rate, but your error rate is too high to be the CX23418 alone. Another device on the PCI bus or another driver can be causing the problem. > My problem is that I can not remember what changes I may have made to my > system. > > Here is a list of possible changes that I wonder about. Please tell me > if any of these may be related to my problem. > > I. Could the problem be related to using a differant kernel than I > originally used? > > 2. Could it be that originally I used the live cd installation and now I > am using the alternate cd installation? For both of these: well they could - the set of differences could be huge. Given that every device on the bus has a kernel device driver of some sort and that some system level hardware gets manipulated by the kernel too. I cannot assign a likelyhood to this being the case however. > 3. Could it be related to installing a second hard drive on my system > and at differant times I have it enabled or disabled? Accesses to the hard drive go over the PCI bus between the CPU and the disk controller. An increase in disk activity could cause the problem. If the disk is relatively inactive, then I'd say it doesn't matter. > 4. Anything else you may be able to think of that I may have done > differantly? On my short list would be checking the following, since they are relatively easy: 1. the PCI latency timers on the bridges the CX23418 is behind and setting them a little longer with setpci. 2. Any device and device driver that generates *a lot* of interrupts according to /proc/interrupts. Blacklist/remove the driver module or remove the device from the machine to check. 3. The power supply. A fully loaded system or maybe adding an extra hard drive could cause enough load on the power that things near the margin start not working properly. Check by removing non-essential PCI cards and disk drives. 4. Dust or dirty contacts in the PCI slot that the CX23418 based card is in. Remove card, blow dust out of slot, reinstall, and retest. 5. Unhooking the antenna cables and video cables from the card. To eliminate any possible grounding problem. With all these tests you want to look at the read/write retry stats from the CX23418 driver to see if you've had a positive effect. Here's a typical set from my system after init and the Mythbackend occasionally pulling EPG info from the ATSC broadcast: cx18-0 info: retried_write[0] = 4550379 cx18-0 info: retried_write[1] = 127 cx18-0 info: retried_write[2] = 76 cx18-0 info: retried_write[3] = 48 cx18-0 info: retried_write[4] = 59 cx18-0 info: retried_write[5] = 59 cx18-0 info: retried_write[6] = 41 cx18-0 info: retried_write[7] = 44 cx18-0 info: retried_write[8] = 34 cx18-0 info: retried_write[9] = 42 cx18-0 info: retried_write[10] = 1257915 cx18-0 info: retried_read[0] = 14124353 cx18-0 info: retried_read[1] = 0 cx18-0 info: retried_read[2] = 0 cx18-0 info: retried_read[3] = 0 cx18-0 info: retried_read[4] = 0 cx18-0 info: retried_read[5] = 0 cx18-0 info: retried_read[6] = 0 cx18-0 info: retried_read[7] = 0 cx18-0 info: retried_read[8] = 0 cx18-0 info: retried_read[9] = 0 cx18-0 info: retried_read[10] = 472 Just after driver/card init, a large deviation from this distribution of retries would indicate you still have a problem. And of course you can always try reverting to a previously known good configuration where things worked, whenever you want to invest that amount of time. Regards, Andy > Thanks a million for your time, > Daryl > > Andy Walls wrote: > > > > > > > > > > So there's not much specific advice I can give at this point. Only some > > general advice: > > > > 1. You can try loading the module also specifying the mmio_ndelay > > parameter. It may not help (actually it shouldn't), but it's easy > > enough to try: > > > > $ sudo modprobe -r cx18 > > $ sudo modprobe cx18 debug=67 retry_mmio=1 mmio_ndelay=243 > > enc_mpg_buffers=1 enc_ts_buffers=0 enc_vbi_buffers=0 enc_yuv_buffers=0 > > enc_pcm_buffers=0 > > > > > > 2. If that doesn't help with the PCI MMIO read errors, then you need to > > start experimenting to find out what on the PCI bus is causing all the > > read errors: a particular card, device driver, or latency timer on a > > bridge are the things I would check. I might also try to disable > > message signaled interrupts, if that's feasible. > > > > Alternatively, can you try the card in another system and see if you get > > the same sort of behavior? > > > > > > 3. If you can resolve the PCI bus read errors, and the DVB frontend > > appears to register, and you still get -ENOMEM being returned, only then > > concentrate on trying to free up memory. > > > > > > Regards, > > Andy > > > > > > > > > _______________________________________________ > 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
