# For example: restrict to use ttyS1, ttyS2 and hiddev1 device nodes at /dev # path only. # Note, the 'libusb' does not support suffix number only. All groups of 'ttyS', 'ttyUSB', 'hiddev', or # 'libusb' device node are enumerated without a suffix number assignment. You can assign # the single device node path or multiple device node paths divided by a # semicolon at this option. Therefore, you can restrict # this enumerate behave by using allowed-device-nodes option. But this may cause a disturbance to the # device node which is occupied by other software. The pwrstatd # defaults to enumerate all acceptable device nodes and pick up to use an # available device node automatically. # The pwrstatd accepts four types of device node which includes the 'ttyS', # 'ttyUSB', 'hiddev', and 'libusb' for communication with UPS. It appears that pwrstatd is trying to talk to my Cisco switch (through the USB-to-serial adapter) rather than my UPS! I’m sure they could have a great conversation together, but it’s hardly productive. usb 3-1: pl2303 converter now attached to ttyUSB0 usb 3-1: Manufacturer: Prolific Technology Inc. usb 3-1: Product: USB-Serial Controller D usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 3-1: New USB device found, idVendor=067b, idProduct=2303 I have a USB-to-serial device that allows my server to talk to the console port on my Cisco switch: usb 3-1: new full-speed USB device number 9 using xhci_hcd Things are beginning to make more sense now. If you remember, we had this line in dmesg when the UPS was plugged in: hid-generic 0003:0764:0501.0004: hiddev0,hidraw0: USB HID v1.10 Device on usb-0000:00:14.0-1/input0 The last line of the lsof output shows that pwrstatd is talking to /dev/ttyS1, but the device is supposed to be a hiddev device over USB. Pwrstatd 3975 root 4u CHR 180,2 /dev/ttyS1 Pwrstatd 3975 root 3u unix 0xffff9e392f0c0c5 /var/pwrstatd.ipc type=STREAM Pwrstatd 3975 root 2u unix 0xffff9e395e13740 type=STREAM Pwrstatd 3975 root 1u unix 0xffff9e395e13740 type=STREAM If the daemon can truly see the UPS, then what is it talking to? I used lsof to examine what the pwrstatd daemon is doing: # lsof -p 3975ĬOMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME The pwrstatd daemon can see the device and communicate with it. I checked the /var/log/pwrstatd.log file to see if there were any errors: 5 12:01:17 PM Daemon startups.ĥ 12:01:24 PM Communication is established.ĥ 12:01:27 PM Low Battery capacity is restored.ĥ 12:05:19 PM Communication is established.ĥ 12:05:22 PM Low Battery capacity is restored. usb 3-1: New USB device strings: Mfr=3, Product=1, SerialNumber=2 usb 3-1: New USB device found, idVendor=0764, idProduct=0501 Checking the basics #Ī quick look at dmesg output shows that the UPS is connected and the kernel recognizes it: usb 3-1: new full-speed USB device number 7 using xhci_hcd I disconnected power from the UPS itself and ran pwrstat again. I disconnected the USB cable and ran pwrstat again. However, the pwrstat command doesn’t retrieve any useful data on the new system: # pwrstat -status I have a CyberPower BRG1350AVRLCD at home and I’ve just connected it to a new device.
0 Comments
Leave a Reply. |