From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 30 03:03:52 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D48D016A4CE; Tue, 30 Nov 2004 03:03:52 +0000 (GMT) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C6A143D4C; Tue, 30 Nov 2004 03:03:52 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id 6AC0BCE6B; Mon, 29 Nov 2004 22:03:51 -0500 (EST) Received: by canoe.dclg.ca (Postfix, from userid 101) id C8056681A; Mon, 29 Nov 2004 22:03:43 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16811.58127.759026.560570@canoe.dclg.ca> Date: Mon, 29 Nov 2004 22:03:43 -0500 To: "Matt Emmerton" In-Reply-To: <003801c4d685$81192640$1200a8c0@gsicomp.on.ca> References: <16811.51043.987275.174410@canoe.dclg.ca> <003801c4d685$81192640$1200a8c0@gsicomp.on.ca> X-Mailer: VM 7.17 under 21.5 (beta17) "chayote" (+CVS-20040321) XEmacs Lucid cc: freebsd-hackers@freebsd.org cc: freebsd-list@dclg.ca cc: freebsd-amd64@freebsd.org Subject: Re: isp driver not 64 bit? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2004 03:03:53 -0000 >>>>> "Matt" == Matt Emmerton writes: Matt> You indicate that this probe is done properly. >> From what I see, cam_calc_geometry() is called *before* the device >> probe Matt> prints out the device size, so I'm unsure of how what you are Matt> describing can occur. Well... cam_calc_geometry seems to get called quite a bit. Almost everytime you touch the disk, in fact. fsck'ing a partition calls it, for instance. Console access is personally expensive (much driving, for instance), but from memory the debugging I put in cam_calc_geometry() would print before the correct output from dadone(). Your description reminds me of this --- but it's no less vexing that the output from dadone() has the correct sector and volume size and the ccg in cam_calc_geometry() has bogus data. I don't know if it's significant, but the correct numbers were: 279353684 sectors of 512 bytes The ccg structure comes up with: 3737169375 sectors of 3737169374 bytes Not entirely sensible. Interesting that they're close values. However, with different things on the stack, the values changed. Matt> Have you built & run a kernel compiled with "options CAMDEBUG" ? Matt> This may provide more insight into where things are going wrong. I put CAMDEBUG in the kernel, but it didn't seem to change the output that much. It seemed to dump the control block showing when geom tried to access the high block number --- and failed, but nothing else particularly useful. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================