View previous topic :: View next topic |
Author |
Message |
Philippe23 Tux's lil' helper
Joined: 20 Dec 2006 Posts: 130 Location: Central NY
|
Posted: Mon Apr 22, 2013 11:07 am Post subject: hid-generic control queue full errors. |
|
|
I tried upgrading from 3.5.?-r1 to 3.8.3 (hardened). Doing so introduced a CONFIG_HID_GENERIC option, which I turned on. Now, after a little while, my machine will become unresponsive after a while and the logs will be filled with kernel errors referring to: "hid-generic 0003:051D:0002.0002: control queue full" as well as other drivers complaining that IOMMU allocations have failed. The ID appears to be the USB connection to my UPS. I am running apcupsd.
Is anybody else seeing this? Does anybody know of a fix? |
|
Back to top |
|
|
trubicoid Tux's lil' helper
Joined: 04 Aug 2009 Posts: 79
|
Posted: Mon Jun 16, 2014 2:11 pm Post subject: |
|
|
there is a quick fix to disable Run-time Powe Management of the corresponding hiddev0 in my case, but as I have just one hiddev, I can run this in eg. /etc/local.d/
Code: | #!/bin/sh
echo "Correct APC USB problem: hid-generic control queue full"
for i in /sys/class/usbmisc/hiddev*/device/../power/control
do
if [ -f ${i} ];
then
echo on > ${i}
fi
done
|
other fix is to decrease POLLTIME in /etc/apcupsd/apcupsd.conf, but I haven't tried that one
interesting is, that with POLLTIME 120 I get the first "control queue full" message aprox. 33 minutes after boot, then several every two minutes as expected
Code: | ...
[ 50.131312] br0: port 2(tap0) entered forwarding state
[ 51.851887] br0: port 1(enp7s0) entered forwarding state
[ 1967.605402] hid-generic 0003:051D:0002.0004: control queue full
[ 2087.778313] hid-generic 0003:051D:0002.0004: control queue full
[ 2087.841686] hid-generic 0003:051D:0002.0004: control queue full
[ 2087.884333] hid-generic 0003:051D:0002.0004: control queue full
[ 2087.946851] hid-generic 0003:051D:0002.0004: control queue full
[ 2088.049248] hid-generic 0003:051D:0002.0004: control queue full
[ 2088.091096] hid-generic 0003:051D:0002.0004: control queue full
[ 2088.132617] hid-generic 0003:051D:0002.0004: control queue full
[ 2088.213981] hid-generic 0003:051D:0002.0004: control queue full
[ 2088.254438] hid-generic 0003:051D:0002.0004: control queue full
[ 2088.294697] hid-generic 0003:051D:0002.0004: control queue full
[ 2088.334954] hid-generic 0003:051D:0002.0004: control queue full
[ 2088.374285] hid-generic 0003:051D:0002.0004: control queue full
[ 2088.412801] hid-generic 0003:051D:0002.0004: control queue full
[ 2088.470766] hid-generic 0003:051D:0002.0004: control queue full
[ 2088.507220] hid-generic 0003:051D:0002.0004: control queue full
[ 2088.543886] hid-generic 0003:051D:0002.0004: control queue full
[ 2208.722264] hid-generic 0003:051D:0002.0004: control queue full
[ 2208.778541] hid-generic 0003:051D:0002.0004: control queue full
[ 2208.814124] hid-generic 0003:051D:0002.0004: control queue full
[ 2208.868629] hid-generic 0003:051D:0002.0004: control queue full
[ 2208.962216] hid-generic 0003:051D:0002.0004: control queue full
[ 2208.993625] hid-generic 0003:051D:0002.0004: control queue full
[ 2209.023837] hid-generic 0003:051D:0002.0004: control queue full
[ 2209.093155] hid-generic 0003:051D:0002.0004: control queue full
[ 2209.121028] hid-generic 0003:051D:0002.0004: control queue full
[ 2209.147701] hid-generic 0003:051D:0002.0004: control queue full
[ 2209.173204] hid-generic 0003:051D:0002.0004: control queue full
[ 2209.198779] hid-generic 0003:051D:0002.0004: control queue full
[ 2209.224450] hid-generic 0003:051D:0002.0004: control queue full
[ 2209.269167] hid-generic 0003:051D:0002.0004: control queue full
[ 2209.292727] hid-generic 0003:051D:0002.0004: control queue full
[ 2209.314990] hid-generic 0003:051D:0002.0004: control queue full
[ 2329.377897] hid-generic 0003:051D:0002.0004: control queue full
... |
the best would be to include the fix directly in apcupsd
Last edited by trubicoid on Tue Jun 17, 2014 9:43 am; edited 1 time in total |
|
Back to top |
|
|
trubicoid Tux's lil' helper
Joined: 04 Aug 2009 Posts: 79
|
Posted: Tue Jun 17, 2014 9:42 am Post subject: |
|
|
trubicoid wrote: | POOLTIME |
I meant POLLTIME, sorry |
|
Back to top |
|
|
mbjr Guru
Joined: 17 Jan 2004 Posts: 531 Location: Budapest/Hungary
|
Posted: Mon May 30, 2016 7:10 pm Post subject: *bump* |
|
|
SOLVED: this looks like an apcupsd bug.
Replacing apcupsd with nut fixed it (gave it over 16 hours and not a single time I've seen this happening).
Logs are clean, UPS provides data as it should.
Leaving info below in case it's useful for someone else bumping into this (can remove if Admins prefer).
Quote: | Ran into the same thing with 4.4.6.
A bunch of these:
#May 30 20:58:54 [kernel] [41361.238580] hid-generic 0003:051D:0002.0004: control queue full
Stuff that didn't work:
1. Control seems to be ok (does the same with an "on" value):
# cat /sys/class/usbmisc/hiddev0/device/0003\:051D\:0002.0004/power/control
auto
2. Polltime is 60 (recommended by apcupsd to be used as default). Changing this results in less frequent reports, but it will happen eventually.
3. Using another cable or another USB port.
4. Killing apcupsd/restarting/etc.
Further observations:
1. This is interesting: https://forums.gentoo.org/viewtopic-t-88161-highlight-hidcore+control+queue+full.html
2. If I disconnect the UPS from USB, wait a couple of seconds and reconnect, it will be okay for a couple of hours; then control queue will get full again.
3. From what I can see, this issue is preventing apcupsd from fetching up-to-date data from the UPS.
I tested this morning and after 15 minutes of battery-only operation it still reported BCHARGE 100.0 percent - which makes relying on UPS based reports unreliable.
I'm using a strict time limit of 1200 seconds, but given battery ages, it's not a good practice to leave it like that.
4. Confirming #2 here, usbhid-dump says I/O error (not getting this for other USB devices such as the keyboard/mouse attached):
Code: | usbhid-dump --model=051d:0002
001:004:000:Failed to retrieve report descriptor: Input/Output Error |
Stuff I didn't rule out yet:
1. This is a new machine, Asus Z170M-Pro, I7-6700t. A previous configuration with the same UPS, 4.4.6 kernel version didn't do this. I'll poke around in Bios settings to see if there's anything that can cause this.
Other info:
1. Apcupsd USE flags: nls usb -cgi -gnome -snmp
2. Genkernel (for now) with a lot of (probably unnecessary) HID stuff (excl common HID devices such as a4tech,apple,belkin,cherry,chicony,ezkey,cypress,kensington,microsoft,montery,wacom):
CONFIG_BT_HIDP=m
CONFIG_HID=y
CONFIG_HIDRAW=y
CONFIG_HID_GENERIC=y
CONFIG_USB_HID=y
CONFIG_HID_PID=y
CONFIG_USB_HIDDEV=y
3. usb-devices reports APC as:
T: Bus=01 Lev=01 Prnt=01 Port=12 Cnt=02 Dev#= 4 Spd=1.5 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=051d ProdID=0002 Rev=01.06
S: Manufacturer=APC
S: Product=Back-UPS ES 700G FW:871.O3 .I USB FW:O3
S: SerialNumber=XXXXXXXXXXX
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=2mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
At this point I'm running nut as an alternative - there are no issues of hid control queue reported (so far) - will give it some time.
I'm starting to think that this is actually an apcupsd bug - but let's give it some time. |
Thanks for reading _________________ mb |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|