next/master boot: 171 boots: 6 failed, 162 passed with 3 offline (next-20180724)
Full Boot Summary: https://kernelci.org/boot/all/job/next/branch/master/kernel/next-20180724/ Full Build Summary: https://kernelci.org/build/next/branch/master/kernel/next-20180724/
Tree: next Branch: master Git Describe: next-20180724 Git Commit: 3946cd385042069ec57d3f04240def53b4eed7e5 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Tested: 67 unique boards, 26 SoC families, 20 builds out of 200
Boot Regressions Detected:
arm:
bcm2835_defconfig: bcm2835-rpi-b: lab-baylibre-seattle: failing since 5 days (last pass: next-20180718 - first fail: next-20180719) bcm2837-rpi-3-b: lab-baylibre: failing since 5 days (last pass: next-20180718 - first fail: next-20180719)
tegra_defconfig: tegra124-jetson-tk1: lab-mhart: failing since 11 days (last pass: next-20180712 - first fail: next-20180713) lab-baylibre-seattle: failing since 11 days (last pass: next-20180712 - first fail: next-20180713)
arm64:
defconfig+CONFIG_CPU_BIG_ENDIAN=y: mt8173-evb: lab-baylibre-seattle: failing since 4 days (last pass: next-20171201 - first fail: next-20180720)
defconfig+CONFIG_RANDOMIZE_BASE=y: mt8173-evb: lab-baylibre-seattle: failing since 4 days (last pass: next-20171201 - first fail: next-20180720)
Boot Failures Detected:
arm:
tegra_defconfig tegra124-jetson-tk1: 2 failed labs
bcm2835_defconfig bcm2835-rpi-b: 1 failed lab bcm2837-rpi-3-b: 1 failed lab
arm64:
defconfig+CONFIG_CPU_BIG_ENDIAN=y mt8173-evb: 1 failed lab
defconfig+CONFIG_RANDOMIZE_BASE=y mt8173-evb: 1 failed lab
Offline Platforms:
arm:
qcom_defconfig: qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab
arm64:
defconfig: mt8173-evb: 1 offline lab
--- For more info write to info@kernelci.org
On Tue, Jul 24, 2018 at 09:46:38AM -0700, kernelci.org bot wrote:
For a little while now the RPi B has been failing to boot using the bcm2835 defconfig in -next:
bcm2835_defconfig: bcm2835-rpi-b: lab-baylibre-seattle: failing since 5 days (last pass: next-20180718 - first fail: next-20180719) bcm2837-rpi-3-b: lab-baylibre: failing since 5 days (last pass: next-20180718 - first fail: next-20180719)
It's working fine on arm64, whatever's going on appears to be specific to this config (it's not getting booted with any other 32 bit configs). Full info and boot logs for one of the boards here:
https://kernelci.org/boot/id/5b58416759b514139596baae/
it looks like it hangs somewhere shortly after or during initializing MMC so never makes it to the console, the tail of the failing logs looks like:
| 09:18:36.332120 [ 1.459801] mmc1: queuing unknown CIS tuple 0x80 (7 bytes) | 09:18:36.345711 [ 1.467585] mmcblk0: mmc0:59b4 USD 7.51 GiB | 09:18:36.346169 [ 1.474834] mmcblk0: p1 | 09:18:36.410184 [ 1.539600] random: fast init done | 09:18:36.458065 [ 1.578056] mmc1: new high speed SDIO card at address 0001 | 09:20:39.745370 ShellCommand command timed out.: Sending # in case of corruption. Connection timeout 00:04:10, retry in 00:02:05 | 09:20:39.846848 #
but like I say the same -next boots with arm64 defconfig.
Hi Mark,
thanks for forwarding. Unfortunately i don't have the time for real investigation until next week, so here some remote diagnostics.
Am 25.07.2018 um 18:11 schrieb Mark Brown:
On Tue, Jul 24, 2018 at 09:46:38AM -0700, kernelci.org bot wrote:
For a little while now the RPi B has been failing to boot using the bcm2835 defconfig in -next:
bcm2835_defconfig: bcm2835-rpi-b: lab-baylibre-seattle: failing since 5 days (last pass: next-20180718 - first fail: next-20180719) bcm2837-rpi-3-b: lab-baylibre: failing since 5 days (last pass: next-20180718 - first fail: next-20180719)It's working fine on arm64, whatever's going on appears to be specific to this config (it's not getting booted with any other 32 bit configs). Full info and boot logs for one of the boards here:
https://kernelci.org/boot/id/5b58416759b514139596baae/it looks like it hangs somewhere shortly after or during initializing MMC so never makes it to the console, the tail of the failing logs looks like:
| 09:18:36.332120 [ 1.459801] mmc1: queuing unknown CIS tuple 0x80 (7 bytes) | 09:18:36.345711 [ 1.467585] mmcblk0: mmc0:59b4 USD 7.51 GiB | 09:18:36.346169 [ 1.474834] mmcblk0: p1 | 09:18:36.410184 [ 1.539600] random: fast init done | 09:18:36.458065 [ 1.578056] mmc1: new high speed SDIO card at address 0001 | 09:20:39.745370 ShellCommand command timed out.: Sending # in case of corruption. Connection timeout 00:04:10, retry in 00:02:05 | 09:20:39.846848 #
but like I say the same -next boots with arm64 defconfig.
There is at least 1 difference between bcm2835_defconfig and arm64 defconfig. bcm2835_defconfig uses DMA
[ 1.265671] sdhost-bcm2835 3f202000.mmc: loaded - DMA enabled (>1)
while arm64 defconfig uses PIO mode for SD interface mmc0 (please ignore mmc1 since it's the onboard wifi and it uses a different driver):
[ 1.907766] sdhost-bcm2835 3f202000.mmc: unable to initialise DMA channel. Falling back to PIO [ 1.995407] sdhost-bcm2835 3f202000.mmc: loaded - DMA disabled
The reason for this output is expected, because the DMA driver isn't build-in for this config.
I think this issue is DMA related.
Regards Stefan
On Wed, Jul 25, 2018 at 05:11:51PM +0100, Mark Brown wrote:
On Tue, Jul 24, 2018 at 09:46:38AM -0700, kernelci.org bot wrote:
For a little while now the RPi B has been failing to boot using the bcm2835 defconfig in -next:
...
It's working fine on arm64, whatever's going on appears to be specific to this config (it's not getting booted with any other 32 bit configs). Full info and boot logs for one of the boards here:
it looks like it hangs somewhere shortly after or during initializing MMC so never makes it to the console, the tail of the failing logs looks like:
This went away for a day or two but it looks like it's back again I'm afraid:
https://kernelci.org/boot/id/5b604cd259b514364696baaa/
| 09:18:36.332120 [ 1.459801] mmc1: queuing unknown CIS tuple 0x80 (7 bytes) | 09:18:36.345711 [ 1.467585] mmcblk0: mmc0:59b4 USD 7.51 GiB | 09:18:36.346169 [ 1.474834] mmcblk0: p1 | 09:18:36.410184 [ 1.539600] random: fast init done | 09:18:36.458065 [ 1.578056] mmc1: new high speed SDIO card at address 0001 | 09:20:39.745370 ShellCommand command timed out.: Sending # in case of corruption. Connection timeout 00:04:10, retry in 00:02:05 | 09:20:39.846848 #
but like I say the same -next boots with arm64 defconfig.
On 31/07/18 16:52, Mark Brown wrote:
On Wed, Jul 25, 2018 at 05:11:51PM +0100, Mark Brown wrote:
On Tue, Jul 24, 2018 at 09:46:38AM -0700, kernelci.org bot wrote:
For a little while now the RPi B has been failing to boot using the bcm2835 defconfig in -next:
...
It's working fine on arm64, whatever's going on appears to be specific to this config (it's not getting booted with any other 32 bit configs). Full info and boot logs for one of the boards here:
https://kernelci.org/boot/id/5b58416759b514139596baae/it looks like it hangs somewhere shortly after or during initializing MMC so never makes it to the console, the tail of the failing logs looks like:
This went away for a day or two but it looks like it's back again I'm afraid:
FWIW, it looks like that blip was due to me completely breaking DMA API functionality for DT devices in next-20180727. Funny that that actually "helped" in this case (unlike all the others...), but it definitely reinforces Stefan's observation.
Robin.
https://kernelci.org/boot/id/5b604cd259b514364696baaa/| 09:18:36.332120 [ 1.459801] mmc1: queuing unknown CIS tuple 0x80 (7 bytes) | 09:18:36.345711 [ 1.467585] mmcblk0: mmc0:59b4 USD 7.51 GiB | 09:18:36.346169 [ 1.474834] mmcblk0: p1 | 09:18:36.410184 [ 1.539600] random: fast init done | 09:18:36.458065 [ 1.578056] mmc1: new high speed SDIO card at address 0001 | 09:20:39.745370 ShellCommand command timed out.: Sending # in case of corruption. Connection timeout 00:04:10, retry in 00:02:05 | 09:20:39.846848 #
but like I say the same -next boots with arm64 defconfig.
linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Robin Murphy robin.murphy@arm.com hat am 31. Juli 2018 um 19:00 geschrieben:
On 31/07/18 16:52, Mark Brown wrote:
On Wed, Jul 25, 2018 at 05:11:51PM +0100, Mark Brown wrote:
On Tue, Jul 24, 2018 at 09:46:38AM -0700, kernelci.org bot wrote:
For a little while now the RPi B has been failing to boot using the bcm2835 defconfig in -next:
...
It's working fine on arm64, whatever's going on appears to be specific to this config (it's not getting booted with any other 32 bit configs). Full info and boot logs for one of the boards here:
https://kernelci.org/boot/id/5b58416759b514139596baae/it looks like it hangs somewhere shortly after or during initializing MMC so never makes it to the console, the tail of the failing logs looks like:
This went away for a day or two but it looks like it's back again I'm afraid:
FWIW, it looks like that blip was due to me completely breaking DMA API functionality for DT devices in next-20180727. Funny that that actually "helped" in this case (unlike all the others...), but it definitely reinforces Stefan's observation.
Robin.
Sorry, still not much time this week. All i can say that next-20180731 is broken, but dma-mapping/for-next is not.
kernel-build-reports@lists.linaro.org
-
kernelci.org bot -
Mark Brown -
Robin Murphy -
Stefan Wahren