[Intel-gfx] Pointers on debugging my machine not booting: i915 GPU lockup

[Bruno Prémont]

Hey Gideon,

[CCing intel-gfx mailing list]

On Wed, 4 Jun 2014 20:22:13 +0530 Gideon D'souza wrote:
> Thank you so much for your reply.
> 
> I did manage to move a bit forward with my issue since my email here.
> When the system kinda stuck, I realized I could press Ctrl + Alt + F2
> and I had access to the system via a virtual terminal. I could connect
> to the internet and everything so it seems like the window manager is
> dead somehow, I wish I new how. It's such a beautifully customized
> system I don't want to lose it. (And I barely have time to get it up)

It seems to be just a bug somewhere in the 3D driver stack, not a
hardware issue.

If you can disable 3D and/or compositing effects you might get to your
desktop environment.

> >What kind of box is it?
> Dell Laptop, x86_64 AMD.
> 
> >If you can hook up a serial console to your box that would maybe help,
> >at least getting access to what has been shown prior to screen going blank.
> I've never fully understood what this means? Does this mean that if I
> set up the right baud rate I can then get a log/output of some sort on
> a serial cable somewhere?
> (1) I don't have a serial out on my laptop. I only have hdmi, lan and usb
> (2) If I did have a serial out, then what would I do next? Hook up a
> serial cable, connect it to another computer and then what? What would
> I install on the other end to read the input?

If you had a serial port on the laptop you could connect a second
computer to it with a null-modem cable (if needed via USB->Serial
converter) and see what output kernel generates using e.g. minicom.
Hooking up a USB->Serial converter on your laptop to get serial port
would probably not work.

> This is what the log looks like just before it hangs up:
> https://www.dropbox.com/s/gyz1sbllyqhuz10/Photo%2031-05-14%2012%2056%2038%20am.jpg
> 
> I've put up much more detail here:
> https://ask.fedoraproject.org/en/question/47850/fedora-is-busted-and-hangs-on-boot/
> 
> But no real answers yet.

Looking at your report on fedoraproject you seem to have:
- Intel GPU (which one?)
- System is booting fine, GPU is just locking up when X starts
  (what are versions of X drivers and mesa?)

Make sure to collect the error state (after GPU locked up/screen went
black, but before rebooting) as reported in your journald log
cat /sys/class/drm/card0/error | gzip -9 > /tmp/i915-error-state.gz
and attach the resulting file /tmp/i915-error-state.gz to a bug report
on https://bugs.freedesktop.org.

Also follow the guidelines listed at
  https://01.org/linuxgraphics/documentation/how-report-bugs
when you report the bug so all important information is included.

If you can do so from console, check for possible MESA or
xf86-video-intel updates. If there are none (that help), manually
compiling more recent releases or -git versions of xf86-video-intel, libdrm
and mesa might get asked.

Bruno


> On Wed, Jun 4, 2014 at 2:27 AM, Bruno Prémont wrote:
> > On Thu, 29 May 2014 "Gideon D'souza" wrote:
> >> So I usually have the latest mainline kernel (on my fedora box) I've
> >> recently sent it tiny refactoring patches.
> >
> > What kind of box is it?
> >
> >> Today, I start my machine and it just doesn't start. I had 3.11, 3.12,
> >> and a few 3.14 rcs.
> >>
> >> All show up booting, a few lines print on the screen about various
> >> things it does. At some random point the screen is just black and
> >> backlit and nothing happens. I tried all kernels, 3.11 and 3.12 and
> >> official fedora supported kernels. The rest I installed. Even the
> >> fedora rescue system doesn't work.
> >>
> >> I tried looking into remote debugging linux and keep just getting hits
> >> on virtual machine options. It's time I left my training wheels and I
> >> want to debug my actual machine and see what's going on.
> >>
> >> Several of those kernels have debugging support on. I just don't get
> >> what wire I need to buy, what really is a JTAG and I just need a
> >> pointer on how to set it up. I have another windows machine and an OSX
> >> machine around.
> >
> > JTAG is a debugging interface mostly present on ARM system (develoment
> > boards, production boards often have no corresponding pin headers).
> > x86/x86_64 system usually don't have JTAG and serial connectors are
> > getting less common...
> > Then there exists some EHCI (yes USB) based debugging interface but
> > that's all I know about it.
> >
> >> Any pointers (pun intended) will be greatly appreciated.
> >
> > If you can hook up a serial console to your box that would maybe help,
> > at least getting access to what has been shown prior to screen going blank.
> >
> > For your kernel you would need to add "console=ttyS0" possibly with
> > a few details on baud-rate (see Documentation/kernel-parameters.txt).
> >
> > Depending on your GPU and corresponding drivers, adding nouveau.modeset=0
> > or radeon.modeset=0 or i915.modeset=0 could get your further in case it's
> > a GPU issue.
> >
> > Also of interest would be whether your system is still alive or not
> > (might react to caps-lock, at least for PS2-conected keyboards), how
> > network interface behaves.
> >
> > Otherwise sharing the kernel log you see before screen goes black could
> > give a hint. If it's initializing GPU that breaks your system - black
> > screen could be just that - checking GPU power supply might be an idea,
> > especially if kernels that worked in the past don't work anymore.
> >
> > Critical information is if the "freeze" always happens during kernel
> > booting or later on when modules are being loaded by your initrd.
> > In the second case, booting with init=/bin/sh could get you a prompt.