Re: [PATCH v2] drm/client: Detect when ACPI lid is closed during initialization
On Tue, Jun 04, 2024 at 10:02:29AM +0800, kernel test robot wrote:
> Hi Mario,
>
> kernel test robot noticed the following build errors:
>
> [auto build test ERROR on drm-misc/drm-misc-next]
> [also build test ERROR on drm/drm-next drm-exynos/exynos-drm-next
> drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip
> linus/master v6.10-rc2 next-20240603]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url:
> https://github.com/intel-lab-lkp/linux/commits/Mario-Limonciello/drm-client-Detect-when-ACPI-lid-is-closed-during-initialization/20240529-050440
> base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
> patch link:
> https://lore.kernel.org/r/20240528210319.1242-1-mario.limonciello%40amd.com
> patch subject: [PATCH v2] drm/client: Detect when ACPI lid is closed during
> initialization
> config: i386-randconfig-053-20240604
> (https://download.01.org/0day-ci/archive/20240604/202406040928.eu1griwv-...@intel.com/config)
> compiler: gcc-9 (Ubuntu 9.5.0-4ubuntu2) 9.5.0
> reproduce (this is a W=1 build):
> (https://download.01.org/0day-ci/archive/20240604/202406040928.eu1griwv-...@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version
> of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot
> | Closes:
> https://lore.kernel.org/oe-kbuild-all/202406040928.eu1griwv-...@intel.com/
>
> All errors (new ones prefixed by >>):
>
>ld: drivers/gpu/drm/drm_client_modeset.o: in function
> `drm_client_match_edp_lid':
> >> drivers/gpu/drm/drm_client_modeset.c:281:(.text+0x221b): undefined
> >> reference to `acpi_lid_open'
>
>
> vim +281 drivers/gpu/drm/drm_client_modeset.c
>
>260
>261static void drm_client_match_edp_lid(struct drm_device *dev,
>262 struct drm_connector
> **connectors,
>263 unsigned int
> connector_count,
>264 bool *enabled)
>265{
>266int i;
>267
>268for (i = 0; i < connector_count; i++) {
>269struct drm_connector *connector = connectors[i];
>270
>271switch (connector->connector_type) {
>272case DRM_MODE_CONNECTOR_LVDS:
>273case DRM_MODE_CONNECTOR_eDP:
>274if (!enabled[i])
>275continue;
>276break;
>277default:
>278continue;
>279}
>280
> > 281if (!acpi_lid_open()) {
>282drm_dbg_kms(dev, "[CONNECTOR:%d:%s] lid
> is closed, disabling\n",
>283connector->base.id,
> connector->name);
>284enabled[i] = false;
>285}
>286}
>287}
>288
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
The failed config has CONFIG_ACPI_BUTTON=m. The build failure can be
fixed with:
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index b76438c31761..0271e66f44f8 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -271,11 +271,13 @@ static void drm_client_match_edp_lid(struct drm_device
*dev,
if (connector->connector_type != DRM_MODE_CONNECTOR_eDP ||
!enabled[i])
continue;
+#if defined(CONFIG_ACPI_BUTTON)
if (!acpi_lid_open()) {
drm_dbg_kms(dev, "[CONNECTOR:%d:%s] lid is closed,
disabling\n",
connector->base.id, connector->name);
enabled[i] = false;
}
+#endif
}
}
Re: [PATCH] drm/client: Detect when ACPI lid is closed during initialization
On Mon, 27 May 2024 at 15:23, Mario Limonciello wrote: > > If the lid on a laptop is closed when eDP connectors are populated > then it remains enabled when the initial framebuffer configuration > is built. > > When creating the initial framebuffer configuration detect the ACPI > lid status and if it's closed disable any eDP connectors. > > Suggested-by: Alex Deucher > Reported-by: Chris Bainbridge > Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3349 > Signed-off-by: Mario Limonciello > --- > drivers/gpu/drm/drm_client_modeset.c | 23 +++ > 1 file changed, 23 insertions(+) Thanks. Works for me. Note that I tested against mainline commit f0cd69b8cca6 due to regression https://lore.kernel.org/all/cabxgcsn1z2gj99zsdhqwynptxbymrqhejdff8axxxoiz_0g...@mail.gmail.com/
Re: 6.10/regression/bisected commit c4cb23111103 causes sleeping function called from invalid context at kernel/locking/mutex.c:585
On Tue, May 21, 2024 at 02:39:06PM +0500, Mikhail Gavrilov wrote:
> Hi,
> Yesterday on the fresh kernel snapshot
> I spotted a new bug message with follow stacktrace:
> [4.307097] BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:585
> [4.307135] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid:
> 1, name: swapper/0
> [4.307150] preempt_count: 3, expected: 0
> [4.307159] RCU nest depth: 0, expected: 0
> [4.307168] 4 locks held by swapper/0/1:
> [4.307176] #0: 8881080ba920 (>mutex){+.+.}-{3:3}, at:
> bus_iommu_probe+0xf6/0x4c0
> [4.307203] #1: 88811654c1b8 (>lock){}-{2:2}, at:
> amd_iommu_attach_device+0x1ad/0x1e80
> [4.307227] #2: 888113518c18 (_data->lock){}-{2:2},
> at: amd_iommu_attach_device+0x213/0x1e80
> [4.307243] #3: 888108393030 (>lock){}-{2:2}, at:
> amd_iommu_iopf_add_device+0x69/0x140
> [4.307243] irq event stamp: 1021718
> [4.307243] hardirqs last enabled at (1021717):
> [] kasan_quarantine_put+0x12e/0x250
> [4.307243] hardirqs last disabled at (1021718):
> [] _raw_spin_lock_irqsave+0x7c/0xa0
> [4.307243] softirqs last enabled at (1020154):
> [] __irq_exit_rcu+0xbb/0x1c0
> [4.307243] softirqs last disabled at (1020147):
> [] __irq_exit_rcu+0xbb/0x1c0
> [4.307243] Preemption disabled at:
> [4.307243] [<>] 0x0
> [4.307243] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 6.10.0-0.rc0.20240520giteb6a9339efeb.9.fc41.x86_64+debug #1
> [4.307243] Hardware name: ASUS System Product Name/ROG STRIX
> B650E-I GAMING WIFI, BIOS 2611 04/07/2024
> [4.307243] Call Trace:
> [4.307243]
> [4.307243] dump_stack_lvl+0x84/0xd0
> [4.307243] __might_resched.cold+0x1f7/0x23d
> [4.307243] ? __pfx___might_resched+0x10/0x10
> [4.307243] __mutex_lock+0xf3/0x13f0
> [4.307243] ? iopf_queue_add_device+0xd2/0x5d0
> [4.307243] ? __pfx___mutex_lock+0x10/0x10
> [4.307243] ? find_held_lock+0x34/0x120
> [4.307243] ? __pfx_lock_acquired+0x10/0x10
> [4.307243] ? iopf_queue_add_device+0xd2/0x5d0
> [4.307243] iopf_queue_add_device+0xd2/0x5d0
> [4.307243] amd_iommu_iopf_add_device+0xcd/0x140
> [4.307243] amd_iommu_attach_device+0xdc8/0x1e80
> [4.307243] ? iommu_create_device_direct_mappings+0x571/0x7d0
> [4.307243] __iommu_attach_device+0x64/0x250
> [4.307243] __iommu_device_set_domain+0x122/0x1c0
> [4.307243] __iommu_group_set_domain_internal+0xfa/0x2d0
> [4.307243] iommu_setup_default_domain+0x918/0xcd0
> [4.307243] bus_iommu_probe+0x1ad/0x4c0
> [4.307243] ? __pfx_bus_iommu_probe+0x10/0x10
> [4.307243] iommu_device_register+0x184/0x230
> [4.307243] ? amd_iommu_iopf_init+0xfd/0x170
> [4.307243] iommu_go_to_state+0xf87/0x3890
> [4.307243] ? __pfx_iommu_go_to_state+0x10/0x10
> [4.307243] ? lockdep_hardirqs_on+0x7c/0x100
> [4.307243] ? _raw_spin_unlock_irqrestore+0x4f/0x80
> [4.307243] ? add_device_randomness+0xb8/0xf0
> [4.307243] ? __pfx_add_device_randomness+0x10/0x10
> [4.307243] ? __pfx_pci_iommu_init+0x10/0x10
> [4.307243] amd_iommu_init+0x21/0x60
> [4.307243] ? __pfx_pci_iommu_init+0x10/0x10
> [4.307243] pci_iommu_init+0x38/0x60
> [4.307243] do_one_initcall+0xd6/0x460
> [4.307243] ? __pfx_do_one_initcall+0x10/0x10
> [4.307243] ? kernel_init_freeable+0x4cb/0x750
> [4.307243] ? kasan_unpoison+0x44/0x70
> [4.307243] kernel_init_freeable+0x6b4/0x750
> [4.307243] ? __pfx_kernel_init_freeable+0x10/0x10
> [4.307243] ? __pfx_kernel_init+0x10/0x10
> [4.307243] ? __pfx_kernel_init+0x10/0x10
> [4.307243] kernel_init+0x1c/0x150
> [4.307243] ? __pfx_kernel_init+0x10/0x10
> [4.307243] ret_from_fork+0x31/0x70
> [4.307243] ? __pfx_kernel_init+0x10/0x10
> [4.307243] ret_from_fork_asm+0x1a/0x30
> [4.307243]
>
> [4.307243] =
> [4.307243] [ BUG: Invalid wait context ]
> [4.307243] 6.10.0-0.rc0.20240520giteb6a9339efeb.9.fc41.x86_64+debug
> #1 Tainted: GW --- ---
> [4.307243] -
> [4.307243] swapper/0/1 is trying to lock:
> [4.307243] 88810de2fa88 (>lock){}-{3:3}, at:
> iopf_queue_add_device+0xd2/0x5d0
> [4.307243] other info that might help us debug this:
> [4.307243] context-{4:4}
> [4.307243] 4 locks held by swapper/0/1:
> [4.307243] #0: 8881080ba920 (>mutex){+.+.}-{3:3}, at:
> bus_iommu_probe+0xf6/0x4c0
> [4.307243] #1: 88811654c1b8 (>lock){}-{2:2}, at:
> amd_iommu_attach_device+0x1ad/0x1e80
> [4.307243] #2: 888113518c18 (_data->lock){}-{2:2},
> at: amd_iommu_attach_device+0x213/0x1e80
> [4.307243] #3: 888108393030 (>lock){}-{2:2}, at:
> amd_iommu_iopf_add_device+0x69/0x140
> [4.307243] stack backtrace:
> [4.307243] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
> --- ---
>
Re: [PATCH v2] drm: use mgr->dev in drm_dbg_kms in drm_dp_add_payload_part2
On Tue, Jun 20, 2023 at 03:59:24PM -0400, Lyude Paul wrote:
> Also since I forgot, so patchwork picks this up:
>
> Reviewed-by: Lyude Paul
>
> On Tue, 2023-06-20 at 15:50 -0400, Lyude Paul wrote:
> > Eek - this might have been a situation where everyone involved assumed
> > someone
> > else would push it, whoops. I'll make sure this is pushed upstream :).
> >
> > FWIW: You could definitely send an MR to the fedora kernel's gitlab to get
> > this included earlier. If you don't get to it before me I'll try to do that
> > today
> >
> > On Tue, 2023-06-20 at 07:18 -0400, Jeff Layton wrote:
> > > I've noticed that this patch is not included in linux-next currently.
> > >
> > > Can I get some confirmation that this is going to be included in v6.5?
> > > Currently, I've been having to rebuild Fedora kernels to avoid this
> > > panic, and I'd like to know there is a light at the end of that tunnel.
> > >
> > > Thanks,
> > > Jeff
> > >
> > > On Wed, 2023-04-19 at 16:54 -0400, Lyude Paul wrote:
> > > > Reviewed-by: Lyude Paul
> > > >
> > > > Thanks!
> > > >
> > > > On Wed, 2023-04-19 at 07:24 -0400, Jeff Layton wrote:
> > > > > I've been experiencing some intermittent crashes down in the display
> > > > > driver code. The symptoms are ususally a line like this in dmesg:
> > > > >
> > > > > amdgpu :30:00.0: [drm] Failed to create MST payload for port
> > > > > 6d3a3885: -5
> > > > >
> > > > > ...followed by an Oops due to a NULL pointer dereference.
> > > > >
> > > > > Switch to using mgr->dev instead of state->dev since "state" can be
> > > > > NULL in some cases.
> > > > >
> > > > > Link: https://bugzilla.redhat.com/show_bug.cgi?id=2184855
> > > > > Suggested-by: Jani Nikula
> > > > > Signed-off-by: Jeff Layton
> > > > > ---
> > > > > drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > I've been running this patch for a couple of days, but the problem
> > > > > hasn't occurred again as of yet. It seems sane though as long as we
> > > > > can
> > > > > assume that mgr->dev will be valid even when "state" is a NULL
> > > > > pointer.
> > > > >
> > > > > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > index 38dab76ae69e..e2e21ce79510 100644
> > > > > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > @@ -3404,7 +3404,7 @@ int drm_dp_add_payload_part2(struct
> > > > > drm_dp_mst_topology_mgr *mgr,
> > > > >
> > > > > /* Skip failed payloads */
> > > > > if (payload->vc_start_slot == -1) {
> > > > > - drm_dbg_kms(state->dev, "Part 1 of payload creation for
> > > > > %s failed, skipping part 2\n",
> > > > > + drm_dbg_kms(mgr->dev, "Part 1 of payload creation for
> > > > > %s failed, skipping part 2\n",
> > > > > payload->port->connector->name);
> > > > > return -EIO;
> > > > > }
> > > >
> > >
> >
>
> --
> Cheers,
> Lyude Paul (she/her)
> Software Engineer at Red Hat
>
Hello, this patch regressed in Wayne's 5aa1dfcdf0a42 commit:
$ git show 5aa1dfcdf0a42 | grep -A6 'Skip failed payloads'
/* Skip failed payloads */
- if (payload->vc_start_slot == -1) {
- drm_dbg_kms(mgr->dev, "Part 1 of payload creation for %s
failed, skipping part 2\n",
+ if (payload->payload_allocation_status !=
DRM_DP_MST_PAYLOAD_ALLOCATION_DFP) {
+ drm_dbg_kms(state->dev, "Part 1 of payload creation for %s
failed, skipping part 2\n",
payload->port->connector->name);
return -EIO;
$ git tag --contains 5aa1dfcdf0a42
v6.7
v6.7-rc1
v6.7-rc2
v6.7-rc3
v6.7-rc4
v6.7-rc5
v6.7-rc6
v6.7-rc7
v6.7-rc8
v6.7.1
v6.7.10
v6.7.11
v6.7.12
v6.7.2
v6.7.3
v6.7.4
v6.7.5
v6.7.6
v6.7.7
v6.7.8
v6.7.9
v6.8
v6.8-rc1
v6.8-rc2
v6.8-rc3
v6.8-rc4
v6.8-rc5
v6.8-rc6
v6.8-rc7
v6.8.1
v6.8.2
v6.8.3
v6.8.4
v6.8.5
v6.8.6
v6.8.7
v6.8.8
v6.9-rc1
v6.9-rc2
v6.9-rc3
v6.9-rc4
v6.9-rc5
[PATCH v4] Fix divide-by-zero regression on DP MST unplug with nouveau
ore drm nvme nvme_core mxm_wmi
xhci_pci xhci_pci_renesas video wmi pinctrl_cannonlake mac_hid
---[ end trace ]---
Fix this by avoiding the divide if bpp is 0.
Fixes: c1d6a22b7219 ("drm/dp: Add helpers to calculate the link BW overhead")
Cc: sta...@vger.kernel.org
Acked-by: Imre Deak
Signed-off-by: Chris Bainbridge
---
drivers/gpu/drm/display/drm_dp_helper.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index b1ca3a1100da..26c188ce5f1c 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -3982,6 +3982,13 @@ int drm_dp_bw_overhead(int lane_count, int hactive,
u32 overhead = 100;
int symbol_cycles;
+ if (lane_count == 0 || hactive == 0 || bpp_x16 == 0) {
+ DRM_DEBUG_KMS("Invalid BW overhead params: lane_count %d,
hactive %d, bpp_x16 %d.%04d\n",
+ lane_count, hactive,
+ bpp_x16 >> 4, (bpp_x16 & 0xf) * 625);
+ return 0;
+ }
+
/*
* DP Standard v2.1 2.6.4.1
* SSC downspread and ref clock variation margin:
--
2.39.2
[PATCH v3] Fix divide-by-zero regression on DP MST unplug with nouveau
ore drm nvme nvme_core mxm_wmi
xhci_pci xhci_pci_renesas video wmi pinctrl_cannonlake mac_hid
---[ end trace ]---
Fix this by avoiding the divide if bpp is 0.
Fixes: c1d6a22b7219 ("drm/dp: Add helpers to calculate the link BW overhead")
Cc: sta...@vger.kernel.org
Acked-by: Imre Deak
Signed-off-by: Chris Bainbridge
---
drivers/gpu/drm/display/drm_dp_helper.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index b1ca3a1100da..d51c1bcee258 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -3982,6 +3982,12 @@ int drm_dp_bw_overhead(int lane_count, int hactive,
u32 overhead = 100;
int symbol_cycles;
+ if (lane_count == 0 || hactive == 0 || bpp_x16 == 0) {
+ DRM_DEBUG_KMS("Invalid BW overhead params: lane_count %d,
hactive %d, bpp_x16 %.04d\n",
+ lane_count, hactive, bpp_x16);
+ return 0;
+ }
+
/*
* DP Standard v2.1 2.6.4.1
* SSC downspread and ref clock variation margin:
--
2.39.2
[PATCH v2] Fix divide-by-zero regression on DP MST unplug with nouveau
ore drm nvme nvme_core mxm_wmi
xhci_pci xhci_pci_renesas video wmi pinctrl_cannonlake mac_hid
---[ end trace ]---
Fix this by avoiding the divide if bpp is 0.
Fixes: c1d6a22b7219 ("drm/dp: Add helpers to calculate the link BW overhead")
Signed-off-by: Chris Bainbridge
Acked-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_helper.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index b1ca3a1100da..9f0e7142f174 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -3982,6 +3982,13 @@ int drm_dp_bw_overhead(int lane_count, int hactive,
u32 overhead = 100;
int symbol_cycles;
+ if (bpp_x16 == 0) {
+ DRM_DEBUG("drm_dp_bw_overhead called with bpp 0\n");
+ }
+ if (lane_count == 0 || hactive == 0 || bpp_x16 == 0) {
+ return 0;
+ }
+
/*
* DP Standard v2.1 2.6.4.1
* SSC downspread and ref clock variation margin:
--
2.39.2
[PATCH] Fix divide-by-zero on DP unplug with nouveau
]---
Fix this by avoiding the divide if bpp is 0.
Fixes: c1d6a22b7219 ("drm/dp: Add helpers to calculate the link BW overhead")
Signed-off-by: Chris Bainbridge
---
drivers/gpu/drm/display/drm_dp_helper.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index b1ca3a1100da..bb8794c8f99c 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -4024,6 +4024,9 @@ int drm_dp_bw_overhead(int lane_count, int hactive,
bpp_x16, symbol_size,
is_mst);
+ /* Avoid potential divide by zero in DIV_ROUND_UP_ULL */
+ if (bpp_x16 == 0)
+ return 0;
return DIV_ROUND_UP_ULL(mul_u32_u32(symbol_cycles * symbol_size *
lane_count,
overhead * 16),
hactive * bpp_x16);
--
2.39.2
4.4-rc, intel dri i915, regular hangs and corruptions
On 17 December 2015 at 18:34, Norbert Preining wrote: > * font corruption > sometime sets of glyphs, or practically all glyphs disappear > related probably to bug > https://bugs.freedesktop.org/show_bug.cgi?id=55500 > I have sent some info there already, without response > > Currently my font displays some kind of strange symbols instead of > an m ... looks a bit like a Kanji. I remember a similar bug around 2.99.917 but that tag is over a year old now and there have been many bug fixes since. You'll need to verify you can still reproduce your issue with the latest from git://anongit.freedesktop.org/xorg/driver/xf86-video-intel and if so do a bisect from the previous working kernel or xf86-video-intel to identify the problematic commit.
