public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Steve deRosier <derosier@gmail.com>
Cc: takei744@oki.com, linux-mtd@lists.infradead.org,
	"goliath@sigma-star.at" <goliath@sigma-star.at>
Subject: Re: Questions about ubifs,ubi and mtd?
Date: Thu, 13 Dec 2018 22:16:11 +0100	[thread overview]
Message-ID: <4423535.My00vEhdVK@blindfold> (raw)
In-Reply-To: <CALLGbRLERrPHXbs9QJ4sVnqjC_0to7r0w+NkYqzAU8A7YPd1Ew@mail.gmail.com>

Steve,

Am Donnerstag, 13. Dezember 2018, 18:18:49 CET schrieb Steve deRosier:
> On Thu, Dec 13, 2018 at 3:36 AM Richard Weinberger <richard@nod.at> wrote:
> >
> > Hello Katsuaki Takei,
> >
> > Am Donnerstag, 13. Dezember 2018, 11:45:36 CET schrieb 武井 克明:
> > > Dear Richard,
> > >
> > > We appreciate your precious advice.
> > > We understood the quality status of kernel 3.2.26.
> > > From now on, we would like to backport from the latest UBI and UBIFS.
> > > Do you think that it is enough to backport the next part?
> > >  - drivers/mtd
> > >  - drivers/mtd/ubi
> > >  - fs/ubifs
> >
> > Under the assumption that the root of the problem is the MTD/UBI stack,
> > your problem should go away.
> >
> 
> Katsuaki Takei,
> 
> Note that the MTD/UBI stack being at fault is an assumption. There's
> other things that might be at fault, and in my experience, you usually
> have multiple problems that all need to be solved.  Here's some other
> possible issues (might not be everything):
> 
> 1. Does your hardware work? Are you meeting all the setup and hold
> times on all signals at all times.
> 2. Does the driver work? Could be a bug, especially a subtle one where
> it usually works fine, but a missed command makes it unstable.
> 3. Does the rest of the MTD/UBI stack work?
> 4. Is your ECC on the NAND setup right and working?
> 5. Does whatever hardware or software you're using calculate the ECC
> bits correctly? For example, on some Atmel processors, there's a bug
> in the in-ROM PMECC algos so updated software does it in software
> instead of using the ROM code, but older bootstraps used the ROM algo
> and thus were bugged.
> 6. Are you flashing your NAND base image correctly (including getting
> all the ECC bits in the right place and correct)?
> 7. When you flash updated images, is that done correctly?
> 8. During your writing of the filesystem that goes bad, do you write
> it correctly and sync after each write? Note that 0-size files when
> you know you wrote something is a key indicator of this problem.
> 9. When erasing the NAND, you do retain and honor the bad-block markers, yes?
> 
> Only if the problem's root is in cases 2 and 3 will backporting
> patches even help. And for the driver case, only if the relevant fix
> is there.
 
Thanks a lot for your great summary!
IMHO it makes sense to put this in form of a checklist to the MTD website.
What do you think?

Thanks,
//richard

  reply	other threads:[~2018-12-13 21:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-11 14:08 Questions about ubifs,ubi and mtd? 武井 克明
2018-12-11 17:10 ` Richard Weinberger
2018-12-12  1:07   ` 武井 克明
2018-12-12  9:20     ` Richard Weinberger
2018-12-13 10:45       ` 武井 克明
2018-12-13 11:32         ` Martin Lund
2018-12-13 11:38           ` Richard Weinberger
2018-12-13 12:04             ` 武井 克明
2018-12-13 11:35         ` Richard Weinberger
2018-12-13 17:18           ` Steve deRosier
2018-12-13 21:16             ` Richard Weinberger [this message]
2018-12-13 22:22               ` Steve deRosier
2018-12-15 11:24                 ` Miquel Raynal
2018-12-14  6:18               ` Katsuaki Takei/OKI/JP
2018-12-14  6:11             ` Katsuaki Takei/OKI/JP

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=4423535.My00vEhdVK@blindfold \
    --to=richard@nod.at \
    --cc=derosier@gmail.com \
    --cc=goliath@sigma-star.at \
    --cc=linux-mtd@lists.infradead.org \
    --cc=takei744@oki.com \
    /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