On Sat, Feb 13, 2021 at 10:54 AM Guenter Roeck [off-list ref] wrote:

Hi,

On Thu, Jan 21, 2021 at 02:57:12PM -0800, Saravana Kannan wrote:

quoted

This allows fw_devlink to create device links between consumers of an
interrupt and the supplier of the interrupt.

Cc: Marc Zyngier <maz@kernel.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Thierry Reding <redacted>
Reviewed-by: Linus Walleij <redacted>
Signed-off-by: Saravana Kannan <redacted>

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-saravanak@google.com/ (local)

Thanks,
Saravana