----- Original Message ----- From: "Dan Nelson" <[EMAIL PROTECTED]> To: "David Gilbert" <[EMAIL PROTECTED]> Cc: "Matt Emmerton" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> 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 _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
