PROBLEM: (88231) (PATCH ID: OSF520-136) ******** Frequent SCSI bus resets on a KZPCA HBA may cause the following panic: PANIC: "sc ws remove: SZ_IN_USE NOT set" with the following typical stack trace: crash> tf > 0 boot src/kernel/arch/alpha/machdep.c : 2644 1 panic src/kernel/bsd/subr_prf.c : 1401 2 ss_finish(SIM_WS *sws) src/kernel/io/cam/sim_sched.c : 1493 3 sm_bus_free(SIM_WS *sws) src/kernel/io/cam/sim_sm.c : 616 4 itpsa_cfgAsStart(CCB_SCSIIO *ccb_scsiio) src/kernel/io/cam/iti/itpsacfg.c : 1840 5 itpsa_asStart src/kernel/io/cam/iti/itpsa.c : 5901 6 itpsa_procIntr src/kernel/io/cam/iti/itpsa.c : 2792 7 itpsaintr src/kernel/io/cam/iti/itpsa.c : 2914 8 _XentInt src/kernel/arch/alpha/locore.s : 1586 PROBLEM: (GB_G02141) (PATCH ID: OSF520-162) ******** This patch fixes a kernel memory fault panic after an "ITPSA: itpsa_action - error converting path ID to ITPSA softc structure" message. This is caused because the error logger tries to use a pointer to a data structure which is not valid. PROBLEM: (91878) (PATCH ID: OSF520-422) ******** This patch adds the capability for KZPCA devices to work with SCSI devices that only support asynchronous data transfers. Typically this problem with data transfer negotiation happens during boot and results in certain SCSI devices not being available after OS boot has completed. ie- these SCSI devices would be seen at console level but not under Tru64 and there would be console error messages related to these deveices during boot. Previously during data transfer negotiations, the KZPCA would issue a MESSAGE REJECT message when it received a SYNCHRONOUS DATA TRANSFER REQUEST message with REQ/ACK offset set to zero from a target. However this is a valid SCSI transaction indicating that the target does not support synchronous data transfers with the implied agreement that data transfer mode should be set to asynchronous mode. PROBLEM: (94632) (PATCH ID: OSF520-713) ******** Kernel memory fault seen at boot time with the following messages and stack trace: ITPSA: can't allocate script memory trap: invalid memory read access from kernel mode crash> tf > 0 stop_secondary_cpu src/kernel/arch/alpha/cpu.c : 1394 1 panic src/kernel/bsd/subr_prf.c : 1320 2 event_timeout src/kernel/arch/alpha/cpu.c : 2341 3 printf src/kernel/bsd/subr_prf.c : 1004 4 panic src/kernel/bsd/subr_prf.c : 1378 5 trap src/kernel/arch/alpha/trap.c : 2285 6 _XentMM src/kernel/arch/alpha/locore.s : 2219 7 itpsa_newReq src/kernel/io/cam/iti/itpsa.c : 4279 PROBLEM: (GB_G04640) (PATCH ID: OSF520-712) ******** Under certain type of tape errors, the SDLT tape drive sends SCSI messages to the KZPCA adapter which, while still compliant with the SCSI signalling specifications, are semantically wrong. This causes the adapter to suspend the SCSI bus for 30+ seconds and reset the bus. The fix in this patch kit prevents the bus suspension and reset, which is disruptive, from happening and enables the recovery of the source of error from the tape drive. SCSI trace shows 546329 299_880 Bus Free 546330 3_300 Arb 546331 2_236 Arbwin 7 546332 0_932 +Select 7,1 546333 0_952 +Sel/Resel End 546334 3_952 +MsgOut C0 Identify 546335 11_652 CMD - Write(6) <-- KZPCA sends a write to the tape 0A 00 00 0F CE 00 546336 4_668 MsgIn 02 Save Data Ptr 04 Disconnect <-- tape disconnects to complete the operation 546337 72.984_698_496 Bus Free 546338 2_428 Arb 546339 1_364 Arbwin 1 546340 1_232 Resel 7,1 <-- tape reconnects 546341 0_492 Sel/Resel End 546342 37.835_845_308 MsgIn 80 Identify 02 Save Data Ptr <<< tape sends a SDP message ! 04 Disconnect 546343 92_568 Bus Reset <-- KZPCA resets bus after 37 seconds 546344 21_993_576 Bus Free Proble: tape reconnects, sends and identify then a Save data pointer (SDP) message. The KZPCA driver is not expecting the SDP message at this point since it does not make any sense. The code falls into the default handler which hangs the bus. The bus eventually gets reset. PROBLEM: (none) (PATCH ID: OSF520-1091) ******** This patch fixes a window where I/Os for a given SCSI target can be created while the target is in the process of negotiating its synchronous parameters. This can cause the IO to pick up asynchronous connection parameters to a target which we negotiate for synchronous connection. This can result in failure to access the target device and generation of "HTH error" messages.