A prodigal son has returned (a spare X61 loaned to sister)

[axur-delmeria]

My youngest sister upgraded to an X220 recently, and because of that the X61 she used before was returned to me. It had a backlight issue, which was solved by transplanting a spare lid assembly (salvaged from my cousin's dead X60).

I put in a spare 1TB HDD (it was retired by my brother due to a squeaking noise he believes to be a sign of impending failure), and amusingly enough, I chose to install Release Candidate 1 of Debian 10 (Buster).

Installation took more than an hour, but finished before the 8-cell battery ran out.

What surprised me the most is that the video playback performance actually improved compared to the last time I ran Debian on an X61 (probably early to mid 2015, running Debian 7 or 8 ).
I played my usual list of video files, checked for dropped frames and saw none; mpv (my video player program of choice) reported zero dropped frames as well.
I did encounter some tearing on some of my newer video files, but I suspect that it's caused by trying to play a 60fps video on a screen with only 50Hz refresh rate.

I'm sure the improvement lies somewhere in the video rendering stage, but I don't know whether it's the application software (mpv), Mesa (OpenGL), or the i915 kernel module. Most likely it's a combination of the three. On Debian 7, I had to use the GMA X3100's hardware overlay for best performance, but now it runs well (heck, even better) out of the box (mpv defaults to OpenGL).

Can I expect similarly welcome surprises if I installed the current Windows on this machine? Heck no.
This is another reason why I love Linux.

I still have lots to do to reach full operational capability. CPU undervolting (necessary), TLP tuning, printer and scanner setup, etc. Will also check that backlight issue, maybe replace the inverter.

Oh, and change my signature at the bottom once it's all done.

[axur-delmeria]

I've just completed undervolting the X61. I'm going to explain my CPU undervolting (and testing) method, and splitting it into parts because I realize it would be too long for a singe post.

It can be described as a "bottom-up" approach, as it begins at the second-to-the-lowest clock speed rather than the fastest.
This is in consideration of the X series' weak cooling system (compared to the T series)-- by starting slow, overheating will not be an issue during the stress-testing step, at least until the clock speed exceeds 1.6GHz. With the fear of overheating absent, stress-testing can be done as long as necessary, ensuring stability.

PHASE I: compiling the phc-intel kernel module

Note: This assumes that the running system is Debian. The instructions may work with derivatives like Ubuntu with a little modification.

1. Install the packages that will be required to compile the kernel module. In Debian (also applies to derivatives like Debian and Mint), I've installed dkms, build-essentials, and debhelper.

2. Go to http://www.linux-phc.org/forum/viewtopic.php?f=7&t=267 and download the phc-intel-pack-rev##.tar.bz2 archive, then unpack/extract the archive to a directory of your choice. Open a terminal window on that directory.

3. Following the instructions on the readme.1st file, run the following command:

Code: Select all

make dkms_mkdeb

If the prerequisite packages are installed, you should not expect any issues. The end result will be a DEB package named "phc-intel-dkms_0.3.2_amd64.deb" if the installed Linux is 64-bit. If it's 32-bit, the package will be named "phc-intel-dkms_0.3.2_i386.deb".

4. Install the package. First, elevate the terminal window that's currently open by running

Code: Select all

su

then entering the root password. Then, install the package using the dpkg command:

Code: Select all

dpkg -i phc-intel-dkms_0.3.2_amd64.deb

Replace the package name when running 32-bit Linux.

"su" may not work in Ubuntu and other distributions with a different configuration. In this case, perhaps using sudo will work:

Code: Select all

sudo dpkg -i phc-intel-dkms_0.3.2_amd64.deb

The package should install without issue.

5. Restart the computer. The phc-intel module blacklists the existing acpi-cpufreq module. The best way to ensure that this happens is to reboot.

6. Once the system has finished rebooting, check if the phc-intel module has been loaded. Open a terminal window, then run

Code: Select all

lsmod | grep -i "phc"

The output of the command should look like

Code: Select all

phc_intel              28672  1

If the output is blank, this means that the phc_intel kernel module has not been loaded. You can try to manually load it by elevating the terminal window to root, then running

Code: Select all

modprobe phc_intel

Another way to test is by running

Code: Select all

ls /sys/devices/system/cpu//sys/devices/system/cpu/cpu*/cpufreq/phc*

The output should be like:

Code: Select all

/sys/devices/system/cpu/cpu0/cpufreq/phc_controls
/sys/devices/system/cpu/cpu0/cpufreq/phc_default_controls
/sys/devices/system/cpu/cpu0/cpufreq/phc_default_vids
/sys/devices/system/cpu/cpu0/cpufreq/phc_fids
/sys/devices/system/cpu/cpu0/cpufreq/phc_version
/sys/devices/system/cpu/cpu0/cpufreq/phc_vids
/sys/devices/system/cpu/cpu1/cpufreq/phc_controls
/sys/devices/system/cpu/cpu1/cpufreq/phc_default_controls
/sys/devices/system/cpu/cpu1/cpufreq/phc_default_vids
/sys/devices/system/cpu/cpu1/cpufreq/phc_fids
/sys/devices/system/cpu/cpu1/cpufreq/phc_version
/sys/devices/system/cpu/cpu1/cpufreq/phc_vids

These entries are the controls that PHC provides to undervolt the CPU. Once these are available, we can now proceed with Undervolting the CPU. Note the separate controls for cpu0 and cpu1: for a single-core CPU, only cpu0 exists; for quad cores, it's from cpu0 to cpu3.

Next time, I'll try to explain the PHC controls and hopefully get into actual undervolting.

[axur-delmeria]

PHASE II: Undervolting and Stress-testing for stability

Undervolting is a very repetitive activity, as every drop in voltage requires stress-testing to ensure its stability. There are some shortcuts though: my prior experience with undervolting has resulted in some insight with regards to how low a CPU can be safely undervolted at a given clock speed.

But first, let's take a look at the PHC controls and what the numbers mean

On a terminal window, type:

Code: Select all

cat /sys/devices/system/cpu/cpu*/cpufreq/phc_default_controls

The output on my X61 with T8100 is:

Code: Select all

75:41 74:34 8:28 6:23 136:17
75:41 74:34 8:28 6:23 136:17

It's a sequence of pairs of numbers. Each pair represents a Frequency ID (FID) and a Voltage ID (VID).

The FIDs correspond to the frequencies found in /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies, so run

Code: Select all

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies

to show those frequencies. In my X61, this outputs:

Code: Select all

2101000 2100000 1600000 1200000 800000 
2101000 2100000 1600000 1200000 800000 

To be honest, the FIDs aren't that important, as the clock speed will be controlled by manipulating /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq.

As for the voltage IDs, there's another set of controls for it.

/sys/devices/system/cpu/cpu0/cpufreq/phc_default_vids contains the default VIDs for cpu0. It can be read by the cat command:

Code: Select all

cat /sys/devices/system/cpu/cpu0/cpufreq/phc_default_vids

Output in my X61:

Code: Select all

41 34 28 23 17

As can be seen, these are the same numbers in the VID part (the number after the colon) of phc_default_controls.

75:41 74:34 8:28 6:23 136:17

/sys/devices/system/cpu/cpu0/cpufreq/phc_vids shows the current VIDs for cpu0, and can be edited to control the voltages. This can be done by an echo command to phc_vids/i]:

The following code is an example, do not run it!!

Code: Select all

echo 40 33 27 22 17 > /sys/devices/system/cpu/cpu0/cpufreq/phc_vids

Note that this only changes the VIDs in cpu0. In practice, voltage controls for all cores are changed at the same time, which can be done using a for loop.

Again, the following code is an example, do not run it!!

Code: Select all

for i in 0 1 ; do echo 40 33 27 22 17 > /sys/devices/system/cpu/cpu$i/cpufreq/phc_vids; done

Now, new voltages can be entered, but the CPU won't necessarily adhere to it. Another program is needed to read the CPU's registers to check its status: read_msr, which can be found here: http://www.linux-phc.org/forum/viewtopic.php?f=13&t=13

Download read_msr_0.2pre3.tar.bz2, unpack it to a directory of your choice, open a terminal window to said directory, then run:

Code: Select all

chmod +x read_msr.py

in order to make it executable. This program requires root privileges, so su or sudo is required.

To check the FID/VID status, run:

Code: Select all

./read_msr.py --readmsr

Sample output from my X61:

Code: Select all

MSRTOOL V0.2pre-3 started...

[cpu1] [CURRENT] FID:8 HID:0 DID:0 VID:17 
[cpu1] [TARGET]  FID:8 HID:1 DID:0 VID:17 
[cpu1] [HIGHEST] FID:10 (HID:0 DID:1) VID:34 (not sure if they exist here)
[cpu1] [LOWEST]  FID:6 (HID:0 DID:0) VID:23 (not sure if they exist here)
[cpu1] [SLFM]    FID:8 VID:17 
[cpu1] [IDA]     FID:11 VID:41 
[cpu1] [CURRENTLY ACTIVE FEATURES] IDA:0 EIST:1

[cpu0] [CURRENT] FID:8 HID:0 DID:0 VID:17 
[cpu0] [TARGET]  FID:8 HID:0 DID:0 VID:17 
[cpu0] [HIGHEST] FID:11 (HID:0 DID:1) VID:41 (not sure if they exist here)
[cpu0] [LOWEST]  FID:6 (HID:0 DID:0) VID:23 (not sure if they exist here)
[cpu0] [SLFM]    FID:8 VID:17 
[cpu0] [IDA]     FID:11 VID:41 
[cpu0] [CURRENTLY ACTIVE FEATURES] IDA:0 EIST:1

Concentrate on the [CURRENT] and [TARGET] lines. In the course of my experiments, I tried to set the VID to 0, and it appeared in the [TARGET] field, but the [CURRENT] showed a different value. Usually, it can only go as low as the VID in the lowest clock speed, which means it cannot be undervolted any further. This is the reason why my method begins at the second lowest frequency.

Next is the final piece of software needed: the stress tester.

I use mprime, which can be found here: https://www.mersenne.org/download/
Grab the 64-bit if you're running 64-bit Linux, 32-bit otherwise.
Unpack the archive to a directory of your choice, then open a terminal window on said directory.

Now, let's get on with the actual undervolting!!!

First off, we need the following windows open:
1. root terminal window on read_msr.py's directory (if you didn't close it) [henceforth Terminal1)
2. terminal window for mprime (we just did that) (henceforth Terminal2)
3. hardware monitor software to keep track of temperatures (I use psensor)
4. (optional) another root terminal window for clock/voltage control. Doing so compartmentalizes the controls, allowing a clearer view of the current status at any given time. (henceforth Terminal3)

As I've mentioned earlier, the undervolting and stress-testing part is repetitive and time consuming. Set aside an entire afternoon for this.

Another thing: get a pen and paper and write down the default VIDs in a single row. Then as the undervolting proceeds, jot down the VIDs tested for the current clock speed in a column below the default VID. At the start, it will look like:

Code: Select all

41 34 28 23 17 
         20
         19
         18         

As the undervolting reaches the higher clocks, it will look more like:

Code: Select all

41 34 28 23 17 
37 30 26 20
34 28 24 19
31 26 22 18         
29 25 21
27    19

Now we're ready.

1. Check the available clock speed. Do this on either Terminal1 or Terminal3:

Code: Select all

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies

Select the second to the last frequency, then set it as the maximum frequency:

Code: Select all

[code]for i in 0 1 ; do echo (put frequency here and remove the parentheses) > /sys/devices/system/cpu/cpu$i/cpufreq/scaling_max_freq; done

Get the current VIDs

Code: Select all

cat /sys/devices/system/cpu/cpu0/cpufreq/phc_vids

Example from my X61:

Code: Select all

41 34 28 23 17

2. Now, to undervolt, chose a VID slightly lower than the current one. Since we're starting at the second-lowest frequency, this corresponds to the second to the right VID. But how low can we go? Can shortcuts be done? My experience says yes(!!)

Penryn CPUs (X61 with T8xxx or T9xxx CPUs) are quite frugal with voltages. In my experience, they can use the lowest VID (the rightmost one) up to 1.6GHz. After that it's a +2 or +3 VIDs for every succeeding clock speed.

Merom CPUs (X60/X61 with T5xxx or T7xxx CPUs) aren't as frugal. and I started with subtracting 3 from the default VID as a starting point, 2 for the next, then 1 per round until the stress-test fails. When it fails, I add 2 to the VID and stress-test again. Once I'm satisfied, I move on to the next clock speed and repeat the cycle again.

Now, back to undervolting...

Change only the second-to-the-last VID as it corresponds to the second-to-the-slowest clock speed, which we're testing at this stage:

Going back to my example from my X61:

Code: Select all

41 34 28 23 17

We change it to

Code: Select all

41 34 28 20 17

Then feed the entire line to the command below:

Code: Select all

for i in 0 1 ; do echo (put VID list here minus the parentheses) > /sys/devices/system/cpu/cpu$i/cpufreq/phc_vids

3. On Terminal 2, start mprime:

Code: Select all

./mprime

On first run, it will ask to join Gimps. Answer N because we're just stress-testing.
Next it asks for the number of torture test threads to run. It auto-detects the number of CPU cores so just press Enter.
Next it asks for the type of torture test to run. Select #1. and press Enter.
Next it asks whether to customize settings, answer N. It also asks to run weaker torture tests, answer N.
Finally it asks to accept all the above answers, answer Y.
Then it starts stress-testing.

While testing, go to Terminal1 and check the VIDs with

Code: Select all

./read_msr.py  --readmsr

The [CURRENT] and [TARGET] lines must be the same, especially the FIDs and VIDs. This means that the CPU is running at the specified clock speed and using the intended voltage.

Keep the stress-test going for at least 30 minutes--for the lower speeds I even test up to an hour; because of the low clock speed, the temperature shouldn't get high enough to be cause worry. If the CPU temp exceeds 70c at low clock speeds, then the heatsink may need cleaning and repasting.

If the stress-test shows no error after 30 minutes-1 hour, it's time to stop the stress-test.
Go to Terminal2 then press Ctrl-C. mprime will then show this menu:

Code: Select all

Hit enter to continue: 
	     Main Menu

	 1.  Test/Primenet
	 2.  Test/Worker threads
	 3.  Test/Status
	 4.  Test/Continue
	 5.  Test/Exit
	 6.  Advanced/Test
	 7.  Advanced/Time
	 8.  Advanced/P-1
	 9.  Advanced/ECM
	10.  Advanced/Manual Communication
	11.  Advanced/Unreserve Exponent
	12.  Advanced/Quit Gimps
	13.  Options/CPU
	14.  Options/Preferences
	15.  Options/Torture Test
	16.  Options/Benchmark
	17.  Help/About
	18.  Help/About PrimeNet Server
Your choice: 

Leave it as it is for now.

5. Now the VID can be lowered again. Go back to Terminal1, and lower the VID again as described in Step 2.

6. To restart the stress-test, go back to Terminal2, Type 15, then press Enter. Again, it will ask the same questions starting from the number of torture test threads to use. While stress-testing, run

Code: Select all

./read_msr.py  --readmsr

again to verify that the new VID is accepted. Don't forget to jot down the VIDs on that piece of paper.

NOTE
When the undervolt is unstable, there will be symptoms aside from mprime spitting out an error. Crashes, hangs, and even sudden restarts can be experienced. That's why it's best to undervolt on a system without any important data in it, as a sudden restart may cause data corruption on the hard drive.

7. At this point, that's pretty much it. Once the lowest stable voltage is found, we can opt to add 1 or 2 to that as a safety basket, then move on to the next frequency. As we go up the frequency ladder, the system temperature will also increase. If it reaches 90c at any point, cancel the stress-test. The heatsink may need cleaning and repasting, or do the test in a colder room.

IMPORTANT NOTE
On CPUs with the odd max frequency like 2101000, 2501000-- in other words, those that end in 1000, it's a difficult to trully test the stability at that frequency. It's actually the IDA (Intel Dynamic Acceleration), which is a crude version of the Turbo Boost available in the mobile Core i5/i7 CPUs. It's crude because it only activates when one core is busy and the other one is idle. Because of this, it's hard to force it to activate while running a stress-test without jumping through a few hoops.

Said hoops mean installing the msrtool package, then creating a script file:

Code: Select all

#!/bin/bash
# Enable-IDA
# YMMV
# disable EIST
# https://askubuntu.com/questions/619875/disabling-intel-turbo-boost-in-ubuntu
wrmsr -p0 0x1a0 0x4000850089
wrmsr -p1 0x1a0 0x4000850089
# enable Dual-IDA
# http://forum.notebookreview.com/threads/how-to-enable-intel-dynamic-acceleration-ida-on-both-cores-of-a-core-2-duo.477704/page-48
wrmsr 0x1a0 0x1364862489
echo 0 > /sys/devices/system/cpu/cpu1/online
rdmsr -p0 0x198
wrmsr 0x199 0xa24
wrmsr 0x1a0 0x5364872489
wrmsr 0x1a0 0x1364862489
rdmsr -p0 0x198
echo 1 > /sys/devices/system/cpu/cpu1/online
rdmsr -p0 0x198
rdmsr -p1 0x198

Open a text editor, copy-paste the code above, then save it as "dual-ida-enable.sh" to a directory of your choice, preferably the same one with read_msr.

Like with read_msr, make it executable with:

Code: Select all

 chmod +x dual-ida-enable.sh

And like read_msr, this requires root privileges to run.

This code effectively disables all the other clock speeds and locks it to the IDA clock. The only way I know to revert this is to reboot the machine.

Check the VIDs, edit the leftmost one, then start stress-testing while checking with read_msr to see if the undervolt was accepted.
Monitor the temperature as well, as it's definitely going to be hot!!

Happy undervolting!!

[axur-delmeria]

Further Debian Buster (RC1) adventures on the prodigal son: Trackpoint settings and udev

Udev rules syntax seems to have changed since Debian Stretch.

My old /etc/udev/rules.d/10-trackpoint.rules file doesn't work anymore:

Code: Select all

ACTION="add" SUBSYSTEM=="input", ATTR{name}=="*TrackPoint*", ATTR{device/sensitivity}="240" ATTR{device/speed}="225"

Checking https://www.thinkwiki.org/wiki/How_to_c ... TrackPoint, there seems to be a slightly different format starting from Ubuntu 16.04, so I modify the old code to

Code: Select all

SUBSYSTEM=="input", ATTR{name}=="*TrackPoint*", ATTR{device/sensitivity}:="240" ATTR{device/speed}:="225"

Turns out these settings are too high for this particular unit, so I dial down the numbers

Code: Select all

SUBSYSTEM=="input", ATTR{name}=="*TrackPoint*", ATTR{device/sensitivity}:="160" ATTR{device/speed}:="192"

[axur-delmeria]

I transplanted the LCD panel from the X60F (AKA "Toy") into the prodigal son, as its current screen (LTN121XJ-L02 scavenged from a Dell laptop, then used in my cousin's now-dead X60) was quite dim, had pressure marks and atrocious viewing angles. Now it's staring to look like something I can proudly call a backup machine.

While it was disassembled, I took the opportunity to install the 42X3805 heatsink (single large heatpipe) and apply some Themal Grizzly Kryonaut (arrived today).

I haven't tried stress-testing it yet-- one guide I read recently recommends idle/light usage for the first 30 minutes after a repaste, rather than immediately stress-testing the laptop.