Looks Like The Is A Read/timing Problem With Sd Reading When High Cpu

[Pleng]

So, after 1 month of not observing any problems, I find that if I try to copy between slot1/slot2, then I get errors after 15-17MB.

That's about where I get to, too.

 

[tsh]

That's about where I get to, too.

Either way, or both 1->2 and 2->1?
USB card reader in A socket, SD in slot1, I can copy ubifs.img there and back, ad it still has the same md5sum as the original.

For me, the problem only appears when BOTH SD cards are in use. Other subsystems might come into play, but this seems a suitable sub-set to focus on. (WiFi is a disaster for repeatability)
And as a subtle twist, copying TO three of my entire collection of cards (less the one in my phone), in either slot, seems to work.

The good cards are:
2GB Sandisk Ultra II (SD)
4GB Sandisk SDHC class 2
2GB Sandisk Micro SD+adaptor

The bad cards are:
PNY 16GB Class 4
Bytestor 16 GB class 2
Samsung 4GB class 4 SDHC-Micro+adaptor


I guess it is a co-incidence that all of the slow cards I own are Sandisk.

 

[Pleng]

That's about where I get to, too.

Either way, or both 1->2 and 2->1?

Just from slot 1 - 2.

Slot 1 Class 4 32Gb extfs
Slot 2 Class 2 16Gb fat32

I haven't tried swapping them around yet. I will try and get around to that next time there's a rainy day.

 

[EmuGuy]

Hmm, I'm seeing this too now. Tried copying 200MB files from slot 1 to slot 2, fails with I/O errors at about 25MB into it.
Copying from slot 2 to slot 1 however works flawlessly.

Swapped cards, same issue, so its not the cards. Slot 1 to 2 always fails. Wow.

 

[wejp]

I can confirm this problem. An old Sandisk 1 GB SD card fails in my Pandora in Slot 1 in exactly the same way. The same card works flawlessly on other devices. I haven't checked other cards yet.

 

[joseluisjazz]

Any news on this bug? Today I found I have the same I/O errors when trying to copy from SD1 to SD2. In my case I have root on SD1 (Kingmax 16GB class6). Anyway here's a bump.

 

[EvilDragon]

Any news on this bug? Today I found I have the same I/O errors when trying to copy from SD1 to SD2. In my case I have root on SD1 (Kingmax 16GB class6). Anyway here's a bump.

Well, the only one that could possibly be working on that is notaz - and as you might've seen in the Beta Testing area, he's currently working on WiFi.
So I guess nothing happened here, unless someone else tried to debug this.

 

[urjaman]

Just dropping by to confirm and bump this. My view: A write to SD2 sometimes causes SD1 read to fail mysterioysly.
It might be even possible to add a kludge to the kernel to avoid this condition. Eg. while reading SD1 pause writing to SD2, but I think this should be really investigated.
Also, just noting that if you need to do partition copy (or card clone) from SD1 to SD2 with the pandora, I use these flags atm:
iflag=direct,dsync oflag=direct,dsync bs=32M
I think that just oflag=dsync might be enough, just so that after writing of the block by dd it has really been written to the device, so the kernel wont try to write to SD2 when dd is reading SD1. iflag=direct is needed to really try to read sectors falsely reported as bad if you tried to do a simple copy first.

I'm not changing my flags because my transfer is nearly complete anyways, just dropping this info here.

EDIT: I made a system to copy files from SD1 to SD2 relatively reliably:

rcopy.sh:

#!/bin/sh

if [ -d "$1" ]; then
        mkdir -vp "$2$1"
        exit 0
fi
TGTDIR=$(dirname "$1")
TGTDIR="$2$TGTDIR"
cat "$1" > /dev/null
cp -v "$1" "$TGTDIR"
sync

And used this to copy files from current dir to /media/mmcblk1p1:

find -exec rcopy.sh '{}' /media/mmcblk1p1/ ';'

It just copied 931M of random files and mp3s for me without a problem. However, note that it cant copy a file thats too big to fit in the disk cache, so YMMV.

 

[abochmann]

Another user with this problem, unfortunately. It's not actually required to "copy" data from one card to another. I was using:

dd if=/dev/zero of=/media/card/data.out bs=1M

...just left it running until the card was full.

With the card in the left slot, I got tons of I/O errors and finally a stack trace. With the same card in the right slot, data was written until the file system ran out of space, with no errors. I was writing to an 8GB ext2 partition on a 16GB card.

Excerpt from the kernel log with card in the left slot:

[38723.146881] mmci-omap mmci-omap.0: MMC IRQ 0x108000 : ERRI DTO
[38723.146972] mmcblk1: error -110 transferring data, sector 20320320, nr 8, card status 0xc00
[38723.329071] end_request: I/O error, dev mmcblk1, sector 20320321
[38723.335113] Buffer I/O error on device mmcblk1p2, logical block 753664
[38723.341674] lost page write due to I/O error on mmcblk1p2
[38723.696777] mmci-omap mmci-omap.0: MMC IRQ 0x108000 : ERRI DTO
[38723.696868] mmcblk1: error -110 transferring data, sector 20582464, nr 8, card status 0xc00
[38724.432434] end_request: I/O error, dev mmcblk1, sector 20582465
[38724.438476] Buffer I/O error on device mmcblk1p2, logical block 786432
[38724.445037] lost page write due to I/O error on mmcblk1p2

[..]

[38731.066131] mmci-omap mmci-omap.0: MMC IRQ 0x108000 : ERRI DTO
[38731.066223] mmcblk1: error -110 transferring data, sector 14291008, nr 8, card status 0xc00
[38731.391754] end_request: I/O error, dev mmcblk1, sector 14291009
[38731.397796] Buffer I/O error on device mmcblk1p2, logical block 0
[38731.403900] lost page write due to I/O error on mmcblk1p2
[39200.550903] ------------[ cut here ]------------
[39200.555572] WARNING: at fs/buffer.c:1186 mark_buffer_dirty+0x38/0xb0()
[39200.562133] Modules linked in: board_omap3pandora_wifi wl1251_sdio wl1251 isofs aes_generic lib80211_crypt_ccmp lib80211_crypt_wep lib80211_crypt_tkip lib80211 arc4 pcbc ecb compat_firmware_class mac80211 cfg80211 compat rfkill_backport bufferclass_ti omaplfb pvrsrvkm ipv6 ads7846 hwmon [last unloaded: wl1251]
[39200.590057] [<c036e4bc>] (dump_stack+0x0/0x14) from [<c0053f60>] (warn_on_slowpath+0x4c/0x84)
[39200.598693] [<c0053f14>] (warn_on_slowpath+0x0/0x84) from [<c00c7124>] (mark_buffer_dirty+0x38/0xb0)
[39200.607910]  r6:00000000 r5:c04b696c r4:cf756608
[39200.612609] [<c00c70ec>] (mark_buffer_dirty+0x0/0xb0) from [<c0108770>] (ext2_write_super+0x7c/0x8c)
[39200.621856]  r5:c2849600 r4:c7145400
[39200.625457] [<c01086f4>] (ext2_write_super+0x0/0x8c) from [<c00a52f0>] (sync_supers+0x78/0xb4)
[39200.634185]  r6:c0485194 r5:c2849640 r4:c2849600
[39200.638885] [<c00a5278>] (sync_supers+0x0/0xb4) from [<c0087a20>] (wb_kupdate+0x50/0x150)
[39200.647155]  r6:cc98df98 r5:cc98c000 r4:cc98df30
[39200.651824] [<c00879d0>] (wb_kupdate+0x0/0x150) from [<c00884a0>] (pdflush+0x10c/0x1c0)
[39200.659942]  r7:c047de90 r6:cc98df98 r5:cc98c000 r4:c0484cc4
[39200.665679] [<c0088394>] (pdflush+0x0/0x1c0) from [<c0066ee0>] (kthread+0x5c/0x94)
[39200.673339] [<c0066e84>] (kthread+0x0/0x94) from [<c0056f60>] (do_exit+0x0/0x6b8)
[39200.680908]  r6:00000000 r5:00000000 r4:00000000
[39200.685607] ---[ end trace 9094bde007f4226b ]---

[edit] that's with HF5, and damn I didn't notice the last post to this thread was half a year ago...

 

[Prometheus]

[edit] that's with HF5, and damn I didn't notice the last post to this thread was half a year ago...

That's not a problem. If you'd like me to split your post into its own thread, though, drop me a PM and I can do that.

 

[abochmann]

[edit] that's with HF5, and damn I didn't notice the last post to this thread was half a year ago...

That's not a problem. If you'd like me to split your post into its own thread, though, drop me a PM and I can do that.

Thanks, but not required... I think I've been on the wrong track anyway - just got I/O errors on the right slot when I was running an e2fsck on the file system...

After some googling there's all sorts of speculation on this kind of error with SD cards on OMAP3 from last year, so this probably leads to nothing.

 

[wejp]

It looks like this is actually a hardware problem. Have a look at the OMAP3530 Silicon Errata document, page 136.

 

[WizardStan]

I don't know. The errata is saying it should affect both MMC1 and MMC2. Why does it only seem to affect one of the slots? And why so consistently when copying from one slot to the other but not the other way around? And why not everyone?

 

[zapman]

I don't know. The errata is saying it should affect both MMC1 and MMC2. Why does it only seem to affect one of the slots? And why so consistently when copying from one slot to the other but not the other way around? And why not everyone?

I had this file corruption problem as well when copying from SD2 to the SD1 slot but it seems hotfix5 fixed it for me.

 

[neko]

I don't know. The errata is saying it should affect both MMC1 and MMC2. Why does it only seem to affect one of the slots? And why so consistently when copying from one slot to the other but not the other way around? And why not everyone?

It's not consistent which slot either. Zapman reports this problem when reading from slot 2, but I have the problem when reading from slot 1.