Re: Regression: DVBSky S960 USB tuner doesn't work in 4.10 or newer

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Apr 04, 2018 at 02:41:51PM +0300, Olli Salonen wrote:
> Hello Peter and Max,
> 
> I noticed that when using kernel 4.10 or newer my DVBSky S960 and
> S960CI satellite USB TV tuners stopped working properly. Basically,
> they will fail at one point when tuning to a channel. This typically
> takes less than 100 tuning attempts. For perspective, when performing
> a full channel scan on my system, the tuner tunes at least 500 times.
> After the tuner fails, I need to reboot the PC (probably unloading the
> driver and loading it again would do).
> 
> 2018-04-04 10:17:36.756 [   INFO] mpegts: 12149H in 4.8E - tuning on
> Montage Technology M88DS3103 : DVB-S #0
> 2018-04-04 10:17:37.159 [  ERROR] diseqc: failed to send diseqc cmd
> (e=Connection timed out)
> 2018-04-04 10:17:37.160 [   INFO] mpegts: 12265H in 4.8E - tuning on
> Montage Technology M88DS3103 : DVB-S #0
> 2018-04-04 10:17:37.535 [  ERROR] diseqc: failed to send diseqc cmd
> (e=Connection timed out)
> 
> I did a kernel bisect between 4.9 and 4.10. It seems the commit that
> breaks my tuner is the following one:
> 
> 9d659ae14b545c4296e812c70493bfdc999b5c1c is the first bad commit
> commit 9d659ae14b545c4296e812c70493bfdc999b5c1c
> Author: Peter Zijlstra <peterz@infradead.org>
> Date:   Tue Aug 23 14:40:16 2016 +0200
> 
>     locking/mutex: Add lock handoff to avoid starvation
> 
> I couldn't easily revert that commit only. I can see that the
> drivers/media/usb/dvb-usb-v2/dvbsky.c driver does use mutex_lock() and
> mutex_lock_interruptible() in a few places.
> 
> Do you guys see anything that's obviously wrong in the way the mutexes
> are used in dvbsky.c or anything in that particular patch that could
> cause this issue?

Nothing, sorry.. really weird. That driver looks fairly straight forward
with respect to mutex usage (although obviously I have less than 0 clue
on the whole usb media thing).

That it breaks that driver would suggest something funny with it though;
because the kernel has loads and loads of mutexes in and they all appear
to work well with that patch -- in fact, it fixed a reported starvation
case.

The only way for that patch to affect things is if there is contention
on the mutex though; so who or what is also trying to acquire the mutex?

The reported error is a timeout, suggesting that whoever is contending
on the lock is keeping it held too long? I do notice that
dvbsky_stream_ctrl() has an msleep() while holding a mutex.

Do you have any idea which of the 3 (afaict) mutexes in that driver is
failing? Going by the fact that it's failing to send, I'd hazard a guess
it's the i2c mutex, but again, I have less than 0 clues about i2c.