XFS support for ARMv5

XFS support for ARMv5

[oferh]

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.

Is there any patch for this bug?

xfsprogs version used: 2.10.2

-Ofer

--
This message was sent on behalf of oferh@marvell.com at openSubscriber.com
http://www.opensubscriber.com/messages/xfs@oss.sgi.com/topic.html

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS support for ARMv5

[Eric Sandeen]

oferh@marvell.com 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@marvell.com at
> openSubscriber.com 
> http://www.opensubscriber.com/messages/xfs@oss.sgi.com/topic.html
> 
> _______________________________________________ xfs mailing list 
> xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

RE: XFS support for ARMv5

[Ofer Heifetz]

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?

-Ofer

-----Original Message-----
From: Eric Sandeen [mailto:sandeen@sandeen.net] 
Sent: Wednesday, November 18, 2009 6:04 PM
To: Ofer Heifetz
Cc: xfs@oss.sgi.com
Subject: Re: XFS support for ARMv5

oferh@marvell.com 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@marvell.com at
> openSubscriber.com 
> http://www.opensubscriber.com/messages/xfs@oss.sgi.com/topic.html
> 
> _______________________________________________ xfs mailing list 
> xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS support for ARMv5

[Richard Sharpe]

On Sun, Nov 22, 2009 at 8:20 AM, Ofer Heifetz <oferh@marvell.com> 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@sandeen.net]
> Sent: Wednesday, November 18, 2009 6:04 PM
> To: Ofer Heifetz
> Cc: xfs@oss.sgi.com
> Subject: Re: XFS support for ARMv5
>
> oferh@marvell.com 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@marvell.com at
>> openSubscriber.com
>> http://www.opensubscriber.com/messages/xfs@oss.sgi.com/topic.html
>>
>> _______________________________________________ xfs mailing list
>> xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
>>
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
>



-- 
Regards,
Richard Sharpe

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS support for ARMv5

[Eric Sandeen]

Ofer Heifetz 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?

Please start by:

> when you get that error from mount, look at dmesg to see what really went wrong ...

because all I know now is "it didn't mount" which isn't much to go on.

-Eric

> -Ofer
> 
> -----Original Message-----
> From: Eric Sandeen [mailto:sandeen@sandeen.net] 
> Sent: Wednesday, November 18, 2009 6:04 PM
> To: Ofer Heifetz
> Cc: xfs@oss.sgi.com
> Subject: Re: XFS support for ARMv5
> 
> oferh@marvell.com 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@marvell.com at
>> openSubscriber.com 
>> http://www.opensubscriber.com/messages/xfs@oss.sgi.com/topic.html
>>
>> _______________________________________________ xfs mailing list 
>> xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
>>
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

RE: XFS support for ARMv5

[Ofer Heifetz]

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?

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@gmail.com] 
Sent: Sunday, November 22, 2009 6:45 PM
To: Ofer Heifetz
Cc: Eric Sandeen; xfs@oss.sgi.com
Subject: Re: XFS support for ARMv5

On Sun, Nov 22, 2009 at 8:20 AM, Ofer Heifetz <oferh@marvell.com> 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@sandeen.net]
> Sent: Wednesday, November 18, 2009 6:04 PM
> To: Ofer Heifetz
> Cc: xfs@oss.sgi.com
> Subject: Re: XFS support for ARMv5
>
> oferh@marvell.com 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@marvell.com at
>> openSubscriber.com
>> http://www.opensubscriber.com/messages/xfs@oss.sgi.com/topic.html
>>
>> _______________________________________________ xfs mailing list
>> xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
>>
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
>



-- 
Regards,
Richard Sharpe

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS support for ARMv5

[Richard Sharpe]

On Sun, Nov 22, 2009 at 12:07 PM, Ofer Heifetz <oferh@marvell.com> 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@gmail.com]
> Sent: Sunday, November 22, 2009 6:45 PM
> To: Ofer Heifetz
> Cc: Eric Sandeen; xfs@oss.sgi.com
> Subject: Re: XFS support for ARMv5
>
> On Sun, Nov 22, 2009 at 8:20 AM, Ofer Heifetz <oferh@marvell.com> 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@sandeen.net]
>> Sent: Wednesday, November 18, 2009 6:04 PM
>> To: Ofer Heifetz
>> Cc: xfs@oss.sgi.com
>> Subject: Re: XFS support for ARMv5
>>
>> oferh@marvell.com 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@marvell.com at
>>> openSubscriber.com
>>> http://www.opensubscriber.com/messages/xfs@oss.sgi.com/topic.html
>>>
>>> _______________________________________________ xfs mailing list
>>> xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
>>>
>>
>> _______________________________________________
>> xfs mailing list
>> xfs@oss.sgi.com
>> http://oss.sgi.com/mailman/listinfo/xfs
>>
>
>
>
> --
> Regards,
> Richard Sharpe
>



-- 
Regards,
Richard Sharpe

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

RE: XFS support for ARMv5

[Ofer Heifetz]

Hi Eric,

Here is the dmesg I got for mount /dev/sda3 /mnt/usb:
SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
XFS mounting filesystem sda3
Starting XFS recovery on filesystem: sda3 (logdev: internal)
XFS: xlog_recover_process_data: bad clientid
XFS: log mount/recovery failed: error 5
XFS: log mount failed

-Ofer

-----Original Message-----
From: Eric Sandeen [mailto:sandeen@sandeen.net] 
Sent: Sunday, November 22, 2009 6:53 PM
To: Ofer Heifetz
Cc: xfs@oss.sgi.com
Subject: Re: XFS support for ARMv5

Ofer Heifetz 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?

Please start by:

> when you get that error from mount, look at dmesg to see what really went wrong ...

because all I know now is "it didn't mount" which isn't much to go on.

-Eric

> -Ofer
> 
> -----Original Message-----
> From: Eric Sandeen [mailto:sandeen@sandeen.net] 
> Sent: Wednesday, November 18, 2009 6:04 PM
> To: Ofer Heifetz
> Cc: xfs@oss.sgi.com
> Subject: Re: XFS support for ARMv5
> 
> oferh@marvell.com 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@marvell.com at
>> openSubscriber.com 
>> http://www.opensubscriber.com/messages/xfs@oss.sgi.com/topic.html
>>
>> _______________________________________________ xfs mailing list 
>> xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
>>
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

RE: XFS support for ARMv5

[Ofer Heifetz]

The KW has the same VIVT cache like the 78200, I have been using Marvell LSP 2.6.22.18 based without any issue with XFS.
The problem I am seeing is with mainline (not 2.6.22.18), have you posted your changes back to Marvell?

-Ofer

-----Original Message-----
From: Richard Sharpe [mailto:realrichardsharpe@gmail.com] 
Sent: Sunday, November 22, 2009 10:17 PM
To: Ofer Heifetz
Cc: Eric Sandeen; xfs@oss.sgi.com
Subject: Re: XFS support for ARMv5

On Sun, Nov 22, 2009 at 12:07 PM, Ofer Heifetz <oferh@marvell.com> 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@gmail.com]
> Sent: Sunday, November 22, 2009 6:45 PM
> To: Ofer Heifetz
> Cc: Eric Sandeen; xfs@oss.sgi.com
> Subject: Re: XFS support for ARMv5
>
> On Sun, Nov 22, 2009 at 8:20 AM, Ofer Heifetz <oferh@marvell.com> 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@sandeen.net]
>> Sent: Wednesday, November 18, 2009 6:04 PM
>> To: Ofer Heifetz
>> Cc: xfs@oss.sgi.com
>> Subject: Re: XFS support for ARMv5
>>
>> oferh@marvell.com 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@marvell.com at
>>> openSubscriber.com
>>> http://www.opensubscriber.com/messages/xfs@oss.sgi.com/topic.html
>>>
>>> _______________________________________________ xfs mailing list
>>> xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
>>>
>>
>> _______________________________________________
>> xfs mailing list
>> xfs@oss.sgi.com
>> http://oss.sgi.com/mailman/listinfo/xfs
>>
>
>
>
> --
> Regards,
> Richard Sharpe
>



-- 
Regards,
Richard Sharpe

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

RE: XFS support for ARMv5

[Andy Poling]

On Mon, 23 Nov 2009, Ofer Heifetz wrote:
> Here is the dmesg I got for mount /dev/sda3 /mnt/usb:
> SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
> XFS mounting filesystem sda3
> Starting XFS recovery on filesystem: sda3 (logdev: internal)
> XFS: xlog_recover_process_data: bad clientid
> XFS: log mount/recovery failed: error 5
> XFS: log mount failed

See this thread in the archives for a patch that may fix this:

 	http://oss.sgi.com/pipermail/xfs/2009-October/042805.html

-Andy

It ain't what you don't know that gets you into trouble.
It's what you know for sure that just ain't so. - Mark Twain

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS support for ARMv5

[Christoph Hellwig]

On Wed, Nov 25, 2009 at 10:30:09AM -0600, Andy Poling wrote:
> On Mon, 23 Nov 2009, Ofer Heifetz wrote:
>> Here is the dmesg I got for mount /dev/sda3 /mnt/usb:
>> SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
>> XFS mounting filesystem sda3
>> Starting XFS recovery on filesystem: sda3 (logdev: internal)
>> XFS: xlog_recover_process_data: bad clientid
>> XFS: log mount/recovery failed: error 5
>> XFS: log mount failed
>
> See this thread in the archives for a patch that may fix this:
>
> 	http://oss.sgi.com/pipermail/xfs/2009-October/042805.html

I don't think it's the case you found, although the symptoms are the
same.  I'd rather guess this is a case of an architecture with virtually
indexed caches (can anyone confirm the cache architecture?) which
doesn't cope too well with the way we use vmap to write into a buffer
through virtually mapped linear addresses, but then do block I/O using
the physical addresses of the individual pages.  James Bottomley has a
patchset to fix this issue by introducing APIs that allow the
architecture specific memory management to cope with it.  He're a
version I could quickly find, although newer ones have been posted
since:

	http://thread.gmane.org/gmane.linux.kernel.cross-arch/4364

The patchset is planned to get merged into Linux 2.6.33.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS support for ARMv5

[Eric Sandeen]

Christoph Hellwig wrote:
> On Wed, Nov 25, 2009 at 10:30:09AM -0600, Andy Poling wrote:
>> On Mon, 23 Nov 2009, Ofer Heifetz wrote:
>>> Here is the dmesg I got for mount /dev/sda3 /mnt/usb:
>>> SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
>>> XFS mounting filesystem sda3
>>> Starting XFS recovery on filesystem: sda3 (logdev: internal)
>>> XFS: xlog_recover_process_data: bad clientid
>>> XFS: log mount/recovery failed: error 5
>>> XFS: log mount failed
>> See this thread in the archives for a patch that may fix this:
>>
>> 	http://oss.sgi.com/pipermail/xfs/2009-October/042805.html
> 
> I don't think it's the case you found, although the symptoms are the
> same.  I'd rather guess this is a case of an architecture with virtually
> indexed caches (can anyone confirm the cache architecture?) which
> doesn't cope too well with the way we use vmap to write into a buffer
> through virtually mapped linear addresses, but then do block I/O using
> the physical addresses of the individual pages.  James Bottomley has a
> patchset to fix this issue by introducing APIs that allow the
> architecture specific memory management to cope with it.  He're a
> version I could quickly find, although newer ones have been posted
> since:
> 
> 	http://thread.gmane.org/gmane.linux.kernel.cross-arch/4364
> 
> The patchset is planned to get merged into Linux 2.6.33.

I'll do some ARM testing w/ that stuff next week.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS support for ARMv5

[Richard Sharpe]

On Wed, Nov 25, 2009 at 1:06 PM, Christoph Hellwig <hch@infradead.org> wrote:
> On Wed, Nov 25, 2009 at 10:30:09AM -0600, Andy Poling wrote:
>> On Mon, 23 Nov 2009, Ofer Heifetz wrote:
>>> Here is the dmesg I got for mount /dev/sda3 /mnt/usb:
>>> SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
>>> XFS mounting filesystem sda3
>>> Starting XFS recovery on filesystem: sda3 (logdev: internal)
>>> XFS: xlog_recover_process_data: bad clientid
>>> XFS: log mount/recovery failed: error 5
>>> XFS: log mount failed
>>
>> See this thread in the archives for a patch that may fix this:
>>
>>       http://oss.sgi.com/pipermail/xfs/2009-October/042805.html
>
> I don't think it's the case you found, although the symptoms are the
> same.  I'd rather guess this is a case of an architecture with virtually
> indexed caches (can anyone confirm the cache architecture?) which

The Marvell 78xx series uses a VIVT cache. I will have to consult the
documentation about the 6281 (I think that was it).

> doesn't cope too well with the way we use vmap to write into a buffer
> through virtually mapped linear addresses, but then do block I/O using
> the physical addresses of the individual pages.  James Bottomley has a
> patchset to fix this issue by introducing APIs that allow the
> architecture specific memory management to cope with it.  He're a
> version I could quickly find, although newer ones have been posted
> since:
>
>        http://thread.gmane.org/gmane.linux.kernel.cross-arch/4364
>
> The patchset is planned to get merged into Linux 2.6.33.
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
>



-- 
Regards,
Richard Sharpe

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

RE: XFS support for ARMv5

[Ofer Heifetz]

Hi Christoph,

I applied the patches to 2.6.31.6 and the mount passes file. I copied some data to the XFS DOK and had no problem reading the content after several system reset.

Here is a dmesg snippet:

SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
XFS mounting filesystem sda3
Starting XFS recovery on filesystem: sda3 (logdev: internal)
Ending XFS recovery on filesystem: sda3 (logdev: internal)

Is this patch confirmed to be mainlined in 2.6.33?
I need to know `cos I want to run some data integrity and performance tests on this patch before I merge it.

-Ofer
-----Original Message-----
From: Christoph Hellwig [mailto:hch@infradead.org] 
Sent: Wednesday, November 25, 2009 11:06 PM
To: Andy Poling
Cc: Ofer Heifetz; xfs@oss.sgi.com
Subject: Re: XFS support for ARMv5

On Wed, Nov 25, 2009 at 10:30:09AM -0600, Andy Poling wrote:
> On Mon, 23 Nov 2009, Ofer Heifetz wrote:
>> Here is the dmesg I got for mount /dev/sda3 /mnt/usb:
>> SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
>> XFS mounting filesystem sda3
>> Starting XFS recovery on filesystem: sda3 (logdev: internal)
>> XFS: xlog_recover_process_data: bad clientid
>> XFS: log mount/recovery failed: error 5
>> XFS: log mount failed
>
> See this thread in the archives for a patch that may fix this:
>
> 	http://oss.sgi.com/pipermail/xfs/2009-October/042805.html

I don't think it's the case you found, although the symptoms are the
same.  I'd rather guess this is a case of an architecture with virtually
indexed caches (can anyone confirm the cache architecture?) which
doesn't cope too well with the way we use vmap to write into a buffer
through virtually mapped linear addresses, but then do block I/O using
the physical addresses of the individual pages.  James Bottomley has a
patchset to fix this issue by introducing APIs that allow the
architecture specific memory management to cope with it.  He're a
version I could quickly find, although newer ones have been posted
since:

	http://thread.gmane.org/gmane.linux.kernel.cross-arch/4364

The patchset is planned to get merged into Linux 2.6.33.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS support for ARMv5

[Christoph Hellwig]

On Thu, Nov 26, 2009 at 04:19:39PM +0200, Ofer Heifetz wrote:
> Hi Christoph,
> 
> I applied the patches to 2.6.31.6 and the mount passes file. I copied some data to the XFS DOK and had no problem reading the content after several system reset.
> 
> Here is a dmesg snippet:
> 
> SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
> XFS mounting filesystem sda3
> Starting XFS recovery on filesystem: sda3 (logdev: internal)
> Ending XFS recovery on filesystem: sda3 (logdev: internal)
> 
> Is this patch confirmed to be mainlined in 2.6.33?
> I need to know `cos I want to run some data integrity and performance tests on this patch before I merge it.

There's no way to 100% confirm it until it's done, but it's firmly
planned.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs