This howto collects some information on the install process of certain Hardware features which is spread about various places. With that tutorial, I hope to make the installation of Gentoo Linux on a Lenovo Thinkpad T61 easier and faster for other users.

I used the amd64 minimal cd to install gentoo on my t61. I found, that it is possible to use

For the T61 I would recommend an amd64 install, because the use of 64 bit makes large computations (in numerical simulations as well as in 3D-engines for games) considerably faster. At the day of this writing, there exists java support for current amd 64 browsers via icedtea. Furthermore, Flashplayer works on 64 bit, and the most audio codecs are natively supported by mplayer (therefore, one does not need a win32-codec package). For the pdf viewer acrobat reader, there exist also various open source programs which are almost equivalent, see http://en.wikipedia.org/wiki/List_of_PDF_software . Therefore, the almost only remaining reason to install a multilib system would be a frequent usage of 32 bit windows software with wine. Since i do not use wine, I installed a no-multilib system.

For my system, I set ~amd64 instead of amd64 because the gcc in in ~amd64 has support for the processor of the T61. Unfortunately, the changes in this new gcc also require to install many ~amd64 packages, since the old ones in amd64 would not compile with the new gcc. The packages in ~amd64 very often depend on libraries which are also in ~amd64. Hence, I did go to ~amd64 in order to avoid a dependeny hell. I personally simply did not like to manually adjust the keywords file at almost each install of a new package. With ~amd64 everything went fine. I have not any seen problems so far, and my mask and unmask files are kept at a minimal length.

In the following, I will describe, how various hardware features of the T61 Laptop can be installed within a gentoo Linux system:

general power management:
a general power management guide for gentoo can be found here:
http://www.gentoo.org/doc/en/power-management-guide.xml
I like the laptop-mode package a lot. When configuring it, look not only at /etc/laptop-mode.conf but also at the files in the directory /etc/laptop-mode/conf.d/ . Unfortunately, with recent Kernels, Laptop-mode and also other tools like acpitool are unable to set the brightness of the LCD-display because /proc/acpi/ibm/brightness is not there anymore and the display is controlled by the acpi video driver instead.
Suspend to ram and Suspend to Disk:
I have an nvidia card. For this card, there exist proprietary linux drivers. They work fine, although they have a little bit problems when the computer is resuming from an acpi suspend-mode. I used the tuxonice-sources as a kernel in addition with hibernate-script. A general introduction can be found here: http://www.gentoo.org/doc/en/power-management-guide.xml#doc_chap7

Suspend to ram works out of the box. At least when I execute the hibernate-ram command of hibernate-script. However, When I want to go into ram hibernation from kde4.2's powerdevil, I see two batteries in the applet after the computer has been waken up.

To make the kernel find this device, one must add the path of the suspend device as kernel option, e.g. via

Code:

resume=/dev/sda2

in the config file of the bootloader, which is in my case /boot/grub/grub.conf . Furthermore, the kernel is only able to find the image if the necessary sata drivers are directly compiled into the kernel (y or *) and not as loadable modules. Additionally, the path of the tuxonice_ui program, which is in my case /usr/sbin/tuxoniceui_text , should be set during the configuration of the kernel. The corresponding entry can be in menuconfig under

Code:

Power management and ACPI options->Enhanced Hibernation (TuxOnIce)->Default userui program location

Unfortunately, the CPU monitor applet of KDE4.2 looks somewhat defect after I wake up from a suspend to disk. It seems that even if I wake up with almost no programs running, the cpu monitor shows the two cores of my Laptop with completely constant load. This is strange since normaly, the activity of my cpus decreases and increases continually, but it is never, say, constantly at 50% for all the time when almost no programs are running...

Due to the aforementioned bugs, I do not use the hibernate acpi states very often.

Disk shock protection:
At first, configure the INPUT_UINPUT kernel-option, which can be found in menuconfig under

Compile this option in the Kernel (* or y). Then, de-activate the in-kernel hdaps driver (i.e. the options CONFIG_SENSORS_HDAPS) completely (that means: Do not compile this driver as a module or even in kernel) since it needs more power than the driver we will install in the following. The in-kernel hdaps driver that we have to deactivate can be found in menuconfig under

(However, if you are already there, you might activate the Intel Core (2) Duo/Solo temperature sensor option CONFIG_SENSORS_CORETEMP in the Hardware Monitoring support section. The temperature sensor can be used with the ACPI fan to adapt its speed automatically to the temperature of the CPUs).

in hdapsd.init out by adding a # before them. These lines are neither valid nor needed for 2.6.28 kernels, and they would prevent a working hdaps daemon to run. After hdapsd is emerged, add it to the default runlevel.

This should make disk-shock protection working. To make the hdaps data readable for other programms, open a console and type the commands

To disable Bluetooth at startup, it unfortunately won't even suffice to remove all Bluetooth support from the Kernel. The hardware would still enable the radio device. Hence, one must explicitely tell the Kernel to disable bluetooth at boot via the rf-kill interface. To do this, one has to insert the following Kernel boot-parameter in the config of the bootloader, which is in my case /boot/grub/grub.conf:

Code:

rfkill.default_state=0

Now, Bluetooth can still be activated and disabled via the above script, but it is not activated at boot.

Network:
I personally like a similar solution for ordinary lan. In a laptop, i do not want that the network gets started every time when my computer boots. Therefore, I wrote a customized script that configures my eth0 and sets it up when I need it. However, to prevent eth0 to get started at boot, one must insert the line

Code:

config_eth0=( "null" )

in /etc/conf.d/net . The T61 Laptop must have the intel e1000e driver installed. During configuration of the kernel, this module can be included with the options CONFIG_NETDEVICES, CONFIG_NETDEV_1000 and CONFIG_E1000E, which can be found in menuconfig under

Wireless Lan
My T61 uses the iwl4965 drivers (however, it seems that some T61 make use of the iwl3945 drivers. Maybe someone else provides an installation howto for them). One can use the corresponding IWLAGN and IWL4965 drivers in the kernel. They can be found in menuconfig under

More recent drivers (in case one observes some bugs of the in kernel drivers, which must be be reportet here: http://www.intellinuxwireless.org/bugzilla/ ) can be installed with the compat-wireless package. Unfortunately, compat-wireless seems to have no ebuild. Therefore, one must compile it by oneself. The source of compat-wireless can be found at http://linuxwireless.org/en/users/Download . The module of the wireless card also needs a firmware that is in portage under net-wireless/iwl4965-ucode . After this firmware is installed, the wireless lan driver can be loaded with

Think light
Works without any installation. Simply press Fn+page_up to switch the light on and of

Trackball
Works without any installation in xorg.

Firewire
I have not tested it, but it should work without problems.

SD Card-reader:
I have not tested it. However, on a 2.6.28 Kernel, it seems that one needs to activate the Kernel modules MMC,MMC_SDHCI,MMC_SDHCI_PCI and MMC_RICOH_MMC, which can be found in menuconfig under

The in-kernel documentation says, that especially the last option must be enabled because linux wants the SDHCI driver to control the MMC device, and not a proprietary Ricoh controller which would block the memory device for linux. The tutorial at http://www.thinkwiki.org/wiki/How_to_get_the_internal_SD_card_working reports that after these drivers were compiled in the Kernel, one should be able to mount an sd card with

Code:

mount /dev/mmcblk0p1 /mnt

Other things that I've not tested are:
Embedded security system: http://www.thinkwiki.org/wiki/Embedded_Security_Subsystem (the wiki says that there are already linux drivers for that. Has someone tried this out?)
Intel active Management Technology: [url]http://www.thinkwiki.org/wiki/Intel_Active_Management_Technology_(AMT)[/url]
Full Disk encryption: [url]http://www.thinkwiki.org/wiki/Full_Disk_Encryption_(FDE)[/url]

Last edited by Benni123 on Fri Apr 10, 2009 7:02 am; edited 16 times in total

Also, I understand that hdapsd is no longer necessary starting with kernel 2.6.28 -- just enable HDAPS in the kernel config.

Wrong. Although it is correct that the Kernel provides an own hdaps driver, this driver unfortunately uses the sysfs interface and therefore it needs more power than the hdaps driver from tp_smapi.

Furthermore, hdapsd is the daemon that needs, in any case, to be installed to run the hdaps drivers. What is not needed anymore is an addidtional kernel patch because this "bulk freeze patch" was imported into the kernel. In short: Just activating hdaps in the kernel configuration won't do anything. If you then run the hdapsd daemon with the hdaps driver from Kernel, you will have a disk protection that needs more power.

Quote:

You should write this up for gentoo wiki

Gentoo wiki? I noticed it was down for a long time. Were the original articles restored?

Quote:

This probably also deserves a link from thinkwiki.org.

I've already set a link there.

Quote:

My T61 uses the IWL3945 driver

OK. I'll edit this in my original post.

Last edited by Benni123 on Thu Mar 19, 2009 4:22 pm; edited 2 times in total

It's good to hear that these wlan drivers can now be used in daily operation. A few months ago, they were so buggy that they did not even modprobe correctly. Seemingly the developers were somewhat surprised by some kernel changes and had to change much of the code. Since this may happen again with future kernel versions, I did set a link to the compat-wireless page. The most recent drivers can be downloaded there (unfortunately, gentoo does not seem to provide an ebuild for compat-wireless yet). However, when one looks at the changelog, I wonder why the devs still fix dozends of bugs in these wlan drivers: http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=shortlog I must say that I've seen drivers which are much more stable...

Quote:

- should have read thinkwiki, it's pretty clear there.

The last time i looked there, i found it somewhat outdated and confusing. In fact, the pages there and the necissity to look on howtos at various places were the reason for me to collect the material of this post together here.

I am running a stable amd64 system (only ~amd64 for xorg). This includes tuxonice-sources-2.6.24. The iwl3945 driver in there works fine; the only thing that doesn't work is the wlan status light, which I don't mind. (This was corrected in 2.6.26.)

For me, the driver iwl4965 did not modprobe with the kernel versions of last summer. I think i remember that this were 2.6.26 Kernels, but I'm not sure.

On 2.6.28 and even before that with 2.6.27 kernels, the in-Kernel wlan drivers run pretty much stable for me!

This being said, one must be aware that many wlan-driver bugs do not get noticed by an average user. For example if a wlan connection runs slow under certain circumstances, the average user might blame the internet server that he connects to, and not his own wlan driver.

On my system, there did not occur any problems so far. I went to ~amd64 for the following reasons:

For example, especially on the T61 Laptop, I prefer the keyword masked gcc-4.3.3-r2, since it has a "march=native" option, with optimisations for the core2 processor of the T61. If one uses that gcc, one also has to install many ~amd64 packages because the new gcc introduced changes which would make the compilation of the amd64 versions of some packages impossible. Furthermore, I want to use the newest tuxonice-kernels which are also masked by keyword...

A masked package may introduce dependencies which are also masked. Hence, I found my package.keywords file to grow larger and larger. And there came other complications: Applications from amd64 may sometimes be updated to a newer version. However, they are then likely to need libraries which are also from amd64. These libraries would often conflict with the dependencies of the manually unmasked applications from ~amd64. In fact, I found myself in a dependency hell.

With the new install, I decided to go on ~amd64. I have encountered no problems so far. I'm using kde4 here and everything works smoothly.

I haven't gone with the full ~amd64, mainly because I didn't feel like fighting battles with openrc and baselayout2. I do have it set for bunch of stuff including gentoo-sources, gcc, Xorg, and kde4.
--
doc

Server crashed and guy who ran it migrated to Media Wiki, there is work in progress to migrate the old articles over updating them as each is done._________________"Science is what we understand well enough to explain to a computer. Art is everything else we do." - Donald Knuth

This rule is only triggered when the module is loaded, so the module must be loaded before hdapsd is started or it will complain:

Code:

* Service hdapsd starting
Fri Apr 10 13:50:59 2009: WARNING: Cannot open hdaps position input file /dev/input/hdaps/accelerometer-event (No such file or directory). You may be using an incompatible version of the hdaps module, or missing the required udev rule.
Falling back to reading the position from sysfs (uses more power).
Use '-y' to silence this warning.
* Service hdapsd started

If the module 'hdaps' is not autoloaded on boot (I haven't checked to see), then it will have to be added to '/etc/modules.autoload.d/kernel-2.6'._________________Personal overlay | Simple backup scheme

I was confused and uncertain initially whether hdapsd was functioning or not since no logs are created when it parks/unparks the disc (earlier it used to output to dmesg). If you instead run hdapsd without backgrounding it, then you can see the park/unpark outputs._________________emerge --quiet redefined | E17 vids: I, II | Now using e from git | e18, e19, and kde4 sucks :-/

* 'hdaps-gl' just tells you that the accelerometer and the input device interface are working.

* watching the sysfs device tells you when the heads actually get parked.

There are a number of other visualization tools floating around, but I don't know if any actually tell you when the heads get parked. I doubt it, since watching the sysfs device uses up CPU cycles/battery power, and I don't think hdapsd has an interface (e.g., a socket) for publishing its actions._________________Personal overlay | Simple backup scheme