Re: [Intel-gfx] [PATCH v3 6/6] freezer, sched: Rewrite core freezer logic
On 2022-10-26 at 13:43:00 +0200, Peter Zijlstra wrote:
> On Wed, Oct 26, 2022 at 01:32:31PM +0300, Ville Syrjälä wrote:
> > Short form looks to be this:
> > <4>[ 355.437846] 1 lock held by rs:main Q:Reg/359:
> > <4>[ 355.438418] #0: 88844693b758 (&rq->__lock){-.-.}-{2:2}, at:
> > raw_spin_rq_lock_nested+0x1b/0x30
> > <4>[ 355.438432] rs:main Q:Reg/359 holding locks while freezing
>
> > <4>[ 355.438429] [ cut here ]
> > <4>[ 355.438432] rs:main Q:Reg/359 holding locks while freezing
> > <4>[ 355.438439] WARNING: CPU: 0 PID: 6211 at kernel/freezer.c:134
> > __set_task_frozen+0x86/0xb0
> > <4>[ 355.438447] Modules linked in: snd_hda_intel i915 mei_hdcp mei_pxp
> > drm_display_helper drm_kms_helper vgem drm_shmem_helper snd_hda_codec_hdmi
> > snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_intel_dspcfg
> > snd_hda_codec snd_hwdep snd_hda_core snd_pcm prime_numbers ttm drm_buddy
> > syscopyarea sysfillrect sysimgblt fb_sys_fops fuse x86_pkg_temp_thermal
> > coretemp kvm_intel btusb btrtl btbcm btintel kvm irqbypass bluetooth
> > crct10dif_pclmul crc32_pclmul ecdh_generic ghash_clmulni_intel ecc e1000e
> > mei_me i2c_i801 ptp mei i2c_smbus pps_core lpc_ich video wmi [last
> > unloaded: drm_kms_helper]
> > <4>[ 355.438521] CPU: 0 PID: 6211 Comm: rtcwake Tainted: G U
> > 6.1.0-rc2-CI_DRM_12295-g3844a56a0922+ #1
> > <4>[ 355.438526] Hardware name: /NUC5i7RYB, BIOS
> > RYBDWi35.86A.0385.2020.0519.1558 05/19/2020
> > <4>[ 355.438530] RIP: 0010:__set_task_frozen+0x86/0xb0
> > <4>[ 355.438536] Code: 83 60 09 00 00 85 c0 74 2a 48 89 df e8 ac 02 9b 00
> > 8b 93 38 05 00 00 48 8d b3 48 07 00 00 48 c7 c7 a0 62 2b 82 e8 ee c1 9a 00
> > <0f> 0b c6 05 51 75 e3 02 01 c7 43 18 00 80 00 00 b8 00 80 00 00 5b
> > <4>[ 355.438541] RSP: 0018:c900012cbcf0 EFLAGS: 00010086
> > <4>[ 355.438546] RAX: RBX: 88810d090040 RCX:
> > 0004
> > <4>[ 355.438550] RDX: 0004 RSI: f5de RDI:
> >
> > <4>[ 355.438553] RBP: R08: R09:
> > c000f5de
> > <4>[ 355.438557] R10: 002335f8 R11: c900012cbb88 R12:
> > 0246
> > <4>[ 355.438561] R13: 81165430 R14: R15:
> > 88810d090040
> > <4>[ 355.438565] FS: 7fcfa43c7740() GS:88844680()
> > knlGS:
> > <4>[ 355.438569] CS: 0010 DS: ES: CR0: 80050033
> > <4>[ 355.438582] CR2: 7fceb380f6b8 CR3: 000117c5c004 CR4:
> > 003706f0
> > <4>[ 355.438586] Call Trace:
> > <4>[ 355.438589]
> > <4>[ 355.438592] task_call_func+0xc4/0xe0
> > <4>[ 355.438600] freeze_task+0x84/0xe0
> > <4>[ 355.438607] try_to_freeze_tasks+0xac/0x260
> > <4>[ 355.438616] freeze_processes+0x56/0xb0
> > <4>[ 355.438622] pm_suspend.cold.7+0x1d9/0x31c
> > <4>[ 355.438629] state_store+0x7b/0xe0
> > <4>[ 355.438637] kernfs_fop_write_iter+0x124/0x1c0
> > <4>[ 355.438644] vfs_write+0x34f/0x4e0
> > <4>[ 355.438655] ksys_write+0x57/0xd0
> > <4>[ 355.438663] do_syscall_64+0x3a/0x90
> > <4>[ 355.438670] entry_SYSCALL_64_after_hwframe+0x63/0xcd
>
> Oh I think I see what's going on.
>
> It's a very narrow race between schedule() and task_call_func().
>
> CPU0CPU1
>
> __schedule()
> rq_lock();
> prev_state = READ_ONCE(prev->__state);
> if (... && prev_state) {
> deactivate_tasl(rq, prev, ...)
> prev->on_rq = 0;
>
> task_call_func()
>
> raw_spin_lock_irqsave(p->pi_lock);
> state = READ_ONCE(p->__state);
> smp_rmb();
> if (... || p->on_rq) //
> false!!!
> rq = __task_rq_lock()
>
> ret = func();
>
> next = pick_next_task();
> rq = context_switch(prev, next)
> prepare_lock_switch()
> spin_release(&__rq_lockp(rq)->dep_map...)
>
>
>
> So while the task is on it's way out, it still holds rq->lock for a
> little while, and right then task_call_func() comes in and figures it
> doesn't need rq->lock anymore (because the task is already dequeued --
> but still running there) and then the __set_task_frozen() thing observes
> it's holding rq->lock and yells murder.
>
> Could you please give the below a spin?
>
> ---
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index cb2aa2b54c7a..f519f44cd4c7 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4200,6 +4200,37 @@ try_to_wake_up(struct task_struct *p, unsigned int
> state, int wake_flags)
> return success;
> }
>
> +static bool __task_needs_rq_lock(struct task_struct *p)
> +{
> + u
Re: [Intel-gfx] [PATCH] drm/aperture: Pass DRM driver structure instead of driver name
On Tue, Jun 29, 2021 at 9:58 PM Thomas Zimmermann wrote: > > Print the name of the DRM driver when taking over fbdev devices. Makes > the output to dmesg more consistent. Note that the driver name is only > used for printing a string to the kernel log. No UAPI is affected by this > change. > > Signed-off-by: Thomas Zimmermann > --- > drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +- Acked-by: Chen-Yu Tsai ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: manual merge of the sunxi tree with the drm-misc tree
On Tue, Mar 7, 2017 at 7:59 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the sunxi tree got a conflict in:
>
> drivers/gpu/drm/sun4i/sun4i_drv.c
>
> between commit:
>
> 50480a78e282 ("drm: sun4i: use vblank hooks in struct drm_crtc_funcs")
>
> from the drm-misc tree and commit:
>
> 1c313a69e3ea ("drm/sun4i: Move layers from sun4i_drv to sun4i_crtc")
>
> from the sunxi tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/sun4i/sun4i_drv.c
> index 9ccf7c4deb6d,1ec5b825aa64..
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@@ -20,10 -21,31 +21,8 @@@
> #include
> #include
>
> - #include "sun4i_crtc.h"
> #include "sun4i_drv.h"
> #include "sun4i_framebuffer.h"
> - #include "sun4i_layer.h"
> -#include "sun4i_tcon.h"
> -
> -static int sun4i_drv_enable_vblank(struct drm_device *drm, unsigned int
> pipe)
> -{
> - struct sun4i_drv *drv = drm->dev_private;
> - struct sun4i_tcon *tcon = drv->tcon;
> -
> - DRM_DEBUG_DRIVER("Enabling VBLANK on pipe %d\n", pipe);
> -
> - sun4i_tcon_enable_vblank(tcon, true);
> -
> - return 0;
> -}
> -
> -static void sun4i_drv_disable_vblank(struct drm_device *drm, unsigned int
> pipe)
> -{
> - struct sun4i_drv *drv = drm->dev_private;
> - struct sun4i_tcon *tcon = drv->tcon;
> -
> - DRM_DEBUG_DRIVER("Disabling VBLANK on pipe %d\n", pipe);
> -
> - sun4i_tcon_enable_vblank(tcon, false);
> -}
>
> static const struct file_operations sun4i_drv_fops = {
> .owner = THIS_MODULE,
Thanks. This looks correct when combined with the fix you sent out.
Maxime, how would you like to handle this?
ChenYu
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Could you merge the tsc patches directly from Len Brown's public repo?
Please ignore my previous patch(it is incorrect), you can cherry pick Len's 8 patches except this one: 540cc882de7d1da2e71591e215f0e04cb89883fa x86 tsc_msr: Extend to include Intel Core Architecture thanks, Yu > -Original Message- > From: Lu, Han > Sent: Friday, April 29, 2016 9:38 AM > To: 'Ville Syrjälä'; Brown, Len > Cc: 'Daniel Vetter'; Nikula, Jani; Lin, Mengdong; Yang, Libin; Li, Jocelyn; > 'intel- > gfx'; Chen, Yu C; Zhao, Juan J > Subject: RE: Could you merge the tsc patches directly from Len Brown's public > repo? > > +Juan > > Hi Yu, > > Do you have any update on your patches? We need a solution to fix the > SandyBridge hang asap, then Daniel and Jani can help to cherry-pick the tsc > patches to drm-intel repo. > > BR, > Han Lu > > > -Original Message- > > From: Lu, Han > > Sent: Wednesday, April 27, 2016 1:18 PM > > To: Ville Syrjälä ; Brown, Len > > > > Cc: Daniel Vetter ; Nikula, Jani > > ; Lin, Mengdong ; Yang, > > Libin ; Li, Jocelyn ; > > intel-gfx ; Chen, Yu C > > > > Subject: RE: Could you merge the tsc patches directly from Len Brown's > > public repo? > > > > Hi Len, > > > > Could you please share if you have any following plan to fix the > > hard-hang on SandyBridge? Will you modify patch > > 540cc882de7d1da2e71591e215f0e04cb89883fa and update your public repo? > > Thanks. > > > > BR, > > Han Lu > > > > > -Original Message- > > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > > > Sent: Wednesday, April 27, 2016 12:36 AM > > > To: Brown, Len > > > Cc: Daniel Vetter ; Lu, Han > > > ; Nikula, Jani ; Lin, > > > Mengdong ; Yang, Libin > > > ; Li, Jocelyn ; > > > intel-gfx > > > Subject: Re: Could you merge the tsc patches directly from Len > > > Brown's public repo? > > > > > > On Tue, Apr 26, 2016 at 06:46:23AM +, Brown, Len wrote: > > > > > On Wed, Apr 20, 2016 at 11:24 AM, Daniel Vetter > > > > > > > > > > wrote: > > > > > > On Wed, Apr 20, 2016 at 10:26 AM, Lu, Han > wrote: > > > > > >> Hi Jani, > > > > > >> > > > > > >> Please find the repo and commit id below: > > > > > >> Repo: > > > > > >> https://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux.gi > > > > > >> t > > > > > >> Branch: x86 > > > > > >> Commit id (begin from earliest): > > > > > >> 6e0c25e64e0fb65a42dfc63ad5f660302e07cd87 > > > > > >> 16caa2834b2f08cdfd130baa490c45822edef256 > > > > > >> ce5c7b5eaad93c7b0043a7509eec319fe0a0e8a0 > > > > > >> ca376a9909f1151484854c46dc7f01be6d6d9bdb > > > > > >> 4a62ba36cf4fb77ea35dee1f5992e0e7c48dad14 > > > > > >> 540cc882de7d1da2e71591e215f0e04cb89883fa > > > > > >> 433f82c8ab3fcaa7ff3b852d01cc74dbdf6d94f1 > > > > > >> 65ae86d4fa3473d24445ea402b190e4b4342172e > > > > > >> 3152b94afb8c27595f9b1bfa67885015cb569ba2 > > > > > >> > > > > > >> I have one silly question: if I understand correctly, these > > > > > >> patches > > > > > will be merged into a separate branch and drm-nightly both. > > > > > After a few weeks, will there be conflicts when merging from > > > > > upstream to drm-nightly, as both upstream and drm-nightly contain tsc > patches? > > > > > > > > > > > > All cherry-picked to topic/core-for-CI, pls double-check it's > > > > > > all there (scripts will take another 5 minutes or so to push > > > > > > it all out and rebuild drm-intel-nightly with those patches). > > > > > > > > > > Dropped them again because they hard-hang Ville's sandybridge on > > > > > boot-up. Adding Ville and Len and mailing lists. > > > > > > > > Does the SNB work if you revert this one?: > > > > > > > > commit 540cc882de7d1da2e71591e215f0e04cb89883fa > > > > Author: Len Brown > > > > Date: Sun Nov 29 01:21:06 2015 -0500 > > > > > > > > x86 tsc_msr: Extend to include Intel Core Architecture > > > > > > Yep, that does seem to be the bad apple. > > > > > > -- > > > Ville Syrjälä > > > Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] VGA console writting is quite time costy after resuming from S3
Hi,all When I'm doing suspend/resume S3 (suspend-to-memory, echo mem > /sys/power/state) on mainline 4.2-rc4, Skylake, I found that , the time cost for resume_console is quite long, It takes nearly 4 seconds to finish. Since there is only one console available in my system(VGA console, by checking /proc/consoles), I think after resuming from S3, VGA writing is very time costy when resume_console is trying to dump all temporary logs to console. I would be appreciate if anyone expert here can give some information on why VGA console takes some much time and would be happy to test with your suggestions, thanks! Best Regards, Yu ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
