>But I've been disapointed by the behavior of our scsi drivers: to test the
>raid5 behavior, I starded switching off and on the disks. The ahc driver
>doesn't like this very much: when I power back the drive, the console if
>flooded with message likes:
>target 4 synchronous at 20.0MHz, offset = 0x8
>and the bus is hung.

Old, old, bug.

>Using scsictl to probe a disk which was not powered at boot time doesn't
>seems to initiate sync/wide negotiation; at last there's no messages and
>the performances are not as good as with a drive probed at boot time.

Later versions of the driver will renegotiate when the device returns
a check condition status.  This is guaranteed to occur after a device is
powered on when it reports it's 'powered on' unit attention.

>These behaviors prevent any king of hotswapping, and raidframe would be much
>more useable if these were fixed. The ahc case seems to be the more simple
>to fix. Maybe a look at the FreeBSD driver would help ?

Perhaps.  Hot swap in general is a difficult proposition in the current
NetBSD SCSI environment.  The new FreeBSD SCSI layer has all of the hooks
to perform this correctly, but there are still some policy issues that need
to be resolved before a complete solution is available (how to you report a
device invalidation to higher levels, what kinds of errors should cause the
system to invalidate a device, how is a device re-validated if we encounter
an unexpected unit attention error and is knowing that it is the same
device sufficient since cache contents may have been lost, etc, etc.).

--
Justin