* Re: linux-next: Tree for Jul 21 [drivers/gpu/drm/xe/xe.ko] [not found] <20250721174126.75106f39@canb.auug.org.au> @ 2025-07-21 20:17 ` Randy Dunlap 2025-07-22 1:38 ` Lucas De Marchi 0 siblings, 1 reply; 5+ messages in thread From: Randy Dunlap @ 2025-07-21 20:17 UTC (permalink / raw) To: Stephen Rothwell, Linux Next Mailing List Cc: Linux Kernel Mailing List, linux-um, Richard Weinberger, intel-xe, Linux DRI Development 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: linux-next: Tree for Jul 21 [drivers/gpu/drm/xe/xe.ko] 2025-07-21 20:17 ` linux-next: Tree for Jul 21 [drivers/gpu/drm/xe/xe.ko] Randy Dunlap @ 2025-07-22 1:38 ` Lucas De Marchi 2025-07-22 5:50 ` Randy Dunlap 0 siblings, 1 reply; 5+ messages in thread From: Lucas De Marchi @ 2025-07-22 1:38 UTC (permalink / raw) To: Randy Dunlap Cc: Stephen Rothwell, Linux Next Mailing List, Linux Kernel Mailing List, linux-um, Richard Weinberger, intel-xe, Linux DRI Development 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(>_reset_failure, 1); + return IS_ENABLED(CONFIG_DEBUG_FS) && should_fail(>_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 > ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: linux-next: Tree for Jul 21 [drivers/gpu/drm/xe/xe.ko] 2025-07-22 1:38 ` Lucas De Marchi @ 2025-07-22 5:50 ` Randy Dunlap 2025-07-22 13:26 ` Lucas De Marchi 0 siblings, 1 reply; 5+ messages in thread From: Randy Dunlap @ 2025-07-22 5:50 UTC (permalink / raw) To: Lucas De Marchi Cc: Stephen Rothwell, Linux Next Mailing List, Linux Kernel Mailing List, linux-um, Richard Weinberger, intel-xe, Linux DRI Development [-- 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(>_reset_failure, 1); > + return IS_ENABLED(CONFIG_DEBUG_FS) && should_fail(>_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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: linux-next: Tree for Jul 21 [drivers/gpu/drm/xe/xe.ko] 2025-07-22 5:50 ` Randy Dunlap @ 2025-07-22 13:26 ` Lucas De Marchi 2025-07-23 15:50 ` Lucas De Marchi 0 siblings, 1 reply; 5+ messages in thread From: Lucas De Marchi @ 2025-07-22 13:26 UTC (permalink / raw) To: Randy Dunlap Cc: Stephen Rothwell, Linux Next Mailing List, Linux Kernel Mailing List, linux-um, Richard Weinberger, intel-xe, Linux DRI Development 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(>_reset_failure, 1); >> + return IS_ENABLED(CONFIG_DEBUG_FS) && should_fail(>_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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: linux-next: Tree for Jul 21 [drivers/gpu/drm/xe/xe.ko] 2025-07-22 13:26 ` Lucas De Marchi @ 2025-07-23 15:50 ` Lucas De Marchi 0 siblings, 0 replies; 5+ messages in thread From: Lucas De Marchi @ 2025-07-23 15:50 UTC (permalink / raw) To: Randy Dunlap Cc: Stephen Rothwell, Linux Next Mailing List, Linux Kernel Mailing List, linux-um, Richard Weinberger, intel-xe, Linux DRI Development 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(>_reset_failure, 1); >>>+ return IS_ENABLED(CONFIG_DEBUG_FS) && should_fail(>_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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-07-23 15:50 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20250721174126.75106f39@canb.auug.org.au>
2025-07-21 20:17 ` linux-next: Tree for Jul 21 [drivers/gpu/drm/xe/xe.ko] Randy Dunlap
2025-07-22 1:38 ` Lucas De Marchi
2025-07-22 5:50 ` Randy Dunlap
2025-07-22 13:26 ` Lucas De Marchi
2025-07-23 15:50 ` Lucas De Marchi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).