Lo, this is your Linux kernel regression tracker speaking. On 01.10.21 08:56, Kalle Valo wrote: > (adding regressions list for easier tracking) Thx for this, that's how it got on the radar of regzbot, my Linux kernel regression tracking bot: https://linux-regtracking.leemhuis.info/regzbot/regression/87czop5j33.fsf@xxxxxxxxxxxxxxxxxx/ > Exuvo <exuvo@xxxxxxxx> writes: > >> I would like to get this resolved, is there any more information you need from me? >> >> I have been manually patching this all year with: >> >> drivers/net/wireless/ralink/rt2x00/rt2x00usb.c >> - if (rt2x00dev->num_proto_errs > 8) >> - return true; >> >> It seems to just be some part of rt2800_load_firmware that is not >> supported on my device and generating errors but it has been running >> without problems in AP mode with daily usage. > > [...] > >>>>>>>> This most likely is the problem introduced by commit: >>>>>>>> >>>>>>>> commit e383c70474db32b9d4a3de6dfbd08784d19e6751 >>>>>>>> Author: Stanislaw Gruszka <sgruszka@xxxxxxxxxx> >>>>>>>> Date: Tue Mar 12 10:51:42 2019 +0100 >>>>>>>> >>>>>>>> rt2x00: check number of EPROTO errors >>>>>>>> >>>>>>>> Plase check below patch that increase number of EPROTO checks >>>>>>>> before marking device removed. If it does not help, plese >>>>>>>> check if reverting above commits helps. > > Should we do a revert? Can someone submit that including an explanation > of the regression. Afaics nothing happened since then. Or did I miss anything? How can we get the ball rolling again? Stanislaw, is there anything Exuvo (who offered to help afaics) could test to get us closer to a fix? Ciao, Thorsten P.S.: I have no personal interest in this issue and watch it using regzbot. Hence, feel free to exclude me on further messages in this thread after the first reply, as I'm only posting this mail to hopefully get a status update and things rolling again. #regzbot poke
