Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: X hang with quirk VT switches
Date: Thu, 04 Dec 2014 11:53:05 +0100	[thread overview]
Message-ID: <s5hd27zr8j2.wl-tiwai@suse.de> (raw)
In-Reply-To: <20141203183145.GB25773@nuc-i3427.alporthouse.com>

At Wed, 3 Dec 2014 18:31:45 +0000,
Chris Wilson wrote:
> 
> On Wed, Dec 03, 2014 at 03:45:35PM +0100, Takashi Iwai wrote:
> > Hi,
> > 
> > while checking the reported bug about VT switch hang on openSUSE 13.2,
> > I also could reproduce a similar issue as reported: namely, X hangs
> > when repeatedly switching VT quickly.
> > 
> > For example, running the following on KDE results in the stall of X.
> > 
> > 	% for i in $(seq 1 100); do chvt 1; chvt 7; done
> > 
> > Looking at the sysrq-t output, it stalls at drm_read().  And after
> > putting some debug prints at event handling codes, it shows like:
> > 
> >  drm_queue_vblank_event event_space=4064
> >  send_vblank_event event_space=4064
> >  drm_poll ENTER event_space=4064
> >  drm_poll mask=0x41 event_space=4064
> >  drm_poll ENTER event_space=4064
> >  drm_poll mask=0x41 event_space=4064
> >  drm_read ENTER event_space=4064
> >  drm_read total=32 event_space=4096
> >  drm_poll ENTER event_space=4096
> >  drm_poll mask=0x0 event_space=4096
> >  drm_read ENTER event_space=4096
> >  drm_read ENTER event_space=4096
> >  drm_read ENTER event_space=4096
> > 
> > So, after a vblank event, two poll calls succeeded, followed by one
> > drm_read().  After that, there were one poll call without event,
> > followed by three(!) drm_read() calls.  The last three drm_read()
> > never exited, thus X stalled.  So, this looks like a race or a
> > refcount issue somewhere.
> 
> The key question is how did you get 3 calls to drm_read that each didn't
> return? The only place where we call drm_read without first doing a poll
> is in the WakeupHandler with the drm fd flagged for reads. This is
> broken in ZaphodHeads as the drm fd is not O_NONBLOCK without
> 
> commit bd008e5b2953186fc0c6633a885ade95e7043800
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Tue Oct 7 14:13:51 2014 +0100
> 
>     drm: Implement O_NONBLOCK support on /dev/dri/cardN
> 
> I assume that isn't the case as I expect you would have mentioned using
> ZaphodHeads.

I took a look back at drm_read() code again, and I found that the
function doesn't care about O_NONBLOCK at all.  (And there is a memory
leak, too.)

So I added the support for O_NONBLOCK, and the problem seems
resolved.

Although this is no right "fix" (the caller side should be fixed), it
would be good to have in anyway.  I'm going to send patches for review
to dri-devel ML, as it's no i915 specific.


thanks,

Takashi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2014-12-04 10:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-03 14:45 X hang with quirk VT switches Takashi Iwai
2014-12-03 18:31 ` Chris Wilson
2014-12-03 19:43   ` Takashi Iwai
2014-12-04 10:53   ` Takashi Iwai [this message]
2014-12-04 11:21     ` Chris Wilson
2014-12-04 11:44       ` Takashi Iwai

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=s5hd27zr8j2.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=maarten.lankhorst@canonical.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox