Original summary and original question:
> The second problem has been under investigation while I was on vacation. I
> suspect that my backup person has screwed it up royally. It appears that
the
> SCSI bus is bad, but Sun has first tried to replace the system disk. Let
us
> pray that my backups are as good as I think theyi are ...
>
> Rodney
>
> Original question:
>
> > I've got a Sparcstation 20 that is giving the following error every
couple
> of
> > minutes:
> >
> > ftpd[8872]: open_pam_conf: stat(/etc/pam.conf) failed: No such file or
> > directory
> >
> > Obviously, it's ftp related, but "/etc/pam.conf" does exist and is
readable
> > by everybody. Can anyone tell me what the system is complaining about?
> >
> > Also, right after I rebooted the system yesterday I got a bunch of SCSI
> > errors:
> >
> > Sep 7 17:17:20 nsfwsd unix: WARNING:
> > /iommu@f,e0000000/sbus@f,e0001000/espdma@f
> > ,400000/esp@f,800000 (esp0):
> > Sep 7 17:17:20 nsfwsd unix: Connected command timeout for Target 2.0
> > Sep 7 17:17:20 nsfwsd unix: WARNING:
> > /iommu@f,e0000000/sbus@f,e0001000/espdma@f
> > ,400000/esp@f,800000 (esp0):
> > Sep 7 17:17:20 nsfwsd unix: Target 2.0 reducing sync. transfer rate
> > Sep 7 17:17:20 nsfwsd unix: WARNING:
> > /iommu@f,e0000000/sbus@f,e0001000/espdma@f
> > ,400000/esp@f,800000/sd@2,0 (sd2):
> > Sep 7 17:17:20 nsfwsd unix: SCSI transport failed: reason 'timeout':
> > retryin
> > g command
> > Sep 7 17:17:20 nsfwsd unix:
> > Sep 7 17:17:20 nsfwsd unix: WARNING:
> > /iommu@f,e0000000/sbus@f,e0001000/espdma@f
> > ,400000/esp@f,800000/sd@2,0 (sd2):
> > Sep 7 17:17:20 nsfwsd unix: SCSI transport failed: reason 'reset':
> > retrying
> > command
> > Sep 7 17:17:20 nsfwsd unix:
> > Sep 7 17:17:20 nsfwsd unix: WARNING:
> > /iommu@f,e0000000/sbus@f,e0001000/espdma@f
> > ,400000/esp@f,800000/sd@4,0 (sd4):
> > Sep 7 17:17:20 nsfwsd unix: SCSI transport failed: reason 'reset':
> > retrying
> > command
> >
> > I've not seen this before. Is my disk about to die?
Since my original summary, Sun has replaced the Sparc 20 CPU board, a couple
of SCSI cables, and tried replacing another disk. The problem persists.
However, he disconnected the CDROM and 8mm tape drive (both external), and
the errors went away. He has, therefore, concluded that my SCSI chain was
too long. That might make sense except for the fact that the system had been
working as configured for several months without errors. If anybody can
suggest anything else to try, I'd be grateful.
Thanks,
Rodney
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:26 CDT