https://bugzilla.kernel.org/show_bug.cgi?id=34772
--- Comment #16 from Michel Dänzer <mic...@daenzer.net> 2011-05-21 14:54:25 --- (In reply to comment #15) > With 2.6.39-rc7 + KMS + agpmode=-1 + no_wb=1 + dynclks=1: > > * XV is not available to mplayer or other applications. When the kernel radeon driver fails to initialize acceleration, there's no point in trying any functionality that needs acceleration, such as XVideo. I don't think there's any point doing any more tests with 2.6.39-rc7, as it's obviously suffering from additional issues which only occurred intermittently during the 2.6.39 cycle. (In reply to comment #12) > BTW, I hope that you don't mind me providing copious amounts of > testing here (and their results) in the hope to get this fixed... :-) Well, I'm afraid less quantity but more quality would be better... It's becoming rather difficult and time-consuming to find the relevant pieces of information in this mass. (In reply to comment #11) > Just for the record #2, 2.6.38 with KMS + agpmode=-1 + no_wb=1 + > dynclks=1 still locks up the GPU when I play a video with mplayer. Has either of you tried agpmode=1 dynclks=1? Does that increase stability at all? > Besides that, like Andreas, with dynclks=1 the resolution is reduced > to be 800x600. I didn't have the opportunity to read the X logs > regarding the S-Video port, but, at least for the user, iBooks > (differently from PowerBooks) don't have user-accessible S-Video ports > (but this doesn't prevent Apple from having inutilized them somehow). I thought there was some kind of multimedia adapter for the external output. Anyway, it should be possible to override the incorrect output detection, either on the kernel command line with something like video=S-video-1:d or later in xorg.conf or during X runtime with something like xrandr. But really, we need to focus on one problem per bug report as much as possible, or things are getting out of hand. (In reply to comment #9) > So, I am not quite sure if it would be the case of bisecting or, at > least, what would be a good starting point. No, there's no point in bisecting, as that problem should be gone with 2.6.39 final. > > Note that you should boot with radeon.no_wb=1 as well for > > OK. I can try no_wb=1 with agpmode=-1 and report back in a few > moments, to see if the lockups are still there or not. no_wb=1 would only have been important for bisecting, to avoid the writeback endianness bug interfering. P.S. beware of Debian package udev version 169-1: IME an initrd generated with that installed prevents the radeon module from being loaded automatically, and when trying to load it manually, it fails to load the CP microcode and consequently fails to initialize acceleration. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
