[Bug 213079] [bisected] IRQ problems and crashes on a PowerMac G5 with 5.12.3

[bugzilla-daemon@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=213079

--- Comment #4 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 297191
  --> https://bugzilla.kernel.org/attachment.cgi?id=297191&action=edit
bisect.log

Turns out the problem was introduced between v5.11 and v5.12 by following
commit:

 # git bisect good
fbbefb320214db14c3e740fce98e2c95c9d0669b is the first bad commit
commit fbbefb320214db14c3e740fce98e2c95c9d0669b
Author: Oliver O'Halloran <oohall@gmail.com>
Date:   Tue Nov 3 15:35:07 2020 +1100

    powerpc/pci: Move PHB discovery for PCI_DN using platforms

    Make powernv, pseries, powermac and maple use ppc_mc.discover_phbs.
    These platforms need to be done together because they all depend on
    pci_dn's being created from the DT. The pci_dn contains a pointer to
    the relevant pci_controller so they need to be created after the
    pci_controller structures are available, but before PCI devices are
    scanned. Currently this ordering is provided by initcalls and the
    sequence is:

      1. PHBs are discovered (setup_arch) (early boot, pre-initcalls)
      2. pci_dn are created from the unflattended DT (core initcall)
      3. PHBs are scanned pcibios_init() (subsys initcall)

    The new ppc_md.discover_phbs() function is also a core_initcall so we
    can't guarantee ordering between the creation of pci_controllers and
    the creation of pci_dn's which require a pci_controller. We could use
    the postcore, or core_sync initcall levels, but it's cleaner to just
    move the pci_dn setup into the per-PHB inits which occur inside of
    .discover_phb() for these platforms. This brings the boot-time path in
    line with the PHB hotplug path that is used for pseries DLPAR
    operations too.

    Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
    [mpe: Squash powermac & maple in to avoid breakage those platforms,
          convert memblock allocs to use kmalloc to avoid warnings]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20201103043523.916109-2-oohall@gmail.com

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.