DietPi-Banner | Show low voltage⚡️ warning

[svh1985]

Creating a feature request

Is your feature request related to a problem? Please describe:

• I typically login via SSH and therefore do not see the low voltage indicator. And if you never login via the HDMI console, you will never know. Low voltage leads an unstable system. So, it would make sense to see an indicator in the DietPi-Banner too.
  

[MichaIng]

@svh1985
Many thanks for your request. Very reasonable!

Since this is on very basic firmware level, even outside of kernel control, I am not sure how to check, probably some vcgencmd command? Or if this sign shows up, can you check if dmesg always shows a related low voltage error? I'll also do some research at a later time.

[svh1985]

I ran dmesg which gave a large list of messages, so I added grep to filter:

root@HomeAssistant:~# dmesg | grep 'Under-voltage detected!'
[    7.032206] Under-voltage detected! (0x00050000)

Maybe this even better:
dmesg | grep '0x00050000'

This needs proper testing tho, we don't want any false positives.

[MichaIng]

@svh1985
This is a good start. We would need to assure that this error ID is unique, at least for the RPi kernel.

[MichaIng]

vcgencmd get_throttled is what we need:

• https://www.raspberrypi.org/forums/viewtopic.php?p=972790#p972790
• With hex values (console output): https://www.raspberrypi.org/forums/viewtopic.php?p=1201876#p1201876

This allows us to even show more detailed info, e.g. ARM fequency throttling due to overheat. Should be included into cpu command as well.

This can be used with cmd arguments as well to check for specific events and if they did occur since last call/check. However for now I think current state is most important:

• Current undervoltage
• Current ARM frequency cap (temp close to temp_limit)
• Current ARM + GPU throttling (temp >= temp_limit)
• Or any combination of the above

Actually, IMO this should be not a banner "option", but if one of these are true, it should be shown on any banner, as a warning, since this implies always a need for action. Especially since we ship RPi images with relatively lower temp_limit (65°C on RPi1/2/Zero, 75°C on RPi3/4, compared to Raspbian default 85°C), system can run into throttling phases easier.

[svh1985]

I've checked:

My dmesg log is full with Under-voltage. I'm guessing the [145637.778081] is a timestamp right?

[145637.778081] Under-voltage detected! (0x00050005)
[145671.074662] Under-voltage detected! (0x00050005)
[145897.908001] rpi_firmware_get_throttled: 4 callbacks suppressed
[145897.908009] Voltage normalised (0x00000000)
[146074.796495] Voltage normalised (0x00000000)
[146076.877500] rpi_firmware_get_throttled: 4 callbacks suppressed
[146076.877512] Under-voltage detected! (0x00050005)
[146089.363713] Voltage normalised (0x00000000)
[146091.444907] Under-voltage detected! (0x00050005)
[146370.304304] Voltage normalised (0x00000000)
[146372.385522] Under-voltage detected! (0x00050005)
[146438.978673] Voltage normalised (0x00000000)
[146441.060025] Under-voltage detected! (0x00050005)
[147038.318221] Voltage normalised (0x00000000)
[147758.358358] Under-voltage detected! (0x00050005)
[147762.520236] Voltage normalised (0x00000000)
[147777.087702] Under-voltage detected! (0x00050005)
[147783.330722] Voltage normalised (0x00000000)
[147808.303368] Under-voltage detected! (0x00050005)
[147814.546335] Voltage normalised (0x00000000)
[148099.648993] rpi_firmware_get_throttled: 6 callbacks suppressed
[148099.649005] Under-voltage detected! (0x00050005)
[148103.811048] rpi_firmware_get_throttled: 6 callbacks suppressed
[148103.811059] Voltage normalised (0x00000000)
[148124.621385] Under-voltage detected! (0x00050005)
[148139.188697] Voltage normalised (0x00000000)
[148143.350735] Under-voltage detected! (0x00050005)
[148349.373751] Voltage normalised (0x00000000)
[148711.474760] Voltage normalised (0x00000000)
[148713.555864] rpi_firmware_get_throttled: 1 callbacks suppressed
[148713.555876] Under-voltage detected! (0x00050005)
[148969.523849] Voltage normalised (0x00000000)
[148973.686008] Under-voltage detected! (0x00050005)
[148988.253236] Voltage normalised (0x00000000)
[148994.496442] Under-voltage detected! (0x00050005)
[149013.225682] rpi_firmware_get_throttled: 1 callbacks suppressed
[149013.225697] Voltage normalised (0x00000000)
[149015.306783] rpi_firmware_get_throttled: 1 callbacks suppressed
[149015.306795] Under-voltage detected! (0x00050005)
[149027.792946] Voltage normalised (0x00000000)
[149038.198320] Under-voltage detected! (0x00050005)
[149044.441247] Voltage normalised (0x00000000)
[149056.927652] Under-voltage detected! (0x00050005)
[149327.462796] rpi_firmware_get_throttled: 10 callbacks suppressed
[149327.462811] Voltage normalised (0x00000000)
[149329.553938] rpi_firmware_get_throttled: 10 callbacks suppressed
[149329.553949] Under-voltage detected! (0x00050005)
[149458.568465] Voltage normalised (0x00000000)
[149970.504380] Under-voltage detected! (0x00050005)
[150322.200132] Voltage normalised (0x00000000)
[150611.464806] Under-voltage detected! (0x00050005)
[150623.951046] Voltage normalised (0x00000000)
[150653.085724] Under-voltage detected! (0x00050005)
[150657.247843] Voltage normalised (0x00000000)
[150665.571959] Under-voltage detected! (0x00050005)
[150682.220230] Voltage normalised (0x00000000)
[151025.592130] rpi_firmware_get_throttled: 3 callbacks suppressed
[151025.592141] Voltage normalised (0x00000000)
[151206.642418] rpi_firmware_get_throttled: 4 callbacks suppressed
[151206.642432] Under-voltage detected! (0x00050005)
[151435.556977] Voltage normalised (0x00000000)
[164910.294389] Under-voltage detected! (0x00050005)
[165264.071152] Voltage normalised (0x00000000)
[165266.152241] Under-voltage detected! (0x00050005)
[165270.314371] Voltage normalised (0x00000000)
[165274.476389] Under-voltage detected! (0x00050005)
[165280.719434] Voltage normalised (0x00000000)
[165403.500946] Under-voltage detected! (0x00050005)
[165915.436833] rpi_firmware_get_throttled: 2 callbacks suppressed
[165915.436843] Voltage normalised (0x00000000)
[204924.541525] rpi_firmware_get_throttled: 2 callbacks suppressed
[204924.541537] Under-voltage detected! (0x00050005)
[205122.240383] Voltage normalised (0x00000000)

[MichaIng]

0x50000

Means under-voltage has occurred and ARM has been throttled (as a result of under-voltage) which perfectly fits your dmesg output. Jep [205122.240383] is the timestamp in seconds from boot, means 2 days and 9 hours, means about 3 hours before the banner print of your above screenshot (Uptime), to get an idea.

While for testing this is nice and proves the output reliability, I suggest you take case your power supply. In bad cases under-voltage means data loss, e.g. when a USB-attached storage looses connection while data is currently written and such 😉.

---

And seeing it, not only "current" events are something we should show, but past events as well. Every event that happend during the current session at best requires some review and possible action.

[svh1985]

In my case the USB ports drain too much power from the RPi. So I can simulate low voltage easily 😄

And seeing it, not only "current" events are something we should show, but past events as well. Every event that happend during the current session at best requires some review and possible action.

I agree, doing a dmesg | grep '0x00050000' then will have the best result I guess. Because it will always match as long as the log has an entry. (that log will be flushed after reboot right?)

I'm also not sure if removing the power-draining-USB-device will restore the throttled ARM state, or that it will only be restored upon next reboot. In the first case, the vcgencmd command will only show when the status is low, which may not be all the time, and therefore unreliable for the banner.

[MichaIng]

@svh1985

In my case the USB ports drain too much power from the RPi. So I can simulate low voltage easily 😄

For testing indeed perfect, but also one of the most common reasons for bug reports about system crash, data corruption, random external drive unmounts and all the aftereffects 😄.
People are just used to plug e.g. external 2,5" drives in USB cases into PC USB ports, especially since 2,5" cases usually come without dedicated power supply.

I agree, doing a dmesg | grep '0x00050000' then will have the best result I guess. Because it will always match as long as the log has an entry. (that log will be flushed after reboot right?)

The 0x50000 vcgencmd output just tells the same. 0x00000 would be never undervolted+never throttled.
0xX0005 would be "currently" undervolted+throttled, so last integer defines current state, first defines past states.
All states + dmesg are flushed on reboot, yes, respectively not saved to disk.

I'm also not sure if removing the power-draining-USB-device will restore the throttled ARM state, or that it will only be restored upon next reboot.

It is normalised immediately together with voltage. 0x50000 with last digit "0" means currently there is neither undervoltage, nor throttling nor ARM freq cap due to temperature being close to temp_limit. Of course you can check:

2019-11-19 12:28:32 root@micha:/var/log# vcgencmd measure_clock arm
frequency(45)=900000000
2019-11-19 12:28:37 root@micha:/var/log# vcgencmd measure_volts
volt=1.3000V
2019-11-19 12:28:51 root@micha:/var/log# vcgencmd get_config over_voltage
over_voltage=-2

• My RPi2 with lowered max volts, hence 1.3V instead of usual 1.4V default.