On Thu, Jan 14, 2010 at 5:47 AM, Ben Wong <[email protected]> wrote: > On 1/13/10, Julien Cristau <[email protected]> wrote: >> The reports seem to have started shortly after the upload of mesa 7.6 to >> unstable, so it's possible this is a long-standing kernel bug being >> triggered by a new bug in mesa 7.6. > > Okay. I'm testing that right now.
Mesa 7.6 is not the problem. I tested with a LiveCD (Mint Helena) that uses Mesa 7.6 and had no problems. I also installed it to hard disk to make sure that that wasn't a factor. Again, no problems. It looks like the kernel in this distribution has the binary blobs kept in the kernel module, rather than split out to files: $ cd /lib/modules/2.6.31-17-generic/kernel/drivers/gpu/drm/radeon $ hd radeon.ko | grep -q '00 70 00 21 00 00 00 00' && echo "Yup" Yup So, once again, the firmware loader is the main suspect. Ben Hutchings, do you have any guesses as to why request_firmware might not be working correctly? Is there some intricacy in the way it is called that we're missing? Could it be the firmware is being loaded when the card is not in the right state to receive it? Thanks, --Ben P.S. Here are some random extra details about the LiveCD system which uses Mesa 7.6 and in which DRI works flawlessly. $ cat /etc/issue Linux Mint 8 Helena - Main Edition $ uname -a Linux 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 2009 i686 GNU/Linux $ dpkg -l libgl1-mesa-dri xserver-xorg linux-image* ii libgl1-mesa-dr 7.6.0-1ubuntu4 OpenGL API -- DRI modules ii linux-image-2. 2.6.31-17.54 Linux kernel image for version 2.6.31 ii xserver-xorg 1:7.4+3ubuntu1 the X.Org X server -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
