| Message ID | 20240517170246.1.Ia769fe5fbeaa6aca2edfb01b82eb7df0c6955459@changeid |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Bluetooth: qca: If memdump doesn't work, re-enable IBS | expand |
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
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 <dianders@chromium.org> > --- Reviewed-by: Stephen Boyd <swboyd@chromium.org>
On Fri, May 17, 2024 at 5:03 PM Douglas Anderson <dianders@chromium.org> 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 <dianders@chromium.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> > --- > 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 >
Hi, On Fri, May 17, 2024 at 5:03 PM Douglas Anderson <dianders@chromium.org> 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 <dianders@chromium.org> > --- > 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
Hi, On Mon, Jun 10, 2024 at 4:52 PM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Fri, May 17, 2024 at 5:03 PM Douglas Anderson <dianders@chromium.org> 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 <dianders@chromium.org> > > --- > > 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
Hi, On Wed, Jul 31, 2024 at 1:29 PM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Mon, Jun 10, 2024 at 4:52 PM Doug Anderson <dianders@chromium.org> wrote: > > > > Hi, > > > > On Fri, May 17, 2024 at 5:03 PM Douglas Anderson <dianders@chromium.org> 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 <dianders@chromium.org> > > > --- > > > 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
Hi Doug, On Wed, Aug 21, 2024 at 5:19 PM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Wed, Jul 31, 2024 at 1:29 PM Doug Anderson <dianders@chromium.org> wrote: > > > > Hi, > > > > On Mon, Jun 10, 2024 at 4:52 PM Doug Anderson <dianders@chromium.org> wrote: > > > > > > Hi, > > > > > > On Fri, May 17, 2024 at 5:03 PM Douglas Anderson <dianders@chromium.org> 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 <dianders@chromium.org> > > > > --- > > > > 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
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; }
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 <dianders@chromium.org> --- 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(+)