Menu
▾
▴
suspend-devel — Linux Suspend Development List
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
(75) |
Mar
(232) |
Apr
(182) |
May
(75) |
Jun
(143) |
Jul
(184) |
Aug
(197) |
Sep
(223) |
Oct
(134) |
Nov
(257) |
Dec
(187) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(242) |
Feb
(230) |
Mar
(283) |
Apr
(200) |
May
(252) |
Jun
(117) |
Jul
(368) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Pavel M. <pa...@uc...> - 2007-07-31 08:07:59
|
On Mon 2007-07-30 19:53:35, Alon Bar-Lev wrote: > On 7/30/07, Stefan Seyfried <se...@su...> wrote: > >> Why do you forward people to suse URLs on whitelist? > >> I would have expected all be forwarded to suspend.sf.net... > >> http://en.opensuse.org/S2ram belongs to the project site... not > >> distribution specific site. > > Ok, so i'm going to take that one personally now. :-) > > This is a mistake! > I don't understand why each simple discussion becomes so heated! ... <html snipped> ... > And walla! You can switch to some other site, or maintain it at > suspend site. At any case you don't need to distribute a new release > with updated URLs. > > Also know that if support and the package come from the same source it > looks more professional to most users... (Just like you get a product > and have a single point of contact). > > Simple, right? > No need to make this an awful discussion. > I will not address all the flame you wrote, next time, please assume > the other side wish to help. Right... so do you have sourceforge login? I guess we could use you as a webmaster for suspend.sf.net project ;-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html |
|
From: Arun R. <aru...@gm...> - 2007-07-31 07:32:45
|
On 7/30/07, Stefan Seyfried <se...@su...> wrote: > On Sat, Jul 28, 2007 at 04:28:21PM +0530, Arun Raghavan wrote: > > I'm not using a framebuffer ... it's the normal VGA console. > > Ok, in this case please test latest 2.6.23-rc and the "beep on resume"- > debugging (it should be included in 2.6.23-rc's IIRC, if not, you might > need to try -mm). Rafael, please complain if i'm talking nonsense here ;-) Surprise of surprises, resume almost works in 2.6.23-rc1! I didn't get any beeping (my laptop might not have a beeping thing), but the machine does resume, except the LCD doesn't come back on. I'm attaching a file (all-options) with all the flags I've tried. None of these worked for me. Trying 10+ different sets of options is really painful, so I've made a little script to automate the process. It tries each of a set of options from a given file in series. I'm attaching both of these (also mirrored at http://nemesis.accosted.net/downloads/s2ram-test.tar.gz) in the hope that someone finds them useful, despite the hackiness. I just make the default Grub option my 2.6.23-rc1 kernel with "init=/root/s2ram-test/s2ram-test.sh", and then the only manual intervention required is hitting a key to wake the machine up after suspend. Feedback on the script is welcome. Also, the list of options used is pretty much arbitrary. Can someone in the know please review them, add/remove relevant options and reorder them by priority? I've updated my BIOS now (F.15 to F.23), and if someone can tell me the right set of options and the right order, I'll give the whole thing another go. Thanks, and hoping to have STR working soon ... Arun p.s.: dmidecode output: sys_vendor = "Hewlett-Packard" sys_product = "HP Pavilion dv5000 (EX103PA#ACJ) " sys_version = "F.23" bios_version = "F.23" p.p.s.: Stefan, sorry about the multiple copies. |
|
From: George T. <gte...@em...> - 2007-07-31 06:23:59
|
Stefan Seyfried wrote: > On Fri, Jul 27, 2007 at 11:08:26AM +0300, George Tellalov wrote: >> Hello, >> >> I have a Thinkpad 600e and I've found that s2ram sort of works. It needs "-f >> -p -m" or otherwise the vga mode is messed up. > > Does it also work with "-a 3"? Most of the slightly newer Thinkpads work fine > with "-a 3". > -a 3 results in a hard lock with caps lock and scroll lock blinking >> Even after -p -m the X video mode is messed up but switching manually to a >> virtual console and back to X fixes everything. > > Yes, i remember something like that from long ago tests on a 600e, however, > given the state of the NeoMagic X-driver, i don't think anybody can do much > about that :-( This is not specific to the X driver. Without X running the situation is even worse - the console is switched in some mode where the screen is bright grey and nothing is displayed. I tried to start X blindly but I failed. The only way out of it was a restart. When X is running switching to a console and back to X fixes both X and the console video modes. I hope this helps. Greetings This e-mail was scanned for viruses using BitDefender |
|
From: a v <ada...@ho...> - 2007-07-30 22:37:04
|
using -a 3 reinitializes the screen/(video adapter) badly, showing white and then slowly and unevenly fading to black: probably the melting screen you mentioned It does respond to stuff in that state (no crash), like sysRq commands, or rebooting with ctrl-alt del (after switching to a vt) so I guess there is a pattern :) >From: Stefan Seyfried <se...@su...> >To: a v <ada...@ho...> >CC: sus...@li... >Subject: Re: [Suspend-devel] s2ram: add tecra8100 to whitelist >Date: Fri, 27 Jul 2007 16:06:51 +0200 >MIME-Version: 1.0 >Received: from mx2.suse.de ([195.135.220.15]) by >bay0-mc2-f15.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Fri, >27 Jul 2007 07:06:56 -0700 >Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8])(using TLSv1 >with cipher DHE-RSA-AES256-SHA (256/256 bits))(No client certificate >requested)by mx2.suse.de (Postfix) with ESMTP id 34E13215DE;Fri, 27 Jul >2007 16:06:56 +0200 (CEST) >X-Message-Info: >LsUYwwHHNt3660MmjhEvYg2f34OAemlK+ZzoV09lDsZmbz8QigGIQtU5Yvr3lK0P >References: <BAY...@ph...l> >X-Operating-System: openSUSE 10.3 (i586) Alpha6plus, Kernel >2.6.22.1-6-default >User-Agent: mutt-ng/devel-r804 (Linux) >Return-Path: se...@su... >X-OriginalArrivalTime: 27 Jul 2007 14:06:57.0382 (UTC) >FILETIME=[64B76060:01C7D057] > >On Thu, Jul 19, 2007 at 03:36:09PM -0400, a v wrote: > > $ sudo s2ram -i > > This machine can be identified by: > > sys_vendor = "TOSHIBA" > > sys_product = "TECRA8100" > > sys_version = "PT810C-11C52" > > bios_version = "Version 2.50" > > > > it only works properly with -a 2 or adding acpi_sleep=s3_mode (same >thing) > > to grub's menu > >Ok, just because i'm curious: does "-a 3" also lead to a kind of "melting >screen"-effect as on my Tecra 8200? (make sure to try this without >important >stuff open, since i think the machine will crash with it). I'm looking for >a pattern here, since machines that fail with "-a 3" and actually need "-a >2" >are rather "exotic" :-) > >Thanks for testing and reporting! > >-- >Stefan Seyfried >QA / R&D Team Mobile Devices | "Any ideas, John?" >SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." > >This footer brought to you by insane German lawmakers: >SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) _________________________________________________________________ Show Your Messenger Buddies How You Really Feel http://www.freemessengeremoticons.ca/?icid=EMENCA122 |
|
From: Joel S. <joe...@in...> - 2007-07-30 17:29:32
|
Stefan Seyfried wrote: > On Mon, Jul 23, 2007 at 02:37:08PM +0200, Joel Schaerer wrote: >> Hi there, >> >> my machine is identified as follows: >> >> This machine can be identified by: >> sys_vendor = "Compaq " >> sys_product = "Evo N800w " >> sys_version = "F.11" >> bios_version = "68P4W Ver. F.11" >> >> It is not in the whitelist and doesn't work out of the box with s2ram -f, so I >> did a bit of testing and finally had success with >> >> s2ram -f -a 2 -p -m >> >> (it also works with -a 3) >> >> Both the a and p,m flags seem to be needed, since without the a flag the >> computer locks completely (find / doesn't do anything), and without the p and m >> flag the display doesn't come back on. > > Ok, but plain "s2ram -f -a3" also works? Because right now the machine is > listed as needing "s2ram -f -p -s", and we'd need to find out the differences > between your machine and the machine of the original reporter :-( No, it doesn't, it needs -f -a3 -p -m. > >> PS2: You guys might want to add a couple -lz to the makefile, I had to manually >> patch it to get it to link to the library on my F7. > > You should probably try the current CVS. -- Joël Schaerer PhD. Student Advisors: Patrick Clarysse, Isabelle Magnin CREATIS-LRMN, UMR CNRS 5220, Inserm U630 INSA de Lyon 7 rue Jean Capelle bat. Blaise Pascal, 4ème étage F-69621 Villeurbanne CEDEX France Tel (+33) 4 72 43 89 17 Fax (+33) 4 72 43 85 26 http://www.creatis.insa-lyon.fr |
|
From: Alon Bar-L. <alo...@gm...> - 2007-07-30 16:53:41
|
On 7/30/07, Stefan Seyfried <se...@su...> wrote: >> Why do you forward people to suse URLs on whitelist? >> I would have expected all be forwarded to suspend.sf.net... >> http://en.opensuse.org/S2ram belongs to the project site... not >> distribution specific site. > Ok, so i'm going to take that one personally now. :-) This is a mistake! I don't understand why each simple discussion becomes so heated! Just know that it makes the other side very uncomfortable... And may cause him not to try to contribute further. I don't care if you find it easier to use some wiki at some site, the URL should be project formal URL. All you need is to create http://suspend.sf.net/s2ram-support.html with the following content: <html> <meta http-equiv="refresh" content="1; URL=http://en.opensuse.org/S2ram"> <head><title>Redirect</title></head> <body> <a href="http://en.opensuse.org/S2ram">Here</a> </body> </html> And walla! You can switch to some other site, or maintain it at suspend site. At any case you don't need to distribute a new release with updated URLs. Also know that if support and the package come from the same source it looks more professional to most users... (Just like you get a product and have a single point of contact). Simple, right? No need to make this an awful discussion. I will not address all the flame you wrote, next time, please assume the other side wish to help. Alon. |
|
From: mire <mi...@os...> - 2007-07-30 16:51:41
|
hello,
I found a commandline that works for my laptop (I'm using ubuntu feisty)
s2ram -f -a3
s2ram --test
Machine is unknown.
This machine can be identified by:
sys_vendor = "TOSHIBA"
sys_product = "Satellite P200"
sys_version = "PSPB0E-01900JG3"
bios_version = "V1.40"
can I whitelist this myself somehow, like editing some config text file?
|
|
From: Stefan S. <se...@su...> - 2007-07-30 15:35:15
|
On Mon, Jul 30, 2007 at 02:45:53PM +0300, Antti Laine wrote: > Stefan Seyfried wrote: > >># s2ram -i > >>This machine can be identified by: > >> sys_vendor = "Hewlett-Packard" > >> sys_product = "HP Compaq nc4400 (EY605EA#AK8)" > >> sys_version = "F.09" > >> bios_version = "68YHV Ver. F.09" > >>See http://en.opensuse.org/S2ram for details. > >Ok. Does it work only from X or also from the text console? Rene Seindal > >reported in March that he needed "s2ram -f -p -s" to resume on a text > >console. This was with the old F.08 BIOS, though. > >If it does not work on the text console for you, please test "s2ram -f -p -m" > >first, then "s2ram -f -p -s". > >Thanks for testing :-) > > Stefan > > No problem :) You're right, those fixes are needed to resume on console. > Otherwise the screen stays blank. Both -m and -s work, but -m renders old > texts on the console unreadable. Switching between VTs fixes that though. That's expected and ok, since the framebuffer content in the videocard gets lost on resume and is only restored on repaint. -m is considered less "intrusive" than -s, so i'll take that one. > Both of the combinations work fine on X too. Very good :-) Machine is added to the whitelist. Thanks for testing Stefan -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) |
|
From: Rafael J. W. <rj...@si...> - 2007-07-30 12:34:07
|
On Monday, 30 July 2007 08:56, Stefan Seyfried wrote: > On Fri, Jul 27, 2007 at 08:45:41PM +0200, Rafael J. Wysocki wrote: > > On Friday, 27 July 2007 18:33, Stefan Seyfried wrote: > > > On Fri, Jul 27, 2007 at 05:18:45PM +0200, Rafael J. Wysocki wrote: > > > > > > > > (yes, i think i know what it does; writing 1 into the state of the > > > > > framebuffer device just disables any drawing - and thus any access > > > > > of possibly not really initialized hardware before running vbe_post > > > > > etc...) > > > > > At least it seemed to do no harm in my (limited) tests. > > > > > > > > I think it can go if > > > > (1) it doesn't break any setups that currently work > > > > > > We will know after the next openSUSE alpha release, where i will have > > > unleashed that patch onto the unexpecting guinea pigs^W^WopenSUSE users ;-) > > > If i don't get a wave of bugreports, than i'll assume that it is safe. > > > > > > Theoretically we could "protect" it by another quirk-flag, but i'd rather > > > try to avoid that. > > > > Agreed. > > > > > I will also go through the kernel code and check if anything can go wrong. > > > > Yes, please do that if you can. > > I did try to go through the kernel code, but i'd not put my hand into the > fire and guarantee that it does not do anything stupid :-) > > Some drivers (radeonfb and i810fb for example) are already doing this in > their suspend method and it seems to work. That sounds good. > That said, it should long-term be fixed in the kernel properly, but if we > can prove from userspace that it helps some machines, then we know that it > is worth the trouble. Yes. > > > Echoing "1" into the state file simply makes the text console "freeze" (but > > > apparently it is still doing stuff in the background, you can still output > > > text etc, you just won't see it). Echoing "0" will make it paint the current > > > screen contents. At least that was what happened in my experiments. > > > > > > > (2) it fixes at least one box that currently doesn't work > > > > > > Yes, the user in the bugreport is a happy camper now :-) (he does not have > > > the s2ram code right now, but uses the script equivalent, but unless i have > > > put a bug into the C code, it should be equivalent). > > > > Can you ask the user to test s2ram with your patch, please? > > yes, i will do that once i have built and pushed a package. OK -- "Premature optimization is the root of all evil." - Donald Knuth |
|
From: Stefan S. <se...@su...> - 2007-07-30 09:14:21
|
On Mon, Jul 30, 2007 at 10:20:10AM +0200, Hendrik-Jan Heins wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello Stefan, > > "# s2ram -a 1 -m" gives: > "The acpi_sleep, vbe_save, vbe_post, radeontool and pci_save parameters > must be used with --force" > > So it just won't work, I only get that message. Yes, i forgot to mention "-f", sorry for that. Fortunately you found this out by yourself ;-) > "s2ram -f -a1 -m" works, but I don't always seem to get the backlight > back on with that setting. (about haf the time it does get back on, and > half the time it doesn't.) Hm, too bad. Although i cannot imagine why this would happen... > > So far I've still had the best results with "s2ram -f -a1" ... i'll whitelist your machine with "-a 1" for now. Thanks for going through all those tests :-) Stefan -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) |
|
From: Stefan S. <se...@su...> - 2007-07-30 08:53:45
|
On Sat, Jul 28, 2007 at 04:28:21PM +0530, Arun Raghavan wrote: > On 7/27/07, Stefan Seyfried <se...@su...> wrote: > > On Mon, Jul 23, 2007 at 12:46:04AM +0530, Arun Raghavan wrote: > <snip> > > Are you using a framebuffer? If yes, try booting with "vga=0" for a > > plain VGA console. There are machines that need this. > > I'm not using a framebuffer ... it's the normal VGA console. Ok, in this case please test latest 2.6.23-rc and the "beep on resume"- debugging (it should be included in 2.6.23-rc's IIRC, if not, you might need to try -mm). Rafael, please complain if i'm talking nonsense here ;-) -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) |
|
From: Hendrik-Jan H. <hj...@pa...> - 2007-07-30 08:20:25
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Stefan, "# s2ram -a 1 -m" gives: "The acpi_sleep, vbe_save, vbe_post, radeontool and pci_save parameters must be used with --force" So it just won't work, I only get that message. "s2ram -f -a1 -m" works, but I don't always seem to get the backlight back on with that setting. (about haf the time it does get back on, and half the time it doesn't.) So far I've still had the best results with "s2ram -f -a1" Hendrik-Jan Stefan Seyfried wrote: > On Sun, Jul 29, 2007 at 10:54:01PM +0200, Hendrik-Jan Heins wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hello Pavel, list, >> >> Today I did some extensive testing with both i386 and amd64 in the X61s. >> The results are somewhat surprising (yes, to me too). >> First: I currently use BIOS version 1.06 (the newest Lenovo currently >> offers). When I started testing, and when I sent you the first e-mail, I >> used version 1.01. With that version other settings were needed for suspend. >> >> Currently I think for amd64 "s2ram -f -m" works best. "s2ram -f -a1" >> also seems to work. > > You could try "s2ram -f -a1 -m", which would be somewhat consistent with what > i saw working on other 64bit thinkpads. > >> For i386 the situation is a bit more complicated; as I said, I have >> issues with getting the backlight back on after suspend. Basically this >> problem exists with all parameters I tested. "s2ram -f -m" which works >> for amd64, doesn't seem to work for i386 (no backlight). >> "s2ram -f -a1" seems to yield the best results. So far I've had it back >> from suspend in all cases (9 tries). >> >> Over all "s2ram -f -a1" seems to be the one that "always" works. >> Ah yes, I'm currently using kernel 2.6.22.1 >> >> If you need me to do more testing, please tell me. > > If you could do some cycles with "-a 1 -m" on both i386 and x86_64, > this would be great. > > Thanks for your efforts, it is really appreciated > > Stefan - -- Publieke GnuPG sleutel beschikbaar op de volgende keyserver: pgpkeys.mit.edu Public GnuPG key available at keyserver pgpkeys.mit.edu -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGrZ86lpzDGKCS86sRAggNAJ9K2sjkgtPwUmE3yVxASeMc2+JTAACgpZEA 8oMhnd0dVOpC6imFffhhY0Q= =kr+B -----END PGP SIGNATURE----- |
|
From: Stefan S. <se...@su...> - 2007-07-30 07:57:24
|
On Mon, Jul 30, 2007 at 12:06:02AM +0200, Alexandr Kara wrote: > Hello, > I can succesfully suspend and resume (with loosing only WiFi connection) > a machine that is not in the database: > > s2ram -i produces this: > > sys_vendor = "FUJITSU SIEMENS" > sys_product = "AMILO Pro Edition V3405" > sys_version = "20 " > bios_version = "R01-B0E " > > I needed the following options in /etc/pm/config: "-f -a3". Thanks for reporting, i added it to the list. -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) |
|
From: Stefan S. <se...@su...> - 2007-07-30 07:57:18
|
On Sun, Jul 29, 2007 at 05:03:55PM -0500, Justin Ferguson wrote: > > This machine can be identified by: > sys_vendor = "Dell Inc." > sys_product = "MP061 " > sys_version = "" > bios_version = "A08" > > s2ram -f (no other arguments) works like a charm on this machine; can > we get it added to the whitelist? It already should be on the list (since 2006-12-18). Is your s2ram version older than that? If not, please post the output of "s2ram -n". -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) |
|
From: Stefan S. <se...@su...> - 2007-07-30 07:57:13
|
On Sun, Jul 29, 2007 at 02:56:12PM +0300, Antti Laine wrote: > Hi. I have a HP Compaq nc4400 notebook pc which doesn't seem to be on > suspend's whitelist, but works just fine with --force with the latest > bios (it did not work with the old bios it had in it when a got the > computer). Here is the output of s2ram -i: > > # s2ram -i > This machine can be identified by: > sys_vendor = "Hewlett-Packard" > sys_product = "HP Compaq nc4400 (EY605EA#AK8)" > sys_version = "F.09" > bios_version = "68YHV Ver. F.09" > See http://en.opensuse.org/S2ram for details. Ok. Does it work only from X or also from the text console? Rene Seindal reported in March that he needed "s2ram -f -p -s" to resume on a text console. This was with the old F.08 BIOS, though. If it does not work on the text console for you, please test "s2ram -f -p -m" first, then "s2ram -f -p -s". Thanks for testing :-) Stefan -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) |
|
From: Stefan S. <se...@su...> - 2007-07-30 07:57:06
|
On Fri, Jul 27, 2007 at 11:14:09PM +0100, Robert Hart wrote: > > My laptop suspends properly from both X and console without any parameters passed to s2ram. > > # s2ram -i > This machine can be identified by: > sys_vendor = "Hewlett-Packard" > sys_product = "HP Pavilion dv2500 Notebook PC" > sys_version = "F.05 " > bios_version = "F.05 " Thanks for reporting, added to the list now. -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) |
|
From: Stefan S. <se...@su...> - 2007-07-30 07:56:54
|
On Fri, Jul 27, 2007 at 08:45:41PM +0200, Rafael J. Wysocki wrote: > On Friday, 27 July 2007 18:33, Stefan Seyfried wrote: > > On Fri, Jul 27, 2007 at 05:18:45PM +0200, Rafael J. Wysocki wrote: > > > > > > (yes, i think i know what it does; writing 1 into the state of the > > > > framebuffer device just disables any drawing - and thus any access > > > > of possibly not really initialized hardware before running vbe_post > > > > etc...) > > > > At least it seemed to do no harm in my (limited) tests. > > > > > > I think it can go if > > > (1) it doesn't break any setups that currently work > > > > We will know after the next openSUSE alpha release, where i will have > > unleashed that patch onto the unexpecting guinea pigs^W^WopenSUSE users ;-) > > If i don't get a wave of bugreports, than i'll assume that it is safe. > > > > Theoretically we could "protect" it by another quirk-flag, but i'd rather > > try to avoid that. > > Agreed. > > > I will also go through the kernel code and check if anything can go wrong. > > Yes, please do that if you can. I did try to go through the kernel code, but i'd not put my hand into the fire and guarantee that it does not do anything stupid :-) Some drivers (radeonfb and i810fb for example) are already doing this in their suspend method and it seems to work. That said, it should long-term be fixed in the kernel properly, but if we can prove from userspace that it helps some machines, then we know that it is worth the trouble. > > Echoing "1" into the state file simply makes the text console "freeze" (but > > apparently it is still doing stuff in the background, you can still output > > text etc, you just won't see it). Echoing "0" will make it paint the current > > screen contents. At least that was what happened in my experiments. > > > > > (2) it fixes at least one box that currently doesn't work > > > > Yes, the user in the bugreport is a happy camper now :-) (he does not have > > the s2ram code right now, but uses the script equivalent, but unless i have > > put a bug into the C code, it should be equivalent). > > Can you ask the user to test s2ram with your patch, please? yes, i will do that once i have built and pushed a package. -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) |
|
From: Stefan S. <se...@su...> - 2007-07-30 07:56:40
|
On Sat, Jul 28, 2007 at 08:24:56PM +0200, Manuel Bernhardt wrote: > Stefan Seyfried schrieb: > >> please whitelist following board: > >> > >> sys_vendor = "System manufacturer" > >> sys_product = "System Product Name" > >> sys_version = "System Version" > >> bios_version = "ASUS M2N32-SLI DELUXE ACPI BIOS Revision 1201" > >> > >> and > >> > >> sys_vendor = "System manufacturer" > >> sys_product = "System Product Name" > >> sys_version = "System Version" > >> bios_version = "ASUS M2N32-SLI DELUXE ACPI BIOS Revision 1101" > >> > >> Option: -f -s -p > >> > >> I'd tested both bios versions and both works for me. > >> > > Does it also work with "-f -p -m"? > > > I test it and it looks like it works. I suspend my pc 2 times and 2 > times it resumes successfully but this parameters was only tested with 1201! Ok. Judging from experience, i don't expect the board's BIOS to make a huge difference here. Added to the list. -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) |
|
From: Stefan S. <se...@su...> - 2007-07-30 07:56:35
|
On Sat, Jul 28, 2007 at 01:30:29AM +0800, Kanru Chen wrote: > On Fri, Jul 27, 2007 at 06:16:55PM +0200, Stefan Seyfried wrote: > > I'd guess that you get more luck from the console with > > s2ram -f -a3 > > or > > s2ram -f -p -m > > > > if this does not help, reading http://en.opensuse.org/S2ram might :-) > > > > Thanks for testing! > > s2ram -f -a3 does bring the screen back. Ok, i added this one to the whitelist. > s2ram -f -p -m gets a segmentfault after resume. That's interesting and would be worth investigating, since it should not happen... -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) |
|
From: Stefan S. <se...@su...> - 2007-07-30 07:56:29
|
On Fri, Jul 27, 2007 at 07:24:31PM +0300, Alon Bar-Lev wrote: > On 7/27/07, Stefan Seyfried <se...@su...> wrote: > > But i am not the one to decide this, as i am only maintaining a small piece > > of the code (mainly the whitelist). > > Why do you forward people to suse URLs on whitelist? > I would have expected all be forwarded to suspend.sf.net... > http://en.opensuse.org/S2ram belongs to the project site... not > distribution specific site. Ok, so i'm going to take that one personally now. :-) The documentation was put onto en.opensuse.org (a community site, not really a suse URL) because: a) it was available without any effort from my site b) it is easy (for me) to keep it up to date c) users can contribute Point b) is really important, since this is documentation after all and as you surely know, nobody likes doing documentation. Even more so if the handling has considerable overhead (and yes, a user telling me "I did not find the information" and me being able to immediately fix it is a big plus). Point c) seems to be not as important, probably because the documentation just works well for almost everyone except you. Until now, nobody but you ever complained about the quality of s2ram documentation on that site. I had reports of users of all kinds of distributions, from debian to Pardus, and every one of these users was pleased with the documentation on that site. I don't think (but i may be blind, of course, or some hooligans might have vandalized the wiki recently) that there is any SUSE-specific information on that site (other than where to get up-to-date suse packages, and this information is there for all distributions where i knew it). You can go through the changelog and you will find out, that i most of the time only changed stuff to add new features which were implemented or to shuffle around the content a bit when we found that users obviously had problems finding information. So please tell me what you don't like about the _content_ of the documentation, and i'll try to fix it. So far it seems the only thing that you don't like is that there is the string "suse" in the URL. I'll even go further: if you provide me with "vendor neutral" webspace where i can maintain that page as easily as on the opensuse wiki, then i'll seriously consider moving the page there. Note that i'd want that URL not to change every year (something i of course also cannot guarantee with the opensuse URL, but i'm pretty sure that it won't change soon). So come on, show me the facts. -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) |
|
From: Stefan S. <se...@su...> - 2007-07-30 07:56:21
|
On Fri, Jul 27, 2007 at 07:38:52PM +0200, Pavel Machek wrote: > If the needed quirks differ between otherwise identical i386 and > x86-64 installation, I'd like to know. That means there's serious > problem somewhere. Well, the '-a' quirks not working on x86_64 - that does not surprise me at all. IIUC, it is somehow surprising that they work on i386 at all, because of 16bit BIOS code <--> 32bit mode kernel, isn't it? And vbetool stuff workin in one arch but not another might be due to LRMI (i386) vs x86emu (x86_64). Some people (Steffen Winterfeldt) told me to always use x86emu, even on i386, but Matthew some time ago suggested that there still might be problems in x86emu and that LRMI might work better. So if we really have a machine where x86_64 works with vbetool, and i386 does not, switching i386 to x86emu would be an option to test, unfortunately the other way round is not an option on x86_64 :-( (removed Hendrik-Jan from Cc, since he's probably not too interested in our techno-babble ;-) -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) |
|
From: Stefan S. <se...@su...> - 2007-07-30 07:56:17
|
On Sun, Jul 29, 2007 at 10:54:01PM +0200, Hendrik-Jan Heins wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello Pavel, list, > > Today I did some extensive testing with both i386 and amd64 in the X61s. > The results are somewhat surprising (yes, to me too). > First: I currently use BIOS version 1.06 (the newest Lenovo currently > offers). When I started testing, and when I sent you the first e-mail, I > used version 1.01. With that version other settings were needed for suspend. > > Currently I think for amd64 "s2ram -f -m" works best. "s2ram -f -a1" > also seems to work. You could try "s2ram -f -a1 -m", which would be somewhat consistent with what i saw working on other 64bit thinkpads. > For i386 the situation is a bit more complicated; as I said, I have > issues with getting the backlight back on after suspend. Basically this > problem exists with all parameters I tested. "s2ram -f -m" which works > for amd64, doesn't seem to work for i386 (no backlight). > "s2ram -f -a1" seems to yield the best results. So far I've had it back > from suspend in all cases (9 tries). > > Over all "s2ram -f -a1" seems to be the one that "always" works. > Ah yes, I'm currently using kernel 2.6.22.1 > > If you need me to do more testing, please tell me. If you could do some cycles with "-a 1 -m" on both i386 and x86_64, this would be great. Thanks for your efforts, it is really appreciated Stefan -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) |
|
From: Stefan S. <se...@su...> - 2007-07-30 07:56:09
|
On Fri, Jul 27, 2007 at 07:41:27PM +0200, Pavel Machek wrote: > Hmm, yes, I guess I want to now. So you have thinkpad that is broken > with -a1 -m, in 64-bit mode only? And no other differences? (Like, > same kernel framebuffer driver, both time from console?) I have a thinkpad on my desk (T61 with intel graphics) that is broken with "-a 3" in 64bit mode only (works in 32bit mode). It does, however, work with "-a 1 -m" in both modes. Everything else is pretty much the same. Oh - and "-p -m" does not work in both modes. -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) |
|
From: Stefan S. <se...@su...> - 2007-07-30 07:56:06
|
On Mon, Jul 30, 2007 at 03:31:43AM +0000, Joe Nahmias wrote: > On Tue, Jul 17, 2007 at 05:00:42PM +0200, Stefan Seyfried wrote: > > But "-a3" works, too? Then i'd take that one, since most thinkpads > > work well with "-a 3" and i'd like to avoid too many special cases. > > Yes, -a3 works as well. Verified both in console and X. > > Thanks, Thanks for confirming, added to the whitelist. -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) |
|
From: Stefan S. <se...@su...> - 2007-07-30 07:55:59
|
On Sat, Jul 28, 2007 at 12:20:00AM +0200, maestro wrote: > Hello Stefan! > > well that does not sound that good :-( unfortunately :-( > one thing that i noticed when resuming on 2.6.18-1 (debian) kernel is > that i can ping the resumed machine just fine and nmap returns the same > open ports as before suspend - but i'm not able to connect to the > running sshd on the resumed machine This sounds like the kernel got started again, but somehow userspace is defective (a broken disk driver could cause this). You could try to connect via ssh before suspend, start "top", and then suspend. If "top" keeps running after resume, this would point in the disk driver direction. > another thing that i just tried comes from Suspend and hibernation > status report [0]. it says that they introduced some "debug" mechanism > that makes the kernel beep after control is handed back to the kernel > during resume (search for r= in that article). - well just compiled > 2.6.23-rc1 executed that command s2ram'ed the machine - "resumed" it and > it did NOT beep. does that help in any way? Note that, until you have a very recently checked out CVS version of s2ram, you need to suspend the machine with "echo mem > /sys/power/state", since old s2ram versions did not know about the beeping flags and might reset them to 0 during suspend. OTOH they should only do this if you give a "-a" option to s2ram... > cheers and thanks again I'll try to get hold of a similar machine this week, but since i'll be off on vacation starting from thursday, i cannot promise that this will happen soon :-( > [0] http://lwn.net/Articles/243404/ Good luck :-) Stefan -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) |
16192 messages has been excluded from this view by a project administrator.