James Smart wrote: > Given this is the 3rd instance of this (qla2xxxx, lpfc, mpt fusion), > we should either: > > - Fix the error handler. (but we all know this is a lot of work, > of which none of us have the time to do, nor expect it to > be complete in time for our next distro delivery). I understand the bugs in the eh. I have worked around them in iscsi and tried to fix them in scsi-ml :) (still working on the queuecommand SCSI_ML_HOST/DEVICE_BUSY fix), but along with the problems in the eh where we could get the device offlined there could really be times when the device needs to be offlined and reonlined, right? For iscsi we do not really worry about either, in our userspace daemon we have code where if the device was offlined and the daemon has corrected the problem (or in qla4xxx case has been notified that the problem has been corrected), then we online the devices. Since FC, has added a netlink interface could we add something like fc_rport state changed event support to some daemom. The daemon could online the device when the rport state is back up if needed. I was also thinking that the iscsi code has some common features and maybe iscsi and fc could share something in some sort of blktool daemon. Or do you think the userspace daemon is more of hack in userspace. I cannot tell when I am hacking around something in the kernel or doing something nifty in userspace anymore :) - 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
