[TLDR: I'm adding this regression report to the list of tracked
regressions; all text from me you find below is based on a few templates
paragraphs you might have encountered already already in similar form.]
Hi, this is your Linux kernel regression tracker.
On 09.06.22 08:58, Jaroslav Pulchart wrote:
>
> I'm struggling with broken network connectivity at VMs using linux
> bridge at host after update of kernel from 5.17.x to 5.18.x @ Dell
> R750 server with E810-XXV NICs.
>
> I noticed the kernel reports "Error setting promisc mode" in dmesg.
>
> # dmesg | grep 'Error setting promisc'
> [ 24.863557] ice 0000:31:00.0: Error setting promisc mode on VSI 6 (rc=-17)
> [ 24.878369] ice 0000:31:00.0: Error setting promisc mode on VSI 6 (rc=-17)
> [ 25.045834] ice 0000:31:00.0: Error setting promisc mode on VSI 6 (rc=-17)
> [ 25.129840] ice 0000:b1:00.0: Error setting promisc mode on VSI 6 (rc=-17)
> [ 25.144440] ice 0000:b1:00.0: Error setting promisc mode on VSI 6 (rc=-17)
>
> # lspci -s 0000:31:00.0
> 31:00.0 Ethernet controller: Intel Corporation Ethernet Controller
> E810-XXV for SFP (rev 02)
> # lspci -s 0000:b1:00.0
> b1:00.0 Ethernet controller: Intel Corporation Ethernet Controller
> E810-XXV for SFP (rev 02)
>
> It is easy to reproduce by:
> # ip link set em1 promisc on
> # dmesg -T | tail -n 1
> [Thu Jun 9 08:48:19 2022] ice 0000:31:00.0: Error setting promisc
> mode on VSI 6 (rc=-17)
>
> Could it be an 'ice' driver bug introduced in the 5.18 kernel?
CCing the regression mailing list, as it should be in the loop for all
regressions, as explained here:
https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
Jaroslav, did you try to revert the change that was suggested to you in
https://lore.kernel.org/all/[email protected]/
Did it help?
Anyway: To be sure below issue doesn't fall through the cracks
unnoticed, I'm adding it to regzbot, my Linux kernel regression tracking
bot:
#regzbot ^introduced v5.17 to v5.18
#regzbot title net: ice: Error setting promisc mode on VSI 6 (rc=-17) @
5.18.x
#regzbot monitor
https://lore.kernel.org/all/CAK8fFZ68+xZ2Z0vDWnihF8PeJKEmEwCyyF-8W9PCZJTd8zfp-A@mail.gmail.com/
#regzbot monitor
https://lore.kernel.org/all/CAK8fFZ61mQ3AYpdWjWtyUXzrs-RVMW61mBLrjRDXBxB-F9GzbA@mail.gmail.com/
#regzbot ignore-activity
This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply -- ideally with also
telling regzbot about it, as explained here:
https://linux-regtracking.leemhuis.info/tracked-regression/
Reminder for developers: When fixing the issue, add 'Link:' tags
pointing to the report (the mail this one replied to), as the kernel's
documentation call for; above page explains why this is important for
tracked regressions.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.
Hello,
yes, I revert that commit. Still the promiscs cannot be set and the dmesg
error message changed to:
---------------
$ ip link set em1 promisc on
$ dmesg
...
ice 0000:63:00.0 em1: Error setting Multicast promiscuous mode on VSI 6
...
---------------
Jaroslav P.
ne 19. 6. 2022 v 13:51 odesílatel Thorsten Leemhuis
<[email protected]> napsal:
>
> [TLDR: I'm adding this regression report to the list of tracked
> regressions; all text from me you find below is based on a few templates
> paragraphs you might have encountered already already in similar form.]
>
> Hi, this is your Linux kernel regression tracker.
>
> On 09.06.22 08:58, Jaroslav Pulchart wrote:
> >
> > I'm struggling with broken network connectivity at VMs using linux
> > bridge at host after update of kernel from 5.17.x to 5.18.x @ Dell
> > R750 server with E810-XXV NICs.
> >
> > I noticed the kernel reports "Error setting promisc mode" in dmesg.
> >
> > # dmesg | grep 'Error setting promisc'
> > [ 24.863557] ice 0000:31:00.0: Error setting promisc mode on VSI 6 (rc=-17)
> > [ 24.878369] ice 0000:31:00.0: Error setting promisc mode on VSI 6 (rc=-17)
> > [ 25.045834] ice 0000:31:00.0: Error setting promisc mode on VSI 6 (rc=-17)
> > [ 25.129840] ice 0000:b1:00.0: Error setting promisc mode on VSI 6 (rc=-17)
> > [ 25.144440] ice 0000:b1:00.0: Error setting promisc mode on VSI 6 (rc=-17)
> >
> > # lspci -s 0000:31:00.0
> > 31:00.0 Ethernet controller: Intel Corporation Ethernet Controller
> > E810-XXV for SFP (rev 02)
> > # lspci -s 0000:b1:00.0
> > b1:00.0 Ethernet controller: Intel Corporation Ethernet Controller
> > E810-XXV for SFP (rev 02)
> >
> > It is easy to reproduce by:
> > # ip link set em1 promisc on
> > # dmesg -T | tail -n 1
> > [Thu Jun 9 08:48:19 2022] ice 0000:31:00.0: Error setting promisc
> > mode on VSI 6 (rc=-17)
> >
> > Could it be an 'ice' driver bug introduced in the 5.18 kernel?
>
> CCing the regression mailing list, as it should be in the loop for all
> regressions, as explained here:
> https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
>
> Jaroslav, did you try to revert the change that was suggested to you in
> https://lore.kernel.org/all/[email protected]/
> Did it help?
>
> Anyway: To be sure below issue doesn't fall through the cracks
> unnoticed, I'm adding it to regzbot, my Linux kernel regression tracking
> bot:
>
> #regzbot ^introduced v5.17 to v5.18
> #regzbot title net: ice: Error setting promisc mode on VSI 6 (rc=-17) @
> 5.18.x
> #regzbot monitor
> https://lore.kernel.org/all/CAK8fFZ68+xZ2Z0vDWnihF8PeJKEmEwCyyF-8W9PCZJTd8zfp-A@mail.gmail.com/
> #regzbot monitor
> https://lore.kernel.org/all/CAK8fFZ61mQ3AYpdWjWtyUXzrs-RVMW61mBLrjRDXBxB-F9GzbA@mail.gmail.com/
> #regzbot ignore-activity
>
> This isn't a regression? This issue or a fix for it are already
> discussed somewhere else? It was fixed already? You want to clarify when
> the regression started to happen? Or point out I got the title or
> something else totally wrong? Then just reply -- ideally with also
> telling regzbot about it, as explained here:
> https://linux-regtracking.leemhuis.info/tracked-regression/
>
> Reminder for developers: When fixing the issue, add 'Link:' tags
> pointing to the report (the mail this one replied to), as the kernel's
> documentation call for; above page explains why this is important for
> tracked regressions.
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>
> P.S.: As the Linux kernel's regression tracker I deal with a lot of
> reports and sometimes miss something important when writing mails like
> this. If that's the case here, don't hesitate to tell me in a public
> reply, it's in everyone's interest to set the public record straight.
[adding Michal to the recipients]
Hi, this is your Linux kernel regression tracker. Top-posting for once,
to make this easily accessible to everyone.
Intel network maintainers, help me out here please. Has anything been
done to address this regression? It looks like Jaroslav didn't even get
a single reply. What's up there?
BTW, took a quick look into the issue and noticed a the patch "ice: Fix
promiscuous mode not turning off" from Michal:
https://lore.kernel.org/all/[email protected]/
Is this maybe fixing this? Then it would be good to add Link and
Reported-by tags to that patch.
Or is this something else and Jaroslav needs to bisect?
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.
#regzbot poke
On 19.06.22 19:00, Jaroslav Pulchart wrote:
> Hello,
>
> yes, I revert that commit. Still the promiscs cannot be set and the dmesg
> error message changed to:
> ---------------
> $ ip link set em1 promisc on
> $ dmesg
> ...
> ice 0000:63:00.0 em1: Error setting Multicast promiscuous mode on VSI 6
> ...
> ---------------
>
> Jaroslav P.
>
> ne 19. 6. 2022 v 13:51 odesílatel Thorsten Leemhuis
> <[email protected]> napsal:
>
>>
>> [TLDR: I'm adding this regression report to the list of tracked
>> regressions; all text from me you find below is based on a few templates
>> paragraphs you might have encountered already already in similar form.]
>>
>> Hi, this is your Linux kernel regression tracker.
>>
>> On 09.06.22 08:58, Jaroslav Pulchart wrote:
>>>
>>> I'm struggling with broken network connectivity at VMs using linux
>>> bridge at host after update of kernel from 5.17.x to 5.18.x @ Dell
>>> R750 server with E810-XXV NICs.
>>>
>>> I noticed the kernel reports "Error setting promisc mode" in dmesg.
>>>
>>> # dmesg | grep 'Error setting promisc'
>>> [ 24.863557] ice 0000:31:00.0: Error setting promisc mode on VSI 6 (rc=-17)
>>> [ 24.878369] ice 0000:31:00.0: Error setting promisc mode on VSI 6 (rc=-17)
>>> [ 25.045834] ice 0000:31:00.0: Error setting promisc mode on VSI 6 (rc=-17)
>>> [ 25.129840] ice 0000:b1:00.0: Error setting promisc mode on VSI 6 (rc=-17)
>>> [ 25.144440] ice 0000:b1:00.0: Error setting promisc mode on VSI 6 (rc=-17)
>>>
>>> # lspci -s 0000:31:00.0
>>> 31:00.0 Ethernet controller: Intel Corporation Ethernet Controller
>>> E810-XXV for SFP (rev 02)
>>> # lspci -s 0000:b1:00.0
>>> b1:00.0 Ethernet controller: Intel Corporation Ethernet Controller
>>> E810-XXV for SFP (rev 02)
>>>
>>> It is easy to reproduce by:
>>> # ip link set em1 promisc on
>>> # dmesg -T | tail -n 1
>>> [Thu Jun 9 08:48:19 2022] ice 0000:31:00.0: Error setting promisc
>>> mode on VSI 6 (rc=-17)
>>>
>>> Could it be an 'ice' driver bug introduced in the 5.18 kernel?
>>
>> CCing the regression mailing list, as it should be in the loop for all
>> regressions, as explained here:
>> https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
>>
>> Jaroslav, did you try to revert the change that was suggested to you in
>> https://lore.kernel.org/all/[email protected]/
>> Did it help?
>>
>> Anyway: To be sure below issue doesn't fall through the cracks
>> unnoticed, I'm adding it to regzbot, my Linux kernel regression tracking
>> bot:
>>
>> #regzbot ^introduced v5.17 to v5.18
>> #regzbot title net: ice: Error setting promisc mode on VSI 6 (rc=-17) @
>> 5.18.x
>> #regzbot monitor
>> https://lore.kernel.org/all/CAK8fFZ68+xZ2Z0vDWnihF8PeJKEmEwCyyF-8W9PCZJTd8zfp-A@mail.gmail.com/
>> #regzbot monitor
>> https://lore.kernel.org/all/CAK8fFZ61mQ3AYpdWjWtyUXzrs-RVMW61mBLrjRDXBxB-F9GzbA@mail.gmail.com/
>> #regzbot ignore-activity
>>
>> This isn't a regression? This issue or a fix for it are already
>> discussed somewhere else? It was fixed already? You want to clarify when
>> the regression started to happen? Or point out I got the title or
>> something else totally wrong? Then just reply -- ideally with also
>> telling regzbot about it, as explained here:
>> https://linux-regtracking.leemhuis.info/tracked-regression/
>>
>> Reminder for developers: When fixing the issue, add 'Link:' tags
>> pointing to the report (the mail this one replied to), as the kernel's
>> documentation call for; above page explains why this is important for
>> tracked regressions.
>>
>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>>
>> P.S.: As the Linux kernel's regression tracker I deal with a lot of
>> reports and sometimes miss something important when writing mails like
>> this. If that's the case here, don't hesitate to tell me in a public
>> reply, it's in everyone's interest to set the public record straight.
>
>
Hi,
Thanks for your e-mail, unfortunately my patch is not fixing this issue.
Adding Grzegorz Siwik, since he is working on similar issue and already
has a patch that is being tested/reviewed internally at the moment.
He can you a send patch tomorrow so you can test if it also fixes your
problem.
BR,
Michał
On 7/5/2022 11:43 AM, Thorsten Leemhuis wrote:
> [adding Michal to the recipients]
>
> Hi, this is your Linux kernel regression tracker. Top-posting for once,
> to make this easily accessible to everyone.
>
> Intel network maintainers, help me out here please. Has anything been
> done to address this regression? It looks like Jaroslav didn't even get
> a single reply. What's up there?
>
> BTW, took a quick look into the issue and noticed a the patch "ice: Fix
> promiscuous mode not turning off" from Michal:
> https://lore.kernel.org/all/[email protected]/
>
> Is this maybe fixing this? Then it would be good to add Link and
> Reported-by tags to that patch.
>
> Or is this something else and Jaroslav needs to bisect?
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>
> P.S.: As the Linux kernel's regression tracker I deal with a lot of
> reports and sometimes miss something important when writing mails like
> this. If that's the case here, don't hesitate to tell me in a public
> reply, it's in everyone's interest to set the public record straight.
>
> #regzbot poke
>
> On 19.06.22 19:00, Jaroslav Pulchart wrote:
>> Hello,
>>
>> yes, I revert that commit. Still the promiscs cannot be set and the dmesg
>> error message changed to:
>> ---------------
>> $ ip link set em1 promisc on
>> $ dmesg
>> ...
>> ice 0000:63:00.0 em1: Error setting Multicast promiscuous mode on VSI 6
>> ...
>> ---------------
>>
>> Jaroslav P.
>>
>> ne 19. 6. 2022 v 13:51 odesílatel Thorsten Leemhuis
>> <[email protected]> napsal:
>>
>>> [TLDR: I'm adding this regression report to the list of tracked
>>> regressions; all text from me you find below is based on a few templates
>>> paragraphs you might have encountered already already in similar form.]
>>>
>>> Hi, this is your Linux kernel regression tracker.
>>>
>>> On 09.06.22 08:58, Jaroslav Pulchart wrote:
>>>> I'm struggling with broken network connectivity at VMs using linux
>>>> bridge at host after update of kernel from 5.17.x to 5.18.x @ Dell
>>>> R750 server with E810-XXV NICs.
>>>>
>>>> I noticed the kernel reports "Error setting promisc mode" in dmesg.
>>>>
>>>> # dmesg | grep 'Error setting promisc'
>>>> [ 24.863557] ice 0000:31:00.0: Error setting promisc mode on VSI 6 (rc=-17)
>>>> [ 24.878369] ice 0000:31:00.0: Error setting promisc mode on VSI 6 (rc=-17)
>>>> [ 25.045834] ice 0000:31:00.0: Error setting promisc mode on VSI 6 (rc=-17)
>>>> [ 25.129840] ice 0000:b1:00.0: Error setting promisc mode on VSI 6 (rc=-17)
>>>> [ 25.144440] ice 0000:b1:00.0: Error setting promisc mode on VSI 6 (rc=-17)
>>>>
>>>> # lspci -s 0000:31:00.0
>>>> 31:00.0 Ethernet controller: Intel Corporation Ethernet Controller
>>>> E810-XXV for SFP (rev 02)
>>>> # lspci -s 0000:b1:00.0
>>>> b1:00.0 Ethernet controller: Intel Corporation Ethernet Controller
>>>> E810-XXV for SFP (rev 02)
>>>>
>>>> It is easy to reproduce by:
>>>> # ip link set em1 promisc on
>>>> # dmesg -T | tail -n 1
>>>> [Thu Jun 9 08:48:19 2022] ice 0000:31:00.0: Error setting promisc
>>>> mode on VSI 6 (rc=-17)
>>>>
>>>> Could it be an 'ice' driver bug introduced in the 5.18 kernel?
>>> CCing the regression mailing list, as it should be in the loop for all
>>> regressions, as explained here:
>>> https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
>>>
>>> Jaroslav, did you try to revert the change that was suggested to you in
>>> https://lore.kernel.org/all/[email protected]/
>>> Did it help?
>>>
>>> Anyway: To be sure below issue doesn't fall through the cracks
>>> unnoticed, I'm adding it to regzbot, my Linux kernel regression tracking
>>> bot:
>>>
>>> #regzbot ^introduced v5.17 to v5.18
>>> #regzbot title net: ice: Error setting promisc mode on VSI 6 (rc=-17) @
>>> 5.18.x
>>> #regzbot monitor
>>> https://lore.kernel.org/all/CAK8fFZ68+xZ2Z0vDWnihF8PeJKEmEwCyyF-8W9PCZJTd8zfp-A@mail.gmail.com/
>>> #regzbot monitor
>>> https://lore.kernel.org/all/CAK8fFZ61mQ3AYpdWjWtyUXzrs-RVMW61mBLrjRDXBxB-F9GzbA@mail.gmail.com/
>>> #regzbot ignore-activity
>>>
>>> This isn't a regression? This issue or a fix for it are already
>>> discussed somewhere else? It was fixed already? You want to clarify when
>>> the regression started to happen? Or point out I got the title or
>>> something else totally wrong? Then just reply -- ideally with also
>>> telling regzbot about it, as explained here:
>>> https://linux-regtracking.leemhuis.info/tracked-regression/
>>>
>>> Reminder for developers: When fixing the issue, add 'Link:' tags
>>> pointing to the report (the mail this one replied to), as the kernel's
>>> documentation call for; above page explains why this is important for
>>> tracked regressions.
>>>
>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>>>
>>> P.S.: As the Linux kernel's regression tracker I deal with a lot of
>>> reports and sometimes miss something important when writing mails like
>>> this. If that's the case here, don't hesitate to tell me in a public
>>> reply, it's in everyone's interest to set the public record straight.
>>
On 05.07.22 15:51, Wilczynski, Michal wrote:
>
> Adding Grzegorz Siwik, since he is working on similar issue and already
> has a patch that is being tested/reviewed internally at the moment.
>
> He can you a send patch tomorrow so you can test if it also fixes your
> problem.
Tony, Jesse, I have to wonder: why is it taken so long to get this
regression fixed? The regression was reported 69 days ago and the first
patches to fix this went out 40 days ago. That's far from ideal.
Reminder: this regression ideally should have been fixed within two
weeks after the report, as explained here:
https://docs.kernel.org/process/handling-regressions.html
FWIW, in case anyone wonders: the latest patch-series to fix this can be
found here:
https://lore.kernel.org/intel-wired-lan/[email protected]/
Thx for working on it Grzegorz! Side note: might be good to add a
"Reported-by", but it's not really important I guess.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.
BTW, let me update the regzbot status:
#regzbot introduce: 5eda8afd6bcc
#regzbot poke
> On 7/5/205eda8afd6bcc22 11:43 AM, Thorsten Leemhuis wrote:
>> [adding Michal to the recipients]
>>
>> Hi, this is your Linux kernel regression tracker. Top-posting for once,
>> to make this easily accessible to everyone.
>>
>> Intel network maintainers, help me out here please. Has anything been
>> done to address this regression? It looks like Jaroslav didn't even get
>> a single reply. What's up there?
>>
>> BTW, took a quick look into the issue and noticed a the patch "ice: Fix
>> promiscuous mode not turning off" from Michal:
>> https://lore.kernel.org/all/[email protected]/
>>
>> Is this maybe fixing this? Then it would be good to add Link and
>> Reported-by tags to that patch.
>>
>> Or is this something else and Jaroslav needs to bisect?
>>
>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>>
>> P.S.: As the Linux kernel's regression tracker I deal with a lot of
>> reports and sometimes miss something important when writing mails like
>> this. If that's the case here, don't hesitate to tell me in a public
>> reply, it's in everyone's interest to set the public record straight.
>>
>> #regzbot poke
>>
>> On 19.06.22 19:00, Jaroslav Pulchart wrote:
>>> Hello,
>>>
>>> yes, I revert that commit. Still the promiscs cannot be set and the
>>> dmesg
>>> error message changed to:
>>> ---------------
>>> $ ip link set em1 promisc on
>>> $ dmesg
>>> ...
>>> ice 0000:63:00.0 em1: Error setting Multicast promiscuous mode on VSI 6
>>> ...
>>> ---------------
>>>
>>> Jaroslav P.
>>>
>>> ne 19. 6. 2022 v 13:51 odesílatel Thorsten Leemhuis
>>> <[email protected]> napsal:
>>>
>>>> [TLDR: I'm adding this regression report to the list of tracked
>>>> regressions; all text from me you find below is based on a few
>>>> templates
>>>> paragraphs you might have encountered already already in similar form.]
>>>>
>>>> Hi, this is your Linux kernel regression tracker.
>>>>
>>>> On 09.06.22 08:58, Jaroslav Pulchart wrote:
>>>>> I'm struggling with broken network connectivity at VMs using linux
>>>>> bridge at host after update of kernel from 5.17.x to 5.18.x @ Dell
>>>>> R750 server with E810-XXV NICs.
>>>>>
>>>>> I noticed the kernel reports "Error setting promisc mode" in dmesg.
>>>>>
>>>>> # dmesg | grep 'Error setting promisc'
>>>>> [ 24.863557] ice 0000:31:00.0: Error setting promisc mode on VSI
>>>>> 6 (rc=-17)
>>>>> [ 24.878369] ice 0000:31:00.0: Error setting promisc mode on VSI
>>>>> 6 (rc=-17)
>>>>> [ 25.045834] ice 0000:31:00.0: Error setting promisc mode on VSI
>>>>> 6 (rc=-17)
>>>>> [ 25.129840] ice 0000:b1:00.0: Error setting promisc mode on VSI
>>>>> 6 (rc=-17)
>>>>> [ 25.144440] ice 0000:b1:00.0: Error setting promisc mode on VSI
>>>>> 6 (rc=-17)
>>>>>
>>>>> # lspci -s 0000:31:00.0
>>>>> 31:00.0 Ethernet controller: Intel Corporation Ethernet Controller
>>>>> E810-XXV for SFP (rev 02)
>>>>> # lspci -s 0000:b1:00.0
>>>>> b1:00.0 Ethernet controller: Intel Corporation Ethernet Controller
>>>>> E810-XXV for SFP (rev 02)
>>>>>
>>>>> It is easy to reproduce by:
>>>>> # ip link set em1 promisc on
>>>>> # dmesg -T | tail -n 1
>>>>> [Thu Jun 9 08:48:19 2022] ice 0000:31:00.0: Error setting promisc
>>>>> mode on VSI 6 (rc=-17)
>>>>>
>>>>> Could it be an 'ice' driver bug introduced in the 5.18 kernel?
>>>> CCing the regression mailing list, as it should be in the loop for all
>>>> regressions, as explained here:
>>>> https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
>>>>
>>>> Jaroslav, did you try to revert the change that was suggested to you in
>>>> https://lore.kernel.org/all/[email protected]/
>>>> Did it help?
>>>>
>>>> Anyway: To be sure below issue doesn't fall through the cracks
>>>> unnoticed, I'm adding it to regzbot, my Linux kernel regression
>>>> tracking
>>>> bot:
>>>>
>>>> #regzbot ^introduced v5.17 to v5.18
>>>> #regzbot title net: ice: Error setting promisc mode on VSI 6 (rc=-17) @
>>>> 5.18.x
>>>> #regzbot monitor
>>>> https://lore.kernel.org/all/CAK8fFZ68+xZ2Z0vDWnihF8PeJKEmEwCyyF-8W9PCZJTd8zfp-A@mail.gmail.com/
>>>> #regzbot monitor
>>>> https://lore.kernel.org/all/CAK8fFZ61mQ3AYpdWjWtyUXzrs-RVMW61mBLrjRDXBxB-F9GzbA@mail.gmail.com/
>>>> #regzbot ignore-activity
>>>>
>>>> This isn't a regression? This issue or a fix for it are already
>>>> discussed somewhere else? It was fixed already? You want to clarify
>>>> when
>>>> the regression started to happen? Or point out I got the title or
>>>> something else totally wrong? Then just reply -- ideally with also
>>>> telling regzbot about it, as explained here:
>>>> https://linux-regtracking.leemhuis.info/tracked-regression/
>>>>
>>>> Reminder for developers: When fixing the issue, add 'Link:' tags
>>>> pointing to the report (the mail this one replied to), as the kernel's
>>>> documentation call for; above page explains why this is important for
>>>> tracked regressions.
>>>>
>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker'
>>>> hat)
>>>>
>>>> P.S.: As the Linux kernel's regression tracker I deal with a lot of
>>>> reports and sometimes miss something important when writing mails like
>>>> this. If that's the case here, don't hesitate to tell me in a public
>>>> reply, it's in everyone's interest to set the public record straight.
>>>
> _______________________________________________
> Intel-wired-lan mailing list
> [email protected]
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
On 8/17/2022 2:08 AM, Thorsten Leemhuis wrote:
> On 05.07.22 15:51, Wilczynski, Michal wrote:
>>
>> Adding Grzegorz Siwik, since he is working on similar issue and already
>> has a patch that is being tested/reviewed internally at the moment.
>>
>> He can you a send patch tomorrow so you can test if it also fixes your
>> problem.
>
> Tony, Jesse, I have to wonder: why is it taken so long to get this
> regression fixed? The regression was reported 69 days ago and the first
> patches to fix this went out 40 days ago. That's far from ideal.
Hi Thorsten,
Our validation found issues when testing the original fix which caused
the delays as the new issues were being worked out.
> Reminder: this regression ideally should have been fixed within two
> weeks after the report, as explained here:
> https://docs.kernel.org/process/handling-regressions.html
>
> FWIW, in case anyone wonders: the latest patch-series to fix this can be
> found here:
> https://lore.kernel.org/intel-wired-lan/[email protected]/
I was going to point you to the newest patches, but you located them.
Our validation finished testing them yesterday so the pull request for
these will be going out to netdev today.
Thanks,
Tony
On 17.08.22 17:59, Tony Nguyen wrote:
> On 8/17/2022 2:08 AM, Thorsten Leemhuis wrote:
>> On 05.07.22 15:51, Wilczynski, Michal wrote:
>>>
>>> Adding Grzegorz Siwik, since he is working on similar issue and already
>>> has a patch that is being tested/reviewed internally at the moment.
>>>
>>> He can you a send patch tomorrow so you can test if it also fixes your
>>> problem.
>>
>> Tony, Jesse, I have to wonder: why is it taken so long to get this
>> regression fixed? The regression was reported 69 days ago and the first
>> patches to fix this went out 40 days ago. That's far from ideal.
>
> Our validation found issues when testing the original fix which caused
> the delays as the new issues were being worked out.
Yeah, that happens, still I wish it wouldn't taken *that* much longer
then what's outlined in the docs.
Side note: this and a similar issue I had today made me wonder if we
need a tag to make "this is a regression fix" more obvious to reviewers
and maintainers. But I guess that overblown; should be enough if
developers make it obvious in their cover letter or description that
this fixes a regression.
>> Reminder: this regression ideally should have been fixed within two
>> weeks after the report, as explained here:
>> https://docs.kernel.org/process/handling-regressions.html
>>
>> FWIW, in case anyone wonders: the latest patch-series to fix this can be
>> found here:
>> https://lore.kernel.org/intel-wired-lan/[email protected]/
>
> I was going to point you to the newest patches, but you located them.
> Our validation finished testing them yesterday so the pull request for
> these will be going out to netdev today.
Great, many thx.
Ciao, Thorsten
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.
On 19.06.22 13:50, Thorsten Leemhuis wrote:
> [TLDR: I'm adding this regression report to the list of tracked
> regressions; all text from me you find below is based on a few templates
> paragraphs you might have encountered already already in similar form.]
>
> On 09.06.22 08:58, Jaroslav Pulchart wrote:
>>
>> I'm struggling with broken network connectivity at VMs using linux
>> bridge at host after update of kernel from 5.17.x to 5.18.x @ Dell
>> R750 server with E810-XXV NICs.
>>
>> I noticed the kernel reports "Error setting promisc mode" in dmesg.
>>
>> # dmesg | grep 'Error setting promisc'
>> [ 24.863557] ice 0000:31:00.0: Error setting promisc mode on VSI 6 (rc=-17)
>> [ 24.878369] ice 0000:31:00.0: Error setting promisc mode on VSI 6 (rc=-17)
>> [ 25.045834] ice 0000:31:00.0: Error setting promisc mode on VSI 6 (rc=-17)
>> [ 25.129840] ice 0000:b1:00.0: Error setting promisc mode on VSI 6 (rc=-17)
>> [ 25.144440] ice 0000:b1:00.0: Error setting promisc mode on VSI 6 (rc=-17)
>
> Anyway: To be sure below issue doesn't fall through the cracks
> unnoticed, I'm adding it to regzbot, my Linux kernel regression tracking
> bot:
>
> #regzbot ^introduced v5.17 to v5.18
> #regzbot title net: ice: Error setting promisc mode on VSI 6 (rc=-17) @
> 5.18.x
> #regzbot monitor
> https://lore.kernel.org/all/CAK8fFZ68+xZ2Z0vDWnihF8PeJKEmEwCyyF-8W9PCZJTd8zfp-A@mail.gmail.com/
> #regzbot monitor
> https://lore.kernel.org/all/CAK8fFZ61mQ3AYpdWjWtyUXzrs-RVMW61mBLrjRDXBxB-F9GzbA@mail.gmail.com/
> #regzbot ignore-activity
#regzbot fixed-by: 79956b83ed4281c35561c39254558092d96a9ed1