From: John Harrison <john.c.harrison@intel.com>
To: "Souza, Jose" <jose.souza@intel.com>,
"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>
Cc: "De Marchi, Lucas" <lucas.demarchi@intel.com>
Subject: Re: [PATCH 3/3] drm/xe: Drop duplicated information about GT tile in devcoredump
Date: Thu, 23 Jan 2025 10:30:03 -0800 [thread overview]
Message-ID: <a8ac03e2-43c1-488d-a821-902aba7caa25@intel.com> (raw)
In-Reply-To: <124780756da7b9546d16158659a562408a23497e.camel@intel.com>
On 1/23/2025 10:24, Souza, Jose wrote:
> On Thu, 2025-01-23 at 10:18 -0800, John Harrison wrote:
>> On 1/23/2025 09:59, José Roberto de Souza wrote:
>>> The GT tile is already available but was added again in commit
>>> c28fd6c358db ("drm/xe/devcoredump: Improve section headings and add tile info"),
>>> so here deleting it.
>>>
>>> Here a devcoredump example with the duplicated information:
>>>
>>> **** Xe Device Coredump ****
>>> Reason: Timedout job - seqno=4294967170, lrc_seqno=4294967170, guc_id=13, flags=0x0
>>> kernel: 6.13.0-zeh-xe+
>>> module: xe
>>> Snapshot time: 1737573530.243521319
>>> Uptime: 2588.041930284
>>> Process: deqp-vk [8850]
>>> PCI ID: 0x64a0
>>> PCI revision: 0x04
>>> GT id: 0
>>> Tile: 0
>>> Type: main
>>> IP ver: 20.4.4
>>> CS reference clock: 19200000
>>> GT id: 1
>>> Tile: 0
>>> Type: media
>>> IP ver: 20.0.4
>>> CS reference clock: 19200000
>> This is an overview of all GTs/tiles in the device within the global
>> section.
>>
>>> **** GT #0 ****
>> This is a section header telling you that everything which follows is
>> inside GT0.
>>
>> It is not duplicated information. And if you remove it then you now have
>> the information of all GTs back to back with no indication of which GT
>> they actually belong to.
> Can't you get this information from Name + class + instance? if not that should be placed in one of the sections below.
No. I was trying to do that originally and determined it was impossible
to do reliably for all current and future platforms. Hence the section
header was added.
It is also much, much, much better to be explicit about debug
information than force people to guess based on heuristics or tribal
knowledge.
>
> So this should be placed in one of this sections:
No. It is not information within a context or within a hardware engine.
It is the reverse. All the following contexts, hardware engines, etc.
are within the GT.
And when you have multiple GTs in a single dump then you need a definite
delimiter to say that all the following is now in a different GT to what
came before.
John.
>
> GuC ID: 13
> Name: ccs13
> Class: 5
> Logical mask: 0x1
> Width: 1
> Ref: 2
> Timeout: 5000 (ms)
> Timeslice: 1000 (us)
> Preempt timeout: 640000 (us)
> HW Context Desc: 0x025e0000
> HW Ring address: 0x025dc000
> HW Indirect Ring State: 0x025e3000
> LRC Head: (memory) 152
> LRC Tail: (internal) 296, (memory) 296
> Ring start: (memory) 0x025dc000
> Start seqno: (memory) -126
> Seqno: (memory) -127
> Timestamp: 0x0000035e
> Job Timestamp: 0x0000035e
> Schedule State: 0x441
> Flags: 0x0
>
> **** HW Engines ****
> ccs0 (physical), logical instance=0
> Capture_source: GuC
> Coverage: full-capture
> Forcewake: domain 0x2, ref 1
> Reserved: no
> FORCEWAKE_GT: 0x00010000
> RCU_MODE: 0x00000001
> HWSTAM: 0xffffffff
> RING_HWS_PGA: 0x018db000
> RING_HEAD: 0x000000ec
> RING_TAIL: 0x00000128
> RING_CTL: 0x00003001
> RING_MI_MODE: 0x00001000
> RING_MODE: 0x00000008
> RING_ESR: 0x00000000
> RING_EMR: 0xffffffff
> RING_EIR: 0x00000000
> RING_IMR: 0x00000000
> IPEHR: 0x7a000a04
> RING_INSTDONE: 0xffdefffe
>
>> John.
>>
>>
>>> Tile: 0
>>>
>>> **** GuC Log ****
>>> ....
>>>
>>> Cc: John Harrison <John.C.Harrison@Intel.com>
>>> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
>>> Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
>>> ---
>>> drivers/gpu/drm/xe/xe_devcoredump.c | 3 ---
>>> 1 file changed, 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c b/drivers/gpu/drm/xe/xe_devcoredump.c
>>> index 1c86e6456d60f..2996945ffee39 100644
>>> --- a/drivers/gpu/drm/xe/xe_devcoredump.c
>>> +++ b/drivers/gpu/drm/xe/xe_devcoredump.c
>>> @@ -111,9 +111,6 @@ static ssize_t __xe_devcoredump_read(char *buffer, size_t count,
>>> drm_printf(&p, "Process: %s [%d]\n", ss->process_name, ss->pid);
>>> xe_device_snapshot_print(xe, &p);
>>>
>>> - drm_printf(&p, "\n**** GT #%d ****\n", ss->gt->info.id);
>>> - drm_printf(&p, "\tTile: %d\n", ss->gt->tile->id);
>>> -
>>> drm_puts(&p, "\n**** GuC Log ****\n");
>>> xe_guc_log_snapshot_print(ss->guc.log, &p);
>>> drm_puts(&p, "\n**** GuC CT ****\n");
next prev parent reply other threads:[~2025-01-23 18:30 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-23 17:59 [PATCH 0/3] Enable GuC log dump and minor fixes in devcoredump José Roberto de Souza
2025-01-23 17:59 ` [PATCH 1/3] drm/xe: Fix and re-enable xe_print_blob_ascii85() José Roberto de Souza
2025-01-23 18:20 ` John Harrison
2025-01-23 19:37 ` Lucas De Marchi
2025-01-23 17:59 ` [PATCH 2/3] drm/xe: Make GUC binaries dump consistent with other binaries in devcoredump José Roberto de Souza
2025-01-23 18:17 ` John Harrison
2025-01-23 18:45 ` Souza, Jose
2025-01-23 19:26 ` John Harrison
2025-01-23 19:12 ` Lucas De Marchi
2025-01-23 17:59 ` [PATCH 3/3] drm/xe: Drop duplicated information about GT tile " José Roberto de Souza
2025-01-23 18:18 ` John Harrison
2025-01-23 18:24 ` Souza, Jose
2025-01-23 18:30 ` John Harrison [this message]
2025-01-23 18:56 ` Souza, Jose
2025-01-23 19:27 ` John Harrison
2025-01-23 19:35 ` Souza, Jose
2025-01-23 20:59 ` John Harrison
2025-01-23 18:08 ` ✓ CI.Patch_applied: success for Enable GuC log dump and minor fixes " Patchwork
2025-01-23 18:08 ` ✗ CI.checkpatch: warning " Patchwork
2025-01-23 18:09 ` ✓ CI.KUnit: success " Patchwork
2025-01-23 18:26 ` ✓ CI.Build: " Patchwork
2025-01-23 18:28 ` ✗ CI.Hooks: failure " Patchwork
2025-01-23 18:29 ` ✓ CI.checksparse: success " Patchwork
2025-01-23 18:55 ` ✓ Xe.CI.BAT: " Patchwork
2025-01-24 5:25 ` ✗ Xe.CI.Full: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a8ac03e2-43c1-488d-a821-902aba7caa25@intel.com \
--to=john.c.harrison@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=jose.souza@intel.com \
--cc=lucas.demarchi@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox