* X hang with quirk VT switches @ 2014-12-03 14:45 Takashi Iwai 2014-12-03 18:31 ` Chris Wilson 0 siblings, 1 reply; 6+ messages in thread From: Takashi Iwai @ 2014-12-03 14:45 UTC (permalink / raw) To: intel-gfx 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. Note that the problem disappears when passing drm.debug=0x0e. And it doesn't seem to happen with a 2D desktop, either. The race window is supposed to be fairly small. The problem is reproduced reliably with xf86-video-intel 2.99.916 and the latest Linus tree on a HP laptop with IVB. Also seen on HSW and other chips, too. Does this ring a bell to anyone? thanks, Takashi _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: X hang with quirk VT switches 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 0 siblings, 2 replies; 6+ messages in thread From: Chris Wilson @ 2014-12-03 18:31 UTC (permalink / raw) To: Takashi Iwai; +Cc: Maarten Lankhorst, intel-gfx 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. Maarten found a very similar issue using radeon: https://bugs.freedesktop.org/show_bug.cgi?id=77885 where the supposition was that the DRM_MASTER was not being relinquished. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: X hang with quirk VT switches 2014-12-03 18:31 ` Chris Wilson @ 2014-12-03 19:43 ` Takashi Iwai 2014-12-04 10:53 ` Takashi Iwai 1 sibling, 0 replies; 6+ messages in thread From: Takashi Iwai @ 2014-12-03 19:43 UTC (permalink / raw) To: Chris Wilson; +Cc: Maarten Lankhorst, intel-gfx 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? I asked this to myself, too... > 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. Right, no extra option is used. And, eDP output only. > Maarten found a very similar issue using radeon: > > https://bugs.freedesktop.org/show_bug.cgi?id=77885 > > where the supposition was that the DRM_MASTER was not being > relinquished. Interesting. In the original bug report we've got, the symptom happened at switching two X sessions, as the bfo entry above. http://bugzilla.opensuse.org/show_bug.cgi?id=904097 The reporter mentioned there that his issue was fixed with 3.17.x kernel, so it's likely a different problem from what I've seen. The bug couldn't be reproduced on my machine, so I tried the simple VT quick switches, then hits a new bug now. In anyway, I'll poke a bit more deeply later (maybe on Friday). But, before that, I'd like to ask: can anyone reproduce this problem at all...? thanks, Takashi _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: X hang with quirk VT switches 2014-12-03 18:31 ` Chris Wilson 2014-12-03 19:43 ` Takashi Iwai @ 2014-12-04 10:53 ` Takashi Iwai 2014-12-04 11:21 ` Chris Wilson 1 sibling, 1 reply; 6+ messages in thread From: Takashi Iwai @ 2014-12-04 10:53 UTC (permalink / raw) To: Chris Wilson; +Cc: Maarten Lankhorst, intel-gfx 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: X hang with quirk VT switches 2014-12-04 10:53 ` Takashi Iwai @ 2014-12-04 11:21 ` Chris Wilson 2014-12-04 11:44 ` Takashi Iwai 0 siblings, 1 reply; 6+ messages in thread From: Chris Wilson @ 2014-12-04 11:21 UTC (permalink / raw) To: Takashi Iwai; +Cc: Maarten Lankhorst, intel-gfx On Thu, Dec 04, 2014 at 11:53:05AM +0100, Takashi Iwai wrote: > 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. I disagree. drm has claimed to support O_NONBLOCK since its inception, but the implementation was buggy. However, I don't think there is a case in non-ZaphodHeads where we use read() without first select/poll reporting that there is something to use (and the problem with ZaphodHeads is that we have two screens that share the same drm fd without clearing the select read flags... hmm) -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: X hang with quirk VT switches 2014-12-04 11:21 ` Chris Wilson @ 2014-12-04 11:44 ` Takashi Iwai 0 siblings, 0 replies; 6+ messages in thread From: Takashi Iwai @ 2014-12-04 11:44 UTC (permalink / raw) To: Chris Wilson; +Cc: Maarten Lankhorst, intel-gfx At Thu, 4 Dec 2014 11:21:47 +0000, Chris Wilson wrote: > > On Thu, Dec 04, 2014 at 11:53:05AM +0100, Takashi Iwai wrote: > > 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. > > I disagree. drm has claimed to support O_NONBLOCK since its inception, > but the implementation was buggy. The nonblock read is obviously buggy. If the current implementation is intentional, then the nonblock flag is somehow misused... > However, I don't think there is a case > in non-ZaphodHeads where we use read() without first select/poll > reporting that there is something to use (and the problem with > ZaphodHeads is that we have two screens that share the same drm fd > without clearing the select read flags... hmm) In my case, I'm using a single screen, so this can't be. And, my rough guess is that this isn't about the lack of poll but rather some race between poll/read or two reads. That explains why my patch worked. In anyway I'd need to trap X stall and diagnose, but I have to leave my machine now. Will check it tomorrow. Meanwhile, it's interesting to see whether this covers Maarten's case, too... thanks, Takashi _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-12-04 11:44 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 2014-12-04 11:21 ` Chris Wilson 2014-12-04 11:44 ` Takashi Iwai
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox