Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 Apr 1995 14:51:00 +0200
From:      se@MI.Uni-Koeln.DE (Stefan Esser)
To:        "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
Subject:   Re: Problem booting SNAP floppy on PCI/I-486SP3G
Message-ID:  <199504261251.AA26385@FileServ1.MI.Uni-Koeln.DE>
Resent-Message-ID: <199504261253.FAA22824@freefall.cdrom.com>
In-Reply-To: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> "Re: Problem booting SNAP floppy on PCI/I-486SP3G" (Apr 25, 11:10)

next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 25, 11:10, "Rodney W. Grimes" wrote:
} Subject: Re: Problem booting SNAP floppy on PCI/I-486SP3G

} > > > I looked at the BOOTFLP config file in /sys/i386/conf and found this entry
} > > > that I do not have in CATBURG.
} > > > 
} > > > options         "SCSI_NCR_MAX_SYNC=0"   #Restrict NCR to asynch. transfers
} > > > 
} > > > Could this be it?  

No, this just prevents the NCR from actively 
trying to negotiate synchronous transfers.
Requests from the drive are answered as if 
the NCR lacked sync. transfer capabilities,
and that reply is in conformance with SCSI-2.

This was introduced to the boot floppy to 
make it come up even in the case of severe 
misconfiguration or drive problems.

} > > Could be, but it worked here with the NCR810's on 4 different systems,
} > > and I am using the same disk drive you have (only more of them :-)).
} > > 
} > > Do you have anything besides the DEC3053L disk on you scsi bus now?

I've tried the SNAP install on my SP3G and
using a DEC DSP3053L. Had no problems at all.

} > : ncr0: restart (scsi reset).
} > : ncr0 scanning for targets 0..6 (V2 pl21 95/03/21)
} > : ncr0 waiting for scsi devices to settle
} > : (ncr0:0:0): "CDC 94171-9 5955" type 0 fixed SCSI 1
} > : sd0(ncr0:0:0): Direct-Access 286MB (586458 512 byte sectors)
} > : (ncr0:1:0): "MAXTOR MXT-1240S F02S" type 0 fixed SCSI 2
} > : sd1(ncr0:1:0): Direct-Access
} > : sd1(ncr0:1:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8.
} > : 1183MB (2423457 512 byte sectors)
} > : (ncr0:2:0): "MAXTOR 7245-SCSI 1057" type 0 fixed SCSI 1
} > : sd2(ncr0:2:0): Direct-Access 234MB (479656 512 byte sectors)
} > : (ncr0:3:0): "NEC CD-ROM DRIVE:500 2.5" type 5 removable SCSI 2
} 
} Can you remove this easily?  I have seen CD-ROM drives hang the
} NCR code up :-(.   And turning off the sync negotiation seems to
} make the problem worse, not better :-(.

Well, if you have seen it, then I guess you sent
the drive brand and model for us to include it into
the list of known rogues.

It won't do you any harm thereafter :)

There is a problem with some drives not accepting 
an IDENTIFY message at certain times, while most
drives require it in just this situation.
Taking the wrong choice may screw up the drive in
such a way that only a SCSI bus reset helps ...

CDROM, QIC tape and DAT manufacturers often have 
their own cost saving interpretation of the SCSI
specs. :(

} > : cd0(ncr0:3:0): CD-ROM cd present.[12571 x 2048 byte records]
} > : (ncr0:4:0): "ARCHIVE VIPER 150  21247 -011" type 1 removable SCSI 1
} > : st0(ncr0:4:0): Sequential-Access st0: Archive  Viper 150 is a known rogue
} > : density code 0x0,  drive empty
} > : (ncr0:5:0): 200ns (5 Mb/sec) offset 8.
} > : (ncr0:5:0): "IBM 0661467 G l" type 0 fixed SCSI 2
} > : sd3(ncr0:5:0): Direct-Access
} > : sd3(ncr0:5:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB
} > : sd3 could not mode sense (4). Using ficticious geometry
} 
} Ahhh.. and unplug this guy too, it seems to be a SCSI 2 device that
} does not understand a mode sense to page 4??  Very strange!

Have seen this with an IBM 400MB drive that once
lived inside an RS/6000 ... Glad we got rid of them.

} > The IBM is a new acquisition and I removed all drives but the cdrom and the
} > tape and it still didn't work.
} 
} Of all the devices we have the most problem with it is CDROM and Tape drives,
} I know this is probably painfull to remove these, but it will help to
} track down the problem.

True. But please send mail to my e-mail address
and tell about drives that didn't work with the 
NCR !

We don't have a chance to get them supported, else.
If we knew a generic solution, we were glad to 
implement it. But we didn't find any ...

} > Why the restriction?
} 
} Attempt to fix some people's system that hang during sync negotiation due
} to devices that claim to be SCSI-2 compliant, but get this part of the
} spec wrong.  Also fixes some very old SCSI-I devices that lock up if
} you try to do sync negotiation with them.  It was suppose to make it
} better, but it may infact be making things worse :-(

If it really makes things worse, then please send 
details. We are religious about this change, but 
it seemed to increase the chance of getting through 
the first phase of a system install.

Regards, STefan

-- 
 Stefan Esser				Internet:	<se@ZPR.Uni-Koeln.DE>
 Zentrum fuer Paralleles Rechnen	Tel:		+49 221 4706017
 Universitaet zu Koeln			FAX:		+49 221 4705160
 Weyertal 80
 50931 Koeln




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504261251.AA26385>