xfs
[Top] [All Lists]

Re: XFS support for ARMv5

To: Ofer Heifetz <oferh@xxxxxxxxxxx>
Subject: Re: XFS support for ARMv5
From: Richard Sharpe <realrichardsharpe@xxxxxxxxx>
Date: Sun, 22 Nov 2009 12:16:48 -0800
Cc: Eric Sandeen <sandeen@xxxxxxxxxxx>, "xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ggeaIV/6+CnsQgAO6X7cF2zNkhkN4YBGrU5D8Gm9Ons=; b=d8hCkSm38AgGRGeRHllCatCrD/x7a61qbQdiV+7FW+NJ4RYx4W8B6SGr0dWevh4gOi k2HmCnuvd8qPpTCGJ24ShyQL4eSgHDeGS2k25vx5+vbIykRqSlCkyFM7UviQn4ZJ0Re+ EVWj5ZfuqtBP9p8kDiV+fot2L/NlUX81xmvrg=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=p4hpcKTWGYNg0TPz/GVjTex2QsWtpgRt/xc6ypLc54kE93DoW9X+jTGFQEHO+c8gFL PU2vdy7G0W8JGZtkgfSmu4eoxDL8ZGvx3smb7Wq9FPxAfGkrzlDbcp0t5gzeh9cDK1Bl Fm3zbev88T2GjjIEr0KLro5qF+w+Vf8tMeHH0=
In-reply-to: <EE71107DF0D1F24FA2D95041E64AB9E8985A59F192@xxxxxxxxxxxxxxxxxxx>
References: <14274282.01258546868484.JavaMail.root@wombat> <4B041AEE.4040506@xxxxxxxxxxx> <EE71107DF0D1F24FA2D95041E64AB9E8985A59F17F@xxxxxxxxxxxxxxxxxxx> <46b8a8850911220845h197cbe28g508cd11783df065a@xxxxxxxxxxxxxx> <EE71107DF0D1F24FA2D95041E64AB9E8985A59F192@xxxxxxxxxxxxxxxxxxx>
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, 2.6.22.18, because that is what is supported by
Marvell.

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.
>
> -Ofer
>
> -----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 
>> 2.6.31.6, 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.
>
>> -Ofer
>>
>> -----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:
>>> Hi,
>>>
>>> I have noticed that XFS on ARMv5TE with latest kernel (2.6.31.6)
>>> 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[0]);
>>                bio_add_page(bio, bp->b_pages[0], 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, 
>> offset);
>>                if (rbytes < nbytes)
>>                        break;
>>
>>
>>
>>> xfsprogs version used: 2.10.2
>>>
>>> -Ofer
>>>
>>> -- This message was sent on behalf of oferh@xxxxxxxxxxx at
>>> openSubscriber.com
>>> http://www.opensubscriber.com/messages/xfs@xxxxxxxxxxx/topic.html
>>>
>>> _______________________________________________ xfs mailing list
>>> xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
>>>
>>
>> _______________________________________________
>> xfs mailing list
>> xfs@xxxxxxxxxxx
>> http://oss.sgi.com/mailman/listinfo/xfs
>>
>
>
>
> --
> Regards,
> Richard Sharpe
>



-- 
Regards,
Richard Sharpe

<Prev in Thread] Current Thread [Next in Thread>