next boot: 267 boots: 5 failed, 261 passed with 1 offline (next-20150408)
Full Boot Summary: http://kernelci.org/boot/all/job/next/kernel/next-20150408/ Full Build Summary: http://kernelci.org/build/next/kernel/next-20150408/
Tree: next Branch: local/master Git Describe: next-20150408 Git Commit: a897436e0e233e84b664bb7f33c4e0d4d3e3bdad Git URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Tested: 68 unique boards, 20 SoC families, 25 builds out of 123
Boot Failures Detected: http://kernelci.org/boot/?next-20150408&fail
arm:
imx_v6_v7_defconfig: imx6q-sabrelite: 1 failed lab
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: sun7i-a20-bananapi: 1 failed lab sun7i-a20-cubieboard2: 1 failed lab sun7i-a20-cubietruck: 2 failed labs
Offline Platforms:
arm:
u8500_defconfig: ste-snowball: 1 offline lab
--- For more info write to info@kernelci.org
Hi Kevin,
On Wed, Apr 8, 2015 at 1:05 PM, kernelci.org bot bot@kernelci.org wrote:
next boot: 267 boots: 5 failed, 261 passed with 1 offline (next-20150408)
Full Boot Summary: http://kernelci.org/boot/all/job/next/kernel/next-20150408/ Full Build Summary: http://kernelci.org/build/next/kernel/next-20150408/
Tree: next Branch: local/master Git Describe: next-20150408 Git Commit: a897436e0e233e84b664bb7f33c4e0d4d3e3bdad Git URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Tested: 68 unique boards, 20 SoC families, 25 builds out of 123
Boot Failures Detected: http://kernelci.org/boot/?next-20150408&fail
arm:
imx_v6_v7_defconfig: imx6q-sabrelite: 1 failed lab
Do you have more information about this failure? I looked in the logs and it was not clear where the error is coming from.
Regards,
Fabio Estevam
Hi Fabio,
On 8 April 2015 at 10:31, Fabio Estevam festevam@gmail.com wrote:
Hi Kevin,
On Wed, Apr 8, 2015 at 1:05 PM, kernelci.org bot bot@kernelci.org wrote:
next boot: 267 boots: 5 failed, 261 passed with 1 offline (next-20150408)
Full Boot Summary: http://kernelci.org/boot/all/job/next/kernel/next-20150408/ Full Build Summary: http://kernelci.org/build/next/kernel/next-20150408/
Tree: next Branch: local/master Git Describe: next-20150408 Git Commit: a897436e0e233e84b664bb7f33c4e0d4d3e3bdad Git URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Tested: 68 unique boards, 20 SoC families, 25 builds out of 123
Boot Failures Detected: http://kernelci.org/boot/?next-20150408&fail
arm:
imx_v6_v7_defconfig: imx6q-sabrelite: 1 failed labDo you have more information about this failure? I looked in the logs and it was not clear where the error is coming from.
Sjoerd and I have recently been observing userspace issues with the imx_v6_v7_defconfig + sabrelite, however these issues have not been observed with multi_v7_defconfig + sabrelite.
Some of the observed issues are:
* Platform never reaches a userspace shell prompt (This was the case above) * Platform is able to reach a userspace shell prompt, however it is not responsive to input. [0] * When the platform reaches a userspace shell prompt and can run commands, they segfault. [1]
The Collabora lab has three platforms sabrelite we test on and correct me if I'm wrong Sjoerd but they all intermittently show these issues.
Regards,
Fabio Estevam _______________________________________________ Kernel-build-reports mailing list Kernel-build-reports@lists.linaro.org https://lists.linaro.org/mailman/listinfo/kernel-build-reports
Tyler
[0] https://lava.collabora.co.uk/scheduler/job/15230/log_file#L_55_324 [1] https://lava.collabora.co.uk/scheduler/job/13636/log_file#L_83_0
Hi Tyler,
On Wed, Apr 8, 2015 at 2:43 PM, Tyler Baker tyler.baker@linaro.org wrote:
Sjoerd and I have recently been observing userspace issues with the imx_v6_v7_defconfig + sabrelite, however these issues have not been observed with multi_v7_defconfig + sabrelite.
Some of the observed issues are:
- Platform never reaches a userspace shell prompt (This was the case above)
- Platform is able to reach a userspace shell prompt, however it is
not responsive to input. [0]
- When the platform reaches a userspace shell prompt and can run
commands, they segfault. [1]
The Collabora lab has three platforms sabrelite we test on and correct me if I'm wrong Sjoerd but they all intermittently show these issues.
I noticed that the silicon revision on this board is TO1.0, which is very old.
Do you know if all the sabrelite boards that fail are from this same revision?
I don't see such problem with other mx6 boards running linux-next.
Regards,
Fabio Estevam
Hi Fabio,
On 8 April 2015 at 10:52, Fabio Estevam festevam@gmail.com wrote:
Hi Tyler,
On Wed, Apr 8, 2015 at 2:43 PM, Tyler Baker tyler.baker@linaro.org wrote:
Sjoerd and I have recently been observing userspace issues with the imx_v6_v7_defconfig + sabrelite, however these issues have not been observed with multi_v7_defconfig + sabrelite.
Some of the observed issues are:
- Platform never reaches a userspace shell prompt (This was the case above)
- Platform is able to reach a userspace shell prompt, however it is
not responsive to input. [0]
- When the platform reaches a userspace shell prompt and can run
commands, they segfault. [1]
The Collabora lab has three platforms sabrelite we test on and correct me if I'm wrong Sjoerd but they all intermittently show these issues.
I noticed that the silicon revision on this board is TO1.0, which is very old.
Do you know if all the sabrelite boards that fail are from this same revision?
Looks like this is the case.
imx6q-sabrelite-lava-cbg-0: CPU identified as i.MX6Q, silicon rev 1.0
imx6q-sabrelite-lava-cbg-1: CPU identified as i.MX6Q, silicon rev 1.0
imx6q-sabrelite-lava-cbg-2: CPU identified as i.MX6Q, silicon rev 1.0
All the jobs/logs are available here if you want to dig deeper. [0]
I don't see such problem with other mx6 boards running linux-next.
Regards,
Fabio Estevam
Tyler
[0] https://lava.collabora.co.uk/scheduler/device_type/imx6q-sabrelite
On 8 April 2015 at 09:05, kernelci.org bot bot@kernelci.org wrote:
next boot: 267 boots: 5 failed, 261 passed with 1 offline (next-20150408)
Full Boot Summary: http://kernelci.org/boot/all/job/next/kernel/next-20150408/ Full Build Summary: http://kernelci.org/build/next/kernel/next-20150408/
Tree: next Branch: local/master Git Describe: next-20150408 Git Commit: a897436e0e233e84b664bb7f33c4e0d4d3e3bdad Git URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Tested: 68 unique boards, 20 SoC families, 25 builds out of 123
Boot Failures Detected: http://kernelci.org/boot/?next-20150408&fail
arm:
imx_v6_v7_defconfig: imx6q-sabrelite: 1 failed lab multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: sun7i-a20-bananapi: 1 failed lab sun7i-a20-cubieboard2: 1 failed lab sun7i-a20-cubietruck: 2 failed labs
Kevin and I bisected this failure with some interesting results.
There are two ways we have found to get these platforms booting again.
1) git checkout next && git revert a897436e0e233e84b664bb7f33c4e0d4d3e3bdad
Add linux-next specific files for 20150408
2) git checkout next && rm -f localversion-next
We thought this might be a kernel load address issue, so we appended the dtb and removed the ramdisk + modules from the equation, same boot failure. Using hexdiff to diff the two zImages (good and bad) yield quite a bit of changes. We also tested building the test kernels with gcc 4.7.3 and 4.9 same result.
Any ideas on what might be the issue here?
[ 1.957715] Unable to handle kernel paging request at virtual address b1000458 [ 1.964943] pgd = c0204000 [ 1.967648] [b1000458] *pgd=00000000 [ 1.971240] Internal error: Oops: 5 [#1] SMP ARM [ 1.975856] Modules linked in: [ 1.978927] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc7-next-20150408 #1 [ 1.986311] Hardware name: Allwinner sun7i (A20) Family [ 1.991530] task: ed870000 ti: ed86c000 task.ti: ed86c000 [ 1.996931] PC is at sunxi_sc_nmi_set_type+0x14c/0x164 [ 2.002065] LR is at sunxi_sc_nmi_set_type+0x74/0x164 [ 2.007112] pc : [] lr : [] psr: 60000093 [ 2.007112] sp : ed86dc58 ip : 00000002 fp : 00000000 [ 2.018573] r10: edb19900 r9 : c0fa3fdc r8 : 00000000 [ 2.023792] r7 : c0ffc428 r6 : ed804418 r5 : 00000008 r4 : ed804650 [ 2.030311] r3 : b1000458 r2 : c0ca5a6c r1 : 00000008 r0 : 00000000 [ 2.036832] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [ 2.044217] Control: 10c5387d Table: 6ddf806a DAC: 00000015 [ 2.049955] Process swapper/0 (pid: 1, stack limit = 0xed86c220) [ 2.055955] Stack: (0xed86dc58 to 0xed86e000) [ 2.060310] dc40: 00000042 edb19900 [ 2.068479] dc60: c04c539c ed80447c 00000008 00000052 00000000 c02987e0 00000001 00000008 [ 2.076649] dc80: 00000052 edb19900 c0f8bb8c 00000000 00000000 c0299cf8 c0f8bb8c 60000013 [ 2.084819] dca0: 00000052 ed86dcd0 00000052 c029d234 ed86dcb8 ed86dcbc 00000000 00000008 [ 2.092988] dcc0: edded420 c17e5eb4 edded400 c0878624 ee7cbc4c 00000002 00000000 00000008 [ 2.101158] dce0: c0d00b9c edde0d20 00000000 edde32a0 c0fa3fdc 00000001 00000000 c037f5a0 [ 2.109328] dd00: 00000001 edded420 edded428 00000000 c0f8bb8c 00000000 00000000 c07d091c [ 2.117497] dd20: edded420 c17e5eb4 00000000 c062be14 00000000 edded420 c062bf50 eddeccf8 [ 2.125667] dd40: c17e5e70 c062a498 ed93e8d4 edd77754 edded420 edded454 c0fa4088 c062bc10 [ 2.133837] dd60: edded420 edded420 c0fa4088 c062b32c edded420 00000000 edded428 c062981c [ 2.142007] dd80: edded404 edded420 ed86ddd8 00000000 edded400 ed86dde4 eddeccb0 edded404 [ 2.150177] dda0: edded420 ed86ddd8 00000000 c07d11b4 00000000 eddeccb0 00000000 eddeccb0 [ 2.158346] ddc0: ee7d6b18 ed86dde4 eddeccf8 c07d15b8 00000000 00000004 00000000 00000000 [ 2.166516] dde0: 00000000 32707861 00003930 00000000 00000000 00000000 00340000 00000000 [ 2.174685] de00: ed86ddd8 ee7d6b18 00000000 00000000 eddecc10 00000000 ed946810 00000000 [ 2.182855] de20: 00000014 000186a0 016e3600 c07d90a0 c0d46174 eddecc10 00000000 ee7d6820 [ 2.191024] de40: eddecc58 ed946810 eddecc10 ed946800 00000000 000186a0 c0e8efe0 fffffffe [ 2.199194] de60: ed946810 fffffdfb c0fa4494 00000000 c0e8efe0 00000000 00000000 c062d210 [ 2.207364] de80: c062d1c8 ed946810 c17e5eb4 00000000 c0fa4494 c062be14 ed946810 c0fa4494 [ 2.215533] dea0: ed946844 00000000 c0e5dfd4 c062bf4c 00000000 c0fa4494 c062beb8 c062a534 [ 2.223703] dec0: ed805ca4 ed921850 c0fa4494 eddb9e00 c0f89290 c062b51c c0d46174 c0fa4494 [ 2.231872] dee0: c0ee1798 c0fa4494 c0ee1798 eddf1940 c0ff8000 c062c588 00000000 c0ee1798 [ 2.240042] df00: c0ee1798 c020aaa4 ffffffff c02142c8 00000001 ed870490 00000000 ed870000 [ 2.248213] df20: 60000113 c0f27f88 00000000 c0ff8000 ef7fce6d c0a05df0 00000118 c02698c8 [ 2.256382] df40: c0d3f404 c0dcb57c 00000006 00000006 00000000 ef7fce40 c0ed5534 00000006 [ 2.264552] df60: c0e8efd4 c0ff8000 00000118 c0e8efe0 c0e15598 c0e15d80 00000006 00000006 [ 2.272721] df80: c0e15598 00000000 00000000 c09db214 00000000 00000000 00000000 00000000 [ 2.280892] dfa0: 00000000 c09db21c 00000000 c0210870 00000000 00000000 00000000 00000000 [ 2.289060] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 2.297230] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffff7fff fffffffb [ 2.305408] [] (sunxi_sc_nmi_set_type) from [] (__irq_set_trigger+0x54/0x10c) [ 2.314279] [] (__irq_set_trigger) from [] (irq_set_irq_type+0x34/0x5c) [ 2.322626] [] (irq_set_irq_type) from [] (irq_create_of_mapping+0x114/0x15c) [ 2.331495] [] (irq_create_of_mapping) from [] (of_irq_get+0x38/0x44) [ 2.339668] [] (of_irq_get) from [] (i2c_device_probe+0x44/0x10c) [ 2.347495] [] (i2c_device_probe) from [] (driver_probe_device+0x1cc/0x270) [ 2.356190] [] (driver_probe_device) from [] (bus_for_each_drv+0x44/0x8c) [ 2.364710] [] (bus_for_each_drv) from [] (device_attach+0x74/0x8c) [ 2.372706] [] (device_attach) from [] (bus_probe_device+0x88/0xac) [ 2.380705] [] (bus_probe_device) from [] (device_add+0x33c/0x52c) [ 2.388617] [] (device_add) from [] (i2c_new_device+0x138/0x170) [ 2.396355] [] (i2c_new_device) from [] (i2c_register_adapter+0x198/0x468) [ 2.404962] [] (i2c_register_adapter) from [] (mv64xxx_i2c_probe+0x310/0x470) [ 2.413829] [] (mv64xxx_i2c_probe) from [] (platform_drv_probe+0x48/0xa4) [ 2.422348] [] (platform_drv_probe) from [] (driver_probe_device+0x1cc/0x270) [ 2.431212] [] (driver_probe_device) from [] (__driver_attach+0x94/0x98) [ 2.439644] [] (__driver_attach) from [] (bus_for_each_dev+0x54/0x88) [ 2.447816] [] (bus_for_each_dev) from [] (bus_add_driver+0xd4/0x1d0) [ 2.455986] [] (bus_add_driver) from [] (driver_register+0x78/0xf4) [ 2.463985] [] (driver_register) from [] (do_one_initcall+0x80/0x1d4) [ 2.472161] [] (do_one_initcall) from [] (kernel_init_freeable+0x10c/0x1d8) [ 2.480856] [] (kernel_init_freeable) from [] (kernel_init+0x8/0xec) [ 2.488943] [] (kernel_init) from [] (ret_from_fork+0x14/0x24) [ 2.496506] Code: e5878000 eaffffe3 e5963020 e0833007 (e5930000) [ 2.502636] ---[ end trace df9330afddbb32fb ]--- [ 2.507390] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 2.507390] [ 2.516525] CPU1: stopping [ 2.519241] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 4.0.0-rc7-next-20150408 #1 [ 2.527840] Hardware name: Allwinner sun7i (A20) Family [ 2.533073] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 2.540817] [] (show_stack) from [] (dump_stack+0x78/0x94) [ 2.548037] [] (dump_stack) from [] (handle_IPI+0x138/0x164) [ 2.555429] [] (handle_IPI) from [] (gic_handle_irq+0x64/0x6c) [ 2.562994] [] (gic_handle_irq) from [] (__irq_svc+0x44/0x5c) [ 2.570465] Exception stack(0xed89df88 to 0xed89dfd0) [ 2.575515] df80: c02112d8 00000000 00000000 00000000 c0ede4a4 00000000 [ 2.583686] dfa0: 00000000 c0ed90c0 c0ede508 c0ede510 00000001 00000000 ed89dfd8 ed89dfd0 [ 2.591852] dfc0: c02112d8 c02112dc 60000113 ffffffff [ 2.596906] [] (__irq_svc) from [] (arch_cpu_idle+0x20/0x3c) [ 2.604301] [] (arch_cpu_idle) from [] (cpu_startup_entry+0x2ac/0x360) [ 2.612561] [] (cpu_startup_entry) from [<4020a8ac>] (0x4020a8ac) [ 2.619526] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Offline Platforms:
arm:
u8500_defconfig: ste-snowball: 1 offline lab
For more info write to info@kernelci.org _______________________________________________ Kernel-build-reports mailing list Kernel-build-reports@lists.linaro.org https://lists.linaro.org/mailman/listinfo/kernel-build-reports
Hi,
On Wed, Apr 08, 2015 at 12:13:08PM -0700, Tyler Baker wrote:
On 8 April 2015 at 09:05, kernelci.org bot bot@kernelci.org wrote:
next boot: 267 boots: 5 failed, 261 passed with 1 offline (next-20150408)
Full Boot Summary: http://kernelci.org/boot/all/job/next/kernel/next-20150408/ Full Build Summary: http://kernelci.org/build/next/kernel/next-20150408/
Tree: next Branch: local/master Git Describe: next-20150408 Git Commit: a897436e0e233e84b664bb7f33c4e0d4d3e3bdad Git URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Tested: 68 unique boards, 20 SoC families, 25 builds out of 123
Boot Failures Detected: http://kernelci.org/boot/?next-20150408&fail
arm:
imx_v6_v7_defconfig: imx6q-sabrelite: 1 failed lab multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: sun7i-a20-bananapi: 1 failed lab sun7i-a20-cubieboard2: 1 failed lab sun7i-a20-cubietruck: 2 failed labsKevin and I bisected this failure with some interesting results.
There are two ways we have found to get these platforms booting again.
- git checkout next && git revert a897436e0e233e84b664bb7f33c4e0d4d3e3bdad
Add linux-next specific files for 20150408
- git checkout next && rm -f localversion-next
We thought this might be a kernel load address issue, so we appended the dtb and removed the ramdisk + modules from the equation, same boot failure. Using hexdiff to diff the two zImages (good and bad) yield quite a bit of changes. We also tested building the test kernels with gcc 4.7.3 and 4.9 same result.
Any ideas on what might be the issue here?
I gave this a shot this weekend, and unfortunately, I can't build a kernel that points out this issue.
Given that this seem to be very sensitive to various string length, I wonder whether the fact that I'm possibly using a different compiler, and building at a different path can "cover" it.
Are you using it using a VM/container? If so, if it's an option, I can always run that VM here and give it a try.
Thanks, Maxime
Hi Maxime,
On 12 April 2015 at 23:47, Maxime Ripard maxime.ripard@free-electrons.com wrote:
Hi,
On Wed, Apr 08, 2015 at 12:13:08PM -0700, Tyler Baker wrote:
On 8 April 2015 at 09:05, kernelci.org bot bot@kernelci.org wrote:
next boot: 267 boots: 5 failed, 261 passed with 1 offline (next-20150408)
Full Boot Summary: http://kernelci.org/boot/all/job/next/kernel/next-20150408/ Full Build Summary: http://kernelci.org/build/next/kernel/next-20150408/
Tree: next Branch: local/master Git Describe: next-20150408 Git Commit: a897436e0e233e84b664bb7f33c4e0d4d3e3bdad Git URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Tested: 68 unique boards, 20 SoC families, 25 builds out of 123
Boot Failures Detected: http://kernelci.org/boot/?next-20150408&fail
arm:
imx_v6_v7_defconfig: imx6q-sabrelite: 1 failed lab multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: sun7i-a20-bananapi: 1 failed lab sun7i-a20-cubieboard2: 1 failed lab sun7i-a20-cubietruck: 2 failed labsKevin and I bisected this failure with some interesting results.
There are two ways we have found to get these platforms booting again.
- git checkout next && git revert a897436e0e233e84b664bb7f33c4e0d4d3e3bdad
Add linux-next specific files for 20150408
- git checkout next && rm -f localversion-next
We thought this might be a kernel load address issue, so we appended the dtb and removed the ramdisk + modules from the equation, same boot failure. Using hexdiff to diff the two zImages (good and bad) yield quite a bit of changes. We also tested building the test kernels with gcc 4.7.3 and 4.9 same result.
Any ideas on what might be the issue here?
I gave this a shot this weekend, and unfortunately, I can't build a kernel that points out this issue.
Given that this seem to be very sensitive to various string length, I wonder whether the fact that I'm possibly using a different compiler, and building at a different path can "cover" it.
Are you using it using a VM/container? If so, if it's an option, I can always run that VM here and give it a try.
Sorry for not posting this earlier, we have been tracking our findings here if you would like to have a look.
https://github.com/kernelci/kernel-bugs/issues/15
Thanks, Maxime
-- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Hi Tyler,
On Mon, Apr 13, 2015 at 11:30:02AM -0700, Tyler Baker wrote:
Hi Maxime,
On 12 April 2015 at 23:47, Maxime Ripard maxime.ripard@free-electrons.com wrote:
Hi,
On Wed, Apr 08, 2015 at 12:13:08PM -0700, Tyler Baker wrote:
On 8 April 2015 at 09:05, kernelci.org bot bot@kernelci.org wrote:
next boot: 267 boots: 5 failed, 261 passed with 1 offline (next-20150408)
Full Boot Summary: http://kernelci.org/boot/all/job/next/kernel/next-20150408/ Full Build Summary: http://kernelci.org/build/next/kernel/next-20150408/
Tree: next Branch: local/master Git Describe: next-20150408 Git Commit: a897436e0e233e84b664bb7f33c4e0d4d3e3bdad Git URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Tested: 68 unique boards, 20 SoC families, 25 builds out of 123
Boot Failures Detected: http://kernelci.org/boot/?next-20150408&fail
arm:
imx_v6_v7_defconfig: imx6q-sabrelite: 1 failed lab multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: sun7i-a20-bananapi: 1 failed lab sun7i-a20-cubieboard2: 1 failed lab sun7i-a20-cubietruck: 2 failed labsKevin and I bisected this failure with some interesting results.
There are two ways we have found to get these platforms booting again.
- git checkout next && git revert a897436e0e233e84b664bb7f33c4e0d4d3e3bdad
Add linux-next specific files for 20150408
- git checkout next && rm -f localversion-next
We thought this might be a kernel load address issue, so we appended the dtb and removed the ramdisk + modules from the equation, same boot failure. Using hexdiff to diff the two zImages (good and bad) yield quite a bit of changes. We also tested building the test kernels with gcc 4.7.3 and 4.9 same result.
Any ideas on what might be the issue here?
I gave this a shot this weekend, and unfortunately, I can't build a kernel that points out this issue.
Given that this seem to be very sensitive to various string length, I wonder whether the fact that I'm possibly using a different compiler, and building at a different path can "cover" it.
Are you using it using a VM/container? If so, if it's an option, I can always run that VM here and give it a try.
Sorry for not posting this earlier, we have been tracking our findings here if you would like to have a look.
Yeah, I saw that, that's actually why I was mentionning the path length and gcc version as a possible cause of it working on my system.
Maxime
kernel-build-reports@lists.linaro.org
-
Fabio Estevam -
kernelci.org bot -
Maxime Ripard -
Tyler Baker