Bug 86931 - hid-generic 0005:099A:0500.0001: unknown main item tag 0x0
Summary: hid-generic 0005:099A:0500.0001: unknown main item tag 0x0
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Bluetooth (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: linux-bluetooth@vger.kernel.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-25 20:23 UTC by Cristian Aravena Romero
Modified: 2024-02-22 12:18 UTC (History)
9 users (show)

See Also:
Kernel Version: 3.16.4
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Cristian Aravena Romero 2014-10-25 20:23:14 UTC
Message with Mouse Bluetooth

[ 32.960478] hid-generic 0005:099A:0500.0001: unknown main item tag 0x0

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1385113
Comment 1 Claudio Saavedra 2015-05-04 09:35:57 UTC
This is still present in 4.0.0. Bluetooth keyboard disconnects, bluetoothd seems to crash, etc.

Do you need any further information to help debug this? This bug makes the bluetooth keyboard unusable.
Comment 2 Stephan Diestelhorst 2016-03-29 19:52:54 UTC
Same in 4.2.0 (-34-generic in Ubuntu 15.10).
Comment 3 jbMacAZ 2016-03-30 17:53:32 UTC
Bluetooth behavior was good in ubuntu 15.10 - bluez5.35, blueman device manager and kernel 4.3.6.  I use a bt mouse and OEM bt keydock (Asus T100-CHI)

Starting with 4.4 thru 4.6-rc1-next*, I have to open blueman's device manager to search for devices after idle timeouts.  I also need to leave the device manager dialogue open/minimized to prevent rapid loss of connection.  Device pairing is remembered, but manually searching is difficult when the pointing devices stop working.  My test setup has a usb mouse as a workaround.

dmesg has "unknown main item tag 0x0" after each idle timeout".  If I move mouse during boot, it will auto-connect, but it then suffers a rapid timeout soon after booting.  See dmesg posted at #114561.  It looks like something is incrementing the bluetooth input assignment # when anything times out.
Comment 4 robsmith11 2018-01-12 09:21:14 UTC
Has anyone solved this yet??

I have the same issue with a bluetooth keyboard and kernel 4.14.
Comment 5 jbMacAZ 2018-01-12 17:26:47 UTC
The issue was fixed for the Asus T100 (baytrail) 2-in-1 family.  See this commit.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?id=c4c285da1ee18582ace366f07e56e355c20ebc49 which is in kernel 4.15. 

You could try adding the quirk for your device.  

(No kernel maintainer has acknowledged this bug report.)
Comment 6 mybigspam 2019-01-30 18:27:54 UTC
It's not clear from the description what is the problem exactly?
I have similar symptoms with "unknown main item tag 0x0" message after timeout.

But my problem is that bluetooth keyboard disconnects on timeout (which is normal), but then, on the first key press it's just loss, while the keyboard reconnects successfully.

It doesn't occurs on the same system with Windows 10 - the key doesn't lost on reconnect.

I wonder if it can be the same problem.
Comment 7 Jeroen Jeurissen 2020-10-30 10:05:51 UTC
I have the same issues with my bluetooth keybloard on 5.9.2-1.g4133ad1-default (Tumbleweed).

hid-generic 0005:04CA:006C.0009: unknown main item tag 0x0

Very annoying.
Comment 8 Jeroen Jeurissen 2021-01-08 14:31:35 UTC
Bug still present in 5.10.4-1-default
Comment 9 Roman Evstifeev 2021-07-18 10:47:54 UTC
The bug is still here in 5.12.13 with asaus m-rbb93 logitech b370 mouse. After some time (unpredictable, can be few hours or few minutes) mouse pointer stops responding, though mouse appears conneceted in the bluetoothctl.

> bluetoothctl 
Agent registered
[Bluetooth Travel Mouse]# info
Device 00:07:61:68:D2:9E (public)
        Name: Bluetooth Travel Mouse
        Alias: Bluetooth Travel Mouse
        Class: 0x00002580
        Icon: input-mouse
        Paired: yes
        Trusted: yes
        Blocked: no
        Connected: yes
        WakeAllowed: yes
        LegacyPairing: no
        UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
        UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
        Modalias: usb:v046DpB002d4809

journalctl and dmesg is silent when the mouse stops responding. Is there any other way to debug this?

When mouse is first connected, dmesg has the message mentioned as the topic of this bug:
[185307.429898] hid-generic 0005:046D:B002.002C: input,hidraw1: BLUETOOTH HID v48.09 Mouse [Bluetooth Travel Mouse] on dc:e9:94:7e:5f:86
[187430.340610] hid-generic 0005:046D:B002.002D: unknown main item tag 0x0
[187430.340668] input: Bluetooth Travel Mouse as /devices/pci0000:00/0000:00:08.1/0000:05:00.4/usb3/3-3/3-3:1.0/bluetooth/hci0/hci0:1/0005:046D:B002.002D/input/input104

 (In reply to jbMacAZ from comment #5)
> The issue was fixed for the Asus T100 (baytrail) 2-in-1 family.  See this
> commit.
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
> commit/?id=c4c285da1ee18582ace366f07e56e355c20ebc49 which is in kernel 4.15. 

Is there a way to enable this system-wide without patching a kernel, for a quick test?

I tried to add btusb.enable_autosuspend=n kernel paremeter:

# cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-5.12.13-1-default root=UUID=ece1a448-6944-4f34-a61c-1742fde2ac3c splash=silent psi=1 nvidia-drm.modeset=1 btusb.enable_autosuspend=n quiet mitigations=auto

# systool -v -m btusb            
Module = "btusb"

  Attributes:
    coresize            = "69632"
    initsize            = "0"
    initstate           = "live"
    refcnt              = "0"
    srcversion          = "8EADE2557C147180496F74C"
    taint               = ""
    uevent              = <store method only>
    version             = "0.8"

  Parameters:
    disable_scofix      = "N"
    enable_autosuspend  = "N"
    force_scofix        = "N"
    reset               = "Y"

But this does not resolve the bug
Comment 10 Kai Krakow 2021-07-19 06:58:32 UTC
"unknown main tag item 0x0" comes from the HID layer, it has nothing to do with Bluetooth or connection stability. It's usually a stray NUL character at the end of the HID descriptor which the kernel safely ignores but still logs. In my own driver development (xpadneo), I just shorten the HID descriptor by one byte if it ends with NUL because the devices I work with are known to NUL-terminate their HID descriptors.

Maybe the kernel should do the same: If the last HID descriptor byte is a NUL-byte, it should simply shorten the HID descriptor by one byte, essentially cutting the offending byte off, and the message would be gone. Other than a log message, it has no consequences in the kernel, it comes from a completely different layer that's not related to Bluetooth at all.
Comment 11 Christian Kujau 2024-02-22 12:18:09 UTC
Happens here with an Apple Magic Mouse A1296:

kernel: magicmouse 0005:05AC:030D.000D: unknown main item tag 0x0
kernel: input: Maus as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/bluetooth/hci0/hci0:512/0005:05AC:030D.000D/input/input34
kernel: magicmouse 0005:05AC:030D.000D: input,hidraw4: BLUETOOTH HID v3.06 Mouse [Maus] on e4:70:b8:3f:cc:93

$ hwinfo --bluetooth
09: USB 00.0: 11500 Bluetooth Device                            
  [Created at usb.122]
  Unique ID: X7GA.GS0ueMFUyi1
  Parent ID: k4bc.2DFUsyrieMD
  SysFS ID: /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0
  SysFS BusID: 1-7:1.0
  Hardware Class: bluetooth
  Model: "Intel Bluetooth wireless interface"
  Hotplug: USB
  Vendor: usb 0x8087 "Intel Corp."
  Device: usb 0x0a2b "Bluetooth wireless interface"
  Revision: "0.10"
  Driver: "btusb"
  Driver Modules: "btusb"
  Speed: 12 Mbps
  Module Alias: "usb:v8087p0A2Bd0010dcE0dsc01dp01icE0isc01ip01in00"
  Driver Info #0:
    Driver Status: btusb is active
    Driver Activation Cmd: "modprobe btusb"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #14 (Hub)

Note You need to log in before you can comment on or make changes to this bug.