Description of problem: UPS Eaton 5E 1100iUSB is recognized and immediately disconnected: journalctl -xe kernel: usb 1-8: new full-speed USB device number 89 using xhci_hcd kernel: usb 1-8: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01 kernel: usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=0 kernel: usb 1-8: Product: 5E kernel: usb 1-8: Manufacturer: EATON kernel: hid-generic 0003:0463:FFFF.0057: hiddev96,hidraw0: USB HID v1.10 Device [EATON 5E] on usb-000> kernel: hid-generic 0003:0463:FFFF.0057: usb_submit_urb(ctrl) failed: -1 kernel: hid-generic 0003:0463:FFFF.0057: timeout initializing reports And device ID goes 58 - 59 and so on. NUT scanners shows this: nut-scanner -U Scanning USB bus. [nutdev1] driver = "usbhid-ups" port = "auto" vendorid = "0463" productid = "FFFF" bus = "001" USB Viewer show xHCI Host Controller: 5E / USB Optical Mouse and for 5E: 5E Manufacturer: EATON Speed: 12Mb/s (full) USB Version: 1.10 Device Class: 00(>ifc ) Device Subclass: 00 Device Protocol: 00 Maximum Default Endpoint Size: 8 Number of Configurations: 1 Vendor Id: 0463 Product Id: ffff Revision Number: 0.01 Config Number: 1 Number of Interfaces: 1 Attributes: a0 MaxPower Needed: 20mA Interface Number: 0 Name: usbhid Alternate Number: 0 Class: 03(HID ) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 3 Type: Int. Max Packet Size: 8 Interval: 20ms Same UPS device is working properly when connected to different machines with OS Fedora 23, Fedora 26 and Windows 10 (with the bundled Win UPS soft). Same problem is observed when the UPS is connected to 3 different machines with Fedora 29 5.0.4-200.fc29.x86_64. Upgrade to 5.0.4 does not help. Connecting the UPS through USB hub does not help. Replacing USB cable does not help. Another UPS Eaton 5E 2000iUSB shows the same problem when connected to OS Fedora 29 and works fine on Debian 9.5 (stretch) - 4.9.110-1 amd64. Version-Release number of selected component (if applicable): Fedora 29 5.0.4-200.fc29.x86_64 How reproducible: Any time Eaton 5E UPS is connected. Steps to Reproduce: 1. Connect Eaton 5E ****iUSB device to USB port 2. 3. Actual results: 1. Log shows that the device is constantly connecting & disconnecting. 2. lsusb shows constantly incrementing Device number. 3. NUT shows: upsdrvctl start Network UPS Tools - UPS driver controller 2.7.4 Network UPS Tools - Generic HID driver 0.41 (2.7.4) USB communication driver 0.33 No matching HID UPS found Driver failed to start (exit status=1) Expected results: No error messages in log, consistent Device number Additional info: Fiddling with /etc/udev/rules.d/69-libmtp.rules to exclude this device from MTP rules does not help: ATTR{idVendor}=="0463", GOTO="libmtp_rules_end" Google search does not point to a work around. I am a user, not professional, not sure if the problem is actually related to udev component. Please, correct it if not true.
Update to Fedora 29 5.0.7 today changes nothing.
One more observation: just installed Fedora 29 Workstation from live CD on another CPU, minimal install without any software. Kernel is 4.18.16.300 and lsusb shows Eaton 5E UPS as expected - without connect/disconnect, no errors in log file!!! After "Select all update" in dnf-dragora and update to kernel 5.07 from Fedora Update repository (no extra repositories configured), the UPS is not recognized properly: lsusb shows the device connect/disconnect/connect with incremental ID, same errors in log. I do not have NUT or any other USB utility installed to repeat all readings shown above, but I think it is clear enough where the problem is lying.
Update to Fedora 29 5.0.10 changes nothing.
I have the same problem. After seeing https://lkml.org/lkml/2018/11/26/580 [PATCH 4.19 038/118] Revert "HID: add NOGET quirk for Eaton Ellipse MAX UPS" I appended kernel boot parameter usbhid.quirks=0x0463:0xffff:0x08 to re-enable the NOGET quirk and now it works.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.