So if I'm understanding correctly, these are actual failures.  It would be
nice to have some tree that actually worked, but if it fails because it's
missing this patch, then it fails.  I think we test the Linaro 3.1 tree
there though right?  Shouldn't that include this, or is this not what we
currently ship in the LEB images?

http://people.linaro.org/~asac/githttp/linux-linaro-3.1.git/ is the one I'm
referring to, though I think it should really refer to the real upstream
tree, not the one in Alex's people.linaro.org account.

Thanks,
Paul Larson

On Tue, Feb 21, 2012 at 6:57 AM, Sangwook Lee <[email protected]>wrote:

> On 16 February 2012 11:39, Deepti Kalakeri <[email protected]>
> wrote:
> > Hello Sangwook,
> >
> > On Thu, Feb 16, 2012 at 4:37 PM, Sangwook Lee <[email protected]>
> > wrote:
> >>
> >>
> >> 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.
> >
> >
> > I have rectified this. Actually we were using a repository setup by Arnd
> on
> > git.linaro.org to build the kernel.
> > We did not notice the move to git.kernel.org and we built the old
> things.
> > But, otherwise also there are hwpacks built for linus(torvalds),
> linux-next
> > tree with exynos4 defconfig using the latest upstream changes.
> > I have not seen the hwpacks coming out for these trees either being
> > successful to boot on the LAVA origen boards.
> > Hence this is a problem that the hwpacks built for the origen boards do
> not
> > work at all and not specific to just arm-soc tree.
> > Can you check as an example if you can verify if the hwpacks built today
> > works fine on your Origen board.
> >
> http://ci.linaro.org/kernel_hwpack/linux-arm-soc-for-next/linux-arm-soc-for-next_origen-exynos4/hwpack_linaro-lt-origen_20120216-0729_b262_armel_supported.tar.gz
> .
> >
>
> With this image, I couldn't see the booting message.
>
> >
> > Do we need to apply the patch you gave yesterday on top of the Arnd
> latest
> > changes to make it work ?
>
> Yes,
>
> I downloaded git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
>  and then could see the booting message with
> the patch.
>
> >>
> >>
> >>
> >>
> >>
> >> On 15 February 2012 21:35, Paul Larson <[email protected]> wrote:
> >>>
> >>> On Wed, Feb 15, 2012 at 3:46 AM, Deepti Kalakeri
> >>> <[email protected]> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Feb 15, 2012 at 4:32 PM, Sangwook Lee <
> [email protected]>
> >>>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 14 February 2012 16:40, Paul Larson <[email protected]>
> wrote:
> >>>>>>
> >>>>>> On Tue, Feb 14, 2012 at 2:21 AM, Sangwook Lee
> >>>>>> <[email protected]> wrote:
> >>>>>>>
> >>>>>>> Hi Paul
> >>>>>>>
> >>>>>>> On 14 February 2012 01:03, Paul Larson <[email protected]>
> >>>>>>> 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<https://code.launchpad.net/%7Ejcrigby/+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
> >
> >
>
_______________________________________________
linaro-validation mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/linaro-validation

Reply via email to