The initial problem, you faced is due to the wrong kernel selected by someone.
If you tried kernel from CI (arnd) , it should be based on 3.2 kernel, but it was not true.
It was based on 2.6.35-rxxx. Where does this kernel come from ?
At first, please select the proper kernel and then try LAVA again.



On 15 February 2012 21:35, Paul Larson <paul.larson@linaro.org> wrote:
On Wed, Feb 15, 2012 at 3:46 AM, Deepti Kalakeri <deepti.kalakeri@linaro.org> wrote:


On Wed, Feb 15, 2012 at 4:32 PM, Sangwook Lee <sangwook.lee@linaro.org> wrote:


On 14 February 2012 16:40, Paul Larson <paul.larson@linaro.org> wrote:
On Tue, Feb 14, 2012 at 2:21 AM, Sangwook Lee <sangwook.lee@linaro.org> wrote:
Hi Paul

On 14 February 2012 01:03, Paul Larson <paul.larson@linaro.org> wrote:

Looking at the latest results on.the kernel CI view I pointed out earlier, here is a serial.log from a recent one http://validation.linaro.org/lava-server/dashboard/streams/anonymous/ci-linux-next/bundles/2bbe117846bab5d41bc8222e38945aae78802c8d/1180312c-5628-11e1-9729-68b599be548c/attachments/47519/

You can see the test kernel starting to boot at around line 19560 and at 19660 it gets only as far as the starting kernel message, hangs, and eventually times out.

I think there is no option to download this log, maybe only for LAVA team.
If I download serial.log file as html, I must follow the link to serial log but again I have a broken link.
Yes, we need a download link there - known feature request that we'll hopefully get to soon. 

but replaces the kernel with the output from jenkins building the selected kernel.  I'm guessing that perhaps we're missing something critical from the kernel configuration?

Yes, That's right. I am attaching the patch to fix this problem.
Unfortunately, currently this is not up-streamable. Hope that we apply this as doing debian packaing.
please let me if you have further problem.
 
I'm not sure what you mean here.  If this patch fixes the problem, what is preventing it from going upstream? 

arnd kernel (mainline kernel) we have to do the following for Origen board
            1) Select exynos4_defconfig
                    All boards for exynos CPU are sharing one configuration.
                    So It select all boards configs and then set UART port to 1
            2) We have to set UART port to 2 manually only for Origen

The patch I sent to you is to select debug UART port to 2 by default, only for Origen
If we release this patch into mainline, all other boards using Exynos will manually select UART port again.

 
I guess we have this fix somewhere in the kernel produced by the landing team?  If so, it seems maybe we should also add the landing team tree here for testing so that we can see it pass.

Here is our branch:
Git:       git://git.linaro.org/landing-teams/working/samsung/kernel.git
branch: tracking
 
Initially I thought LAVA team is using hwpack built by John
  https://code.launchpad.net/~jcrigby/+recipe/linux-linaro-3.2-lt-origen-daily

Does Lave team build their own hwpack from kernel ?

Not the LAVA team. We(Infra) team build the latest upstream changes on ci.linaro.org and then send them to LAVA for testing.
Right, so I guess the better question would be, is there a bug for this already, and is there a better solution? Can we pass something on the boot cmdline that selects the proper uart? Why don't we have this problem with the linaro kernel in our leb images, do they include this workaround there?

Thanks,
Paul Larson