Sheldon Hearn wrote:
>
> > It was somehow distressing, though, that the new code had the exact
> > same bug as the old, even though it was quite different code.
>
> When you say "the new code", are you referring to the newer acd driver
> as opposed to the older wcd driver? If so, do you think it'll be worth
> my while trying to mangle into the acd code your diffs against the wcd
> code?
No. As I said, that was ages ago... :-) Once we had a wd.c whose
code path was quite different from what we have (had) in wd.c now.
i368/1730. Funny that did doesn't seem to be the original PR that
was fixed, but one applying to the "new" (then :) code. Didn't have
much success searching for my own PRs. It ought to do substring
searching on the web pages, but it doesn't. :-( OTOH, it seems some
of my PRs were filed as confidential, even though they were not, so
that my also explain why I couldn't find the other PR.
Relevant parts:
> This happens because a DELAY is missing in one loop, and ARS_BSY
> flag is being ignored in another (atapi_request_immediate and
> atapi_wait_cmd functions).
On the code:
> ireason = inb (ata->port + AR_IREASON);
> ac->result.status = inb (ata->port + AR_STATUS);
> phase = (ireason & (ARI_CMD | ARI_IN)) |
> - (ac->result.status & ARS_DRQ);
> + (ac->result.status & (ARS_DRQ|ARS_BSY));
> if (phase == PHASE_CMDOUT)
> break;
> DELAY (10);
The missing delay is not relevant. (Or, at least, I hope acd is not
missing delays in wait loops!)
The problem is the ARS_BSY signal. If my memory doesn't fail me, if
ARS_BSY is active, then the other signals may contain trash. In this
particular loop, ARS_BSY could be active, but it wasn't being
checked for, on the assumption that ARS_DRQ would only be up (down?)
when the operation completed.
Mmmmm.... Found my PRs now. It definitely looks like a PR went
confidential... :-( I think I explained the bug a lot better on the
other one... :-( Oh, well.
Well, feel free to search for ARS_DRQ and ARS_BSY on acd (if it uses
the same defines...). The ATAPI document I used was SFF8020. It
might have been obsoleted by now.
--
Daniel C. Sobral (8-DCS)
d...@newsguy.com
d...@freebsd.org
"To make it absolutely clear: you stand on the wrong end of my
blasters, so you better get lost before I start target practice!"
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
