Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 9 Sep 1997 02:20:05 -0400
From:      "David S. Miller" <davem@jenolan.rutgers.edu>
To:        shirsch@ibm.net
Cc:        aic7xxx@FreeBSD.ORG, linux-kernel@vger.rutgers.edu
Subject:   Re: aic Driver problems
Message-ID:  <199709090620.CAA01705@jenolan.rutgers.edu>
In-Reply-To: <Pine.LNX.3.95.970908071936.197A-100000@air.steve.net> (shirsch@ibm.net)

next in thread | previous in thread | raw e-mail | index | archive | help
   Date: 	Mon, 8 Sep 1997 20:48:19 -0400 (EDT)
   From: "Steven N. Hirsch" <shirsch@ibm.net>

   (scsi0:-1:1) Reset device active_scb 0 
	   (targ -1/B) matching to (targ 0/B)

   Resetting Ch. B
   seq restart

   (loop back to first "Scanning.." message above & repeat forever)

   This was hastily transcibed by hand from the screen, so the formatting and
   exact wording may be a bit off.  I'm fairly confident that the identifiers
   and numbers are correct, though.

   What to do next?

The aic7xxx driver doesn't handle very well scanning a bus which has
disks which have not spun up yet.  Disks in this state act in a very
peculiar way, some of them refuse to negotiate for wide transfers or
synchronous transfers, and will instead reset or lockup the bus when
you perform this negotiation.

In the Sparc ESP scsi driver I solved this problem in a simple way,
the aic7xxx driver can do something similar.

During the initial bus scan the generic scsi code sets the "borken"
flag in the scsi device structure, after a device has been properly
probed and if needed, spun up, the borken flag is cleared.

So therefore, I defer wide/sync negotiations until that borken flag is
cleared.  I think the aic7xxx driver should do something like this as
well.  It will cure the bus scanning problems I was seeing on
UltraSparc PCI systems with a disk which did not spin up on power up.

You need to be real careful about wide/sync negotiations anyways, it
really should not be done until a full probe of the device has
occurred and you can be reasonably sure the device won't act up.

Later,
David "Sparc" Miller
davem@caip.rutgers.edu



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709090620.CAA01705>