Disabling HPD polling from i915_hpd_poll_init_work() involves probing
all display connectors explicitly to account for lost hotplug
interrupts. On some platforms (mostly pre-ICL) with HDMI connectors the
I2C EDID bit-banging using udelay() triggers in turn the
workqueue: i915_hpd_poll_init_work [i915] hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND
warning.
Fix the above by scheduling i915_hpd_poll_init_work() on a WQ_UNBOUND
workqueue. It's ok to use a system WQ, since i915_hpd_poll_init_work()
is properly flushed in intel_hpd_cancel_work().
The connector probing from drm_mode_config::output_poll_work resulting
in the same warning is fixed by the next patch.
Cc: Tejun Heo <tj(a)kernel.org>
Cc: Heiner Kallweit <hkallweit1(a)gmail.com>
CC: stable(a)vger.kernel.org # 6.5
Suggested-by: Tejun Heo <tj(a)kernel.org>
Suggested-by: Heiner Kallweit <hkallweit1(a)gmail.com>
Reported-by: Heiner Kallweit <hkallweit1(a)gmail.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9245
Link: https://lore.kernel.org/all/f7e21caa-e98d-e5b5-932a-fe12d27fde9b@gmail.com
Signed-off-by: Imre Deak <imre.deak(a)intel.com>
---
drivers/gpu/drm/i915/display/intel_hotplug.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c b/drivers/gpu/drm/i915/display/intel_hotplug.c
index e8562f6f8bb44..accc2fec562a0 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -774,7 +774,7 @@ void intel_hpd_poll_enable(struct drm_i915_private *dev_priv)
* As well, there's no issue if we race here since we always reschedule
* this worker anyway
*/
- queue_work(dev_priv->unordered_wq,
+ queue_work(system_unbound_wq,
&dev_priv->display.hotplug.poll_init_work);
}
@@ -803,7 +803,7 @@ void intel_hpd_poll_disable(struct drm_i915_private *dev_priv)
return;
WRITE_ONCE(dev_priv->display.hotplug.poll_enabled, false);
- queue_work(dev_priv->unordered_wq,
+ queue_work(system_unbound_wq,
&dev_priv->display.hotplug.poll_init_work);
}
--
2.37.2
We notice some platforms set "snps,dis_u3_susphy_quirk" and
"snps,dis_u2_susphy_quirk" when they should not need to. Just make sure that
the GUSB3PIPECTL.SUSPENDENABLE and GUSB2PHYCFG.SUSPHY are clear during
initialization. The host initialization involved xhci. So the dwc3 needs to
implement the xhci_plat_priv->plat_start() for xhci to re-enable the suspend
bits.
Since there's a prerequisite patch to drivers/usb/host/xhci-plat.h that's not a
fix patch, this series should go on Greg's usb-testing branch instead of
usb-linus.
Thinh Nguyen (2):
usb: xhci-plat: Don't include xhci.h
usb: dwc3: core: Prevent phy suspend during init
drivers/usb/dwc3/core.c | 90 +++++++++++++++---------------------
drivers/usb/dwc3/core.h | 1 +
drivers/usb/dwc3/gadget.c | 2 +
drivers/usb/dwc3/host.c | 27 +++++++++++
drivers/usb/host/xhci-plat.h | 4 +-
5 files changed, 71 insertions(+), 53 deletions(-)
base-commit: 3d122e6d27e417a9fa91181922743df26b2cd679
--
2.28.0
On Tue, Mar 12, 2024 at 07:04:10AM -0400, Eric Hagberg wrote:
> On Thu, Mar 7, 2024 at 11:33 AM Steve Wahl <steve.wahl(a)hpe.com> wrote:
> > What Linux Distribution are you running on that machine? My guess
> > would be that this is not distro related; if you are running something
> > quite different from Pavin that would confirm this.
>
> Distro in use is Rocky 8, so it’s pretty clear not to be distro-specific.
>
> > I found an AMD based system to try to reproduce this on.
>
> yeah, it probably requires either a specific cpu or set or devices plus cpu
> to trigger… found that it also affects Dell R7625 servers in addition to
> the R6615s
I agree that it's likely the CPU or particular set of surrounding
devices that trigger the problem.
I have not succeeded in reproducing the problem yet. I tried an AMD
based system lent to me, but it's probably the wrong generation (AMD
EPYC 7251) and I didn't see the problem. I have a line on a system
that's more in line with the systems the bug was reported on that I
should be able to try tomorrow.
I would love to have some direction from the community at large on
this. The fact that nogbpages on the command line causes the same
problem without my patch suggests it's not bad code directly in my
patch, but something in the way kexec reacts to the resulting identity
map. One quick solution would be a kernel command line parameter to
select between the previous identity map creation behavior and the new
behavior. E.g. in addition to "nogbpages", we could have
"somegbpages" and "allgbpages" -- or gbpages=[all, some, none] with
nogbpages a synonym for backwards compatibility.
But I don't want to introduce a new command line parameter if the
actual problem can be understood and fixed. The question is how much
time do I have to persue a direct fix before some other action needs
to be taken?
Thanks,
--> Steve Wahl
--
Steve Wahl, Hewlett Packard Enterprise
Stuart Hayhurst has found that both at bootup and fullscreen VA-API video
is leading to black screens for around 1 second and kernel WARNING [1] traces
when calling dmub_psr_enable() with Parade 08-01 TCON.
These symptoms all go away with PSR-SU disabled for this TCON, so disable
it for now while DMUB traces [2] from the failure can be analyzed and the failure
state properly root caused.
Cc: stable(a)vger.kernel.org
Cc: Marc Rossi <Marc.Rossi(a)amd.com>
Cc: Hamza Mahfooz <Hamza.Mahfooz(a)amd.com>
Link: https://gitlab.freedesktop.org/drm/amd/uploads/a832dd515b571ee171b3e3b566e9… [1]
Link: https://gitlab.freedesktop.org/drm/amd/uploads/8f13ff3b00963c833e23e68aa811… [2]
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2645
Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com>
---
---
drivers/gpu/drm/amd/display/modules/power/power_helpers.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
index e304e8435fb8..477289846a0a 100644
--- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
+++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
@@ -841,6 +841,8 @@ bool is_psr_su_specific_panel(struct dc_link *link)
isPSRSUSupported = false;
else if (dpcd_caps->sink_dev_id_str[1] == 0x08 && dpcd_caps->sink_dev_id_str[0] == 0x03)
isPSRSUSupported = false;
+ else if (dpcd_caps->sink_dev_id_str[1] == 0x08 && dpcd_caps->sink_dev_id_str[0] == 0x01)
+ isPSRSUSupported = false;
else if (dpcd_caps->psr_info.force_psrsu_cap == 0x1)
isPSRSUSupported = true;
}
--
2.34.1
Adapt the internal and external APIs of the sysctl core to handle
read-only instances of "struct ctl_table".
Patch 1: Bugfix for the sysctl core, the bug can be reliably triggered
with the series applied
Patch 2: Trivial preparation commit for the sysctl BPF hook
Patch 3: Adapts the internal sysctl APIs
Patch 4: Adapts the external sysctl APIs
Patch 5: Constifies the sysctl internal tables as proof that it works
Patch 6: Updates scripts/const_structs.checkpatch for "struct ctl_table"
Motivation
==========
Moving structures containing function pointers into unmodifiable .rodata
prevents attackers or bugs from corrupting and diverting those pointers.
Also the "struct ctl_table" exposed by the sysctl core were never meant
to be mutated by users.
For this goal changes to both the sysctl core and "const" qualifiers for
various sysctl APIs are necessary.
Full Process
============
* Drop ctl_table modifications from the sysctl core ([0], in mainline)
* Constify arguments to ctl_table_root::{set_ownership,permissions}
([1], in mainline)
* Migrate users of "ctl_table_header::ctl_table_arg" to "const".
(in mainline)
* Afterwards convert "ctl_table_header::ctl_table_arg" itself to const.
(in mainline)
* Prepare helpers used to implement proc_handlers throughout the tree to
use "const struct ctl_table *". ([2], in mainline)
* Afterwards switch over all proc_handlers callbacks to use
"const struct ctl_table *" in one commit. (in mainline)
* Switch over the internals of the sysctl core to "const struct ctl_table *" (this series)
* Switch include/linux/sysctl.h to "const struct ctl_table *" (this series)
* Transition instances of "struct ctl_table" through the tree to const (to be done)
This series is meant to be applied through the sysctl tree.
Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net>
---
Changes in v2:
- Avoid spurious permanent empty tables (patch 1)
- Link to v1: https://lore.kernel.org/r/20240729-sysctl-const-api-v1-0-ca628c7a942c@weiss…
---
Thomas Weißschuh (6):
sysctl: avoid spurious permanent empty tables
bpf: Constify ctl_table argument of filter function
sysctl: move internal interfaces to const struct ctl_table
sysctl: allow registration of const struct ctl_table
sysctl: make internal ctl_tables const
const_structs.checkpatch: add ctl_table
fs/proc/internal.h | 2 +-
fs/proc/proc_sysctl.c | 100 +++++++++++++++++++++------------------
include/linux/bpf-cgroup.h | 2 +-
include/linux/sysctl.h | 12 ++---
kernel/bpf/cgroup.c | 2 +-
scripts/const_structs.checkpatch | 1 +
6 files changed, 63 insertions(+), 56 deletions(-)
---
base-commit: 8400291e289ee6b2bf9779ff1c83a291501f017b
change-id: 20240729-sysctl-const-api-73954f3d62c1
Best regards,
--
Thomas Weißschuh <linux(a)weissschuh.net>