Using the radeon.o driver from 2.4.22 with 2.4.24 avoids the problem. Looking at the diffs between the radeon code in 22 and 24 I see:
+ some new CP microcode + changes to the initialization of the scratch register pointer + changes to the radeon_do_init_pageflip method + changes to the radeon_freelist_int method that notes a potential deadlock! + lots and lots and lots of other changes.
So I think there are plenty of good candidates for this problem.
I guess the next step is to check with 2.4.23 to see if I can narrow down to a smaller change set (but I don't think there were many changes from 23 to 24?).
Unfortunately I am moving house this week, so I'm not going to have much more of a chance to debug this. But if somebody has some test code they want to try, I'm happy to find time to give it a go.
cheers
Michel DÃnzer wrote:
On Tue, 2004-02-10 at 13:36, Greg Wilkins wrote:
I can confirm that doing a warm reboot from 4.2.22 to 4.2.24 "solves" the problem and that glxgears works.
Some random ideas to try and further track down the problem:
* make a diff of drivers/char/drm between kernels 2.4.22 and 2.4.24, and check it for obvious regressions on hardware initialisation * move the contents of drivers/char/drm from kernel 2.4.22 to 2.4.24 and/or vice versa, and see if it still works/breaks
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
