Created attachment 10524 [details]
dmesg log

Created attachment 10525 [details]
lspci -vv

Created attachment 10526 [details]
xorg.conf

Created attachment 10527 [details]
Xorg.0.log

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.

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.

I'm still experiencing the issue reported, using version 2.1.0 (Gutsy's 2.1.0-1ubuntu1) of the intel driver.

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.

Created attachment 10644 [details]
Xorg log.

Created attachment 10645 [details]
Xorg configuration file

Created attachment 10646 [details]
Registers diff before and after the Xorg mode setting

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.

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.

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.
> 

(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.

> 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.

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.

Created attachment 10919 [details]
xorg.conf (LCD & CRT)

Created attachment 10920 [details]
Xorg.0.log (LCD & CRT)

Created attachment 10921 [details]
dmesg log (LCD & CRT)

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.

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.

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.

(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.

This sounds a bit like this bug, for which I uploaded a patch to Gutsy today:

https://bugs.launchpad.net/ubuntu/+bug/127101

@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,

Is this a whole system freeze, or just display freeze with like network working?

(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.... 

Keith, any comments?

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).

Con, can you try the latest driver from git?  Peter fixed a few problems that might cause the hang you're seeing.

(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).

Created attachment 12288 [details]
Log with curent debian driver

Created attachment 12289 [details]
Log with git(1.11.2007) intel driver

Created attachment 12290 [details]
Log with git(1.11.2007) + PipeA patch

with pipeA patch - LSD resolution set to 1152x768

in all variants my notebook freeze when lid open.

if connect CRT monitor all is OK

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.

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

Conn or Tim, does this problem still occur with the latest driver?

Upping severity

Upping severity

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.

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.

(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

@ 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 ;)

(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.

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.

I`m found it!
The promlem in function i830_crtc_dpms if disable it, problem has gone!

test a patch.

Created attachment 13004 [details] [review]
solve system freeze

require refinement

Excellent, that narrows things down a lot... We'll have to fix up the CRTC DPMS function...

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

Created attachment 13037 [details]
New quirk type for leaving pipe a enabled

Based on Raul's patch, but converted to a quirk.

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...

Created attachment 13039 [details]
lspci -nv output for Dell Inspiron 510m.

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.

Created attachment 13042 [details]
Xorg log after the JBarnes patch. X got stuck before coming up.

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?

Created attachment 13043 [details]
Leave PLL running in mode_set too

> 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.

(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.

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...

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,

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.

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)

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

(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

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?

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.

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

Created attachment 13530 [details]
Xorg.0.log with "Leave PLL running in mode_set too" patch

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.

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.

Cool, thanks for testing and adding a quirk.  I'll go ahead and push this soon.

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.

Hey, can I get y

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

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!

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

Shame on me Jesse!, you did it. I'm sorry :S

In what version is this fixed?

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.

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

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.

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!

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