Hi John, > I've seen timeout errors from HCI commands where it looks like > schedule_timeout() has returned immediately; additional logging for the > error case gives: > > req_status=1 req_result=0 remaining=10000 jiffies > > so the device is still in state HCI_REQ_PEND and the value returned by > schedule_timeout() is the same as the original timeout (HCI_INIT_TIMEOUT > on a system with HZ=1000). > > Use wait_event_interruptible_timeout() instead of open-coding similar > behaviour which is subject to the spurious failure described above. > > Signed-off-by: John Keeping <john@xxxxxxxxxxxx> > --- > I saw problems with the -rt patchset on 4.9 and I'm not convinced that > it's Bluetooth at fault for the problem described above, but I think > this is a nice cleanup even if it's not a bug fix. > > net/bluetooth/hci_request.c | 30 +++++++----------------------- > 1 file changed, 7 insertions(+), 23 deletions(-) patch has been applied to bluetooth-next tree. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
