On Mon, Jan 12, 2009 at 8:54 PM, Sytse Wielinga <s.b.wieli...@student.utwente.nl> wrote: > Hi Alex, > > I'm addressing this to you (Alex), as you seem to be The Man to talk to about > r6xx dri support at the moment. CC'ing both the radeonhd and the dri-devel > mailing lists.
Thanks for debugging this! > > Good. > > I tried running the r6xx-r7xx-support branch from drm/xf86-video-radeonhd with > my RV670 card (HD 3870) on an amd64 platform, but it failed, giving me an > irrecoverable black screen, and an OOPS because of a null pointer dereference. > > It became apparent the cause was an ioremap in r600_cp.c failing, and the > result wasn't checked, so it didn't quite fail gracefully. > > It seems to me (I must admit I don't really know what I'm talking about > though, I haven't looked into the way memory is handled in x86 cpus yet) > that the correct fix would be to use ioremap_wc (which maps to ioremap_nocache > on non-PAT-enabled kernels) instead. It works for me: with EXA enabled, I get > a working X instance, with lots of slowness and glitches but I guess that's > expected behavior at the moment. > > Below is a patch, which does four things: > > - Change drm_core_ioremap to drm_core_ioremap_wc (note that this is already > the function that's called in the r3xx code in the exact same place; I > don't know what went wrong here, but someone missed something) The patch is correct. The PAT fix got missed when we merged the r6xx branch into master. > > - Add a check for this specific drm_core_ioremap(_wc) invocation failing; any > failure should return -EINVAL. Also, when dev_priv->pcigart_offset_set > isn't set, it should return -EINVAL, and not just continue as if nothing's > amiss > > - Add many debugging messages. Your opinion on this may be different from > mine, so apply whatever you deem useful. > > Note particularly that I added messages for succeeding or failing ioremaps > and ioremapfrees These seem fine. I've gone ahead and committed the radeon chunk: fd3b361a540c4d370c33ea6a472ad2b24928a930 > > - drm_core_ioremap_wc was enabled only on 2.6.26+ kernels, which seems odd. > I checked, and ioremap_wc has been in the kernel a *long* time (on x86); > there was a #define to check whether it exists on the current arch, so I > changed drm_core_ioremap_wc to be always present (it's used unconditionally > in radeon_cp.c anyway, so it seems to be a sane idea to define > drm_core_ioremap_wc to do the right thing whether ioremap_wc is present or > not). > This is probably fine as well, but I'd like to get Dave's opinion first. Thanks! Alex ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
