[Suspend-devel] suspend to ram on HP/Compaq tc4200
Hi, I finally got suspend-to-ram working on my Hewlett-Packard/Compaq tc4200. I basically only had a distribution problem (Ubuntu Feisty), but s2ram seems not to work without -f (I'm using it with powersaved). So maybe these informations are helpful for you to include support for the tc4200 by default. s2ram --test says the following: Machine is unknown. This machine can be identified by: sys_vendor = "Hewlett-Packard" sys_product = "HP Compaq tc4200 (PV984AW#ABD) " sys_version = "F.0D" bios_version = "68DTH Ver. F.0D" I'm quite sure that the bios version is important, but I can't say which versions exactly work. This one (Sep. 2006) works for sure; before the upgrade I had problems, but I can't say for sure if that was a BIOS problem. The version of the uswsusp package in which s2ram is packaged on Ubuntu is 0.3~cvs20060928-6ubuntu3 (sounds quite old ...). Hope this helps you. If you have any questions, just drop me a mail. Cheers, Frank -- Frank <[EMAIL PROTECTED]> Use GnuPG! GPG key: http://kluenter.de/frank.asc pgpXKNkThSOHR.pgp Description: PGP signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Suspend-devel mailing list Suspend-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/suspend-devel
Re: [Suspend-devel] s2ram settings for HP Pavilion zt3300 and Opensuse 10.1
2006/8/28, Stefan Seyfried <[EMAIL PROTECTED]>: > Hi, > > i took the suspend-devel mailinglist into Cc: > > On Wed, Aug 16, 2006 at 12:01:54AM +0200, Frank Schröder wrote: > > Hi, > > > > thanks for the great howto on the opensuse.org website. After playing > > with it for a while I got Suspend to RAM working on my HP Pavilion > > zt3380us which has an ATI Radeon 9200 Mobile graphics chip. > > > > Here's the output of "s2ram -i" > > > > This machine can be identified by: > >sys_vendor = "Hewlett-Packard " > >sys_product = "Pavilion zt3300 (PF083UA#ABA) " > >sys_version = "F.42" > >bios_version = "68BAL Ver. F.42" > > > > and > > > >s2ram -f > > > > works just fine even from X. I've set > > Cool. Does it also work without X, e.g. from init=/bin/bash? Yes it does :) > > > SUSPEND2RAM_FORCE="yes" > > > > and that's it. > > > > Hope that helps. > > > > On a related note I've been trying to get the ATI chip to work with > > the fglrx driver to have a look at Xgl but the driver doesn't seem to > > be able to find the correct modelines for the 1200x800 display. The > > HCL page claims that it works but Sax2 can't come up with a working > > config. The screen is always garbled. Updating the driver also didn't > > help. Any idea? > > Sorry, i have absolutely no knowledge about the ATI drivers, but filing > a bug in the novell bugzilla will connect you directly to the experts :-) OK, will do. -- Frank Schröder - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Suspend-devel mailing list Suspend-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/suspend-devel
[Suspend-devel] Machine not booting - How to bypass resume?
Hello, I just installed uswsusp and it seemed to work. I configured it to compress and encrypt the image, I chose to use RSA key. After suspending and rebooting the machine I am prompted for a passphrase. The one I supplied for RSA key generation doesn't match (of course) so something did not seem to work out with the RSA decryption I guess so I seem to be asked for the passphrase which is used if no RSA key is configured. The console output is this: ... Begin: Mounting root filesystem... ... Begin: Running /scripts/local-top ... Done. Begin Running /scripts/local-premount ... kinit: name_to_dev_t(/dev/hda5) = hda5(3,5) kinit: trying to resume from /dev/hda5 Attempting manual resume kinit: no resume image, doing normal boot resume: libgcrypt version: 1.2.3 resume: Compressed image resume: Encrypted image Passphrase please (must be non-empty): Two questions arises from now: The most important is to get the system booting again, so what do I have to change (when I have it booted from a live CD) to bypass the resume to have a normal boot process? And what could have went wrong in general? The machine is a Samsung X11Pro, Debian 4.0, Kernel 2.6.18.3, uswsusp 0.3~cvs20060928-6 Thanks you for help! Frank. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Suspend-devel mailing list Suspend-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/suspend-devel
Re: [Suspend-devel] Machine not booting - How to bypass resume?
Pavel Machek schrieb: > Hi! > >> I just installed uswsusp and it seemed to work. I configured it to >> compress and encrypt the image, I chose to use RSA key. >> After suspending and rebooting the machine I am prompted for a >> passphrase. The one I supplied for RSA key generation doesn't match (of >> course) so something did not seem to work out with the RSA decryption I >> guess so I seem to be asked for the passphrase which is used if no RSA >> key is configured. >> >> The console output is this: >> >> ... >> Begin: Mounting root filesystem... ... >> Begin: Running /scripts/local-top ... >> Done. >> Begin Running /scripts/local-premount ... >> kinit: name_to_dev_t(/dev/hda5) = hda5(3,5) >> kinit: trying to resume from /dev/hda5 >> Attempting manual resume >> kinit: no resume image, doing normal boot >> resume: libgcrypt version: 1.2.3 >> resume: Compressed image >> resume: Encrypted image >> Passphrase please (must be non-empty): >> >> >> Two questions arises from now: >> The most important is to get the system booting again, so what do I have >> to change (when I have it booted from a live CD) to bypass the resume to >> have a normal boot process? >> And what could have went wrong in general? >> >> The machine is a Samsung X11Pro, Debian 4.0, Kernel 2.6.18.3, uswsusp >> 0.3~cvs20060928-6 > > Did you try mkswap /dev/hda5? That should kill the image and let it > boot... > Pavel Thanks. That works. I'm back to life... Frank. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Suspend-devel mailing list Suspend-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/suspend-devel
Re: [Suspend-devel] Machine not booting - How to bypass resume?
Rafael J. Wysocki schrieb: > Hi, > > On Wednesday, 3 January 2007 00:51, Frank Hempel wrote: >> Hello, >> >> I just installed uswsusp and it seemed to work. > > Which version? uswsusp 0.3~cvs20060928-6 > >> I configured it to compress and encrypt the image, I chose to use RSA key. > > Does it work with compression alone and with compression+encryption > without the RSA? it worked (suspend+resume) with compression alone. I'm not sure how can I disable RSA and have a passphrase instead, because where do I have to put the passphrase? > >> After suspending and rebooting the machine I am prompted for a >> passphrase. The one I supplied for RSA key generation doesn't match (of >> course) so something did not seem to work out with the RSA decryption I >> guess so I seem to be asked for the passphrase which is used if no RSA >> key is configured. >> >> The console output is this: >> >> ... >> Begin: Mounting root filesystem... ... >> Begin: Running /scripts/local-top ... >> Done. >> Begin Running /scripts/local-premount ... >> kinit: name_to_dev_t(/dev/hda5) = hda5(3,5) >> kinit: trying to resume from /dev/hda5 >> Attempting manual resume >> kinit: no resume image, doing normal boot >> resume: libgcrypt version: 1.2.3 >> resume: Compressed image >> resume: Encrypted image >> Passphrase please (must be non-empty): > > Hm. What's in your suspend.conf? #cat suspend.conf snapshot_device = /dev/snapshot resume_device = #cat uswsusp.conf resume_device = /dev/hda5 compress = y image size = 1e+09 RSA key file = /etc/uswsusp.key > >> Two questions arises from now: >> The most important is to get the system booting again, so what do I have >> to change (when I have it booted from a live CD) to bypass the resume to >> have a normal boot process? > > mkswap your_swap_partition yes, that worked. Thanks for your help... Frank. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Suspend-devel mailing list Suspend-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/suspend-devel
Re: [Suspend-devel] Machine not booting - How to bypass resume?
Rafael J. Wysocki schrieb: > Hi, > [...] >>>> >>>> The console output is this: >>>> >>>> ... >>>> Begin: Mounting root filesystem... ... >>>> Begin: Running /scripts/local-top ... >>>> Done. >>>> Begin Running /scripts/local-premount ... >>>> kinit: name_to_dev_t(/dev/hda5) = hda5(3,5) >>>> kinit: trying to resume from /dev/hda5 >>>> Attempting manual resume >>>> kinit: no resume image, doing normal boot >>>> resume: libgcrypt version: 1.2.3 >>>> resume: Compressed image >>>> resume: Encrypted image >>>> Passphrase please (must be non-empty): >>> Hm. What's in your suspend.conf? >> #cat suspend.conf >> snapshot_device = /dev/snapshot >> resume_device = >> >> #cat uswsusp.conf >> resume_device = /dev/hda5 >> compress = y >> image size = 1e+09 > > I'm not sure if that's decoded correctly (though I don't think it matters > anyway). > >> RSA key file = /etc/uswsusp.key > > Can you try to use "encrypt = yes" explicitly here? then I have the situation again I originally posted. I'm getting asked for a passphrase. Another thing: do you know whether it is possible to integrate the 915resolution patch into the resume operation (I have not found something via google yet)? Because the machine is an Intel based one which needs to have 915resolution started at every startup to have the correct video modes available. When I resume from disk 915resolution is not called so I have to do it manually afterwards. Thanks, Ciao, Frank. > > Greetings, > Rafael > > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Suspend-devel mailing list Suspend-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/suspend-devel
Re: [Suspend-devel] suspend to RAM on lifebook 7110
Hi,
On Wednesday 03 January 2007 20:31, Miroslav Ruda wrote:
> ..
> It's patched version from suspend-0.50-6 (rpm on OpenSuse 10.2). I
> have attached patched s2ram.c too.
>
> Best regards
>
> Mirek Ruda
thanks a lot for your testing.
I now have a new version of the patch that should fix the problem.
Have fun,
Frank
---
s2ram.c | 78 +---
1 file changed, 75 insertions(+), 3 deletions(-)
Index: s2ram.c
===
--- s2ram.c
+++ s2ram.c
@@ -11,12 +11,17 @@
#include
#include
+#include
+
#define S2RAM
#include "vbetool/vbetool.h"
#include "vt.h"
#include "s2ram.h"
static void *vbe_buffer;
+unsigned char vga_pci_state[256];
+static struct pci_dev *vga_dev = NULL;
+static struct pci_access *pacc = NULL;
/* Flags set from whitelist */
static int flags, vbe_mode = -1;
char bios_version[1024], sys_vendor[1024], sys_product[1024], sys_version[1024];
@@ -36,6 +41,7 @@ char bios_version[1024], sys_vendor[1024
#define UNSURE 0x20 /* unverified entries from acpi-support 0.59 */
#define NOFB0x40 /* must not use a frame buffer */
#define VBE_MODE0x80 /* machine needs "vbetool vbemode get / set" */
+#define PCI_SAVE 0x100 /* we need to save the VGA PCI registers */
#include "whitelist.c"
@@ -67,14 +73,15 @@ void machine_known(int i)
"bios_version = '%s'\n", i,
whitelist[i].sys_vendor, whitelist[i].sys_product,
whitelist[i].sys_version, whitelist[i].bios_version);
- printf("Fixes: 0x%x %s%s%s%s%s%s%s\n", flags,
+ printf("Fixes: 0x%x %s%s%s%s%s%s%s%s\n", flags,
(flags & VBE_SAVE) ? "VBE_SAVE " : "",
(flags & VBE_POST) ? "VBE_POST " : "",
(flags & VBE_MODE) ? "VBE_MODE " : "",
(flags & RADEON_OFF) ? "RADEON_OFF " : "",
(flags & S3_BIOS) ? "S3_BIOS " : "",
(flags & S3_MODE) ? "S3_MODE " : "",
- (flags & NOFB) ? "NOFB " : "");
+ (flags & NOFB) ? "NOFB " : "",
+ (flags & PCI_SAVE) ? "PCI_SAVE " : "");
if (flags & UNSURE)
printf("Machine is in the whitelist but perhaps using "
"vbetool unnecessarily.\n"
@@ -143,6 +150,43 @@ int s2ram_check(int id)
return ret;
}
+struct pci_dev *find_vga(void)
+{
+ struct pci_dev *dev;
+ struct pci_dev *result;
+
+ pci_scan_bus(pacc); /* We want to get the list of devices */
+
+ for (dev=pacc->devices; dev; dev=dev->next) {
+ pci_fill_info(dev, PCI_FILL_IDENT | PCI_FILL_CLASS);
+ if (dev->device_class == 0x300)
+ break;
+ }
+
+if (!dev)
+result = NULL;
+else {
+ /* save result */
+ result = malloc(sizeof(*dev));
+ if (result) {
+ memcpy(result, dev, sizeof(*dev));
+ result->next = NULL;
+ }
+}
+
+ return result;
+}
+
+void save_vga_pci(struct pci_dev *dev)
+{
+ pci_read_block(dev, 0, vga_pci_state, 256);
+}
+
+void restore_vga_pci(struct pci_dev *dev)
+{
+ pci_write_block(dev, 0, vga_pci_state, 256);
+}
+
/* warning: we have to be on a text console when calling this */
int s2ram_hacks(void)
{
@@ -171,6 +215,17 @@ int s2ram_hacks(void)
printf("Calling radeon_cmd_light(0)\n");
radeon_cmd_light(0);
}
+ if (flags & PCI_SAVE) {
+ pacc = pci_alloc(); /* Get the pci_access structure */
+ pci_init(pacc); /* Initialize the PCI library */
+
+ vga_dev = find_vga();
+ if (vga_dev) {
+ printf("saving PCI config of device %02x:%02x.%d\n",
+vga_dev->bus, vga_dev->dev, vga_dev->func);
+ save_vga_pci(vga_dev);
+ }
+ }
return 0;
}
@@ -216,6 +271,13 @@ int s2ram_do(void)
void s2ram_resume(void)
{
+ if ((flags & PCI_SAVE) && vga_dev) {
+ printf("restoring PCI config of device %02x:%02x.%d\n",
+ vga_dev->bus, vga_dev->dev, vga_dev->func);
+ restore_vga_pci(vga_dev);
+
+ pci_cleanup(pacc);
+ }
// FIXME: can we call vbetool_init() multiple times without cleaning up?
if (flags & VBE_POST) {
vbetool_init();
@@ -260,6 +322,7 @@ static void usage(void)
"-a, --acpi_sleep: set the acpi_sleep parameter before "
"suspend\n"
" 1=s3_bios, 2=s3_mode, 3=both\n"
+ "-v, --pci_save: save the PCI config space for the VGA card.\n"
"\n");
exit(1);
}
@@ -278,10 +341,11 @@ int main(int argc, char *argv[])
{ "radeontool", no_argument, NULL, 'r'},
{ "identify", no_argument, NULL, 'i'},
{ "acpi_sle
Re: [Suspend-devel] pci save state patch
Hi!
On Wednesday 10 January 2007 10:39, Pavel Machek wrote:
> Well, Frank was wrong here for subtle reason, and I did not like it:
>
> If malloc failed (basically can not happen, but...) he'd suspend,
> anyway, failing to restore PCI config at the exit, and bringing video
> corruption back to us... Without knowing that pci save state failed.
You are absolutly right, this wan't that nice. But it still could happen,
that find_vga returns NULL (eventhoug of course this is now very unlikely)
and furthermore we now have a second global variable for
the same thing (global static pointer to global static struct).
So, i did a further cleanup to this patch. This version has only one global
struct for the vga_dev and terminates execution if vga_dev
couldn't be found.
Have fun, :)
Frank
Index: s2ram.c
===
--- s2ram.c
+++ s2ram.c
@@ -11,12 +11,17 @@
#include
#include
+#include
+
#define S2RAM
#include "vbetool/vbetool.h"
#include "vt.h"
#include "s2ram.h"
static void *vbe_buffer;
+unsigned char vga_pci_state[256];
+static struct pci_dev vga_dev;
+static struct pci_access *pacc = NULL;
/* Flags set from whitelist */
static int flags, vbe_mode = -1;
char bios_version[1024], sys_vendor[1024], sys_product[1024],
sys_version[1024];
@@ -36,6 +41,7 @@ char bios_version[1024], sys_vendor[1024
#define UNSURE 0x20 /* unverified entries from acpi-support 0.59 */
#define NOFB0x40 /* must not use a frame buffer */
#define VBE_MODE0x80 /* machine needs "vbetool vbemode get / set" */
+#define PCI_SAVE 0x100 /* we need to save the VGA PCI registers */
#include "whitelist.c"
@@ -67,14 +73,15 @@ void machine_known(int i)
"bios_version = '%s'\n", i,
whitelist[i].sys_vendor, whitelist[i].sys_product,
whitelist[i].sys_version, whitelist[i].bios_version);
- printf("Fixes: 0x%x %s%s%s%s%s%s%s\n", flags,
+ printf("Fixes: 0x%x %s%s%s%s%s%s%s%s\n", flags,
(flags & VBE_SAVE) ? "VBE_SAVE " : "",
(flags & VBE_POST) ? "VBE_POST " : "",
(flags & VBE_MODE) ? "VBE_MODE " : "",
(flags & RADEON_OFF) ? "RADEON_OFF " : "",
(flags & S3_BIOS) ? "S3_BIOS " : "",
(flags & S3_MODE) ? "S3_MODE " : "",
- (flags & NOFB) ? "NOFB " : "");
+ (flags & NOFB) ? "NOFB " : "",
+ (flags & PCI_SAVE) ? "PCI_SAVE " : "");
if (flags & UNSURE)
printf("Machine is in the whitelist but perhaps using "
"vbetool unnecessarily.\n"
@@ -143,6 +150,37 @@ int s2ram_check(int id)
return ret;
}
+int find_vga(void)
+{
+ struct pci_dev *dev;
+
+ pci_scan_bus(pacc); /* We want to get the list of devices */
+
+ for (dev=pacc->devices; dev; dev=dev->next) {
+ pci_fill_info(dev, PCI_FILL_IDENT | PCI_FILL_CLASS);
+ if (dev->device_class == 0x300)
+ break;
+ }
+
+if (!dev)
+return 1;
+
+ memcpy(&vga_dev, dev, sizeof(*dev));
+ vga_dev.next = NULL;
+
+ return 0;
+}
+
+void save_vga_pci(void)
+{
+ pci_read_block(&vga_dev, 0, vga_pci_state, 256);
+}
+
+void restore_vga_pci(void)
+{
+ pci_write_block(&vga_dev, 0, vga_pci_state, 256);
+}
+
/* warning: we have to be on a text console when calling this */
int s2ram_hacks(void)
{
@@ -171,6 +209,17 @@ int s2ram_hacks(void)
printf("Calling radeon_cmd_light(0)\n");
radeon_cmd_light(0);
}
+ if (flags & PCI_SAVE) {
+ pacc = pci_alloc(); /* Get the pci_access structure */
+ pci_init(pacc); /* Initialize the PCI library */
+
+ if (find_vga() == 0) {
+ printf("saving PCI config of device %02x:%02x.%d\n",
+ vga_dev.bus, vga_dev.dev, vga_dev.func);
+ save_vga_pci();
+ } else
+ return 1;
+ }
return 0;
}
@@ -216,6 +265,13 @@ int s2ram_do(void)
void s2ram_resume(void)
{
+ if ((flags & PCI_SAVE) && vga_dev.device_class == 0x300) {
+ printf("restoring PCI config of device %02x:%02x.%d\n",
+ vga_dev.bus, vga_dev.dev, vga_dev.func);
+ restore_vga_pci();
+
+ pci_cleanup(pacc);
+ }
// FIXME: can we call vbetool_init(
[Suspend-devel] IBM (Lenovo) Z61m
Hello, i got a Z61m with ATi X1400 and 1680x1050 display. Due to this i have ti use the closed source fglrx driver to get X with the native display resolution. This is what "s2ram -i" (Version 0.5) emits: --- cut -- This machine can be identified by: sys_vendor = "LENOVO" sys_product = "9450HAG" sys_version = "ThinkPad Z61m" bios_version = "7FET96WW (2.14 )" See http://en.opensuse.org/S2ram for details. If you report a problem, please include the complete output above. --- cut -- In text mode (framebuffer vesafb) suspend works using the vbe options (see table below). However in graphical mode it seems to restore well, but when switching to vt7 (the X display) the display goes black and thats it. None of the s2ram option goes to work. Here is the table of options (use fixed font !): Option | works in text mode ? | works in X +--+ -a 1| no | no -a 2| no | no -a 3| no | no -p -m | yes | no -p -s | yes | no -m | yes, partially | no -s | yes | no -p | no | no -a 1 -m | yes | no -a 1 -s | yes | no It seems that the fglrx driver has a problem at suspending. This also applies when suspending to disk using hibernate (version 1.94 from www.suspend2.net). So - are there any hints for me to get it working under X. Using vesa is not an option. I want to get the native resolution. Installed ATi fglrx has the version 8.35.5. regards Petric - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Suspend-devel mailing list Suspend-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/suspend-devel
Re: [Suspend-devel] IBM (Lenovo) Z61m
Hello, an update to my own post. On Saturday 19 May 2007 13:10, Petric Frank wrote: > Hello, > > i got a Z61m with ATi X1400 and 1680x1050 display. Due to this i have ti > use the closed source fglrx driver to get X with the native display > resolution. > > This is what "s2ram -i" (Version 0.5) emits: > --- cut -- > This machine can be identified by: > sys_vendor = "LENOVO" > sys_product = "9450HAG" > sys_version = "ThinkPad Z61m" > bios_version = "7FET96WW (2.14 )" Upgraded BIOS. Now bios_version = "7FET99WW (2.17 )" > --- cut -- Suspend to RAM works when in VGA mode (not framebuffer) using the command s2ram -f -a 1 (s2ram -f alone was not successful) > Installed ATi fglrx has the version 8.35.5. It works under X also using the options above. So you can enable this Notebook in the next releases of the suspend package. For others struggling to get it working on a Z61m - kernel modules tg3, pcmcia (locks yenta_socket) and yenta_socket must be unloaded before suspend. yenta_socket seem not to release the interrupt line when suspending. As result the according interrupt will be disabled when resuming. tg3 lost the network somehow after resume. Unloading it before and loading after resume cures the problem. The kernel in use is 2.6.20. regards Petric - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Suspend-devel mailing list Suspend-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/suspend-devel
Re: [Suspend-devel] [PATCH, 3rd try] make disable_console_suspend runtime configurable
From: Stefan Seyfried <[EMAIL PROTECTED]>
I hate having to recompile the kernel, just to be able to debug suspend.
Remove CONFIG_DISABLE_CONSOLE_SUSPEND, replace it by a tunable in
/sys/power/disable_console_suspend.
Signed-off-by: Stefan Seyfried <[EMAIL PROTECTED]>
Signed-off-by: Frank Seidel <[EMAIL PROTECTED]>
---
Third try, renamed sysfs interface to console_suspend
reporting and expecting either "enabled" or "disabled"
Documentation/power/basic-pm-debugging.txt | 16 +---
drivers/serial/serial_core.c |8 ++--
include/linux/console.h|7 ++-
kernel/power/Kconfig | 11 ---
kernel/power/main.c| 28
kernel/printk.c|7 +--
6 files changed, 46 insertions(+), 31 deletions(-)
--- a/Documentation/power/basic-pm-debugging.txt
+++ b/Documentation/power/basic-pm-debugging.txt
@@ -78,13 +78,15 @@ c) Advanced debugging
In case the STD does not work on your system even in the minimal configuration
and compiling more drivers as modules is not practical or some modules cannot
be unloaded, you can use one of the more advanced debugging techniques to find
-the problem. First, if there is a serial port in your box, you can set the
-CONFIG_DISABLE_CONSOLE_SUSPEND kernel configuration option and try to log
kernel
-messages using the serial console. This may provide you with some information
-about the reasons of the suspend (resume) failure. Alternatively, it may be
-possible to use a FireWire port for debugging with firescope
-(ftp://ftp.firstfloor.org/pub/ak/firescope/). On i386 it is also possible to
-use the PM_TRACE mechanism documented in Documentation/s2ram.txt .
+the problem. First, if there is a serial port in your box, you can
+
+# echo disabled > /sys/power/console_suspend
+
+and try to log kernel messages using the serial console. This may provide you
+with some information about the reasons of the suspend (resume) failure.
+Alternatively, it may be possible to use a FireWire port for debugging with
+firescope (ftp://ftp.firstfloor.org/pub/ak/firescope/). On i386 it is also
+possible to use the PM_TRACE mechanism documented in Documentation/s2ram.txt .
2. Testing suspend to RAM (STR)
--- a/drivers/serial/serial_core.c
+++ b/drivers/serial/serial_core.c
@@ -1934,12 +1934,10 @@ int uart_suspend_port(struct uart_driver
mutex_lock(&state->mutex);
-#ifdef CONFIG_DISABLE_CONSOLE_SUSPEND
- if (uart_console(port)) {
+ if (disable_console_suspend && uart_console(port)) {
mutex_unlock(&state->mutex);
return 0;
}
-#endif
if (state->info && state->info->flags & UIF_INITIALIZED) {
const struct uart_ops *ops = port->ops;
@@ -1982,12 +1980,10 @@ int uart_resume_port(struct uart_driver
mutex_lock(&state->mutex);
-#ifdef CONFIG_DISABLE_CONSOLE_SUSPEND
- if (uart_console(port)) {
+ if (disable_console_suspend && uart_console(port)) {
mutex_unlock(&state->mutex);
return 0;
}
-#endif
uart_change_pm(state, 0);
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -64,6 +64,8 @@ extern const struct consw vga_con;/* VG
extern const struct consw newport_con; /* SGI Newport console */
extern const struct consw prom_con;/* SPARC PROM console */
+extern int disable_console_suspend;
+
int con_is_bound(const struct consw *csw);
int register_con_driver(const struct consw *csw, int first, int last);
int unregister_con_driver(const struct consw *csw);
@@ -120,14 +122,9 @@ extern void console_stop(struct console
extern void console_start(struct console *);
extern int is_console_locked(void);
-#ifndef CONFIG_DISABLE_CONSOLE_SUSPEND
/* Suspend and resume console messages over PM events */
extern void suspend_console(void);
extern void resume_console(void);
-#else
-static inline void suspend_console(void) {}
-static inline void resume_console(void) {}
-#endif /* CONFIG_DISABLE_CONSOLE_SUSPEND */
int mda_console_init(void);
void prom_con_init(void);
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -37,17 +37,6 @@ config PM_DEBUG
code. This is helpful when debugging and reporting various PM bugs,
like suspend support.
-config DISABLE_CONSOLE_SUSPEND
- bool "Keep console(s) enabled during suspend/resume (DANGEROUS)"
- depends on PM && PM_DEBUG
- default n
- ---help---
- This option turns off the console suspend mechanism that prevents
- debug messages from reaching the console during the suspend/resume
- operations. This may be helpful when debugging device drivers'
- suspend/resume routines, but may itself lead to problems, for exa
Re: [Suspend-devel] [PATCH3/6] - autoconf/automake glue - cflags
Hi, On Friday 03 August 2007 01:13:56 Alon Bar-Lev wrote: > Can anyone please explain this usage? > These flags should seldom be used. Why do you think so? _GNU_SOURCE activates various features like __STRICT_ANSI__, _ISOC99_SOURCE and so forth (see include/features.h). Thanks, Frank - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Suspend-devel mailing list Suspend-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/suspend-devel
Re: [Suspend-devel] [PATCH] print_checksum fixup
On Monday 06 August 2007 00:46:01 Alon Bar-Lev wrote: > On 8/6/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > On Monday, 6 August 2007 00:05, Alon Bar-Lev wrote: > > > > > > Well... It never worked :) > > > > Why exactly do you think so? > > Because you increment buf and return it... This will not work with > printf() as it always be an empty string. ? Sorry, i also cannot see the problem you describe. The way print_checksum worked until now can be found very often (also e.g. inside the kernel) and it works just absolutely fine for me. Incrementing and returning buf (or any other non-constant function parameter, being just a kind of runtime-preset local variable) is nothing wrong, special or abnormal. And why should the sprintf always be/produce an empty string? It will always give you 16 characters (not including the terminating zero). I really appreciate the effort you put into all this, but this special patch is more or less just a artificial pad out. Thanks, Frank - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Suspend-devel mailing list Suspend-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/suspend-devel
Re: [Suspend-devel] [PATCH] print_checksum fixup
On Monday 06 August 2007 10:18:18 Alon Bar-Lev wrote:
> I MUST GOING CRAZY
> PLEASE WAKE ME UP
Hi,
i don't see a reason to get loud here ;-)
(and btw no need to CC me for an answer, i'm reading the list)
It just wasn't clear what you meant (at least to me).
> Here is the original function:
> ..
> Here is the usage:
>
> resume.c::584:
>printf("resume: MD5 checksum %s\n",
> print_checksum(buffer, orig_checksum));
> ...
> Does anybody but me can also tell that the checksum will never be printed?
Ok, so there's a gap between functiondesign and its usage, that's right. I
didn't
look at the correct usage. (The definition of print_cheksum alone didn't show
at all what you were talking about ;-)
> I can explain more if you like... How printf works, how it scans for
> parameters etc...
No need at all, thanks. But - at least to me - it just was not clear at all of
what
printf you were talking about (or to be more precise i thought you meant the
sprintf in print_cheksum).
So theres no reason to talk at this level.
> This problem can be solved using my patch or if you so like this
> kernel programming you can do this without changing the print_checksum
> function
i wouldn't call this kernel programming, but to come back to the topic
again.. yes, this should get fixed. Either by your patch or by fixing the usage.
As the original/current usage of print_checksum is - IMHO - more intuitive, so
i'd actually vote for Alons patch now.
Thanks,
Frank
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel
