Subject: Re: [BUG] net, pci: 6.3-rc1-4 hangs during boot on PowerEdge R620 with igb

From: Andy Shevchenko <[email-masked]>
Date: Wed, 12 Apr 2023 16:20:33 +0300

On Tue, Apr 11, 2023 at 02:02:03PM -0500, Rob Herring wrote:
> On Tue, Apr 11, 2023 at 7:53 AM Donald Hunter <[email-masked]> wrote:
> > Bjorn Helgaas <[email-masked]> writes:
> > > On Mon, Apr 10, 2023 at 04:10:54PM +0100, Donald Hunter wrote:
> > >> On Sun, 2 Apr 2023 at 23:55, Bjorn Helgaas <[email-masked]> wrote:
> > >> > On Sat, Apr 01, 2023 at 01:52:25PM +0100, Donald Hunter wrote:
> > >> > > On Fri, 31 Mar 2023 at 20:42, Bjorn Helgaas <[email-masked]> wrote:
> > >> > > >
> > >> > > > I assume this igb NIC (07:00.0) must be built-in (not a plug-in card)
> > >> > > > because it apparently has an ACPI firmware node, and there's something
> > >> > > > we don't expect about its status?
> > >> > >
> > >> > > Yes they are built-in, to my knowledge.
> > >> > >
> > >> > > > Hopefully Rob will look at this.  If I were looking, I would be
> > >> > > > interested in acpidump to see what's in the DSDT.
> > >> > >
> > >> > > I can get an acpidump. Is there a preferred way to share the files, or just
> > >> > > an email attachment?
> > >> >
> > >> > I think by default acpidump produces ASCII that can be directly
> > >> > included in email.  http://vger.kernel.org/majordomo-info.html says
> > >> > 100K is the limit for vger mailing lists.  Or you could open a report
> > >> > at https://bugzilla.kernel.org and attach it there, maybe along with a
> > >> > complete dmesg log and "sudo lspci -vv" output.
> > >>
> > >> Apologies for the delay, I was unable to access the machine while travelling.
> > >>
> > >> https://bugzilla.kernel.org/show_bug.cgi?id=217317
> > >
> > > Thanks for that!  Can you boot a kernel with 6fffbc7ae137 reverted
> > > with this in the kernel parameters:
> > >
> > >   dyndbg="file drivers/acpi/* +p"
> > >
> > > and collect the entire dmesg log?
> >
> > Added to the bugzilla report.
> 
> Rafael, Andy, Any ideas why fwnode_device_is_available() would return
> false for a built-in PCI device with a ACPI device entry? The only
> thing I see in the log is it looks like the parent PCI bridge/bus
> doesn't have ACPI device entry (based on "[    0.913389] pci_bus
> 0000:07: No ACPI support"). For DT, if the parent doesn't have a node,
> then the child can't. Not sure on ACPI.

Thanks for the Cc'ing. I haven't checked anything yet, but from the above it
sounds like a BIOS issue. If PCI has no ACPI companion tree, then why the heck
one of the devices has the entry? I'm not even sure this is allowed by ACPI
specification, but as I said, I just solely used the above mail.

-- 
With Best Regards,
Andy Shevchenko