Re: System hard lock when closing lid(2nd try)
On Sa, 27 Okt 2007, Peter Clifton wrote: http://www2.eng.cam.ac.uk/~pcjc2/ubuntu/xserver-xorg-video-intel_2.1.1-0ubuntu10~pcjc2.2.diff.gz Any chances that all these patches (there are quite a lot in there!) are included in the Debian packages, too? It seems that several of these patches might be of interest for us, too. Best wishes Norbert --- Dr. Norbert Preining [EMAIL PROTECTED]Vienna University of Technology Debian Developer [EMAIL PROTECTED] Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- DORRIDGE (n.) Technical term for one of the lame excuses written in very small print on the side of packets of food or washing powder to explain why there's hardly anything inside. Examples include 'Contents may have settled in transit' and 'To keep each biscuit fresh they have been individually wrapped in silver paper and cellophane and separated with corrugated lining, a cardboard flap, and heavy industrial tyres'. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: System hard lock when closing lid(2nd try)
On Sat, 2007-10-27 at 14:20 +0200, Raúl Sánchez Siles wrote: Hello: Peter Clifton wrote: On Fri, 2007-10-26 at 17:41 +0200, Raúl Sánchez Siles wrote: Hello All: Some time ago(2007/09/17) I wrote this e-mail: Raúl Sánchez Siles wrote: Hello all: I've searched for a more user related ML, but this is the closest I've found. I own a Dell inspiron 510m laptop which include the HW listed at [1] As you can see there the graphics card is an intel 855GM. The newer xorg intel driver tries to save power by disabling one of the video output pipes of the card, the one that could drive an external VGA monitor. As a result, someone told me that the system enters in SMM (System Management Mode), leaves the system in such a state that the system ends up locking totally: no ssh connection or sys-rq combination works, just hard power off. More details at https://bugs.freedesktop.org/show_bug.cgi?id=11432 The lid problem stills exist on a current Xorg version, even with intel video driver git version. I'm not surprised since I suspect heavily on a BIOS problem. I'm coming back with more attached info: Thanks a lot for your reply, Peter. :) There is probably a BIOS issue (from reports I've seen on this issue), however the git version of the xserver-xorg-video-intel driver does not address a couple of crashes with 855 hardware which are caused by the X driver writing registers in the card. http://www2.eng.cam.ac.uk/~pcjc2/ubuntu/xserver-xorg-video-intel_2.1.1-0ubuntu10~pcjc2.2.diff.gz Shows the diff applied to a (yet unreleased) Ubuntu package for the drivers. (Applies against 2.1.1 release version). You should be able to find the patches in the debian/patches/ dir which the diff creates. I've been following this thread on the xorg-devel ML, and I have those patches queued for testing ;) It might be worth looking at these, and revisiting the BIOS issue if (as is unfortunately likely) if there remains an issue. If you pay attention to https://bugs.freedesktop.org/show_bug.cgi?id=11432 I had published there a patch (comment #23) there that has been happily working for me since I post it (yet it works). But what it does is ugly and has drawbacks as explained there so I still consider it a workaround and not a final solution. That's the reason I came here, to check out wether the Linux kernel could address the issue. I guess this depends on whether it turns out to be ACPI code which is poking the video chip when you close / open the lid. Please try the above patches without the patch from comment #23, as there is a chance it will still improve things. (It'd be good to identify which cases it does help in). There might of course be a similar test required in the display detection code which enables PipeA temporarily, as in the Video overlay enable code. If it still crashes with the patches I wrote, it would be good to find out exactly what line in the driver locks the system up in your case. I guess it might be a register access to PIPEACONF somewhere. For the patches I made, I added lots of driver print messages, before and after suspect register accesses, added a sync(); call after each message, and got my tester to work with hard-drive write-caching switched off. (This got the log entries previous to the hang to disk.) Please let us know on the xorg mailing-list if you discover anything interesting! Regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: System hard lock when closing lid(2nd try)
On Fri, 2007-10-26 at 17:41 +0200, Raúl Sánchez Siles wrote: Hello All: Some time ago(2007/09/17) I wrote this e-mail: Raúl Sánchez Siles wrote: Hello all: I've searched for a more user related ML, but this is the closest I've found. I own a Dell inspiron 510m laptop which include the HW listed at [1] As you can see there the graphics card is an intel 855GM. The newer xorg intel driver tries to save power by disabling one of the video output pipes of the card, the one that could drive an external VGA monitor. As a result, someone told me that the system enters in SMM (System Management Mode), leaves the system in such a state that the system ends up locking totally: no ssh connection or sys-rq combination works, just hard power off. More details at https://bugs.freedesktop.org/show_bug.cgi?id=11432 This result is the same no matter what Linux version I use, tried 2.6.20,21 and 22. I have done some research as to know if this could be avoided some way in Linux. I ran the linux firmwarekit, I checked the dsdl table, I upgraded bios, tried different boot parameters but no valuable results I got. This information is available, so feel free to ask for it. I'd like to know if there's anything that could be done with regard to Linux kernel to soothe or solve the issue. Of course, I'm at your disposal to do whatever test is needed. Just in case, I also attach a dmesg output, maybe not the latest stable kernel, but still 2.6.22. Thanks a lot. [1] lspci -nn 00:00.0 Host bridge [0600]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3580] (rev 02) 00:00.1 System peripheral [0880]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3584] (rev 02) 00:00.3 System peripheral [0880]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3585] (rev 02) 00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02) 00:02.1 Display controller [0380]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 [8086:24c2] (rev 01) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 [8086:24c4] (rev 01) 00:1d.2 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 [8086:24c7] (rev 01) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller [8086:24cd] (rev 01) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 81) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge [8086:24cc] (rev 01) 00:1f.1 IDE interface [0101]: Intel Corporation 82801DBM (ICH4-M) IDE Controller [8086:24ca] (rev 01) 00:1f.5 Multimedia audio controller [0401]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller [8086:24c5] (rev 01) 00:1f.6 Modem [0703]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller [8086:24c6] (rev 01) 01:01.0 CardBus bridge [0607]: Texas Instruments PCI4510 PC card Cardbus Controller [104c:ac44] (rev 02) 01:01.1 FireWire (IEEE 1394) [0c00]: Texas Instruments PCI4510 IEEE-1394 Controller [104c:8029] 01:03.0 Network controller [0280]: Intel Corporation PRO/Wireless 2200BG Network Connection [8086:4220] (rev 05) 01:08.0 Ethernet controller [0200]: Intel Corporation 82801DB PRO/100 VE (MOB) Ethernet Controller [8086:103d] (rev 81) Maybe by that date there was nobody avaible for considering this issue so I'm trying again. The lid problem stills exist on a current Xorg version, even with intel video driver git version. I'm not surprised since I suspect heavily on a BIOS problem. I'm coming back with more attached info: There is probably a BIOS issue (from reports I've seen on this issue), however the git version of the xserver-xorg-video-intel driver does not address a couple of crashes with 855 hardware which are caused by the X driver writing registers in the card. http://www2.eng.cam.ac.uk/~pcjc2/ubuntu/xserver-xorg-video-intel_2.1.1-0ubuntu10~pcjc2.2.diff.gz Shows the diff applied to a (yet unreleased) Ubuntu package for the drivers. (Applies against 2.1.1 release version). You should be able to find the patches in the debian/patches/ dir which the diff creates. It might be worth looking at these, and revisiting the BIOS issue if (as is unfortunately likely) if there remains an issue. Regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) - To unsubscribe from this list: send the line
Re: System hard lock when closing lid(2nd try)
Hello: Peter Clifton wrote: On Fri, 2007-10-26 at 17:41 +0200, Raúl Sánchez Siles wrote: Hello All: Some time ago(2007/09/17) I wrote this e-mail: Raúl Sánchez Siles wrote: Hello all: I've searched for a more user related ML, but this is the closest I've found. I own a Dell inspiron 510m laptop which include the HW listed at [1] As you can see there the graphics card is an intel 855GM. The newer xorg intel driver tries to save power by disabling one of the video output pipes of the card, the one that could drive an external VGA monitor. As a result, someone told me that the system enters in SMM (System Management Mode), leaves the system in such a state that the system ends up locking totally: no ssh connection or sys-rq combination works, just hard power off. More details at https://bugs.freedesktop.org/show_bug.cgi?id=11432 The lid problem stills exist on a current Xorg version, even with intel video driver git version. I'm not surprised since I suspect heavily on a BIOS problem. I'm coming back with more attached info: Thanks a lot for your reply, Peter. :) There is probably a BIOS issue (from reports I've seen on this issue), however the git version of the xserver-xorg-video-intel driver does not address a couple of crashes with 855 hardware which are caused by the X driver writing registers in the card. http://www2.eng.cam.ac.uk/~pcjc2/ubuntu/xserver-xorg-video-intel_2.1.1-0ubuntu10~pcjc2.2.diff.gz Shows the diff applied to a (yet unreleased) Ubuntu package for the drivers. (Applies against 2.1.1 release version). You should be able to find the patches in the debian/patches/ dir which the diff creates. I've been following this thread on the xorg-devel ML, and I have those patches queued for testing ;) It might be worth looking at these, and revisiting the BIOS issue if (as is unfortunately likely) if there remains an issue. If you pay attention to https://bugs.freedesktop.org/show_bug.cgi?id=11432 I had published there a patch (comment #23) there that has been happily working for me since I post it (yet it works). But what it does is ugly and has drawbacks as explained there so I still consider it a workaround and not a final solution. That's the reason I came here, to check out wether the Linux kernel could address the issue. Regards, Raúl Sánchez Siles -Proud Debian user- Linux registered user #416098 - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
System hard lock when closing lid(2nd try)
Hello All: Some time ago(2007/09/17) I wrote this e-mail: Raúl Sánchez Siles wrote: Hello all: I've searched for a more user related ML, but this is the closest I've found. I own a Dell inspiron 510m laptop which include the HW listed at [1] As you can see there the graphics card is an intel 855GM. The newer xorg intel driver tries to save power by disabling one of the video output pipes of the card, the one that could drive an external VGA monitor. As a result, someone told me that the system enters in SMM (System Management Mode), leaves the system in such a state that the system ends up locking totally: no ssh connection or sys-rq combination works, just hard power off. More details at https://bugs.freedesktop.org/show_bug.cgi?id=11432 This result is the same no matter what Linux version I use, tried 2.6.20,21 and 22. I have done some research as to know if this could be avoided some way in Linux. I ran the linux firmwarekit, I checked the dsdl table, I upgraded bios, tried different boot parameters but no valuable results I got. This information is available, so feel free to ask for it. I'd like to know if there's anything that could be done with regard to Linux kernel to soothe or solve the issue. Of course, I'm at your disposal to do whatever test is needed. Just in case, I also attach a dmesg output, maybe not the latest stable kernel, but still 2.6.22. Thanks a lot. [1] lspci -nn 00:00.0 Host bridge [0600]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3580] (rev 02) 00:00.1 System peripheral [0880]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3584] (rev 02) 00:00.3 System peripheral [0880]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3585] (rev 02) 00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02) 00:02.1 Display controller [0380]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 [8086:24c2] (rev 01) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 [8086:24c4] (rev 01) 00:1d.2 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 [8086:24c7] (rev 01) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller [8086:24cd] (rev 01) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 81) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge [8086:24cc] (rev 01) 00:1f.1 IDE interface [0101]: Intel Corporation 82801DBM (ICH4-M) IDE Controller [8086:24ca] (rev 01) 00:1f.5 Multimedia audio controller [0401]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller [8086:24c5] (rev 01) 00:1f.6 Modem [0703]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller [8086:24c6] (rev 01) 01:01.0 CardBus bridge [0607]: Texas Instruments PCI4510 PC card Cardbus Controller [104c:ac44] (rev 02) 01:01.1 FireWire (IEEE 1394) [0c00]: Texas Instruments PCI4510 IEEE-1394 Controller [104c:8029] 01:03.0 Network controller [0280]: Intel Corporation PRO/Wireless 2200BG Network Connection [8086:4220] (rev 05) 01:08.0 Ethernet controller [0200]: Intel Corporation 82801DB PRO/100 VE (MOB) Ethernet Controller [8086:103d] (rev 81) Maybe by that date there was nobody avaible for considering this issue so I'm trying again. The lid problem stills exist on a current Xorg version, even with intel video driver git version. I'm not surprised since I suspect heavily on a BIOS problem. I'm coming back with more attached info: A more up to date dmesg output for 2.6.22, the dmidecode output and the dsdt image. All of them are gzip compressed. I hope someone could give me any pointer or tell me whatever info is necessary to debug or solve this. I am available for whatever point you have. Thank you very much and regards, -- Raúl Sánchez Siles -Proud Debian user- Linux registered user #416098 dmi.gz Description: GNU Zip compressed data dmesg.gz Description: GNU Zip compressed data dsdt.gz Description: GNU Zip compressed data signature.asc Description: This is a digitally signed message part.
