I think these reports all point to a problem with the sparc32 kernel far outside of the drivers in question. We have no reports like this on sparc64. My running theory is that things like msleep() are returning immediately on sparc32, or at least too fast, instead of delaying the minimum necessary amount. This will screw up the scsi reset settle delay, and the devices will return scsi command status's that the SCSI bus probe will consider not good enough to recognize the device. This is exactly what tracing from Tom Callaway has shown in the past. So this is a sparc32 kernel bug of some sort, most likely, not a driver bug. - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
