Bluetooth: qca: If memdump doesn't work, re-enable IBS

Commit Message

Doug Anderson May 18, 2024, 12:02 a.m. UTC

On systems in the field, we are seeing this sometimes in the kernel logs:
  Bluetooth: qca_controller_memdump() hci0: hci_devcd_init Return:-95

This means that _something_ decided that it wanted to get a memdump
but then hci_devcd_init() returned -EOPNOTSUPP (AKA -95).

The cleanup code in qca_controller_memdump() when we get back an error
from hci_devcd_init() undoes most things but forgets to clear
QCA_IBS_DISABLED. One side effect of this is that, during the next
suspend, qca_suspend() will always get a timeout.

Let's fix it so that we clear the bit.

Fixes: 06d3fdfcdf5c ("Bluetooth: hci_qca: Add qcom devcoredump support")
Signed-off-by: Douglas Anderson <[e-mail]>
---
I'm nowhere near an expert on this code so please give extra eyes on
this patch. I also have no idea how to reproduce the problem nor even
how to trigger a memdump to test it. I'd love any advice that folks
could give. ;-)

 drivers/bluetooth/hci_qca.c | 1 +
 1 file changed, 1 insertion(+)

Comments

[e-mail] May 18, 2024, 1:06 a.m. UTC | #1

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=854121

---Test result---

Test Summary:
CheckPatch                    PASS      0.64 seconds
GitLint                       PASS      0.29 seconds
SubjectPrefix                 PASS      0.11 seconds
BuildKernel                   PASS      29.99 seconds
CheckAllWarning               PASS      32.49 seconds
CheckSparse                   PASS      37.61 seconds
CheckSmatch                   FAIL      38.05 seconds
BuildKernel32                 PASS      28.58 seconds
TestRunnerSetup               PASS      518.20 seconds
TestRunner_l2cap-tester       PASS      20.53 seconds
TestRunner_iso-tester         FAIL      33.05 seconds
TestRunner_bnep-tester        PASS      4.76 seconds
TestRunner_mgmt-tester        PASS      112.08 seconds
TestRunner_rfcomm-tester      PASS      7.30 seconds
TestRunner_sco-tester         PASS      14.85 seconds
TestRunner_ioctl-tester       PASS      7.72 seconds
TestRunner_mesh-tester        PASS      5.80 seconds
TestRunner_smp-tester         PASS      6.80 seconds
TestRunner_userchan-tester    PASS      4.98 seconds
IncrementalBuild              PASS      27.90 seconds

Details
##############################
Test: CheckSmatch - FAIL
Desc: Run smatch tool with source
Output:

Segmentation fault (core dumped)
make[4]: *** [scripts/Makefile.build:244: net/bluetooth/hci_core.o] Error 139
make[4]: *** Deleting file 'net/bluetooth/hci_core.o'
make[3]: *** [scripts/Makefile.build:485: net/bluetooth] Error 2
make[2]: *** [scripts/Makefile.build:485: net] Error 2
make[2]: *** Waiting for unfinished jobs....
Segmentation fault (core dumped)
make[4]: *** [scripts/Makefile.build:244: drivers/bluetooth/bcm203x.o] Error 139
make[4]: *** Deleting file 'drivers/bluetooth/bcm203x.o'
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [scripts/Makefile.build:485: drivers/bluetooth] Error 2
make[2]: *** [scripts/Makefile.build:485: drivers] Error 2
make[1]: *** [/github/workspace/src/src/Makefile:1919: .] Error 2
make: *** [Makefile:240: __sub-make] Error 2
##############################
Test: TestRunner_iso-tester - FAIL
Desc: Run iso-tester with test-runner
Output:
Total: 122, Passed: 117 (95.9%), Failed: 1, Not Run: 4

Failed Test Cases
ISO Connect Suspend - Success                        Failed       4.177 seconds


---
Regards,
Linux Bluetooth

Stephen Boyd May 22, 2024, 10:13 p.m. UTC | #2

Quoting Douglas Anderson (2024-05-17 17:02:46)
> On systems in the field, we are seeing this sometimes in the kernel logs:
>   Bluetooth: qca_controller_memdump() hci0: hci_devcd_init Return:-95
>
> This means that _something_ decided that it wanted to get a memdump
> but then hci_devcd_init() returned -EOPNOTSUPP (AKA -95).
>
> The cleanup code in qca_controller_memdump() when we get back an error
> from hci_devcd_init() undoes most things but forgets to clear
> QCA_IBS_DISABLED. One side effect of this is that, during the next
> suspend, qca_suspend() will always get a timeout.
>
> Let's fix it so that we clear the bit.
>
> Fixes: 06d3fdfcdf5c ("Bluetooth: hci_qca: Add qcom devcoredump support")
> Signed-off-by: Douglas Anderson <[e-mail]>
> ---

Reviewed-by: Stephen Boyd <[e-mail]>

Guenter Roeck May 22, 2024, 10:18 p.m. UTC | #3

On Fri, May 17, 2024 at 5:03 PM Douglas Anderson <[e-mail]> wrote:
>
> On systems in the field, we are seeing this sometimes in the kernel logs:
>   Bluetooth: qca_controller_memdump() hci0: hci_devcd_init Return:-95
>
> This means that _something_ decided that it wanted to get a memdump
> but then hci_devcd_init() returned -EOPNOTSUPP (AKA -95).
>
> The cleanup code in qca_controller_memdump() when we get back an error
> from hci_devcd_init() undoes most things but forgets to clear
> QCA_IBS_DISABLED. One side effect of this is that, during the next
> suspend, qca_suspend() will always get a timeout.
>
> Let's fix it so that we clear the bit.
>
> Fixes: 06d3fdfcdf5c ("Bluetooth: hci_qca: Add qcom devcoredump support")
> Signed-off-by: Douglas Anderson <[e-mail]>

Reviewed-by: Guenter Roeck <[e-mail]>

> ---
> I'm nowhere near an expert on this code so please give extra eyes on
> this patch. I also have no idea how to reproduce the problem nor even
> how to trigger a memdump to test it. I'd love any advice that folks
> could give. ;-)
>
>  drivers/bluetooth/hci_qca.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index 0c9c9ee56592..1ef12f5a115d 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -1090,6 +1090,7 @@ static void qca_controller_memdump(struct work_struct *work)
>                                 qca->memdump_state = QCA_MEMDUMP_COLLECTED;
>                                 cancel_delayed_work(&qca->ctrl_memdump_timeout);
>                                 clear_bit(QCA_MEMDUMP_COLLECTION, &qca->flags);
> +                               clear_bit(QCA_IBS_DISABLED, &qca->flags);
>                                 mutex_unlock(&qca->hci_memdump_lock);
>                                 return;
>                         }
> --
> 2.45.0.rc1.225.g2a3ae87e7f-goog
>

Doug Anderson June 10, 2024, 11:52 p.m. UTC | #4

Hi,

On Fri, May 17, 2024 at 5:03 PM Douglas Anderson <[e-mail]> wrote:
>
> On systems in the field, we are seeing this sometimes in the kernel logs:
>   Bluetooth: qca_controller_memdump() hci0: hci_devcd_init Return:-95
>
> This means that _something_ decided that it wanted to get a memdump
> but then hci_devcd_init() returned -EOPNOTSUPP (AKA -95).
>
> The cleanup code in qca_controller_memdump() when we get back an error
> from hci_devcd_init() undoes most things but forgets to clear
> QCA_IBS_DISABLED. One side effect of this is that, during the next
> suspend, qca_suspend() will always get a timeout.
>
> Let's fix it so that we clear the bit.
>
> Fixes: 06d3fdfcdf5c ("Bluetooth: hci_qca: Add qcom devcoredump support")
> Signed-off-by: Douglas Anderson <[e-mail]>
> ---
> I'm nowhere near an expert on this code so please give extra eyes on
> this patch. I also have no idea how to reproduce the problem nor even
> how to trigger a memdump to test it. I'd love any advice that folks
> could give. ;-)
>
>  drivers/bluetooth/hci_qca.c | 1 +
>  1 file changed, 1 insertion(+)

Totally fine if you just need more time, but I wanted to follow up and
check to see if there is anything you need me to do to help move this
patch forward. If not, I'll snooze this patch and check up on it again
sometime around the end of July.


Thanks!

-Doug

Doug Anderson July 31, 2024, 8:29 p.m. UTC | #5

Hi,

On Mon, Jun 10, 2024 at 4:52 PM Doug Anderson <[e-mail]> wrote:
>
> Hi,
>
> On Fri, May 17, 2024 at 5:03 PM Douglas Anderson <[e-mail]> wrote:
> >
> > On systems in the field, we are seeing this sometimes in the kernel logs:
> >   Bluetooth: qca_controller_memdump() hci0: hci_devcd_init Return:-95
> >
> > This means that _something_ decided that it wanted to get a memdump
> > but then hci_devcd_init() returned -EOPNOTSUPP (AKA -95).
> >
> > The cleanup code in qca_controller_memdump() when we get back an error
> > from hci_devcd_init() undoes most things but forgets to clear
> > QCA_IBS_DISABLED. One side effect of this is that, during the next
> > suspend, qca_suspend() will always get a timeout.
> >
> > Let's fix it so that we clear the bit.
> >
> > Fixes: 06d3fdfcdf5c ("Bluetooth: hci_qca: Add qcom devcoredump support")
> > Signed-off-by: Douglas Anderson <[e-mail]>
> > ---
> > I'm nowhere near an expert on this code so please give extra eyes on
> > this patch. I also have no idea how to reproduce the problem nor even
> > how to trigger a memdump to test it. I'd love any advice that folks
> > could give. ;-)
> >
> >  drivers/bluetooth/hci_qca.c | 1 +
> >  1 file changed, 1 insertion(+)
>
> Totally fine if you just need more time, but I wanted to follow up and
> check to see if there is anything you need me to do to help move this
> patch forward. If not, I'll snooze this patch and check up on it again
> sometime around the end of July.

It being the end of July, I'm back to check up on this patch. I
checked mainline and bluetooth-next and I don't see any sign of this
patch. Is there anything blocking it? Do you need me to repost it or
take any other actions?

Thanks!

-Doug

Doug Anderson Aug. 21, 2024, 9:18 p.m. UTC | #6

Hi,

On Wed, Jul 31, 2024 at 1:29 PM Doug Anderson <[e-mail]> wrote:
>
> Hi,
>
> On Mon, Jun 10, 2024 at 4:52 PM Doug Anderson <[e-mail]> wrote:
> >
> > Hi,
> >
> > On Fri, May 17, 2024 at 5:03 PM Douglas Anderson <[e-mail]> wrote:
> > >
> > > On systems in the field, we are seeing this sometimes in the kernel logs:
> > >   Bluetooth: qca_controller_memdump() hci0: hci_devcd_init Return:-95
> > >
> > > This means that _something_ decided that it wanted to get a memdump
> > > but then hci_devcd_init() returned -EOPNOTSUPP (AKA -95).
> > >
> > > The cleanup code in qca_controller_memdump() when we get back an error
> > > from hci_devcd_init() undoes most things but forgets to clear
> > > QCA_IBS_DISABLED. One side effect of this is that, during the next
> > > suspend, qca_suspend() will always get a timeout.
> > >
> > > Let's fix it so that we clear the bit.
> > >
> > > Fixes: 06d3fdfcdf5c ("Bluetooth: hci_qca: Add qcom devcoredump support")
> > > Signed-off-by: Douglas Anderson <[e-mail]>
> > > ---
> > > I'm nowhere near an expert on this code so please give extra eyes on
> > > this patch. I also have no idea how to reproduce the problem nor even
> > > how to trigger a memdump to test it. I'd love any advice that folks
> > > could give. ;-)
> > >
> > >  drivers/bluetooth/hci_qca.c | 1 +
> > >  1 file changed, 1 insertion(+)
> >
> > Totally fine if you just need more time, but I wanted to follow up and
> > check to see if there is anything you need me to do to help move this
> > patch forward. If not, I'll snooze this patch and check up on it again
> > sometime around the end of July.
>
> It being the end of July, I'm back to check up on this patch. I
> checked mainline and bluetooth-next and I don't see any sign of this
> patch. Is there anything blocking it? Do you need me to repost it or
> take any other actions?

I feel like I'm shouting into the wind. Am I following some incorrect
process for submitting this patch? Can anyone suggest something I
should do differently to get a response here?

Thanks!

-Doug

Luiz Augusto von Dentz Aug. 21, 2024, 10:10 p.m. UTC | #7

Hi Doug,

On Wed, Aug 21, 2024 at 5:19 PM Doug Anderson <[e-mail]> wrote:
>
> Hi,
>
> On Wed, Jul 31, 2024 at 1:29 PM Doug Anderson <[e-mail]> wrote:
> >
> > Hi,
> >
> > On Mon, Jun 10, 2024 at 4:52 PM Doug Anderson <[e-mail]> wrote:
> > >
> > > Hi,
> > >
> > > On Fri, May 17, 2024 at 5:03 PM Douglas Anderson <[e-mail]> wrote:
> > > >
> > > > On systems in the field, we are seeing this sometimes in the kernel logs:
> > > >   Bluetooth: qca_controller_memdump() hci0: hci_devcd_init Return:-95
> > > >
> > > > This means that _something_ decided that it wanted to get a memdump
> > > > but then hci_devcd_init() returned -EOPNOTSUPP (AKA -95).
> > > >
> > > > The cleanup code in qca_controller_memdump() when we get back an error
> > > > from hci_devcd_init() undoes most things but forgets to clear
> > > > QCA_IBS_DISABLED. One side effect of this is that, during the next
> > > > suspend, qca_suspend() will always get a timeout.
> > > >
> > > > Let's fix it so that we clear the bit.
> > > >
> > > > Fixes: 06d3fdfcdf5c ("Bluetooth: hci_qca: Add qcom devcoredump support")
> > > > Signed-off-by: Douglas Anderson <[e-mail]>
> > > > ---
> > > > I'm nowhere near an expert on this code so please give extra eyes on
> > > > this patch. I also have no idea how to reproduce the problem nor even
> > > > how to trigger a memdump to test it. I'd love any advice that folks
> > > > could give. ;-)
> > > >
> > > >  drivers/bluetooth/hci_qca.c | 1 +
> > > >  1 file changed, 1 insertion(+)
> > >
> > > Totally fine if you just need more time, but I wanted to follow up and
> > > check to see if there is anything you need me to do to help move this
> > > patch forward. If not, I'll snooze this patch and check up on it again
> > > sometime around the end of July.
> >
> > It being the end of July, I'm back to check up on this patch. I
> > checked mainline and bluetooth-next and I don't see any sign of this
> > patch. Is there anything blocking it? Do you need me to repost it or
> > take any other actions?
>
> I feel like I'm shouting into the wind. Am I following some incorrect
> process for submitting this patch? Can anyone suggest something I
> should do differently to get a response here?

Just resend it since it is no longer listed on patchwork it felt off my radar.

> Thanks!
>
> -Doug

Patch

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 0c9c9ee56592..1ef12f5a115d 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1090,6 +1090,7 @@  static void qca_controller_memdump(struct work_struct *work)
 				qca->memdump_state = QCA_MEMDUMP_COLLECTED;
 				cancel_delayed_work(&qca->ctrl_memdump_timeout);
 				clear_bit(QCA_MEMDUMP_COLLECTION, &qca->flags);
+				clear_bit(QCA_IBS_DISABLED, &qca->flags);
 				mutex_unlock(&qca->hci_memdump_lock);
 				return;
 			}