USB mass storage and ARM cache coherency
in [Kernel]
|
Prev: [PATCH 0/3] HID: make raw output callback more flexible
Next: kprobes: Disable booster when CONFIG_PREEMPT=y
From: Alan Stern on 1 Feb 2010 15:20 On Mon, 1 Feb 2010, Catalin Marinas wrote: > On Fri, 2010-01-29 at 18:54 +0000, Matthew Dharm wrote: > > HOWEVER, I firmly believe that the cache-management functions belong with > > the driver that actually talks to the low-level hardware, as that's the > > only place where you can be 100% certain of what cache operations are > > needed. After all, I think someone is working on a USB-over-IP transport, > > and trying to manage cache at the usb-storage level in that scenario is > > just silly. > > > > So, let's put this in the HCD drivers and be done with it. > > The patch below is what fixes the I-D cache incoherency issues on ARM. I > don't particularly like the solution but it seems to be the only one > available. > > IMHO, Linux should have functions similar to the DMA API but for PIO > drivers (e.g. pio_map_single/pio_unmap_single) that non-coherent > architectures can define, otherwise being no-ops. Any thoughts? You should bring this up on the linux-arm-kernel mailing list and CC: the ARM maintainer. They are the ones most directly affected. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andreas Mohr on 1 Feb 2010 17:40 [CC Takashi] On Mon, Feb 01, 2010 at 05:29:14PM +0000, Catalin Marinas wrote: > On Fri, 2010-01-29 at 18:54 +0000, Matthew Dharm wrote: > > HOWEVER, I firmly believe that the cache-management functions belong with > > the driver that actually talks to the low-level hardware, as that's the > > only place where you can be 100% certain of what cache operations are > > needed. After all, I think someone is working on a USB-over-IP transport, > > and trying to manage cache at the usb-storage level in that scenario is > > just silly. > > > > So, let's put this in the HCD drivers and be done with it. > > The patch below is what fixes the I-D cache incoherency issues on ARM. I > don't particularly like the solution but it seems to be the only one > available. Thanks very much for working on this amazingly large problem! I took some time to add your patch to ehci-q.c / ohci-q.c (for my *hci-ssb.c ASUS WL-500gP v2), on my now _heavily_ patched-up 2.6.31.9, but _UNFORTUNATELY_ it kept locking up the same way as always when stopping playback despite being damn sure this time that this patch could have the potential to finally fix it ;) (I had to replace memory.h with page.h on my arch though, to fix the build) This is on MIPSEL (not one of my many ARM devices, unfortunately ;), with usb-audio, and the madplay process crashes in __bzero(), which strongly indicates cache coherency issues (other subsequent backtraces have lots of mmap and vma listed, see also my "snd_usb_audio OOPS on MIPSEL - is that the mmap issue?"). Next thing I'll do is fire up gdb and get a good backtrace of the __bzero() address to find out which page handling in mpd exactly is hampered with crashes. This is now ~ the third patch that I applied on-the-go and that didn't help, so it's probably time to do some earnest analysis on what's really going on locally. Note that usb-storage itself does work on this platform though. Rather annoying to be so close (sound works) yet so far away, especially after all that USB host trouble I already had. Thanks a lot again, Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Paul Mundt on 1 Feb 2010 23:30 On Mon, Feb 01, 2010 at 03:14:04PM -0500, Alan Stern wrote: > On Mon, 1 Feb 2010, Catalin Marinas wrote: > > > On Fri, 2010-01-29 at 18:54 +0000, Matthew Dharm wrote: > > > HOWEVER, I firmly believe that the cache-management functions belong with > > > the driver that actually talks to the low-level hardware, as that's the > > > only place where you can be 100% certain of what cache operations are > > > needed. After all, I think someone is working on a USB-over-IP transport, > > > and trying to manage cache at the usb-storage level in that scenario is > > > just silly. > > > > > > So, let's put this in the HCD drivers and be done with it. > > > > The patch below is what fixes the I-D cache incoherency issues on ARM. I > > don't particularly like the solution but it seems to be the only one > > available. > > > > IMHO, Linux should have functions similar to the DMA API but for PIO > > drivers (e.g. pio_map_single/pio_unmap_single) that non-coherent > > architectures can define, otherwise being no-ops. Any thoughts? > > You should bring this up on the linux-arm-kernel mailing list and CC: > the ARM maintainer. They are the ones most directly affected. > No, this belongs on linux-arch, as it's something that impacts a lot of people besides ARM. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Paul Mundt on 2 Feb 2010 01:40 On Mon, Feb 01, 2010 at 05:29:14PM +0000, Catalin Marinas wrote: > On Fri, 2010-01-29 at 18:54 +0000, Matthew Dharm wrote: > > HOWEVER, I firmly believe that the cache-management functions belong with > > the driver that actually talks to the low-level hardware, as that's the > > only place where you can be 100% certain of what cache operations are > > needed. After all, I think someone is working on a USB-over-IP transport, > > and trying to manage cache at the usb-storage level in that scenario is > > just silly. > > > > So, let's put this in the HCD drivers and be done with it. > > The patch below is what fixes the I-D cache incoherency issues on ARM. I > don't particularly like the solution but it seems to be the only one > available. > > IMHO, Linux should have functions similar to the DMA API but for PIO > drivers (e.g. pio_map_single/pio_unmap_single) that non-coherent > architectures can define, otherwise being no-ops. Any thoughts? > I would certainly be in favour of such a thing, particularly since on SH we often find ourselves with coherent PIO and non-coherent MMIO. This is however something that should be prototyped and submitted to linux-arch for discussion. > diff --git a/drivers/usb/host/isp1760-hcd.c b/drivers/usb/host/isp1760-hcd.c > index 27b8f7c..4d3eeee 100644 > --- a/drivers/usb/host/isp1760-hcd.c > +++ b/drivers/usb/host/isp1760-hcd.c > @@ -18,6 +18,8 @@ > #include <linux/uaccess.h> > #include <linux/io.h> > #include <asm/unaligned.h> > +#include <asm/cacheflush.h> > +#include <asm/memory.h> > asm/memory.h isn't a portable header. If you are including it for virt_to_page(), linux/io.h should already bring that in via asm/io.h. If arm doesn't bring in virt_to_page() through its asm/io.h, then fix the headers there please. FWIW I used the same fix you came up with on r8a66597_hcd and it fixed up crashes we were seeing there, too. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Oliver Neukum on 2 Feb 2010 02:00
Am Montag, 1. Februar 2010 23:30:01 schrieb Andreas Mohr: > I took some time to add your patch to ehci-q.c / ohci-q.c > (for my *hci-ssb.c ASUS WL-500gP v2), on my now heavily patched-up 2.6.31.9, > but UNFORTUNATELY it kept locking up the same way as always when stopping > playback despite being damn sure this time that this patch could have > the potential to finally fix it ;) > (I had to replace memory.h with page.h on my arch though, to fix the build) A moment please. You are using ehci and ohci. Both are using dma. Why does this issue arise? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |