2 bug repport

2 bug repport

[alpha_one_x86]

Hi,

I post here patch for odroid C2, the kernel 5.6.6 is broken here on 
odroid C2.

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?

Cheers,

-- 
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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: 2 bug repport

[alpha_one_x86]

[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

Attached file

On 2020-04-22 03:03, alpha_one_x86 wrote:
> Hi,
>
> I post here patch for odroid C2, the kernel 5.6.6 is broken here on 
> odroid C2.
>
> 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?
>
> Cheers,
>
-- 
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


[-- Attachment #2: patch-5.6.diff --]
[-- Type: text/x-patch, Size: 560 bytes --]

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index b46ef985bb44..c6cf82c607f4 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -199,8 +199,8 @@ eth_phy0: ethernet-phy@0 {
 			/* Realtek RTL8211F (0x001cc916) */
 			reg = <0>;
 
-			reset-assert-us = <10000>;
-			reset-deassert-us = <30000>;
+			reset-assert-us = <20000>;
+			reset-deassert-us = <100000>;
 			reset-gpios = <&gpio GPIOZ_14 GPIO_ACTIVE_LOW>;

[-- Attachment #3: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: 2 bug repport

[Russell King - ARM Linux admin]

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.

-- 
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

Re: 2 bug repport

[Russell King - ARM Linux admin]

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.

-- 
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

Re: 2 bug repport

[Ulf Hansson]

On Wed, 22 Apr 2020 at 10:29, Russell King - ARM Linux admin
<linux@armlinux.org.uk> 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.

In v5.6 the following commits were introduced - and it has turned out
that a few other sdhci controllers had issues with them (which we have
fixed now).

Perhaps you can try a v5.6 kernel and just revert them and see if that
could help - as a start

533a6cfe08f9 ("mmc: core: Default to generic_cmd6_time as timeout in
__mmc_switch()")
ad91619aa9d7 ("mmc: block: Use generic_cmd6_time when modifying
INAND_CMD38_ARG_EXT_CSD")
24ed3bd01d6a ("mmc: core: Specify timeouts for BKOPS and CACHE_FLUSH for eMMC")

Kind regards
Uffe

Re: 2 bug repport

[Ulf Hansson]

On Wed, 22 Apr 2020 at 10:29, Russell King - ARM Linux admin
<linux@armlinux.org.uk> 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.

In v5.6 the following commits were introduced - and it has turned out
that a few other sdhci controllers had issues with them (which we have
fixed now).

Perhaps you can try a v5.6 kernel and just revert them and see if that
could help - as a start

533a6cfe08f9 ("mmc: core: Default to generic_cmd6_time as timeout in
__mmc_switch()")
ad91619aa9d7 ("mmc: block: Use generic_cmd6_time when modifying
INAND_CMD38_ARG_EXT_CSD")
24ed3bd01d6a ("mmc: core: Specify timeouts for BKOPS and CACHE_FLUSH for eMMC")

Kind regards
Uffe

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: 2 bug repport

[Russell King - ARM Linux admin]

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

Re: 2 bug repport

[Russell King - ARM Linux admin]

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

Re: 2 bug repport

[Ulf Hansson]

On Wed, 22 Apr 2020 at 20:17, alpha_one_x86
<alpha_one_x86@first-world.info> 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@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
>
> --
> 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

Re: 2 bug repport

[Ulf Hansson]

On Wed, 22 Apr 2020 at 20:17, alpha_one_x86
<alpha_one_x86@first-world.info> 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@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
>
> --
> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel