From: Greg KH <gregkh@linuxfoundation.org>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: javierm@redhat.com, deller@gmx.de, sashal@kernel.org,
stable@vger.kernel.org,
Andreas Thalhammer <andreas.thalhammer-linux@gmx.net>,
Thorsten Leemhuis <regressions@leemhuis.info>,
Zack Rusin <zackr@vmware.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Daniel Vetter <daniel@ffwll.ch>, Sam Ravnborg <sam@ravnborg.org>,
Alex Deucher <alexander.deucher@amd.com>,
Zhen Lei <thunder.leizhen@huawei.com>,
Changcheng Deng <deng.changcheng@zte.com.cn>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org
Subject: Re: [PATCH] video/aperture: Call sysfb_disable() before removing PCI devices
Date: Tue, 25 Oct 2022 13:36:03 +0200 [thread overview]
Message-ID: <Y1fKI7CtCaqK03tj@kroah.com> (raw)
In-Reply-To: <20221025110453.9404-1-tzimmermann@suse.de>
On Tue, Oct 25, 2022 at 01:04:53PM +0200, Thomas Zimmermann wrote:
> Call sysfb_disable() from aperture_remove_conflicting_pci_devices()
> before removing PCI devices. Without, simpledrm can still bind to
> simple-framebuffer devices after the hardware driver has taken over
> the hardware. Both drivers interfere with each other and results are
> undefined.
>
> Reported modesetting errors are shown below.
>
> ---- snap ----
> rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13-.... } 7 jiffies s: 165 root: 0x2000/.
> rcu: blocking rcu_node structures (internal RCU debug):
> Task dump for CPU 13:
> task:X state:R running task stack: 0 pid: 4242 ppid: 4228 flags:0x00000008
> Call Trace:
> <TASK>
> ? commit_tail+0xd7/0x130
> ? drm_atomic_helper_commit+0x126/0x150
> ? drm_atomic_commit+0xa4/0xe0
> ? drm_plane_get_damage_clips.cold+0x1c/0x1c
> ? drm_atomic_helper_dirtyfb+0x19e/0x280
> ? drm_mode_dirtyfb_ioctl+0x10f/0x1e0
> ? drm_mode_getfb2_ioctl+0x2d0/0x2d0
> ? drm_ioctl_kernel+0xc4/0x150
> ? drm_ioctl+0x246/0x3f0
> ? drm_mode_getfb2_ioctl+0x2d0/0x2d0
> ? __x64_sys_ioctl+0x91/0xd0
> ? do_syscall_64+0x60/0xd0
> ? entry_SYSCALL_64_after_hwframe+0x4b/0xb5
> </TASK>
> ...
> rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13-.... } 30 jiffies s: 169 root: 0x2000/.
> rcu: blocking rcu_node structures (internal RCU debug):
> Task dump for CPU 13:
> task:X state:R running task stack: 0 pid: 4242 ppid: 4228 flags:0x0000400e
> Call Trace:
> <TASK>
> ? memcpy_toio+0x76/0xc0
> ? memcpy_toio+0x1b/0xc0
> ? drm_fb_memcpy_toio+0x76/0xb0
> ? drm_fb_blit_toio+0x75/0x2b0
> ? simpledrm_simple_display_pipe_update+0x132/0x150
> ? drm_atomic_helper_commit_planes+0xb6/0x230
> ? drm_atomic_helper_commit_tail+0x44/0x80
> ? commit_tail+0xd7/0x130
> ? drm_atomic_helper_commit+0x126/0x150
> ? drm_atomic_commit+0xa4/0xe0
> ? drm_plane_get_damage_clips.cold+0x1c/0x1c
> ? drm_atomic_helper_dirtyfb+0x19e/0x280
> ? drm_mode_dirtyfb_ioctl+0x10f/0x1e0
> ? drm_mode_getfb2_ioctl+0x2d0/0x2d0
> ? drm_ioctl_kernel+0xc4/0x150
> ? drm_ioctl+0x246/0x3f0
> ? drm_mode_getfb2_ioctl+0x2d0/0x2d0
> ? __x64_sys_ioctl+0x91/0xd0
> ? do_syscall_64+0x60/0xd0
> ? entry_SYSCALL_64_after_hwframe+0x4b/0xb5
> </TASK>
>
> The problem was added by commit 5e0137612430 ("video/aperture: Disable
> and unregister sysfb devices via aperture helpers") to v6.0.3 and does
> not exist in the mainline branch.
Why isn't this a problem in Linus's tree? What commits there cause this
to not be an issue and why can't we just take them instead?
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: sashal@kernel.org, linux-fbdev@vger.kernel.org,
Andreas Thalhammer <andreas.thalhammer-linux@gmx.net>,
dri-devel@lists.freedesktop.org,
Daniel Vetter <daniel.vetter@ffwll.ch>,
deller@gmx.de, javierm@redhat.com, stable@vger.kernel.org,
Changcheng Deng <deng.changcheng@zte.com.cn>,
Thorsten Leemhuis <regressions@leemhuis.info>,
Zhen Lei <thunder.leizhen@huawei.com>,
Alex Deucher <alexander.deucher@amd.com>,
Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH] video/aperture: Call sysfb_disable() before removing PCI devices
Date: Tue, 25 Oct 2022 13:36:03 +0200 [thread overview]
Message-ID: <Y1fKI7CtCaqK03tj@kroah.com> (raw)
In-Reply-To: <20221025110453.9404-1-tzimmermann@suse.de>
On Tue, Oct 25, 2022 at 01:04:53PM +0200, Thomas Zimmermann wrote:
> Call sysfb_disable() from aperture_remove_conflicting_pci_devices()
> before removing PCI devices. Without, simpledrm can still bind to
> simple-framebuffer devices after the hardware driver has taken over
> the hardware. Both drivers interfere with each other and results are
> undefined.
>
> Reported modesetting errors are shown below.
>
> ---- snap ----
> rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13-.... } 7 jiffies s: 165 root: 0x2000/.
> rcu: blocking rcu_node structures (internal RCU debug):
> Task dump for CPU 13:
> task:X state:R running task stack: 0 pid: 4242 ppid: 4228 flags:0x00000008
> Call Trace:
> <TASK>
> ? commit_tail+0xd7/0x130
> ? drm_atomic_helper_commit+0x126/0x150
> ? drm_atomic_commit+0xa4/0xe0
> ? drm_plane_get_damage_clips.cold+0x1c/0x1c
> ? drm_atomic_helper_dirtyfb+0x19e/0x280
> ? drm_mode_dirtyfb_ioctl+0x10f/0x1e0
> ? drm_mode_getfb2_ioctl+0x2d0/0x2d0
> ? drm_ioctl_kernel+0xc4/0x150
> ? drm_ioctl+0x246/0x3f0
> ? drm_mode_getfb2_ioctl+0x2d0/0x2d0
> ? __x64_sys_ioctl+0x91/0xd0
> ? do_syscall_64+0x60/0xd0
> ? entry_SYSCALL_64_after_hwframe+0x4b/0xb5
> </TASK>
> ...
> rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13-.... } 30 jiffies s: 169 root: 0x2000/.
> rcu: blocking rcu_node structures (internal RCU debug):
> Task dump for CPU 13:
> task:X state:R running task stack: 0 pid: 4242 ppid: 4228 flags:0x0000400e
> Call Trace:
> <TASK>
> ? memcpy_toio+0x76/0xc0
> ? memcpy_toio+0x1b/0xc0
> ? drm_fb_memcpy_toio+0x76/0xb0
> ? drm_fb_blit_toio+0x75/0x2b0
> ? simpledrm_simple_display_pipe_update+0x132/0x150
> ? drm_atomic_helper_commit_planes+0xb6/0x230
> ? drm_atomic_helper_commit_tail+0x44/0x80
> ? commit_tail+0xd7/0x130
> ? drm_atomic_helper_commit+0x126/0x150
> ? drm_atomic_commit+0xa4/0xe0
> ? drm_plane_get_damage_clips.cold+0x1c/0x1c
> ? drm_atomic_helper_dirtyfb+0x19e/0x280
> ? drm_mode_dirtyfb_ioctl+0x10f/0x1e0
> ? drm_mode_getfb2_ioctl+0x2d0/0x2d0
> ? drm_ioctl_kernel+0xc4/0x150
> ? drm_ioctl+0x246/0x3f0
> ? drm_mode_getfb2_ioctl+0x2d0/0x2d0
> ? __x64_sys_ioctl+0x91/0xd0
> ? do_syscall_64+0x60/0xd0
> ? entry_SYSCALL_64_after_hwframe+0x4b/0xb5
> </TASK>
>
> The problem was added by commit 5e0137612430 ("video/aperture: Disable
> and unregister sysfb devices via aperture helpers") to v6.0.3 and does
> not exist in the mainline branch.
Why isn't this a problem in Linus's tree? What commits there cause this
to not be an issue and why can't we just take them instead?
thanks,
greg k-h
next prev parent reply other threads:[~2022-10-25 11:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-25 11:04 [PATCH] video/aperture: Call sysfb_disable() before removing PCI devices Thomas Zimmermann
2022-10-25 11:04 ` Thomas Zimmermann
2022-10-25 11:36 ` Greg KH [this message]
2022-10-25 11:36 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y1fKI7CtCaqK03tj@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=alexander.deucher@amd.com \
--cc=andreas.thalhammer-linux@gmx.net \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel@ffwll.ch \
--cc=deller@gmx.de \
--cc=deng.changcheng@zte.com.cn \
--cc=dri-devel@lists.freedesktop.org \
--cc=javierm@redhat.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=regressions@leemhuis.info \
--cc=sam@ravnborg.org \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=thunder.leizhen@huawei.com \
--cc=tzimmermann@suse.de \
--cc=zackr@vmware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.