Pack of CAM improvements

[Alexander Motin]

Juergen Lock wrote:
> Ok while we are talking about ahci(4) on IXP700...  Can anyone reproduce
> the `test unit ready' bug on one of those?  Since I saw no reply to
> my post,
> 	http://docs.freebsd.org/cgi/mid.cgi?201001231407.o0NE7l8j002620
> maybe the bug is controller-specific?  How to reproduce:  just try
> 	camcontrol tur adaX
> or
> 	cdrecord -scanbus
> or (at least I think this is the same issue) start xfburn without hal
> running, then watch for the bus to hang at the next disk access.
> (Also leaving the disk led on solid here.)  With the previous patch,
> 	http://people.freebsd.org/~mav/cam-ata.20100119.patch
> (haven't tested the latest one yet) at least it now seems to recover
> after some timeout, leaving this in dmesg:  (sorry I didn't notice
> when I first tried, guess I didn't wait long enough...)

It is controller specific. Intel and NVidia controllers just return
error immediately, as they should, and continue operation. ATI IXP700 -
doesn't:

> ahcich2: Timeout on slot 20
> ahcich2: is 04000000 cs 00100000 ss 00100000 rs 00100000 tfd 451 serr 00400000
> ahcich2: AHCI reset...
> ahcich2: hardware reset ...
> ahcich2: SATA connect time=0ms status=00000123
> ahcich2: ready wait time=11ms
> ahcich2: AHCI reset done: device found
> (ada1:ahcich2:0:0:0): Command timed out
> (ada1:ahcich2:0:0:0): Retrying Command

But after command timeout channel should reset and continue operation.
I've tried to handle this situation, but haven't found a good way.

But it is possible to just avoid this situation. As soon as CAM will any
way need to tell SIM ATAPI CDB length supported by device, it will be
easy for SIM to not send ATAPI commands to ATA devices. I am going to do
it, as soon as more important things will stabilize.

-- 
Alexander Motin