Regression on linux-next (next-20241120) and drm-tip
Thomas Weißschuh
linux at weissschuh.net
Tue Dec 3 08:25:00 UTC 2024
On 2024-12-03 09:50:05+0200, Luca Coelho wrote:
> On Tue, 2024-12-03 at 07:50 +0100, Thomas Weißschuh wrote:
> > (+Cc Sebastian)
> >
> > Hi Chaitanya,
> >
> > On 2024-12-03 05:07:47+0000, Borah, Chaitanya Kumar wrote:
> > > Hope you are doing well. I am Chaitanya from the linux graphics team in Intel.
> > >
> > > This mail is regarding a regression we are seeing in our CI runs[1] on linux-next repository.
> >
> > Thanks for the report.
> >
> > > Since the version next-20241120 [2], we are seeing the following regression
> > >
> > > `````````````````````````````````````````````````````````````````````````````````
> > > <4>[ 19.990743] Oops: general protection fault, probably for non-canonical address 0xb11675ef8d1ccbce: 0000 [#1] PREEMPT SMP NOPTI
> > > <4>[ 19.990760] CPU: 21 UID: 110 PID: 867 Comm: prometheus-node Not tainted 6.12.0-next-20241120-next-20241120-gac24e26aa08f+ #1
> > > <4>[ 19.990771] Hardware name: Intel Corporation Arrow Lake Client Platform/MTL-S UDIMM 2DPC EVCRB, BIOS MTLSFWI1.R00.4400.D85.2410100007 10/10/2024
> > > <4>[ 19.990782] RIP: 0010:power_supply_get_property+0x3e/0xe0
> > > `````````````````````````````````````````````````````````````````````````````````
> > > Details log can be found in [3].
> > >
> > > After bisecting the tree, the following patch [4] seems to be the first "bad"
> > > commit
> > >
> > > `````````````````````````````````````````````````````````````````````````````````````````````````````````
> > > Commit 49000fee9e639f62ba1f965ed2ae4c5ad18d19e2
> > > Author: Thomas Weißschuh <mailto:linux at weissschuh.net>
> > > AuthorDate: Sat Oct 5 12:05:03 2024 +0200
> > > Commit: Sebastian Reichel <mailto:sebastian.reichel at collabora.com>
> > > CommitDate: Tue Oct 15 22:22:20 2024 +0200
> > > power: supply: core: add wakeup source inhibit by power_supply_config
> > > `````````````````````````````````````````````````````````````````````````````````````````````````````````
> > >
> > > This is now seen in our drm-tip runs as well. [5]
> > >
> > > Could you please check why the patch causes this regression and provide a fix if necessary?
> >
> > I don't see how this patch can lead to this error.
> > Could you doublecheck the bisect?
>
> FWIW I also bisected this and came to the same conclusion, this is the
> first bad commit. My guess is that some component is not yet setting
> things up properly for the new feature.
The thing is that at this point nothing is using this feature.
And the new code runs during registration while the error happens later.
> This is very easily reproducible in our system, with vanila 6.13-rc1,
> so if there's anything you want to try, let us know.
Can you try the following diffs, each alone on top of
49000fee9e639f62ba1f965ed2ae4c5ad18d19e2?
diff --git a/drivers/power/supply/power_supply_core.c b/drivers/power/supply/power_supply_core.c
index a2005e3c6f38..c6e7ca5b1283 100644
--- a/drivers/power/supply/power_supply_core.c
+++ b/drivers/power/supply/power_supply_core.c
@@ -1411,7 +1411,7 @@ __power_supply_register(struct device *parent,
goto device_add_failed;
if (cfg && cfg->no_wakeup_source)
- ws = false;
+ ;
rc = device_init_wakeup(dev, ws);
if (rc)
diff --git a/drivers/power/supply/power_supply_core.c b/drivers/power/supply/power_supply_core.c
index a2005e3c6f38..5aefba2ddcda 100644
--- a/drivers/power/supply/power_supply_core.c
+++ b/drivers/power/supply/power_supply_core.c
@@ -1410,9 +1410,6 @@ __power_supply_register(struct device *parent,
if (rc)
goto device_add_failed;
- if (cfg && cfg->no_wakeup_source)
- ws = false;
-
rc = device_init_wakeup(dev, ws);
if (rc)
goto wakeup_init_failed;
Could you also print the name of the device?
diff --git a/drivers/power/supply/power_supply_core.c b/drivers/power/supply/power_supply_core.c
index a2005e3c6f38..63e9e339cc01 100644
--- a/drivers/power/supply/power_supply_core.c
+++ b/drivers/power/supply/power_supply_core.c
@@ -1356,6 +1356,8 @@ __power_supply_register(struct device *parent,
pr_warn("%s: Expected proper parent device for '%s'\n",
__func__, desc->name);
+ pr_warn("PSY: name=%s\n", desc->name);
+
psy = kzalloc(sizeof(*psy), GFP_KERNEL);
if (!psy)
return ERR_PTR(-ENOMEM);
Also line numbers would be useful.
Is this configuration running KASAN?
Thanks a lot,
Thomas
More information about the Intel-gfx
mailing list