Bug#414932: Processed: Re: Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm
Martin Michlmayr [EMAIL PROTECTED] writes: * Eric Sandeen [EMAIL PROTECTED] [2008-06-21 10:50]: It was just recently added to the xfs cvs tree. Message to the list was TAKE 982930 - fix dir2 shortform structures on ARM old ABI * Niv Sardi [EMAIL PROTECTED] [2008-06-23 15:12]: http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs-2.6.git;a=commit;h=7a9ba9bb899933293604a2b3c5ca4f40ad5a92a8 This fixes the issue, and should be pushed in the next kernel.org xfs. It seems there hasn't been a pull request for xfs for 2.6.27 yet and rc1 will happen soon. Any idea when there'll be a pull request? It should be happening in the next days, we're having some weird behaviours with the [EMAIL PROTECTED], and trying to get those sorted out. Cheers, -- Niv Sardi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: Processed: Re: Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm
* Eric Sandeen [EMAIL PROTECTED] [2008-06-21 10:50]: It was just recently added to the xfs cvs tree. Message to the list was TAKE 982930 - fix dir2 shortform structures on ARM old ABI * Niv Sardi [EMAIL PROTECTED] [2008-06-23 15:12]: http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs-2.6.git;a=commit;h=7a9ba9bb899933293604a2b3c5ca4f40ad5a92a8 This fixes the issue, and should be pushed in the next kernel.org xfs. It seems there hasn't been a pull request for xfs for 2.6.27 yet and rc1 will happen soon. Any idea when there'll be a pull request? -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm
* Eric Sandeen [EMAIL PROTECTED] [2008-06-21 10:50]: Do you know what the status is of your XFS patch to make it work on ARM (old ABI)? It was just recently added to the xfs cvs tree. Message to the list was TAKE 982930 - fix dir2 shortform structures on ARM old ABI Excellent news, thanks! -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: Processed: Re: Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm
http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs-2.6.git;a=commit;h=7a9ba9bb899933293604a2b3c5ca4f40ad5a92a8 This fixes the issue, and should be pushed in the next kernel.org xfs. Cheers, -- Niv Sardi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm
Eric,
Do you know what the status is of your XFS patch to make it work on
ARM (old ABI)?
* Martin Michlmayr [EMAIL PROTECTED] [2008-03-17 09:50]:
A patch for this problem has been posted now.
Message-ID: [EMAIL PROTECTED]
Date: Fri, 14 Mar 2008 22:24:49 -0500
From: Eric Sandeen [EMAIL PROTECTED]
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: xfs-oss [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: [PATCH] fix dir2 shortform structures on ARM old ABI
This should fix the longstanding issues with xfs and old ABI
arm boxes, which lead to various asserts and xfs shutdowns,
and for which an (incorrect) patch has been floating around
for years. (Said patch made ARM internally consistent, but
altered the normal xfs on-disk format such that it looked
corrupted on other architectures):
http://lists.arm.linux.org.uk/lurker/message/20040311.002034.5ecf21a2.html
Old ABI ARM has interesting packing padding; for example
on ARM old abi:
struct xfs_dir2_sf_entry {
__uint8_t namelen; /* 0 1 */
/* XXX 3 bytes hole, try to pack */
xfs_dir2_sf_off_t offset; /* 4 4 */
__uint8_t name[1]; /* 8 1 */
/* XXX 3 bytes hole, try to pack */
xfs_dir2_inou_tinumber; /*12 8 */
/* size: 20, cachelines: 1 */
/* sum members: 14, holes: 2, sum holes: 6 */
/* last cacheline: 20 bytes */
};
but on x86:
struct xfs_dir2_sf_entry {
__uint8_t namelen; /* 0 1 */
xfs_dir2_sf_off_t offset; /* 1 2 */
__uint8_t name[1]; /* 3 1 */
xfs_dir2_inou_tinumber; /* 4 8 */
/* size: 12, cachelines: 1 */
/* last cacheline: 12 bytes */
};
... this sort of discrepancy leads to problems.
I've verified this patch by comparing the on-disk structure
layouts using pahole from the dwarves package, as well as
running through a bit of xfsqa under qemu-arm, modified so
that the check/repair phase after each test actually executes
check/repair from the x86 host, on the filesystem populated
by the arm emulator. Thus far it all looks good.
There are 2 other structures with extra padding at the end,
but they don't seem to cause trouble. I suppose they could
be packed as well: xfs_dir2_data_unused_t and xfs_dir2_sf_t.
Note that userspace needs a similar treatment, and any
filesystems which were running with the previous rogue
fix will now see corruption (either in the kernel, or
during xfs_repair) with this fix properly in place; it
may be worth teaching xfs_repair to identify and fix that
specific issue.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux-2.6.24/fs/xfs/linux-2.6/xfs_linux.h
===
--- linux-2.6.24.orig/fs/xfs/linux-2.6/xfs_linux.h
+++ linux-2.6.24/fs/xfs/linux-2.6/xfs_linux.h
@@ -300,4 +300,11 @@ static inline __uint64_t howmany_64(__ui
return x;
}
+/* ARM old ABI has some weird alignment/padding */
+#if defined(__arm__) !defined(__ARM_EABI__)
+#define __arch_pack __attribute__((packed))
+#else
+#define __arch_pack
+#endif
+
#endif /* __XFS_LINUX__ */
Index: linux-2.6.24/fs/xfs/xfs_dir2_sf.h
===
--- linux-2.6.24.orig/fs/xfs/xfs_dir2_sf.h
+++ linux-2.6.24/fs/xfs/xfs_dir2_sf.h
@@ -62,7 +62,7 @@ typedef union {
* Normalized offset (in a data block) of the entry, really
xfs_dir2_data_off_t.
* Only need 16 bits, this is the byte offset into the single block form.
*/
-typedef struct { __uint8_t i[2]; } xfs_dir2_sf_off_t;
+typedef struct { __uint8_t i[2]; } __arch_pack xfs_dir2_sf_off_t;
/*
* The parent directory has a dedicated field, and the self-pointer must
@@ -76,14 +76,14 @@ typedef struct xfs_dir2_sf_hdr {
__uint8_t count; /* count of entries */
__uint8_t i8count;/* count of 8-byte inode #s */
xfs_dir2_inou_t parent; /* parent dir inode number */
-} xfs_dir2_sf_hdr_t;
+} __arch_pack xfs_dir2_sf_hdr_t;
typedef struct xfs_dir2_sf_entry {
__uint8_t namelen;/* actual name length */
xfs_dir2_sf_off_t offset; /* saved offset */
__uint8_t name[1];/* name, variable size */
xfs_dir2_inou_t inumber;/* inode number, var. offset */
-} xfs_dir2_sf_entry_t;
+} __arch_pack xfs_dir2_sf_entry_t;
typedef struct xfs_dir2_sf {
xfs_dir2_sf_hdr_t hdr;/* shortform header */
--
Martin Michlmayr
http://www.cyrius.com/
--
Martin Michlmayr
http://www.cyrius.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm
Martin Michlmayr wrote: Eric, Do you know what the status is of your XFS patch to make it work on ARM (old ABI)? It was just recently added to the xfs cvs tree. Message to the list was TAKE 982930 - fix dir2 shortform structures on ARM old ABI -Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm
Please note that the above patch isn't helpful on armel.
We had some very fruitful discussions about armel w/ some XFS guys,
and it turns out that a simple patch like the attached is needed. This
works fine for me on 2.6.25-rc6, but I assume it will be made to
look/behave differently before being pushed upstream into the
kernel/xfs-cvs :-)
Since this fixes a cache issue, plain (old) arm will most likely need
it in addition to the struct packing patch, too.
Index: linux-2.6.25-rc6/fs/xfs/linux-2.6/xfs_buf.c
===
--- linux-2.6.25-rc6.orig/fs/xfs/linux-2.6/xfs_buf.c 2008-03-26 21:41:29.932766585 +
+++ linux-2.6.25-rc6/fs/xfs/linux-2.6/xfs_buf.c 2008-03-26 21:43:13.037769383 +
@@ -1157,6 +1157,17 @@ _xfs_buf_ioapply(
(bp-b_flags XBF_READ_AHEAD) ? READA : READ;
}
+#if 0
+ if ((bp-b_flags (_XBF_PAGE_CACHE|_XBF_PAGES))
+ (bp-b_flags XBF_MAPPED)
+ (bp-b_page_count 1)) {
+ flush_cache_vunmap(bp-b_addr - bp-b_offset, // start
+ bp-b_addr - bp-b_offset + (bp-b_page_count * PAGE_SIZE));
+ }
+#else
+ flush_cache_vunmap (0, 1);
+#endif
+
/* Special code path for reading a sub page size buffer in --
* we populate up the whole page, and hence the other metadata
* in the same page. This optimization is only valid when the
Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm
A patch for this problem has been posted now.
Message-ID: [EMAIL PROTECTED]
Date: Fri, 14 Mar 2008 22:24:49 -0500
From: Eric Sandeen [EMAIL PROTECTED]
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: xfs-oss [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: [PATCH] fix dir2 shortform structures on ARM old ABI
This should fix the longstanding issues with xfs and old ABI
arm boxes, which lead to various asserts and xfs shutdowns,
and for which an (incorrect) patch has been floating around
for years. (Said patch made ARM internally consistent, but
altered the normal xfs on-disk format such that it looked
corrupted on other architectures):
http://lists.arm.linux.org.uk/lurker/message/20040311.002034.5ecf21a2.html
Old ABI ARM has interesting packing padding; for example
on ARM old abi:
struct xfs_dir2_sf_entry {
__uint8_t namelen; /* 0 1 */
/* XXX 3 bytes hole, try to pack */
xfs_dir2_sf_off_t offset; /* 4 4 */
__uint8_t name[1]; /* 8 1 */
/* XXX 3 bytes hole, try to pack */
xfs_dir2_inou_tinumber; /*12 8 */
/* size: 20, cachelines: 1 */
/* sum members: 14, holes: 2, sum holes: 6 */
/* last cacheline: 20 bytes */
};
but on x86:
struct xfs_dir2_sf_entry {
__uint8_t namelen; /* 0 1 */
xfs_dir2_sf_off_t offset; /* 1 2 */
__uint8_t name[1]; /* 3 1 */
xfs_dir2_inou_tinumber; /* 4 8 */
/* size: 12, cachelines: 1 */
/* last cacheline: 12 bytes */
};
... this sort of discrepancy leads to problems.
I've verified this patch by comparing the on-disk structure
layouts using pahole from the dwarves package, as well as
running through a bit of xfsqa under qemu-arm, modified so
that the check/repair phase after each test actually executes
check/repair from the x86 host, on the filesystem populated
by the arm emulator. Thus far it all looks good.
There are 2 other structures with extra padding at the end,
but they don't seem to cause trouble. I suppose they could
be packed as well: xfs_dir2_data_unused_t and xfs_dir2_sf_t.
Note that userspace needs a similar treatment, and any
filesystems which were running with the previous rogue
fix will now see corruption (either in the kernel, or
during xfs_repair) with this fix properly in place; it
may be worth teaching xfs_repair to identify and fix that
specific issue.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux-2.6.24/fs/xfs/linux-2.6/xfs_linux.h
===
--- linux-2.6.24.orig/fs/xfs/linux-2.6/xfs_linux.h
+++ linux-2.6.24/fs/xfs/linux-2.6/xfs_linux.h
@@ -300,4 +300,11 @@ static inline __uint64_t howmany_64(__ui
return x;
}
+/* ARM old ABI has some weird alignment/padding */
+#if defined(__arm__) !defined(__ARM_EABI__)
+#define __arch_pack __attribute__((packed))
+#else
+#define __arch_pack
+#endif
+
#endif /* __XFS_LINUX__ */
Index: linux-2.6.24/fs/xfs/xfs_dir2_sf.h
===
--- linux-2.6.24.orig/fs/xfs/xfs_dir2_sf.h
+++ linux-2.6.24/fs/xfs/xfs_dir2_sf.h
@@ -62,7 +62,7 @@ typedef union {
* Normalized offset (in a data block) of the entry, really
xfs_dir2_data_off_t.
* Only need 16 bits, this is the byte offset into the single block form.
*/
-typedef struct { __uint8_t i[2]; } xfs_dir2_sf_off_t;
+typedef struct { __uint8_t i[2]; } __arch_pack xfs_dir2_sf_off_t;
/*
* The parent directory has a dedicated field, and the self-pointer must
@@ -76,14 +76,14 @@ typedef struct xfs_dir2_sf_hdr {
__uint8_t count; /* count of entries */
__uint8_t i8count;/* count of 8-byte inode #s */
xfs_dir2_inou_t parent; /* parent dir inode number */
-} xfs_dir2_sf_hdr_t;
+} __arch_pack xfs_dir2_sf_hdr_t;
typedef struct xfs_dir2_sf_entry {
__uint8_t namelen;/* actual name length */
xfs_dir2_sf_off_t offset; /* saved offset */
__uint8_t name[1];/* name, variable size */
xfs_dir2_inou_t inumber;/* inode number, var. offset */
-} xfs_dir2_sf_entry_t;
+} __arch_pack xfs_dir2_sf_entry_t;
typedef struct xfs_dir2_sf {
xfs_dir2_sf_hdr_t hdr;/* shortform header */
--
Martin Michlmayr
http://www.cyrius.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: Info received (Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm)
* Lennert Buytenhek [EMAIL PROTECTED] [2007-04-27 21:06]: The xfstest suite is pretty good, if anyone would like to run through it on arm with the above packed structures... I'll have a look. Did you get a chance to? -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: Info received (Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm)
On Thu, Apr 26, 2007 at 11:57:40PM -0500, Eric Sandeen wrote:
Maybe the alignment isn't broken; it's just special - I guess there
are no actual rules on how the structure must be aligned... hmm...
Yep. Padding rules on old-ABI ARM systems are 'special', but still
spec-compliant. See:
http://www.simplemachines.it/arm-linux/book/afaq.html
For example, this means that sizeof(struct { char a; char b; }) == 4
on old-ABI ARM systems. This is the main cause of pain when porting
applications to ARM platforms. (#2 is the fact that chars are unsigned
by default on ARM, which is also something that the relevant specs
allow but not a lot of people expect.)
The new ARM ABI (EABI) changes both of these things (and a couple more,
such as 64 bit type alignment and the floating point calling convention)
to be more in line with other deployed Linux platforms. There is a
preliminary Debian EABI port available here:
http://wiki.debian.org/ArmEabiPort
But Debian EABI uptake has been very slow, and most people are still on
old-ABI systems.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm
On Thu, Apr 26, 2007 at 11:34:56PM -0500, Eric Sandeen wrote:
Root cause seems to be gcc misaligning the xfs shortform directory
structures. In the example below, bar.parent has offset 4, while
boo.parent has offset 2. The union seems to cause extra padding - I
believe c should be at offset 2 in both structures.
This is leading to trouble in xfs_dir2_sf_hdr_t and others, and is
unfortunately leading to on-disk corruption, I think. The patch that's
been floating around to fix this probably only masks the problem, by
accommodating the extra padding when calculating sizes.
#include stdio.h
struct bar {
unsigned char a;
unsigned char b;
union {
unsigned char x;
unsigned char y;
} c;
};
struct boo {
unsigned char a;
unsigned char b;
unsigned char c;
};
#define offsetof(TYPE, MEMBER) ((size_t) ((TYPE *)0)-MEMBER)
int main(int argc, char ** argv) {
printf(a: %d\n, offsetof(struct bar, a));
printf(b: %d\n, offsetof(struct bar, b));
printf(c: %d\n, offsetof(struct bar, c));
printf(a: %d\n, offsetof(struct boo, a));
printf(b: %d\n, offsetof(struct boo, b));
printf(c: %d\n, offsetof(struct boo, c));
return 0;
}
[EMAIL PROTECTED]:~$ ./gcc-test
a: 0
b: 1
c: 4
a: 0
b: 1
c: 2
On an EABI ARM system:
$ ./x
a: 0
b: 1
c: 2
a: 0
b: 1
c: 2
[EMAIL PROTECTED]:~$ gcc -v
Using built-in specs.
Target: arm-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
arm-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
iop0:~# gcc -v
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v
--enable-languages=c,c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-checking=release
arm-linux-gnueabi
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
[EMAIL PROTECTED]:~$ uname -a
Linux all6500-arm 2.6.18-4-iop32x #1 Thu Feb 22 03:51:25 UTC 2007
armv5tel GNU/Linux
iop0:~# uname -a
Linux iop0.wantstofly.org 2.6.20 #9 Thu Mar 29 04:35:38 CEST 2007
armv5tel GNU/Linux
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: Info received (Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm)
Lennert Buytenhek wrote: Yep. Padding rules on old-ABI ARM systems are 'special', but still spec-compliant. See: Thanks, I've read up a bit since, and I think I grok it now :) So, adding __attribute__((packed)) to xfs_dir2_sf_off_t, xfs_dir2_sf_hdr_t, and perhaps also xfs_dir2_sf_entry_t might fix things? The xfstest suite is pretty good, if anyone would like to run through it on arm with the above packed structures... -Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: Info received (Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm)
On Fri, Apr 27, 2007 at 08:26:10AM -0500, Eric Sandeen wrote:
Yep. Padding rules on old-ABI ARM systems are 'special', but still
spec-compliant. See:
Thanks, I've read up a bit since, and I think I grok it now :)
So, adding __attribute__((packed)) to xfs_dir2_sf_off_t,
xfs_dir2_sf_hdr_t, and perhaps also xfs_dir2_sf_entry_t might fix things?
It might, but it would likely also reduce performance on other platforms.
I.e. on platforms that can't do unaligned accesses, if you access,
say, an unsigned long long via a pointer to a struct that is
__attribute__((packed)), the compiler might end up emitting 8 individual
byte accesses, and combining those values together into a long long by
hand.
You'd probably want to do something like:
#if defined(__arm__) !defined(__ARM_EABI__)
#define PACKED __attribute__((packed))
#else
#define PACKED
#endif
typedef struct {
int foo;
char bar;
long baz;
} PACKED;
Or something like that.
The xfstest suite is pretty good, if anyone would like to run
through it on arm with the above packed structures...
I'll have a look.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm
Root cause seems to be gcc misaligning the xfs shortform directory
structures. In the example below, bar.parent has offset 4, while
boo.parent has offset 2. The union seems to cause extra padding - I
believe c should be at offset 2 in both structures.
This is leading to trouble in xfs_dir2_sf_hdr_t and others, and is
unfortunately leading to on-disk corruption, I think. The patch that's
been floating around to fix this probably only masks the problem, by
accommodating the extra padding when calculating sizes.
#include stdio.h
struct bar {
unsigned char a;
unsigned char b;
union {
unsigned char x;
unsigned char y;
} c;
};
struct boo {
unsigned char a;
unsigned char b;
unsigned char c;
};
#define offsetof(TYPE, MEMBER) ((size_t) ((TYPE *)0)-MEMBER)
int main(int argc, char ** argv) {
printf(a: %d\n, offsetof(struct bar, a));
printf(b: %d\n, offsetof(struct bar, b));
printf(c: %d\n, offsetof(struct bar, c));
printf(a: %d\n, offsetof(struct boo, a));
printf(b: %d\n, offsetof(struct boo, b));
printf(c: %d\n, offsetof(struct boo, c));
return 0;
}
[EMAIL PROTECTED]:~$ ./gcc-test
a: 0
b: 1
c: 4
a: 0
b: 1
c: 2
[EMAIL PROTECTED]:~$ gcc -v
Using built-in specs.
Target: arm-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
arm-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
[EMAIL PROTECTED]:~$ uname -a
Linux all6500-arm 2.6.18-4-iop32x #1 Thu Feb 22 03:51:25 UTC 2007
armv5tel GNU/Linux
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: Info received (Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm)
Maybe the alignment isn't broken; it's just special - I guess there are no actual rules on how the structure must be aligned... hmm... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm
Eric, We at Debian received a bug report about XFS on ARM (see below). I noticed your posting at http://oss.sgi.com/archives/xfs/2007-03/msg00053.html in which you said that this was a known issue. I cannot find the workaround you mentioned in your message. Do you know where I can find it? I think you also mentioned not having access to any ARM hardware. If I can give you an account on an ARM machine, do you think you could invetigate this issue in more detail? It would be great to have a small testcase that could be sent to the GCC folks. Thanks. * Michael Prokop [EMAIL PROTECTED] [2007-03-14 21:30]: Package: linux-image-2.6.18-4-ixp4xx Version: 2.6.18.dfsg.1-11 Severity: important I'm using the NSLU2 device with Debian (http://www.cyrius.com/debian/nslu2/): # uname -a Linux NSLU 2.6.18-4-ixp4xx #1 Thu Feb 22 14:00:55 UTC 2007 armv5tel GNU/Linux The problem: using a partition which has been generated on a x86 system using the filesystem XFS does not work on arm/NSLU2. Mounting the partition does not indicate any problems in the syslog, but access to the partition/files is definitely not possible: # ls -la /mnt/sdb2 total 4 drwxr-xr-x 7 root root 76 Oct 13 00:09 / drwxr-xr-x 7 root root 76 Oct 13 00:09 / drwxr-xr-x 7 root root 76 Oct 13 00:09 / drwxr-xr-x 7 root root 76 Oct 13 00:09 / drwxr-xr-x 7 root root 76 Oct 13 00:09 ./ drwxr-xr-x 4 root root 4096 Mar 7 19:46 ../ # Though the disk usage is displayed correct: # df -h FilesystemSize Used Avail Use% Mounted on /dev/sda1 773M 606M 128M 83% / tmpfs 15M 0 15M 0% /lib/init/rw udev 10M 44K 10M 1% /dev tmpfs 15M 0 15M 0% /dev/shm /dev/sdb2 271G 95G 176G 35% /mnt/sdb2 The XFS partition can be used without any problems on the x86 system, there's no data loss. XFS itself is ok on arm/NSLU2 if the partition has been generated on the arm platform using mkfs.xfs. I played around with xfs_repair, xfs_db, xfs_check,... tons of error messages are displayed though the partition itself is ok - it's just that there seem to be serious problems on the arm platform. The problem is reproducable, just run something like # mkfs.xfs -d file,name=/file,size=20m on a x86 system and try to mount the file on arm/NSLU2 then. If you need any further information, debugging output,... please let me know. regards, -mika- -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm
Eric, We at Debian received a bug report about XFS on ARM (see below). I noticed your posting at http://oss.sgi.com/archives/xfs/2007-03/msg00053.html in which you said that this was a known issue. I cannot find the workaround you mentioned in your message. Do you know where I can find it? I think you also mentioned not having access to any ARM hardware. If I can give you an account on an ARM machine, do you think you could invetigate this issue in more detail? It would be great to have a small testcase that could be sent to the GCC folks. Thanks. * Michael Prokop [EMAIL PROTECTED] [2007-03-14 21:30]: Package: linux-image-2.6.18-4-ixp4xx Version: 2.6.18.dfsg.1-11 Severity: important I'm using the NSLU2 device with Debian (http://www.cyrius.com/debian/nslu2/): # uname -a Linux NSLU 2.6.18-4-ixp4xx #1 Thu Feb 22 14:00:55 UTC 2007 armv5tel GNU/Linux The problem: using a partition which has been generated on a x86 system using the filesystem XFS does not work on arm/NSLU2. Mounting the partition does not indicate any problems in the syslog, but access to the partition/files is definitely not possible: # ls -la /mnt/sdb2 total 4 drwxr-xr-x 7 root root 76 Oct 13 00:09 / drwxr-xr-x 7 root root 76 Oct 13 00:09 / drwxr-xr-x 7 root root 76 Oct 13 00:09 / drwxr-xr-x 7 root root 76 Oct 13 00:09 / drwxr-xr-x 7 root root 76 Oct 13 00:09 ./ drwxr-xr-x 4 root root 4096 Mar 7 19:46 ../ # Though the disk usage is displayed correct: # df -h FilesystemSize Used Avail Use% Mounted on /dev/sda1 773M 606M 128M 83% / tmpfs 15M 0 15M 0% /lib/init/rw udev 10M 44K 10M 1% /dev tmpfs 15M 0 15M 0% /dev/shm /dev/sdb2 271G 95G 176G 35% /mnt/sdb2 The XFS partition can be used without any problems on the x86 system, there's no data loss. XFS itself is ok on arm/NSLU2 if the partition has been generated on the arm platform using mkfs.xfs. I played around with xfs_repair, xfs_db, xfs_check,... tons of error messages are displayed though the partition itself is ok - it's just that there seem to be serious problems on the arm platform. The problem is reproducable, just run something like # mkfs.xfs -d file,name=/file,size=20m on a x86 system and try to mount the file on arm/NSLU2 then. If you need any further information, debugging output,... please let me know. regards, -mika- -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm
Martin Michlmayr wrote: Eric, We at Debian received a bug report about XFS on ARM (see below). I noticed your posting at http://oss.sgi.com/archives/xfs/2007-03/msg00053.html in which you said that this was a known issue. I cannot find the workaround you mentioned in your message. Do you know where I can find it? I think you also mentioned not having access to any ARM hardware. If I can give you an account on an ARM machine, do you think you could invetigate this issue in more detail? It would be great to have a small testcase that could be sent to the GCC folks. I think this was the fix: http://www.spinics.net/lists/arm-kernel/msg18479.html yeah, somebody should get to the bottom of this... sure, if I can log into an arm machine that demonstrates the bug, I could try to come up with a compact gcc testcase. Well, from looking at this patch I suppose anyone could, but I'll try to find some time. :) Thanks, -Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm
Eric mentioned a workaround for this miscompilation. Do you know more about this? Also, do you have any idea whether this issue has actually been reported to the GCC folks? -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm
* Martin Michlmayr [EMAIL PROTECTED] [20070317 21:15]: Eric mentioned a workaround for this miscompilation. Do you know more about this? No, sorry. Also, do you have any idea whether this issue has actually been reported to the GCC folks? I don't think so, as Eric had no access to such a system to verify and play with it on his own and I wanted to report the bug to Debian's BTS before bugging upstream. regards, -mika- pgpIOu8uWanb4.pgp Description: PGP signature
Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm
* Michael Prokop [EMAIL PROTECTED] [2007-03-17 21:19]: I don't think so, as Eric had no access to such a system to verify and play with it on his own and I wanted to report the bug to Debian's BTS before bugging upstream. Ok, I'm fairly busy right now but I'll try to talk to Eric in about a month or 1.5 months, and maybe I can arrange access to an ARM box for him. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm
I just found http://oss.sgi.com/archives/xfs/2007-03/msg00078.html which is another XFS problem on NSLU2. Apparently it's because of a miscompilation in XFS on ARM. I'll confirm with the XFS developers whether your problem may be caused by this too after reproducing it on another ARM machine, hopefully this weekend. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm
* Martin Michlmayr [EMAIL PROTECTED] [20070316 21:24]: I just found http://oss.sgi.com/archives/xfs/2007-03/msg00078.html which is another XFS problem on NSLU2. Apparently it's because of a miscompilation in XFS on ARM. I'll confirm with the XFS developers whether your problem may be caused by this too after reproducing it on another ARM machine, hopefully this weekend. ACK, I was talking to Eric Sandeen on #xfs and we played around with stuff like 'xfs_db -r /dev/... = sb 0; p', xfs_check,... and came to the same conclusion. I've the log from xfs_repair available, JFTR: # xfs_repair -n /dev/sdb2 Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 entry in shortform directory 128 references invalid inode 1852205415 size of entry #0 overflows space left in in shortform dir 128 would junk 4 entries would have corrected entry count in directory 128 from 4 to 0 would have corrected directory 128 size from 59 to 8 would have corrected root directory 128 .. entry from 8390144 to 128 entry in shortform directory 131 references invalid inode 3619769856 size of entry #0 overflows space left in in shortform dir 131 would junk 4 entries would have corrected entry count in directory 131 from 4 to 0 would have corrected directory 131 size from 67 to 8 [...] regards, -mika- pgpQiBcfmXiUH.pgp Description: PGP signature
Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm
Package: linux-image-2.6.18-4-ixp4xx Version: 2.6.18.dfsg.1-11 Severity: important I'm using the NSLU2 device with Debian (http://www.cyrius.com/debian/nslu2/): # uname -a Linux NSLU 2.6.18-4-ixp4xx #1 Thu Feb 22 14:00:55 UTC 2007 armv5tel GNU/Linux The problem: using a partition which has been generated on a x86 system using the filesystem XFS does not work on arm/NSLU2. Mounting the partition does not indicate any problems in the syslog, but access to the partition/files is definitely not possible: # ls -la /mnt/sdb2 total 4 drwxr-xr-x 7 root root 76 Oct 13 00:09 / drwxr-xr-x 7 root root 76 Oct 13 00:09 / drwxr-xr-x 7 root root 76 Oct 13 00:09 / drwxr-xr-x 7 root root 76 Oct 13 00:09 / drwxr-xr-x 7 root root 76 Oct 13 00:09 ./ drwxr-xr-x 4 root root 4096 Mar 7 19:46 ../ # Though the disk usage is displayed correct: # df -h FilesystemSize Used Avail Use% Mounted on /dev/sda1 773M 606M 128M 83% / tmpfs 15M 0 15M 0% /lib/init/rw udev 10M 44K 10M 1% /dev tmpfs 15M 0 15M 0% /dev/shm /dev/sdb2 271G 95G 176G 35% /mnt/sdb2 The XFS partition can be used without any problems on the x86 system, there's no data loss. XFS itself is ok on arm/NSLU2 if the partition has been generated on the arm platform using mkfs.xfs. I played around with xfs_repair, xfs_db, xfs_check,... tons of error messages are displayed though the partition itself is ok - it's just that there seem to be serious problems on the arm platform. The problem is reproducable, just run something like # mkfs.xfs -d file,name=/file,size=20m on a x86 system and try to mount the file on arm/NSLU2 then. If you need any further information, debugging output,... please let me know. regards, -mika- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
