On 06/11/2015 11:46 PM, Fathi Boudra wrote:

Hi Alex,

On 11 June 2015 at 17:45, Alex Shi alex.shi@linaro.org wrote:

...

Hi Fathi,

I just updated the eas-test branch on https://git.linaro.org/kernel/eas-backports.git

But the dashboard said deploy linaro kernel failed: https://validation.linaro.org/dashboard/streams/public/team/linaro/eas/bundl...

And I didn't find the eas on https://ci.linaro.org/view/kernel-ci/ or lsk-ci.

It isn't included in any view. I'll add it to the main view.

Got the EAS build now. Thanks! https://ci.linaro.org/job/linux-eas/

...

Guess I miss sth, could you lead me to right ci or testing url?

it has been built as expected (https://ci.linaro.org/job/linux-eas/17/) but it failed to build:

/home/buildslave/workspace/linux-eas/kernel/sched/fair.c: In function 'scale_rt_capacity': /home/buildslave/workspace/linux-eas/kernel/sched/fair.c:5661:6: warning: unused variable 'delta' [-Wunused-variable] s64 delta; ^ /home/buildslave/workspace/linux-eas/kernel/sched/fair.c: In function 'find_busiest_queue': /home/buildslave/workspace/linux-eas/kernel/sched/fair.c:6339:17: error: storage size of 'rt' isn't known enum fbq_type rt; ^ /home/buildslave/workspace/linux-eas/kernel/sched/fair.c:6339:17: warning: unused variable 'rt' [-Wunused-variable] make[3]: *** [kernel/sched/fair.o] Error 1

new branch passed in build thanks!

...

Thanks&Regards! Alex

On 12 June 2015 at 13:03, Alex Shi alex.shi@linaro.org wrote:

Hi Fathi,

https://validation.linaro.org/dashboard/streams/public/team/linaro/eas/bundl...

My eas-test branch booted OK on panda ES, but failed on tc2 with test case: execute_boot_cmds and boot_linaro_image.

the console log are:

Bootloader Error: boot command execution failed.

or

Lava failed at action boot_linaro_image with error:Failed to boot test image. Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/lava_dispatcher/job.py", line 381, in run action.run(**params) File "/usr/lib/python2.7/dist-packages/lava_dispatcher/actions/boot_control.py", line 139, in run raise CriticalError("Failed to boot test image.") CriticalError: Failed to boot test image.

---

Maybe it is kernel panic in booting. Is it possible to get the kernel ops during booting?

It's caused by UEFI boot menu changes. We need to update the LAVA job definition. Looking at this issue now.

Thanks! Alex

On 12 June 2015 at 13:51, Mark Brown broonie@linaro.org wrote:

On Fri, Jun 12, 2015 at 01:40:45PM +0300, Fathi Boudra wrote:

...

It's caused by UEFI boot menu changes. We need to update the LAVA job definition. Looking at this issue now.

Doesn't the integration of the board into lAVA handle the interaction with the firmware?

LAVA has boot_cmds for the firmware used at that some point in time. The lab can override them when a firmware is updated to match the new firmware. The LAVA job definition itself can override the boot_cmds to handle the firmware changes if necessary.

We fall in the last case, the job definition has boot_cmds for a deprecated firmware. The lab configuration has updated boot_cmds to match the new firmware. Most likely the fix here is to get rid of the custom boot_cmds used by the LAVA job definition in order to use the lab configuration, which is good now... until next firmware upgrade that will break the UEFI menu...

On 12 June 2015 at 14:34, Mark Brown broonie@kernel.org wrote:

On Fri, Jun 12, 2015 at 01:59:31PM +0300, Fathi Boudra wrote:

...

The lab configuration has updated boot_cmds to match the new firmware. Most likely the fix here is to get rid of the custom boot_cmds used by the LAVA job definition in order to use the lab configuration, which is good now... until next firmware upgrade that will break the UEFI menu...

Well, presumably when there's a new firmware update the machine integration rather than the jobs should be updated?

Both. The lab configuration is updated and if the LAVA job definition contains custom boot_cmds, it has to be updated as well. You can submit a build job using a specific firmware and use custom boot_cmds for this specific firmware.

Lesson learned: when a new firmware is deployed and the boot_cmds are updated, review the LAVA job definitions and update them if necessary.

On 12 June 2015 at 15:12, Mark Brown broonie@kernel.org wrote:

On Fri, Jun 12, 2015 at 02:47:07PM +0300, Fathi Boudra wrote:

...

Lesson learned: when a new firmware is deployed and the boot_cmds are updated, review the LAVA job definitions and update them if necessary.

Well, and also be very careful about adding custom boot commands in the first place - it's a sign that the system is getting more fragile.

It has been discussed several times since UEFI exists and the way it is handled by LAVA. e.g. https://bugs.launchpad.net/lava-dispatcher/+bug/1197582

LAVA isn't able to handle the menu. The whole hardcoded pexpect is a workaround and is fragile. Long term, as discussed with UEFI people, we want to move away from this and use UEFI shell as much as possible.