registry team mailing list archive
-
registry team
-
Mailing list archive
-
Message #15191
[Bug 28326] Re: i810 Xv crashes after suspend -> infinite resprawn
Launchpad has imported 27 comments from the remote bug at
http://bugs.freedesktop.org/show_bug.cgi?id=10798.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2007-04-28T10:11:47+00:00 lcampagn wrote:
I am using the i810 driver on a Lenovo X60 tablet running
kubuntu/feisty. lspci calls my video device an "Intel Corporation Mobile
945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03)".
When I resume from suspend on my machine, about half of the time the X
server will start, freeze, and restart in an infinite loop. The X log
from this crash contains the following:
Error in I830WaitLpRing(), now is 353619, start is 351618
pgetbl_ctl: 0x3ffc0001 pgetbl_err: 0x0
ipeir: 0 iphdr: c000720
LP ring tail: 8 head: 18 len: 1f001 start 0
eir: 0 esr: 0 emr: ffff
instdone: ffc1 instpm: 0
memmode: 306 instps: f84cc
hwstam: ffff ier: a2 imr: ffff iir: 0
space: 8 wanted 80
DRIUnlock called when not locked
(II) I810(0): [drm] removed 1 reserved context for kernel
(II) I810(0): [drm] unmapping 8192 bytes of SAREA 0xf8fdf000 at 0xb7c25000
Fatal server error:
lockup
This bug appears to be related to several others: 5774 (which has been
closed), 10258, 10472.. There are also a number of people reporting this
bug on launchpad (https://launchpad.net/bugs/28326). I have also tried
the modesetting version if the i810 driver, which did not help.
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/93
------------------------------------------------------------------------
On 2007-09-30T11:13:38+00:00 Smajchl wrote:
I have the same problem on HP nx6110 with the same graphics card. Debian
testting.
I spent lot of time to get it worgking and now I am using old version
2:1.7.2-4 with vbetool, without 3d rendering. With 3d rendering it makes
this problem and with newer version, it doesn't do anything, only black
screen, even if 3d rendering is off :-(
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/100
------------------------------------------------------------------------
On 2007-11-20T00:59:04+00:00 Freedesktop-tmp wrote:
Created an attachment (id=12642)
Xorg-log after crash
Same problem here, tested with
- Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller
- Gentoo system
- xorg-server-1.4-r2
- xf86-video-i810 2.1.0, 2.1.1, 2.1.99 and current git version
- kernel 2.6.22 and 2.6.23
- with framebuffer (vesa, uvesa) and without
Steps to reproduce:
1. Boot system (drm and i915 unloaded)
2. Start X (everything's ok)
3. Use xterm or switch back to VT
4. s2ram
5. Resume
X will crash as soon it is activated.
It does not matter if you exit X and unload drm and i915 before
suspending! X will crash when you try to restart it after resume.
Other way to reproduce:
1. Start system (without X)
2. s2ram
3. resume
4. Start X -> everything is OK
5. Quit X
6. s2ram
7. resume
8. Start X -> Crash
So I don't think this might be a kernel problem.
Interesting line from the logfile:
> space: 130800 wanted 131064
This value varies from time to time, so it seems to be a memory
allocation problem?
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/107
------------------------------------------------------------------------
On 2007-11-20T00:59:33+00:00 Freedesktop-tmp wrote:
Created an attachment (id=12643)
my current xorg.conf
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/108
------------------------------------------------------------------------
On 2007-11-20T01:00:02+00:00 Freedesktop-tmp wrote:
Created an attachment (id=12644)
current kernel config
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/109
------------------------------------------------------------------------
On 2007-11-21T09:51:01+00:00 Freedesktop-tmp wrote:
X doesn't crash when setting option "NoAccel" to true. But... no dri, no
compiz and very slow window redraw (e.g. when moving windows). Just a
temporary solution for me.
This bug might be related to bug #11720.
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/110
------------------------------------------------------------------------
On 2007-11-28T12:19:34+00:00 Jesse Barnes wrote:
Sounds like an intel driver bug.
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/111
------------------------------------------------------------------------
On 2007-12-04T17:00:09+00:00 Jesse Barnes wrote:
Upping severity as this causes a crash/hang.
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/112
------------------------------------------------------------------------
On 2007-12-11T13:21:10+00:00 Jesse Barnes wrote:
Have you tested with the latest git driver? We fixed several
suspend/resume bugs (really Enter/LeaveVT bugs) for that release,
hopefully yours was fixed as well.
Could also be related to 11432 or 13196.
It would be helpful if you could build the intel_reg_dumper tool and
capture some register state from after the resume before the X crash
along with a dump from before starting a working X session.
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/113
------------------------------------------------------------------------
On 2007-12-11T13:52:43+00:00 Jesse Barnes wrote:
*** Bug 11720 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/114
------------------------------------------------------------------------
On 2007-12-11T13:57:57+00:00 Freedesktop-tmp wrote:
Created an attachment (id=13040)
Log the crashed server with current git tree
I've just compiled and tested the current git version. The server still
crashes (same procedure as described earlier or in bug #11720), but now
it looks somewhat different. I'll doing additional tests tomorrow.
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/115
------------------------------------------------------------------------
On 2007-12-12T11:24:25+00:00 Freedesktop-tmp wrote:
Created an attachment (id=13068)
Backtrace when X crashed after resume and vt-switch
New backtrace with current git version of xf86-video-intel
1. Start system w/o X
2. Start X with gdb (ssh)
3. Switch to vt1 and suspend
4. Resume and switch back to vt7 -> crash
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/116
------------------------------------------------------------------------
On 2007-12-12T11:25:15+00:00 Freedesktop-tmp wrote:
Created an attachment (id=13069)
intel_reg_dump after startup but before X
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/117
------------------------------------------------------------------------
On 2007-12-12T11:25:40+00:00 Freedesktop-tmp wrote:
Created an attachment (id=13070)
intel_reg_dump after startup while X is running
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/118
------------------------------------------------------------------------
On 2007-12-12T11:26:05+00:00 Freedesktop-tmp wrote:
Created an attachment (id=13071)
intel_reg_dump after resume but before switching to vt7
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/119
------------------------------------------------------------------------
On 2007-12-12T11:26:35+00:00 Freedesktop-tmp wrote:
Created an attachment (id=13072)
intel_reg_dump after resume and switch to vt7 (this means, after crash)
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/120
------------------------------------------------------------------------
On 2007-12-12T11:32:10+00:00 Freedesktop-tmp wrote:
If you require additional info, let me suggest to give you temporary
root-access to my system so you can trace this bug by yourself. Please
contact me by mail.
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/121
------------------------------------------------------------------------
On 2007-12-14T15:40:29+00:00 Freedesktop-tmp wrote:
Created an attachment (id=13115)
Xorg.log when crashing after resuming from disk (tuxonice)
I just did some tests with tuxonice instead of default suspend. When
resuming from disk, the server keeps crashing when entering vt7. But it
seems to be slightly different because I was not able to backtrace this
crash with gdb. The screen shows garbage but the server still runs and
receives SIGUSR1-events (however it does not handle them).
Maybe an interesting detail: When suspending to mem via sysfs (using
hibernate-tools) after killing a running X-session, the screen is blank
after resuming. If I'm not totally wrong even the backlight keeps
disabled. But when starting X (using an ssh-connection) the backlight is
enabled again and the server crashes the same way it did when suspending
to disk.
None of this problems occurs when option NoAccel is true in xorg.conf.
Is someone working on this? I will help as best as I can, but this bug
is really annoying.
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/122
------------------------------------------------------------------------
On 2007-12-17T15:28:25+00:00 Jesse Barnes wrote:
I wonder if this might be related to 13196... my latest theory there is
that we're not letting the PLLs settle for a long enough period before
writing the pipe registers... There's a patch there to test that
theory, can you give it a try?
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/123
------------------------------------------------------------------------
On 2007-12-19T00:25:19+00:00 Freedesktop-tmp wrote:
Thanks to Jesse, I was able to find out more information about the
problem. To make it short, resuming works fine with classic vesafb,
although I'm not sure wether it had worked all the time. Actually, it
seems that I experienced different problems, all related to the kernel:
The first one (which encouraged me to start experimenting with various
versions and kernel settings), resuming from disk with vesafb-tng
(kernel 2.6.22), was apparently fixed some times ago and works at least
with current git drivers.
The second one, resuming from ram with vesafb-tng, still exists but is a
kernel problem (the screen stays black and the system completely hangs
on resume, independently of starting an X-session).
The third and current one (used for the backtraces) occurs with the new
uvesafb and kernel 2.6.23, but I think it may be an uvesafb-bug so I'll
report it there, too.
I stupidly never tested with classic vesafb or without fb-support
because I thought the driver is disabled when omitting the video=-line
from kernel options, but obviously I was wrong.
@Jesse: Thank you for your patience, and sorry for the missleading and
imperfect description of the bug. At least I learned how to use git and
how to get backtraces with gdb ;-). Please change status if you think
that this bug doesn't belong to xorg any longer.
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/124
------------------------------------------------------------------------
On 2007-12-19T00:57:48+00:00 Freedesktop-tmp wrote:
Added the bug to gentoo database:
http://bugs.gentoo.org/show_bug.cgi?id=202756
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/125
------------------------------------------------------------------------
On 2008-01-09T19:32:11+00:00 Michael Fu wrote:
(In reply to comment #19)
>
> @Jesse: Thank you for your patience, and sorry for the missleading and
> imperfect description of the bug. At least I learned how to use git and how to
> get backtraces with gdb ;-). Please change status if you think that this bug
> doesn't belong to xorg any longer.
>
Roland, did you have a chance to try the patch in bug# 13196 that Jesse
mentioned?
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/126
------------------------------------------------------------------------
On 2008-01-10T01:09:37+00:00 Freedesktop-tmp wrote:
I tried already, it had no effect. At the moment I'm pretty sure that
this is an uvesafb-issue because my system resumes perfectly since I'm
using classic vesafb. Futhermore there is another user with the same
problem at gentoo's bugzilla.
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/127
------------------------------------------------------------------------
On 2008-01-11T02:38:43+00:00 Benjamin-close wrote:
Bugzilla Upgrade Mass Bug Change
NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs
previously listed as NEEDSINFO.
- benjsc
fd.o Wrangler
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/128
------------------------------------------------------------------------
On 2008-01-17T00:30:20+00:00 Michael Fu wrote:
(In reply to comment #19)
>
> I stupidly never tested with classic vesafb or without fb-support because I
> thought the driver is disabled when omitting the video=-line from kernel
> options, but obviously I was wrong.
>
Roland, it sounds to me if you remove vesafb kernel driver, just using
drm driver, the suspend/resume works fine then?
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/129
------------------------------------------------------------------------
On 2008-01-17T00:58:18+00:00 Priit Laes wrote:
(In reply to comment #24)
> (In reply to comment #19)
> >
> > I stupidly never tested with classic vesafb or without fb-support because I
> > thought the driver is disabled when omitting the video=-line from kernel
> > options, but obviously I was wrong.
> >
>
> Roland, it sounds to me if you remove vesafb kernel driver, just using drm
> driver, the suspend/resume works fine then?
>
Withouth uvesafb compiled in kernel, suspend-resume works fine for me.
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/130
------------------------------------------------------------------------
On 2008-01-17T01:38:36+00:00 Michael Fu wrote:
(In reply to comment #25)
> (In reply to comment #24)
> > (In reply to comment #19)
> > >
> > > I stupidly never tested with classic vesafb or without fb-support because I
> > > thought the driver is disabled when omitting the video=-line from kernel
> > > options, but obviously I was wrong.
> > >
> >
> > Roland, it sounds to me if you remove vesafb kernel driver, just using drm
> > driver, the suspend/resume works fine then?
> >
>
> Withouth uvesafb compiled in kernel, suspend-resume works fine for me.
>
great. I'm closing this bug then..
Reply at: https://bugs.launchpad.net/null/+bug/28326/comments/131
** Changed in: xorg-server
Status: Invalid => Won't Fix
** Changed in: xorg-server
Importance: Unknown => High
** Bug watch added: Gentoo Bugzilla #202756
http://bugs.gentoo.org/show_bug.cgi?id=202756
--
i810 Xv crashes after suspend -> infinite resprawn
https://bugs.launchpad.net/bugs/28326
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for NULL Project.
