[Bug 86551] Screen freezes on boot at "fb: switching to inteldrmfb from simple"

[bugzilla-daemon at bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=86551

--- Comment #3 from Imre Deak <imre.deak at intel.com> ---
(In reply to Mike Auty from comment #2)
> I'm sorry, I have tried, but the tablet has no ethernet port, and no serial
> port, so I've tried using a USB ethernet adaptor (which the machine detects
> fine), but I've tried netconsole on a kernel I *can* get to boot, and I'm
> not getting any packets (netconsole is compiled in to the kernel, and I've
> tried it both with no parameters other than a target IP, and also giving it
> a ports, IPs and the interface name, using the stable naming scheme).  As
> for serial console, I have one USB serial adaptor, and no machines with a
> native serial port, so no way to see what's coming out of the serial adaptor
> (if anything).  So I'm afraid I have no way of recovering the data you've
> asked for.

Ok, I know the pain of getting logs from contemporary systems:) Most (all?) of
the USB ethernet adapters won't work since they lack netpolling support which
is needed by netconsole. Other possibilities you could check:

- serial port exposed via a USB device port (if your machine has any),
  that you can access via a normal USB cable and the FTDI driver on
  your host

- ramoops. See Documentation/ramoops and
  https://bugs.freedesktop.org/show_bug.cgi?id=76520#c27 to set it up.
  The RAM contents may get reset if you reboot by power off/on, so you may
  need the following kernel options too:
  CONFIG_LOCKUP_DETECTOR
  CONFIG_BOOTPARAM_HARDLOCKUP_PANIC
  CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC
  CONFIG_BOOTPARAM_HUNG_TASK_PANIC

  and boot with the kernel parameter panic=5.

> Are there any other tests I can run, or further information I can provide
> that might help?  I was hoping that the specific git commit that I mentioned
> in my initial comment might help narrow down the issue?

That commit is "drm/i915: respect the VBT minimum backlight brightness" and
does some backlight level scaling. I can't see how that could lead to a lockup,
so could you try its parent commit 1de6068eb several times to be sure the
bisect result is correct and it's not just some timing issue?

It's just a wild guess, but could you try if the patch at
https://lkml.org/lkml/2014/10/2/254 helps?

Also please give a try to the latest drm-intel-nightly kernel:
git://anongit.freedesktop.org/drm-intel drm-intel-nightly branch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.