isp driver not 64 bit?

[Matt Emmerton]

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