Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!goanna.cs.rmit.edu.au!aggedor.rmit.EDU.AU!harbinger.cc.monash.edu.au!msunews!uwm.edu!math.ohio-state.edu!jussieu.fr!univ-lyon1.fr!swidir.switch.ch!scsing.switch.ch!news.dfn.de!rrz.uni-koeln.de!RRZ.Uni-Koeln.DE!RRZ.Uni-Koeln.DE!news From: se@fileserv1.MI.Uni-Koeln.DE (Stefan Esser) Newsgroups: comp.os.386bsd.questions Subject: Re: NCR 53C810 SCSI problem.... Date: 6 Jan 1995 22:41:23 GMT Organization: Institute for Mathematics, University of Cologne, Germany Lines: 80 Distribution: world Message-ID: <3ekgujINN23nn@rs1.rrz.Uni-Koeln.DE> References: <3edfbd$d25@ibridge.iohk.com> NNTP-Posting-Host: fileserv1.mi.uni-koeln.de In article <3edfbd$d25@ibridge.iohk.com>, jvong@igate.iohk.com (Jeffrey Vong) writes: |> |> I got a ASUS PVI-486AP with 486DX2-66 and 16M ram. |> |> When I boot up the machine with the boot disk, I got a message like that |> |> CACHE test : failed ...... host write -1 |> CACHE test : failed ..... ncr write -1 |> .... etc Yes. True. The ASUS PVI-486AP is the only PCI board we know about, that definitely doesn't like the NCR 53c810 driver (or is it the other way around ?). Is it possible to send me the full message ? (I.e. all values written and read back, and who wrote and who read them. E.g. "CPU 1 NCR 0, ...") |> The the system can't detact any scsi drive nor any partations whatsoever. No, after failing the cache test, the system doesn't initialize the NCR chip at all. |> By the way the SCSI card and all the SCSI devices are test okay with DOS |> and as a NOVELL server. The jummper setting and the terminators on the |> cables are tested okay as well. Yes. The DOS and NOVELL drivers don't try to make best use of the NCR. The NCR is in fact a small CPU with SCSI support features, but it can be used in a dumb mode where only one command is executed by that CPU at a time, and then the status read back by the 486. The BSD driver has the NCR work as an independent CPU, that checks a shared memory region for new commands and writes back the status after the command has completed. Now there is a problem, if the shared memory isn't seen coherently by the 486 and the NCR. This is usually the result of a buggy cache implementation, which is not uncommon on PC motherboards that try to reduce cost at any price ... The cache test consists of memory writes and reads by the 486 and NCR. If either one doesn't immediately see the values written by the other one, or if the cache writes back outdated values (because it lacks a dirty tag RAM), this will show up as test failures. The ASUS PVI uses the Aries chip set, and that chip set is capable of driving a write back second level cache. If you can set the cache to write through, I'd like to know the difference. (The CACHE test messages, and the behaviour of the system with the cache test disabled, if neccessary). We can try to debug this, but it will require kernel compiles, and it would be easier if you had a system to build test kernels on. (We don't have any ASUS PVI system here, and I don't want to buy one for obvious reasons.) Regards, STefan -- Stefan Esser Internet: <se@ZPR.Uni-Koeln.DE> Zentrum fuer Paralleles Rechnen Tel: +49 221 4706010 Universitaet zu Koeln FAX: +49 221 4705160 Weyertal 80 50931 Koeln