Re: Bug#409349: usbhid: control queue full; hung apcupsd task
found 2.6.32-40
thanks
Hi,
Hope it's okay for me to reassign #409349 and #611646 as kernel bugs.
It may be only apcupsd users who experience this, but the process hangs
due to a system call failing to return, and there were reports of a
related error message in the kernel log (control queue full), which
seems to have been a precursor to this hang.
It's clear that this bug has existed for some time (the initial report
was on 2.6.17). I'll have difficulty testing this on 3.2.x kernels
because I require OpenVZ on the affected machine (and that's not ported
to 3.x kernels yet), and I was unsuccessful so far in reproducing it on
a spare box.
I notice that most reports were from users of OHCI hardware. I've even
seen this on a recent RHEL6-derived kernel just now (amd64 OpenVZ kernel
2.6.32-042stab049.6) :
> [425881.271304] INFO: task apcupsd:7104 blocked for more than 120 seconds.
> [425881.278546] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [425881.287407] apcupsd D ffff88004dc00680 0 7104 1 0 0x00000004
> [425881.295778] ffff880008f57d18 0000000000000082 0000000000000000 0000000000000286
> [425881.304301] 00000000fffffffe 0000000000000000 ffff88008f33b0a0 ffff8800762fe200
> [425881.312839] ffff880008f57cb8 ffff88004dc00c38 ffff880008f57fd8 ffff880008f57fd8
> [425881.321374] Call Trace:
> [425881.324325] [<ffffffff81396ef5>] usb_kill_urb+0x85/0xc0
> [425881.330289] [<ffffffff81095310>] ? autoremove_wake_function+0x0/0x40
> [425881.337470] [<ffffffff81406d79>] usbhid_init_reports+0xb9/0x120
> [425881.344191] [<ffffffff81408a68>] hiddev_ioctl+0x418/0x710
> [425881.350357] [<ffffffff81154ba4>] ? handle_mm_fault+0x1e4/0x2b0
> [425881.356967] [<ffffffff81042b54>] ? __do_page_fault+0x1e4/0x480
> [425881.363595] [<ffffffff811a0182>] vfs_ioctl+0x22/0xa0
> [425881.369277] [<ffffffff811a0324>] do_vfs_ioctl+0x84/0x5b0
> [425881.375361] [<ffffffff8118e9f9>] ? __fput+0x1e9/0x280
> [425881.381140] [<ffffffff811a089f>] sys_ioctl+0x4f/0x80
> [425881.386822] [<ffffffff8100b182>] system_call_fastpath+0x16/0x1b
Regards,
--
Steven Chamberlain
steven@pyro.eu.org
Reply to: