Date: Thu, 1 Oct 2009 10:33:07 -0500 From: "Richard Kolkovich" <sarumont@sigil.org> To: Robert Noland <rnoland@FreeBSD.org> Cc: freebsd-x11@freebsd.org Subject: Re: HD4550 DRI issues Message-ID: <20091001153307.GF36488@magus.portal.sigil.org> In-Reply-To: <1254392190.98309.750.camel@balrog.2hip.net> References: <1253915723.2145.53.camel@balrog.2hip.net> <20090926001158.GA42914@divination.portal.sigil.org> <1253925689.2065.81.camel@balrog.2hip.net> <20090926045706.GB42914@divination.portal.sigil.org> <1253977337.2048.17.camel@balrog.2hip.net> <1253993801.2048.295.camel@balrog.2hip.net> <20090926194802.GA67832@divination.portal.sigil.org> <1254001621.2048.431.camel@balrog.2hip.net> <20091001021855.GE36488@magus.portal.sigil.org> <1254392190.98309.750.camel@balrog.2hip.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--m1UC1K4AOz1Ywdkx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > > >=20 > > > 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... > > >=20 > >=20 > > Any ideas yet? For some reason, I now need to disable mtrr for my nvid= ia-driver to work (the card > > my 4550 is hopefully replacing...I'm having other issues with nvidia-dr= iver and would prefer an > > open-source solution). I don't think I've tried the radeon with mtrr d= isabled. > >=20 > > My 30 day return window on this card is almost up, so I may end up retu= rning it if we can't figure > > this out. Apparently, a different card wouldn't help, either. :-\ >=20 > 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. >=20 I haven't seen any other issues indicative of RAM failure, but I'll give me= mtest 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. >=20 +% 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. >=20 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 455= 0), 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 showe= d the correct info. Either way, I'm pretty sure I remember the (2d) performance being a bit lag= gy 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. >=20 Go figure...my first Intel board/CPU, and I stumble across something like t= his. :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. --=20 Richard Kolkovich sarumont@sigil.org --m1UC1K4AOz1Ywdkx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkrEy7EACgkQfXtD1KVAIbCvXgCgzkQTQoGOo6t0DW8vGTuNUWIg o3oAnAulw38eyfJEv+Dw3ncQ5fCJmnpJ =k+1I -----END PGP SIGNATURE----- --m1UC1K4AOz1Ywdkx--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091001153307.GF36488>