Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 Dec 2004 12:57:21 -0500
From:      "Matt Emmerton" <matt@gsicomp.on.ca>
To:        "Dan Nelson" <dnelson@allantgroup.com>, "David Gilbert" <dgilbert@dclg.ca>
Cc:        freebsd-amd64@freebsd.org
Subject:   Re: isp driver not 64 bit?
Message-ID:  <00c601c4d7cf$3652ba90$1200a8c0@gsicomp.on.ca>
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>

next in thread | previous in thread | raw e-mail | index | archive | help

----- Original Message ----- 
From: "Dan Nelson" <dnelson@allantgroup.com>
To: "David Gilbert" <dgilbert@dclg.ca>
Cc: "Matt Emmerton" <matt@gsicomp.on.ca>; <freebsd-hackers@freebsd.org>;
<freebsd-list@dclg.ca>; <freebsd-amd64@freebsd.org>
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00c601c4d7cf$3652ba90$1200a8c0>