Hello Andy. On Friday 02 May 2008 15:15:50 you wrote: > Given that your software hasn't changed, and assuming the driver code is > correct (for a large majority of users), then the remaining problem > areas I see are the card itself, the mainboard's PCI bus, and the > possibility of a marginal power supply. (Can anyone else think of > something else?) Perhaps. But maybe it's a combination of a few factors: is the MK3 model w/ CI as widely used and tested as the older model w/ CI? Maybe a combination of my hardware is triggering some hw/sw flaw. The card is brand-new and was slightly modified by KNC1 for better QAM256 receiption with my cable provider. The mainboard is a Asus Crosshair which is pretty much top-notch. Irionically I am no gamer and still own a highend gamer board but it's hard to get a decent piece of quality hardware nowadays. :-( The power supply should be more than enough with its 500W. ;-) > Can you check the output of > # lspci -nnxxx > for your Host and PCI bridges and the video card? Thanks for the tipp. That brings me to another problem that I think might be related. Since I put in the new card, I am experiencing the following: - power on computer -> wait for kdm -> switching to console fails the monitor even turns off because it gets no signal. usually blindly switching back to Xorg works and the screen is back. - rebooting the system -> everything works fine from there on I did some more investigating and figured that the problem only occurs when the system has just been powered on _and_ something is accessing the dvb-c card. So powering on the machine without starting the vdr works just fine. But as soon as vdr has been started, no more vt switching is possible. The problem doesn't show up after a reboot- at all. This is never ever happened with the old card. I checked the cabling and all but I wasn't able to figure out what's the cause of this. No error msgs. Nothing. For the record, unfortunately I am using a nvidia card with the 173.08 driver release. But I already did that with the old card. I have attached the lspci output for both cases by the way. > Also could you look at the latency timer of all the PCI devices on the > bus? Values that are very high (e.g. nVidia likes to use 248) and > values less than or equal to 32 (n.b. 0 is OK for some bridge devices) > can cause problems. Due the fact that I only have the knc one card in the machine and everything else is either on board or on PCI-E, the latency is 0 everywhere except for the knc one card, there it's 32. > Tweaking PCI bus latency timers with "setpci" may resolve your problems. I'll give that a shot too. I really would like to set the latency when the module is being loaded. Unfortunately there is no module parameter for that so I'll have a look through the sources and hard wire to 64 which should be plenty. > I believe this is a log message from an error condition. The EEPROM on > the i2c bus on the card was not able to be read properly. > (See: linux/drivers/media/dvb/ttpci/ttpci-eeprom.c) That also happened with the old card so I guess that's okay. BTW. I switched to kernel 2.6.25.1 and in-tree dvb but no change at least on the "boot up" problem. For the original problem, I'll have an eye on it. Sometimes I really wonder why I chose to study computer science. Life could be so much easier. ;-) If anyone has some more ideas or things I could try... :-) Thanks a lot, matthew.
<<attachment: lspci_powerup_with_problem.zip>>
<<attachment: lspci_after_reboot-working.zip>>
_______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
