Re: About tracing clues

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Hello Steve,

On Sat, 20 Aug 2022 at 14:51, Prasad Pandit <ppandit@xxxxxxxxxx> wrote:
>>   # trace-cmd agent

* For me `trace-cmd agent` in the guest shows =>  listening on @4294967295:823

>>   # trace-cmd record --poll -M 1E -e all --proxy 2 --name host -e kvm -e sched -e irq /home/test/rt-tests/oslat --cpu-list 1-4 --rtprio 1 --duration 12h -T 30

* Running above command with --proxy 4294967295:823 throws an error =>
guest 4294967295 not found

* Looking through 'trace-record.c' source IIUC,
   -  The long type CID(=4294967295) causes atoi(3) calls in
parse_guest_name() to return -1
       so 'cid' is set to -1.
   - Later in parse_guest_name() guest->name is returned without
setting '*res' addrinfo parameter.
          guest = trace_get_guest(*cid, gname);
          if (guest) {
              *cid = guest->cid;
              return guest->name;     <==

* ie. cid==-1 and result==NULL leads to the above error via  =>
die("guest %s not found", optarg);

* Instead of 'return guest->name', if we set 'gname = guest->name',
parse_guest_name() sets the '*res' addrinfo struct and returns gname.
  It helps to avoid above error, but then shows another error below
       ==>  Failed to connect to host host:823

* If I run above command with --name 4294967295, then it breaks with
      ==> Failed to connect to host 4294967295:823

* Not sure if the long type CID value is erroneous OR
parse_guest_name() function needs some fixing OR maybe both. Wdyt...?

Thank you.
  - P J P

[Index of Archives]     [Linux USB Development]     [Linux USB Development]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux