netdev - Re: Oops in during sriov_enable with ixgbe driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b9e461a5-75de-6f45-1709-d9573492f7ac@intel.com>
Date:   Thu, 30 Sep 2021 19:38:37 +0200
From:   "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
To:     Jesse Brandeburg <jesse.brandeburg@...el.com>,
        Niklas Schnelle <schnelle@...ux.ibm.com>,
        Tony Nguyen <anthony.l.nguyen@...el.com>
CC:     <linux-acpi@...r.kernel.org>, <netdev@...r.kernel.org>,
        "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>
Subject: Re: Oops in during sriov_enable with ixgbe driver

On 9/30/2021 7:31 PM, Jesse Brandeburg wrote:
> On 9/28/2021 4:56 AM, Niklas Schnelle wrote:
>> Hi Jesse, Hi Tony,
>>
>> Since v5.15-rc1 I've been having problems with enabling SR-IOV VFs on
>> my private workstation with an Intel 82599 NIC with the ixgbe driver. I
>> haven't had time to bisect or look closer but since it still happens on
>> v5.15-rc3 I wanted to at least check if you're aware of the problem as
>> I couldn't find anything on the web.
> We haven't heard anything of this problem.
>
>
>> I get below Oops when trying "echo 2 > /sys/bus/pci/.../sriov_numvfs"
>> and suspect that the earlier ACPI messages could have something to do
>> with that, absolutely not an ACPI expert though. If there is a need I
>> could do a bisect.
> Hi Niklas, thanks for the report, I added the Intel Driver's list for
> more exposure.
>
> I asked the developers working on that driver to take a look and they
> tried to reproduce, and were unable to do so. This might be related to
> your platform, which strongly suggests that the ACPI stuff may be related.
>
> We have tried to reproduce but everything works fine no call trace in
> scenario with creating VF.
>
> This is good in that it doesn't seem to be a general failure, you may
> want to file a kernel bugzilla (bugzilla.kernel.org) to track the issue,
> and I hope that @Rafael might have some insight.
>
> This issue may be related to changes in acpi_pci_find_companion,
> but as I say, we are not able to reproduce this.
>
> commit 59dc33252ee777e02332774fbdf3381b1d5d5f5d
> Author: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> Date:   Tue Aug 24 16:43:55 2021 +0200
>      PCI: VMD: ACPI: Make ACPI companion lookup work for VMD bus

This change doesn't affect any devices beyond the ones on the VMD bus.


> At this point maybe a bisect would be helpful, since this seems to be a
> corner case that we used to handle but no longer do.
>
> Thanks!
> Jesse