> The slight problem here is that no-one has a sequencer manual which tells us what all this means. However, it's > completely normal since the driver has a dump_card_state() call in the abort routine. > > Why the abort was called in the first place is anyone's guess, but it > probably came from a command timing out. The timeout could either be a > sequencer error or simply a normal problem because you're hammering the device hard and it took longer to get to the > command to process. > > You can test this latter quite easily by doubling the command timeouts: > > echo 60 > /sys/class/scsi_disk/*/device/timeout > > And seeing if the trouble occurs with the same frequency. If it does, there's likely some sequencer issue; if the > frequency decreases, it's device related and you can probably throttle the device by reducing the queue depth to avoid > the situation. > > James James, That sounds like a good idea. I will try to adjust the timeout. However, I have to ask about the "completely normal part". I can see the abort message occasionaly occurring normally if the drives always recovered after the abort. However, is it normal that the devices will go offline the second time this situation occurs? I'm afraid my knowledge of SCSI does not go to this level of detail. If it is normal, and I can substancially reduce the frequency by some tweaking I can live with that. However, if this there is a real bug I would like to get it fixed. Thanks, Jay -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
