headers
Huang Shijie | 1 Aug 2012 04:21
Favicon

Re: [PATCH RESEND] mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver

于 2012年08月01日 00:11, Scott Wood 写道:
> Why is it better to lie about ECC geometry than to just say "subpage
> writes aren't supported"?  Does/will the ECC geometry get used by upper
yes. I think it's better to provide an official method to let the driver 
say: " i do not support the subpage writes."

Huang Shijie

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 0 comments |
headers
Iwo Mergler | 1 Aug 2012 07:20
Favicon

RE: question about write/read sub-page with BCH algorithm or disable sub-page operation when using ubifs

On Tue, 31 Jul 2012 17:23:25 +1000
曹荣荣 <caorr1980 <at> gmail.com> wrote:

> Hello,
> I have a question about sub-page when using ubifs, so ask help from
> here.
> 
> Let me take a 2048-size page with 4 sub-page Nand as example.
> 
> The documentation said, "To write a sub-page, the driver may actually
> write whole NAND page, but put 0xFF bytes to the sub-pages which are
> not relevant to this operation."
> It's OK for some ECC algorithms such as Hamming algorithm, because the
> ECC codes generated by Hamming algorithm for the 0xFF data are still
> 0xFF'ed. However, if we use BCH algorithm, the generated ECC codes for
> 0xFF data will be not 0xFF'ed, and they will overwrite the previous
> OOB data, so error will be happened when reading next time.
> 
> I try to resolve this issue by disabling sub-page operation, so I add
> NAND_NO_SUBPAGE_WRITE into chip->options, but chip->options will be
> flushed in nand_get_flash_type() funtion (chip->options &=
> ~NAND_CHIPOPTIONS_MSK).
> 
> So, my question is, How can I do to write/read sub-page with BCH
> algorithm, or to disable sub-page operation?
> 

Without sub-page support, UBI overhead doubles from about 1.5% to
over 3%, so sub-page support is worth considering.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russell Zuck | 1 Aug 2012 14:40

Re: UBIFS corruption after software upgrade

On 7/24/2012 5:02 PM, Russell Zuck wrote:
> I have not yet attempted to reproduce this issue using nandsim nor do I
> have a simple reproducer for the problem yet.  Please provide some ideas
> about how to simulate the reboot using nandsim as I think the reboot
> portion of this scenario will be critical to reproducing the issue.

Can anyone direct me to some information that might help me simulate a 
reboot using nandsim to attempt to reproduce my UBIFS corruption issue?

Additionally, I would really appreciate any suggestions, tips, tricks, 
criticisms of the upgrade process I outlined previously, or "Have you 
considered this" type questions.  I've read everything I could find that 
even remotely pertains to my scenario but nothing is clicking for me 
yet.  I'm desperately trying to resolve my issue.  Any guidance would be 
welcome.

Best regards,

Russ

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 6 comments |
headers
Matthieu CASTET | 1 Aug 2012 15:05
Favicon

Re: [PATCH RESEND] mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver

Hi Scott,

Scott Wood a écrit :
> On 07/31/2012 02:33 AM, Matthieu CASTET wrote:
>> Hi,
>>
>> for ONFI flash (like this micron one) the information should be extracted form
>> the ONFI table (programs_per_page IIRC)
>>
>> This should be better than relying on the SOC driver for setting this flags.
> 
> This is for cases where the constraint is the controller, not the chip.
> 
>> Does the gpmi driver set this flag because it do not support partial write ?
>> In this case why it doesn't set  chip->ecc.steps to 1 ?
> 
> Why is it better to lie about ECC geometry than to just say "subpage
> writes aren't supported"?  Does/will the ECC geometry get used by upper
> layers in evaluating the number of corrected bitflips?
If it is not because of ecc geometry, why the controller doesn't support subpage
writes ?

Matthieu

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 2 comments |
headers
Scott Wood | 1 Aug 2012 18:15
Favicon

Re: [PATCH RESEND] mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver

On 08/01/2012 08:05 AM, Matthieu CASTET wrote:
> Hi Scott,
> 
> Scott Wood a écrit :
>> On 07/31/2012 02:33 AM, Matthieu CASTET wrote:
>>> Hi,
>>>
>>> for ONFI flash (like this micron one) the information should be extracted form
>>> the ONFI table (programs_per_page IIRC)
>>>
>>> This should be better than relying on the SOC driver for setting this flags.
>>
>> This is for cases where the constraint is the controller, not the chip.
>>
>>> Does the gpmi driver set this flag because it do not support partial write ?
>>> In this case why it doesn't set  chip->ecc.steps to 1 ?
>>
>> Why is it better to lie about ECC geometry than to just say "subpage
>> writes aren't supported"?  Does/will the ECC geometry get used by upper
>> layers in evaluating the number of corrected bitflips?
> If it is not because of ecc geometry, why the controller doesn't support subpage
> writes ?

I can't answer for GPMI, but in the case of Freescale eLBC/IFC, the
controller only does ECC when you do a full page transaction -- but the
ECC is still done in steps, which is relevant for bitflip thresholds.

-Scott

______________________________________________________
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian Norris | 2 Aug 2012 03:08
Picon

Re: [PATCH RESEND] mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver

On Wed, Aug 1, 2012 at 9:15 AM, Scott Wood <scottwood <at> freescale.com> wrote:
> On 08/01/2012 08:05 AM, Matthieu CASTET wrote:
>> Scott Wood a écrit :
>>> On 07/31/2012 02:33 AM, Matthieu CASTET wrote:
>>>> Hi,
>>>>
>>>> for ONFI flash (like this micron one) the information should be extracted form
>>>> the ONFI table (programs_per_page IIRC)
>>>>
>>>> This should be better than relying on the SOC driver for setting this flags.
>>>
>>> This is for cases where the constraint is the controller, not the chip.
>>>
>>>> Does the gpmi driver set this flag because it do not support partial write ?
>>>> In this case why it doesn't set  chip->ecc.steps to 1 ?
>>>
>>> Why is it better to lie about ECC geometry than to just say "subpage
>>> writes aren't supported"?  Does/will the ECC geometry get used by upper
>>> layers in evaluating the number of corrected bitflips?
>> If it is not because of ecc geometry, why the controller doesn't support subpage
>> writes ?
>
> I can't answer for GPMI, but in the case of Freescale eLBC/IFC, the
> controller only does ECC when you do a full page transaction -- but the
> ECC is still done in steps, which is relevant for bitflip thresholds.

My controller (out-of-tree driver) *can* support subpage writes, but
disabling them gives performance benefits and allows stronger ECC
modes. My driver already performs a kind of hack by enabling
NAND_NO_SUBPAGE_WRITE in between nand_scan_ident() and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott Wood | 2 Aug 2012 03:47
Favicon

jffs2 unmount with delayed work queued

With slub debugging on, I was seeing a crash in timer code after
unmounting a jffs2 filesystem, with a reference to poisoned memory.  I
traced this back to jffs2_kill_sb() freeing the superblock with
c->wbuf_dwork.timer still active, and c->wbuf_queued = 1.  I've seen
this in Linus's current tree as well as 3.5.

I would have just sent a patch, but I wasn't sure exactly how to
gracefully shut things down -- cancel or flush, and at what point?
Don't want to do it too late for the work to happen safely, but don't
want to do it too early so that it could get queued again.

-Scott

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 1 comment |
headers
Subodh Nijsure | 2 Aug 2012 04:10

Re: UBIFS corruption after software upgrade

On 08/01/2012 05:40 AM, Russell Zuck wrote:
> On 7/24/2012 5:02 PM, Russell Zuck wrote:
>> I have not yet attempted to reproduce this issue using nandsim nor do I
>> have a simple reproducer for the problem yet.  Please provide some ideas
>> about how to simulate the reboot using nandsim as I think the reboot
>> portion of this scenario will be critical to reproducing the issue.
>
> Can anyone direct me to some information that might help me simulate a 
> reboot using nandsim to attempt to reproduce my UBIFS corruption issue?
>
> Additionally, I would really appreciate any suggestions, tips, tricks, 
> criticisms of the upgrade process I outlined previously, or "Have you 
> considered this" type questions.  I've read everything I could find 
> that even remotely pertains to my scenario but nothing is clicking for 
> me yet.  I'm desperately trying to resolve my issue.  Any guidance 
> would be welcome.

Some of the things I have done/considered to minimize issues  with UBIFS 
getting corrupted.

. Partition your UBIFS such that your run-time software ('os') is on one 
UBIFS and that is always mounted read-only.
. Create independent UBIFS (data) partition where your applications 
read/write data. If you can't mount this data partition at startup, have 
tools around in first partition that can recreate this 'data' partition 
and may be recreate contents of 'data' partition with default values. 
Might consider mounting this data partition with -o sync option.
. Use stuff like inotify to verify that your applications are not using 
flash as scratch storage to store intermediate data, that could be more 
easily assembled in tmpfs and then copied to flash.
(Continue reading)

Permalink | Reply | 0 comments |
headers
hejianet | 2 Aug 2012 05:04
Picon

jffs2 copy too long after mounting

hi All
my kernel is 2.6.16
after mounting the nand flash with jffs2 partition, the first copy operation
for a 15M file(from jffs2 partition to jffs2 partition) take 9
minutes,but the
second copy operation takes 1 minutes.
the disk usage(df result) is over 85%.
I wonder is there any patch ported to such old kernel?
Thanks

B.R.
Jia

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 8 comments |
headers
hejianet | 2 Aug 2012 05:16
Picon

Re: jffs2 copy too long after mounting

On 2012-08-02 11:04, hejianet wrote:
> hi All
> my kernel is 2.6.16
> after mounting the nand flash with jffs2 partition, the first copy operation
> for a 15M file(from jffs2 partition to jffs2 partition) take 9
> minutes,but the
> second copy operation takes 1 minutes.
> the disk usage(df result) is over 85%.
> I wonder is there any patch ported to such old kernel?
> Thanks
>
> B.R.
> Jia
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
besides, how to search all the archives of linux-mtd?
http://lists.infradead.org/pipermail/linux-mtd/ is a link, but it
couldn't be searched totally by date. I have review all pages
month by month :(

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 1 comment |

Gmane