# Thoughts on hwmon symlink targets changing on reboot

## graysky

Quite a bit in google on this topic but no hard fixes.  Basically, the assignments of various hwmon symlinks change on each reboot.  This causes fancontrol as well as my own little temp script to file as a result.  For example:

```
% ls /sys/class/hwmon/ -al

total 0

drwxr-xr-x  2 root root 0 Mar 29 21:48 .

drwxr-xr-x 38 root root 0 Mar 29 21:48 ..

lrwxrwxrwx  1 root root 0 Mar 29 21:48 hwmon0 -> ../../devices/virtual/hwmon/hwmon0

lrwxrwxrwx  1 root root 0 Mar 29 21:48 hwmon1 -> ../../devices/platform/eeepc-wmi/hwmon/hwmon1

lrwxrwxrwx  1 root root 0 Mar 29 21:48 hwmon2 -> ../../devices/platform/coretemp.0/hwmon/hwmon2

lrwxrwxrwx  1 root root 0 Mar 29 21:48 hwmon3 -> ../../devices/platform/nct6775.656/hwmon/hwmon3
```

Here you see that coretemp.0 is #2 and nct6775 is #3.  Upon a reboot they shifted:

```
% ls /sys/class/hwmon/ -al

total 0

drwxr-xr-x  2 root root 0 Mar 29 21:50 .

drwxr-xr-x 38 root root 0 Mar 29 21:50 ..

lrwxrwxrwx  1 root root 0 Mar 29 21:50 hwmon0 -> ../../devices/virtual/hwmon/hwmon0

lrwxrwxrwx  1 root root 0 Mar 29 21:50 hwmon1 -> ../../devices/platform/coretemp.0/hwmon/hwmon1

lrwxrwxrwx  1 root root 0 Mar 29 21:50 hwmon2 -> ../../devices/platform/eeepc-wmi/hwmon/hwmon2

lrwxrwxrwx  1 root root 0 Mar 29 21:50 hwmon3 -> ../../devices/platform/nct6775.656/hwmon/hwmon3
```

Now... coretemp.0 is #1 and nct6775 is #3.

----------

## Dr Croubie

I'm also getting this, seems every time I reboot they switch, and when they switch fancontrol doesn't load properly.

Thankfully with a fairly loud fan and transparent window in my case I can either hear or see the bottom inlet fan spinning (it's set to only come on at very high temps).

I've actually got 2 fancontrol scripts, in /root/fancontrol/

> ~ # ls -l fancontrol/

total 8

-rw-r--r-- 1 root root 890 Jan 14 10:58 rules.k100

-rw-r--r-- 1 root root 890 Jan 13 10:36 rules.radeon0

They're otherwise the same except for the DEV lines at the top:

```
INTERVAL=1

DEVPATH=hwmon1=devices/pci0000:00/0000:00:02.0/0000:01:00.0 hwmon0=devices/pci0000:00/0000:00:18.3 hwmon2=devices/platform/it87.552

DEVNAME=hwmon1=radeon hwmon0=k10temp hwmon2=it8720

FCTEMPS=hwmon2/device/pwm3=hwmon0/device/temp1_input hwmon2/device/pwm2=hwmon1/temp1_input hwmon2/device/pwm1=hwmon2/device/temp2_input

FCFANS=hwmon2/device/pwm3=hwmon2/device/fan3_input hwmon2/device/pwm2=hwmon2/device/fan2_input hwmon2/device/pwm1=hwmon2/device/fan1_input

MINTEMP=hwmon2/device/pwm3=40 hwmon2/device/pwm2=45 hwmon2/device/pwm1=45

MAXTEMP=hwmon2/device/pwm3=55 hwmon2/device/pwm2=55 hwmon2/device/pwm1=55

MINSTART=hwmon2/device/pwm3=0 hwmon2/device/pwm2=50 hwmon2/device/pwm1=100

MINSTOP=hwmon2/device/pwm3=0 hwmon2/device/pwm2=55 hwmon2/device/pwm1=85

MINPWM=hwmon2/device/pwm2=0 hwmon2/device/pwm1=0

MAXPWM=hwmon2/device/pwm3=255 hwmon2/device/pwm2=180 hwmon2/device/pwm1=255
```

```
INTERVAL=1

DEVPATH=hwmon0=devices/pci0000:00/0000:00:02.0/0000:01:00.0 hwmon1=devices/pci0000:00/0000:00:18.3 hwmon2=devices/platform/it87.552

DEVNAME=hwmon0=radeon hwmon1=k10temp hwmon2=it8720

FCTEMPS=hwmon2/device/pwm3=hwmon1/device/temp1_input hwmon2/device/pwm2=hwmon0/temp1_input hwmon2/device/pwm1=hwmon2/device/temp2_input

FCFANS=hwmon2/device/pwm3=hwmon2/device/fan3_input hwmon2/device/pwm2=hwmon2/device/fan2_input hwmon2/device/pwm1=hwmon2/device/fan1_input

MINTEMP=hwmon2/device/pwm3=40 hwmon2/device/pwm2=45 hwmon2/device/pwm1=45

MAXTEMP=hwmon2/device/pwm3=55 hwmon2/device/pwm2=55 hwmon2/device/pwm1=55

MINSTART=hwmon2/device/pwm3=0 hwmon2/device/pwm2=50 hwmon2/device/pwm1=100

MINSTOP=hwmon2/device/pwm3=0 hwmon2/device/pwm2=55 hwmon2/device/pwm1=85

MINPWM=hwmon2/device/pwm2=0 hwmon2/device/pwm1=0

MAXPWM=hwmon2/device/pwm3=255 hwmon2/device/pwm2=180 hwmon2/device/pwm1=255
```

and whenever I reboot and they've changed, I copy the correct one over:

> cp fancontrol/rules.radeon0 /etc/fancontrol && rc

OR

> cp fancontrol/rules.k100 /etc/fancontrol && rc

It's kludgy, and it means I have to maintain 2 fancontrol config files (ie, if I change a temp or speed on one I have to change it on the other).

I did try creating a directory /etc/fancontrol/ and breaking the files therein into rules.devices and rules.temps, with the point being that I'd replace the rules.devices file and leave the temperature settings alone, but fancontrol doesn't like reading config from a directory.

Has anyone else found a way to stop these devices being renamed? Is it a BIOS issue? Kernel? Udev doing its unpredicatble-naming thing again like when it borked eth0? Something else?

----------

## khayyam

graysky, Dr Croubie ... I can't reproduce with mdev & 3.13.11

```
# uname -r

3.13.11-ck

# uptime -p

up 27 days

# ls -l /sys/class/hwmon/

total 0

lrwxrwxrwx 1 root root 0 2014-12-29 19:19 hwmon0 -> ../../devices/platform/coretemp.0/hwmon/hwmon0/

lrwxrwxrwx 1 root root 0 2014-12-29 19:19 hwmon1 -> ../../devices/platform/applesmc.768/hwmon/hwmon1/
```

on reboot ...

```
# uname -r

3.13.11-ck

# uptime -p

up 3 minutes

# ls -l /sys/class/hwmon/

total 0

lrwxrwxrwx 1 root root 0 2015-01-26 03:49 hwmon0 -> ../../devices/platform/coretemp.0/hwmon/hwmon0/

lrwxrwxrwx 1 root root 0 2015-01-26 03:49 hwmon1 -> ../../devices/platform/applesmc.768/hwmon/hwmon1/
```

best ... khay

----------

## Dr Croubie

 *khayyam wrote:*   

> graysky, Dr Croubie ... I can't reproduce with mdev & 3.13.11

 

Yeah, that's one of the big problems, it's not a very reproducible bug, it just switches sometimes on boot and not others.

I've done a bit more digging / searching, seems the OP got a bit more help posting the same thread over at Archlinux.

In short, there are a few causes / workarounds:

1 - "Use /sys/devices paths instead" - ie, rewrite your /etc/fancontrol file to use exact references instead of links.

Problem is, that using links is how the pwmconfig script gets written. If you rewrite /etc/fancontrol to get rid of the links, then run pwmconfig again (for whatever reason), you get the same error.

This would have to be communicated upstream to the pwmconfig devs to change the pwmconfig behaviour.

2 - "Strategy is not to rely on /etc/conf.d/lm_sensors generated by `sensors-detect` for module loading, but instead to do it manually.

1) Remove lm_sensors.serivce from autostart. (gentoo translation, remove it from rc boot?)

2) Place needed modules in /etc/modules-load.d/load_these.conf."

Of course, that only works if you're using all as modules. I've got 'k10temp' and 'it87' as modules in my kernel config from Device Drivers -> Hardware Monitoring and 'radeon' as a module from Graphics -> DRM (at least, I think this 'radeon' module is where the radeon temp sensor comes from, there's certainly no 'radeon' option in the Hardware Monitoring menu, also 'lsmod' gives: "hwmon 2514 4 it87, k10temp, radeon, thermal_sys).

So this option is certainly possible for me, although I've never felt the need to auto-load any modules at startup except when explicitly told to (like Virtualbox tells me to autoload the vbox modules). I just let the kernel decide what modules to load as it sees fit. If they were built into the kernel, however, I'm not sure in what order they'd get loaded.

My biggest concern, actually, is that the fancontrol daemon and/or the rc script is not picking up that the fancontrol service hasn't started.

Consider what happens when I copy the 'wrong' config file over to /etc/fancontrol and try to start it using rc:

```
> service fancontrol stop && cp fancontrol/rules.k100 /etc/fancontrol && rc && rc && fancontrol start

(stop the currently running and working fancontrol)

 * Stopping fancontrol ...                                                                                                                                                [ ok ]

(copying over 'wrong' config file)

(first rc, doesn't pick up that fancontrol failed to start)

 * Starting fancontrol ...                                                                                                                                                [ ok ]

(second rc, just to show that it's still trying to start fancontrol and failing, but still thinking it's started ok)

 * Starting fancontrol ...                                                                                                                                                [ ok ]

(only now, when I explicitly start fancontrol by itself, not via rc, does it give an error)

Loading configuration from /etc/fancontrol ...

Common settings:

  INTERVAL=1

Settings for hwmon2/device/pwm3:

  Depends on hwmon0/device/temp1_input

  Controls hwmon2/device/fan3_input

  MINTEMP=40

  MAXTEMP=55

  MINSTART=0

  MINSTOP=0

  MINPWM=0

  MAXPWM=255

Settings for hwmon2/device/pwm2:

  Depends on hwmon1/temp1_input

  Controls hwmon2/device/fan2_input

  MINTEMP=45

  MAXTEMP=55

  MINSTART=50

  MINSTOP=55

  MINPWM=0

  MAXPWM=180

Settings for hwmon2/device/pwm1:

  Depends on hwmon2/device/temp2_input

  Controls hwmon2/device/fan1_input

  MINTEMP=45

  MAXTEMP=55

  MINSTART=100

  MINSTOP=85

  MINPWM=0

  MAXPWM=255

Device path of hwmon1 has changed

Device path of hwmon0 has changed

Device name of hwmon1 has changed

Device name of hwmon0 has changed

Configuration appears to be outdated, please run pwmconfig again
```

So at the very least I think that this needs to be fed back upstream, to the devs of either/both fancontrol or rc, that the service is failing to start and yet rc isn't picking up that it's failed.

----------

