From: Steve deRosier <derosier@gmail.com>
To: JH <jupiter.hce@gmail.com>
Cc: Richard Weinberger <richard.weinberger@gmail.com>,
linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: How the bad blocks occured in despite MTD manages the bad blocks
Date: Thu, 3 Oct 2019 16:44:44 -0700 [thread overview]
Message-ID: <CALLGbRJKJYcwHKGML00GB9mWG7U_EjAnEUSL+HxmHmWXjZY1vw@mail.gmail.com> (raw)
In-Reply-To: <CAA=hcWSYNtCyN460gw1LNJe3M2TCiXKUzv84_kCG3PO78BweDw@mail.gmail.com>
On Thu, Oct 3, 2019 at 2:26 PM JH <jupiter.hce@gmail.com> wrote:
>
> On 10/3/19, Richard Weinberger <richard.weinberger@gmail.com> wrote:
> > On Thu, Oct 3, 2019 at 1:14 PM JH <jupiter.hce@gmail.com> wrote:
> >> I was told by hardware engineer, it was broken by bad block problem.
> >
> > Did he inspect the filesystem in detail?
> > If he said so based on the same information you shared with us, it was
> > pure guesswork.
>
> Yep, he did.
>
> >> After those lines, the boot stopped in an emergent mode in a prompt to
> >> suggest to log in by Ctl-D, but that could not work, I was not able to
> >> log into the file system, nor can I get kernel log. From your
> >> experience, what could be likely the causes, hardware or software?
> >
> > Without logs I cannot say anything, sorry.
>
> That's ok, as long as I learned it is not caused by bad blocks, I
> doubt the software caused meltdown, even the full of file system would
> not cause the damage if NAND. So, my finger would point to hardware
> problems.
>
Don't be so fast - you don't have enough information to determine what
the problem is. That it is or is not a hardware or a software problem.
You need real kernel logs from the system to even begin to have a
clue. In my experience there's often many things wrong and you're
only going to figure out what the root cause is by understanding the
system. "it's not a software problem" and throwing it back over the
wall to the hardware team is just going to result in them turning
around and doing the same to you.
Honestly - it likely is a software problem. Configuration or bug or
process issue. But fundamentally you don't know because you don't have
meaningful error messages.
Your error messages should show on the bootup terminal output. If
you're suppressing the kernel log messages, change it so you can read
them, boot to failure and scroll back and see what's there.
- Steve
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2019-10-03 23:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-02 10:35 How the bad blocks occured in despite MTD manages the bad blocks JH
2019-10-02 16:09 ` Steve deRosier
2019-10-02 16:13 ` Richard Weinberger
2019-10-03 11:14 ` JH
2019-10-03 13:28 ` Richard Weinberger
2019-10-03 21:26 ` JH
2019-10-03 23:44 ` Steve deRosier [this message]
2019-10-04 6:36 ` JH
2019-10-05 8:38 ` Richard Weinberger
2019-10-05 21:56 ` JH
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=CALLGbRJKJYcwHKGML00GB9mWG7U_EjAnEUSL+HxmHmWXjZY1vw@mail.gmail.com \
--to=derosier@gmail.com \
--cc=jupiter.hce@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=richard.weinberger@gmail.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;
as well as URLs for NNTP newsgroup(s).