After installing 2.6.9-rc2 on my PC today (x86 VIA Chipset motherboard and
Athlon XP CPU), The IDE detection during boot in probing for ide2-5 and
displaying errors, and the hard drives that it does find are telling me that
"hda: cache flushes not supported" (when they are displayed as supported
when using 2.6.9-rc1.
On Mon, Sep 13 2004, C.Y.M. wrote:
> After installing 2.6.9-rc2 on my PC today (x86 VIA Chipset motherboard and
> Athlon XP CPU), The IDE detection during boot in probing for ide2-5 and
> displaying errors, and the hard drives that it does find are telling me that
> "hda: cache flushes not supported" (when they are displayed as supported
> when using 2.6.9-rc1.
Your drive doesn't advertise FLUSH_CACHE support, the model for when we
use these commands changed between -rc1 and -rc2. This essentially means
that you have to turn off write back caching for safe operations on a
journalled drive.
Alan, I bet there are a lot of these. Maybe we should consider letting
the user manually flag support for FLUSH_CACHE, at least it is in their
hands then.
--
Jens Axboe
>
> On Mon, Sep 13 2004, C.Y.M. wrote:
> > After installing 2.6.9-rc2 on my PC today (x86 VIA Chipset
> motherboard and
> > Athlon XP CPU), The IDE detection during boot in probing
> for ide2-5 and
> > displaying errors, and the hard drives that it does find
> are telling me that
> > "hda: cache flushes not supported" (when they are displayed
> as supported
> > when using 2.6.9-rc1.
>
> Your drive doesn't advertise FLUSH_CACHE support, the model
> for when we
> use these commands changed between -rc1 and -rc2. This
> essentially means
> that you have to turn off write back caching for safe operations on a
> journalled drive.
>
> Alan, I bet there are a lot of these. Maybe we should consider letting
> the user manually flag support for FLUSH_CACHE, at least it
> is in their
> hands then.
>
> --
> Jens Axboe
>
Thanks for the explanation. I can understand that some of the older drives
will not support FLUSH_CACHE which is acceptable. On another note, since
most computers only have IDE0 and IDE1 slots, is there a way to prevent the
probe from returning errors on boot when looking for IDE2 to IDE5? Perhaps
a kernel configuration option asking how many IDE's are expected to probe
(defaulting to two)?
Best Regards,
C.Y.M.
On Tue, Sep 14 2004, C.Y.M. wrote:
>
> >
> > On Mon, Sep 13 2004, C.Y.M. wrote:
> > > After installing 2.6.9-rc2 on my PC today (x86 VIA Chipset
> > motherboard and
> > > Athlon XP CPU), The IDE detection during boot in probing
> > for ide2-5 and
> > > displaying errors, and the hard drives that it does find
> > are telling me that
> > > "hda: cache flushes not supported" (when they are displayed
> > as supported
> > > when using 2.6.9-rc1.
> >
> > Your drive doesn't advertise FLUSH_CACHE support, the model
> > for when we
> > use these commands changed between -rc1 and -rc2. This
> > essentially means
> > that you have to turn off write back caching for safe operations on a
> > journalled drive.
> >
> > Alan, I bet there are a lot of these. Maybe we should consider letting
> > the user manually flag support for FLUSH_CACHE, at least it
> > is in their
> > hands then.
> >
> > --
> > Jens Axboe
> >
>
> Thanks for the explanation. I can understand that some of the older drives
> will not support FLUSH_CACHE which is acceptable. On another note, since
They do support it, they just don't flag the support in the capability
flags. And of course some don't support it at all, you can try this on
your drives if you want to know for sure.
> most computers only have IDE0 and IDE1 slots, is there a way to prevent the
> probe from returning errors on boot when looking for IDE2 to IDE5? Perhaps
> a kernel configuration option asking how many IDE's are expected to probe
> (defaulting to two)?
It is very annoying, I agree, I don't see the need to confuse people
with this message as well. Until that is fixed, you should be able to
use ide2=noprobe etc on the boot command line.
--
Jens Axboe
On Tue, Sep 14 2004, Jens Axboe wrote:
> They do support it, they just don't flag the support in the capability
> flags. And of course some don't support it at all, you can try this on
> your drives if you want to know for sure.
Forgot to attach the code, here it is...
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <string.h>
#include <sys/ioctl.h>
#include <linux/hdreg.h>
int main(int argc, char *argv[])
{
char args[7];
int fd;
if (argc < 2) {
printf("%s: <dev>\n", argv[0]);
return 1;
}
fd = open(argv[1], O_RDONLY | O_NONBLOCK);
if (fd == -1) {
perror("open");
return 2;
}
memset(args, 0, 7);
args[0] = 0xE7;
printf("issuing FLUSH_CACHE: ");
if (ioctl(fd, HDIO_DRIVE_TASK, args) == -1)
printf("failed 0x%x/0x%x!\n", args[0], args[1]);
else
printf("worked\n");
memset(args, 0, 7);
args[0] = 0xEA;
printf("issuing FLUSH_CACHE_EXT: ");
if (ioctl(fd, HDIO_DRIVE_TASK, args) == -1)
printf("failed 0x%x/0x%x!\n", args[0], args[1]);
else
printf("worked\n");
close(fd);
return 0;
}
--
Jens Axboe
>
> Forgot to attach the code, here it is...
>
When I use your test application on the disabled drives, I get the following
results:
issuing FLUSH_CACHE: worked
issuing FLUSH_CACHE_EXT: failed 0x51/0x4!
Is FLUSH_CACHE_EXT also a requirement? Would it not be possible to just add
this test function to ide-probe.c instead of looking for what the drive may
or may not be advertising properly?
--
C.Y.M.
On Tue, Sep 14 2004, C.Y.M. wrote:
> >
> > Forgot to attach the code, here it is...
> >
>
> When I use your test application on the disabled drives, I get the following
> results:
>
> issuing FLUSH_CACHE: worked
> issuing FLUSH_CACHE_EXT: failed 0x51/0x4!
As expected - so your drive does support FLUSH_CACHE, but doesn't
advertise it.
> Is FLUSH_CACHE_EXT also a requirement? Would it not be possible to just add
No, only for drives that are bigger than what lba28 can address: 128GiB.
> this test function to ide-probe.c instead of looking for what the drive may
> or may not be advertising properly?
This is what the code used to do, but some flash cards go nuts when you
issue unknown commands to it. So we cannot do that anymore.
--
Jens Axboe
On Tue, Sep 14 2004, Alan Cox wrote:
> On Maw, 2004-09-14 at 07:06, Jens Axboe wrote:
> > Alan, I bet there are a lot of these. Maybe we should consider letting
> > the user manually flag support for FLUSH_CACHE, at least it is in their
> > hands then.
>
> You are assuming the drive supports "FLUSH_CACHE" just because it
> doesn't error it. Thats a good way to have accidents.
I've yet to see one that lies about it, if timing is to be believed.
That would be close to criminal behaviour from the vendor, imho.
> The patch I posted originally did turn wcache off for barrier if no
> flush cache support was present but had a small bug so that bit got
> dropped.
That would be fine, though.
--
Jens Axboe
On Maw, 2004-09-14 at 07:06, Jens Axboe wrote:
> Alan, I bet there are a lot of these. Maybe we should consider letting
> the user manually flag support for FLUSH_CACHE, at least it is in their
> hands then.
You are assuming the drive supports "FLUSH_CACHE" just because it
doesn't error it. Thats a good way to have accidents.
The patch I posted originally did turn wcache off for barrier if no
flush cache support was present but had a small bug so that bit got
dropped.
On Maw, 2004-09-14 at 08:15, Jens Axboe wrote:
> printf("issuing FLUSH_CACHE: ");
> if (ioctl(fd, HDIO_DRIVE_TASK, args) == -1)
> printf("failed 0x%x/0x%x!\n", args[0], args[1]);
> else
> printf("worked\n");
Drive acked the command is all that proves. Maybe its a nop, maybe it
does it, maybe like the last time someone engaged in this kind of "lets
not check" approach it erases your firmware and leaves your CD-ROM drive
defunct as the Mandrake error of the same form did.
On Tue, Sep 14 2004, Alan Cox wrote:
> On Maw, 2004-09-14 at 08:06, Jens Axboe wrote:
> > They do support it, they just don't flag the support in the capability
> > flags. And of course some don't support it at all, you can try this on
> > your drives if you want to know for sure.
>
> You have data sheets to prove this ?
Nope, good luck finding that. The only info I have is common sense
(which doesn't always apply, granted) and timing I did on the one such
drive I have here that doesn't flag support for FLUSH_CACHE but also
doesn't error the command.
--
Jens Axboe
On Tue, Sep 14 2004, Alan Cox wrote:
> On Maw, 2004-09-14 at 08:15, Jens Axboe wrote:
> > printf("issuing FLUSH_CACHE: ");
> > if (ioctl(fd, HDIO_DRIVE_TASK, args) == -1)
> > printf("failed 0x%x/0x%x!\n", args[0], args[1]);
> > else
> > printf("worked\n");
>
> Drive acked the command is all that proves. Maybe its a nop, maybe it
> does it, maybe like the last time someone engaged in this kind of "lets
> not check" approach it erases your firmware and leaves your CD-ROM drive
> defunct as the Mandrake error of the same form did.
Alan, you are sounding like a broken record :)
--
Jens Axboe
On Maw, 2004-09-14 at 08:06, Jens Axboe wrote:
> They do support it, they just don't flag the support in the capability
> flags. And of course some don't support it at all, you can try this on
> your drives if you want to know for sure.
You have data sheets to prove this ?
> It is very annoying, I agree, I don't see the need to confuse people
> with this message as well. Until that is fixed, you should be able to
> use ide2=noprobe etc on the boot command line.
This is the Probing IDE foo... That should be KERN_DEBUG or even vanish
once its had a bit of testing. No argument there
On Maw, 2004-09-14 at 12:12, Jens Axboe wrote:
> > Drive acked the command is all that proves. Maybe its a nop, maybe it
> > does it, maybe like the last time someone engaged in this kind of "lets
> > not check" approach it erases your firmware and leaves your CD-ROM drive
> > defunct as the Mandrake error of the same form did.
>
> Alan, you are sounding like a broken record :)
Thats because someone else appears incapable of listening and learning
that issuing commands that may not be safe is not a good idea. I happen
to think users should be able to expect their hardware not to go boom
I've nothing against a well documented "actually I have a cache" option
with appropriate warnings (and of course possibly a whitelist if we can
get vendors to help). But one that like hdparm does bother to note when
you may be playing with fire.
Alan
On Tue, Sep 14 2004, Alan Cox wrote:
> On Maw, 2004-09-14 at 12:12, Jens Axboe wrote:
> > > Drive acked the command is all that proves. Maybe its a nop, maybe it
> > > does it, maybe like the last time someone engaged in this kind of "lets
> > > not check" approach it erases your firmware and leaves your CD-ROM drive
> > > defunct as the Mandrake error of the same form did.
> >
> > Alan, you are sounding like a broken record :)
>
> Thats because someone else appears incapable of listening and learning
> that issuing commands that may not be safe is not a good idea. I happen
> to think users should be able to expect their hardware not to go boom
If you had actually read the mail, you'd see that this was just an
experiment to see what kind of drive he had. I'm not suggestion to add
this back to the kernel.
> I've nothing against a well documented "actually I have a cache" option
> with appropriate warnings (and of course possibly a whitelist if we can
> get vendors to help). But one that like hdparm does bother to note when
> you may be playing with fire.
You should be able to turn on support from user space, if you so wish,
if you know that the drive works.
--
Jens Axboe
On Tuesday 14 September 2004 03:15, Jens Axboe wrote:
>On Tue, Sep 14 2004, Jens Axboe wrote:
>> They do support it, they just don't flag the support in the
>> capability flags. And of course some don't support it at all, you
>> can try this on your drives if you want to know for sure.
>
>Forgot to attach the code, here it is...
Handy tool, thanks.
[...]
Running 2.6.9-rc1-mm5 ATM.
This code returns, hdd is a new 200GB WD:
[root@coyote src]# ./cache-flush-test /dev/hdd
issuing FLUSH_CACHE: worked
issuing FLUSH_CACHE_EXT: worked
And hda is an older 120GB Maxtor
[root@coyote src]# ./cache-flush-test /dev/hda
issuing FLUSH_CACHE: worked
issuing FLUSH_CACHE_EXT: failed 0x51/0x4!
Is this the real cause of my aborted journal on / 3 or 4 days ago? I
was running -rc1-mm2 at the time.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.26% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
On Maw, 2004-09-14 at 12:43, Jens Axboe wrote:
> > I've nothing against a well documented "actually I have a cache" option
> > with appropriate warnings (and of course possibly a whitelist if we can
> > get vendors to help). But one that like hdparm does bother to note when
> > you may be playing with fire.
>
> You should be able to turn on support from user space, if you so wish,
> if you know that the drive works.
No argument there at all. A whitelist would be nice also.
On Tue, Sep 14 2004, Alan Cox wrote:
> On Maw, 2004-09-14 at 12:43, Jens Axboe wrote:
> > > I've nothing against a well documented "actually I have a cache" option
> > > with appropriate warnings (and of course possibly a whitelist if we can
> > > get vendors to help). But one that like hdparm does bother to note when
> > > you may be playing with fire.
> >
> > You should be able to turn on support from user space, if you so wish,
> > if you know that the drive works.
>
> No argument there at all. A whitelist would be nice also.
Definitely. I have the first entry candidate right here ;-)
--
Jens Axboe
On Tuesday 14 September 2004 12:05, Alan Cox wrote:
> On Maw, 2004-09-14 at 07:06, Jens Axboe wrote:
> > Alan, I bet there are a lot of these. Maybe we should consider letting
> > the user manually flag support for FLUSH_CACHE, at least it is in their
> > hands then.
>
> You are assuming the drive supports "FLUSH_CACHE" just because it
> doesn't error it. Thats a good way to have accidents.
Yep.
> The patch I posted originally did turn wcache off for barrier if no
> flush cache support was present but had a small bug so that bit got
> dropped.
'small bug' was that it didn't disable wcache except one
error case (which I've never seen in the wild). 8)
Check what ioctl hdparm uses for enabling wcache
and then think about implications for disabling wcache
by default.
always cc: [email protected] on ATA stuff
On Tuesday 14 September 2004 09:03, C.Y.M. wrote:
>
> >
> > On Mon, Sep 13 2004, C.Y.M. wrote:
> > > After installing 2.6.9-rc2 on my PC today (x86 VIA Chipset
> > motherboard and
> > > Athlon XP CPU), The IDE detection during boot in probing
> > for ide2-5 and
> > > displaying errors, and the hard drives that it does find
> > are telling me that
> > > "hda: cache flushes not supported" (when they are displayed
> > as supported
> > > when using 2.6.9-rc1.
> >
> > Your drive doesn't advertise FLUSH_CACHE support, the model
> > for when we
> > use these commands changed between -rc1 and -rc2. This
> > essentially means
> > that you have to turn off write back caching for safe operations on a
> > journalled drive.
> >
> > Alan, I bet there are a lot of these. Maybe we should consider letting
> > the user manually flag support for FLUSH_CACHE, at least it
> > is in their
> > hands then.
> >
> > --
> > Jens Axboe
> >
>
> Thanks for the explanation. I can understand that some of the older drives
> will not support FLUSH_CACHE which is acceptable. On another note, since
> most computers only have IDE0 and IDE1 slots, is there a way to prevent the
> probe from returning errors on boot when looking for IDE2 to IDE5? Perhaps
errros? these are innocent KERN_DEBUG messages
> a kernel configuration option asking how many IDE's are expected to probe
> (defaulting to two)?
grep drivers/ide/Kconfig IDE_GENERIC
> Best Regards,
> C.Y.M.
On Tue, Sep 14 2004, Bartlomiej Zolnierkiewicz wrote:
> > Thanks for the explanation. I can understand that some of the older drives
> > will not support FLUSH_CACHE which is acceptable. On another note, since
> > most computers only have IDE0 and IDE1 slots, is there a way to prevent the
> > probe from returning errors on boot when looking for IDE2 to IDE5? Perhaps
>
> errros? these are innocent KERN_DEBUG messages
To a user, they look like errors.
--
Jens Axboe
Alan Cox wrote:
> On Maw, 2004-09-14 at 07:06, Jens Axboe wrote:
>
>>Alan, I bet there are a lot of these. Maybe we should consider letting
>>the user manually flag support for FLUSH_CACHE, at least it is in their
>>hands then.
>
>
> You are assuming the drive supports "FLUSH_CACHE" just because it
> doesn't error it. Thats a good way to have accidents.
>
> The patch I posted originally did turn wcache off for barrier if no
> flush cache support was present but had a small bug so that bit got
> dropped.
FWIW the libata test for checking whether it is OK to issue a flush is
return ata_id_wcache_enabled(dev) ||
ata_id_has_flush(dev) ||
ata_id_has_flush_ext(dev);
and if it passes that test,
if ((tf->flags & ATA_TFLAG_LBA48) &&
(ata_id_has_flush_ext(qc->dev)))
tf->command = ATA_CMD_FLUSH_EXT;
else
tf->command = ATA_CMD_FLUSH;
I wouldn't object to removing the "ata_id_wcache_enabled" test if people
feel that it is unsafe.
Jeff
On Tue, Sep 14 2004, Jeff Garzik wrote:
> Alan Cox wrote:
> >On Maw, 2004-09-14 at 07:06, Jens Axboe wrote:
> >
> >>Alan, I bet there are a lot of these. Maybe we should consider letting
> >>the user manually flag support for FLUSH_CACHE, at least it is in their
> >>hands then.
> >
> >
> >You are assuming the drive supports "FLUSH_CACHE" just because it
> >doesn't error it. Thats a good way to have accidents.
> >
> >The patch I posted originally did turn wcache off for barrier if no
> >flush cache support was present but had a small bug so that bit got
> >dropped.
>
>
> FWIW the libata test for checking whether it is OK to issue a flush is
>
> return ata_id_wcache_enabled(dev) ||
> ata_id_has_flush(dev) ||
> ata_id_has_flush_ext(dev);
>
> and if it passes that test,
>
> if ((tf->flags & ATA_TFLAG_LBA48) &&
> (ata_id_has_flush_ext(qc->dev)))
> tf->command = ATA_CMD_FLUSH_EXT;
> else
> tf->command = ATA_CMD_FLUSH;
>
> I wouldn't object to removing the "ata_id_wcache_enabled" test if people
> feel that it is unsafe.
Alan says it's unsafe for some of his flash cards, and I do believe they
say they have write caching enabled.
--
Jens Axboe
That all looks pretty safe to me. I wouldn't touch it.
But one could augment it with a check of the ATA revision code,
and possibly exclude drives that predate the *formal* introduction
of the FLUSH_CACHE command, unless their IDENTIFY data specifically
claims to include it.
Cheers
--
Mark Lord
(hdparm keeper & the original "Linux IDE Guy")
> Alan says it's unsafe for some of his flash cards, and I do believe they
> say they have write caching enabled.
Flash cards should be detectable --> many of them will claim
to implement the CFA feature set.
--
Mark Lord
(hdparm keeper & the original "Linux IDE Guy")
Mark Lord wrote:
> Flash cards should be detectable --> many of them will claim
> to implement the CFA feature set.
many but not all ;-)
Mark Lord wrote:
>> Alan says it's unsafe for some of his flash cards, and I do believe they
>> say they have write caching enabled.
>
> Flash cards should be detectable --> many of them will claim
> to implement the CFA feature set.
One obvious safeguard would be to never use FLUSH_CACHE on any
drive that lacks UDMA, unless the drive claims to support FLUSH_CACHE.
That will eliminate all current FLASH memory devices.
Cheers
--
Mark Lord
(hdparm keeper & the original "Linux IDE Guy")
Mark Lord wrote:
> One obvious safeguard would be to never use FLUSH_CACHE on any
> drive that lacks UDMA, unless the drive claims to support FLUSH_CACHE.
>
> That will eliminate all current FLASH memory devices.
I think you're hunting for hueristics, not making a general rule. IMO
any assumption that this behavior will always be limited to flash
devices is a shaky assumption.
Your initial suggestion is probably much better:
> But one could augment it with a check of the ATA revision code,
> and possibly exclude drives that predate the *formal* introduction
> of the FLUSH_CACHE command, unless their IDENTIFY data specifically
> claims to include it.
That implies my code would become
if (ata version < 4)
return not-supported
if (wbcache-enabled or have-flush-cache or have-flush-cache-ext)
return supported
return not-supported
Yes?
Alan, do you still feel that the "wbcache-enabled" test should be removed?
Since wbcache-enabled is more of a hueristic than a formal test, I don't
mind removing it.
Jeff
On Maw, 2004-09-14 at 16:51, Jeff Garzik wrote:
> if (ata version < 4)
> return not-supported
> if (wbcache-enabled or have-flush-cache or have-flush-cache-ext)
> return supported
> return not-supported
I like Mark's approach. Its a heuristic but it feels a sane one. What we
really need to know of course is what Redmond does because thats the
standard by order of Bill.
On Maw, 2004-09-14 at 16:25, Jens Axboe wrote:
> Alan says it's unsafe for some of his flash cards, and I do believe they
> say they have write caching enabled.
It'll crash one of the flashcards doing that and the IT8212, but neither
the flash cards nor the IT8212 are SATA so its less of a concern there.
Still wrong really though.