Messages in this thread | | | Date | Tue, 27 May 2014 17:19:51 +0200 | From | Alexander Holler <> | Subject | 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
| |