Bug 6001

Created attachment 7222 [details]
lspci output

Does this still happen with "acpi=off"?

If it happens only with ACPI enabled, does it happen with
CONFIG_ACPI_VIDEO=n?

I tried that and:

It _only_ happens with ACPI enabled, acpi=off resolves the problem.



 ~ $ grep ACPI_VIDEO /usr/src/linux-2.6.15.1/.config
# CONFIG_ACPI_VIDEO is not set

So, the answer to your second question is yes it does.

ACPI off = good
ACPI on + CONFIG_ACPI_VIDEO=n = crash

It's not only my problem, i know of other guy who has the same laptop and has
this problem.

without proper driver support it is impossible to set up a dual head
configuration with this graphics chip.

Also, connecting to a beamer or external monitor is only possible by means of
the commandline-only tool i855crt... Maybe this helps to isolate the problem and
helps with a solution!

Is there any way i can provide more information on this?

please attach the output from acpidump

Created attachment 12527 [details]
acpidump output

Created attachment 12538 [details]
patch-debug

Method (DSSM, 0, NotSerialized)
                {
                    If (LEqual (0x00, DSEN))
                    {
                        Store (CADL, PADL)
                        If (LEqual (OSTP, 0x03))
                        {
                            Notify (\_SB.PCI0, 0x00)
                        }
                        Else
                        {
                            Notify (\_SB.PCI0.GFX0, 0x00)
                        }

                        Sleep (0x03E8)
                        Notify (\_SB.PCI0.GFX0, 0x80)
                    }

                    If (LEqual (0x01, DSEN))
                    {
                        \_SB.PCI0.LPC0.PHSS (0x01)
                        Notify (\_SB.PCI0.GFX0, 0x81)
                    }
}
If DSEN == 0x01, video driver will get notification 0x81.

Method (_DOS, 1, NotSerialized)
{
       Store (And (Arg0, 0x03), DSEN)
}
And DSEN is set by the _DOS method.

So first please try "echo  0 >/proc/acpi/video/GFX0/DOS" and see if there is any difference.
If the system still hangs, please apply the debug patch in comment #9 and reload the acpi video driver.

I don't have CONFIG_ACPI_VIDEO enabled, so /proc/acpi/video/GFX0/DOS doesnt exist.

Should i still apply that patch?

Hmm, then can you try a recent mainline kernel with CONFIG_ACPI_VIDEO=m?
you don't need to apply the patch, but please try with /proc/acpi/video/GFX0/DOS = 0 and 1.

/proc/acpi/video/GFX0/DOS = 0 --> No crash :)

/proc/acpi/video/GFX0/DOS = 1 --> Crash

That's great. Thanks, Sergio. :)
Do you have an extra CRT plugged in when you press the Fn+F5?
If the answer is yes, is the output display actually switched when DOS is 0?
If the answer is no, well, Fn+F5 doesn't make sense for you. and we can't debug further. :(
BTW: you must do the test in X mode, right? Please confirm that system doesn't crash with DOS = 1 when you press Fn+F5 in console mode.

(In reply to comment #14)
> That's great. Thanks, Sergio. :)
> Do you have an extra CRT plugged in when you press the Fn+F5?
No. I'll try that latter, maybe still today.


> BTW: you must do the test in X mode, right? Please confirm that system
> doesn't
> crash with DOS = 1 when you press Fn+F5 in console mode.
It crashes in console mode also. In grub/bios/windows it doesnt crash.

>It crashes in console mode also
That's interesting.

If (LEqual (0x01, DSEN))
    {
          \_SB.PCI0.LPC0.PHSS (0x01)
           Notify (\_SB.PCI0.GFX0, 0x81)
    }
If DOS = 1,
\_SB.PCI0.LPC0.PHSS (0x01) will generate a SMI.
Notify (\_SB.PCI0.GFX0, 0x81) will send a notification to ACPI video driver.
I suspect that \_SB.PCI0.LPC0.PHSS (0x01) is the root cause of the system crash.

Can you apply the patch in comment #9 and try again in console mode with DOS=1?

> Do you have an extra CRT plugged in when you press the Fn+F5?

I tried this. It doesnt switch, it doesnt crash, but i can see the imagem on the CRT (and on the LCD at the same time)

This is strange, because the only way i had to have the CRT display something was if i booted the laptop with the CRT already plugged. Now i just plugged it and saw the image.


> Can you apply the patch in comment #9 and try again in console mode with
> DOS=1?
It still crashes with the patched moduled.

>Now i just plugged it and saw the image.
Do you mean you even don't need to press the Fn+F5?
If Fn+F5 works properly, in your case, usually we can get
LCD on, CRT on --> LCD off, CRT on -->LCD on, CRT off-->to the start point

>It still crashes with the patched moduled.
OK, then \_SB.PCI0.LPC0.PHSS (0x01) is the only suspect now.
It's really bad for the bios to crash the system when DOS=1.
this piece of code is never tested even in windows? I'm not sure. :(
But I think you can report a bios bug to acer.

Len, it seems that set DOS to 1 by default is not a good idea.
Windows don't crash when Fn+F5 is pressed, so they probably set DOS to 0 by default.

I'll send a patch to use DOS=0 by default.

Is there a way to set DOS to 1 in windows?

I have no idea. :(
Sergio, can you help me verify if _DOS=2 and _DOS=3 works for you?

The reason why the image appeared on crt and LCD without pressing Fn+F5 was because i had Option  "MonitorLayout" "None,CRT+LFP" in my xorg.conf.

So, repeating the tests in console mode (with no X server running):

DOS in (0, 2, 3): No switching, nothing happens, just some flickering.
DOS = 1: Crash and sometimes slowdown

acpi=off: it works.

Created attachment 12851 [details]
clear _DOS by default

This patch is also sent to the linux-acpi mail list.
Hope it can hit 2.6.24

But in the ACPI spec, section "B.4.1 _DOS (Enable/Disable Output Switching)" it says the default _DOS value must be 1.

Yes, I know, :(
But the laptop hangs in SMM mode if _DOS is set to 1.
Something strange is that windows works well on this laptop.
This makes me doubt if windows set _DOS to 1 by default.

In fact, the SMM code may polute the video native register.
This may hang the system when there is a native video driver loaded.
Linux needs to set _DOS to 0 so that the native video driver
can switch the display instead of BIOS when X is running.

Hi
I've just got 2.6.23 and this patch freezes the system whenever I change of display or close the lid! With this dell latitude x300, it's simply the opposite of the reported bug now happening:
/proc/acpi/video/*/DOS = 1 -> it works fine
/proc/acpi/video/*/DOS = 0 (now the default) -> it crashes (when in X, not in console)

The graphic chipset is an intel 855GM. In X I'm using the "intel" driver with acceleration disabled.

Is there any way to fix it while not breaking the reported bug? Can this be fixed in the "intel" driver? Or am I doomed to change the default of _DOS back to 1 from now on?

Does _DOS=3 (or 7) work any better?

On my side (with 2.6.23.1), DOS={1,3,7} work all the same: fine. Only 0 freezes the computer.

(In reply to comment #21)
> The reason why the image appeared on crt and LCD without pressing Fn+F5 was
> because i had Option  "MonitorLayout" "None,CRT+LFP" in my xorg.conf.
> 
> So, repeating the tests in console mode (with no X server running):
> 
> DOS in (0, 2, 3): No switching, nothing happens, just some flickering.
> DOS = 1: Crash and sometimes slowdown
> 
> acpi=off: it works.
> 
just want to confirm when you say "acpi=off: it works", it means the display can be cycled as rui mentioned in comment# 18, i.e. LCD on, CRT on --> LCD off, CRT on -->LCD on, CRT off-->to the start point?

(In reply to comment #28)
> (In reply to comment #21)
> > The reason why the image appeared on crt and LCD without pressing Fn+F5 was
> > because i had Option  "MonitorLayout" "None,CRT+LFP" in my xorg.conf.
> > 
> > So, repeating the tests in console mode (with no X server running):
> > 
> > DOS in (0, 2, 3): No switching, nothing happens, just some flickering.
> > DOS = 1: Crash and sometimes slowdown
> > 
> > acpi=off: it works.
> > 
> just want to confirm when you say "acpi=off: it works", it means the display
> can be cycled as rui mentioned in comment# 18, i.e. LCD on, CRT on --> LCD
> off,
> CRT on -->LCD on, CRT off-->to the start point?
> 

yes, it cycles

Sergio's hang on _DOS=1 was fixed by
commit a21101c46ca5b4320e31408853cdcbf7cb1ce4ed
(ACPI: video: _DOS=0 by default to prevent hotkey hang)

But that caused Eric's hang on _DOS=0

both systems are Intel i855GM hardware.

The X guys tell us in no uncertain terms that they do not
want ACPI switching the display beneath them -- that is
the job of the native graphics driver.  So at this point
we have no choice but to:

1. leave DOS=0 the default (good for Sergio, bad for Eric)
2. for systems where ACPI display switching works (Eric)
   manually use "echo 1 > /proc/acpi/video/*/DOS"
   as a workaround.
3. Wait for X's native drivers to include native display switching.
   I know this is in development -- at least for intel graphics chips --
   but I don't know how far along it is.

closed as DOCUMENTED.

May be related to https://bugs.freedesktop.org/show_bug.cgi?id=11432, I neglected to ask if the reporters in that bug had _DOS=0 or 1.

In some cases, we can handle firmware code (SMM or whatever) touching video registers, but generally we can't handle real changes to the pipe configuration.  Theoretically we could with a lot of work to the gfx driver (hooking into the notification and reprobing the configuration), but that's not something we do now, and current efforts are focused on handling hotkey notifications completely in the driver.

(In reply to comment #30)
> Sergio's hang on _DOS=1 was fixed by
> commit a21101c46ca5b4320e31408853cdcbf7cb1ce4ed
> (ACPI: video: _DOS=0 by default to prevent hotkey hang)
> 
> But that caused Eric's hang on _DOS=0
> 
> both systems are Intel i855GM hardware.
> 
> The X guys tell us in no uncertain terms that they do not
> want ACPI switching the display beneath them -- that is
> the job of the native graphics driver.  So at this point
> we have no choice but to:
> 
> 1. leave DOS=0 the default (good for Sergio, bad for Eric)
> 2. for systems where ACPI display switching works (Eric)
>    manually use "echo 1 > /proc/acpi/video/*/DOS"
>    as a workaround.
> 3. Wait for X's native drivers to include native display switching.
>    I know this is in development -- at least for intel graphics chips --
>    but I don't know how far along it is.
> 
> closed as DOCUMENTED.

My HP 6710B also crashes when DOS=0, DOS=1,2 or 3 works just fine though. This has an GM965 intel chipset. What does the ACPI spec say about values other then 0 or 1 ?

It seems that the change that was done from 1 to 0 causes some quit bad regressions on some laptops, while fixing others. Otoh all reporters say that DOS=2 works..

The switch from DOS=1 (demanded by ACPI spec, if above comments are correct) to DOS=0 caused regressions (on 855 and 965 chipsetst).
The regressions are hangs as described in comment #25 on 855GM and GM965 (comment #32). But also non-working display switching on others.

We possibly like to switch back to DOS=1 (should also go to 2.6.24.X then to stay consistent, which is a bit dangereous but IMO still better than to have one kernel that behave in an other way than previous and following ones).

I gave this a try on a Compaq 6715 with an ATI card.
On console:
DOS=0 -> nothing happens
DOS=1 -> Display switching works fine
DOS=2 -> nothing happens
DOS=3 -> Display switching works fine

With X-server started(binary,fglrx):
DOS=[0-4] -> nothing happens

With X-server started(OpenSource,readonhd):
DOS=0 -> nothing happens
DOS=1 -> freeze
DOS=2 -> nothing happens
DOS=3 -> freeze

With X-server started(OpenSource,framebuffer):
DOS=0 -> nothing happens
DOS=1 -> freeze
DOS=2 -> nothing happens
DOS=3 -> freeze

While X-server was started and switched back to console, still the first (console) is valid (DOS=0,2 does nothing, but DOS=1,3 can switch the display, only tested 0 and 1...)

The display switch key is not exported via acpi event, but via normal key event, but it is not know yet.

Hmm, while switching display on console is really cool..., I doubt it justifies possible freezes when running on X-server or does it make sense to propagate to the X-people or distributions that they add this to their X-startup script:
#!/bin/bash
  for x in /proc/acpi/video/*/DOS do
      echo 0 >$x
  done

Advantage:
  - Then we would stay compatible with the spec.
  - Display switching would work without X.
Disadvantage:
  - If zeroing is forgotten when X is started machine freezes when pushing
    the key...

Hmm or could the freezes of framebuffer and radeonhd driver possibly be solved, fglrx also works... I expect the freezes more or less come from SMM code popping in, confusing the driver from the back, not much one can do about?

Comments?

AFAIK DOS=1 isn't demanded by the spec, all of the values are supposed to work:
Arguments:
       Bit 1:0
               0: The system BIOS should not automatically switch (toggle) the
                  active display output,
                  but instead just save the desired state change for the
                  display output devices in
                  variables associated with each display output, and generate
                  the display switch event.
                  OSPM can query these state changes by calling the _DGS
                  method.
               1: The system BIOS should automatically switch (toggle) the
                  active display output, with
                  no interaction required on the OS part. The display switch
                  event should not be
                  generated in this case.
               2: The _DGS values should be locked. It’s highly recommended
                  that the system BIOS
                  do nothing when hotkey pressed. No switch, no notification.
               3: The system BIOS should not automatically switch (toggle) the
                  active display output,
                  but instead generate the display switch event notify codes
                  0x82, 0x83, or 0x84.
                  OSPM will determine what display output state should be set,
                  and change the display
                  output state without further involvement from the system
                  BIOS.
       Bit 2
               0: The system BIOS should automatically control the brightness
                  level of the LCD when
                  the power changes from AC to DC.
               1: The system BIOS should not automatically control the
                  brightness level of the LCD
                  when the power changes from AC to DC.

DOS=1 was added to the spec so machines w/o multi-head aware graphics drivers could still use multiple screens (typically laptops running Windows 95ish stuff).  vgacon & fb drivers also fall into that category, but the X drivers for the main chipsets these days do not.  So I think Thomas is on the right track:  at X startup, DOS should probably be set to something other than 1 (either 0, 2 or 3 depending on what the X driver supports).

another side effect caused by DOS=0.
http://bugzilla.kernel.org/show_bug.cgi?id=9642
I agree that we should revert the patch a21101c46ca5b4320e31408853cdcbf7cb1ce4ed and let X set the DOS value when it's started.
But we'd better find a proper place in sys as the proc I/F is deprecated.

Another Question:
should we keep the vidou_output class sys I/F? It invokes ACPI methods, e.g. _DSS, _DCS, to switch the display, which is known to work on none laptops.

If we want to keep this I/F, I suggest to add an attribute for video_output class, which is used to set different mode for display switching.

Actually, display switching *does* work on thinkpads.  I recently asked people if I could get rid of it from thinkpad-acpi, and many requested that I don't.

Usual caveats, though. It works only on text mode, or VESA.

> another side effect caused by DOS=0.
I wonder how this can be broken down...
We have (graphics drivers + console + some versions?) * (laptop models) * (BIOS versions, Vista capable?) * 2 (DOS=0/1) to test...

> Usual caveats, though. It works only on text mode, or VESA.
Yes, I think I also saw DOS=1 for vesa-fb and console working on another machine, above test machine seem to have a specific problem here again...

I haven't read the bugs in detail, do we have a chance to figure out why the machines hang with DOS=0 (this should never happen? DOS=1 and graphics driver active would make some sense..., but I'd expect DOS=0 to be the safe one?).

Maybe we could check for:
  - Are all video extension functions available
  - Blacklist for date (e.g. not before 2006)
otherwise do not touch video switching at all (maybe the same with brightness). Would that help to let the machines not freeze? Or better would this match most machines which would not work correctly anyway or even freeze?

We also need a better overview IMO. Having single bug reports flying around is too much work to read up and get in order.
I don't have much reports yet. OpenSUSE 10.3 was shipped with the video driver blacklisted at the end because it interfered with the Intel graphics driver. 
I wonder how we could get people together and summarize yet found problems...

*** Bug 9642 has been marked as a duplicate of this bug. ***

some interesting update.

We tried to use KVM to peek at how windows use _DOS.
And this is the result:
customized dsdt:
Method (_DOS, 1, NotSerialized)
{
        Store(0x11, \DBGL)
        Store(Arg0, \DBGL)
        Store(0x12, \DBGL)
}

result:
ACPI: DBG: 0x00000011
ACPI: DBG: 0x00000000
ACPI: DBG: 0x00000012

It seems that windows clears _DOS like we do in Linux...

I'll attach the customized dsdt and the test results of running a windows XP
and running a fc6

Created attachment 16236 [details]
customized dsdt

Created attachment 16237 [details]
xp-log

Created attachment 16238 [details]
fc6-log

> We tried to use KVM to peek at how windows use _DOS.
Wow. That's cool.
Do you mind to give a little introduction on the linux-acpi list how you've done that.
> result:
> ACPI: DBG: 0x00000011
This does not look like Linux acpica output?

1) Have you just overridden the DSDT in Windows and used Windows tools to get the debug output? If yes, kvm is not needed?

2) Or have you passed the DSDT to Windows through KVM? Then you still need to know where to search or how to get the debug output produced in Windows? Or can you pass the debug output down to Linux though kvm then?

(In reply to comment #38)
> *** Bug 9642 has been marked as a duplicate of this bug. ***
> 
hi, 
Good news on kernel kernel-2.6.25.4-10.fc8 , blacklight , suspend and hibernation works correctly .

Thanks

weird. I don't think there is any change in Linux on this.
hmm, what do you see when "cat /proc/acpi/video/*/DOS"?

(In reply to comment #45)
> weird. I don't think there is any change in Linux on this.
> hmm, what do you see when "cat /proc/acpi/video/*/DOS"?
> 

hmm, my bug had marked has duplicated by this one, but my problem is with blacklight, which stop to work on kernel-2.6.23 ...
on kernel 2.6.25 
cat /proc/acpi/video/C055/DOS
DOS setting: <0>

(In reply to comment #46)
> (In reply to comment #45)
> > weird. I don't think there is any change in Linux on this.
> > hmm, what do you see when "cat /proc/acpi/video/*/DOS"?
> > 
> 
> hmm, my bug had marked has duplicated by this one, but my problem is with
> blacklight, which stop to work on kernel-2.6.23 ...
> on kernel 2.6.25 
> cat /proc/acpi/video/C055/DOS
> DOS setting: <0>
> 
arr ... my mistake  on kernel 2.6.25 _still_ not having backlight on boot.
but after a resume I got it, has in kernel 2.6.23. Which is funny because just don't work on boot.

I patch kernel 2.6.24 to have _DOS = 1 , and backligth back to work. 
BTW I also have an Intel graphics, but one 915GM. 

(In reply to comment #18) 
> Len, it seems that set DOS to 1 by default is not a good idea.
> Windows don't crash when Fn+F5 is pressed, so they probably set DOS to 0 by
> default.
> 
> I'll send a patch to use DOS=0 by default.

That could not be right , this could be a drm i915 problem , I'd like to know if 
DOS=1 by default , with latest kernel works or still have this issue , if the issue is gone , than we should back to DOS=1 by default
 
 

Created attachment 18402 [details]
revert the bitsect patch 

According Thomas Renninger:
http://marc.info/?l=linux-acpi&m=121635170410211&w=2

I know about a lot HP and others having problems with _DOS=0 and freezing on 
LID:
https://bugzilla.novell.com/show_bug.cgi?id=378917 (-> a lot duplicates)
https://bugzilla.novell.com/show_bug.cgi?id=290219

we should put _DOS=1 on boot, I am Sérgio Basto ans not Sergio Luis .

My computer info is on http://bugzilla.kernel.org/show_bug.cgi?id=9642

(In reply to comment #49)
 
> we should put _DOS=1 on boot, I am Sérgio Basto ans not Sergio Luis .

(*) and I am not Sergio Luis.  

> My computer info is on http://bugzilla.kernel.org/show_bug.cgi?id=9642

Other reason, Sergio Luis and Eric Pielbug don't reply to this bug report saying if  _DOS=1 problem still there or not  

(In reply to comment #48)
> That could not be right , this could be a drm i915 problem , I'd like to know
> if 
> DOS=1 by default , with latest kernel works or still have this issue , if the
> issue is gone , than we should back to DOS=1 by default
Sorry for the delay.

I'm the original reporter, who was very happy with DOS=0 since it fixed my problem (i have crashes with DOS=1).

I just tested this again, with a more recent kernel (2.6.24.16) and now it crashes with _BOTH_ DOS=1 and DOS=0.

Isto serve de alguma coisa ? 

Following the comment, I added ForceEnablePipeA to xorg.conf, like below

Section "Device"
 ... <other options here> ...
 Option "ForceEnablePipeA" "true"
EndSection

I tried 10x to reproduce the problem without success (login/logout). I
was possible to hibernate and suspend as well. This option seems to
solve the problem. I am using a newer gdm version as well
(2.20.6-0ubuntu1) but problem was happening with it if I don't use the
cited option.

Just to keep the bug tracker up to date. I will test more. I have a Dell
Latitude D505 with Intel 855GM.

https://bugs.launchpad.net/xorg-server/+bug/138256








On Wed, 2008-10-22 at 15:58 -0700, bugme-daemon@bugzilla.kernel.org
wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=6001
> 
> 
> 
> 
> 
> ------- Comment #51 from ld.fifty@gmail.com  2008-10-22 15:58 -------
> (In reply to comment #48)
> > That could not be right , this could be a drm i915 problem , I'd like to
> know
> > if 
> > DOS=1 by default , with latest kernel works or still have this issue , if
> the
> > issue is gone , than we should back to DOS=1 by default
> Sorry for the delay.
> 
> I'm the original reporter, who was very happy with DOS=0 since it fixed my
> problem (i have crashes with DOS=1).
> 
> I just tested this again, with a more recent kernel (2.6.24.16) and now it
> crashes with _BOTH_ DOS=1 and DOS=0.
> 
> 

well #52 , have some Portuguese works , that can be ignored ..., sorry.

Matthew Garrett, (http://lkml.org/lkml/2008/11/10/200)  has proposed another patch http://lkml.org/lkml/2008/11/10/233
that is on recent fedora kernels 2.6.27.

I am trying keep the track of this problem, here.

ah other thing talking with Sérgio Luis, switching displays, means switching from LCD to CRT, which only triggered when we have ACPI. So when he said that his laptop don't crash with acpi=off, also means that not even, was close to work. 
Reading this bug the assumption that _DOS=0 solve Sérgio Luís problem and changing kernel because that at least should be revert.

hmm, setting _DOS back to 1 is not a good idea.
because we also have laptops that crash when _DOS=1.
sorry that I forget the bug entries.

(In reply to comment #54)
> hmm, setting _DOS back to 1 is not a good idea.
> because we also have laptops that crash when _DOS=1.
> sorry that I forget the bug entries.
> 

I don't think so. According Thomas Renninger: "I know about a lot HP and others having problems with _DOS=0 "
( http://marc.info/?l=linux-acpi&m=121635170410211&w=2 )
So we have laptops that crash when _DOS=0 
I don't notice any laptop that crash with _DOS=1.

I saw one nice serial backtrace in a bug, but cannot find it anymore.
Could anyone attach a serial console, increase debug ACPI debug level and then trigger that?
echo 0x21f >/sys/modules/acpi/parameters/debug_level
netconsole might also work (in the kernel sources):
Documentation/networking/netconsole.txt
IIRC the message was an "Unable to handle paging request" or similar.
It would be great to see which ACPI line is causing that and why the kernel/HW is freezing.

In 2.6.28 there is code which makes the video.ko module not registering for not available ACPI graphics cards. Maybe this came from poking on the dummy graphics device? Reporting whether it works or not if you want to give the latest git a test anyway would be great.

do you mean http://bugzilla.kernel.org/show_bug.cgi?id=11259#c5 ?

Created attachment 19136 [details]
customized DSDT: remove the AML code that may crash the system

Lius,
now the system crashes no matter _DOS=0 or _DOS=1, right?
could you update your system first? Including both kernel and X.
If the problem still exists, please try this customized DSDT.
how to override a DSDT can be found at:
http://www.lesswatts.org/projects/acpi/overridingDSDT.php

> do you mean http://bugzilla.kernel.org/show_bug.cgi?id=11259#c5
No, someone provided a full acpi.debug_level=0x21F trace until the machine hang IIRC.

Jan  2 11:54:57 segulix kernel: dswstate-0243 [00] ds_result_stack_push  : Results=f49e94b0 State=f48a6a00
Jan  2 11:54:57 segulix kernel: dswstate-0198 [00] ds_result_push        : Obj=f6d3f5c8 [Package] State=f48a6a00 Num=1 Cur=0
Jan  2 11:54:57 segulix kernel: dswscope-0078 [00] ds_scope_stack_clear  : Popped object type (Method)
Jan  2 11:54:57 segulix kernel:  exdump-0489 [00] ex_dump_operand       : f6d3f5c8 Package [Len 4] ElementArray f786c8e0
Jan  2 11:54:57 segulix kernel:  exdump-0487 [00] ex_dump_operand       :  [1] f6d3f9d8 Integer 0000000000000002
Jan  2 11:54:57 segulix kernel:  exdump-0487 [00] ex_dump_operand       :  [1] f6d3fa78 Integer 0000000000000127
Jan  2 11:54:57 segulix kernel:  exdump-0487 [00] ex_dump_operand       :  [1] f6d3f708 Integer 00000000000002D0
Jan  2 11:54:57 segulix kernel:  exdump-0487 [00] ex_dump_operand       :  [1] f6d3f7d0 Integer 000000000000312B
Jan  2 11:54:57 segulix kernel:   event-0242 [00] bus_generate_netlink_e: Failed to send a Genetlink message!
Jan  2 11:55:00 segulix kernel:     osl-0708 [00] os_execute            : Scheduling function [c054d56e(f78df55c)] for deferred execution.

is anything related ? means anything for you ? 
if I can provide more information , please tell me ! 

this title should be "Switching to tv-out freezes system if _DOS is 1 on i855GM"

(In reply to comment #58)
> Created an attachment (id=19136) [details]
> customized DSDT: remove the AML code that may crash the system
> 
> Lius,
> now the system crashes no matter _DOS=0 or _DOS=1, right?
> could you update your system first? Including both kernel and X.
> If the problem still exists, please try this customized DSDT.
> how to override a DSDT can be found at:
> http://www.lesswatts.org/projects/acpi/overridingDSDT.php
> 
Do you mean me (Luis)?

> this title should be "Switching to tv-out freezes system if _DOS is 1 on
> i855GM"

tv-out is fine, the problem is with vga

(In reply to comment #62)

> > this title should be "Switching to tv-out freezes system if _DOS is 1 on
> i855GM"
> 
> tv-out is fine, the problem is with vga
> 

You said : 

My laptop has a key (F5) that says CRT/LCD. 

you said on Problem Description:
freeze when press fn+f5 
so this is _not_ on switching consoles/display with crtl-alt-f1 to f9 , but switch to tv-out. Which is very different, switching to CRT needs a big support from drive (normally calls dual-head).
Change between ttys no . 

So please confirm that is the key fn+f5 that is the problem.

What do you mean with VGA ?  you got a laptop with a LCD and can plug a CRT 

 

> so this is _not_ on switching consoles/display with crtl-alt-f1 to f9

I never said it was a problem with switching between virtual terminals (vc1 to vc9). It's a problem when switching to VGA output.


> What do you mean with VGA ?  you got a laptop with a LCD and can plug a CRT 

Fn+F5 enables VGA output, VGA+LCD or only LCD (default).

My laptop also has a tv-out port which I never tried but I think it's unrelated to this bug though. I don't even know if it's the same key to enable it, the button only says CRT/LCD, not TV.

Switch to tv-out or to VGA, is the same thing, you need dual-head drive support.
The only difference is the hardware adapter. 
yes, the same key will work for tv-out. 
Thanks for clarifying this issue. 

I just found a bug on lid with mac OS, at 
https://bugzilla.redhat.com/show_bug.cgi?id=432587#c17
also says the only solution is pre-kernels 2.6.23 .

I still have to use this patch, to get lid working 

 static int acpi_video_bus_start_devices(struct acpi_video_bus *video)
 {
-       return acpi_video_bus_DOS(video, 0, 0);
+       return acpi_video_bus_DOS(video, 3, 1);
 }

Created attachment 22334 [details]
customized DSDT: set GPIO 0x0D to SCI mode if _DOS=0

this is a customized DSDT I made based on the acpidump you attached in bug #9642.
please try this DSDT and see if it helps.

Just wanted to say I'm no longer the owner of that laptop so I can't test things anymore.



Good luck.

Created attachment 22402 [details]
dmesg with Override DSDT

(In reply to comment #67)
> Created an attachment (id=22334) [details]
> customized DSDT: set GPIO 0x0D to SCI mode if _DOS=0
> 
> this is a customized DSDT I made based on the acpidump you attached in bug
> #9642.
> please try this DSDT and see if it helps.

No, lid still doesn't work , I saw acpid lid events ( 
acpid: completed event "button/lid C1E9") but backlight doesn't off, when press the lid button.

okay, this is not the problem described in this bug report.
let's reopen 9642 and close this one as the problem is not reproducible.