On 22 February 2012 09:53, Deepti Kalakeri <[email protected]>wrote:
> > > On Tue, Feb 21, 2012 at 10:30 PM, Paul Larson <[email protected]>wrote: > >> 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. >> >> > Yes we build the linux-linaro 3.1 from > http://people.linaro.org/~asac/githttp/linux-linaro-3.1.git/ which > points to the latest upstream changes as well. > But the origen hwpack fails for this tree as well. > > > @ Sangwook, > > So should we apply the patch for all the trees (arm-soc, linus(torvalds), > linux-linaro, linux-next) and build the kernel for testing on the origen > boards? > > Yes, only If you want to build kernel automatically without touching exynos4_defconfig or .confg. > 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 >>> > >>> > >>> >> >> > > > -- > 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
