On Thu, 9 Sep 2004, Geoff Keating wrote:
> On 09/09/2004, at 9:52 PM, Bruce Allen wrote:
> > The real question is 'how in the world did this get written to the
> > SMART
> > data area?'. This is not part of the user accessible 'address space'
> > of
> > the disk. However many disks DO support this command:
> > #define ATA_SMART_WRITE_THRESHOLDS 0xd7
> > and so one has to wonder if some bit of rouge kernel or userland
> > software
> > has issued this command. And NO, smartmontools does NOT issue this
> > command, ever.
> I don't think it's actually reporting what's on the disk. I believe
> that either the disk or the kernel is returning data from the wrong
> buffer (or from the right buffer, and not waiting until it's filled in,
> or processing the wrong command, or something).
Oh, OK, this makes sense. Sure, if the kernel is returning random buffer
garbage rather than the data from the disk, that would explain it. But I
don't see how the kernel would behave this way with your laptop and
differently with Cameron's since you have the same OS versions and code.
> Other versions of the output were other kinds of random data, that I
> didn't look so closely at. It's hard to tell the difference between
> random pages from memory, random pages that are in the kernel's disk
> buffers and random pages that are in the drive's disk buffers; all we
> really know is that we're getting random pages from somewhere.
> The spec for this drive doesn't say it supports D7h, but then again I
> suspect it's the kind of thing that might not be documented. There's
> no way to issue that command from userspace, and there's no constant
> for it in the SMART part of the kernel.
> I've never seen this behaviour on any of the machines I've looked at,
> but I haven't done any checking on the G3 ibooks. Those machines use a
> different ATA driver, I think (that is, different code to talk to the
> actual hardware; the SMART library is the same).
OK, that would explain why you don't see the behavior.
> If we get more reports that will hopefully help narrow it down
To me this now smells like a kernel bug. Do you agree?