Skip to contentSkip to conversation

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

Bug 86931 [email protected] 2 participants 12 messages Mar 30, 2016 – Jan 12 1 message not in the archive Bluetooth drivers

lore
Share & tools
lore

[email protected]

author
#1 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=86931

jbMacAZ <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #3 from jbMacAZ <[email protected]> ---
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.

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#2 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=86931

[email protected] changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #4 from [email protected] ---
Has anyone solved this yet??

I have the same issue with a bluetooth keyboard and kernel 4.14.

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#3 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=86931

--- Comment #5 from jbMacAZ ([email protected]) ---
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.)

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#4 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=86931

--- Comment #6 from [email protected] ---
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.

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#5 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=86931

Jeroen Jeurissen ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #7 from Jeroen Jeurissen ([email protected]) --- 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.

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#7 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=86931

Roman Evstifeev ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #9 from Roman Evstifeev ([email protected]) --- 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.

Quoted 1 line

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)

Quoted 4 lines

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

Signature · 4 lines
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.
author
#8 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=86931

Kai Krakow ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #10 from Kai Krakow ([email protected]) --- "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.

Signature · 4 lines
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.
#9 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=86931

--- Comment #11 from Christian Kujau ([email protected]) --- 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)
Signature · 4 lines
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.
#10 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=86931

Randy Dunlap ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #12 from Randy Dunlap ([email protected]) --- This message is now (as of June-2025) rate-limited, so there should not be so much flooding of the log. AFAIK the underlying cause still has not been determined.

Patch:
commit 4051ead99888

Author: Li Chen <[email protected]>
Date:   Fri Jun 20 20:02:31 2025 +0800

HID: rate-limit hid_warn to prevent log flooding

Signature · 4 lines
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.
#11 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=86931

--- Comment #13 from Kai Krakow ([email protected]) --- Randy,

the underlying issue is quite easy to understand:

All Microsoft Xbox controllers are sending a NUL terminated HID descriptor block. If we strip it away for those devices, the message is gone. This is probably true for some other vendors (as reported here for Apple Magic Mouse).

We are doing it here around these lines to avoid the warning for Xbox controllers:
https://github.com/atar-axis/xpadneo/commit/1e6b074506b85d03d2636beca528177f482029b8

So maybe the HID parser should just ignore a single trailing NUL byte and accept that some device vendors just do that.

OTOH, it may be useful to warn about it, so device developers can properly fix their HID descriptors. And for that case, rate limiting is the proper implementation to work around other side effects (like overwhelming an UART console).

Signature · 4 lines
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.
#12 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=86931

Bastien Nocera ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |NEEDINFO
                 CC|                            |[email protected]

--- Comment #14 from Bastien Nocera ([email protected]) --- This should have been fixed by:
https://github.com/bluez/bluez/commit/2645d3f662ebe8e601df628432886d3712b421b3
which will be in the next bluez release after 5.85.

You might need to re-pair your device, would appreciate a test from someone who's seen the problem.

Signature · 4 lines
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.