Kernel panic occurs when USB flash drive is plugged during boot

Technical Support
, , , ,
1

Good day!

[Problem]
Kernel panic occurs intermittently when a USB flash drive is plugged into the device during boot.

I am currently checking the possible causes of kernel panic and it seems it is caused by the usb0 network interface loaded via g_ether/rndis driver.

I cannot disable g_ether/rndis on kernel since it is used on TEZI.
(I tried disabling it but I was not able to use TEZI afterwards)

I tried adding “initcall_blacklist=g_ether” on boot parameters to disable/blacklist the driver but usb0 network interface is still created.

Can anyone let me know about below items:

  • Other possible causes of kernel panic
  • Other ways to disable g_ether/rndis without affecting TEZI

[HW/SW Configuration]

  • Colibri iMX6ULL 512MB RAM V1.1A
  • Custom Board (Colibri Evaluation Board-based)
  • Kernel: 6.1.22-6.2.0-devel+git.3b29299e5f60
  • Distro: 6.2.0-devel-20241216092236-build.0
  • Yocto: kirkstone

Regards,
Elton

2

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Hello!

Thank you for reaching out with your question. Based on the Colibri iMX6ULL documentation, here are some key points regarding USB configuration:

  1. The module features two USB 2.0 High-Speed (480 Mbit/s) ports. While both ports are technically identical, it is recommended to use the USBC port as a dual-use interface, while the USBH port should be used as host-only for compatibility with other Colibri modules.

  2. The USBC controller is also utilized for serial loader mode (recovery mode).

  3. For USB host functionality, ensure that your carrier board generates the 5V USB supply voltage. The Colibri iMX6ULL provides optional signals for USB power supply control.

Regarding your specific question about g_ether/rndis and its impact on the Toradex Easy Installer (TEZI), you can disable the g_ether module by blacklisting it in the kernel configuration or by modifying the device tree to prevent it from loading. This should not affect TEZI, as it primarily relies on other interfaces for its operation.

I hope this information helps you resolve the kernel panic issue. If you have further questions, feel free to ask!

Best regards,
Toradex AI Assistant.

3

Hi @elton.reformado , could very well be a kernel bug.

However I don’t fully understand your use case or how it affects TEZI. TEZI should only be used to install your image when you receive your module. Then you flash your image and TEZI is overwritten.

How are you using TEZI / why is it important to you to keep this functionality for TEZI?

4

Hello @alvaro.tx ,

could very well be a kernel bug.

However I don’t fully understand your use case or how it affects TEZI. TEZI should only be used to install your image when you receive your module. Then you flash your image and TEZI is overwritten.

How are you using TEZI / why is it important to you to keep this functionality for TEZI?

I don’t fully understand how TEZI works but we are using it to (re-)flash our custom board by running “run bootcmd_usb0” on Uboot. This will “run/load” binaries from the USB stick.
I noticed that TEZI uses RNDIS, so if RNDIS-disabled kernel zImage is loaded on the USB stick, it will affect TEZI operation.

Anyways, I was able to prevent the creation of “usb0” network interface by disabling “usbg.service” systemd service.

Currently, I am testing a device with “usbg.service” disabled for 25 to 50 iterations.
So far, there has been no kernel panic in the first 5 iterations.
In contrast, with “usbg.service” enabled, kernel panic typically occurs on the 2nd or 3rd iteration.

I am still investigating the root cause and will share my findings once I have more information

Regards,
Elton

5

I see. TEZI is not an update tool but a flashing and recovery tool so this is a bit of an edge case. Technically is thought to be launched from USB DRP as recovery:

Also any reason why you are using 6.2.0? This was a quarterly release that is currently at 6.8.x. Any bugs in 6.2.0 were fixed in 6.3.0 and newer versions so there is a chance this issue doesn’t happen in newer versions.

Looking forward to it.