HD4550 DRI issues

Richard Kolkovich sarumont at sigil.org
Thu Oct 1 15:33:18 UTC 2009


On Thu, Oct 01, 2009 at 05:16:30AM -0500, Robert Noland wrote:
> On Wed, 2009-09-30 at 21:18 -0500, Richard Kolkovich wrote:
> > On Sat, Sep 26, 2009 at 04:47:01PM -0500, Robert Noland wrote:
> > > 
> > > Ok, that eliminates everything to do with the card and X.  Let me talk
> > > to some folks and see if we can figure out where to go from here...  I'm
> > > wondering if this might be BIOS or CPU related now...
> > > 
> > 
> > Any ideas yet?  For some reason, I now need to disable mtrr for my nvidia-driver to work (the card
> > my 4550 is hopefully replacing...I'm having other issues with nvidia-driver and would prefer an
> > open-source solution).  I don't think I've tried the radeon with mtrr disabled.
> > 
> > My 30 day return window on this card is almost up, so I may end up returning it if we can't figure
> > this out.  Apparently, a different card wouldn't help, either. :-\
> 
> All of the evidence suggests that this has nothing to do with the card.
> Basically, with the test program the only card specific things that
> happen are those that happen at driver load time.  We haven't even told
> the card about the memory that we have allocated yet.  It has been
> suggested that it might be a bug in drm's mmap routine, but I can't find
> it at this point.  It has also been suggested that you run memcheck to
> verify the ram, but since things seem to be correct from the kernel
> perspective, I don't think that is the issue.
> 

I haven't seen any other issues indicative of RAM failure, but I'll give memtest a shot.

> The mtrr issue, might be a clue though.  It sets the caching mode for
> the memory allocation.  I'm mostly using PAT now, (particularly with the
> patch that I gave you).  Did you send me a "memcontrol list", I don't
> recall at this point.  The x58 appears to deal with memory rather
> differently than traditional chipsets, so I wonder if it might not be a
> chipset or BIOS bug.
> 

+% sudo memcontrol list
Password:
memcontrol: can't size range descriptor array: Operation not supported

Mabye that's a clue?  :-\  (I'm back on my 8.0-RC1 kernel now, btw)

> As for nvidia, you can always use nouveau.  That will (*should*) get you
> EXA and Xv acceleration, but not 3d at this point.  Follow the
> instructions in the xf86-video-nouveau for getting my kernel patch how
> to set things up.  However, that driver also uses scatter-gather memory,
> perhaps even more so than the radeon driver.  So, given what we have
> seen so far, I don't know that it will not produce corruption or
> possibly worse.
> 

I've given nouveau a shot before, and I'm pretty sure everything worked the first time (beginning of
July)  Last time I tried it (more recently...just before I ordered this 4550), rotation did not work
for me with both monitors.  One screen had corruption (much the same as we see with the 4550) at the
top.  It was like the screen had the wrong coordinates, though xrandr showed the correct info.
Either way, I'm pretty sure I remember the (2d) performance being a bit laggy for everyday use.

> I've spent a fair amount of time digging through the mmap and memory
> allocation bits in the kernel, but haven't found anything that looks
> wrong.  What I don't understand is, why this doesn't effect all or at
> least all i386 systems.  So, I think it almost has to be chipset
> specific. .... Well, I just went back and found one of the prior reports
> of this.  It looks like that (assuming it is the same cause) was on an
> intel 945 chipset running 7.2-RELEASE i386.  Have you considered running
> amd64?  Your i7 is certainly worthy of it and I would be curious to see
> if the problem exists when running amd64 also.
> 

Go figure...my first Intel board/CPU, and I stumble across something like this. :P

I had considered trying amd64 after I saw your setup was amd64.  I've never had too much reason for
running amd64, but I could justify it now that I'm using zfs.  ;)

I may give amd64 a shot later today and let you know if that helps.

-- 

Richard Kolkovich
sarumont at sigil.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20091001/a0e9eafb/attachment.pgp


More information about the freebsd-x11 mailing list