On Aug 22, 2018, at 2:03 PM, Valentin Merkulov wrote:
>
> With interruptonly the driver output goes into a loop (is it an
> expected behavior?)
Yes, this is what the driver does in the background if you do not pass any "-D"
flags. If you were to start `upsd` at that point, it should be able to
With interruptonly the driver output goes into a loop (is it an
expected behavior?) After I interrupt the loop and launch the driver
again, it would return "No matching HID device found" until I unplug /
re-plug USB cable.
Gzipped output is attached.
> On Wed, Aug 22, 2018 at 3:49 PM Charles
Understood about unplugging USB - others with the 3016 devices have proposed
various methods with USB hubs that have per-port power switching, etc. to
simulate unplugging. I am not a fan of the concept, but I recognize that others
have made more significant investments than the single UPS that
I cannot unplug/re-plug USB though, because currently I'm away from
the hardware location.
On Mon, Aug 20, 2018 at 4:07 PM, Valentin Merkulov wrote:
> After "No device" error the driver does not seem to be able to
> communicate with the UPS (as seen before with the port build):
After "No device" error the driver does not seem to be able to
communicate with the UPS (as seen before with the port build):
# /usr/local/ups/bin/usbhid-ups -a ups - -u root
Network UPS Tools - Generic HID driver 0.53 (v2.7.4-603-gb14c3b42.7.4.1)
USB communication driver 0.37
0.00
On Aug 20, 2018, at 7:40 AM, Valentin Merkulov wrote:
>
> Attached are config.log and usbhid-ups output with -u root (gzipped).
> Now driver output looks a lot like the one from port build.
If memory serves, this was the sort of error we were seeing from 3016 devices
on Linux:
0.154899
Attached are config.log and usbhid-ups output with -u root (gzipped).
Now driver output looks a lot like the one from port build.
On Mon, Aug 20, 2018 at 1:42 PM, Charles Lepple wrote:
> On Aug 20, 2018, at 1:03 AM, Valentin Merkulov wrote:
>>
>> 0.033412 [D3] nut_usb_claim_interface:
On Aug 20, 2018, at 1:03 AM, Valentin Merkulov wrote:
>
> 0.033412 [D3] nut_usb_claim_interface: failed to claim USB
> device (Other error).
> 0.033417 [D3] nut_usb_claim_interface: failed to detach kernel
> driver from USB device (Other error).
I am not as familiar with this branch
On Aug 19, 2018, at 3:03 PM, Valentin Merkulov wrote:
>
> Here is what I get:
>
> # usbconfig -u 1 -a 3 dump_curr_config_desc
> ugen1.3: at usbus1, cfg=0 md=HOST spd=LOW
> (1.5Mbps) pwr=ON (100mA)
>
[...]
Hmm, that may be an issue on the NUT side, then. (You might see issues if you
run
Here is what I get:
# usbconfig -u 1 -a 3 dump_curr_config_desc
ugen1.3: at usbus1, cfg=0 md=HOST spd=LOW
(1.5Mbps) pwr=ON (100mA)
Configuration index 0
bLength = 0x0009
bDescriptorType = 0x0002
wTotalLength = 0x0022
bNumInterfaces = 0x0001
bConfigurationValue = 0x0001
On Aug 19, 2018, at 2:04 AM, Valentin Merkulov wrote:
>
> Hi Everyone,
>
> I'm having trouble getting TrippLite SMX1500LCDT to work on FreeBSD
> 11.2, nut 2.7.4 installed from FreeBSD port.
>
> The debug output is rather big when I'm starting usbhid-ups initially,
> Please find that attached
Hi Everyone,
I'm having trouble getting TrippLite SMX1500LCDT to work on FreeBSD
11.2, nut 2.7.4 installed from FreeBSD port.
The debug output is rather big when I'm starting usbhid-ups initially,
Please find that attached (gzipped to comply with message size limit).
Subsequently, until I
12 matches
Mail list logo
