Menu
▾
▴
axfs-developer
|
From: Andre P. <and...@im...> - 2008-11-18 13:20:02
|
Hi list, I am using a axfs with profiling enabled as my root filesystem. Here is my kernel command line: "console=ttyS0,115200n8 rootfstype=axfs rootflags=physaddr=0x360000". I am not able to mount the image in any other way than using the physaddr-flag (see last post for details). After extracting the captured profile I tried to build the appropriate profiled file system image. However, mounting this image in the same way does not work. Well, mounting it works but trying to execute init just raises some "illegal instruction" messages on my serial console. Seems like there is something wrong :-) Maybe mapping the XIP sections fails? If I mount the same image after booting the rootfs via nfs it works with the -o physaddr-flag, but I can't umount the image afterwards. If I just use /dev/mtd3 or /dev/mtdblock3 mouting also fails with a kernel NULL pointer dereference or with an Oops like the one below. I guess there is something wrong with handling the mount parameters on one hand and with mapping the XIP section on the other hand. Any hints? Best regards, Andre <log> # mount -t axfs /dev/mtdblock3 /mnt/flash/ [ 146.800000] Internal error: Oops: 17 [#1] [ 146.800000] Modules linked in: [ 146.800000] CPU: 0 [ 146.800000] PC is at memcpy+0x48/0x330 [ 146.800000] LR is at axfs_copy_mem+0x24/0x2c [ 146.800000] pc : [<c00f4f48>] lr : [<c00a6d6c>] Not tainted [ 146.800000] sp : c3de3b84 ip : 00000000 fp : c3de3bac [ 146.800000] r10: c3ced800 r9 : 00000000 r8 : 00000100 [ 146.800000] r7 : 00000000 r6 : 00000000 r5 : c03a8200 r4 : 00000100 [ 146.800000] r3 : c3ced800 r2 : 00000080 r1 : 00000000 r0 : c03c50c0 [ 146.800000] Flags: nzCv IRQs on FIQs on Mode SVC_32 Segment user [ 146.800000] Control: 397F [ 146.800000] Table: A03E4000 DAC: 00000015 [ 146.800000] Process mount (pid: 196, stack limit = 0xc3de2260) [ 146.800000] Stack: (0xc3de3b84 to 0xc3de4000) [ 146.800000] 3b80: c03a8200 00000000 00000000 00000100 c03c50c0 00000100 c00a6d6c [ 146.800000] 3ba0: c3de3bf4 c3de3bb0 c00a6e6c c00a6d54 00000100 00000000 c03c50c0 c03a8200 [ 146.800000] 3bc0: c02f4ba0 c03ac2a0 c02f4ba0 00000100 00000000 c03c50c0 c02f4ba0 c03ac2a0 [ 146.800000] 3be0: c02f4ba0 c0224b50 c3de3c54 c3de3bf8 c00a73f0 c00a6d80 00000100 00000000 [ 146.800000] 3c00: c03a8200 c3ced800 c02f4ba0 00000000 c3de3c54 c3de3c20 c006791c c007adc4 [ 146.800000] 3c20: c006f4c4 c3ced800 a0000013 c03a8200 c03a8200 c3cedc00 c02f4ba0 c03ac2a0 [ 146.800000] 3c40: c02f4ba0 c0224b50 c3de3c7c c3de3c58 c00a8e18 c00a7378 c3de3c7c c3d86000 [ 146.800000] 3c60: c3cedc00 c0224b50 00008000 00008000 c3de3cac c3de3c80 c00a8edc c00a8dd0 [ 146.800000] 3c80: c03ac2a0 c00a736c c02f4ba0 c3de3c98 01f00003 c3d86000 c3de3cc0 c3cedc00 [ 146.800000] 3ca0: c3de3d44 c3de3cb0 c00a91ec c00a8e88 00000003 c00a736c c02f4ba0 c025a600 [ 146.800000] 3cc0: c3d792b8 c02f4ca0 c3de3d14 c3de3cd8 c00624e4 00000001 00000001 00000000 [ 146.800000] 3ce0: 000000d0 00000001 c006f4c4 c03e2000 a0000013 c025a600 c0224b50 00008000 [ 146.800000] 3d00: c02f4ba0 c3d86000 c3de3d34 c3de3d18 c006274c c0062774 c3de3d3c c3de3d74 [ 146.800000] 3d20: c3cedc00 c3d86000 c0224b50 00008000 c02f4ba0 c3d86000 c3de3da4 c3de3d48 [ 146.800000] 3d40: c00a6cb0 c00a9058 c02f4ba0 c3de3d74 c3de3d7c c3de3d60 c006274c c0062774 [ 146.800000] 3d60: 00000000 c02f4ba0 00000000 00000000 c03e2000 00000000 c3d95ba0 c02f4ba0 [ 146.800000] 3d80: fffffff4 c3d86000 c03e2000 c0224b50 c03e2000 c000e000 c3de3dd4 c3de3da8 [ 146.800000] 3da0: c0067e38 c00a6a64 c02f4ba0 c03e2000 c3de3dd4 c0224b50 ffffffed c03e2000 [ 146.800000] 3dc0: c3d86000 00008000 c3de3df4 c3de3dd8 c0067ed0 c0067dec c3de3df4 00000000 [ 146.800000] 3de0: 00000000 00000000 c3de3f6c c3de3df8 c007cad0 c0067ea0 c3d67ee8 c0354040 [ 146.800000] 3e00: c3de3e4c c3de3e10 c00207dc c0020568 c3de3f44 00000001 00000001 00000017 [ 146.800000] 3e20: 00008000 ffffffff c0220678 00000017 c3de3f00 00062000 60000013 00061018 [ 146.800000] 3e40: c3de3efc c3de3e50 c0020974 c00205e8 c00f9144 c00f8a54 00000090 00000000 [ 146.800000] 3e60: c3cf4000 00001000 00001f03 c000a968 c000a968 0000000f 20000013 c0223804 [ 146.800000] 3e80: 00000000 00061018 c3de3ee4 c3de3e98 c0050a44 c0050460 00000044 c000afbc [ 146.800000] 3ea0: 000200d0 00000000 00000000 00000001 c0223a84 c0223a84 000061b0 00000000 [ 146.800000] 3ec0: 00061018 000000d0 00000000 c0354040 c3de2000 c0223a80 c3de3f34 ffffffff [ 146.800000] 3ee0: c3de3f34 00000018 c000fd58 c02f4320 c3de3f6c c3de3f00 c001a7ec 00000001 [ 146.800000] 3f00: 00000001 00000000 00000000 00062000 00001000 00061018 00000018 c03e2000 [ 146.800000] 3f20: c3de3f84 c3de2000 00061018 c3de3f6c 00000000 c3de3f48 00000000 c01af300 [ 146.800000] 3f40: 20000013 00000000 c3cf4000 bec62eaf 00008000 c001ad64 c3de2000 00061018 [ 146.800000] 3f60: c3de3fa4 c3de3f70 c007cbc8 c007c59c c03e2000 400a6e58 c3de3f9c c3d86000 [ 146.800000] 3f80: c000e000 c03e2000 00061018 bec62ebe bec62eaa 00000015 00000000 c3de3fa8 [ 146.800000] 3fa0: c001abe0 c007cb48 00061018 bec62ebe bec62eaf bec62ebe bec62eaa 00008000 [ 146.800000] 3fc0: 00061018 bec62ebe bec62eaa 00000015 00008000 00008000 00061018 0000c648 [ 146.800000] 3fe0: 4001b644 bec628a0 0002ff80 4001b654 20000010 bec62eaf 00000000 00000000 [ 146.800000] Backtrace: [ 146.800000] [<c00a6d48>] (axfs_copy_mem+0x0/0x2c) from [<c00a6e6c>] (axfs_copy_metadata+0xf8/0x1e0) [ 146.800000] [<c00a6d74>] (axfs_copy_metadata+0x0/0x1e0) from [<c00a73f0>] (axfs_fill_super+0x84/0x9b0) [ 146.800000] [<c00a736c>] (axfs_fill_super+0x0/0x9b0) from [<c00a8e18>] (get_sb_mtd_aux+0x54/0xb8) [ 146.800000] [<c00a8dc4>] (get_sb_mtd_aux+0x0/0xb8) from [<c00a8edc>] (get_sb_mtd_nr+0x60/0x70) [ 146.800000] r8 = 00008000 r7 = 00008000 r6 = C0224B50 r5 = C3CEDC00 [ 146.800000] r4 = C3D86000 [ 146.800000] [<c00a8e7c>] (get_sb_mtd_nr+0x0/0x70) from [<c00a91ec>] (axfs_get_sb_mtd+0x1a0/0x23c) [ 146.800000] r7 = C3CEDC00 r6 = C3DE3CC0 r5 = C3D86000 r4 = 01F00003 [ 146.800000] [<c00a904c>] (axfs_get_sb_mtd+0x0/0x23c) from [<c00a6cb0>] (axfs_get_sb+0x258/0x2f0) [ 146.800000] [<c00a6a58>] (axfs_get_sb+0x0/0x2f0) from [<c0067e38>] (vfs_kern_mount+0x58/0x94) [ 146.800000] [<c0067de0>] (vfs_kern_mount+0x0/0x94) from [<c0067ed0>] (do_kern_mount+0x3c/0x50) [ 146.800000] r8 = 00008000 r7 = C3D86000 r6 = C03E2000 r5 = FFFFFFED [ 146.800000] r4 = C0224B50 [ 146.800000] [<c0067e94>] (do_kern_mount+0x0/0x50) from [<c007cad0>] (do_mount+0x540/0x5ac) [ 146.800000] r6 = 00000000 r5 = 00000000 r4 = 00000000 [ 146.800000] [<c007c590>] (do_mount+0x0/0x5ac) from [<c007cbc8>] (sys_mount+0x8c/0xd4) [ 146.800000] [<c007cb3c>] (sys_mount+0x0/0xd4) from [<c001abe0>] (ret_fast_syscall+0x0/0x2c) [ 146.800000] r7 = 00000015 r6 = BEC62EAA r5 = BEC62EBE r4 = 00061018 [ 146.800000] Code: ba000002 f5d1f03c f5d1f05c f5d1f07c (e8b151f8) </log> |
|
From: Will M. <wjm...@gm...> - 2008-11-26 16:20:18
|
Andre, Sorry I haven't gotten back to you. Andre Puschmann wrote: > Hi list, > > I am using a axfs with profiling enabled as my root filesystem. Here is > my kernel command line: "console=ttyS0,115200n8 rootfstype=axfs > rootflags=physaddr=0x360000". I am not able to mount the image in any > other way than using the physaddr-flag (see last post for details). > I forgot to ask last time, what version of the kernel are you using? Mount methods other than iomem, physaddr and block devices are not (currently) supported pre-2.6.22, and our effective backport testing goes to 2.6.18. > After extracting the captured profile I tried to build the appropriate > profiled file system image. However, mounting this image in the same way > does not work. Well, mounting it works but trying to execute init just > raises some "illegal instruction" messages on my serial console. So when you attempt to mount AXFS as the root filing system, with a profiled image, and you mount via rootflags=physaddr, you get a segfault? We've had rumblings of a bug in mkfs.axfs that we've been needing to track down. > Seems > like there is something wrong :-) Maybe mapping the XIP sections fails? > If I mount the same image after booting the rootfs via nfs it works with > the -o physaddr-flag, but I can't umount the image afterwards. We have some noisy unmounts, depending on the kernel. When you mount after booting with nfs, does XIP work? > If I just > use /dev/mtd3 or /dev/mtdblock3 mouting also fails with a kernel NULL > pointer dereference or with an Oops like the one below. I guess there is > something wrong with handling the mount parameters on one hand and with > mapping the XIP section on the other hand. > Any hints? > > Best regards, > Andre > > > <log> > # mount -t axfs /dev/mtdblock3 /mnt/flash/ > [ 146.800000] Internal error: Oops: 17 [#1] > [ 146.800000] Modules linked in: > [ 146.800000] CPU: 0 > [ 146.800000] PC is at memcpy+0x48/0x330 > [ 146.800000] LR is at axfs_copy_mem+0x24/0x2c > [ 146.800000] pc : [<c00f4f48>] lr : [<c00a6d6c>] Not tainted > [ 146.800000] sp : c3de3b84 ip : 00000000 fp : c3de3bac > [ 146.800000] r10: c3ced800 r9 : 00000000 r8 : 00000100 > [ 146.800000] r7 : 00000000 r6 : 00000000 r5 : c03a8200 r4 : 00000100 > [ 146.800000] r3 : c3ced800 r2 : 00000080 r1 : 00000000 r0 : c03c50c0 > [ 146.800000] Flags: nzCv IRQs on FIQs on Mode SVC_32 Segment user > [ 146.800000] Control: 397F > [ 146.800000] Table: A03E4000 DAC: 00000015 > [ 146.800000] Process mount (pid: 196, stack limit = 0xc3de2260) > [ 146.800000] Stack: (0xc3de3b84 to 0xc3de4000) > [ 146.800000] 3b80: c03a8200 00000000 00000000 00000100 > c03c50c0 00000100 c00a6d6c > [ 146.800000] 3ba0: c3de3bf4 c3de3bb0 c00a6e6c c00a6d54 00000100 > 00000000 c03c50c0 c03a8200 > [ 146.800000] 3bc0: c02f4ba0 c03ac2a0 c02f4ba0 00000100 00000000 > c03c50c0 c02f4ba0 c03ac2a0 > [ 146.800000] 3be0: c02f4ba0 c0224b50 c3de3c54 c3de3bf8 c00a73f0 > c00a6d80 00000100 00000000 > [ 146.800000] 3c00: c03a8200 c3ced800 c02f4ba0 00000000 c3de3c54 > c3de3c20 c006791c c007adc4 > [ 146.800000] 3c20: c006f4c4 c3ced800 a0000013 c03a8200 c03a8200 > c3cedc00 c02f4ba0 c03ac2a0 > [ 146.800000] 3c40: c02f4ba0 c0224b50 c3de3c7c c3de3c58 c00a8e18 > c00a7378 c3de3c7c c3d86000 > [ 146.800000] 3c60: c3cedc00 c0224b50 00008000 00008000 c3de3cac > c3de3c80 c00a8edc c00a8dd0 > [ 146.800000] 3c80: c03ac2a0 c00a736c c02f4ba0 c3de3c98 01f00003 > c3d86000 c3de3cc0 c3cedc00 > [ 146.800000] 3ca0: c3de3d44 c3de3cb0 c00a91ec c00a8e88 00000003 > c00a736c c02f4ba0 c025a600 > [ 146.800000] 3cc0: c3d792b8 c02f4ca0 c3de3d14 c3de3cd8 c00624e4 > 00000001 00000001 00000000 > [ 146.800000] 3ce0: 000000d0 00000001 c006f4c4 c03e2000 a0000013 > c025a600 c0224b50 00008000 > [ 146.800000] 3d00: c02f4ba0 c3d86000 c3de3d34 c3de3d18 c006274c > c0062774 c3de3d3c c3de3d74 > [ 146.800000] 3d20: c3cedc00 c3d86000 c0224b50 00008000 c02f4ba0 > c3d86000 c3de3da4 c3de3d48 > [ 146.800000] 3d40: c00a6cb0 c00a9058 c02f4ba0 c3de3d74 c3de3d7c > c3de3d60 c006274c c0062774 > [ 146.800000] 3d60: 00000000 c02f4ba0 00000000 00000000 c03e2000 > 00000000 c3d95ba0 c02f4ba0 > [ 146.800000] 3d80: fffffff4 c3d86000 c03e2000 c0224b50 c03e2000 > c000e000 c3de3dd4 c3de3da8 > [ 146.800000] 3da0: c0067e38 c00a6a64 c02f4ba0 c03e2000 c3de3dd4 > c0224b50 ffffffed c03e2000 > [ 146.800000] 3dc0: c3d86000 00008000 c3de3df4 c3de3dd8 c0067ed0 > c0067dec c3de3df4 00000000 > [ 146.800000] 3de0: 00000000 00000000 c3de3f6c c3de3df8 c007cad0 > c0067ea0 c3d67ee8 c0354040 > [ 146.800000] 3e00: c3de3e4c c3de3e10 c00207dc c0020568 c3de3f44 > 00000001 00000001 00000017 > [ 146.800000] 3e20: 00008000 ffffffff c0220678 00000017 c3de3f00 > 00062000 60000013 00061018 > [ 146.800000] 3e40: c3de3efc c3de3e50 c0020974 c00205e8 c00f9144 > c00f8a54 00000090 00000000 > [ 146.800000] 3e60: c3cf4000 00001000 00001f03 c000a968 c000a968 > 0000000f 20000013 c0223804 > [ 146.800000] 3e80: 00000000 00061018 c3de3ee4 c3de3e98 c0050a44 > c0050460 00000044 c000afbc > [ 146.800000] 3ea0: 000200d0 00000000 00000000 00000001 c0223a84 > c0223a84 000061b0 00000000 > [ 146.800000] 3ec0: 00061018 000000d0 00000000 c0354040 c3de2000 > c0223a80 c3de3f34 ffffffff > [ 146.800000] 3ee0: c3de3f34 00000018 c000fd58 c02f4320 c3de3f6c > c3de3f00 c001a7ec 00000001 > [ 146.800000] 3f00: 00000001 00000000 00000000 00062000 00001000 > 00061018 00000018 c03e2000 > [ 146.800000] 3f20: c3de3f84 c3de2000 00061018 c3de3f6c 00000000 > c3de3f48 00000000 c01af300 > [ 146.800000] 3f40: 20000013 00000000 c3cf4000 bec62eaf 00008000 > c001ad64 c3de2000 00061018 > [ 146.800000] 3f60: c3de3fa4 c3de3f70 c007cbc8 c007c59c c03e2000 > 400a6e58 c3de3f9c c3d86000 > [ 146.800000] 3f80: c000e000 c03e2000 00061018 bec62ebe bec62eaa > 00000015 00000000 c3de3fa8 > [ 146.800000] 3fa0: c001abe0 c007cb48 00061018 bec62ebe bec62eaf > bec62ebe bec62eaa 00008000 > [ 146.800000] 3fc0: 00061018 bec62ebe bec62eaa 00000015 00008000 > 00008000 00061018 0000c648 > [ 146.800000] 3fe0: 4001b644 bec628a0 0002ff80 4001b654 20000010 > bec62eaf 00000000 00000000 > [ 146.800000] Backtrace: > [ 146.800000] [<c00a6d48>] (axfs_copy_mem+0x0/0x2c) from [<c00a6e6c>] > (axfs_copy_metadata+0xf8/0x1e0) > [ 146.800000] [<c00a6d74>] (axfs_copy_metadata+0x0/0x1e0) from > [<c00a73f0>] (axfs_fill_super+0x84/0x9b0) > [ 146.800000] [<c00a736c>] (axfs_fill_super+0x0/0x9b0) from > [<c00a8e18>] (get_sb_mtd_aux+0x54/0xb8) > [ 146.800000] [<c00a8dc4>] (get_sb_mtd_aux+0x0/0xb8) from [<c00a8edc>] > (get_sb_mtd_nr+0x60/0x70) > [ 146.800000] r8 = 00008000 r7 = 00008000 r6 = C0224B50 r5 = C3CEDC00 > [ 146.800000] r4 = C3D86000 > [ 146.800000] [<c00a8e7c>] (get_sb_mtd_nr+0x0/0x70) from [<c00a91ec>] > (axfs_get_sb_mtd+0x1a0/0x23c) > [ 146.800000] r7 = C3CEDC00 r6 = C3DE3CC0 r5 = C3D86000 r4 = 01F00003 > [ 146.800000] [<c00a904c>] (axfs_get_sb_mtd+0x0/0x23c) from > [<c00a6cb0>] (axfs_get_sb+0x258/0x2f0) > [ 146.800000] [<c00a6a58>] (axfs_get_sb+0x0/0x2f0) from [<c0067e38>] > (vfs_kern_mount+0x58/0x94) > [ 146.800000] [<c0067de0>] (vfs_kern_mount+0x0/0x94) from [<c0067ed0>] > (do_kern_mount+0x3c/0x50) > [ 146.800000] r8 = 00008000 r7 = C3D86000 r6 = C03E2000 r5 = FFFFFFED > [ 146.800000] r4 = C0224B50 > [ 146.800000] [<c0067e94>] (do_kern_mount+0x0/0x50) from [<c007cad0>] > (do_mount+0x540/0x5ac) > [ 146.800000] r6 = 00000000 r5 = 00000000 r4 = 00000000 > [ 146.800000] [<c007c590>] (do_mount+0x0/0x5ac) from [<c007cbc8>] > (sys_mount+0x8c/0xd4) > [ 146.800000] [<c007cb3c>] (sys_mount+0x0/0xd4) from [<c001abe0>] > (ret_fast_syscall+0x0/0x2c) > [ 146.800000] r7 = 00000015 r6 = BEC62EAA r5 = BEC62EBE r4 = 00061018 > [ 146.800000] Code: ba000002 f5d1f03c f5d1f05c f5d1f07c (e8b151f8) > </log> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > AXFS-developer mailing list > AXF...@li... > https://lists.sourceforge.net/lists/listinfo/axfs-developer > > |
|
From: Andre P. <and...@im...> - 2008-11-26 16:55:54
|
Hi Will, Will Marone wrote: > I forgot to ask last time, what version of the kernel are you using? > Mount methods other than iomem, physaddr and block devices are not > (currently) supported pre-2.6.22, and our effective backport testing > goes to 2.6.18. I am running these tests on a gumstix verdex board which has a ARM pxa270 core. Currently, I am using the stock gumstix kernel, which is version 2.6.21. > So when you attempt to mount AXFS as the root filing system, with a > profiled > image, and you mount via rootflags=physaddr, you get a segfault? No segfault, using the physaddr flag raises this: <log> [ 1.170000] VFS: Mounted root (axfs filesystem) readonly. [ 1.170000] Freeing init memory: 72K Illegal instruction sh: rcBoot: unknown operand Illegal instruction Illegal instruction </log> As you can see, mounting is ok. Executing any application raises the illegal instruction. If I append "init=/bin/sh" to my command line, I get the shell, so busybox seems to _work partly_. If I then run "ls" or "dmesg" or whatever, I get the illegal instruction again. > We've had > rumblings of a bug in mkfs.axfs that we've been needing to track down. So let's do this! You need my images or profiles? >> Seems like there is something wrong :-) Maybe mapping the XIP >> sections fails? >> If I mount the same image after booting the rootfs via nfs it works >> with the -o physaddr-flag, but I can't umount the image afterwards. > We have some noisy unmounts, depending on the kernel. When you mount > after > booting with nfs, does XIP work? Yes, works. Regards, Andre |
|
From: Will M. <wjm...@gm...> - 2008-11-27 18:00:46
|
Andre Puschmann wrote: >> So when you attempt to mount AXFS as the root filing system, with a >> profiled >> image, and you mount via rootflags=physaddr, you get a segfault? > No segfault, using the physaddr flag raises this: > <log> > [ 1.170000] VFS: Mounted root (axfs filesystem) readonly. > [ 1.170000] Freeing init memory: 72K > Illegal instruction > sh: rcBoot: unknown operand > Illegal instruction > Illegal instruction > </log> > > As you can see, mounting is ok. Executing any application raises the > illegal instruction. If I append "init=/bin/sh" to my command line, I > get the shell, so busybox seems to _work partly_. If I then run "ls" > or "dmesg" or whatever, I get the illegal instruction again. Odd that XIP fails when mounted as root but behaves normally when mounted after boot. I'm assuming you have no issues if you generate the image without the profile. >> We've had rumblings of a bug in mkfs.axfs that we've been needing to >> track down. > So let's do this! You need my images or profiles? If you can share both, that would be excellent. > >>> Seems like there is something wrong :-) Maybe mapping the XIP >>> sections fails? >>> If I mount the same image after booting the rootfs via nfs it works >>> with the -o physaddr-flag, but I can't umount the image afterwards. >> We have some noisy unmounts, depending on the kernel. When you mount >> after >> booting with nfs, does XIP work? > Yes, works. > > > Regards, > Andre Will Marone |
|
From: Andre P. <and...@im...> - 2008-11-28 08:39:38
|
Hi Will, Will Marone wrote: > Odd that XIP fails when mounted as root but behaves normally when > mounted after boot. I'm assuming you have no issues if you generate > the image without the profile. Yes, of course, I use the same file basis. The non-profiled image works just fine. >>> We've had rumblings of a bug in mkfs.axfs that we've been needing to >>> track down. >> So let's do this! You need my images or profiles? > If you can share both, that would be excellent. Maybe it is better to cut that discussion off at this point and re-release it to the real world after we found a solution ... Best regards, Andre |
|
From: Will M. <wjm...@gm...> - 2008-12-11 23:45:42
|
Andre, We took a closer look at the bug you were encountering, and did a little more indepth testing and managed to produce a bug in XIP execution in our own filesystem images similar to what you described that caused failures when executing using a profiled filesystem generated by mkfs.axfs. This bug cropped up in 2.6.25 and prior, back to at least 2.6.18 but wasn't present in 2.6.26 and onward. We made some changes which are now up on sourceforge. We ran our tests against the new image both before and after the changes, and the crash was resolved. Let me know how these changes work for you, as I suspect your problem is related to (or the same as) one we were informed of on 2.6.18. Will Marone |
|
From: Andre P. <and...@im...> - 2008-12-19 11:05:44
|
Hi Will, thanks for figuring that out! I tried to apply the changes that you made on my 2.6.21 kernel. Despite a few changes I had to make the kernel doesn't allow to start any application. After mounting the image (which works) there is no other output. So I guess init is not running properly. But I have to admit that I applied the patches by hand with the help of the websvn interface as I can't use normal svn through our firewall. Maybe I overlooked something here. At least I encountered these problems: - vm_insert_mixed() is only available in kernel around 2.6.25/26 not 2.6.17 (see axfs_inode.c) - when compiled with mtd support axfs_get_io_dev_size() is not available, the prototype is defined but not more Would be nice to have some benchmarks of axfs without profiling as cramfs (+linear patch) is still a bit faster, at least in my environment. Best regards, Andre Will Marone wrote: > Andre, > > We took a closer look at the bug you were encountering, and did a > little more indepth testing and managed to produce a bug in XIP > execution in our own filesystem images similar to what you described > that caused failures when executing using a profiled filesystem > generated by mkfs.axfs. > > This bug cropped up in 2.6.25 and prior, back to at least 2.6.18 but > wasn't present in 2.6.26 and onward. We made some changes which are > now up on sourceforge. > > We ran our tests against the new image both before and after the > changes, and the crash was resolved. > > Let me know how these changes work for you, as I suspect your problem > is related to (or the same as) one we were informed of on 2.6.18. > > Will Marone |
Thanks for helping keep SourceForge clean.
X