Rockbox mail archive
Subject: Re: Red led dead - this is where it goes wrong!!!
From: Mike Holden (rockbox_at_mikeholden.uklinux.net)
Björn Stenberg said:
> Mike Holden wrote:
>> > I haven't done this because I don't like the idea of breaking the
>> ATA specification only to lessen the impact of our own bugs.
>> Fair enough. Does the spec state we must wait 10 seconds? If so, then
>> I'm sure we must comply with that.
> I couldn't find it with a quick glance, but I recall reading it in the
>> At the very least, can we get rid of that awful perform_soft_reset()
>> function that takes 90 seconds to complete, as this makes the impact
>> of the problem far more severe than it needs to be. As I have stated
>> earlier, it loops through a 10 second wait 9 times, before returning
>> an error to the mpeg layer. Rockbox then skips to the next track and
>> again waits 90 seconds and so on to the end of the playlist/directory.
> I doubt this will help much either. We can cut down the wait time to 31
> seconds per reset call, but is still means a very long time hung when
> playing a moderately-sized playlist. Far longer than most users are
> willing to wait.
Maybe we need to consider the possibility that a long wait for a reset
that will __often__ fail is not necessarily the best course of action.
Maybe we should instead consider a panic() type of approach with a
disk-read error reported to the user, and a reboot of the system. With
flashing available to a lot of users, a 5 second reboot and resume is
preferrable to even a 31 second wait, let alone 90 seconds.
I still agree with the earlier sentiments that a proper fix is the best
course of action, but regardless of how we handle disk lockups, there will
always be the possibility that the unit needs a reboot (at least Archos
Rockbox page: http://www.mikeholden.org/~rockbox
Page was last modified "Jan 10 2012" The Rockbox Crew