On Sun, Nov 03, 2013 at 10:18:14PM +0100, Daniel Vetter wrote: > > On Sun, Nov 3, 2013 at 8:00 PM, Thomas Richter <thor@xxxxxxxxxxxxxxxxx> wrote: > > On 03.11.2013 18:13, Daniel Vetter wrote: > >>> > >>> Have you tried my patch to reorder the dvo sequence a bit? That /should/ > >>> get all these things right: > >>> > >>> http://www.spinics.net/lists/intel-gfx/msg34349.html > >> > >> There's also a follow-up patch for you to test: > >> > >> > >> http://www.spinics.net/lists/intel-gfx/msg34350.html > >> > >> That would prove that the first patch does indeed work. Note that patch 1 > >> in this series is already merged. > > > > Thanks, I tried. Actually, this worked fairly (but not perfectly) well. I no > > longer get a "stuck DVO" as I did before, i.e. the "re-enable" logic is not > > triggered anymore. However, I do get (occasionally) a kernel-oops: > > That's just a warning, not an oops ... > > > > > ------------[ cut here ]------------ > > WARNING: CPU: 0 PID: 2311 at drivers/gpu/drm/i915/intel_display.c:1098 > > assert_cursor.constprop.68+0xba/0xc0 [i915]() > > cursor on pipe A assertion failure (expected off, current on) > > Modules linked in: cpufreq_stats binfmt_misc michael_mic arc4 ecb > > lib80211_crypt_tkip lib80211_crypt_ccmp fuse nfsd exportfs nfs_acl nfs lockd > > fscache sunrpc loop firewire_sbp2 hostap_cs hostap snd_intel8x0 > > snd_ac97_codec ac97_bus lib80211 snd_pcm i915 snd_page_alloc snd_seq > > snd_seq_device snd_timer psmouse snd pcmcia apanel input_polldev soundcore > > yenta_socket pcmcia_rsrc pcmcia_core lpc_ich i2c_i801 mfd_core pcspkr > > i2c_algo_bit rng_core serio_raw evdev drm_kms_helper drm fujitsu_laptop > > led_class intel_agp intel_gtt agpgart i2c_core video ac button hid_generic > > usbhid hid sg sr_mod cdrom firewire_ohci firewire_core crc_itu_t 8139too > > 8139cp mii uhci_hcd usbcore usb_common > > CPU: 0 PID: 2311 Comm: Xorg Tainted: G W 3.12.0-rc7+ #13 > > Hardware name: FUJITSU SIEMENS LIFEBOOK S Series/FJNB159, BIOS Version 1.06 > > 07/02/2002 > > c12f8c44 c1033def f8ad3990 f6adfab0 00000907 f8ad25d8 0000044a f8a81ffa > > f8a81ffa f5ca8000 00000041 00000000 f5ca8000 c1033eb3 00000009 f6adfa98 > > f8ad3990 f6adfab0 f8a81ffa f8ad25d8 0000044a f8ad3990 00000041 f8adb9a0 > > Call Trace: > > [<c12f8c44>] ? dump_stack+0xa/0x13 > > [<c1033def>] ? warn_slowpath_common+0x7f/0xb0 > > [<f8a81ffa>] ? assert_cursor.constprop.68+0xba/0xc0 [i915] > > [<f8a81ffa>] ? assert_cursor.constprop.68+0xba/0xc0 [i915] > > [<c1033eb3>] ? warn_slowpath_fmt+0x33/0x40 > > [<f8a81ffa>] ? assert_cursor.constprop.68+0xba/0xc0 [i915] > > [<f8a83b90>] ? intel_disable_pipe+0x30/0xb0 [i915] > > [<f8a8491a>] ? i9xx_crtc_disable+0xca/0x2f0 [i915] > > [<f8a8b25e>] ? __intel_set_mode+0x7ae/0x13b0 [i915] > > [<f8a8e1f3>] ? intel_set_mode+0x23/0x40 [i915] > > [<f8a8e9bc>] ? intel_crtc_set_config+0x7ac/0x9d0 [i915] > > [<f802fe33>] ? drm_mode_set_config_internal+0x43/0xb0 [drm] > > [<f81386a5>] ? drm_fb_helper_set_par+0x45/0xac [drm_kms_helper] > > [<c11a7976>] ? fb_set_var+0x1a6/0x420 > > [<c10eec6e>] ? __find_get_block+0x9e/0x160 > > [<c11b56e0>] ? fbcon_blank+0x290/0x2d0 > > [<c1203848>] ? do_unblank_screen+0x98/0x1b0 > > [<c1201acd>] ? notify_update+0x1d/0x30 > > [<c11faa12>] ? complete_change_console+0x52/0xe0 > > [<c11fbba4>] ? vt_ioctl+0x1104/0x1220 > > [<f802a1d0>] ? drm_setmaster_ioctl+0xe0/0xe0 [drm] > > [<c11faaa0>] ? complete_change_console+0xe0/0xe0 > > [<c11f17da>] ? tty_ioctl+0x21a/0x9a0 > > [<c10adb12>] ? do_wp_page.isra.92+0x2a2/0x650 > > [<c10af428>] ? handle_mm_fault+0x318/0x610 > > [<c11f15c0>] ? no_tty+0x20/0x20 > > [<c10d66ac>] ? do_vfs_ioctl+0x7c/0x550 > > [<c102d221>] ? __do_page_fault+0x1b1/0x490 > > [<c10c7d17>] ? vfs_write+0x137/0x1b0 > > [<c10d6bc6>] ? SyS_ioctl+0x46/0x80 > > [<c12fc19e>] ? sysenter_do_call+0x12/0x26 > > ---[ end trace 85d231d1072e932a ]--- > > > > If this happens, I get a black screen with only a cursor on it. Switching to > > the console and back restores the screen. > > Hm, that would mean that the cursor is somehow stuck in the enabled state, > despite that we've tried to disabled it very hard. Can you please try out > the below patch? If this doesn't work please take not of the different > WARNINGs you're hitting and whether it's always the same one with the same > calltrace or something different. > > I think for now we should try to get the single monitor case working - I > have a few theories for the dual-screen issues, but there's not much point > working on them if the simple case doesn't work yet. > > Also I think I'll merge the two patches if they don't make things worse > for you, imo it's the right approach and at least conceptually should be > able to avoid all these retry loops. > > Thanks, Daniel > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c > index f34252d134b6..04d2699f51b4 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -7123,7 +7123,9 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, u32 base) > intel_crtc->cursor_visible = visible; > } > /* and commit changes on next vblank */ > + POSTING_READ(CURCNTR(pipe)); > I915_WRITE(CURBASE(pipe), base); > + POSTING_READ(CURBASE(pipe)); > } > > static void ivb_update_cursor(struct drm_crtc *crtc, u32 base) > @@ -7152,7 +7154,9 @@ static void ivb_update_cursor(struct drm_crtc *crtc, u32 base) > intel_crtc->cursor_visible = visible; > } > /* and commit changes on next vblank */ > + POSTING_READ(CURCNTR_IVB(pipe)); > I915_WRITE(CURBASE_IVB(pipe), base); > + POSTING_READ(CURBASE_IVB(pipe)); > } To clarify: Do you need this patch to make the single-pipe mode work reliably? It's a bit unclear in your answer ... Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
