lkml.org 
[lkml]   [2013]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: i915 black screen introduced by ACPI changes
From
On Wed, Feb 20, 2013 at 8:17 AM, Chris Li <lkml@chrisli.org> wrote:
> On Tue, Feb 19, 2013 at 12:52 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>> Well it definitely sounds i915 related. I was just thinking that if
>> certain bits were routed to the nvidia chip instead of the i915 one,
>> the i915 driver may get confused and panic.
>
> That is certainly possible.
>
>> For debugging, you could modify the modeset_init function in i915_dma.c
>> and make it return early with an error. You could use that to narrow
>> down which part of init was failing.
>
> I did try that. It seems there is not fail at modeset_init function. The
> function complete successfully. Here is the related section.
> [i915 Hack] was the line add by me.
>
> There is one line said: "vgaarb: transferring owner from
> PCI:0000:00:02.0 to PCI:0000:01:00.0".
> Does it mean the display switch to the Nvidia video card?

vgaarb is just about legacy VGA access routing, gpu switching is done
with vgaswitcheroo (if you have such a platform). Still, it could be
that the bios exposes different such interfaces with the differen acpi
os name. Can you please check the dmesg of a working kernel (or attach
it)?

> [ 4.917591] i915 0000:00:02.0: setting latency timer to 64
> [ 4.962649] i915 0000:00:02.0: irq 43 for MSI/MSI-X
> [ 4.962656] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [ 4.962660] [drm] Driver supports precise vblank timestamp query.
> [ 4.962663] [i915 Hack] enter modeset
> [ 4.962670] [i915 Hack] after intel_parse_bios
> [ 4.962672] [i915 Hack] after vga_client_register
> [ 4.962727] [i915 Hack] after intel_register_dsm_handler
> [ 4.962730] [i915 Hack] after intel_switchroo_register_client
> [ 4.962733] [i915 Hack] after i915_gen_init_stolen
> [ 4.962752] vgaarb: device changed decodes:
> PCI:0000:00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem
> [ 4.962757] vgaarb: transferring owner from PCI:0000:00:02.0 to
> PCI:0000:01:00.0
> [ 5.018486] [i915 Hack] after intel_modeset_init
> [ 5.020823] [i915 Hack] after i915_gem_init
> [ 5.020869] [i915 Hack] after intel_modeset_gem_init
> [ 5.020892] [i915 Hack] after drm_irq_install
> [ 5.051980] fbcon: inteldrmfb (fb0) is primary device
> [ 5.089303] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1,
> id: 0x1e2b1, caps: 0xd00123/0x840300/0x123c00, board id: 1800, fw id:
> 1087391
> [ 5.202472] input: SynPS/2 Synaptics TouchPad as
> /devices/platform/i8042/serio1/input/input5
> [ 5.711448] Console: switching to colour frame buffer device 240x67
> [ 5.722628] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
> [ 5.722630] i915 0000:00:02.0: registered panic notifier
> [ 5.722633] [i915 Hack] after intel_fbdev_init
> [ 5.722634] [i915 Hack] after drm_kms_helper_poll_init
> [ 5.722635] [i915 Hack] exit mode switch
> [ 5.722682] nouveau 0000:01:00.0: enabling device (0006 -> 0007)
> [ 5.723017] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS
> [ 5.733222] acpi device:3c: registered as cooling_device8
> [ 5.733587] ACPI: Video Device [PEGP] (multi-head: yes rom: yes post: no)
> [ 5.733746] input: Video Bus as
> /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:3a/LNXVIDEO:00/input/input6
> [ 5.745904] acpi device:48: registered as cooling_device9
>
> I attach the dmesg and config of the kernel. It is with the tip of git tree.
>
> BTW, my previous claim was wrong about the kernel is dead. It turn out the
> wifi is usable after the black screen, I just need to wait long
> enough. The kernel
> has no panic at all. That explains why I didnot get a kernel crash
> dump previously.
> The caps locks LED actually works.

Starts to smell like a bog-standard i915 black screen bug (albeit with
a strange cause for the regression). Can you please boot the broken
kernels again with drm.debug=0xe and grab the complete dmesg?
Depending upon how long it takes for your wifi to get up, you might
need to extend the log buffer, it dumps a lot.

Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


\
 
 \ /
  Last update: 2013-02-20 12:21    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site