I updated to 4.11.0-trunk-armmp from experimental, and I am also using u-boot
from ALARM, as I have not seen this issue on my ALARM-running A20 boards yet…
… and it failed again, this time with no explicit MMC-related errors, but with
hung tasks instead, much like my previous kernel log.
To be
On Sat, 2017-06-03 at 22:56 +0200, Thibaut Girka wrote:
> I keep experiencing this issue even with a brand new board (same model, newer
> hw revision) and on linux-image-4.10.0-rc6-armmp.
>
> I have been informed that this issue might have been fixed by:
>
I keep experiencing this issue even with a brand new board (same model, newer
hw revision) and on linux-image-4.10.0-rc6-armmp.
I have been informed that this issue might have been fixed by:
After a little less than two weeks running on 4.8, the second board finally
crashed during an “aptitude update” with:
1062229.158740] mmc0: Card stuck in programming state! mmc_do_erase
[1062229.933728] sunxi-mmc 1c0f000.mmc: fatal err update clk timeout
[1062230.708711] sunxi-mmc 1c0f000.mmc:
I have made some more tests using the “spew” and “stress” packages, but it
doesn't seem to cause the issue. So far, it mainly happened during package
installation (thus causing the additional pain of leaving some packages in a
broken state).
I have been unable to reproduce the issue with older
Package: linux-image-4.9.0-1-armmp
Severity: normal
I recently switched to linux 4.9.0 (jessie-backport package on one, package
from testing in the other) and latest u-boot on my two A20-OLinuXIno-LIME2
boards, which were running seriously outdated versions of linux until now (4.4
and 4.0).
Both
6 matches
Mail list logo
