Hi Greg, hi Sasha,
Please applied f3c89983cb4f ("block: Fix where bio IO priority gets
set") to stable 6.1+, it applies cleanly to v6.1.110/v6.6.51.
Thx!
Jinpu Wang @ IONOS
Hi,
Upstream commit 1474bc87fe57 ("wifi: cfg80211: check wiphy mutex is held for wdev mutex")
has been backported recently to 5.15/6.1/6.6 stable branches. After that
we started seeing numerous lockdep assertion splats in these kernels
originating from different parts of wireless stack where wdev_lock() is
called. There is also a huge pile of them already found in Syzbot [1,2,3].
Digging more into the issue it appears that the blamed commit is a part of
a much larger series [4] with locking cleanups and improvements for the
whole wireless subsystem. The series was merged at 6.7.
The cover letter for the series says:
There's a kind of pointless commit in there that adds some wiphy
locking assertions to the wdev as an intermediate step, I can
remove that if you think that's better. We ran with it at that
intermediate stage for a while to test things.
So backporting this commit to stable branches without taking the series as
a whole is pointless and just leads to bogus lockdep assertion splats
there. The series itself is an improvement and cleanup work and therefore
is not considered as material for old stable kernels.
The solution which comes to mind is to revert this backported patch from
the affected stable branches.
Namely:
- 5.15 https://lore.kernel.org/stable/20240901160825.013135421@linuxfoundation.org/
- 6.1 https://lore.kernel.org/stable/20240827143842.546537850@linuxfoundation.org/
- 6.6 https://lore.kernel.org/stable/20240827143846.794100356@linuxfoundation.org/
The intention why it was suddenly backported to these branches a year
after merge-to-upstream is not clear actually: there are no stable or
Fixes tags in commit message, and I don't find any public request for
explicit backport on mailing lists.
Please let me know if you can revert the commits yourself or I have to
prepare and send them to you.
[1]: https://syzkaller.appspot.com/bug?extid=310a1a9715fc1c9ead61
[2]: https://syzkaller.appspot.com/bug?extid=b730e8b6bc76d07fe10b
[3]: https://syzkaller.appspot.com/bug?extid=09501cf606ec2823fafa
[4]: https://lore.kernel.org/linux-wireless/20230828115927.116700-41-johannes@si…
--
Thanks,
Fedor
CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND is an int, defaulting to 250. When
the wakeref is non-zero, it's either -1 or a dynamically allocated
pointer, depending on CONFIG_DRM_I915_DEBUG_RUNTIME_PM. It's likely that
the code works by coincidence with the bitwise AND, but with
CONFIG_DRM_I915_DEBUG_RUNTIME_PM=y, there's the off chance that the
condition evaluates to false, and intel_wakeref_auto() doesn't get
called. Switch to the intended logical AND.
Fixes: ad74457a6b5a ("drm/i915/dgfx: Release mmap on rpm suspend")
Cc: Matthew Auld <matthew.auld(a)intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
Cc: Anshuman Gupta <anshuman.gupta(a)intel.com>
Cc: Andi Shyti <andi.shyti(a)linux.intel.com>
Cc: <stable(a)vger.kernel.org> # v6.1+
Signed-off-by: Jani Nikula <jani.nikula(a)intel.com>
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 5c72462d1f57..c157ade48c39 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1131,7 +1131,7 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
GEM_WARN_ON(!i915_ttm_cpu_maps_iomem(bo->resource));
}
- if (wakeref & CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)
+ if (wakeref && CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)
intel_wakeref_auto(&to_i915(obj->base.dev)->runtime_pm.userfault_wakeref,
msecs_to_jiffies_timeout(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND));
--
2.39.2
Hi,
There were some fixes for RAPL reading issues recently on some AMD systems.
Can you please bring this commit to 6.6.y, 6.10.y and 6.11.y?
commit 166df51097a2 ("powercap/intel_rapl: Add support for AMD family 1Ah")
Can you also please bring this commit to 6.10.y and 6.11.y?
commit 26096aed255f ("powercap/intel_rapl: Fix the energy-pkg event for
AMD CPUs")
Thanks!
Dell All In One (AIO) models released after 2017 may use a backlight
controller board connected to an UART.
In DSDT this uart port will be defined as:
Name (_HID, "DELL0501")
Name (_CID, EisaId ("PNP0501")
The Dell OptiPlex 5480 AIO has an ACPI device for one if its UARTs with
the above _HID + _CID. Loading the dell-uart-backlight driver fails with
the following errors:
[ 18.261353] dell_uart_backlight serial0-0: Timed out waiting for response.
[ 18.261356] dell_uart_backlight serial0-0: error -ETIMEDOUT: getting firmware version
[ 18.261359] dell_uart_backlight serial0-0: probe with driver dell_uart_backlight failed with error -110
Indicating that there is no backlight controller board attached to
the UART, while the GPU's native backlight control method does work.
Add a quirk to use the GPU's native backlight control method on this model.
Fixes: cd8e468efb4f ("ACPI: video: Add Dell UART backlight controller detection")
Cc: All applicable <stable(a)vger.kernel.org>
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
drivers/acpi/video_detect.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index b70e84e8049a..015bd8e66c1c 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -844,6 +844,15 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
* controller board in their ACPI tables (and may even have one), but
* which need native backlight control nevertheless.
*/
+ {
+ /* https://github.com/zabbly/linux/issues/26 */
+ .callback = video_detect_force_native,
+ /* Dell OptiPlex 5480 AIO */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 5480 AIO"),
+ },
+ },
{
/* https://bugzilla.redhat.com/show_bug.cgi?id=2303936 */
.callback = video_detect_force_native,
--
2.46.0