lava-users

lava-users@lists.lavasoftware.org

3 participants
925 discussions

Missing dependency for LAVA 2023.01 on Debian Bullseye

by tim.jaacks＠seco.com

Hey everyone, in the announcement of LAVA 2023.01 it says: > The support for Debian Buster has been dropped as Debian Buster does > not provide support for the latest pyyaml versions. So I updated my LAVA machines from buster to bullseye. Now I have the problem that I cannot install lava-dispatcher anymore now due to the following error: The following packages have unmet dependencies: libbpf0 : Depends: linux-libc-dev (>= 5.14) but 5.10.162-1 is to be installed libbpf0 seems to come from the LAVA repository: libbpf0: Installed: (none) Candidate: 1:0.5.0-1~bpo11+1~lava1 Version table: 1:0.5.0-1~bpo11+1~lava1 500 500 http://apt.lavasoftware.org/release bullseye/main amd64 Packages 1:0.3-2 500 500 http://ftp.de.debian.org/debian bullseye/main amd64 Packages While linux-libc-dev is part of the standard debian repositories: linux-libc-dev: Installed: 5.10.162-1 Candidate: 5.10.162-1 Version table: *** 5.10.162-1 500 500 http://security.debian.org/debian-security bullseye-security/main amd64 Packages 100 /var/lib/dpkg/status 5.10.158-2 500 500 http://ftp.de.debian.org/debian bullseye/main amd64 Packages This is the LAVA repository I am using: deb http://apt.lavasoftware.org/release bullseye main Is this a known issue? How do I correctly install LAVA 2023.01 on Debian Bullseye? Thanks in advance and kind regards, Tim -- Tim Jaacks SOFTWARE DEVELOPER SECO Northern Europe GmbH Schlachthofstrasse 20 21079 Hamburg Germany T: +49 40 791899-183 E: tim.jaacks(a)seco.com Register: Amtsgericht Hamburg, HRB 148893 Represented by: Dirk Finstel, Marc-Michael Braun, Massimo Mauri

2 years, 4 months

Deploying LAVA packages on Debian11

by Koturappa, Hemanth

Hello Lava Users, On deploying the latest LAVA release(LAVA 2022.11.1) packages after building the packages on Debian11 Host , we are facing issue with deploying lava-dispatcher-host package on Debian 11 host(11.6). On checking further we noticed https://git.lavasoftware.org/lava/lava/-/blob/master/debian/control , lava-dispatcher-host package depends on base-files (<< 11.1) but base-files on system is 11.1+deb11u6. To support Deploying on latest Debian bullseye release should this be updated or are we missing something. $ sudo dpkg -i lava-dispatcher-host_2022.11.1+11+bullseye_all.deb (Reading database ... 283093 files and directories currently installed.) Preparing to unpack lava-dispatcher-host_2022.11.1+11+bullseye_all.deb ... Unpacking lava-dispatcher-host (2022.11.1+11+bullseye) over (2021.10+10+buster) ... dpkg: dependency problems prevent configuration of lava-dispatcher-host: lava-dispatcher-host depends on base-files (<< 11.1) | python3-bpfcc (>= 0.21); however: Version of base-files on system is 11.1+deb11u6. Package python3-bpfcc is not installed. lava-dispatcher-host depends on base-files (<< 11.1) | linux-headers-amd64 | linux-headers-arm64 | linux-headers-generic; however: Version of base-files on system is 11.1+deb11u6. .... Thanks, Hemanth.

2 years, 5 months

Robot Framework in LAVA:

by pawanKumar

Hi All, I'm looking to automate overall testing process and post the test results in to JIRA instead of going to Lava CI. Is there any way that I can use robot framework to run the tests on Lava and so robot framework produces results in XML file that can be used to post into issue tracker. Any suggestions would be helpful Thanks, Pavan

2 years, 6 months

Query on Generating Overlay:

by pawanKumar

Hi Team, Good Morning! How to generate overlay and run the test using 7z image compression format in LAVA. Best Regards, Pavan Kumar

2 years, 7 months

How to Disable login prompt after reboot:

by pawanKumar

Hello Team, Good Day to All! We are setting up a new device into LAVA Automation with the following requirements. Flash panel to R4 image Copy delta to R5 Deploy R5 reboot Make sure the panel boots to R5 The Test definition i'm using is as follows: actions: - deploy: to: flasher images: package: url: https://artifactory.softwaretools.com/artifactory/mfgtools-***-0v3 - boot: timeout: minutes: 15 commands: - boot method: u-boot prompts: - 'root@hon-grip' auto_login: login_prompt: 'login: ' username: root password_prompt: 'Password:' password: root login_commands: - coredump --enable - sysinfo - ifconfig - networkctl status - wget http://192.100.**.**/oslat - ostree static-delta apply-offline /home/root/oslat - ostree admin deploy 35b3297cf3e4bc59d2a21e2ae9f7a02ef3f7a940e37389a7e9ae66a610c60b7 - reboot After reboot command is executed, the panel again prompts for login and password, whereas I cannot declare auto_login for the second time. Please let me know how to disable auto login after the reboot (for second time login) Best Regards *Pavan Kumar*

2 years, 7 months

lava-test-shell timeout : How to run test-suites using lava-test-case/shell/runner where DUT is non-IP or no NFS support

by Nagendra Singamsetti

Hi Team, I had a Query which is particularly to use lava-test-shell or other binaries like lava-test-runner. My board is booted with Linux and It has a POSIX environment but it doesn't support either ssh/nfs due to the low memory footprint available and the ethernet driver not fully functional. To test/run my test-suite drivers How can I use lava-test-runner/ lava-test-shell ? Is it possible to test our suite using lava-test-shell/runner where DUT doesn't have the ethernet/nfs support. I am getting lava-test-shell timeout on the DUT console whereas Lava-worker had all the binaries available by lava-overlay method. Please find the attached test job definition/lava-job log files for your reference. Kindly let me know the solution.

2 years, 8 months

Sample job for run android cts?

by cnspring2002

Hi teams, I wonder if you could share an android cts lava job define to me, is it in https://validation.linaro.org/? I want to have a reference, thanks!

2 years, 8 months

Job does not exiting even after the timeout

by koti

Hi. It looks like I am facing the same problem and the job does not exist even after the timeout. . I guess there might be communication gap between the Dispatcher and server. Dispatcher log screenshot: (/var/log/lava-dispatcher/lava-worker.log) ###################### [image: image.png] any solution to resolve this? Regards, Koti On Sat, 26 Feb 2022 at 05:30, <lava-users-request(a)lists.lavasoftware.org> wrote: > Send Lava-users mailing list submissions to > lava-users(a)lists.lavasoftware.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > lava-users-request(a)lists.lavasoftware.org > > You can reach the person managing the list at > lava-users-owner(a)lists.lavasoftware.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Lava-users digest..." > > Today's Topics: > > 1. Re: Job is not exiting after the timeout (P T, Sarath) > 2. Re: Job is not exiting after the timeout (Antonio Terceiro) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 25 Feb 2022 05:10:58 +0000 > From: "P T, Sarath" <Sarath_PT(a)mentor.com> > Subject: [Lava-users] Re: Job is not exiting after the timeout > To: Antonio Terceiro <antonio.terceiro(a)linaro.org> > Cc: "lava-users(a)lists.lavasoftware.org" > <lava-users(a)lists.lavasoftware.org> > Message-ID: > <7b18ad8ebf54460e935b147659d2da99(a)svr-orw-mbx-01.mgc.mentorg.com> > Content-Type: text/plain; charset="us-ascii" > > Hi Antonio, > > These are the logs for the server connection: > > Worker side log ( /var/log/lava-dispatcher/lava-worker.log ) > ------------------------------------------------------------ > > 2022-02-24 05:56:58,718 INFO [3834] FINISHED => server > 2022-02-24 05:57:01,233 ERROR [3834] -> server error: code 404 > 2022-02-24 05:57:01,233 DEBUG [3834] --> {"error": "Unknown job '3834'"} > 2022-02-24 05:57:18,246 INFO PING => server > 2022-02-24 05:57:18,729 INFO [3834] FINISHED => server > 2022-02-24 05:57:18,965 ERROR [3834] -> server error: code 503 > 2022-02-24 05:57:18,965 DEBUG [3834] --> ('Connection aborted.', > RemoteDisconnected('Remote end closed connection without response')) > 2022-02-24 05:57:38,248 INFO PING => server > 2022-02-24 05:57:38,737 INFO [3834] FINISHED => server > 2022-02-24 05:57:38,977 ERROR [3834] -> server error: code 503 > 2022-02-24 05:57:38,977 DEBUG [3834] --> ('Connection aborted.', > RemoteDisconnected('Remote end closed connection without response')) > 2022-02-24 05:57:58,250 INFO PING => server > 2022-02-24 05:57:58,731 INFO [3834] FINISHED => server > 2022-02-24 05:57:58,968 ERROR [3834] -> server error: code 503 > 2022-02-24 05:57:58,969 DEBUG [3834] --> ('Connection aborted.', > RemoteDisconnected('Remote end closed connection without response')) > 2022-02-24 05:58:18,252 INFO PING => server > 2022-02-24 05:58:18,745 INFO [3834] FINISHED => server > 2022-02-24 05:58:21,739 ERROR [3834] -> server error: code 502 > 2022-02-24 05:58:21,740 DEBUG [3834] --> <!DOCTYPE HTML PUBLIC > "-//IETF//DTD HTML 2.0//EN"> > <html><head> > <title>502 Bad Gateway</title> > </head><body> > <h1>Bad Gateway</h1> > <p>The proxy server received an invalid > response from an upstream server.<br /> > </p> > <hr> > <address>Apache/2.4.38 (Debian) Server at 132.186.71.148 Port 80</address> > </body></html> > > > 2022-02-24 05:58:38,253 INFO PING => server > 2022-02-24 05:58:38,735 INFO [3834] FINISHED => server > 2022-02-24 05:58:38,971 ERROR [3834] -> server error: code 503 > 2022-02-24 05:58:38,971 DEBUG [3834] --> ('Connection aborted.', > RemoteDisconnected('Remote end closed connection without response')) > 2022-02-24 05:58:58,254 INFO PING => server > 2022-02-24 05:58:58,738 INFO [3834] FINISHED => server > 2022-02-24 05:58:58,973 ERROR [3834] -> server error: code 503 > 2022-02-24 05:58:58,973 DEBUG [3834] --> ('Connection aborted.', > RemoteDisconnected('Remote end closed connection without response')) > 2022-02-24 05:59:18,256 INFO PING => server > > > Server side log ( /var/log/apache2/lava-server.log ) > ------------------------------------------------------ > > 134.86.62.69 - - [24/Feb/2022:19:39:46 +0530] "GET /ws/ HTTP/1.1" 500 804 > "-" "lava-worker 2021.10" > ::1 - - [24/Feb/2022:19:39:46 +0530] "POST /scheduler/internal/v1/workers/ > HTTP/1.1" 400 68338 "-" "lava-worker 2021.10" > [Thu Feb 24 19:39:46.711251 2022] [proxy:warn] [pid 9108:tid > 140199652738816] [client 134.86.62.139:42968] AH01144: No protocol > handler was valid for the URL /ws/ (scheme 'ws'). If you are using a DSO > version of mod_proxy, make sure the proxy submodules are included in the > configuration using LoadModule. > 134.86.62.139 - - [24/Feb/2022:19:39:46 +0530] "GET /ws/ HTTP/1.1" 500 804 > "-" "lava-worker 2021.10" > [Thu Feb 24 19:39:47.054716 2022] [proxy:warn] [pid 9151:tid > 140199132653312] [client 134.86.61.20:43200] AH01144: No protocol handler > was valid for the URL /ws/ (scheme 'ws'). If you are using a DSO version of > mod_proxy, make sure the proxy submodules are included in the configuration > using LoadModule. > 134.86.61.20 - - [24/Feb/2022:19:39:47 +0530] "GET /ws/ HTTP/1.1" 500 804 > "-" "lava-worker 2021.10" > [Thu Feb 24 19:39:47.919417 2022] [proxy:warn] [pid 9108:tid > 140200256718592] [client 134.86.62.69:45566] AH01144: No protocol handler > was valid for the URL /ws/ (scheme 'ws'). If you are using a DSO version of > mod_proxy, make sure the proxy submodules are included in the configuration > using LoadModule. > 134.86.62.69 - - [24/Feb/2022:19:39:47 +0530] "GET /ws/ HTTP/1.1" 500 804 > "-" "lava-worker 2021.10" > [Thu Feb 24 19:39:48.202295 2022] [proxy:warn] [pid 9151:tid > 140199661131520] [client 134.86.62.139:42970] AH01144: No protocol > handler was valid for the URL /ws/ (scheme 'ws'). If you are using a DSO > version of mod_proxy, make sure the proxy submodules are included in the > configuration using LoadModule. > 134.86.62.139 - - [24/Feb/2022:19:39:48 +0530] "GET /ws/ HTTP/1.1" 500 804 > "-" "lava-worker 2021.10" > [Thu Feb 24 19:39:48.515377 2022] [proxy:warn] [pid 9108:tid > 140200655480576] [client 134.86.61.20:43202] AH01144: No protocol handler > was valid for the URL /ws/ (scheme 'ws'). If you are using a DSO version of > mod_proxy, make sure the proxy submodules are included in the configuration > using LoadModule. > 134.86.61.20 - - [24/Feb/2022:19:39:48 +0530] "GET /ws/ HTTP/1.1" 500 804 > "-" "lava-worker 2021.10" > > > Server side log ( /var/log/lava-server/gunicorn.log ) > -------------------------------------------------------- > > [2022-02-24 14:02:17 +0000] [704] [DEBUG] GET > /scheduler/internal/v1/workers/slll-worker-testing/ > [2022-02-24 14:02:18 +0000] [704] [DEBUG] POST > /scheduler/internal/v1/workers/ > [2022-02-24 14:02:19 +0000] [704] [DEBUG] GET > /scheduler/internal/v1/workers/bng-test-worker/ > [2022-02-24 14:02:20 +0000] [722] [DEBUG] GET > /scheduler/internal/v1/workers/Test-worker/ > [2022-02-24 14:02:20 +0000] [704] [DEBUG] POST > /scheduler/internal/v1/jobs/3879/ > [2022-02-24 14:02:23 +0000] [722] [DEBUG] POST > /scheduler/internal/v1/workers/ > [2022-02-24 14:02:28 +0000] [721] [DEBUG] POST > /scheduler/internal/v1/workers/ > [2022-02-24 14:02:29 +0000] [704] [DEBUG] GET > /scheduler/job/3966/job_status > [2022-02-24 14:02:29 +0000] [721] [DEBUG] GET > /scheduler/job/3966/log_pipeline_incremental > [2022-02-24 14:02:33 +0000] [704] [DEBUG] POST > /scheduler/internal/v1/workers/ > [2022-02-24 14:02:37 +0000] [704] [DEBUG] GET > /scheduler/internal/v1/workers/slll-worker-testing/ > [2022-02-24 14:02:38 +0000] [720] [DEBUG] POST > /scheduler/internal/v1/workers/ > [2022-02-24 14:02:38 +0000] [704] [DEBUG] POST > /scheduler/internal/v1/jobs/3834/ > [2022-02-24 14:02:39 +0000] [704] [DEBUG] GET > /scheduler/internal/v1/workers/bng-test-worker/ > [2022-02-24 14:02:40 +0000] [704] [DEBUG] GET > /scheduler/internal/v1/workers/Test-worker/ > [2022-02-24 14:02:43 +0000] [722] [DEBUG] POST > /scheduler/internal/v1/workers/ > [2022-02-24 14:02:48 +0000] [722] [DEBUG] POST > /scheduler/internal/v1/workers/ > > > Regards > Sarath P T > > -----Original Message----- > From: Antonio Terceiro [mailto:antonio.terceiro@linaro.org] > Sent: 24 February 2022 18:37 > To: P T, Sarath <Sarath_PT(a)mentor.com> > Cc: lava-users(a)lists.lavasoftware.org > Subject: Re: [Lava-users] Re: Job is not exiting after the timeout > > On Thu, Feb 24, 2022 at 09:40:22AM +0000, P T, Sarath wrote: > > Hi Team, > > > > I could able to find the root cause of the issue just giving my > observation : > > > > 1. I deleted a `cancelling` job with the ID 3834 from the GUI. > > 2. And for the next test run its giving an error log under worker like > this . > > > > 2022-02-24 01:18:57,502 ERROR [3834] -> server error: code 503 > > 2022-02-24 01:18:57,502 DEBUG [3834] --> ('Connection aborted.', > RemoteDisconnected('Remote end closed connection without response')) > > 2022-02-24 01:19:16,795 INFO PING => server > > 2022-02-24 01:19:17,268 INFO [3834] FINISHED => server > > 2022-02-24 01:19:18,666 ERROR [3834] -> server error: code 404 > > 2022-02-24 01:19:18,666 DEBUG [3834] --> {"error": "Unknown job > '3834'"} > > 2022-02-24 01:19:36,797 INFO PING => server > > 2022-02-24 01:19:37,274 INFO [3834] FINISHED => server > > 2022-02-24 01:19:37,509 ERROR [3834] -> server error: code 503 > > 2022-02-24 01:19:37,509 DEBUG [3834] --> ('Connection aborted.', > RemoteDisconnected('Remote end closed connection without response')) > > Is the server receiving the connections normally? If you look at the > server logs (apache and/or gunicorn) there should be corresponding error > messages in there telling you what went wrong. > > ------------------------------ > > Message: 2 > Date: Fri, 25 Feb 2022 10:37:00 -0300 > From: Antonio Terceiro <antonio.terceiro(a)linaro.org> > Subject: [Lava-users] Re: Job is not exiting after the timeout > To: "P T, Sarath" <Sarath_PT(a)mentor.com> > Cc: "lava-users(a)lists.lavasoftware.org" > <lava-users(a)lists.lavasoftware.org> > Message-ID: <YhjbfBGnnyO67EIY(a)linaro.org> > Content-Type: multipart/signed; micalg=pgp-sha256; > protocol="application/pgp-signature"; boundary="U431ChLU/1f+Fa7u" > > On Fri, Feb 25, 2022 at 05:10:58AM +0000, P T, Sarath wrote: > > Server side log ( /var/log/apache2/lava-server.log ) > > ------------------------------------------------------ > > > > 134.86.62.69 - - [24/Feb/2022:19:39:46 +0530] "GET /ws/ HTTP/1.1" 500 > 804 "-" "lava-worker 2021.10" > > ::1 - - [24/Feb/2022:19:39:46 +0530] "POST > /scheduler/internal/v1/workers/ HTTP/1.1" 400 68338 "-" "lava-worker > 2021.10" > > [Thu Feb 24 19:39:46.711251 2022] [proxy:warn] [pid 9108:tid > 140199652738816] [client 134.86.62.139:42968] AH01144: No protocol > handler was valid for the URL /ws/ (scheme 'ws'). If you are using a DSO > version of mod_proxy, make sure the proxy submodules are included in the > configuration using LoadModule. > > 134.86.62.139 - - [24/Feb/2022:19:39:46 +0530] "GET /ws/ HTTP/1.1" 500 > 804 "-" "lava-worker 2021.10" > > [Thu Feb 24 19:39:47.054716 2022] [proxy:warn] [pid 9151:tid > 140199132653312] [client 134.86.61.20:43200] AH01144: No protocol handler > was valid for the URL /ws/ (scheme 'ws'). If you are using a DSO version of > mod_proxy, make sure the proxy submodules are included in the configuration > using LoadModule. > > 134.86.61.20 - - [24/Feb/2022:19:39:47 +0530] "GET /ws/ HTTP/1.1" 500 > 804 "-" "lava-worker 2021.10" > > [Thu Feb 24 19:39:47.919417 2022] [proxy:warn] [pid 9108:tid > 140200256718592] [client 134.86.62.69:45566] AH01144: No protocol handler > was valid for the URL /ws/ (scheme 'ws'). If you are using a DSO version of > mod_proxy, make sure the proxy submodules are included in the configuration > using LoadModule. > > 134.86.62.69 - - [24/Feb/2022:19:39:47 +0530] "GET /ws/ HTTP/1.1" 500 > 804 "-" "lava-worker 2021.10" > > [Thu Feb 24 19:39:48.202295 2022] [proxy:warn] [pid 9151:tid > 140199661131520] [client 134.86.62.139:42970] AH01144: No protocol > handler was valid for the URL /ws/ (scheme 'ws'). If you are using a DSO > version of mod_proxy, make sure the proxy submodules are included in the > configuration using LoadModule. > > 134.86.62.139 - - [24/Feb/2022:19:39:48 +0530] "GET /ws/ HTTP/1.1" 500 > 804 "-" "lava-worker 2021.10" > > [Thu Feb 24 19:39:48.515377 2022] [proxy:warn] [pid 9108:tid > 140200655480576] [client 134.86.61.20:43202] AH01144: No protocol handler > was valid for the URL /ws/ (scheme 'ws'). If you are using a DSO version of > mod_proxy, make sure the proxy submodules are included in the configuration > using LoadModule. > > 134.86.61.20 - - [24/Feb/2022:19:39:48 +0530] "GET /ws/ HTTP/1.1" 500 > 804 "-" "lava-worker 2021.10" > > Your apache is not configured correctly, you are probably missing > enabling mod_proxy and/or mod_proxy_http. See > > https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html#pr… >

2 years, 8 months

Lava Socket connection error:

by pawanKumar

Hi Team, I'm running Multi node testing by connecting two devices of the same type. But it results in a socket connection error. I check the lava-coordinator conf file in server and dispatcher, both contain the same configuration. Error log is as follows: ava-dispatcher, installed at version: 2022.06 <http://158.100.69.109/scheduler/job/506.0#L1>start: 0 validate <http://158.100.69.109/scheduler/job/506.0#L2>Start time: 2022-09-28 09:25:47.384539+00:00 (UTC) <http://158.100.69.109/scheduler/job/506.0#L3>This MultiNode test job contains top level actions, in order, of: deploy, boot, test, finalize <http://158.100.69.109/scheduler/job/506.0#L4>Validating that file:///home/lava/mfgtools-01.006572-082-aio-01939v3.7z exists <http://158.100.69.109/scheduler/job/506.0#L5>WARNING: Using boot commands supplied in the job definition, NOT the LAVA device configuration <http://158.100.69.109/scheduler/job/506.0#L6>validate duration: 0.00 <http://158.100.69.109/scheduler/job/506.0#results_4678>case: validate case_id: 4678 definition: lava result: pass <http://158.100.69.109/results/testcase/4678> <http://158.100.69.109/scheduler/job/506.0#L8>Initialising group c223cee3-3ef3-4a2d-9c01-7822951ac651 <http://158.100.69.109/scheduler/job/506.0#L9>Connecting to LAVA Coordinator on localhost:3079 timeout=90 seconds. <http://158.100.69.109/scheduler/job/506.0#L10>socket error on connect: 111 localhost 3079 <http://158.100.69.109/scheduler/job/506.0#L11>socket error on connect: 111 localhost 3079 <http://158.100.69.109/scheduler/job/506.0#L12>socket error on connect: 111 localhost 3079 <http://158.100.69.109/scheduler/job/506.0#L13>socket error on connect: 111 localhost 3079 Please suggest an approach to resolve this issue. Thanks.

2 years, 8 months

Enquire if frequent bpf action will cause any performance drop?

by Larry Shen

In fact, I didn't see any performance drop because I'm still trying it in a small and initial phase, just want to eliminate any risk when move to debian11, you know if issue happen in production environment, it maybe really not easy to debug. Back to the question: in lava, if we use debian11 which default cgroupV2 enabled, then when use docker-test-shell, lava will attach a custom BPF Device program to container to replace the default one in docker. Everything looks fine, just I observed if I use "adb devices" in container, then the trace_pipe will be flushed with next: ``` device poll-7289 [001] d... 103054.767620: bpf_trace_printk: Device access: major = 189, minor = 261 device poll-7289 [001] d... 103055.767851: bpf_trace_printk: Device access: major = 189, minor = 261 device poll-7289 [001] d... 103056.768117: bpf_trace_printk: Device access: major = 189, minor = 261 device poll-7289 [001] d... 103057.768354: bpf_trace_printk: Device access: major = 189, minor = 261 device poll-7289 [001] d... 103058.768590: bpf_trace_printk: Device access: major = 189, minor = 261 device poll-7289 [001] d... 103059.768819: bpf_trace_printk: Device access: major = 189, minor = 261 device poll-7289 [001] d... 103060.769053: bpf_trace_printk: Device access: major = 189, minor = 261 ``` Which means that bpf function frequently be called (interval less than 1 second) On the other hand, if I do next then the BPF prog unregistered from linux kernel, but looks every adb devices still works. ``` /sys/fs/cgroup/system.slice/docker-a9354f54a8c6a56932e15b4d577432abf86c897630d5e94da442474e938bf875.scope 78 device multi lava_docker_dev $ bpftool cgroup detach /sys/fs/cgroup/system.slice/docker-a9354f54a8c6a56932e15b4d577432abf86c897630d5e94da442474e938bf875.scope device id 78 ``` So, I just want to confirm have you guys noticed this behavior, and you confirm this behavior is ok? (To be honestly, I'm not sure BPF performance if it's frequently be called, so this is just a enquire) Or, we have better methods handle it in lava? I need your confirm to decide if I need to downgrade to CGroupV1 when I migrate, thanks! Regards, Larry

2 years, 8 months

← Newer
1
...
7
8
9
10
11
12
13
...
93
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users