On Mon, 2013-07-01 at 16:55 -0400, Jörn Engel wrote: > On Mon, 1 July 2013 19:23:25 +0000, James Bottomley wrote: > > On Mon, 2013-07-01 at 13:44 -0400, Jörn Engel wrote: > > > If a single device is bad, don't ever do a host > > > reset. > > > > This isn't a tenable position. Sometimes a device looks bad because the > > host state for it has gone insane. At that point, the only safe action > > is a reset of the host to sane state. > > > > I could be persuaded that you should never do the transport equivalent > > of a bus reset (on non-SPI transports, at least), which is actually hard > > to do on some of the modern transports, but I don't think you can get > > away without having a host reset in the eh arsenal. > > Fair enough. Hardware being hardware and hardware bugs being hard to > fix, I see your point. > > However, we shouldn't screw the poor user who has paid a premium for a > second HBA to get some redundancy and reset both of them at the same > time. That would, you know, defeat the redundancy. ;) I don't understand what you're getting at. In a dual HBA situation, whether the second HBA is implicated or not depends on configuration and what the first HBA is doing. If it's just passively lost device state, then the second HBA should continue just fine. If the insane HBA is injecting rogue data on the bus then, in a properly isolated configuration, it shouldn't be able to affect the second HBA, but if there's some leak and it does, chances are error handling will occur on both simultaneously. I don't see any way to avoid this other than having the user buy better hardware and properly configure it. James -- 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
