Re: memory corruption/panic solved ("FAILURE - ATAPI_IDENTIFY no interrupt")

Matthew Dillon wrote:
> :I've tracked down the source of the memory corruption in -current that
> :results when booting with various CD and DVD drives (especially the ones
> :that come with Thinkpads including T23, R32, T41, etc.)  The panic is
> :..
> 
>     Nick, 

s/Nick/Nate and not either of the Williams ones (Net and FreeBSD).  :)

>     what about the retry code in ata_completed()? (ata-queue.c 229).
>     Does it need to reset donecount as well?  Both the code in 5.x and 
>     the code in 4.x looks 'dangerous' with regards to general retries.

Hmm, it seems like this could be a problem with requests that are
re-queued.  It's likely that donecount was never incremented in the
error cases but I don't know the code well enough to say this.  There is
also the question of whether it's ok to retry a request in immediate
mode that previously was done as a queued request.

I'll let Soeren address this.

>     The 5.x code seems to handle retries generically via 
>     ata_finish()->ata_completed()->(retry handling), and this seems to
>     include IMMEDIATE requests, and it does not appear to reset the 
>     donecount when it requeues.
> 
>     The 4.x code seems to handle retries in ad_timeout() and ad_interrupt()
>     (and doesn't reset donecount in either case as far as I can tell),
>     and the 4.x code's addump() seems to rely on donecount in its transfer
>     loop (but I do not see any similar reliance in the 5.x code).

I don't see any obvious problems here but looking into error handling or
other uncommon paths is usually a good way to find latent issues.

-Nate