The KW has the same VIVT cache like the 78200, I have been using Marvell LSP
220.127.116.11 based without any issue with XFS.
The problem I am seeing is with mainline (not 18.104.22.168), have you posted your
changes back to Marvell?
From: Richard Sharpe [mailto:realrichardsharpe@xxxxxxxxx]
Sent: Sunday, November 22, 2009 10:17 PM
To: Ofer Heifetz
Cc: Eric Sandeen; xfs@xxxxxxxxxxx
Subject: Re: XFS support for ARMv5
On Sun, Nov 22, 2009 at 12:07 PM, Ofer Heifetz <oferh@xxxxxxxxxxx> wrote:
> Hi Richard,
> Regarding the CPU, yes it is Marvell SoC 6281(Kirkwood).
> I am questioning where do you propose using flush_icache_range?
> Did you use it accompanied with the patch Eric posted?
OK, I was working with the 78200, but if the 6281 has a VIVT cache
like the 78200, then the same issue might be at work.
Indeed, we had to add flush-dcache-page when we copied date to
page-cache pages in our SCSI LLD to fix the first corruption problem
we saw, which occasionally caused XFS corruption, and eventually had
to add flush-icache-range, also to our SCSI LLD.
I hasten to point out (and that was in my last sentence in my first
reply) that we saw the problems in our SCSI LLD and did not do
anything in XFS. Indeed, we are working with a very old version of
Linux and XFS, 22.214.171.124, because that is what is supported by
Our issue was in moving data from a non-cached region to page-cache
pages (which are cached), but that is dictated to us by our inter-core
architecture (the 78200 is a dual-core architecture but does not have
a snooping cache).
> Regarding dmesg, I am using serial console (ttyS0) and am not @ work, but I
> figure that is all dmesg will have, if there is more I will send tomorrow.
> -----Original Message-----
> From: Richard Sharpe [mailto:realrichardsharpe@xxxxxxxxx]
> Sent: Sunday, November 22, 2009 6:45 PM
> To: Ofer Heifetz
> Cc: Eric Sandeen; xfs@xxxxxxxxxxx
> Subject: Re: XFS support for ARMv5
> On Sun, Nov 22, 2009 at 8:20 AM, Ofer Heifetz <oferh@xxxxxxxxxxx> wrote:
>> Hi Eric,
>> I have tried the patch you advised and still get the same error using
>> 126.96.36.199, xfs version 2.10.2 on Ubuntu 9.04.
>> Any other suggestions you think that might help me with this?
> If it is a Marvell chip, we eventually found that we had to add
> flush_icache_range, although we were doing that in our SCSI_LLD.
>> -----Original Message-----
>> From: Eric Sandeen [mailto:sandeen@xxxxxxxxxxx]
>> Sent: Wednesday, November 18, 2009 6:04 PM
>> To: Ofer Heifetz
>> Cc: xfs@xxxxxxxxxxx
>> Subject: Re: XFS support for ARMv5
>> oferh@xxxxxxxxxxx wrote:
>>> I have noticed that XFS on ARMv5TE with latest kernel (188.8.131.52)
>>> fails to mount after copying some data and reboot the system.
>>> I get "mount: /dev/sda1: can't read superblock", I understand that
>>> there were some problems with virtual aliasing that was added to XFS
>>> some time ago but ARM arch has not dealt with this properly.
>> when you get that error from mount, look at dmesg to see what really went
>> wrong ...
>>> Is there any patch for this bug?
>> This is a big-hammer approach for the aliasing problem:
>> Index: linux-2.6.25-rc1/fs/xfs/linux-2.6/xfs_buf.c
>> --- linux-2.6.25-rc1.orig/fs/xfs/linux-2.6/xfs_buf.c
>> +++ linux-2.6.25-rc1/fs/xfs/linux-2.6/xfs_buf.c
>> @@ -1172,6 +1172,7 @@ _xfs_buf_ioapply(
>> bio->bi_end_io = xfs_buf_bio_end_io;
>> bio->bi_private = bp;
>> + flush_dcache_page(bp->b_pages);
>> bio_add_page(bio, bp->b_pages, PAGE_CACHE_SIZE, 0);
>> size = 0;
>> @@ -1198,6 +1199,7 @@ next_chunk:
>> if (nbytes > size)
>> nbytes = size;
>> + flush_dcache_page(bp->b_pages[map_i]);
>> rbytes = bio_add_page(bio, bp->b_pages[map_i], nbytes,
>> if (rbytes < nbytes)
>>> xfsprogs version used: 2.10.2
>>> -- This message was sent on behalf of oferh@xxxxxxxxxxx at
>>> _______________________________________________ xfs mailing list
>>> xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
>> xfs mailing list
> Richard Sharpe