From: Richard Weinberger <richard@nod.at>
To: Brian Norris <computersforpeace@gmail.com>,
Scott Branden <sbranden@broadcom.com>
Cc: Ricard Wanderlof <ricard.wanderlof@axis.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: suspect UBIFS async operations causing issues during reboot
Date: Wed, 26 Nov 2014 09:30:17 +0100 [thread overview]
Message-ID: <54758F99.6010502@nod.at> (raw)
In-Reply-To: <20141126081732.GQ3212@norris-Latitude-E6410>
Am 26.11.2014 um 09:17 schrieb Brian Norris:
> On Sun, Nov 09, 2014 at 09:10:03PM -0800, Scott Branden wrote:
>> On 14-11-09 02:20 AM, Richard Weinberger wrote:
>>> Well, I agree with David that anything we do in software will only hide the real problem
>>> or trim down the window.
>> Hi Richard,
>>
>> Currently the NAND does not shut down in a clean manner for a reboot
>> operation. This is due to the asynchronous ubi_thread make flash
>> erase calls. unmount is done properly in ubi already and cleanly
>> shuts down. reboot is not done in a clean manner as there is no
>> reboot_notifier to handle the situation.
>>
>> This is not hiding a real problem. It is just shutting down ubi
>> properly rather than pulling the power from it in the middle of
>> operations.
>>
>> In addition to this - a reboot_notifier needs to be added at the mtd
>> level to shut it down properly as well.
>>
>> This is not trimming down a window. It is having the drivers shut
>> down properly so they do not look like a power failure to the NAND
>> device.
>>
>> There is no solution to the power failure - it will corrupt pages in
>> the middle of erasure. And you do handle this in UBI/UBIFS. But
>> why corrupt other erase pages unnecessarily when all that needs to
>> be done is shut down the drivers properly. I don't know what you
>> are agreeing with David with? It is not making a window smaller.
>> It is changing the functionality so that the UBI and MTD drivers are
>> shut down cleanly in reboot situations. Right now, they are not
>> shut down at all in these situations.
>
> I agree with Scott's statements. While it's fine to talk about how all
> layers (from bootloader to UBIFS) should be able to handle a power cut
> in the midst of an erase, that does *not* mean that we should
> intentionally deny the chance to shut down cleanly.
>
> AFAICT, Scott's not trying to work around any unsound reset behaviors
> (in UBIFS or in his bootloader); he's just trying to shut things down
> gracefully, just as we would try to terminate processes, sync file
> systems, etc., rather than just cutting power on reboot.
If there is a solution which makes Artem and David happy, I'm perfectly fine. :)
Thanks,
//richard
next prev parent reply other threads:[~2014-11-26 8:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-05 8:32 suspect UBIFS async operations causing issues during reboot Scott Branden
2014-11-05 9:22 ` Richard Weinberger
2014-11-05 17:56 ` Scott Branden
2014-11-05 18:21 ` Richard Weinberger
2014-11-05 22:52 ` Scott Branden
2014-11-06 21:56 ` Scott Branden
2014-11-07 8:45 ` Richard Weinberger
2014-11-07 17:31 ` Scott Branden
2014-11-09 10:20 ` Richard Weinberger
2014-11-10 5:10 ` Scott Branden
2014-11-26 8:17 ` Brian Norris
2014-11-26 8:30 ` Richard Weinberger [this message]
2014-11-26 9:25 ` Brian Norris
2014-11-27 19:07 ` Scott Branden
2014-11-10 8:44 ` Ricard Wanderlof
2014-11-10 9:08 ` Richard Weinberger
2014-11-10 7:44 ` Tanya Brokhman
2014-11-12 11:20 ` Artem Bityutskiy
2014-11-15 3:30 ` Scott Branden
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=54758F99.6010502@nod.at \
--to=richard@nod.at \
--cc=computersforpeace@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=ricard.wanderlof@axis.com \
--cc=sbranden@broadcom.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.