Bugzilla – Bug 158633
KDETV locks up the whole computer after a very short while
Last modified: 2006-11-30 00:08:24 UTC
I did a standard GNOME desktop install. KDETV does the channel scan like it's supposed to. After it's done and I start watching TV if I start flipping through the channels, to see what's on, I get to about the 7th one and the whole computer locks up. Have to do a hard reboot. The computer seems stable otherwise. I've browsed the web using Firefox, played some of the included games, used Openoffice for several days now with no trouble except with the KDETV. I've got SuSE installed on a brand new NForce 6100 integrated motherboard. I upgraded from the open source NV video driver to the closed source NVIDIA video driver, which I downloaded from NVIDIA and I applied the SuSE patch to. It didn't fix the problem with KDETV. The TV card is a standard BTTV card from ATI which I've had for several years and haven't had any trouble with it in other computers with other Linux distros. Thanks
Suspect this is a kdetv, X or hardware issue.
kdetv only uses xvideo, more likely nvidia/kernel issue
Yes, sounds like a Xvideo issue. Strange that it happens with nv *and* nvidia driver. Probably we can't do much without access to this hardware.
Tried to reproduce this on a Beta8 on a GeForce 6600 (1280x1024@24bpp). Works fine with nv *and* nvidia driver. There's currently nothing I can do about. But at least you could attach your /var/log/Xorg.0.log and /etc/X11/xorg.conf. If you can access the machine during you are testing kdetv via network, please do a "tail -f /var/log/messages" and "tail -f /var/log/Xorg.0.log" and attach the lines which (might) occur when this problem arises.
Daren, please provide the information that was asked for.
Here is tail-f /var/log/messages output on a networked computer, leading up till frozen test computer. These messages are repeated over and over each time I change a channel via the keyboard. * Mar 24 18:43:43 Excalibur kernel: bttv0: SCERR @ 3a2cd014,bits: OFLOW FDSR SCERR* Mar 24 18:43:43 Excalibur kernel: bttv0: SCERR @ 3a2cd014,bits: HSYNC OFLOW FDSR SCERR* Mar 24 18:43:44 Excalibur kernel: bttv0: SCERR @ 3a2cd014,bits: HSYNC OFLOW FDSR SCERR* Mar 24 18:43:44 Excalibur kernel: bttv0: SCERR @ 3a2cd014,bits: OFLOW FDSR SCERR* Mar 24 18:43:45 Excalibur kernel: bttv0: SCERR @ 3a2cd014,bits: HSYNC OFLOW FDSR SCERR* Mar 24 18:44:23 Excalibur kernel: bttv0: SCERR @ 3a2cd014,bits: OFLOW FDSR SCERR* Mar 24 18:44:25 Excalibur kernel: bttv0: SCERR @ 3a2cd014,bits: OFLOW FDSR SCERR* Mar 24 18:44:26 Excalibur kernel: bttv0: SCERR @ 3a2cd014,bits: HSYNC OFLOW FDSR SCERR* Mar 24 18:44:27 Excalibur kernel: bttv0: SCERR @ 3a2cd014,bits: OFLOW FDSR SCERR* Mar 24 18:44:27 Excalibur kernel: bttv0: SCERR @ 3a2cd014,bits: OFLOW FDSR SCERR* Mar 24 18:44:28 Excalibur kernel: bttv0: SCERR @ 3a2cd014,bits: HSYNC OFLOW FDSR SCERR* Doing a tail -f /var/log/Xorg.0.log reveils nothing after X comes up other than the fact that it can't find a couple of font paths so they are removed from the list. While the testing computer is locked up, I cannot close the SSH session from the working computer. The session is locked as well. In a moment I will post the xorg.conf, and Xorg.0.log files from the test computer.
Created attachment 75006 [details] from test computer that freezes in kdetv
Created attachment 75007 [details] xorg.conf from test computer that freezes in kdetv
kraxel might be able to comment on the output in comment #6. Anyway, I'm afraid I need to set this to LATER for now, because we can't do any investigations without access to this hardware and we can't reproduce it on similar hardware.
bttv tends to push the hardware to the limits, especially when doing PCI-PCI transfers directly from the grabber to the gfx card, and trigger hardware bugs along the way ... bios updates and/or fiddeling with bios settings has chances to succeed, especially if the same bttv version runs rock-solid on other hardware.
Adjusting severity ...
This should be retested with SUSE 10.2 Alpha3.
NEEDINFO.
openSUSE 10.2 Beta1 has just been released.
To prevent this bugreport remaining open for the time being I close this one now as fixed - assuming it *is* fixed. Don't hesitate to reopen it again if you still can reproduce it with openSUSE >= 10.2. The final release of openSUSE 10.2 is scheduled for 2006-12-07.