Bug 904151
| Summary: | problem with interface smartups apcupsd | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | la_antorcha_guia | ||||
| Component: | apcupsd | Assignee: | Michal Hlavinka <mhlavink> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 18 | CC: | mhlavink, moschleg, pcfe | ||||
| Target Milestone: | --- | Keywords: | Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 1061984 (view as bug list) | Environment: | |||||
| Last Closed: | 2014-02-05 22:59:33 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
FWIW; I have a Smart-UPS 1500 on USB and that works fine. Could you attach your /etc/apcupsd/apcupsd.conf please? Created attachment 692397 [details]
apcupsd.conf
What version of apcupsd package do you have? What version of kernel do you have? Please reboot and once problem reproduces again, attach output of dmesg Thanks updated to fedora 18, seems solved ok, closing this bug. If you see this problem again, feel free to reopen. /sys/devices/pci0000:00/0000:00:10.3/usb5/5-2/5-2:1.0/0003:051D:0002.0001 I think that this problem appears when power control of USB/PCI is in "auto" mode. I do not know if is problem of apcupsd or kernel with USB chipset. Powertop program, select "good": USB Smart-UPS USB UHCI Host Controller (of UPS) PCI VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (of UPS) Wait some time. Review logs. Problem with some data. Seems "solved" returning to "Bad" USB Smart-UPS device. This issue is still going on with the current Fedora kernel and packages. I see this still in Fedora 19 x86_64 with kernel 3.10.4-300 and apcupsd 3.14.10-10 packages: kernel-3.10.4-300.fc19.x86_64 apcupsd-3.14.10-10.fc19.x86_64 libusb-0.1.4-1.fc19.x86_64 (not sure if this is useful) UPS: MODEL: Smart-UPS 1500, FIRMWARE : 601.3.D USB FW:8.1 BATTDATE : 2013-06-23 $> dmesg [249178.141536] hid-generic 0003:051D:0002.0001: control queue full [249178.161628] hid-generic 0003:051D:0002.0001: control queue full [249178.181720] hid-generic 0003:051D:0002.0001: control queue full [249178.221878] hid-generic 0003:051D:0002.0001: control queue full [249178.262042] hid-generic 0003:051D:0002.0001: control queue full $> lsusb | grep American Bus 007 Device 002: ID 051d:0002 American Power Conversion Uninterruptible Power Supply $> lsusb -vs 007:002 Bus 007 Device 002: ID 051d:0002 American Power Conversion Uninterruptible Power Supply Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x051d American Power Conversion idProduct 0x0002 Uninterruptible Power Supply bcdDevice 0.06 iManufacturer 3 iProduct 1 iSerial 2 bNumConfigurations 1 ps. My best suspicion is that this is due to going into and out of power save/ suspend to RAM mode. I occasionally use suspend to ram, I suspect that the UPS or the driver doesn't do this right. This is still occurring on: kernel 3.10.10-200.fc19.x86_64 (updated since comment 8) libusb-0.1.5-2.fc19.x86_64 (updated since comment 8) apcupsd-3.14.10-10.fc19.x86_64 (kernel and libusb updated since comment 8) I can report that the current Fedora kernel kernel-3.11.1-200.fc19.x86_64 has this fixed. (In reply to Mark Schlegel from comment #11) > I can report that the current Fedora kernel kernel-3.11.1-200.fc19.x86_64 > has this fixed. UPDATE- I had to run kernel 3.11.2-201.fc19.x86_64 a bit longer for the bug to return, so this is NOT fixed yet. The below is filling up the kernel buffer in this kernel > dmesg [84775.774827] hid-generic 0003:051D:2281.0001: control queue full [84775.835026] hid-generic 0003:051D:2281.0001: control queue full [84775.855100] hid-generic 0003:051D:2281.0001: control queue full [84775.875174] hid-generic 0003:051D:2281.0001: control queue full [84775.895249] hid-generic 0003:051D:2281.0001: control queue full [84775.915324] hid-generic 0003:051D:2281.0001: control queue full [84775.935400] hid-generic 0003:051D:2281.0001: control queue full [84775.975536] hid-generic 0003:051D:2281.0001: control queue full [84776.015675] hid-generic 0003:051D:2281.0001: control queue full Update on the kernel version showing this issue: I still get 'control queue full' with a newer kernel than my last common in post #12: 3.11.8-200.fc19.x86_64 SMP Wed Nov 13 16:29:59 UTC 2013 GNU/Linux This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. 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 WONTFIX if it remains open with a Fedora 'version' of '18'. 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 prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 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 to Fedora 18's end of life. 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. In update for the Fedora 18 EOL issue, note that bug is still evident on kernel 3.12.7-200.fc19.x86_64 on Fedora 19. Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 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. |
Description of problem: plug smartups sua1000i USB. No update of data from UPS, and logs repeat several times (40 per minute): "hid-generic 0003:051D:0002.0001: control queue full" Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1.plug smartups 2.start apcupsd 3.open logs Actual results: unexpected results Expected results: good data from ups and no log problem Additional info: Bus 002 Device 002: ID 051d:0002 American Power Conversion Uninterruptible Power Supply Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0. bDeviceProtocol 0. bMaxPacketSize0 8 idVendor 0x051d American Power Conversion idProduct 0x0002 Uninterruptible Power Supply bcdDevice 0.06 iManufacturer 3. iProduct 1 Smart-UPS 1000 FW:652.13.I USB FW:7.3 iSerial 2 AS********** bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 34 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 11 1 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 30mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0. HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.10 bCountryCode 33 US bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 1064 Report Descriptors:. ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0006 1x 6 bytes bInterval 100 Device Status: 0x0001 Self Powered