* Changes to ide-probe.c in 2.6.9-rc2 causing improper detection @ 2004-09-14 2:26 C.Y.M. 2004-09-14 6:06 ` Jens Axboe 0 siblings, 1 reply; 30+ messages in thread From: C.Y.M. @ 2004-09-14 2:26 UTC (permalink / raw) To: linux-kernel 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 2:26 Changes to ide-probe.c in 2.6.9-rc2 causing improper detection C.Y.M. @ 2004-09-14 6:06 ` Jens Axboe 2004-09-14 7:03 ` C.Y.M. 2004-09-14 10:05 ` Alan Cox 0 siblings, 2 replies; 30+ messages in thread From: Jens Axboe @ 2004-09-14 6:06 UTC (permalink / raw) To: C.Y.M.; +Cc: linux-kernel, Alan Cox 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 6:06 ` Jens Axboe @ 2004-09-14 7:03 ` C.Y.M. 2004-09-14 7:06 ` Jens Axboe 2004-09-14 11:59 ` Bartlomiej Zolnierkiewicz 2004-09-14 10:05 ` Alan Cox 1 sibling, 2 replies; 30+ messages in thread From: C.Y.M. @ 2004-09-14 7:03 UTC (permalink / raw) To: 'Jens Axboe'; +Cc: linux-kernel, 'Alan Cox' > > 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 7:03 ` C.Y.M. @ 2004-09-14 7:06 ` Jens Axboe 2004-09-14 7:15 ` Jens Axboe 2004-09-14 10:07 ` Alan Cox 2004-09-14 11:59 ` Bartlomiej Zolnierkiewicz 1 sibling, 2 replies; 30+ messages in thread From: Jens Axboe @ 2004-09-14 7:06 UTC (permalink / raw) To: C.Y.M.; +Cc: linux-kernel, 'Alan Cox' 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 7:06 ` Jens Axboe @ 2004-09-14 7:15 ` Jens Axboe 2004-09-14 8:20 ` C.Y.M. ` (2 more replies) 2004-09-14 10:07 ` Alan Cox 1 sibling, 3 replies; 30+ messages in thread From: Jens Axboe @ 2004-09-14 7:15 UTC (permalink / raw) To: C.Y.M.; +Cc: linux-kernel, 'Alan Cox' 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 7:15 ` Jens Axboe @ 2004-09-14 8:20 ` C.Y.M. 2004-09-14 8:28 ` Jens Axboe 2004-09-14 10:09 ` Alan Cox 2004-09-14 11:37 ` Gene Heskett 2 siblings, 1 reply; 30+ messages in thread From: C.Y.M. @ 2004-09-14 8:20 UTC (permalink / raw) To: 'Jens Axboe'; +Cc: linux-kernel, 'Alan Cox' > > 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 8:20 ` C.Y.M. @ 2004-09-14 8:28 ` Jens Axboe 0 siblings, 0 replies; 30+ messages in thread From: Jens Axboe @ 2004-09-14 8:28 UTC (permalink / raw) To: C.Y.M.; +Cc: linux-kernel, 'Alan Cox' 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 7:15 ` Jens Axboe 2004-09-14 8:20 ` C.Y.M. @ 2004-09-14 10:09 ` Alan Cox 2004-09-14 11:12 ` Jens Axboe 2004-09-14 11:37 ` Gene Heskett 2 siblings, 1 reply; 30+ messages in thread From: Alan Cox @ 2004-09-14 10:09 UTC (permalink / raw) To: Jens Axboe; +Cc: C.Y.M., Linux Kernel Mailing List 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 10:09 ` Alan Cox @ 2004-09-14 11:12 ` Jens Axboe 2004-09-14 10:35 ` Alan Cox 0 siblings, 1 reply; 30+ messages in thread From: Jens Axboe @ 2004-09-14 11:12 UTC (permalink / raw) To: Alan Cox; +Cc: C.Y.M., Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 11:12 ` Jens Axboe @ 2004-09-14 10:35 ` Alan Cox 2004-09-14 11:43 ` Jens Axboe 0 siblings, 1 reply; 30+ messages in thread From: Alan Cox @ 2004-09-14 10:35 UTC (permalink / raw) To: Jens Axboe; +Cc: C.Y.M., Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 10:35 ` Alan Cox @ 2004-09-14 11:43 ` Jens Axboe 2004-09-14 11:19 ` Alan Cox 0 siblings, 1 reply; 30+ messages in thread From: Jens Axboe @ 2004-09-14 11:43 UTC (permalink / raw) To: Alan Cox; +Cc: C.Y.M., Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 11:43 ` Jens Axboe @ 2004-09-14 11:19 ` Alan Cox 2004-09-14 12:21 ` Jens Axboe 0 siblings, 1 reply; 30+ messages in thread From: Alan Cox @ 2004-09-14 11:19 UTC (permalink / raw) To: Jens Axboe; +Cc: C.Y.M., Linux Kernel Mailing List 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 11:19 ` Alan Cox @ 2004-09-14 12:21 ` Jens Axboe 0 siblings, 0 replies; 30+ messages in thread From: Jens Axboe @ 2004-09-14 12:21 UTC (permalink / raw) To: Alan Cox; +Cc: C.Y.M., Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 7:15 ` Jens Axboe 2004-09-14 8:20 ` C.Y.M. 2004-09-14 10:09 ` Alan Cox @ 2004-09-14 11:37 ` Gene Heskett 2 siblings, 0 replies; 30+ messages in thread From: Gene Heskett @ 2004-09-14 11:37 UTC (permalink / raw) To: linux-kernel; +Cc: Jens Axboe, C.Y.M., 'Alan Cox' 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 7:06 ` Jens Axboe 2004-09-14 7:15 ` Jens Axboe @ 2004-09-14 10:07 ` Alan Cox 2004-09-14 11:11 ` Jens Axboe 1 sibling, 1 reply; 30+ messages in thread From: Alan Cox @ 2004-09-14 10:07 UTC (permalink / raw) To: Jens Axboe; +Cc: C.Y.M., Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 10:07 ` Alan Cox @ 2004-09-14 11:11 ` Jens Axboe 0 siblings, 0 replies; 30+ messages in thread From: Jens Axboe @ 2004-09-14 11:11 UTC (permalink / raw) To: Alan Cox; +Cc: C.Y.M., Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 7:03 ` C.Y.M. 2004-09-14 7:06 ` Jens Axboe @ 2004-09-14 11:59 ` Bartlomiej Zolnierkiewicz 2004-09-14 13:15 ` Jens Axboe 1 sibling, 1 reply; 30+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2004-09-14 11:59 UTC (permalink / raw) To: syphir; +Cc: 'Jens Axboe', linux-kernel, 'Alan Cox' always cc: linux-ide@vger.kernel.org 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 11:59 ` Bartlomiej Zolnierkiewicz @ 2004-09-14 13:15 ` Jens Axboe 0 siblings, 0 replies; 30+ messages in thread From: Jens Axboe @ 2004-09-14 13:15 UTC (permalink / raw) To: Bartlomiej Zolnierkiewicz; +Cc: syphir, linux-kernel, 'Alan Cox' 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 6:06 ` Jens Axboe 2004-09-14 7:03 ` C.Y.M. @ 2004-09-14 10:05 ` Alan Cox 2004-09-14 11:09 ` Jens Axboe ` (2 more replies) 1 sibling, 3 replies; 30+ messages in thread From: Alan Cox @ 2004-09-14 10:05 UTC (permalink / raw) To: Jens Axboe; +Cc: C.Y.M., Linux Kernel Mailing List 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 10:05 ` Alan Cox @ 2004-09-14 11:09 ` Jens Axboe 2004-09-14 12:07 ` Bartlomiej Zolnierkiewicz 2004-09-14 15:18 ` Jeff Garzik 2 siblings, 0 replies; 30+ messages in thread From: Jens Axboe @ 2004-09-14 11:09 UTC (permalink / raw) To: Alan Cox; +Cc: C.Y.M., Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 10:05 ` Alan Cox 2004-09-14 11:09 ` Jens Axboe @ 2004-09-14 12:07 ` Bartlomiej Zolnierkiewicz 2004-09-14 15:18 ` Jeff Garzik 2 siblings, 0 replies; 30+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2004-09-14 12:07 UTC (permalink / raw) To: Alan Cox; +Cc: Jens Axboe, C.Y.M., Linux Kernel Mailing List 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 10:05 ` Alan Cox 2004-09-14 11:09 ` Jens Axboe 2004-09-14 12:07 ` Bartlomiej Zolnierkiewicz @ 2004-09-14 15:18 ` Jeff Garzik 2004-09-14 15:25 ` Jens Axboe 2004-09-14 15:31 ` Mark Lord 2 siblings, 2 replies; 30+ messages in thread From: Jeff Garzik @ 2004-09-14 15:18 UTC (permalink / raw) To: Alan Cox; +Cc: Jens Axboe, C.Y.M., Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 15:18 ` Jeff Garzik @ 2004-09-14 15:25 ` Jens Axboe 2004-09-14 15:05 ` Alan Cox 2004-09-14 15:33 ` Mark Lord 2004-09-14 15:31 ` Mark Lord 1 sibling, 2 replies; 30+ messages in thread From: Jens Axboe @ 2004-09-14 15:25 UTC (permalink / raw) To: Jeff Garzik; +Cc: Alan Cox, C.Y.M., Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 15:25 ` Jens Axboe @ 2004-09-14 15:05 ` Alan Cox 2004-09-14 15:33 ` Mark Lord 1 sibling, 0 replies; 30+ messages in thread From: Alan Cox @ 2004-09-14 15:05 UTC (permalink / raw) To: Jens Axboe; +Cc: Jeff Garzik, C.Y.M., Linux Kernel Mailing List 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 15:25 ` Jens Axboe 2004-09-14 15:05 ` Alan Cox @ 2004-09-14 15:33 ` Mark Lord 2004-09-14 15:39 ` Mark Lord 2004-09-14 15:45 ` Jeff Garzik 1 sibling, 2 replies; 30+ messages in thread From: Mark Lord @ 2004-09-14 15:33 UTC (permalink / raw) To: Jens Axboe; +Cc: Jeff Garzik, Alan Cox, C.Y.M., Linux Kernel Mailing List > 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") ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 15:33 ` Mark Lord @ 2004-09-14 15:39 ` Mark Lord 2004-09-14 15:51 ` Jeff Garzik 2004-09-14 15:45 ` Jeff Garzik 1 sibling, 1 reply; 30+ messages in thread From: Mark Lord @ 2004-09-14 15:39 UTC (permalink / raw) To: Mark Lord Cc: Jens Axboe, Jeff Garzik, Alan Cox, C.Y.M., Linux Kernel Mailing List 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") ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 15:39 ` Mark Lord @ 2004-09-14 15:51 ` Jeff Garzik 2004-09-14 15:06 ` Alan Cox 0 siblings, 1 reply; 30+ messages in thread From: Jeff Garzik @ 2004-09-14 15:51 UTC (permalink / raw) To: Mark Lord; +Cc: Jens Axboe, Alan Cox, C.Y.M., Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 15:51 ` Jeff Garzik @ 2004-09-14 15:06 ` Alan Cox 0 siblings, 0 replies; 30+ messages in thread From: Alan Cox @ 2004-09-14 15:06 UTC (permalink / raw) To: Jeff Garzik; +Cc: Mark Lord, Jens Axboe, C.Y.M., Linux Kernel Mailing List 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 15:33 ` Mark Lord 2004-09-14 15:39 ` Mark Lord @ 2004-09-14 15:45 ` Jeff Garzik 1 sibling, 0 replies; 30+ messages in thread From: Jeff Garzik @ 2004-09-14 15:45 UTC (permalink / raw) To: Mark Lord; +Cc: Jens Axboe, Alan Cox, C.Y.M., Linux Kernel Mailing List Mark Lord wrote: > Flash cards should be detectable --> many of them will claim > to implement the CFA feature set. many but not all ;-) ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Changes to ide-probe.c in 2.6.9-rc2 causing improper detection 2004-09-14 15:18 ` Jeff Garzik 2004-09-14 15:25 ` Jens Axboe @ 2004-09-14 15:31 ` Mark Lord 1 sibling, 0 replies; 30+ messages in thread From: Mark Lord @ 2004-09-14 15:31 UTC (permalink / raw) To: Jeff Garzik; +Cc: Alan Cox, Jens Axboe, C.Y.M., Linux Kernel Mailing List 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") ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2004-09-14 16:23 UTC | newest] Thread overview: 30+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-09-14 2:26 Changes to ide-probe.c in 2.6.9-rc2 causing improper detection C.Y.M. 2004-09-14 6:06 ` Jens Axboe 2004-09-14 7:03 ` C.Y.M. 2004-09-14 7:06 ` Jens Axboe 2004-09-14 7:15 ` Jens Axboe 2004-09-14 8:20 ` C.Y.M. 2004-09-14 8:28 ` Jens Axboe 2004-09-14 10:09 ` Alan Cox 2004-09-14 11:12 ` Jens Axboe 2004-09-14 10:35 ` Alan Cox 2004-09-14 11:43 ` Jens Axboe 2004-09-14 11:19 ` Alan Cox 2004-09-14 12:21 ` Jens Axboe 2004-09-14 11:37 ` Gene Heskett 2004-09-14 10:07 ` Alan Cox 2004-09-14 11:11 ` Jens Axboe 2004-09-14 11:59 ` Bartlomiej Zolnierkiewicz 2004-09-14 13:15 ` Jens Axboe 2004-09-14 10:05 ` Alan Cox 2004-09-14 11:09 ` Jens Axboe 2004-09-14 12:07 ` Bartlomiej Zolnierkiewicz 2004-09-14 15:18 ` Jeff Garzik 2004-09-14 15:25 ` Jens Axboe 2004-09-14 15:05 ` Alan Cox 2004-09-14 15:33 ` Mark Lord 2004-09-14 15:39 ` Mark Lord 2004-09-14 15:51 ` Jeff Garzik 2004-09-14 15:06 ` Alan Cox 2004-09-14 15:45 ` Jeff Garzik 2004-09-14 15:31 ` Mark Lord
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox