[PATCH] MIPS: Fixups of ALSA memory maps

[PATCH] MIPS: Fixups of ALSA memory maps

[Wu Zhangjin]

Hi, All

Seems this is MIPS specific, but it's not that easy to move this patch
into the arch/mips part, So, any better solution?

Thanks & Regards,
       Wu Zhangjin

------------------------

The user application mmap audio dma regions must be dma-coherent. This
patch fix it.

Without this patch, artsd will fail on boot, and mplayer will exit with
"Segmentation fault". (this happens on YeeLoong netbook, fuloong2f
mini pc with snd_cs5535 audio card)

This is originally from the to-mips branch of
http://dev.lemote.com/code/linux_loongson, and contributed by Yanhua
from Lemote Inc.

Reported-by: qiaochong <qiaochong@gmail.com>
Signed-off-by: Wu Zhangjin <wuzj@lemote.com>
---
 sound/core/pcm_native.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index ab73edf..2779b9a 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -3087,7 +3087,11 @@ static int snd_pcm_mmap_data_fault(struct vm_area_struct *area,
 			return VM_FAULT_SIGBUS;
 	} else {
 		vaddr = runtime->dma_area + offset;
+#if defined(__mips__) && defined(CONFIG_DMA_NONCOHERENT)
+		page = virt_to_page(CAC_ADDR(vaddr));
+#else
 		page = virt_to_page(vaddr);
+#endif
 	}
 	get_page(page);
 	vmf->page = page;
@@ -3202,6 +3206,11 @@ static int snd_pcm_mmap(struct file *file, struct vm_area_struct *area)
 	if (PCM_RUNTIME_CHECK(substream))
 		return -ENXIO;
 
+#if defined(__mips__) && defined(CONFIG_DMA_NONCOHERENT)
+	/* all mmap using uncached mode */
+	area->vm_page_prot = pgprot_noncached(area->vm_page_prot);
+	area->vm_flags |= (VM_RESERVED | VM_IO);
+#endif
 	offset = area->vm_pgoff << PAGE_SHIFT;
 	switch (offset) {
 	case SNDRV_PCM_MMAP_OFFSET_STATUS:
-- 
1.6.2.1

Re: [PATCH] MIPS: Fixups of ALSA memory maps

[Ralf Baechle]

On Tue, Nov 17, 2009 at 12:48:14AM +0800, Wu Zhangjin wrote:

> Seems this is MIPS specific, but it's not that easy to move this patch
> into the arch/mips part, So, any better solution?
> 
> Thanks & Regards,
>        Wu Zhangjin
> 
> ------------------------
> 
> The user application mmap audio dma regions must be dma-coherent. This
> patch fix it.
> 
> Without this patch, artsd will fail on boot, and mplayer will exit with
> "Segmentation fault". (this happens on YeeLoong netbook, fuloong2f
> mini pc with snd_cs5535 audio card)
> 
> This is originally from the to-mips branch of
> http://dev.lemote.com/code/linux_loongson, and contributed by Yanhua
> from Lemote Inc.
> 
> Reported-by: qiaochong <qiaochong@gmail.com>
> Signed-off-by: Wu Zhangjin <wuzj@lemote.com>

This issue is an old ghost still around, see:

   http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20060124.132832.37533152.nemoto%40toshiba-tops.co.jp

which is a superset of your proposed patch and which itself is refering to
an even older posting from 2003:

   http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20030523215935.71373.qmail%40web11901.mail.yahoo.com

The #ifdef'ed solution doesn't cut it for sure.  Let's see what better we
can find ...

  Ralf

Re: [PATCH] MIPS: Fixups of ALSA memory maps

[Takashi Iwai]

At Mon, 16 Nov 2009 18:06:41 +0100,
Ralf Baechle wrote:
> 
> On Tue, Nov 17, 2009 at 12:48:14AM +0800, Wu Zhangjin wrote:
> 
> > Seems this is MIPS specific, but it's not that easy to move this patch
> > into the arch/mips part, So, any better solution?
> > 
> > Thanks & Regards,
> >        Wu Zhangjin
> > 
> > ------------------------
> > 
> > The user application mmap audio dma regions must be dma-coherent. This
> > patch fix it.
> > 
> > Without this patch, artsd will fail on boot, and mplayer will exit with
> > "Segmentation fault". (this happens on YeeLoong netbook, fuloong2f
> > mini pc with snd_cs5535 audio card)
> > 
> > This is originally from the to-mips branch of
> > http://dev.lemote.com/code/linux_loongson, and contributed by Yanhua
> > from Lemote Inc.
> > 
> > Reported-by: qiaochong <qiaochong@gmail.com>
> > Signed-off-by: Wu Zhangjin <wuzj@lemote.com>
> 
> This issue is an old ghost still around, see:
> 
>    http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20060124.132832.37533152.nemoto%40toshiba-tops.co.jp
> 
> which is a superset of your proposed patch and which itself is refering to
> an even older posting from 2003:
> 
>    http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20030523215935.71373.qmail%40web11901.mail.yahoo.com
> 
> The #ifdef'ed solution doesn't cut it for sure.  Let's see what better we
> can find ...

Indeed.  My preference option is to deploy dma_mmap_coherent() to
possible architectures and use it commonly in the ALSA core code.

But, as a temporary workaround, I'm fine with ifdef until the API is
defined...


thanks,

Takashi

Re: [PATCH] MIPS: Fixups of ALSA memory maps

[Ralf Baechle]

On Mon, Nov 16, 2009 at 06:14:14PM +0100, Takashi Iwai wrote:

> > > Seems this is MIPS specific, but it's not that easy to move this patch
> > > into the arch/mips part, So, any better solution?
> > > 
> > > Thanks & Regards,
> > >        Wu Zhangjin
> > > 
> > > ------------------------
> > > 
> > > The user application mmap audio dma regions must be dma-coherent. This
> > > patch fix it.
> > > 
> > > Without this patch, artsd will fail on boot, and mplayer will exit with
> > > "Segmentation fault". (this happens on YeeLoong netbook, fuloong2f
> > > mini pc with snd_cs5535 audio card)
> > > 
> > > This is originally from the to-mips branch of
> > > http://dev.lemote.com/code/linux_loongson, and contributed by Yanhua
> > > from Lemote Inc.
> > > 
> > > Reported-by: qiaochong <qiaochong@gmail.com>
> > > Signed-off-by: Wu Zhangjin <wuzj@lemote.com>
> > 
> > This issue is an old ghost still around, see:
> > 
> >    http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20060124.132832.37533152.nemoto%40toshiba-tops.co.jp
> > 
> > which is a superset of your proposed patch and which itself is refering to
> > an even older posting from 2003:
> > 
> >    http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20030523215935.71373.qmail%40web11901.mail.yahoo.com
> > 
> > The #ifdef'ed solution doesn't cut it for sure.  Let's see what better we
> > can find ...
> 
> Indeed.  My preference option is to deploy dma_mmap_coherent() to
> possible architectures and use it commonly in the ALSA core code.
> 
> But, as a temporary workaround, I'm fine with ifdef until the API is
> defined...

There is a MIPS platform which may be based on a variety of system
controllers only one of which supports cache coherency.  So we want to
deciede at runtime not at compile time.

  Ralf

Re: [PATCH] MIPS: Fixups of ALSA memory maps

[Takashi Iwai]

At Tue, 17 Nov 2009 00:48:14 +0800,
Wu Zhangjin wrote:
> 
> Hi, All
> 
> Seems this is MIPS specific, but it's not that easy to move this patch
> into the arch/mips part, So, any better solution?

Actually, this has been a looong-standing problem.
I have a series of patches to fix these issues, but it's more
intensively involved with dma_*() functions.

The patches can be found in test/dma-fix branch of sound GIT tree.
  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git test/dma-fix

This basically adds dma_mmap_coherent() function to feasible
architectures, which is already implemented for ARM, so far.


thanks,

Takashi

Re: [PATCH] MIPS: Fixups of ALSA memory maps

[Ralf Baechle]

On Mon, Nov 16, 2009 at 06:12:22PM +0100, Takashi Iwai wrote:

> Actually, this has been a looong-standing problem.
> I have a series of patches to fix these issues, but it's more
> intensively involved with dma_*() functions.
> 
> The patches can be found in test/dma-fix branch of sound GIT tree.
>   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git test/dma-fix
> 
> This basically adds dma_mmap_coherent() function to feasible
> architectures, which is already implemented for ARM, so far.

Cool - but needs a little further tweaking to work right.  That's a
solution which will use uncached accesses on all MIPS systems.

IP27/IP35-family machines will explode when you try that.  Eventually the
cache coherency logic will notice that cache, directory caches and memory
have become inconsistent and bombard the CPU with a bunch of nasty
exceptions.

For cache-coherent machines otoh it's a big waste of performance.

int dma_mmap_coherent(struct device *dev, struct vm_area_struct *vma,
                      void *cpu_addr, dma_addr_t handle, size_t size)
{
        struct page *pg;

	if (!plat_device_is_coherent(dev))
		vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
        cpu_addr = (void *)dma_addr_to_virt(handle);
        pg = virt_to_page(cpu_addr);

        return remap_pfn_range(vma, vma->vm_start,
                               page_to_pfn(pg) + vma->vm_pgoff,
                               size, vma->vm_page_prot);
}
EXPORT_SYMBOL(dma_mmap_coherent);

Thomas - you're the IP28 specialist.  Would the plat_device_is_coherent()
above have to become a cpu_is_noncoherent_r10000() call?  Any further
nasties?

  Ralf

Re: [PATCH] MIPS: Fixups of ALSA memory maps

[Takashi Iwai]

At Mon, 16 Nov 2009 18:43:24 +0100,
Ralf Baechle wrote:
> 
> On Mon, Nov 16, 2009 at 06:12:22PM +0100, Takashi Iwai wrote:
> 
> > Actually, this has been a looong-standing problem.
> > I have a series of patches to fix these issues, but it's more
> > intensively involved with dma_*() functions.
> > 
> > The patches can be found in test/dma-fix branch of sound GIT tree.
> >   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git test/dma-fix
> > 
> > This basically adds dma_mmap_coherent() function to feasible
> > architectures, which is already implemented for ARM, so far.
> 
> Cool - but needs a little further tweaking to work right.  That's a
> solution which will use uncached accesses on all MIPS systems.
> 
> IP27/IP35-family machines will explode when you try that.  Eventually the
> cache coherency logic will notice that cache, directory caches and memory
> have become inconsistent and bombard the CPU with a bunch of nasty
> exceptions.

OK, that's really bad.

> For cache-coherent machines otoh it's a big waste of performance.
> 
> int dma_mmap_coherent(struct device *dev, struct vm_area_struct *vma,
>                       void *cpu_addr, dma_addr_t handle, size_t size)
> {
>         struct page *pg;
> 
> 	if (!plat_device_is_coherent(dev))
> 		vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>         cpu_addr = (void *)dma_addr_to_virt(handle);
>         pg = virt_to_page(cpu_addr);
> 
>         return remap_pfn_range(vma, vma->vm_start,
>                                page_to_pfn(pg) + vma->vm_pgoff,
>                                size, vma->vm_page_prot);
> }
> EXPORT_SYMBOL(dma_mmap_coherent);
> 
> Thomas - you're the IP28 specialist.  Would the plat_device_is_coherent()
> above have to become a cpu_is_noncoherent_r10000() call?  Any further
> nasties?

Thanks for checking!


thanks,

Takashi

Re: [PATCH] MIPS: Fixups of ALSA memory maps

[Ralf Baechle]

On Tue, Nov 17, 2009 at 10:29:10AM +0100, Takashi Iwai wrote:

> > > Actually, this has been a looong-standing problem.
> > > I have a series of patches to fix these issues, but it's more
> > > intensively involved with dma_*() functions.
> > > 
> > > The patches can be found in test/dma-fix branch of sound GIT tree.
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git test/dma-fix
> > > 
> > > This basically adds dma_mmap_coherent() function to feasible
> > > architectures, which is already implemented for ARM, so far.
> > 
> > Cool - but needs a little further tweaking to work right.  That's a
> > solution which will use uncached accesses on all MIPS systems.
> > 
> > IP27/IP35-family machines will explode when you try that.  Eventually the
> > cache coherency logic will notice that cache, directory caches and memory
> > have become inconsistent and bombard the CPU with a bunch of nasty
> > exceptions.
> 
> OK, that's really bad.

Hardware designers do such things to you.  Often even for a reason.

> > For cache-coherent machines otoh it's a big waste of performance.
> > 
> > int dma_mmap_coherent(struct device *dev, struct vm_area_struct *vma,
> >                       void *cpu_addr, dma_addr_t handle, size_t size)
> > {
> >         struct page *pg;
> > 
> > 	if (!plat_device_is_coherent(dev))
> > 		vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> >         cpu_addr = (void *)dma_addr_to_virt(handle);
> >         pg = virt_to_page(cpu_addr);
> > 
> >         return remap_pfn_range(vma, vma->vm_start,
> >                                page_to_pfn(pg) + vma->vm_pgoff,
> >                                size, vma->vm_page_prot);
> > }
> > EXPORT_SYMBOL(dma_mmap_coherent);
> > 
> > Thomas - you're the IP28 specialist.  Would the plat_device_is_coherent()
> > above have to become a cpu_is_noncoherent_r10000() call?  Any further
> > nasties?
> 
> Thanks for checking!

You're welcome!

So basically I'd not mind putting this into the Linux/MIPS tree; we still
can iron out the kinks from there on and probably much better than by
having arch stuff in the ALSA tree.

I recall this new API having been posted for discussion to linux-arch.
What was the outcome?  I'd only like to add a new API if the other arch
maintainers see it fit their needs also.

  Ralf

Re: [PATCH] MIPS: Fixups of ALSA memory maps

[Takashi Iwai]

At Wed, 18 Nov 2009 15:20:56 +0100,
Ralf Baechle wrote:
> 
> On Tue, Nov 17, 2009 at 10:29:10AM +0100, Takashi Iwai wrote:
> 
> > > > Actually, this has been a looong-standing problem.
> > > > I have a series of patches to fix these issues, but it's more
> > > > intensively involved with dma_*() functions.
> > > > 
> > > > The patches can be found in test/dma-fix branch of sound GIT tree.
> > > >   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git test/dma-fix
> > > > 
> > > > This basically adds dma_mmap_coherent() function to feasible
> > > > architectures, which is already implemented for ARM, so far.
> > > 
> > > Cool - but needs a little further tweaking to work right.  That's a
> > > solution which will use uncached accesses on all MIPS systems.
> > > 
> > > IP27/IP35-family machines will explode when you try that.  Eventually the
> > > cache coherency logic will notice that cache, directory caches and memory
> > > have become inconsistent and bombard the CPU with a bunch of nasty
> > > exceptions.
> > 
> > OK, that's really bad.
> 
> Hardware designers do such things to you.  Often even for a reason.

Heh, not only software engineers are so crazy ;)

> > > For cache-coherent machines otoh it's a big waste of performance.
> > > 
> > > int dma_mmap_coherent(struct device *dev, struct vm_area_struct *vma,
> > >                       void *cpu_addr, dma_addr_t handle, size_t size)
> > > {
> > >         struct page *pg;
> > > 
> > > 	if (!plat_device_is_coherent(dev))
> > > 		vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> > >         cpu_addr = (void *)dma_addr_to_virt(handle);
> > >         pg = virt_to_page(cpu_addr);
> > > 
> > >         return remap_pfn_range(vma, vma->vm_start,
> > >                                page_to_pfn(pg) + vma->vm_pgoff,
> > >                                size, vma->vm_page_prot);
> > > }
> > > EXPORT_SYMBOL(dma_mmap_coherent);
> > > 
> > > Thomas - you're the IP28 specialist.  Would the plat_device_is_coherent()
> > > above have to become a cpu_is_noncoherent_r10000() call?  Any further
> > > nasties?
> > 
> > Thanks for checking!
> 
> You're welcome!
> 
> So basically I'd not mind putting this into the Linux/MIPS tree; we still
> can iron out the kinks from there on and probably much better than by
> having arch stuff in the ALSA tree.

Yes, that's the very purpose of my patchset.

> I recall this new API having been posted for discussion to linux-arch.
> What was the outcome?  I'd only like to add a new API if the other arch
> maintainers see it fit their needs also.

Well, we haven't reached the consensus.  The discussion faded away
somehow mainly because I had too little time to update and ping people
again.

In Tokyo, I talked with some guys regarding this.  Ben agreed to take
this approach for ppc, and David said that he doesn't mind for sparc
part.   Fujita-san mentioned it's no big problem to add one op from
the generic dma_ops.

So, maybe somehow need to convince James in the end (and ask Paul to
check SH part, too), then it'll be all up... theoretically :)

Anyway, I'm going to raise the discussion again on linux-arch.
I'm afraid it's a bit too late game for 2.6.33, but starting now is
better than too late again.


thanks,

Takashi

Re: [PATCH] MIPS: Fixups of ALSA memory maps

[Wu Zhangjin]

On Wed, 2009-11-18 at 18:47 +0100, Takashi Iwai wrote:
[...]
> 
> Well, we haven't reached the consensus.  The discussion faded away
> somehow mainly because I had too little time to update and ping people
> again.
> 
> In Tokyo, I talked with some guys regarding this.  Ben agreed to take
> this approach for ppc, and David said that he doesn't mind for sparc
> part.   Fujita-san mentioned it's no big problem to add one op from
> the generic dma_ops.
> 
> So, maybe somehow need to convince James in the end (and ask Paul to
> check SH part, too), then it'll be all up... theoretically :)
> 
> Anyway, I'm going to raise the discussion again on linux-arch.
> I'm afraid it's a bit too late game for 2.6.33, but starting now is
> better than too late again.

Hi, Takashi Iwai

Before the API stuff going into the mainline(2.6.33), can we apply this
"[PATCH] MIPS: Fixups of ALSA memory maps"(This is the minimal
necessares) as a current fixup. and then we will not get a broken sound
support for MIPS, and also the support to the latest Loongson2F family
machines will benefit from it.

and Ralf, what about your suggestion?

Thanks & Best wishes,
	Wu Zhangjin

Re: [PATCH] MIPS: Fixups of ALSA memory maps

[Takashi Iwai]

At Sat, 21 Nov 2009 20:31:41 +0800,
Wu Zhangjin wrote:
> 
> On Wed, 2009-11-18 at 18:47 +0100, Takashi Iwai wrote:
> [...]
> > 
> > Well, we haven't reached the consensus.  The discussion faded away
> > somehow mainly because I had too little time to update and ping people
> > again.
> > 
> > In Tokyo, I talked with some guys regarding this.  Ben agreed to take
> > this approach for ppc, and David said that he doesn't mind for sparc
> > part.   Fujita-san mentioned it's no big problem to add one op from
> > the generic dma_ops.
> > 
> > So, maybe somehow need to convince James in the end (and ask Paul to
> > check SH part, too), then it'll be all up... theoretically :)
> > 
> > Anyway, I'm going to raise the discussion again on linux-arch.
> > I'm afraid it's a bit too late game for 2.6.33, but starting now is
> > better than too late again.
> 
> Hi, Takashi Iwai
> 
> Before the API stuff going into the mainline(2.6.33), can we apply this
> "[PATCH] MIPS: Fixups of ALSA memory maps"(This is the minimal
> necessares) as a current fixup. and then we will not get a broken sound
> support for MIPS, and also the support to the latest Loongson2F family
> machines will benefit from it.
> 
> and Ralf, what about your suggestion?

The question is whether this hack can be safely added for all MIPS
platforms just by checking kconfig.  I had an impression that rather
many things have to be checked in the runtime.

As I have really little clue about MIPS architecture, I'd like let
MIPS guys decide about it...


thanks,

Takashi

Re: [PATCH] MIPS: Fixups of ALSA memory maps

[Ralf Baechle]

On Mon, Nov 23, 2009 at 09:56:39AM +0100, Takashi Iwai wrote:

> > On Wed, 2009-11-18 at 18:47 +0100, Takashi Iwai wrote:
> > [...]
> > > 
> > > Well, we haven't reached the consensus.  The discussion faded away
> > > somehow mainly because I had too little time to update and ping people
> > > again.
> > > 
> > > In Tokyo, I talked with some guys regarding this.  Ben agreed to take
> > > this approach for ppc, and David said that he doesn't mind for sparc
> > > part.   Fujita-san mentioned it's no big problem to add one op from
> > > the generic dma_ops.
> > > 
> > > So, maybe somehow need to convince James in the end (and ask Paul to
> > > check SH part, too), then it'll be all up... theoretically :)
> > > 
> > > Anyway, I'm going to raise the discussion again on linux-arch.
> > > I'm afraid it's a bit too late game for 2.6.33, but starting now is
> > > better than too late again.
> > 
> > Hi, Takashi Iwai
> > 
> > Before the API stuff going into the mainline(2.6.33), can we apply this
> > "[PATCH] MIPS: Fixups of ALSA memory maps"(This is the minimal
> > necessares) as a current fixup. and then we will not get a broken sound
> > support for MIPS, and also the support to the latest Loongson2F family
> > machines will benefit from it.
> > 
> > and Ralf, what about your suggestion?
> 
> The question is whether this hack can be safely added for all MIPS
> platforms just by checking kconfig.  I had an impression that rather
> many things have to be checked in the runtime.
> 
> As I have really little clue about MIPS architecture, I'd like let
> MIPS guys decide about it...

Okay, I'll cook up a nice kludge.  It can't cover all cases but it will
be an improvment for most platforms.

  Ralf

Re: [PATCH] MIPS: Fixups of ALSA memory maps

[Takashi Iwai]

At Mon, 23 Nov 2009 12:36:15 +0000,
Ralf Baechle wrote:
> 
> On Mon, Nov 23, 2009 at 09:56:39AM +0100, Takashi Iwai wrote:
> 
> > > On Wed, 2009-11-18 at 18:47 +0100, Takashi Iwai wrote:
> > > [...]
> > > > 
> > > > Well, we haven't reached the consensus.  The discussion faded away
> > > > somehow mainly because I had too little time to update and ping people
> > > > again.
> > > > 
> > > > In Tokyo, I talked with some guys regarding this.  Ben agreed to take
> > > > this approach for ppc, and David said that he doesn't mind for sparc
> > > > part.   Fujita-san mentioned it's no big problem to add one op from
> > > > the generic dma_ops.
> > > > 
> > > > So, maybe somehow need to convince James in the end (and ask Paul to
> > > > check SH part, too), then it'll be all up... theoretically :)
> > > > 
> > > > Anyway, I'm going to raise the discussion again on linux-arch.
> > > > I'm afraid it's a bit too late game for 2.6.33, but starting now is
> > > > better than too late again.
> > > 
> > > Hi, Takashi Iwai
> > > 
> > > Before the API stuff going into the mainline(2.6.33), can we apply this
> > > "[PATCH] MIPS: Fixups of ALSA memory maps"(This is the minimal
> > > necessares) as a current fixup. and then we will not get a broken sound
> > > support for MIPS, and also the support to the latest Loongson2F family
> > > machines will benefit from it.
> > > 
> > > and Ralf, what about your suggestion?
> > 
> > The question is whether this hack can be safely added for all MIPS
> > platforms just by checking kconfig.  I had an impression that rather
> > many things have to be checked in the runtime.
> > 
> > As I have really little clue about MIPS architecture, I'd like let
> > MIPS guys decide about it...
> 
> Okay, I'll cook up a nice kludge.  It can't cover all cases but it will
> be an improvment for most platforms.

OK, but I found that the original patch doesn't work correctly for
some cases, as I mentioned in another thread.  I'm going to send a patch
set soon as a new thread.


thanks,

Takashi