question: Why the nand_wait() wait for 20ms for nand program.

question: Why the nand_wait() wait for 20ms for nand program.

[Huang Shijie]

Hi all:
Why the nand_wait() wait for 20ms for nand program. could we
expand this time to 40ms? I have a nand chip : Micron MT29F64G08CBABAWP.
The chip's BUSY/READY pin may needs more then 20ms to become ready,
though its
datasheet tells me the tPROG's max value is 2.5ms.

thanks
Huang Shijie

Re: question: Why the nand_wait() wait for 20ms for nand program.

[Matthieu CASTET]

Huang Shijie a écrit :
> Hi all:
> Why the nand_wait() wait for 20ms for nand program. could we
> expand this time to 40ms? I have a nand chip : Micron MT29F64G08CBABAWP.
> The chip's BUSY/READY pin may needs more then 20ms to become ready,
> though its
> datasheet tells me the tPROG's max value is 2.5ms.
> 
Don't you have an hardware problem (missing pullup/down on ready busy pin) ?

If the datasheet say the max value is 2.5 ms , how it can be more than 20 ms.


Matthieu

Re: question: Why the nand_wait() wait for 20ms for nand program.

[Huang Shijie]

于 2013年01月18日 20:26, Matthieu CASTET 写道:
> Huang Shijie a écrit :
>> Hi all:
>> Why the nand_wait() wait for 20ms for nand program. could we
>> expand this time to 40ms? I have a nand chip : Micron MT29F64G08CBABAWP.
>> The chip's BUSY/READY pin may needs more then 20ms to become ready,
>> though its
>> datasheet tells me the tPROG's max value is 2.5ms.
>>
> Don't you have an hardware problem (missing pullup/down on ready busy pin) ?
>
> If the datasheet say the max value is 2.5 ms , how it can be more than 20 ms.

I finally found the root cause.

I added the do_gettimeofday() in the nand_wait() to measure the 
READY/BUSY time. The code is like this:
---------------------------------------------------- code start 
-----------------------------------------------------------------------

+static struct timeval start, finish;
+static int my_nand_wait(struct mtd_info *mtd, struct nand_chip *chip)
+{
+
+ unsigned long timeo = jiffies;
+ int status, state = chip->state;
+ int check = 0;
+
+ if (state == FL_ERASING)
+ timeo += (HZ * 400) / 1000;
+ else
+ timeo += (HZ * 20) / 1000;
+
+ led_trigger_event(nand_led_trigger, LED_FULL);
+
+ /*
+ * Apply this short delay always to ensure that we do wait tWB in any
+ * case on any machine.
+ */
+ ndelay(100);
+
+ if ((state == FL_ERASING) && (chip->options & NAND_IS_AND))
+ chip->cmdfunc(mtd, NAND_CMD_STATUS_MULTI, -1, -1);
+ else
+ chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1);
+
+ do_gettimeofday(&start);
+
+ if (in_interrupt() || oops_in_progress)
+ panic_nand_wait(mtd, chip, timeo);
+ else {
+ while (time_before(jiffies, timeo)) {
+ if (chip->dev_ready) {
+ if (chip->dev_ready(mtd)) {
+ do_gettimeofday(&finish);
+ check = 1;
+ break;
+ }
+ } else {
+ if (chip->read_byte(mtd) & NAND_STATUS_READY)
+ break;
+ }
+ cond_resched();
+ }
+ }
+ led_trigger_event(nand_led_trigger, LED_OFF);
+
+ status = (int)chip->read_byte(mtd);
+ if (check == 0) {
+ long ms, us;
+
+ /* get it here. */
+ do_gettimeofday(&finish);
+
+ us = (finish.tv_sec * USEC_PER_SEC + finish.tv_usec)
+ - (start.tv_sec * USEC_PER_SEC + start.tv_usec);
+ ms = us / USEC_PER_MSEC;
+
+ printk("[ %s : ], status : %x, <%lu, %lu>, < %lu, %lu>, <%lu, %lu>, Js 
<%lu, %lu>\n",
+ __func__, status, finish.tv_sec, start.tv_sec,
+ finish.tv_usec, start.tv_usec, ms, us);
+
+ }
+ start = finish = (struct timeval) {0, 0};
+ return status;
+}

/**
* __nand_unlock - [REPLACEABLE] unlocks specified locked blocks
* @mtd: mtd info
@@ -2180,7 +2247,8 @@ static int nand_write_page(struct mtd_info *mtd, 
struct nand_chip *chip,
if (!cached || !(chip->options & NAND_CACHEPRG)) {

chip->cmdfunc(mtd, NAND_CMD_PAGEPROG, -1, -1);
- status = chip->waitfunc(mtd, chip);
+ status = my_nand_wait(mtd, chip);
+
/*
* See if operation failed and additional status checks are
* available.
-- 
------------------------------------------------------------------------code 
end 
here.----------------------------------------------------------------------------


The code tells me that it will wait for 20ms, but in actually, the 
kernel may breaks the while loop in JUST 1ms.
My CONFIG_HZ is 100.

Any idea about this?

thanks.
Huang Shijie









>
> Matthieu
>

Re: question: Why the nand_wait() wait for 20ms for nand program.

[Matthieu CASTET]

Huang Shijie a écrit :
> 于 2013年01月18日 20:26, Matthieu CASTET 写道:
>> Huang Shijie a écrit :
>>> Hi all:
>>> Why the nand_wait() wait for 20ms for nand program. could we
>>> expand this time to 40ms? I have a nand chip : Micron MT29F64G08CBABAWP.
>>> The chip's BUSY/READY pin may needs more then 20ms to become ready,
>>> though its
>>> datasheet tells me the tPROG's max value is 2.5ms.
>>>
>> Don't you have an hardware problem (missing pullup/down on ready busy pin) ?
>>
>> If the datasheet say the max value is 2.5 ms , how it can be more than 20 ms.
> 
> I finally found the root cause.
> 
> I added the do_gettimeofday() in the nand_wait() to measure the 
> READY/BUSY time. The code is like this:
> ---------------------------------------------------- code start 
>
Could you dump jiffies and timeo in your code ?

Re: question: Why the nand_wait() wait for 20ms for nand program.

[Matthieu CASTET]

Huang Shijie a écrit :
>  于 2013年01月21日 16:57, Matthieu CASTET 写道:
>> Huang Shijie a écrit :
>>> 于 2013年01月18日 20:26, Matthieu CASTET 写道:
>>>> Huang Shijie a écrit :
>>>>> Hi all:
>>>>> Why the nand_wait() wait for 20ms for nand program. could we
>>>>> expand this time to 40ms? I have a nand chip : Micron MT29F64G08CBABAWP.
>>>>> The chip's BUSY/READY pin may needs more then 20ms to become ready,
>>>>> though its
>>>>> datasheet tells me the tPROG's max value is 2.5ms.
>>>>>
>>>> Don't you have an hardware problem (missing pullup/down on ready busy pin) ?
>>>>
>>>> If the datasheet say the max value is 2.5 ms , how it can be more than 20 ms.
>>> I finally found the root cause.
>>>
>>> I added the do_gettimeofday() in the nand_wait() to measure the 
>>> READY/BUSY time. The code is like this:
>>> ---------------------------------------------------- code start 
>>>
>> Could you dump jiffies and timeo in your code ?
> The following just shows some part of the log:
> 
> [my_nand_wait]status : 80, <21480, 21480>, < 665911, 664170>, <1, 1741>
> [my_nand_wait]status : 80, <21480, 21480>, < 735989, 734626>, <1, 1363>
> [my_nand_wait]status : 80, <21480, 21480>, < 805693, 804825>, <0, 868>
> 
> From the log, we can see that the kernel just waits for 1741us to break
> the while loop,
> not 20ms.
> 

Yes but you should display jiffies and timeo value to understand why the kernel
thinks 2 jiffies elapsed.


Matthieu

Re: question: Why the nand_wait() wait for 20ms for nand program.

[Huang Shijie]

于 2013年01月21日 17:15, Matthieu CASTET 写道:
> Huang Shijie a écrit :
>>   于 2013年01月21日 16:57, Matthieu CASTET 写道:
>>> Huang Shijie a écrit :
>>>> 于 2013年01月18日 20:26, Matthieu CASTET 写道:
>>>>> Huang Shijie a écrit :
>>>>>> Hi all:
>>>>>> Why the nand_wait() wait for 20ms for nand program. could we
>>>>>> expand this time to 40ms? I have a nand chip : Micron MT29F64G08CBABAWP.
>>>>>> The chip's BUSY/READY pin may needs more then 20ms to become ready,
>>>>>> though its
>>>>>> datasheet tells me the tPROG's max value is 2.5ms.
>>>>>>
>>>>> Don't you have an hardware problem (missing pullup/down on ready busy pin) ?
>>>>>
>>>>> If the datasheet say the max value is 2.5 ms , how it can be more than 20 ms.
>>>> I finally found the root cause.
>>>>
>>>> I added the do_gettimeofday() in the nand_wait() to measure the
>>>> READY/BUSY time. The code is like this:
>>>> ---------------------------------------------------- code start
>>>>
>>> Could you dump jiffies and timeo in your code ?
>> The following just shows some part of the log:
>>
>> [my_nand_wait]status : 80,<21480, 21480>,<  665911, 664170>,<1, 1741>
>> [my_nand_wait]status : 80,<21480, 21480>,<  735989, 734626>,<1, 1363>
>> [my_nand_wait]status : 80,<21480, 21480>,<  805693, 804825>,<0, 868>
>>
>>  From the log, we can see that the kernel just waits for 1741us to break
>> the while loop,
>> not 20ms.
>>
> Yes but you should display jiffies and timeo value to understand why the kernel
> thinks 2 jiffies elapsed.
I dumpped the jiffies and timeo too. The jiffies is really _equal_ to 
the timeo, and then the while loop breaks.

thanks for your comments.

I think there is something wrong with the timer.

Huang Shijie





>
> Matthieu
>

Re: question: Why the nand_wait() wait for 20ms for nand program.

[Matthieu CASTET]

Huang Shijie a écrit :
> 于 2013年01月21日 17:15, Matthieu CASTET 写道:
>> Huang Shijie a écrit :
>>>   于 2013年01月21日 16:57, Matthieu CASTET 写道:
>>>> Huang Shijie a écrit :
>>>>> 于 2013年01月18日 20:26, Matthieu CASTET 写道:
>>>>>> Huang Shijie a écrit :
>>>>>>> Hi all:
>>>>>>> Why the nand_wait() wait for 20ms for nand program. could we
>>>>>>> expand this time to 40ms? I have a nand chip : Micron MT29F64G08CBABAWP.
>>>>>>> The chip's BUSY/READY pin may needs more then 20ms to become ready,
>>>>>>> though its
>>>>>>> datasheet tells me the tPROG's max value is 2.5ms.
>>>>>>>
>>>>>> Don't you have an hardware problem (missing pullup/down on ready busy pin) ?
>>>>>>
>>>>>> If the datasheet say the max value is 2.5 ms , how it can be more than 20 ms.
>>>>> I finally found the root cause.
>>>>>
>>>>> I added the do_gettimeofday() in the nand_wait() to measure the
>>>>> READY/BUSY time. The code is like this:
>>>>> ---------------------------------------------------- code start
>>>>>
>>>> Could you dump jiffies and timeo in your code ?
>>> The following just shows some part of the log:
>>>
>>> [my_nand_wait]status : 80,<21480, 21480>,<  665911, 664170>,<1, 1741>
>>> [my_nand_wait]status : 80,<21480, 21480>,<  735989, 734626>,<1, 1363>
>>> [my_nand_wait]status : 80,<21480, 21480>,<  805693, 804825>,<0, 868>
>>>
>>>  From the log, we can see that the kernel just waits for 1741us to break
>>> the while loop,
>>> not 20ms.
>>>
>> Yes but you should display jiffies and timeo value to understand why the kernel
>> thinks 2 jiffies elapsed.
> I dumpped the jiffies and timeo too. The jiffies is really _equal_ to 
> the timeo, and then the while loop breaks.
> 
> thanks for your comments.
> 
> I think there is something wrong with the timer.
> 
timeo += (HZ * 20) / 1000;

So what is the value of HZ ?

In order (HZ * 20) / 1000 is 0 HZ should be < 50.


Matthieu

Re: question: Why the nand_wait() wait for 20ms for nand program.

[Huang Shijie]

于 2013年01月21日 17:32, Matthieu CASTET 写道:
> Huang Shijie a écrit :
>> 于 2013年01月21日 17:15, Matthieu CASTET 写道:
>>> Huang Shijie a écrit :
>>>>    于 2013年01月21日 16:57, Matthieu CASTET 写道:
>>>>> Huang Shijie a écrit :
>>>>>> 于 2013年01月18日 20:26, Matthieu CASTET 写道:
>>>>>>> Huang Shijie a écrit :
>>>>>>>> Hi all:
>>>>>>>> Why the nand_wait() wait for 20ms for nand program. could we
>>>>>>>> expand this time to 40ms? I have a nand chip : Micron MT29F64G08CBABAWP.
>>>>>>>> The chip's BUSY/READY pin may needs more then 20ms to become ready,
>>>>>>>> though its
>>>>>>>> datasheet tells me the tPROG's max value is 2.5ms.
>>>>>>>>
>>>>>>> Don't you have an hardware problem (missing pullup/down on ready busy pin) ?
>>>>>>>
>>>>>>> If the datasheet say the max value is 2.5 ms , how it can be more than 20 ms.
>>>>>> I finally found the root cause.
>>>>>>
>>>>>> I added the do_gettimeofday() in the nand_wait() to measure the
>>>>>> READY/BUSY time. The code is like this:
>>>>>> ---------------------------------------------------- code start
>>>>>>
>>>>> Could you dump jiffies and timeo in your code ?
>>>> The following just shows some part of the log:
>>>>
>>>> [my_nand_wait]status : 80,<21480, 21480>,<   665911, 664170>,<1, 1741>
>>>> [my_nand_wait]status : 80,<21480, 21480>,<   735989, 734626>,<1, 1363>
>>>> [my_nand_wait]status : 80,<21480, 21480>,<   805693, 804825>,<0, 868>
>>>>
>>>>    From the log, we can see that the kernel just waits for 1741us to break
>>>> the while loop,
>>>> not 20ms.
>>>>
>>> Yes but you should display jiffies and timeo value to understand why the kernel
>>> thinks 2 jiffies elapsed.
>> I dumpped the jiffies and timeo too. The jiffies is really _equal_ to
>> the timeo, and then the while loop breaks.
>>
>> thanks for your comments.
>>
>> I think there is something wrong with the timer.
>>
> timeo += (HZ * 20) / 1000;
>
> So what is the value of HZ ?
my CONFIG_HZ is 100.

thanks
Huang Shijie
> In order (HZ * 20) / 1000 is 0 HZ should be<  50.
>
>
> Matthieu
>

Re: question about mtd_torturetest.c

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

On Wed, 2013-01-23 at 15:25 +0800, Huang Shijie wrote:
> Hi all:
> 
>     The mtd_torturetest.c uses the 55/AA patterns to torture the nand block.
> Are the 55/AA patterns more tougher then the random data?

Probably not, please, improve the test.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: question about mtd_torturetest.c

[Gupta, Pekon]

> On Wed, 2013-01-23 at 15:25 +0800, Huang Shijie wrote:
> > Hi all:
> >
> >     The mtd_torturetest.c uses the 55/AA patterns to torture the nand
> block.
> > Are the 55/AA patterns more tougher then the random data?
> 
> Probably not, please, improve the test.
> 

(0x55/0xAA/0x55) pattern ensures that _all_ bits in the byte transition from 0-> 1, and 1->0,
Whereas, a random pattern may miss a bit-cell or miss transition sequence, of an bad bit-cell.
Exercising each bit both ways is important so as to differentiate a bad bit-cell (permanent error) from read-disturb errors (temporary error).

For read-disturb: http://download.micron.com/pdf/presentations/events/flash_mem_summit_jcooke_inconvenient_truths_nand.pdf


with regards, pekon

Re: question about mtd_torturetest.c

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

On Mon, 2013-02-04 at 05:19 +0000, Gupta, Pekon wrote:
> > On Wed, 2013-01-23 at 15:25 +0800, Huang Shijie wrote:
> > > Hi all:
> > >
> > >     The mtd_torturetest.c uses the 55/AA patterns to torture the nand
> > block.
> > > Are the 55/AA patterns more tougher then the random data?
> > 
> > Probably not, please, improve the test.
> > 
> 
> (0x55/0xAA/0x55) pattern ensures that _all_ bits in the byte transition from 0-> 1, and 1->0,
> Whereas, a random pattern may miss a bit-cell or miss transition sequence, of an bad bit-cell.
> Exercising each bit both ways is important so as to differentiate a bad bit-cell (permanent error) from read-disturb errors (temporary error).
> 
> For read-disturb: http://download.micron.com/pdf/presentations/events/flash_mem_summit_jcooke_inconvenient_truths_nand.pdf

Sure, I did not mean remove those, I meant that random data test can
also be added and that would be an improvement.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: question about mtd_torturetest.c

[Huang Shijie]

于 2013年02月04日 14:58, Artem Bityutskiy 写道:
> On Mon, 2013-02-04 at 05:19 +0000, Gupta, Pekon wrote:
>>> On Wed, 2013-01-23 at 15:25 +0800, Huang Shijie wrote:
>>>> Hi all:
>>>>
>>>>      The mtd_torturetest.c uses the 55/AA patterns to torture the nand
>>> block.
>>>> Are the 55/AA patterns more tougher then the random data?
>>> Probably not, please, improve the test.
>>>
>> (0x55/0xAA/0x55) pattern ensures that _all_ bits in the byte transition from 0->  1, and 1->0,
>> Whereas, a random pattern may miss a bit-cell or miss transition sequence, of an bad bit-cell.
>> Exercising each bit both ways is important so as to differentiate a bad bit-cell (permanent error) from read-disturb errors (temporary error).
>>
>> For read-disturb: http://download.micron.com/pdf/presentations/events/flash_mem_summit_jcooke_inconvenient_truths_nand.pdf
> Sure, I did not mean remove those, I meant that random data test can
> also be added and that would be an improvement.
>
I think the random data test is much like the simulation of the nand 
real use, such as the nand is used in
the filesystem.

thank
Huang Shijie

Re: question: Why the nand_wait() wait for 20ms for nand program.

[Huang Shijie]

于 2013年01月21日 17:32, Matthieu CASTET 写道:
> Huang Shijie a écrit :
>> 于 2013年01月21日 17:15, Matthieu CASTET 写道:
>>> Huang Shijie a écrit :
>>>>    于 2013年01月21日 16:57, Matthieu CASTET 写道:
>>>>> Huang Shijie a écrit :
>>>>>> 于 2013年01月18日 20:26, Matthieu CASTET 写道:
>>>>>>> Huang Shijie a écrit :
>>>>>>>> Hi all:
>>>>>>>> Why the nand_wait() wait for 20ms for nand program. could we
>>>>>>>> expand this time to 40ms? I have a nand chip : Micron MT29F64G08CBABAWP.
>>>>>>>> The chip's BUSY/READY pin may needs more then 20ms to become ready,
>>>>>>>> though its
>>>>>>>> datasheet tells me the tPROG's max value is 2.5ms.
>>>>>>>>
>>>>>>> Don't you have an hardware problem (missing pullup/down on ready busy pin) ?
>>>>>>>
>>>>>>> If the datasheet say the max value is 2.5 ms , how it can be more than 20 ms.
>>>>>> I finally found the root cause.
>>>>>>
>>>>>> I added the do_gettimeofday() in the nand_wait() to measure the
>>>>>> READY/BUSY time. The code is like this:
>>>>>> ---------------------------------------------------- code start
>>>>>>
>>>>> Could you dump jiffies and timeo in your code ?
>>>> The following just shows some part of the log:
>>>>
>>>> [my_nand_wait]status : 80,<21480, 21480>,<   665911, 664170>,<1, 1741>
>>>> [my_nand_wait]status : 80,<21480, 21480>,<   735989, 734626>,<1, 1363>
>>>> [my_nand_wait]status : 80,<21480, 21480>,<   805693, 804825>,<0, 868>
>>>>
>>>>    From the log, we can see that the kernel just waits for 1741us to break
>>>> the while loop,
>>>> not 20ms.
>>>>
>>> Yes but you should display jiffies and timeo value to understand why the kernel
>>> thinks 2 jiffies elapsed.
>> I dumpped the jiffies and timeo too. The jiffies is really _equal_ to
>> the timeo, and then the while loop breaks.
>>
>> thanks for your comments.
>>
>> I think there is something wrong with the timer.
>>
> timeo += (HZ * 20) / 1000;
>
> So what is the value of HZ ?
>
> In order (HZ * 20) / 1000 is 0 HZ should be<  50.

thanks for your help.

I really appreciate it.

this bug is caused by our unstable kernel.
I tried with some other stable code, the issue never occurs.


thanks
Huang shijie
>
> Matthieu
>