SDcard IO Error and FS corruption when receiving call (unstable image)

[gbe]

I just tried playing around with the latest unstable image and I experienced quite an odd bug. I installed it onto an 8 GB Transcend uSD card, from which it booted without problems. Sending and receiving SMS is also no problem. If I however call the phone from my home phone, the screen gets garbled and the vibration doesn't turn off even if I hang up on my home phone. I had an SSH session running when I first experienced it and I could get the results of a dmesg which showed pretty severe issues with the SDcard (the output is attached). Thinking it was just a glitch from a broken rootfs, i redownloaded the tarball and reinstalled. On this new rootfs I was abled to reproduce that issue also. In case it matters, on the second try I had tangoGPS running, though I don't remember whether that was running on the first try.

[gbe]

I just reinstalled the unstable rootfs, but replaced the kernel (2.6.29-r3) by the one from the stable release (2.6.29-r2). So far, receiving calls works, but I'll keep an eye open on it.

[gbe]

Okay, I tried receiving a call with tangoGPS running in the background and it trashed the FS again. This seems to be related to fso-gpsd running, though I'm not sure how that could be related

[gbe]

I went back to the testing rootfs + kernel, thinking the problem would've been solved then. For a few days everything worked fine, though today I tried to see what happens if I have the touchscreen locked (via simple_lock) while receiving a call. The phone started to vibrate and the ringtone played, but then the screen got garbled again. I had nothing running in the background, except for simple_lock. Am I the only one with this issue?

[spaetz]

Seems like it, I haven't heard of this one before...
BTW, testing is currently not changing a lot...

[gbe]

I think I found a solution to the problem. It looks like the GSM modem is interfering with the data lanes on the SD card interface. After asking in #openmoko-cdevel, I was suggested trying the kernel option glamo_mci.sd_drive, which, if set to 2 seems to solve the problem. I've been running the system like that for a few days now and there has been no crash since. Someone mentioned the GPS TTFF might go up a lot, but I couldn't experience that. GPS works just as well as before, so I'd suggest closing this bug report and maybe adding a note to some FAQ for users with the same problem.

[vnevoa]

Replying to spaetz:
Thanks a lot, gbe. I've been having the same problem continuously with most of the testing images (garbled screen and hanging system), and I didn't even notice it coincided with gps usage (I thought it was GPRS triggered). But it makes sense, now that you say it.
Will test the workaround and give feedback soon.

[vnevoa]

I've had to crank it up to level 4 to get a stable system. Below that I still get freezes and FS access failures.
I tested with:

• GTA02v5 with buzzfix and GPS cap fix;
• kernel kernel-image-2.6.29-rc3 - 2.6.29-oe10+gitr119826+dcd90798cdab0ab1e7c1fb56af8841bb225b5fdc-r3.5
• bootloader qi-s3c2442-1.0.2+gitr3b8513d8b3d9615ebda605de4bda18371aa3f359

By doing "echo x > /sys/module/glamo_mci/parameters/sd_drive", "x" being the desired drive level, while playing around with TangoGPS with a GPRS link up.

At levels 0 and 1: random FS failures and corruptions as well as screen going into a mode that looks like an analog TV with "rain" on the right side;
At levels 2 and 3: random system freezes;
At level 4: occasionally the screen goes into a mode that shows a "scanning wave" of light going from top to bottom. Suspending and awakening sets it straight.

So, with a higher drive level, it solves the FS access problem and therefore stabilizes the applications; but the screen controller still gets mucked up. I didn't see any performance difference in the GPS receiver.

I presume now I need to pump up something else in glamo's graphics controller side to avoid this problem?... what?