Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
Hi Artem, On Mon, 30 Jul 2012 16:56:50 +0300 Artem Bityutskiy wrote: > Hi Shmulik, I've separated out the defconfig changes and pushed patches > 1,2, and 3 to the UBI tree (the master branch). Patches 4 and 5 are > already merged upstream. I did a couple of minor modifications in > commentaries and messages and I think in variables declaration section, > nothing else. I'll send you the patches separately. Thanks! I've noticed a diff in the Kconfig describing MTD_UBI_BEB_LIMIT. In my original [PATCH 2/5] "ubi: Limit amount of reserved eraseblocks for bad PEB handling" I've amended the MTD_UBI_BEB_LIMIT explanation a bit. The diff between what's on linux-ubi and my suggested description is: - This option specifies the maximum bad physical eraseblocks UBI - expects on the UBI device (percents of total number of physical - eraseblocks on this MTD partition). If the underlying flash does not - admit of bad eraseblocks (e.g. NOR flash), this value is ignored. + If the MTD device admits of bad eraseblocks (e.g. NAND flash), UBI + reserves some amount of physical eraseblocks to handle new bad + eraseblocks. + This option specifies the maximum bad eraseblocks UBI expects on the + ubi device (percents of total number of flash eraseblocks). + This limit is used in order to derive amount of eraseblock UBI + reserves for handling new bad blocks. + If the device has more bad eraseblocks than this limit, UBI does not + reserve any physical eraseblocks for new bad eraseblocks, but + attempts to use available eraseblocks (if any). + If the underlying flash does not admit of bad eraseblocks (e.g. NOR + flash), this value is ignored. Just wanted to make sure you deliberately discarded these amendments. Regards, Shmulik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
Hi Artem, On Mon, 30 Jul 2012 16:56:50 +0300 Artem Bityutskiy dedeki...@gmail.com wrote: Hi Shmulik, I've separated out the defconfig changes and pushed patches 1,2, and 3 to the UBI tree (the master branch). Patches 4 and 5 are already merged upstream. I did a couple of minor modifications in commentaries and messages and I think in variables declaration section, nothing else. I'll send you the patches separately. Thanks! I've noticed a diff in the Kconfig describing MTD_UBI_BEB_LIMIT. In my original [PATCH 2/5] ubi: Limit amount of reserved eraseblocks for bad PEB handling I've amended the MTD_UBI_BEB_LIMIT explanation a bit. The diff between what's on linux-ubi and my suggested description is: - This option specifies the maximum bad physical eraseblocks UBI - expects on the UBI device (percents of total number of physical - eraseblocks on this MTD partition). If the underlying flash does not - admit of bad eraseblocks (e.g. NOR flash), this value is ignored. + If the MTD device admits of bad eraseblocks (e.g. NAND flash), UBI + reserves some amount of physical eraseblocks to handle new bad + eraseblocks. + This option specifies the maximum bad eraseblocks UBI expects on the + ubi device (percents of total number of flash eraseblocks). + This limit is used in order to derive amount of eraseblock UBI + reserves for handling new bad blocks. + If the device has more bad eraseblocks than this limit, UBI does not + reserve any physical eraseblocks for new bad eraseblocks, but + attempts to use available eraseblocks (if any). + If the underlying flash does not admit of bad eraseblocks (e.g. NOR + flash), this value is ignored. Just wanted to make sure you deliberately discarded these amendments. Regards, Shmulik -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
On Wed, 2012-07-04 at 11:05 +0300, Shmulik Ladkani wrote: > The existing mechanism of reserving PEBs for bad PEB handling has two > flaws: > - It is calculated as a percentage of good PEBs instead of total PEBs. > - There's no limit on the amount of PEBs UBI reserves for future bad > eraseblock handling. > > This patchset changes the mechanism to overcome these flaws. Hi Shmulik, I've separated out the defconfig changes and pushed patches 1,2, and 3 to the UBI tree (the master branch). Patches 4 and 5 are already merged upstream. I did a couple of minor modifications in commentaries and messages and I think in variables declaration section, nothing else. I'll send you the patches separately. Thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
On Wed, 2012-07-04 at 11:05 +0300, Shmulik Ladkani wrote: The existing mechanism of reserving PEBs for bad PEB handling has two flaws: - It is calculated as a percentage of good PEBs instead of total PEBs. - There's no limit on the amount of PEBs UBI reserves for future bad eraseblock handling. This patchset changes the mechanism to overcome these flaws. Hi Shmulik, I've separated out the defconfig changes and pushed patches 1,2, and 3 to the UBI tree (the master branch). Patches 4 and 5 are already merged upstream. I did a couple of minor modifications in commentaries and messages and I think in variables declaration section, nothing else. I'll send you the patches separately. Thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
On Tue, 2012-07-17 at 10:23 +0300, Shmulik Ladkani wrote: > But it would only make sense after accepting Richard's patchset as well, > which suggests configuring per-ubi-device beb limit via the attach ioctl. Yes, sure, you are right. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
On Tue, 2012-07-17 at 10:23 +0300, Shmulik Ladkani wrote: But it would only make sense after accepting Richard's patchset as well, which suggests configuring per-ubi-device beb limit via the attach ioctl. Yes, sure, you are right. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
Hi Artem, On Mon, 16 Jul 2012 18:33:57 +0300 Artem Bityutskiy wrote: > But one more think is the mtd web-site. I've grepped for '1%' and there > are plenty of them. I've changed them all to 2% more or less > mechanically - only cleaned up one section by removing out-of-date > information. Would you please grep for '2%' and review if the > information there is reasonable? Also, would you please add some more > info to this FAQ entry: > > http://linux-mtd.infradead.org/faq/ubi.html#L_bad_blocks_exceeded > > Or even better if you could write a separate section for this stuff in > the documentation, then you could remove that FAQ entry completely. Sure, I'll try to do it as well. But it would only make sense after accepting Richard's patchset as well, which suggests configuring per-ubi-device beb limit via the attach ioctl. I didn't had the time to properly review it yet, but IMO it looks more controversial. http://lists.infradead.org/pipermail/linux-mtd/2012-July/042803.html Regards, Shmulik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
Hi Artem, On Mon, 16 Jul 2012 18:33:57 +0300 Artem Bityutskiy dedeki...@gmail.com wrote: But one more think is the mtd web-site. I've grepped for '1%' and there are plenty of them. I've changed them all to 2% more or less mechanically - only cleaned up one section by removing out-of-date information. Would you please grep for '2%' and review if the information there is reasonable? Also, would you please add some more info to this FAQ entry: http://linux-mtd.infradead.org/faq/ubi.html#L_bad_blocks_exceeded Or even better if you could write a separate section for this stuff in the documentation, then you could remove that FAQ entry completely. Sure, I'll try to do it as well. But it would only make sense after accepting Richard's patchset as well, which suggests configuring per-ubi-device beb limit via the attach ioctl. I didn't had the time to properly review it yet, but IMO it looks more controversial. http://lists.infradead.org/pipermail/linux-mtd/2012-July/042803.html Regards, Shmulik -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
On Wed, 2012-07-04 at 11:05 +0300, Shmulik Ladkani wrote: > The existing mechanism of reserving PEBs for bad PEB handling has two > flaws: > - It is calculated as a percentage of good PEBs instead of total PEBs. > - There's no limit on the amount of PEBs UBI reserves for future bad > eraseblock handling. Thanks Shmulik - I did not have time to look at the patches, but the overall description looks good. I will review the patches as soon as I can. Thanks for making sense of this mess. But one more think is the mtd web-site. I've grepped for '1%' and there are plenty of them. I've changed them all to 2% more or less mechanically - only cleaned up one section by removing out-of-date information. Would you please grep for '2%' and review if the information there is reasonable? Also, would you please add some more info to this FAQ entry: http://linux-mtd.infradead.org/faq/ubi.html#L_bad_blocks_exceeded Or even better if you could write a separate section for this stuff in the documentation, then you could remove that FAQ entry completely. Thanks a lot! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
On Wed, 2012-07-04 at 11:05 +0300, Shmulik Ladkani wrote: The existing mechanism of reserving PEBs for bad PEB handling has two flaws: - It is calculated as a percentage of good PEBs instead of total PEBs. - There's no limit on the amount of PEBs UBI reserves for future bad eraseblock handling. Thanks Shmulik - I did not have time to look at the patches, but the overall description looks good. I will review the patches as soon as I can. Thanks for making sense of this mess. But one more think is the mtd web-site. I've grepped for '1%' and there are plenty of them. I've changed them all to 2% more or less mechanically - only cleaned up one section by removing out-of-date information. Would you please grep for '2%' and review if the information there is reasonable? Also, would you please add some more info to this FAQ entry: http://linux-mtd.infradead.org/faq/ubi.html#L_bad_blocks_exceeded Or even better if you could write a separate section for this stuff in the documentation, then you could remove that FAQ entry completely. Thanks a lot! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
2012/7/7 Shmulik Ladkani : > Many thanks for testing. > > Could you please verify the crash only occurs with the patch? > > Can you provide the vmlinux matching this oops, so I may analyze the > exact null dereferencing point? > It seems to be somewhere in ubi_wl_init, however the patch seems not to > affect these parts of ubi... Hi ! I can't reproduce it... Maybe the problem was between the chair and the keyboard. Anyway, if I ran into it again, I'll let you know. Richard. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
2012/7/7 Shmulik Ladkani shmulik.ladk...@gmail.com: Many thanks for testing. Could you please verify the crash only occurs with the patch? Can you provide the vmlinux matching this oops, so I may analyze the exact null dereferencing point? It seems to be somewhere in ubi_wl_init, however the patch seems not to affect these parts of ubi... Hi ! I can't reproduce it... Maybe the problem was between the chair and the keyboard. Anyway, if I ran into it again, I'll let you know. Richard. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
2012/7/7 Shmulik Ladkani : > Many thanks for testing. > > Could you please verify the crash only occurs with the patch? > > Can you provide the vmlinux matching this oops, so I may analyze the > exact null dereferencing point? > It seems to be somewhere in ubi_wl_init, however the patch seems not to > affect these parts of ubi... > > Also, what's your CONFIG_MTD_UBI_BEB_LIMIT? I'll do that on monday. Nice week-end ! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
Hi Richard, On Fri, 6 Jul 2012 17:27:59 +0200 Richard Genoud wrote: > I've got an oops... > this is my dev-kernel in 3.5-rc5 + some work to be able to boot on my board > NB: If I use ubi_format it's ok. > the mtd1 device has 1984 PEB > the 4 last are UBI reserved + BBT > > I didn't test without your patch, but anyway something is wrong there. Many thanks for testing. Could you please verify the crash only occurs with the patch? Can you provide the vmlinux matching this oops, so I may analyze the exact null dereferencing point? It seems to be somewhere in ubi_wl_init, however the patch seems not to affect these parts of ubi... Also, what's your CONFIG_MTD_UBI_BEB_LIMIT? Regards, Shmulik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
Hi Richard, On Fri, 6 Jul 2012 17:27:59 +0200 Richard Genoud richard.gen...@gmail.com wrote: I've got an oops... this is my dev-kernel in 3.5-rc5 + some work to be able to boot on my board NB: If I use ubi_format it's ok. the mtd1 device has 1984 PEB the 4 last are UBI reserved + BBT I didn't test without your patch, but anyway something is wrong there. Many thanks for testing. Could you please verify the crash only occurs with the patch? Can you provide the vmlinux matching this oops, so I may analyze the exact null dereferencing point? It seems to be somewhere in ubi_wl_init, however the patch seems not to affect these parts of ubi... Also, what's your CONFIG_MTD_UBI_BEB_LIMIT? Regards, Shmulik -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
2012/7/7 Shmulik Ladkani shmulik.ladk...@gmail.com: Many thanks for testing. Could you please verify the crash only occurs with the patch? Can you provide the vmlinux matching this oops, so I may analyze the exact null dereferencing point? It seems to be somewhere in ubi_wl_init, however the patch seems not to affect these parts of ubi... Also, what's your CONFIG_MTD_UBI_BEB_LIMIT? I'll do that on monday. Nice week-end ! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
I've got an oops... this is my dev-kernel in 3.5-rc5 + some work to be able to boot on my board NB: If I use ubi_format it's ok. the mtd1 device has 1984 PEB the 4 last are UBI reserved + BBT I didn't test without your patch, but anyway something is wrong there. # flash_erase /dev/mtd1 0 1980 Erasing 128 Kibyte @ f76 -- 100 % complete # ubiattach /dev/ubi_ctrl -m1 [ 35.671875] UBI: attaching mtd1 to ubi0 [ 35.671875] UBI DBG (pid 419): ubi_attach_mtd_dev: sizeof(struct ubi_ainf_peb) 48 [ 35.679687] UBI DBG (pid 419): ubi_attach_mtd_dev: sizeof(struct ubi_wl_entry) 20 [ 35.687500] UBI DBG (pid 419): io_init: min_io_size 2048 [ 35.695312] UBI DBG (pid 419): io_init: max_write_size 2048 [ 35.703125] UBI DBG (pid 419): io_init: hdrs_min_io_size 2048 [ 35.703125] UBI DBG (pid 419): io_init: ec_hdr_alsize2048 [ 35.710937] UBI DBG (pid 419): io_init: vid_hdr_alsize 2048 [ 35.718750] UBI DBG (pid 419): io_init: vid_hdr_offset 2048 [ 35.718750] UBI DBG (pid 419): io_init: vid_hdr_aloffset 2048 [ 35.726562] UBI DBG (pid 419): io_init: vid_hdr_shift0 [ 35.734375] UBI DBG (pid 419): io_init: leb_start4096 [ 35.742187] UBI DBG (pid 419): io_init: max_erroneous198 [ 35.742187] UBI: physical eraseblock size: 131072 bytes (128 KiB) [ 35.75] UBI: logical eraseblock size:126976 bytes [ 35.757812] UBI: smallest flash I/O unit:2048 [ 35.757812] UBI: VID header offset: 2048 (aligned 2048) [ 35.765625] UBI: data offset:4096 [ 36.210937] UBI DBG (pid 419): scan_all: scanning is finished [ 36.218750] UBI: empty MTD device detected [ 36.226562] UBI: max. sequence number: 0 [ 36.226562] UBI: create volume table (copy #1) [ 36.242187] UBI: create volume table (copy #2) [ 36.257812] Unable to handle kernel NULL pointer dereference at virtual address [ 36.265625] pgd = c752 [ 36.265625] [] *pgd=27bb7831, *pte=, *ppte= [ 36.273437] Internal error: Oops: 17 [#1] ARM [ 36.273437] CPU: 0Not tainted (3.5.0-rc5+ #14) [ 36.273437] PC is at ubi_wl_init+0x138/0x36c [ 36.273437] LR is at schedule_erase+0x50/0x64 [ 36.273437] pc : []lr : []psr: 6013 [ 36.273437] sp : c7501ee8 ip : 8000 fp : [ 36.273437] r10: c753fef8 r9 : c0361364 r8 : ffe0 [ 36.273437] r7 : c7537020 r6 : c7537034 r5 : c7538280 r4 : c7bd3540 [ 36.273437] r3 : r2 : c7bd3938 r1 : c75382c0 r0 : [ 36.273437] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 36.273437] Control: 0005317f Table: 2752 DAC: 0015 [ 36.273437] Process ubiattach (pid: 419, stack limit = 0xc7500270) [ 36.273437] Stack: (0xc7501ee8 to 0xc7502000) [ 36.273437] 1ee0: c7537020 c7bd3540 c7537020 c7bd3540 [ 36.273437] 1f00: c757caa0 c0009388 c750 c019800c c7bd3540 [ 36.273437] 1f20: c018d79c c757caa0 becdaaf8 c757caa0 40186f40 0003 [ 36.273437] 1f40: c0009388 c018dccc 0001 [ 36.273437] 1f60: becdaaf8 0003 40186f40 c0076890 c7ba4dc0 0003 40186f40 c7ba4dc0 [ 36.273437] 1f80: becdaaf8 c0076900 0003 becdaaf8 becdaaf8 40186f40 0003 [ 36.273437] 1fa0: 0036 c00091e0 becdaaf8 40186f40 0003 40186f40 becdaaf8 [ 36.273437] 1fc0: becdaaf8 40186f40 0003 0036 0002 becdadb4 0001 [ 36.273437] 1fe0: b6f39ec4 becdaab0 98c8 b6f39f08 6010 0003 [ 36.273437] [] (ubi_wl_init+0x138/0x36c) from [] (ubi_attach+0x74/0xbc) [ 36.273437] [] (ubi_attach+0x74/0xbc) from [] (ubi_attach_mtd_dev+0x1dc/0x4bc) [ 36.273437] [] (ubi_attach_mtd_dev+0x1dc/0x4bc) from [] (ctrl_cdev_ioctl+0xd4/0x164) [ 36.273437] [] (ctrl_cdev_ioctl+0xd4/0x164) from [] (do_vfs_ioctl+0x270/0x2ac) [ 36.273437] [] (do_vfs_ioctl+0x270/0x2ac) from [] (sys_ioctl+0x34/0x54) [ 36.273437] [] (sys_ioctl+0x34/0x54) from [] (ret_fast_syscall+0x0/0x2c) [ 36.273437] Code: e1a01005 e593 ebfb44ff ea74 (e5983020) [ 36.281250] ---[ end trace f540180ccfcbf7f6 ]--- Segmentation fault 2012/7/4 Shmulik Ladkani : > On Wed, 04 Jul 2012 10:35:42 +0200 Richard Weinberger wrote: >> Has this patch set an impact on UBI fastmap? > > Not sure yet. Maybe. Need to medidate on this :-) > >> ...wondering why I'm CC'd. :-) > > Heads-up. > As this is a bit delicate, you may review if the parts modified relate > to your fastmap work. > > Regards, > Shmulik -- for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
I've got an oops... this is my dev-kernel in 3.5-rc5 + some work to be able to boot on my board NB: If I use ubi_format it's ok. the mtd1 device has 1984 PEB the 4 last are UBI reserved + BBT I didn't test without your patch, but anyway something is wrong there. # flash_erase /dev/mtd1 0 1980 Erasing 128 Kibyte @ f76 -- 100 % complete # ubiattach /dev/ubi_ctrl -m1 [ 35.671875] UBI: attaching mtd1 to ubi0 [ 35.671875] UBI DBG (pid 419): ubi_attach_mtd_dev: sizeof(struct ubi_ainf_peb) 48 [ 35.679687] UBI DBG (pid 419): ubi_attach_mtd_dev: sizeof(struct ubi_wl_entry) 20 [ 35.687500] UBI DBG (pid 419): io_init: min_io_size 2048 [ 35.695312] UBI DBG (pid 419): io_init: max_write_size 2048 [ 35.703125] UBI DBG (pid 419): io_init: hdrs_min_io_size 2048 [ 35.703125] UBI DBG (pid 419): io_init: ec_hdr_alsize2048 [ 35.710937] UBI DBG (pid 419): io_init: vid_hdr_alsize 2048 [ 35.718750] UBI DBG (pid 419): io_init: vid_hdr_offset 2048 [ 35.718750] UBI DBG (pid 419): io_init: vid_hdr_aloffset 2048 [ 35.726562] UBI DBG (pid 419): io_init: vid_hdr_shift0 [ 35.734375] UBI DBG (pid 419): io_init: leb_start4096 [ 35.742187] UBI DBG (pid 419): io_init: max_erroneous198 [ 35.742187] UBI: physical eraseblock size: 131072 bytes (128 KiB) [ 35.75] UBI: logical eraseblock size:126976 bytes [ 35.757812] UBI: smallest flash I/O unit:2048 [ 35.757812] UBI: VID header offset: 2048 (aligned 2048) [ 35.765625] UBI: data offset:4096 [ 36.210937] UBI DBG (pid 419): scan_all: scanning is finished [ 36.218750] UBI: empty MTD device detected [ 36.226562] UBI: max. sequence number: 0 [ 36.226562] UBI: create volume table (copy #1) [ 36.242187] UBI: create volume table (copy #2) [ 36.257812] Unable to handle kernel NULL pointer dereference at virtual address [ 36.265625] pgd = c752 [ 36.265625] [] *pgd=27bb7831, *pte=, *ppte= [ 36.273437] Internal error: Oops: 17 [#1] ARM [ 36.273437] CPU: 0Not tainted (3.5.0-rc5+ #14) [ 36.273437] PC is at ubi_wl_init+0x138/0x36c [ 36.273437] LR is at schedule_erase+0x50/0x64 [ 36.273437] pc : [c0195a7c]lr : [c0194388]psr: 6013 [ 36.273437] sp : c7501ee8 ip : 8000 fp : [ 36.273437] r10: c753fef8 r9 : c0361364 r8 : ffe0 [ 36.273437] r7 : c7537020 r6 : c7537034 r5 : c7538280 r4 : c7bd3540 [ 36.273437] r3 : r2 : c7bd3938 r1 : c75382c0 r0 : [ 36.273437] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 36.273437] Control: 0005317f Table: 2752 DAC: 0015 [ 36.273437] Process ubiattach (pid: 419, stack limit = 0xc7500270) [ 36.273437] Stack: (0xc7501ee8 to 0xc7502000) [ 36.273437] 1ee0: c7537020 c7bd3540 c7537020 c7bd3540 [ 36.273437] 1f00: c757caa0 c0009388 c750 c019800c c7bd3540 [ 36.273437] 1f20: c018d79c c757caa0 becdaaf8 c757caa0 40186f40 0003 [ 36.273437] 1f40: c0009388 c018dccc 0001 [ 36.273437] 1f60: becdaaf8 0003 40186f40 c0076890 c7ba4dc0 0003 40186f40 c7ba4dc0 [ 36.273437] 1f80: becdaaf8 c0076900 0003 becdaaf8 becdaaf8 40186f40 0003 [ 36.273437] 1fa0: 0036 c00091e0 becdaaf8 40186f40 0003 40186f40 becdaaf8 [ 36.273437] 1fc0: becdaaf8 40186f40 0003 0036 0002 becdadb4 0001 [ 36.273437] 1fe0: b6f39ec4 becdaab0 98c8 b6f39f08 6010 0003 [ 36.273437] [c0195a7c] (ubi_wl_init+0x138/0x36c) from [c019800c] (ubi_attach+0x74/0xbc) [ 36.273437] [c019800c] (ubi_attach+0x74/0xbc) from [c018d79c] (ubi_attach_mtd_dev+0x1dc/0x4bc) [ 36.273437] [c018d79c] (ubi_attach_mtd_dev+0x1dc/0x4bc) from [c018dccc] (ctrl_cdev_ioctl+0xd4/0x164) [ 36.273437] [c018dccc] (ctrl_cdev_ioctl+0xd4/0x164) from [c0076890] (do_vfs_ioctl+0x270/0x2ac) [ 36.273437] [c0076890] (do_vfs_ioctl+0x270/0x2ac) from [c0076900] (sys_ioctl+0x34/0x54) [ 36.273437] [c0076900] (sys_ioctl+0x34/0x54) from [c00091e0] (ret_fast_syscall+0x0/0x2c) [ 36.273437] Code: e1a01005 e593 ebfb44ff ea74 (e5983020) [ 36.281250] ---[ end trace f540180ccfcbf7f6 ]--- Segmentation fault 2012/7/4 Shmulik Ladkani shmulik.ladk...@gmail.com: On Wed, 04 Jul 2012 10:35:42 +0200 Richard Weinberger rich...@nod.at wrote: Has this patch set an impact on UBI fastmap? Not sure yet. Maybe. Need to medidate on this :-) ...wondering why I'm CC'd. :-) Heads-up. As this is a bit delicate, you may review if the parts modified relate to your fastmap work. Regards, Shmulik -- for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at
