Guruplug I/O and JDB errors on writing to micro SD card

[puterboy]

I have a GPlug-Display which is configured with boot and root partitions on a micro-SD card (/dev/sda1, /dev/sda2, respectively) while there is an internal flash drive partitioned as FAT16 for storing videos (this is how it came configured).

When running applications that seem to write intensively to the flash (such as apt-upgrade but occassionally even simpler things), I randomly get errors on the console of form:
xa-sdh pxa-sdh.0: DATA Line Error(status: 0x0010)!
mmcblk0: error -5 transferring data, sector 1319016, nr 120, card status 0x900
end_request: I/O error, dev mmcblk0, sector 1319096
Buffer I/O error on device mmcblk0p2, logical block 139387
lost page write due to I/O error on mmcblk0p2
end_request: I/O error, dev mmcblk0, sector 1319104
Buffer I/O error on device mmcblk0p2, logical block 139388
lost page write due to I/O error on mmcblk0p2
end_request: I/O error, dev mmcblk0, sector 1319112
Buffer I/O error on device mmcblk0p2, logical block 139389
lost page write due to I/O error on mmcblk0p2
end_request: I/O error, dev mmcblk0, sector 1319120
Buffer I/O error on device mmcblk0p2, logical block 139390
lost page write due to I/O error on mmcblk0p2
end_request: I/O error, dev mmcblk0, sector 1319128
Buffer I/O error on device mmcblk0p2, logical block 139391
lost page write due to I/O error on mmcblk0p2
JBD: Detected IO errors while flushing file data on mmcblk0p2
JBD: Detected IO errors while flushing file data on mmcblk0p2

I'm not sure if this is due to bad flash or due to a driver issue. I am concerned though of course about data corruption.

NOTE the  output of fdisk -l is:
Disk /dev/mmcblk0: 4035 MB, 4035969024 bytes
68 heads, 3 sectors/track, 38640 cylinders
Units = cylinders of 204 * 512 = 104448 bytes
Disk identifier: 0x00000000

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1               1        1000      101998+   6  FAT16
/dev/mmcblk0p2            1001       38640     3839280   83  Linux

Disk /dev/mmcblk1: 8018 MB, 8018460672 bytes
219 heads, 12 sectors/track, 5959 cylinders
Units = cylinders of 2628 * 512 = 1345536 bytes
Disk identifier: 0x00000000

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk1p1               4        5960     7826432    b  W95 FAT32

and the outut of df is:
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mmcblk0p2         3778976   1072780   2514232  30% /
tmpfs                   257748         0    257748   0% /lib/init/rw
udev                     10240       520      9720   6% /dev
tmpfs                   257748         4    257744   1% /dev/shm

In any case, the problem seems to occur when writing to the root filesystem

[UnaClocker]

Wow, how'd you get one of those? I didn't think they were even forsale..

[UnaClocker]

Err, yeah.. It's not..  http://www.globalscaletechnologies.com/p-33-guruplug-display-devkit.aspx
How do you expect us to answer questions about something that only you have? heh.. I wish it was for sale, I'd love to play with one...

[puterboy]

I just mentioned the model for full disclosure, BUT I assumed that the problem may be more generic to Gurplugs or even to linux+flash in general.

I ended up reformatting the internal 8GB card (which is originally all vfat) into a boot and root partition so that I could boot from the internal flash drive (I also of course had to change the Uboot bootargs and bootcmd to get it to boot from it).

And I ended up getting SIMILAR write errors with the internal flash.
So, since it is probably unlikely to have both the external micro SD and the internal flah broken, my hypothesis now is that it is more likely to be a driver problem.

I must say the errors are "scary" when they show up randomly during a long 'apt-get upgrade' since you never know whether anything got corrupted that might one day come back to bite you... (I wish dpkg had a 'verify' mode like rpm).

(And please don't be jealous of me since I don't have an HDMI monitor to really make it work and the DVI-HDMI converter plug I have seems to work OK for standard display but the screen goes berzerk when I try to play any video (and of course sound doesn't work)

[restamp]

I can't comment on whether any data got lost.  I do think Unix tends to retry such errors, but I would at least do an "fsck -f" on the affected partitions -- and preferably from an external machine when you fsck your root partition.

That said, I will mention that I got some similar errors once from my SheevaPlug, and pulling and reseating the SD-card a few times cured it.  Sometimes the contacts develop some resistance over time.  You might want to try that on your Guruplug.

[pietsnot]

I have a GPlug-Display which is configured with boot and root partitions on a micro-SD card (/dev/sda1, /dev/sda2, respectively) while there is an internal flash drive partitioned as FAT16 for storing videos (this is how it came configured).

When running applications that seem to write intensively to the flash (such as apt-upgrade but occassionally even simpler things), I randomly get errors on the console of form:
xa-sdh pxa-sdh.0: DATA Line Error(status: 0x0010)!
mmcblk0: error -5 transferring data, sector 1319016, nr 120, card status 0x900
end_request: I/O error, dev mmcblk0, sector 1319096
Buffer I/O error on device mmcblk0p2, logical block 139387
lost page write due to I/O error on mmcblk0p2
end_request: I/O error, dev mmcblk0, sector 1319104
Buffer I/O error on device mmcblk0p2, logical block 139388
lost page write due to I/O error on mmcblk0p2
end_request: I/O error, dev mmcblk0, sector 1319112
Buffer I/O error on device mmcblk0p2, logical block 139389
lost page write due to I/O error on mmcblk0p2
end_request: I/O error, dev mmcblk0, sector 1319120
Buffer I/O error on device mmcblk0p2, logical block 139390
lost page write due to I/O error on mmcblk0p2
end_request: I/O error, dev mmcblk0, sector 1319128
Buffer I/O error on device mmcblk0p2, logical block 139391
lost page write due to I/O error on mmcblk0p2
JBD: Detected IO errors while flushing file data on mmcblk0p2
JBD: Detected IO errors while flushing file data on mmcblk0p2

I'm not sure if this is due to bad flash or due to a driver issue. I am concerned though of course about data corruption.

NOTE the  output of fdisk -l is:
Disk /dev/mmcblk0: 4035 MB, 4035969024 bytes
68 heads, 3 sectors/track, 38640 cylinders
Units = cylinders of 204 * 512 = 104448 bytes
Disk identifier: 0x00000000

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1               1        1000      101998+   6  FAT16
/dev/mmcblk0p2            1001       38640     3839280   83  Linux

Disk /dev/mmcblk1: 8018 MB, 8018460672 bytes
219 heads, 12 sectors/track, 5959 cylinders
Units = cylinders of 2628 * 512 = 1345536 bytes
Disk identifier: 0x00000000

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk1p1               4        5960     7826432    b  W95 FAT32

and the outut of df is:
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mmcblk0p2         3778976   1072780   2514232  30% /
tmpfs                   257748         0    257748   0% /lib/init/rw
udev                     10240       520      9720   6% /dev
tmpfs                   257748         4    257744   1% /dev/shm

In any case, the problem seems to occur when writing to the root filesystem

i have two gp+'s running and have since 8 months also the rootfs and swap allocated on mmc-cards.
on one guruplug i've exactly the same problem as you (8gb mmc a-data), the other gp+ is running without any problem (4gb mmc)!
i have not yet figured out what the problem is: the specific mmc-card or  gp+
the problem occurs about one time in 2 months.
i did a badsector check on my laptop, result: no bad sectors.
my workaround is simple: insert the mmc-card in your laptop, do a fsck with autorepair (a lot of errors will be found) , after that my gp+ with that recovered mmc-rootFS is running fine for weeks.
weekly i make a tar-backup of the rootFS, in the beginning i did not the above mentioned workaround, but formatted the root-partition and restored the tar-backup.