[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled

[bugzilla-daemon at bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=34772





--- Comment #16 from Michel Dänzer <michel at 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 at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel