On Sun, Jun 21, 2009 at 5:14 PM, Andrew Lutomirski<luto@mit.edu> wrote:> On Sun, Jun 21, 2009 at 3:47 PM, Linus> Torvalds<torvalds@linux-foundation.org> wrote:>>>>>> What *has* changed is that we have a newradeon driver, and it looks like>> that new radeon driver is crap, and does this:>>>> info->fix.smem_start = (unsigned long)fbptr;>>>> which is totally screwed up. It assigns a _virtual_ address to that>> "smem_start" thing, even though it should be a physical one.>>>> I don't know the radeon driver, so I don't know where to find the physical>> address. It's also possible that there is no good single physical>> address, and the radeon driver should implement a "fb_mmap" function.>>>> Does this patch make the warning and the oops at least go away? Obviously>> it won't result in a working frame buffer, but that's a separate issue>>>> I haven't tried your patch, but I hacked up the one below instead,> which also fixes the oops. It still doesn't boot, though -- plymouth> hangs (or otherwise dies), preventing my initramfs from finishing.> The same kernel image boots fine with radeon.modeset=0.

My patch is no good -- plymouthd just dies more silently with it.Returning -EINVAL from radeonfb_mmap prevents plymouthd's splashscreen from working (of course) but lets the system boot. (Not onlydoes the system boot, but this is the first modesetting kernel I'veever seen work on this hardware.) Linus's patch works and even letsme start X.

David -- there are still plenty of bugs. The kernel gets my monitor'sresolution wrong (X reads it off DDC correctly but I have to usexrandr to force the resolution). And glxgears triggers the kernel'scommand verification and dies. But this is still a huge improvementover modesetting on the F11 kernel, which is unusable for me (image isgarbled beyond recognition once I start X).