Archive for the ‘Hardware’ Category

Hardware monitoring in Linux

I have had this motherboard for a few months, currently on BIOS version 1.40. Although fan speed control is available though the BIOS, I wanted to have access through the OS or at least to be able to read temperature, voltage and fan RPM data from within linux like I could on my previous motherboard, an Asrock Z68 Pro3-M.

I found a while back that

# sensors-detect

is able to identify the embedded controller on the Z370M Pro4:

Trying family `VIA/Winbond/Nuvoton/Fintek'... Yes
Found `Nuvoton NCT6683D eSIO'
 (address 0xa10, but not activated)

but is not able to access it.

I spent some time on this today and here are my findings:

From cold boot,  I saw this in dmesg:
[    4.754471] nct6683: EC is disabled
not looking promising, but I tried to load the driver anyway.  Per the README, the nct6683 hwmon driver must be force loaded on non-Intel boards
# modprobe nct6683 force=1
and it fails with the following error:
# modprobe: ERROR: could not insert 'nct6683': No such device
However, if I suspend the system, then resume and try to load the driver again…success!
[ 4464.599527] nct6683: Found NCT6683D or compatible chip at 0x2e:0xa20

[ 4464.600616] nct6683 nct6683.2592: NCT6683D EC firmware version 1.0 build 07/18/16
# sensors
seems to give valid data:
Adapter: ISA adapter
Package id 0: +35.0°C (high = +82.0°C, crit = +100.0°C)
Core 0: +34.0°C (high = +82.0°C, crit = +100.0°C)
Core 1: +33.0°C (high = +82.0°C, crit = +100.0°C)
Core 2: +35.0°C (high = +82.0°C, crit = +100.0°C)
Core 3: +37.0°C (high = +82.0°C, crit = +100.0°C)
Core 4: +35.0°C (high = +82.0°C, crit = +100.0°C)
Core 5: +33.0°C (high = +82.0°C, crit = +100.0°C)

Adapter: ISA adapter
VIN0: +0.34 V (min = +0.00 V, max = +0.00 V)
VIN1: +1.02 V (min = +0.00 V, max = +0.00 V)
VIN2: +1.01 V (min = +0.00 V, max = +0.00 V)
VIN3: +1.06 V (min = +0.00 V, max = +0.00 V)
VIN7: +1.34 V (min = +0.00 V, max = +0.00 V)
VIN16: +1.07 V (min = +0.00 V, max = +0.00 V)
VIN12: +0.00 V (min = +0.00 V, max = +0.00 V)
VIN13: +1.02 V (min = +0.00 V, max = +0.00 V)
VCC: +3.30 V (min = +0.00 V, max = +0.00 V)
VSB: +3.42 V (min = +0.00 V, max = +0.00 V)
AVSB: +3.42 V (min = +0.00 V, max = +0.00 V)
VTT: +1.06 V (min = +0.00 V, max = +0.00 V)
VBAT: +3.04 V (min = +0.00 V, max = +0.00 V)
fan1: 0 RPM (min = 0 RPM)
fan2: 2474 RPM (min = 0 RPM)
fan3: 0 RPM (min = 0 RPM)
fan4: 781 RPM (min = 0 RPM)
Thermistor 14: +34.0°C (low = +0.0°C)
 (high = +0.0°C, hyst = +0.0°C)
 (crit = +0.0°C) sensor = thermistor
Thermistor 15: +33.5°C (low = +0.0°C)
 (high = +0.0°C, hyst = +0.0°C)
 (crit = +0.0°C) sensor = thermistor
PECI 0.0: +35.0°C (low = +0.0°C)
 (high = +0.0°C, hyst = +0.0°C)
 (crit = +0.0°C) sensor = Intel PECI
intrusion0: OK
beep_enable: disabled

For the record, adding


with or without


on the kernel command line does not change anything.  Furthermore, fan speed control is still not available due to a limitation of the nct6683 driver.

 I am not sure if my findings are specific to my hardware or represent a bug in lm_sensors, the nct6683 driver, or the Asrock Z370M Pro4 BIOS. Asrock does not support linux so I have not bothered contacting them. I did contact the lm_sensors maintainer, Guenter Roeck and hopefully he will reply.  In the meantime, I would be interested in hearing from anyone running linux on an Asrock Z370 motherboard running into similar issues.


Thanks to Guenter for his suggestion to try the nct6683 driver from his GitHub repository  – and for his work on lm_sensors.  I built and installed the out of tree driver and now have access to the sensor data from my Asrock 370M Pro4 motherboard from within linux, without the need for the odd workaround.  Please note, the  driver still must be force loaded as explained above.


Have you ever come across any old electronics or tools with a rubberized finish that has degraded over time, leaving a sticky residue?  I recently purchased a NOS (new old stock) URC* programmable universal remote on eBay.  The remote  had been sealed in a plastic bag in it’s original packaging for over 10 years and was in excellent condition – except for the goo on the surface.  I did some reading online about restoring degraded soft touch plastics and came across lots of recommendations including cleaning with denatured alcohol and using Armor All (silicone based) or vegetable oil to bring back the shine or applying talcum powder to just get rid of the stickiness.  I didn’t want to use anything so harsh it would destroy the screen printing on the remote and I didn’t want to apply anything that would leave a  heavy build up so I decided on a combined approach.

In the end I came up with the following gentle, easy restoration process and it gave me great results:

First I used 70% isopropyl alcohol prep pads  to clean the surface of the remote. This left the surface dry and dull.  Since  plastic meant to be handled on a frequent basis should be able to hold up to the oils on one’s skin, I  decided to try hand lotion to replenish the oils in the plastic. I applied one pump of Cetaphil (unscented, dye free)  lotion to my hands and rubbed it in. Then I rubbed the entire surface of the remote with my hands, in effect transferring a light coating of lubricants from the lotion on my hands to the surface of the remote.  I left the remote to dry overnight. Finally, the next morning, I lightly dampened a microfiber cloth with Meguiar’s Quik Interior Detailer and polished the surface one last time. This left the remote with a uniform, smooth satin finish – not sticky and not greasy – and with no damage to the screen printing. Mission accomplished.

*In case you are not familiar with this brand, URC makes remotes with excellent keypads that are built to last – and to me, that’s the most important part of a remote.

So now that I replaced one of our desktops with a laptop and it happened to be the one that the shared printer was connected to, I had to figure out what to do with the printer.  Since there is no guarantee the laptop will be near the printer at any given time, I didn’t want to use it as the print server.  There is no room for it at my desk so the printer stays where it is.

After a Google search for print servers that work with Linux, I picked up a nicely priced Netgear PS121 USB 2.0 Mini Print Server from eBay.  The consensus was that it’s not perfect and the documentation regarding use with Linux is just about nonexistent, but it works.  And I found that to be the case in combination with my Canon Pixma ip4300 printer.

The trick to get this to work (at least with my printer and Arch Linux setup):

Your device URI needs to look like this:


(replace the x’s with your device’s actual IP address and device name).

Note the “_P1” at the end of the device name.  It represents the port number.  It’s not mentioned in the user manual but without it, you won’t be printing anything.

N.B. –  These tips apply only to version 2 of the  PS121.  From what I have read,  version 1  is actually a completely different piece of hardware.  If you have a v1 you might want to take a look here.

With a couple of tweaks, the Acer Aspire 5740 series looks like a winner for Linux users. Two issues I have run into both have workarounds. The other one should be an easy fix as well.

Brightness Control

As I mentioned before, I am running Arch Linux on this computer. Out of the box you can’t adjust the backlight brightness. I confirmed the same with Ubuntu 10.04. This can be fixed by adding the following to your GRUB kernel parameters:


A kernel patch has been proposed here to prevent the need for this; maybe it will make it into the next release.

UPDATE – There is a new and better fix for the brightness issue.  See my comment here and if you are running Ubuntu, check Kamal Mostafa’s PPA.

Wired Networking

Because of an issue with the tg3 driver in the kernel, the Broadcom wired NIC is not detected properly at startup. A temporary fix is to remove the tg3 module, load the Broadcom module then reinsert the tg3 module. A better solution is to download the current driver from Broadcom, compile it yourself and install it.

N.B. – Make sure you have your kernel headers installed before you try to compile the module.

UPDATE – It seems that the tg3 driver is fixed in the 2.6.35 kernel so the above procedure is no longer necessary (after you upgrade).


There also seems to be an issue with audio coming from the built-in speakers when the headphone jack is in use. I will get to that one soon.

Everything else just works!  If I come across any other issues I will update this post.