[Intel-gfx] i915 GPU lockup
Gideon D'souza
gidisrael at gmail.com
Sun Jun 8 21:02:38 CEST 2014
Hey Bruno,
So I got my system up and running finally by just doing a sudo yum update.
So it seems like the problem is fixed is a newer library. I looked at :
https://bugs.freedesktop.org
But I can't seem to find a decent subgroup to file my bug into? also,
the information I send into the report will be "wrong" since all my
packages got updated.
I've attached two files to this email anyway.
Thanks very much,
Gideon
On Thu, Jun 5, 2014 at 1:58 PM, Bruno Prémont <bonbons at linux-vserver.org> wrote:
> Hey Gideon,
>
> On Thu, 5 Jun 2014 13:02:11 +0530 Gideon D'souza wrote:
>> Thank you so infinitely much for replying Bruno :)
>>
>> Few questions:
>>
>> 1> When I did "cat /sys/class/drm/card0/error" I get an endless stream
>> of hex values on the console, is this expected? Or was it because I
>> booted, went into the Virtual Terminal and then used the system for a
>> while, and then tried "cat ..."
>
> Those hex values are the interesting ones for developers.
>
> You need to perform the piping to collect them into a file or pass them
> over to a program to do something useful with them.
>
> Hence my suggestion to
> cat /sys/class/drm/card0/error | gzip -9 > /tmp/i915-error-state.gz
> ^^^
> program to read the (special) file
> ^
> pass output to next program
> ^^^^
> program to compress the data
> ^
> pass the compressed output to a a file
> ^^^^^^^^^^^^^^^^^^^^^^^^
> file to upload to bug report
>
>> 2> I booted the kernel with nomodeset and this got my desktop back. I
>> don't fully understand what it's doing and why that fixes things.
>
> nomodeset is disabling Intel graphics driver and forcing your system
> to boot on a VGA/VESA console/framebuffer with no acceleration at all.
>
> This you don't execute any of the acceleration that causes the GPU
> to freeze.
>
>> 3> By MESA you mean the mesa 3d grfx library right?
>
> Exactly.
>
>> I will send a bug report soon.
>
>
> Note, when replying to mails make sure to keep all recipients,
> especially the lists!
> So do reply-to-all instead of simple reply.
>
>
>> Thanks again.
>>
>> On Thu, Jun 5, 2014 at 11:38 AM, Bruno Prémont
>> <bonbons at linux-vserver.org> wrote:
>> > 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: i915-error-state.gz
Type: application/x-gzip
Size: 307790 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20140609/db7a9d50/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: journalctl.log
Type: text/x-log
Size: 167588 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20140609/db7a9d50/attachment-0001.bin>
More information about the Intel-gfx
mailing list