ThinkWiki - User contributions [en]

Talk:Problems with SATA and Linux

2006-08-17T14:29:19Z

Jlquinn: /* Patch against SATA-resume problem with T60 */

__TOC__

I'm running gentoo on my T43; I had problems with X11 (opensource radeon driver) and a SATA-patched kernel (I tried both 2.6.14 and 2.6.15-gentoo). Suspend to RAM worked nicely, but starting X freezed the machine after a short time. I tried removing radeonfb from the kernel; with vesafb, everything seems to work.

-- Stefan, 10 Jan 2006

--------
That's strange - with the libata passthrough (IDE driver not in kernel) as set up in the text, my t43p DVD drive also will not record as hinted in the wikipage... DMA works fine, so DVD playing / ripping is smooth and quick. CD record functions also are absent. I have PATA enabled, and the suspend + SMART patches applied over 2.6.14.2.
--------
I can confirm this with 2.6.14.4, however with 2.6.15/15.1 with sata_pm patch it works.

-- Rasto, 24 Jan 2006

--------
regarding the "BIOS error 2010 on user-installed hard disk":
the text says that corruption occurs if you use a harddisk without the specific ibm bios. would be interesting if it is possible to fix this problem in the kernel so that you can use any disk and the kernel doesn't use specific ATA commands which are known to cause problems.

in the tabook i didn't find any specification of the SATA bridge. it would be interesting:
1) what type it is
2) if it is fixed on the mainboard or if it is possible to solder in a new one

----

Another interesting question is whether these ThinkPads can be hacked to accept a real SATA system disk, by bypassing the SATA-to-PATA bridge (this would probably involve some soldering and cutting). If the BIOS can also handle that then it may come in handy, since some new high-capacity 2.5" disks have only SATA versions.
--[[User:Thinker|Thinker]] 02:56, 8 Oct 2005 (CEST)

----

'''Z series'''

Since the Z series uses a SATA controller and disk, without the bridge, would it be possible to make SATA ATAPI support as a module that you could load only when using the optical drive? Then, for everyday use, the experimental options of PATA and ATAPI with ata_piix would not be needed, moving you one step further in the direction of stability.

----

I have an R52 with Ubuntu Breezy and no problems with SATA (I personally asked the developers to include the needed patches).

However, I'd like to know wheter there are any advantages with this configuration. Future proof? Power saving? Speed?

Anybody cares to comment?

-- [[User:Micampe|Michele]]

Straight SATA, like in the Z60m/t, will provide better upgrade options in the long run (the hard disk industry is slowly but surely moving to SATA), and maybe a small performance increase if your drive, controller and OS support command queueing (they probably don't). However, with the hybrid ThinkPad models that use a SATA-to-PATA bridge, like your R52, you get all the drawbacks and none of the benefits; plus there's the horrible issue with [[Problem with non-ThinkPad hard disks|drive compatibility]]. My impression is that Lenovo did this just as a convenient (for them!) transition path, in order to use new chipsets without comitting to (temporarily) scarcer and more expensive drives. In any case, they didn't even have the decency to make the UltraBay Slim accept SATA drives.

--[[User:Thinker|Thinker]] 18:10, 3 Nov 2005 (CET)
----
There is a [[UltraBay Slim SATA HDD Adapter]], but only compatible with the Z series (at least for the moment).

--[[User:Tonko|Tonko]] 03:12, 4 Nov 2005 (CET)
----

Is it possible to enable AHCI on the Z60m? There doesn't seem to be an option for it in the BIOS, even after updating to the latest BIOS version (1.19). I don't think it's enabled by default since the "ata_piix" driver finds my controller and the "ahci" driver doesn't.

--[[User:Wyzard|Wyzard]] 06:06, 12 August 2006 (CEST)
----

Ok, I got it working with compatibility instead of AHCI (X60s) but I would like to know whats the difference between those two? Anybody with a quick explanation?

@Wyzard: AFAIK you have to switch it within BIOS and if you can't then you can't use ata_piix.

--[[User:elm|elm]] 16:46, 12 August 2006 (CEST)

== updated libata_passthru.patch ==

FYI: when using the Suspend-to-RAM patch from http://lkml.org/lkml/2005/9/23/97 against 2.6.14 the libata_passthru.patch from the article doesn't apply any more, so I've put up an updated version at http://linux.spiney.org/system/files?file=02_libata_passthru.fixed.patch

I give no warranties whatsoever whether it works or kills your hardware, but since I just removed duplicate parts already in the Suspend-to-RAM patch it should be ok.

--[[User:spiney|spiney]] 19:04, 4 Nov 2005 (CET)

Hi

Running 2.6.16-rc4 and I'm running into scsci errors and Input/output
errrors when resuming from suspend to ram. The suspend patch is
supposed to be in 2.6.16-rc1 and I'm booting with

title= 2.6.16-rc4
root (hd0,0)
kernel /boot/kernel-2.6.16-rc4 root=/dev/sda3 ro combined_mode=libata
libata.atapi_enabled=1 acpi_sleep=s3_bios processor.max_cstate=2
elevator=cfq ide1=noprobe

Thanks.

----

Don't know about -rc4, but -rc3 worked without problems, could you try that one instead? Maybe there was some bug introduced between these two versions. What's combined_mode=libata BTW?

--[[User:Spiney|spiney]] 08:28, 23 February 2006 (CET)

== ATA_ENABLE_PATA PCI IDs ==

Spiney, could you extend the article to explain what and why are the PCI IDs in the footnote about ATA_ENABLE_PATA?

--[[User:Thinker|Thinker]] 21:59, 4 Nov 2005 (CET)
----

Ok, done, feel free to fix the table because I'm a bit struggling with Wiki-style editing. ;) As for the why, those PCI IDs are the only ones affected by the ATA_ENABLE_PATA, as seen in {{path|drivers/scsi/ata_piix.c}} in the kernel source.

--[[User:spiney|spiney]] 11:19, 5 Nov 2005 (CET)
----

Will other cards work without ATA_ENABLE_PATA, or just fail? In the former case your instructions are right, but in the latter case we should tell the user to check the list of IDs in his ''current'' kernel and, if there's no match, to give up in the first place instead of following the rest of the instructions.

--[[User:Thinker|Thinker]] 12:48, 5 Nov 2005 (CET)
----

AFAICT if the chipset is supported by libata it will work, regardless of what low-level driver is used. Of course if there is no low-level driver for the chipset then even using the harddisk via libata will fail, but that's a different story. At least ATA_ENABLE_PATA will then make no difference since it's Intel PIIX (and compatible) only.

--[[User:spiney|spiney]] 13:24, 5 Nov 2005 (CET)
----

Not sure I got you. Is there any case where the instructions will work without ATA_ENABLE_PATA, given that all ThinkPad optical drives are PATA?

--[[User:Thinker|Thinker]] 13:41, 5 Nov 2005 (CET)
----

The instructions will work without ATA_ENABLE_PATA unless the Thinkpad uses one of the three chipsets listed in the article, as long as libata works at all, i.e. the system drive shows up as /dev/sda. The #define doesn't change the behaviour of libata for any other chipset, it's [http://linux.yyz.us/sata/sata-status.html#ich5 ata_piix] only.

Since I don't have a machine with one of the three chipsets (anyone?), I can't tell whether those work at all with libata, but I guess there's a reason why they're not enabled by default. It's just that defining ATA_ENABLE_PATA is only making sense for these three chipsets.

Any clearer now? If not, just run {{cmd|grep -r ATA_ENABLE_PATA /path/to/kernelsource|}} and see how seldom and where the #define is used.

--[[User:spiney|spiney]] 14:55, 5 Nov 2005 (CET)
----

All clear now. I thought it will work only if you have these chipsets ''and'' ATA_ENABLE_PATA=1. Thanks for the explanation!

--[[User:Thinker|Thinker]] 15:12, 5 Nov 2005 (CET)
----

Does any of the relevant ThinkPad models (listed in the article) use these chips? They look too old to be found on the SATA models.

--[[User:Thinker|Thinker]] 23:35, 9 Nov 2005 (CET)
----

I don't think so, I was about to add "in the unlikely event that you own one of these chipsets" or something.

--[[User:Spiney|spiney]] 07:56, 10 Nov 2005 (CET)
----

== DVD DMA with ide/sata as module ==

Did anyone get DVD DMA to work with either the IDE or SATA drivers compiled as modules? If so, please fill in the missing details in that section. I have it working only with both IDE and SATA built-in.

--[[User:Thinker|Thinker]] 17:58, 16 Nov 2005 (CET)
----

Basically using a Live-CD with a recent kernel (is there one with 2.6.14 already?) would be sufficient, since they usually use an initrd or something similar, don't they? I'll give the Debian distribution kernel a try when I get around to it (bit busy atm), after all there's 2.6.14 in sid.

But for people using their own kernel compiled from source I see no point in doing the module+initrd thing anyway, unless you want LVM for the root filesystem or other funky stuff.

--[[User:Spiney|spiney]] 19:22, 16 Nov 2005 (CET)
----

Hi

Can anyone tell me how those modules are called?

Thomas
--[[User:Thomas|thomas]] 19:48, 23 Jan 2006 (CET)
----

Where the hell do I find the libata module?

--[[User:squashball|squashball]] 09:09, 11 June 2006 (CET)

The relevant driver is called ata_piix. The ata_piix driver uses a chunk of shared kernel code called libata.

--[[User:Thinker|Thinker]] 09:33, 11 June 2006 (CEST)

Ok, Thanks. Nevertheless I am not able to get my drive working. It's a T60...

--[[User:squashball|squashball]] 12:29, 12 June 2006 (CET)

Your T60 uses AHCI by default. You have to change the BIOS settings to "compatibility mode" to use the HDD and DVD drive with ata_piix. Then, you're also able to hotswap your ultrabay. But for this, a patch for ibm_acpi is needed.

--[[User:Whoopie|Whoopie]] 14:57, 12 June 2006 (CEST)

Yeah, thanks, it's working now! Where was I supposed to find this info?
EDIT: But DMA is still off and can't be enabled.

--[[User:squashball|squashball]] 07:58, 13 June 2006 (CET)

DMA is enabled by default with libata. Do a "dmesg |grep DMA" and you'll see. You can't use hdparm to see the settings for your hdd. BTW, if you have more questions, you could join IRC ##ibmthinkpad.

--[[User:Whoopie|Whoopie]] 11:04, 13 June 2006 (CEST)
----

== occasional hang upon resume with various kernels ==

I keep having trouble with resume after suspend to ram. Occasionally, it takes longer to wake up and then is in a semi-hanged
state, i.e. nothing having to do with actual reading from the disk works. (what was running, as aterm
is still running, ls works, when the listing is buffered, but hangs if it is not).
Kernel is 2.6.15 with sata-pm patch. Later 2.6.15 kernels hang always and it's the same with 2.6.16.
Could perhaps somebody, for whom it works without problems post his .config somewhere?
I'm out of ideas.

--[[User:Rasto|Rasto]] 14:46, 20 March 2006 (CET)

I have the same problem with my x41 and 2.6.16 or 2.6.16-r1 running on Gentoo. Sometimes resume is ok and sometimes the disk doesn't resume. I can't see any log because the disk is unwritable after resume. The logs on F12 is full of io error.
I tested many different kernel configs, unloading modules before suspend, stopping services...
Like Rasto, I'm out of ideas...

--[[User:Pplr|Pplr]] 19:21, 8 April 2006 (CEST)

You could try http://rtr.ca/dell_i9300/kernel/kernel-2.6.16/02_libata_resume_fix.patch
This patch worked for me.

--[[User:Whoopie|Whoopie]] 21:21, 8 April 2006 (CEST)

Hello, according to the first lines of the article, resume does not work prior to kernel 2.6.16, i.e. the computer hangs up just a second after it comes back. I just switched from 2.6.15 to 2.6.16 but the problem still remains. I have a Z60M thinkpad. So this has obviously the same problem as the T60.

-- [[User:Bjoern.thalheim|BjÃ¶rn]] 14:37, 10 April 2006 (CEST)

Increasing the timeouts seems to do the trick. I applied it about two weeks ago, and it works since.

-- [[User:Rasto|Rasto]] 09:59, 11 April 2006 (CEST)

Ubuntu Dapper with 2.6.15-23 is also exhibiting this problem even though the sata_pm patch is applied. Bjorn, which timeout are you referring to?

-- [[User:nmuntz|nmuntz]] 09:08, 13 June 2006 (MDT)

== Suspend to RAM on X41 not working with Debian-packaged 2.6.16 ==

I just tried the Debian package of the Linux 2.6.16 kernel on my [[X41]] to see if suspend-to-RAM would work. Unfortunately, it didn't. The laptop suspends just fine, but when it's turned back on, the backlight remains off, there is a lot of disk activity for a while, and then the computer just shuts off. When turned on again, it boots normally. Suspend-to-disk works fine, just like before.

On a different note, CPU throttling broke on my system with the new kernel. I can no longer modprobe acpi-cpufreq. [[User:Ehn|Ehn]] 04:28, 22 March 2006 (CET)

:The latter issue was solved by using speedstep-centrino instead of acpi-cpufreq. [[User:Ehn|Ehn]] 23:25, 9 April 2006 (CEST)
----

Neither problem is related to this article, so it's unlikely to be answered here.

--[[User:Thinker|Thinker]] 17:37, 22 March 2006 (CET)
----

Hm. It seems to be a problem with sata power management for me, so I guess this could be one of the places.

[[User:Rasto|Rasto]] 17:45, 22 March 2006 (CET)
---

Ehn, by "disk activity" do you mean a constantly on HDD LED and no disk movement noises, or ''real'' disk activity with the LED flashing and disk noise? The former is likely to be the SATA problem, the latter rules out the SATA problem.

--[[User:Thinker|Thinker]] 18:44, 22 March 2006 (CET)

:The latter. There is real disk activity, indicated by LED flashing and disk movement noise, for about 30 seconds, before the machine gives up and shuts down. If this is not SATA-related, what might it be? [[User:Ehn|Ehn]] 23:23, 9 April 2006 (CEST)

----

Sorry, I didn't realize Ehn has two problems, and I considered your post as aimed at my and Ehn's. Never mind then.

[[User:Rasto|Rasto]] 10:47, 23 March 2006 (CET)

== Problem with 2.6.16 ==

ok, seems like we have a new problem:
After upgrading from 2.6.15 to 2.6.16 my DVD device is not recognised anymore by libsata.
The only way to get working is by using the ide layer - without DMA of course.
Can anyone confirm this?

--[[User:Defiant|Erik]] 17:49, 23 Mar 2006 (CET)
--------

Try the kernel parameter '''combined_mode=libata''', does this help? Also, have you enabled libata's ATAPI support as described in the article?

--[[User:Thinker|Thinker]] 20:31, 23 March 2006 (CET)
----

Yes, I'm using the command line parameter libata.atapi_enable=1 - up to 2.6.15 it works fine.
About the combined_mode parameter: Also tried it, though the Author of this patch mentioned that the default behavior did not changed.
I will continue hungting this problem when I find some time.

--[[User:Defiant|Erik]] 7:12, 24 Mar 2006 (CET)
-----

I can confirm Eriks problem. After updating to 2.6.16 I have it, too. libata.atapi_enable=1 is still on kernel command line. With some help of Michael Ott I figured out that this only happens if you have the current suspend2 patches applied.
Using a vanilla 2.6.16 works as expected.

--[[User:Mobst|mobst]] 14:30, 24 Mar 2006 (CET)
-----

Ahh thanks. Finding the problem in the suspend2 patch should be an easy task.
I just hope for some free time this weekend!

--[[User:Defiant|Erik]] 18:31, 24 Mar 2006 (CET)
-----

Uhm, looks like [[ZolnOtt|ZolnOtt]] was faster, he added the note to
http://thinkwiki.org/wiki/Problems_with_SATA_and_Linux#No_DMA_on_DVD_drive

--[[User:Defiant|Erik]] 20:02, 24 Mar 2006 (CET)

== Patch against SATA-resume problem with T60 ==

I only have a Fujitsu-Siemens C1320, but I had the same problem with resuming from suspend with a SATA disk and kernel 2.6.16 as mentioned for the T60. I solved the problem for me by merging several patches (patches.fixes/libata-increase-timeout-for-resume, patches.fixes/ahci-suspend, patches.fixes/ahci-atapi-sense-request, patches.drivers/libata-acpi-suspend, patches.fixes/libata-resume-drive_port-mode, patches.fixes/ahci-init-on-resume, patches.drivers/libata-device-spindown)
from the OpenSuSE kernel 2.6.16-12 to vanilla 2.6.16.5. You'll find my patch at http://www.spinnaker.de/linux/c1320/sata-resume-2.6.16.5.patch. I expect this to solve the T60 problem, so I provide the patch here, as this wiki helped me so much with my laptop.

--[[User:Rrosenfeld|Rrosenfeld]] 23:12, 16 April 2006 (CEST)

I just want to let you know that I managed to get Suspend-to-RAM working on the T60. I'm using Gentoo's suspend2-sources-2.6.16-r2 as base and applied the above patches from Rrosenfeld (thanks!) and additionally this [https://bugzilla.novell.com/attachment.cgi?id=75844&action=view one] (here the corresponding [https://bugzilla.novell.com/show_bug.cgi?id=162090 bug]).

--[[User:Sts|sts]] 22:52, 17 April 2006 (CEST)

same here. applied both patches to gentoo suspend-sources-2.6.16-r5 --- working. sweet.

--[[User:Husemann|dr who]] 21:51, 3 May 2006 (CEST)

however: powersave (powersaved) is a spoiler: it will cause the resume operation to get stuck at "reading back caches" and eventually result in a kernel panic. stopping powersaved before hibernating does not prevent it: it seems that running powersaved just once will screw things up. interesting and nasty. but not a show stopper (IMHO).

--[[User:Husemann|dr who]] 17:14, 10 May 2006 (CEST)

that's not powersaved's fault. kernel panics are always kernel (or hardware) bugs. i experienced this kind of lockups when using different cpufreq governors at once (that's probaly something one shoudln't do?). i'm now using only cpufreq_userspace and don't have any problems.

--[[User:Sts|sts]] 15:11, 11 May 2006 (CEST)

Having exactly the same SATA wakeup problem on my Z60t, using FC5. Can the patch from rosenfeld be applied also to the FC5 kernelsource?

--[[User:SzentivÃ¡nyi|szenti]] 21:29, 11 May 2006 (CEST)

Latest fedora (FC5) 2.6.17-1.2139_FC5smp kernel solved the problem on my T60p. I have successfully resumed a number of times now.

--[[User:Gfbarros|Guil]] 20:38, 27 June 2006 (CEST)

Vanilla 2.6.17.8 lets me suspend and resume on a T60p. But I had to set the SATA mode to Compatibility (ata-piix) in the BIOS. The other catch is that if you suspend from a console rather than X, you get a black screen. Fn-F7 back to X gets your display back. Of course, if you don't have X up, you're kind of stuck and the safest thing to do is to tell the machine to reboot. The keyboard still works, so you have to type blind.

--jlquinn 17 Aug 2006 (signature button didn't work properly)

Problems with fglrx

2006-08-08T14:50:12Z

Jlquinn: /* Perpetual Mesa GLX Indirect on Debian */

This page discusses issues with the ATI proprietary [[fglrx]] display driver.

== Known Troubles and Solutions ==

=== X-specific issues ===

ATI proprietary drivers version 8.21.7 and later work with x.org 6.9.

If you are running an older version (8.20.8) under Debian sid and you upgrade your xserver-xorg, apt will force you to remove any debian-packaged fglrx drivers (package fglrx-driver depends on x.org << 6.8.99). You can just download the driver from the ATI site and install after modifying the Debian packager script to allow dependencies to be satisfied by x.org 6.9, or just download 8.21.7 and install manually. See talk page for step-by-step commands.

After installing the fglrx driver, you can use module-assist to build the appropriate kernel module.

=== Kernel-specific troubles ===

Using ATI drivers <=8.21.7 with kernel >=2.6.15 needs a [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]. (see table below for detail.) If you can't compile the driver modules with 2.6.15 or later, you should apply this [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch patch] instead.

If you do not use one of these patches, you may experience peculiar lockups of X. Try {{cmduser|fglrxinfo}} - if your shell hangs at the end of this command, you may have an issue and should try the patch or upgrade.

Although unproven, there is a substantial amount of user / developer concern that the above patches prevent hard lockups but do not provide full reliability with 2.6.15 and there are larger / redisgn issues preventing compatibility. These issues have been fixed with later ATI drivers (> 8.21.7) so you can simply upgrade if you are running a more modern kernel.

=== No hardware acceleration ===

====Acceleration lost after driver update====
If you lose hardware acceleration after a driver update this can be caused by an old fglrx kernel module being loaded.

Check out {{path|1=/var/log/Xorg.0.log}} for a message like:
:<code>(WW) fglrx(0): Kernel Module version does *not* match driver.</code>
:<code>(EE) fglrx(0): incompatible kernel module detected - HW accelerated OpenGL will not work</code>

You can verify this yourself by looking at the version message some lines above. It should read something not matching the installed version like:
:<code>(II) fglrx(0): Kernel Module Version Information:</code>
:<code>(II) fglrx(0): Name: fglrx</code>
:<code>(II) fglrx(0): Version: 8.10.19</code>

The cause for this trouble might be that there resist multiple versions of the fglrx module within the kernel module search path. 
Go to {{path|1=/lib/modules/<your linux kernel version>/}} and type {{cmdroot|1=grep fglrx modules.dep}}. 
If grep finds multiple lines you nailed down the problem. All you have to do now is to delete any versions of the module (look at the filedate) but the most current one. Then run {{cmdroot|1=depmod}} and you are done.

{{HINT|Newer versions (8.21.7) of the fglrx module seem to be installed in the <code>extra/</code> subdirectory. 
Older versions (8.19.10) used to be located in the <code>kernel/drivers/char/drm/</code> subdirectory.}}

====GCC 3.4====
If the ATI driver works only without the hardware acceleration, take into consideration that {{path|fglrx_dri.so}} was linked against libstdc++.so.5 which may not be present if your system uses gcc-3.4.

To fix this, compile gcc-3.3.5 and copy <tt>libstdc++.so.5*</tt> to {{path|/usr/lib}} and update the dynamic linker cache via {{cmdroot|ldconfig}}.

Or install a compat package for your favorite distro. FC4 users can do:
:{{cmdroot|yum install libstdc++.so.5}}

====radeonfb framebuffer====
Another possible cause for broken hardware acceleration (2D and 3D) is the radeonfb framebuffer: Switching to vesafb or vesafb-tng is reported to solve the problem on some systems. Also it has proven helpful to not perform {{cmdroot|modprobe fglrx}} after boot but to have the module loaded via {{path|/etc/modules.autoload/kernel2.x}} at boottime instead.

====Perpetual Mesa GLX Indirect on Debian====
If you've done everything right and you're still seeing:

$ fglrxinfo
display: :0.0 screen: 0
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.2 (1.5 Mesa 6.4.1)

try this:

# mkdir -p /usr/X11R6/lib/modules/dri
# ln -s /usr/lib/dri/fglrx_dri.so /usr/X11R6/lib/modules/dri

Thanks to Maciej Matysiak for the clear debug [http://lists.debian.org/debian-amd64/2006/02/msg00217.html here] and solution [http://lists.debian.org/debian-amd64/2006/02/msg00311.html here].

More generally, use LIBGL_DEBUG=verbose fglrxinfo, to see what's happening, and whether you get this:
gandalf:~$ LIBGL_DEBUG=verbose fglrxinfo
libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/fglrx_dri.so
libGL error: dlopen /usr/X11R6/lib/modules/dri/fglrx_dri.so failed (/usr/X11R6/lib/modules/dri/fglrx_dri.so: cannot open shared object file: No such file or directory)
libGL error: unable to find driver: fglrx_dri.so
display: :0.0 screen: 0
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.2 (1.5 Mesa 6.4.2)

instead of that:
gandalf:~$ LIBGL_DEBUG=verbose fglrxinfo
libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/fglrx_dri.so
libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)
drmOpenByBusid: busid is PCI:1:0:0
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 4, (OK)
drmOpenByBusid: drmOpenMinor returns 4
drmOpenByBusid: drmGetBusid reports PCI:1:0:0
Can't open configuration file /home/merlin/.drirc: No such file or directory.
fglrx: DPD supported.
display: :0.0 screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: MOBILITY FIREGL T2 Pentium 4 (SSE2) (FireGL) (GNU_ICD)
OpenGL version string: 2.0.5879 (8.26.18)

I have contacted ATI to add that info by default, the mesa guys to do that in glxinfo too, as well as the debian packager to fix the debian packaging bug (2006/07/22), so hopefully the situation will improve soon

You may have to run fglrxinfo as root to get this detail rather than a useless message.

=== Softlink hell ===
The [[fglrx]] installer replaces the standard X.org OpenGL implementation (Mesa) with its own files, potentially causing collisions with the distribution's file and package management. It is best to install the driver via a package built for your distribution, which will typically include the necessary kludges to make things work. See the [[fglrx]] page for pointers.

====Discussion====
If using {{cmduser|fglrxinfo}} after installing [[fglrx]] indicates that you are still using the mesa indirect software GL renderer, you likely have some misplaced softlinks. It seems like it has to do with an apt-get upgrade that sometimes replaces these links. Anyway, go to
:{{cmdroot|cd /usr/X11R6/lib}}
and list your GL libraries and links
:{{cmdroot|ls -la *GL*}}
You should see something like the following two lines amoung others:
:{{cmdresult|libGL.so -> libGL.so.1.2}}
:{{cmdresult|libGL.so.1 -> libGL.so.1.2}}
If you see a link to a mesa library (something like {{cmdresult|... -> libGL.mesa.1.2}}), then that's your problem! Restore the softlink like this (use your actual library version, though):
:{{cmdroot|ln -s libGL.so.1.2 libGL.so.1}}

For some reason, this link might "break" later, giving you the software rendering once more. Even after renaming the mesa library to something like <tt>mesa.bkup</tt>, the system might still find it and link to it despite the name change. If you have to do this a lot, you could write a restoreGL script.

=====Gentoo=====
{{Gentoo}} has built in tools for managing the OpenGL symlinks. They seem to be replacing the old tool with a new one, so one of the following should work for you:
:{{cmdroot|opengl-update ati}} or
:{{cmdroot|eselect opengl set ati}}
Eselect is new, and still ~x86 (as of the end of 2005), so you may not have it yet. <tt>opengl-update</tt> is the old tried-and-true method for managing the symlinks. If <tt>opengl-update</tt> doesn't fix it for you, you should probably tell [http://bugs.gentoo.org Gentoo Bugzilla] (assuming they don't know yet).

If {{cmdroot|ldd /usr/X11R6/bin/glxinfo}} shows that your system still uses the xorg-x11 mesa libs after trying one of the above commands, i.e. a line like this:
:{{cmdresult|1=libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0x400a8000)}}
you will also need to relink {{path|libGl.so.1.2}}:
:{{cmdroot|cd /usr/lib/opengl/xorg-x11/lib/}}
:{{cmdroot|mv libGL.so.1.2 libGL.so.1.2_backup}}
:{{cmdroot|ln -s /usr/lib/libGL.so.1.2 libGL.so.1.2}}
After another restart of X {{cmduser|fglrxinfo}} should show that it's using the right libs now.

=====Debian=====

<pre>
# rm /usr/lib/libGL.so*
# rm /usr/X11R6/lib/libGL.so*
# cd /usr/X11R6/lib
# cp /usr/lib/fglrx/diversions/lib/libGL.so.1.2 .
# ln -s libGL.so.1.2 libGL.so.1
# ldconfig
</pre>

=== Troubles using software suspend ===
When the computer resumes from suspend, X only displays a garbled image and the computer is frozen.
The problem is acknowledged in ATI's release notes and in knowledge base entry <strike>[https://support.ati.com/ics/support/KBResult.asp?searchFor=Search+Words&search.x=0&search.y=0&searchOption=id&questionID=737-218+&task=knowledge&searchTime=-1&productID=&folderID=-1&resultLimit=50 737-218]</strike> [https://support.ati.com/ics/support/KBAnswer.asp?questionID=218 737-218]. Driver version 8.19.10 has "initial support for Suspend and Resume" but is working very nicely for most people (verified on T43, T43p and T42) without vbetool.

If you are using an older version of fglrx, using [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to save/restore the video card state before/after suspend worked for some people. If you use [[Software Suspend 2|Software Suspend 2 (suspend2)]] scripts, you can simply uncomment <tt>EnableVbetool yes</tt> in {{path|/etc/hibernate/hibernate.conf}}. Be aware though that it breaks suspend/resume for drivers beginning with version 8.19.10, so remember to disable it again when upgrading.

{| cellspacing="0" cellpadding="2" border="1"
|+ tested with the following configurations
!model!!distro||kernel!!fglrx!!PM!!success!!comments
|-
|{{T42}}||SUSE 9.3||2.6.11||8.14.13||swsusp||yes||
|-
|{{T41p}}||???||2.6.14||8.19.10||suspend2 2.2-rc9||yes||needs a small [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch]
|-
|{{T42p}}||Debian||2.6.10||Debian packaged||suspend2||yes||
|-
|{{T43}}||Debian sid||2.6.14.2||8.19.10||swsusp||yes||works perfectly with 8.19.10 (but not earlier versions!)
|-
|{{T43}}||Debian etch||2.6.14.2||8.19.10||swsusp||yes||works perfectly with 8.19.10 and without vbetool
|-
|{{T43}}||Ubuntu Breezy||2.6.12-10||8.19.10||swsusp||yes||Perfect. (Finally.)
|-
|{{T43}}||FC4||2.6.14.1||8.19.10||suspend2 2.2-rc9||yes||needs a small [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch], requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)
|-
|{{T43}}||FC4||2.6.14.2||8.19.10||suspend2 2.2-rc11||yes||requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)
|-
|{{T43}}||FC4||2.6.14.3||8.19.10||suspend2 2.2-rc13||no||DRI enabled
|-
|{{T43}}||FC4||2.6.14.3||8.20.8||suspend2 2.2-rc13||no||DRI enabled
|-
|{{R50p}}||???||???||8.19.10||swsusp||yes||
|-
|{{T43p}}||Debian sid||2.6.14||8.19.10||Suspend to RAM||yes||without vbetool or UseDummyXServer, those two ''break'' the resume process here, with DRI enabled
|-
|{{T43p}}||Debian sid||2.6.14.3||8.20.8||Suspend to RAM||yes||without vbetool or UseDummyXServer, with DRI enabled
|-
|{{R52}}||Debian sid||2.6.15-rc5||8.20.8||swsup||yes||both vbetool and UseDummyXServer disabled, DRI enabled, needs [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]
|-
|{{T43p}}||Gentoo||[http://packages.gentoo.org/ebuilds/?suspend2-sources-2.6.15-r6 2.6.15]||8.22.5||Suspend to RAM||yes||without vbetool or UseDummyXServer, with DRI enabled - console is garbled until switching back from X
|-
|{{T43p}}||Gentoo||[http://packages.gentoo.org/ebuilds/?suspend2-sources-2.6.15-r6 2.6.15]||8.22.5||suspend2 2.2||yes||without vbetool or UseDummyXServer, with DRI enabled
|-
|{{T43}}||SUSE 10.1||2.6.16||8.25.18||swsusp||yes||without vbetool or UseDummyXServer, with DRI enabled
|-
|{{T43}}||SUSE 10.1||2.6.16||8.25.18||Suspend to RAM||yes||without vbetool or UseDummyXServer, with DRI enabled
|-
|{{T60p}}||Kubuntu 6.06||2.6.15||8.25.18||swsusp||no||Switching to VT to suspend: no resume, X restarts; Not switching: suspend works, garbled X display on resume, later X restarts
|-
|{{T60p}}||Kubuntu 6.06 Text Mode||2.6.15||---||swsusp||yes||suspend works in textmode after rmmod fglrx.
|}

=== Troubles with large RAM ===
Version 8.14.13 (and probably earlier versions) of the driver does not seem to be able to cope with large amounts of RAM: with 512 MB it works, with 1.5 GB it crashes the machine as soon as X is started. The problem is present only if the <tt>fglrx</tt> kernel module is loaded, but independently of whether {{kernelconf|CONFIG_HIGHMEM||||||}} is enabled. A workaround is to limit RAM by adding the {{bootparm|mem|864m}} kernel parameter.

Version 8.16.20 fixes the problem.

===Display switching ===
The switching between internal and external display doesn't work with fglrx versions <= 8.24.8, because the driver blocks messing around with the chipset via ACPI. If you want to use this feature (i.e. during presentations), you should use the <tt>vesa</tt> server instead (experienced with a R52, Kernel 2.6.11, xorg 6.8.2, fglrx 8.16.20). Or boot notebook with CRT connected, it will automatically detect it and display on both.

===Composite Support===
ATI has not officially supported composite windowing (alpha channel) enabling hardware acclerated translucent windows (primarily for 'eye candy.') Enabling Composite in KDE and the fglrx driver results in a very pretty desktop but unacceptably slow performance on a T43p with ATI's FireGL T2. It is still unusable in its current state (as of driver 8.25.18).

ATI promises support in the future when composite is officially supported by Xorg. Discussion of current status of drivers can be found in the Rage3d forums' (http://rage3d.com/board) Linux area.

There were some rumors that composite support was fast with the open-source 2d accelerated drivers in x.org 7.0 (as opposed to 6.8.x). Alas, trying this gives better results than the proprietary drivers, but it is still too slow to be reasonably useful.

===Hardlock on X logout===
Up from driver version 8.19.10 you will experience a system hard lock when logging out from X, if the session manager (kdm/gdm) is not properly configured. You have to tell the session manager to restart X.

In the kdm config file (gentoo: {{path|/usr/kde/<VERSION>/share/config/kdm/kdmrc}}) you have to add following to the section <code>[X-:*-Core]</code>:
TerminateServer=true

In the gdm config file add:
AlwaysRestartServer=true

Information from the ATI bugtracker: http://ati.cchtml.com/show_bug.cgi?id=239

Another reason of hardlock my be using the wrong AGP driver. Make sure that you have proper drivers for your motherboard loaded before fglrx: (gentoo: {{path|/etc/modules.autoload.d/kernel-2.6}}):
intel-agp
fglrx

A common problem seems to be mistakenly using ATI Chipset drivers instead of Intel.

Information from gentoo bugtracker: http://bugs.gentoo.org/show_bug.cgi?id=113685

===Cannot switch to VT===

At least with a T60p (Mobility Fire GLV5200) on Kubuntu 6.06 and fglrx 8.25.18 it is not possible to switch to a VT from X (Using Alt+Fn); Display becomed dark and the system freezes. CTRL+ALT+BKSPCE doesn't return to console, instead X restarts (Seems to be a kdm configuration feature from Kubuntu). When trying to do console login only every second attempt succeeds, otherwise it yields a black display.

http://ati.cchtml.com/show_bug.cgi?id=37

===Flickering Display===

Some people have reported problems with their display flickering when using ati-drivers newer than 8.14.13. The problem is unclear
(possibly associated with an incorrect modeline setting) and no known solution exists except to use the open source radeon drivers.
You can follow this problem here: http://ati.cchtml.com/show_bug.cgi?id=248

===Error messages in system log===

If you find something like the following in {{path|/var/log/messages}}:

:{{cmdresult|kernel: mtrr: base(0xc0000000) is not aligned on a size(0x7ff0000) boundary}}
:{{cmdresult|kernel: [fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)}}
:{{cmdresult|kernel: [fglrx:firegl_unlock] *ERROR* Process 5132 using kernel context 0}}

try to execute the following line and reload the fglrx module:

:{{cmdroot|1=echo "base=0xd0000000 size=0x8000000 type=write-combining" > /proc/mtrr}}

More detailed instructions can be found [http://ubuntuforums.org/showthread.php?t=115104 here].

===Hang when logging out===

A common problem is that when logging out from X, instead of gettign the KDM or GDM prompt, the system hangs.

This is discussed, including workarounds here: http://ati.cchtml.com/show_bug.cgi?id=239

===No power saving when CRT in use===

When both CRT and LCD are in use, power saving cannot be enabled.

This is reported here: http://ati.cchtml.com/show_bug.cgi?id=304

== Patches ==
The following patches might be needed for certain versions of fglrx.

===fglrx 8.23.7===
* For kernel 2.6.16: [http://mirror.espri.arizona.edu/gentoo/rsync/x11-drivers/ati-drivers/files/ati-drivers-8.22.5-intermodule.patch <tt>intermodule</tt> patch] and [http://mirror.espri.arizona.edu/gentoo/rsync/x11-drivers/ati-drivers/files/ati-drivers-8.23.7-noiommu.patch <tt>noiommu</tt> patch]

===fglrx 8.21.7===

* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]

===fglrx 8.20.8===

* [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 for kernel 2.6.15]
or
* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]

===fglrx (problem met at least with version 8.18.8)===
* [http://lkml.org/lkml/2005/9/22/183 for kernel >= 2.6.13 ] Missing verify_area bug

===fglrx 8.8.25 ===
* [http://www.rage3d.com/board/showthread.php?t=33798874 for kernels >= 2.6.10]
* [http://www.gehirn.org.uk/wiki/images/8.8.25-kernel-2.6.11+.patch For kernels >= 2.6.11-rc1]

===Links ===
* [http://gentoo-wiki.com/HOWTO_ATI_Drivers Gentoo HOWTO ATI]