Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Nov 2012 20:12:53 -0800
From:      matt <sendtomatt@gmail.com>
To:        "Henry B." <cryptix@riseup.net>
Cc:        freebsd-x11@freebsd.org
Subject:   Re: Radeon HD 4350 - no DRI / only Software Rasterizer under FreeBSD 9.0?
Message-ID:  <50B6E0C5.9020303@gmail.com>
In-Reply-To: <e7adcfd7264c6037d8867bc064663ed4.squirrel@fulvetta.riseup.net>
References:  <e7adcfd7264c6037d8867bc064663ed4.squirrel@fulvetta.riseup.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 11/28/12 18:57, Henry B. wrote:
> On 29.11.2012, at 1:31 , matt <sendtomatt@gmail.com> wrote:
>> That card should work, I personally use a crappy 4650 (PowerColor GO!,
> RV730) and it usually only has issues with buggy GL programs.
>
> That's good news! I was beginning to think nobody uses ATI graphics cards
> on FreeBSD. :)
> I currently can't recall the card manufacturer but the chip is RV710.
>
>> Try a different card (system setup bad)
> That's what I'm thinking about next if this can't be figured out..
>
>> Try a different monitor (corrupt EDID crashes driver)
> I also use the monitors (Benq G2110w) with my macbook, a raspi and had
> them on two PCs of friends.
> Never had a problem with them and they worked fine under Linux on the same
> box.
>
>> Try same card in Linux/Windows (card is bad)
> I'm trying to adopt my dual head setup from a previous ArchLinux
> installation, so I think I can rule out 'bad card'.
>
> It feels like bad driver / bad timing. The driver on Linux was much more
> recent and using KMS but i have the card for quite some time and also had
> this setup before KMS was introduced, which makes this problem quite
> unexpected and weird.
>
>> It looks like a bad crash...can you SSH in and keep gdb attached to get
> a backtrace?
> From what i can tell, the system actually panics when I try to load X with
> DRI enabled and it takes down the SSH connections with it.
>
> I attached what is left from gdb's output to the mail. Sadly I don't have
> a chance to input bt before it goes down..
>
>
>> I think it might be connector table or PLL related, my card says this
> after yours crashes.
>> [165240.090] Output UNIPHY1 transmitter setup success
>> [165240.090] Output CRT2 disable success
>> [165240.090] Output UNIPHY0 transmitter setup success
>> [165240.090] Blank CRTC 0 success
>> [165240.090] Disable CRTC memreq 0 success
>> [165240.090] Disable CRTC 0 success
>> [165240.090] Blank CRTC 1 success
>> [165240.090] Disable CRTC memreq 1 success
>> [165240.090] Disable CRTC 1 success
>> [165240.091] Output UNIPHY0 transmitter setup success
>> [165240.091] Blank CRTC 0 success
>> [165240.091] Disable CRTC memreq 0 success
>> [165240.091] Disable CRTC 0 success
>> [165240.091] Set CRTC 0 Source success
>> [165240.091] Mode 1680x1050 - 2240 1089 6
>> [165240.091] (II) RADEON(0): RADEONRestoreMemMapRegisters() :
>> [165240.091] (II) RADEON(0):   MC_FB_LOCATION   : 0x00df00d0 0x00df00d0
>> [165240.091] (II) RADEON(0):   MC_AGP_LOCATION  : 0x00030000
>> [165240.091] Picked PLL 0
>> [165240.091] before 14625
>> [165240.091] after 14625
>> [165240.091] best_freq: 146250
>> [165240.091] best_feedback_div: 130
>> [165240.091] best_frac_feedback_div: 0
>> [165240.091] best_ref_div: 3
>> [165240.091] best_post_div: 8
>> [165240.091] (II) RADEON(0): crtc(0) Clock: mode 146250, PLL 1462500
>> [165240.091] (II) RADEON(0): crtc(0) PLL  : refdiv 3, fbdiv 0x82(130),
> fracfbdiv 0, pdiv 8
>> [165240.101] Set CRTC 0 PLL success
>> [165240.101] Set CRTC Timing success
>> [165240.101] Set CRTC 0 Overscan success
>> [165240.101] Not using RMX
>>
>> Matt
>
> Comparing your output to the one i get from gdb it looks like the next
> line would be
> [165240.091] Mode 1680x1050 - 2240 1089 6
>
> I'm also intrigued by the "failed to set mtrr: Invalid argument" not sure
> what to make of it.
>
>
> kind regards,
>
> Henry
>
>
> _______________________________________________
> freebsd-x11@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org"
Here's some other thoughts...by no means exclusive.

-It's always possible that Linux behaves more graciously with a given
EDID. FreeBSD can be more picky about hardware, especially graphics of
course. Did xrandr see all your modes properly?

-Regarding mtrr, this
http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050072.html
looks fruitful...not sure if it's all still accurate. Do you happen to
have an onboard controller other than the ATI? If so, see if you can
change BIOS options related to it...apparently this shouldn't be fatal.
Any GART bios options etc?

-If you are just copying your arch xorg.conf, try doing X -configure and
copying the resulting file (/root/xorg.conf.new) to /etc/xorg.conf...it
will have all the radeon driver options in it.

Amongst those there are some options to twiddle, the man page has docs.
There is one which ignores the connector table on the card, another
which enables/disables something called NewPLL and some for dealing with
EDID issues. You can rule out EDID with another monitor. The other two
options could be worth twiddling. I really think this is either a EDID
bug, connector table bug or PLL setup is wrong and crashing the card.

-Another debugging option is to turn on hw.dri.0.debug=1 with sysctl
after kldloading radeon.ko, and then watching the dmesg over ssh until
the crash...or set the fs options to sync in fstab and check the logs
after you power cycle it. This will give some insight into what the drm
devices is doing.

-You could try a BIOS update too, usually won't hurt.

-CFLAGS should be -02 -pipe (at least for system setup), and this is
coming from a gentoo user :).

-You can also try the newer Xorg, by putting WITH_NEW_XORG=YES into
make.conf, update your ports tree with portsnap or svn and then run
portmaster -day...This will bring in the more recent Xorg and ATI
driver, HOWEVER, it's not easy to go back if you're not pretty familiar
with ports. You will also have to rebuild all the X drivers.

If you can beg/borrow/steal a different HD4xxx it would be interesting
to see if the problem persists.

Matt



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50B6E0C5.9020303>