Re: [ACPI] Call for help: list of machines with working S3
Pavel Machek wrote: >> this server crashes when switching to the console or shutting >> down (crashing is sometimes, not always), very nice screen which >> slowly turns white > > Hmm, it would be nice to be able to trigger "go white" on purpose -- > it looks like screen is burning and could scare quite a lot of people > :-). BTW: turning white does not necessarily mean "screen is dying" but can also mean "LCD is powered off and slowly turning transparent but the backlight is still on" which brings me back to the original subject: Sharp PC-AR10 (ATI rage mobility P/M AGP 2x), which is sort of the crappiest hardware i have ever seen, has working S3 without any tricks. The backlight is not turned off at S3 but in fact it is explicitly turned on (if i do "xset dpms force off" before suspend, it turns back on after or shortly before entering suspend) and the screen slowly goes white (because TFT power is turned off), but if you enter S3 via lidswitch this does not matter since the lidswitch turns off the backlight :-) -- Stefan Seyfried, QA / R Team Mobile Devices, SUSE LINUX, Nürnberg. "Any ideas, John?" "Well, surrounding them's out." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Hi! > > > - DRI must be disabled I guess?! Even with newer X server (x.org)? > > > > You still didn't state which X server are you using. In short, XFree86 4.4, > > I have stated it several times, but here a sum up: > > - XFree86 4.3 (debian/sid) > no work > - X.Org 6.8.1.99 (debian -dri-trunk stuff plus kernel modules9 > no work > with 2.6.11-rc4 and 2.6.11-rc3-mm2 > this server crashes when switching to the console or shutting > down (crashing is sometimes, not always), very nice screen which > slowly turns white Hmm, it would be nice to be able to trigger "go white" on purpose -- it looks like screen is burning and could scare quite a lot of people :-). Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Hi! - DRI must be disabled I guess?! Even with newer X server (x.org)? You still didn't state which X server are you using. In short, XFree86 4.4, I have stated it several times, but here a sum up: - XFree86 4.3 (debian/sid) no work - X.Org 6.8.1.99 (debian -dri-trunk stuff plus kernel modules9 no work with 2.6.11-rc4 and 2.6.11-rc3-mm2 this server crashes when switching to the console or shutting down (crashing is sometimes, not always), very nice screen which slowly turns white Hmm, it would be nice to be able to trigger go white on purpose -- it looks like screen is burning and could scare quite a lot of people :-). Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Pavel Machek wrote: this server crashes when switching to the console or shutting down (crashing is sometimes, not always), very nice screen which slowly turns white Hmm, it would be nice to be able to trigger go white on purpose -- it looks like screen is burning and could scare quite a lot of people :-). BTW: turning white does not necessarily mean screen is dying but can also mean LCD is powered off and slowly turning transparent but the backlight is still on which brings me back to the original subject: Sharp PC-AR10 (ATI rage mobility P/M AGP 2x), which is sort of the crappiest hardware i have ever seen, has working S3 without any tricks. The backlight is not turned off at S3 but in fact it is explicitly turned on (if i do xset dpms force off before suspend, it turns back on after or shortly before entering suspend) and the screen slowly goes white (because TFT power is turned off), but if you enter S3 via lidswitch this does not matter since the lidswitch turns off the backlight :-) -- Stefan Seyfried, QA / RD Team Mobile Devices, SUSE LINUX, Nürnberg. Any ideas, John? Well, surrounding them's out. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Thu, Feb 24, 2005 at 01:37:16PM +0100, Norbert Preining wrote: > - X.Org 6.8.1.99 (debian -dri-trunk stuff plus kernel modules9 > no work > with 2.6.11-rc4 and 2.6.11-rc3-mm2 > this server crashes when switching to the console or shutting > down (crashing is sometimes, not always), very nice screen which > slowly turns white > I get a very similar experience on a Sony Vaio PCG-FX401 (Duron 800 / Mach64 based RageM1) All suggestions welcome - no DRI or Framebuffers in use - X is Xorg 6.8.2 and the kernel is a 2.6.10mdk from cooker (yeah - I know not vanilla) P - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Thu, Feb 24, 2005 at 01:37:16PM +0100, Norbert Preining wrote: - X.Org 6.8.1.99 (debian -dri-trunk stuff plus kernel modules9 no work with 2.6.11-rc4 and 2.6.11-rc3-mm2 this server crashes when switching to the console or shutting down (crashing is sometimes, not always), very nice screen which slowly turns white I get a very similar experience on a Sony Vaio PCG-FX401 (Duron 800 / Mach64 based RageM1) All suggestions welcome - no DRI or Framebuffers in use - X is Xorg 6.8.2 and the kernel is a 2.6.10mdk from cooker (yeah - I know not vanilla) P - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Thus wrote Norbert Preining: > - X.Org 6.8.1.99 (debian -dri-trunk stuff plus kernel modules9 > no work > with 2.6.11-rc4 and 2.6.11-rc3-mm2 > this server crashes when switching to the console or shutting > down (crashing is sometimes, not always), very nice screen which > slowly turns white This is either distribution or hardware specific. Try with vanilla 6.8.2 and stock DRM modules, perhaps? Best regards, -- Karol 'sziwan' Kozimor [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Die, 22 Feb 2005, Karol Kozimor wrote: > Thus wrote Norbert Preining: > > - DRI must be disabled I guess?! Even with newer X server (x.org)? > > You still didn't state which X server are you using. In short, XFree86 4.4, I have stated it several times, but here a sum up: - XFree86 4.3 (debian/sid) no work - X.Org 6.8.1.99 (debian -dri-trunk stuff plus kernel modules9 no work with 2.6.11-rc4 and 2.6.11-rc3-mm2 this server crashes when switching to the console or shutting down (crashing is sometimes, not always), very nice screen which slowly turns white Best wishes Norbert --- Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- QUEDGELEY (n.) A rabidly left-wing politician who can afford to be that way because he married a millionairess. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Die, 22 Feb 2005, Karol Kozimor wrote: Thus wrote Norbert Preining: - DRI must be disabled I guess?! Even with newer X server (x.org)? You still didn't state which X server are you using. In short, XFree86 4.4, I have stated it several times, but here a sum up: - XFree86 4.3 (debian/sid) no work - X.Org 6.8.1.99 (debian -dri-trunk stuff plus kernel modules9 no work with 2.6.11-rc4 and 2.6.11-rc3-mm2 this server crashes when switching to the console or shutting down (crashing is sometimes, not always), very nice screen which slowly turns white Best wishes Norbert --- Norbert Preining preining AT logic DOT at Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- QUEDGELEY (n.) A rabidly left-wing politician who can afford to be that way because he married a millionairess. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Thus wrote Norbert Preining: - X.Org 6.8.1.99 (debian -dri-trunk stuff plus kernel modules9 no work with 2.6.11-rc4 and 2.6.11-rc3-mm2 this server crashes when switching to the console or shutting down (crashing is sometimes, not always), very nice screen which slowly turns white This is either distribution or hardware specific. Try with vanilla 6.8.2 and stock DRM modules, perhaps? Best regards, -- Karol 'sziwan' Kozimor [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Thus wrote Norbert Preining: > - DRI must be disabled I guess?! Even with newer X server (x.org)? You still didn't state which X server are you using. In short, XFree86 4.4, X.Org 6.7 and 6.8.2 are fine, anything other (including X.Org 6.8.0 and .1) is not. Best regards, -- Karol 'sziwan' Kozimor [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Thus wrote Norbert Preining: - DRI must be disabled I guess?! Even with newer X server (x.org)? You still didn't state which X server are you using. In short, XFree86 4.4, X.Org 6.7 and 6.8.2 are fine, anything other (including X.Org 6.8.0 and .1) is not. Best regards, -- Karol 'sziwan' Kozimor [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Am Freitag, 18. Februar 2005 14:38 schrieb Norbert Preining: > On Fre, 18 Feb 2005, Norbert Preining wrote: > > I tried: > > 2.6.11-rc3-mm2 + Xorg + DRI disabled > > and this works. > > > > I cannot enable dri/drm with the cvs version of the drm modules, because > > the drm modules do not compile for -mm kernels, since there is the patch > > for multiple agp bridges included (that's the reason why I tried -rc4 > > Final observation: After patching in the changes from mm kernels for > multiple agp bridges to the drm-source code (the patch > drm-add-support-for-new-multiple-agp-bridge-agpgart-api.patch from the > broken out archive) I could compile the drm-trunk-src modules. > > So now I am running with 2.6.11-rc3-mm2 + Xorg + DRI enabled (and > working) with the drm modules from drm-trunk-module-src. > > Outcome: freeze when switching to X. As with the other modules (in fact > I think that most of the changes to the drm stuff are included in the mm > kernel, so this should not change anything, as mm pulls from bk-agpgart, > bk-drm-via) a funny screen, and the CapsLock light is blinking. Kernel panik. Can you ssh into your maschine and get a dmesg? I recommend you to write to the dri devs. Stefan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Fre, 18 Feb 2005, Norbert Preining wrote: > I tried: > 2.6.11-rc3-mm2 + Xorg + DRI disabled > and this works. > > I cannot enable dri/drm with the cvs version of the drm modules, because > the drm modules do not compile for -mm kernels, since there is the patch > for multiple agp bridges included (that's the reason why I tried -rc4 Final observation: After patching in the changes from mm kernels for multiple agp bridges to the drm-source code (the patch drm-add-support-for-new-multiple-agp-bridge-agpgart-api.patch from the broken out archive) I could compile the drm-trunk-src modules. So now I am running with 2.6.11-rc3-mm2 + Xorg + DRI enabled (and working) with the drm modules from drm-trunk-module-src. Outcome: freeze when switching to X. As with the other modules (in fact I think that most of the changes to the drm stuff are included in the mm kernel, so this should not change anything, as mm pulls from bk-agpgart, bk-drm-via) a funny screen, and the CapsLock light is blinking. Best wishes Norbert --- Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- `That young girl is one of the least benightedly unintelligent organic life forms it has been my profound lack of pleasure not to be able to avoid meeting.' --- Marvin's first ever compliment about anybody. --- Douglas Adams, The Hitchhikers Guide to the Galaxy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Don, 17 Feb 2005, Stefan Dösinger wrote: > > Ok, I installed xlibmesa-gl1-dri-trunk, xserver-xfree86-dri-trunk and > > compiled linux-2.6.11-rc4 and drm modules from drm-trunk-module-src, all > > from http://www.nixnuts.net/files/ > > > > But I had no success whatsoever. With this (Xorg server, current dri/drm > > stuff, ..) the laptop not even wakes up from sleep! > Sorry, no Idea. What about 2.6.11-rc3-mm2 + Xorg 6.8.1.99? Did you test this > combination? I tried: 2.6.11-rc3-mm2 + Xorg + DRI disabled and this works. I cannot enable dri/drm with the cvs version of the drm modules, because the drm modules do not compile for -mm kernels, since there is the patch for multiple agp bridges included (that's the reason why I tried -rc4 without mm) and the drm modules from drm-trunk-module-src are not prepared to the change of the api. I even tried to incorporate the changes to the api but gave up. I *can* active dri but with the builtin kernel drm modules, which makes the kernel freeze while resuming. > Am I right with assuming that resumeworked after the X upgrade if X wasn't > started before suspend? NO!!! Most interestingly: Doing a suspend from single user mode makes the machine freeze (not even sysrq!) I suspect that it has to do with the restoring of graphics state with vbetool from a data set which was taken *while* running X: My suspend2ram script looks like this (as suggested here): statedir=/root/s3/state /usr/bin/chvt 1 cat /dev/vcsa >$statedir/vcsa sync echo 3 > /proc/acpi/sleep sync vbetool post vbetool vbestate restore <$statedir/vbe cat $statedir/vcsa >/dev/vcsa ... but $statedir/vbe was taken once for XFree86 running. Can this be the reason for the freeze? Best wishes Norbert --- Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- MAVIS ENDERBY (n.) The almost-completely-forgotten girlfriend from your distant past for whom your wife has a completely irrational jealousy and hatred. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Don, 17 Feb 2005, Stefan Dösinger wrote: Ok, I installed xlibmesa-gl1-dri-trunk, xserver-xfree86-dri-trunk and compiled linux-2.6.11-rc4 and drm modules from drm-trunk-module-src, all from http://www.nixnuts.net/files/ But I had no success whatsoever. With this (Xorg server, current dri/drm stuff, ..) the laptop not even wakes up from sleep! Sorry, no Idea. What about 2.6.11-rc3-mm2 + Xorg 6.8.1.99? Did you test this combination? I tried: 2.6.11-rc3-mm2 + Xorg + DRI disabled and this works. I cannot enable dri/drm with the cvs version of the drm modules, because the drm modules do not compile for -mm kernels, since there is the patch for multiple agp bridges included (that's the reason why I tried -rc4 without mm) and the drm modules from drm-trunk-module-src are not prepared to the change of the api. I even tried to incorporate the changes to the api but gave up. I *can* active dri but with the builtin kernel drm modules, which makes the kernel freeze while resuming. Am I right with assuming that resumeworked after the X upgrade if X wasn't started before suspend? NO!!! Most interestingly: Doing a suspend from single user mode makes the machine freeze (not even sysrq!) I suspect that it has to do with the restoring of graphics state with vbetool from a data set which was taken *while* running X: My suspend2ram script looks like this (as suggested here): statedir=/root/s3/state /usr/bin/chvt 1 cat /dev/vcsa $statedir/vcsa sync echo 3 /proc/acpi/sleep sync vbetool post vbetool vbestate restore $statedir/vbe cat $statedir/vcsa /dev/vcsa ... but $statedir/vbe was taken once for XFree86 running. Can this be the reason for the freeze? Best wishes Norbert --- Norbert Preining preining AT logic DOT at Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- MAVIS ENDERBY (n.) The almost-completely-forgotten girlfriend from your distant past for whom your wife has a completely irrational jealousy and hatred. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Fre, 18 Feb 2005, Norbert Preining wrote: I tried: 2.6.11-rc3-mm2 + Xorg + DRI disabled and this works. I cannot enable dri/drm with the cvs version of the drm modules, because the drm modules do not compile for -mm kernels, since there is the patch for multiple agp bridges included (that's the reason why I tried -rc4 Final observation: After patching in the changes from mm kernels for multiple agp bridges to the drm-source code (the patch drm-add-support-for-new-multiple-agp-bridge-agpgart-api.patch from the broken out archive) I could compile the drm-trunk-src modules. So now I am running with 2.6.11-rc3-mm2 + Xorg + DRI enabled (and working) with the drm modules from drm-trunk-module-src. Outcome: freeze when switching to X. As with the other modules (in fact I think that most of the changes to the drm stuff are included in the mm kernel, so this should not change anything, as mm pulls from bk-agpgart, bk-drm-via) a funny screen, and the CapsLock light is blinking. Best wishes Norbert --- Norbert Preining preining AT logic DOT at Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- `That young girl is one of the least benightedly unintelligent organic life forms it has been my profound lack of pleasure not to be able to avoid meeting.' --- Marvin's first ever compliment about anybody. --- Douglas Adams, The Hitchhikers Guide to the Galaxy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Am Freitag, 18. Februar 2005 14:38 schrieb Norbert Preining: On Fre, 18 Feb 2005, Norbert Preining wrote: I tried: 2.6.11-rc3-mm2 + Xorg + DRI disabled and this works. I cannot enable dri/drm with the cvs version of the drm modules, because the drm modules do not compile for -mm kernels, since there is the patch for multiple agp bridges included (that's the reason why I tried -rc4 Final observation: After patching in the changes from mm kernels for multiple agp bridges to the drm-source code (the patch drm-add-support-for-new-multiple-agp-bridge-agpgart-api.patch from the broken out archive) I could compile the drm-trunk-src modules. So now I am running with 2.6.11-rc3-mm2 + Xorg + DRI enabled (and working) with the drm modules from drm-trunk-module-src. Outcome: freeze when switching to X. As with the other modules (in fact I think that most of the changes to the drm stuff are included in the mm kernel, so this should not change anything, as mm pulls from bk-agpgart, bk-drm-via) a funny screen, and the CapsLock light is blinking. Kernel panik. Can you ssh into your maschine and get a dmesg? I recommend you to write to the dri devs. Stefan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3 (fwd)
Pavel Machek schrieb: > >>>I'm not sure if you can push the whole industry at once. >> >>The goal is to know what to tell the system vendors >>interested in supporting Linux what they should do >>with their BIOS on future platforms. >> >>I believe our message should be: >>1. BIOS should save/restore video in S3 > > Actually, that'd expect too much of BIOS writers. I believe right > solution is "POST video as you do during normal boot in S3 resume". Why not leave the choice to the BIOS writers? If some are able to save/restore video state by themselves, we shoudln't stop them. As long as the state after resume accepts setting the mode without lockup, we should be fine. >>2. Use Intel's ACPICA ASL compiler -- if not for production, >>then at least as a static source code checker for validation. > > > 3. Try to boot linux (here's live cd). If it complains about bios bugs > (dmesg | grep ...), try to see if it is not indeed your bug. That could even be automated more. A live cd which boots, performs a few tests, displays the results on screen and offers an option to save these results to usbstick/network/disk/whatever. After saving the boot results, it will perform a S3 suspend and resume and display/save the results of that, too. If Intel have enough money, they could provide the functionality on a hard disk and it would have the benefit that S4 could be tested as well. If the disk has a FAT32 partition, the results can be saved there. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3 (fwd)
Hi! Sorry, I was too fast with my mail client. Please cc: Len in your replies. To: Len Brown <[EMAIL PROTECTED]> Subject: Re: [ACPI] Call for help: list of machines with working S3 X-Warning: Reading this can be dangerous to your mental health. Hi! > > I'm not sure if you can push the whole industry at once. > > The goal is to know what to tell the system vendors > interested in supporting Linux what they should do > with their BIOS on future platforms. > > I believe our message should be: > 1. BIOS should save/restore video in S3 Actually, that'd expect too much of BIOS writers. I believe right solution is "POST video as you do during normal boot in S3 resume". > 2. Use Intel's ACPICA ASL compiler -- if not for production, > then at least as a static source code checker for validation. 3. Try to boot linux (here's live cd). If it complains about bios bugs (dmesg | grep ...), try to see if it is not indeed your bug. -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - End forwarded message - -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Hello Pavel! On Mon 14 Feb 2005 22:11, Pavel Machek wrote: > Stefan provided me initial list of machines where S3 works (including > video). If you have machine that is not on the list, please send me a > diff. If you have eMachines... I'd like you to try playing with Sorry, but a diff of what? Of the list? > Table of known working systems: > > Model hack (or "how to do it") > -- IBM ThinkPad T42p (2373-GTG [1]) acpi_sleep=s3_bios (2) More info available upon request, but in general: - Debian unstable - vanilla kernel 2.6.10 - ACPI patch 20050125 - BlueZ patch -mh4 - IBM trackpoint patch [2] - radeonfb - radeon XFree86 4.3.0.dfsg.1-11 - all modules my laptop support installed (and loaded ;-) ) - I used a script that switch to vc1 and stop mysql (this is a known problem [3] [4]), then "echo -n [mem|disk] > /sys/power/state" I've a working S4 with the same configuration, too. But it seems I still suffer a problem about hwclock I already reported with another laptop [5] [6]. In this case, the command proposed seems not working anymore (I should test more deeply, just a question of time ;-) ). Anyway, this laptop works very well! I've also a docking station [7], I'll test with it ASAP. Thx, bye, Gismo / Luca [1] http://www5.pc.ibm.com/ch/products.nsf/$wwwPartNumLookup/_UC2GTSE?OpenDocument [2] http://people.clarkson.edu/~evanchsa/ [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=259745 [4] http://bugs.mysql.com/bug.php?id=4596 [5] http://sourceforge.net/mailarchive/message.php?msg_id=9844751 [6] http://sourceforge.net/mailarchive/message.php?msg_id=9864402 [7] http://www5.pc.ibm.com/ch/products.nsf/$wwwPartNumLookup/_74P6733?OpenDocument pgpkSj2De7ysa.pgp Description: PGP signature
Re: [ACPI] Call for help: list of machines with working S3
On Thu, 2005-02-17 at 05:15, Vojtech Pavlik wrote: > I'm not sure if you can push the whole industry at once. The goal is to know what to tell the system vendors interested in supporting Linux what they should do with their BIOS on future platforms. I believe our message should be: 1. BIOS should save/restore video in S3 2. Use Intel's ACPICA ASL compiler -- if not for production, then at least as a static source code checker for validation. thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Am Donnerstag, 17. Februar 2005 20:08 schrieb Norbert Preining: > On Die, 15 Feb 2005, Stefan Dösinger wrote: > > > - DRI must be disabled I guess?! Even with newer X server (x.org)? > > > > Do you use the fglrx driver? This doesn't work with any type of suspend > > so far. If you use the radeon driver try a driver update. > > Ok, I installed xlibmesa-gl1-dri-trunk, xserver-xfree86-dri-trunk and > compiled linux-2.6.11-rc4 and drm modules from drm-trunk-module-src, all > from http://www.nixnuts.net/files/ > > But I had no success whatsoever. With this (Xorg server, current dri/drm > stuff, ..) the laptop not even wakes up from sleep! Sorry, no Idea. What about 2.6.11-rc3-mm2 + Xorg 6.8.1.99? Did you test this combination? Am I right with assuming that resumeworked after the X upgrade if X wasn't started before suspend? Stefan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Hi! > >>4. Include a mandantory description of video bringup after resume > > > > That sounds overcomplicated. Simply add this to the specs: > > You have to start to think like a vendor with a long legacy. Then my > spec draft will make more sense. Basically, you can't tell a vendor > that his hardware is broken or he will ignore your efforts from that > point on. "It's a question of honour." If, on the other hand, a > vendor can claim his products are conforming to the spec by issuing > a software update for broken hardware, it is much more likely that > the spec gets accepted. Well, whether you POST video or not is still only software... anyway... Your _WAK idea could work for notebooks (but if you did it in _WAK you'd break windows, so you'd have to call it _VWK (VideoWaK) or something), but for desktop where user can plug in any video card he buys... I do not see how you can get away with something other than normal POST. > > BIOS must do that during normal boot; this should be very little > > additional work. > > Not necessarily. Some BIOSes stay in graphics mode during the whole > bootup (at least it seems so) and would have to include additional > code to enter 80x25 text mode. ??? When grub is launched, you are in 80x25 text mode. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Pavel Machek schrieb: > >>>to reinitialise the graphics hardware, few are going to care about >>>making life easier for Linux. >> > [...] >>3. Get some shiny certification/label going that can be put on >>fully conforming products as a sticker. Something like the old >>"EPA pollution preventer" logo, but with a more appealing design. >>Perhaps a "InstantOn/PowerSave" sticker, you get the idea. > > Like "This machine actually works" sticker? :-) Yes. >>4. Include a mandantory description of video bringup after resume > > That sounds overcomplicated. Simply add this to the specs: You have to start to think like a vendor with a long legacy. Then my spec draft will make more sense. Basically, you can't tell a vendor that his hardware is broken or he will ignore your efforts from that point on. "It's a question of honour." If, on the other hand, a vendor can claim his products are conforming to the spec by issuing a software update for broken hardware, it is much more likely that the spec gets accepted. > "BIOS must POST video during S3 wakeup. Video must be working > and in 80x25 text mode when it jumps to OS. VESA BIOS calls must be > available to the OS." That would make some products non-conformant which are working perfectly today. If the video state is preserved over S3, it doesn't make sense to declare that behaviour non-conformant. > BIOS must do that during normal boot; this should be very little > additional work. Not necessarily. Some BIOSes stay in graphics mode during the whole bootup (at least it seems so) and would have to include additional code to enter 80x25 text mode. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Vernon Mauery schrieb: > Carl-Daniel Hailfinger wrote: > >>1. A first step towards better DSDTs would be to make the ASL compiler >>complain about the same things which are complained about by the >>in-kernel ACPI interpreter. An example would be the following: >> >>acpi_processor-0496 [10] acpi_processor_get_inf: Invalid PBLK length [7] >> >>The ASL compiler will not complain about it, yet the kernel will >>refuse to do any processor throttling with a PBLK length of 7. > > > This is like getting gcc to complain about run-time bugs in a program. Oh, gcc does that to a certain extent. For example, it has warnings like "this comparison is always true" or "value too big for selected type". > The compiler of a language (ASL in this case) compiles the language, > regardless of run-time bugs because it can only detect syntax errors. > And iasl does that pretty well. It is possible to do quite a bit of semantic verification at compile time, but of course there are limits to everything. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Hi! > > to reinitialise the graphics hardware, few are going to care about > > making life easier for Linux. > > 1. A first step towards better DSDTs would be to make the ASL compiler > complain about the same things which are complained about by the > in-kernel ACPI interpreter. An example would be the following: > > acpi_processor-0496 [10] acpi_processor_get_inf: Invalid PBLK length [7] > > The ASL compiler will not complain about it, yet the kernel will > refuse to do any processor throttling with a PBLK length of 7. Not sure if you can check all interesting stuff statically. > 2. Urge/force vendors to use the latest ASL compiler available. Heh, good luck. > 3. Get some shiny certification/label going that can be put on > fully conforming products as a sticker. Something like the old > "EPA pollution preventer" logo, but with a more appealing design. > Perhaps a "InstantOn/PowerSave" sticker, you get the idea. Like "This machine actually works" sticker? :-) > 4. Include a mandantory description of video bringup after resume That sounds overcomplicated. Simply add this to the specs: "BIOS must POST video during S3 wakeup. Video mujst be working and in 80x25 text mode when it jumps to OS. VESA BIOS calls must be available to the OS." BIOS must do that during normal boot; this should be very little additional work. Pavel -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Die, 15 Feb 2005, Pavel Machek wrote: > > - Sometimes I have to make a Sysrq-s (sync) to get some stuff running > > (eg logging in from the console hangs after input of passwd, calling > > sysrq-s makes it continue). I had a similar effect when logging in > > AFTER resuming (for the resume I had only gdm running but wasn't > > logged in) the GNOME starting screen stayed there indefinitely, no > > change. Even after restarting the X server and retrying. > > Logging in with twm session DID work without any problem. > > Do you have any idea what this could be? > > Does it happen with swsusp? Is it in any way reproducible? Maybe > commenting out refrigerator would help Hmm, don't have swsusp in my kernel (2.6.11-rc3-mm2). reproducible: Not deterministically, i.e. it happened again, but then again not always. Sorry. Best wishes Norbert --- Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- PLYMOUTH (vb.) To relate an amusing story to someone without remembering that it was they who told it to you in the first place. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Die, 15 Feb 2005, Stefan Dösinger wrote: > > - DRI must be disabled I guess?! Even with newer X server (x.org)? > Do you use the fglrx driver? This doesn't work with any type of suspend so > far. If you use the radeon driver try a driver update. Ok, I installed xlibmesa-gl1-dri-trunk, xserver-xfree86-dri-trunk and compiled linux-2.6.11-rc4 and drm modules from drm-trunk-module-src, all from http://www.nixnuts.net/files/ But I had no success whatsoever. With this (Xorg server, current dri/drm stuff, ..) the laptop not even wakes up from sleep! Now I am back at debian XFree 4.3.0.1 and DRI disabled and suspend works again. I don't know wether this is a problem with the kernel or the drm, so to sum up: - kernel 2.6.11-rc3-mm2, XFree 4.3.0.1 (debian/sid), no dri works - kernel 2.6.11-rc4, Xorg 6.8.1.99 (debian sid + nixnuts), drm cvs, drm activated no resume (thus also no test for X) Best wishes Norbert --- Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- SWANIBOST (adj.) Complete shagged out after a hard day having income tax explained to you. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Carl-Daniel Hailfinger wrote: > 1. A first step towards better DSDTs would be to make the ASL compiler > complain about the same things which are complained about by the > in-kernel ACPI interpreter. An example would be the following: > > acpi_processor-0496 [10] acpi_processor_get_inf: Invalid PBLK length [7] > > The ASL compiler will not complain about it, yet the kernel will > refuse to do any processor throttling with a PBLK length of 7. This is like getting gcc to complain about run-time bugs in a program. The compiler of a language (ASL in this case) compiles the language, regardless of run-time bugs because it can only detect syntax errors. And iasl does that pretty well. --Vernon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Matthew Garrett schrieb: > On Thu, 2005-02-17 at 01:16 -0500, Len Brown wrote: > >>I think that it is the BIOS' job on S3-suspend >>to save the video mode. On S3-resume the BIOS should >>re-POST and restore the video mode. > > I agree, but in the absence of spec requirement and some form of > certification process, I don't see it happening in the near future. > Given that vendors are still shipping invalid DSDTs, if Windows is able > to reinitialise the graphics hardware, few are going to care about > making life easier for Linux. 1. A first step towards better DSDTs would be to make the ASL compiler complain about the same things which are complained about by the in-kernel ACPI interpreter. An example would be the following: acpi_processor-0496 [10] acpi_processor_get_inf: Invalid PBLK length [7] The ASL compiler will not complain about it, yet the kernel will refuse to do any processor throttling with a PBLK length of 7. 2. Urge/force vendors to use the latest ASL compiler available. In most cases, this will result in a size reduction of the compiled code, which should be in the interest of the vendors. 3. Get some shiny certification/label going that can be put on fully conforming products as a sticker. Something like the old "EPA pollution preventer" logo, but with a more appealing design. Perhaps a "InstantOn/PowerSave" sticker, you get the idea. 4. Include a mandantory description of video bringup after resume into the ACPI spec along the lines of "Conforming products SHOULD make information about handling of the primary video device on resume available to the ACPI interpreter during runtime. If video state will be preserved over a suspend/resume cycle, the _WAK method for said video device MUST be empty. If the video device requires any actions by the operating system after resume to restore the state it had before suspend, the _WAK method for said video device MUST contain ALL the code needed to restore the state before suspend. The _WAK method MAY call OS-supplied ACPI helper functions like ACPI_EXECUTE_CODE_FROM_ROM to keep the _WAK method short. If no _WAK method for a given video device is available, the OS MUST be able to rely on the fact that video state is preserved over suspend/resume. Something like item 4 would be a major step forward and as a bonus, it wouldn't require any hardware changes, only perhaps 3 or 4 additional lines of code in the DSDT. If the _WAK function for my laptop graphics card existed and had the hypothetical commands ACPI_EXECUTE_CODE_FROM_ROM_X86(VGA.ROM) ACPI_RESTORE_VESA_STATE(VGA) we wouldn't have this discussion in the first place. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Die, 15 Feb 2005, Stefan Dösinger wrote: > > After deactivating DRI in the X config file and saving the states with > > your script (thanks) and turning off various stuff I get X running > > again. > > > > Questions: > > - DRI must be disabled I guess?! Even with newer X server (x.org)? > > Do you use the fglrx driver? This doesn't work with any type of suspend so No > far. If you use the radeon driver try a driver update. >From deb http://www.nixnuts.net/files/ ./ ?? Or direct from dri.freedesktop.org, and updating X to X.org on sid? Best wishes Norbert --- Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- SWANIBOST (adj.) Complete shagged out after a hard day having income tax explained to you. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Hi! > I think that it is the BIOS' job on S3-suspend > to save the video mode. On S3-resume the BIOS should > re-POST and restore the video mode. Can you find it written down somewhere? It would be certainly easier for me if every BIOS did re-post, but it is not the case on any new BIOS > To completely solve the Linux S3 video restore issue, > we need to push the platform and BIOS vendors. > > What am I missing? I think we are missing few lines in docs somewhere saying "video must be re-POSTed during S3 wakeup". And then we miss someone going around vendors with baseball bat, telling them to fix their BIOSes. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Thu, 2005-02-17 at 01:16 -0500, Len Brown wrote: > Pavel, > I think that it is the BIOS' job on S3-suspend > to save the video mode. On S3-resume the BIOS should > re-POST and restore the video mode. I agree, but in the absence of spec requirement and some form of certification process, I don't see it happening in the near future. Given that vendors are still shipping invalid DSDTs, if Windows is able to reinitialise the graphics hardware, few are going to care about making life easier for Linux. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Thu, Feb 17, 2005 at 01:16:45AM -0500, Len Brown wrote: > Pavel, > I think that it is the BIOS' job on S3-suspend > to save the video mode. On S3-resume the BIOS should > re-POST and restore the video mode. Should. But this definitely is not the case on about 80+% of notebooks. You can save the video state through VESA VBE, and restore it on resume, but if the BIOS didn't re-POST the video, this will often fail. > While Linux's X drivers may be able to handle the case > where X is running -- that doesn't help us with the > cases where X is not running (a case that Windows > presumably does not have). > > Besides updated X drivers, which may have complicated > restore routines for complicated modes, all the other > techniques for restoring video from Linux are > hit/miss workarounds for broken platforms. > > To completely solve the Linux S3 video restore issue, > we need to push the platform and BIOS vendors. That's correct. > What am I missing? I'm not sure if you can push the whole industry at once. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Thu, Feb 17, 2005 at 01:16:45AM -0500, Len Brown wrote: Pavel, I think that it is the BIOS' job on S3-suspend to save the video mode. On S3-resume the BIOS should re-POST and restore the video mode. Should. But this definitely is not the case on about 80+% of notebooks. You can save the video state through VESA VBE, and restore it on resume, but if the BIOS didn't re-POST the video, this will often fail. While Linux's X drivers may be able to handle the case where X is running -- that doesn't help us with the cases where X is not running (a case that Windows presumably does not have). Besides updated X drivers, which may have complicated restore routines for complicated modes, all the other techniques for restoring video from Linux are hit/miss workarounds for broken platforms. To completely solve the Linux S3 video restore issue, we need to push the platform and BIOS vendors. That's correct. What am I missing? I'm not sure if you can push the whole industry at once. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Thu, 2005-02-17 at 01:16 -0500, Len Brown wrote: Pavel, I think that it is the BIOS' job on S3-suspend to save the video mode. On S3-resume the BIOS should re-POST and restore the video mode. I agree, but in the absence of spec requirement and some form of certification process, I don't see it happening in the near future. Given that vendors are still shipping invalid DSDTs, if Windows is able to reinitialise the graphics hardware, few are going to care about making life easier for Linux. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Hi! I think that it is the BIOS' job on S3-suspend to save the video mode. On S3-resume the BIOS should re-POST and restore the video mode. Can you find it written down somewhere? It would be certainly easier for me if every BIOS did re-post, but it is not the case on any new BIOS To completely solve the Linux S3 video restore issue, we need to push the platform and BIOS vendors. What am I missing? I think we are missing few lines in docs somewhere saying video must be re-POSTed during S3 wakeup. And then we miss someone going around vendors with baseball bat, telling them to fix their BIOSes. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Die, 15 Feb 2005, Stefan Dösinger wrote: After deactivating DRI in the X config file and saving the states with your script (thanks) and turning off various stuff I get X running again. Questions: - DRI must be disabled I guess?! Even with newer X server (x.org)? Do you use the fglrx driver? This doesn't work with any type of suspend so No far. If you use the radeon driver try a driver update. From deb http://www.nixnuts.net/files/ ./ ?? Or direct from dri.freedesktop.org, and updating X to X.org on sid? Best wishes Norbert --- Norbert Preining preining AT logic DOT at Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- SWANIBOST (adj.) Complete shagged out after a hard day having income tax explained to you. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Matthew Garrett schrieb: On Thu, 2005-02-17 at 01:16 -0500, Len Brown wrote: I think that it is the BIOS' job on S3-suspend to save the video mode. On S3-resume the BIOS should re-POST and restore the video mode. I agree, but in the absence of spec requirement and some form of certification process, I don't see it happening in the near future. Given that vendors are still shipping invalid DSDTs, if Windows is able to reinitialise the graphics hardware, few are going to care about making life easier for Linux. 1. A first step towards better DSDTs would be to make the ASL compiler complain about the same things which are complained about by the in-kernel ACPI interpreter. An example would be the following: acpi_processor-0496 [10] acpi_processor_get_inf: Invalid PBLK length [7] The ASL compiler will not complain about it, yet the kernel will refuse to do any processor throttling with a PBLK length of 7. 2. Urge/force vendors to use the latest ASL compiler available. In most cases, this will result in a size reduction of the compiled code, which should be in the interest of the vendors. 3. Get some shiny certification/label going that can be put on fully conforming products as a sticker. Something like the old EPA pollution preventer logo, but with a more appealing design. Perhaps a InstantOn/PowerSave sticker, you get the idea. 4. Include a mandantory description of video bringup after resume into the ACPI spec along the lines of Conforming products SHOULD make information about handling of the primary video device on resume available to the ACPI interpreter during runtime. If video state will be preserved over a suspend/resume cycle, the _WAK method for said video device MUST be empty. If the video device requires any actions by the operating system after resume to restore the state it had before suspend, the _WAK method for said video device MUST contain ALL the code needed to restore the state before suspend. The _WAK method MAY call OS-supplied ACPI helper functions like ACPI_EXECUTE_CODE_FROM_ROM to keep the _WAK method short. If no _WAK method for a given video device is available, the OS MUST be able to rely on the fact that video state is preserved over suspend/resume. Something like item 4 would be a major step forward and as a bonus, it wouldn't require any hardware changes, only perhaps 3 or 4 additional lines of code in the DSDT. If the _WAK function for my laptop graphics card existed and had the hypothetical commands ACPI_EXECUTE_CODE_FROM_ROM_X86(VGA.ROM) ACPI_RESTORE_VESA_STATE(VGA) we wouldn't have this discussion in the first place. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Carl-Daniel Hailfinger wrote: 1. A first step towards better DSDTs would be to make the ASL compiler complain about the same things which are complained about by the in-kernel ACPI interpreter. An example would be the following: acpi_processor-0496 [10] acpi_processor_get_inf: Invalid PBLK length [7] The ASL compiler will not complain about it, yet the kernel will refuse to do any processor throttling with a PBLK length of 7. This is like getting gcc to complain about run-time bugs in a program. The compiler of a language (ASL in this case) compiles the language, regardless of run-time bugs because it can only detect syntax errors. And iasl does that pretty well. --Vernon - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Die, 15 Feb 2005, Stefan Dösinger wrote: - DRI must be disabled I guess?! Even with newer X server (x.org)? Do you use the fglrx driver? This doesn't work with any type of suspend so far. If you use the radeon driver try a driver update. Ok, I installed xlibmesa-gl1-dri-trunk, xserver-xfree86-dri-trunk and compiled linux-2.6.11-rc4 and drm modules from drm-trunk-module-src, all from http://www.nixnuts.net/files/ But I had no success whatsoever. With this (Xorg server, current dri/drm stuff, ..) the laptop not even wakes up from sleep! Now I am back at debian XFree 4.3.0.1 and DRI disabled and suspend works again. I don't know wether this is a problem with the kernel or the drm, so to sum up: - kernel 2.6.11-rc3-mm2, XFree 4.3.0.1 (debian/sid), no dri works - kernel 2.6.11-rc4, Xorg 6.8.1.99 (debian sid + nixnuts), drm cvs, drm activated no resume (thus also no test for X) Best wishes Norbert --- Norbert Preining preining AT logic DOT at Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- SWANIBOST (adj.) Complete shagged out after a hard day having income tax explained to you. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Die, 15 Feb 2005, Pavel Machek wrote: - Sometimes I have to make a Sysrq-s (sync) to get some stuff running (eg logging in from the console hangs after input of passwd, calling sysrq-s makes it continue). I had a similar effect when logging in AFTER resuming (for the resume I had only gdm running but wasn't logged in) the GNOME starting screen stayed there indefinitely, no change. Even after restarting the X server and retrying. Logging in with twm session DID work without any problem. Do you have any idea what this could be? Does it happen with swsusp? Is it in any way reproducible? Maybe commenting out refrigerator would help Hmm, don't have swsusp in my kernel (2.6.11-rc3-mm2). reproducible: Not deterministically, i.e. it happened again, but then again not always. Sorry. Best wishes Norbert --- Norbert Preining preining AT logic DOT at Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- PLYMOUTH (vb.) To relate an amusing story to someone without remembering that it was they who told it to you in the first place. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Hi! to reinitialise the graphics hardware, few are going to care about making life easier for Linux. 1. A first step towards better DSDTs would be to make the ASL compiler complain about the same things which are complained about by the in-kernel ACPI interpreter. An example would be the following: acpi_processor-0496 [10] acpi_processor_get_inf: Invalid PBLK length [7] The ASL compiler will not complain about it, yet the kernel will refuse to do any processor throttling with a PBLK length of 7. Not sure if you can check all interesting stuff statically. 2. Urge/force vendors to use the latest ASL compiler available. Heh, good luck. 3. Get some shiny certification/label going that can be put on fully conforming products as a sticker. Something like the old EPA pollution preventer logo, but with a more appealing design. Perhaps a InstantOn/PowerSave sticker, you get the idea. Like This machine actually works sticker? :-) 4. Include a mandantory description of video bringup after resume That sounds overcomplicated. Simply add this to the specs: BIOS must POST video during S3 wakeup. Video mujst be working and in 80x25 text mode when it jumps to OS. VESA BIOS calls must be available to the OS. BIOS must do that during normal boot; this should be very little additional work. Pavel -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Vernon Mauery schrieb: Carl-Daniel Hailfinger wrote: 1. A first step towards better DSDTs would be to make the ASL compiler complain about the same things which are complained about by the in-kernel ACPI interpreter. An example would be the following: acpi_processor-0496 [10] acpi_processor_get_inf: Invalid PBLK length [7] The ASL compiler will not complain about it, yet the kernel will refuse to do any processor throttling with a PBLK length of 7. This is like getting gcc to complain about run-time bugs in a program. Oh, gcc does that to a certain extent. For example, it has warnings like this comparison is always true or value too big for selected type. The compiler of a language (ASL in this case) compiles the language, regardless of run-time bugs because it can only detect syntax errors. And iasl does that pretty well. It is possible to do quite a bit of semantic verification at compile time, but of course there are limits to everything. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Pavel Machek schrieb: to reinitialise the graphics hardware, few are going to care about making life easier for Linux. [...] 3. Get some shiny certification/label going that can be put on fully conforming products as a sticker. Something like the old EPA pollution preventer logo, but with a more appealing design. Perhaps a InstantOn/PowerSave sticker, you get the idea. Like This machine actually works sticker? :-) Yes. 4. Include a mandantory description of video bringup after resume That sounds overcomplicated. Simply add this to the specs: You have to start to think like a vendor with a long legacy. Then my spec draft will make more sense. Basically, you can't tell a vendor that his hardware is broken or he will ignore your efforts from that point on. It's a question of honour. If, on the other hand, a vendor can claim his products are conforming to the spec by issuing a software update for broken hardware, it is much more likely that the spec gets accepted. BIOS must POST video during S3 wakeup. Video must be working and in 80x25 text mode when it jumps to OS. VESA BIOS calls must be available to the OS. That would make some products non-conformant which are working perfectly today. If the video state is preserved over S3, it doesn't make sense to declare that behaviour non-conformant. BIOS must do that during normal boot; this should be very little additional work. Not necessarily. Some BIOSes stay in graphics mode during the whole bootup (at least it seems so) and would have to include additional code to enter 80x25 text mode. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Hi! 4. Include a mandantory description of video bringup after resume That sounds overcomplicated. Simply add this to the specs: You have to start to think like a vendor with a long legacy. Then my spec draft will make more sense. Basically, you can't tell a vendor that his hardware is broken or he will ignore your efforts from that point on. It's a question of honour. If, on the other hand, a vendor can claim his products are conforming to the spec by issuing a software update for broken hardware, it is much more likely that the spec gets accepted. Well, whether you POST video or not is still only software... anyway... Your _WAK idea could work for notebooks (but if you did it in _WAK you'd break windows, so you'd have to call it _VWK (VideoWaK) or something), but for desktop where user can plug in any video card he buys... I do not see how you can get away with something other than normal POST. BIOS must do that during normal boot; this should be very little additional work. Not necessarily. Some BIOSes stay in graphics mode during the whole bootup (at least it seems so) and would have to include additional code to enter 80x25 text mode. ??? When grub is launched, you are in 80x25 text mode. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Am Donnerstag, 17. Februar 2005 20:08 schrieb Norbert Preining: On Die, 15 Feb 2005, Stefan Dösinger wrote: - DRI must be disabled I guess?! Even with newer X server (x.org)? Do you use the fglrx driver? This doesn't work with any type of suspend so far. If you use the radeon driver try a driver update. Ok, I installed xlibmesa-gl1-dri-trunk, xserver-xfree86-dri-trunk and compiled linux-2.6.11-rc4 and drm modules from drm-trunk-module-src, all from http://www.nixnuts.net/files/ But I had no success whatsoever. With this (Xorg server, current dri/drm stuff, ..) the laptop not even wakes up from sleep! Sorry, no Idea. What about 2.6.11-rc3-mm2 + Xorg 6.8.1.99? Did you test this combination? Am I right with assuming that resumeworked after the X upgrade if X wasn't started before suspend? Stefan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Thu, 2005-02-17 at 05:15, Vojtech Pavlik wrote: I'm not sure if you can push the whole industry at once. The goal is to know what to tell the system vendors interested in supporting Linux what they should do with their BIOS on future platforms. I believe our message should be: 1. BIOS should save/restore video in S3 2. Use Intel's ACPICA ASL compiler -- if not for production, then at least as a static source code checker for validation. thanks, -Len - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Hello Pavel! On Mon 14 Feb 2005 22:11, Pavel Machek wrote: Stefan provided me initial list of machines where S3 works (including video). If you have machine that is not on the list, please send me a diff. If you have eMachines... I'd like you to try playing with Sorry, but a diff of what? Of the list? Table of known working systems: Model hack (or how to do it) -- IBM ThinkPad T42p (2373-GTG [1]) acpi_sleep=s3_bios (2) More info available upon request, but in general: - Debian unstable - vanilla kernel 2.6.10 - ACPI patch 20050125 - BlueZ patch -mh4 - IBM trackpoint patch [2] - radeonfb - radeon XFree86 4.3.0.dfsg.1-11 - all modules my laptop support installed (and loaded ;-) ) - I used a script that switch to vc1 and stop mysql (this is a known problem [3] [4]), then echo -n [mem|disk] /sys/power/state I've a working S4 with the same configuration, too. But it seems I still suffer a problem about hwclock I already reported with another laptop [5] [6]. In this case, the command proposed seems not working anymore (I should test more deeply, just a question of time ;-) ). Anyway, this laptop works very well! I've also a docking station [7], I'll test with it ASAP. Thx, bye, Gismo / Luca [1] http://www5.pc.ibm.com/ch/products.nsf/$wwwPartNumLookup/_UC2GTSE?OpenDocument [2] http://people.clarkson.edu/~evanchsa/ [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=259745 [4] http://bugs.mysql.com/bug.php?id=4596 [5] http://sourceforge.net/mailarchive/message.php?msg_id=9844751 [6] http://sourceforge.net/mailarchive/message.php?msg_id=9864402 [7] http://www5.pc.ibm.com/ch/products.nsf/$wwwPartNumLookup/_74P6733?OpenDocument pgpkSj2De7ysa.pgp Description: PGP signature
Re: [ACPI] Call for help: list of machines with working S3 (fwd)
Hi! Sorry, I was too fast with my mail client. Please cc: Len in your replies. To: Len Brown [EMAIL PROTECTED] Subject: Re: [ACPI] Call for help: list of machines with working S3 X-Warning: Reading this can be dangerous to your mental health. Hi! I'm not sure if you can push the whole industry at once. The goal is to know what to tell the system vendors interested in supporting Linux what they should do with their BIOS on future platforms. I believe our message should be: 1. BIOS should save/restore video in S3 Actually, that'd expect too much of BIOS writers. I believe right solution is POST video as you do during normal boot in S3 resume. 2. Use Intel's ACPICA ASL compiler -- if not for production, then at least as a static source code checker for validation. 3. Try to boot linux (here's live cd). If it complains about bios bugs (dmesg | grep ...), try to see if it is not indeed your bug. -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - End forwarded message - -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3 (fwd)
Pavel Machek schrieb: I'm not sure if you can push the whole industry at once. The goal is to know what to tell the system vendors interested in supporting Linux what they should do with their BIOS on future platforms. I believe our message should be: 1. BIOS should save/restore video in S3 Actually, that'd expect too much of BIOS writers. I believe right solution is POST video as you do during normal boot in S3 resume. Why not leave the choice to the BIOS writers? If some are able to save/restore video state by themselves, we shoudln't stop them. As long as the state after resume accepts setting the mode without lockup, we should be fine. 2. Use Intel's ACPICA ASL compiler -- if not for production, then at least as a static source code checker for validation. 3. Try to boot linux (here's live cd). If it complains about bios bugs (dmesg | grep ...), try to see if it is not indeed your bug. That could even be automated more. A live cd which boots, performs a few tests, displays the results on screen and offers an option to save these results to usbstick/network/disk/whatever. After saving the boot results, it will perform a S3 suspend and resume and display/save the results of that, too. If Intel have enough money, they could provide the functionality on a hard disk and it would have the benefit that S4 could be tested as well. If the disk has a FAT32 partition, the results can be saved there. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Pavel, I think that it is the BIOS' job on S3-suspend to save the video mode. On S3-resume the BIOS should re-POST and restore the video mode. While Linux's X drivers may be able to handle the case where X is running -- that doesn't help us with the cases where X is not running (a case that Windows presumably does not have). Besides updated X drivers, which may have complicated restore routines for complicated modes, all the other techniques for restoring video from Linux are hit/miss workarounds for broken platforms. To completely solve the Linux S3 video restore issue, we need to push the platform and BIOS vendors. What am I missing? thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Am Mittwoch, 16. Februar 2005 16:06 schrieb Carl-Daniel Hailfinger: > Stefan Dösinger schrieb: > >>The problems with this patch are: > >>- you need to press a key to come back from the "resume-console" after > >>resume. - DRI in X does not work (at least for me with intel-agp, others > >>reportet it works) > >>I just disabloed it by not loading intel-agp (hotplug-blacklist) > > > > You can force the radeon X driver to use pci mode by setting Option > > "ForcePciMode" to "true" or something simmilar in you X config file. This > > way you can get dri without intel-agp. This is much slower, but enought > > to play tuxracer ;-) > > How do I enable DRI with my card to test that crash? I have the > following in my XF86Config: > > Section "DRI" > Group "video" > Mode 0660 > EndSection > > but nothing else about DRI. So do I have to change something in > my configuration? > > Oh, and could you please include run "lspci -vv" and include the > part about VGA compatible controller in your mail? I have some > hypothesis about the settings there having to do with resume. You can set Option "BusType" "PCI" in your cards driver section in xorg.conf / XF86Config. With this setting you should get DRI without having intel-agp loaded(if the rest is set up correctly) My lspci output is: :00:00.0 Host bridge: Intel Corp. 82855PM Processor to I/O Controller (rev 03) Subsystem: Acer Incorporated [ALI]: Unknown device 001f Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- Reset- FastB2B- :00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03) (prog-if 00 [UHCI]) Subsystem: Acer Incorporated [ALI]: Unknown device 001f Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- FastB2B- :00:1f.0 ISA bridge: Intel Corp. 82801DBM (ICH4-M) LPC Interface Bridge (rev 03) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Region 1: I/O ports at Region 2: I/O ports at Region 3: I/O ports at Region 4: I/O ports at 1860 [size=16] Region 5: Memory at 2000 (32-bit, non-prefetchable) [size=1K] :00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 03) Subsystem: Acer Incorporated [ALI]: Unknown device 001f Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset+ 16bInt+ PostWrite- 16-bit legacy interface ports at 0001 :02:06.1 CardBus bridge: O2 Micro, Inc. OZ711M1 SmartCardBus MultiMediaBay Controller (rev 20) Subsystem: Acer Incorporated [ALI]: Unknown device 001f Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- Reset- 16bInt- PostWrite- 16-bit legacy interface ports at 0001 :02:06.2 System peripheral: O2 Micro, Inc. OZ711Mx MultiMediaBay Accelerator Subsystem: Acer Incorporated [ALI]: Unknown device 001f Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Wed, 16 Feb 2005 16:06:00 +0100, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote: > Stefan Dösinger schrieb: > >>The problems with this patch are: > >>- you need to press a key to come back from the "resume-console" after > >>resume. - DRI in X does not work (at least for me with intel-agp, others > >>reportet it works) > >>I just disabloed it by not loading intel-agp (hotplug-blacklist) > > > > You can force the radeon X driver to use pci mode by setting Option > > "ForcePciMode" to "true" or something simmilar in you X config file. This > > way > > you can get dri without intel-agp. This is much slower, but enought to play > > tuxracer ;-) > > How do I enable DRI with my card to test that crash? I have the > following in my XF86Config: > > Section "DRI" > Group "video" > Mode 0660 > EndSection > > but nothing else about DRI. So do I have to change something in > my configuration? > you need to compile the right modules and load the agp-bridge's and your gfx module. > Oh, and could you please include run "lspci -vv" and include the > part about VGA compatible controller in your mail? I have some > hypothesis about the settings there having to do with resume. > I attached the full output because there are some more "AGP" there. I just tried it again and it only crashed my X after resume with intel-agp .. I was able to type still and start a new X but when I tried to run a 3d-app it hard crashed and I had to reboot :( I hope you have an idea. Regards, Stefan lspcivv Description: Binary data
Re: [ACPI] Call for help: list of machines with working S3
On Wed, Feb 16, 2005 at 03:54:38PM +0100, Carl-Daniel Hailfinger wrote: > Romano Giannetti schrieb: > > > > I tried with my Sony Vaio FX701. No luck. It goes S3 ok, but it will never > > come back (blank screen, HDD led fixed on). > > > > I am wishing to help, imply tell me what I have to do. > > Please tell us about your graphics chipset, your .config, your > dmesg and the modules loaded. Then we my be able to help. Oops, sorry, I should have added the info before. My apologies. Here will find all the info (if you need more, tell me). Note that I tried with and without ndiswrapper driver loaded, and I have the same hang on resume (blank screen, HDD light fixed on, and no answer to wireless pings). One more note: the ndiswrapper *did* survive OK to a disk suspend cycle. I am running an up-to-date Mandrake 10.0 distribution, with a kernel 2.6.11-rc1 (Linus tree), on a Sony Vaio PGC-FX701 which is almost working perfectly. * Patch applied: - a little patch for ALPS pad detection. http://www.dea.icai.upco.es/romano/linux/alps-detection-2611rc1.txt * .config: http://www.dea.icai.upco.es/romano/linux/config-2.6.11rc1.txt * lsmod after boot: http://www.dea.icai.upco.es/romano/linux/lsmod.txt * lspci -vv http://www.dea.icai.upco.es/romano/linux/lspci.txt * dmesg http://www.dea.icai.upco.es/romano/linux/dmesg.txt * /proc/acpi/dsdt http://www.dea.icai.upco.es/romano/linux/mydsdt.bin More data on http://perso.wanadoo.es/r_mano/vaio/vaio.html Thanks again, Romano -- Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain) Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 596 569 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Stefan Dösinger schrieb: >>The problems with this patch are: >>- you need to press a key to come back from the "resume-console" after >>resume. - DRI in X does not work (at least for me with intel-agp, others >>reportet it works) >>I just disabloed it by not loading intel-agp (hotplug-blacklist) > > You can force the radeon X driver to use pci mode by setting Option > "ForcePciMode" to "true" or something simmilar in you X config file. This way > you can get dri without intel-agp. This is much slower, but enought to play > tuxracer ;-) How do I enable DRI with my card to test that crash? I have the following in my XF86Config: Section "DRI" Group "video" Mode 0660 EndSection but nothing else about DRI. So do I have to change something in my configuration? Oh, and could you please include run "lspci -vv" and include the part about VGA compatible controller in your mail? I have some hypothesis about the settings there having to do with resume. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Romano Giannetti schrieb: > On Tue, Feb 15, 2005 at 06:08:37PM +0100, Norbert Preining wrote: > >>On Die, 15 Feb 2005, Carl-Daniel Hailfinger wrote: >> >>>To suspend and resume properly, call the following script as root: >> >>Success. > > I tried with my Sony Vaio FX701. No luck. It goes S3 ok, but it will never > come back (blank screen, HDD led fixed on). > > I am wishing to help, imply tell me what I have to do. Please tell us about your graphics chipset, your .config, your dmesg and the modules loaded. Then we my be able to help. Regards, Carl-Daniel P.S. If anyone of you is running SUSE 9.2, try their latest kernels from ftp.suse.com/pub/projects/kernel/kotd/i386/HEAD/ Additionally, you may have to upgrade mkinitrd and udev with packages from ftp.suse.com/pub/projects and ftp.suse.com/pub/people (try searching around a bit and you'll surely find them). I'm running a kernel from there right now and can still use S3 without problems on my Samsung P35. -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Hi Carl-Daniel, hi all, On Die, 15 Feb 2005, Carl-Daniel Hailfinger wrote: > > - DRI must be disabled I guess?! Even with newer X server (x.org)? > > I never disabled it. Here X freezes (Sysrq-b works) with DRI enabled (debian sid, x4.3.0.1, kernel 2.6.11-rc3-mm2, radeon, drm as modules) > I used to unload modules, shutdown network interfaces etc. until I > tried without all that stuff and it still worked. So I concluded YOu are right. I only have to stop the mysql server and everything is working. Thanks. Only one thing (maybe covered somewhere else): After resuming (without having stopped the usb system) my external mouse (USB) stopped working. Is there a way to reactive the external mouse? > I'll prepare a web page with detailed S3/S4 suspend/resume > information for ATI graphics card owners including step-by-step > howtos for smooth suspend/resume cycles. Great idea! I was really searching for something like this. I will check as soon as you have something online wether I have to add something! Best wishes Norbert --- Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- CORRIEVORRIE (n.) Corridor etiquette demands that one a corriedoo (q.v.) has been declared, corrievorrie must be employed. Both protagonists must now embellish their approach with an embarrassing combination of waving, grinning, making idiot faces, doing pirate impressions, and waggling the head from side to side while holding the other person's eyes as the smile drips off their face, until with great relief, they pass each other. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Tue, Feb 15, 2005 at 06:08:37PM +0100, Norbert Preining wrote: > On Die, 15 Feb 2005, Carl-Daniel Hailfinger wrote: > > To suspend and resume properly, call the following script as root: > > Success. > I tried with my Sony Vaio FX701. No luck. It goes S3 ok, but it will never come back (blank screen, HDD led fixed on). I am wishing to help, imply tell me what I have to do. Romano -- Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain) Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 596 569 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
> The problems with this patch are: > - you need to press a key to come back from the "resume-console" after > resume. - DRI in X does not work (at least for me with intel-agp, others > reportet it works) > I just disabloed it by not loading intel-agp (hotplug-blacklist) You can force the radeon X driver to use pci mode by setting Option "ForcePciMode" to "true" or something simmilar in you X config file. This way you can get dri without intel-agp. This is much slower, but enought to play tuxracer ;-) Stefan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
The problems with this patch are: - you need to press a key to come back from the resume-console after resume. - DRI in X does not work (at least for me with intel-agp, others reportet it works) I just disabloed it by not loading intel-agp (hotplug-blacklist) You can force the radeon X driver to use pci mode by setting Option ForcePciMode to true or something simmilar in you X config file. This way you can get dri without intel-agp. This is much slower, but enought to play tuxracer ;-) Stefan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Tue, Feb 15, 2005 at 06:08:37PM +0100, Norbert Preining wrote: On Die, 15 Feb 2005, Carl-Daniel Hailfinger wrote: To suspend and resume properly, call the following script as root: Success. I tried with my Sony Vaio FX701. No luck. It goes S3 ok, but it will never come back (blank screen, HDD led fixed on). I am wishing to help, imply tell me what I have to do. Romano -- Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain) Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 596 569 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Hi Carl-Daniel, hi all, On Die, 15 Feb 2005, Carl-Daniel Hailfinger wrote: - DRI must be disabled I guess?! Even with newer X server (x.org)? I never disabled it. Here X freezes (Sysrq-b works) with DRI enabled (debian sid, x4.3.0.1, kernel 2.6.11-rc3-mm2, radeon, drm as modules) I used to unload modules, shutdown network interfaces etc. until I tried without all that stuff and it still worked. So I concluded YOu are right. I only have to stop the mysql server and everything is working. Thanks. Only one thing (maybe covered somewhere else): After resuming (without having stopped the usb system) my external mouse (USB) stopped working. Is there a way to reactive the external mouse? I'll prepare a web page with detailed S3/S4 suspend/resume information for ATI graphics card owners including step-by-step howtos for smooth suspend/resume cycles. Great idea! I was really searching for something like this. I will check as soon as you have something online wether I have to add something! Best wishes Norbert --- Norbert Preining preining AT logic DOT at Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- CORRIEVORRIE (n.) Corridor etiquette demands that one a corriedoo (q.v.) has been declared, corrievorrie must be employed. Both protagonists must now embellish their approach with an embarrassing combination of waving, grinning, making idiot faces, doing pirate impressions, and waggling the head from side to side while holding the other person's eyes as the smile drips off their face, until with great relief, they pass each other. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Romano Giannetti schrieb: On Tue, Feb 15, 2005 at 06:08:37PM +0100, Norbert Preining wrote: On Die, 15 Feb 2005, Carl-Daniel Hailfinger wrote: To suspend and resume properly, call the following script as root: Success. I tried with my Sony Vaio FX701. No luck. It goes S3 ok, but it will never come back (blank screen, HDD led fixed on). I am wishing to help, imply tell me what I have to do. Please tell us about your graphics chipset, your .config, your dmesg and the modules loaded. Then we my be able to help. Regards, Carl-Daniel P.S. If anyone of you is running SUSE 9.2, try their latest kernels from ftp.suse.com/pub/projects/kernel/kotd/i386/HEAD/ Additionally, you may have to upgrade mkinitrd and udev with packages from ftp.suse.com/pub/projects and ftp.suse.com/pub/people (try searching around a bit and you'll surely find them). I'm running a kernel from there right now and can still use S3 without problems on my Samsung P35. -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Stefan Dösinger schrieb: The problems with this patch are: - you need to press a key to come back from the resume-console after resume. - DRI in X does not work (at least for me with intel-agp, others reportet it works) I just disabloed it by not loading intel-agp (hotplug-blacklist) You can force the radeon X driver to use pci mode by setting Option ForcePciMode to true or something simmilar in you X config file. This way you can get dri without intel-agp. This is much slower, but enought to play tuxracer ;-) How do I enable DRI with my card to test that crash? I have the following in my XF86Config: Section DRI Group video Mode 0660 EndSection but nothing else about DRI. So do I have to change something in my configuration? Oh, and could you please include run lspci -vv and include the part about VGA compatible controller in your mail? I have some hypothesis about the settings there having to do with resume. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Wed, Feb 16, 2005 at 03:54:38PM +0100, Carl-Daniel Hailfinger wrote: Romano Giannetti schrieb: I tried with my Sony Vaio FX701. No luck. It goes S3 ok, but it will never come back (blank screen, HDD led fixed on). I am wishing to help, imply tell me what I have to do. Please tell us about your graphics chipset, your .config, your dmesg and the modules loaded. Then we my be able to help. Oops, sorry, I should have added the info before. My apologies. Here will find all the info (if you need more, tell me). Note that I tried with and without ndiswrapper driver loaded, and I have the same hang on resume (blank screen, HDD light fixed on, and no answer to wireless pings). One more note: the ndiswrapper *did* survive OK to a disk suspend cycle. I am running an up-to-date Mandrake 10.0 distribution, with a kernel 2.6.11-rc1 (Linus tree), on a Sony Vaio PGC-FX701 which is almost working perfectly. * Patch applied: - a little patch for ALPS pad detection. http://www.dea.icai.upco.es/romano/linux/alps-detection-2611rc1.txt * .config: http://www.dea.icai.upco.es/romano/linux/config-2.6.11rc1.txt * lsmod after boot: http://www.dea.icai.upco.es/romano/linux/lsmod.txt * lspci -vv http://www.dea.icai.upco.es/romano/linux/lspci.txt * dmesg http://www.dea.icai.upco.es/romano/linux/dmesg.txt * /proc/acpi/dsdt http://www.dea.icai.upco.es/romano/linux/mydsdt.bin More data on http://perso.wanadoo.es/r_mano/vaio/vaio.html Thanks again, Romano -- Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain) Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 596 569 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Wed, 16 Feb 2005 16:06:00 +0100, Carl-Daniel Hailfinger [EMAIL PROTECTED] wrote: Stefan Dösinger schrieb: The problems with this patch are: - you need to press a key to come back from the resume-console after resume. - DRI in X does not work (at least for me with intel-agp, others reportet it works) I just disabloed it by not loading intel-agp (hotplug-blacklist) You can force the radeon X driver to use pci mode by setting Option ForcePciMode to true or something simmilar in you X config file. This way you can get dri without intel-agp. This is much slower, but enought to play tuxracer ;-) How do I enable DRI with my card to test that crash? I have the following in my XF86Config: Section DRI Group video Mode 0660 EndSection but nothing else about DRI. So do I have to change something in my configuration? you need to compile the right modules and load the agp-bridge's and your gfx module. Oh, and could you please include run lspci -vv and include the part about VGA compatible controller in your mail? I have some hypothesis about the settings there having to do with resume. I attached the full output because there are some more AGP there. I just tried it again and it only crashed my X after resume with intel-agp .. I was able to type still and start a new X but when I tried to run a 3d-app it hard crashed and I had to reboot :( I hope you have an idea. Regards, Stefan lspcivv Description: Binary data
Re: [ACPI] Call for help: list of machines with working S3
Am Mittwoch, 16. Februar 2005 16:06 schrieb Carl-Daniel Hailfinger: Stefan Dösinger schrieb: The problems with this patch are: - you need to press a key to come back from the resume-console after resume. - DRI in X does not work (at least for me with intel-agp, others reportet it works) I just disabloed it by not loading intel-agp (hotplug-blacklist) You can force the radeon X driver to use pci mode by setting Option ForcePciMode to true or something simmilar in you X config file. This way you can get dri without intel-agp. This is much slower, but enought to play tuxracer ;-) How do I enable DRI with my card to test that crash? I have the following in my XF86Config: Section DRI Group video Mode 0660 EndSection but nothing else about DRI. So do I have to change something in my configuration? Oh, and could you please include run lspci -vv and include the part about VGA compatible controller in your mail? I have some hypothesis about the settings there having to do with resume. You can set Option BusType PCI in your cards driver section in xorg.conf / XF86Config. With this setting you should get DRI without having intel-agp loaded(if the rest is set up correctly) My lspci output is: :00:00.0 Host bridge: Intel Corp. 82855PM Processor to I/O Controller (rev 03) Subsystem: Acer Incorporated [ALI]: Unknown device 001f Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- Latency: 0 Region 0: Memory at e000 (32-bit, prefetchable) Capabilities: [e4] #09 [f104] Capabilities: [a0] AGP version 2.0 Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW+ Rate=x4 :00:01.0 PCI bridge: Intel Corp. 82855PM Processor to AGP Controller (rev 03) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 96 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 3000-3fff Memory behind bridge: d010-d01f Prefetchable memory behind bridge: d800-dfff Expansion ROM at 3000 [disabled] [size=4K] BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- Reset- FastB2B- :00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03) (prog-if 00 [UHCI]) Subsystem: Acer Incorporated [ALI]: Unknown device 001f Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin A routed to IRQ 10 Region 4: I/O ports at 1800 [size=32] :00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 03) (prog-if 00 [UHCI]) Subsystem: Acer Incorporated [ALI]: Unknown device 001f Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin B routed to IRQ 10 Region 4: I/O ports at 1820 [size=32] :00:1d.2 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 03) (prog-if 00 [UHCI]) Subsystem: Acer Incorporated [ALI]: Unknown device 001f Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin C routed to IRQ 10 Region 4: I/O ports at 1840 [size=32] :00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 03) (prog-if 20 [EHCI]) Subsystem: Acer Incorporated [ALI]: Unknown device 001f Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin D routed to IRQ 10 Region 0: Memory at d000 (32-bit, non-prefetchable) Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] #0a [2080] :00:1e.0 PCI bridge: Intel Corp. 82801 Mobile PCI Bridge (rev 83) (prog-if 00
Re: [ACPI] Call for help: list of machines with working S3
Pavel, I think that it is the BIOS' job on S3-suspend to save the video mode. On S3-resume the BIOS should re-POST and restore the video mode. While Linux's X drivers may be able to handle the case where X is running -- that doesn't help us with the cases where X is not running (a case that Windows presumably does not have). Besides updated X drivers, which may have complicated restore routines for complicated modes, all the other techniques for restoring video from Linux are hit/miss workarounds for broken platforms. To completely solve the Linux S3 video restore issue, we need to push the platform and BIOS vendors. What am I missing? thanks, -Len - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Model hack (or "how to do it") -- Acer Aspire 1406LC ole's radeonfb patch I have to turn off dri, and then it works with the radeonfb patch. I use this method because I like the fancy framebuffersplash on booting .. although I do not reboot often when S3 wors ;) You can find the patch here: http://dev.gentoo.org/~marineam/patch-radeonfb-2.6.11-rc2-mm2 or for older kernels: http://dev.gentoo.org/~genstef/files/radeon-s3-resume-2.6.10.patch The problems with this patch are: - you need to press a key to come back from the "resume-console" after resume. - DRI in X does not work (at least for me with intel-agp, others reportet it works) I just disabloed it by not loading intel-agp (hotplug-blacklist) I have not only issues with video not coming back, but I also need to append acpi=noirq to my command-line that I am able to finish resuming and use my devices correctly afterwards. Regards, Stefan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Matthew Garrett schrieb: > On Tue, 2005-02-15 at 19:57 +0100, Carl-Daniel Hailfinger wrote: > > >>Kendall Bennett is working with me to get suspend/resume working >>even with framebuffers. Once we have results, I'll post them here. > > > I've had success using vesafb with vbetool state restoration. vga16fb > ought to work fairly happily. Well, in my testing the machine deadlocked if any framebuffer was active during resume. It even deadlocked *before* I could run vbetool. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Hi, On Mon, 2005-02-14 at 22:11 +0100, Pavel Machek wrote: > Stefan provided me initial list of machines where S3 works (including > video). If you have machine that is not on the list, please send me a > diff. If you have eMachines... I'd like you to try playing with > vbetool (it worked for me), and if it works for you supplying right > model numbers. I have S3 working with 2.6.11-rc4 here: Model hack (or "how to do it") -- IBM TP X31 / Type 2672-XXH LCD backlight must be turned off manually using radeontool [1] Sincerely, Brix [1]: http://fdd.com/software/radeon/ -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [ACPI] Call for help: list of machines with working S3
On Tue, 2005-02-15 at 19:57 +0100, Carl-Daniel Hailfinger wrote: > Kendall Bennett is working with me to get suspend/resume working > even with framebuffers. Once we have results, I'll post them here. I've had success using vesafb with vbetool state restoration. vga16fb ought to work fairly happily. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Hi! > - Sometimes I have to make a Sysrq-s (sync) to get some stuff running > (eg logging in from the console hangs after input of passwd, calling > sysrq-s makes it continue). I had a similar effect when logging in > AFTER resuming (for the resume I had only gdm running but wasn't > logged in) the GNOME starting screen stayed there indefinitely, no > change. Even after restarting the X server and retrying. > Logging in with twm session DID work without any problem. > Do you have any idea what this could be? Does it happen with swsusp? Is it in any way reproducible? Maybe commenting out refrigerator would help Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Am Dienstag, 15. Februar 2005 18:08 schrieb Norbert Preining: > On Die, 15 Feb 2005, Carl-Daniel Hailfinger wrote: > > To suspend and resume properly, call the following script as root: > > Success. > > After deactivating DRI in the X config file and saving the states with > your script (thanks) and turning off various stuff I get X running > again. > > Questions: > - DRI must be disabled I guess?! Even with newer X server (x.org)? Do you use the fglrx driver? This doesn't work with any type of suspend so far. If you use the radeon driver try a driver update. Stefan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Norbert Preining schrieb: > On Die, 15 Feb 2005, Carl-Daniel Hailfinger wrote: > >>To suspend and resume properly, call the following script as root: > > > Success. Great! > After deactivating DRI in the X config file and saving the states with > your script (thanks) and turning off various stuff I get X running > again. > > Questions: > - DRI must be disabled I guess?! Even with newer X server (x.org)? I never disabled it. > - I dont have to restore the font, it is back without any problem > (I have vga console) Good. I guess that's highly chipset-specific. > - Sometimes I have to make a Sysrq-s (sync) to get some stuff running > (eg logging in from the console hangs after input of passwd, calling > sysrq-s makes it continue). I had a similar effect when logging in > AFTER resuming (for the resume I had only gdm running but wasn't > logged in) the GNOME starting screen stayed there indefinitely, no > change. Even after restarting the X server and retrying. > Logging in with twm session DID work without any problem. > Do you have any idea what this could be? Pavel? > - My script is a bit more complicated: stopping: hotplug, mysql, > ifplugd, waproamd, cpufreqd, acpid, ifdown eth0, eth1, rmmod acerhk > echo "performance" onto governor, then going to sleepand doing > more or less the reverse stuff after waking up. > DO you have any experience with hotplug network etc stuff, working > even without stopping? I used to unload modules, shutdown network interfaces etc. until I tried without all that stuff and it still worked. So I concluded that stopping things before suspend was a thing only needed with older kernels. Granted, mounted volumes on USB or IEEE1394 still have problems because the kernel doesn't expect them to disappear for a few moments, but that's nothing a module unload would fix. Simply umount all external drives and use my script. Drivers which still need to be unloaded and reloaded are buggy and have to be fixed. I'll prepare a web page with detailed S3/S4 suspend/resume information for ATI graphics card owners including step-by-step howtos for smooth suspend/resume cycles. Kendall Bennett is working with me to get suspend/resume working even with framebuffers. Once we have results, I'll post them here. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Die, 15 Feb 2005, Carl-Daniel Hailfinger wrote: > To suspend and resume properly, call the following script as root: Success. After deactivating DRI in the X config file and saving the states with your script (thanks) and turning off various stuff I get X running again. Questions: - DRI must be disabled I guess?! Even with newer X server (x.org)? - I dont have to restore the font, it is back without any problem (I have vga console) - Sometimes I have to make a Sysrq-s (sync) to get some stuff running (eg logging in from the console hangs after input of passwd, calling sysrq-s makes it continue). I had a similar effect when logging in AFTER resuming (for the resume I had only gdm running but wasn't logged in) the GNOME starting screen stayed there indefinitely, no change. Even after restarting the X server and retrying. Logging in with twm session DID work without any problem. Do you have any idea what this could be? - My script is a bit more complicated: stopping: hotplug, mysql, ifplugd, waproamd, cpufreqd, acpid, ifdown eth0, eth1, rmmod acerhk echo "performance" onto governor, then going to sleepand doing more or less the reverse stuff after waking up. DO you have any experience with hotplug network etc stuff, working even without stopping? Thanks a lot. Best wishes Norbert --- Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- CROMARTY (n.) The brittle sludge which clings to the top of ketchup bottles and plastic tomatoes in nasty cafes. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Pavel Machek wrote: > > Table of known working systems: > > Model hack (or "how to do it") > -- > IBM TP R32 / Type 2658-MMG none (1) IBM TP T40 / Type 2373-MU4 none (1) IBM TP R50p / Type 1832-22U s3_bios (2) > Athlon HP Omnibook XE3none (1) > Compaq Armada E500 - P3-700 none (1) (S1 also works OK) > IBM t41p none (1) --Vernon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Norbert Preining schrieb: > On Mon, 14 Feb 2005, Pavel Machek wrote: > >>(1) systems where video state is preserved over S3. >> >>(2) systems where it is possible to call video bios during S3 >> resume. Unfortunately, it is not correct to call video BIOS at that >> point, but it happens to work on some machines. Use >> acpi_sleep=s3_bios. >> >>(3) systems that initialize video card into vga text mode and where BIOS >> works well enough to be able to set video mode. Use >> acpi_sleep=s3_mode on these. >> >>(4) on some systems s3_bios kicks video into text mode, and >> acpi_sleep=s3_bios,s3_mode is needed. >> >>(5) radeon systems, where X can soft-boot your video card. You'll need >> patched X, and plain text console (no vesafb or radeonfb), see >> http://www.doesi.gmxhome.de/linux/tm800s3/s3.html. >> >>(6) other radeon systems, where vbetool is enough to bring system back >> to life. Do vbetool vbestate save > /tmp/delme; echo 3 > /proc/acpi/sleep; >> vbetool post; vbetool vbestate restore < /tmp/delme; setfont >> , and your video should work. >> >>Acer TM 800 vga=normal, X patches, see webpage (5) > > > > Acer TM 650 (Radeon M7) > > vga=normal plus boot-radeon (webpage(5)) works to get text console > back. But switching to X freezes the computer completely. Please try method (6). It should work perfectly because it is the successor for method (5) and works even without special patches for X. > X from debian sid. > XFree86 Version 4.3.0.1 (Debian 4.3.0.dfsg.1-10 20041215174925 [EMAIL > PROTECTED]) > Release Date: 15 August 2003 > X Protocol Version 11, Revision 0, Release 6.6 > Build Operating System: Linux 2.4.26 i686 [ELF] > Build Date: 15 December 2004 > > > I would like to get X running to, but there are no traces in the logfile > whatsoever to be seen. Pity. First, boot into X and run the following script ONCE: #!/bin/bash statedir=/root/s3/state mkdir -p $statedir chvt 2 sleep 1 vbetool vbestate save >$statedir/vbe To suspend and resume properly, call the following script as root: #!/bin/bash statedir=/root/s3/state curcons=`fgconsole` fuser /dev/tty$curcons 2>/dev/null|xargs ps -o comm= -p|grep -q X && chvt 2 cat /dev/vcsa >$statedir/vcsa sync echo 3 >/proc/acpi/sleep sync vbetool post vbetool vbestate restore <$statedir/vbe cat $statedir/vcsa >/dev/vcsa rckbd restart chvt $[curcons%6+1] chvt $curcons Unless you change your grahics card or other hardware configuration, the state once saved will be OK for every resume afterwards. NOTE: The "rckbd restart" command may be different for your distribution. Simply replace it with the command you would use to set the fonts on screen. > So it seems that my laptop does not fall in any of these categories. Please try my scripts and resport back. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Thus wrote Norbert Preining: > vga=normal plus boot-radeon (webpage(5)) works to get text console > back. But switching to X freezes the computer completely. > > X from debian sid. > XFree86 Version 4.3.0.1 (Debian 4.3.0.dfsg.1-10 20041215174925 [EMAIL > PROTECTED]) > Release Date: 15 August 2003 Get a recent X version, 4.4, 6.7.0 or 6.8.2 will do. Alternatively, disable DRI. Best regards, -- Karol 'sziwan' Kozimor [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Mon, 14 Feb 2005, Pavel Machek wrote: > (1) systems where video state is preserved over S3. > > (2) systems where it is possible to call video bios during S3 > resume. Unfortunately, it is not correct to call video BIOS at that > point, but it happens to work on some machines. Use > acpi_sleep=s3_bios. > > (3) systems that initialize video card into vga text mode and where BIOS > works well enough to be able to set video mode. Use > acpi_sleep=s3_mode on these. > > (4) on some systems s3_bios kicks video into text mode, and > acpi_sleep=s3_bios,s3_mode is needed. > > (5) radeon systems, where X can soft-boot your video card. You'll need > patched X, and plain text console (no vesafb or radeonfb), see > http://www.doesi.gmxhome.de/linux/tm800s3/s3.html. > > (6) other radeon systems, where vbetool is enough to bring system back > to life. Do vbetool vbestate save > /tmp/delme; echo 3 > /proc/acpi/sleep; > vbetool post; vbetool vbestate restore < /tmp/delme; setfont > , and your video should work. > > Acer TM 800 vga=normal, X patches, see webpage (5) Acer TM 650 (Radeon M7) vga=normal plus boot-radeon (webpage(5)) works to get text console back. But switching to X freezes the computer completely. X from debian sid. XFree86 Version 4.3.0.1 (Debian 4.3.0.dfsg.1-10 20041215174925 [EMAIL PROTECTED]) Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.26 i686 [ELF] Build Date: 15 December 2004 I would like to get X running to, but there are no traces in the logfile whatsoever to be seen. Pity. So it seems that my laptop does not fall in any of these categories. Best wishes Norbert --- Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- PELUTHO (n.) A South American ball game. The balls are whacked against a brick wall with a stout wooden bat until the prisoner confesses. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Mon, 14 Feb 2005, Pavel Machek wrote: (1) systems where video state is preserved over S3. (2) systems where it is possible to call video bios during S3 resume. Unfortunately, it is not correct to call video BIOS at that point, but it happens to work on some machines. Use acpi_sleep=s3_bios. (3) systems that initialize video card into vga text mode and where BIOS works well enough to be able to set video mode. Use acpi_sleep=s3_mode on these. (4) on some systems s3_bios kicks video into text mode, and acpi_sleep=s3_bios,s3_mode is needed. (5) radeon systems, where X can soft-boot your video card. You'll need patched X, and plain text console (no vesafb or radeonfb), see http://www.doesi.gmxhome.de/linux/tm800s3/s3.html. (6) other radeon systems, where vbetool is enough to bring system back to life. Do vbetool vbestate save /tmp/delme; echo 3 /proc/acpi/sleep; vbetool post; vbetool vbestate restore /tmp/delme; setfont whatever, and your video should work. Acer TM 800 vga=normal, X patches, see webpage (5) Acer TM 650 (Radeon M7) vga=normal plus boot-radeon (webpage(5)) works to get text console back. But switching to X freezes the computer completely. X from debian sid. XFree86 Version 4.3.0.1 (Debian 4.3.0.dfsg.1-10 20041215174925 [EMAIL PROTECTED]) Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.26 i686 [ELF] Build Date: 15 December 2004 I would like to get X running to, but there are no traces in the logfile whatsoever to be seen. Pity. So it seems that my laptop does not fall in any of these categories. Best wishes Norbert --- Norbert Preining preining AT logic DOT at Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- PELUTHO (n.) A South American ball game. The balls are whacked against a brick wall with a stout wooden bat until the prisoner confesses. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Thus wrote Norbert Preining: vga=normal plus boot-radeon (webpage(5)) works to get text console back. But switching to X freezes the computer completely. X from debian sid. XFree86 Version 4.3.0.1 (Debian 4.3.0.dfsg.1-10 20041215174925 [EMAIL PROTECTED]) Release Date: 15 August 2003 Get a recent X version, 4.4, 6.7.0 or 6.8.2 will do. Alternatively, disable DRI. Best regards, -- Karol 'sziwan' Kozimor [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Norbert Preining schrieb: On Mon, 14 Feb 2005, Pavel Machek wrote: (1) systems where video state is preserved over S3. (2) systems where it is possible to call video bios during S3 resume. Unfortunately, it is not correct to call video BIOS at that point, but it happens to work on some machines. Use acpi_sleep=s3_bios. (3) systems that initialize video card into vga text mode and where BIOS works well enough to be able to set video mode. Use acpi_sleep=s3_mode on these. (4) on some systems s3_bios kicks video into text mode, and acpi_sleep=s3_bios,s3_mode is needed. (5) radeon systems, where X can soft-boot your video card. You'll need patched X, and plain text console (no vesafb or radeonfb), see http://www.doesi.gmxhome.de/linux/tm800s3/s3.html. (6) other radeon systems, where vbetool is enough to bring system back to life. Do vbetool vbestate save /tmp/delme; echo 3 /proc/acpi/sleep; vbetool post; vbetool vbestate restore /tmp/delme; setfont whatever, and your video should work. Acer TM 800 vga=normal, X patches, see webpage (5) Acer TM 650 (Radeon M7) vga=normal plus boot-radeon (webpage(5)) works to get text console back. But switching to X freezes the computer completely. Please try method (6). It should work perfectly because it is the successor for method (5) and works even without special patches for X. X from debian sid. XFree86 Version 4.3.0.1 (Debian 4.3.0.dfsg.1-10 20041215174925 [EMAIL PROTECTED]) Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.26 i686 [ELF] Build Date: 15 December 2004 I would like to get X running to, but there are no traces in the logfile whatsoever to be seen. Pity. First, boot into X and run the following script ONCE: #!/bin/bash statedir=/root/s3/state mkdir -p $statedir chvt 2 sleep 1 vbetool vbestate save $statedir/vbe To suspend and resume properly, call the following script as root: #!/bin/bash statedir=/root/s3/state curcons=`fgconsole` fuser /dev/tty$curcons 2/dev/null|xargs ps -o comm= -p|grep -q X chvt 2 cat /dev/vcsa $statedir/vcsa sync echo 3 /proc/acpi/sleep sync vbetool post vbetool vbestate restore $statedir/vbe cat $statedir/vcsa /dev/vcsa rckbd restart chvt $[curcons%6+1] chvt $curcons Unless you change your grahics card or other hardware configuration, the state once saved will be OK for every resume afterwards. NOTE: The rckbd restart command may be different for your distribution. Simply replace it with the command you would use to set the fonts on screen. So it seems that my laptop does not fall in any of these categories. Please try my scripts and resport back. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Pavel Machek wrote: Table of known working systems: Model hack (or how to do it) -- IBM TP R32 / Type 2658-MMG none (1) IBM TP T40 / Type 2373-MU4 none (1) IBM TP R50p / Type 1832-22U s3_bios (2) Athlon HP Omnibook XE3none (1) Compaq Armada E500 - P3-700 none (1) (S1 also works OK) IBM t41p none (1) --Vernon - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Die, 15 Feb 2005, Carl-Daniel Hailfinger wrote: To suspend and resume properly, call the following script as root: Success. After deactivating DRI in the X config file and saving the states with your script (thanks) and turning off various stuff I get X running again. Questions: - DRI must be disabled I guess?! Even with newer X server (x.org)? - I dont have to restore the font, it is back without any problem (I have vga console) - Sometimes I have to make a Sysrq-s (sync) to get some stuff running (eg logging in from the console hangs after input of passwd, calling sysrq-s makes it continue). I had a similar effect when logging in AFTER resuming (for the resume I had only gdm running but wasn't logged in) the GNOME starting screen stayed there indefinitely, no change. Even after restarting the X server and retrying. Logging in with twm session DID work without any problem. Do you have any idea what this could be? - My script is a bit more complicated: stopping: hotplug, mysql, ifplugd, waproamd, cpufreqd, acpid, ifdown eth0, eth1, rmmod acerhk echo performance onto governor, then going to sleepand doing more or less the reverse stuff after waking up. DO you have any experience with hotplug network etc stuff, working even without stopping? Thanks a lot. Best wishes Norbert --- Norbert Preining preining AT logic DOT at Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- CROMARTY (n.) The brittle sludge which clings to the top of ketchup bottles and plastic tomatoes in nasty cafes. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Norbert Preining schrieb: On Die, 15 Feb 2005, Carl-Daniel Hailfinger wrote: To suspend and resume properly, call the following script as root: Success. Great! After deactivating DRI in the X config file and saving the states with your script (thanks) and turning off various stuff I get X running again. Questions: - DRI must be disabled I guess?! Even with newer X server (x.org)? I never disabled it. - I dont have to restore the font, it is back without any problem (I have vga console) Good. I guess that's highly chipset-specific. - Sometimes I have to make a Sysrq-s (sync) to get some stuff running (eg logging in from the console hangs after input of passwd, calling sysrq-s makes it continue). I had a similar effect when logging in AFTER resuming (for the resume I had only gdm running but wasn't logged in) the GNOME starting screen stayed there indefinitely, no change. Even after restarting the X server and retrying. Logging in with twm session DID work without any problem. Do you have any idea what this could be? Pavel? - My script is a bit more complicated: stopping: hotplug, mysql, ifplugd, waproamd, cpufreqd, acpid, ifdown eth0, eth1, rmmod acerhk echo performance onto governor, then going to sleepand doing more or less the reverse stuff after waking up. DO you have any experience with hotplug network etc stuff, working even without stopping? I used to unload modules, shutdown network interfaces etc. until I tried without all that stuff and it still worked. So I concluded that stopping things before suspend was a thing only needed with older kernels. Granted, mounted volumes on USB or IEEE1394 still have problems because the kernel doesn't expect them to disappear for a few moments, but that's nothing a module unload would fix. Simply umount all external drives and use my script. Drivers which still need to be unloaded and reloaded are buggy and have to be fixed. I'll prepare a web page with detailed S3/S4 suspend/resume information for ATI graphics card owners including step-by-step howtos for smooth suspend/resume cycles. Kendall Bennett is working with me to get suspend/resume working even with framebuffers. Once we have results, I'll post them here. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Am Dienstag, 15. Februar 2005 18:08 schrieb Norbert Preining: On Die, 15 Feb 2005, Carl-Daniel Hailfinger wrote: To suspend and resume properly, call the following script as root: Success. After deactivating DRI in the X config file and saving the states with your script (thanks) and turning off various stuff I get X running again. Questions: - DRI must be disabled I guess?! Even with newer X server (x.org)? Do you use the fglrx driver? This doesn't work with any type of suspend so far. If you use the radeon driver try a driver update. Stefan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Hi! - Sometimes I have to make a Sysrq-s (sync) to get some stuff running (eg logging in from the console hangs after input of passwd, calling sysrq-s makes it continue). I had a similar effect when logging in AFTER resuming (for the resume I had only gdm running but wasn't logged in) the GNOME starting screen stayed there indefinitely, no change. Even after restarting the X server and retrying. Logging in with twm session DID work without any problem. Do you have any idea what this could be? Does it happen with swsusp? Is it in any way reproducible? Maybe commenting out refrigerator would help Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Tue, 2005-02-15 at 19:57 +0100, Carl-Daniel Hailfinger wrote: Kendall Bennett is working with me to get suspend/resume working even with framebuffers. Once we have results, I'll post them here. I've had success using vesafb with vbetool state restoration. vga16fb ought to work fairly happily. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Hi, On Mon, 2005-02-14 at 22:11 +0100, Pavel Machek wrote: Stefan provided me initial list of machines where S3 works (including video). If you have machine that is not on the list, please send me a diff. If you have eMachines... I'd like you to try playing with vbetool (it worked for me), and if it works for you supplying right model numbers. I have S3 working with 2.6.11-rc4 here: Model hack (or how to do it) -- IBM TP X31 / Type 2672-XXH LCD backlight must be turned off manually using radeontool [1] Sincerely, Brix [1]: http://fdd.com/software/radeon/ -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [ACPI] Call for help: list of machines with working S3
Matthew Garrett schrieb: On Tue, 2005-02-15 at 19:57 +0100, Carl-Daniel Hailfinger wrote: Kendall Bennett is working with me to get suspend/resume working even with framebuffers. Once we have results, I'll post them here. I've had success using vesafb with vbetool state restoration. vga16fb ought to work fairly happily. Well, in my testing the machine deadlocked if any framebuffer was active during resume. It even deadlocked *before* I could run vbetool. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Model hack (or how to do it) -- Acer Aspire 1406LC ole's radeonfb patch I have to turn off dri, and then it works with the radeonfb patch. I use this method because I like the fancy framebuffersplash on booting .. although I do not reboot often when S3 wors ;) You can find the patch here: http://dev.gentoo.org/~marineam/patch-radeonfb-2.6.11-rc2-mm2 or for older kernels: http://dev.gentoo.org/~genstef/files/radeon-s3-resume-2.6.10.patch The problems with this patch are: - you need to press a key to come back from the resume-console after resume. - DRI in X does not work (at least for me with intel-agp, others reportet it works) I just disabloed it by not loading intel-agp (hotplug-blacklist) I have not only issues with video not coming back, but I also need to append acpi=noirq to my command-line that I am able to finish resuming and use my devices correctly afterwards. Regards, Stefan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Mon, 2005-02-14 at 23:23 +, Matthew Garrett wrote: > On Mon, 2005-02-14 at 22:11 +0100, Pavel Machek wrote: > > Hi! > > > > Stefan provided me initial list of machines where S3 works (including > > video). If you have machine that is not on the list, please send me a > > diff. If you have eMachines... I'd like you to try playing with > > vbetool (it worked for me), and if it works for you supplying right > > model numbers. > > http://www.ubuntulinux.org/wiki/HoaryPMTesting has a list of several > working machines. HP seem to be the worst supported at the moment. Sorry - that should be http://www.ubuntulinux.org/wiki/HoaryPMResults -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Mon, 2005-02-14 at 22:11 +0100, Pavel Machek wrote: > Hi! > > Stefan provided me initial list of machines where S3 works (including > video). If you have machine that is not on the list, please send me a > diff. If you have eMachines... I'd like you to try playing with > vbetool (it worked for me), and if it works for you supplying right > model numbers. http://www.ubuntulinux.org/wiki/HoaryPMTesting has a list of several working machines. HP seem to be the worst supported at the moment. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Pavel Machek schrieb: > Hi! > > Stefan provided me initial list of machines where S3 works (including > video). If you have machine that is not on the list, please send me a > diff. If you have eMachines... I'd like you to try playing with > vbetool (it worked for me), and if it works for you supplying right > model numbers. > > Pavel > > > Video issues with S3 resume > ~~~ > 2003-2005, Pavel Machek > > During S3 resume, hardware needs to be reinitialized. For most > devices, this is easy, and kernel driver knows how to do > it. Unfortunately there's one exception: video card. Those are usually > initialized by BIOS, and kernel does not have enough information to > boot video card. (Kernel usually does not even contain video card > driver -- vesafb and vgacon are widely used). > > This is not problem for swsusp, because during swsusp resume, BIOS is > run normally so video card is normally initialized. S3 has absolutely > no change to work with SMP/HT. Be sure it to turn it off before > testing (swsusp should work ok, OTOH). > > There are few types of systems where video works after S3 resume: > > (1) systems where video state is preserved over S3. > > (2) systems where it is possible to call video bios during S3 > resume. Unfortunately, it is not correct to call video BIOS at that > point, but it happens to work on some machines. Use > acpi_sleep=s3_bios. > > (3) systems that initialize video card into vga text mode and where BIOS > works well enough to be able to set video mode. Use > acpi_sleep=s3_mode on these. > > (4) on some systems s3_bios kicks video into text mode, and > acpi_sleep=s3_bios,s3_mode is needed. > > (5) radeon systems, where X can soft-boot your video card. You'll need > patched X, and plain text console (no vesafb or radeonfb), see > http://www.doesi.gmxhome.de/linux/tm800s3/s3.html. (5) machines should also work with (6), but not the other way round. > > (6) other radeon systems, where vbetool is enough to bring system back > to life. Do vbetool vbestate save > /tmp/delme; echo 3 > /proc/acpi/sleep; > vbetool post; vbetool vbestate restore < /tmp/delme; setfont > , and your video should work. (6) has to be done from a text console! It should work for all radeon systems, btw. > > Now, if you pass acpi_sleep=something, and it does not work with your > bios, you'll get hard crash during resume. Be carefull. Also it is > safest to do your experiments with plain old VGA console. vesafb and > radeonfb (etc) drivers have tendency to crash the machine during resume. > > You may have system where none of above works. At that point you > either invent another ugly hack that works, or write proper driver for > your video card (good luck getting docs :-(). Maybe suspending from X > (proper X, knowing your hardware, not XF68_FBcon) might have better > chance of working. > > Table of known working systems: > > Model hack (or "how to do it") > -- > IBM TP R32 / Type 2658-MMG none (1) > Athlon HP Omnibook XE3none (1) > Compaq Armada E500 - P3-700 none (1) (S1 also works OK) > IBM t41p none (1) > Athlon64 desktop prototypes3_bios (2) > HP NC6000 s3_bios (2) > Toshiba Satellite 4080XCDT s3_mode (3) > Toshiba Satellite 4030CDT s3_mode (3) > Dell D600, ATI RV250vga=normal (**) The Dell system above should also work fine with vbestate. > Asus L2400D s3_mode (3)(***) (S1 also works OK) > Toshiba Satellite P10-554 s3_bios,s3_mode (4)() > Acer TM 800 vga=normal, X patches, see webpage (5) > Athlon64 Arima W730a vbestate needed (6) > eMachines athlon64 machines vbestate needed (6) (someone please get me > model #s) Samsung P35 vbestate needed (6) > > (**) Text console is "strange" after resume. Backlight is switched on again > by the X server. X server is: > | X Window System Version 6.8.1.904 (6.8.2 RC 4) > | Release Date: 2 February 2005 > | X Protocol Version 11, Revision 0, Release 6.8.1.904 > | Build Operating System: SuSE Linux [ELF] SuSE > as present in SUSE 9.3preview3. > > (***) To be tested with a newer kernel. > > () Not with SMP kernel, UP only. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Pavel Machek schrieb: Hi! Stefan provided me initial list of machines where S3 works (including video). If you have machine that is not on the list, please send me a diff. If you have eMachines... I'd like you to try playing with vbetool (it worked for me), and if it works for you supplying right model numbers. Pavel Video issues with S3 resume ~~~ 2003-2005, Pavel Machek During S3 resume, hardware needs to be reinitialized. For most devices, this is easy, and kernel driver knows how to do it. Unfortunately there's one exception: video card. Those are usually initialized by BIOS, and kernel does not have enough information to boot video card. (Kernel usually does not even contain video card driver -- vesafb and vgacon are widely used). This is not problem for swsusp, because during swsusp resume, BIOS is run normally so video card is normally initialized. S3 has absolutely no change to work with SMP/HT. Be sure it to turn it off before testing (swsusp should work ok, OTOH). There are few types of systems where video works after S3 resume: (1) systems where video state is preserved over S3. (2) systems where it is possible to call video bios during S3 resume. Unfortunately, it is not correct to call video BIOS at that point, but it happens to work on some machines. Use acpi_sleep=s3_bios. (3) systems that initialize video card into vga text mode and where BIOS works well enough to be able to set video mode. Use acpi_sleep=s3_mode on these. (4) on some systems s3_bios kicks video into text mode, and acpi_sleep=s3_bios,s3_mode is needed. (5) radeon systems, where X can soft-boot your video card. You'll need patched X, and plain text console (no vesafb or radeonfb), see http://www.doesi.gmxhome.de/linux/tm800s3/s3.html. (5) machines should also work with (6), but not the other way round. (6) other radeon systems, where vbetool is enough to bring system back to life. Do vbetool vbestate save /tmp/delme; echo 3 /proc/acpi/sleep; vbetool post; vbetool vbestate restore /tmp/delme; setfont whatever, and your video should work. (6) has to be done from a text console! It should work for all radeon systems, btw. Now, if you pass acpi_sleep=something, and it does not work with your bios, you'll get hard crash during resume. Be carefull. Also it is safest to do your experiments with plain old VGA console. vesafb and radeonfb (etc) drivers have tendency to crash the machine during resume. You may have system where none of above works. At that point you either invent another ugly hack that works, or write proper driver for your video card (good luck getting docs :-(). Maybe suspending from X (proper X, knowing your hardware, not XF68_FBcon) might have better chance of working. Table of known working systems: Model hack (or how to do it) -- IBM TP R32 / Type 2658-MMG none (1) Athlon HP Omnibook XE3none (1) Compaq Armada E500 - P3-700 none (1) (S1 also works OK) IBM t41p none (1) Athlon64 desktop prototypes3_bios (2) HP NC6000 s3_bios (2) Toshiba Satellite 4080XCDT s3_mode (3) Toshiba Satellite 4030CDT s3_mode (3) Dell D600, ATI RV250vga=normal (**) The Dell system above should also work fine with vbestate. Asus L2400D s3_mode (3)(***) (S1 also works OK) Toshiba Satellite P10-554 s3_bios,s3_mode (4)() Acer TM 800 vga=normal, X patches, see webpage (5) Athlon64 Arima W730a vbestate needed (6) eMachines athlon64 machines vbestate needed (6) (someone please get me model #s) Samsung P35 vbestate needed (6) (**) Text console is strange after resume. Backlight is switched on again by the X server. X server is: | X Window System Version 6.8.1.904 (6.8.2 RC 4) | Release Date: 2 February 2005 | X Protocol Version 11, Revision 0, Release 6.8.1.904 | Build Operating System: SuSE Linux [ELF] SuSE as present in SUSE 9.3preview3. (***) To be tested with a newer kernel. () Not with SMP kernel, UP only. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Mon, 2005-02-14 at 22:11 +0100, Pavel Machek wrote: Hi! Stefan provided me initial list of machines where S3 works (including video). If you have machine that is not on the list, please send me a diff. If you have eMachines... I'd like you to try playing with vbetool (it worked for me), and if it works for you supplying right model numbers. http://www.ubuntulinux.org/wiki/HoaryPMTesting has a list of several working machines. HP seem to be the worst supported at the moment. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
On Mon, 2005-02-14 at 23:23 +, Matthew Garrett wrote: On Mon, 2005-02-14 at 22:11 +0100, Pavel Machek wrote: Hi! Stefan provided me initial list of machines where S3 works (including video). If you have machine that is not on the list, please send me a diff. If you have eMachines... I'd like you to try playing with vbetool (it worked for me), and if it works for you supplying right model numbers. http://www.ubuntulinux.org/wiki/HoaryPMTesting has a list of several working machines. HP seem to be the worst supported at the moment. Sorry - that should be http://www.ubuntulinux.org/wiki/HoaryPMResults -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
