Re: 2 bug repport

[Russell King - ARM Linux admin <linux@armlinux.org.uk>]

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