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>