Hi Andrei,
Thanks for suggestion, I too had a same doubt before proceeding with the
upgrade.
I will try to setup the latest version in new system or i will take a
backup of existing setup and run the test.
Thanks & Regards,
Dhanunjaya. P
On Mon, Jan 27, 2020 at 2:24 PM Andrei Gansari <andrei.gansari(a)nxp.com>
wrote:
> Hello Dhanunjaya,
>
>
>
> These are the instructions on installing lava, you have to do something
> similar to this in order to upgrade:
>
> https://docs.lavasoftware.org/lava/installing_on_debian.html
>
>
>
> I’m not sure if it will break or not your current setup, so be cautious
> when upgrading, better backup if you have a live setup that is testing
> other boards.
>
>
>
> I’m not a currently maintaining a LAVA server so I don’t have experience
> updating from one version to another.
>
> Better you search the mailing list, ask on the mailing list or tryout on a
> virtual machine.
>
>
>
>
>
> Andrei
>
>
>
> *From:* dhanu msys <dhanuskd.palnati(a)gmail.com>
> *Sent:* Friday, January 24, 2020 12:44 PM
> *To:* Andrei Gansari <andrei.gansari(a)nxp.com>
> *Subject:* Re: [EXT] Re: [Lava-users] Test jobs to boot the target
> through JLink
>
>
>
> *Caution: *EXT Email
>
> Hi Andrei,
>
>
>
> Can you please share the procedure to upgrade to the latest lava version.
>
>
>
> Thanks in advance.
>
>
>
> Regards,
>
> Dhanunjaya. P
>
>
>
>
>
> On Thu, Jan 23, 2020 at 7:33 PM Andrei Gansari <andrei.gansari(a)nxp.com>
> wrote:
>
> From the screenshot it looks like you have a version of LAVA that does not
> support jlink boot method.
>
> JLink was added in version 2019.10-1
>
>
>
> Andrei
>
>
>
> *From:* dhanu msys <dhanuskd.palnati(a)gmail.com>
> *Sent:* Thursday, January 23, 2020 3:13 PM
> *To:* Andrei Gansari <andrei.gansari(a)nxp.com>
> *Cc:* Kumar Gala <kumar.gala(a)linaro.org>; Andrei Gansari <
> andrei.gansari(a)linaro.org>; lava-users <lava-users(a)lists.lavasoftware.org>
> *Subject:* Re: [EXT] Re: [Lava-users] Test jobs to boot the target
> through JLink
>
>
>
> *Caution: *EXT Email
>
> Hi Andrei,
>
>
>
> I run the test job based on the references shared by you.
>
>
>
> But , facing the error , while running the test job.
>
>
>
> Here I have attached the device template & device configuration files
> along with the error.
>
>
>
> Please find the attachments & please provide me the inputs.
>
>
>
> Thanks in Advance.
>
>
>
> Regards,
>
> Dhanunjaya. P
>
>
>
>
>
> On Tue, Jan 21, 2020 at 5:29 PM Andrei Gansari <andrei.gansari(a)nxp.com>
> wrote:
>
> Hello Dhanunjaya. P,
>
>
>
> You need to create a yaml file in
> lava/lava_dispatcher/tests/sample_jobs/fpga_a64-jlink.yaml … assuming you
> have already created the device fpga_a64.
>
>
>
> You have an example of FRDM-K64F booting cmsis-dap here:
>
>
> https://github.com/Linaro/lite-lava-docker-compose/blob/lite/example/lava.j…
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>
>
> You need to replace “method: cmsis-dap” -> “method: jlink”
>
>
>
> I didn’t run a clean lava environment, so I maybe missing something.
>
>
>
>
>
> Andrei G.
>
>
>
> *From:* dhanu msys <dhanuskd.palnati(a)gmail.com>
> *Sent:* Tuesday, January 21, 2020 12:31 PM
> *To:* Andrei Gansari <andrei.gansari(a)nxp.com>
> *Cc:* Kumar Gala <kumar.gala(a)linaro.org>; Andrei Gansari <
> andrei.gansari(a)linaro.org>; lava-users <lava-users(a)lists.lavasoftware.org>
> *Subject:* Re: [EXT] Re: [Lava-users] Test jobs to boot the target
> through JLink
>
>
>
> *Caution: *EXT Email
>
> Hi Andrei,
>
>
>
> Based on the information shared earlier , i have tried to configure the
> device type to make use of jlink based boot method test job , but i have
> faced an issue "Configuration Error: missing or invalid template*.* Jobs
> requesting this device type (fpga_a64) will not be able to start until a
> template is available on the master."
>
>
>
> Can you please check once and share the updated Device-Type Template also.
>
>
>
> Thanks & Regards,
>
> Dhanunjaya. P
>
>
>
>
>
> On Tue, Jan 21, 2020 at 3:28 PM dhanu msys <dhanuskd.palnati(a)gmail.com>
> wrote:
>
> Hi Andrei ,
>
> Hi Kumar,
>
>
>
> Can you please share some of the Test Job definition references to check
> the Jlink-based test jobs configurations.
>
>
>
> Thanks & Regards,
>
> Dhanunjaya. P
>
>
>
>
>
> On Tue, Nov 26, 2019 at 2:36 PM Andrei Gansari <andrei.gansari(a)nxp.com>
> wrote:
>
> I’ve tested lava+jlink on Cortex M with both onboard debugger and external
> debugger, like the one you referenced.
>
> You should change the following if needed:
>
>
>
> address:
>
> *0x00000000*
>
> options:
>
> - '-device *MK64FN1M0xxx12'*
>
> - '-if SWD'
>
> - '-speed 4000'
>
>
>
> The interface SWD is supported, not JTAG, that can be easily changed if
> you need to.
>
>
>
> Regards,
>
> Andrei
>
>
>
> *From:* Lava-users <lava-users-bounces(a)lists.lavasoftware.org> *On Behalf
> Of *dhanu msys
> *Sent:* Tuesday, November 26, 2019 7:49 AM
> *To:* Kumar Gala <kumar.gala(a)linaro.org>
> *Cc:* Andrei Gansari <andrei.gansari(a)linaro.org>; lava-users <
> lava-users(a)lists.lavasoftware.org>
> *Subject:* [EXT] Re: [Lava-users] Test jobs to boot the target through
> JLink
>
>
>
> *Caution: *EXT Email
>
> Hi Kumar,
>
>
>
> Thanks for sharing the reference.
>
>
>
> It's better to have some references for the test jobs submission also.
>
>
>
> Currently we are in initial phase to make use of LAVA , so we wants to
> check the feasibility to deploy through JLink based test jobs.
>
>
>
> Here I have provided the JLink Interface , which we are going to use for
> the development.
>
>
>
>
> https://www.thingbits.net/products/segger-j-link-base-jtag-swd-debugger?utm…
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.thing…>
>
>
>
>
> Regards,
>
> Dhanunjaya. P
>
>
>
>
>
> On Sat, Nov 23, 2019 at 9:37 PM Kumar Gala <kumar.gala(a)linaro.org> wrote:
>
>
>
> > On Nov 21, 2019, at 11:06 PM, dhanu msys <dhanuskd.palnati(a)gmail.com>
> wrote:
> >
> > Hi Team,
> >
> > Can you please share some reference test jobs to run the tests using
> J-Link boot method.
>
> Here’s a reference to the board cfg side change for J-Link:
>
>
> https://github.com/agansari/lite-lava/blob/35a5bcbc01780638e6fd5e126bdfe180…
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>
>
> Andrei,
>
> Did you have a test job example to go along with this?
>
> - k
>
>
Hello,
Our internal LAVA setup has been hitting this crash intermittently (it reproduces about one out of every 30 job submissions). The below log snippet is from the 2019.07 LAVA docker images, but we updated to the 2019.12 images and the crash still occurs with the same error signature.
lava-master | 2019-10-22 15:37:17,539 DEBUG |--> [523] scheduling
lava-master | 2019-10-22 15:37:17,854 INFO [523] START => lava-dispatcher (CY8CKIT_062-01)
lava-master | 2019-10-22 15:37:17,969 INFO [523] lava-dispatcher => START_OK
lava-master | 2019-10-22 15:37:22,981 INFO [523] lava-dispatcher => END (lava-run crashed, mark job as INCOMPLETE)
lava-master | 2019-10-22 15:37:23,038 ERROR [523] Unable to dump 'description.yaml'
lava-master | 2019-10-22 15:37:23,038 ERROR [523] Compressed data ended before the end-of-stream marker was reached
lava-master | Traceback (most recent call last):
lava-master | File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-master.py", line 337, in _handle_end
lava-master | description = lzma.decompress(compressed_description)
lava-master | File "/usr/lib/python3.5/lzma.py", line 340, in decompress
lava-master | raise LZMAError("Compressed data ended before the "
lava-master | _lzma.LZMAError: Compressed data ended before the end-of-stream marker was reached
Please let me know if I can provide any other info to help debug.
Thanks,
Alex
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
Hey everyone,
I have a problem where a physical hardware device on my worker passed through to an LXC container cannot be read from or written to when I am connected to the LXC in a hacking session via SSH.
I have registered the device in my static_info:
{% set static_info = [
{"board_id": "GO31472"},
] %}
LAVA starts the LXC and attaches the device to it correctly:
start: 2.2 lxc-add-static (timeout 00:04:50) [remote]
Adding /dev/ttyUSB16, /dev/serial/by-id/usb-GFL_M_504_G_GO31472-if00-port0, /dev/bus/usb/004/008, /dev/serial/by-path/pci-0000:00:1d.3-usb-0:1:1.0-port0
nice lxc-device -n lxc-remote-10577 add /dev/ttyUSB16
nice lxc-device -n lxc-remote-10577 add /dev/serial/by-id/usb-GFL_M_504_G_GO31472-if00-port0
nice lxc-device -n lxc-remote-10577 add /dev/bus/usb/004/008
nice lxc-device -n lxc-remote-10577 add /dev/serial/by-path/pci-0000:00:1d.3-usb-0:1:1.0-port0
end: 2.2 lxc-add-static (duration 00:00:00) [remote]
When I connect to the LXC via SSH using a hacking session, the device is there, but I cannot access it:
root@lxc-remote-10577:~# ls -la /dev/ttyUSB16
crw-r--r-- 1 root root 180, 0 Aug 27 11:26 /dev/ttyUSB16
root@lxc-remote-10577:~# cat /dev/ttyUSB16
cat: /dev/ttyUSB16: Operation not permitted
However, when I attach to the LXC directly from the worker using "lxc-attach", I can access it:
root@lxc-remote-10577:~# ls -la /dev/ttyUSB16
crw-r--r-- 1 root root 180, 0 Aug 27 11:26 /dev/ttyUSB16
root@lxc-remote-10577:~# cat /dev/ttyUSB16
����������^C
root@lxc-remote-10577:/#
Did anybody else encounter such a problem before? Any hints on what might be the difference between lxc-attach and the SSH connection?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Schlachthofstrasse 20
21079 Hamburg
Direct: +49 40 791 899 - 183
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
WE MAKE IT YOURS!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
Hello Lava Users,
Trying to boot a target in LAVA based on base-grub device type.The LAVA
version installed is 2019.11.
>From the GRUB command line when I manually enter following commands for
network setting ,it is getting executed successfully.
grub> insmod efinet
grub> net_ls_cards
efinet2 20:87:56:b6:74:cd
efinet1 20:87:56:f1:cf:21
efinet0 20:87:56:f1:cf:22
grub> net_add_addr test efinet0 134.86.62.99
grub> net_ls_addr
test 20:87:56:f1:cf:22 134.86.62.99
But when I am sending same thing via LAVA ,
*net_add_addr test efinet0 134.86.62.99*
[H[J[1;1Hgrub> net_add_addr test efinet0 134.86.62.99
bootloader-commands: Wait for prompt ['grub>'] (timeout 00:09:38)
[1;7Hn[1;8H[1;8He[1;9H[1;9Ht[1;10H[1;10H_[1;11H[1;11Ha[1;12H[1;12Hd[1;13H[1;13Hd[1;14H[1;14H_[1;15H[1;15Ha[1;16H[1;16Hd[1;17H[1;17Hd[1;18H[1;18Hr[1;19H[1;19H
[1;20H[1;20Ht[1;21H[1;21He[1;22H[1;22Hs[1;23H[1;23Ht[1;24H[1;24H
[1;25H[1;25H [1;26H
*error: three arguments expected.*
The above error will come when we don't pass 3 parameters to net_add_addr
grub> net_add_addr test efinet0
error: three arguments expected.
I am getting this error even though 3 arguments are getting passed.
Attached is the screen shot of the Job execution log.
Thanks,
Hemanth.
Hello,
I ran the same job on staging (debian buster) and it's working fine:
https://staging.validation.linaro.org/scheduler/job/266192
Something wrong on your system. Difficult to know.
Could you send the full logs.
Rgds
Le mar. 14 janv. 2020 à 07:35, dhanu msys <dhanuskd.palnati(a)gmail.com> a
écrit :
> Hi Remi,
>
> Can you please check the logs and let me know what was the changes i need
> to make to run the LAVA QEMU arm based test jobs.
>
> Thanks & Regards,
> Dhanunjaya. P
>
>
> On Mon, Dec 23, 2019 at 5:47 PM dhanu msys <dhanuskd.palnati(a)gmail.com>
> wrote:
>
>> Hi Remi,
>>
>> Can you able to check the below mentioned the Log Files & Job related
>> configurations along with the Job failure logs.
>>
>> Thanks & Regards,
>> Dhanunjaya. P
>>
>>
>> On Thu, Nov 28, 2019 at 6:01 PM dhanu msys <dhanuskd.palnati(a)gmail.com>
>> wrote:
>>
>>> Hi Remi,
>>>
>>> Here I have attached the test job definition , test summary details &
>>> qemu device configuration file along with device template for qemu arm64
>>> architecture. PFA.
>>>
>>> Regards,
>>> Dhanunjaya. P
>>>
>>>
>>> On Tue, Nov 26, 2019 at 5:19 PM dhanu msys <dhanuskd.palnati(a)gmail.com>
>>> wrote:
>>>
>>>> Hi Remi,
>>>>
>>>> Here I have attached the Host Information.
>>>>
>>>> root@Dhanu:~# uname -a
>>>> Linux Dhanu 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20)
>>>> x86_64 GNU/Linux
>>>>
>>>> root@Dhanu:~# lsb_release -a
>>>> No LSB modules are available.
>>>> Distributor ID: Debian
>>>> Description: Debian GNU/Linux 10 (buster)
>>>> Release: 10
>>>> Codename: buster
>>>>
>>>> root@Dhanu:~# df -h
>>>> Filesystem Size Used Avail Use% Mounted on
>>>> udev 1.9G 0 1.9G 0% /dev
>>>> tmpfs 383M 18M 365M 5% /run
>>>> /dev/sda1 289G 23G 252G 9% /
>>>> tmpfs 1.9G 375M 1.6G 20% /dev/shm
>>>> tmpfs 5.0M 4.0K 5.0M 1% /run/lock
>>>> tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
>>>> tmpfs 383M 5.7M 377M 2% /run/user/1000
>>>>
>>>> And also I have attached the CPU Info & MemInfo related information for
>>>> your reference.
>>>>
>>>> Regards,
>>>> Dhanunjaya. P
>>>>
>>>>
>>>> On Tue, Nov 26, 2019 at 3:17 PM Remi Duraffort <
>>>> remi.duraffort(a)linaro.org> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>>> https://staging.validation.linaro.org/scheduler/device/staging-qemu03
>>>>>>
>>>>>>
>>>>>> This should work, unless your system is way too old. what host are
>>>>> you using?
>>>>>
>>>>>
>>>>> Rgds
>>>>>
>>>>> --
>>>>> Rémi Duraffort
>>>>> LAVA Architect
>>>>> Linaro
>>>>>
>>>>
--
Rémi Duraffort
LAVA Architect
Linaro
Hello, all,
Recently I heard from somebody said, lava will drop stretch support from 2020.01 release, I didn't find related information, is it true?
I also want to know if I remain on stretch, but still use 2019.12 release just for slave, but maybe later just upgrade master to for example 2020.06 release on buster.
Will 2019.12 slave on stretch be compatible with 2020.06(Just a example version) master on buster? Will you promise it?
Best Regards,
David
Hello, all,
Recently I heard from somebody said, lava will drop stretch support from 2020.01 release, I didn't find related information, is it true?
I also want to know if I remain on stretch, but still use 2019.12 release just for slave, but maybe later just upgrade master to for example 2020.06 release on buster.
Will 2019.12 slave on stretch be compatible with 2020.06(Just a example version) master on buster? Will you promise it?
Best Regards,
David
Hi, there,
We have one job to do some stress test, the final log is about 270MB.
We use `lavacli -i production jobs logs --raw 30686` to fetch the log, it gives me next:
```
$ time lavacli -i production jobs logs --raw 30686
/usr/lib/python3/dist-packages/lavacli/__init__.py:101: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
config = yaml.load(f_conf.read())
Unable to call 'jobs.logs': <ProtocolError for http://larry.shen:xxx@xxx.nxp.com/RPC2: 500 ('Connection broken: IncompleteRead(0 bytes read)', IncompleteRead(0 bytes read))>
real 0m39.006s
user 0m0.989s
sys 0m0.191s
```
I check the gunicorn log, it give me:
[2020-01-08 08:11:12 +0000] [188] [CRITICAL] WORKER TIMEOUT (pid:11506)
Any suggestion?
