Re: [PATCH 6.10 288/809] media: dvb-usb: Fix unexpected infinite loop in dvb_usb_read_remote_control()

[Sean Young <sean@mess.org>]

On Wed, Aug 07, 2024 at 03:21:52AM +0200, Stefan Lippers-Hollmann wrote:
> On 2024-08-06, Sean Young wrote:
> > On Sat, Aug 03, 2024 at 06:08:52PM +0200, Stefan Lippers-Hollmann wrote:
> > > On 2024-08-03, Sean Young wrote:
> > > > On Thu, Aug 01, 2024 at 04:51:46PM +0200, Stefan Lippers-Hollmann wrote:
> > > > > On 2024-07-30, Greg Kroah-Hartman wrote:
> > > > > > 6.10-stable review patch.  If anyone has any objections, please let me know.
> [...]
> > > > > > Infinite log printing occurs during fuzz test:
> > > > > >
> > > > > >   rc rc1: DViCO FusionHDTV DVB-T USB (LGZ201) as ...
> > > > > >   ...
> > > > > >   dvb-usb: schedule remote query interval to 100 msecs.
> > > > > >   dvb-usb: DViCO FusionHDTV DVB-T USB (LGZ201) successfully initialized ...
> > > > > >   dvb-usb: bulk message failed: -22 (1/0)
> > > > > >   dvb-usb: bulk message failed: -22 (1/0)
> > > > > >   dvb-usb: bulk message failed: -22 (1/0)
> > > > > >   ...
> > > > > >   dvb-usb: bulk message failed: -22 (1/0)
> > > > > >
> > > > > > Looking into the codes, there is a loop in dvb_usb_read_remote_control(),
> > > > > > that is in rc_core_dvb_usb_remote_init() create a work that will call
> > > > > > dvb_usb_read_remote_control(), and this work will reschedule itself at
> > > > > > 'rc_interval' intervals to recursively call dvb_usb_read_remote_control(),
> > > > > > see following code snippet:
> [...]
> > I don't think this drivers uses the bulk endpoint, and it is missing the
> > corresponding out bulk endpoint.
> >
> > Please could you test the patch below please - that would be very helpful in
> > narrowing down this issue.
> [...]
> 
> After applying this patch, the TeVii s480 works again on both of my
> systems, but there seems to be a new error message in the log
> 
> ds3000_writereg: writereg error(err == -11, reg == 0xa2, value == 0xb7)
> ds3000_writereg: writereg error(err == -11, reg == 0x03, value == 0x12)
> ds3000_writereg: writereg error(err == -11, reg == 0x03, value == 0x12)
> ds3000_writereg: writereg error(err == -11, reg == 0x03, value == 0x02)
> ds3000_writereg: writereg error(err == -11, reg == 0x03, value == 0x02)

I've spent of a lot time reading various code paths, and I don't understand
where this is coming from, which also makes it difficult to add debug printks
too. Without the hardware to debug this, I think we have to revert the commit.

The only idea I've had so far is that we are no longer clearing a halt on
the bulk endpoint, but that seems pretty unlikely for a device that has just
been plugged in.

Stefan, thank you for reporting the issue and testing my patch.


Sean