[Nut-upsdev] Error "Data for UPS [pcmusb] is stale - check driver"

Tue Feb 4 08:16:12 GMT 2025

Hello all,

  Sorry for not jumping in earlier, I was away to a conference.

  One point that Ted raised, about storage, is generally valid, correct and
indeed very important (you can't replace worn-out soldered storage as
easily as pop an MMC/USB/M.2 module).
  "But, there's always a `but`!" :)

  NUT by itself does not write log files. System integrations (service
units, init scripts...) might redirect its daemons' stdout/stderr to log
files, but this is not a requirement of NUT programs as such. Depending on
debug verbosity settings (now can be more easily changed at run-time than
before) the stream can be pretty intense or practically nothing. With newer
codebase, there are also provisions for a number of `NUT_QUIET_<something>`
envvar settings to suppress start-up banners, systemd or similar framework
notification initializers, etc. that can help in embedded space.

  One notable exception is `upslog` that can write to files (or stderr). I
am not sure how widely it is used, but it did get a series of face-lifts
recently.
  Other daemons write PID files and create UNIX sockets, the killpower file
in upsmon, etc. that can all be done in tmpfs. These locations can be
built-in by build configuration or tuned by environment variables like
NUT_CONFPATH, NUT_STATEPATH etc.

  Also note that NUT daemons send messages to at least two streams (enabled
or not as settings would tell them) - stderr or syslog. I think the latter
goes to a local syslog daemon socket per local syslog library
implementation (we just call the standard method), at least there are no
explicit settings in NUT for that like selecting an external log sink
server. So another system component that might write to storage is that.
Generally, it can also route collected messages to a remote sink.

  I saw some embedded systems like routers write a copy of logs to a
RAM-backed tmpfs, so usually a few last kilobytes of system activity can be
seen that way before they rotate away. In this case, note that if syslog
messages are written and rotated by daemon, it is easier to arrange, than
somehow reloading/restarting NUT daemons (or some collector of their stderr
outputs) every few minutes/seconds to do so.

  Regarding disconnections in general, some drivers (usbhid-ups) were
improved in recent years about this, but I haven't seen pcmusb specifically
touched in a while.

  In some cases, e.g. with CPS-originated devices, we saw their controller
chip going to sleep if not polled frequently enough - so reducing the cycle
times could help.

  For example, with Raspberry Pi being popular recently, by the flow of
questions on NUT issue tracker there was a feeling that e.g. RPi3 had
connection issues reported often, RPi4 rarely, RPi5 on the rise again. This
might reflect popularity of the platform and some chance of hitting issues
at all, compared to some same-device series less used, or it could be
linked with hardware (chips, soldering, overheating, firmware tuning, etc.)
- so certainly something to look into with your router HW designer. Either
to confirm that it might be a venue or to honestly(!) rule out a dead end
and focus on the more likely causes. Double-check the power budget, maybe
the appetites of hardware grew with its new revision. Insufficient sources
causing logical chips to do random things especially at a "wrong time to
fail" did bite me a number of times in small machines and big ones alike.

Hope this helps,
Jim Klimov

On Sun, Feb 2, 2025 at 7:28 PM Ted Mittelstaedt via Nut-upsdev <
nut-upsdev at alioth-lists.debian.net> wrote:

> OpenWRT version 23.05.0-rc3 is, for starters, not supported anymore by the
> OpenWRT project, and is old.
>
> The current version is OpenWRT 23.05.05
>
> The reason you are likely getting an old version of NUT when you load the
> nut package is because you are using an old version of openwrt.
>
> Your team needs to sysupdate your 4G LTE Wifi router
>
> You also, in my opinion, need to seriously reconsider running NUT on an
> openwrt router.  The reason why is that NUT generates logfiles and writes
> to the filesystem.
>
> The flash chips that are used on routers are not designed like a USB flash
> stick where they are intended to have a read/write filesystem on them.
> They have no bad block management with NAND flash chips.  That is provided
> by a UBI layer.  You can read about that here:
>
> [OpenWrt Wiki] The OpenWrt Flash Layout
> <https://openwrt.org/docs/techref/flash.layout>
>
> SOME of the NAND devices that OpenWRT has been ported to, DO have complete
> UBI support, others don't.  You did not say what model of router you are
> running - but unless you have researched it and are completely sure that it
> has a fully functional bad block management, you can easily cause problems
> over time attempting to run programs on an OpenWRT router.
>
> In general it's safest to run READ ONLY programs on openwrt.  For example,
> the snmpd server.  Programs that WRITE to the filesystem on the OpenWRT
> router should be avoided.
>
> There's a reason we use hard drives on servers.
>
> Ted
> On 1/30/2025 7:50 PM, Rushabh Sanghavi (Rush) wrote:
>
> Dear NUT Developers,
>
>
>
> A very good morning to you and hope that you are in the best of health and
> spirits.
>
>
>
> For an upcoming UPS Project, our team has been testing Powercom’s
> Cleanline T-1500 UPS model whose photo has been attached with this e-mail.
> Our team has been testing this UPS with one of our 4G LTE WiFi router
> models on which Network UPS Tools (NUT) Version 2.8.0-3 has been installed.
> BUT during the testing our team observed multiple instances of error
> message *"Data for UPS [pcmusb] is stale - check driver"* being randomly
> reported by our 4G LTE WiFi router. Here is the SUMMARY of the issue below
> for clear understanding purposes.
>
>
>
>    - NUT Version 2.8.0-3 was installed on our 4G LTE WiFi router by our
>    team.
>    - Also our 4G LTE WiFi router had Linux Kernel Version 5.15.127,
>    OpenWRT Distribution release “23.05.0-rc3” and OpenWRT Distribution
>    Revision “r23389-5deed175a5” installed on it.
>    - Powercom’s Cleanline T-1500 UPS was connected with our 4G LTE WiFi
>    router via USB to USB Cable Connection (i.e. USB Port on router side
>    and USB Port on UPS side)
>
> Now when NUT installed on our 4G LTE WiFi router model unit tried to poll
> and fetch values of different UPS parameters from Powercom’s Cleanline
> T-1500 UPS model
>
> after both UPS and router had been running for sometime (i.e. for random
> period of time):
>
>
>
>    - router started reporting the error message *“Data for UPS [pcmusb]
>       is stale - check driver”*
>       - after that router could not get UPS’s status any more unless we
>       restart the NUT service
>       - and the router started reporting the error message “Data for UPS
>       [pcmusb] is stale - check driver” after running for sometime again
>
>
>
> Note: *[pcmusb]* represents the *name or identifier* assigned to the UPS
> instance within the NUT (Network UPS Tools) configuration
>
>
>
>    - Our team tried to increase value of NUT’s timers such as
>    “pollinterval”, “pollfreq”, “maxage” but still the issue could not get
>    solved or fixed
>    - Kindly NOTE that our team tested the above with both the NUT Drivers
>    i.e. blazer_usb and nutdrv_qx. But the same error message mentioned above
>    was observed.
>    - Also kindly NOTE that our team also tried to test with NUT Driver
>    “usbhid-ups” but it is seems that this particular Driver is not supported
>    by Powercom’s Cleanline T-1500 UPS model whose photo has been attached
>    with this e-mail.
>    - Currently our team is not 100% sure about the exact root cause.
>
>
>
> Our team need to know the following from NUT Developers.
>
>
>
>    - Which the is correct NUT Driver that our team need to use on the 4G
>    LTE WiFi router so that it can communicate smoothly and successfully with Powercom’s
>    Cleanline T-1500 UPS model whose photo has been attached with this
>    e-mail?
>    - Which specific parameters within the default Configuration Settings
>    file of NUT Version 2.8.0-3 on our 4G LTE WiFi router need to be
>    tweaked / changed so that our 4G LTE WiFi router model can communicate with
>    the Powercom’s Cleanline T-1500 UPS model smoothly and successfully?
>    - Which specific parameters within the default ups.conf / upsd.conf
>    file on our 4G LTE WiFi router needs to be tweaked / changed so that our 4G
>    LTE WiFi router model can communicate with the Powercom’s Cleanline
>    T-1500 UPS model smoothly and successfully?
>
>
>
> Also I am hereby attaching the Log Files with the Log Messages reported on
> our 4G LTE WiFi router model. The 1st Log file contains Log Messages during
> testing with NUT Driver “blazer_usb” while the 2nd Log file contains Log
> Messages during testing with NUT Driver “nutdrv_qx”. You will observe the
> ERROR Message *“Data for UPS [pcmusb] is stale - check driver”* within
> both these attached Log Files.
>
>
>
> Awaiting your swift response back.
>
>
>
> Thanking you,
>
>
>
> Yours sincerely,
>
>
>
>
>
> [image: Legs Logo]
>
> *Rushabh N. S*
>
> *Research and Development Director*
>
> *PP Ontime Company Limited*
>
> *PP Group of Companies*
>
> Address: 1011 Supalai Grand Tower,
>
> 16th Floor, Rama 3 Road,
>
> Chongnonsi, Yannawa,
>
> Bangkok – 10120, Thailand
>
> Landline No: +66-2-0562099 Ext. 2201
>
> Fax No: +66-2-0562088
>
> Cell Phone No: +66-8-59118578 / +66-6-22236221
>
> E-mail: rushabh at pp-ontime.co.th
>
> Web: www.pp-ontime.co.th
>
> Skype ID: rushabh.sanghavi
>
>
>
> *Disclaimer:*
>
> ***************************************************************
> *Important*
> Confidentiality: This Information is intended for the above-named person
> and may contain confidential and/or legally privileged material. Any
> opinions expressed in this information are not necessarily those of the
> company. If it has come to you in error you must take no action based on
> it, nor must you copy or show it to anyone; please delete/destroy and
> inform the sender immediately.
>
>
>
> *Monitoring/Viruses/Malwares*
> PP-Ontime reserves the right to monitor all incoming and outgoing emails
> via PP-Ontime's systems. Although we have security program to monitor and
> eliminate virus/malware, we also advise that in keeping with good computing
> practice the recipient should ensure they are actually virus/malwares free.
> ***************************************************************
>
>
> Disclaimer:
> ***********************************************************************************************
> *Important*
> Confidentiality: This Information is intended for the above-named person
> and may contain confidential and/or legally privileged material. Any
> opinions expressed in this information are not necessarily those of the
> company. If it has come to you in error you must take no action based on
> it, nor must you copy or show it to anyone; please delete/destroy and
> inform the sender immediately. *Monitoring/Viruses/Malwares*
> PP-Ontime reserves the right to monitor all incoming and outgoing emails
> via PP-Ontime's systems. Although we have security program to monitor and
> eliminate virus/malware, we also advise that in keeping with good computing
> practice the recipient should ensure they are actually virus/malwares free.
> **********************************************************************************************
>
>
> _______________________________________________
> Nut-upsdev mailing listNut-upsdev at alioth-lists.debian.nethttps://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20250204/8fd61f93/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 4031 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20250204/8fd61f93/attachment-0001.jpg>