From: Jan Kiszka [mailto:firstname.lastname@example.org]
Sent: 10 March 2020 00:23
To: Pavel Machek <email@example.com>; Bhola, Bikram <Bikram_Bhola@mentor.com>; Quirin Gylstorff <firstname.lastname@example.org>
Subject: Re: I need de0-nano testing for -rt release was Re: [cip-dev] 4.19.106-cip21-rt8 problems on de0-nano
On 09.03.20 11:21, Pavel Machek wrote:
Yes... I don't need that target, but I need de0-nano... and it did not
The logs read like the targets are not (always) coming up, e.g.
And something went seriously wrong after these tests. I submitted
I managed to narrow the bad commit to the -rt tree, between:
I pushed candidate for -cip-rt, but it seems to fail on de0-nano It is pipeline
board. Code under testing is at:
I'll reuse the branch for more testing.
OK 122904930 pick 69aa73357e6a rcu: Don't allow to change
rcu_normal_after_boot on RT pick 849ef8789077 pci/switchtec: fix
stream_open.cocci warnings pick ad8a5e8279c4 sched/core: Drop a
preempt_disable_rt() statement pick 966f066d96cb timers: Redo the
notification of canceling timers on -RT pick 0393fd5a4f9a Revert "futex: Ensure lock/unlock symetry versus pi_lock and hash bucket lock"
pick 84eb0b64a27a Revert "futex: Fix bug on when a requeued RT task times out"
pick fcc893280f4e Revert "rtmutex: Handle the various new futex race conditions"
pick 2eac93cf9d16 Revert "futex: workaround migrate_disable/enable in different context"
pick 9b8964629f4f futex: Make the futex_hash_bucket lock raw pick
cc1812bf198b futex: Delay deallocation of pi_state
pick f5e115c43100 mm/zswap: Do not disable preemption in pick e0d0d09a08ad revert-aio
pick a0a40bfb4300 fs/aio: simple simple work pick 0fae581d8c5e
revert-thermal pick c0d95b4a8a1b thermal: Defer thermal wakups to
threads pick 700fbb4afb6e revert-block pick 4cda50ff12cf block:
blk-mq: move blk_queue_usage_counter_release() into process context
pick 9e982f55745b workqueue: rework pick c0db53dc3bf4 i2c: exynos5:
Remove IRQF_ONESHOT pick 1f160d170203 i2c: hix5hd2: Remove
IRQF_ONESHOT BAD 122882826 eae5a7cab722 sched/deadline: Ensure
inactive_timer runs in hardirq context
same tree twice, and got different results.
First this -- de0-nano succeeds:
Now this -- de0-nano fails (and ipc227e is unfinished for long time):
I'll need some help here.
work last time I checked.
Bikram, could someone on your side check the board status in the Mentor lab? Thanks!
On a related note... it would be good to somehow show difference
between "kernel test failure" and "target failure".
If we see bootloader in the logs, and then test fails/timeouts =>
"kernel test failure", I need to solve it.
If we don't get messages from the bootloader => "target failure",
someone needs to check the power relays or something...
I'm not happy about the parsability of those LAVA logs either, but I have no idea if/how that can be improved best. Maybe Quirin has some idea based on his work with them.
Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux