From: Russell King - ARM Linux admin <linux@armlinux•org.uk>
To: alpha_one_x86 <alpha_one_x86@first-world•info>,
huziji@marvell•com, linux-mmc@vger•kernel.org,
ulf.hansson@linaro•org, adrian.hunter@intel•com
Cc: linux-arm-kernel@lists•infradead.org
Subject: Re: 2 bug repport
Date: Wed, 22 Apr 2020 12:36:31 +0100 [thread overview]
Message-ID: <20200422113631.GN25745@shell.armlinux.org.uk> (raw)
In-Reply-To: <50004568-09e5-719b-ec4a-c09882767a6a@first-world.info>
Adding back those who *need* to be copied. Please be more careful
with your replies. As I said, those others are for your benefit,
not for mine, as they are more likely going to be able to help you.
Thanks for confirming that it is indeed a regression with 5.6
kernels.
Over to the Adrian/Ulf/others now...
On Wed, Apr 22, 2020 at 07:15:18AM -0400, alpha_one_x86 wrote:
> Hi,
>
> On multiple hardware I had tested 4.20, 5.6.6, again 4.20, 5.6.6, again
> 4.20.
>
> The problem is only with 5.6.6, never with 4.20
>
> On 2020-04-22 07:10, Russell King - ARM Linux admin wrote:
> > On Wed, Apr 22, 2020 at 07:00:11AM -0400, alpha_one_x86 wrote:
> > > Hi,
> > >
> > > It's regression because on the kernel 4.20 all is working.
> > PLEASE do not drop the Cc list. The Cc list is for YOUR benefit.
> >
> > You can't say that without going back and checking.
> >
> > SD cards are flash media, and they fail in weird and stupid ways.
> > Flash media itself only has a limited number of write cycles before
> > the memory irrevocerably fails. SD cards have firmware on them to
> > manage the flash media to perform wear leveling. Firmware can be
> > buggy and cause problems. I've had SD cards become completely
> > inaccessible because of a firmware failure.
> >
> > So, after finding a problem on a later kernel with SD cards, you
> > need to confirm the regression by checking whether the previously
> > working kernel continues to behave correctly (indicating a kernel
> > regression) or whether it behaves the same (indicating a failure of
> > the SD card.)
> >
> > If you're not willing to do that, I'm afraid we will have to discount
> > your bug report since it doesn't contain the information necessary to
> > make a proper evaluation of what may be going on.
> >
> > > Cheers,
> > >
> > > On 2020-04-22 04:28, Russell King - ARM Linux admin wrote:
> > > > On Wed, Apr 22, 2020 at 03:03:57AM -0400, alpha_one_x86 wrote:
> > > > > Hi,
> > > > >
> > > > > On mcbin platform I have uSD problem, repported but no reply on linux kernel
> > > > > bugzilla, https://bugzilla.kernel.org/show_bug.cgi?id=207083
> > > > >
> > > > > Any idea what patch try?
> > > > I think that's a question for the MMC people.
> > > >
> > > > If you go back to your working 4.20 kernel, does the problem go away?
> > > > If so, it sounds like a regression in the MMC subsystem. If not, I
> > > > wonder if it could be the uSD card going bad.
> > > >
> > > > However, I suspect the former. I've seen one instance here where a
> > > > Clearfog GT8k (Armada 8040 based just like the mcbin) running 5.6 with
> > > > the rootfs on eMMC completely lost the ability to talk to the eMMC to
> > > > the point that the machine had to be power cycled to recover it -
> > > > merely rebooting did not. I don't know the cause - the initial failure
> > > > had vanished from the kernel logs, and because the eMMC was no longer
> > > > accessible, the rsyslog files did not contain the details either.
> > > > I've since setup remote logging, and I'm currently waiting for it to
> > > > happen again. I couldn't say if _that_ is a regression because I
> > > > haven't been using the GT8k until very recently, and I tend not to use
> > > > eMMC/uSD on the Macchiatobin that runs 24x7.
> > > >
> > > --
> > > alpha_one_x86/BRULE Herman <alpha_one_x86@first-world•info>
> > > Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server management
> > > IT, OS, technologies, research & development, security and business department
> > >
> --
> alpha_one_x86/BRULE Herman <alpha_one_x86@first-world•info>
> Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server management
> IT, OS, technologies, research & development, security and business department
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists•infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-04-22 11:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-22 7:03 2 bug repport alpha_one_x86
2020-04-22 7:12 ` alpha_one_x86
2020-04-22 8:28 ` Russell King - ARM Linux admin
2020-04-22 10:32 ` Ulf Hansson
[not found] ` <5a67104f-1286-2cb0-d01e-8aa61c9f7e48@first-world.info>
[not found] ` <20200422111025.GM25745@shell.armlinux.org.uk>
[not found] ` <50004568-09e5-719b-ec4a-c09882767a6a@first-world.info>
2020-04-22 11:36 ` Russell King - ARM Linux admin [this message]
[not found] ` <268145c0-97de-cfd9-71bf-b698248d732a@first-world.info>
2020-04-24 7:26 ` Ulf Hansson
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=20200422113631.GN25745@shell.armlinux.org.uk \
--to=linux@armlinux$(echo .)org.uk \
--cc=adrian.hunter@intel$(echo .)com \
--cc=alpha_one_x86@first-world$(echo .)info \
--cc=huziji@marvell$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-mmc@vger$(echo .)kernel.org \
--cc=ulf.hansson@linaro$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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