* Re: 2.6.6-mm5
2004-05-22 8:36 2.6.6-mm5 Andrew Morton
@ 2004-05-22 9:09 ` Jeff Garzik
2004-05-22 9:22 ` 2.6.6-mm5 hch
2004-05-22 11:51 ` 2.6.6-mm5 R. J. Wysocki
2004-05-22 9:26 ` 2.6.6-mm5 hch
` (8 subsequent siblings)
9 siblings, 2 replies; 29+ messages in thread
From: Jeff Garzik @ 2004-05-22 9:09 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, SCSI Mailing List
Andrew Morton wrote:
> - Added a new SATA RAID driver from 3ware. From a quick peek it seem to
> need a little work yet.
It's not too bad... but it looks more like a 2.2 driver forward ported
to 2.4, than a 2.6.x driver. Needs some luvin' from the 2.6 scsi api crew.
Overall, it appears to be a message-based firmware engine like
drivers/block/carmel.c, that hides the SATA details in the firmware.
Jeff
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: 2.6.6-mm5
2004-05-22 9:09 ` 2.6.6-mm5 Jeff Garzik
@ 2004-05-22 9:22 ` hch
2004-05-22 9:26 ` 2.6.6-mm5 Andrew Morton
2004-05-22 11:51 ` 2.6.6-mm5 R. J. Wysocki
1 sibling, 1 reply; 29+ messages in thread
From: hch @ 2004-05-22 9:22 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Andrew Morton, linux-kernel, SCSI Mailing List
On Sat, May 22, 2004 at 05:09:59AM -0400, Jeff Garzik wrote:
> Andrew Morton wrote:
> >- Added a new SATA RAID driver from 3ware. From a quick peek it seem to
> > need a little work yet.
>
>
> It's not too bad... but it looks more like a 2.2 driver forward ported
> to 2.4, than a 2.6.x driver. Needs some luvin' from the 2.6 scsi api crew.
>
> Overall, it appears to be a message-based firmware engine like
> drivers/block/carmel.c, that hides the SATA details in the firmware.
In addition driver submission should always go through linux-scsi. Please
tell them to submit it to linux-scsi so we can have a public review process
there.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 9:22 ` 2.6.6-mm5 hch
@ 2004-05-22 9:26 ` Andrew Morton
0 siblings, 0 replies; 29+ messages in thread
From: Andrew Morton @ 2004-05-22 9:26 UTC (permalink / raw)
To: hch; +Cc: jgarzik, linux-kernel, linux-scsi
hch@infradead.org wrote:
>
> On Sat, May 22, 2004 at 05:09:59AM -0400, Jeff Garzik wrote:
> > Andrew Morton wrote:
> > >- Added a new SATA RAID driver from 3ware. From a quick peek it seem to
> > > need a little work yet.
> >
> >
> > It's not too bad... but it looks more like a 2.2 driver forward ported
> > to 2.4, than a 2.6.x driver. Needs some luvin' from the 2.6 scsi api crew.
> >
> > Overall, it appears to be a message-based firmware engine like
> > drivers/block/carmel.c, that hides the SATA details in the firmware.
>
> In addition driver submission should always go through linux-scsi. Please
> tell them to submit it to linux-scsi so we can have a public review process
> there.
Adam did attempt to cc linux-scsi but at 140kbytes the email probably got
spat out.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 9:09 ` 2.6.6-mm5 Jeff Garzik
2004-05-22 9:22 ` 2.6.6-mm5 hch
@ 2004-05-22 11:51 ` R. J. Wysocki
1 sibling, 0 replies; 29+ messages in thread
From: R. J. Wysocki @ 2004-05-22 11:51 UTC (permalink / raw)
To: Jeff Garzik, Andrew Morton; +Cc: linux-kernel, SCSI Mailing List
On Saturday 22 of May 2004 11:09, Jeff Garzik wrote:
> Andrew Morton wrote:
> > - Added a new SATA RAID driver from 3ware. From a quick peek it seem to
> > need a little work yet.
>
> It's not too bad... but it looks more like a 2.2 driver forward ported
> to 2.4, than a 2.6.x driver. Needs some luvin' from the 2.6 scsi api crew.
>
> Overall, it appears to be a message-based firmware engine like
> drivers/block/carmel.c, that hides the SATA details in the firmware.
BTW, which 3ware driver would you suggest to use with the 2.6.x now? I'm
going to install such a controller in my box ...
RJW
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 8:36 2.6.6-mm5 Andrew Morton
2004-05-22 9:09 ` 2.6.6-mm5 Jeff Garzik
@ 2004-05-22 9:26 ` hch
2004-05-22 9:32 ` 2.6.6-mm5 Andrew Morton
2004-05-22 9:38 ` 2.6.6-mm5 hch
` (7 subsequent siblings)
9 siblings, 1 reply; 29+ messages in thread
From: hch @ 2004-05-22 9:26 UTC (permalink / raw)
To: Andrew Morton, brking; +Cc: linux-kernel
> +ipr-ppc64-depends.patch
>
> Make ipr.c depend on PPC
>> Makes ipr depend on CONFIG_PPC since this driver is unique to PPC hardware.
>>
>> (It actually builds OK on x86, but it heavily uses anonymous unions, which
>> breaks on gcc-2.95)
I use gcc-2.95 happily on ppc. Better thing is to either fix it up not to
use anonymous unions (which is a pitty because that feature helps making
code more readable sometimes) or stick a
#if (__GNUC__ < 3)
# error "This driver requires GCC 3.x"
#endif
ontop of the driver so people know why it fails at least.
Still wondering why these fixes don't go trhough linux-scsi..
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: 2.6.6-mm5
2004-05-22 9:26 ` 2.6.6-mm5 hch
@ 2004-05-22 9:32 ` Andrew Morton
2004-05-22 9:41 ` 2.6.6-mm5 hch
0 siblings, 1 reply; 29+ messages in thread
From: Andrew Morton @ 2004-05-22 9:32 UTC (permalink / raw)
To: hch; +Cc: brking, linux-kernel
hch@infradead.org wrote:
>
> > +ipr-ppc64-depends.patch
> >
> > Make ipr.c depend on PPC
>
> >> Makes ipr depend on CONFIG_PPC since this driver is unique to PPC hardware.
> >>
> >> (It actually builds OK on x86, but it heavily uses anonymous unions, which
> >> breaks on gcc-2.95)
>
> I use gcc-2.95 happily on ppc. Better thing is to either fix it up not to
> use anonymous unions (which is a pitty because that feature helps making
> code more readable sometimes) or stick a
It uses a *ton* of anonymous unions.
> #if (__GNUC__ < 3)
> # error "This driver requires GCC 3.x"
> #endif
That breaks allfooconfig.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 9:32 ` 2.6.6-mm5 Andrew Morton
@ 2004-05-22 9:41 ` hch
2004-05-22 19:03 ` 2.6.6-mm5 Brian King
0 siblings, 1 reply; 29+ messages in thread
From: hch @ 2004-05-22 9:41 UTC (permalink / raw)
To: Andrew Morton; +Cc: brking, linux-kernel
On Sat, May 22, 2004 at 02:32:18AM -0700, Andrew Morton wrote:
> > code more readable sometimes) or stick a
>
> It uses a *ton* of anonymous unions.
>
> > #if (__GNUC__ < 3)
> > # error "This driver requires GCC 3.x"
> > #endif
>
> That breaks allfooconfig.
Well, the patch currently in -mm also breaks allmodconfig. Just not on
your arch or with a recent enough compiler, while with this it'll break
an all arches unless you have a recent enough compiler. And give the
driver isn't actually ppc specific that sounds like a really bad tradeoff.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 9:41 ` 2.6.6-mm5 hch
@ 2004-05-22 19:03 ` Brian King
0 siblings, 0 replies; 29+ messages in thread
From: Brian King @ 2004-05-22 19:03 UTC (permalink / raw)
To: hch; +Cc: Andrew Morton, linux-kernel
hch@infradead.org wrote:
> On Sat, May 22, 2004 at 02:32:18AM -0700, Andrew Morton wrote:
>
>>>code more readable sometimes) or stick a
>>
>>It uses a *ton* of anonymous unions.
>>
>>
>>>#if (__GNUC__ < 3)
>>># error "This driver requires GCC 3.x"
>>>#endif
>>
>>That breaks allfooconfig.
>
>
> Well, the patch currently in -mm also breaks allmodconfig. Just not on
> your arch or with a recent enough compiler, while with this it'll break
> an all arches unless you have a recent enough compiler. And give the
> driver isn't actually ppc specific that sounds like a really bad tradeoff.
I'll pull out the anonymous unions and submit to linux-scsi.
--
Brian King
eServer Storage I/O
IBM Linux Technology Center
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 8:36 2.6.6-mm5 Andrew Morton
2004-05-22 9:09 ` 2.6.6-mm5 Jeff Garzik
2004-05-22 9:26 ` 2.6.6-mm5 hch
@ 2004-05-22 9:38 ` hch
2004-05-22 9:44 ` 2.6.6-mm5 Jens Axboe
2004-05-22 9:46 ` 2.6.6-mm5 Felipe Alfaro Solana
` (6 subsequent siblings)
9 siblings, 1 reply; 29+ messages in thread
From: hch @ 2004-05-22 9:38 UTC (permalink / raw)
To: Andrew Morton, axboe; +Cc: linux-kernel
> +disk-barrier-core.patch
> +disk-barrier-core-tweaks.patch
> +disk-barrier-ide.patch
> +disk-barrier-ide-symbol-expoprt.patch
> +disk-barrier-ide-warning-fix.patch
> +disk-barrier-scsi.patch
>
> Support for IDE and SCSI barriers
>
> +disk-barrier-dm.patch
> +disk-barrier-md.patch
>
> Via device mapper and raid as well.
Some comments on the API and the SCSI part:
- issue_flush_fn prototype choice is bad, the request_queue_t argument
wile always be disk->queue so it's not needed and only causes
confusion.
- issue_flush sounds a little strange to me, what about cache_flush
or sync_cache instead?
- scsi_drive.issue_flush should take a scsi_device * as first parameter,
not struct device * - makes life for bother caller and callee easier.
- should probably add a small helper to get the scsi_driver from the
gendisk instead of duplicating the code, ala:
static inline struct scsi_driver *scsi_disk_driver(struct gendisk *disk)
{
return *(struct scsi_driver **) disk->private_data;
}
- the WCE check should move into sd_sync_cache
- NULL scsi_disk can't happen for sd_issue_flush, no need to check,
and thus the disctinction of sd_issue_flush vs sd_sync_cache can
go and sd_shutdown can simply call the cache flush method.
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: 2.6.6-mm5
2004-05-22 9:38 ` 2.6.6-mm5 hch
@ 2004-05-22 9:44 ` Jens Axboe
0 siblings, 0 replies; 29+ messages in thread
From: Jens Axboe @ 2004-05-22 9:44 UTC (permalink / raw)
To: hch, Andrew Morton, linux-kernel
On Sat, May 22 2004, hch@infradead.org wrote:
> > +disk-barrier-core.patch
> > +disk-barrier-core-tweaks.patch
> > +disk-barrier-ide.patch
> > +disk-barrier-ide-symbol-expoprt.patch
> > +disk-barrier-ide-warning-fix.patch
> > +disk-barrier-scsi.patch
> >
> > Support for IDE and SCSI barriers
> >
> > +disk-barrier-dm.patch
> > +disk-barrier-md.patch
> >
> > Via device mapper and raid as well.
>
> Some comments on the API and the SCSI part:
>
> - issue_flush_fn prototype choice is bad, the request_queue_t argument
> wile always be disk->queue so it's not needed and only causes
> confusion.
Agree, it's mutated into place which is probably the reason for the
dupe.
> - issue_flush sounds a little strange to me, what about cache_flush
> or sync_cache instead?
Fine with me, I'm notoriously bad at naming.
> - scsi_drive.issue_flush should take a scsi_device * as first parameter,
> not struct device * - makes life for bother caller and callee easier.
> - should probably add a small helper to get the scsi_driver from the
> gendisk instead of duplicating the code, ala:
>
> static inline struct scsi_driver *scsi_disk_driver(struct gendisk *disk)
> {
> return *(struct scsi_driver **) disk->private_data;
> }
Fine too.
> - the WCE check should move into sd_sync_cache
Ditto
> - NULL scsi_disk can't happen for sd_issue_flush, no need to check,
> and thus the disctinction of sd_issue_flush vs sd_sync_cache can
> go and sd_shutdown can simply call the cache flush method.
Neat, thanks.
Thanks for the review Christoph!
--
Jens Axboe
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 8:36 2.6.6-mm5 Andrew Morton
` (2 preceding siblings ...)
2004-05-22 9:38 ` 2.6.6-mm5 hch
@ 2004-05-22 9:46 ` Felipe Alfaro Solana
2004-05-23 15:51 ` 2.6.6-mm5 James Morris
2004-05-22 11:59 ` 2.6.6-mm5 Matthias Andree
` (5 subsequent siblings)
9 siblings, 1 reply; 29+ messages in thread
From: Felipe Alfaro Solana @ 2004-05-22 9:46 UTC (permalink / raw)
To: Andrew Morton; +Cc: Kernel Mailinglist
On Sat, 2004-05-22 at 10:36, Andrew Morton wrote:
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/
>
Will you included the i586-optimized AES patch from Fruhwirth Clemens to
the -mm tree? I find this patch really interesting, as it boost IPSec
ESP AES considerably.
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: 2.6.6-mm5
2004-05-22 9:46 ` 2.6.6-mm5 Felipe Alfaro Solana
@ 2004-05-23 15:51 ` James Morris
0 siblings, 0 replies; 29+ messages in thread
From: James Morris @ 2004-05-23 15:51 UTC (permalink / raw)
To: Felipe Alfaro Solana; +Cc: Andrew Morton, Kernel Mailinglist, David S. Miller
On Sat, 22 May 2004, Felipe Alfaro Solana wrote:
> On Sat, 2004-05-22 at 10:36, Andrew Morton wrote:
> > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/
> >
>
> Will you included the i586-optimized AES patch from Fruhwirth Clemens to
> the -mm tree? I find this patch really interesting, as it boost IPSec
> ESP AES considerably.
The problem is that we still need some kind of algorithm selection
mechanism (config time, preferrably), so that the right boxes get the asm
version loaded.
- James
--
James Morris
<jmorris@redhat.com>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 8:36 2.6.6-mm5 Andrew Morton
` (3 preceding siblings ...)
2004-05-22 9:46 ` 2.6.6-mm5 Felipe Alfaro Solana
@ 2004-05-22 11:59 ` Matthias Andree
2004-05-22 12:19 ` [patch] 2.6.6-mm5: JFFS2_FS_NAND=y compile error Adrian Bunk
` (4 subsequent siblings)
9 siblings, 0 replies; 29+ messages in thread
From: Matthias Andree @ 2004-05-22 11:59 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Sat, 22 May 2004, Andrew Morton wrote:
> - Implementation of request barriers for IDE and SCSI. The idea here is
> that a filesystem can tag an IO request as a barrier and the disk will not
> reorder writes across the barrier. It provides additional integrity
> guarantees for the journalling filesystems. The feature is enabled for
> reiserfs and ext3.
>
> On reiserfs do `mount /dev/hda /wherever -o barrier=flush' or
> `barrier=none'.
>
> On ext3 do `mount ... -o barrier=1' or `barrier=0'.
>
> ext3 also supports `mount -o remount,barrier=N'. I didn't check whether
> reiserfs supports switching at remount time and nobody tells me these
> things.
Ah, progress!
What SCSI low level drivers will translate barriers to tags?
Of particular personal egoistic interest for me are, in decreasing order
of importance: sym53c8xx_2 megaraid aic7xxx tmscsim
How will the system handle the Queue Algorithm Modifier? Appearently,
allowing command reordering is a matter of the device, not of the
individual partitions, so the barrier stuff is a property that would
belong into the block driver rather than into partition handling. Upon
mounting, the file system would have to query if the underlying block
device requires write barriers or will execute commands in order
(control mode page, queue algorithm modifier). If I need to operate the
target with "restricted reordering" algorithm for any other partition
that is mounted without barriers or with a barriers-unaware file system,
we won't gain much by all this barrier stuff for the target mustn't
reorder operations anyways.
The potential benefits of Queue Algorithm Modifier "Unrestricted
Reordering allowed" however requires that all file systems inform the
target about their write ordering requirements. IMHO, the barrier
"switch" does not belong into the file systems -- I don't see OTOH how
using these on a device that performs writes in order will matter, so
using these always will probably not harm (it's still useful for testing
probably).
--
Matthias Andree
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95
^ permalink raw reply [flat|nested] 29+ messages in thread* [patch] 2.6.6-mm5: JFFS2_FS_NAND=y compile error
2004-05-22 8:36 2.6.6-mm5 Andrew Morton
` (4 preceding siblings ...)
2004-05-22 11:59 ` 2.6.6-mm5 Matthias Andree
@ 2004-05-22 12:19 ` Adrian Bunk
2004-05-23 1:01 ` 2.6.6-mm5 Eric W. Biederman
` (3 subsequent siblings)
9 siblings, 0 replies; 29+ messages in thread
From: Adrian Bunk @ 2004-05-22 12:19 UTC (permalink / raw)
To: Andrew Morton, Rusty Russell, David Woodhouse, Sam Ravnborg,
l.s.r, Linus Torvalds
Cc: linux-kernel
The patch
[PATCH] trivial: Make JFFS2 ready for Linux 2.7
from Linus' tree is broken with CONFIG_JFFS2_FS_NAND=y:
<-- snip -->
...
LD .tmp_vmlinux1
fs/built-in.o(.text+0x16bdc2): In function `jffs2_wbuf_recover':
: undefined reference to `jffs2_erase_pending_trigger'
fs/built-in.o(.text+0x16c0e2): In function `jffs2_wbuf_recover':
: undefined reference to `jffs2_reserve_space_gc'
fs/built-in.o(.text+0x16c198): In function `jffs2_wbuf_recover':
: undefined reference to `jffs2_alloc_raw_node_ref'
fs/built-in.o(.text+0x16c1d0): In function `jffs2_wbuf_recover':
: undefined reference to `jffs2_add_physical_node_ref'
fs/built-in.o(.text+0x16c46b): In function `jffs2_wbuf_recover':
: undefined reference to `jffs2_erase_pending_trigger'
fs/built-in.o(.text+0x16c8f9): In function `__jffs2_flush_wbuf':
: undefined reference to `jffs2_erase_pending_trigger'
fs/built-in.o(.text+0x16c9f3): In function `jffs2_flush_wbuf_gc':
: undefined reference to `jffs2_garbage_collect_pass'
fs/built-in.o(.text+0x16cac8): In function `jffs2_flash_writev':
: undefined reference to `jffs2_flash_direct_writev'
make: *** [.tmp_vmlinux1] Error 1
<-- snip -->
The bug is obvious, and the fix is trivial:
--- linux-2.6.6-mm5-full/fs/jffs2/Makefile.old 2004-05-22 14:15:47.000000000 +0200
+++ linux-2.6.6-mm5-full/fs/jffs2/Makefile 2004-05-22 14:16:30.000000000 +0200
@@ -12,4 +12,4 @@
jffs2-y += symlink.o build.o erase.o background.o fs.o writev.o
jffs2-y += super.o
-jffs2-$(CONFIG_JFFS2_FS_NAND) := wbuf.o
+jffs2-$(CONFIG_JFFS2_FS_NAND) += wbuf.o
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: 2.6.6-mm5
2004-05-22 8:36 2.6.6-mm5 Andrew Morton
` (5 preceding siblings ...)
2004-05-22 12:19 ` [patch] 2.6.6-mm5: JFFS2_FS_NAND=y compile error Adrian Bunk
@ 2004-05-23 1:01 ` Eric W. Biederman
2004-05-23 1:08 ` 2.6.6-mm5 Andrew Morton
2004-05-24 22:11 ` 2.6.6-mm5 (compile stats) John Cherry
` (2 subsequent siblings)
9 siblings, 1 reply; 29+ messages in thread
From: Eric W. Biederman @ 2004-05-23 1:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Andrew Morton <akpm@osdl.org> writes:
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/
>
>
> add-i386-readq.patch
> add i386 readq()/writeq()
> static inline u64 readq(void *addr)
> {
> return readl(addr) | (((u64)readl(addr + 4)) << 32);
> }
>
> static inline void writeq(u64 v, void *addr)
> {
> u32 v32;
>
> v32 = v;
> writel(v32, addr);
> v32 = v >> 32;
> writel(v32, addr + 4);
> }
>
> #endif
The implementation is broken and it will break drivers that actually
expect writeq and readq to be 64bit reads and writes.
In particular an interrupt can come in during the middle of a read
or a write and widely separate the two different halves.
Unless the driver has a lock protecting access to the card already
this race could be nasty and quite difficult to debug. And I have
looked and we do have some cases in the kernel that do not have
a lock protecting them.
I attempted to suggest some alternative implementations earlier
in the original thread that brought this up but it looks like
you missed that.
Eric
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: 2.6.6-mm5
2004-05-23 1:01 ` 2.6.6-mm5 Eric W. Biederman
@ 2004-05-23 1:08 ` Andrew Morton
2004-05-23 1:15 ` 2.6.6-mm5 Roland Dreier
2004-05-23 2:45 ` 2.6.6-mm5 Eric W. Biederman
0 siblings, 2 replies; 29+ messages in thread
From: Andrew Morton @ 2004-05-23 1:08 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: linux-kernel
ebiederm@xmission.com (Eric W. Biederman) wrote:
>
> Andrew Morton <akpm@osdl.org> writes:
>
> > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/
> >
> >
> > add-i386-readq.patch
> > add i386 readq()/writeq()
>
> > static inline u64 readq(void *addr)
> > {
> > return readl(addr) | (((u64)readl(addr + 4)) << 32);
> > }
> >
> > static inline void writeq(u64 v, void *addr)
> > {
> > u32 v32;
> >
> > v32 = v;
> > writel(v32, addr);
> > v32 = v >> 32;
> > writel(v32, addr + 4);
> > }
> >
> > #endif
>
> The implementation is broken and it will break drivers that actually
> expect writeq and readq to be 64bit reads and writes.
I don't think we can expect all architectures to be able to implement
atomic 64-bit IO's, can we?
ergo, drivers which want to use readq and writeq should provide the
appropriate locking.
> I attempted to suggest some alternative implementations earlier
> in the original thread that brought this up but it looks like
> you missed that.
I saw some stuff float past, but I don't recall seeing anything which would
work on all architectures?
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: 2.6.6-mm5
2004-05-23 1:08 ` 2.6.6-mm5 Andrew Morton
@ 2004-05-23 1:15 ` Roland Dreier
2004-05-24 16:17 ` 2.6.6-mm5 Matt Mackall
2004-05-23 2:45 ` 2.6.6-mm5 Eric W. Biederman
1 sibling, 1 reply; 29+ messages in thread
From: Roland Dreier @ 2004-05-23 1:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: Eric W. Biederman, linux-kernel
Andrew> I don't think we can expect all architectures to be able
Andrew> to implement atomic 64-bit IO's, can we?
Andrew> ergo, drivers which want to use readq and writeq should
Andrew> provide the appropriate locking.
Perhaps we should have ARCH_HAS_ATOMIC_WRITEQ or something so that
drivers don't add the overhead of locking on architectures where it's
not necessary?
(I happen to be working on a driver that needs atomic 64-bit writes,
and where those writes happen to be in the fast path)
Thanks,
Roland
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: 2.6.6-mm5
2004-05-23 1:15 ` 2.6.6-mm5 Roland Dreier
@ 2004-05-24 16:17 ` Matt Mackall
2004-05-24 17:03 ` 2.6.6-mm5 Eric W. Biederman
0 siblings, 1 reply; 29+ messages in thread
From: Matt Mackall @ 2004-05-24 16:17 UTC (permalink / raw)
To: Roland Dreier; +Cc: Andrew Morton, Eric W. Biederman, linux-kernel
On Sat, May 22, 2004 at 06:15:51PM -0700, Roland Dreier wrote:
> Andrew> I don't think we can expect all architectures to be able
> Andrew> to implement atomic 64-bit IO's, can we?
>
> Andrew> ergo, drivers which want to use readq and writeq should
> Andrew> provide the appropriate locking.
>
> Perhaps we should have ARCH_HAS_ATOMIC_WRITEQ or something so that
> drivers don't add the overhead of locking on architectures where it's
> not necessary?
Or perhaps we just need a lockless __readq/__writeq for drivers that
know better.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2.6.6-mm5
2004-05-24 16:17 ` 2.6.6-mm5 Matt Mackall
@ 2004-05-24 17:03 ` Eric W. Biederman
2004-05-24 17:43 ` 2.6.6-mm5 Roland Dreier
0 siblings, 1 reply; 29+ messages in thread
From: Eric W. Biederman @ 2004-05-24 17:03 UTC (permalink / raw)
To: Matt Mackall; +Cc: Roland Dreier, Andrew Morton, linux-kernel
Matt Mackall <mpm@selenic.com> writes:
> On Sat, May 22, 2004 at 06:15:51PM -0700, Roland Dreier wrote:
> > Andrew> I don't think we can expect all architectures to be able
> > Andrew> to implement atomic 64-bit IO's, can we?
> >
> > Andrew> ergo, drivers which want to use readq and writeq should
> > Andrew> provide the appropriate locking.
> >
> > Perhaps we should have ARCH_HAS_ATOMIC_WRITEQ or something so that
> > drivers don't add the overhead of locking on architectures where it's
> > not necessary?
>
> Or perhaps we just need a lockless __readq/__writeq for drivers that
> know better.
I can see implementing these emulations with a name of
readq_emulated/writeq_emulated, or readl2/writel2. For drivers that
can stand not generating a true 64bit bus I/O cycle to the device,
that sounds helpful.
However there are and will likely continue to be devices that need a
64bit I/O cycle on the bus. That is what writeq logically/obviously
does. Putting an emulation in place of the real thing is likely to
cause all sorts subtle of problems.
Having listened to this conversation for a while I strongly dislike
the atomic language because that sounds like generating the wrong bus
cycles are somehow OK, and doing what the function says it does is
somehow just an optimization.
If no hardware actually cared or someone could show me that you can't
generate a 64bit memory I/O cycle on the PCI bus that would be
interesting. I have seen several drivers that care. Later today
I intend to look at my pci docs and confirm that 64bit I/O cycles
do exist on the bus, even in 32bit slots. PCI bus traffic is packet
based so I would be strongly surprised if 64bit cycles did not
exist.
Eric
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2.6.6-mm5
2004-05-24 17:03 ` 2.6.6-mm5 Eric W. Biederman
@ 2004-05-24 17:43 ` Roland Dreier
2004-05-25 7:25 ` 2.6.6-mm5 Eric W. Biederman
0 siblings, 1 reply; 29+ messages in thread
From: Roland Dreier @ 2004-05-24 17:43 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Matt Mackall, Andrew Morton, linux-kernel
Eric> If no hardware actually cared or someone could show me that
Eric> you can't generate a 64bit memory I/O cycle on the PCI bus
Eric> that would be interesting. I have seen several drivers that
Eric> care. Later today I intend to look at my pci docs and
Eric> confirm that 64bit I/O cycles do exist on the bus, even in
Eric> 32bit slots. PCI bus traffic is packet based so I would be
Eric> strongly surprised if 64bit cycles did not exist.
Hang on -- how could you generate a 64-bit cycle on a 32-bit PCI bus?
By definition a 32-bit PCI bus can only transfer 32 bits per cycle.
PCI Express traffic is packet based but parallel PCI definitely is not.
- Roland
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: 2.6.6-mm5
2004-05-24 17:43 ` 2.6.6-mm5 Roland Dreier
@ 2004-05-25 7:25 ` Eric W. Biederman
0 siblings, 0 replies; 29+ messages in thread
From: Eric W. Biederman @ 2004-05-25 7:25 UTC (permalink / raw)
To: Roland Dreier; +Cc: Matt Mackall, Andrew Morton, linux-kernel
Roland Dreier <roland@topspin.com> writes:
> Eric> If no hardware actually cared or someone could show me that
> Eric> you can't generate a 64bit memory I/O cycle on the PCI bus
> Eric> that would be interesting. I have seen several drivers that
> Eric> care. Later today I intend to look at my pci docs and
> Eric> confirm that 64bit I/O cycles do exist on the bus, even in
> Eric> 32bit slots. PCI bus traffic is packet based so I would be
> Eric> strongly surprised if 64bit cycles did not exist.
>
> Hang on -- how could you generate a 64-bit cycle on a 32-bit PCI bus?
> By definition a 32-bit PCI bus can only transfer 32 bits per cycle.
>
> PCI Express traffic is packet based but parallel PCI definitely is not.
But parallel PCI is transaction based, which largely gives the same
effect as being packet based. And you can have man data cycles for
every address cycle. What I am not yet clear are the transaction splitting
rules. My outstanding questions that I really need to track down are:
- Must a 64bit memory write transaction have the same effect as 2
32bit write transactions?
- Must a 64bit read transaction have the same effect as 2 32bit
read transactions?
If true then it is impossible to implement the corresponding 64bit
atomic transaction on the PCI bus, and locks are required for
everyone's code.
The same questions can be asked of PCI-Express.
As soon as I managed to dig a copy of the protocol specifications
I will see if I can answer those questions.
Eric
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2.6.6-mm5
2004-05-23 1:08 ` 2.6.6-mm5 Andrew Morton
2004-05-23 1:15 ` 2.6.6-mm5 Roland Dreier
@ 2004-05-23 2:45 ` Eric W. Biederman
1 sibling, 0 replies; 29+ messages in thread
From: Eric W. Biederman @ 2004-05-23 2:45 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Andrew Morton <akpm@osdl.org> writes:
> ebiederm@xmission.com (Eric W. Biederman) wrote:
> >
> > Andrew Morton <akpm@osdl.org> writes:
> >
> > >
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/
>
> > >
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/
>
> > >
> > >
> > > add-i386-readq.patch
> > > add i386 readq()/writeq()
> >
> > > static inline u64 readq(void *addr)
> > > {
> > > return readl(addr) | (((u64)readl(addr + 4)) << 32);
> > > }
> > >
> > > static inline void writeq(u64 v, void *addr)
> > > {
> > > u32 v32;
> > >
> > > v32 = v;
> > > writel(v32, addr);
> > > v32 = v >> 32;
> > > writel(v32, addr + 4);
> > > }
> > >
> > > #endif
> >
> > The implementation is broken and it will break drivers that actually
> > expect writeq and readq to be 64bit reads and writes.
>
> I don't think we can expect all architectures to be able to implement
> atomic 64-bit IO's, can we?
No I don't think we can expect all architectures to be able to
generate 64-bit bus cycles. Although I think we can expect a majority
of them to, and I believe that majority encompasses all the platforms
we want to run drivers that require readq and writeq.
There are some drivers that cannot be implemented on architectures
without 64bit transactions on the I/O bus. This is not always a race
issue that can be fixed with locking. I know of at least mtd map
driver where if you don't feed the device 64bit writes you will store
corrupt data.
If we want to use the above quoted functions we need to call them
readq_emulated and writeq_emulated. Because they are not the real
mccoy. Likely only readq_emulated and writeq_emulated can be
implemented on all architectures.
As I understand the current situation every architecture that
implements readq/writeq generates true 64bit bus cycles. A driver can
test if it the support exists at compile time with a simple #ifdef to
see if the function is present. If the function is not supported at
compile time the driver can implement a work around (like
readq_emulated) or it can fail to compile.
> ergo, drivers which want to use readq and writeq should provide the
> appropriate locking.
Hmm. I thought the logic:
I am going to introduce a broken implementation of a generic
function and this will reduce the maintainability of your driver in
subtle incomprehensible ways by not doing what is advertised. In
addition I will not even attempt to fix all of the drivers in the
tree when I generate the patch.
did not fly in linux.
I am worried about the general and subtle breakage that may occur
from a driver that works when real 64bit read/writes are generated
on the bus, and fails when we emulate them.
Knowing of two drivers off the top of my head that will break
with this patch, I am opposed to it on general grounds. The
infiniband driver is not in the tree and it can have locking
added to correct the additional race. The 64bit mtd map drivers
I have seen for some ppc platrrom will break as soon as they stop
rolling readq/writeq by hand, and no amount of locking will help
there. I don't know what else in the tree will break.
> > I attempted to suggest some alternative implementations earlier
> > in the original thread that brought this up but it looks like
> > you missed that.
>
> I saw some stuff float past, but I don't recall seeing anything which would
> work on all architectures?
I am not yet convinced you can write code that will work on all
architectures. I have yet to see generic code that with all
existing drivers.
I was attempting to start the conversation, because I don't know all
of the answers, I can just detect failures. In general on a 32bit
arch you need to use the FPU to implement a 64bit read or write. This
is not something you can code casually in the kernel or that you can
write generically. Although the basic idiom will likely be the same
for different architectures.
Currently I know of a safe version that will work on x86 on processors
with sse support. And I how to generate 64bit I/O cycles with using
mmx or x87 registers, but don't know if I can write code that touches
the FPU registers that is interrupt safe.
Eric
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2.6.6-mm5 (compile stats)
2004-05-22 8:36 2.6.6-mm5 Andrew Morton
` (6 preceding siblings ...)
2004-05-23 1:01 ` 2.6.6-mm5 Eric W. Biederman
@ 2004-05-24 22:11 ` John Cherry
2004-05-25 13:53 ` 2.6.6-mm5 Pavel Machek
2004-05-26 12:41 ` 2.6.6-mm5 Anders Gustafsson
9 siblings, 0 replies; 29+ messages in thread
From: John Cherry @ 2004-05-24 22:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Linux 2.6 (mm tree) Compile Statistics (gcc 3.2.2)
Warnings/Errors Summary
Kernel bzImage bzImage bzImage modules bzImage modules
(defconfig) (allno) (allyes) (allyes) (allmod) (allmod)
--------------- ---------- -------- -------- -------- -------- --------
2.6.6-mm5 0w/0e 0w/0e 109w/5e 5w/0e 2w/0e 110w/0e
2.6.6-mm4 0w/0e 0w/0e 112w/9e 5w/0e 2w/5e 106w/1e
2.6.6-mm3 3w/9e 0w/0e 120w/26e 5w/0e 2w/0e 114w/10e
2.6.6-mm2 4w/11e 0w/0e 120w/24e 6w/0e 2w/0e 118w/9e
2.6.6-mm1 1w/0e 0w/0e 118w/25e 6w/0e 2w/0e 114w/10e
2.6.6-rc3-mm2 0w/0e 0w/0e 117w/ 0e 8w/0e 2w/0e 116w/0e
2.6.6-rc3-mm1 0w/0e 0w/0e 120w/10e 8w/0e 2w/0e 152w/2e
2.6.6-rc2-mm2 0w/0e 1w/5e 118w/ 0e 8w/0e 3w/0e 118w/0e
2.6.6-rc2-mm1 0w/0e 0w/0e 115w/ 0e 7w/0e 3w/0e 116w/0e
2.6.6-rc1-mm1 0w/0e 0w/7e 122w/ 0e 7w/0e 4w/0e 122w/0e
2.6.5-mm6 0w/0e 0w/0e 123w/ 0e 7w/0e 4w/0e 124w/0e
2.6.5-mm5 0w/0e 0w/0e 119w/ 0e 7w/0e 4w/0e 120w/0e
2.6.5-mm4 0w/0e 0w/0e 120w/ 0e 7w/0e 4w/0e 121w/0e
2.6.5-mm3 0w/0e 1w/0e 121w/12e 7w/0e 3w/0e 123w/0e
2.6.5-mm2 0w/0e 0w/0e 128w/12e 7w/0e 3w/0e 134w/0e
2.6.5-mm1 0w/0e 5w/0e 122w/ 0e 7w/0e 3w/0e 124w/0e
2.6.5-rc3-mm4 0w/0e 0w/0e 124w/ 0e 8w/0e 4w/0e 126w/0e
2.6.5-rc3-mm3 0w/0e 5w/0e 129w/14e 8w/0e 4w/0e 129w/6e
2.6.5-rc3-mm2 0w/0e 5w/0e 130w/14e 8w/0e 4w/0e 129w/6e
2.6.5-rc3-mm1 0w/0e 5w/0e 129w/ 0e 8w/0e 4w/0e 129w/0e
2.6.5-rc2-mm5 0w/0e 5w/0e 130w/ 0e 8w/0e 4w/0e 129w/0e
2.6.5-rc2-mm4 0w/0e 5w/0e 134w/ 0e 8w/0e 3w/0e 133w/0e
2.6.5-rc2-mm3 0w/0e 5w/0e 134w/ 0e 8w/0e 3w/0e 133w/0e
2.6.5-rc2-mm2 0w/0e 5w/0e 137w/ 0e 8w/0e 3w/0e 134w/0e
2.6.5-rc2-mm1 0w/0e 5w/0e 136w/ 0e 8w/0e 3w/0e 134w/0e
2.6.5-rc1-mm2 0w/0e 5w/0e 135w/ 5e 8w/0e 3w/0e 133w/0e
2.6.5-rc1-mm1 0w/0e 5w/0e 135w/ 5e 8w/0e 3w/0e 133w/0e
2.6.4-mm2 1w/2e 5w/2e 144w/10e 8w/0e 3w/2e 144w/0e
2.6.4-mm1 1w/0e 5w/0e 146w/ 5e 8w/0e 3w/0e 144w/0e
2.6.4-rc2-mm1 1w/0e 5w/0e 146w/12e 11w/0e 3w/0e 147w/2e
2.6.4-rc1-mm2 1w/0e 5w/0e 144w/ 0e 11w/0e 3w/0e 145w/0e
2.6.4-rc1-mm1 1w/0e 5w/0e 147w/ 5e 11w/0e 3w/0e 147w/0e
2.6.3-mm4 1w/0e 5w/0e 146w/ 0e 7w/0e 3w/0e 142w/0e
2.6.3-mm3 1w/2e 5w/2e 146w/15e 7w/0e 3w/2e 144w/5e
2.6.3-mm2 1w/8e 5w/0e 140w/ 0e 7w/0e 3w/0e 138w/0e
2.6.3-mm1 1w/0e 5w/0e 143w/ 5e 7w/0e 3w/0e 141w/0e
2.6.3-rc3-mm1 1w/0e 0w/0e 144w/13e 7w/0e 3w/0e 142w/3e
2.6.3-rc2-mm1 1w/0e 0w/265e 144w/ 5e 7w/0e 3w/0e 145w/0e
2.6.3-rc1-mm1 1w/0e 0w/265e 141w/ 5e 7w/0e 3w/0e 143w/0e
2.6.2-mm1 2w/0e 0w/264e 147w/ 5e 7w/0e 3w/0e 173w/0e
2.6.2-rc3-mm1 2w/0e 0w/265e 146w/ 5e 7w/0e 3w/0e 172w/0e
2.6.2-rc2-mm2 0w/0e 0w/264e 145w/ 5e 7w/0e 3w/0e 171w/0e
2.6.2-rc2-mm1 0w/0e 0w/264e 146w/ 5e 7w/0e 3w/0e 172w/0e
2.6.2-rc1-mm3 0w/0e 0w/265e 144w/ 8e 7w/0e 3w/0e 169w/0e
2.6.2-rc1-mm2 0w/0e 0w/264e 144w/ 5e 10w/0e 3w/0e 171w/0e
2.6.2-rc1-mm1 0w/0e 0w/264e 144w/ 5e 10w/0e 3w/0e 171w/0e
2.6.1-mm5 2w/5e 0w/264e 153w/11e 10w/0e 3w/0e 180w/0e
2.6.1-mm4 0w/821e 0w/264e 154w/ 5e 8w/1e 5w/0e 179w/0e
2.6.1-mm3 0w/0e 0w/0e 151w/ 5e 10w/0e 3w/0e 177w/0e
2.6.1-mm2 0w/0e 0w/0e 143w/ 5e 12w/0e 3w/0e 171w/0e
2.6.1-mm1 0w/0e 0w/0e 146w/ 9e 12w/0e 6w/0e 171w/0e
2.6.1-rc2-mm1 0w/0e 0w/0e 149w/ 0e 12w/0e 6w/0e 171w/4e
2.6.1-rc1-mm2 0w/0e 0w/0e 157w/15e 12w/0e 3w/0e 185w/4e
2.6.1-rc1-mm1 0w/0e 0w/0e 156w/10e 12w/0e 3w/0e 184w/2e
2.6.0-mm2 0w/0e 0w/0e 161w/ 0e 12w/0e 3w/0e 189w/0e
2.6.0-mm1 0w/0e 0w/0e 173w/ 0e 12w/0e 3w/0e 212w/0e
Web page with links to complete details:
http://developer.osdl.org/cherry/compile/
John
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: 2.6.6-mm5
2004-05-22 8:36 2.6.6-mm5 Andrew Morton
` (7 preceding siblings ...)
2004-05-24 22:11 ` 2.6.6-mm5 (compile stats) John Cherry
@ 2004-05-25 13:53 ` Pavel Machek
2004-05-26 12:41 ` 2.6.6-mm5 Anders Gustafsson
9 siblings, 0 replies; 29+ messages in thread
From: Pavel Machek @ 2004-05-25 13:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Hi!
> - Implementation of request barriers for IDE and SCSI. The idea here is
> that a filesystem can tag an IO request as a barrier and the disk will not
> reorder writes across the barrier. It provides additional integrity
> guarantees for the journalling filesystems. The feature is enabled for
> reiserfs and ext3.
*Additional* guarantees? Is there anything we can garant
without request barriers?
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: 2.6.6-mm5
2004-05-22 8:36 2.6.6-mm5 Andrew Morton
` (8 preceding siblings ...)
2004-05-25 13:53 ` 2.6.6-mm5 Pavel Machek
@ 2004-05-26 12:41 ` Anders Gustafsson
2004-05-26 12:49 ` 2.6.6-mm5 Jens Axboe
9 siblings, 1 reply; 29+ messages in thread
From: Anders Gustafsson @ 2004-05-26 12:41 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Jens Axboe
On Sat, May 22, 2004 at 01:36:36AM -0700, Andrew Morton wrote:
>
> - Implementation of request barriers for IDE and SCSI. The idea here is
> that a filesystem can tag an IO request as a barrier and the disk will not
> reorder writes across the barrier. It provides additional integrity
> guarantees for the journalling filesystems. The feature is enabled for
> reiserfs and ext3.
I get: this error message when using barriers on a scsi disk:
lost page write due to I/O error on sdb1
JBD: barrier-based sync failed on sdb1 - bisabling barriers
and I don't want them barriers bisabled :)
ext3 filesystem. reiser also disables barriers.
I have a "Adaptec AIC-7902 U320 (rev 3)" SCSI controller and the disk is a
SEAGATE ST373307LW.
It works on ide.
--
Anders Gustafsson - andersg@0x63.nu - http://0x63.nu/
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: 2.6.6-mm5
2004-05-26 12:41 ` 2.6.6-mm5 Anders Gustafsson
@ 2004-05-26 12:49 ` Jens Axboe
2004-05-26 12:59 ` 2.6.6-mm5 Anders Gustafsson
0 siblings, 1 reply; 29+ messages in thread
From: Jens Axboe @ 2004-05-26 12:49 UTC (permalink / raw)
To: Anders Gustafsson; +Cc: Andrew Morton, linux-kernel
On Wed, May 26 2004, Anders Gustafsson wrote:
> On Sat, May 22, 2004 at 01:36:36AM -0700, Andrew Morton wrote:
> >
> > - Implementation of request barriers for IDE and SCSI. The idea here is
> > that a filesystem can tag an IO request as a barrier and the disk will not
> > reorder writes across the barrier. It provides additional integrity
> > guarantees for the journalling filesystems. The feature is enabled for
> > reiserfs and ext3.
>
> I get: this error message when using barriers on a scsi disk:
>
> lost page write due to I/O error on sdb1
> JBD: barrier-based sync failed on sdb1 - bisabling barriers
>
> and I don't want them barriers bisabled :)
>
> ext3 filesystem. reiser also disables barriers.
>
> I have a "Adaptec AIC-7902 U320 (rev 3)" SCSI controller and the disk is a
> SEAGATE ST373307LW.
But they need to be bisabled, since -o barrier doesn't work on SCSI yet.
Only non-data tagged flushes are supported, those from
blkdev_issue_flush().
--
Jens Axboe
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2.6.6-mm5
2004-05-26 12:49 ` 2.6.6-mm5 Jens Axboe
@ 2004-05-26 12:59 ` Anders Gustafsson
2004-05-26 13:03 ` 2.6.6-mm5 Jens Axboe
0 siblings, 1 reply; 29+ messages in thread
From: Anders Gustafsson @ 2004-05-26 12:59 UTC (permalink / raw)
To: Jens Axboe; +Cc: Andrew Morton, linux-kernel
On Wed, May 26, 2004 at 02:49:44PM +0200, Jens Axboe wrote:
> But they need to be bisabled, since -o barrier doesn't work on SCSI yet.
> Only non-data tagged flushes are supported, those from
> blkdev_issue_flush().
:(
Is the problem in the scsi drivers or at a higher level? Would really
like to have them unbisabled, got a huge speed improvement in a
logging-application with barriers when tested on IDE.
anders
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2.6.6-mm5
2004-05-26 12:59 ` 2.6.6-mm5 Anders Gustafsson
@ 2004-05-26 13:03 ` Jens Axboe
0 siblings, 0 replies; 29+ messages in thread
From: Jens Axboe @ 2004-05-26 13:03 UTC (permalink / raw)
To: Anders Gustafsson; +Cc: Andrew Morton, linux-kernel
On Wed, May 26 2004, Anders Gustafsson wrote:
> On Wed, May 26, 2004 at 02:49:44PM +0200, Jens Axboe wrote:
> > But they need to be bisabled, since -o barrier doesn't work on SCSI yet.
> > Only non-data tagged flushes are supported, those from
> > blkdev_issue_flush().
>
> :(
>
> Is the problem in the scsi drivers or at a higher level? Would really
> like to have them unbisabled, got a huge speed improvement in a
> logging-application with barriers when tested on IDE.
The error handling needs some work to safely enbable it on SCSI. Will
happen soonish. Additionally, low level drivers need to be updated. This
last step should not be too bad, though.
--
Jens Axboe
^ permalink raw reply [flat|nested] 29+ messages in thread