Bug 11432 - [855GM] system hang during suspend/resume
[855GM] system hang during suspend/resume
Status: RESOLVED FIXED
Product: xorg
Classification: Unclassified
Component: Driver/intel
git
x86 (IA32) Linux (All)
: medium major
Assigned To: Jesse Barnes
Xorg Project Team
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-30 19:01 UTC by Conn
Modified: 2008-03-07 13:29 UTC (History)
10 users (show)

See Also:


Attachments
dmesg log (22.71 KB, text/x-log)
2007-06-30 19:02 UTC, Conn
no flags Details
lspci -vv (8.03 KB, text/x-log)
2007-06-30 19:02 UTC, Conn
no flags Details
xorg.conf (3.13 KB, text/plain)
2007-06-30 19:03 UTC, Conn
no flags Details
Xorg.0.log (57.98 KB, text/plain)
2007-06-30 19:03 UTC, Conn
no flags Details
Xorg log. (99.37 KB, text/plain)
2007-07-09 16:40 UTC, Raúl
no flags Details
Xorg configuration file (4.00 KB, text/plain)
2007-07-09 16:42 UTC, Raúl
no flags Details
Registers diff before and after the Xorg mode setting (6.75 KB, text/plain)
2007-07-09 16:43 UTC, Raúl
no flags Details
xorg.conf (LCD & CRT) (3.62 KB, text/plain)
2007-07-30 15:33 UTC, Conn
no flags Details
Xorg.0.log (LCD & CRT) (66.82 KB, text/plain)
2007-07-30 15:33 UTC, Conn
no flags Details
dmesg log (LCD & CRT) (41.14 KB, text/plain)
2007-07-30 15:34 UTC, Conn
no flags Details
Patch to force enabling pipe A. (1.73 KB, patch)
2007-09-09 15:47 UTC, Raúl
no flags Details | Splinter Review
Patch providing a configuration option to forcibly enable pipe A. (2.16 KB, patch)
2007-09-10 14:08 UTC, Raúl
no flags Details | Splinter Review
Log with curent debian driver (54.77 KB, text/plain)
2007-11-01 02:01 UTC, timyr_lan
tamerlan311: 6.9/7.0+
Details
Log with git(1.11.2007) intel driver (59.10 KB, text/plain)
2007-11-01 02:03 UTC, timyr_lan
no flags Details
Log with git(1.11.2007) + PipeA patch (72.79 KB, text/plain)
2007-11-01 02:05 UTC, timyr_lan
no flags Details
solve system freeze (487 bytes, patch)
2007-12-09 02:18 UTC, timyr_lan
no flags Details | Splinter Review
New quirk type for leaving pipe a enabled (3.37 KB, text/x-diff)
2007-12-11 12:50 UTC, Jesse Barnes
no flags Details
lspci -nv output for Dell Inspiron 510m. (3.91 KB, text/plain)
2007-12-11 13:47 UTC, Raúl
no flags Details
Xorg log after the JBarnes patch. X got stuck before coming up. (31.65 KB, text/plain)
2007-12-11 14:49 UTC, Raúl
no flags Details
Leave PLL running in mode_set too (4.27 KB, text/x-diff)
2007-12-11 15:35 UTC, Jesse Barnes
no flags Details
fix freeze on c400 version2 (438 bytes, patch)
2007-12-19 12:31 UTC, timyr_lan
no flags Details | Splinter Review
Xorg.0.log with "Leave PLL running in mode_set too" patch (62.50 KB, text/plain)
2008-01-04 11:05 UTC, Conn
no flags Details
Patch to add the Dell Inspiron 510m to the quirk table. (431 bytes, text/plain)
2008-01-07 12:12 UTC, Raúl
no flags Details
Fix CRT detection status (524 bytes, text/plain)
2008-01-10 09:51 UTC, Jesse Barnes
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Conn 2007-06-30 19:01:21 UTC
System: Dell Inspiron 510m laptop, Intel 865GM chipset. Ubuntu Gutsy, xserver 1.3.0, latest xf86-video-intel from git

I have a reproducible crash with the latest Intel driver from git:

1. Close laptop lid/press lid pressure button
2. Screen blanks, system completely freezes

The crash occurs 100% of the time using latest git, whereas the 2.0.0 release of the driver crashed only sporadically.

Some notes (most relevant first):
1. Issuing "xset s activate" works as expected, and does not appear to cause any crashes
2. Switching between X and virtual consoles can occasionally cause a hard freeze  (although much less common compared to version 2.0.0 release)
3. When switching between X and a VT, occasionally there is slight corruption visible in the console
3. Using '"AccelMethod" "exa"' generally works (2D & 3D), except beryl/compiz/compiz-fusion causes an unrecoverable hard freeze, similar to the issue in this report; Using "xaa" presents no problems.
4. I am forced to use Legacy3D, as Ubuntu's kernel is incompatible with the new drm/agpgart modules.

Some useful info:

cat /proc/mtrr:
---------------
reg00: base=0x00000000 (   0MB), size= 512MB: write-back, count=1
reg01: base=0x1ff00000 ( 511MB), size=   1MB: uncachable, count=1
reg02: base=0xfeda0000 (4077MB), size= 128KB: write-through, count=1
reg03: base=0xf0000000 (3840MB), size= 128MB: write-combining, count=1

lspci -nn | grep VGA
--------------------
00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02)

I'll attach other relevant logs. Thanks in advance :)
Comment 1 Conn 2007-06-30 19:02:30 UTC
Created attachment 10524 [details]
dmesg log
Comment 2 Conn 2007-06-30 19:02:58 UTC
Created attachment 10525 [details]
lspci -vv
Comment 3 Conn 2007-06-30 19:03:30 UTC
Created attachment 10526 [details]
xorg.conf
Comment 4 Conn 2007-06-30 19:03:44 UTC
Created attachment 10527 [details]
Xorg.0.log
Comment 5 Conn 2007-06-30 19:05:50 UTC
I forgot to mention: Using the 1.7.4 release of the i810 driver, I experience no crashes when closing the laptop lid or switching between consoles.
Comment 6 Raúl 2007-07-02 15:44:55 UTC
Same problem here. Inspiron 510m, I855GM and Debian unstable. This is happenning since intel 2.0 version, I didn't explore back, but last i810 driver worked perfectly in this sense.. Last tested on git and still the problem is there. I can reproduce it even on kdm logon screen. Haven't tried EXA, but I will and report.

Please let me know if I should provide any information or it's enough with the already reported by Conn.
Comment 7 Conn 2007-07-03 16:12:02 UTC
I'm still experiencing the issue reported, using version 2.1.0 (Gutsy's 2.1.0-1ubuntu1) of the intel driver.
Comment 8 Raúl 2007-07-09 16:37:32 UTC
After a conversation at #xorg-devel with Keith Packard I did some tests.
This is my info:
lspci -vv
00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02)

I used the vesafb driver from the kernel and set it to vga=0x305 which corresponds to 1024x768x8. That was the more similar resolution to my Xorg which is depth 24 and framebuffer bpp 32 1024x768.

I attach my xorg.conf file and my Xorg log with the modedebug enabled, as per conf. I'm also attaching a diff between the registers before the Xorg mode set and after for convenience.
Comment 9 Raúl 2007-07-09 16:40:04 UTC
Created attachment 10644 [details]
Xorg log.
Comment 10 Raúl 2007-07-09 16:42:51 UTC
Created attachment 10645 [details]
Xorg configuration file
Comment 11 Raúl 2007-07-09 16:43:32 UTC
Created attachment 10646 [details]
Registers diff before and after the Xorg mode setting
Comment 12 Conn 2007-07-09 17:15:51 UTC
Raúl,

I tried booting with vga=0x305 and it worked properly (evident with Ubuntu's usplash, it's usually stuck at 640x480), but when I try to switch to a virtual terminal, all I can see is graphical corruption and no visible signs of a console - but I can switch back using Ctrl & Alt & F7. However, pressing the laptop pressure switch still causes an unrecoverable freeze.

Thanks for replying to this bug, tomorrow I'll post the same before/after logs; hopefully they may help.
Comment 13 Raúl 2007-07-10 11:17:42 UTC
Following the results with Keith Packard, he suggested that my BIOS was crappy and that the problem is that the SMM enters in action when the lid button is pressed, so the chipset registers were messes and hence the lock.

I need to keep the pipe A (VGA) enable to avoid the lock either by using an external VGA monitor or enabling it somehow using xrandr. Another solution would be taking care of the lid button in the OS(GNU/Linux) and not in the BIOS.

So at the driver level it's possible to add an configuration hacking option to keep pipe A enabled or to implement the lid button handling in the OS.
Comment 14 Conn 2007-07-13 19:24:11 UTC
Keith,

I have isolated the commit that introduced these hangs when closing the laptop lid, it's at b31bef1a8effa9acb6de7edd206b9d8c48d88144 - "Deal with i830 CRT load detection which cannot use FORCE_BORDER." 

Before this commit, the driver will restore the screen after closing the lid/pressing the lid button, but it will eventually crash if I attempt to close/reopen it too often.

I'm also trying to isolate what commit is causing DRI in conjunction with EXA to hard crash the system every time I try running compiz (XAA works fine) - but that's a matter for another bug report.

(In reply to comment #13)
> Following the results with Keith Packard, he suggested that my BIOS was crappy
> and that the problem is that the SMM enters in action when the lid button is
> pressed, so the chipset registers were messes and hence the lock.
> 
> I need to keep the pipe A (VGA) enable to avoid the lock either by using an
> external VGA monitor or enabling it somehow using xrandr. Another solution
> would be taking care of the lid button in the OS(GNU/Linux) and not in the
> BIOS.
> 
> So at the driver level it's possible to add an configuration hacking option to
> keep pipe A enabled or to implement the lid button handling in the OS.
> 

Comment 15 Michel Dänzer 2007-07-16 01:14:58 UTC
(In reply to comment #14)
> I'm also trying to isolate what commit is causing DRI in conjunction with EXA
> to hard crash the system every time I try running compiz (XAA works fine) - but
> that's a matter for another bug report.

If there's a line like

(II) XAA: Evicting pixmaps

in the log file, it's a bad X server patch of your distribution.
Comment 16 Conn 2007-07-16 12:48:33 UTC
> If there's a line like
> 
> (II) XAA: Evicting pixmaps
> 
> in the log file, it's a bad X server patch of your distribution.
> 

Thanks Michel, I've filed a separate bug at https://bugs.freedesktop.org/show_bug.cgi?id=11626 in order to keep this bug on-topic. I'll isolate the bad patch and recompile without it, if possible.
Comment 17 Conn 2007-07-30 15:32:16 UTC
Some more notes:

1. The crash also occurs if I press Fn + F8, which is the key combination to switch between CRT/LCD outputs.

2. With a CRT attached, I can now close the laptop lid without the system freezing, and the above key combination works as expected. I'll attach some logs after closing and reopening the lid a few times.
Comment 18 Conn 2007-07-30 15:33:10 UTC
Created attachment 10919 [details]
xorg.conf (LCD & CRT)
Comment 19 Conn 2007-07-30 15:33:44 UTC
Created attachment 10920 [details]
Xorg.0.log (LCD & CRT)
Comment 20 Conn 2007-07-30 15:34:54 UTC
Created attachment 10921 [details]
dmesg log (LCD & CRT)
Comment 21 Raúl 2007-09-09 15:44:41 UTC
I have a (very ugly) patch that could at least avoid the total freeze. It works on the function that does the detection of the VGA monitor presence. It always returns it is connected, so the pipe A is enabled and I didn't experience the hang caused by the crappy BIOS.

Of course this is a nasty workaround to avoid freezes but it's not a final solution. Also it has some drawbacks. The ones I'm aware of for the moment are:
  -Enabling pipe A when no monitor is connected is a power waste. The best thing would be enabling it just when going for suspend, minimizing that way the time pipe A is enabled unnecessarily.
  -Pressing the lid button blanks the panel(turn off) but after releasing it, it doesn't come back automatically, you should go to a text console and then return to X.
  -When using Xv for video output, on the LVDS you will see a blue square where the video should appear, this happens because (I guess) the video is being redirected to the (pretended) VGA monitor. Use xvattr to redirect it to the right pipe.

  Taking this into account I will try to find another ways to hack this. I'm opened for advice, indeed I will have to ask for other feasible options. At the moment I think of two better approaches:

  1- Use xrandr to force the pipe A enabling. I think this is the smarter option but you won't be able to just close the lid, you will need to do the xrandr call somehow manually or using any kind of automation.
  2- Use a xorg.conf option to force enable pipe A. This forcing could be either done in the VGA monitor detection (as per this patch) or possibly better on the output mode set routines.
  3- Use pipe A to output LVDS. This would be the optimal solution, IMHO. Keith Packard told me about it, but is the most complex to implement and also I'm not sure about its feasibility yet. When I was told it was a theorical solution.

  Comment are more than welcome.
Comment 22 Raúl 2007-09-09 15:47:22 UTC
Created attachment 11482 [details] [review]
Patch to force enabling pipe A.

This applies to current git (freedesktop/master) HEAD.
It includes some debug code which you may not need.
_Warning_: read the comments before trying it.
Comment 23 Raúl 2007-09-10 14:08:17 UTC
Created attachment 11492 [details] [review]
Patch providing a configuration option to forcibly enable pipe A.

This is a slightly improved version of the previous one. This time the enabling can be configured using the ForceEnablePipeA option in the Device section like this:

Option          "ForceEnablePipeA" "true"

This way the pipe A enabling is not determined in build time, unlike previous patch. This applies to today's git version.
Comment 24 timyr_lan 2007-09-12 09:02:44 UTC
(In reply to comment #23)
> Created an attachment (id=11492) [details]
> Patch providing a configuration option to forcibly enable pipe A.

On my Dell c400 this patch don`t work.

1) if DPMS off when lid open - system freze. after reboot filesystem (reiserfs 3.6) chash - ~800 uncompleted transactions......
2) if DMPS on before lid open - system work normaly...
3) if external monitor pluged - system not freze on lid open with DPMS off

system Debian testing.

P.S. Sorry my bad english.
Comment 25 Bryce Harrington 2007-09-28 19:33:23 UTC
This sounds a bit like this bug, for which I uploaded a patch to Gutsy today:

https://bugs.launchpad.net/ubuntu/+bug/127101
Comment 26 Raúl 2007-09-30 09:52:39 UTC
@timyr_lan:
  Have you included the ForceEnablePipeA option in the intel device section? Could you provide the Xorg log when using the patch? I would also appreciate if you could explain further 1) and 2). I understand 3), and that solves the problem since that will enable pipeA which is just what patch should do.

@Bryce Have you checked that you are not talking about https://bugs.freedesktop.org/show_bug.cgi?id=10809 or https://bugs.freedesktop.org/show_bug.cgi?id=10812 ?

Regards,
Comment 27 Gordon Jin 2007-10-09 06:17:10 UTC
Is this a whole system freeze, or just display freeze with like network working?
Comment 28 timyr_lan 2007-10-09 07:09:05 UTC
(In reply to comment #27)
> Is this a whole system freeze, or just display freeze with like network
> working?
> 

NetWork freeze too.

MagicSysKey also do not work.... 
Comment 29 Gordon Jin 2007-10-11 19:07:44 UTC
Keith, any comments?
Comment 30 Peter Clifton 2007-10-22 16:05:16 UTC
This also sounds like:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/138256

For which I've written a few patches, and some users are reporting improvements. The patched package for Ubuntu Gutsy (and sources) are at:

http://www2.eng.cam.ac.uk/~pcjc2/ubuntu/

(The package versioned xserver-xorg-video-intel_2.1.1-0ubuntu10~pcjc2.2 has the most fixes / workarounds in it).
Comment 31 Jesse Barnes 2007-10-31 14:23:06 UTC
Con, can you try the latest driver from git?  Peter fixed a few problems that might cause the hang you're seeing.
Comment 32 Peter Clifton 2007-10-31 15:15:04 UTC
(In reply to comment #31)
> Con, can you try the latest driver from git?  Peter fixed a few problems that
> might cause the hang you're seeing.
> 

I don't want to put a downer on testing the git version (it may have fixes), but the patches I've been working on mostly not in git. There was a fix Jesse committed for the "grey blocks crash" seen on various hardware, although many 855 users still saw crashes caused by register accesses which aren't yet fixed in git.

I'll find the appropriate bugs to attach my other patches too shortly. (This    bug isn't directly fixed by those patches for _all_ Ubuntu users who've tested my patches), but it may have helped some. (I'll try to remember to cross-post the patch which might help here too).

Comment 33 timyr_lan 2007-11-01 02:01:42 UTC
Created attachment 12288 [details]
Log with curent debian driver
Comment 34 timyr_lan 2007-11-01 02:03:07 UTC
Created attachment 12289 [details]
Log with git(1.11.2007) intel driver
Comment 35 timyr_lan 2007-11-01 02:05:50 UTC
Created attachment 12290 [details]
Log with git(1.11.2007) + PipeA patch

with pipeA patch - LSD resolution set to 1152x768
Comment 36 timyr_lan 2007-11-01 02:09:32 UTC
in all variants my notebook freeze when lid open.

if connect CRT monitor all is OK
Comment 37 Raúl 2007-11-13 12:26:34 UTC
timmy: Thanks for testing the patches. I see you have an intel 845 model and I have an 855, also I don't know if you are on a Dell inspiron 510m. These conditions _would_ make a difference.

BTW, I'll study the logs you posted and look for the reason that's making the patch fail.

Take into account that the patch effect should be the same as when you plug an external VGA monitor.
Comment 38 Jesse Barnes 2007-11-14 08:39:40 UTC
I think Keith was probably right that the BIOS is messing with the graphics configuration behind the X driver's back.  It probably assumes that pipe A is always enabled (btw if there's a way for you to disable the CRT/LCD switch button or make it generate an ACPI event instead, you should probably do that).

Raúl, something like your patch is probably needed, but maybe we could make it into a new quirk flag instead?  That way machines that we know have this kind of problem could be automatically detected...

Thanks,
Jesse
Comment 39 Jesse Barnes 2007-11-29 13:21:46 UTC
Conn or Tim, does this problem still occur with the latest driver?
Comment 40 Jesse Barnes 2007-12-04 17:00:33 UTC
Upping severity
Comment 41 Jesse Barnes 2007-12-04 17:01:09 UTC
Upping severity
Comment 42 Raúl 2007-12-04 17:10:01 UTC
Hello:

First of all I have to say that I'm sticking to latest stable version and TBH testing git is on not on the top of mu TODO queue. But I don't see anything in git that could make this thing works.

The only success I've got was using the patch I posted here.

So being things like that I tried to pull some collaboration from linux-acpi people since I'm lost there. http://article.gmane.org/gmane.linux.acpi.devel/25937

Unfortunately, I didn't get any answer apart of coming back to xorg people support which I've found quite good so far.

Having said this, i'm available to test whatever you may consider useful.

Thanks.
Comment 43 Bryce Harrington 2007-12-05 15:49:14 UTC
Hi Jesse,

I've been tabulating reports of suspend/resume issues for Ubuntu bug 138256 and others, particularly focusing on reports with 855 graphics:

https://wiki.ubuntu.com/X/Bugs/ScreenModeChange

Rolla suggested you might find this of interest.  I hoped this would highlight obvious duplicate issues from independent ones, but it's a little unclear from the limited details on hand.

Most of these reports are from pre-2.2 -intel.  If you recognize specific issues as definitely fixed, I'd appreciate hearing.  Otherwise I just plan to request everyone retest on Hardy alpha-1 with -intel 2.2.

Comment 44 timyr_lan 2007-12-06 11:40:46 UTC
(In reply to comment #43)
> Hi Jesse,
> 
> I've been tabulating reports of suspend/resume issues for Ubuntu bug 138256 and
> others, particularly focusing on reports with 855 graphics:
> 
> https://wiki.ubuntu.com/X/Bugs/ScreenModeChange
> 
> Rolla suggested you might find this of interest.  I hoped this would highlight
> obvious duplicate issues from independent ones, but it's a little unclear from
> the limited details on hand.
> 
> Most of these reports are from pre-2.2 -intel.  If you recognize specific
> issues as definitely fixed, I'd appreciate hearing.  Otherwise I just plan to
> request everyone retest on Hardy alpha-1 with -intel 2.2.
> 

xserver-xorg-video-i810-1.7.2 - work fine
intel_1.9.94 and intel_2.0.0 - faled on "allocate memory" and X not start.
intel_2.1.0 and intel_2.2.0 - freze on lid open
Comment 45 Raúl 2007-12-06 23:12:20 UTC
@ timyr_lan 
> intel_2.1.0 and intel_2.2.0 - freze on lid open
Maybe you mean on lid close, please check it out ;)
Comment 46 timyr_lan 2007-12-07 02:34:31 UTC
(In reply to comment #45)
> @ timyr_lan 
> > intel_2.1.0 and intel_2.2.0 - freze on lid open
> Maybe you mean on lid close, please check it out ;)
> 

when I close the lid, it's ok. But when I open it the system freezes. If before opening the lid I set 'DMPS on' the system doesn't freeze.
Comment 47 timyr_lan 2007-12-07 14:53:04 UTC
I think problem in function with set DPMS state. Because if set DPMS off and close lid system freeze too.

When lid state changed - the screen blinking (on console too). Blinking has gone when external monitor pluged. I think this BIOS feature.

In new driver version simple function I830DisplayPowerManagementSet (in i830_driver.c) changed to i830_crtc_dpms (i830_display.c).

But i don`t undestand what new function work.
Comment 48 timyr_lan 2007-12-09 02:15:10 UTC
I`m found it!
The promlem in function i830_crtc_dpms if disable it, problem has gone!

test a patch.

Comment 49 timyr_lan 2007-12-09 02:18:02 UTC
Created attachment 13004 [details] [review]
solve system freeze

require refinement
Comment 50 Jesse Barnes 2007-12-09 17:41:44 UTC
Excellent, that narrows things down a lot... We'll have to fix up the CRTC DPMS function...
Comment 51 Jesse Barnes 2007-12-11 12:49:39 UTC
And after trolling through the Ubuntu bug reports on this issue (not as easy as it sounds since some bugs were describing at least 3 separate problems!) it sounds like what we've got is:
  - hang at lid close time
    - fixed by leaving pipe A enabled (presumably for the BIOS)
  - hang at lid open time
    - fixed by not disabling CRTCs in the DPMS off routine

Assuming all that's true, this patch may address both problems.  In order to do this automatically though I'll need the output of 'lspci -nv' from the Inspiron 510m or other problematic configs.

Please test and get back to me.

Thanks,
Jesse
Comment 52 Jesse Barnes 2007-12-11 12:50:16 UTC
Created attachment 13037 [details]
New quirk type for leaving pipe a enabled

Based on Raul's patch, but converted to a quirk.
Comment 53 Raúl 2007-12-11 13:45:23 UTC
Hello:
I'm quite excited with latest new. I'm heading towards testing you patch, Jesse.

The requested lspci -nv for my inspiron 510m laptop is attached. I will report about the patch a little later...
Comment 54 Raúl 2007-12-11 13:47:25 UTC
Created attachment 13039 [details]
lspci -nv output for Dell Inspiron 510m.
Comment 55 Raúl 2007-12-11 14:48:17 UTC
Well, I have applied the patch to latest git, but I can't get X to come up. This is what I did:
-Merged Debian packaging section to latest freedesktop git. This is my usual testing method, so I don't think here is the problem, yet it could.
-Applied the Jesse Barnes patch.
-Got my Dell subsytem and model for the video card: 1028:0164
-Added this line to the list of quirks:
{ PCI_CHIP_I855_GM, 0x1028, 0x0164, quirk_pipea_force },

I after building and installing I got a Xorg running till got stuck when setting pipe A (or sort of). I couldn't see the login screen. I'm attaching the  log.
Comment 56 Raúl 2007-12-11 14:49:22 UTC
Created attachment 13042 [details]
Xorg log after the JBarnes patch. X got stuck before coming up.
Comment 57 Jesse Barnes 2007-12-11 15:35:24 UTC
Hm, I wonder if that's because we try to disable the PLL in i830_crtc_mode_set before re-enabling it again (this would be bad if we left the pipe enabled).  Can you try the new patch?
Comment 58 Jesse Barnes 2007-12-11 15:35:56 UTC
Created attachment 13043 [details]
Leave PLL running in mode_set too
Comment 59 timyr_lan 2007-12-11 20:10:51 UTC
> I after building and installing I got a Xorg running till got stuck when
> setting pipe A (or sort of). I couldn't see the login screen.

I had this problem too, to fix disable only DPMS off in i830_crtc_dpms and promlem gone.
Comment 60 timyr_lan 2007-12-11 23:25:11 UTC
(In reply to comment #55)
> I after building and installing I got a Xorg running till got stuck when
> setting pipe A (or sort of). I couldn't see the login screen.

I mean:

    if (mode == DPMSModeOff) {
        return;
    }

Jesse Barnes,

> ((pipe == 0) && (pI830->quirk_flag & QUIRK_PIPEA_FORCE))

ForcePipeA isn`t need on my Dell C400, because it sets a wrong screen mode.
Comment 61 Jesse Barnes 2007-12-12 08:30:04 UTC
Ok, thanks for testing.  The problem is that we can't just unconditionally disable the DPMS off code, we need some way of selectively leaving pipes enabled...
Comment 62 Raúl 2007-12-12 23:17:40 UTC
I've tested your latest patch, but it got me to the same point as before: X won't come up.

I'm now trying to double-check the patching process in case I failed to do it correctly and I will also try to debug the X start progress in case I can see where it got stuck.

Thanks,
Comment 63 Raúl 2007-12-13 15:58:50 UTC
I'm so sorry. I've being hitting a problem in my source tree. The problem is that the code is not correct and a symbol couldn't be found, hence the behaviour.

I'll try to do some cleanup and retry.
Comment 64 Laurento Frittella 2007-12-19 04:42:57 UTC
I'd like to test your patch because I have similar problems on my DELL Latitude D510 (intel i915), I tried to port the patch for the version 2.1.1... without success :)

I create a patch to replace i830-crt-detect() function in 2.1.1 with the one in the git repo and with this I can apply your patch (with some fuzz)

But with this modified driver Xorg doesn't start at all... and I'm not surprised ;)

If you can release a patch that works with 2.1* driver I'll be glad to test it (I've tried 2.2.0 driver too but it seems slower)
Comment 65 timyr_lan 2007-12-19 12:31:06 UTC
Created attachment 13231 [details] [review]
fix freeze on c400 version2

Laurento Frittella, please test this patch.
I`m use it with intel 2.1.0
Comment 66 Laurento Frittella 2007-12-19 23:53:14 UTC
(In reply to comment #65)
> Laurento Frittella, please test this patch.
> I`m use it with intel 2.1.0

It doesn't work. Xorg doesn't start (blank screen) and I found these error messages in the log:

(EE) intel(0): I830 Vblank Pipe Setup Failed 0
(EE) intel(0): I830 Vblank Pipe Setup Failed 0
(EE) intel(0): I830 Vblank Pipe Setup Failed 0

Comment 67 Jesse Barnes 2008-01-03 15:29:37 UTC
Raúl or Conn, any news on this one?  Were you able to test out the "Leave PLL running in mode_set too" patch w/o any other changes?  Also, if you switch back to a VT before pressing the lid or output switch button do things work?
Comment 68 Raúl 2008-01-03 15:36:45 UTC
Hello Jesse:

I'm sorry for the long delay. I've just returned from vacation and I'll try to give some feedback in the next days.

Thanks.
Comment 69 Conn 2008-01-04 11:02:02 UTC
Jesse,

My apologies for the delay. I grabbed the latest git as of 4/1/08 and applied i830-leave-pipea-on-3.patch. When pressing the lid switch or the "CRT/LCD" function key (Fn+F8), there is no crash - but the screen does not turn off, nor does the screen "blink" as usual when trying to switch modes. Switching to a VT and then pressing the lid/output switch also has no effect, but no crash either.

I'll attach logs.

Thanks,
Conn
Comment 70 Conn 2008-01-04 11:05:53 UTC
Created attachment 13530 [details]
Xorg.0.log with "Leave PLL running in mode_set too" patch
Comment 71 Jesse Barnes 2008-01-04 11:23:33 UTC
Ok, good to hear that it doesn't crash anymore...

As for actually switching the video output, that'll depend on your platform and how it's configured.  In most cases, *not* using the video BIOS to perform the switch (as seems to be happening in your case) is a good thing.  We'd rather not have the system firmware poking the video registers behind our back.  Depending your particular machine, there may be a way to make the display output switch key or lid switch generate regular keyboard events; if so you could then just configure your desktop to respond to them accordingly by going into an S3 state or running the appropriate 'xrandr' command.
Comment 72 Raúl 2008-01-07 12:12:20 UTC
Created attachment 13575 [details]
Patch to add the Dell Inspiron 510m to the quirk table.

Hey. It did work!. Well, using the ForceEnablePipeA option had working from the  begining but you also need the attached path to avoid using that flag.

So no hang when applying your i830-leave-pipea-on-3.patch and this patch and not using the ForceEnablePipeA option.

All that I noticed is that the video post wasn't done properly but that could be a problem in my suspend configuration.
Comment 73 Jesse Barnes 2008-01-07 12:22:11 UTC
Cool, thanks for testing and adding a quirk.  I'll go ahead and push this soon.
Comment 74 Jesse Barnes 2008-01-09 09:56:33 UTC
Ok, fixed by 3c22ed633be2ac96eea7bc533839e956f1f31b84.  Conn & Raúl I think the quirk I checked in (from Raúl) should cover you both.  Thanks a lot for your patience and help with this bug.
Comment 75 Jesse Barnes 2008-01-10 09:49:37 UTC
Hey, can I get y
Comment 76 Jesse Barnes 2008-01-10 09:51:12 UTC
Created attachment 13646 [details]
Fix CRT detection status

Oops.  I mean to say hey can I get you guys to test one more patch?  This one should correct the output status reported by randr, while retaining the "leave pipe A on" semantics.  It's not really a critical change, but if it works it'll certainly be nicer than reporting that a CRT is connected when it's not.

Thanks,
Jesse
Comment 77 Raúl 2008-01-10 14:12:35 UTC
Great shot James!

I've tested it and not only everything went on working but having the system that there isn't anything plugged into that pipe is quite convenient.

Now I don't have to change XV_PIPE anymore on video play.

I won't be able to test this thoroughfully, since I've moved some time ago to a new laptop with 965 chipset.

Well done!
Comment 78 Jesse Barnes 2008-01-10 14:26:21 UTC
Well, I don't know who James is, but I'm glad he fixed this. :)

Thanks a lot for testing, I'll push the fix and make everyone happy.

Jesse
Comment 79 Raúl 2008-01-10 14:40:08 UTC
Shame on me Jesse!, you did it. I'm sorry :S
Comment 80 Alex Mauer 2008-03-07 10:52:32 UTC
In what version is this fixed?
Comment 81 Jesse Barnes 2008-03-07 11:25:27 UTC
This should be fixed in the 2.2.1 driver.  This one is specifically related to the pipe A force quirk (see the man page for details), so if you have a suspend/resume bug not related to that quirk, please file another bug.
Comment 82 Alex Mauer 2008-03-07 12:07:40 UTC
I find that I need to enable that option with a Dell Latitude D500, 855GM chipset, even with driver 2.2.1.

excerpt from lspci -vn:

00:02.0 0300: 8086:3582 (rev 02) (prog-if 00 [VGA controller])
        Subsystem: 1028:0152
        Flags: bus master, fast devsel, latency 0, IRQ 11
        Memory at f0000000 (32-bit, prefetchable) [size=128M]
        Memory at faf80000 (32-bit, non-prefetchable) [size=512K]
        I/O ports at c000 [size=8]
        Capabilities: [d0] Power Management version 1
Comment 83 Jesse Barnes 2008-03-07 12:10:09 UTC
Thanks for testing Alex.  Can you file a new bug, summary something like "need pipe a quirk on dell latitude D500" along with the info requested in the man page?  We'll fix it up for you in the next release so that you won't need the xorg.conf option.
Comment 84 Conn 2008-03-07 12:52:15 UTC
Jesse,

Many thanks, this quirk is set for my laptop by default and works flawlessly.

However... I always have that nagging feeling that we should investigate this issue more thoroughly and develop a proper fix... why? Because of potential power loss from keeping Pipe A constantly on. It matters on a laptop.

Otherwise, thanks again!
Comment 85 Jesse Barnes 2008-03-07 13:29:49 UTC
Conn, yeah that would be a good thing to do, but we'd need one of the laptops with this problem to narrow things down.  A few things that might be worth testing for people with affected machines:
  - does this problem occur w/o any fb drivers loaded?
  - does this problem occur on specific key events (brightness changes, display switch, lid close)?  that is, is it specifically reproducible with a given set of steps?
  - do the ACPI _DOS settings affect this bug?  see /proc/acpi/...

It may be that one of these factors will get rid of the need for the quirk.  If you find anything like this, please file an RFE so we can restructure the quirk or driver code to deal with the problem better.

Thanks,
Jesse