Hello Fengguang,
I hope this email finds you well. Since our call last week, we’ve been
working internally trying to best identify issues/questions we need to
draft up the scope of work for our collaboration with Compass CI and we
have the following points we wish to discuss with you further.
After some internal discussions, we think and support your proposal of
having Compass CI dispatch jobs to LAVA via the dispatcher. However, we did
have a few questions we need your help in answering:
Q1. Do you expect to use LKFT’s lab?
Q2. Do you want to add your embedded boards to your dispatcher in your own
lab?
Q3. We assume you want to test the OpenEuler kernel. Do you want to use our
OpenEmbedded or OpenEuler rootFS?
Q4. Do you want to run the same test we run in LKFT?
Q5. Do you want to run LKP tests
Q6. IF you wish to run Linaro test definitions, the data will be stored in
SQUAD. For LKP, we expect the tests themselves to send the test results to
Compass CI directly.
We spent a lot of time discussing how to best collaborate with Compass CI
to the benefit of Linaro's members and we believe bolstering benchmark
testing is a key value your team can help us deliver. The focus is on
benchmark test extraction, processing and comparison. The functionality we
seek is in LKP so your team’s help in extracting and genericising such
tooling so we can leverage it in LKFT and other test frameworks.
We can discuss the above points over email or setup a call if you like.
Thanks,
Anmar
Hello anmar,
I'm sorry I forgot to tell you my email is liuyinsi(a)163.com, please do not email to liuyinsi(a)huawei.com.
Thank you for providing me the QEMU's instance booting log, I'm sorry I still don't know how to reproduce the issues.
Hello David and Luca,
Which command did it report errors when it was executed?
Where did you execute the commands？In the server openEuler OS
that i setup for you, or run a container on the server, then execute commands in the container?
Could you help me to reappear question on tmux 'tm lys', it is convenient to locate the problem, thank you very much.
Thanks,
yinsi
liuyinsi(a)163.com
发件人： Anmar Oueja
发送日期： 2021年02月18日 02:43
收件人： liuyinsi
抄送人： Cameron，wufengguang，yuchuan，lkq-dev，Dave Pigott，Luca Di Stefano，Jammy Zhou
主题： Issues with docker on OpenEulerOS
Hello Yinsi/Yuchan,
Happy Lunar New Year!!!
David and Luca (on CC) are hitting a few bumps trying to get the QEMU
instances running in a docker container on the OpenEuler OS install
you setup for us. The QEMU instances are failing to boot from NFS.
Thinking it might be a permission problem, we confirmed that the
containers are run as root and SELinux is disabled yet the problem
persists. We did replicate the setup on a Debian Aarch64 system and it
worked so we suspect there's something in OpenEuler OS we haven't
configured correctly.
This is QEMU's instance booting log you:
https://lkft-staging.validation.linaro.org/scheduler/job/100307
Can you please work with David and Luca to try and figure this out.
Cheers!
anmar
We still have some work to do to fully enable the Kungpen worker. We need to set up local mirrors in China of snapshots and set up git and netrc redirects so that we get a reasonable bandwidth.
Chase and Jammy - how do we go about expediting this?
Thanks
Dave
> On 21 Apr 2021, at 10:32, wufengguang via Lkq-dev <lkq-dev(a)op-lists.linaro.org> wrote:
>
> Hi Anmar,
>
>> Hello Fengguang,
>>
>> I hope this email finds you well. Since our call last week, we’ve
>> been working internally trying to best identify issues/questions we
>> need to draft up the scope of work for our collaboration with Compass
>> CI and we have the following points we wish to discuss with you
>> further.
>>
>> After some internal discussions, we think and support your proposal of
>> having Compass CI dispatch jobs to LAVA via the dispatcher.
>
> Glad to hear that, thanks!
>
>> However, we did have a few questions we need your help in answering:
>
> OK. Let me try answering these questions in the context of
> "having Compass CI dispatch jobs to LAVA via the dispatcher".
>
>> Q1. Do you expect to use LKFT’s lab?
>
> Yes in the sense of reusing LKFT lab's current facilities and
> functionalities to test openEuler kernel.
>
> As for "Compass CI + LAVA dispatcher", we mainly care about implementing
> the functionality. You may freely choose the most convenient lab (or
> create an experimental instance) to use in the development and debug
> process.
>
>> Q2. Do you want to add your embedded boards to your dispatcher in your own lab?
>
> I suppose so, after implemented the functionality.
>
> During the development phase, the developer may try things out on his local side
> if that would be more efficient.
>
>> Q3. We assume you want to test the OpenEuler kernel. Do you want to use our OpenEmbedded or OpenEuler rootFS?
>
> Yes we'll test openEuler kernel.
>
> For rootFS, I guess whatever readily available (eg. OpenEmbedded) should
> be fine in the beginning. When the job conversion+execution flow works,
> we may go on to check how to deploy openEuler rootFS via LAVA for
> limited SUT types.
>
>> Q4. Do you want to run the same test we run in LKFT?
>
> LKP jobs are our priority. I tend to not list LKFT jobs in the goal of
> this CompassCI+LAVA integration project, to reduce unnecessary complexity.
>
>> Q5. Do you want to run LKP tests
>
> Yes. Submitting LKP jobs to LAVA controlled devices.
> Auto converting LKP job to LAVA job for execution.
>
>> Q6. IF you wish to run Linaro test definitions, the data will be stored in SQUAD.
>> For LKP, we expect the tests themselves to send the test results to Compass CI directly.
>
> OK, got it.
>
>> We spent a lot of time discussing how to best collaborate with Compass
>> CI to the benefit of Linaro's members and we believe bolstering
>> benchmark testing is a key value your team can help us deliver. The
>> focus is on benchmark test extraction, processing and comparison. The
>> functionality we seek is in LKP so your team’s help in extracting and
>> genericising such tooling so we can leverage it in LKFT and other test
>> frameworks.
>
> lkp-tests is designed to be reusable by other projects. It should
> relatively easy to reuse its code.
>
> compass-ci services all run in containers, which makes their build
> dependency clear.
>
> Though there may still be a ton of boring/messy works in trying to
> integrating different parts of lkp-tests/compass-ci to LKFT in order to
> create a complete solution.
>
> Another tough question is whether LKFT duplicate the code and evolve
> standalone, or reuse code in place while trying to modify
> various places of the code to work in a different situation.
>
> compass-ci grows on top of lkp-tests in the very beginning, which makes
> the development natural and simple.
>
> Thanks,
> Fengguang
> --
> Lkq-dev mailing list
> Lkq-dev(a)op-lists.linaro.org
> https://op-lists.linaro.org/mailman/listinfo/lkq-dev
Hey, Rémi!
On Tue, 30 Mar 2021 at 07:49, Remi Duraffort via Lkq-dev
<lkq-dev(a)op-lists.linaro.org> wrote:
> I'm tryin to boot test some of lkft x86_64 and i386 kernels using TuxTest.
> My main issue is that lkft kernels does not support virtio as a block
> device, making TuxTest life more difficult.
>
> Would it be possible to add support for virtio block devices?
Do you happen to know which configs it is that we need? We actually
carry a "Virtio" config fragment:
https://github.com/Linaro/meta-lkft/blob/sumo/recipes-kernel/linux/files/vi…
Here's a (torvalds/master) kernel that we built with that fragment:
https://builds.tuxbuild.com/1qRb2aF6PNl6c20JEDRfFB4RFMT/
Thanks and greetings!
Daniel Díaz
daniel.diaz(a)linaro.org
Hello,
I'm tryin to boot test some of lkft x86_64 and i386 kernels using TuxTest.
My main issue is that lkft kernels does not support virtio as a block
device, making TuxTest life more difficult.
Would it be possible to add support for virtio block devices?
Cheers
--
Rémi Duraffort
Tux Architect
Linaro
To be more clear, 22.03 LTS will use 5.10 kernel but LTS with
4.19 will be maintained as well.
On 2021/3/19 17:23, Hanjun Guo via Lkq-dev wrote:
> Hi,
>
> LTS will be based on 4.19 kernel, but 21.03 innovation version will use
> 5.10 kernel.
>
> Thanks
> Hanjun
>
>
> On 2021/3/19 8:29, Jammy Zhou wrote:
>> +Hanjun
>>
>> As I know, the kernel will be based on v5.10 for openEuler 21.09, but
>> for 21.03 and 20.03 LTS, it is still based on v4.19.
>>
>> On Fri, 19 Mar 2021 at 00:33, Jonathan Cameron
>> <Jonathan.Cameron(a)huawei.com <mailto:Jonathan.Cameron@huawei.com>> wrote:
>>
>> @yinsi
>>
>> What are chances of upgrading the host os to a more recent openEuler
>> kernel.
>> 4.19 is a bit of a stretch for a backport of the fix.
>> I guess it might be easy, but would feel more comfortable with 5.10
>> or 5.5
>>
>> Or can we ask openEuler to carry a backport of this set directly?
>>
>> Another alternative is to see if there is an available BIOS with
>> the fix
>> in place and upgrade.
>>
>> Jonathan
>>
>> On Thu, 18 Mar 2021 13:38:28 +0000
>> Dave Pigott <dave.pigott(a)linaro.org <mailto:dave.pigott@linaro.org>>
>> wrote:
>>
>> > Hi Yinsi,
>> >
>> > Okay - that fixed it. We’ve now got an excellent download speed.
>> We’re back to the problems with qemu compatibility. Working on this.
>> >
>> > Thanks for your help!
>> >
>> > Dave
>> >
>> > > On 18 Mar 2021, at 12:11, liuyinsi(a)163.com
>> <mailto:liuyinsi@163.com> wrote:
>> > >
>> > > Hi Dave,
>> > >
>> > > I pull the images in openEulerOS, though you got the message
>> about docker pull limit, you still can pull successfully, ignore the
>> message if not block our work.
>> > >
>> > > Thanks
>> > > Yinsi
>> > >
>> > >
>> > >
>> > > liuyinsi
>> > > 邮箱：liuyinsi(a)163.com <mailto:liuyinsi@163.com>
>> > > <https://maas.mail.163.com/dashi-web-extend/html
>> /proSignature.html?ftlId=1&name=liuyinsi&uid=liuyinsi%40163.com&
>> iconUrl=https%3A%2F%2Fmail-
>> online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png&items=%5B%22%E9
>> %82%AE%E7%AE%B1%EF%BC%9Aliuyinsi%40163.com%22%5D>签名由 网易邮箱大师
>> <https://mail.163.com/dashi/dlpro.html?from=mail88> 定制
>> > >
>> > > On 03/18/2021 19:47, Dave Pigott <mailto:dave.pigott@linaro.org
>> <mailto:dave.pigott@linaro.org>> wrote:
>> > > Hi Yinsi,
>> > >
>> > > It’s lavasoftware/lava-dispatcher:2021.03
>> > >
>> > > Dave
>> > >
>> > >> On 18 Mar 2021, at 11:44, liuyinsi(a)163.com
>> <mailto:liuyinsi@163.com> <mailto:liuyinsi@163.com
>> <mailto:liuyinsi@163.com>> wrote:
>> > >>
>> > >> Hi Dave,
>> > >>
>> > >> What is the docker images name you want to pull from
>> dockerhub？
>> > >>
>> > >> Thanks
>> > >> Yinsi
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> liuyinsi
>> > >> 邮箱：liuyinsi(a)163.com <mailto:liuyinsi@163.com>
>> > >> <https://maas.mail.163.com/dashi-web-extend/html
>> /proSignature.html?ftlId=1&name=liuyinsi&uid=liuyinsi%40163.com&
>> iconUrl=https%3A%2F%2Fmail-
>> online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png&items=%5B%22%E9
>> %82%AE%E7%AE%B1%EF%BC%9Aliuyinsi%40163.com%22%5D>签名由 网易邮箱大师
>> <https://mail.163.com/dashi/dlpro.html?from=mail88> 定制
>> > >>
>> > >> On 03/18/2021 19:28, Dave Pigott
>> <mailto:dave.pigott@linaro.org <mailto:dave.pigott@linaro.org>>
>> wrote:
>> > >> Hi Yinsi,
>> > >>
>> > >> We’re trying to upgrade the docker worker to the latest
>> release and we got the message that we’ve hit our docker pull limit.
>> We’ve only done two pulls. Any ideas?
>> > >>
>> > >> Thanks
>> > >>
>> > >> Dave
>> > >>
>> > >>
>> > >>> On 18 Mar 2021, at 10:47, liuyinsi(a)163.com
>> <mailto:liuyinsi@163.com> <mailto:liuyinsi@163.com
>> <mailto:liuyinsi@163.com>> wrote:
>> > >>>
>> > >>> Hi Dave,
>> > >>>
>> > >>> I notice the job 2313644
>> <https://lkft.validation.linaro.org/scheduler/job/2313644> is
>> created 2 weeks, 6 days ago, can you test a new job, test wget
>>
>> http://images.validation.linaro.org/snapshots.linaro.org/components/lava/st…
>>
>>
>> <http://images.validation.linaro.org/snapshots.linaro.org/components/lava/st…>
>> on openEulerOS machine is ok, first download speed about 2.63MB/s.
>> > >>>
>> > >>> It's better to improve your download code, to face unstable
>> and slow network issues, for example, increase timeout and add
>> retries.
>> > >>>
>> > >>> Thanks
>> > >>> Yinsi
>> > >>>
>> > >>> liuyinsi(a)163.com <mailto:liuyinsi@163.com>
>> <mailto:liuyinsi@163.com <mailto:liuyinsi@163.com>>
>> > >>>
>> > >>> From: Dave Pigott <mailto:dave.pigott@linaro.org
>> <mailto:dave.pigott@linaro.org>>
>> > >>> Date: 2021-03-18 17:04
>> > >>> To: liuyinsi(a)163.com <mailto:liuyinsi@163.com>
>> <mailto:liuyinsi@163.com <mailto:liuyinsi@163.com>>
>> > >>> CC: Anmar Oueja <mailto:anmar.oueja@linaro.org
>> <mailto:anmar.oueja@linaro.org>>; Luca Di Stefano
>> <mailto:luca.distefano@linaro.org
>> <mailto:luca.distefano@linaro.org>>; wufengguang
>> <mailto:wufengguang@huawei.com <mailto:wufengguang@huawei.com>>;
>> Jonathan Cameron <mailto:jonathan.cameron@huawei.com
>> <mailto:jonathan.cameron@huawei.com>>; lkq-dev
>> <mailto:lkq-dev@op-lists.linaro.org
>> <mailto:lkq-dev@op-lists.linaro.org>>; jammy.zhou(a)linaro.org
>> <mailto:jammy.zhou@linaro.org> <mailto:jammy.zhou@linaro.org
>> <mailto:jammy.zhou@linaro.org>>
>> > >>> Subject: Re: Issues with docker on OpenEulerOS
>> > >>> Hi Yinsi,
>> > >>>
>> > >>> If you look at a failed example - e.g.
>> https://lkft.validation.linaro.org/scheduler/job/2313644
>> <https://lkft.validation.linaro.org/scheduler/job/2313644> - you’ll
>> see it’s not failing on a git clone, it’s failing on a wget.
>> > >>>
>> > >>> Dave
>> > >>>
>> > >>>
>> > >>>> On 18 Mar 2021, at 08:19, liuyinsi(a)163.com
>> <mailto:liuyinsi@163.com> <mailto:liuyinsi@163.com
>> <mailto:liuyinsi@163.com>> wrote:
>> > >>>>
>> > >>>> Hi Dave,
>> > >>>>
>> > >>>> "http download timeout", does it happen often?
>> > >>>> "https download timeout", has this problem been solved by
>> edit ~/.gitconfig?
>> > >>>>
>> > >>>> Thanks
>> > >>>> Yinsi
>> > >>>>
>> > >>>> liuyinsi(a)163.com <mailto:liuyinsi@163.com>
>> <mailto:liuyinsi@163.com <mailto:liuyinsi@163.com>>
>> > >>>>
>> > >>>> From: liuyinsi(a)163.com <mailto:liuyinsi@163.com>
>> <mailto:liuyinsi@163.com <mailto:liuyinsi@163.com>>
>> > >>>> Date: 2021-03-17 10:19
>> > >>>> To: Dave Pigott <mailto:dave.pigott@linaro.org
>> <mailto:dave.pigott@linaro.org>>
>> > >>>> CC: Oueja <mailto:anmar.oueja@linaro.org
>> <mailto:anmar.oueja@linaro.org>>; luca
>> <mailto:luca.distefano@linaro.org
>> <mailto:luca.distefano@linaro.org>>; wufengguang
>> <mailto:wufengguang@huawei.com <mailto:wufengguang@huawei.com>>;
>> Cameron <mailto:jonathan.cameron@huawei.com
>> <mailto:jonathan.cameron@huawei.com>>; lkq-dev
>> <mailto:lkq-dev@op-lists.linaro.org
>> <mailto:lkq-dev@op-lists.linaro.org>>; jammy.zhou(a)linaro.org
>> <mailto:jammy.zhou@linaro.org> <mailto:jammy.zhou@linaro.org
>> <mailto:jammy.zhou@linaro.org>>
>> > >>>> Subject: Re: Re: Issues with docker on OpenEulerOS
>> > >>>>
>> > >>>>
>> > >>>>>>
>> > >>>>>> Locally, in the lab, we use KissCache for https cacheing.
>> We would have to go through every test definition submitted by every
>> bot and developer to change from https to git.
>> > >>>>>>
>> > >>>>> vi ~/.gitconfig
>> > >>>>>
>> > >>>>> [url "git://github.com <http://github.com>
>> <git://github.com <http://github.com>>"]
>> > >>>>> insteadOf = https://github.com <https://github.com/>
>> > >>>>>
>> > >>>>> This will change from https to git.
>> > >>>>>
>> > >>>>
>> > >>>> Hi Yinsi,
>> > >>>>
>> > >>>> If you look at the job definitions, e.g.
>>
>> https://lkft.validation.linaro.org/scheduler/job/2409008/definition#defline…
>>
>>
>> <https://lkft.validation.linaro.org/scheduler/job/2409008/definition#defline…>,
>>
>> you’ll see the URL is defined there. I’m not sure where you are
>> suggesting this could be universally changed to use git.
>> > >>>>
>> > >>>> Hi Dave,
>> > >>>>
>> > >>>> You can edit the file in any environment where you execute
>> the clone command, for example, i get the URL and will git clone in
>> a qemu, if i edit ~/.gitconfig in qemu before clone,
>> > >>>> then it will automatically change https to git.
>> > >>>>
>> > >>>> Thanks
>> > >>>> Yinsi
>> > >>>>
>> > >>>> Dave
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> Thanks
>> > >>>>>>
>> > >>>>>> Dave
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>> anmar
>> > >>
>> > >
>> >
>> >
>>
Hello!
On Thu, 4 Mar 2021 at 03:12, liuyinsi--- via Lkq-dev
<lkq-dev(a)op-lists.linaro.org> wrote:
> Hi anmar/luca,
>
> http://images.validation.linaro.org/snapshots.linaro.org/components/lava/st…
> https://github.com/Linaro/test-definitions.git
>
> 1. http download:
> How many HTTP files do you have to download? If not many, please provide http files download links,
> we can download all http files at first time, then we can use http proxy cache at next time to fix
> download timeout.
Would it be possible to set up a mirror closer to your network?
Greetings!
Daniel Díaz
daniel.diaz(a)linaro.org
On Wed, 24 Feb 2021 08:02:05 +0000
Jonathan Cameron via Lkq-dev <lkq-dev(a)op-lists.linaro.org> wrote:
> Try specifying gic v3. There is a bug in some firmware versions that makes the host kernel think we are gic v2 compatible which it doesn't.
>
> Jonathan
https://lore.kernel.org/linux-arm-kernel/20201130102639.7504-1-shameerali.k…
For reference on the issue - plus proposed fix.
Marc Zyngier then posted an alternative fix
https://lore.kernel.org/linux-arm-kernel/20210115140323.2682634-1-maz@kerne…
I believe Marc's fix is queued up for current merge window.
If it's not that, it would be great to have the command run + boot log.
Jonathan
>
>
>
>
> --------------------------------------------------
> Jonathan Cameron
> Mobile: +44-7870588074
> Email: jonathan.cameron(a)huawei.com<mailto:jonathan.cameron@huawei.com>
> From:Luca Di Stefano <luca.distefano(a)linaro.org>
> To:liuyinsi <liuyinsi(a)163.com>;Oueja <anmar.oueja(a)linaro.org>;Pigott <dave.pigott(a)linaro.org>
> Cc:wufengguang <wufengguang(a)huawei.com>;Jonathan Cameron <jonathan.cameron(a)huawei.com>;jammy.zhou <jammy.zhou(a)linaro.org>;lkq-dev <lkq-dev(a)op-lists.linaro.org>
> Date:2021-02-23 12:12:05
> Subject:Re: Fw: Issues with docker on OpenEulerOS
>
>
> Hi Yinsi,
>
> On 20/02/2021 07:19, liuyinsi(a)163.com<mailto:liuyinsi@163.com> wrote:
> Hello anmar,
>
> I'm sorry I forgot to tell you my email is liuyinsi(a)163.com<mailto:liuyinsi@163.com>, please do not email to liuyinsi(a)huawei.com<mailto:liuyinsi@huawei.com>.
>
> Thank you for providing me the QEMU's instance booting log, I'm sorry I still don't know how to reproduce the issues.
>
> Hello David and Luca,
>
> Which command did it report errors when it was executed?
>
> There was not a specific error as much as the qemu not being able to mount the rootfs as in other equivalent aarch64 jobs on other dispatchers:
>
> https://lkft-staging.validation.linaro.org/scheduler/job/100307T
>
> That's an example of the boot process.
>
> Tried the same qemu command manually with the same kernel and initrd in a container on the server and had the same result.
>
>
> Where did you execute the commands？In the server openEuler OS
> that i setup for you, or run a container on the server, then execute commands in the container?
>
> We run everything on a container on the server.
>
> Could you help me to reappear question on tmux 'tm lys', it is convenient to locate the problem, thank you very much.
>
> Does that command need to be run in the background? otherwise i get a new shell opened only.
>
> Thank you
>
> Thanks,
> yinsi
> ________________________________
> liuyinsi(a)163.com<mailto:liuyinsi@163.com>
> 发件人： Anmar Oueja<mailto:anmar.oueja@linaro.org>
> 发送日期： 2021年02月18日 02:43
> 收件人： liuyinsi<mailto:liuyinsi@huawei.com>
> 抄送人： Cameron<mailto:jonathan.cameron@huawei.com>，wufengguang<mailto:wufengguang@huawei.com>，yuchuan<mailto:13186087857@163.com>，lkq-dev<mailto:lkq-dev@op-lists.linaro.org>，Dave Pigott<mailto:dave.pigott@linaro.org>，Luca Di Stefano<mailto:luca.distefano@linaro.org>，Jammy Zhou<mailto:jammy.zhou@linaro.org>
> 主题： Issues with docker on OpenEulerOS
> Hello Yinsi/Yuchan,
>
> Happy Lunar New Year!!!
>
> David and Luca (on CC) are hitting a few bumps trying to get the QEMU
> instances running in a docker container on the OpenEuler OS install
> you setup for us. The QEMU instances are failing to boot from NFS.
>
> Thinking it might be a permission problem, we confirmed that the
> containers are run as root and SELinux is disabled yet the problem
> persists. We did replicate the setup on a Debian Aarch64 system and it
> worked so we suspect there's something in OpenEuler OS we haven't
> configured correctly.
>
> This is QEMU's instance booting log you:
> https://lkft-staging.validation.linaro.org/scheduler/job/100307
>
> Can you please work with David and Luca to try and figure this out.
>
> Cheers!
> anmar
Hello Yinsi/Yuchan,
Happy Lunar New Year!!!
David and Luca (on CC) are hitting a few bumps trying to get the QEMU
instances running in a docker container on the OpenEuler OS install
you setup for us. The QEMU instances are failing to boot from NFS.
Thinking it might be a permission problem, we confirmed that the
containers are run as root and SELinux is disabled yet the problem
persists. We did replicate the setup on a Debian Aarch64 system and it
worked so we suspect there's something in OpenEuler OS we haven't
configured correctly.
This is QEMU's instance booting log you:
https://lkft-staging.validation.linaro.org/scheduler/job/100307
Can you please work with David and Luca to try and figure this out.
Cheers!
anmar
