On Sun, Jan 20, 2019 at 04:43:08PM +0200, Antti Palosaari wrote: > On 1/13/19 11:13 PM, James Hutchinson wrote: > > Ref: https://bugzilla.kernel.org/show_bug.cgi?id=199323 > > > > Users are experiencing problems with the DVBSky S960/S960C USB devices > > since the following commit: > > > > 9d659ae: ("locking/mutex: Add lock handoff to avoid starvation") > > > > The device malfunctions after running for an indeterminable period of > > time, and the problem can only be cleared by rebooting the machine. > > > > It is possible to encourage the problem to surface by blocking the > > signal to the LNB. > > > > Further debugging revealed the cause of the problem. > > > > In the following capture: > > - thread #1325 is running m88ds3103_set_frontend > > - thread #42 is running ts2020_stat_work > > > > a> [1325] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 07 80 > > [1325] usb 1-1: dvb_usb_v2_generic_io: <<< 08 > > [42] usb 1-1: dvb_usb_v2_generic_io: >>> 09 01 01 68 3f > > [42] usb 1-1: dvb_usb_v2_generic_io: <<< 08 ff > > [42] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 03 11 > > [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 > > [42] usb 1-1: dvb_usb_v2_generic_io: >>> 09 01 01 60 3d > > [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 ff > > b> [1325] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 07 00 > > [1325] usb 1-1: dvb_usb_v2_generic_io: <<< 07 > > [42] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 03 11 > > [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 > > [42] usb 1-1: dvb_usb_v2_generic_io: >>> 09 01 01 60 21 > > [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 ff > > [42] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 03 11 > > [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 > > [42] usb 1-1: dvb_usb_v2_generic_io: >>> 09 01 01 60 66 > > [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 ff > > [1325] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 03 11 > > [1325] usb 1-1: dvb_usb_v2_generic_io: <<< 07 > > [1325] usb 1-1: dvb_usb_v2_generic_io: >>> 08 60 02 10 0b > > [1325] usb 1-1: dvb_usb_v2_generic_io: <<< 07 > > > > Two i2c messages are sent to perform a reset in m88ds3103_set_frontend: > > > > a. 0x07, 0x80 > > b. 0x07, 0x00 > > > > However, as shown in the capture, the regmap mutex is being handed over > > to another thread (ts2020_stat_work) in between these two messages. > > > > > From here, the device responds to every i2c message with an 07 message, > > and will only return to normal operation following a power cycle. > > > > Use regmap_multi_reg_write to group the two reset messages, ensuring > > both are processed before the regmap mutex is unlocked. > > I tried to reproduce that issue with pctv 461e, which has em28xx > usb-interface, but without success. Even when I added some sleep between > reset commands and increased tuner statistic polling interval such that it > polls all the time, it works correctly. Device has tuner is connected to > demod i2c bus, which I think is same for your device (it calls demod i2c mux > select for every tuner i2c access). > > Taking into account tests I made it is probably issue with usb-interface i2c > adapter instead - for some reason it stops working and starts returning 07 > error all the time. Did any other I2C command succeed after failure? I mean > is there any other i2c client on that bus you could test if it fails too on > error situation? > > All in all, fix should be done to usb-interface i2c adapter if possible > unless it has proven issue is somewhere else. You could try to add some > sleep or repeat to i2c adapter in order to see if it helps. > > regards > Antti > > -- > http://palosaari.fi/ Thanks for taking the time to review my patch. My device is the dvbsky usb s960 which is a pretty popular device and hasn't been working for several users since commit 9d659ae. I did some further investigation and can now see that the issue likely only affects adapters which use the m88ds3103_get_agc_pwm function to get the AGC from the demodulator as part of ts2020_stat_work. This is the 3f message in my original capture, which gets an ff response. [42] usb 1-1: dvb_usb_v2_generic_io: >>> 09 01 01 68 3f [42] usb 1-1: dvb_usb_v2_generic_io: <<< 08 ff The m88ds3103_get_agc_pwm function looks to be used by a subset of devices and their variants from the dvbsky usb-interface (s960 & s960c), and the cx23885-dvb pci-interface (s950, s950c, s952). The problem does NOT occur if I disable auto-gain correction by removing the following line from dvbsky_s960_attach: ts2020_config.get_agc_pwm = m88ds3103_get_agc_pwm; I then have the same experience as you; I can add a sleep between the reset commands and increase the tuner statistic polling interval, and it still works correctly. I can also reproduce the issue on older kernels (pre-commit 9d659ae) by adding a sleep between the two reset commands and leaving the agc read enabled. Whilst my original patch works around the issue, I'm not sure it's really addressing the root cause, and I do wonder whether other areas of the m88ds3103 module may end up needing to be protected in a similar way. Afterall, the ts2020 stat work thread runs every 2000ms, and there's currently no guarantee what state the demodulator is going to be in at that time. Regards, James.
