On Wed, 22 Apr 2020 at 20:17, alpha_one_x86 <alpha_one_x86@xxxxxxxxxxxxxxxx> wrote: > > I had tested Linux 5.6.6 no change. > > Other idea? Yes, try a couple releases between 5.6 and 4.20. For example, 5.5. Kind regards Uffe > > On 2020-04-22 07:36, Russell King - ARM Linux admin wrote: > > 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@xxxxxxxxxxxxxxxx> > 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@xxxxxxxxxxxxxxxx> > 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@xxxxxxxxxxxxxxxx> > Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server management > IT, OS, technologies, research & development, security and business department
