903 microSD write fails on PocketBook 903

[LoneTech]

This is quite a serious problem, and probably related to why we see the suggestion to use class 4 cards. In repeated attempts to access the microSD over USB, writes have been ignored. Earlier I also got filesystem corruption, suggesting that some may be misplaced, which is even worse. It is not USB specific as attempts to make changes from the Files view also fail; can't rename, no space, can't move... the card isn't write protected, the filesystem is a perfectly accessible vfat, and a move doesn't require any space (unless it needs to grow a directory, and the root directory which I moved to cannot grow) - besides which, there was plenty of space. It doesn't even consistently fail, as one attempt to remove a file instead created a second, empty file. Perhaps it ran creat() before rename() to make sure it didn't overwrite another file, and only the creat() took effect.

It appears the PocketBook device has a kernel bug, causing it to fail to write to this SD. If higher class cards tend to work, this is indicative that it simply presumes to talk to the card at higher speeds than it can handle.. and the SD class does not guarantee it will work, because you don't know the access pattern as a USB storage device. Also, if you fail to write, bloody well report it! Silently dropping users' documents is inexcusable.

This is all with firmware 2.0.4.

A bit of reading up in the SD spec suggests that, if it is as I suspect, the busy status any write may indicate is not respected. The interesting section is in the middle of page 31 of part 1: "Some cards may require long and unpredictable times to write a block of data."

I'd be willing to take a look at fixing this, but it would of course require root access on the device as well as kernel source code. And possibly a little documentation from Samsung about S3C6410, as it seems it should have an SD host controller; the bug is nearly certainly theirs, anyway.

[LoneTech]

Okay, now I'm actually getting angry. Looking in your published kernel sources, the SD driver s3c2440mci is not source. There's a binary blob, meaning the kernel you have published as "Source code" is anything but.

The vanilla kernel source, meanwhile, has a s3cmci driver which probably works better, so this offense is doing damage every which way you turn it! This driver has seen improvement since the 2.6.29.6 release used in the 903, so it's quite possible the bug I'm running into has already been fixed upstream.

Another possibility is that the bug is in silicon, in which case Samsung really owe us quite a bit more.

It looks like an old issue has caused similar trouble.

[LoneTech]

In order to test the hypothesis that the pocketbook isn't actually writing all the data it receives, I tried copying the entire contents of my unclassed 2GB card using both a card reader and the 903.

Using only a card reader:
2003304448 bytes (2.0 GB) copied, 2324.63 s, 862 kB/s
The write speed was jumping around quite a bit, usually staying about 1MB/s but peaking about 3.3MB/s.
Using PocketBook 903:
The write speed clearly showed buffering going on, as the device would accept several megabytes (44MB in 3s was observed) from time to time, and nothing at all in between.
The first test failed, with some worrying messages from the kernel (after these came hundreds of errors because the device was gone):
[828350.358282] usb 2-1.5: reset high speed USB device using ehci_hcd and address 45
[828355.432875] usb 2-1.5: can't restore configuration #1 (error=-110)
[828355.433130] sd 24:0:0:1: Device offlined - not ready after error recovery
[828355.433143] sd 24:0:0:1: [sdc] Unhandled error code
[828355.433147] sd 24:0:0:1: [sdc] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
[828355.433153] sd 24:0:0:1: [sdc] CDB: Write(10): 2a 20 00 10 8d c8 00 00 f0 00
Second test also failed. The device simply fails after some time. Before the failure, it appeared to copy a lot of data:
1212235776 bytes (1.2 GB) copied, 168.922 s, 7.2 MB/s
But as earlier indicated, that much couldn't have gone into the SD card that fast, not even if we count the device RAM as cache.

It is clear there's a failure detected in the PocketBook as well, and this is why it gets removed. I can't get at the internal diagnostics, though, as the terminal for earlier devices doesn't work on the 903.

[paola]

Hi Lonetech, hope somebody from Pocektbook picks up your point and those raised by others and actually provide some feedback - because they seem quite active on the German forum even these days, while here it seems there way more questions and frustrated would be users than answers and help, would be nice if they popped around more often!
Thankgod for Dulin, though there is only so much he can do...

[LoneTech]

For now I simply cannot use the 903 to write to microSD. I tested later if the contents were intact, and they weren't - so both the addressing and writing had gone wrong (I was writing the exact same data that was there in the first place).

[Dulin's Books]

Truthfully Im not sure Im even understanding the problem. I understand the last bit of the test- you tried to copy the contents of a 2gb card. where did you try to copy it too and from? sorry if it sounds dense but from my history of ferreting out problems with cars over the internet i know every question needs to be asked even the "obviious".

did you place an empty 2gb card into the 903 and then try to write the contents from the other card to the 903 through a computer over usb?

and previously you had issues just moving one file? also you had problems just deleting a file from the card on device?

I can tell you I have not had any of that sort of issue with the 902 I have except for copying the contents of an entire card., i simply havent tried that.

what OS are you using?

[LoneTech]

I copied it to and from a file on my laptop hard disk, without mounting the microSD card, using dd. I tested this with both a USB card reader and the PocketBook.

I'm not sure what you meant by empty card, though I must note the PocketBook may not export the whole card if it has been partitioned. I have my card unpartitioned, and attempted to overwrite it with the exact contents it already had. Modifying the filesystem led to unpredictable effects, including corruption.

Yes, single operations within the PocketBook 903 Files tab failed. I tried renaming a directory, renaming a file, moving a file to a different directory, and deleting a file. Only the file rename attempt had any effect, creating an empty file.

I am using Debian GNU/Linux.

I believe this problem is easier to trigger with a slow microSD like mine. For faster ones, it will probably occur if you do many small writes all over the card (not sequentially).

[Dulin's Books]

i meant did you use a card with nothing on it. take an empty card and attempt to move the large file/files to it.



it seems you used a card that already had the file/files on it and attempt to over write the entire card using the same file/files as stored on your lap top . correct?

what if you write that large file to a new empty sd card? does the same thing happen as when you try to overwrite? what if you over write it with something different?

i just tried again all of the functions you mention on device and the only thing I had trouble with was renaming a file. it didnt look like it had worked. the titled displayed didnt change. however when i looked at the information for the file the file name had changed, just the displayed title had not. turning the device off and rebooting had no effect.

[LoneTech]

SD cards are not delivered empty - they have a FAT filesystem by default (part 2 of the spec, not public). I could wipe the card, but it's really the same operation as overwriting it. Since I was overwriting the entire card sequentially the prior contents should not affect the test. I was not overwriting it with files but an image of the entire card contents. It was not mounted so no filesystem effects were involved. Basically like using Ghost or similar disk imaging tools in exact copy mode.

In short, yes, I overwrote it with the same contents. The results weren't the same, however, though I haven't analyzed precisely what it did; my guess is dropped data such that what remained got shifted to lower addresses.

Note that it appears a partitioned card is not exported as the whole card by the PocketBook, but as the partition itself. I avoided this difference simply by having the card unpartitioned.

Come to think on it, actually wiping by SD erase commands might be a good idea. I don't know if I have any device that can do that.

[Dulin's Books]

yes i mean empty but for the FAT. if you put a fresh new card( or the same card with everything having been deleted using the card reader and laptop) in the device and try to write the image to it over USB what happens?


I should make this clear- i have no knowledge of linux or linux OSs AT ALL i have enough understanding of the language to be able to follow some conversations. for instance I assume when you wrote "dd" earlier that you meant drag and drop but you might have meant something else.

Im not so concerned over the whole card image thing (how often would someone do that really. I would have put the card in the laptop to do something like that out of habit) as I am about the other on device items not working. did you try with items in the internal memory or only in the SD? can you move a file from device to SD and back?


what if you format the card with the device?

do you have a different card to try?

[Dulin's Books]

hmmm https://www.mobileread.com/forums/sho...62#post1307262

[LoneTech]

dd is an ancient copy command, the meaning of the name has been lost to history (although the guess "data duplicator" is around). Its original use was to transfer data to and from tapes that were particularly picky about how large chunks you could access, and it can also do translations for IBM mainframe data, padding, byte swapping and such. In this case, however, it is simply copying a disk, sector by sector, although I chose somewhat larger transfer sizes. The PocketBook basically overrode the block size anyhow, since it buffers several megabytes and writes at whatever pace it picks. One feature of dd is the final report of how fast it worked.

Accessing the internal memory on the PocketBook (called Device in the GUI, Pocket903 as exported or /mnt/ext1 in the OS) works fine, I've written files there with no problems. This indicates that the USB storage system works normally, and the problem is specific to the SD slot driver - though probably dependent on card type.

That thread does look like the same behaviour. It's a late symptom, however, as all it's saying is the USB storage device disappeared. It happens for me too, at some point after the PocketBook internally realizes something is wrong, but there's no telling what.. and things have gone wrong earlier, as evidenced by my misplaced data.

I just tried the Configuration - Maintenance - Format SD card choice in the PocketBook. It did not erase the card, I'm not sure it overwrote anything at all. It did, however, jump into digitizer calibration. I do not know if that's expected.

I have a couple of other microSD cards to test with, though one appears broken and both are tiny. The whole point of installing the card was that my books wouldn't fit otherwise.

The card image thing was mostly to eliminate other factors. I am estimating that the problem is more likely to reoccur, not less, with any other access pattern except very slow access limited to one sector at a time.

I have now tested one of my SanDisk 128MB TransFlash cards. It appears to have no problem at all. The format command did wipe this one, and triggered a calibration as well. The problem may be SDHC specific, and seems most likely to occur on large and slow cards.

I must point out that I do not believe my use of Linux affects this at all; how to write to the SD card is out of the computer's hands once the data has moved over to the PocketBook.

I probably could purchase a card with less trouble, but that would not fix the root cause. The card itself is not defective, as it works just fine in every other card reader I have. The only way it would be prevented is having a card that consistently outperforms the PocketBook's attempts to write, so it never gets its buffers full; and that's a very hard guarantee to make. We don't know how fast it attempts, and cards aren't typically rated so you can be sure. In particular, SD class only covers whole erase block recording such as done by video cameras. On the other hand, it's possible the bug is specific to SDHC cards that do not have the write rate information. I just don't know.

[NextStep]

Indeed, this looks like a really serious defect. If this is true we can say that the Pockebook can't reliably write to any micro SD card. Maybe a lot of people will say that they haven't experienced any problems so far, but the keypoint is in the word reliable.

Originally Posted by LoneTech

.... if it is as I suspect, the busy status any write may indicate is not respected.

As far as I understand it you were not able to assess 100% sure that this write status was not observed.

How can we make sure this issue is read (and solved of course) by the Pocketbook programmers? Are you planning to post it in the Sticky Bug report thread?

[LoneTech]

I cannot easily confirm the details of my conjectures; doing so would require a lot more work, which I have neither time nor wages for, involving a logic analyzer on the microSD port, which is a bit small to reach. An adaptor that reaches into the slot would be useful. When I first started testing, I could not even access the dmesg inside the PocketBook; now I've reached that far, but haven't repeated my tests.

[rkomar]

Originally Posted by NextStep

How can we make sure this issue is read (and solved of course) by the Pocketbook programmers? Are you planning to post it in the Sticky Bug report thread?

This sounds like a problem with the underlying Linux OS rather than any customized PB applications. It may be outside the "core competency" of the PB programmers, and so take a while to correct.

@LoneTech, you mentioned in another thread (which I haven't revisited yet today) that you had a terminal working on your device. It would be worth looking at the output from the 'dmesg' command after one of these failed operations to see if the kernel reported any problems. Reporting any error messages would greatly help speed up the debugging process.