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: Andreas Mohr on 8 Feb 2010 02:40 Hi, On Mon, Feb 08, 2010 at 07:55:19AM +0100, Pavel Machek wrote: > Plus it does unneccessary flushes on x86, etc... Noticed that as well, there should be an arch-obeying helper for this. On my MIPSEL, I had urb->transfer_buffer NULL ptr crashes (I think that was expected in case of a certain DMA setup, Alan said). However, even with NULL check added I still had: hub 2-1.1:1.0: state 7 ports 7 chg 0000 evt 0010 Unhandled kernel unaligned access[#1]: Cpu 0 $ 0 : 00000000 fffffffd 803b0000 00010000 $ 4 : 08002042 8143bfe0 0043bfe0 0000000d $ 8 : 00000001 3b9aca00 c4653600 00000000 $12 : 00000049 3b9aca00 81dbc868 00000000 $16 : a1e00000 803b0000 8037f840 81dfaa80 $20 : 00000000 81dd5080 80000000 00000000 $24 : 00000000 80015a64 $28 : 8033a000 8033bc10 a1dd83cc 801da5e4 Hi : 00000000 Lo : 00000000 epc : 800171e8 __flush_dcache_page+0x38/0x120 Not tainted ra : 801da5e4 ehci_urb_done+0x180/0x1e4 Status: 10009002 KERNEL EXL Cause : 00800010 BadVA : 08002056 PrId : 00029029 (Broadcom BCM3302) Modules linked in: Process swapper (pid: 0, threadinfo=8033a000, task=8033c000, tls=00000000) Stack : 00000000 00000000 81e04980 801c80ac a1dd9060 a1dd8394 ffffff6a ffffff6a 81dfaa80 a1dd83cc a1dd8380 801db3a4 803a6a28 80068e9c 000003f8 00003fc0 a1dd81cc 801dea58 00000001 00000000 a1dd9360 81dd5080 a1dd8380 10009001 a1dd83cc 81dd5158 00000000 80318d44 81dd5158 00000001 00010031 801de8f4 81dd5158 8033bce0 803a76a0 803a0000 8033d860 8004f924 00000219 00000043 ... Call Trace: [<800171e8>] __flush_dcache_page+0x38/0x120 [<801da5e4>] ehci_urb_done+0x180/0x1e4 [<801db3a4>] qh_completions+0x484/0x554 [<801de8f4>] ehci_work+0x1ec/0xb68 [<801e2598>] ehci_irq+0x360/0x3a4 [<801c7cf8>] usb_hcd_irq+0x64/0x15c [<80066d58>] handle_IRQ_event+0x90/0x280 [<80068e80>] handle_percpu_irq+0x48/0x9c [<8000e228>] plat_irq_dispatch+0x15c/0x178 [<80001444>] ret_from_irq+0x0/0x4 [<80001680>] r4k_wait+0x20/0x40 [<8000fe34>] cpu_idle+0x30/0x60 [<80354a34>] start_kernel+0x338/0x350 Code: 00000000 10800029 3c02803b <8c820014> 14400026 3c02803b 8c83001c 2482001c 14620021 Disabling lock debugging due to kernel taint Kernel panic - not syncing: Fatal exception in interrupt Seems like BadVA : 08002056 really isn't as aligned (offset 0x6) as it should be. I've given up on this now BTW, I'll wait until the dust has settled (i.e. some nice improvements have found their way to the kernel) and retry in some months with a much newer kernel version (currently patched-up 2.6.31.9) whether something remains to be fixed. I'll work on more productive things such as submitting some waiting patches. 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: Catalin Marinas on 8 Feb 2010 05:00 Hi, On Mon, 2010-02-08 at 06:55 +0000, Pavel Machek wrote: > > > 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. > > Really? It looks like arm should just flush the caches when mapping > executable page to the userspace.... you can't expect all the drivers > to be modified like that... We could of course flush the caches every time we get a page fault but that's far from optimal, especially since DMA-capable drivers to do not pollute the D-cache and don't need this extra flushing. Note that the recent ARM processors have PIPT caches but separate for I and D and it's the PIO drivers that pollute the D-cache. The kernel API provides flush_dcache_page() to be called every time the kernel writes to a page cache page. This is further optimised for working in pair with update_mmu_cache() to delay the flushing until the actual page is mapped into user space and this latter function is called (which in general is not a cache maintenance function). The problem with some PIO drivers and a filesystems like ext2 is that there is no call to flush_dcache_page() when getting data into a page cache page. Since the page isn't marked as dirty (PG_arch_1), a subsequent call to update_mmu_cache() as a result of a page fault doesn't flush the caches. There is a flush_icache_page() function called from __do_fault(), however, Documentation/cachetlb.txt states that all the functionality of this function can be implemented in flush_dcache_page() and update_mmu_cache(), hence this function is a no-op. Please suggest a better solution that does not involve modifying generic Linux code. > Plus it does unneccessary flushes on x86, etc... On x86, it should indeed be conditionally compiled based on ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE. Regards. -- Catalin -- 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: Andy Green on 8 Feb 2010 05:10 On 02/08/10 10:51, Somebody in the thread at some point said: > We could of course flush the caches every time we get a page fault but > that's far from optimal, especially since DMA-capable drivers to do not > pollute the D-cache and don't need this extra flushing. Note that the > recent ARM processors have PIPT caches but separate for I and D and it's > the PIO drivers that pollute the D-cache. Just noting that AFAIK iMX31 USB and MMC drivers both are PIO at the moment, for lack of any platform DMA support of its unusual DMA engine. -Andy -- 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: Catalin Marinas on 8 Feb 2010 05:30 On Mon, 2010-02-08 at 07:33 +0000, Andreas Mohr wrote: > On Mon, Feb 08, 2010 at 07:55:19AM +0100, Pavel Machek wrote: > > Plus it does unneccessary flushes on x86, etc... > > Noticed that as well, there should be an arch-obeying helper for this. > > > On my MIPSEL, I had urb->transfer_buffer NULL ptr crashes > (I think that was expected in case of a certain DMA setup, Alan said). > > However, even with NULL check added I still had: > > hub 2-1.1:1.0: state 7 ports 7 chg 0000 evt 0010 > Unhandled kernel unaligned access[#1]: Just to avoid confusion - that's a similar patch applied to a different driver. The ISP1760 HCD driver works fine with my patch (transfer_buffer never seems to be NULL with latest mainline). I can't comment on the ehci-q.c driver (it looks like it has some support for DMA while my patch only applies to PIO drivers where transfer_buffer should be set). -- Catalin -- 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: Pavel Machek on 8 Feb 2010 06:00
> Hi, > > On Mon, 2010-02-08 at 06:55 +0000, Pavel Machek wrote: > > > > 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. > > > > Really? It looks like arm should just flush the caches when mapping > > executable page to the userspace.... you can't expect all the drivers > > to be modified like that... > > We could of course flush the caches every time we get a page fault but > that's far from optimal, especially since DMA-capable drivers to do > not Maybe far for optimal, but it is something that should be done, _first_. Correctness is more important than performance, and you can't expect all drivers to behave like you want them. Then you can add optimalizations not to do the flushes on drivers you audited and where you care... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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/ |