CI hwpack on lava fail to boot on the boards

Bug #972191 reported by Deepti B. Kalakeri
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Linaro CI
Fix Released
Deepti B. Kalakeri

Bug Description

The hwpacks generated by CI does not boot on the lava boards.
Fix the hwpack problems if any from the CI side.

Here is the traceback of the lava for the boot test
Lava failed at action boot_linaro_image with error: Failed to boot test image.\nTraceback (most recent call last):\n File \"/srv/lava/instances/production/local/lib/python2.7/site-packages/lava_dispatcher/\", line 146, in run\n**params)\n File \"/srv/lava/instances/production/lib/python2.7/site-packages/lava_dispatcher/actions/\", line 57, in run\n raise CriticalError(\"Failed to boot test image.\")\nCriticalError: Failed to boot test image.\n",

Related branches

Changed in linaro-ci:
assignee: nobody → Deepti B. Kalakeri (deeptik)
milestone: none → 2012.04
importance: Undecided → Medium
Revision history for this message
Deepti B. Kalakeri (deeptik) wrote :

With the omap2plus defconfig , my hwpack seems to get stuck at various points with diff config options, with the default upstream omap2 defconfig my hwpack seems to hang @ With the following omap2plus config options, the hwpack fails to boot @ .

Between, with the default omap4_defconfig available in the linux linaro tracking tree the hwpack is able to boot on the board when ethernet port is connected and otherwise the boot process keeps waiting at the point where it searches for the ethernet connection to be up when ethernet port is not connected( I tested this on panda only).

Also, I was speaking to Andrey today, he was suggesting that we should use the default omap4 defconfig to build arm-soc , linux(master), linux-next as well. I am in discussion with Ricardo, Andrey to check if we need to continue with the omap2plus defconfig builds or just have omap4 defconfig.


David Zinman (dzinman)
Changed in linaro-ci:
milestone: 2012.04 → 2012.05
Changed in linaro-ci:
status: New → In Progress
Revision history for this message
Deepti B. Kalakeri (deeptik) wrote :

Here is the boot log for the boot test run by LAVA, this is not for the above hwpack, but is a similar error which is produced by
You need to click on Inline Viewer tab to see the console messages

I was able to fix the above boot problem of the CI kernel hwpacks built with omap2plus defconfig
by adding the options similar to the ones available in (linux-linaro tree) default omap4 defconfig on top of the default
omap2plus defconfig options.

Here is the list of the config options which I added along with the omap2plus
defconfig to make it work.

There are several config options that are enabled, but we need to come up with a minimal omapplus2 config options needed to be able to boot. Also, since the config options in omap2plus defconfig was enabled by referring to omap4 defconfig I am not sure if its the right way fix the problem.

A mail was sent to linaro-dev mailing list with the details on the same.
Deepak Saxena from Kernel team has informed that OMAP maintainer Tony L would probably be looking into the same.

Revision history for this message
Deepti B. Kalakeri (deeptik) wrote :

Nothing heard from Deepak or Tony L. Hence moving the bug to next milestone.

Changed in linaro-ci:
milestone: 2012.05 → 2012.06
Revision history for this message
Deepti B. Kalakeri (deeptik) wrote :

I tried building the kernel on ompa2 defconfig builds for armhf and this seemed to fix the errors we were seeing.
The omap2_defconfig builds boot fine on panda boards, but the kernel built is failing to boot on beagle boards because of Kernel panic . The Kernel trace can be found in the log

Revision history for this message
Deepti B. Kalakeri (deeptik) wrote :

There is a separate bug to track the omap2 kernel panic for beagle board and is tracked under bug Hence closing this bug.

Changed in linaro-ci:
status: In Progress → Fix Committed
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.