From: Mike Holden <rockbox_at_mikeholden.uklinux.net>
Date: Tue, 5 Aug 2003 22:18:11 +0100 (BST)

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
> spec.
>
>> 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[1] 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
think so!)

-- 
Mike Holden
Rockbox page: http://www.mikeholden.org/~rockbox

Received on 2003-08-05