kernel crashes when transferring big files via g_mass_storage on i.MX6 module

[markusbraitner]

Hello to all,

I got the following problem:

I use the mass storage gadget driver on an i.MX6s module running Linux. Transferring text files <10MB don't cause any problems, but trying to transmit text files >100MB, the kernel on the i.MX6 system crashes after transmitting approx. 50MB.

- Kernel version I use: 3.10.17 (custom one from module vendor)

- I compiled the driver as kernel module, loading it with

"modprobe g_mass_storage file="/dev/mmcblk1p3" removable=y stall=0"

- The Mass storage Gadget has version 2009/09/11

- I attached my kernel config as "defconfig-mine"

- usually I don't get any error messages from the kernel on the module (terminal communication simply freezes), but once I was able to capture a (ripped) "oops" message, which I attached as "20160210_Kernel_crash_g_mass_storage.txt"

Has anybody an idea?

Markus

Original Attachment has been moved to: 20160210_Kernel_crash_g_mass_storage.txt.zip

Original Attachment has been moved to: defconfig-mine.zip

[markusbraitner · Accepted solution]

Last week, in discussion with our module vendor, it turned out that the whole thing had NOT been a Hardware Problem, but rather a Problem with the wrong bootloader configuration...

I somehow took the bootloader configuration for another module, which configured the RAM to be of 1GB (in fact having only 512MB)... Using the correct bootloader config everything worked fine now even on the same Hardware...

Just in case somebody else can also learn from my mistakes... :-)

Markus

[markusbraitner]

It now turned out to be a HW problem - simply exchanging the COM module solved the case...

However, the Memory test of the COM manufacturer and i.MX6/7 DDR Stress Test Tool V2.51 didn't show any errors at about RAM working frequency, so I still don't know what exactly had been the problem.

Thanks to all for your help!

Markus

[markusbraitner]

I just remember, I also experienced two times the case that data was even written to the framebuffer (resulting in "funny" colorful patterns on the display of the embedded system) before (?) the kernel crashed.

[igorpadykov]

Hi Markus

one can check memory on board (then update uboot *.cfg file)

i.MX6/7 DDR Stress Test Tool V2.40

also one can check board power supplies (ripples, spikes) as at large

data transfers current may significantly increase.

It makes sense to migrate to newer kernels as 3.10.17 is quite old.

Best regards

igor

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------

[markusbraitner]

Hello Igor,

thanks for your inputs!

1) Did a DDR memory check with a module vendor tool, showing no problems with the memory

2) I checked the board supply when transferring the files, but didn't see any spikes.

3) We're using a version of the freescale kernel being adapted by the board vendor. Unfortunately, the board vendor has not yet updated the kernel to a newer version...

Your hint with the memory brought me to something else that I could check - The data exposed by the mass storage gadget lies on a SD card, so I will check whether this card is corrupted.

Markus

[markusbraitner]

Hm, just checked the problem with some other sd card and it still remains...

Now I got the following error message when the kernel crashed:

------------------

Unable to handle kernel NULL pointer dereference at virtual address 00000378

pgd = 80004000

[00000378] *pgd=00000000

------------------

Any more ideas what I could check?

Markus

[markusbraitner]

This time I got another error message when the kernel crashed:

"Bad IRQ2160806148"

Could this maybe be a problem with some other driver that is being used by the gadget driver?

Markus