On 15.11.23 01:54, Jay Vosburgh wrote:
> Bagas Sanjaya <[email protected]> wrote:
>
>> I come across LACP bonding regression on Bugzilla [1].
Side note: Stephen forwards some (all?) network regressions to the right
people:
https://lore.kernel.org/all/[email protected]/
Would be best to check for that, no need to forward things twice, that
just results in a mess.
>> The reporter
>> (Cc'ed) has two regressions. The first is actual LACP bonding
>> regression (but terse):
>>
>>> Till linkx kernel 6.5.7 it is working fine, but after upgrading to 6.6.1 ping stop working with LACP bonding.
>>> When we disable SR-IOV from bios , everything working fine
Makes me wonder if things have been working with or without the OOT
module on 6.5.7, as strictly speaking it's only considered a kernel
regression if thing worked with a vanilla kernel (e.g. without OOT
modules) beforehand and broke when switching to a newer vanilla kernel.
If that's the case it would be okay to add to regzbot.
>> And the second is out-of-tree module FTBFS:
> [... skip OOT stuff ...]
>
>> Should I add the first regression to regzbot (since the second one
>> is obviously out-of-tree problem), or should I asked detailed regression
>> info to the reporter?
>
> My vote is to get additional information. Given the nature of
> the workaround ("When we disable SR-IOV from bios , everything working
> fine"), it's plausible that the underlying cause is something
> platform-specific.
Maybe, but when it comes to the "no regressions" rule that likely makes
no difference from Linus perspective.
But I guess unless the intel folks or someone else has an idea what
might be wrong here we likely need a bisection (with vanilla kernels of
course) to get anywhere.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
Its not hardware issue when I do rmmod iavf ping started working .
So issue is certainly in this kernel and with sriov only
Iavf id Nic driver for VF(sriovnic)
Thanks,
Anil
> On Nov 14, 2023, at 9:50 PM, Linux regression tracking (Thorsten Leemhuis) <[email protected]> wrote:
>
> On 15.11.23 01:54, Jay Vosburgh wrote:
>> Bagas Sanjaya <[email protected]> wrote:
>>
>>> I come across LACP bonding regression on Bugzilla [1].
>
> Side note: Stephen forwards some (all?) network regressions to the right
> people:
> https://lore.kernel.org/all/[email protected]/
>
> Would be best to check for that, no need to forward things twice, that
> just results in a mess.
>
>>> The reporter
>>> (Cc'ed) has two regressions. The first is actual LACP bonding
>>> regression (but terse):
>>>
>>>> Till linkx kernel 6.5.7 it is working fine, but after upgrading to 6.6.1 ping stop working with LACP bonding.
>>>> When we disable SR-IOV from bios , everything working fine
>
> Makes me wonder if things have been working with or without the OOT
> module on 6.5.7, as strictly speaking it's only considered a kernel
> regression if thing worked with a vanilla kernel (e.g. without OOT
> modules) beforehand and broke when switching to a newer vanilla kernel.
> If that's the case it would be okay to add to regzbot.
>
>>> And the second is out-of-tree module FTBFS:
>> [... skip OOT stuff ...]
>>
>>> Should I add the first regression to regzbot (since the second one
>>> is obviously out-of-tree problem), or should I asked detailed regression
>>> info to the reporter?
>>
>> My vote is to get additional information. Given the nature of
>> the workaround ("When we disable SR-IOV from bios , everything working
>> fine"), it's plausible that the underlying cause is something
>> platform-specific.
>
> Maybe, but when it comes to the "no regressions" rule that likely makes
> no difference from Linus perspective.
>
> But I guess unless the intel folks or someone else has an idea what
> might be wrong here we likely need a bisection (with vanilla kernels of
> course) to get anywhere.
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
Following error error scribing to said is also new
> On Nov 14, 2023, at 9:50 PM, Linux regression tracking (Thorsten Leemhuis) <[email protected]> wrote:
>
> On 15.11.23 01:54, Jay Vosburgh wrote:
>> Bagas Sanjaya <[email protected]> wrote:
>>
>>> I come across LACP bonding regression on Bugzilla [1].
>
> Side note: Stephen forwards some (all?) network regressions to the right
> people:
> https://lore.kernel.org/all/[email protected]/
>
> Would be best to check for that, no need to forward things twice, that
> just results in a mess.
>
>>> The reporter
>>> (Cc'ed) has two regressions. The first is actual LACP bonding
>>> regression (but terse):
>>>
>>>> Till linkx kernel 6.5.7 it is working fine, but after upgrading to 6.6.1 ping stop working with LACP bonding.
>>>> When we disable SR-IOV from bios , everything working fine
>
> Makes me wonder if things have been working with or without the OOT
> module on 6.5.7, as strictly speaking it's only considered a kernel
> regression if thing worked with a vanilla kernel (e.g. without OOT
> modules) beforehand and broke when switching to a newer vanilla kernel.
> If that's the case it would be okay to add to regzbot.
>
>>> And the second is out-of-tree module FTBFS:
>> [... skip OOT stuff ...]
>>
>>> Should I add the first regression to regzbot (since the second one
>>> is obviously out-of-tree problem), or should I asked detailed regression
>>> info to the reporter?
>>
>> My vote is to get additional information. Given the nature of
>> the workaround ("When we disable SR-IOV from bios , everything working
>> fine"), it's plausible that the underlying cause is something
>> platform-specific.
>
> Maybe, but when it comes to the "no regressions" rule that likely makes
> no difference from Linus perspective.
>
> But I guess unless the intel folks or someone else has an idea what
> might be wrong here we likely need a bisection (with vanilla kernels of
> course) to get anywhere.
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
On Wed, Nov 15, 2023 at 06:50:26AM +0100, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 15.11.23 01:54, Jay Vosburgh wrote:
> > Bagas Sanjaya <[email protected]> wrote:
> >
> >> I come across LACP bonding regression on Bugzilla [1].
>
> Side note: Stephen forwards some (all?) network regressions to the right
> people:
> https://lore.kernel.org/all/[email protected]/
>
> Would be best to check for that, no need to forward things twice, that
> just results in a mess.
>
> >> The reporter
> >> (Cc'ed) has two regressions. The first is actual LACP bonding
> >> regression (but terse):
> >>
> >>> Till linkx kernel 6.5.7 it is working fine, but after upgrading to 6.6.1 ping stop working with LACP bonding.
> >>> When we disable SR-IOV from bios , everything working fine
>
> Makes me wonder if things have been working with or without the OOT
> module on 6.5.7, as strictly speaking it's only considered a kernel
> regression if thing worked with a vanilla kernel (e.g. without OOT
> modules) beforehand and broke when switching to a newer vanilla kernel.
> If that's the case it would be okay to add to regzbot.
>
> >> And the second is out-of-tree module FTBFS:
> > [... skip OOT stuff ...]
> >
> >> Should I add the first regression to regzbot (since the second one
> >> is obviously out-of-tree problem), or should I asked detailed regression
> >> info to the reporter?
> >
> > My vote is to get additional information. Given the nature of
> > the workaround ("When we disable SR-IOV from bios , everything working
> > fine"), it's plausible that the underlying cause is something
> > platform-specific.
>
> Maybe, but when it comes to the "no regressions" rule that likely makes
> no difference from Linus perspective.
>
> But I guess unless the intel folks or someone else has an idea what
> might be wrong here we likely need a bisection (with vanilla kernels of
> course) to get anywhere.
>
OK, thanks!
--
An old man doll... just what I always wanted! - Clara
On Tue, Nov 14, 2023 at 10:13:20PM -0800, Anil Choudhary wrote:
> Its not hardware issue when I do rmmod iavf ping started working .
> So issue is certainly in this kernel and with sriov only
> Iavf id Nic driver for VF(sriovnic)
>
>
Please don't top-post; reply inline with appropriate context instead.
So you have this regression on vanilla kernel, right? If so, please
bisect (see Documentation/admin-guide/bug-bisect.rst in the kernel
sources for reference).
Thanks.
--
An old man doll... just what I always wanted! - Clara
On Tue, Nov 14, 2023 at 10:19:25PM -0800, Anil Choudhary wrote:
>
>
>
> Following error error scribing to said is also new
>
Please don't top-post; reply inline with appropriate context instead.
What error? Can you reply with logs pasted (with error you mentioned)?
Confused...
--
An old man doll... just what I always wanted! - Clara
We are getting errorError subscribing to SWID 0x0000.
from following code
root@us-ash-r1-c2-m1:~/linux# grep -rn -e "subscribing to " .
grep: ./debian/linux-image/lib/modules/6.6.1-vdx/kernel/drivers/net/ethernet/intel/ice/ice.ko: binary file matches
./samples/connector/ucon.c:149: ulog("subscribing to %u.%u\n", CN_TEST_IDX, CN_TEST_VAL);
./Documentation/driver-api/media/v4l2-event.rst:117:add called when a new listener gets added (subscribing to the same
./Documentation/driver-api/media/v4l2-event.rst:130:Unsubscribing to an event is via:
./Documentation/maintainer/feature-and-driver-maintainers.rst:44:mailing list. Either by subscribing to the whole list or using more
grep: ./drivers/net/ethernet/intel/ice/ice_lag.o: binary file matches
grep: ./drivers/net/ethernet/intel/ice/ice.o: binary file matches
grep: ./drivers/net/ethernet/intel/ice/ice.ko: binary file matches
./drivers/net/ethernet/intel/ice/ice_lag.c:1007: dev_err(ice_pf_to_dev(local_lag->pf), "Error subscribing to SWID 0x%04X\n",
root@us-ash-r1-c2-m1:~/linux#
Thanks,
Anil
> On Nov 14, 2023, at 10:19 PM, Anil Choudhary <[email protected]> wrote:
>
> <PastedGraphic-1.png>
>
>
> Following error error scribing to said is also new
>
>> On Nov 14, 2023, at 9:50 PM, Linux regression tracking (Thorsten Leemhuis) <[email protected]> wrote:
>>
>> On 15.11.23 01:54, Jay Vosburgh wrote:
>>> Bagas Sanjaya <[email protected]> wrote:
>>>
>>>> I come across LACP bonding regression on Bugzilla [1].
>>
>> Side note: Stephen forwards some (all?) network regressions to the right
>> people:
>> https://lore.kernel.org/all/[email protected]/
>>
>> Would be best to check for that, no need to forward things twice, that
>> just results in a mess.
>>
>>>> The reporter
>>>> (Cc'ed) has two regressions. The first is actual LACP bonding
>>>> regression (but terse):
>>>>
>>>>> Till linkx kernel 6.5.7 it is working fine, but after upgrading to 6.6.1 ping stop working with LACP bonding.
>>>>> When we disable SR-IOV from bios , everything working fine
>>
>> Makes me wonder if things have been working with or without the OOT
>> module on 6.5.7, as strictly speaking it's only considered a kernel
>> regression if thing worked with a vanilla kernel (e.g. without OOT
>> modules) beforehand and broke when switching to a newer vanilla kernel.
>> If that's the case it would be okay to add to regzbot.
>>
>>>> And the second is out-of-tree module FTBFS:
>>> [... skip OOT stuff ...]
>>>
>>>> Should I add the first regression to regzbot (since the second one
>>>> is obviously out-of-tree problem), or should I asked detailed regression
>>>> info to the reporter?
>>>
>>> My vote is to get additional information. Given the nature of
>>> the workaround ("When we disable SR-IOV from bios , everything working
>>> fine"), it's plausible that the underlying cause is something
>>> platform-specific.
>>
>> Maybe, but when it comes to the "no regressions" rule that likely makes
>> no difference from Linus perspective.
>>
>> But I guess unless the intel folks or someone else has an idea what
>> might be wrong here we likely need a bisection (with vanilla kernels of
>> course) to get anywhere.
>>
>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>> --
>> Everything you wanna know about Linux kernel regression tracking:
>> https://linux-regtracking.leemhuis.info/about/#tldr
>> If I did something stupid, please tell me, as explained on that page.
>
On Wed, Nov 15, 2023 at 12:48:51PM -0800, Anil Choudhary wrote:
> We are getting errorError subscribing to SWID 0x0000.
> from following code
> root@us-ash-r1-c2-m1:~/linux# grep -rn -e "subscribing to " .
> grep: ./debian/linux-image/lib/modules/6.6.1-vdx/kernel/drivers/net/ethernet/intel/ice/ice.ko: binary file matches
> ./samples/connector/ucon.c:149: ulog("subscribing to %u.%u\n", CN_TEST_IDX, CN_TEST_VAL);
> ./Documentation/driver-api/media/v4l2-event.rst:117:add called when a new listener gets added (subscribing to the same
> ./Documentation/driver-api/media/v4l2-event.rst:130:Unsubscribing to an event is via:
> ./Documentation/maintainer/feature-and-driver-maintainers.rst:44:mailing list. Either by subscribing to the whole list or using more
> grep: ./drivers/net/ethernet/intel/ice/ice_lag.o: binary file matches
> grep: ./drivers/net/ethernet/intel/ice/ice.o: binary file matches
> grep: ./drivers/net/ethernet/intel/ice/ice.ko: binary file matches
> ./drivers/net/ethernet/intel/ice/ice_lag.c:1007: dev_err(ice_pf_to_dev(local_lag->pf), "Error subscribing to SWID 0x%04X\n",
> root@us-ash-r1-c2-m1:~/linux#
>
Again, please don't top-post; reply inline with appropriate context instead.
You may need to configure your email client to start reply below the quoted
context.
OK, now on your Bugzilla ticket, please attach the full log (either from
dmesg or from journalctl). And don't forget to perform bisection if
you'd like to get this regression fixed.
Thanks.
--
An old man doll... just what I always wanted! - Clara