ThinkWiki - User contributions [en]

Sierra Wireless HSDPA WWAN

2008-04-26T16:42:30Z

Noahf: how to get the linux sierra driver to recognize the MC8765 1199:6805 device in some thinkpads

North American ThinkPads have the Sierra Wireless MC8765 card.
European ThinkPads have the Sierra Wireless MC8755 card.

According to the T61 hardware maintenance manual, the T61 uses the MC8775, which is quad band EDGE (850/900/1800/1900) and tri band HSDPA (850/1900/2100).

The only difference between the two is the frequency at which they support WCDMA. The MC8765 supports WCDMA800 and WCDMA1900, while the MC8755 supports only WCDMA2100.

Both models support GPRS and EDGE at 850, 900, 1800, and 1900MHz.

Both models are category 11/12 UMTS devices, meaning they support up to 1.8Mbps downstream using QPSK modulation. They do not support 16QAM modulation.

=== Sierra Wireless MC8765 1199:6805 support ===

The model 2613-ETU T60p (and possibly others) has one of these cards which the linux <tt>sierra</tt> device driver does not automatically recognize (as of kernel 2.6.24.4, at least). While it's the same device in every other respect the PCI id isn't standard, presumably because IBM/Lenovo use their own PCI ids to restrict the use of arbitrary 3rd party cards. Using the 2.6.23+ hotplug infrastructure, we can cause the driver to claim it anyway and register serial devices in <tt>/dev</tt> for it.

To do this using the '''udev''' subsystem, edit or create the file <tt>/etc/udev/rules.d/98-local.rules</tt> file and add:

<code><pre>######
## Sierra Wireless MC8765 1199:6805 support
##
## My model 2613-ETU T60p contains a WAN device which the linux sierra
## device driver does not automatically recognize. Using the 2.6.23+
## hotplug infrastructure, we can cause the driver to claim it.
##
## The 3-port interface works with this device, but there's not much point
## in registering the 2nd and 3rd since they are used for control purposes
## that we don't currently use under linux.
######

#SUBSYSTEM=="drivers", \
# ACTION=="add", \
# ENV{DEVPATH}=="/bus/usb-serial/drivers/sierra3", \
# RUN+="/bin/sh -c 'echo 1199 6805 > /sys/bus/usb-serial/drivers/sierra3/new_id'"

SUBSYSTEM=="drivers", \
ACTION=="add", \
ENV{DEVPATH}=="/bus/usb-serial/drivers/sierra1", \
RUN+="/bin/sh -c 'echo 1199 6805 > /sys/bus/usb-serial/drivers/sierra1/new_id'"

# TODO: fix this:
# This isn't quite right for sierra3, since it will always symlink
# wan_modem to the last created device; in the 3-port case that's not the
# device we actually want to refer to for modem interaction (we want the
# first device). We could limit this using ENV{PHYSDEVDRIVER}="sierra1",
# but udev warns that this is deprecated and will be removed from a future
# kernel.
KERNEL=="ttyUSB*", \
SYSFS{manufacturer}=="Sierra Wireless*", \
SYMLINK+="wan_modem", \
GROUP="uucp", \
MODE="0666"
</pre></code>

Problems with fglrx

2008-02-06T04:04:49Z

Noahf: use xrandr to work around fglrx 8-01 3D bug

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

== Known Troubles and Solutions ==

=== X-specific issues ===

==== upgrading xserver-xorg ====
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.

==== new Xorg ID Scheme ====
ATI proprietary drivers <=8.36.5 with xorg >=7.1.0-18 (==1.3.0.0) in Debian Sid and Fedora ([http://www.sidux.com/PNphpBB2-viewtopic-t-3162-postdays-0-postorder-asc.html Debian] and [http://www.phoronix.net/forums/showthread.php?t=2382 Fedora] Forum Entries)

Ubuntu feisty made their own xorg with the standard id of 7.2, to work around this issue.

Xorg has changed its ID Scheme in newer Versions, and fglrx cannot cope with that (Error message saying "[...] X version mismatch - detected X.org 1.3.-1.905, required X.org 7.1.0.0 [...]").

A binary hack solves the Problem [http://rage3d.com/board/showthread.php?s=4638d94143536f6acacbccd8f0443472&t=33889029 (rage3d.com Forum Entry)]. This is a very '''dirty''' solution, and is probably violating the ATI driver license.

Simply using the open source ati driver (or holding back the xorg upgrades) until a new driver is released, is suggested.

As of version 8.37.6, this issue is solved. No more binary hacking needed.

=== 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.

==== 2.6.23 ====
In 2.6.23 release cycle, config option CONFIG_SUSPEND_SMP got renamed to CONFIG_PM_SLEEP_SMP. fglrx uses this variable for disabling power management on older kernels. As a result, SMP users running 2.6.23 weren't able to resume properly (almost instant lockup in that rare case fglrx managed to show a few usable pixels. A [http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-10/msg03437.html quick patch] is available.

=== 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:

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

try this:

:{{cmdroot|mkdir -p /usr/X11R6/lib/modules/dri}}
:{{cmdroot|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:
:{{cmduser|<nowiki>LIBGL_DEBUG=verbose</nowiki> fglrxinfo}}
:{{cmdresult|libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)}}
:{{cmdresult|libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/fglrx_dri.so}}
:{{cmdresult|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)}}
:{{cmdresult|libGL error: unable to find driver: fglrx_dri.so}}
:{{cmdresult|display: :0.0 screen: 0}}
:{{cmdresult|OpenGL vendor string: Mesa project: www.mesa3d.org}}
:{{cmdresult|OpenGL renderer string: Mesa GLX Indirect}}
:{{cmdresult|OpenGL version string: 1.2 (1.5 Mesa 6.4.2)}}

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

==== Where to look for fglrx_dri.so (gentoo and general)====
After installing a new kernel (linux-2.6.20-gentoo-r7) with gentoo I again was not able to get the ATI driver working
correctly. But now I found out what the problem was:

I tried
:{{cmduser|<nowiki>LIBGL_DEBUG=verbose</nowiki> fglrxinfo}}
:{{cmdresult|libGL: XF86DRIGetClientDriverName: 8.35.5 fglrx (screen 0)}}
:{{cmdresult|libGL: OpenDriver: trying /usr/lib32/dri/fglrx_dri.so}}
:{{cmdresult|libGL error: dlopen /usr/lib32/dri/fglrx_dri.so failed (/usr/lib32/dri/fglrx_dri.so: wrong ELF class: ELFCLASS32)}}
:{{cmdresult|libGL error: unable to find driver: fglrx_dri.so}}

The error itself makes sense, because I am running a 64-Bit linux on AMD. The question was, why libGL tries to look
in /usr/lib32 only...

After some digging around I found out, that apparently 8.35.5 version of the driver uses the environment variable
'''LIBGL_DRIVERS_PATH''' to find out where it should look for the "fglrx_dri.so" driver.

Now in my case this environment variable pointed to "/usr/lib32/dri" and that was what caused the problem.
So doing
:{{cmduser|<nowiki>export LIBGL_DRIVERS_PATH='/usr/lib64/dri:/usr/lib32/dri'</nowiki>}}
solved the problem in my case.

As mentioned I use gentoo. After some more digging around I found out, that it is apparently necessary to call
:{{cmduser|env-update}}
after a re-install of the ATI driver. To be more specific, it seems that "eselect opengl set ati" sometimes
does something wrong. "env-update" seems to repair the problem so that afterwards the '''LIBGL_DRIVERS_PATH'''
environment variable is set correctly when you log in.

If you want to check, look in <code>/etc/profile.env</code> and <code>/etc/profile.csh</code>. This is the
place where the '''LIBGL_DRIVERS_PATH''' environment variable gets set.

=== 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.
:{{cmdroot|eselect opengl set ati}}
If <tt>eselect opengl ati</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=====

:{{cmdroot|rm /usr/lib/libGL.so*}}
:{{cmdroot|rm /usr/X11R6/lib/libGL.so*}}
:{{cmdroot|cd /usr/X11R6/lib}}
:{{cmdroot|cp /usr/lib/fglrx/diversions/lib/libGL.so.1.2 .}}
:{{cmdroot|ln -s libGL.so.1.2 libGL.so.1}}
:{{cmdroot|ldconfig}}

=== Troubles using software suspend ===

Suspend won't work on any distribution which has activated the new SLUB allocator with fglrx < 8.42. This affects e.g. Ubuntu 7.10 Gutsy (see https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/121653/). The only workaround is currently to compile a custom kernel with SLAB support!

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
|-
|{{T43p}}||FC6||2.6.20-1.2933||8.34.8||swsusp, STR||yes||DRI enabled, occasionally fails, reason unknown.
|-
|{{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
|-
|{{T60}}||Gentoo 2006.1||2.6.19-suspend2||8.31.5||Suspend2||yes||Everything works: 3D, suspend-to-disk, suspend-to-ram, suspend in X.org, switching to VT's at any moment. Never needed to unload any modules manually, worked immediately. Fglrx driver 8.32.5 totally broke suspend for me, so i'm sticking with 8.31.5. T60 2008-B62 model.
|-
|{{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.
|-
|{{T60p}}||Debian/unstable/experimental||2.6.18||8.31.5-1 (from debian experimental)||susptoram hibernate debian packages||yes||suspend and resume works with X, 3D acc., Xv overlay...
|-
|{{T60p}}||Fedora Core 6 x86_64||2.6.20-1.2962_1.fc6.cubbi_suspend2|| 8.38.6||suspend2 hibernate||yes||suspend2 hibernate and resume working with libata driver (ahci not tested). Xv still broken since 8.35.5. Have not needed to set extra_pages_allowance thus far.
|-
|{{Z61m}}||Debian Sid||2.6.20.7||8.35.5-1||Suspend to RAM||yes||works without any problems, justs needs the usual acpi_sleep hacks
|-
|{{Z61m}}||Debian Sid||2.6.20.7||8.35.5-1||Suspend to Disk (Software Suspend)||yes||works without any problems
|-
|{{Z61m}}||Debian Sid||2.6.21||8.35.5-1||Suspend to RAM||yes||fglrx module must not be loaded into the kernel, or it won't resume
|-
|{{Z61m}}||openSUSE 10.2||2.6.21.5||8.37.6||suspend2 2.2.10||yes||/sys/power/suspend2/extra_pages_allowance must be set to 20000
|-
|{{Z61p}}||ARCH Linux||2.6.20||8.35.5-1||Suspend to RAM||yes||works with KDE suspend
|-
|{{T60p}}||Gentoo||2.6.22-r8 gentoo-sources||8.39.4||Suspend to RAM,swsusp||yes||swsusp works without hibernate-script installed (installing breaks it), s-to-RAM works only with CONFIG_FB ''disabled'' in kernel. No acpi_sleep=... parameter, no special script, no vbetool.
|}

=== 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, as of fglrx 8.42.3 added composite windowing (alpha channel), enabling hardware accelerated translucent windows (primarily for 'eye candy.') This has not been tested yet, and reports will be added here as users evaluate this versus the R300 open source drivers.

For reference, some discussion of current status of drivers can be found in the Rage3d forums' (http://rage3d.com/board) Linux area.

Composite support is also supported with recent Mesa and Xorg > 7 with the open source 3d radeon / R300 drivers found in the linux kernel or debian's driver repository. It works with the [[R300]] / FireGL T2 series as found on the T43p extremely well. This has made rapid progress in speed with the latest few releases, and as of kernel 2.6.23 runs perfectly well with an R300 based card.

===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 (/etc/gdm/gdm.conf) file add the following to the daemon-section:
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: <s>[http://bugs.gentoo.org/show_bug.cgi?id=113685 113685]</s>. Fixed in 8.25.18

===Cannot switch to VT===

With usplash boot enabled, it may not be possible to switch to a VT from X (Using Alt+Fn). Tested on T60p (Mobility Fire GLV5200) on Ubuntu 6.06 / 6.10 and fglrx 8.25.18 / 8.28.8. Display may become garbled and system might freeze. Solution (testet on Ubuntu 6.10) is to either remove the "splash" kernel boot parameter or add "vga=791" parameter ("vga=794" can be used on 1400x1050 panel).

http://ati.cchtml.com/show_bug.cgi?id=37 
https://launchpad.net/distros/ubuntu/+source/usplash/+bug/63558

===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

===WineX / Cedega Installs Software But Errors on Loading Games===

Some users may experience problems with certain FIREGL cards (in my case an ibm t43p laptop with a v3200 ati firegl) whereby projects such as cedega and wine refuse to work with 3d graphics, but native binaries (e.g. quake 4) work fine. A possible workaround is to add the following line in the drivers section of your /etc/X11/xorg.conf

Option "UseFastTLS" "2"

This option used to be configured with the older ati drivers when you ran "fglrxconfig". I have not yet found a way to get it to appear with "aticonfig", hence the manual insertion. This option is good for several linux distros I have tried, fedora core 5, ubuntu dapper and suse 10.1. It does not appear to effect performance on natively run programs.

{{NOTE|This may cause problems on machines with a Linux kernel version of 2.6.20 or higher (observed choppy video and video color inversion on T60p with both 2.6.20 and 2.6.21).}}

===Line Appears Below Mouse Cursor===

Some users have reported seeing a line approximately 1 mouse height below the bottom edge of the cursor, which follows the mouse and appears to change color based on the image below the cursor. This has been seen to happen using fglrx without the kernel module installed (in 2D mode) and additionally on external displays or multiple X servers. To work around the problem, try disabling the DGA extension by making the following changes to your XFree86.conf or xorg.conf file. Replace (or comment-out)
Load "extmod"
with
SubSection "extmod"
Option "omit xfree86-dga"
EndSubSection

===Freeze while using OpenGL Apps===

Some OpenGL applications such as screensavers or games (SecondLife) cause freezes. The cursor still moves, but otherwise the machine is unresponsive. This is the case with Xorg 7.1 and fglrx 8.29.6 using an x1400 and other cards. The solution is to add the following options to the video Device section in xorg.conf:
Option "Capabilities" "0x00000800"
Option "KernelModuleParm" "locked-userpages=0"

===Xv doesn't work correctly with drivers >= 8.36 and Xyyyy-cards===

See [http://ati.cchtml.com/show_bug.cgi?id=677] for further information. It seems as if only Xyyyy-cards are affected. Problem: graphical glitches with mplayer, programs like xine and totem might not start up at all. 8.35 doesn't seem to be affected

===Floating Point Exception with various X apps===

When the X server is left to autodetect the DPI, the fglrx driver may fail to supply the monitor dimensions. Video output switching may contribute to this bug.

Problems were experienced on T42p with Ubuntu 7.04, xorg-driver-fglrx 7.1.0-8.34.8+2.6.20.5-16.29.

This can be observed with xdpyinfo

:{{cmduser|xdpyinfo | grep dimensions}}
:{{cmdresult|dimensions: 1280x1024 pixels (0x0 millimeters)}}

Many applications will use the screen size and attempt to calculate DPI, resulting in a divide by zero operation and a SIGFPE.

A work around is to supply the dimensions in /etc/X11/xorg.conf. Use the DisplaySize parameter within your monitor's configuration. For example:

Section "Monitor"
Identifier "Generic Monitor"
HorizSync 28.0 - 64.0
VertRefresh 43.0 - 60.0
Option "DPMS"
DisplaySize 433 351
EndSection

=== Corrupted 3D display ===
With driver version 7-12 or later, you may experience a corrupted 3D display, if your horizontal screen resolution is not a multiple of 64. This is a known bug[http://support.ati.com/ics/support/default.asp?deptID=894&task=knowledge&questionID=31720] but ATI support does not have a solution to it yet.

There are two possible workarounds for this bug:

1/ Open the Catalyst Control Center and force the anti-aliasing to at least 2x for all applications. This surprisingly fixes the problem, at the expense of framerate.

2/ As suggested by ATI support, edit the /etc/X11/xorg.conf and find the section "Display". Add the following line into the "Display" section:
Virtual <width> <height>
where <width> is the width of your screen in pixels rounded up to the next multiple of 64 and <height> is the height of your screen in pixels.
For example, if your native resolution is 1400x1050, use
Virtual 1408 1050

After starting the X server you can run {{cmdresult|xrandr -s 0}} to restore the X server to a native display resolution, and 3D rendering will still work.

== Patches ==
The following patches might be needed for certain versions of fglrx. Before you apply any of these, make sure that you really need them, as some distributions include all the necessary patches with the appropriate package (e.g. ati-drivers in gentoo).

===fglrx 8.37.6===
* For kernel 2.6.22 you need this patch from a [http://www.phoronix.com/forums/showthread.php?t=2849 Phoronix thread].

===fglrx 8.35.5===
* [http://whoopie.gmxhome.de/linux/patches/2.6.20/fglrx-8.35.5-for-2.6.20.patch For kernel 2.6.20], part of the Fedora packaging scripts in the ATI installer

===fglrx 8.34.8===
* [http://whoopie.gmxhome.de/linux/patches/2.6.20/fglrx-8.34.8-for-2.6.20.patch For kernel 2.6.20]

===fglrx 8.32.5===
* [http://whoopie.gmxhome.de/linux/patches/2.6.19/fglrx-8.32.5-for-2.6.19.patch For kernel 2.6.19]

===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]

Category:T60

2008-02-06T03:40:43Z

Noahf: Mention that even with 64-bit kernel, 945 chipset can't access 4GB ram

This pages gives an overview of all ThinkPad T60 related topics.
{| width="100%"
|style="vertical-align:top" |
<div style="margin: 0; margin-right:10px; border: 1px solid #dfdfdf; padding: 0em 1em 1em 1em; background-color:#F8F8FF; align:right;">

== Standard Features ==
=== Processor ===
* [[Intel Core 2 Duo (Merom)]] 1.66, 1.83, 2.0, 2.16, 2.33 GHz CPU
* [[Intel Core Duo (Yonah)]] 1.66, 1.83, 2.0, 2.16, 2.33 GHz CPU
* [[Intel Core Solo (Yonah)]] 1.66 GHz CPU

=== Graphics Adaptor ===
* [[Intel Graphics Media Accelerator 950]]
* [[ATI Mobility Radeon X1300]] (64 MB)
* [[ATI Mobility Radeon X1400]] (128 MB)

=== Display ===
* 14.1" TFT display with 1024x768 resolution
* 14.1" TFT display with 1400x1050 resolution
* 15.0" TFT display with 1024x768 resolution
* 15.0" TFT IPS display with 1400x1050 resolution
* 15.0" TFT IPS display with 1600x1200 resolution
* 15.4" TFT display with 1680x1050 resolution (widescreen)

* 512 MB or 1 GB [[PC2-5300]] memory standard upgradable to 4 GB{{footnote|1}}
* 40, 60, 80, 100 or 120GB 5400RPM SATA HDD (Some available in 7200RPM)
* [[AD1981HD]] HD Audio 1.0 controller
* [[Ethernet Controllers#Intel Gigabit (10/100/1000)|Intel Gigabit Ethernet Controller]]
* [[UltraBay|UltraBay Slim]] with one of the following:
** [[UltraBay Slim DVD-ROM Drive]]
** [[UltraBay Slim CD-RW/DVD-ROM Combo II Drive]]
** [[UltraBay Slim Super Multi-Burner Drive]]
* [[MiniPCI Express slot]] 1 with one of the following:
** None (empty)
** [[Intel PRO/Wireless 3945ABG Mini-PCI Express Adapter]]
** [[ThinkPad 11a/b/g Wireless LAN Mini Express Adapter]]
** [[ThinkPad 11a/b/g/n Wireless LAN Mini Express Adapter]]
* [[MiniPCI Express slot]] 2 with one of the following:
** None (empty)
** [[Verizon 1xEV-DO WWAN]]
** [[Cingular HSDPA WWAN]]
* [[CardBus slot]] (Type 2)
* [[ExpressCard slot|ExpressCard/54 slot]]
* [[Embedded Security Subsystem|IBM Embedded Security Subsystem 2.0]]
* [[Active Protection System|IBM Active Protection System]]
* [[Integrated Fingerprint Reader]] on select models
* [[ThinkPad Bluetooth with Enhanced Data Rate (BDC-2)]] on select models
* [[UltraNav]] (TrackPoint / Touchpad combo)
</div>
|style="vertical-align:top" |
[[Image:ThinkPadT60.jpg|ThinkPad T60]]
|}

== Resources ==
* [http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovo&lndocid=MIGR-62733 T60/p Hardware Maintenance Manual]
* [http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovo&lndocid=MIGR-62465 T60/p Service and Troubleshooting Guide]
* [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-65367 T60p Linux capable]
== Reviews ==
* [http://www.notebookreview.com/default.asp?newsID=2702 NotebookReview.com], 2006-01-05
* [http://www.anandtech.com/mobile/showdoc.aspx?i=2663&p=15 AnandTech], 2006-01-05
* [http://forum.thinkpads.com/viewtopic.php?t=21513&highlight=clean Nottes], 2006-02-25 (links from thinkpads.com; includes pictures of disassembled unit)
* [http://www.pcmag.com/article2/0,1895,1933669,00.asp PCMag.com], 2006-03-06
* [http://www.laptoplogic.com/reviews/detail.php?id=112&part=full&page=1 Laptop Logic], 2006-03-27
* [http://www.notebookjournal.de/tests/104 notebookjournal.de], 2006-04-24 (german, some good pictures)
* [http://www.notebookreview.com/default.asp?newsID=3368 NotebookReview.com], 2006-10-28 (widescreen T60)

== Miscellaneous ==
* [http://vizzzion.org/?id=t60 Running Linux on the Thinkpad T60], 25-05-2006
* [http://www.gtishrine.com/t60.php Installing Gentoo Linux on the Thinkpad T60], 15-06-2006

{{footnotes|
# Due to an addressing limitation in the Intel [[Intel_945PM|945PM]] and [[Intel_945GM|945GM]] chipsets, only 3GB will be available for use. (This is true even with an x86_64 kernel on models with core2 processor upgrades. Is there ''any'' workaround for this?)
}}

[[Category:T Series]]

Installing Fedora 8 on a ThinkPad T60

2008-02-06T03:25:07Z

Noahf: set no_multithreaded_io to speed up tuxonice hibernation

Meaning to get to this, but don't wait for me. Anyone doing a clean install should go ahead and fill this space. Here's the very short version:

I recently upgraded my T60 from F7 to F8, and that went smoothly.

Things mostly work when using the vesa driver for video. You can use the ATI driver if you want 3D, and that works great, but then suspend and resume stops working. I get a hang on suspend.

The free Intel WiFi driver works, but the status LED does not work.

What's your experience? --[[User:Whizkid|Whizkid]] 19:52, 16 November 2007 (UTC)

== Fresh install ==

I did a fresh install on my T60p, which I previously had Fedora Core 6 on.

Things worked quite well. The vesa driver is working OK over my ATI graphics card. The iwl3945 module is working acceptably (and much less of a pain to keep up to date than the old ipw3945). However, sometimes I'm getting lost connections. I'll try to investigate.

Hibernate works, but is very slow. I haven't tried suspending. [[User:Pfps|Pfps]] 01:28, 5 February 2008 (CET)

--

I found that I was able to speed up suspending considerably in the 2.6.23.14-107_1.cubbi_tuxonice.fc8 kernel by adding the following line to my hibernate.conf:

ProcSetting no_multithreaded_io 1

I don't know why multithreaded i/o is so much slower, but this option helped dramatically. The only other snag is that the fglrx driver causes a temporary cpu lockup of about 11s. --[[User:Noahf|noah]] 04:25, 6 February 2008 (CET)

[[Category:T60]]
[[Category:Fedora]]

User:Noahf

2008-01-11T21:13:10Z

Noahf:

[http://www.splode.com/~friedman/ Noah Friedman]

I currently own a T60p 2007-93U laptop: 15" 1600x1200 ATI V5200 FireGL display, Core2 Duo T7600 processor, and 4GB ram.

As of January 2008 I run Fedora 8 x86_64 on it.

The Intel 945PM chipset is limited such that even though I have 4GB of ram, the 64-bit kernel can still only "see" 3GB. What a waste.

User:Noahf

2008-01-11T21:09:44Z

Noahf:

Talk:Installing Fedora 8 on a ThinkPad T61p

2008-01-11T21:06:26Z

Noahf: yes, 64-bit is fine.

Can the same trick of Fedora 7 be applied to Fedora 8 regarding the alsa drivers and the sound buttons?

-- Yes of course, should be working as well. --[[User:Thhart|Thhart]] 18:42, 11 January 2008 (CET)

== 32-bit or 64-bit? ==

The T61p should work with 64-bit, right? How well does that work? --[[User:Whizkid|Whizkid]] 18:37, 28 December 2007 (CET)

-- I see no reason to do that, you only have less application support and probably other unknown problems. AFAIK it gives you no markable performance advantages. --[[User:Thhart|Thhart]] 18:42, 11 January 2008 (CET)

-- 64-bit on the T60p (with the appropriate core2 duo processor upgrade) works fine. You can still run 32-bit applications on it for those cases where there is no 64-bit version yet (e.g. Wine). No reason the 61p would be different in that regard. Whether you care about being able to run 64-bit applications at all is up to you. --[[User:noahf|noahf]] 13:03, 11 January 2008 (PST)

User:Noahf

2007-07-12T22:18:12Z

Noahf:

[http://www.splode.com/~friedman/ Noah Friedman]

User:Noahf

2007-07-12T22:15:33Z

Noahf: â†Created page with '[http://www.splode.com Noah Friedman]'

[http://www.splode.com Noah Friedman]

Problems with fglrx

2007-07-12T22:05:39Z

Noahf: report success on t60p w/ 2.6.20+suspend2 & fglrx 8.38.6

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

== Known Troubles and Solutions ==

=== X-specific issues ===

==== upgrading xserver-xorg ====
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.

==== new Xorg ID Scheme ====
ATI proprietary drivers <=8.36.5 with xorg >=7.1.0-18 (==1.3.0.0) in Debian Sid and Fedora ([http://www.sidux.com/PNphpBB2-viewtopic-t-3162-postdays-0-postorder-asc.html Debian] and [http://www.phoronix.net/forums/showthread.php?t=2382 Fedora] Forum Entries)

Ubuntu feisty made their own xorg with the standard id of 7.2, to work around this issue.

Xorg has changed its ID Scheme in newer Versions, and fglrx cannot cope with that (Error message saying "[...] X version mismatch - detected X.org 1.3.-1.905, required X.org 7.1.0.0 [...]").

A binary hack solves the Problem [http://rage3d.com/board/showthread.php?s=4638d94143536f6acacbccd8f0443472&t=33889029 (rage3d.com Forum Entry)]. This is a very '''dirty''' solution, and is probably violating the ATI driver license.

Simply using the open source ati driver (or holding back the xorg upgrades) until a new driver is released, is suggested.

As of version 8.37.6, this issue is solved. No more binary hacking needed.

=== 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:

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

try this:

:{{cmdroot|mkdir -p /usr/X11R6/lib/modules/dri}}
:{{cmdroot|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:
:{{cmduser|<nowiki>LIBGL_DEBUG=verbose</nowiki> fglrxinfo}}
:{{cmdresult|libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)}}
:{{cmdresult|libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/fglrx_dri.so}}
:{{cmdresult|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)}}
:{{cmdresult|libGL error: unable to find driver: fglrx_dri.so}}
:{{cmdresult|display: :0.0 screen: 0}}
:{{cmdresult|OpenGL vendor string: Mesa project: www.mesa3d.org}}
:{{cmdresult|OpenGL renderer string: Mesa GLX Indirect}}
:{{cmdresult|OpenGL version string: 1.2 (1.5 Mesa 6.4.2)}}

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

==== Where to look for fglrx_dri.so (gentoo and general)====
After installing a new kernel (linux-2.6.20-gentoo-r7) with gentoo I again was not able to get the ATI driver working
correctly. But now I found out what the problem was:

I tried
:{{cmduser|<nowiki>LIBGL_DEBUG=verbose</nowiki> fglrxinfo}}
:{{cmdresult|libGL: XF86DRIGetClientDriverName: 8.35.5 fglrx (screen 0)}}
:{{cmdresult|libGL: OpenDriver: trying /usr/lib32/dri/fglrx_dri.so}}
:{{cmdresult|libGL error: dlopen /usr/lib32/dri/fglrx_dri.so failed (/usr/lib32/dri/fglrx_dri.so: wrong ELF class: ELFCLASS32)}}
:{{cmdresult|libGL error: unable to find driver: fglrx_dri.so}}

The error itself makes sense, because I am running a 64-Bit linux on AMD. The question was, why libGL tries to look
in /usr/lib32 only...

After some digging around I found out, that apparently 8.35.5 version of the driver uses the environment variable
'''LIBGL_DRIVERS_PATH''' to find out where it should look for the "fglrx_dri.so" driver.

Now in my case this environment variable pointed to "/usr/lib32/dri" and that was what caused the problem.
So doing
:{{cmduser|<nowiki>export LIBGL_DRIVERS_PATH='/usr/lib64/dri:/usr/lib32/dri'</nowiki>}}
solved the problem in my case.

As mentioned I use gentoo. After some more digging around I found out, that it is apparently necessary to call
:{{cmduser|env-update}}
after a re-install of the ATI driver. To be more specific, it seems that "eselect opengl set ati" sometimes
does something wrong. "env-update" seems to repair the problem so that afterwards the '''LIBGL_DRIVERS_PATH'''
environment variable is set correctly when you log in.

If you want to check, look in <code>/etc/profile.env</code> and <code>/etc/profile.csh</code>. This is the
place where the '''LIBGL_DRIVERS_PATH''' environment variable gets set.

=== 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=====

:{{cmdroot|rm /usr/lib/libGL.so*}}
:{{cmdroot|rm /usr/X11R6/lib/libGL.so*}}
:{{cmdroot|cd /usr/X11R6/lib}}
:{{cmdroot|cp /usr/lib/fglrx/diversions/lib/libGL.so.1.2 .}}
:{{cmdroot|ln -s libGL.so.1.2 libGL.so.1}}
:{{cmdroot|ldconfig}}

=== 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
|-
|{{T43p}}||FC6||2.6.20-1.2933||8.34.8||swsusp, STR||yes||DRI enabled, occasionally fails, reason unknown.
|-
|{{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
|-
|{{T60}}||Gentoo 2006.1||2.6.19-suspend2||8.31.5||Suspend2||yes||Everything works: 3D, suspend-to-disk, suspend-to-ram, suspend in X.org, switching to VT's at any moment. Never needed to unload any modules manually, worked immediately. Fglrx driver 8.32.5 totally broke suspend for me, so i'm sticking with 8.31.5. T60 2008-B62 model.
|-
|{{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.
|-
|{{T60p}}||Debian/unstable/experimental||2.6.18||8.31.5-1 (from debian experimental)||susptoram hibernate debian packages||yes||suspend and resume works with X, 3D acc., Xv overlay...
|-
|{{T60p}}||Fedora Core 6 x86_64||2.6.20-1.2962_1.fc6.cubbi_suspend2|| 8.38.6||suspend2 hibernate||yes||suspend2 hibernate and resume working with libata driver (ahci not tested). Xv still broken since 8.35.5. Have not needed to set extra_pages_allowance thus far.
|-
|{{Z61m}}||Debian Sid||2.6.20.7||8.35.5-1||Suspend to RAM||yes||works without any problems, justs needs the usual acpi_sleep hacks
|-
|{{Z61m}}||Debian Sid||2.6.20.7||8.35.5-1||Suspend to Disk (Software Suspend)||yes||works without any problems
|-
|{{Z61m}}||Debian Sid||2.6.21||8.35.5-1||Suspend to RAM||yes||fglrx module must not be loaded into the kernel, or it won't resume
|-
|{{Z61m}}||openSUSE 10.2||2.6.21.5||8.37.6||suspend2 2.2.10||yes||/sys/power/suspend2/extra_pages_allowance must be set to 20000
|-
|{{Z61p}}||ARCH Linux||2.6.20||8.35.5-1||Suspend to RAM||yes||works with KDE suspend
|}

=== 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.

Composite support is now supported with recent Mesa and Xorg > 7 with the open source 3d radeon drivers (if you run debian unstable, you should be all set.) It works with the [[R300]] / FireGL T2 series as found on the T43p, but noticably slows down the system. This has made rapid progress in speed with the latest few releases and with kernel 2.6.21, it is finally usable with an R300 based card. Expect drivers to improve in the future, but it seems that composite does require a very fast video card and system.

===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 (/etc/gdm/gdm.conf) file add the following to the daemon-section:
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: <s>[http://bugs.gentoo.org/show_bug.cgi?id=113685 113685]</s>. Fixed in 8.25.18

===Cannot switch to VT===

With usplash boot enabled, it may not be possible to switch to a VT from X (Using Alt+Fn). Tested on T60p (Mobility Fire GLV5200) on Ubuntu 6.06 / 6.10 and fglrx 8.25.18 / 8.28.8. Display may become garbled and system might freeze. Solution (testet on Ubuntu 6.10) is to either remove the "splash" kernel boot parameter or add "vga=791" parameter ("vga=794" can be used on 1400x1050 panel).

http://ati.cchtml.com/show_bug.cgi?id=37 
https://launchpad.net/distros/ubuntu/+source/usplash/+bug/63558

===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

===WineX / Cedega Installs Software But Errors on Loading Games===

Some users may experience problems with certain FIREGL cards (in my case an ibm t43p laptop with a v3200 ati firegl) whereby projects such as cedega and wine refuse to work with 3d graphics, but native binaries (e.g. quake 4) work fine. A possible workaround is to add the following line in the drivers section of your /etc/X11/xorg.conf

Option "UseFastTLS" "2"

This option used to be configured with the older ati drivers when you ran "fglrxconfig". I have not yet found a way to get it to appear with "aticonfig", hence the manual insertion. This option is good for several linux distros I have tried, fedora core 5, ubuntu dapper and suse 10.1. It does not appear to effect performance on natively run programs.

{{NOTE|This may cause problems on machines with a Linux kernel version of 2.6.20 or higher (observed choppy video and video color inversion on T60p with both 2.6.20 and 2.6.21).}}

===Line Appears Below Mouse Cursor===

Some users have reported seeing a line approximately 1 mouse height below the bottom edge of the cursor, which follows the mouse and appears to change color based on the image below the cursor. This has been seen to happen using fglrx without the kernel module installed (in 2D mode) and additionally on external displays or multiple X servers. To work around the problem, try disabling the DGA extension by making the following changes to your XFree86.conf or xorg.conf file. Replace (or comment-out)
Load "extmod"
with
SubSection "extmod"
Option "omit xfree86-dga"
EndSubSection

===Freeze while using OpenGL Apps===

Some OpenGL applications such as screensavers or games (SecondLife) cause freezes. The cursor still moves, but otherwise the machine is unresponsive. This is the case with Xorg 7.1 and fglrx 8.29.6 using an x1400 and other cards. The solution is to add the following options to the video Device section in xorg.conf:
Option "Capabilities" "0x00000800"
Option "KernelModuleParm" "locked-userpages=0"

===Xv doesn't work correctly with drivers >= 8.36 and Xyyyy-cards===

See [http://ati.cchtml.com/show_bug.cgi?id=677] for further information. It seems as if only Xyyyy-cards are affected. Problem: graphical glitches with mplayer, programs like xine and totem might not start up at all. 8.35 doesn't seem to be affected

== Patches ==
The following patches might be needed for certain versions of fglrx. Before you apply any of these, make sure that you really need them, as some distributions include all the necessary patches with the appropriate package (e.g. ati-drivers in gentoo).

===fglrx 8.37.6===
* For kernel 2.6.22 you need this patch from a [http://www.phoronix.com/forums/showthread.php?t=2849 Phoronix thread].

===fglrx 8.35.5===
* [http://whoopie.gmxhome.de/linux/patches/2.6.20/fglrx-8.35.5-for-2.6.20.patch For kernel 2.6.20], part of the Fedora packaging scripts in the ATI installer

===fglrx 8.34.8===
* [http://whoopie.gmxhome.de/linux/patches/2.6.20/fglrx-8.34.8-for-2.6.20.patch For kernel 2.6.20]

===fglrx 8.32.5===
* [http://whoopie.gmxhome.de/linux/patches/2.6.19/fglrx-8.32.5-for-2.6.19.patch For kernel 2.6.19]

===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]

Talk:How to make use of Dynamic Frequency Scaling

2007-06-08T23:44:46Z

Noahf: /* Turn off one Core (Core Duo on T60, Debian SID) */

== CPUfreq "stuck" ==
Using the "acpi-cpufreq" and "processor" modules, I can use the performance and ondemand governor with great success on a T43, and it switches between 2.1 GHz and ~700 MHz without incident. However, sometimes the processor becomes "stuck" at ~700 MHz, and when I switch to the performance governor "cat /proc/cpuinfo" notes it is still at ~700 MHz.

I have not been able to precisely reproduce these conditions, but they have happened several times. It is cured by a reboot. I'm not running any userspace frequency governers. Anybody else experienced this peculiar behavior? [[User:gsmenden|gsmenden]] 11:20, 10 JAN 2006 (CEST)

----

I had something similar on my T43. It seems that BIOS interfers with cpufreqd's operation. In the end I set BIOS to "maximum performance" when the laptop is on AC, and let cpufreqd keep track of the speed. It seems to work for me (T43, 2669, 2.6.15-kernel)

----
Verfied for my T43. Article amended.
----
Note that this problem seems to disappear completely when using the speedstep-centrino module instead of acpi-cpufreq in a T43p. [[User:gsmenden|gsmenden]] 21:24 2 MAR 2006 (EST)

== CPU Speedstep management activation ==
I could not find the "processor" and "acpi-cpufreq" modules, thus leading to an empty /sys/devices/system/cpu/cpu0/ and preventing to set cpu throttling.
I found the speedstep-centrino module which enables the feature.
Environment : X41 (Pentium M), Debian Sid with custom 2.6.12 kernel.
Is the Debian part of the article outdated ?
Hope this helps,
Vincent

== speedstep-smi for T22 ==
I had to use the speedstep-smi driver for my T22, not the speedstep-ich driver as stated in the how-to.
Thomas
----
Yes, it was a mistake. Thanks for the note. [[User:Wyrfel|Wyrfel]] 21:49, 27 Oct 2005 (CEST)
----

== Extremely low freq on a T22 ==

About an hour ago I made Speedstep work on a T22 running Ubuntu Breezy (5.10). Before that I had the machine randomly boot at 700MHz or 900MHz. That is nothing special. But, earlier today, when I booted it, it was running at 187MHz, according to both /proc/cpuinfo and Gnome's CPU frequency applet. It also took about 4 times as long to do some CPU-intensive processing than usually (grepping and sorting a known amount of text), so I'm still thinking that my Thinkpad really was running at 187MHz until I rebooted it.

Has anyone else noticed anything like this? Is there a way to replicate this behavior? Is there a way to "enable" this "step"?

-- _sd
----
Yes, i brought my X20 down to similarly low frequencies also with Ubuntu. I think it's possible through ACPI throttling, but I'm not sure if that was actually how i did it.

[[User:Wyrfel|Wyrfel]] 23:51, 9 Jan 2006 (CET)
----
This is a BIOS problem. Disable any Powermanagment in BIOS, else it will boot with lower frequencies if your on battery or any other reason if didnt figure out.
ACPI-Throttling does not change the frequency (read mhz) but something else.
echo 4:0 >/proc/acpi/processor/CPU/throttling
This will not change the mhz but will make it slower. I didnt understand how to make any use of it as it does not give more battery.

[[User:nusse|nusse]] Tue Mar 21 06:26:31 CET 2006

== Obsolete daemons ==
Removed the note about daemons being obsolete. Using ondemand/conservate is *not* a replacement for daemons, they are generally smarter than a fixed governor and can adapt to different situations better.
----
I reinserted the note, but changed it a little. The point about that note is that most users get good results and less confusion with those two governors. Feel free to extend the section by some remarks about why one might want to use a deamon instead.

[[User:Wyrfel|Wyrfel]] 10:40, 16 January 2006 (CET)
----
Elaborated a bit on it.

--[[User:Earthwings|Earthwings]] 23:15, 17 January 2006 (CET)
----
Thx, reads good.

[[User:Wyrfel|Wyrfel]] 23:25, 17 January 2006 (CET)
----

== Throttling useless? ==

I just removed the following comment:

:==A note about CPU throttling==
:On a modern CPU, throttling is useless, even it can increase power consumption instead of decreasing it. By forcing the CPU to sleep using throttling the CPU will reach a state higher as C2 less often. On a T43 it is a difference of more then 100mW.

I don't know what counts as a "modern CPU" but my desktop Athlon 64 3000+ 768 and my laptop 1.1GHz Pentium M both run *much* cooler at low frequencies than at high frequencies; it is just indisputable that they are using considerably less energy when throttled than before. So I think the above statement needs to be at the very least clarified before it goes into the main article. [[User:Ciphergoth|Ciphergoth]] 11:06, 20 June 2006 (CEST)

----

You seem to be very confused about this issue. CPU throttling does '''not''' change the clock, as it has nothing to do with clock speed. I will readd the comment, with some extra explanations to avoid the confusion. Downclocking a CPU will '''definately''' cause it to consume less power, that's the whole point of the governors.

--[[User:Hmh|hmh]] 03:48, 27 October 2006 (CEST)

== Turn off one Core (Core Duo on T60, Debian SID) ==

Is it possible to disable one core of the dual core processor? --[[User:Matsch|Matsch]] 23:36, 18 January 2007 (CET)

Yes. If you have CONFIG_HOTPLUG_CPU=y, CONFIG_HOTPLUG=y, CONFIG_ACPI_HOTPLUG_CPU=y in kernel config. You can disable the second CPU with this command: echo 0 > /sys/devices/system/cpu/cpu1/online and enable it with echo 1 > /sys/devices/system/cpu/cpu1/online.

What the above commentator said is correct. However when I played with this on my T60p w/ T7600 core2 duo, both core thermal sensors reported an increase in temperature even with the machine idle. Re-enabling the second core eventually reduced the overall temperature of the processor. I didn't measure to see if there was any decrease in watts consumed.

Problem with e1000: Open issue with latency

2007-03-30T22:37:23Z

Noahf: links to bios update 2.11, which fixes latency problem

This issue has been observed with the 2.6.17 linux kernel and the e1000 on the T60 and t60p. The bug is being tracked [http://bugme.osdl.org/show_bug.cgi?id=6929 here]

The recommended fix is to load the e1000 driver with an RxIntDelay of 8 or 32, to ensure success, you should also reload the driver by removing it before inserting it:

<tt>modprobe -r e1000</tt>

<tt>modprobe e1000 RxIntDelay=32</tt>

This fix is recommended by Intel developers, and has been shown to work at least anecdotally by the author of this page. 32 seems to work better than 8, again, anecdotally.

Alternatively, [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-63027 BIOS update 2.11] is reported to fix the problem so that setting RxIntDelay is not necessary.

===What is RxIntDelay?===
From the [http://www.intel.com/support/network/sb/cs-009209.htm Intel site]:

''This value delays the generation of receive interrupts in units of 1.024 microseconds. Receive interrupt reduction can improve CPU efficiency if properly tuned for specific network traffic. Increasing this value adds extra latency to frame reception and can end up decreasing the throughput of TCP traffic. If the system is reporting dropped receives, this value may be set too high, causing the driver to run out of available receive descriptors.''

''CAUTION: When setting RxIntDelay to a value other than 0, adapters may hang (stop transmitting) under certain network conditions. If this occurs a NETDEV WATCHDOG message is logged in the system event log. In addition, the controller is automatically reset, restoring the network connection. To eliminate the potential for the hang ensure that RxIntDelay is set to zero.''