Date: Fri, 22 Mar 1996 21:14:23 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: Charles Owens <owensc@enc.edu> Cc: reebsd-stable@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: -stable and NCR problems? Message-ID: <199603222014.AA02130@Sisyphos> In-Reply-To: Charles Owens <owensc@enc.edu> "Re: -stable and NCR problems?" (Mar 20, 10:04)
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 20, 10:04, Charles Owens wrote: } Subject: Re: -stable and NCR problems? } On Tue, 19 Mar 1996, Dan Polivy wrote: } } > Hey, } > } > I just got -stable working, and have had a few odd problems with my ncr0 } > PCI scsi controller...It seemed to work fine for 2.1-RELEASE...what has } > changed in the ncr driver from release->stable? I can try and give you } > more info if you need it...lemme go look in the logs.....Well, just } > seeing if anyone else has had this problem? Thanks! } } What are you seeing? I'm seeing this sorta stuff: } } Mar 17 12:59:39 dingo /kernel: ncr0:0: ERROR (0:140) (40-67-4) (8/13) @ (abc:008c0064). That's the infamous handshake timeout ... This feature seems to do more harm than good, and I'll apply the following patch to -stable (it has been in current for some time already): Index: /sys/pci/ncr.c =================================================================== RCS file: /usr/cvs/src/sys/pci/ncr.c,v retrieving revision 1.37.4.6 diff -C2 -r1.37.4.6 ncr.c *** ncr.c 1996/03/11 19:59:46 1.37.4.6 --- ncr.c 1996/03/22 20:12:58 *************** *** 4441,4445 **** OUTB (nc_stest2, EXT ); /* Extended Sreq/Sack filtering */ OUTB (nc_stest3, TE ); /* TolerANT enable */ ! OUTB (nc_stime0, 0xfb ); /* HTH = 1.6sec STO = 0.1 sec. */ /* --- 4441,4445 ---- OUTB (nc_stest2, EXT ); /* Extended Sreq/Sack filtering */ OUTB (nc_stest3, TE ); /* TolerANT enable */ ! OUTB (nc_stime0, 0x0b ); /* HTH = disabled, STO = 0.1 sec. */ /* } Should I suspect the driver, my SCSI cable/termination or something else? The handshake timeout occurs, when there has been no ACK, 1.6 seconds after a REQ. This may be caused by a lost pulse, but it may also be caused by termal recal or ECC error recovery making the drive unresponsive for such an amount of time ... Please let me know, whether the patch does help. (I'll be on a vacation, so don't expect a reply before the second week of April.) Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se <se@ZPR.Uni-Koeln.DE>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603222014.AA02130>