iriver h320: freezes, lags and buffer stalls with ssd

[Horazont]

Hi all,

I hope this is right in hardware; I did not find a driver section, so I thought hardware might fit. Anyways, on topic:

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 the iriver with a 60GB 1.8" 50-pin IDE SSD (MXSSD1MNANO50-60G). After reinstalling rockbox software (bootloader was still there ofc), everything worked fine, but after a few minutes of playback, 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[1] while doing research about that issue).

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

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 suspecded 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 commit on the 3.11 git-tag.

So today 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.

So to summarize:
* SSD works flawlessly over USB
* Boot and initial buffer filling 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 )) as soon as a disk access occurs some time later (not sure after which time this happens exactly; guess: after 255 seconds (current value of the spindown-timeout-setting))

so far: many thanks to the rockbox project; it gave me a really awesome DAP which still outruns many recent players in everything except size (esp. since I replaced the HDD). I'd really like to see that fixed and I'm happy to help with debugging. I may also write a patch upon being pointed into the right direction where to look (i.e.: which commands/files/… might be relevant to play around with or something).

best regards
jonas

[1]: http://forums.rockbox.org/index.php?topic=23436.0;wap2

[Horazont]

Okay, updates: I was able to test the original firmware today. Result: No problems. It runs smoothly for some time now, with no (notable) lags when skipping songs or whatsoever.

My assumption now is that something goes wrong with power management in Rockbox. I read the whole source of firmware/drivers/ata.c and sparingly some other files in the meantime in the quest for a clue what might go wrong.

Turning off all sending to sleep did not work out—so I guess that the ssd device itself might go to sleep automatically. Is there any way to force a wakeup? I read about CMD_IDLE{,_IMMEDIATE} in the ATA specs, but I am somehow a bit hesitant on trying to write raw ATA without having talkback to the pros .

Also I noticed the following oddity in the code:
in ata_transfer_sectors, the following is done:
    timeout = current_tick + READWRITE_TIMEOUT;
where READWRITE_TIMEOUT is defined to 5*HZ at the beginning of the file.
However, wait_for_start_of_transfer waits for up to 30*HZ (referring to around line 497 in ata.c, where you goto to retry if the wait times out. So the goto retry is useless, because right afterwards a check for TIME_BEFORE with the above timeout is made, which is of course already elapsed. This yields an immediate abort, even if a soft reset might have helped.

My initial assumption about having problems after 255 seconds turns out to be wrong. I could not yet detemine a reliable pattern, but its definetly occuring later sometimes.

any comments (might this be better a mailing list issue?)
jonas

[bluebrother]

any comments (might this be better a mailing list issue?)

Yes, this is better discussed on the development mailing list -- not all developers check the forums frequently (if at all).

(can't help on the topic itself)

[Horazont]

any comments (might this be better a mailing list issue?)

Yes, this is better discussed on the development mailing list

Okay, thanks for the suggestion. Moved that topic to the mailinglist. I hope I didn't do a major fail in doing so .

best regards
jonas