Writing to the sdcard hangs suddently #2500
Comments
|
This is very interesting. I am having similar issues here with one of my projects where also on heavy write operations to the SD card (mmc device) operations suddenly stop with the kernel returning "hung process" warnings after 120s. I am also able to perform a remote login to the system and every process not read/writing to the sd card returns immediately. but as soon as I try to read from the sd card the process in question hangs. Compared to your setup I am using the latest 4.14.33 kernel. After some investigation I could slightly improve the probability that the sd card hang occurs by adding I will try to grab some more debug information on that matter and post it here accordingly. But if a raspberrypi developer could already give some hints in how or where to investigate that issue, this would be great. |
|
Could you post your kernel configs? I've had this happen too, with the exact same symptoms (everything that needs sdcard IO just hangs), sometimes without the kernel hung task detector complaining. I can't imagine it happens under Raspbian, so maybe there is some common variable in our configs that might be causing it. |
|
That's the kernel defconfig file my project is using and which exhibits the issue (especially if |
|
@stschake in fact I was never able to reproduce in Raspbian. |
|
As you are using the NOOBS provided kernel which actually is also created by buildroot like my environment/kernel I also suspect that this might be somewhat related to some kernel option or toolchain build related things causing that raspberrypi kernels compiled within buildroot might exhibit the problem. Perhaps indeed comparing kernel defconfigs between Raspbian and buildroot/NOOBS and also perhaps toolchain related differences might help in trying to pin down the potential issue. However, would also be great if some raspberrypi developer could comment on that issue and give some hints in how to debug this situation. |
|
@jens-maus Which kernel are you building? sdhci_bcm2708 hasn't existed for very long time now (the 3.9 kernel, from what I can tell). The sdhost driver interacts with the firmware to manage the clock divisor, but only when the MMC framework is expecting the clock to change, i.e. when the card is being probed and brought up to speed. Apart from that the only dependency should be on the DMA driver/hardware and on the SD hardware itself. You may learn something by enabling the driver's logging feature which will record activity the kernel message log. Add |
|
I change root to f2fs for fix this problem (not fix, but minimaze) |
|
@jens-maus Did you have a chance to try out @pelwell suggestions above? |
JamesH65
added
the
Waiting for external input
|
This issue will be closed within 30 days unless further interactions are posted. If you wish this issue to remain open, please add a comment. A closed issue may be reopened if requested. |
JamesH65
added
the
Close within 30 days
|
I tested with the dtparam=sd_debug=on and I was able to reproduce the issue a couple of times. No error appeared in dmesg. Logs indicated that data was being written and then gradually stopped. The rest of the behavior is as described in the first post. I'm now using the watchdog to handle this issue, I couldn't find another way. |
JamesH65
removed
the
Close within 30 days
Hello! I'm using a modified version of noobs for a project and I noticed that sometimes the process that writes to the sdcard hangs indefinitely. This happens an multiple sdcards and multiple devices. The process is a wget | gz | bsdtar. When it hangs, I can log in via ssh and whatever I try to run on the sdcard hangs. I added strace to the image and I get this:
This is the status:
I can see no interrupt for mmc0 in /proc/interrupts. It seems someone else reproduced a similar behaviour in my report here raspberrypi/noobs#487. This is all I have from dmesg:
Rebooting fixes the problem and everything is back to normal. I have never reproduced anything similar in raspbian. Any advice on what I could do to debug further? Thanks!
The text was updated successfully, but these errors were encountered: