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

            Bug ID: 215189
           Summary: hci0: unexpected event for opcode 0xfc2f
           Product: Drivers
           Version: 2.5
    Kernel Version: 5.16-rc1
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Bluetooth
          Assignee: linux-bluetooth@vger.kernel.org
          Reporter: pmenzel+bugzilla.kernel.org@molgen.mpg.de
        Regression: No

Created attachment 299811
  --> https://bugzilla.kernel.org/attachment.cgi?id=299811&action=edit
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)
        ...

quoted

HCI Event: Command Status (0x0f) plen 4

      Intel Write BD Data (0x3f|0x002f) ncmd 1
        Status: Success (0x00)

quoted

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

-- 
You may reply to this email to add a comment.

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