On Tue, 22 Nov 2022, Michal Wajdeczko wrote:
> On 18.11.2022 11:52, Jani Nikula wrote:
>> On Thu, 17 Nov 2022, john.c.harri...@intel.com wrote:
>>> From: John Harrison
>>>
>>> When trying to analyse bug reports from CI, customers, etc. it can be
>>> difficult to work out exactly what is happening
On 18.11.2022 11:52, Jani Nikula wrote:
> On Thu, 17 Nov 2022, john.c.harri...@intel.com wrote:
>> From: John Harrison
>>
>> When trying to analyse bug reports from CI, customers, etc. it can be
>> difficult to work out exactly what is happening on which GT in a
>> multi-GT system. So add GT or
On 21/11/2022 18:21, John Harrison wrote:
On 11/18/2022 02:52, Jani Nikula wrote:
On Thu, 17 Nov 2022, john.c.harri...@intel.com wrote:
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it can be
difficult to work out exactly what is happening on which GT in a
On 11/18/2022 02:52, Jani Nikula wrote:
On Thu, 17 Nov 2022, john.c.harri...@intel.com wrote:
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it can be
difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT oriented debug/err
On Thu, 17 Nov 2022, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> When trying to analyse bug reports from CI, customers, etc. it can be
> difficult to work out exactly what is happening on which GT in a
> multi-GT system. So add GT oriented debug/error message wrappers. If
> used ins
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it can be
difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT oriented debug/error message wrappers. If
used instead of the drm_ equivalents, you get the same output but with
a
