Re: XFS Fails Quality Assurance Tests on ARM
From: Christoph Hellwig <[EMAIL PROTECTED]> Date: Tue, 30 Oct 2007 17:54:18 + > On Tue, Oct 30, 2007 at 12:47:35AM -0500, Eric Sandeen wrote: > > There was a patch floating around to "fix" it but it's not on-disk > > compatible w/ x86 & friends, it just makes things consistent for arm. I > > think packing some of these structures would take care of it, but this > > problem could use some attention & testing I think, it's been floating > > around a long time. > > Do you have a pointer to that patch? Once the unaliged fields are > identified simply using get_unaligned on them should fix this issue. True, but there is the tertiary issue that the packing done by these platforms might mean that the on-disk format is different on different platforms which the XFS folks likely want to avoid if possible. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: XFS Fails Quality Assurance Tests on ARM
Christoph Hellwig wrote: > On Tue, Oct 30, 2007 at 12:47:35AM -0500, Eric Sandeen wrote: >> There was a patch floating around to "fix" it but it's not on-disk >> compatible w/ x86 & friends, it just makes things consistent for arm. I >> think packing some of these structures would take care of it, but this >> problem could use some attention & testing I think, it's been floating >> around a long time. > > Do you have a pointer to that patch? Once the unaliged fields are > identified simply using get_unaligned on them should fix this issue. > http://www.spinics.net/lists/arm-kernel/msg18479.html is the one I was thinking of, IIRC, but it just does the math a different way so that it comes out right on ARM, and doesn't fix the underlying problem. I think the end result is no crashes, but a filesystem which is broken when used on another arch. But the problem AFAIK is that the *on-disk* structures don't match when compiled with one ARM abi or another, I think, so get_unaligned isn't going to help here. -Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: XFS Fails Quality Assurance Tests on ARM
On Tue, Oct 30, 2007 at 12:47:35AM -0500, Eric Sandeen wrote: > There was a patch floating around to "fix" it but it's not on-disk > compatible w/ x86 & friends, it just makes things consistent for arm. I > think packing some of these structures would take care of it, but this > problem could use some attention & testing I think, it's been floating > around a long time. Do you have a pointer to that patch? Once the unaliged fields are identified simply using get_unaligned on them should fix this issue. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: XFS Fails Quality Assurance Tests on ARM
On Tue, Oct 30, 2007 at 12:47:35AM -0500, Eric Sandeen wrote: There was a patch floating around to fix it but it's not on-disk compatible w/ x86 friends, it just makes things consistent for arm. I think packing some of these structures would take care of it, but this problem could use some attention testing I think, it's been floating around a long time. Do you have a pointer to that patch? Once the unaliged fields are identified simply using get_unaligned on them should fix this issue. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: XFS Fails Quality Assurance Tests on ARM
Christoph Hellwig wrote: On Tue, Oct 30, 2007 at 12:47:35AM -0500, Eric Sandeen wrote: There was a patch floating around to fix it but it's not on-disk compatible w/ x86 friends, it just makes things consistent for arm. I think packing some of these structures would take care of it, but this problem could use some attention testing I think, it's been floating around a long time. Do you have a pointer to that patch? Once the unaliged fields are identified simply using get_unaligned on them should fix this issue. http://www.spinics.net/lists/arm-kernel/msg18479.html is the one I was thinking of, IIRC, but it just does the math a different way so that it comes out right on ARM, and doesn't fix the underlying problem. I think the end result is no crashes, but a filesystem which is broken when used on another arch. But the problem AFAIK is that the *on-disk* structures don't match when compiled with one ARM abi or another, I think, so get_unaligned isn't going to help here. -Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: XFS Fails Quality Assurance Tests on ARM
From: Christoph Hellwig [EMAIL PROTECTED] Date: Tue, 30 Oct 2007 17:54:18 + On Tue, Oct 30, 2007 at 12:47:35AM -0500, Eric Sandeen wrote: There was a patch floating around to fix it but it's not on-disk compatible w/ x86 friends, it just makes things consistent for arm. I think packing some of these structures would take care of it, but this problem could use some attention testing I think, it's been floating around a long time. Do you have a pointer to that patch? Once the unaliged fields are identified simply using get_unaligned on them should fix this issue. True, but there is the tertiary issue that the packing done by these platforms might mean that the on-disk format is different on different platforms which the XFS folks likely want to avoid if possible. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: XFS Fails Quality Assurance Tests on ARM
Andi Kleen wrote: > David Miller <[EMAIL PROTECTED]> writes: > >> From: Byron Bradley <[EMAIL PROTECTED]> >> Date: Fri, 31 Aug 2007 03:12:46 + (UTC) >> >>> Anybody got any ideas of how we fix this? >> I don't know how much testing XFS gets on ARM, but one thing that some >> ARM chips have is D-cache aliasing problems and one thing XFS uses a >> lot is virtual remapping of various data structures via vmap(). >> >> This might be what is causing the problems. Sorry, I lost the original to reply to, but stumbled on this thread looking for something else. :) Anyway, from the assertion: Assertion failed: (char *)sfep - (char *)sfp == dp->i_d.di_size, file: fs/xfs/xfs_dir2_sf.c, line: 647 kernel BUG at fs/xfs/support/debug.c:82! this is almost certainly a result of xfs_dir2_sf_off_t, xfs_dir2_sf_hdr_t, and/or xfs_dir2_sf_entry_t or others not being "properly" aligned on arm. There was a patch floating around to "fix" it but it's not on-disk compatible w/ x86 & friends, it just makes things consistent for arm. I think packing some of these structures would take care of it, but this problem could use some attention & testing I think, it's been floating around a long time. -Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: XFS Fails Quality Assurance Tests on ARM
Andi Kleen wrote: David Miller [EMAIL PROTECTED] writes: From: Byron Bradley [EMAIL PROTECTED] Date: Fri, 31 Aug 2007 03:12:46 + (UTC) Anybody got any ideas of how we fix this? I don't know how much testing XFS gets on ARM, but one thing that some ARM chips have is D-cache aliasing problems and one thing XFS uses a lot is virtual remapping of various data structures via vmap(). This might be what is causing the problems. Sorry, I lost the original to reply to, but stumbled on this thread looking for something else. :) Anyway, from the assertion: Assertion failed: (char *)sfep - (char *)sfp == dp-i_d.di_size, file: fs/xfs/xfs_dir2_sf.c, line: 647 kernel BUG at fs/xfs/support/debug.c:82! this is almost certainly a result of xfs_dir2_sf_off_t, xfs_dir2_sf_hdr_t, and/or xfs_dir2_sf_entry_t or others not being properly aligned on arm. There was a patch floating around to fix it but it's not on-disk compatible w/ x86 friends, it just makes things consistent for arm. I think packing some of these structures would take care of it, but this problem could use some attention testing I think, it's been floating around a long time. -Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: XFS Fails Quality Assurance Tests on ARM
On Fri, Sep 28, 2007 at 07:40:48AM +1000, Nick Piggin wrote: > On Sunday 02 September 2007 08:14, Andi Kleen wrote: > > David Miller <[EMAIL PROTECTED]> writes: > > > From: Byron Bradley <[EMAIL PROTECTED]> > > > Date: Fri, 31 Aug 2007 03:12:46 + (UTC) > > > > Anybody got any ideas of how we fix this? > > > > > > I don't know how much testing XFS gets on ARM, but one thing that some > > > ARM chips have is D-cache aliasing problems and one thing XFS uses a > > > lot is virtual remapping of various data structures via vmap(). > > > > > > This might be what is causing the problems. > > > > AFAIK XFS uses vmap() mainly during log replay. If David's theory > > was true then the failures must be seen during tests that do > > this. > > I think it can also do vmap for directory lookups, and it crashed > in some directory lookup AFAIKS. > > One way to verify would be to create the XFS filesystem with PAGE_SIZE > directory blocks (mkfs.xfs -nsize=PAGE_SIZE) I believe. Dave will correct > me if I'm wrong. By default the directory block size is the same as the filesystem block size which means it will be <= PAGE_SIZE unless some special mkfs.xfs goo was used. What is the output of 'xfs_info ' on the machine in question? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: XFS Fails Quality Assurance Tests on ARM
On Fri, Sep 28, 2007 at 07:40:48AM +1000, Nick Piggin wrote: On Sunday 02 September 2007 08:14, Andi Kleen wrote: David Miller [EMAIL PROTECTED] writes: From: Byron Bradley [EMAIL PROTECTED] Date: Fri, 31 Aug 2007 03:12:46 + (UTC) Anybody got any ideas of how we fix this? I don't know how much testing XFS gets on ARM, but one thing that some ARM chips have is D-cache aliasing problems and one thing XFS uses a lot is virtual remapping of various data structures via vmap(). This might be what is causing the problems. AFAIK XFS uses vmap() mainly during log replay. If David's theory was true then the failures must be seen during tests that do this. I think it can also do vmap for directory lookups, and it crashed in some directory lookup AFAIKS. One way to verify would be to create the XFS filesystem with PAGE_SIZE directory blocks (mkfs.xfs -nsize=PAGE_SIZE) I believe. Dave will correct me if I'm wrong. By default the directory block size is the same as the filesystem block size which means it will be = PAGE_SIZE unless some special mkfs.xfs goo was used. What is the output of 'xfs_info mntpt' on the machine in question? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: XFS Fails Quality Assurance Tests on ARM
On Sunday 02 September 2007 08:14, Andi Kleen wrote: > David Miller <[EMAIL PROTECTED]> writes: > > From: Byron Bradley <[EMAIL PROTECTED]> > > Date: Fri, 31 Aug 2007 03:12:46 + (UTC) > > > > > Anybody got any ideas of how we fix this? > > > > I don't know how much testing XFS gets on ARM, but one thing that some > > ARM chips have is D-cache aliasing problems and one thing XFS uses a > > lot is virtual remapping of various data structures via vmap(). > > > > This might be what is causing the problems. > > AFAIK XFS uses vmap() mainly during log replay. If David's theory > was true then the failures must be seen during tests that do > this. I think it can also do vmap for directory lookups, and it crashed in some directory lookup AFAIKS. One way to verify would be to create the XFS filesystem with PAGE_SIZE directory blocks (mkfs.xfs -nsize=PAGE_SIZE) I believe. Dave will correct me if I'm wrong. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: XFS Fails Quality Assurance Tests on ARM
On Sunday 02 September 2007 08:14, Andi Kleen wrote: David Miller [EMAIL PROTECTED] writes: From: Byron Bradley [EMAIL PROTECTED] Date: Fri, 31 Aug 2007 03:12:46 + (UTC) Anybody got any ideas of how we fix this? I don't know how much testing XFS gets on ARM, but one thing that some ARM chips have is D-cache aliasing problems and one thing XFS uses a lot is virtual remapping of various data structures via vmap(). This might be what is causing the problems. AFAIK XFS uses vmap() mainly during log replay. If David's theory was true then the failures must be seen during tests that do this. I think it can also do vmap for directory lookups, and it crashed in some directory lookup AFAIKS. One way to verify would be to create the XFS filesystem with PAGE_SIZE directory blocks (mkfs.xfs -nsize=PAGE_SIZE) I believe. Dave will correct me if I'm wrong. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: XFS Fails Quality Assurance Tests on ARM
David Miller <[EMAIL PROTECTED]> writes: > From: Byron Bradley <[EMAIL PROTECTED]> > Date: Fri, 31 Aug 2007 03:12:46 + (UTC) > > > Anybody got any ideas of how we fix this? > > I don't know how much testing XFS gets on ARM, but one thing that some > ARM chips have is D-cache aliasing problems and one thing XFS uses a > lot is virtual remapping of various data structures via vmap(). > > This might be what is causing the problems. AFAIK XFS uses vmap() mainly during log replay. If David's theory was true then the failures must be seen during tests that do this. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: XFS Fails Quality Assurance Tests on ARM
David Miller [EMAIL PROTECTED] writes: From: Byron Bradley [EMAIL PROTECTED] Date: Fri, 31 Aug 2007 03:12:46 + (UTC) Anybody got any ideas of how we fix this? I don't know how much testing XFS gets on ARM, but one thing that some ARM chips have is D-cache aliasing problems and one thing XFS uses a lot is virtual remapping of various data structures via vmap(). This might be what is causing the problems. AFAIK XFS uses vmap() mainly during log replay. If David's theory was true then the failures must be seen during tests that do this. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: XFS Fails Quality Assurance Tests on ARM
From: Byron Bradley <[EMAIL PROTECTED]> Date: Fri, 31 Aug 2007 03:12:46 + (UTC) > Anybody got any ideas of how we fix this? I don't know how much testing XFS gets on ARM, but one thing that some ARM chips have is D-cache aliasing problems and one thing XFS uses a lot is virtual remapping of various data structures via vmap(). This might be what is causing the problems. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
XFS Fails Quality Assurance Tests on ARM
[to: linux-xfs]
[cc: lkml]
Hello,
I am one of the developers at http://linkstationwiki.net , we are trying to
port linux (2.6.22) to the LinkStation Pro. This has an ARM926EJ chip and
we are having problems with XFS (the default filesystem for these devices).
While we only have a few users who have reported problems with XFS in
real life, the quality assurance tests consistently fail and leave the
partitions in an inconsistent and irreparable state. With debug mode
enabled the following assertion fails during test 001:
Assertion failed: (char *)sfep - (char *)sfp == dp->i_d.di_size, file:
fs/xfs/xfs_dir2_sf.c, line: 647 kernel BUG at fs/xfs/support/debug.c:82!
Unable to handle kernel NULL pointer dereference at virtual address
pgd = c5888000
[] *pgd=06254031, *pte=, *ppte= Internal error:
Oops: 817 [#1]
Modules linked in: nfs nfsd exportfs lockd nfs_acl sunrpc reiserfs fuse
CPU: 0Not tainted (2.6.22 #7)
PC is at __bug+0x20/0x2c
LR is at 0x6013
pc : []lr : [<6013>]psr: 6013 sp : c678fba0 ip
: c678fad0 fp : c678fbac r10: c606fd40 r9 : c01a6aac r8 : 0008 r7 :
c606fda8 r6 : r5 : 0030 r4 : c606fdae r3 : r2 :
r1 : 223a r0 : 002c Flags: nZCv IRQs on FIQs on Mode
SVC_32 Segment user Control: a005317f Table: 05888000 DAC: 0015
Process mkdir (pid: 1522, stack limit = 0xc678e260) Stack: (0xc678fba0 to
0xc679)
fba0: c678fbbc c678fbb0 c01ab70c c002936c c678fbe4 c678fbc0 c015d6e0
c01ab6ec fbc0: c63b8290 c606fd40 0008 c678fd04
c678fc1c c678fbe8 fbe0: c015d760 c015d5f4 c00c48a8 c678fc20 c678fc0c
c63b8290 c606fd40 fc00: 0008 c01a6aac c678fd04
c678fca4 c678fc20 c015205c c015d748 fc20: c63b8290 0004 c678ff00
0008 c160e498 062d19b9 fc40: c606fd40
0008 fc60: 05f2
c018f22c 0100 fc80:
c606fd60 c63b8238 c606fd40 c678fcf8 c678fce4 c678fca8
fca0: c018f244 c0151f48 c678fcf8 c016bec0 0008 0046
fcc0: 0008 0046 c606fd60 c606fd40 c63b8238
c678fd34 c678fce8 fce0: c01953b4 c018f1e4 c678fd04 c678fcf8 0010
c678fd44 c678e000 000200d2 fd00: c678fd2c c678fd10 c678fd2c c63b8238
c61a2458 c678fdb0 c678fda4 fd20: c1714aa0 c6070e40 c678fd5c
c678fd38 c01a6aac c019530c fd40: c61a2458 c678fdb0
c678fec0 c63b8238 c678fd94 c678fd60 c009639c c01a6a68 fd60: c678e000
c6070eac c678fdcc c678fda4 c5e7700e 0107 c678fec0 c5e77000 fd80:
c678e000 c678fde4 c678fd98 c00981c0 c0096230 c678e000 0001
fda0: c678fdc4 00c27168 0004 c5e7700a c1714aa0 c61a2458 c678fdf4
c678fec0 fdc0: c17141a0 c678fec0 c78ba598 c5e77000 c678e000 c678fde8
c678fe5c c678fde8 fde0: c0098914 c00979a0 c78ba598 c17141a0 0017
4013c000 c678ff3c 0001 fe00: 0001 c678ffb0 4013c058
0c678ffac c678ff00 fe20: c0024230 c002c6b0 c5889000 c5a64b64 c678ff10
0002 c678fec0 c0552200 fe40: c5e77000 0001 c0025794 009000c3
c678fe6c c678fe60 c0098a18 c0098894 fe60: c678fe9c c678fe70 c0098c40
c0098a04 c678fe9c c678fe80 c5e77000 0001 fe80: c678fec0 ff9c
c0025794 009000c3 c678febc c678fea0 c0099748 c0098b90 fea0: bebde6c4
c678ff40 c678fec0 00c3 c678ff2c c678fec0 c0092184 c0099714 fec0:
c61a2458 c1714aa0 0017 4013c000 c678ff3c 0001 0001
fee0: c678ffb0 4013c058 40149000 c678ffac c678ff00 c0024230
c002c6b0 ff00: c5889000 c5a64b64 c678ff10 0002 bebde6c4
c678ff40 bebde911 ff20: c678ff3c c678ff30 c0092274 c0092170 c678ffa4
c678ff40 c002b270 c0092268 ff40: 40017000 c0025794 c678ff64
400d9000 40016000 ff60: 0001 1fdc 0001
0001520c 40149000 c678ff9c c678ff88 ff80: c002c9c0 c002c6b0
0001 c678ffa8 ffa0: c0024fa0
c002b260 0001 bebde911 bebde6c4 bebde6c4 ffc0:
0001 bebde911 bebde7a4 0003 0001 01ed bebde754
ffe0: 400e1300 bebde638 984c 400e1310 6010 bebde911
Backtrace:
[] (__bug+0x0/0x2c) from [] (assfail+0x30/0x38)
[] (assfail+0x0/0x38) from []
(xfs_dir2_sf_check+0xfc/0x154) [] (xfs_dir2_sf_check+0x0/0x154)
from [] (xfs_dir2_sf_lookup+0x28/0x360) []
(xfs_dir2_sf_lookup+0x0/0x360) from []
(xfs_dir_lookup+0x124/0x170) [] (xfs_dir_lookup+0x0/0x170) from
[] (xfs_dir_lookup_int+0x70/0x134)
r7:c678fcf8 r6:c606fd40 r5:c63b8238 r4:c606fd60
[] (xfs_dir_lookup_int+0x0/0x134) from []
(xfs_lookup+0xb8/0x160) [] (xfs_lookup+0x0/0x160) from
[] (xfs_vn_lookup+0x54/0x98) []
(xfs_vn_lookup+0x0/0x98) from [] (do_lookup+0x17c/0x1b8)
r5:c63b8238 r4:c678fec0
[] (do_lookup+0x0/0x1b8) from []
(__link_path_walk+0x830/0xef4) [] (__link_path_walk+0x0/0xef4)
from [] (link_path_walk+0x90/0x170) []
(link_path_walk+0x0/0x170) from [] (path_walk+0x24/0x28)
[] (path_walk+0x0/0x28) from []
XFS Fails Quality Assurance Tests on ARM
[to: linux-xfs]
[cc: lkml]
Hello,
I am one of the developers at http://linkstationwiki.net , we are trying to
port linux (2.6.22) to the LinkStation Pro. This has an ARM926EJ chip and
we are having problems with XFS (the default filesystem for these devices).
While we only have a few users who have reported problems with XFS in
real life, the quality assurance tests consistently fail and leave the
partitions in an inconsistent and irreparable state. With debug mode
enabled the following assertion fails during test 001:
Assertion failed: (char *)sfep - (char *)sfp == dp-i_d.di_size, file:
fs/xfs/xfs_dir2_sf.c, line: 647 kernel BUG at fs/xfs/support/debug.c:82!
Unable to handle kernel NULL pointer dereference at virtual address
pgd = c5888000
[] *pgd=06254031, *pte=, *ppte= Internal error:
Oops: 817 [#1]
Modules linked in: nfs nfsd exportfs lockd nfs_acl sunrpc reiserfs fuse
CPU: 0Not tainted (2.6.22 #7)
PC is at __bug+0x20/0x2c
LR is at 0x6013
pc : [c002937c]lr : [6013]psr: 6013 sp : c678fba0 ip
: c678fad0 fp : c678fbac r10: c606fd40 r9 : c01a6aac r8 : 0008 r7 :
c606fda8 r6 : r5 : 0030 r4 : c606fdae r3 : r2 :
r1 : 223a r0 : 002c Flags: nZCv IRQs on FIQs on Mode
SVC_32 Segment user Control: a005317f Table: 05888000 DAC: 0015
Process mkdir (pid: 1522, stack limit = 0xc678e260) Stack: (0xc678fba0 to
0xc679)
fba0: c678fbbc c678fbb0 c01ab70c c002936c c678fbe4 c678fbc0 c015d6e0
c01ab6ec fbc0: c63b8290 c606fd40 0008 c678fd04
c678fc1c c678fbe8 fbe0: c015d760 c015d5f4 c00c48a8 c678fc20 c678fc0c
c63b8290 c606fd40 fc00: 0008 c01a6aac c678fd04
c678fca4 c678fc20 c015205c c015d748 fc20: c63b8290 0004 c678ff00
0008 c160e498 062d19b9 fc40: c606fd40
0008 fc60: 05f2
c018f22c 0100 fc80:
c606fd60 c63b8238 c606fd40 c678fcf8 c678fce4 c678fca8
fca0: c018f244 c0151f48 c678fcf8 c016bec0 0008 0046
fcc0: 0008 0046 c606fd60 c606fd40 c63b8238
c678fd34 c678fce8 fce0: c01953b4 c018f1e4 c678fd04 c678fcf8 0010
c678fd44 c678e000 000200d2 fd00: c678fd2c c678fd10 c678fd2c c63b8238
c61a2458 c678fdb0 c678fda4 fd20: c1714aa0 c6070e40 c678fd5c
c678fd38 c01a6aac c019530c fd40: c61a2458 c678fdb0
c678fec0 c63b8238 c678fd94 c678fd60 c009639c c01a6a68 fd60: c678e000
c6070eac c678fdcc c678fda4 c5e7700e 0107 c678fec0 c5e77000 fd80:
c678e000 c678fde4 c678fd98 c00981c0 c0096230 c678e000 0001
fda0: c678fdc4 00c27168 0004 c5e7700a c1714aa0 c61a2458 c678fdf4
c678fec0 fdc0: c17141a0 c678fec0 c78ba598 c5e77000 c678e000 c678fde8
c678fe5c c678fde8 fde0: c0098914 c00979a0 c78ba598 c17141a0 0017
4013c000 c678ff3c 0001 fe00: 0001 c678ffb0 4013c058
0c678ffac c678ff00 fe20: c0024230 c002c6b0 c5889000 c5a64b64 c678ff10
0002 c678fec0 c0552200 fe40: c5e77000 0001 c0025794 009000c3
c678fe6c c678fe60 c0098a18 c0098894 fe60: c678fe9c c678fe70 c0098c40
c0098a04 c678fe9c c678fe80 c5e77000 0001 fe80: c678fec0 ff9c
c0025794 009000c3 c678febc c678fea0 c0099748 c0098b90 fea0: bebde6c4
c678ff40 c678fec0 00c3 c678ff2c c678fec0 c0092184 c0099714 fec0:
c61a2458 c1714aa0 0017 4013c000 c678ff3c 0001 0001
fee0: c678ffb0 4013c058 40149000 c678ffac c678ff00 c0024230
c002c6b0 ff00: c5889000 c5a64b64 c678ff10 0002 bebde6c4
c678ff40 bebde911 ff20: c678ff3c c678ff30 c0092274 c0092170 c678ffa4
c678ff40 c002b270 c0092268 ff40: 40017000 c0025794 c678ff64
400d9000 40016000 ff60: 0001 1fdc 0001
0001520c 40149000 c678ff9c c678ff88 ff80: c002c9c0 c002c6b0
0001 c678ffa8 ffa0: c0024fa0
c002b260 0001 bebde911 bebde6c4 bebde6c4 ffc0:
0001 bebde911 bebde7a4 0003 0001 01ed bebde754
ffe0: 400e1300 bebde638 984c 400e1310 6010 bebde911
Backtrace:
[c002935c] (__bug+0x0/0x2c) from [c01ab70c] (assfail+0x30/0x38)
[c01ab6dc] (assfail+0x0/0x38) from [c015d6e0]
(xfs_dir2_sf_check+0xfc/0x154) [c015d5e4] (xfs_dir2_sf_check+0x0/0x154)
from [c015d760] (xfs_dir2_sf_lookup+0x28/0x360) [c015d738]
(xfs_dir2_sf_lookup+0x0/0x360) from [c015205c]
(xfs_dir_lookup+0x124/0x170) [c0151f38] (xfs_dir_lookup+0x0/0x170) from
[c018f244] (xfs_dir_lookup_int+0x70/0x134)
r7:c678fcf8 r6:c606fd40 r5:c63b8238 r4:c606fd60
[c018f1d4] (xfs_dir_lookup_int+0x0/0x134) from [c01953b4]
(xfs_lookup+0xb8/0x160) [c01952fc] (xfs_lookup+0x0/0x160) from
[c01a6aac] (xfs_vn_lookup+0x54/0x98) [c01a6a58]
(xfs_vn_lookup+0x0/0x98) from [c009639c] (do_lookup+0x17c/0x1b8)
r5:c63b8238 r4:c678fec0
[c0096220] (do_lookup+0x0/0x1b8) from [c00981c0]
(__link_path_walk+0x830/0xef4) [c0097990]
Re: XFS Fails Quality Assurance Tests on ARM
From: Byron Bradley [EMAIL PROTECTED] Date: Fri, 31 Aug 2007 03:12:46 + (UTC) Anybody got any ideas of how we fix this? I don't know how much testing XFS gets on ARM, but one thing that some ARM chips have is D-cache aliasing problems and one thing XFS uses a lot is virtual remapping of various data structures via vmap(). This might be what is causing the problems. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
