public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: "武井 克明" <takei744@oki.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: Questions about ubifs,ubi and mtd?
Date: Wed, 12 Dec 2018 10:20:23 +0100	[thread overview]
Message-ID: <3417318.kOS8JojacP@blindfold> (raw)
In-Reply-To: <TY2PR01MB270060F7EC282F9C7C705D409DA70@TY2PR01MB2700.jpnprd01.prod.outlook.com>

Hello Katsuaki Takei,

Am Mittwoch, 12. Dezember 2018, 02:07:33 CET schrieb 武井 克明:
> Dear Richard,
>  Thank you for your comment.
>  We are using kernel 3.2.26 for reasons.
>  I can not update the kernel right now.

3.2.x is dead.
It contains bugs, security problems, is unmaintained, etc...
Shipping with 3.2.x is a very bad idea.
 
> To everyone
> Is there a lot of fixes and patches for processing that causes abnormal behavior as I asked you?
> We hope to solve the problem by patch to kernel 3.2.26. if possible.
> Shyly, I have little experience of developing ubifs or ubi, and I can not yet figure out which program is likely to be involved in this abnormal operation(ref. Note*).
> 
> Note*:
> Nevertheless, when loading our program from 'rootfs-a', trying to read the inode with the ubifs_read_node() function will result in "bad node type" (ex: 193 but expected 9) and the LEB can not be read with the expected value. (Even though you do not have write access to rootfs) In addition, the file size may be 0 byte in some cases.

The problem could be anything.
Both UBI and UBIFS faced tons of fixes over the last years.
Maybe it is also bug somewhere else.

You could try backporting the whole UBI and UBIFS subsystems to your kernel.

Thanks,
//richard

  reply	other threads:[~2018-12-12  9:20 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 [this message]
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
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=3417318.kOS8JojacP@blindfold \
    --to=richard@nod.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