USB camera spamming dmesg when idle

[oshunluvr]

KDEneon (22.04 base), kernel 5.15.0-67

I've been switching kernels between 5.15.0-67, 5.19.0-32, and 5.19.0-35 because of various different issues;
5.19.0-35 no sound
5.19.0-32 screens won't wake up from power save

So I went back to 5.15.0-67 because it has neither of the above issues. T

This morning I checked dmesg and found this message repeated 6 times a minute (about every 12 seconds) forever...

[Wed Mar  8 08:44:19 2023] usb 1-1.4: reset high-speed USB device number 62 using xhci_hcd

A small amount of sleuthing (lsusb -t) reveals:

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 480M
   |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
       |__ Port 2: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M
       |__ Port 4: Dev 62, If 0, Class=Video, Driver=uvcvideo, 480M
       |__ Port 4: Dev 62, If 1, Class=Video, Driver=uvcvideo, 480M
       |__ Port 4: Dev 62, If 2, Class=Audio, Driver=snd-usb-audio, 480M
       |__ Port 4: Dev 62, If 3, Class=Audio, Driver=snd-usb-audio, 480M
​

So it's my cheapo USB web cam (for work Zoom and Teams meetings, not whatever YOU'RE thinking ).

Launching Kamosa stopped the message immediately. I left it on from several minutes to verify this, and no more messages. Then I closed Kamoso and got this:

[Wed Mar  8 08:52:53 2023] usb 1-1.4: 3:1: cannot get freq at ep 0x84
[Wed Mar  8 08:52:54 2023] usb 1-1.4: 3:1: cannot get freq at ep 0x84
[Wed Mar  8 08:52:54 2023] usb 1-1.4: 3:1: cannot get freq at ep 0x84
[Wed Mar  8 08:54:41 2023] usb 1-1.4: reset high-speed USB device number 63 using xhci_hcd
​

and the "reset" message returns ad infinitum.

Note one oddity, the "USB device number" changed from 62 to 63. Probably meaningless, but I noticed it. Repeating the above thereafter results in it staying on 63.

I'm curious if anyone else has seen this and if there are any suggestions - short of unplugging it, obviously - that might stop the messages so that dmesg is meaningful again.

[claydoh]

So it's my cheapo USB web cam (for work Zoom and Teams meetings, not whatever YOU'RE thinking ).

If you hadn't mentioned it, we wouldn't be thinking anything, tbh
Now we can't get the 'whatever out of our heads

No clue in the output, though. The usual try a different port trick, maybe a bum cable?
My dirt cheap-ish Wal-mart brand uvc cam seems fine here, though I am on the current kernel.

[oshunluvr]

Well I've tried it in several ports and I get the same results. I'm guessing it's either a bad driver or bad device.

I also get this message when I plug it it:

cannot get freq at ep 0x84
​

[claydoh]

Well I've tried it in several ports and I get the same results. I'm guessing it's either a bad driver or bad device.

I also get this message when I plug it it

cannot get freq at ep 0x84
​

I think I see that on mine, too. Not your spamming though.

usb 1-12.4: 3:1: cannot get freq at ep 0x86
[31429.814602] usb 1-12.4: 3:2: cannot set freq 11025 to ep 0x86
[31429.816740] usb 1-12.4: 3:3: cannot set freq 16000 to ep 0x86
[31430.388611] usb 1-12.4: 3:4: cannot get freq at ep 0x86
[31430.391293] usb 1-12.4: 3:5: cannot set freq 24000 to ep 0x86
[31430.962446] usb 1-12.4: 3:6: cannot get freq at ep 0x86
[31432.144877] usb 1-12.4: Warning! Unlikely big volume range (=4096), cval->res is probably wrong.
[31432.144888] usb 1-12.4: [7] FU [Mic Capture Volume] ch = 1, val = 0/4096/1

It works fine, though.

[oshunluvr]

Still seeing this. I moved ports again and fiddled around. Now getting this:

[Tue Apr 18 16:33:33 2023] usb 1-1.1: reset high-speed USB device number 10 using xhci_hcd
[Tue Apr 18 16:33:34 2023] usb 1-1.1: restoring control 00000000-0000-0000-0000-000000000101/10/5
[Tue Apr 18 16:33:34 2023] usb 1-1.1: restoring control 00000000-0000-0000-0000-000000000101/12/11
​

but not spamming like it was. It seems it was/is some sort of incompatibility between USB drivers/ports of various type (USB 2.0, 3.0, 3.1, 3.2) and this cheap camera.