linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Roese <stefan.roese@gmail.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: Huang Shijie <b32955@freescale.com>,
	Kevin Cernekee <cernekee@gmail.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Artem Bityutskiy <dedekind1@gmail.com>
Subject: Re: cfi_cmdset_0002: do_write_buffer timeouts
Date: Fri, 12 Apr 2013 08:34:11 +0200	[thread overview]
Message-ID: <5167AAE3.3070202@gmail.com> (raw)
In-Reply-To: <CAN8TOE8BRhgi_ep8xypA_OwF4qfJikztmUcc-+XDB7hjnopuUA@mail.gmail.com>

On 11.04.2013 11:00, Brian Norris wrote:
> [Sorry for the repeat email for some; Gmail switched me back to
> HTML-mode, so my previous email couldn't be delivered to the MTD list]
> 
> Hi all,
> 
> I'm having some trouble where I am getting timeouts in cfi_cmdset_0002.c:
> 
> MTD do_write_buffer(): software timeout
> 
> I'm using a 64Mbyte Spansion S29GL512 NOR flash:
> 
> physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank.
> Manufacturer ID 0x000001 Chip ID 0x002301
> 
> I can reproduce the timeout approximately 0.5% of the time on a simple
> reboot, mount UBI rootfs test. My system has CONFIG_HZ=250, and so the
> timeout comes out to just 1 jiffy. I have to increase this timeout to
> at least 3 ticks to avoid the timeouts. (I've been running reboot
> tests successfully for several days with the timeout as 3 jiffies.)
> 
> So my question is: what is the "best" way to decide these timeouts?
> I'm inclined to just increase the timeout (and to use the proper
> msecs_to_jiffies() macro, as a cleanup). But according to the
> datasheets (which agree with the comments in the code), the max time
> should be less than a millisecond. So simply increasing the timeout
> may in fact just be masking some other bug.
> 
> Huang,
> 
> I noticed you recently sent a patch that adjusts the timeout print
> message in do_write_buffer(). Have you had problems with this code
> recently?
> 
> Any thoughts from any interested (or uninterested) party would be useful.

Without looking into the cmdset_0002 code, I remember fixing a
similar issue for cmdset_0001 a few months ago:

git id: 7be1f6b9a1ae3476a424380b52aad7c14c3273ab
Author: Stefan Roese <sr@denx.de>  2012-08-28 11:34:13
Committer: David Woodhouse <David.Woodhouse@intel.com>  2012-09-29 16:29:08
Follows: v3.6-rc2
Precedes: v3.7-rc1

    mtd: cfi_cmdset_0001: Fix problem with unlocking timeout
    
    Unlocking may take up to 1.4 seconds on some Intel flashes. So
    lets use a max. of 1.5 seconds (1500ms) as timeout.
    
    See "Clear Block Lock-Bits Time" on page 40 in
    "3 Volt Intel StrataFlash Memory" 28F128J3,28F640J3,28F320J3 manual
    from February 2003
    
    This patch also fixes some other problems with this timeout:
    
    - Don't use HZ in timeout "calculation"!
      While testing we noticed that an unlocking timeout occured with
      HZ=1000 and didn't occur with HZ=300. This was because the
      timeout parameter was calculated differently depending on the
      HZ value. Now a fixed value of 1500ms is used.
    
    - The last parameter of WAIT_TIMEOUT (defined to
      inval_cache_and_wait_for_operation) has to be passed in
      micro-seconds. So multiply the ms value with 1000 and not 100
      to calculate this value.
    
    - Use variable name "mdelay" instead of misleading "udelay".
    

One main issue here was that the resulting timeout was HZ related
resulting in different behavior depending on the HZ configuration.

This current issue here might be related, not sure though.

Thanks,
Stefan

      parent reply	other threads:[~2013-04-12  6:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAN8TOE8dVYxBbb8MtozFio8dS-ypq14U8RuKTo38QcAtXM5Qrw@mail.gmail.com>
2013-04-11  9:00 ` cfi_cmdset_0002: do_write_buffer timeouts Brian Norris
2013-04-11  9:21   ` Huang Shijie
2013-04-11 19:37     ` Brian Norris
2013-04-12  6:23   ` Norbert van Bolhuis
2013-04-13  2:59     ` Brian Norris
2013-04-15  7:55       ` Huang Shijie
2013-04-17 21:45         ` Brian Norris
2013-04-18  2:09           ` Huang Shijie
2013-04-12  6:34   ` Stefan Roese [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5167AAE3.3070202@gmail.com \
    --to=stefan.roese@gmail.com \
    --cc=b32955@freescale.com \
    --cc=cernekee@gmail.com \
    --cc=computersforpeace@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).