Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 16 Nov 2014 08:35:26 -0500
From:      Dutch Ingraham <stoa@gmx.us>
To:        freebsd-x11@freebsd.org
Subject:   Re: Xorg configure failure with Radeon card
Message-ID:  <5468A81E.5040806@gmx.us>
In-Reply-To: <5468A1F7.8040907@addr.com>
References:  <5466DD69.5000205@gmx.us> <54673C5D.6040900@gmail.com> <54676567.8090200@gmx.us> <5467A3BE.2060207@gmail.com> <5467A75D.9000605@gmx.us> <5467AD77.9060408@gmail.com> <20141115164711.dc9f2b0b219c604ceff307cf@gmx.us> <5468A1F7.8040907@addr.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 11/16/14 08:09, Tony Sweeney wrote:
> On 11/15/2014 21:47, Dutch Ingraham wrote:
>> On Sat, 15 Nov 2014 20:45:59 +0100
>> Jan Kokemüller <jan.kokemueller@gmail.com> wrote:
>>
>>>> Thanks again, Jan.  I already had that there (from the 10.1-RELEASE
>>>> notes), so the error is with that tuner set.
>>>
>>> Does "kldload radeonkms" as root work, as in gives you a nice looking
>>> console in native screen resolution? If that works, at least the KMS
>>> driver does something correctly.
>>>
>>> Another idea is to try to rebuild the "x11-drivers/xf86-video-ati" port,
>>> if you haven't done that already.
>>>
>>> Can you post the complete contents of /var/log/Xorg.0.log and the output
>>> of dmesg after a failed attempt to start the X server?
>>>
>>> -Jan
>>
>> Jan!!  That's just the wake-up I needed!  I went back to the last
>> section of the wiki on graphics referred to above and re-read it.  For
>> some reason, I was under the impression that loading the radeon
>> firmware in the method described in that section was only if I
>> wanted/needed kms to be loaded early; I assumed it would be loaded
>> later in the boot process on its own, though.
>>
>> I was wrong.  After issuing a #<kldload radeonkms> as you suggested,
>> the fb graphical resolution loaded.  Then, taking wblock@'s advice
>> (elsewhere) that Xorg -config is now generally unnecessary, just
>> issued a <startx> and things were working properly.  A little xrandr
>> action and both monitors are working as desired.
>>
>> For the record, if anyone else is having this radeon issue, here is a
>> summary specific to the 5450 card (note some of this may be
>> unnecessary, I haven't tested each yet):
>>
>> In loader.conf
>>
>> kern.vty=vt
>> radeonkmsfw_CEDAR_pfp_load="YES"
>> radeonkmsfw_CEDAR_me_load="YES"
>> radeonkmsfw_CEDAR_rlc_load="YES"
>> radeonkms_load="YES"
>>
>> In make.conf:
>>
>> WITH_NEW_XORG=YES
>> WITH_KMS=YES
>> OPTIONS_SET=GALLIUM (or WITH_GALLIUM=YES, but the compiler will warn
>> on this when building dri)
>>
>> Thanks again for all your help, Jan.
>>
> OK, following Jan and Dutch's advice I've gotten further, but I'm still
> not quite there.  I'm running 10.1-RELEASE (upgraded from 10.1-RC4 using
> freebsd-update), the base system is an AMD 7850, so I'm not expecting
> the built in Kaveri chip to work any time soon.  However, I also have an
> HD5450 installed so I'm hoping I can get this to work.  I added the
> kern.vty tunable and manually loaded radeonkms.  This pulls in the same
> CEDAR firmwares as above and enables the high res framebuffer, but
> startx still gives "no screens found".  Initially the log showed that it
> was trying and failing to load the fbdev driver, so I pkg installed
> xf86-video-fbdev (this may have been a mistake) and it now fails loading
> submodule fbdevfw.  So far I've been trying to work entirely with
> packages, but I'm happy to build from ports if it will get me a working
> X console.  I've attached the standard logs recommended in the Wiki.
> 
> Tony.
> 
> 
> _______________________________________________
> 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"
> 
Tony:

Until someone with real knowledge comes along, you could check and make
sure you don't have an errant xorg.conf laying around screwing things up.

Also, I'm not sure of the default options set with the pre-built binary
packages, so I would check the dri configuration; specifically, issue a
<pkg info dri> and make sure the option GALLIUM is set to :on.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5468A81E.5040806>