Scott Wrote: > Honestly i wouldnt know where to start in applying the patch you > provided, if you could provide a little help on that part i would > appreciate it as im not a seasoned linux user yet. > > Thanks
Scott, There is some risk of hanging up the kernel if the SCL clock is slowed down too much. Given the headaches that can lead to, I'm going to ask you not to apply the patch. I have other avenues I can still investigate. If you want to experiment with coming up in single user mode, where most of the system daemons and desktop are turned off, that should be pretty safe. In single user mode, start doing # /etc/init.d/foo stop on services that are running that you know for sure you don't need (n.b don't stop syslogd if its running). Then start doing # modprobe -r foo on modules that you know you don't need, or suspect may be a problem (*cough* nvidia *cough*), and then # modprobe cx18 debug=65535 And see what you get in the logs. Thanks for helping me try to figure this out. Regards, Andy > Andy Walls wrote: > > Scott wrote: > > > >> i re downloaded and recompiled the drivers and still > no /dev/video0, i > >> still get the same invalid eeprom error. im beginning to think this > is > >> worthless on that particular machine and that i should put it on > my > >> desktop as the backend and then use the box for a frontend. > >> > > > > > >> but if there is anything else you can do to help, i would like to > still try. > >> > > > > Well, you're the second user, so far, that has reported the fix for > > trying to correct the timing of I2C transitions did nothing. But > you're > > the only one so far who provided all the lspci and lsmod info > > (thanks!). > > > > I'm going to take a harder look at the lspci and lsmod and dmesg > output > > you provided to see if there's something more subtle going on. If > > another user with I2C problems can report the same sort of info, I > (or > > anyone else on the list who'd like) can start doing comparative & > > differential analyses. > > > > > > In the mean time I'd like you to try two more things: > > > > 1) Test that PCI bus latencies are *not* to blame for the I2C > problems > > by slowing the I2C bus SCL clock down significantly. The attached > test > > patch slows it down by a factor of 450 by modifying the > CX18_SCL_PERIOD. > > (That's the slowest my system will let cx18 run it without griping > about > > soft lockups in dmesg.) This patch is only for test. > > > > 2) Try and perform more aggressive initialization of the HVR-1600's > I2C > > buses. The attached patch has this change in the form of two new > > functions, each called to initialize each I2C bus on the HVR-1600. > > > > > > If the attached patch works for you, we can start to narrow down > what > > actually helped. If it doesn't, I can start to look at other > potential > > problem sources (e.g. debugging from i2c-algo-bit, PCI bus error > > reporting to the cx18 driver, PCI chipset errata, CX23418 hardware > block > > initialization, etc.). > > > > > > Again your feedback, both positive and negative, helps. > > > > > > Regards, > > Andy > > _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
