** Description changed: [ Impact ] On some machine with Mediatek USB bluetooth controller, activate scanning will lead to system hang. This is due to unexpected null pointer dereference in the set up flow. [ Fix ] Cherry-pick one commit from mainline linux: - 61c5a3def90a (Bluetooth: btmtk: adjust the position to init iso data + 61c5a3def90a (Bluetooth: btmtk: adjust the position to init iso data anchor) - [ Test ] 1. Boot into the kenrel 2. Run bluetoothctl 3. In the bluetoothctl shell, run "scan on" 4. The MTK bluetooth usb device should be able to scan, and system should not hang. + + [ Where problems could occur ] + + The call trace in the upstream commit shows that the intention for the + patch is to fix what was happening unexpected USB disconnect. However, + here in 6.11-oem the btusb_mtk_disconnect() in the call trace, which is + what usb_kill_anchored_urbs() an uninitailized usb anchor and lead to + the error, is not even implemented. + + The root cause in 6.11-oem seems to be the unexpected shutdown or + suspend. They all lead to calling the usb_kill_anchored_urbs() before + the same btmtk_data->isopkt_anchor is initialized by the + init_usb_anchor(). That's probably why the patch could fix the issue + here as well. + + The upstream patch author didn't state on when or why such "unexpected + USB disconnect during setup" might happen.
** Description changed: [ Impact ] On some machine with Mediatek USB bluetooth controller, activate scanning will lead to system hang. This is due to unexpected null pointer dereference in the set up flow. [ Fix ] Cherry-pick one commit from mainline linux: 61c5a3def90a (Bluetooth: btmtk: adjust the position to init iso data anchor) [ Test ] 1. Boot into the kenrel 2. Run bluetoothctl 3. In the bluetoothctl shell, run "scan on" 4. The MTK bluetooth usb device should be able to scan, and system should not hang. [ Where problems could occur ] The call trace in the upstream commit shows that the intention for the patch is to fix what was happening unexpected USB disconnect. However, here in 6.11-oem the btusb_mtk_disconnect() in the call trace, which is what usb_kill_anchored_urbs() an uninitailized usb anchor and lead to the error, is not even implemented. - The root cause in 6.11-oem seems to be the unexpected shutdown or - suspend. They all lead to calling the usb_kill_anchored_urbs() before - the same btmtk_data->isopkt_anchor is initialized by the - init_usb_anchor(). That's probably why the patch could fix the issue - here as well. + From the call trace collected we collected, the code path seems to be + btusb_disconnect()->hci_unregister_dev()->btmtk shutdwn callback. + However they all lead to calling the usb_kill_anchored_urbs() before the + same btmtk_data->isopkt_anchor is initialized by the init_usb_anchor(). + That's probably why the patch could fix the issue here as well. The upstream patch author didn't state on when or why such "unexpected USB disconnect during setup" might happen. ** Description changed: [ Impact ] On some machine with Mediatek USB bluetooth controller, activate scanning will lead to system hang. This is due to unexpected null pointer dereference in the set up flow. [ Fix ] Cherry-pick one commit from mainline linux: 61c5a3def90a (Bluetooth: btmtk: adjust the position to init iso data anchor) [ Test ] 1. Boot into the kenrel 2. Run bluetoothctl 3. In the bluetoothctl shell, run "scan on" 4. The MTK bluetooth usb device should be able to scan, and system should not hang. [ Where problems could occur ] The call trace in the upstream commit shows that the intention for the patch is to fix what was happening unexpected USB disconnect. However, here in 6.11-oem the btusb_mtk_disconnect() in the call trace, which is what usb_kill_anchored_urbs() an uninitailized usb anchor and lead to the error, is not even implemented. From the call trace collected we collected, the code path seems to be btusb_disconnect()->hci_unregister_dev()->btmtk shutdwn callback. However they all lead to calling the usb_kill_anchored_urbs() before the same btmtk_data->isopkt_anchor is initialized by the init_usb_anchor(). That's probably why the patch could fix the issue here as well. - The upstream patch author didn't state on when or why such "unexpected - USB disconnect during setup" might happen. + The upstream patch author didn't state when or why such "unexpected USB + disconnect during setup" might happen. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2092473 Title: [SRU] Fix system hang issue caused by the btmtk driver To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2092473/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
