>>
>>
>>
>>
>>
>> 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
>>
>>
>
>
>
> --
> Thanks and Regards,
> Deepti
> Infrastructure Team Member, Linaro Platform Teams
> Linaro.org | Open source software for ARM SoCs
> Follow Linaro:
http://www.facebook.com/pages/Linaro
>
http://twitter.com/#!/linaroorg -
http://www.linaro.org/linaro-blog
>
>