Linux Kernel freeze on imx8mm-pico-pi if ath/qcom wlan.ko module is not loaded at boot or unloaded at runtime. about linux-tn-imx

[richard-hu]

@jolivain :

Thanks for your feedback.

We did see error log after rmmod then attempting modprobe wlan module driver.
But we don't see system hanging after rmmod wlan module driver.

Test steps:

1. Boot into the Yocto 3.0 image below (based on imx-5.4.70-2.3.0_2021Q4.xml).
   https://download.technexion.com/.to_customer/pico-imx8mm_pi_yocto-3.0_xwayland_qca_20211018151521.zip
2. rmmod wlan driver.
3. modprobe wlan

In arch/arm64/boot/dts/freescale/imx8mm-pico.dtsi, under kernel source code:
WIFI SDIO is configured as non-removable devices.

/* WIFI SDIO */
&usdhc1 {
	pinctrl-names = "default", "state_100mhz", "state_200mhz";
	pinctrl-0 = <&pinctrl_usdhc1>;
	pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
	pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
	bus-width = <4>;
	no-1-8-v;
	vmmc-supply = <&wl_reg_on>;
	pm-ignore-notify;
	keep-power-in-suspend;
	non-removable;
	status = "okay";
};

I guess It would need to trigger mmc driver to rescan bus once the driver is reloaded.

BR,

Richard

[jolivain]

Hi Richard,

Thank you for testing.

On my end, I see the same as you: doing "rmmod wlan" alone on a started Yocto system does not freeze the system.

To crash the system, I also need to stop connman before unloading wlan, with the two commands:

systemctl stop connman
rmmod wlan

The same crash is reproduced when systemd is not started at all. To do so, interrupt the U-Boot autoboot by hitting a key, add "init=/bin/sh" in mmc boot args, then boot:

setenv mmcargs ${mmcargs} init=/bin/sh
boot

The bash prompt will show, and the system freezes about 5 seconds later.

For information, I use a bare imx8mm-pico-pi board, with only USB-C power and USB uart connected. (No display, no hat, etc.)

Best regards,

Julien.

[jolivain]

Hi Richard,

Some more info:

With the xwayland image you provided (imx-image-full-pico-imx8mm-20211018151521), I cannot always reproduce the issue with the "rmmod wlan": it seems some other user space processes are hiding the issue (most likely connman, hciattach). When writing my initial report, I was using a core-image-minimal Yocto image from imx-5.4.70-2.3.0_2021Q4.

Adding "init=/bin/sh" to kernel boot args always trigger the issue on your image. It seems the most reliable way to trigger the issue.

Note: I'm also able to reproduce the same issue with components from the branch tn-imx_5.10.52_2.1.0-next:
Kernel on commit 486b33f
U-Boot on commit e57a84b6944d55e7748ef6d09afbf4f3b4a131f7

Thanks,

Julien.