Re: test patch for zswap bug
On 8/19/19 3:29 PM, Chris Murphy wrote: Hi, Is it possible to get the following test patch in a Rawhide kernel as a one off for testing? Or is that a PITA? Ordinarily I'd just build a kernel myself locally, but that build machine is in a very confused Rawhide<-->Branched state and so I can't. But that led me to wonder about the general case of whether it's ordinary to request test patches for testing in Rawhide kernels, or if such things considered out of scope until they get merged? https://bugzilla.kernel.org/attachment.cgi?id=284507&action=diff We generally prefer not to bring in patches for testing in rawhide. It's easy to bring a patch in but much harder to drop one. https://koji.fedoraproject.org/koji/taskinfo?taskID=37168533 Here's a scratch build that should have the patch. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
test patch for zswap bug
Hi, Is it possible to get the following test patch in a Rawhide kernel as a one off for testing? Or is that a PITA? Ordinarily I'd just build a kernel myself locally, but that build machine is in a very confused Rawhide<-->Branched state and so I can't. But that led me to wonder about the general case of whether it's ordinary to request test patches for testing in Rawhide kernels, or if such things considered out of scope until they get merged? https://bugzilla.kernel.org/attachment.cgi?id=284507&action=diff -- Chris Murphy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 2/2] drm/nouveau: Only recalculate PBN/VCPI on mode/connector changes
On Fri, Aug 16, 2019 at 4:25 PM Lyude Paul wrote:
>
> I -thought- I had fixed this entirely, but it looks like that I didn't
> test this thoroughly enough as we apparently still make one big mistake
> with nv50_msto_atomic_check() - we don't handle the following scenario:
>
> * CRTC #1 has n VCPI allocated to it, is attached to connector DP-4
> which is attached to encoder #1. enabled=y active=n
> * CRTC #1 is changed from DP-4 to DP-5, causing:
> * DP-4 crtc=#1→NULL (VCPI n→0)
> * DP-5 crtc=NULL→#1
> * CRTC #1 steals encoder #1 back from DP-4 and gives it to DP-5
> * CRTC #1 maintains the same mode as before, just with a different
> connector
> * mode_changed=n connectors_changed=y
> (we _SHOULD_ do VCPI 0→n here, but don't)
>
> Once the above scenario is repeated once, we'll attempt freeing VCPI
> from the connector that we didn't allocate due to the connectors
> changing, but the mode staying the same. Sigh.
>
> Since nv50_msto_atomic_check() has broken a few times now, let's rethink
> things a bit to be more careful: limit both VCPI/PBN allocations to
> mode_changed || connectors_changed, since neither VCPI or PBN should
> ever need to change outside of routing and mode changes.
>
> Changes since v1:
> * Fix accidental reversal of clock and bpp arguments in
> drm_dp_calc_pbn_mode() - William Lewis
>
> Signed-off-by: Lyude Paul
> Reported-by: Bohdan Milar
> Tested-by: Bohdan Milar
> Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST")
> References: 412e85b60531 ("drm/nouveau: Only release VCPI slots on mode
> changes")
> Cc: Lyude Paul
> Cc: Ben Skeggs
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Jerry Zuo
> Cc: Harry Wentland
> Cc: Juston Li
> Cc: Laurent Pinchart
> Cc: Karol Herbst
> Cc: Ilia Mirkin
> Cc: # v5.1+
> Acked-by: Ben Skeggs
> Signed-off-by: Dave Airlie
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20190809005307.18391-1-ly...@redhat.com
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 22 +-
> 1 file changed, 13 insertions(+), 9 deletions(-)
>
Applied, should make all 5.2.10 and newer builds.
Thanks,
Justin
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 847b7866137d..bdaf5ffd2504 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -766,16 +766,20 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
> struct nv50_head_atom *asyh = nv50_head_atom(crtc_state);
> int slots;
>
> - /* When restoring duplicated states, we need to make sure that the
> -* bw remains the same and avoid recalculating it, as the connector's
> -* bpc may have changed after the state was duplicated
> -*/
> - if (!state->duplicated)
> - asyh->dp.pbn =
> - drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
> -connector->display_info.bpc * 3);
> + if (crtc_state->mode_changed || crtc_state->connectors_changed) {
> + /*
> +* When restoring duplicated states, we need to make sure that
> +* the bw remains the same and avoid recalculating it, as the
> +* connector's bpc may have changed after the state was
> +* duplicated
> +*/
> + if (!state->duplicated) {
> + const int bpp = connector->display_info.bpc * 3;
> + const int clock = crtc_state->adjusted_mode.clock;
> +
> + asyh->dp.pbn = drm_dp_calc_pbn_mode(clock, bpp);
> + }
>
> - if (crtc_state->mode_changed) {
> slots = drm_dp_atomic_find_vcpi_slots(state, &mstm->mgr,
> mstc->port,
> asyh->dp.pbn);
> --
> 2.21.0
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 1/2] drm/nouveau: Only release VCPI slots on mode changes
On Fri, Aug 16, 2019 at 4:25 PM Lyude Paul wrote:
>
> Looks like a regression got introduced into nv50_mstc_atomic_check()
> that somehow didn't get found until now. If userspace changes
> crtc_state->active to false but leaves the CRTC enabled, we end up
> calling drm_dp_atomic_find_vcpi_slots() using the PBN calculated in
> asyh->dp.pbn. However, if the display is inactive we end up calculating
> a PBN of 0, which inadvertently causes us to have an allocation of 0.
> >From there, if userspace then disables the CRTC afterwards we end up
> accidentally attempting to free the VCPI twice:
>
> WARNING: CPU: 0 PID: 1484 at drivers/gpu/drm/drm_dp_mst_topology.c:3336
> drm_dp_atomic_release_vcpi_slots+0x87/0xb0 [drm_kms_helper]
> RIP: 0010:drm_dp_atomic_release_vcpi_slots+0x87/0xb0 [drm_kms_helper]
> Call Trace:
> drm_atomic_helper_check_modeset+0x3f3/0xa60 [drm_kms_helper]
> ? drm_atomic_check_only+0x43/0x780 [drm]
> drm_atomic_helper_check+0x15/0x90 [drm_kms_helper]
> nv50_disp_atomic_check+0x83/0x1d0 [nouveau]
> drm_atomic_check_only+0x54d/0x780 [drm]
> ? drm_atomic_set_crtc_for_connector+0xec/0x100 [drm]
> drm_atomic_commit+0x13/0x50 [drm]
> drm_atomic_helper_set_config+0x81/0x90 [drm_kms_helper]
> drm_mode_setcrtc+0x194/0x6a0 [drm]
> ? vprintk_emit+0x16a/0x230
> ? drm_ioctl+0x163/0x390 [drm]
> ? drm_mode_getcrtc+0x180/0x180 [drm]
> drm_ioctl_kernel+0xaa/0xf0 [drm]
> drm_ioctl+0x208/0x390 [drm]
> ? drm_mode_getcrtc+0x180/0x180 [drm]
> nouveau_drm_ioctl+0x63/0xb0 [nouveau]
> do_vfs_ioctl+0x405/0x660
> ? recalc_sigpending+0x17/0x50
> ? _copy_from_user+0x37/0x60
> ksys_ioctl+0x5e/0x90
> ? exit_to_usermode_loop+0x92/0xe0
> __x64_sys_ioctl+0x16/0x20
> do_syscall_64+0x59/0x190
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> WARNING: CPU: 0 PID: 1484 at drivers/gpu/drm/drm_dp_mst_topology.c:3336
> drm_dp_atomic_release_vcpi_slots+0x87/0xb0 [drm_kms_helper]
> ---[ end trace 4c395c0c51b1f88d ]---
> [drm:drm_dp_atomic_release_vcpi_slots [drm_kms_helper]] *ERROR* no VCPI for
> [MST PORT:e288eb7d] found in mst state 8e642070
>
> So, fix this by doing what we probably should have done from the start: only
> call drm_dp_atomic_find_vcpi_slots() when crtc_state->mode_changed is set, so
> that VCPI allocations remain for as long as the CRTC is enabled.
>
> Signed-off-by: Lyude Paul
> Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST")
> Cc: Lyude Paul
> Cc: Ben Skeggs
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Jerry Zuo
> Cc: Harry Wentland
> Cc: Juston Li
> Cc: Karol Herbst
> Cc: Laurent Pinchart
> Cc: Ilia Mirkin
> Cc: # v5.1+
> Acked-by: Ben Skeggs
> Signed-off-by: Dave Airlie
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20190801220216.15323-1-ly...@redhat.com
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
This patch was included in 5.2.7 stable upstream.
Justin
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 4b1650f51955..847b7866137d 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -775,7 +775,7 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
> drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
> connector->display_info.bpc * 3);
>
> - if (drm_atomic_crtc_needs_modeset(crtc_state)) {
> + if (crtc_state->mode_changed) {
> slots = drm_dp_atomic_find_vcpi_slots(state, &mstm->mgr,
> mstc->port,
> asyh->dp.pbn);
> --
> 2.21.0
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 2/9] Drop cpumask auto select patch
On 8/16/19 2:55 PM, Paul Bolle wrote: Hi Laura, Laura Abbott schreef op do 15-08-2019 om 15:57 [-0400]: .../fedora/generic/x86/x86_64/CONFIG_NR_CPUS | 2 +- kernel.spec | 2 -- ...-CPUMASK_OFFSTACK-usable-without-deb.patch | 34 --- 3 files changed, 1 insertion(+), 37 deletions(-) delete mode 100644 lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch diff --git a/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS b/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS index 27d187f4d..9ce2b2de6 100644 --- a/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS +++ b/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS @@ -1 +1 @@ -CONFIG_NR_CPUS=1024 +CONFIG_NR_CPUS=512 This patch needs an included regeneration of the kernel-*.config files to be complete. Thanks, Paul Bolle Thanks for the reminder ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 2/9] Drop cpumask auto select patch
On 8/16/19 2:57 PM, Paul Bolle wrote: Florian Weimer schreef op vr 16-08-2019 om 14:04 [+0200]: RHEL has a larger NR_CPU value, though. For example, it's 8192 on x86-64, while Fedora 31 has 1024. On the Fedora x86-64 debug builds it's 8192 again. Why's that? Paul Bolle That's the option for max cpus. We don't want to turn it on in all Fedora builds since it would use up more resources we probably don't actually need. Turning on for debugging in Fedora is okay though. RHEL is focused on larger footprints and makes the trade off to have it enabled all the time. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
