From owner-freebsd-amd64@FreeBSD.ORG Wed Dec 1 18:00:09 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD53616A4CE; Wed, 1 Dec 2004 18:00:09 +0000 (GMT) Received: from skippyii.compar.com (old.compar.com [216.208.38.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E93443D31; Wed, 1 Dec 2004 18:00:09 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from hermes (CPE00062566c7bb-CM000039c69a66.cpe.net.cable.rogers.com [69.193.82.185])iB1I7BK2013418; Wed, 1 Dec 2004 13:07:12 -0500 (EST) (envelope-from matt@gsicomp.on.ca) Message-ID: <00c601c4d7cf$3652ba90$1200a8c0@gsicomp.on.ca> From: "Matt Emmerton" To: "Dan Nelson" , "David Gilbert" References: <16811.51043.987275.174410@canoe.dclg.ca> <003801c4d685$81192640$1200a8c0@gsicomp.on.ca> <16811.58127.759026.560570@canoe.dclg.ca> <20041130055611.GN5518@dan.emsphone.com> Date: Wed, 1 Dec 2004 12:57:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 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-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2004 18:00:10 -0000 ----- Original Message ----- From: "Dan Nelson" To: "David Gilbert" Cc: "Matt Emmerton" ; ; ; Sent: Tuesday, November 30, 2004 12:56 AM Subject: Re: isp driver not 64 bit? > In the last episode (Nov 29), David Gilbert said: > > 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. Does this not seem excessive to anyone? Call me naive, but shouldn't the only time we need to obtain the geometry is at initial probe time? > > 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. > > Even more interesting is their hex values: > > DEC0ADDF and DEC0ADDE, aka 0xDEADC0DE. Something's reading memory > after the kernel freed it. Which makes me wonder if one of our 'extra' cam_calc_geometry() calls is being executed from a place where it shouldn't be. -- Matt Emmerton