Hello, guys,
While a debugging of an issue with I2C communication on my board sent by mistake a read of 0 bytes:
root@verdin-imx8mp-15315030:~# i2ctransfer -y 3 r0@0x56
The result was Kernel panic due to fatal exception in I2C interrupt handler.
Full log is attached.
read_zero_bytes_kernel_panic_log.txt (4.3 KB)
Verdin iMX8MP QL 1GB
Custom Yocto build 6.6.101-devel
BSP 7.5.0
Custom carrier board
With kind regards,
Ivan
Hi, I’m the Toradex AI Assistant.
I might make mistakes or occasionally get you wrong. Our support team will step in if needed.
Thank you for reporting this I2C issue with the Verdin iMX8M Plus. Based on your description, you encountered a kernel panic when attempting to read 0 bytes from an I2C device using the i2ctransfer command.
The I2C Tools package is included in the Reference Multimedia Image and provides command-line utilities for interacting with I2C devices (1). For Verdin modules, I2C buses are accessed via device nodes that follow the module family naming convention (1).
According to the Verdin iMX8M Plus datasheet, your module features multiple I2C interfaces (2). The standard Verdin I2C interface I2C_1 is available on pins 12/14 (SODIMM_12/14) and maps to I2C4 on the i.MX 8M Plus SoC (2). Additional I2C interfaces are available for DSI, HDMI, and CSI applications (2).
To identify your I2C buses, you can use (1):
# ls -l /dev/verdin-i2c*
Verify I2C Bus Mapping: Use i2cdetect -l to confirm the controller addresses and ensure you’re using the correct bus number (1).
Check Device Presence: Before attempting data transfers, detect devices on the bus using (1):
# i2cdetect -y -r 3
Use Standard I2C Commands: The documentation recommends using i2cget, i2cset, and i2cdump for basic I2C operations rather than i2ctransfer (1).
Consider using Torizon OS for I2C communication, as it’s preferred for controlling I2C buses due to its ease of use and smoother application development experience (1). The documentation specifically mentions that Torizon OS provides better I2C handling compared to custom Yocto builds.
Since you’re using a custom Yocto build with BSP 7.5.0, you might want to review your kernel configuration and consider updating to ensure all I2C-related patches are included.
Best regards, Toradex AI Assistant.
Did you like my answer? 
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
Hi @Ivan_Gorchev!
I could reproduce your issue, and, after looking into the source code of the i2ctransfer command, it seems to be a possible behavior. The command sends an empty message to the device, which is then handled by the corresponding device driver. Some drivers do not have a mechanism to protect the kernel against an empty message, which can result in a kernel panic.
For example, with the BSP reference minimal image, the behavior of the i2ctransfer command depends on the driver that receives the message:
root@verdin-imx8mp-15604798:~# i2ctransfer -y 6 r0@0x30
Error: Sending messages failed: Operation not supported
root@verdin-imx8mp-15604798:~# i2ctransfer -y 3 r0@0x51
[ 4704.697796] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
[ 4704.706613] Mem abort info:
[ 4704.709410] ESR = 0x0000000096000045
[ 4704.713165] EC = 0x25: DABT (current EL), IL = 32 bits
[ 4704.718485] SET = 0, FnV = 0
[ 4704.721545] EA = 0, S1PTW = 0
[ 4704.724689] FSC = 0x05: level 1 translation fault
[ 4704.729576] Data abort info:
[ 4704.732459] ISV = 0, ISS = 0x00000045, ISS2 = 0x00000000
[ 4704.737949] CM = 0, WnR = 1, TnD = 0, TagAccess = 0
[ 4704.743010] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 4704.748331] user pgtable: 4k pages, 39-bit VAs, pgdp=000000010314b000
[ 4704.754781] [0000000000000010] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
[ 4704.763505] Internal error: Oops: 0000000096000045 [#1] PREEMPT SMP
[ 4704.769782] Modules linked in: 8021q garp stp mrp llc onboard_usb_hub rfcomm caam_jr caamkeyblob_desc caamhash_desc usb_conn_gpio caamalg_desc snd_soc_hdmi_codec crypto_engine rng_core nls_iso8859_1 authenc bnep nls_cp437 dwc3 dw_hdmi_cec dw_hdmi_gp_audio roles spidev libdes crypto_null evdev aes_ce_cipher mwifiex_sdio ghash_ce gf128mul mwifiex sha2_ce fsl_imx8_ddr_perf sha256_arm64 snd_soc_imx_hdmi snd_soc_fsl_sai snd_soc_simple_card phy_fsl_imx8m_pcie sha1_ce snd_soc_simple_card_utils sha1_generic snd_soc_fsl_utils imx_pcm_dma hci_uart dwc3_imx8mp cfg80211 phy_fsl_samsung_hdmi bluetooth phy_fsl_imx8mq_usb irq_imx_irqsteer ecdh_generic ecc rfkill typec snd_soc_fsl_aud2htx ti_ads1015 industrialio_triggered_buffer sec_mipi_dsim_imx sec_dsim imx_sdma imx_bus spi_nxp_fspi libaes kfifo_buf snd_soc_nau8822 lm75 ina2xx lontium_lt8912b caam flexcan error pwm_imx27 can_dev snvs_pwrkey nvmem_snvs_lpgpr imx8mm_thermal spi_imx gpio_keys display_connector fuse ipv6 autofs4
[ 4704.799967] i2c i2c-3: <i2c_imx_read> read timedout
[ 4704.855297] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.6.119-7.5.0-devel #1
[ 4704.855304] Hardware name: Toradex Verdin iMX8M Plus WB on Verdin Development Board (DT)
[ 4704.855308] pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 4704.855315] pc : i2c_imx_isr+0x3d4/0x754
[ 4704.855327] lr : i2c_imx_isr+0xd0/0x754
[ 4704.890149] sp : ffffffc080003ef0
[ 4704.893475] x29: ffffffc080003ef0 x28: ffffffe9e1631080 x27: 0000000000000000
[ 4704.900638] x26: 00000000ffb2ebf0 x25: 0000044765d6bedc x24: 0000000000000000
[ 4704.907792] x23: ffffff80c0e05e00 x22: 00000000000000a2 x21: 00000000000000c0
[ 4704.914946] x20: ffffff80c0bc7dec x19: ffffff80c0bc7880 x18: 0000000000000000
[ 4704.922104] x17: ffffff971e30d000 x16: ffffffc080000000 x15: 00000001306fe0a0
[ 4704.929260] x14: 0000000000000000 x13: 0000000000000003 x12: 0000000000000000
[ 4704.936414] x11: 0000000000000040 x10: ffffff80c00290a8 x9 : ffffff80c00290a0
[ 4704.943569] x8 : ffffff80c0400700 x7 : 0000000000000000 x6 : 0000000000000000
[ 4704.950724] x5 : 00000000ffffffff x4 : 0000000000000002 x3 : 0000000000000010
[ 4704.957878] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
[ 4704.965032] Call trace:
[ 4704.967488] i2c_imx_isr+0x3d4/0x754
[ 4704.971076] __handle_irq_event_percpu+0x48/0x13c
[ 4704.975793] handle_irq_event+0x4c/0xa8
[ 4704.979638] handle_fasteoi_irq+0xa4/0x230
[ 4704.983744] handle_irq_desc+0x40/0x58
[ 4704.987505] generic_handle_domain_irq+0x1c/0x28
[ 4704.992138] gic_handle_irq+0x50/0x128
[ 4704.995898] call_on_irq_stack+0x30/0x64
[ 4704.999836] do_interrupt_handler+0x80/0x8c
[ 4705.004031] el1_interrupt+0x34/0x68
[ 4705.007618] el1h_64_irq_handler+0x18/0x24
[ 4705.011725] el1h_64_irq+0x64/0x68
[ 4705.015141] cpuidle_enter_state+0x134/0x2e0
[ 4705.019420] cpuidle_enter+0x38/0x50
[ 4705.023007] do_idle+0x1f4/0x264
[ 4705.026242] cpu_startup_entry+0x34/0x3c
[ 4705.030173] kernel_init+0x0/0x1dc
[ 4705.033588] arch_post_acpi_subsys_init+0x0/0x8
[ 4705.038128] start_kernel+0x4f0/0x5f8
[ 4705.041803] __primary_switched+0xbc/0xc4
[ 4705.045830] Code: 92401c02 d5033dbf ca020042 b5000002 (38214860)
[ 4705.051938] ---[ end trace 0000000000000000 ]---
[ 4705.056564] Kernel panic - not syncing: Oops: Fatal exception in interrupt
[ 4705.063451] SMP: stopping secondary CPUs
[ 4705.067384] Kernel Offset: 0x2960400000 from 0xffffffc080000000
[ 4705.073312] PHYS_OFFSET: 0x40000000
[ 4705.076806] CPU features: 0x0,00000001,00020000,1000420b
[ 4705.082132] Memory Limit: none
[ 4705.085195] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---
As shown in the logs above, for the device at address 0x31 on bus 6, attempting to read 0 bytes is rejected by the driver and results in an Operation not supported. However, for the device at address 0x51 on bus 3, the driver does not handle the request to read 0 bytes, which leads to a kernel panic.
Best regards.