From: Jonas Wielicki <j.wielicki_at_sotecware.net>
Date: Mon, 16 Apr 2012 08:58:32 +0200

Hello rockbox-dev,

This is basically a repost of of my forum post [1], as I was indicated
to have a try on the mailing list. I'll repost everything here in a
restructured manner + some more details for the sake of completeness though.

I recently replaced the toshiba HDD (which had a hardware defect, i.e.
it only went tick-tick-tick crrrsssh on certain songs and I/O-errord
when trying to access those via USB) in my iriver H320 with a 60GB 1.8"
50-pin IDE SSD (MXSSD1MNANO50-60G). After reinstalling rockbox software
(bootloader was still there ofc), everything worked fine, but a few
minutes of playback later, some errors may (I say may, because the
symptoms differ, see below) occur:
* Playback reliably stops
* “Error accessing playlist control file” - may occur
* Freeze - may occur after the above error; however, freeze might also
be me too unpatient when trying to turn the player off
* Freeze if one tries to do anything with the drive (e.g. accessing
files, loading a theme…)

The first three conditions can be exited “gracefully” by just turning
the player off by holding Stop for a few seconds—just as usual. However,
shutdown takes longer (I suspect a hard turn-off by rockbox at that
place because of timeouts, I read about that in the forums[2] while
doing research about that issue).

I first tried to set the spindown time to 255 in the config file. Didn't
help.

I then went on to try recompiling rockbox with changed settings for my
h320, namely, I changed HAVE_DISK_STORAGE to HAVE_FLASH_STORAGE and
removed HAVE_ATA_POWER_OFF, because I suspected the SSD having issues
with “spinning up” (read about that in the same thread as above).

This did not fix the issue (i know I am using my custom build, as the
version number is now referring to my commit instead of the release
number). I based my changes on the 3.11 git-tag.

So then I had time to follow the buffering thread in the debug menu when
a playback stall occurs. Basically the usefl-value decreases (am I right
when I assume that this is the “useful” part of the undecoded buffer
data?) to zero, after which the pcm buffer depletes which then makes
playback stop. I waited a few seconds, but it did not refill.

More debugging took place since then. Esentially I found out that
playback may stop only for like 30 seconds (*), and continue then. In
that case, the usefl buffer still holds contents, but pcm is empty for a
while. I guess the pcm thread stalls for data due to the buffers being
blocked by a blocking ATA request or similar.
(*) why do I say 30 seconds? This is the timeout I found in ata.c. I did
not measure, but it pretty much feels like 30 seconds.

Also the original firmware seems to cope flawlessly with the SSD. I
played some music jumping from one song through the next with it without
problems yesterday—but there are enough other good reasons to use
rockbox instead.

I read through sources, mainly ata.c and a bit of its surroundings,
storage.c and the (on my target appearantly unused) ata_flash.c, a few
lines of fat.c and codec{,_thread}.c to find a clue. I also skimmed an
ATA specification draft I found linked on wikipedia, but it seems
outdated (for example missing the 0x42 Feature Code you're using).

I made some experiments with disabling sending the disk to sleep etc.,
but that didn't help. It seems like the SSD puts itself to sleep after a
while, because the symptoms which occur with a Disk Spindown Timer of 5
seconds at the end of the first song are the same I have after a few
minutes of playback with all sleeping disabled. However, I've no idea
why waking up does not work in that case.

Furthermore noticed the following oddity in the
ata.c:ata_transfer_sectors code (me being right with the following would
indicate that I understood what's going on there ;) ):
In line 389 (referring to git tag 3.11), we have timeout set to
current_tick+READWRITE_TIMEOUT, the latter being 5*HZ. This is checked
against in line 401, right after the retry:-label. Later on we do
wait_for_start_of_transfer, and on timeout of that we jump to retry.
However, the timeout of wait_for_start_of_transfer occurs after 30*HZ.
So basically, after a perform_soft_reset has taken place, one
deterministically exits with an error without seeing whether it actually
helped.

So to summarize:
* SSD works flawlessly over USB
* Boot and initial buffer filling works fine
* Original software works fine
* Stall (or freeze, if the software waits for the access in the “main
thread” (I call the part main thread which allows me to turn the device
off gracefully Wink )) as soon as a disk access occurs some time later
(not sure after which time this happens exactly)

Sorry for that big wall of text, but I think its reasonable and contains
necessary information for helping and getting help for debugging that
issue :).

best regards,
jonas

[1]: http://forums.rockbox.org/index.php/topic,34004.0.html
[2]: http://forums.rockbox.org/index.php/topic,23436.0.html
Received on 2012-04-16