Because, even with Q-Fan enabled for the chassis fans and put on “silent” in the BIOS, they’re pretty loud, especially if like me you’re still using a mix of 80, 92 and 120 mm fans.

This guide has been written on Linux Mint 20, and is specifically for the Asus P6T Deluxe V2 motherboard. I hope the revision doesn’t matter. In case it does, I’m sorry: you’re out of luck.
Information here could apply to other Asus motherboards, but I’ve still not done other tests.

Of course, the obvious disclaimer: the following procedure is provided as-is.
My computer is still up and running (quieter than before), but if your CPU fan stops spinning, your computer catches fire, there is some fuel around it, and it starts a chain of event that leads to the core of the nearest nuclear power plant melting down, I’ll have nothing to do about it.

Ok, so, first thing firsts: the ASUS P6T Deluxe V2 is a twelve years old motherboard but because it can use cheap 6-core / 12-threads LGA-1366 Xeons, available for as low as 15-20$ on AliExpress, is still hard to find and the prices are still high. Also, it’s a good platform for overclocking and it’s not that difficult to run a 2.5/2.6 GHz 6C Xeon at 3.5/3.8GHz stable. Extreme overclocking can lead top-tier Xeons up to 4.2 or even 4.5 GHz.
Thus, this motherboard is not cheap on the used market.
It just happens that I bought one new in 2010, along with an i7-930 – a 1st gen Core i7 from Intel – that I replaced for an X5650 and then for an X5660, currently on the board, but not overclocked (anymore). The case I used back then is the same as now, a Chieftec Dragon, which by today standard is a pretty old design.

Let’s get to fan speed.

This motherboard has 5 fan headers in total: 1 4-wire (PWM) for the CPU, 3 3-wire for the case fans and 1 3-wire for the PSU fan (whose speed cannot be adjusted).

I currently have four chassis fan connected to the system, all by Arctic Cooling: a front intake 80mm F8, a pair of intake 92mm F9 on the side panel (using a fan cable splitter) and a rear exhaust 120mm F12. None of these are PWM, they’re regular 3-pin fans.
The fan are connected as follows:
front F8 → CHA_FAN1 header
side F9s → CHA_FAN3 header
rear F12 → CHA_FAN2 header

The fan speed can be adjusted by the BIOS or the Operating System
* BIOS: This motherboard support the so-called Q-Fan feature on both the CPU and the chassis fan, and I’ve enabled it, using the “Silent” profile.
* OS: Under Windows there is the well-known ASUS Fan Xpert tool (but I suppose SpeedFan would have worked as well).

With the BIOS control, in silent mode, fan are quieter… but not so much. Both the front and side fans were spinning at around 1300 rpm even with the CPU completely idle at 30°C.

Under windows, with Fan Xpert, I was able to further reduce the fan speed to around 700/800 rpm at idle.

Under Linux… well there are quite a few problems to solve.

The first one is the ASUS ATK0110 driver. As much as I like ASUS motheboards, I’ve never – ever – understood the purpose of this driver.

Mint is “smart” enough to load this driver – asus_atk0110 – automatically so with the use of the lm-sensors package you can have access to temperatures, fan speeds and voltages. Install xsensors and you can even see them in a “nice” GUI application with a “very cool” 1995 feel (all those quotes are there for a reason, you know?).

The only problem is that if you attempt to run pwmconfig to control the fan speed, as reported in many guides, it tells you that there are no pwm-controllable fan in the system (which is kinda true, as the only PWM fan is the cpu one, but I’m not gonna control it, I’ll leave that to the BIOS as it’s not so loud after all). That’s because ATK0110 is something… well… not exactly defined. You find the “same” driver more or less on any ASUS product, from cheap laptops to workstation-grade motherboards, but there are different incarnation of the device and the related driver.

So, thank you Mint for loading the driver automatically, but… let me just use another one.

A quick series of “apt install”s, just to be sure everything is installed and up-to-date:

# apt install lm-sensors xsensors fancontrol

Similarly to what I’ve already done by editing a file “by hand” for lm-sensors (you can copy the content of this file and put it in a file like /etc/sensors.d/ASUS-P6T-Deluxe-V2):

# libsensors configuration file for ASUS P6T Deluxe V2
# ----------------------------------------------------

chip "w83667hg-*"

label in0 "Vcore Voltage"
label in3 "+3.3 Voltage"
label in2 "AVCC"
label in7 "3VSB"
# label in8 "Vbat"

set in2_min 3.3 * 0.90
set in2_max 3.3 * 1.10
set in3_min 3.3 * 0.90
set in3_max 3.3 * 1.10
set in7_min 3.3 * 0.90
set in7_max 3.3 * 1.10
set in8_min 3.0 * 0.90
set in8_max 3.3 * 1.10

label fan1 "CHASSIS1 FAN Speed"
label fan2 "CPU FAN Speed"
label fan3 "POWER FAN Speed"
label fan4 "CHASSIS2 FAN Speed"
label fan5 "CHASSIS3 FAN Speed"

label temp1 "MB Temperature"
ignore in8

After a quick check to be sure the correct driver has been loaded:

# lsmod | grep w83627
w83627ehf 49152 0
hwmon_vid 16384 1 w83627ehf


After running pwmconfig, you can customize the /etc/fancontrol file as follow:

# Configuration file generated by pwmconfig, changes will be lost
INTERVAL=10
DEVPATH=hwmon2=devices/platform/w83627ehf.656 hwmon3=devices/platform/coretemp.0
DEVNAME=hwmon2=w83667hg hwmon3=coretemp
FCTEMPS=hwmon2/device/pwm2=hwmon3/temp2_input
FCFANS= hwmon2/device/pwm2=hwmon2/device/fan1_input
MINTEMP=hwmon2/device/pwm2=35
MAXTEMP=hwmon2/device/pwm2=75
MINSTART=hwmon2/device/pwm2=80
MINSTOP=hwmon2/device/pwm2=75
MINPWM=hwmon2/device/pwm2=75
MAXPWM=hwmon2/device/pwm2=235

The result I obtained is the following (just ignore the ‘qlcnic’ temperature sensors of the network card):

And now the system is so much quiter (not silent, as it wasn’t my original purpose) than before that it’s reasonable to work on it.
This blog post was written on the PC in question after all.

Bye

I’m doing some experiments with OpenWrt (http://openwrt.org), in particular, I need to build a custom firmware for a cheap router (a TP-Link WR-841N).
OpenWrt is modular enough to install packages on an already installed image, but when your flash memory size is 4MiB, you want to strip everything unnecessary and add everything you need inside the SquashFS file system.

Building a custom image doesn’t require recompiling anything, there is an ImageBuider package that just create the complete firmware image with a custom build script.

The ImageBuider package has been designed to run on an x86_64 Linux distro.

So I installed Centos 7.0 on Hyper-V on Windows 8.1, everything was working out great except for the screen resolution, that was stuck at 1152×864 (X.org is smart) in the Display Settings in Gnome, and my notebook display is 1366×768.
I would be pretty satisfied at running Linux with a resolution of 1024×768, it’s not that I really need 1366×768 at the moment, but even if 1024×768 is a lower resolution compared to 1152×864, X.org doesn’t allow to select any of the lower VGA, SVGA or XGA resolution.

It’s not that the VM is unusable, but it’s very frustrating dealing with scrollbars even in full-screen mode. The funny part is that Linux already include the Hyper-V integration services since kernel 3.3 or 3.4 or something like that and RHEL 7.0 currently use 3.10 (a giant leap forward from the 2.6.32 kernel of RHEL 6.x), but there was no way X.org recognized the Hyper-V framebuffer.

With the xorg.conf file gone a long time ago, we are in the era of autoconfig, monitor hotplugging, etc.

Microsoft state that the best way of connecting to a VM running in Hyper-V is via RDP, this requires having a stable network connection between the host and the guest OSs and having a RDP service running in the guest OS: pretty easy on Windows, a bit more complicated on Linux where xrdp, an RDP server, works but it’s not an easy solution and always require a stable network connection.
If the Hyper-V server is in the DataCenter, this surely is the best solution, but on a notebook this is a bit an overkill.

Looking at the output of lsmod, the hyperv_fb module is already loaded, so there is no reason for it not to work.

After following various guides with all the sort of commands, like adding a modeline to xrandr (doesn’t work), adding video=1366×768:24 to the kernel boot arguments (doesn’t work), adding resolution=1366×768 always to the kernel boot arguments (needless to say…), I’ve finally found the first alf of the solution in a forum about SUSE.

TL;DR

Adding in GRUB2 the kernel boot argument:

video=hyperv_fb:1366x768

finally allowed me to use the VM in full screen @ 1366×768!

Bye

And I’m saying goodbye, not farewell!

By the way, I moved from Debian “Squeeze” ( 6.0 testing ) to CentOS 5.5 on Tomcat and, even with an older 2.6.18 kernel (compared to the newer 2.6.32 debian’s one) everything worked flawlessly: video, network card, audio.

I must admit that Tomcat is a little old, but the battery is still alive and it’s powerful enough for many of my daily task, like writing small programs, reading e-mails, surfing the web, doing some electronic projects, using office apps etc.

It is not that I don’t like Debian anymore. I was using a testing distribution and I had only minor issues, so I was quite happy with it.

Then Hyper-V came: a powerful virtualization service for Windows Server 2008 that is also able to run Linux as a guest OS. Great, but it only works with SLES or RHEL. You can obtain SLES for free but you will have only two month of updates without purchasing a subscripition with Novell. On the other hand, you can’t have RHEL for free, but you can have CentOS and upgrades for free, so I went for CentOS. I currently have a VM running CentOS with the Linux integrations services installed that works well.

I did a backup of all the data on Tomcat and installed CentOS on it. It works perfectly beside Windows XP on the another partition.

Recently, I have also installed CentOS on Nighthawk. I use it remotely via SSH or VNC.
I’m slowly getting accustomished to yum, even if sometimes I still type apt-get instead of yum… oh well.

However, my “goodbye” to Debian isn’t really true, because as of writing this post, this page is being served by apache running on a Debian 4.0 virtual machine according to the informations tophost gives me on the site’s control panel…

Bye

Probably, this may works with other distributions, kernel versions and other systems, but I’m not going to do any further test.

Recently, a friend of mine asked me to install a new hard drive on his Sony Vaio laptop, because he ran out of free space on the original drive.

So after buying and installing a new 160GB drive, I began with the setup of Windows XP SP3. Anyway I left some free space for Linux.

Setting up Windows was quite easy, but setting up Linux, was a real nightmare.

I tried 4 differents x86 Ubuntu’s CDs (8.04 live, 8.10 live & alternate, 9.04 alternate). They all had the same problem: kernel hanged during startup. The strange thing about that was that by pressing a key (any key), kernel startup process moved forward of a single step, and, keypress after keypress, after 10 or more minutes, the OS was completely loaded!

I tried with OpenSuSE 11.1 live CD. There were less problems during startup, but the matter still remained the same: the OS required several keypresses to boot. After installing to disk, nothing changed.

Now, I’m not an expert, but thinking about that, I supposed there was a problem with interrupts or system clock or both, so after looking for solutions on Google, I found someone writing about the boot parameter “clocksource”.

To know clocksources available on my system, I wrote:

cat /sys/devices/system/clocksource/clocksource0/available_clocksource

on a terminal, and got:

tsc acpi_pm jiffies

Firstly I tried adding “clocksource=acpi_pm” in /boot/grub/menu.lst but, at the following boot, nothing changed.

Then I tried with “clocksource=jiffies“: that actually works!

The system boot up quite rapidly and without the need of any keypress.

Hope this article could help someone who is hitting a wall with his head trying to install Linux on this laptop.

Bye

This is a post taken from an old unused blog of mine. Many things have changed, but this article could be useful for distributions that still use the “classical” ( /dev/sda1 or /dev/hda1 ) way to refer to mass storage devices.

Having some spare time, I decided do some jobs on Mirage.
Apart from Solaris 9 that is unused by months on the Samsung 20GB IDE drive, I decided to reinstall Debian 4.0 on the Fujitsu 18GB SCSI drive that was initially placed inside the Sun 599 box.
Version 4.0 is the last one that allow installing a working dektop environment. Version 5.0 with the “new” 2.6.26 kernel doesn’t correctly start X.org, while Debian 4.0 works flawlessly.
Just to try something new, I decided to go for XFCE as default desktop environment instead of Gnome.
Installation was perfect, but at the first reboot, the system halted on the message:

Begin: mounting root file system

Obviously, there are some problems in mouting /, /boot, /usr and other filesystems…
Pressing

[STOP]+[A]

take me to the OpenBoot prompt where using

reset-all

I restart the system, this time giving more attention to the kernel messages.
During boot, kernel finds the Samsung IDE drive, the two 9GB IBM SCSI drives inside the Sun 599, the Plextor SCSI CD drive and, finally, the Fujitsu SCSI drive.
Ok, so, if the two IBM drives are /dev/sda and /dev/sdb respectively and the Plextor CD drive is /dev/sdc, then the Fujitsu drive must be /dev/sdd.

Obviously the system hangs on the same message, as before.
Once started BusyBox, the emergency shell

mkdir temp

followed by

mount /dev/sdd1 /temp

Some warnings, but it mount the file system. With

ls /temp

I can read the files in /boot. 

 An immediate check to the silo.conf file shows me

root=/dev/sdc4

So, in a moment

vi /temp/silo.conf

the “wrong” parameter is modified.

At the next boot… the system hangs always on the same message.

Uhm… probably (ehm, that means, “for sure”) I mounted the file system read-only from BusyBox.
Looking at the file, I actually haven’t modified it.

At the next boot, at the SILO prompt I type

help

and SILO tells me that I can define a root device using

root=/dev/$device

So I try

linux root=/dev/sdd4

and finally boot goes on, even if it stops for another less important reason.

The next question is easy to solve. It simply try to mount /dev/sdc4 as /.

mkdir temp
mount /dev/sdd4 /temp
vi /temp/etc/fstab

Just the time of changing every reference of /dev/sdc to /dev/sdd and rebooting and…
Voilà! Everything goes right and within a minute I’m able to login in gdm.

Okay… and now there is a problem bigger than a house.
The CD-ROM drive IS NOT /dev/sdc.

And so, what?

What the Hell is “stealing” a SCSI drive designation?

… SUSPENCE …

The “thief” is a 128MB USB flash drive, to which the kernel assigns the designation /dev/sda.
Obiviously, removing that drive means that the system hangs on finding the root file system…
Changing silo.conf and /etc/fstab to use the original /dev/sdc  make the system bootable without the USB drive inserted, but of course with the drive inserted the system is unable to boot.

The title of this article came from a message the Debian installer wrtites at the end of the process:
“The Silo bootloader results installed. The system should now be bootable.”

[UPDATE – PROBLEM SOLVED]

After asking some friends and doing some search I’ve found many interesting things (like how useful udev can be)… that haven’t helped me figuring out how to solve this problem.
The BIG idea come from a friend’s laptop on which I recently installed OpenSUSE 11.1. This Linux distribution uniquely identify a disk using an id. To access a mass storage device, instead of using the classical

/dev/sdxn

where x is the letter used to identify the physical disk device and n is the number identifying the partition, uses

/dev/disk/by-id/scsi-SFUJITSU_MAN3184MC_JADDAJADDAJADDA-partn

where JADDAJADDAJADDA is the device serial number and n is always the partition number.
This way to identify the various devices has been introduced in kernel 2.6 and newer.

Modifying silo.conf and /etc/fstab accordingly Mirage is now bootable even with more USB devices attached.
A minor “collateral damage” is that the system disk can be designated in various different ways depending on the number of external disks connected, but until now this has caused no problems.

Bye