Rockbox Technical Forums
Support and General Use => Hardware => Topic started by: Horazont on April 09, 2012, 11:37:47 AM
-
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
-
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
-
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)
-
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