regressions.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* Re: rt2x00 regression
       [not found]             ` <f935dc15-08bd-2e28-fc1b-b27634c618be@exuvo.se>
@ 2021-10-01  6:56               ` Kalle Valo
  2021-10-01  8:24                 ` Thorsten Leemhuis
  2021-11-05 13:25                 ` rt2x00 regression Thorsten Leemhuis
  0 siblings, 2 replies; 15+ messages in thread
From: Kalle Valo @ 2021-10-01  6:56 UTC (permalink / raw)
  To: Exuvo; +Cc: Stanislaw Gruszka, linux-wireless, Helmut Schaa, regressions

(adding regressions list for easier tracking)

Exuvo <exuvo@exuvo.se> 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@redhat.com>
>>>>>>> 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.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: rt2x00 regression
  2021-10-01  6:56               ` rt2x00 regression Kalle Valo
@ 2021-10-01  8:24                 ` Thorsten Leemhuis
  2021-11-30  9:16                   ` rt2x00 regression #forregzbot Thorsten Leemhuis
  2021-11-05 13:25                 ` rt2x00 regression Thorsten Leemhuis
  1 sibling, 1 reply; 15+ messages in thread
From: Thorsten Leemhuis @ 2021-10-01  8:24 UTC (permalink / raw)
  To: regressions

On 01.10.21 08:56, Kalle Valo wrote:
> (adding regressions list for easier tracking)

Feel free to ignore this message. I write it to make regzbot track above
issue. Regzbot is the regression tracking bot I'm working on. It's still
in the early stages and this is still one of the first few regression I
make it track to get started and things tested in the field. That also
why I'm sending the mail just to the regressions list (it will do its
full magic nevertheless). For details see:
https://linux-regtracking.leemhuis.info/post/inital-regzbot-running/
https://linux-regtracking.leemhuis.info/post/regzbot-approach/

#regzbot ^introduced e383c70474db32b9d4a3de6dfbd08784d19e6751
#regzbot monitor
https://lore.kernel.org/linux-wireless/bff7d309-a816-6a75-51b6-5928ef4f7a8c@exuvo.se/
#regzbot ignore-activitiy

BTW, in case anyone is reading this: the regzbot's webinterface that
gives insights into what is tracked can be found here:

https://linux-regtracking.leemhuis.info/regzbot/mainline.html

Ciao, Thorsten

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: rt2x00 regression
  2021-10-01  6:56               ` rt2x00 regression Kalle Valo
  2021-10-01  8:24                 ` Thorsten Leemhuis
@ 2021-11-05 13:25                 ` Thorsten Leemhuis
  2021-11-08 18:00                   ` Thorsten Leemhuis
  1 sibling, 1 reply; 15+ messages in thread
From: Thorsten Leemhuis @ 2021-11-05 13:25 UTC (permalink / raw)
  To: Stanislaw Gruszka
  Cc: linux-wireless, Helmut Schaa, regressions, Kalle Valo, Exuvo

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@tynnyri.adurom.net/


> Exuvo <exuvo@exuvo.se> 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@redhat.com>
>>>>>>>> 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: rt2x00 regression
  2021-11-05 13:25                 ` rt2x00 regression Thorsten Leemhuis
@ 2021-11-08 18:00                   ` Thorsten Leemhuis
       [not found]                     ` <20211109073127.ga109212@wp.pl>
  2021-11-09  7:31                     ` Stanislaw Gruszka
  0 siblings, 2 replies; 15+ messages in thread
From: Thorsten Leemhuis @ 2021-11-08 18:00 UTC (permalink / raw)
  To: Stanislaw Gruszka, Stanislaw Gruszka
  Cc: linux-wireless, Helmut Schaa, regressions, Kalle Valo, Exuvo

Sending this again, but this time also to Stanislaw's email address
currently found in MAINTAINERS.

Stanislaw, can you help with this regression?

Helmut: or can you help somehow to get things rolling again?

Ciao, Thorsten, your Linux kernel regression tracker

On 05.11.21 14:25, Thorsten Leemhuis wrote:
> 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@tynnyri.adurom.net/
> 
> 
>> Exuvo <exuvo@exuvo.se> 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@redhat.com>
>>>>>>>>> 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: rt2x00 regression
  2021-11-08 18:00                   ` Thorsten Leemhuis
       [not found]                     ` <20211109073127.ga109212@wp.pl>
@ 2021-11-09  7:31                     ` Stanislaw Gruszka
  2021-11-09 12:07                       ` Stanislaw Gruszka
  1 sibling, 1 reply; 15+ messages in thread
From: Stanislaw Gruszka @ 2021-11-09  7:31 UTC (permalink / raw)
  To: Thorsten Leemhuis
  Cc: Stanislaw Gruszka, linux-wireless, Helmut Schaa, regressions,
	Kalle Valo, Exuvo

On Mon, Nov 08, 2021 at 07:00:20PM +0100, Thorsten Leemhuis wrote:
> Sending this again, but this time also to Stanislaw's email address
> currently found in MAINTAINERS.
>
> Stanislaw, can you help with this regression?

Yes. 

I'll check on mail archives what is the status and what can be done.

Stanislaw

> Helmut: or can you help somehow to get things rolling again?
> 
> Ciao, Thorsten, your Linux kernel regression tracker
> 
> On 05.11.21 14:25, Thorsten Leemhuis wrote:
> > 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@tynnyri.adurom.net/
> > 
> > 
> >> Exuvo <exuvo@exuvo.se> 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@redhat.com>
> >>>>>>>>> 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: rt2x00 regression
  2021-11-09  7:31                     ` Stanislaw Gruszka
@ 2021-11-09 12:07                       ` Stanislaw Gruszka
  2021-11-09 15:22                         ` Exuvo
  0 siblings, 1 reply; 15+ messages in thread
From: Stanislaw Gruszka @ 2021-11-09 12:07 UTC (permalink / raw)
  To: Thorsten Leemhuis
  Cc: Stanislaw Gruszka, linux-wireless, Helmut Schaa, regressions,
	Kalle Valo, Exuvo

On Tue, Nov 09, 2021 at 08:32:07AM +0100, Stanislaw Gruszka wrote:
> On Mon, Nov 08, 2021 at 07:00:20PM +0100, Thorsten Leemhuis wrote:
> > Sending this again, but this time also to Stanislaw's email address
> > currently found in MAINTAINERS.
> >
> > Stanislaw, can you help with this regression?
> 
> Yes. 
> 
> I'll check on mail archives what is the status and what can be done.

Ok, so what I can see here  
https://lore.kernel.org/linux-wireless/20211109073127.GA109212@wp.pl/T/#m6a677995c1afaf6b9b1ff19de9566f304089d3ac
is that this problem happen only on firmware load,
so I think we can use below patch as fix.

Anton, please test it.

Thanks
Stanislaw

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
index e4473a551241..57c947dad036 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
@@ -30,7 +30,8 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status)
 	else
 		rt2x00dev->num_proto_errs = 0;
 
-	if (rt2x00dev->num_proto_errs > 3)
+	if (rt2x00dev->num_proto_errs > 3 &&
+	    !test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags))
 		return true;
 
 	return false;

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: rt2x00 regression
  2021-11-09 12:07                       ` Stanislaw Gruszka
@ 2021-11-09 15:22                         ` Exuvo
       [not found]                           ` <cc85b4e8a038417b865069c6578acf50@grupawp.pl>
  0 siblings, 1 reply; 15+ messages in thread
From: Exuvo @ 2021-11-09 15:22 UTC (permalink / raw)
  To: Stanislaw Gruszka, Thorsten Leemhuis
  Cc: Stanislaw Gruszka, linux-wireless, Helmut Schaa, regressions, Kalle Valo

Just tested it and it passes the rt2x00lib_load_firmware but still errors on rt2800usb_set_device_state:

[  348.363942] ieee80211 phy1: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'
[  348.364519] ieee80211 phy1: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36
[  348.650321] ieee80211 phy1: rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x0404 with error -71
[  349.695576] ieee80211 phy1: rt2800_wait_csr_ready: Error - Unstable hardware
[  349.695606] ieee80211 phy1: rt2800usb_set_device_state: Error - Device failed to enter state 4 (-5)

which was the last error i got in my previous dump_stack too (which you linked):

2020-07-15T19:16:10.956602+0000 kernel: Call Trace:
2020-07-15T19:16:10.956620+0000 kernel:  dump_stack+0x64/0x88
2020-07-15T19:16:10.956635+0000 kernel: rt2x00usb_vendor_request.cold+0x2b/0x69 [rt2x00usb]
2020-07-15T19:16:10.956649+0000 kernel: rt2x00usb_vendor_req_buff_lock+0xa6/0x230 [rt2x00usb]
2020-07-15T19:16:10.956663+0000 kernel: rt2x00usb_register_write_lock+0x37/0x60 [rt2800usb]
2020-07-15T19:16:10.956677+0000 kernel: rt2800_mcu_request+0x100/0x110 [rt2800lib]
2020-07-15T19:16:10.956696+0000 kernel: rt2800_enable_radio+0xb6/0x2d36 [rt2800lib]
2020-07-15T19:16:10.956712+0000 kernel: rt2800usb_set_device_state+0xbd/0x18b [rt2800usb]
2020-07-15T19:16:10.956735+0000 kernel: rt2x00lib_enable_radio+0x3e/0xa0 [rt2x00lib]
2020-07-15T19:16:10.956754+0000 kernel:  rt2x00lib_start+0x7c/0xc0 [rt2x00lib]
2020-07-15T19:16:10.956778+0000 kernel:  drv_start+0x3e/0x130 [mac80211]

Anton "exuvo" Olsson
    exuvo@exuvo.se

On 2021-11-09 13:07, Stanislaw Gruszka wrote:
> On Tue, Nov 09, 2021 at 08:32:07AM +0100, Stanislaw Gruszka wrote:
>> On Mon, Nov 08, 2021 at 07:00:20PM +0100, Thorsten Leemhuis wrote:
>>> Sending this again, but this time also to Stanislaw's email address
>>> currently found in MAINTAINERS.
>>>
>>> Stanislaw, can you help with this regression?
>> Yes.
>>
>> I'll check on mail archives what is the status and what can be done.
> Ok, so what I can see here
> https://lore.kernel.org/linux-wireless/20211109073127.GA109212@wp.pl/T/#m6a677995c1afaf6b9b1ff19de9566f304089d3ac
> is that this problem happen only on firmware load,
> so I think we can use below patch as fix.
>
> Anton, please test it.
>
> Thanks
> Stanislaw
>
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
> index e4473a551241..57c947dad036 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
> @@ -30,7 +30,8 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status)
>   	else
>   		rt2x00dev->num_proto_errs = 0;
>   
> -	if (rt2x00dev->num_proto_errs > 3)
> +	if (rt2x00dev->num_proto_errs > 3 &&
> +	    !test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags))
>   		return true;
>   
>   	return false;

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: rt2x00 regression
       [not found]                           ` <cc85b4e8a038417b865069c6578acf50@grupawp.pl>
@ 2021-11-10  6:59                             ` Kalle Valo
  2021-11-10  8:01                               ` Stanislaw Gruszka
  0 siblings, 1 reply; 15+ messages in thread
From: Kalle Valo @ 2021-11-10  6:59 UTC (permalink / raw)
  To: Stanisław Gruszka
  Cc: Exuvo, Thorsten Leemhuis, Stanislaw Gruszka, linux-wireless,
	Helmut Schaa, regressions

Stanisław Gruszka <stf_xl@wp.pl> writes:

> Dnia 9 listopada 2021 16:22 Exuvo <exuvo@exuvo.se> napisał(a):
>
>  Just tested it and it passes the rt2x00lib_load_firmware but still errors on
>  rt2800usb_set_device_state:
>
> <snip>
>
>  @@ -30,7 +30,8 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status)
>    else
>    rt2x00dev->num_proto_errs = 0;
>   
>  - if (rt2x00dev->num_proto_errs > 3)
>  + if (rt2x00dev->num_proto_errs > 3 &&
>  +    !test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags))
>    return true;
>   
>    return false;
>
> Sorry, I screwed logic in my patch. It should be test_bit() instead of !test_bit(). 
> And also we should not count when device did not start. So patch should be somewhat different. I'll
> send tomorrow hopefully better patch. 

No HTML, please :) I'll reply so that lists see your email.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: rt2x00 regression
  2021-11-10  6:59                             ` Kalle Valo
@ 2021-11-10  8:01                               ` Stanislaw Gruszka
  2021-11-11 10:54                                 ` Exuvo
  0 siblings, 1 reply; 15+ messages in thread
From: Stanislaw Gruszka @ 2021-11-10  8:01 UTC (permalink / raw)
  To: Kalle Valo
  Cc: Exuvo, Thorsten Leemhuis, Stanislaw Gruszka, linux-wireless,
	Helmut Schaa, regressions

On Wed, Nov 10, 2021 at 08:59:22AM +0200, Kalle Valo wrote:
> Stanisław Gruszka <stf_xl@wp.pl> writes:
> 
> > Dnia 9 listopada 2021 16:22 Exuvo <exuvo@exuvo.se> napisał(a):
> >
> >  Just tested it and it passes the rt2x00lib_load_firmware but still errors on
> >  rt2800usb_set_device_state:
> >
> > <snip>
> >
> >  @@ -30,7 +30,8 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status)
> >    else
> >    rt2x00dev->num_proto_errs = 0;
> >   
> >  - if (rt2x00dev->num_proto_errs > 3)
> >  + if (rt2x00dev->num_proto_errs > 3 &&
> >  +    !test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags))
> >    return true;
> >   
> >    return false;
> >
> > Sorry, I screwed logic in my patch. It should be test_bit() instead of !test_bit(). 
> > And also we should not count when device did not start. So patch should be somewhat different. I'll
> > send tomorrow hopefully better patch. 
> 
> No HTML, please :) I'll reply so that lists see your email.

Eh, I sent from my phone to give quick update, did not realize
it send in HTML.

Anyway, below is updated patch. I hope it will work correctly now.

Regards 
Stanislaw

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
index e4473a551241..74c3d8cb3100 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
@@ -25,6 +25,9 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status)
 	if (status == -ENODEV || status == -ENOENT)
 		return true;
 
+	if (!test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags))
+		return false;
+
 	if (status == -EPROTO || status == -ETIMEDOUT)
 		rt2x00dev->num_proto_errs++;
 	else



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: rt2x00 regression
  2021-11-10  8:01                               ` Stanislaw Gruszka
@ 2021-11-11 10:54                                 ` Exuvo
  2021-11-11 14:10                                   ` [PATCH] rt2x00: do not mark device gone on EPROTO errors during start Stanislaw Gruszka
  0 siblings, 1 reply; 15+ messages in thread
From: Exuvo @ 2021-11-11 10:54 UTC (permalink / raw)
  To: Stanislaw Gruszka, Kalle Valo
  Cc: Thorsten Leemhuis, Stanislaw Gruszka, linux-wireless,
	Helmut Schaa, regressions

Yes that patch works :D

Anton "exuvo" Olsson
    exuvo@exuvo.se

On 2021-11-10 09:01, Stanislaw Gruszka wrote:
> On Wed, Nov 10, 2021 at 08:59:22AM +0200, Kalle Valo wrote:
>> Stanisław Gruszka <stf_xl@wp.pl> writes:
>>
>>> Dnia 9 listopada 2021 16:22 Exuvo <exuvo@exuvo.se> napisał(a):
>>>
>>>   Just tested it and it passes the rt2x00lib_load_firmware but still errors on
>>>   rt2800usb_set_device_state:
>>>
>>> <snip>
>>>
>>>   @@ -30,7 +30,8 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status)
>>>     else
>>>     rt2x00dev->num_proto_errs = 0;
>>>    
>>>   - if (rt2x00dev->num_proto_errs > 3)
>>>   + if (rt2x00dev->num_proto_errs > 3 &&
>>>   +    !test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags))
>>>     return true;
>>>    
>>>     return false;
>>>
>>> Sorry, I screwed logic in my patch. It should be test_bit() instead of !test_bit().
>>> And also we should not count when device did not start. So patch should be somewhat different. I'll
>>> send tomorrow hopefully better patch.
>> No HTML, please :) I'll reply so that lists see your email.
> Eh, I sent from my phone to give quick update, did not realize
> it send in HTML.
>
> Anyway, below is updated patch. I hope it will work correctly now.
>
> Regards
> Stanislaw
>
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
> index e4473a551241..74c3d8cb3100 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
> @@ -25,6 +25,9 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status)
>   	if (status == -ENODEV || status == -ENOENT)
>   		return true;
>   
> +	if (!test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags))
> +		return false;
> +
>   	if (status == -EPROTO || status == -ETIMEDOUT)
>   		rt2x00dev->num_proto_errs++;
>   	else
>
>

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH] rt2x00: do not mark device gone on EPROTO errors during start
  2021-11-11 10:54                                 ` Exuvo
@ 2021-11-11 14:10                                   ` Stanislaw Gruszka
  2021-11-18  6:16                                     ` Thorsten Leemhuis
  2021-11-29 10:54                                     ` Kalle Valo
  0 siblings, 2 replies; 15+ messages in thread
From: Stanislaw Gruszka @ 2021-11-11 14:10 UTC (permalink / raw)
  To: Exuvo
  Cc: Kalle Valo, Thorsten Leemhuis, Stanislaw Gruszka, linux-wireless,
	Helmut Schaa, regressions

As reported by Exuvo is possible that we have lot's of EPROTO errors
during device start i.e. firmware load. But after that device works
correctly. Hence marking device gone by few EPROTO errors done by
commit e383c70474db ("rt2x00: check number of EPROTO errors") caused
regression - Exuvo device stop working after kernel update. To fix
disable the check during device start.

Reported-and-tested-by: Exuvo <exuvo@exuvo.se>
Fixes: e383c70474db ("rt2x00: check number of EPROTO errors")
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
---
 drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
index e4473a551241..74c3d8cb3100 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
@@ -25,6 +25,9 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status)
 	if (status == -ENODEV || status == -ENOENT)
 		return true;
 
+	if (!test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags))
+		return false;
+
 	if (status == -EPROTO || status == -ETIMEDOUT)
 		rt2x00dev->num_proto_errs++;
 	else
-- 
2.25.4

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] rt2x00: do not mark device gone on EPROTO errors during start
  2021-11-11 14:10                                   ` [PATCH] rt2x00: do not mark device gone on EPROTO errors during start Stanislaw Gruszka
@ 2021-11-18  6:16                                     ` Thorsten Leemhuis
  2021-11-19 14:19                                       ` Kalle Valo
  2021-11-29 10:54                                     ` Kalle Valo
  1 sibling, 1 reply; 15+ messages in thread
From: Thorsten Leemhuis @ 2021-11-18  6:16 UTC (permalink / raw)
  To: Stanislaw Gruszka, Exuvo
  Cc: Kalle Valo, Stanislaw Gruszka, linux-wireless, Helmut Schaa, regressions

Hi, this is your Linux kernel regression tracker speaking. Thx for this fix.

On 11.11.21 15:10, Stanislaw Gruszka wrote:
> As reported by Exuvo is possible that we have lot's of EPROTO errors
> during device start i.e. firmware load. But after that device works
> correctly. Hence marking device gone by few EPROTO errors done by
> commit e383c70474db ("rt2x00: check number of EPROTO errors") caused
> regression - Exuvo device stop working after kernel update. To fix
> disable the check during device start.
> 
> Reported-and-tested-by: Exuvo <exuvo@exuvo.se>

FWIW: In case you need to send an improved patch, could you
please add this before the 'Reported-by:' (see at (¹) below for the
reasoning):

Link:
https://lore.kernel.org/linux-wireless/bff7d309-a816-6a75-51b6-5928ef4f7a8c@exuvo.se/

And if the patch is already good to go: could the subsystem maintainer
please add it when applying?

> Fixes: e383c70474db ("rt2x00: check number of EPROTO errors")

What's the plan to getting this merged? Just wondering, because there
*afaics* wasn't any activity for a week now. Yes, e383c70474db was a
commit for v5.2-rc1, so it's not a new regression that needs to be
handled really urgently. But it's still a regression that would be good
to get fixed rather sooner than later, as there might be still people
out there then might run into this on a update.

Ciao, Thorsten (carrying his Linux kernel regression tracker hat)


(¹) Long story: The commit message would benefit from a link to the
regression report, for reasons explained in
Documentation/process/submitting-patches.rst. To quote:

```
If related discussions or any other background information behind the
change can be found on the web, add 'Link:' tags pointing to it. In case
your patch fixes a bug, for example, add a tag with a URL referencing
the report in the mailing list archives or a bug tracker; [...]
```

This concept is old, but the text was reworked recently to make this use
case for the Link: tag clearer. For details see:
https://git.kernel.org/linus/1f57bd42b77c

Yes, that "Link:" is not really crucial; but it's good to have if
someone needs to look into the backstory of this change sometime in the
future. But I care for a different reason. I'm tracking this regression
(and others) with regzbot, my Linux kernel regression tracking bot. This
bot will notice if a patch with a Link: tag to a tracked regression gets
posted and record that, which allowed anyone looking into the regression
to quickly gasp the current status from regzbot's webui
(https://linux-regtracking.leemhuis.info/regzbot ) or its reports. The
bot will also notice if a commit with a Link: tag to a regression report
is applied by Linus and then automatically mark the regression as
resolved then.

IOW: this tag makes my life a regression tracker a lot easier, as I
otherwise have to tell regzbot manually when the fix lands. :-/


P.S.: As a Linux kernel regression tracker I'm getting a lot of reports
on my table. I can only look briefly into most of them. Unfortunately
therefore I sometimes will get things wrong or miss something important.
I hope that's not the case here; if you think it is, don't hesitate to
tell me about it in a public reply. That's in everyone's interest, as
what I wrote above might be misleading to everyone reading this; any
suggestion I gave they thus might sent someone reading this down the
wrong rabbit hole, which none of us wants.

BTW, I have no personal interest in this issue, which is tracked using
regzbot, my Linux kernel regression tracking bot
(https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting
this mail to get things rolling again and hence don't need to be CC on
all further activitie wrt to this regression. Ohh, and feel free to
ignore the following lines, they are meant for regzbot:

#regzbot poke

> Cc: stable@vger.kernel.org
> Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
> ---
>  drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
> index e4473a551241..74c3d8cb3100 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
> @@ -25,6 +25,9 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status)
>  	if (status == -ENODEV || status == -ENOENT)
>  		return true;
>  
> +	if (!test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags))
> +		return false;
> +
>  	if (status == -EPROTO || status == -ETIMEDOUT)
>  		rt2x00dev->num_proto_errs++;
>  	else
> 

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] rt2x00: do not mark device gone on EPROTO errors during start
  2021-11-18  6:16                                     ` Thorsten Leemhuis
@ 2021-11-19 14:19                                       ` Kalle Valo
  0 siblings, 0 replies; 15+ messages in thread
From: Kalle Valo @ 2021-11-19 14:19 UTC (permalink / raw)
  To: Thorsten Leemhuis
  Cc: Stanislaw Gruszka, Exuvo, Stanislaw Gruszka, linux-wireless,
	Helmut Schaa, regressions

Thorsten Leemhuis <regressions@leemhuis.info> writes:

> Hi, this is your Linux kernel regression tracker speaking. Thx for this fix.
>
> On 11.11.21 15:10, Stanislaw Gruszka wrote:
>> As reported by Exuvo is possible that we have lot's of EPROTO errors
>> during device start i.e. firmware load. But after that device works
>> correctly. Hence marking device gone by few EPROTO errors done by
>> commit e383c70474db ("rt2x00: check number of EPROTO errors") caused
>> regression - Exuvo device stop working after kernel update. To fix
>> disable the check during device start.
>> 
>> Reported-and-tested-by: Exuvo <exuvo@exuvo.se>
>
> FWIW: In case you need to send an improved patch, could you
> please add this before the 'Reported-by:' (see at (¹) below for the
> reasoning):
>
> Link:
> https://lore.kernel.org/linux-wireless/bff7d309-a816-6a75-51b6-5928ef4f7a8c@exuvo.se/
>
> And if the patch is already good to go: could the subsystem maintainer
> please add it when applying?

Sure, I'll add it during commit.

>> Fixes: e383c70474db ("rt2x00: check number of EPROTO errors")
>
> What's the plan to getting this merged?

My plan is to commit this to wireless-drivers tree, the tree was just
closed due to the merge window.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: rt2x00: do not mark device gone on EPROTO errors during start
  2021-11-11 14:10                                   ` [PATCH] rt2x00: do not mark device gone on EPROTO errors during start Stanislaw Gruszka
  2021-11-18  6:16                                     ` Thorsten Leemhuis
@ 2021-11-29 10:54                                     ` Kalle Valo
  1 sibling, 0 replies; 15+ messages in thread
From: Kalle Valo @ 2021-11-29 10:54 UTC (permalink / raw)
  To: Stanislaw Gruszka
  Cc: Exuvo, Thorsten Leemhuis, Stanislaw Gruszka, linux-wireless,
	Helmut Schaa, regressions

Stanislaw Gruszka <stf_xl@wp.pl> wrote:

> As reported by Exuvo is possible that we have lot's of EPROTO errors
> during device start i.e. firmware load. But after that device works
> correctly. Hence marking device gone by few EPROTO errors done by
> commit e383c70474db ("rt2x00: check number of EPROTO errors") caused
> regression - Exuvo device stop working after kernel update. To fix
> disable the check during device start.
> 
> Link: https://lore.kernel.org/linux-wireless/bff7d309-a816-6a75-51b6-5928ef4f7a8c@exuvo.se/
> Reported-and-tested-by: Exuvo <exuvo@exuvo.se>
> Fixes: e383c70474db ("rt2x00: check number of EPROTO errors")
> Cc: stable@vger.kernel.org
> Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>

Patch applied to wireless-drivers.git, thanks.

ed53ae756930 rt2x00: do not mark device gone on EPROTO errors during start

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20211111141003.GA134627@wp.pl/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: rt2x00 regression #forregzbot
  2021-10-01  8:24                 ` Thorsten Leemhuis
@ 2021-11-30  9:16                   ` Thorsten Leemhuis
  0 siblings, 0 replies; 15+ messages in thread
From: Thorsten Leemhuis @ 2021-11-30  9:16 UTC (permalink / raw)
  To: regressions

On 01.10.21 10:24, Thorsten Leemhuis wrote:
> On 01.10.21 08:56, Kalle Valo wrote:
>> (adding regressions list for easier tracking)
> 
> Feel free to ignore this message. I write it to make regzbot track above
> issue. Regzbot is the regression tracking bot I'm working on. It's still
> in the early stages and this is still one of the first few regression I
> make it track to get started and things tested in the field. That also
> why I'm sending the mail just to the regressions list (it will do its
> full magic nevertheless). For details see:
> https://linux-regtracking.leemhuis.info/post/inital-regzbot-running/
> https://linux-regtracking.leemhuis.info/post/regzbot-approach/
> 
> #regzbot ^introduced e383c70474db32b9d4a3de6dfbd08784d19e6751
> #regzbot monitor
> https://lore.kernel.org/linux-wireless/bff7d309-a816-6a75-51b6-5928ef4f7a8c@exuvo.se/
> #regzbot ignore-activitiy

#regzbot fixed-by: ed53ae75693096f1c10b4561edd31a07b631bd72

TWIMC: this mail is primarily send for documentation purposes and for
regzbot, my Linux kernel regression tracking bot. These mails usually
contain '#forregzbot' in the subject, to make them easy to spot and filter.

Ciao, Thorsten, your Linux kernel regression tracker.

P.S:: Normally this mail wouldn't have been needed, but when I added
this regression to regzbot I didn't pointed it to the initial report

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2021-11-30  9:16 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bff7d309-a816-6a75-51b6-5928ef4f7a8c@exuvo.se>
     [not found] ` <20190927080303.GA7667@redhat.com>
     [not found]   ` <CA+GwT0B5SyRZnGLqwqOeuJK4CWMVc=dKaWre9VN8KQC6kBzKGw@mail.gmail.com>
     [not found]     ` <20191203075736.GA701@redhat.com>
     [not found]       ` <d74dab51-3a84-9035-d89e-ea8f63e89198@exuvo.se>
     [not found]         ` <a8eeb0bc-95da-291a-7fb9-5d15d1174c27@exuvo.se>
     [not found]           ` <c22673af-40e0-3af2-5ab7-69b23fc03598@exuvo.se>
     [not found]             ` <f935dc15-08bd-2e28-fc1b-b27634c618be@exuvo.se>
2021-10-01  6:56               ` rt2x00 regression Kalle Valo
2021-10-01  8:24                 ` Thorsten Leemhuis
2021-11-30  9:16                   ` rt2x00 regression #forregzbot Thorsten Leemhuis
2021-11-05 13:25                 ` rt2x00 regression Thorsten Leemhuis
2021-11-08 18:00                   ` Thorsten Leemhuis
     [not found]                     ` <20211109073127.ga109212@wp.pl>
2021-11-09  7:31                     ` Stanislaw Gruszka
2021-11-09 12:07                       ` Stanislaw Gruszka
2021-11-09 15:22                         ` Exuvo
     [not found]                           ` <cc85b4e8a038417b865069c6578acf50@grupawp.pl>
2021-11-10  6:59                             ` Kalle Valo
2021-11-10  8:01                               ` Stanislaw Gruszka
2021-11-11 10:54                                 ` Exuvo
2021-11-11 14:10                                   ` [PATCH] rt2x00: do not mark device gone on EPROTO errors during start Stanislaw Gruszka
2021-11-18  6:16                                     ` Thorsten Leemhuis
2021-11-19 14:19                                       ` Kalle Valo
2021-11-29 10:54                                     ` Kalle Valo
     [not found] <ca+gwt0b5syrznglqwqoeujk4cwmvc=dkawre9vn8kqc6kbzkgw@mail.gmail.com>

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).