I upgraded an older EM64T server with 2 Qlogic controllers (QLA2340 FW:v3.03.27 DVR:v8.03.01-k10) to SLES 11 and when a SCSI Bus Reset (Loop Reset) is issued I get this time out where the driver ends up removing all devices (causing IO failures for mounted file systems and the like) and then rescaning to add the devices back. I verified that with the latest stable kernel (2.6.33.4) I see similar behavior (though the new kernel recovery much quicker). If I go back to an older boot disk with Red Hat EL 4 that kernel/driver will issue a reset without any issues, aka no port time out or loss of connection to the storage. I have tried similar tests on different servers connected to the same FC switch/storage as well as servers connected to different storage without seeing this behavior. output to /var/log/messages: May 14 11:18:14 goofy kernel: qla2xxx 0000:06:01.0: scsi(2:2:15): LOOP RESET ISSUED. May 14 11:18:34 goofy kernel: rport-2:0-4: blocked FC remote port time out: removing target and saving binding May 14 11:18:34 goofy kernel: sd 2:0:2:1: [sdv] Synchronizing SCSI cache May 14 11:18:34 goofy multipathd: sdv: remove path (uevent) May 14 11:19:04 goofy kernel: rport-2:0-2: blocked FC remote port time out: removing target and saving binding May 14 11:19:04 goofy kernel: rport-2:0-3: blocked FC remote port time out: removing target and saving binding May 14 11:19:14 goofy kernel: rport-2:0-6: blocked FC remote port time out: removing rport May 14 11:20:22 goofy LifeKeeper[8115]: RECOVERY class=disk event=inqfail name=3600508b300902930a83a23d1a2850036 STARTING AT: Fri May 14 11:20:22 EDT 2010 May 14 11:20:23 goofy LifeKeeper[8115]: RECOVERY class=disk event=inqfail name=3600508b300902930a83a23d1a2850036 ENDING AT: Fri May 14 11:20:23 EDT 2010 May 14 11:23:14 goofy kernel: qla2xxx 0000:06:01.0: qla2xxx_eh_bus_reset: reset succeded What is causing this time out and how can I avoid it? Eddie Williams -- 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
