On Sun, Jun 04, 2006 at 12:41:19PM +0900, Tejun Heo wrote: > Russell, can you please verify arm's flush_kernel_dcache_page()? That should be fine from a theoretical standpoint, but I can't say much more than that - I have _great_ difficulty in reproducing the problem with IDE and as such I consider myself out of the game of testing for this problem: | Date: Fri, 13 Jan 2006 22:02:15 +0000 | From: Russell King <rmk+lkml@xxxxxxxxxxxxxxxx> | To: Tejun Heo <htejun@xxxxxxxxx> | Subject: Re: [PATCHSET] block: fix PIO cache coherency bug | | On Sat, Jan 14, 2006 at 12:24:16AM +0900, Tejun Heo wrote: | > Russell, can you please test whether this fixes the bug on arm? If | > this fixes the bug and people agree with the approach, I'll follow up | > with patches for yet unconverted drivers and documentation update. | | Unfortunately, as I previously explained, I'm not able to test this. | The reason is that in order to reproduce the bug, you need a system | with a VIVT write-back write-allocate cache. | | Unfortunately, the few systems I have which have such a cache do not | have IDE, SCSI nor SATA (not even PCMCIA.) I suggest contacting the | folk who reported the bug in the first instance. You need to approach other members of the ARM community to test these patches. Unfortunately I don't have a list of who has found the problem and who is in a state to be able to reproduce it - since most members are embedded engineers, they tend to move on to other projects quite rapidly. What I suggest is that we just throw _something_ which looks right into the kernel and see what happens. I can't see any other possible way to proceed, _especially_ as we've had 6 months of very little progress on this issue. > I tried to implement flush_anon_page() too but didn't know what to do > with anon_vma object. I'm not sure what this is about... -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html