On Wed Apr 3, 2024 at 7:22 PM IST, Sebastian Reichel wrote:

Hi,

On Wed, Apr 03, 2024 at 01:03:07AM +0000, Pratham Patel wrote:

...

...

...

...

Also, can you give the output of <debugfs>/devices_deferred for the good vs bad case?

I can't provide you with requested output from the bad case, since the kernel never moves past this to an initramfs rescue shell, but following is the output from v6.8.1 (**with aforementioned patch reverted**).

# cat /sys/kernel/debug/devices_deferred fc400000.usb platform: wait for supplier /phy@fed90000/usb3-port 1-0022 typec_fusb302: cannot register tcpm port fc000000.usb platform: wait for supplier /phy@fed80000/usb3-port

It seems that v6.8.2 works _without needing to revert the patch_. I will have to look into this sometime this week but it seems like a8037ceb8964 (arm64: dts: rockchip: drop rockchip,trcm-sync-tx-only from rk3588 i2s) seems to be the one that fixed the root issue. I will have to test it sometime later this week.

Ok, once you find the patch that fixes things, let me know too.

Will do!

FWIW the v6.8.1 kernel referenced above is definitely patched, since upstream's Rock 5B DT does neither describe fusb302, nor the USB port it is connected to.

We have a few Rock 5B in Kernel CI and upstream boots perfectly fine:

https://lava.collabora.dev/scheduler/device_type/rk3588-rock-5b

Hmm, weird then. I can confirm that v6.8.1 doesn't _always_ boot. It boots some times but still fails a majority of times. There is a 2 out of 10 chance that v6.8.1 will not boot. If you keep rebooting enough times, you might get it to boot but the next boot is likely to be borked. :(

That said, v6.8.2 might still have the same issue, but the probably of a failed boot might be _lesser_ than v6.8.1 (from what I saw). I will verify that behaviour sometime tomorrow or day after tomorrow.

So it could be one of your downstream patches, which is introducing this problem.

I thought so too. So I built a vanilla kernel from the release tarball of v6.8.1, using GCC + arm64 defconfig. I also tried using LLVM just in case but noticed the same result.

-- Pratham Patel