Hello
I got the following crash with 2018.11 on debian stretch
dpkg -l|grep lava
ii lava
2018.11-1~bpo9+1 all Linaro Automated
Validation Architecture metapackage
ii lava-common
2018.11-1~bpo9+1 all Linaro Automated
Validation Architecture common
ii lava-coordinator
0.1.7-1 all LAVA Coordinator
daemon
ii lava-dev
2018.11-1~bpo9+1 all Linaro Automated
Validation Architecture developer support
ii lava-dispatcher
2018.11-1~bpo9+1 amd64 Linaro Automated
Validation Architecture dispatcher
ii lava-server
2018.11-1~bpo9+1 all Linaro Automated
Validation Architecture server
ii lava-server-doc
2018.11-1~bpo9+1 all Linaro Automated
Validation Architecture documentation
ii lavacli
0.9.3-1~bpo9+1 all LAVA XML-RPC command
line interface
ii lavapdu-client
0.0.5-1 all LAVA PDU client
ii lavapdu-daemon
0.0.5-1 all LAVA PDU control
daemon
2018-12-04 14:14:40,187 ERROR [EXIT] Unknown exception raised, leaving!
2018-12-04 14:14:40,187 ERROR string index out of range
Traceback (most recent call last):
File
"/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py",
line 193, in handle
self.main_loop()
File
"/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py",
line 253, in main_loop
while self.wait_for_messages(False):
File
"/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py",
line 287, in wait_for_messages
self.logging_socket()
File
"/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py",
line 433, in logging_socket
job.save()
File
"/usr/lib/python3/dist-packages/django_restricted_resource/models.py", line
71, in save
return super(RestrictedResource, self).save(*args, **kwargs)
File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 796,
in save
force_update=force_update, update_fields=update_fields)
File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 820,
in save_base
update_fields=update_fields)
File "/usr/lib/python3/dist-packages/django/dispatch/dispatcher.py", line
191, in send
response = receiver(signal=self, sender=sender, **named)
File "/usr/lib/python3/dist-packages/lava_scheduler_app/signals.py", line
139, in testjob_notifications
send_notifications(job)
File
"/usr/lib/python3/dist-packages/lava_scheduler_app/notifications.py", line
305, in send_notifications
title, body, settings.SERVER_EMAIL, [recipient.email_address]
File "/usr/lib/python3/dist-packages/django/core/mail/__init__.py", line
62, in send_mail
return mail.send()
File "/usr/lib/python3/dist-packages/django/core/mail/message.py", line
342, in send
return self.get_connection(fail_silently).send_messages([self])
File "/usr/lib/python3/dist-packages/django/core/mail/backends/smtp.py",
line 107, in send_messages
sent = self._send(message)
File "/usr/lib/python3/dist-packages/django/core/mail/backends/smtp.py",
line 120, in _send
recipients = [sanitize_address(addr, encoding) for addr in
email_message.recipients()]
File "/usr/lib/python3/dist-packages/django/core/mail/backends/smtp.py",
line 120, in <listcomp>
recipients = [sanitize_address(addr, encoding) for addr in
email_message.recipients()]
File "/usr/lib/python3/dist-packages/django/core/mail/message.py", line
161, in sanitize_address
address = Address(nm, addr_spec=addr)
File "/usr/lib/python3.5/email/headerregistry.py", line 42, in __init__
a_s, rest = parser.get_addr_spec(addr_spec)
File "/usr/lib/python3.5/email/_header_value_parser.py", line 1988, in
get_addr_spec
token, value = get_local_part(value)
File "/usr/lib/python3.5/email/_header_value_parser.py", line 1800, in
get_local_part
if value[0] in CFWS_LEADER:
IndexError: string index out of range
2018-12-04 14:14:40,211 INFO [EXIT] Disconnect logging socket and
process messages
2018-12-04 14:14:40,211 DEBUG [EXIT] unbinding from 'tcp://0.0.0.0:5555'
2018-12-04 14:14:50,221 INFO [EXIT] Closing the logging socket: the
queue is empty
Regards
Hi,
I'm trying to experiment with 'interactive' test shell. The docs are here:
https://master.lavasoftware.org/static/docs/v2/actions-test.html#index-1
As I understand the feature should work in the following way (the docs
aren't very clear):
1. wait for one of the prompts
2. send command
3. match the result to regex (pass or fail)
However when I try it out, there is no wait for prompt. LAVA
immediately sends the command and adds value from prompts to list of
expressions to match. Is this correct? Example job:
https://staging.validation.linaro.org/scheduler/job/245886#L53
LAVA sends the command even before the board starts booting.
Any help is appreciated.
milosz
Hi everyone,
I’m facing an issue when U-Boot commands are sent one after another without waiting for a prompt. Obviously, device is not able to boot.
Excerpt from logs:
dhcp
=> dhcp
bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:56)
setenv serverip 172.17.1.189
setenv serverip 172.17.1.189
bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:56)
tftp 0x80000000 60/tftp-deploy-46_3_i9j/kernel/zImage-am335x-vcu.bin
tftp 0x80000000 60/tftp-deploy-46_3_i9j/kernel/zImage-am335x-vcu.bin
bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:56)
tftp 0x83000000 60/tftp-deploy-46_3_i9j/ramdisk/ramdisk.cpio.gz.uboot
tftp 0x83000000 60/tftp-deploy-46_3_i9j/ramdisk/ramdisk.cpio.gz.uboot
bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:55)
setenv initrd_size ${filesize}
setenv initrd_size ${filesize}
bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:55)
tftp 0x82000000 60/tftp-deploy-46_3_i9j/dtb/am335x-vcu-prod1.dtb
tftp 0x82000000 60/tftp-deploy-46_3_i9j/dtb/am335x-vcu-prod1.dtb
bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:55)
dhcp
dhcp
link up on port 0, speed 10, half duplex
BOOTP broadcast 1
setenv serverip 172.17.1.189
tftp 0x80000000 60/tftp-deploy-46_3_i9j/kernel/zImage-am335x-vcu.bin
BOOTP broadcast 2
tftp 0x83000000 60/tftp-deploy-46_3_i9j/ramdisk/ramdisk.cpio.gz.uboot
setenv initrd_size ${filesize}
tftp 0x82000000 60/tftp-deploy-46_3_i9j/dtb/am335x-vcu-prod1.dtb
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
Retry time exceeded
setenv bootargs 'console=ttyS2,115200n8 root=/dev/ram0 ti_cpsw.rx_packet_max=1526 ip=dhcp'
=> setenv bootargs 'console=ttyS2,115200n8 root=/dev/ram0 ti_cpsw.rx_packet_max=1526 ip=dhcp'
bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:50)
setenv bootargs 'console=ttyS2,115200n8 root=/dev/ram0 ti_cpsw.rx_packet_max=1526 ip=dhcp'
setenv bootargs 'console=ttyS2,115200n8 root=/dev/ram0 ti_cpsw.rx_packet_max=1526 ip=dhcp'
=>
bootz 0x80000000 0x83000000 0x82000000
=> bootz 0x80000000 0x83000000 0x82000000
bootloader-commands: Wait for prompt Starting kernel (timeout 00:04:50)
bootz 0x80000000 0x83000000 0x82000000
bootz 0x80000000 0x83000000 0x82000000
Bad Linux ARM zImage magic!
=>
Bad Linux ARM zImage magic!
As you see, all commands that were sent between `dhcp` command and until it was able to complete or fail are simply dropped.
Device type config:
{% extends 'base-uboot.jinja2' %}
{% set device_type = "vcu" %}
{% set console_device = 'ttyS2' %}
{% set baud_rate = 115200 %}
{% set interrupt_prompt = 'Press s to abort autoboot' %}
{% set interrupt_char = 's' %}
{% set bootloader_prompt = '=>' %}
{% set uboot_mkimage_arch = 'arm' %}
{% set bootz_kernel_addr = '0x80000000' %}
{% set bootz_ramdisk_addr = '0x83000000' %}
{% set bootz_dtb_addr = '0x82000000' %}
{% set extra_kernel_args = 'ti_cpsw.rx_packet_max=1526' %}
{% set kernel_start_message = 'Welcome to' %}
Device config:
{% extends 'vcu.jinja2' %}
{% set connection_command = 'telnet lava-disp-1.local 7000' %}
{% set power_on_command = 'relay-ctrl --relay 1 --state on' %}
{% set power_off_command = 'relay-ctrl --relay 1 --state off' %}
{% set hard_reset_command = 'relay-ctrl --relay 1 --toggle' %}
Boot action block from job definition:
- boot:
timeout:
minutes: 5
method: u-boot
commands: ramdisk
auto_login:
login_prompt: 'am335x-nmhw21 login: '
username: root
prompts:
- 'fct@am335x-nmhw21:~# '
Have I misconfigured something? What I’m missing? Thanks!
Best regards,
Andrejs Cainikovs.
Hello,
I have a LAVA job with long running test, so I put a timeout of 180
minutes in the test action itself[1].
However, but the job times out after 3989 seconds (~ 66 min)[2].
Looking closer at the "Timing" section of the job, I see that
lava-test-shell indeed has a timeout of ~3989 seconds, but I have no
idea where that number comes from. That's neither the 10 minutes in the
default "timeouts" section, nor the 180 minutes I put in the "test"
action.
Hmm, after almost pushing send on this, I now seeing that in the
"timeouts" sections, the whole job has a timeout of 70 minutes. So, I
assume that means an absolute max, even if one of the actions puts a
higher timeout?
So I guess this email now turns into a feature request rather than a bug
report.
Maybe LAVA should show a warning at the top of the job if any of the
actions has a timeout that's longer than the job timeout.
Kevin
[1] http://lava.baylibre.com:10080/scheduler/job/60374/definition#defline89
[2] http://lava.baylibre.com:10080/scheduler/job/60374#results_694663
Hi all,
When I try to run a test in lava , hacking session is not starting .
it is exiting by showing:
Using /lava-18
export SHELL=/bin/sh
# export SHELL=/bin/sh
/lava-18/bin/lava-test-runner /lava-18/0
/lava-18/bin/lava-test-runner /lava-18/0
Test shell timeout: 10s (minimum of the action and connection timeout)
export SHELL=/bin/sh
# /lava-18/bin/lava-test-runner /lava-18/0
Illegal instruction
<LAVA_TEST_RUNNER EXIT>
ok: lava_test_shell seems to have completed
end: 3.1 lava-test-shell (duration 00:00:01) [common]
end: 3 lava-test-retry (duration 00:00:01) [common]
start: 4 finalize (timeout 00:10:00) [common]
start: 4.1 power-off (timeout 00:00:05) [common]
end: 4.1 power-off (duration 00:00:00) [common]
my board linux has busybox init system
Please help me resolve the issue.
I've attached the job log below.
Thanks & Regards,
Manoj
Hi everyone,
I'm currently running CTS tests on imx8mq on Android 9.
My test job is based on Linaro's test definition located here :
https://git.linaro.org/qa/test-definitions.git/tree/automated/android/trade…
I had issue concerning the Java heap size, causing the test to abort and
skip a lot of tests.
So, I cloned this git tree and made modifications in "tradefed.sh" :
export _JAVA_OPTIONS="-Xmx350M"
replaced by :
export _JAVA_OPTIONS="-Xmx700M"
Since this modification, I'm able to run the full CTS 9.
So, I think you should consider modify this script, so other users
can benefit from it.
Best regards,
Axel
Hi all,
In Tftp deploy , How to give new set of u-boot bootargs by modifying device
configuration file?
I've tried by giving:
{% set base_kernel_args = "setenv bootargs console=serial1,115200
console=tty1 root=/dev/ram0 ip=dhcp rootwait" %}
But it is not taking these args.
Please suggest the modifications I have to make.
Thanks and regards,
Manoj
Hi Neil,
When LAVA start container from image for the first time(usually docker run ), if failed, it will bring a zoobie container.
And I found that LAVA did not check whether LAVA run is OK, and has no dead container cleanup method.(maybe I was wrong).
Does LAVA have some method to prevent it or do you think it is necessary?
Best Regards
Li Xiaoming
Hi all,
During send-reboot-commands phase in Health check on my raspberry pi 3
board,
LAVA is trying to match the keyword "The system is going down for reboot
NOW" after sending the reset command "reboot -n" to the DUT.
But the problem is when my board starts Reboot it shows "Started Show
Plymouth Reboot Screen .." , not the same as what LAVA want.
So is there any way to specify the keywords to what it should be("Started
Show Plymouth Reboot Screen" or something) in the corresponding DUTs jinja2
file?
I've attached the reslult log of my test below.
Regards,
Manoj
Hi everyone,
I have some troubles to log in my Web UI. I type the good password and
username and then the website sends me back to the home page. If I type a
wrong password, I get an error message. It does the same thing for all user
accounts. Tried to restart lava services, apache2 but it's still doing the
same thing. No error messages returned in logs.
Best regards,
Axel Le Bourhis
