Date: Wed, 18 Dec 1996 03:30:01 -0800 (PST) From: se@freebsd.org (Stefan Esser) To: freebsd-bugs Subject: Re: kern/2240: ncr53c810 crashing Message-ID: <199612181130.DAA00598@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/2240; it has been noted by GNATS.
From: se@freebsd.org (Stefan Esser)
To: bogdanr@adelaide.on.net
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: kern/2240: ncr53c810 crashing
Date: Wed, 18 Dec 1996 11:37:43 +0100
On Dec 17, bogdanr@adelaide.on.net wrote:
> starndard 2.1.5-RELEASE (GENERIC and customised kernels)
> Dell Omniplex 590 with on-board pci ncr53c810 scsi host
> and seagate 2gb fast scsi 2 hard disk
> >Description:
> i have a dell omniplex 590 which has the ncr53c810 built-in
> on the motherboard and there is only 1 scsi device attached to it (a
> hard disk)... all is terminated properly (i am 100% sure!) and works
> without any problems under windows nt...
>
> frequently (about every 10-30mins when running X11) my system crashes.
> following are some of the error messages i get on my console:
>
>
> sd0(ncr0:0:0): FASt SCSI-2 100ns (10mb/s) offset 8
>
> ncr0: restart (ncr dead ?)
> /kernel ncr0: restart (ncr dead ?)
>
> /kernel: script cmd = 88030000
>
> ncr0:0 error (81:0) (8-a2-0) (0/13) @ (ffd1002c:00000000)
> reg: ca 00 40 13 47 00 00 1f 71 08 00 a2 80 00 0a 02
Did your system ever run correctly with the NCR driver ?
The error code indicates an illegal instruction had been
fetched by the NCR.
I've got no idea, what kind of chip set the Dell uses, but
it may be broken in some way. (This happened with early
i486 chip sets, but the Intel Triton and newer seem OK.)
Having Win/NT running on the same hardware is no proof of
it working correctly, for two reasons:
1) Win/NT may know about the chip sets deficiency, and
may just disable some performance option
2) The BSD NCR driver is unique in that it has the NCR
running as an independent CPU, which communicates
with the host CPU through a job queue and shared
memory variables. This is quite different from other
NCR drivers, which have the CPU set the NCR program
counter to the begin of a very short code fragment
(often less than 10 instructions), and have the NCR
interrupt the host CPU when it finishes with them.
I'm not absolutely sure, but it looks like the NCR got
an all zero value when trying to fetch an instruction.
This is no valid op-code, and it was correct to abort
the running command at that point.
This is a hardware problem, which may be resolved by
going to slower DRAM timing, or perhaps (on chip sets
that are older than a year) by disabling some of the
PCI performance options (write buffers, burst mode)
of the chip set.
There is not much that I could do about this ...
Regards, STefan
with a very small multi
tasking code. This increases the degree of parallelism
between host CPU and NCR, and
> ncr0: restart (fatal error).
>
> sd0(ncr0:0:0): COMMAND FAILED (9 ff) @ f1243400.
> sd0(ncr0:0:0): COMMAND FAILED (9 ff) @ f1243a00.
> sd0(ncr0:0:0): COMMAND FAILED (9 ff) @ f1243c00.
>
> vnode_pager_input: I/O read error
> vm_fault: pager input (probably hardware) error, PID 599 failure
>
>
> ...the messages repeat each other with slightly different values, many
> many times... after this happens usually my system does not lock up, however
> the disk and/or scsi host are no longer functioning...
> after i reboot all is well, until the problem happens again...
>
> >How-To-Repeat:
> use the system under heavy disk loads...
> espesially running X11 and installing a package like emacs
>
> >Fix:
>
> >Audit-Trail:
> >Unformatted:
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612181130.DAA00598>