Re: bisected: i915 modeset broken in ac9b8236551d1177fd07b56aef9b565d1864420d

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Mon, Dec 14, 2015 at 03:31:09PM +0200, Meelis Roos wrote:
> > Between 4.4-rc3 and 4.4-rc4, i915 modesetting broke on my i5-2400 PC. 
> 
> That would seem to be SNB.

Yes.

> > Instead of seeing the new dense graphics mode, I see the last VGA text 
> > lines and no X appears either.
> 
> That's a bit weird. SNB has no power power wells, so only runtime PM
> could be a factor, but it should not kick in that fast during boot even
> if you enable it before loading the driver since we set the delay to 10
> seconds.
> 
> And in any case the commit you list shouldn't really change anything
> for SNB. We used to grab a rpm reference for gmbus via
> intel_aux_display_runtime_get() and now we get it via the GMBUS power
> domain instead.

I captured dmesg from failing boot, from system logs. gmbus has 
something to do with it:

[drm:i915_dump_device_info] i915 device info: gen=6, pciid=0x0102 
rev=0x09 flags=need_gfx_hws,has_fbc,has_hotplug,has_llc,
[drm:intel_detect_pch] Found CougarPoint PCH
[drm] Memory usable by graphics device = 2048M
[drm:i915_gem_gtt_init] GMADR size = 256M
[drm:i915_gem_gtt_init] GTT stolen size = 32M
[drm:i915_gem_gtt_init] ppgtt mode: 1
[drm] Replacing VGA console driver
Console: switching to colour dummy device 80x25
BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [<ffffffff81519c74>] __mutex_lock_slowpath+0x74/0x100
PGD 0 
Oops: 0002 [#1] SMP 
Modules linked in: i915(+) x86_pkg_temp_thermal kvm_intel kvm irqbypass video crc32c_intel i2c_algo_bit aesni_intel aes_x86_64 glue_helper lrw drm_kms_helper syscopyarea sysfillrect ablk_helper cryptd iTCO_wdt sysimgblt iTCO_vendor_support fb_sys_fops snd_hda_codec_realtek drm psmouse snd_hda_codec_generic e1000e xhci_pci xhci_hcd snd_hda_intel pcspkr snd_hda_codec snd_hwdep snd_hda_core snd_pcm_oss snd_mixer_oss i2c_i801 snd_pcm ehci_pci ehci_hcd nuvoton_cir usbcore snd_timer parport_pc ptp pps_core evdev rc_core parport snd usb_common soundcore tpm_tis tpm floppy lpc_ich mfd_core md_mod w83627ehf hwmon_vid coretemp hwmon eeprom i2c_core loop autofs4
CPU: 0 PID: 390 Comm: systemd-udevd Not tainted 4.4.0-rc2-00006-gac9b823 #185
Hardware name:                  /DQ67OW, BIOS SWQ6710H.86A.0066.2012.1105.1504 11/05/2012
task: ffff8800b7e48c40 ti: ffff880233420000 task.ti: ffff880233420000
RIP: 0010:[<ffffffff81519c74>]  [<ffffffff81519c74>] __mutex_lock_slowpath+0x74/0x100
RSP: 0018:ffff880233423620  EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff8800b6a594f8 RCX: ffff8800b7e48c40
RDX: 0000000000000001 RSI: ffff8800b7e48c40 RDI: ffff8800b6a594fc
RBP: ffff880233423670 R08: 0000000000000000 R09: 0000000000000001
R10: ffff8800b6a507e8 R11: 0000000000000013 R12: ffff8800b7e48c40
R13: ffff8800b6a594fc R14: 00000000ffffffff R15: ffff8800b6a59500
FS:  00007f58846428c0(0000) GS:ffff88023e200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000233424000 CR4: 00000000000406f0
Stack:
 ffff8800b6a59500 0000000000000000 ffff8802353b7148 0000000000000206
 ffff8800b6a50000 ffff8800b6a594f8 000000000000001d ffff8800b6a594f8
 ffff8800b6a50000 ffff8800b6a50000 00000000fffeea06 ffffffff81519d1b
Call Trace:
 [<ffffffff81519d1b>] ? mutex_lock+0x1b/0x30
 [<ffffffffa0423859>] ? intel_display_power_get+0x29/0xe0 [i915]
 [<ffffffffa04af048>] ? gmbus_xfer+0x38/0x680 [i915]
 [<ffffffff81073113>] ? try_to_wake_up+0x43/0x320
 [<ffffffffa0015cc6>] ? __i2c_transfer+0x106/0x380 [i2c_core]
 [<ffffffffa0015fad>] ? i2c_transfer+0x6d/0xa0 [i2c_core]
 [<ffffffffa0016185>] ? i2c_smbus_xfer_emulated+0x105/0x4c0 [i2c_core]
 [<ffffffff81086f3e>] ? __wake_up_common+0x4e/0x90
 [<ffffffff812a7cab>] ? idr_get_empty_slot+0x18b/0x390
 [<ffffffffa0016658>] ? i2c_smbus_xfer+0x118/0x2e0 [i2c_core]
 [<ffffffffa00168e5>] ? i2c_default_probe+0xc5/0x110 [i2c_core]
 [<ffffffffa00154d9>] ? i2c_check_addr_busy+0x39/0x60 [i2c_core]
 [<ffffffffa0018339>] ? i2c_do_add_adapter+0x159/0x260 [i2c_core]
 [<ffffffffa0018440>] ? i2c_do_add_adapter+0x260/0x260 [i2c_core]
 [<ffffffff81382b85>] ? bus_for_each_drv+0x55/0x90
 [<ffffffffa0017fb6>] ? i2c_register_adapter+0x1c6/0x320 [i2c_core]
 [<ffffffffa04afa80>] ? intel_setup_gmbus+0x220/0x310 [i915]
 [<ffffffffa04ba1eb>] ? i915_driver_load+0x4eb/0x15e0 [i915]
 [<ffffffffa026493c>] ? drm_dev_register+0x9c/0xb0 [drm]
 [<ffffffffa0266c49>] ? drm_get_pci_dev+0x89/0x1d0 [drm]
 [<ffffffff812d8c71>] ? pci_device_probe+0x81/0xe0
 [<ffffffff81384857>] ? driver_probe_device+0x147/0x310
 [<ffffffff81384a9b>] ? __driver_attach+0x7b/0x80
 [<ffffffff81384a20>] ? driver_probe_device+0x310/0x310
 [<ffffffff81382ada>] ? bus_for_each_dev+0x5a/0x90
 [<ffffffff81383e34>] ? bus_add_driver+0x1a4/0x220
 [<ffffffffa033c000>] ? 0xffffffffa033c000
 [<ffffffff813851e7>] ? driver_register+0x57/0xc0
 [<ffffffff810003b1>] ? do_one_initcall+0x81/0x1b0
 [<ffffffff8116b601>] ? kmem_cache_alloc_trace+0x31/0x120
 [<ffffffff8111fb77>] ? do_init_module+0x5b/0x1dc
 [<ffffffff810c16c2>] ? load_module+0x1e52/0x2220
 [<ffffffff810be3b0>] ? __symbol_put+0x50/0x50
 [<ffffffff810c1c35>] ? SyS_finit_module+0x85/0x90
 [<ffffffff8151b9db>] ? entry_SYSCALL_64_fastpath+0x16/0x6a
Code: e8 c2 1a 00 00 8b 03 83 f8 01 0f 84 92 00 00 00 48 8b 43 10 4c 8d 7b 08 48 89 63 10 41 be ff ff ff ff 4c 89 3c 24 48 89 44 24 08 <48> 89 20 4c 89 64 24 10 eb 19 49 c7 04 24 02 00 00 00 c6 43 04 
RIP  [<ffffffff81519c74>] __mutex_lock_slowpath+0x74/0x100
 RSP <ffff880233423620>
CR2: 0000000000000000
---[ end trace 5e2e7e41ffefe21d ]---


> So this bisect result is somewhat mysterious. A full dmesg with
> drm.debug=0xe with and without the offending patch reverted would be
> helpful. And might be best to attach those into a bug report
> (https://bugs.freedesktop.org/ -> DRI -> DRM/Intel) so that we don't
> lose track of them.

Full dmesgs at https://bugs.freedesktop.org/show_bug.cgi?id=93608

> 
> Oh, are we even talking about HDMI/DVI here, or something else?

DVI

> 
> > 
> > I saw something similar on I865G but have not had time to check if it is 
> > the same issue.
> > 
> > ac9b8236551d1177fd07b56aef9b565d1864420d is the first bad commit
> > commit ac9b8236551d1177fd07b56aef9b565d1864420d
> > Author: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> > Date:   Fri Nov 27 18:55:26 2015 +0200
> > 
> >     drm/i915: Introduce a gmbus power domain
> >     
> >     Currently the gmbus code uses intel_aux_display_runtime_get/put in an
> >     effort to make sure the hardware is powered up sufficiently for gmbus.
> >     That function only takes the runtime PM reference which on VLV/CHV/BXT
> >     is not enough. We need the disp2d/pipe-a well on VLV/CHV and power well
> >     2 on BXT. So add a new power domnain for gmbus and kill off the now
> >     unused intel_aux_display_runtime_get/put. And change
> >     intel_hdmi_set_edid() to use the gmbus power domain too since that's all
> >     we need there.
> >     
> >     Also toss in a BUILD_BUG_ON() to catch problems if we run out of
> >     bits for power domains. We're already really close to the limit...
> >     
> >     [Patrik: Add gmbus string to debugfs output]
> >     
> >     Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> >     Reviewed-by: Patrik Jakobsson <patrik.jakobsson@xxxxxxxxxxxxxxx>
> >     [Cherry-picked from drm-intel-next-queued f0ab43e6 (Imre)]
> >     Signed-off-by: Imre Deak <imre.deak@xxxxxxxxx>
> >     Link: http://patchwork.freedesktop.org/patch/msgid/1448643329-18675-3-git-send-email-imre.deak@xxxxxxxxx
> >     Signed-off-by: Jani Nikula <jani.nikula@xxxxxxxxx>
> > 
> > :040000 040000 39379146d7e6dda8a4d5f8781ee3d307cce8c47e f4f09fae0485ad6263d31d425296fa9cd7de343b M     drivers
> > 
> > 
> > -- 
> > Meelis Roos (mroos@xxxxxxxx)
> 
> 

-- 
Meelis Roos (mroos@xxxxxxxx)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux