Ticket #2364 (new defect)

Opened 4 years ago

Last modified 4 years ago

Hanging micro sdhc card

Reported by: janvlug Owned by: openmoko-kernel
Priority: highest Milestone:
Component: kernel Version:
Severity: normal Keywords:
Cc: Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible:

Description

Since I have kernel 2.6.32 in SHR, I cannot use the micro sd card reliable anymore.
When I force intensive I/O (e.g. by downloading map tiles with foxtrotgps), it hangs, although I could not catch any error on dmesg.
This issue has been reported on SHR as well, but has been marked 'upstream' over there, see:
http://trac.shr-project.org/trac/ticket/1143

Change History

comment:1 Changed 4 years ago by psonek

I am using 2.6.34 kernel for a weeks in qtmoko and i havent hit the problem yet. If you would like to experiment, you can download qtmoko here [1] and use it's kernel+modules with SHR. Kernel is in /boot after extracting and modules are in /lib/modules. You might need to fix sysfs path that powers on modem, because it has changed since 2.6.32.

find /sys | grep power_on

will tell you the right path.

SHR uses KMS for glamo, so it will help to identify if the problem is there.

[1] http://sourceforge.net/projects/qtmoko/files/Experimental/qtmoko-debian-v27.tar.gz/download

comment:2 Changed 4 years ago by gena2x

just for record:

I am using .34 from http://git.openmoko.org/?p=kernel.git;a=shortlog;h=refs/heads/om-gta02-2.6.34 since june or july i think, and never had such problem. Also AFAIR i were using .32 (without kms) for a while, and had nothing like this.

But as soon as i compiled shr's .32, i immediately hit something like this - i have to fsck.xfs after each(proper) power down.

comment:3 Changed 4 years ago by Fox Mulder

gena2x which .32 kernel without kms did you use with shr-u that worked without sd problems?
I really would like to try it because at the moment, without reliably working sd-card access, my freerunner is only a brick.

comment:4 Changed 4 years ago by gena2x

Sorry, i am not using SHR. I compiled .32 loong ago (in beginning of summer), now I'm on .34 for experiments in my debian, but i doubt it will work out of box due to other issues (but i can just share this with you if you want to check for this particular issue). For normal usage, i am using .29 from qtmoko v26.

If it's not a problem for you, you can compile kernel yourself.

http://git.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-openmoko-2.6.32 <- this is location of shr's kernel and all patches. get kernel, apply patches and build it. only 'special' thing you need is to use non-kms config (./arch/arm/configs/gta02_defconfig) and do not apply kms-patches: 0007-DRM-for-platform-devices.patch, 0008-Glamo-DRM-and-KMS-driver.patch, 0009-Work-on-Glamo-core-for-DRM.patch (i think). To do fast check if this is really kms-related, you may build kernel without all patches on that page, probably it will work more or less, and check for this particular issue.

comment:5 Changed 4 years ago by jama

Seems like using non-kms config (./arch/arm/configs/gta02_defconfig) is enough or even not using DRM kernel glamo driver (by using xf86-video-fbdev instead of glamo).

Note: See TracTickets for help on using tickets.