> I have a dual pentium Pro machine with 2 SCSI controllers (one TekRam
> 390U that has a DAT tape drive on it and a CDROM, and the other TekRam
> 390F that has 2 narrow barracudas and 1 wide barracuda on it), running
> RedHat 5.1 with updates. I upgraded the linux kernel 1.0.5 (with the
> 2.5f version of the SCSI drivers for NCR53C8XX) to 1.0.8 (version 3.0e
> of the SCSI drivers) with the Alan Cox patches applied. Whenever my
> nightly scripts try to do a dump, they first do a:
>
> st -f /dev/nst0 rewind
>
> The SCSI controller spits out the following message to the syslog:
>
> Jul 12 03:04:11 tiktok kernel: SCSI host 0 abort (pid 34805) timed out - resetting
The SCSI tape driver timeout is by default 900 seconds.
Is it enough to rewind the tape ? (I guess yes).
Driver 3.0e reads the NVRAM by default. If you did'nt enable this
feature in 2.1.105, then the NVRAM setup may have changed the
device configuration assumed by the driver. The driver will ignore
the NVRAM if you enter the following option at boot up.
ncr53c8xx=nvram:n
Could you check that the controller setup in the NVRAM has SCSI
disconnection enabled for all devices.
> Jul 12 03:04:11 tiktok kernel: SCSI bus is being reset for host 0 channel 0.
> Jul 12 03:04:11 tiktok kernel: ncr53c8xx_reset: pid=34805 reset_flags=2 serial_number=382045 serial_number_at_timeout=382045
> Jul 12 03:04:11 tiktok kernel: ncr53c875-0: restart (scsi reset).
> Jul 12 03:04:11 tiktok kernel: ncr53c875-0: Downloading SCSI SCRIPTS.
> Jul 12 03:04:11 tiktok kernel: ncr53c875-0-<2,0>: phase change 6-7 6@0764acc8 resid=4.
This is another story. Target 2 (DAT?) seems to dislike the negotiation
message after the reset without having actually read it. Could be in
some initialization process since the timestamps indicates that there is
no delay between the SCSI reset and the next command.
> Jul 12 03:04:11 tiktok kernel: ncr53c875-0-<2,*>: asynchronous.
>
> and then the mt process hangs (which of course hangs the rest of the
> dump script).
Could you send me the kernel messages printed out at boot-up and _all_
the messages printed by the SCSI layer when the problem occured.
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html