OSError: [Errno 16] Device or resource busy

[supermaz]

Hi,

I'm using Gentoo and I wanted to configure my new Bolt Receiver which came with my new Lift Mouse.

But Solaar is unable to open the device:

workstation ~ $ LC_ALL=C solaar -d
13:42:52,349    ERROR [MainThread] logitech_receiver.receiver: open DeviceInfo(path='/dev/hidraw7', vendor_id='046D', product_id='C548', serial='', release=None, manufacturer=None, product=None, interface=2, driver='hid-generic', bus_id=3, isDevice=None)
Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/logitech_receiver/receiver.py", line 389, in open
    handle = _base.open_path(device_info.path)
  File "/usr/lib/python3.9/site-packages/logitech_receiver/base.py", line 161, in open_path
    return _hid.open_path(path)
  File "/usr/lib/python3.9/site-packages/hidapi/udev.py", line 294, in open_path
    return _os.open(device_path, _os.O_RDWR | _os.O_SYNC)
OSError: [Errno 16] Device or resource busy: '/dev/hidraw7'
13:42:52,350  WARNING [MainThread] solaar.listener: failed to open DeviceInfo(path='/dev/hidraw7', vendor_id='046D', product_id='C548', serial='', release=None, manufacturer=None, product=None, interface=2, driver='hid-generic', bus_id=3, isDevice=None)

Do you have any idea why the hidraw device is blocked? I tried with lsof but couldn't find anything.

Same when running with sudo.

Kernel 5.17.8, Solaar 1.1.3

[pfps]

I'm not having any problems with the same Bolt Receiver model running Fedora with kernel 5.17.6. I'm assuming that you ran lsof and it didn't show any process with /dev/hidraw7 open.

Try solaar show and see whether that produces an error.

[supermaz]

workstation ~ $ LC_ALL=C solaar -d show
21:06:07,127    ERROR [MainThread] logitech_receiver.receiver: open DeviceInfo(path='/dev/hidraw7', vendor_id='046D', product_id='C548', serial='', release=None, manufacturer=None, product=None, interface=2, driver='hid-generic', bus_id=3, isDevice=None)
Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/logitech_receiver/receiver.py", line 389, in open
    handle = _base.open_path(device_info.path)
  File "/usr/lib/python3.9/site-packages/logitech_receiver/base.py", line 161, in open_path
    return _hid.open_path(path)
  File "/usr/lib/python3.9/site-packages/hidapi/udev.py", line 294, in open_path
    return _os.open(device_path, _os.O_RDWR | _os.O_SYNC)
OSError: [Errno 16] Device or resource busy: '/dev/hidraw7'
solaar: error: Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/solaar/cli/__init__.py", line 201, in run
    raise Exception('No devices found')
Exception: No devices found

Nothing that helps me. Indeed, lsof doesn't show anything. Do you have HIDPP enabled in the kernel?

[pfps]

Strange. Can you use your Lift Mouse at all connected through the Bolt receiver?

I don't think that the kernel itself knows much about HID++ (or HIDPP). There is an hid_logitech_hidpp driver that implements a few HID++ things (including name, serial, battery, scroll wheel resolution, and force feedback) but Solaar doesn't need that driver running to work.

Try unplugging the receiver and replugging it again and see what kernel messages are printed (journalctl -f before you unplug the receiver).

[supermaz]

I paired the mouse using a Windows PC that I need to use sometimes, so the mouse is working fine.
I thought maybe the hid_logitech_hidpp driver is taken control of the hidraw device. I might compile it out and see if that makes any difference. Unplugging/Plugging das make any difference, tried that couple of times before.

[pfps]

The driver shouldn't take control of the device. On the contrary, the driver should make the device available.

The problem might be a timing issue. You could try having Solaar running before the receiver is inserted, if this is possible on your system. Or you could try running Solaar only after the receiver is inserted.

[supermaz]

Tried every combindation last day, but might try again later.

[pfps]

If you've tried every combination then I don't know what is going on.

Can you connect your mouse via Bluetooth? If so, try that.
If you have access to another kind of Logitech receiver, you could try that.

[pfps]

Another thing you could do is to try to write to the device directly. Try something like cat - > /dev/hidraw7 and see whether that produces an error message.

Solaar includes the hidconsole tool. Clone Solaar and run ./tools/hidconsole /dev/hidraw7 from the cloned directory and see whether that produces an error.

[supermaz]

writing to and trying hidconsole also ends with "Device or resource busy".

Here is my kernel config with grepped HID:

CONFIG_BT_HIDP=m
CONFIG_MEDIA_HIDE_ANCILLARY_SUBDRV=y
CONFIG_HID=y
CONFIG_HID_BATTERY_STRENGTH=y
CONFIG_HIDRAW=y
CONFIG_UHID=y
CONFIG_HID_GENERIC=y
CONFIG_HID_A4TECH=y
CONFIG_HID_APPLE=y
CONFIG_HID_BELKIN=y
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
CONFIG_HID_CYPRESS=y
CONFIG_HID_DRAGONRISE=y
CONFIG_HID_EZKEY=y
CONFIG_HID_KYE=y
CONFIG_HID_GYRATION=y
CONFIG_HID_ITE=y
CONFIG_HID_TWINHAN=y
CONFIG_HID_KENSINGTON=y
CONFIG_HID_LOGITECH=y
CONFIG_HID_LOGITECH_DJ=y
CONFIG_HID_LOGITECH_HIDPP=y
CONFIG_HID_REDRAGON=y
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MONTEREY=y
CONFIG_HID_NTRIG=y
CONFIG_HID_PANTHERLORD=y
CONFIG_HID_PETALYNX=y
CONFIG_HID_PLANTRONICS=y
CONFIG_HID_SAMSUNG=y
CONFIG_HID_SUNPLUS=y
CONFIG_HID_GREENASIA=y
CONFIG_HID_SMARTJOYPLUS=y
CONFIG_HID_TOPSEED=y
CONFIG_HID_THRUSTMASTER=y
CONFIG_HID_ZEROPLUS=y
CONFIG_USB_HID=y
CONFIG_USB_HIDDEV=y

[pfps]

A very simple test to perform is to just try to read from the device via cat /dev/hidraw7. If that fails with device busy there is something truly unusual going on. The list of kernel modules appears to be fine

Try ls -l /dev/hidraw*. Lines with a '+' after the permissions bits should correspond to HID++ devices. I expect there to be at least two - one for the receiver and one for the mouse. Try checking each of them the busy problem.

[supermaz]

Its hidraw 5 - 7.
5 can be read, but no output, 6 is the mouse and can be read, 7 cannot, device busy.

BTW, here are the kernel messages:

[    5.854463] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.4/4-1.4:1.0/0003:046D:C548.0006/input/input21
[    5.906183] hid-generic 0003:046D:C548.0006: input,hidraw5: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:00:1d.0-1.4/input0
[    5.907555] input: Logitech USB Receiver Mouse as /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.4/4-1.4:1.1/0003:046D:C548.0007/input/input22
[    5.907885] input: Logitech USB Receiver Consumer Control as /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.4/4-1.4:1.1/0003:046D:C548.0007/input/input23
[    5.959973] input: Logitech USB Receiver System Control as /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.4/4-1.4:1.1/0003:046D:C548.0007/input/input24
[    5.960219] hid-generic 0003:046D:C548.0007: input,hidraw6: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:1d.0-1.4/input1
[    5.962285] hid-generic 0003:046D:C548.0008: hiddev99,hidraw7: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:1d.0-1.4/input2

I wonder if hid-generic is the correct driver for hidraw7?

[pfps]

I see the exact same kernel messages with my Bolt receiver. Solaar uses the device node that on your system is /dev/hidraw7.

So something is going wrong with /dev/hidraw7 before Solaar is involved. I don't know what this could be. Two possibilities are that some driver is misbehaving or some program is locking the device.

Further investigation is going to require expertise that I don't have.

[squadramunter]

@supermaz I assume you did unplug and replug the receiver already? This is what solved the problem for my Unify Receiver and it's working fine for me. Since the message says busy it means Solaar can't lock on that device. When unplugging the receiver it may reconnect properly and Solaar should take care of it.

[pfps]

@supermaz Are you still having the problem? It still looks to me as if something is going wrong before Solaar starts.

[supermaz]

No, no change so far. But I haven't tried different kernel options, yet. Even after a clean restart the hidraw device is in use.

[pfps]

It sure looks as if something is going wrong before Solaar starts. Given that the problem also affects solaar show I don't see that there is any way that the Solaar GUI startup or thread stuff could be involved.

One thing to try is to run solaar -ddd and post the output. This will help show where in Solaar's startup the problem occurs. If it is very early then there is way that Solaar is involved.

[supermaz]

Nothing of interest there. The file is already in use after startup, before solaar is started. So I don't think it is solaar's fault, I just hoped that you guys know which other software or kernel options blocks access.

[pfps]

No, no further information from here. I'm going to close this issue. If you find out the cause you can post to the issue even if it is closed.