-
@jonathanlee said in NUT package:
did a full reinstall of pfSense on my Netgate 2100 Max last night and reinstalled the NUT package to see if that helps. I wanted to rule that out. 1hr so far with no issues on a BareMetal install of pfSense 23.01.
I will be very pleased, but also very surprised, if this resolves the issue.
If it does, it would indicate a problem with the prior kernel or nut install. IIRC, you had already complete removed and reinstalled nut, yes?
-
@tman222 said in NUT package:
I went ahead and disabled UPS polling completely by adding the interruptonly flag to the usbhid driver (in the "Extra Arguments to driver (optional)" input box).
I have not had one disconnect now in over 14 hours.This is useful. Two possible reasons it is more stable... one there is lot less interactive with the ups, so less opportunity for a random pointer to be hit. The other is that something particular to the ups extended data is what is triggering the pointer problem.
In the interest of looking at the later, would you do me a favor please? Could you post two snapshots of the complete ups status page (Services / UPS/ Status), one with the interruptonly flag set, and one without. Thanks!
-
Yeah well without that in that section my Synology wont connect to it so If you have a better way to make that happen with the code removed, I'm all ears.
Also, in your config, the content of "Additional configuration lines for ups.conf" is invalid and should be completely removed. This section is for global directives only, and what you have there conflicts with the package configuration.
-
A bare metal install fixed my issues, test installed the package at 8:34am it is now 10:50 and still no issues.
Weird right? TAC support told me that my upgrade in place did not fully complete and it was bonked up somehow. It did fix it for the SG-2100.
-
@xavier1 said in NUT package:
Yeah well without that in that section my Synology wont connect to it so If you have a better way to make that happen with the code removed, I'm all ears.
You deleted the post that had your configuration information... was this intentional?
Your Synology needs the entries in upsd.conf and upsd.users. The global entries for ups.conf have no impact on remote connections.
The requirements for Synology support are:
- the name of the ups must be "ups" (field UPS Name)
- user "monuser" with password "secret" must exist (field Advanced settings > Additional lines for upsd.users)
- remote access is enabled (see post #2 in this thread)
-
@jonathanlee said in NUT package:
A bare metal install fixed my issues, test installed the package at 8:34am it is now 10:50 and still no issues.
Weird right? TAC support told me that my upgrade in place did not fully complete and it was bonked up somehow. It did fix it for the SG-2100.That's fantastic.
-
For anyone else who is having the signal 10/11 issue with usbhid-ups, are able to do a complete reinstall?
If so, could you report back after doing so?
Thanks!
-
@dennypage said in NUT package:
@lcbbcl I'm looking for messages from "usbhid-ups". I don't need anything from "upsd" or "upsmon".
Also, I note in your former post your advanced section is cut off... but it is expanded which would indicate that you have something set in there. Can you confirm if you have anything in the advanced section at all?
I have only Feb 19 20:35:00 upsd 30880 Can't connect to UPS [APC] (usbhid-ups-APC): No such file or directory
msg whith usbhid-upsIn advance section i set only what interface to use to listen and users
-
@dennypage said in NUT package:
For anyone else who is having the signal 10/11 issue with usbhid-ups, are able to do a complete reinstall?
If so, could you report back after doing so?
Thanks!
Unfortunately, in my case I'm dealing with a custom build so there is no direct path to install 23.01. If I recall correctly, isn't it still 2.60 CE > 22.05 > 23.01? If that's the case, I'm not sure it would necessarily fix the problem since it still an upgrade vs. a fresh install.
For good measure, I did try uninstalling the NUT package, rebooting, reinstalling, rebooting again, but still end up with the same signal 10/11 issue unless I run NUT with the
interruptonly
flag. When the NUT package is uninstalled, is there anything left behind that can be removed manually? The one thing that I have not tried yet is simply switching the USB port on the back of the system to see if that might fix it. -
@tman222 I can't advise you on the upgrade path, but based on what is currently known with a fresh re-install fixing the issue, I have assume that the issue is kernel or libusb related. Re-install of nut will not have any effect on that.
There have been several reports of upgrades not fully completing, so I think a re-install is a good idea.
The best that I can recommend is reaching out to Netgate for advice on how to do a fresh install. I'm sure there is some way to accomplish it.
-
@dennypage I spoke to soon its back. . . :(
-
@jonathanlee said in NUT package:
its back. . . :(
Sigh. That's unfortunate. Back on the path of getting a debug build I guess.
-
@tman222 Hey, I'm sorry if you mentioned this before and I missed it, but could you share some information on the kind of hardware you are running pfSense on? Is it Intel or Arm based? Thanks
-
so rebooted XG-7100 back into 22.05 (thanks to ZFS) and confirmed nut package and USB drivers work as expected. Rebooted back into 23.01 and same - exit on signal 10.
Some data points:
My NAS runs TrueNAS Core 13.0-U3.1, which os based on FreeBSD 13.1-RELEASE-p2. It is connected to a 1U CyberPower 700VA UPS via nut and it is also working as expected - no issues.
If I connect the 700VA UPS to my XG-7100 I get the same results - exit on signal 10. If I connect the 500VA UPS (normally connected to the XG-7100) to my TrueNAS server, works as expected - no issues and reports correct information.
Also, I have connected the USB cable of both UPS to both USB 2.0 ports on my XG-7100 with the same results - eventually exits on signal 10.
so...
nut package and USB devices look to work correctly under FreeBSD 12.3-STABLE and FreeBSD-13.1-RELEASE. Issue must be with FreeBSD-14-CURRENT.
-
@dennypage said in NUT package:
@tman222 Hey, I'm sorry if you mentioned this before and I missed it, but could you share some information on the kind of hardware you are running pfSense on? Is it Intel or Arm based? Thanks
Hi @dennypage - this particular system that is seeing the signal 10 errors is based on newer Intel based hardware (running on an 10th gen Intel Core i3 CPU). It looks like it continues to run fine using the
interruptonly
flag as additional input to the NUT usbhid-ups driver (no disconnections/crashes yet). Please let me know if the NUT status screenshots would still be helpful to have. -
where do you put the interruptonly flag in the nut config gui?
-
@shaffergr said in NUT package:
where do you put the interruptonly flag in the nut config gui?
Hi @shaffergr - you would put it in the "Extra Arguments to driver (optional)" section:
-
@dennypage Thank you very much for your excellent work on this package.
I have not upgraded to 23.01 yet, so a quick question:Should we expect this to be an issue with all USB-HID driver local attached UPS’es, or do you suspect this is UPS model (USB implementation) dependant?
About once or twice a week I have a short UPS dropout (< 1 minute) on SG-2100/22.05 with my Eaton 500S UPS.
The SG-2100 is VERY remote, so I will try and replace the USB cable in a couple of weeks when I’m on-site again. I was hoping to upgrade to 23.01 at that time :-)My SG-6100/22.05 have no such symptoms with its Eaton 550SC.
-
@tman222 said in NUT package:
Please let me know if the NUT status screenshots would still be helpful to have.
They would. The purpose is to know what additional variables are being processed for the cyberpower when interruptonly is not set. Thanks.
-
@keyser said in NUT package:
Should we expect this to be an issue with all USB-HID driver local attached UPS’es, or do you suspect this is UPS model (USB implementation) dependant?
So far all the signal 10/11 reports pertain to the cyberpower subdriver of usbhid. Not a guarantee, but a good indicator.