2021-02-06 update breaks negative temperatures for 1-wire sensors (reports 7000 degrees instead of -10)

[johnterickson]

Is this the right place for my bug report?
This repository contains the Linux kernel used on the Raspberry Pi. If you believe that the issue you are seeing is kernel-related, this is the right place. If not, we have other repositories for the GPU firmware at github.com/raspberrypi/firmware and Raspberry Pi userland applications at github.com/raspberrypi/userland. If you have problems with the Raspbian distribution packages, report them in the github.com/RPi-Distro/repo. If you simply have a question, then the Raspberry Pi forums are the best place to ask it.

Describe the bug
I have a temperature sensor in Rasp Pi 2 in my garage. It's been running great for over a year. I have it set to update nightly. Last night, as soon as the update rebooted, I got a notification that my freezer was at 7000 degrees F. Fridge temp was nominal. I hard-powered off and on the device. No change.

Looking at the data sheet I realized that the 7000 deg F temp was way beyond what the sensor could even represent in binary. I double checked the direct output from the sensor (see below) to make sure it wasn't my code that messed it up.

To reproduce
Attach DS18B20, enable 1-wire, put sensor below 0 degrees celcius.

Expected behaviour
Negative temperatures from 1-wire sensors are correct.

Actual behaviour
Negative temperatures are incorrectly sign extended.

System
Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions:

• Which model of Raspberry Pi? e.g. Pi3B+, PiZeroW
  Raspberry Pi 2
• Which OS and version (cat /etc/rpi-issue)?

pi@raspberrypi:/sys/devices/w1_bus_master1 $ cat /etc/rpi-issue
Raspberry Pi reference 2020-02-13
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 5f884374b6ac6e155330c58caa1fb7249b8badf1, stage4

• Which firmware version (vcgencmd version)?

pi@raspberrypi:/sys/devices/w1_bus_master1 $ vcgencmd version
Jan 27 2021 22:26:53
Copyright (c) 2012 Broadcom
version 99d9a48302e4553cff3688692bb7e9ac760a03fa (clean) (release) (start)

• Which kernel version (uname -a)?

pi@raspberrypi:/sys/devices/w1_bus_master1 $ uname -a
Linux raspberrypi 5.10.11-v7+ #1399 SMP Thu Jan 28 12:06:05 GMT 2021 armv7l GNU/Linux

Logs

Start-Date: 2021-02-06  00:01:52
Commandline: apt-get upgrade -y
Requested-By: pi (1000)
Upgrade: libraspberrypi-bin:armhf (1.20210108-1, 1.20210201-1), libraspberrypi-dev:armhf (1.20210108-1, 1.20210201-1), libraspberrypi-doc:armhf (1.20210108-1, 1.20210201-1), libldap-2.4-2:armhf (2.4.47+dfsg-3+rpi1+deb10u4, 2.4.47+dfsg-3+rpi1+deb10u5), raspberrypi-kernel:armhf (1.20210108-1, 1.20210201-1), raspberrypi-bootloader:armhf (1.20210108-1, 1.20210201-1), libldap-common:armhf (2.4.47+dfsg-3+rpi1+deb10u4, 2.4.47+dfsg-3+rpi1+deb10u5), libraspberrypi0:armhf (1.20210108-1, 1.20210201-1), ca-certificates:armhf (20200601~deb10u1, 20200601~deb10u2), tzdata:armhf (2020e-0+deb10u1, 2021a-0+deb10u1)

# fridge
pi@raspberrypi:/sys/devices/w1_bus_master1 $ cat 28-03119779ae01/temperature
5187
pi@raspberrypi:/sys/devices/w1_bus_master1 $ cat 28-03119779ae01/w1_slave
52 00 55 05 7f a5 a5 66 d4 : crc=d4 YES
52 00 55 05 7f a5 a5 66 d4 t=5125

# freezer
pi@raspberrypi:/sys/devices/w1_bus_master1 $ cat 28-030997791dbd/temperature
4085000
pi@raspberrypi:/sys/devices/w1_bus_master1 $ cat 28-030997791dbd/w1_slave
3d ff 55 05 7f a5 a5 66 c9 : crc=c9 YES
3d ff 55 05 7f a5 a5 66 c9 t=4083812

Additional context
You can find my mitigation to properly sign-extend here: johnterickson/MiPi-1wire-rs@2b852cb

[johnterickson]

My guess is this is a regression from 9ace0b4

[johnterickson]

Yup in w1_DS18B20_convert_temp, it used to have a correctly sized integer s16 but now it transits as an int and I think the le16_to_cpup returned value is not sign-extended in conversion to int.

[johnterickson]

I’ll spin up a PR to bring in https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/w1/slaves/w1_therm.c?h=next-20210205&id=2f6055c26f1913763eabc66c7c27d0693561e966

[danieltroger]

I did not know where to report this so I "reported" it on stack overflow instead and got guided here.

I also opened a question on the pi forums but either the site is buggy or it's still in moderation.

Idk who to tell but it would be great to get this fixed ASAP.

@johnterickson do you have some binary for me that I can use to get my thermometers working? Or anything else I can do while avoiding to compile the entire linux kernel on my pi which I imagine takes like 5 weeks.

[danieltroger]

Thanks to Jarosław Komar there is a workaround!

The thermometers always overreport by 4096°C and by subtracting 4096 if the temperature is over 100°C correct readings can be obtained.

[johnterickson]

@danieltroger Glad you found a workaround - I think the "subtract 4096" is equivalent, but you can see how I worked around this in my app here as another reference point: johnterickson/MiPi-1wire-rs@2b852cb

[pelwell]

The upstream fix is now in rpi-5.10.y and rpi-5.11.y.

[popcornmix]

rpi-update contains the potential fix for this. Please test and report.

[Jaszczur666]

Just updated and tested - it works for me, thank you.

[johnterickson]

Confirmed here as well - thanks @pelwell and @popcornmix for the quick turnaround!

[tracerrx]

Can confirm that this patch fixes reading negatives on a Raspberry Pi Model B Rev 2, kernel 5.10.14. Thanks for the quick fix!

[danieltroger]

Can confirm here too it is now working again, thanks a lot!

[awarburt]

Tested the fix by way of raspi-config, and negative centigrade temperatures appear to be getting decoded correctly again. Thank you for the rapid fix.