Re: [PATCH 2/2] bluetooth: raise HCI_CMD_TIMEOUT from 2s to 8s

[Alexander Holler]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/