Thanks for the suggestion Antti.
I've tried to add a delay in various places, but haven't seen any
improvement. However, what I did saw was that if I added an msleep
after the lock:
static int dvbsky_usb_generic_rw(struct dvb_usb_device *d,
u8 *wbuf, u16 wlen, u8 *rbuf, u16 rlen)
{
int ret;
struct dvbsky_state *state = d_to_priv(d);
mutex_lock(&d->usb_mutex);
msleep(20);
The error was seen very within a minute. If I increased the msleep to
50, it failed within seconds. This doesn't seem to make sense to me.
This is the only function where usb_mutex is used. If the mutex is
held for a longer time, the next attempt to lock the mutex should just
be delayed a bit, no?
Cheers,
-olli
On 18 April 2018 at 10:49, Antti Palosaari <crope@xxxxxx> wrote:
>
> On 04/18/2018 07:49 AM, Olli Salonen wrote:
>>
>> Thank you for your response Peter!
>>
>> Indeed, it seems strange. dvbsky.c driver seems to use mutex_lock in
>> very much the same way as many other drivers. I've now confirmed that
>> I can get a 4.10 kernel with working DVBSky S960 by reverting the
>> following 4 patches:
>>
>> 549bdd3 Revert "locking/mutex: Add lock handoff to avoid starvation"
>> 3210f31 Revert "locking/mutex: Restructure wait loop"
>> 418a170 Revert "locking/mutex: Simplify some ww_mutex code in
>> __mutex_lock_common()"
>> 0b1fb8f Revert "locking/mutex: Enable optimistic spinning of woken waiter"
>> c470abd Linux 4.10
>
>
> These kind of issues tend to be timing issues very often. Just add some
> sleeps to i2c adapter algo / usb control messages and test.
>
> regards
> Antti
>
>
>
>
> --
> http://palosaari.fi/
