On Sat, Feb 13, 2021 at 10:54 AM Guenter Roeck <li...@roeck-us.net> wrote: > > Hi, > > On Thu, Jan 21, 2021 at 02:57:12PM -0800, Saravana Kannan wrote: > > This allows fw_devlink to create device links between consumers of an > > interrupt and the supplier of the interrupt. > > > > Cc: Marc Zyngier <m...@kernel.org> > > Cc: Kevin Hilman <khil...@baylibre.com> > > Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> > > Reviewed-by: Rob Herring <r...@kernel.org> > > Reviewed-by: Thierry Reding <tred...@nvidia.com> > > Reviewed-by: Linus Walleij <linus.wall...@linaro.org> > > Signed-off-by: Saravana Kannan <sarava...@google.com> > > This patch causes all ppc64:powernv qemu emulations to fail. > The problem is always the same: The root file system can not be mounted. > > Example: > > [ 14.245672][ T1] VFS: Cannot open root device "sda" or > unknown-block(0,0): error -6 > [ 14.246063][ T1] Please append a correct "root=" boot option; here are > the available partitions: > [ 14.246609][ T1] 1f00 131072 mtdblock0 > [ 14.246648][ T1] (driver?) > [ 14.247137][ T1] Kernel panic - not syncing: VFS: Unable to mount root > fs on unknown-block(0,0) > [ 14.247631][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > 5.11.0-rc7-next-20210212 #1 > [ 14.248166][ T1] Call Trace: > [ 14.248344][ T1] [c000000002c07a70] [c0000000008f052c] > dump_stack+0x100/0x174 (unreliable) > [ 14.248780][ T1] [c000000002c07ab0] [c00000000010d0e0] panic+0x190/0x450 > [ 14.249097][ T1] [c000000002c07b50] [c0000000014d1af8] > mount_block_root+0x320/0x430 > [ 14.249442][ T1] [c000000002c07c50] [c0000000014d1e64] > prepare_namespace+0x1b0/0x204 > [ 14.249798][ T1] [c000000002c07cc0] [c0000000014d1544] > kernel_init_freeable+0x3dc/0x438 > [ 14.250145][ T1] [c000000002c07da0] [c000000000012b7c] > kernel_init+0x2c/0x170 > [ 14.250466][ T1] [c000000002c07e10] [c00000000000d56c] > ret_from_kernel_thread+0x5c/0x70 > [ 28.068945385,5] OPAL: Reboot request... > > Another: > > [ 14.273398][ T1] md: Autodetecting RAID arrays. > [ 14.273665][ T1] md: autorun ... > [ 14.273860][ T1] md: ... autorun DONE. > [ 14.275078][ T1] Waiting for root device /dev/mmcblk0... > > [ waits until terminated ] > > Key difference seems to be that PCI devices are no longer instantiated > with this patch applied. Specifically, I see > > [ 1.153780][ T1] pci 0005:01 : [PE# fd] Setting up window#0 > 0..7fffffff pg=10000^M > [ 1.154475][ T1] pci 0005:01 : [PE# fd] Enabling 64-bit DMA bypass^M > [ 1.155749][ T1] pci 0005:01:00.0: Adding to iommu group 0^M > [ 1.160543][ T1] pci 0005:00:00.0: enabling device (0105 -> 0107)^M > > in both cases, but (exmple nvme) I don't see > > [ 13.520561][ T11] nvme nvme0: pci function 0005:01:00.0^M > [ 13.521747][ T45] nvme 0005:01:00.0: enabling device (0100 -> 0102)^M > > after this patch has been applied. > > Reverting th patch plus its fix resolves the problem. > > Bisect log attached.
Hi Guenter, Thanks for the report. Can you please give me the following details: * The DTS file for the board (not the SoC). * A boot log with the logs enabled in device_links_check_suppliers() and device_link_add() That should help me debug this. Rob, Looks like Guenter has this patch[1] too. What PPC specific IRQ hack am I missing? Any ideas? [1] - https://lore.kernel.org/lkml/20210209010439.3529036-1-sarava...@google.com/ Thanks, Saravana