Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jolivain opened this issue Nov 6, 2021 · 3 comments

Comments

@jolivain
Copy link

jolivain commented Nov 6, 2021

How to reproduce:

Environment:

Board imx8mm pico pi: https://www.technexion.com/products/system-on-modules/evk/pico-pi-imx8m-mini/

Starting from Yocto BSP:

repo init -u https://github.com/TechNexion/tn-imx-yocto-manifest.git -b zeus_5.4.y-stable -m imx-5.4.70-2.3.0_2021Q4.xml

tx-imx-yocto-manigest is on commit 86721af835feb1e3ad9ed843c8708c128409acf8, at the time of this writing.
Kernel tag: tn-zeus_5.4.70-2.3.0_20211018

Step 1: run the system without wlan.ko:

Option 1: Add "init=/bin/sh" in Kernel boot args

Option 2: On a normally started system, login as root, then unload wlan.ko with commands:

systemctl stop connman
modprobe -r wlan

Actual result

system hang after few seconds.
The hang can be avoided the first time, by running "modprobe wlan" before the hang.
Note: further unloading/reloading wlan.ko seems to crash for other reasons.

Expected result

system should be usable even if the wlan.ko module is not loaded.
Ideally, wlan.ko unloading/reloading should work too.

@richard-hu
Copy link
Contributor

richard-hu commented Nov 9, 2021

@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

imx8mm-pico-pi_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
Copy link
Author

jolivain commented Nov 9, 2021

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants