Pointers on debugging my machine not booting

Pointers on debugging my machine not booting

[Gideon D'souza]

Hey guys,

So I usually have the latest mainline kernel (on my fedora box) I've
recently sent it tiny refactoring patches.

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.

Any pointers (pun intended) will be greatly appreciated.

Regards,
Gideon

Re: Pointers on debugging my machine not booting

[Bruno Prémont]

Hey Gideon,

On Thu, 29 May 2014 "Gideon D'souza" <gidisrael@gmail.com> wrote:
> Hey guys,
> 
> 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.

Bruno

Re: 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.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx