Bug 215189

Summary: hci0: unexpected event for opcode 0xfc2f
Product: Drivers Reporter: Paul Menzel (pmenzel+bugzilla.kernel.org)
Component: BluetoothAssignee: linux-bluetooth (linux-bluetooth)
Status: NEW ---    
Severity: normal CC: dront78, shwoseph, wiredknight375
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 5.16-rc1 Subsystem:
Regression: No Bisected commit-id:
Attachments: Linux 5.16-rc1 messages (output of `dmesg`)

Description Paul Menzel 2021-12-01 16:52:51 UTC 
Created attachment 299811 [details]
Linux 5.16-rc1 messages (output of `dmesg`)

On a Dell Latitude E7520 with

    Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface

running Debian sid/unstable, Linux 5.16-rc1 (but has so with older versions too) logs

    [   46.423662] Bluetooth: hci0: unexpected event for opcode 0xfc2f

when starting (or when resuming).

The WWW contains several reports of this issue:

1.  https://debianforum.de/forum/viewtopic.php?t=174717
2.  https://askubuntu.com/questions/1179883/how-to-solve-256966901-bluetooth-hclo-unexpected-event-for-opcode-0xfc2f-mes
3.  https://bugzilla.redhat.com/show_bug.cgi?id=1576865#c15

*[5.2.0-rcx] Bluetooth: hci0: unexpected event for opcode* [1] claims it was introduced by commit f80c5dad7b64 (Bluetooth: Ignore CC events not matching the last HCI command).

Marcel also analyzed the problem [2]:

> so this is the culprit command.
> 
> < HCI Command: Intel Write BD Data (0x3f|0x002f) plen 80
>         Address: 00:00:00:00:00:00 (OUI 00-00-00)
>         ...
> > HCI Event: Command Status (0x0f) plen 4
>       Intel Write BD Data (0x3f|0x002f) ncmd 1
>         Status: Success (0x00)
> > HCI Event: Vendor (0xff) plen 2
>       Intel Write BD Data Complete (0x19)
>         Status: Success (0x00)
> 
> There is actually nothing wrong with it and the firmware bseq file clearly
> says that it is expecting a command status followed by the vendor event. The
> driver however for simplicity reasons is using __hci_cmd_sync_ev and just
> waiting for the vendor event since the command status doesn’t offer any
> useful information in the success case.
> 
> Now I think that in the case of __hci_cmd_sync_ev with an extra event
> expected, we should not print this error when receiving the command status
> since that is clearly a valid response. How to achieve that, I don’t know
> yet. Maybe Joao Paulo has an idea.

I can’t find any responses from Joao Paulo though.

[1]: https://www.spinics.net/lists/kernel/msg3151547.html
[2]: https://www.spinics.net/lists/kernel/msg3153203.html
Comment 1 Ivan 2022-01-18 06:07:04 UTC 
5.16.1 MS-16J4 same problem with
Linux 5.16.1-arch1-1 #1 SMP PREEMPT Sun, 16 Jan 2022 11:39:23 +0000 x86_64 GNU/Linux
Bus 001 Device 004: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
Comment 2 shwoseph 2022-05-08 19:15:02 UTC 
I am suffering from this issue as well. It wouldn’t be so bad except that the message gets printed out to tty1 and messes up my login console on wake from sleep.
Comment 3 Rijnhard Hessel 2022-11-27 18:18:22 UTC 
Forgive me if this isn't related but also seeing the same message with

Bus 001 Device 003: ID 8087:07dc Intel Corp. Bluetooth wireless interface

System:
  Host: HESSEL-MSI-MINT Kernel: 5.15.0-53-generic x86_64 bits: 64
    Desktop: Cinnamon 5.4.12 Distro: Linux Mint 21 Vanessa
Machine:
  Type: Desktop System: Micro-Star product: GE70 2PC v: REV:1.0
    serial: <superuser required>
  Mobo: Micro-Star model: MS-1759 v: REV:0.B serial: <superuser required>
    UEFI: American Megatrends v: E1759IMS.62D date: 04/13/2015

Also the side track also seeing a lot of other issues around powering on the adapter after a suspend resume cycle (quite a few over the web, on launchpad etc)

so was wondering if it could be related.