Re: [PATCH 2/2] bluetooth: raise HCI_CMD_TIMEOUT from 2s to 8s
Hi Alexander,
>>> The reasoning to do this is the following:
>>>
>>> - If a timeout occurs, the HCI-communication is broken afterwards and the
>>> dongle isn't usable anymore.
>>> - If it works after e.g. waiting 4s everyone is still happy but if it
>>> just breaks after only waiting 2s nothing is gained.
>>> - Having to wait some more seconds until an error occurs doesn't change
>>> anything.
>>>
>>> So there is no disadvantage in rasing the timeout but a great advantage
>>> in case the dongle needs more than 2s to process an HCI command.
>>> E.g. I had sometimes HCI command timeouts at boot (but never after the BT
>>> stack
>>> was successfull started). I assume the reason might be the USB-probing which
>>> happend before through the bootloader, which might have confused the dongle
>>> such that it needs a bit more time, but I'm not sure.
>>>
>>> Together with the patch which limits the timeout only to the actual time the
>>> dongle needs to process an HCI command (and doesn't include the time the
>>> kernel needs to process the answer to an HCI command), my problems were
>>> gone.
>>>
>>> Signed-off-by: Alexander Holler
>>> ---
>>> include/net/bluetooth/hci.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
>>> index be150cf..d50fd34 100644
>>> --- a/include/net/bluetooth/hci.h
>>> +++ b/include/net/bluetooth/hci.h
>>> @@ -180,7 +180,7 @@ enum {
>>> #define HCI_DISCONN_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */
>>> #define HCI_PAIRING_TIMEOUT msecs_to_jiffies(6) /* 60 seconds */
>>> #define HCI_INIT_TIMEOUTmsecs_to_jiffies(1) /* 10 seconds */
>>> -#define HCI_CMD_TIMEOUTmsecs_to_jiffies(2000) /* 2 seconds */
>>> +#define HCI_CMD_TIMEOUTmsecs_to_jiffies(8000) /* 8 seconds */
>>> #define HCI_ACL_TX_TIMEOUT msecs_to_jiffies(45000) /* 45 seconds */
>>> #define HCI_AUTO_OFF_TIMEOUTmsecs_to_jiffies(2000) /* 2 seconds */
>>> #define HCI_POWER_OFF_TIMEOUT msecs_to_jiffies(5000) /* 5 seconds */
>>
>> I think moving the command timeout handling into a delayed work struct might
>> actually solve this problem nicely and does not force us to increase the
>> timeout. A chip that does not respond for 8 seconds is a pretty bad chip.
>
> As I said in another mail, I don't think it is the chip. On the system
> where I'm experiencing these timeouts there's still the USB-subsysten
> inbetween. And this system boots from USB too, which means there's a lot
> of other traffic on the USB-bus besides the one for the USB-BT-dongle.
> And I don't know how the USB-stack (and hw) schedules the traffic, if he
> is able to schedule that at all.
I posted an experimental patch for changing cmd_timer into a delayed_work item
and this might solve your scheduling problem. However that patch is untested
and might needs some additional thinking on which queue the delayed work should
be scheduled on. Nevertheless, you see the direction that we should explore
first.
The L2CAP layer is not using struct timer_list at all anymore and in general we
should remove timer_list usage from the Bluetooth subsystem since we do all our
command processing in a workqueue. At least for lower protocols like HCI,
L2CAP, SMP and A2DP.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] bluetooth: raise HCI_CMD_TIMEOUT from 2s to 8s
Am 31.05.2014 07:32, schrieb Marcel Holtmann:
> Hi Alexander,
>
>> The reasoning to do this is the following:
>>
>> - If a timeout occurs, the HCI-communication is broken afterwards and the
>> dongle isn't usable anymore.
>> - If it works after e.g. waiting 4s everyone is still happy but if it
>> just breaks after only waiting 2s nothing is gained.
>> - Having to wait some more seconds until an error occurs doesn't change
>> anything.
>>
>> So there is no disadvantage in rasing the timeout but a great advantage
>> in case the dongle needs more than 2s to process an HCI command.
>> E.g. I had sometimes HCI command timeouts at boot (but never after the BT
>> stack
>> was successfull started). I assume the reason might be the USB-probing which
>> happend before through the bootloader, which might have confused the dongle
>> such that it needs a bit more time, but I'm not sure.
>>
>> Together with the patch which limits the timeout only to the actual time the
>> dongle needs to process an HCI command (and doesn't include the time the
>> kernel needs to process the answer to an HCI command), my problems were gone.
>>
>> Signed-off-by: Alexander Holler
>> ---
>> include/net/bluetooth/hci.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
>> index be150cf..d50fd34 100644
>> --- a/include/net/bluetooth/hci.h
>> +++ b/include/net/bluetooth/hci.h
>> @@ -180,7 +180,7 @@ enum {
>> #define HCI_DISCONN_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */
>> #define HCI_PAIRING_TIMEOUT msecs_to_jiffies(6) /* 60 seconds */
>> #define HCI_INIT_TIMEOUT msecs_to_jiffies(1) /* 10 seconds */
>> -#define HCI_CMD_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */
>> +#define HCI_CMD_TIMEOUT msecs_to_jiffies(8000) /* 8 seconds */
>> #define HCI_ACL_TX_TIMEOUT msecs_to_jiffies(45000) /* 45 seconds */
>> #define HCI_AUTO_OFF_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */
>> #define HCI_POWER_OFF_TIMEOUTmsecs_to_jiffies(5000) /* 5 seconds */
>
> I think moving the command timeout handling into a delayed work struct might
> actually solve this problem nicely and does not force us to increase the
> timeout. A chip that does not respond for 8 seconds is a pretty bad chip.
As I said in another mail, I don't think it is the chip. On the system
where I'm experiencing these timeouts there's still the USB-subsysten
inbetween. And this system boots from USB too, which means there's a lot
of other traffic on the USB-bus besides the one for the USB-BT-dongle.
And I don't know how the USB-stack (and hw) schedules the traffic, if he
is able to schedule that at all.
Regards,
Alexander
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] bluetooth: raise HCI_CMD_TIMEOUT from 2s to 8s
Am 31.05.2014 07:32, schrieb Marcel Holtmann:
Hi Alexander,
The reasoning to do this is the following:
- If a timeout occurs, the HCI-communication is broken afterwards and the
dongle isn't usable anymore.
- If it works after e.g. waiting 4s everyone is still happy but if it
just breaks after only waiting 2s nothing is gained.
- Having to wait some more seconds until an error occurs doesn't change
anything.
So there is no disadvantage in rasing the timeout but a great advantage
in case the dongle needs more than 2s to process an HCI command.
E.g. I had sometimes HCI command timeouts at boot (but never after the BT
stack
was successfull started). I assume the reason might be the USB-probing which
happend before through the bootloader, which might have confused the dongle
such that it needs a bit more time, but I'm not sure.
Together with the patch which limits the timeout only to the actual time the
dongle needs to process an HCI command (and doesn't include the time the
kernel needs to process the answer to an HCI command), my problems were gone.
Signed-off-by: Alexander Holler hol...@ahsoftware.de
---
include/net/bluetooth/hci.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index be150cf..d50fd34 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -180,7 +180,7 @@ enum {
#define HCI_DISCONN_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */
#define HCI_PAIRING_TIMEOUT msecs_to_jiffies(6) /* 60 seconds */
#define HCI_INIT_TIMEOUT msecs_to_jiffies(1) /* 10 seconds */
-#define HCI_CMD_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */
+#define HCI_CMD_TIMEOUT msecs_to_jiffies(8000) /* 8 seconds */
#define HCI_ACL_TX_TIMEOUT msecs_to_jiffies(45000) /* 45 seconds */
#define HCI_AUTO_OFF_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */
#define HCI_POWER_OFF_TIMEOUTmsecs_to_jiffies(5000) /* 5 seconds */
I think moving the command timeout handling into a delayed work struct might
actually solve this problem nicely and does not force us to increase the
timeout. A chip that does not respond for 8 seconds is a pretty bad chip.
As I said in another mail, I don't think it is the chip. On the system
where I'm experiencing these timeouts there's still the USB-subsysten
inbetween. And this system boots from USB too, which means there's a lot
of other traffic on the USB-bus besides the one for the USB-BT-dongle.
And I don't know how the USB-stack (and hw) schedules the traffic, if he
is able to schedule that at all.
Regards,
Alexander
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] bluetooth: raise HCI_CMD_TIMEOUT from 2s to 8s
Hi Alexander,
The reasoning to do this is the following:
- If a timeout occurs, the HCI-communication is broken afterwards and the
dongle isn't usable anymore.
- If it works after e.g. waiting 4s everyone is still happy but if it
just breaks after only waiting 2s nothing is gained.
- Having to wait some more seconds until an error occurs doesn't change
anything.
So there is no disadvantage in rasing the timeout but a great advantage
in case the dongle needs more than 2s to process an HCI command.
E.g. I had sometimes HCI command timeouts at boot (but never after the BT
stack
was successfull started). I assume the reason might be the USB-probing which
happend before through the bootloader, which might have confused the dongle
such that it needs a bit more time, but I'm not sure.
Together with the patch which limits the timeout only to the actual time the
dongle needs to process an HCI command (and doesn't include the time the
kernel needs to process the answer to an HCI command), my problems were
gone.
Signed-off-by: Alexander Holler hol...@ahsoftware.de
---
include/net/bluetooth/hci.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index be150cf..d50fd34 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -180,7 +180,7 @@ enum {
#define HCI_DISCONN_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */
#define HCI_PAIRING_TIMEOUT msecs_to_jiffies(6) /* 60 seconds */
#define HCI_INIT_TIMEOUTmsecs_to_jiffies(1) /* 10 seconds */
-#define HCI_CMD_TIMEOUTmsecs_to_jiffies(2000) /* 2 seconds */
+#define HCI_CMD_TIMEOUTmsecs_to_jiffies(8000) /* 8 seconds */
#define HCI_ACL_TX_TIMEOUT msecs_to_jiffies(45000) /* 45 seconds */
#define HCI_AUTO_OFF_TIMEOUTmsecs_to_jiffies(2000) /* 2 seconds */
#define HCI_POWER_OFF_TIMEOUT msecs_to_jiffies(5000) /* 5 seconds */
I think moving the command timeout handling into a delayed work struct might
actually solve this problem nicely and does not force us to increase the
timeout. A chip that does not respond for 8 seconds is a pretty bad chip.
As I said in another mail, I don't think it is the chip. On the system
where I'm experiencing these timeouts there's still the USB-subsysten
inbetween. And this system boots from USB too, which means there's a lot
of other traffic on the USB-bus besides the one for the USB-BT-dongle.
And I don't know how the USB-stack (and hw) schedules the traffic, if he
is able to schedule that at all.
I posted an experimental patch for changing cmd_timer into a delayed_work item
and this might solve your scheduling problem. However that patch is untested
and might needs some additional thinking on which queue the delayed work should
be scheduled on. Nevertheless, you see the direction that we should explore
first.
The L2CAP layer is not using struct timer_list at all anymore and in general we
should remove timer_list usage from the Bluetooth subsystem since we do all our
command processing in a workqueue. At least for lower protocols like HCI,
L2CAP, SMP and A2DP.
Regards
Marcel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] bluetooth: raise HCI_CMD_TIMEOUT from 2s to 8s
Hi Alexander,
> The reasoning to do this is the following:
>
> - If a timeout occurs, the HCI-communication is broken afterwards and the
> dongle isn't usable anymore.
> - If it works after e.g. waiting 4s everyone is still happy but if it
> just breaks after only waiting 2s nothing is gained.
> - Having to wait some more seconds until an error occurs doesn't change
> anything.
>
> So there is no disadvantage in rasing the timeout but a great advantage
> in case the dongle needs more than 2s to process an HCI command.
> E.g. I had sometimes HCI command timeouts at boot (but never after the BT
> stack
> was successfull started). I assume the reason might be the USB-probing which
> happend before through the bootloader, which might have confused the dongle
> such that it needs a bit more time, but I'm not sure.
>
> Together with the patch which limits the timeout only to the actual time the
> dongle needs to process an HCI command (and doesn't include the time the
> kernel needs to process the answer to an HCI command), my problems were gone.
>
> Signed-off-by: Alexander Holler
> ---
> include/net/bluetooth/hci.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index be150cf..d50fd34 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -180,7 +180,7 @@ enum {
> #define HCI_DISCONN_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */
> #define HCI_PAIRING_TIMEOUT msecs_to_jiffies(6) /* 60 seconds */
> #define HCI_INIT_TIMEOUT msecs_to_jiffies(1) /* 10 seconds */
> -#define HCI_CMD_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */
> +#define HCI_CMD_TIMEOUT msecs_to_jiffies(8000) /* 8 seconds */
> #define HCI_ACL_TX_TIMEOUTmsecs_to_jiffies(45000) /* 45 seconds */
> #define HCI_AUTO_OFF_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */
> #define HCI_POWER_OFF_TIMEOUT msecs_to_jiffies(5000) /* 5 seconds */
I think moving the command timeout handling into a delayed work struct might
actually solve this problem nicely and does not force us to increase the
timeout. A chip that does not respond for 8 seconds is a pretty bad chip.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] bluetooth: raise HCI_CMD_TIMEOUT from 2s to 8s
Hi Alexander,
The reasoning to do this is the following:
- If a timeout occurs, the HCI-communication is broken afterwards and the
dongle isn't usable anymore.
- If it works after e.g. waiting 4s everyone is still happy but if it
just breaks after only waiting 2s nothing is gained.
- Having to wait some more seconds until an error occurs doesn't change
anything.
So there is no disadvantage in rasing the timeout but a great advantage
in case the dongle needs more than 2s to process an HCI command.
E.g. I had sometimes HCI command timeouts at boot (but never after the BT
stack
was successfull started). I assume the reason might be the USB-probing which
happend before through the bootloader, which might have confused the dongle
such that it needs a bit more time, but I'm not sure.
Together with the patch which limits the timeout only to the actual time the
dongle needs to process an HCI command (and doesn't include the time the
kernel needs to process the answer to an HCI command), my problems were gone.
Signed-off-by: Alexander Holler hol...@ahsoftware.de
---
include/net/bluetooth/hci.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index be150cf..d50fd34 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -180,7 +180,7 @@ enum {
#define HCI_DISCONN_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */
#define HCI_PAIRING_TIMEOUT msecs_to_jiffies(6) /* 60 seconds */
#define HCI_INIT_TIMEOUT msecs_to_jiffies(1) /* 10 seconds */
-#define HCI_CMD_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */
+#define HCI_CMD_TIMEOUT msecs_to_jiffies(8000) /* 8 seconds */
#define HCI_ACL_TX_TIMEOUTmsecs_to_jiffies(45000) /* 45 seconds */
#define HCI_AUTO_OFF_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */
#define HCI_POWER_OFF_TIMEOUT msecs_to_jiffies(5000) /* 5 seconds */
I think moving the command timeout handling into a delayed work struct might
actually solve this problem nicely and does not force us to increase the
timeout. A chip that does not respond for 8 seconds is a pretty bad chip.
Regards
Marcel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] bluetooth: raise HCI_CMD_TIMEOUT from 2s to 8s
Am 16.05.2014 07:35, schrieb Alexander Holler: Am 15.05.2014 17:19, schrieb Alexander Holler: Am 15.05.2014 16:50, schrieb Alexander Holler: Am 15.05.2014 14:54, schrieb Luiz Augusto von Dentz: This timeout seems arbitrary so I suppose we can increase it if we feel it is necessary but we used already different timeout for different commands like HCI_POWER_OFF_TIMEOUT, so perhaps if we can identify which command is more likely to timeout. We could perhaps auto reset if a command timeout if there is really no other way to recover. It is arbitrary but 2s is not enough here. And as I've written in the description, there is absolutely no reason to keep this timeout unnecessarily short. No one cares if an error message appears after 2s or 8s if the communication with the dongle is in both cases broken afterwards. One of the commands I experieced the problem with was e.g. HCI_OP_DELETE_STORED_LINK_KEY or HCI_OP_WRITE_SSP_MODE. The problem is that you can never be sure what the origin of a timeouted command was. It might have been e.g. the USB-subsystem through wich the command and the response has to travel (in case of USB dongles) and not the dongle itself. To explain a bit more, the box I'm experiencing these problems boots from USB2.0 HD. So it's likely that there is quiet some action on the bus and that shouldn't affect the operation of the BT-stack (besides slowing it maybe a bit down). Anything wrong with my conclusion? I don't know what's the origin of the current timeout of 2s, but I don't think it takes the used transport into account. So if the source of these 2s is the spec for BT-devices, the 2s would make sense as a timeout to test BT-devices, but it already becomes an arbitrary value whenever the transport isn't realtime and/or exclusive for the device but e.g. an I/O scheduler is inbetween (which is the case for USB). Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] bluetooth: raise HCI_CMD_TIMEOUT from 2s to 8s
Am 16.05.2014 07:35, schrieb Alexander Holler: Am 15.05.2014 17:19, schrieb Alexander Holler: Am 15.05.2014 16:50, schrieb Alexander Holler: Am 15.05.2014 14:54, schrieb Luiz Augusto von Dentz: This timeout seems arbitrary so I suppose we can increase it if we feel it is necessary but we used already different timeout for different commands like HCI_POWER_OFF_TIMEOUT, so perhaps if we can identify which command is more likely to timeout. We could perhaps auto reset if a command timeout if there is really no other way to recover. It is arbitrary but 2s is not enough here. And as I've written in the description, there is absolutely no reason to keep this timeout unnecessarily short. No one cares if an error message appears after 2s or 8s if the communication with the dongle is in both cases broken afterwards. One of the commands I experieced the problem with was e.g. HCI_OP_DELETE_STORED_LINK_KEY or HCI_OP_WRITE_SSP_MODE. The problem is that you can never be sure what the origin of a timeouted command was. It might have been e.g. the USB-subsystem through wich the command and the response has to travel (in case of USB dongles) and not the dongle itself. To explain a bit more, the box I'm experiencing these problems boots from USB2.0 HD. So it's likely that there is quiet some action on the bus and that shouldn't affect the operation of the BT-stack (besides slowing it maybe a bit down). Anything wrong with my conclusion? I don't know what's the origin of the current timeout of 2s, but I don't think it takes the used transport into account. So if the source of these 2s is the spec for BT-devices, the 2s would make sense as a timeout to test BT-devices, but it already becomes an arbitrary value whenever the transport isn't realtime and/or exclusive for the device but e.g. an I/O scheduler is inbetween (which is the case for USB). Regards, Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] bluetooth: raise HCI_CMD_TIMEOUT from 2s to 8s
Am 15.05.2014 17:19, schrieb Alexander Holler: Am 15.05.2014 16:50, schrieb Alexander Holler: Am 15.05.2014 14:54, schrieb Luiz Augusto von Dentz: This timeout seems arbitrary so I suppose we can increase it if we feel it is necessary but we used already different timeout for different commands like HCI_POWER_OFF_TIMEOUT, so perhaps if we can identify which command is more likely to timeout. We could perhaps auto reset if a command timeout if there is really no other way to recover. It is arbitrary but 2s is not enough here. And as I've written in the description, there is absolutely no reason to keep this timeout unnecessarily short. No one cares if an error message appears after 2s or 8s if the communication with the dongle is in both cases broken afterwards. One of the commands I experieced the problem with was e.g. HCI_OP_DELETE_STORED_LINK_KEY or HCI_OP_WRITE_SSP_MODE. The problem is that you can never be sure what the origin of a timeouted command was. It might have been e.g. the USB-subsystem through wich the command and the response has to travel (in case of USB dongles) and not the dongle itself. To explain a bit more, the box I'm experiencing these problems boots from USB2.0 HD. So it's likely that there is quiet some action on the bus and that shouldn't affect the operation of the BT-stack (besides slowing it maybe a bit down). Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] bluetooth: raise HCI_CMD_TIMEOUT from 2s to 8s
Am 15.05.2014 16:50, schrieb Alexander Holler: Am 15.05.2014 14:54, schrieb Luiz Augusto von Dentz: This timeout seems arbitrary so I suppose we can increase it if we feel it is necessary but we used already different timeout for different commands like HCI_POWER_OFF_TIMEOUT, so perhaps if we can identify which command is more likely to timeout. We could perhaps auto reset if a command timeout if there is really no other way to recover. It is arbitrary but 2s is not enough here. And as I've written in the description, there is absolutely no reason to keep this timeout unnecessarily short. No one cares if an error message appears after 2s or 8s if the communication with the dongle is in both cases broken afterwards. One of the commands I experieced the problem with was e.g. HCI_OP_DELETE_STORED_LINK_KEY or HCI_OP_WRITE_SSP_MODE. The problem is that you can never be sure what the origin of a timeouted command was. It might have been e.g. the USB-subsystem through wich the command and the response has to travel (in case of USB dongles) and not the dongle itself. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] bluetooth: raise HCI_CMD_TIMEOUT from 2s to 8s
Am 15.05.2014 14:54, schrieb Luiz Augusto von Dentz:
> Hi Alexander,
>
> On Wed, May 14, 2014 at 5:00 PM, Alexander Holler
> wrote:
>> The reasoning to do this is the following:
>>
>> - If a timeout occurs, the HCI-communication is broken afterwards and the
>> dongle isn't usable anymore.
>> - If it works after e.g. waiting 4s everyone is still happy but if it
>> just breaks after only waiting 2s nothing is gained.
>> - Having to wait some more seconds until an error occurs doesn't change
>> anything.
>>
>> So there is no disadvantage in rasing the timeout but a great advantage
>> in case the dongle needs more than 2s to process an HCI command.
>> E.g. I had sometimes HCI command timeouts at boot (but never after the BT
>> stack
>> was successfull started). I assume the reason might be the USB-probing which
>> happend before through the bootloader, which might have confused the dongle
>> such that it needs a bit more time, but I'm not sure.
>>
>> Together with the patch which limits the timeout only to the actual time the
>> dongle needs to process an HCI command (and doesn't include the time the
>> kernel needs to process the answer to an HCI command), my problems were gone.
>>
>> Signed-off-by: Alexander Holler
>> ---
>> include/net/bluetooth/hci.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
>> index be150cf..d50fd34 100644
>> --- a/include/net/bluetooth/hci.h
>> +++ b/include/net/bluetooth/hci.h
>> @@ -180,7 +180,7 @@ enum {
>> #define HCI_DISCONN_TIMEOUTmsecs_to_jiffies(2000) /* 2 seconds */
>> #define HCI_PAIRING_TIMEOUTmsecs_to_jiffies(6) /* 60 seconds */
>> #define HCI_INIT_TIMEOUT msecs_to_jiffies(1) /* 10 seconds */
>> -#define HCI_CMD_TIMEOUTmsecs_to_jiffies(2000) /* 2 seconds
>> */
>> +#define HCI_CMD_TIMEOUTmsecs_to_jiffies(8000) /* 8 seconds
>> */
>> #define HCI_ACL_TX_TIMEOUT msecs_to_jiffies(45000) /* 45 seconds */
>> #define HCI_AUTO_OFF_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */
>> #define HCI_POWER_OFF_TIMEOUT msecs_to_jiffies(5000) /* 5 seconds */
>> --
>> 1.8.3.1
>
> This timeout seems arbitrary so I suppose we can increase it if we
> feel it is necessary but we used already different timeout for
> different commands like HCI_POWER_OFF_TIMEOUT, so perhaps if we can
> identify which command is more likely to timeout.
>
> We could perhaps auto reset if a command timeout if there is really no
> other way to recover.
It is arbitrary but 2s is not enough here. And as I've written in the
description, there is absolutely no reason to keep this timeout
unnecessarily short. No one cares if an error message appears after 2s
or 8s if the communication with the dongle is in both cases broken
afterwards.
One of the commands I experieced the problem with was e.g.
HCI_OP_DELETE_STORED_LINK_KEY or HCI_OP_WRITE_SSP_MODE.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] bluetooth: raise HCI_CMD_TIMEOUT from 2s to 8s
Hi Alexander,
On Wed, May 14, 2014 at 5:00 PM, Alexander Holler wrote:
> The reasoning to do this is the following:
>
> - If a timeout occurs, the HCI-communication is broken afterwards and the
> dongle isn't usable anymore.
> - If it works after e.g. waiting 4s everyone is still happy but if it
> just breaks after only waiting 2s nothing is gained.
> - Having to wait some more seconds until an error occurs doesn't change
> anything.
>
> So there is no disadvantage in rasing the timeout but a great advantage
> in case the dongle needs more than 2s to process an HCI command.
> E.g. I had sometimes HCI command timeouts at boot (but never after the BT
> stack
> was successfull started). I assume the reason might be the USB-probing which
> happend before through the bootloader, which might have confused the dongle
> such that it needs a bit more time, but I'm not sure.
>
> Together with the patch which limits the timeout only to the actual time the
> dongle needs to process an HCI command (and doesn't include the time the
> kernel needs to process the answer to an HCI command), my problems were gone.
>
> Signed-off-by: Alexander Holler
> ---
> include/net/bluetooth/hci.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index be150cf..d50fd34 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -180,7 +180,7 @@ enum {
> #define HCI_DISCONN_TIMEOUTmsecs_to_jiffies(2000) /* 2 seconds */
> #define HCI_PAIRING_TIMEOUTmsecs_to_jiffies(6) /* 60 seconds */
> #define HCI_INIT_TIMEOUT msecs_to_jiffies(1) /* 10 seconds */
> -#define HCI_CMD_TIMEOUTmsecs_to_jiffies(2000) /* 2 seconds
> */
> +#define HCI_CMD_TIMEOUTmsecs_to_jiffies(8000) /* 8 seconds
> */
> #define HCI_ACL_TX_TIMEOUT msecs_to_jiffies(45000) /* 45 seconds */
> #define HCI_AUTO_OFF_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */
> #define HCI_POWER_OFF_TIMEOUT msecs_to_jiffies(5000) /* 5 seconds */
> --
> 1.8.3.1
This timeout seems arbitrary so I suppose we can increase it if we
feel it is necessary but we used already different timeout for
different commands like HCI_POWER_OFF_TIMEOUT, so perhaps if we can
identify which command is more likely to timeout.
We could perhaps auto reset if a command timeout if there is really no
other way to recover.
--
Luiz Augusto von Dentz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] bluetooth: raise HCI_CMD_TIMEOUT from 2s to 8s
Hi Alexander,
On Wed, May 14, 2014 at 5:00 PM, Alexander Holler hol...@ahsoftware.de wrote:
The reasoning to do this is the following:
- If a timeout occurs, the HCI-communication is broken afterwards and the
dongle isn't usable anymore.
- If it works after e.g. waiting 4s everyone is still happy but if it
just breaks after only waiting 2s nothing is gained.
- Having to wait some more seconds until an error occurs doesn't change
anything.
So there is no disadvantage in rasing the timeout but a great advantage
in case the dongle needs more than 2s to process an HCI command.
E.g. I had sometimes HCI command timeouts at boot (but never after the BT
stack
was successfull started). I assume the reason might be the USB-probing which
happend before through the bootloader, which might have confused the dongle
such that it needs a bit more time, but I'm not sure.
Together with the patch which limits the timeout only to the actual time the
dongle needs to process an HCI command (and doesn't include the time the
kernel needs to process the answer to an HCI command), my problems were gone.
Signed-off-by: Alexander Holler hol...@ahsoftware.de
---
include/net/bluetooth/hci.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index be150cf..d50fd34 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -180,7 +180,7 @@ enum {
#define HCI_DISCONN_TIMEOUTmsecs_to_jiffies(2000) /* 2 seconds */
#define HCI_PAIRING_TIMEOUTmsecs_to_jiffies(6) /* 60 seconds */
#define HCI_INIT_TIMEOUT msecs_to_jiffies(1) /* 10 seconds */
-#define HCI_CMD_TIMEOUTmsecs_to_jiffies(2000) /* 2 seconds
*/
+#define HCI_CMD_TIMEOUTmsecs_to_jiffies(8000) /* 8 seconds
*/
#define HCI_ACL_TX_TIMEOUT msecs_to_jiffies(45000) /* 45 seconds */
#define HCI_AUTO_OFF_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */
#define HCI_POWER_OFF_TIMEOUT msecs_to_jiffies(5000) /* 5 seconds */
--
1.8.3.1
This timeout seems arbitrary so I suppose we can increase it if we
feel it is necessary but we used already different timeout for
different commands like HCI_POWER_OFF_TIMEOUT, so perhaps if we can
identify which command is more likely to timeout.
We could perhaps auto reset if a command timeout if there is really no
other way to recover.
--
Luiz Augusto von Dentz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] bluetooth: raise HCI_CMD_TIMEOUT from 2s to 8s
Am 15.05.2014 14:54, schrieb Luiz Augusto von Dentz:
Hi Alexander,
On Wed, May 14, 2014 at 5:00 PM, Alexander Holler hol...@ahsoftware.de
wrote:
The reasoning to do this is the following:
- If a timeout occurs, the HCI-communication is broken afterwards and the
dongle isn't usable anymore.
- If it works after e.g. waiting 4s everyone is still happy but if it
just breaks after only waiting 2s nothing is gained.
- Having to wait some more seconds until an error occurs doesn't change
anything.
So there is no disadvantage in rasing the timeout but a great advantage
in case the dongle needs more than 2s to process an HCI command.
E.g. I had sometimes HCI command timeouts at boot (but never after the BT
stack
was successfull started). I assume the reason might be the USB-probing which
happend before through the bootloader, which might have confused the dongle
such that it needs a bit more time, but I'm not sure.
Together with the patch which limits the timeout only to the actual time the
dongle needs to process an HCI command (and doesn't include the time the
kernel needs to process the answer to an HCI command), my problems were gone.
Signed-off-by: Alexander Holler hol...@ahsoftware.de
---
include/net/bluetooth/hci.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index be150cf..d50fd34 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -180,7 +180,7 @@ enum {
#define HCI_DISCONN_TIMEOUTmsecs_to_jiffies(2000) /* 2 seconds */
#define HCI_PAIRING_TIMEOUTmsecs_to_jiffies(6) /* 60 seconds */
#define HCI_INIT_TIMEOUT msecs_to_jiffies(1) /* 10 seconds */
-#define HCI_CMD_TIMEOUTmsecs_to_jiffies(2000) /* 2 seconds
*/
+#define HCI_CMD_TIMEOUTmsecs_to_jiffies(8000) /* 8 seconds
*/
#define HCI_ACL_TX_TIMEOUT msecs_to_jiffies(45000) /* 45 seconds */
#define HCI_AUTO_OFF_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */
#define HCI_POWER_OFF_TIMEOUT msecs_to_jiffies(5000) /* 5 seconds */
--
1.8.3.1
This timeout seems arbitrary so I suppose we can increase it if we
feel it is necessary but we used already different timeout for
different commands like HCI_POWER_OFF_TIMEOUT, so perhaps if we can
identify which command is more likely to timeout.
We could perhaps auto reset if a command timeout if there is really no
other way to recover.
It is arbitrary but 2s is not enough here. And as I've written in the
description, there is absolutely no reason to keep this timeout
unnecessarily short. No one cares if an error message appears after 2s
or 8s if the communication with the dongle is in both cases broken
afterwards.
One of the commands I experieced the problem with was e.g.
HCI_OP_DELETE_STORED_LINK_KEY or HCI_OP_WRITE_SSP_MODE.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] bluetooth: raise HCI_CMD_TIMEOUT from 2s to 8s
Am 15.05.2014 16:50, schrieb Alexander Holler: Am 15.05.2014 14:54, schrieb Luiz Augusto von Dentz: This timeout seems arbitrary so I suppose we can increase it if we feel it is necessary but we used already different timeout for different commands like HCI_POWER_OFF_TIMEOUT, so perhaps if we can identify which command is more likely to timeout. We could perhaps auto reset if a command timeout if there is really no other way to recover. It is arbitrary but 2s is not enough here. And as I've written in the description, there is absolutely no reason to keep this timeout unnecessarily short. No one cares if an error message appears after 2s or 8s if the communication with the dongle is in both cases broken afterwards. One of the commands I experieced the problem with was e.g. HCI_OP_DELETE_STORED_LINK_KEY or HCI_OP_WRITE_SSP_MODE. The problem is that you can never be sure what the origin of a timeouted command was. It might have been e.g. the USB-subsystem through wich the command and the response has to travel (in case of USB dongles) and not the dongle itself. Regards, Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] bluetooth: raise HCI_CMD_TIMEOUT from 2s to 8s
Am 15.05.2014 17:19, schrieb Alexander Holler: Am 15.05.2014 16:50, schrieb Alexander Holler: Am 15.05.2014 14:54, schrieb Luiz Augusto von Dentz: This timeout seems arbitrary so I suppose we can increase it if we feel it is necessary but we used already different timeout for different commands like HCI_POWER_OFF_TIMEOUT, so perhaps if we can identify which command is more likely to timeout. We could perhaps auto reset if a command timeout if there is really no other way to recover. It is arbitrary but 2s is not enough here. And as I've written in the description, there is absolutely no reason to keep this timeout unnecessarily short. No one cares if an error message appears after 2s or 8s if the communication with the dongle is in both cases broken afterwards. One of the commands I experieced the problem with was e.g. HCI_OP_DELETE_STORED_LINK_KEY or HCI_OP_WRITE_SSP_MODE. The problem is that you can never be sure what the origin of a timeouted command was. It might have been e.g. the USB-subsystem through wich the command and the response has to travel (in case of USB dongles) and not the dongle itself. To explain a bit more, the box I'm experiencing these problems boots from USB2.0 HD. So it's likely that there is quiet some action on the bus and that shouldn't affect the operation of the BT-stack (besides slowing it maybe a bit down). Regards, Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
