|09-30-09, 09:51 AM||#1|
Join Date: Sep 2009
Core i5 hard locks playing video w/ XBMC et al.
I have a new system consisting of:
Core i5 750 CPU
Gigabyte GA-P55M-UD4 (BIOS F3)
2x2GB DDR3 RAM
Sparkle 9500GT 1GB
In theory, this should be a great HTPC setup. But I've been having major problems with the system hard-locking when playing any video. I have found one extremely specific and extremely crippled configuration where I can get a reliable system, but the solution I've found is really unacceptable. I'd like some help in finding a reasonable configuration where I can play back video reliably without totally crippling my system.
The software I'm trying to use is XBMC, out of the Team XBMC PPA. The procedure to reproduce this hard lock is:
Videos -> Play big_buck_bunny_1080p_surround.avi (http://mirror.bigbuckbunny.de/peach/...p_surround.avi) until the Rabbit wakes up
Hit ESC to return to the UI
Videos -> Play big_buck_bunny_1080p.mpg (same file, but transcoded to MPEG 2 and stereo sound)
In many configurations, the system will hard lock up by the time the first playback shows leaves in the stream. In some configrations, this will hard lock up by the time the second playback shows leaves in a stream. Occasionally, the system will need you to flip back and forth between playing those clips a few times before it hard locks.
The hard lock happens with XBMC set to render using VDPAU, Advanced acceleration (GLSL), and Basic acceleration. The hard lock does NOT happen with XBMC set to render using Software.
By hard lock, I mean, just that. No debugging at all, including Magic SysReq or network console. Whatever sound happens to be in the DMA buffer keeps getting sent over and over again to my receiver. No keypresses cause any response, nor does ping. It's dead, Jim.
I've also used VDPAU-enabled builds of MPlayer and the GNOME video playing software. With the latter two, the system will hard lock in the same configurations that XBMC will lock in, but for some reason, XBMC seems to be stressing the system in just the right way to reproduce the hard lock quickly, while the others require some back-and-forth between videos and other UI elements and general fiddling, so I don't have a reliable procedure to reproduce it. The configurations that lock up quickly with XBMC lock up quickly with MPlayer et al., and those that take more steps do here too.
The following configurations hard lock up very quickly when trying to play the videos - that is, at or before the leaves in the stream playing the video for the first time:
XBMC Live CD (http://downloads.sourceforge.net/pro...e_mirror=voxel) - 180.44
Ubuntu Karmic Alpha 6 i386 - 180.60 (hand hacked to compile), 185.xx (whatever Karmic's Restricted installed), and 190.32
Ubuntu Karmic Alpha 6 i386 with custom 184.108.40.206 kernel - 180.60, 185.xx, 190.32
Ubuntu Jaunty i386 - 185.18.36, 190.32
Ubuntu Jaunty i386 with custom 220.127.116.11 kernel - 180.60 (hand hacked to compile), 185.xx, 190.32
I've found that I can get through the first video with this configuration:
Ubuntu Jaunty i386 - 180.60
However, it will sometimes lock up showing the UI again when you hit escape, and always lock up if you play a second file.
In order to fix those lock-ups, I found (through painful trial and error) that I needed to add the following options to the kernel command line. I got these from the suggestions in this forum's sticky, and trial and error to see which ones were needed:
pci=nommconf idle=poll clocksource=hpet acpi=force
But I also need to set the following options in the BIOS:
Turbo Mode: Disabled
Cores Enabled: 1
That is, I have to disable all power management (bad), and I have to disable three of the four cores (bad). If I don't disable all of the power management, it will lock up very reliably playing the second video. If I don't disable all but one core, it may go a little longer, but after a few back-and-forth switches, it will lock up.
Gigabyte has a newer beta BIOS posed, rev. F4h, which I tried. It doesn't change any of the lock-up behaviors or variable sensitivities. On F3, dmesg tells me that ACPI is disabled because the BIOS's DMI block date is out of the acceptable range, so I had to add acpi=force to override that check. On F4h, this is not necessary. This does lead me to believe that Gigabyte's ACPI implementation has maturity problems.
In order to have video playback that won't hard lock my system, I have to disable everything that's interesting about my Core i5, AND use a very particular OS, AND use a very particular NVidia driver version, AND use kernel command line options. This is a pretty bad state.
Could you offer any suggestions on how to debug this, or how to move forward?
Has NVidia's Linux team tested your drivers on the Core i5 platform, and or Gigabyte's Core i5 motherboards? What were your results? Is there a specific kernel/driver version I need to use for i5?
Thank you for any help you can give me.