From owner-cvs-src@FreeBSD.ORG Mon May 29 20:31:55 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D9C316A77E; Mon, 29 May 2006 20:31:55 +0000 (UTC) (envelope-from mjacob@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id E585F43D72; Mon, 29 May 2006 20:31:54 +0000 (GMT) (envelope-from mjacob@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.13.6/8.13.6) with ESMTP id k4TKUeMA010755; Mon, 29 May 2006 20:30:40 GMT (envelope-from mjacob@repoman.freebsd.org) Received: (from mjacob@localhost) by repoman.freebsd.org (8.13.6/8.13.4/Submit) id k4TKUerk010754; Mon, 29 May 2006 20:30:40 GMT (envelope-from mjacob) Message-Id: <200605292030.k4TKUerk010754@repoman.freebsd.org> From: Matt Jacob Date: Mon, 29 May 2006 20:30:40 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org X-FreeBSD-CVS-Branch: HEAD Cc: Subject: cvs commit: src/sys/dev/mpt mpt_cam.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2006 20:31:56 -0000 mjacob 2006-05-29 20:30:40 UTC FreeBSD src repository Modified files: sys/dev/mpt mpt_cam.c Log: + Change some debug messages to MPT_PRT_NEGOTIATE level (so we can see the results of SPI negotiation w/o being overwhelmed with other crap). + For U320 devices, check against both Settings *and* DV flags before deciding whether we need to skip actual SPI settings for a device. + Go back to creating a 'physical disk' side of a raid/passthru bus that is limited to the number of maximum physical disks. Actually, this isn't probably *quite* right yet for one RAID volume, and if we ever end up with finding a device that supports more than one RAID volume (not likely), it probably won't quite be right either. The problem here is that the creating of this 'physical' passthru sim is just a cheap way to leverage off the CAM midlayer to do our negotiation for us on the subentities that make up a RAID volume. It almost causes more trouble than it is worth because we have to remember which side we're talking to in terms of forming commands and which target ids are real and so on. Bleah. + Skip trying to actually do SPI settings for the RAID volumes on the real side of the raid/passthru bus pair- this just confuses the issue. The underlying real physical devices will have the negotiation performed and the Raid volume will inherit the resultant settings. At the sime time, non-RAID devices can be on the same real bus, so *do* perform negotiations with them. + At the end of doing all of the settings twiddling, *ahem*, remember to go update the settings on the card itself (dunno how this got nuked). At this point, negotiations *seem* to be being done (again) correctly for both RAID volumes and their subentities. And they seem to be *mostly* now right for other non-RAID entities on the same bus (I ended up with 3 out of 8 other disks still at narror/async- haven't the slightest idea why yes). Finally, negotiations on a normal bus seem to work (again). There's still more work coming into this area, but we're in the final stretch. Revision Changes Path 1.20 +79 -74 src/sys/dev/mpt/mpt_cam.c