[SOLVED] fglrx, AMD3510MX/Radeon HD6620, and Xorg - can't st

[meursalt]

Hello,

First, here is some general background. Skip below to SYMPTOMS for my exact issue:

I’m in the process of setting up my first Gentoo install. So far I am really enjoying the system, mainly because of how BSD-like it is. I have some general un*x and Linux background, but I have been out of the FOSS scene for several years and am a bit rusty in some areas. I’d really like to go with Gentoo as my primary distribution because I don’t like the direction some of the more mainstream distributions have gone: For instance, Debian (my old distro of choice when I wasn’t using one of the BSD’s) now defaults to booting graphically into gdm3 if you install X. Rather than paring down a Debian install and rebuilding it the way I like it, I’d like to start with a distro that is more minimal out of the box. I thought this was going to be Slackware, but I tried Gentoo on a whim and I am pretty impressed with it. It almost felt like installing NetBSD!

Again, I have some general Linux background, but my knowledge is a bit outdated. Xorg is new to me, but before the fork I was pretty comfortable setting up XFree86, which was more temperamental. I’m not afraid to get my hands dirty and do my research, but I seem to be going in circles trying to get X set up on this Gentoo laptop. I was hesitant to waste the time of others with requests for help, but I have worked on this for a week and have reached a point where I may be in over my head. I am still learning the portage/emerge system, so I might be making some trivial mistake somewhere.

I fear my issue may be fairly hardware-specific. This is a brand-new Samsung Series 3 NP305V laptop, with the fairly-new AMD 3510MX (Llano core) APU with on-die Radeon HD 6620 display adapter. The mainboard chipset appears to be AMD all the way, with a Realtek 1000BT NIC and Atheros 802.11/bluetooth. Samsung hasn’t released specs for the system and their support staff gave me incorrect specs (they told me it was an Intel chipset with an Intel Core i3 CPU), so all of my information comes from probing. Let me know if more specific information is needed, but I am fairly certain the APU is the crux of all my woes.

Most recent distro’s boot with a black screen when “fb" or Xorg start modesetting, or simply hang on boot. The open source Radeon driver simply doesn’t seem to support this display adapter, although the VESA drivers seem to work OK, but with distorted aspect ratio due to the wide screen on this laptop. Maybe this is fixable, but I’d like 3D acceleration, so I have focused my efforts on a more hardware-specific driver.

My only good option seems to be to use the proprietary ATI “fglrx” driver. I know the driver works at least passably well with my hardware, because I have gotten it to work on Debian testing/wheezy (using the package manager) and Fedora (by simply running the ATI installer, since I don’t really care about the Fedora system, and am keeping it just in case I hose an install and need a bootable system to fall back to). The xorg.conf generated by “aticonfig --initial” is identical on the working Debian and Fedora systems and the broken Gentoo system.

SYMPTOMS:

If I delete any existing /etc/xorg.conf and run “sudo /usr/bin/Xorg -configure”, the command fails immediately without any probing, stating “No devices to configure. Configuration failed.” Maybe this is to be expected since I'm using a proprietary driver module? Full stderr and log output is at the end of this post.

If I then run “startx” (still with no xorg.conf), nothing happens for about 30 seconds, then the command exits. No probing is done and the screen never flashes or turns black (full stderr and log at end of post).

If I run “sudo aticonfig --initial”, an xorg.conf is produced, identical to that on my Debian partition (where it actually works). If I then run “startx,” I get a delay of about 10 seconds, followed by a black screen which flashes twice like it’s attempting a probe. Then Xorg shuts down and returns me to the console shell. On stderr, I do get the following warning:

[DaggyStyle]

[meursalt]

x11/drivers/ati-drivers is version 11.12. This is the same version that is working on Debian and Fedorah. It was initially at an earlier version until I sync'ed the system. It may have been updated due to my ACCEPT="~AMD64" flag in make.conf, but I am not sure of this.

[DaggyStyle]

[meursalt]

[DaggyStyle]

[meursalt]

[DaggyStyle]

[meursalt]

OK, I rolled my system back to a backed up partition image (in order to avoid the library downgrade you mentioned), and left ACCEPT out of my /etc/make.conf. I'm still having the same issues as before: startx seems to hang for about 10-20 seconds, then the screen goes black and flashes twice before the X server appears to exit gracefully.

I first tried with the normal "stable" Xorg server (I believe this is 1.11.2-r2? I don't have the version number in front of me.) and ati-drivers 11.11. When that didn't work, I added "x11-drivers/ati-drivers ~amd64" to /etc/portage/package.keywords in order to get ati-drivers 11.12. I emerged ati-drivers, did "eselect set opengl ati," rebooted, and tried again with the same results. I then added "x11-base/xorg-server ~amd64" to get xorg-server 1.11.3, emerged xorg-server, and still got the same results.

To reiterate, this is working under Debian with ati-drivers 11.12 and xorg-server 1.11.2.902 (1.11.3 RC 2), so I know this driver is capable of working with this hardware. Here is the most recent log with ati-drivers 11.12 against xorg-server 1.11.3, along with my xorg.conf:


/var/log/Xorg.0.log:
http://pastebin.com/pP6buG0q

my xorg.conf:
http://pastebin.com/5nGNqcV5

I'd appreciate any suggestions or insight, or even just a "me too" from someone else running Gentoo on a recent AMD/ATI APU so I can get a better idea if this is a problem on my end. Thanks for looking at this,

-m

[DaggyStyle]

care to supply dmesg of the last run?
_________________
Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein

[Ant P.]

If you used ACCEPT="~amd64", then it won't change anything to remove it because the correct variable is ACCEPT_KEYWORDS.

[meursalt]

OK daggystyle, here is dmesg and lspci output from the kernel I'm currently working under:
dmesg output:

http://pastebin.com/V6BWsp8v

lspci output:

http://pastebin.com/5hXGdT2i

@Ant P. - My apologies; I was going from memory and typing in a hurry. I was indeed using ACCEPT_KEYWORDS, not ACCEPT. Since then, I restored the system from a backup, so this is no longer in place. Sorry for any confusion.

Thanks
-m

[meursalt]

I don't know if this is helpful, but i just tried running the "Xorg" binary without going through "startx". This time, the server didn't exit on its own. It stopped with a black screen. I was able to ctl-alt-F2 to a virtual terminal and "tail -f /var/log/Xorg.0.log." The server was still responsive to signals, so I was able to exit with ctl-C. Here is the part of the log from immediately before the screen going black:

[meursalt]

Correction: I somehow pasted the wrong URL for my dmesg output. Here is the correct one:

http://pastebin.com/V6BWsp8v

Sorry!
-m

[DaggyStyle]

do you have either framebuffer or kms enabled in the kernel?
_________________
Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein

[meursalt]

[Ant P.]

Kernel settings look fine. Try running "X -retro", it should get stuck on the old fashioned black-and-white background. If that works then it's likely the problems are all in xinitrc.

[meursalt]

[jasn]

Since this is llano, (new), hardware to be on the safe side, you should be ok if you make sure you're using the latest drivers, and it appears that you are. Once you've emerged the latest portage xorg-server, xorg-drivers, and ati-drivers, you should be able to generate your xorg.conf with aticonfig.

The thing to remember about the ATI drivers is that you follow the open source directions if you want to use the open source driver, and you follow the fglrx instructions to use the proprietary driver. You don't mix instructions. That means for fglrx no other display driver kernel config other than agpgart, and no kernel firmware configuration/loading. The firmware loading instructions are only for the radeon open source driver.

Good Luck..

[meursalt]

@jasn - Thanks for the info; I did not realise that fglrx doesn't require the firmware blobs. I guess it probably already has them internally, since it comes from ATI? I'll remove them next time I tweak the kernel.

@Ant P. - You have saved me a lot of time. Chalk this up to my being more familiar with XFree86 than Xorg. Prior to a month or two ago, I had literally barely touched a computer since before the Xorg/XFree86 fork. Everything else works so similarly between the two, with Xorg generally being more forgiving of sloppy configurations, that it never occurred to me that Xorg would have a "stealth mode" server with a black background and invisible mouse cursor by default. I had seen the -retro flag referenced in some FreeBSD forum posts with no clear indication of what it actually did, and since it doesn't seem to even be mentioned in the Xorg manual, I didn't want to muck about with it until you suggested it.

Turns out, I think I had everything working just fine days ago. But when I saw a black screen instead of the familiar X cursor and stippled background, I assumed the driver was malfunctioning. I have to wonder what drove the design decision to make the X server default to an all-black "stealth mode." Perhaps it was an effort to appease the eye candy kiddies who wanted a smoother transition when starting X. It's times like this I'm glad I have a decent sense of humour; otherwise I might be a bit upset.

@Daggystyle - you probably saved me big headaches further down the road by catching my make.conf error.

I think I'm ready to start building a pretty desktop. Thanks again everyone. I'd like to mark this [SOLVED]. Is there a special flag for this in the forum software, or can I edit the subject line?

Thanks,
-m

[DaggyStyle]

I haven't used the ati closed driver for some time now because it gives me no gain over the open one but do note that what I do remember is that screen framebuffer and the driver don't get along, you need to disable the fb.
_________________
Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein

[meursalt]