Bug 22862

Summary: ncr probe fails with CACHE TEST FAILED: ? write ? read
Product: Base System Reporter: David Muir Sharnoff <muir>
Component: kernAssignee: freebsd-scsi (Nobody) <scsi>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.2-STABLE   
Hardware: Any   
OS: Any   

Description David Muir Sharnoff 2000-11-15 09:30:01 UTC 
	I tried to upgrade to the latest -STABLE.  That happens to
	be 4.2-BETA.  My scsi controller no longer probes.  Big 
	problem.

	It fails with a message like:

		ncr0: CACHE TEST FAILED: ? write 1 ? read 2 

		or maybe write 2 read 1.

	Sorry my notes aren't perfect.

Fix: 

I'm compiling a kernel with the 4.0 version of ncr.c in 
	the hopes that it will work.   That's a short-term fix
	though.
How-To-Repeat: 
	Try to boot 4.2-BETA on my home system.  Sigh.
Comment 1 David Muir Sharnoff 2000-11-15 09:35:47 UTC 
The 4.0 version of ncr.c worked.  I'm very glad my setup allowed
me to fix the problem rather than reinstalling!
Comment 2 Sheldon Hearn 2000-11-15 12:41:04 UTC 
On Wed, 15 Nov 2000 01:27:16 PST, muir@idiom.com wrote:

> 	I tried to upgrade to the latest -STABLE.  That happens to
> 	be 4.2-BETA.  My scsi controller no longer probes.  Big 
> 	problem.

If this isn't a hardware problem, I'd recommend switching to the sym(4)
driver, which recently grew support for almost all the hardware
previously supported by the ncr(4) driver.

Ciao,
Sheldon.
Comment 3 groudier 2000-11-15 19:50:49 UTC 
The CACHE TEST in `ncr' tries to detect a possible misconfiguration as
cacheable of the chip's MMIO window. It may also display a failure
message, if the MMIO address is just wrong, for example. When it fails
(that is, when it succeeds detecting a problem :-) ), then MMIO does not
work at all for the chip, and not attaching the device is the only
reasonnable behaviour. The `sym' driver uses the exact same test,
inherited from `ncr', and in my opinion, will likely succeeds such a
failure detection :) in the same situation with exactly the same message.

My first idea is that, either the driver is hitting a wrong MMIO window
for some reason, or the MMIO window has been set cacheable for some other
reason :). In the latter case, it could be some driver or some other part
that changed a MTRR, for example, or that made cacheable the page entry
that maps the chip's MMIO window.

  G=E9rard.
Comment 4 Matt Jacob freebsd_committer freebsd_triage 2001-10-02 05:55:32 UTC 
State Changed
From-To: open->feedback

Is this still broken for you? Is it broken with the sym driver?
Comment 5 David Muir Sharnoff 2001-10-26 10:07:32 UTC 
This problem is not fixed as of 4.4-STABLE Oct 25, 2001.
It is not fixed even when using the build option

options         SYM_SETUP_LP_PROBE_MAP=0x40
Comment 6 Giorgos Keramidas freebsd_committer freebsd_triage 2002-12-17 14:27:18 UTC 
State Changed
From-To: feedback->open

Followup from indicates this is still a problem.
Comment 7 Mark Linimon freebsd_committer freebsd_triage 2004-08-26 21:05:34 UTC 
Responsible Changed
From-To: freebsd-bugs->freebsd-scsi

Is this still a problem with modern versions of FreeBSD?
Comment 8 Mark Linimon freebsd_committer freebsd_triage 2004-08-26 21:06:08 UTC 
State Changed
From-To: open->feedback

Is this still a problem with modern versions of FreeBSD?
Comment 9 Mark Linimon freebsd_committer freebsd_triage 2004-08-26 22:58:59 UTC 
State Changed
From-To: feedback->closed

Submitter no longer can duplicate the problem.