Re: linux-next: Tree for Jul 21 [drivers/gpu/drm/xe/xe.ko]

Re: linux-next: Tree for Jul 21 [drivers/gpu/drm/xe/xe.ko]

[Randy Dunlap]

On 7/21/25 12:41 AM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20250718:
> 

on ARCH=um SUBARCH=i386, when
# CONFIG_DEBUG_FS is not set

ERROR: modpost: "gt_reset_failure" [drivers/gpu/drm/xe/xe.ko] undefined!

-- 
~Randy

Re: linux-next: Tree for Jul 21 [drivers/gpu/drm/xe/xe.ko]

[Lucas De Marchi]

On Mon, Jul 21, 2025 at 01:17:33PM -0700, Randy Dunlap wrote:
>
>
>On 7/21/25 12:41 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20250718:
>>
>
>on ARCH=um SUBARCH=i386, when
># CONFIG_DEBUG_FS is not set

can you share your entire config? I have all of the settings above, but
I can't reproduce it with gcc-13. Is this a regression from the previous
-next tag? I think the diff below should fix it, but I can't confirm on
my end nor I see how this would be a regression from a few days ago
only.

-----8<-------
diff --git a/drivers/gpu/drm/xe/xe_gt.h b/drivers/gpu/drm/xe/xe_gt.h
index e9ccab8aedbef..41880979f4ded 100644
--- a/drivers/gpu/drm/xe/xe_gt.h
+++ b/drivers/gpu/drm/xe/xe_gt.h
@@ -24,7 +24,7 @@
  extern struct fault_attr gt_reset_failure;
  static inline bool xe_fault_inject_gt_reset(void)
  {
-	return should_fail(&gt_reset_failure, 1);
+	return IS_ENABLED(CONFIG_DEBUG_FS) && should_fail(&gt_reset_failure, 1);
  }
  
  struct xe_gt *xe_gt_alloc(struct xe_tile *tile);
-----8<-------

thanks,
Lucas De Marchi

>
>ERROR: modpost: "gt_reset_failure" [drivers/gpu/drm/xe/xe.ko] undefined!

>
>-- 
>~Randy
>

Re: linux-next: Tree for Jul 21 [drivers/gpu/drm/xe/xe.ko]

[Randy Dunlap]

[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]

Hi,

On 7/21/25 6:38 PM, Lucas De Marchi wrote:
> On Mon, Jul 21, 2025 at 01:17:33PM -0700, Randy Dunlap wrote:
>>
>>
>> On 7/21/25 12:41 AM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Changes since 20250718:
>>>
>>
>> on ARCH=um SUBARCH=i386, when
>> # CONFIG_DEBUG_FS is not set
> 
> can you share your entire config? I have all of the settings above, but
> I can't reproduce it with gcc-13. Is this a regression from the previous
> -next tag? I think the diff below should fix it, but I can't confirm on
> my end nor I see how this would be a regression from a few days ago
> only.

It's a randconfig, attached. (#1046 is for 32-bit)
config-um64-drmxegt is for 64-bit.
using gcc (SUSE Linux) 15.1.1 20250714

> 
> -----8<-------
> diff --git a/drivers/gpu/drm/xe/xe_gt.h b/drivers/gpu/drm/xe/xe_gt.h
> index e9ccab8aedbef..41880979f4ded 100644
> --- a/drivers/gpu/drm/xe/xe_gt.h
> +++ b/drivers/gpu/drm/xe/xe_gt.h
> @@ -24,7 +24,7 @@
>  extern struct fault_attr gt_reset_failure;
>  static inline bool xe_fault_inject_gt_reset(void)
>  {
> -    return should_fail(&gt_reset_failure, 1);
> +    return IS_ENABLED(CONFIG_DEBUG_FS) && should_fail(&gt_reset_failure, 1);
>  }
>  
>  struct xe_gt *xe_gt_alloc(struct xe_tile *tile);
> -----8<-------

This fixes the problem for me. Thanks.

Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>

> 
> thanks,
> Lucas De Marchi
> 
>>
>> ERROR: modpost: "gt_reset_failure" [drivers/gpu/drm/xe/xe.ko] undefined!


-- 
~Randy

[-- Attachment #2: config-r1046.gz --]
[-- Type: application/gzip, Size: 29476 bytes --]

[-- Attachment #3: config-um64-drmxegt.gz --]
[-- Type: application/gzip, Size: 31423 bytes --]

Re: linux-next: Tree for Jul 21 [drivers/gpu/drm/xe/xe.ko]

[Lucas De Marchi]

On Mon, Jul 21, 2025 at 10:50:29PM -0700, Randy Dunlap wrote:
>Hi,
>
>On 7/21/25 6:38 PM, Lucas De Marchi wrote:
>> On Mon, Jul 21, 2025 at 01:17:33PM -0700, Randy Dunlap wrote:
>>>
>>>
>>> On 7/21/25 12:41 AM, Stephen Rothwell wrote:
>>>> Hi all,
>>>>
>>>> Changes since 20250718:
>>>>
>>>
>>> on ARCH=um SUBARCH=i386, when
>>> # CONFIG_DEBUG_FS is not set
>>
>> can you share your entire config? I have all of the settings above, but
>> I can't reproduce it with gcc-13. Is this a regression from the previous
>> -next tag? I think the diff below should fix it, but I can't confirm on
>> my end nor I see how this would be a regression from a few days ago
>> only.
>
>It's a randconfig, attached. (#1046 is for 32-bit)
>config-um64-drmxegt is for 64-bit.
>using gcc (SUSE Linux) 15.1.1 20250714

just tried on Ubuntu with gcc 14 and still can't reproduce it. I try
again later on arch or suse.

>
>>
>> -----8<-------
>> diff --git a/drivers/gpu/drm/xe/xe_gt.h b/drivers/gpu/drm/xe/xe_gt.h
>> index e9ccab8aedbef..41880979f4ded 100644
>> --- a/drivers/gpu/drm/xe/xe_gt.h
>> +++ b/drivers/gpu/drm/xe/xe_gt.h
>> @@ -24,7 +24,7 @@
>>  extern struct fault_attr gt_reset_failure;
>>  static inline bool xe_fault_inject_gt_reset(void)
>>  {
>> -    return should_fail(&gt_reset_failure, 1);
>> +    return IS_ENABLED(CONFIG_DEBUG_FS) && should_fail(&gt_reset_failure, 1);
>>  }
>>
>>  struct xe_gt *xe_gt_alloc(struct xe_tile *tile);
>> -----8<-------
>
>This fixes the problem for me. Thanks.
>
>Acked-by: Randy Dunlap <rdunlap@infradead.org>
>Tested-by: Randy Dunlap <rdunlap@infradead.org>

ok, thanks for confirming.  Initially I thought we could have a
dependency on debugfs that commit ccbfd2df3018 ("drm/xe: clean up fault
injection usage") broke, but it doesn't seem so.

So... another approach, probably more correct, would be to move the
attribute off _debugfs.c, since it's availability shouldn't be tied to
debugfs.

Lucas De Marchi

>
>>
>> thanks,
>> Lucas De Marchi
>>
>>>
>>> ERROR: modpost: "gt_reset_failure" [drivers/gpu/drm/xe/xe.ko] undefined!
>
>
>-- 
>~Randy

Re: linux-next: Tree for Jul 21 [drivers/gpu/drm/xe/xe.ko]

[Lucas De Marchi]

On Tue, Jul 22, 2025 at 10:26:11AM -0300, Lucas De Marchi wrote:
>On Mon, Jul 21, 2025 at 10:50:29PM -0700, Randy Dunlap wrote:
>>Hi,
>>
>>On 7/21/25 6:38 PM, Lucas De Marchi wrote:
>>>On Mon, Jul 21, 2025 at 01:17:33PM -0700, Randy Dunlap wrote:
>>>>
>>>>
>>>>On 7/21/25 12:41 AM, Stephen Rothwell wrote:
>>>>>Hi all,
>>>>>
>>>>>Changes since 20250718:
>>>>>
>>>>
>>>>on ARCH=um SUBARCH=i386, when
>>>># CONFIG_DEBUG_FS is not set
>>>
>>>can you share your entire config? I have all of the settings above, but
>>>I can't reproduce it with gcc-13. Is this a regression from the previous
>>>-next tag? I think the diff below should fix it, but I can't confirm on
>>>my end nor I see how this would be a regression from a few days ago
>>>only.
>>
>>It's a randconfig, attached. (#1046 is for 32-bit)
>>config-um64-drmxegt is for 64-bit.
>>using gcc (SUSE Linux) 15.1.1 20250714
>
>just tried on Ubuntu with gcc 14 and still can't reproduce it. I try
>again later on arch or suse.
>
>>
>>>
>>>-----8<-------
>>>diff --git a/drivers/gpu/drm/xe/xe_gt.h b/drivers/gpu/drm/xe/xe_gt.h
>>>index e9ccab8aedbef..41880979f4ded 100644
>>>--- a/drivers/gpu/drm/xe/xe_gt.h
>>>+++ b/drivers/gpu/drm/xe/xe_gt.h
>>>@@ -24,7 +24,7 @@
>>> extern struct fault_attr gt_reset_failure;
>>> static inline bool xe_fault_inject_gt_reset(void)
>>> {
>>>-    return should_fail(&gt_reset_failure, 1);
>>>+    return IS_ENABLED(CONFIG_DEBUG_FS) && should_fail(&gt_reset_failure, 1);
>>> }
>>>
>>> struct xe_gt *xe_gt_alloc(struct xe_tile *tile);
>>>-----8<-------
>>
>>This fixes the problem for me. Thanks.
>>
>>Acked-by: Randy Dunlap <rdunlap@infradead.org>
>>Tested-by: Randy Dunlap <rdunlap@infradead.org>
>
>ok, thanks for confirming.  Initially I thought we could have a
>dependency on debugfs that commit ccbfd2df3018 ("drm/xe: clean up fault
>injection usage") broke, but it doesn't seem so.
>
>So... another approach, probably more correct, would be to move the
>attribute off _debugfs.c, since it's availability shouldn't be tied to
>debugfs.

nvm, the change is correct, it is actually a debugfs attribute.

Applied to drm-xe-next:

	4d3bbe9dd28c ("drm/xe: Fix build without debugfs")

thanks,
Lucas De Marchi