Hi,
I am trying to boot linux on SMP system with root file system(ext2) on eMMC.
The eMMC is partitioned in 3 parts and I am trying to use 2nd
partition of 128M to keep
the rootfs.
The command line used is:
Kernel command line: cachepolicy=writealloc noinitrd
root=/dev/mmcblk0p2 rootfstype=ext2 rootdelay=1 init=/bin/sh rw
console=ttyAMA2,115200n8 mem=128M
After mounting the rootfs in eMMC, it panics.
Panic log as below. When I traced, I observed it fails while its
execution "run_init_process"
I have tried with different init process,i.e. init=/linuxrc,
init=/bin/busybox, init=/sbin/init
Even I tried initramfs and the switch_root/pivot_root to rootfs on
eMMC partition.
In all the cases, I got the same panic.
Can anybody help me in understanding the exact reason for this panic?
Panic Log:
DRIVER MMC: probe
Waiting 1sec before mounting root device...
mmc0: new MMC card at address 0001
mmcblk0: mmc0:0001 M8G4DD 8028160KiB
mmcblk0: p1 p2 p3
VFS: Mounted root (ext2 filesystem).
Freeing init memory: 108K
Kernel panic - not syncing: Attempted to kill init!
CPU0: stopping
[<c0028950>] (dump_stack+0x0/0x14) from [<c0023384>] (do_IPI+0xd4/0x140)
[<c00232b0>] (do_IPI+0x0/0x140) from [<c0023a88>] (__irq_svc+0x48/0xdc)
Exception stack(0xc01fdf40 to 0xc01fdf88)
df40: 00000000 c01fc000 c01fdf88 00000000 c0025754 c01fc000 00322000 00000004
df60: c001d000 410fc090 c001dfc0 c01fdf94 c01fdf98 c01fdf88 c0025794 c0025798
df80: 60000013 ffffffff
r9:c01fc000 r8:00000001 r7:00000002 r6:00000401 r5:f0410100
r4:ffffffff
[<c0025754>] (default_idle+0x0/0x4c) from [<c0025634>] (cpu_idle+0x64/0x94)
[<c00255d0>] (cpu_idle+0x0/0x94) from [<c018666c>] (rest_init+0x6c/0x80)
r5:c02188dc r4:c0225358
[<c0186600>] (rest_init+0x0/0x80) from [<c0008bf4>] (start_kernel+0x2f0/0x358)
[<c0008904>] (start_kernel+0x0/0x358) from [<0000807c>] (0x807c)
--
Regards,
Sudeep
On Thu, Jun 18, 2009 at 02:48:10PM +0530, Sudeep K N wrote:
> After mounting the rootfs in eMMC, it panics.
> Panic log as below. When I traced, I observed it fails while its
> execution "run_init_process"
> I have tried with different init process,i.e. init=/linuxrc,
> init=/bin/busybox, init=/sbin/init
> Even I tried initramfs and the switch_root/pivot_root to rootfs on
> eMMC partition.
> In all the cases, I got the same panic.
> Can anybody help me in understanding the exact reason for this panic?
Enable CONFIG_DEBUG_USER and pass user_debug=31 - that should get
more detail on the problem that's killing init.
Hi Russell,
Thanks for the suggestion.
With the logs it is clear that crash is in the userspace.
I am getting one of the 2 logs(below) randomly.
>From trial#2,
pgd = c60bc000
[00000000] *pgd=061ee031, *pte=00000000, *ppte=00000000
I could understand that the page tables are not proper.
I am not able understand how to proceed.
Trial#1:
VFS: Mounted root (ext2 filesystem).
Freeing init memory: 108K
linuxrc (1): undefined instruction: pc=40008100
Code: e08e3003 eb002842 e2801008 e58c217c (e0812103)
Kernel panic - not syncing: Attempted to kill init!
CPU0: stopping
[<c0028950>] (dump_stack+0x0/0x14) from [<c0023384>] (do_IPI+0xd4/0x140)
[<c00232b0>] (do_IPI+0x0/0x140) from [<c0023a88>] (__irq_svc+0x48/0xdc)
Exception stack(0xc01fbf40 to 0xc01fbf88)
bf40: 00000000 c01fa000 c01fbf88 00000000 c0025754 c01fa000 00320000 00000004
bf60: c001d000 410fc090 c001dfc0 c01fbf94 c01fbf98 c01fbf88 c0025794 c0025798
bf80: 60000013 ffffffff
r9:c01fa000 r8:00000001 r7:00000002 r6:00000401 r5:f0410100 r4:ffffffff
[<c0025754>] (default_idle+0x0/0x4c) from [<c0025634>] (cpu_idle+0x64/0x94)
[<c00255d0>] (cpu_idle+0x0/0x94) from [<c0184d38>] (rest_init+0x6c/0x80)
r5:c021691c r4:c0223398
[<c0184ccc>] (rest_init+0x0/0x80) from [<c0008bf4>] (start_kernel+0x2f0/0x358)
[<c0008904>] (start_kernel+0x0/0x358) from [<0000807c>] (0x807c)
Trial#2:
VFS: Mounted root (ext2 filesystem).
Freeing init memory: 108K
pgd = c60bc000
[00000000] *pgd=061ee031, *pte=00000000, *ppte=00000000
Pid: 1, comm: linuxrc
BUG: using smp_processor_id() in preemptible [00000000] code: linuxrc/1
caller is __show_regs+0x18/0x238
[<c0028950>] (dump_stack+0x0/0x14) from [<c0116120>]
(debug_smp_processor_id+0xb8/0xdc)
[<c0116068>] (debug_smp_processor_id+0x0/0xdc) from [<c00253b0>]
(__show_regs+0x18/0x238)
r7:00000017 r6:0000000b r5:00000000 r4:c6029fb0
[<c0025398>] (__show_regs+0x0/0x238) from [<c00256ec>] (show_regs+0x40/0x50)
[<c00256ac>] (show_regs+0x0/0x50) from [<c002ad88>] (__do_user_fault+0x5c/0xa4)
r5:00000000 r4:c6024cc0
[<c002ad2c>] (__do_user_fault+0x0/0xa4) from [<c002b050>]
(do_page_fault+0x204/0x23c)
r7:c61f1e14 r6:c61165a0 r5:c6024cc0 r4:00010000
[<c002ae4c>] (do_page_fault+0x0/0x23c) from [<c0023448>]
(do_DataAbort+0x3c/0xa0)
[<c002340c>] (do_DataAbort+0x0/0xa0) from [<c0023ea0>]
(ret_from_exception+0x0/0x10)
Exception stack(0xc6029fb0 to 0xc6029ff8)
9fa0: 00000000 40021000 20000000 40020e08
9fc0: 00000000 00000050 40021000 00000000 00000000 00000001 00000000 bef31c54
9fe0: 00000000 bef31980 400090d4 40009100 00000010 ffffffff
r8:00000000 r7:00000000 r6:40021000 r5:00000050 r4:ffffffff
CPU: 1 Not tainted (2.6.27 #3)
PC is at 0x40009100
LR is at 0x400090d4
pc : [<40009100>] lr : [<400090d4>] psr: 00000010
sp : bef31980 ip : 00000000 fp : bef31c54
r10: 00000000 r9 : 00000001 r8 : 00000000
r7 : 00000000 r6 : 40021000 r5 : 00000050 r4 : 00000000
r3 : 40020e08 r2 : 20000000 r1 : 40021000 r0 : 00000000
Flags: nzcv IRQs on FIQs on Mode USER_32 ISA ARM Segment user
Control: 00c5387f Table: 060bc00b DAC: 00000015
[<c00256ac>] (show_regs+0x0/0x50) from [<c002ad88>] (__do_user_fault+0x5c/0xa4)
r5:00000000 r4:c6024cc0
[<c002ad2c>] (__do_user_fault+0x0/0xa4) from [<c002b050>]
(do_page_fault+0x204/0x23c)
r7:c61f1e14 r6:c61165a0 r5:c6024cc0 r4:00010000
[<c002ae4c>] (do_page_fault+0x0/0x23c) from [<c0023448>]
(do_DataAbort+0x3c/0xa0)
[<c002340c>] (do_DataAbort+0x0/0xa0) from [<c0023ea0>]
(ret_from_exception+0x0/0x10)
Exception stack(0xc6029fb0 to 0xc6029ff8)
9fa0: 00000000 40021000 20000000 40020e08
9fc0: 00000000 00000050 40021000 00000000 00000000 00000001 00000000 bef31c54
9fe0: 00000000 bef31980 400090d4 40009100 00000010 ffffffff
r8:00000000 r7:00000000 r6:40021000 r5:00000050 r4:ffffffff
Kernel panic - not syncing: Attempted to kill init!
CPU0: stopping
[<c0028950>] (dump_stack+0x0/0x14) from [<c0023384>] (do_IPI+0xd4/0x140)
[<c00232b0>] (do_IPI+0x0/0x140) from [<c0023a88>] (__irq_svc+0x48/0xdc)
Exception stack(0xc01fbf40 to 0xc01fbf88)
bf40: 00000000 c01fa000 c01fbf88 00000000 c0025754 c01fa000 00320000 00000004
bf60: c001d000 410fc090 c001dfc0 c01fbf94 c01fbf98 c01fbf88 c0025794 c0025798
bf80: 60000013 ffffffff
r9:c01fa000 r8:00000001 r7:00000002 r6:00000401 r5:f0410100 r4:ffffffff
[<c0025754>] (default_idle+0x0/0x4c) from [<c0025634>] (cpu_idle+0x64/0x94)
[<c00255d0>] (cpu_idle+0x0/0x94) from [<c0184d38>] (rest_init+0x6c/0x80)
r5:c021691c r4:c0223398
[<c0184ccc>] (rest_init+0x0/0x80) from [<c0008bf4>] (start_kernel+0x2f0/0x358)
[<c0008904>] (start_kernel+0x0/0x358) from [<0000807c>] (0x807c)
On Fri, Jun 19, 2009 at 7:14 PM, Russell King - ARM
Linux<[email protected]> wrote:
> On Thu, Jun 18, 2009 at 02:48:10PM +0530, Sudeep K N wrote:
>> After mounting the rootfs in eMMC, it panics.
>> Panic log as below. ?When I traced, I observed it fails while its
>> execution "run_init_process"
>> I have tried with different init process,i.e. init=/linuxrc,
>> init=/bin/busybox, init=/sbin/init
>> Even I tried initramfs and the switch_root/pivot_root to rootfs on
>> eMMC partition.
>> In all the cases, I got the same panic.
>> Can anybody help me in understanding the exact reason for this panic?
>
> Enable CONFIG_DEBUG_USER and pass user_debug=31 - that should get
> more detail on the problem that's killing init.
>
--
Regards,
Sudeep
On Mon, 2009-06-22 at 19:43 +0530, Sudeep K N wrote:
> Thanks for the suggestion.
> With the logs it is clear that crash is in the userspace.
> I am getting one of the 2 logs(below) randomly.
This sounds familiar: SMP -> writealloc cache policy (could be forced by
hardware) -> cache corruption in user space with ext2.
Does you driver use the DMA API? If not, does your eMMC driver flush the
cache (in case you hit one of the long-standing problems with PIO
drivers).
It's worth trying this hack:
http://article.gmane.org/gmane.linux.ports.arm.kernel/51556
--
Catalin
On Mon, 2009-06-22 at 15:26 +0100, Catalin Marinas wrote:
> On Mon, 2009-06-22 at 19:43 +0530, Sudeep K N wrote:
> > Thanks for the suggestion.
> > With the logs it is clear that crash is in the userspace.
> > I am getting one of the 2 logs(below) randomly.
>
> This sounds familiar: SMP -> writealloc cache policy (could be forced by
> hardware) -> cache corruption in user space with ext2.
>
> Does you driver use the DMA API? If not, does your eMMC driver flush the
> cache (in case you hit one of the long-standing problems with PIO
> drivers).
>
> It's worth trying this hack:
>
> http://article.gmane.org/gmane.linux.ports.arm.kernel/51556
To be more precise:
If your system is ARM11MPCore based and your driver uses DMA, try this
patch (in-software DMA cache maintenance operations broadcasting):
http://www.linux-arm.org/git?p=linux-2.6-stable.git;a=commitdiff_plain;h=95298b1792121e7068258de451caec7f3dda0e78
If your driver is a PIO one, try this patch (flush_dcache_page called in
the VFS layer):
http://www.linux-arm.org/git?p=linux-2.6-stable.git;a=commitdiff_plain;h=d763f5815aa21095141c3ba87011906a61505dad
--
Catalin
On Mon, Jun 22, 2009 at 07:43:40PM +0530, Sudeep K N wrote:
> Hi Russell,
>
> Thanks for the suggestion.
> With the logs it is clear that crash is in the userspace.
> I am getting one of the 2 logs(below) randomly.
> >From trial#2,
> pgd = c60bc000
> [00000000] *pgd=061ee031, *pte=00000000, *ppte=00000000
> I could understand that the page tables are not proper.
> I am not able understand how to proceed.
>
> Trial#1:
> VFS: Mounted root (ext2 filesystem).
> Freeing init memory: 108K
> linuxrc (1): undefined instruction: pc=40008100
> Code: e08e3003 eb002842 e2801008 e58c217c (e0812103)
Your processor is misbehaving; none of the above hex codes are undefined
instructions, so you shouldn't be taking an undefined instruction trap.
That, coupled with the random nature of these crashes leads me to believe
that it's a case of noisy power supply to the SoC. Suggest you get your
hardware people to check your board.
On Mon, 2009-06-22 at 16:43 +0100, Russell King - ARM Linux wrote:
> On Mon, Jun 22, 2009 at 07:43:40PM +0530, Sudeep K N wrote:
> > Thanks for the suggestion.
> > With the logs it is clear that crash is in the userspace.
> > I am getting one of the 2 logs(below) randomly.
> > >From trial#2,
> > pgd = c60bc000
> > [00000000] *pgd=061ee031, *pte=00000000, *ppte=00000000
> > I could understand that the page tables are not proper.
> > I am not able understand how to proceed.
> >
> > Trial#1:
> > VFS: Mounted root (ext2 filesystem).
> > Freeing init memory: 108K
> > linuxrc (1): undefined instruction: pc=40008100
> > Code: e08e3003 eb002842 e2801008 e58c217c (e0812103)
>
> Your processor is misbehaving; none of the above hex codes are undefined
> instructions, so you shouldn't be taking an undefined instruction trap.
The undefined instruction aborts are possible in this situation since
instructions are fetched via the I-cache while the abort handler shows
the code via the D-cache.
--
Catalin
On Mon, Jun 22, 2009 at 04:50:46PM +0100, Catalin Marinas wrote:
> On Mon, 2009-06-22 at 16:43 +0100, Russell King - ARM Linux wrote:
> > On Mon, Jun 22, 2009 at 07:43:40PM +0530, Sudeep K N wrote:
> > > Thanks for the suggestion.
> > > With the logs it is clear that crash is in the userspace.
> > > I am getting one of the 2 logs(below) randomly.
> > > >From trial#2,
> > > pgd = c60bc000
> > > [00000000] *pgd=061ee031, *pte=00000000, *ppte=00000000
> > > I could understand that the page tables are not proper.
> > > I am not able understand how to proceed.
> > >
> > > Trial#1:
> > > VFS: Mounted root (ext2 filesystem).
> > > Freeing init memory: 108K
> > > linuxrc (1): undefined instruction: pc=40008100
> > > Code: e08e3003 eb002842 e2801008 e58c217c (e0812103)
> >
> > Your processor is misbehaving; none of the above hex codes are undefined
> > instructions, so you shouldn't be taking an undefined instruction trap.
>
> The undefined instruction aborts are possible in this situation since
> instructions are fetched via the I-cache while the abort handler shows
> the code via the D-cache.
However, you're missing a very important point.
This early on, the I-cache for the non-kernel pages won't contain any
entries except those placed there by this first binary - it's the very
first user process which is receiving these exceptions.
Second point is that the page concerned has only recently been mapped
into that page. I would be very very surprised if speculative
instruction prefetch managed to dirty the exact right page via the
kernel mapping to always cause the first process to fail in some way.
On Mon, 2009-06-22 at 16:56 +0100, Russell King - ARM Linux wrote:
> On Mon, Jun 22, 2009 at 04:50:46PM +0100, Catalin Marinas wrote:
> > On Mon, 2009-06-22 at 16:43 +0100, Russell King - ARM Linux wrote:
> > > On Mon, Jun 22, 2009 at 07:43:40PM +0530, Sudeep K N wrote:
> > > > Thanks for the suggestion.
> > > > With the logs it is clear that crash is in the userspace.
> > > > I am getting one of the 2 logs(below) randomly.
> > > > >From trial#2,
> > > > pgd = c60bc000
> > > > [00000000] *pgd=061ee031, *pte=00000000, *ppte=00000000
> > > > I could understand that the page tables are not proper.
> > > > I am not able understand how to proceed.
> > > >
> > > > Trial#1:
> > > > VFS: Mounted root (ext2 filesystem).
> > > > Freeing init memory: 108K
> > > > linuxrc (1): undefined instruction: pc=40008100
> > > > Code: e08e3003 eb002842 e2801008 e58c217c (e0812103)
> > >
> > > Your processor is misbehaving; none of the above hex codes are undefined
> > > instructions, so you shouldn't be taking an undefined instruction trap.
> >
> > The undefined instruction aborts are possible in this situation since
> > instructions are fetched via the I-cache while the abort handler shows
> > the code via the D-cache.
>
> However, you're missing a very important point.
Well, I get this kind of errors (with /sbin/init) every time I try ext2
on CompactFlash (with pata_platform). You could try with USB as well on
a RealView/EB+ARM11MPCore board.
> This early on, the I-cache for the non-kernel pages won't contain any
> entries except those placed there by this first binary - it's the very
> first user process which is receiving these exceptions.
The problem is not the I-cache, it is just fetched from the main memory.
> Second point is that the page concerned has only recently been mapped
> into that page. I would be very very surprised if speculative
> instruction prefetch managed to dirty the exact right page via the
> kernel mapping to always cause the first process to fail in some way.
This has nothing to do with speculative prefetching. It's just that the
I-cache is being filled with data from main memory but the D-cache
wasn't flushed (on ARM SMP systems, the D-cache is write-allocate making
this more visible).
Could you or Sudeep clarify whether the driver uses DMA or PIO?
In my case (ext2 over pata_platform), there is no flush_dcache_page()
call after the page was written with data from the CompactFlash (neither
the driver nor the VFS layer do this and we used hardware tracing to
double-check). When the page is mapped into user space,
update_mmu_cache() is called but the page hasn't been marked as dirty
and no D-cache flushing occurs. Calling flush_dcache_page() in
mpage_end_io_read() works around this issue.
--
Catalin
On Mon, Jun 22, 2009 at 05:13:16PM +0100, Catalin Marinas wrote:
> Well, I get this kind of errors (with /sbin/init) every time I try ext2
> on CompactFlash (with pata_platform). You could try with USB as well on
> a RealView/EB+ARM11MPCore board.
Is USB now usable on the rev.B board I have?
> Could you or Sudeep clarify whether the driver uses DMA or PIO?
If I knew what this "eMMC" was...
> In my case (ext2 over pata_platform), there is no flush_dcache_page()
> call after the page was written with data from the CompactFlash (neither
> the driver nor the VFS layer do this and we used hardware tracing to
> double-check). When the page is mapped into user space,
> update_mmu_cache() is called but the page hasn't been marked as dirty
> and no D-cache flushing occurs. Calling flush_dcache_page() in
> mpage_end_io_read() works around this issue.
As already covered, there's no chance of adding such a call to the
generic kernel. It's the responsibility of the drivers to ensure that
data they read in hits the underlying page - in the same way that DMA
does.
On Mon, 2009-06-22 at 17:46 +0100, Russell King - ARM Linux wrote:
> On Mon, Jun 22, 2009 at 05:13:16PM +0100, Catalin Marinas wrote:
> > Could you or Sudeep clarify whether the driver uses DMA or PIO?
>
> If I knew what this "eMMC" was...
The only eMMC reference I could find is the omap_hsmmc.c driver.
>
> > In my case (ext2 over pata_platform), there is no flush_dcache_page()
> > call after the page was written with data from the CompactFlash (neither
> > the driver nor the VFS layer do this and we used hardware tracing to
> > double-check). When the page is mapped into user space,
> > update_mmu_cache() is called but the page hasn't been marked as dirty
> > and no D-cache flushing occurs. Calling flush_dcache_page() in
> > mpage_end_io_read() works around this issue.
>
> As already covered, there's no chance of adding such a call to the
> generic kernel. It's the responsibility of the drivers to ensure that
> data they read in hits the underlying page - in the same way that DMA
> does.
I'm not proposing to add this call. My patch is a hack to get things
working with any PIO driver. I just wanted to point to the problem I
think Sudeep encountered.
(to summarise for LKML) As it was mentioned in the past, most PIO
drivers don't do any cache flushing. In the mmci.c driver you added a
flush_dcache_call() but other block device drivers only get a pointer to
a buffer and don't have direct access to a struct page pointer. Using
virt_to_page(buffer) may help a bit but the driver would need to
reconstruct the page structures already known to code like fs/mpage.c.
There is also a bio_page() function but I'm not familiar enough with
block device drivers to suggest the best approach.
--
Catalin
> Could you or Sudeep clarify whether the driver uses DMA or PIO?
>
I have option to use both. I tried you patch(rather hack) for PIO mode i.e
(flush_dcache_page called in the VFS layer). This solves the crash in polling
mode. I need to work for proper way of flushing in the MMC driver.
I am yet to try with DMA as I am not much familiar with the DMA driver and
need some time.
> In my case (ext2 over pata_platform), there is no flush_dcache_page()
> call after the page was written with data from the CompactFlash (neither
> the driver nor the VFS layer do this and we used hardware tracing to
> double-check). When the page is mapped into user space,
> update_mmu_cache() is called but the page hasn't been marked as dirty
> and no D-cache flushing occurs. Calling flush_dcache_page() in
> mpage_end_io_read() works around this issue.
Looks like the crash I am getting is similar to one you are explaining with
your experience with CF cards.
Thanks to both Catalin and Russell for making such a informative discussion on
ARM SMP and related cache know hows.
--
Regards,
Sudeep
2009/6/22 Russell King - ARM Linux <[email protected]>:
> If I knew what this "eMMC" was...
It's to be read out "embedded MultiMediaCard", comes
from JEDEC but is based on the standard from MMCA.
Just as it says, it's like an MMC card you embed.
It uses lower voltages than MMC and thus save some
power. It doesn't look like an MMC card either, it comes
in a standardized solder-on BGA package so it looks
like any chip, no expensive card holders. It uses 8bit wide
transfers giving a total of 10 pins for the bus.
(Plus voltage of course.)
But usually you reuse a standard MMC hardware IP
to talk to it.
Here is some whitepaper:
http://www.jedec.org/download/search/JESD84-C43.pdf
Linus Walleij
On Mon, 2009-06-22 at 17:46 +0100, Russell King - ARM Linux wrote:
> On Mon, Jun 22, 2009 at 05:13:16PM +0100, Catalin Marinas wrote:
> > In my case (ext2 over pata_platform), there is no flush_dcache_page()
> > call after the page was written with data from the CompactFlash (neither
> > the driver nor the VFS layer do this and we used hardware tracing to
> > double-check). When the page is mapped into user space,
> > update_mmu_cache() is called but the page hasn't been marked as dirty
> > and no D-cache flushing occurs. Calling flush_dcache_page() in
> > mpage_end_io_read() works around this issue.
>
> As already covered, there's no chance of adding such a call to the
> generic kernel. It's the responsibility of the drivers to ensure that
> data they read in hits the underlying page - in the same way that DMA
> does.
The patch below appears to solve the problem with CompactFlash using
pata_platform (I cc'ed linux-ide since the patch changes their code).
The patch only handles the read case but similarly it may need to handle
the write case if D-cache aliasing between user and kernel mappings
exists.
For the USB mass storage, I haven't yet figured out the best place to
call flush_dcache_page().
Call flush_dcache_page after PIO data transfer in libata-aff.c
From: Catalin Marinas <[email protected]>
When reading data from an ATA device using PIO, the kernel dirties the
D-cache but there is no flush_dcache_page() call in ata_pio_sector().
Since neither the VFS layer calls this function, a subsequent
update_mmu_cache() is not aware of the dirty page which may lead to
cache incoherency in user space.
Signed-off-by: Catalin Marinas <[email protected]>
---
drivers/ata/libata-sff.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index bbbb1fa..2ae15c3 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -893,6 +893,9 @@ static void ata_pio_sector(struct ata_queued_cmd *qc)
do_write);
}
+ if (!do_write)
+ flush_dcache_page(page);
+
qc->curbytes += qc->sect_size;
qc->cursg_ofs += qc->sect_size;
--
Catalin
On Mon, Jul 13, 2009 at 05:44:00PM +0200, Dirk Behme wrote:
> Hi Catalin,
>
> Catalin Marinas wrote:
>> On Mon, 2009-06-22 at 17:46 +0100, Russell King - ARM Linux wrote:
>>> On Mon, Jun 22, 2009 at 05:13:16PM +0100, Catalin Marinas wrote:
>>>> In my case (ext2 over pata_platform), there is no flush_dcache_page()
>>>> call after the page was written with data from the CompactFlash (neither
>>>> the driver nor the VFS layer do this and we used hardware tracing to
>>>> double-check). When the page is mapped into user space,
>>>> update_mmu_cache() is called but the page hasn't been marked as dirty
>>>> and no D-cache flushing occurs. Calling flush_dcache_page() in
>>>> mpage_end_io_read() works around this issue.
>>> As already covered, there's no chance of adding such a call to the
>>> generic kernel. It's the responsibility of the drivers to ensure that
>>> data they read in hits the underlying page - in the same way that DMA
>>> does.
>>
>> The patch below appears to solve the problem with CompactFlash using
>> pata_platform (I cc'ed linux-ide since the patch changes their code).
>> The patch only handles the read case but similarly it may need to handle
>> the write case if D-cache aliasing between user and kernel mappings
>> exists.
>>
>> For the USB mass storage, I haven't yet figured out the best place to
>> call flush_dcache_page().
>
> Any news regarding USB mass storage on ARM MPCore? Else this would mean
> that USB mass storage (USB stick, USB disk) formatted with ext2/3/4
> wouldn't work with MPCore?
USB normally uses DMA, so should be unaffected by this issue.
Hi Catalin,
Catalin Marinas wrote:
> On Mon, 2009-06-22 at 17:46 +0100, Russell King - ARM Linux wrote:
>> On Mon, Jun 22, 2009 at 05:13:16PM +0100, Catalin Marinas wrote:
>>> In my case (ext2 over pata_platform), there is no flush_dcache_page()
>>> call after the page was written with data from the CompactFlash (neither
>>> the driver nor the VFS layer do this and we used hardware tracing to
>>> double-check). When the page is mapped into user space,
>>> update_mmu_cache() is called but the page hasn't been marked as dirty
>>> and no D-cache flushing occurs. Calling flush_dcache_page() in
>>> mpage_end_io_read() works around this issue.
>> As already covered, there's no chance of adding such a call to the
>> generic kernel. It's the responsibility of the drivers to ensure that
>> data they read in hits the underlying page - in the same way that DMA
>> does.
>
> The patch below appears to solve the problem with CompactFlash using
> pata_platform (I cc'ed linux-ide since the patch changes their code).
> The patch only handles the read case but similarly it may need to handle
> the write case if D-cache aliasing between user and kernel mappings
> exists.
>
> For the USB mass storage, I haven't yet figured out the best place to
> call flush_dcache_page().
Any news regarding USB mass storage on ARM MPCore? Else this would
mean that USB mass storage (USB stick, USB disk) formatted with
ext2/3/4 wouldn't work with MPCore?
Many thanks and best regards
Dirk
On Mon, 2009-07-13 at 17:44 +0200, Dirk Behme wrote:
> Catalin Marinas wrote:
> > The patch below appears to solve the problem with CompactFlash using
> > pata_platform (I cc'ed linux-ide since the patch changes their code).
> > The patch only handles the read case but similarly it may need to handle
> > the write case if D-cache aliasing between user and kernel mappings
> > exists.
> >
> > For the USB mass storage, I haven't yet figured out the best place to
> > call flush_dcache_page().
>
> Any news regarding USB mass storage on ARM MPCore? Else this would
> mean that USB mass storage (USB stick, USB disk) formatted with
> ext2/3/4 wouldn't work with MPCore?
On the ARM RealView boards, the USB is PIO rather than DMA-capable. I
posted this patch on the list here (but have to follow up with the
maintainers):
http://lists.arm.linux.org.uk/lurker/message/20090710.130032.bfb8b218.en.html
--
Catalin