RE: TPM driver changes to support multiple locality
-Original Message-
From: Randy Dunlap [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 11, 2007 4:02 PM
To: Agarwal, Lomesh
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: Re: TPM driver changes to support multiple locality
On Thu, 11 Oct 2007 15:46:03 -0700 Agarwal, Lomesh wrote:
> Attached is the patch which resolves all the comments.
Inline patches are preferred so that reviewers can comment on them
more easily.
What mail client are you using?
[Agarwal, Lomesh] I am using MS Outlook. Earlier you said inline patches
have problem because of mail client. That's why I sent it as attachment.
The patch has trailing CRs on each line ("DOS mode").
Just verifying: this TPM device has interrupts per locality?
+ /* check if interrupt is meant for this locality */
+ if (check_locality(chip, locality) < 0)
+ return IRQ_NONE;
~~~~~~~~~
[Agarwal, Lomesh] TPM device has only one interrupt. so on receiving
interrupt driver has to make sure that its meant for its locality.
init_tis() still seems to have some problems.
static int __init init_tis(void)
{
+#define DEVNAME_SIZE 10
+
int rc;
+ if ((locality < 0) || (locality > 4))
+ return PTR_ERR(pdev);
pdev hasn't been set (so it's NULL).
+ pdev = platform_device_register_simple(devname, -1,
NULL, 0);
+ if (IS_ERR(pdev))
return PTR_ERR(pdev);
Error path above needs to call driver_unregister().
[Agarwal, Lomesh] attached is the new patch.
---
~Randy
tpm_tis.c.patch
Description: tpm_tis.c.patch
RE: TPM driver changes to support multiple locality
Attached is the patch which resolves all the comments. tpm_tis.c.patch Description: tpm_tis.c.patch
RE: TPM driver changes to support multiple locality
-Original Message-
From: Arjan van de Ven [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 11, 2007 2:41 PM
To: Agarwal, Lomesh
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: Re: TPM driver changes to support multiple locality
On Thu, 11 Oct 2007 11:33:35 -0700
"Agarwal, Lomesh" <[EMAIL PROTECTED]> wrote:
> Below is the patch for TPM driver.
> Comments/suggestions?
please don't top post
>
> --- pristine-linux-2.6.18/drivers/char/tpm/tpm_tis.c 2006-09-19
> 20:42:06.0 -0700
> +++ linux-2.6.18-xen/drivers/char/tpm/tpm_tis.c 2007-10-09
> 15:30:49.0 -0700
or send word wrapped patches
.. or patches against 2 year old kernels for that matter ;)
> enum tis_defaults {
> TIS_MEM_BASE = 0xFED4,
> - TIS_MEM_LEN = 0x5000,
> + TIS_MEM_LEN = 0x1000,
hmmm/// why
[Agarwal, Lomesh] 0x5000 is the length of CSRs for all the localities.
Each locality's CSR size is 0x1000. so 0x1000 is sufficient and will
catch error if driver tries to write to wrong locality.
-
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: TPM driver changes to support multiple locality
ot;\tData Avail Int Support\n");
- if (request_locality(chip, 0) != 0) {
- rc = -ENODEV;
+ if (request_locality(chip, locality) < 0) {
+ rc = -EBUSY;
+ printk("tpm_tis: failed request_locality %d\n",
locality);
goto out_err;
}
@@ -582,9 +594,11 @@ static int tpm_tis_init(struct device *d
tpm_get_timeouts(chip);
tpm_continue_selftest(chip);
+ release_locality(chip, chip->vendor.locality, 1);
return 0;
out_err:
+ release_locality(chip, chip->vendor.locality, 1);
if (chip->vendor.iobase)
iounmap(chip->vendor.iobase);
tpm_remove_hardware(chip->dev);
@@ -636,7 +650,7 @@ module_param_string(hid, tpm_pnp_tbl[TIS
MODULE_PARM_DESC(hid, "Set additional specific HID for this driver to
probe");
static struct device_driver tis_drv = {
- .name = "tpm_tis",
+ .name = "",
.bus = _bus_type,
.owner = THIS_MODULE,
.suspend = tpm_pm_suspend,
@@ -648,19 +662,34 @@ static struct platform_device *pdev;
static int force;
module_param(force, bool, 0444);
MODULE_PARM_DESC(force, "Force device probe rather than using ACPI
entry");
+
+static char *devname;
+
static int __init init_tis(void)
{
+#define DEVNAME_SIZE 10
+
int rc;
+ if ((locality < 0) || (locality > 4)) {
+ return PTR_ERR(pdev);
+ }
+
if (force) {
+ devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
+ scnprintf(devname, DEVNAME_SIZE, "%s%d", "tpm_tis",
locality);
+
+ tis_drv.name = devname;
rc = driver_register(_drv);
if (rc < 0)
return rc;
- if
(IS_ERR(pdev=platform_device_register_simple("tpm_tis", -1, NULL, 0)))
+
+ if (IS_ERR(pdev=platform_device_register_simple(devname,
-1, NULL, 0)))
return PTR_ERR(pdev);
if((rc=tpm_tis_init(>dev, 0, 0)) != 0) {
platform_device_unregister(pdev);
driver_unregister(_drv);
+ kfree(devname);
}
return rc;
}
@@ -692,7 +721,9 @@ static void __exit cleanup_tis(void)
if (force) {
platform_device_unregister(pdev);
driver_unregister(_drv);
- } else
+ kfree(devname);
+ }
+ else
pnp_unregister_driver(_pnp_driver);
}
I don't have scripts/checkpatch.pl in my linux tree. Where can I get
one?
Devname is being used in 2 functions. That's why it is global. Locality
parameter is initialized with 0 just to be safe. Are all the global
variables in driver is guaranteed to be init 0? Even if it is it doesn't
hurt to init it.
-Original Message-
From: Randy Dunlap [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 11, 2007 11:54 AM
To: Agarwal, Lomesh
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: Re: TPM driver changes to support multiple locality
On Thu, 11 Oct 2007 11:33:35 -0700 Agarwal, Lomesh wrote:
> Below is the patch for TPM driver.
> Comments/suggestions?
Observe/use kernel coding style.
Run the patch thru scripts/checkpatch.pl and check its suggestions.
Use "diffstat -p1 -w70" and put that summary near the top of the
patch (after the patch description).
Use -p option of diff to generate the diff so that reviewers
can see the function name that patch blocks apply to.
Use tabs instead of spaces for indenting.
More below.
> --- pristine-linux-2.6.18/drivers/char/tpm/tpm_tis.c 2006-09-19
> 20:42:06.0 -0700
> +++ linux-2.6.18-xen/drivers/char/tpm/tpm_tis.c 2007-10-09
> 15:30:49.0 -0700
> @@ -56,29 +56,36 @@
>
> enum tis_defaults {
> TIS_MEM_BASE = 0xFED4,
> - TIS_MEM_LEN = 0x5000,
> + TIS_MEM_LEN = 0x1000,
> TIS_SHORT_TIMEOUT = 750,/* ms */
> TIS_LONG_TIMEOUT = 2000,/* 2 sec */
> };
>
> -#define TPM_ACCESS(l) (0x | ((l) << 12))
> -#define TPM_INT_ENABLE(l) (0x0008 | ((l) << 12))
> -#define TPM_INT_VECTOR(l) (0x000C | ((l) << 12))
> -#define TPM_INT_STATUS(l) (0x0010 | ((l) << 12))
> -#define TPM_INTF_CAPS(l)(0x0014 | ((l) << 12))
> -#define TPM_STS(l) (0x0018 | ((l) << 12))
> -#define TPM_DATA_FIFO(l)(0x0024 | ((l) << 12))
> +#define TPM_ACCESS(l) (0x)
> +#define TPM_INT_ENABLE(l) (0x0008)
> +#define TPM_INT_VECTOR(l) (0x000C)
> +#define TPM_INT_STATUS(l) (0x0010)
> +#
RE: TPM driver changes to support multiple locality
release_locality(chip, chip->vendor.locality, 1);
if (chip->vendor.iobase)
iounmap(chip->vendor.iobase);
tpm_remove_hardware(chip->dev);
@@ -636,7 +649,7 @@
MODULE_PARM_DESC(hid, "Set additional specific HID for this driver to
probe");
static struct device_driver tis_drv = {
- .name = "tpm_tis",
+ .name = "",
.bus = _bus_type,
.owner = THIS_MODULE,
.suspend = tpm_pm_suspend,
@@ -648,19 +661,34 @@
static int force;
module_param(force, bool, 0444);
MODULE_PARM_DESC(force, "Force device probe rather than using ACPI
entry");
+
+static char *devname = NULL;
+
static int __init init_tis(void)
{
+#define DEVNAME_SIZE 10
+
int rc;
+ if ((locality < 0) || (locality > 4)) {
+ return PTR_ERR(pdev);
+ }
+
if (force) {
+ devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
+ scnprintf(devname, DEVNAME_SIZE, "%s%d", "tpm_tis",
locality);
+
+ tis_drv.name = devname;
rc = driver_register(_drv);
if (rc < 0)
return rc;
- if
(IS_ERR(pdev=platform_device_register_simple("tpm_tis", -1, NULL, 0)))
+
+ if (IS_ERR(pdev=platform_device_register_simple(devname,
-1, NULL, 0)))
return PTR_ERR(pdev);
if((rc=tpm_tis_init(>dev, 0, 0)) != 0) {
platform_device_unregister(pdev);
driver_unregister(_drv);
+ kfree(devname);
}
return rc;
}
@@ -692,7 +720,9 @@
if (force) {
platform_device_unregister(pdev);
driver_unregister(_drv);
- } else
+ kfree(devname);
+ }
+ else
pnp_unregister_driver(_pnp_driver);
}
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 12:46 PM
To: Agarwal, Lomesh
Cc: linux-kernel@vger.kernel.org
Subject: Re: TPM driver changes to support multiple locality
On Tue, 09 Oct 2007 15:51:11 PDT, "Agarwal, Lomesh" said:
> Current TPM driver supports only locality 0. I am planning to add
> support so that it can access any locality. Locality parameter will be
> passed as parameter. Will this change be acceptable? If yes then I
will
> modify the driver and send the patch.
Make sure you extend the API in such a way that older userspace programs
that don't pass the new locality parameter still work correctly.
-
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: TPM driver changes to support multiple locality
, Set additional specific HID for this driver to
probe);
static struct device_driver tis_drv = {
- .name = tpm_tis,
+ .name = ,
.bus = platform_bus_type,
.owner = THIS_MODULE,
.suspend = tpm_pm_suspend,
@@ -648,19 +661,34 @@
static int force;
module_param(force, bool, 0444);
MODULE_PARM_DESC(force, Force device probe rather than using ACPI
entry);
+
+static char *devname = NULL;
+
static int __init init_tis(void)
{
+#define DEVNAME_SIZE 10
+
int rc;
+ if ((locality 0) || (locality 4)) {
+ return PTR_ERR(pdev);
+ }
+
if (force) {
+ devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
+ scnprintf(devname, DEVNAME_SIZE, %s%d, tpm_tis,
locality);
+
+ tis_drv.name = devname;
rc = driver_register(tis_drv);
if (rc 0)
return rc;
- if
(IS_ERR(pdev=platform_device_register_simple(tpm_tis, -1, NULL, 0)))
+
+ if (IS_ERR(pdev=platform_device_register_simple(devname,
-1, NULL, 0)))
return PTR_ERR(pdev);
if((rc=tpm_tis_init(pdev-dev, 0, 0)) != 0) {
platform_device_unregister(pdev);
driver_unregister(tis_drv);
+ kfree(devname);
}
return rc;
}
@@ -692,7 +720,9 @@
if (force) {
platform_device_unregister(pdev);
driver_unregister(tis_drv);
- } else
+ kfree(devname);
+ }
+ else
pnp_unregister_driver(tis_pnp_driver);
}
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 12:46 PM
To: Agarwal, Lomesh
Cc: linux-kernel@vger.kernel.org
Subject: Re: TPM driver changes to support multiple locality
On Tue, 09 Oct 2007 15:51:11 PDT, Agarwal, Lomesh said:
Current TPM driver supports only locality 0. I am planning to add
support so that it can access any locality. Locality parameter will be
passed as parameter. Will this change be acceptable? If yes then I
will
modify the driver and send the patch.
Make sure you extend the API in such a way that older userspace programs
that don't pass the new locality parameter still work correctly.
-
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: TPM driver changes to support multiple locality
= -EBUSY;
+ printk(tpm_tis: failed request_locality %d\n,
locality);
goto out_err;
}
@@ -582,9 +594,11 @@ static int tpm_tis_init(struct device *d
tpm_get_timeouts(chip);
tpm_continue_selftest(chip);
+ release_locality(chip, chip-vendor.locality, 1);
return 0;
out_err:
+ release_locality(chip, chip-vendor.locality, 1);
if (chip-vendor.iobase)
iounmap(chip-vendor.iobase);
tpm_remove_hardware(chip-dev);
@@ -636,7 +650,7 @@ module_param_string(hid, tpm_pnp_tbl[TIS
MODULE_PARM_DESC(hid, Set additional specific HID for this driver to
probe);
static struct device_driver tis_drv = {
- .name = tpm_tis,
+ .name = ,
.bus = platform_bus_type,
.owner = THIS_MODULE,
.suspend = tpm_pm_suspend,
@@ -648,19 +662,34 @@ static struct platform_device *pdev;
static int force;
module_param(force, bool, 0444);
MODULE_PARM_DESC(force, Force device probe rather than using ACPI
entry);
+
+static char *devname;
+
static int __init init_tis(void)
{
+#define DEVNAME_SIZE 10
+
int rc;
+ if ((locality 0) || (locality 4)) {
+ return PTR_ERR(pdev);
+ }
+
if (force) {
+ devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
+ scnprintf(devname, DEVNAME_SIZE, %s%d, tpm_tis,
locality);
+
+ tis_drv.name = devname;
rc = driver_register(tis_drv);
if (rc 0)
return rc;
- if
(IS_ERR(pdev=platform_device_register_simple(tpm_tis, -1, NULL, 0)))
+
+ if (IS_ERR(pdev=platform_device_register_simple(devname,
-1, NULL, 0)))
return PTR_ERR(pdev);
if((rc=tpm_tis_init(pdev-dev, 0, 0)) != 0) {
platform_device_unregister(pdev);
driver_unregister(tis_drv);
+ kfree(devname);
}
return rc;
}
@@ -692,7 +721,9 @@ static void __exit cleanup_tis(void)
if (force) {
platform_device_unregister(pdev);
driver_unregister(tis_drv);
- } else
+ kfree(devname);
+ }
+ else
pnp_unregister_driver(tis_pnp_driver);
}
I don't have scripts/checkpatch.pl in my linux tree. Where can I get
one?
Devname is being used in 2 functions. That's why it is global. Locality
parameter is initialized with 0 just to be safe. Are all the global
variables in driver is guaranteed to be init 0? Even if it is it doesn't
hurt to init it.
-Original Message-
From: Randy Dunlap [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 11, 2007 11:54 AM
To: Agarwal, Lomesh
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: Re: TPM driver changes to support multiple locality
On Thu, 11 Oct 2007 11:33:35 -0700 Agarwal, Lomesh wrote:
Below is the patch for TPM driver.
Comments/suggestions?
Observe/use kernel coding style.
Run the patch thru scripts/checkpatch.pl and check its suggestions.
Use diffstat -p1 -w70 and put that summary near the top of the
patch (after the patch description).
Use -p option of diff to generate the diff so that reviewers
can see the function name that patch blocks apply to.
Use tabs instead of spaces for indenting.
More below.
--- pristine-linux-2.6.18/drivers/char/tpm/tpm_tis.c 2006-09-19
20:42:06.0 -0700
+++ linux-2.6.18-xen/drivers/char/tpm/tpm_tis.c 2007-10-09
15:30:49.0 -0700
@@ -56,29 +56,36 @@
enum tis_defaults {
TIS_MEM_BASE = 0xFED4,
- TIS_MEM_LEN = 0x5000,
+ TIS_MEM_LEN = 0x1000,
TIS_SHORT_TIMEOUT = 750,/* ms */
TIS_LONG_TIMEOUT = 2000,/* 2 sec */
};
-#define TPM_ACCESS(l) (0x | ((l) 12))
-#define TPM_INT_ENABLE(l) (0x0008 | ((l) 12))
-#define TPM_INT_VECTOR(l) (0x000C | ((l) 12))
-#define TPM_INT_STATUS(l) (0x0010 | ((l) 12))
-#define TPM_INTF_CAPS(l)(0x0014 | ((l) 12))
-#define TPM_STS(l) (0x0018 | ((l) 12))
-#define TPM_DATA_FIFO(l)(0x0024 | ((l) 12))
+#define TPM_ACCESS(l) (0x)
+#define TPM_INT_ENABLE(l) (0x0008)
+#define TPM_INT_VECTOR(l) (0x000C)
+#define TPM_INT_STATUS(l) (0x0010)
+#define TPM_INTF_CAPS(l)(0x0014)
+#define TPM_STS(l) (0x0018)
+#define TPM_DATA_FIFO(l)(0x0024)
-#define TPM_DID_VID(l) (0x0F00 | ((l) 12))
-#define TPM_RID(l) (0x0F04 | ((l) 12))
+#define TPM_DID_VID(l) (0x0F00)
+#define TPM_RID(l) (0x0F04)
static LIST_HEAD(tis_chips);
static DEFINE_SPINLOCK(tis_lock
RE: TPM driver changes to support multiple locality
-Original Message-
From: Arjan van de Ven [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 11, 2007 2:41 PM
To: Agarwal, Lomesh
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: Re: TPM driver changes to support multiple locality
On Thu, 11 Oct 2007 11:33:35 -0700
Agarwal, Lomesh [EMAIL PROTECTED] wrote:
Below is the patch for TPM driver.
Comments/suggestions?
please don't top post
--- pristine-linux-2.6.18/drivers/char/tpm/tpm_tis.c 2006-09-19
20:42:06.0 -0700
+++ linux-2.6.18-xen/drivers/char/tpm/tpm_tis.c 2007-10-09
15:30:49.0 -0700
or send word wrapped patches
.. or patches against 2 year old kernels for that matter ;)
enum tis_defaults {
TIS_MEM_BASE = 0xFED4,
- TIS_MEM_LEN = 0x5000,
+ TIS_MEM_LEN = 0x1000,
hmmm/// why
[Agarwal, Lomesh] 0x5000 is the length of CSRs for all the localities.
Each locality's CSR size is 0x1000. so 0x1000 is sufficient and will
catch error if driver tries to write to wrong locality.
-
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: TPM driver changes to support multiple locality
Attached is the patch which resolves all the comments. tpm_tis.c.patch Description: tpm_tis.c.patch
RE: TPM driver changes to support multiple locality
-Original Message-
From: Randy Dunlap [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 11, 2007 4:02 PM
To: Agarwal, Lomesh
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: Re: TPM driver changes to support multiple locality
On Thu, 11 Oct 2007 15:46:03 -0700 Agarwal, Lomesh wrote:
Attached is the patch which resolves all the comments.
Inline patches are preferred so that reviewers can comment on them
more easily.
What mail client are you using?
[Agarwal, Lomesh] I am using MS Outlook. Earlier you said inline patches
have problem because of mail client. That's why I sent it as attachment.
The patch has trailing CRs on each line (DOS mode).
Just verifying: this TPM device has interrupts per locality?
+ /* check if interrupt is meant for this locality */
+ if (check_locality(chip, locality) 0)
+ return IRQ_NONE;
~
[Agarwal, Lomesh] TPM device has only one interrupt. so on receiving
interrupt driver has to make sure that its meant for its locality.
init_tis() still seems to have some problems.
static int __init init_tis(void)
{
+#define DEVNAME_SIZE 10
+
int rc;
+ if ((locality 0) || (locality 4))
+ return PTR_ERR(pdev);
pdev hasn't been set (so it's NULL).
+ pdev = platform_device_register_simple(devname, -1,
NULL, 0);
+ if (IS_ERR(pdev))
return PTR_ERR(pdev);
Error path above needs to call driver_unregister().
[Agarwal, Lomesh] attached is the new patch.
---
~Randy
tpm_tis.c.patch
Description: tpm_tis.c.patch
RE: TPM driver changes to support multiple locality
There will be no change in API. Driver will accept a parameter "locality" and it will always operate on that locality. By default this parameter will be 0 which is what current driver assumes. Who is the maintainer for this driver? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 10, 2007 12:46 PM To: Agarwal, Lomesh Cc: linux-kernel@vger.kernel.org Subject: Re: TPM driver changes to support multiple locality On Tue, 09 Oct 2007 15:51:11 PDT, "Agarwal, Lomesh" said: > Current TPM driver supports only locality 0. I am planning to add > support so that it can access any locality. Locality parameter will be > passed as parameter. Will this change be acceptable? If yes then I will > modify the driver and send the patch. Make sure you extend the API in such a way that older userspace programs that don't pass the new locality parameter still work correctly. - 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: TPM driver changes to support multiple locality
There will be no change in API. Driver will accept a parameter locality and it will always operate on that locality. By default this parameter will be 0 which is what current driver assumes. Who is the maintainer for this driver? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 10, 2007 12:46 PM To: Agarwal, Lomesh Cc: linux-kernel@vger.kernel.org Subject: Re: TPM driver changes to support multiple locality On Tue, 09 Oct 2007 15:51:11 PDT, Agarwal, Lomesh said: Current TPM driver supports only locality 0. I am planning to add support so that it can access any locality. Locality parameter will be passed as parameter. Will this change be acceptable? If yes then I will modify the driver and send the patch. Make sure you extend the API in such a way that older userspace programs that don't pass the new locality parameter still work correctly. - 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/
TPM driver changes to support multiple locality
Current TPM driver supports only locality 0. I am planning to add support so that it can access any locality. Locality parameter will be passed as parameter. Will this change be acceptable? If yes then I will modify the driver and send the patch. Thanks, Lomesh - 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/
TPM driver changes to support multiple locality
Current TPM driver supports only locality 0. I am planning to add support so that it can access any locality. Locality parameter will be passed as parameter. Will this change be acceptable? If yes then I will modify the driver and send the patch. Thanks, Lomesh - 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: what is the difference between shutdown command and writing to /sys/power/state
Can someone tell me the flow of code for these two scenarios - I write disk to /sys/power/state. How does system go to hibernation? How does this trigger ACPI driver functions? I issue shutdown command. I am using 2.6.18 kernel. Thanks, Lomesh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rafael J. Wysocki Sent: Wednesday, September 19, 2007 5:09 PM To: Agarwal, Lomesh Cc: linux-kernel@vger.kernel.org Subject: Re: what is the difference between shutdown command and writing to /sys/power/state On Wednesday, 19 September 2007 23:37, Agarwal, Lomesh wrote: > Can you tell me the differences? > Also what do you mean by - depending also on what you mean by 'now'? I Please tell me what kernel version you're referring to. > gave now as a time parameter to shutdown command. How can it be > interpreted in a different way? Sorry, I have misunderstood your post (the "now" doesn't look as a part of the command). Greetings, Rafael > -Original Message- > From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 19, 2007 2:35 PM > To: Agarwal, Lomesh > Cc: linux-kernel@vger.kernel.org > Subject: Re: what is the difference between shutdown command and writing > to /sys/power/state > > On Wednesday, 19 September 2007 20:50, Agarwal, Lomesh wrote: > > Does linux handles writing "disk" to /sys/power/state and shutdown -P > > now differently (except writing to disk part)? > > Yes, it does (depending also on what you mean by 'now'). - 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/ - 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: what is the difference between shutdown command and writing to /sys/power/state
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rafael J. Wysocki Sent: Wednesday, September 19, 2007 5:09 PM To: Agarwal, Lomesh Cc: linux-kernel@vger.kernel.org Subject: Re: what is the difference between shutdown command and writing to /sys/power/state On Wednesday, 19 September 2007 23:37, Agarwal, Lomesh wrote: > Can you tell me the differences? > Also what do you mean by - depending also on what you mean by 'now'? I Please tell me what kernel version you're referring to. [Agarwal, Lomesh] 2.6.18 - 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: what is the difference between shutdown command and writing to /sys/power/state
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rafael J. Wysocki Sent: Wednesday, September 19, 2007 5:09 PM To: Agarwal, Lomesh Cc: linux-kernel@vger.kernel.org Subject: Re: what is the difference between shutdown command and writing to /sys/power/state On Wednesday, 19 September 2007 23:37, Agarwal, Lomesh wrote: Can you tell me the differences? Also what do you mean by - depending also on what you mean by 'now'? I Please tell me what kernel version you're referring to. [Agarwal, Lomesh] 2.6.18 - 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: what is the difference between shutdown command and writing to /sys/power/state
Can someone tell me the flow of code for these two scenarios - I write disk to /sys/power/state. How does system go to hibernation? How does this trigger ACPI driver functions? I issue shutdown command. I am using 2.6.18 kernel. Thanks, Lomesh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rafael J. Wysocki Sent: Wednesday, September 19, 2007 5:09 PM To: Agarwal, Lomesh Cc: linux-kernel@vger.kernel.org Subject: Re: what is the difference between shutdown command and writing to /sys/power/state On Wednesday, 19 September 2007 23:37, Agarwal, Lomesh wrote: Can you tell me the differences? Also what do you mean by - depending also on what you mean by 'now'? I Please tell me what kernel version you're referring to. gave now as a time parameter to shutdown command. How can it be interpreted in a different way? Sorry, I have misunderstood your post (the now doesn't look as a part of the command). Greetings, Rafael -Original Message- From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 19, 2007 2:35 PM To: Agarwal, Lomesh Cc: linux-kernel@vger.kernel.org Subject: Re: what is the difference between shutdown command and writing to /sys/power/state On Wednesday, 19 September 2007 20:50, Agarwal, Lomesh wrote: Does linux handles writing disk to /sys/power/state and shutdown -P now differently (except writing to disk part)? Yes, it does (depending also on what you mean by 'now'). - 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/ - 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: what is the difference between shutdown command and writing to /sys/power/state
Can you tell me the differences? Also what do you mean by - depending also on what you mean by 'now'? I gave now as a time parameter to shutdown command. How can it be interpreted in a different way? -Original Message- From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 19, 2007 2:35 PM To: Agarwal, Lomesh Cc: linux-kernel@vger.kernel.org Subject: Re: what is the difference between shutdown command and writing to /sys/power/state On Wednesday, 19 September 2007 20:50, Agarwal, Lomesh wrote: > Does linux handles writing "disk" to /sys/power/state and shutdown -P > now differently (except writing to disk part)? Yes, it does (depending also on what you mean by 'now'). Greetings, Rafael - 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/
what is the difference between shutdown command and writing to /sys/power/state
Does linux handles writing "disk" to /sys/power/state and shutdown -P now differently (except writing to disk part)? I have a Xen system and if I try both (in dom0 which is linux) then writing "disk" powers off the system while issuing shutdown command halts the system but the system is still power on. Dom0 is using ramdisk so writing "disk" to /sys/power/state should essentially be same as shutdown command. - 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/
what is the difference between shutdown command and writing to /sys/power/state
Does linux handles writing disk to /sys/power/state and shutdown -P now differently (except writing to disk part)? I have a Xen system and if I try both (in dom0 which is linux) then writing disk powers off the system while issuing shutdown command halts the system but the system is still power on. Dom0 is using ramdisk so writing disk to /sys/power/state should essentially be same as shutdown command. - 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: what is the difference between shutdown command and writing to /sys/power/state
Can you tell me the differences? Also what do you mean by - depending also on what you mean by 'now'? I gave now as a time parameter to shutdown command. How can it be interpreted in a different way? -Original Message- From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 19, 2007 2:35 PM To: Agarwal, Lomesh Cc: linux-kernel@vger.kernel.org Subject: Re: what is the difference between shutdown command and writing to /sys/power/state On Wednesday, 19 September 2007 20:50, Agarwal, Lomesh wrote: Does linux handles writing disk to /sys/power/state and shutdown -P now differently (except writing to disk part)? Yes, it does (depending also on what you mean by 'now'). Greetings, Rafael - 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: which signal is sent to freeze process?
This patch works for me too. -Original Message- From: Manfred Spraul [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 24, 2007 11:49 AM To: Pavel Machek Cc: Rafael J. Wysocki; linux-kernel@vger.kernel.org; Agarwal, Lomesh; Nigel Cunningham Subject: Re: which signal is sent to freeze process? > Hi! > > Can you generate small testcase that demonstrates the problem? > > > Then what would be the correct way to handle resume process. The other > > way of course is to make all the applications check the errno in case of > > failure. But that seems more more problematic then system call checking. > > What do you say? > > Hmm, does that testcase behave correctly over SIGSTOP/SIGCONT? I'm not > saying kernel behaves nicely here, but perhaps fixing the apps to > check errno properly is the right thing to do? :-) Perhaps the kernel should use ERESTARTNOHAND instead of EINTR? The current code is more than odd: - select() and sys_ppoll() both use ERESTARTNOHAND (i.e.: the functions do not return to user space with SIGSTOP/SIGCONT or freezer()) - sys_poll() uses EINTR (i.e.: SIGSTOP/SIGCONT/freezer() return to user space) Attached is a patch that switches sys_poll to ERESTARTNOHAND and a poll test app. Boot tested with FC6. What do you think? With ERESTARTNOHAND, poll would only return to user space if the app has a SIGCONT handler installed. -- Manfred - 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: which signal is sent to freeze process?
This patch works for me too. -Original Message- From: Manfred Spraul [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 24, 2007 11:49 AM To: Pavel Machek Cc: Rafael J. Wysocki; linux-kernel@vger.kernel.org; Agarwal, Lomesh; Nigel Cunningham Subject: Re: which signal is sent to freeze process? Hi! Can you generate small testcase that demonstrates the problem? Then what would be the correct way to handle resume process. The other way of course is to make all the applications check the errno in case of failure. But that seems more more problematic then system call checking. What do you say? Hmm, does that testcase behave correctly over SIGSTOP/SIGCONT? I'm not saying kernel behaves nicely here, but perhaps fixing the apps to check errno properly is the right thing to do? :-) Perhaps the kernel should use ERESTARTNOHAND instead of EINTR? The current code is more than odd: - select() and sys_ppoll() both use ERESTARTNOHAND (i.e.: the functions do not return to user space with SIGSTOP/SIGCONT or freezer()) - sys_poll() uses EINTR (i.e.: SIGSTOP/SIGCONT/freezer() return to user space) Attached is a patch that switches sys_poll to ERESTARTNOHAND and a poll test app. Boot tested with FC6. What do you think? With ERESTARTNOHAND, poll would only return to user space if the app has a SIGCONT handler installed. -- Manfred - 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: which signal is sent to freeze process?
The net effect would be same. Why would you choose one over other (do_sys_poll vs. do_poll)? Can you point me to code where socket read returns in case of signal_pending? I need to try couple of things. -Original Message- From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED] Sent: Monday, July 23, 2007 2:51 PM To: Agarwal, Lomesh Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org Subject: Re: which signal is sent to freeze process? On Monday, 23 July 2007 22:57, Agarwal, Lomesh wrote: > Why do you need try_to_freeze in below patch? Shouldn't > !freezing(current) checking is enough? The try_to_freeze() is needed so that the process doesn't block the freezing of tasks (it is supposed to call refrigerator() as soon as reasonably possible when freezing(current) is true). Alternatively, we might return 0 from do_sys_poll() if do_poll() has returned 0 and both signal_pending(current) and freezing(current) are true. Below is a patch that implements that. Could you please try it? Greetings, Rafael --- fs/select.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.22-rc6-mm1/fs/select.c === --- linux-2.6.22-rc6-mm1.orig/fs/select.c +++ linux-2.6.22-rc6-mm1/fs/select.c @@ -722,7 +722,7 @@ int do_sys_poll(struct pollfd __user *uf walk = walk->next; } err = fdcount; - if (!fdcount && signal_pending(current)) + if (!fdcount && (signal_pending(current) && !freezing(current))) err = -EINTR; out_fds: walk = head; - 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: which signal is sent to freeze process?
Why do you need try_to_freeze in below patch? Shouldn't
!freezing(current) checking is enough?
-Original Message-
From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED]
Sent: Friday, July 20, 2007 3:10 PM
To: Agarwal, Lomesh
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: Re: which signal is sent to freeze process?
On Friday, 20 July 2007 20:07, Agarwal, Lomesh wrote:
> Can you suggest a way I can debug the issue why I am getting EINTR
error
> for system calls in resuming? What else can cause the system call
> failure with EINTR?
Well, I think I know what the problem is. do_poll checks
signal_pending(current) and breaks when it's set, but that may be caused
by the freezer.
You may try the patch below (untested) and see if that helps.
Greetings,
Rafael
---
fs/select.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Index: linux-2.6.22-rc6-mm1/fs/select.c
===
--- linux-2.6.22-rc6-mm1.orig/fs/select.c
+++ linux-2.6.22-rc6-mm1/fs/select.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
@@ -593,6 +594,8 @@ static int do_poll(unsigned int nfds, s
struct poll_list *walk;
long __timeout;
+ try_to_freeze();
+
set_current_state(TASK_INTERRUPTIBLE);
for (walk = list; walk != NULL; walk = walk->next) {
struct pollfd * pfd, * pfd_end;
@@ -618,7 +621,8 @@ static int do_poll(unsigned int nfds, s
* a poll_table to them on the next loop iteration.
*/
pt = NULL;
- if (count || !*timeout || signal_pending(current))
+ if (count || !*timeout ||
+ (signal_pending(current) && !freezing(current)))
break;
count = wait->error;
if (count)
-
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: which signal is sent to freeze process?
Then what would be the correct way to handle resume process. The other
way of course is to make all the applications check the errno in case of
failure. But that seems more more problematic then system call checking.
What do you say?
BTW can you point me to code where socket read checks for
signal_pending(current)?
-Original Message-
From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED]
Sent: Monday, July 23, 2007 12:25 PM
To: Agarwal, Lomesh
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Pavel Machek
Subject: Re: which signal is sent to freeze process?
On Monday, 23 July 2007 20:38, Agarwal, Lomesh wrote:
> The other problem I am facing that read from socket returns with
ENODATA
> when resuming. any ideas?
It's of similar kind: the system call checks signal_pending(current) and
exit
with an error if that's true.
Well, I'm afraid we can't place try_to_freeze() in every system call
that
does something like that ...
Greetings,
Rafael
> -Original Message-
> From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 20, 2007 3:10 PM
> To: Agarwal, Lomesh
> Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
> Subject: Re: which signal is sent to freeze process?
>
> On Friday, 20 July 2007 20:07, Agarwal, Lomesh wrote:
> > Can you suggest a way I can debug the issue why I am getting EINTR
> error
> > for system calls in resuming? What else can cause the system call
> > failure with EINTR?
>
> Well, I think I know what the problem is. do_poll checks
> signal_pending(current) and breaks when it's set, but that may be
caused
> by the freezer.
>
> You may try the patch below (untested) and see if that helps.
>
> Greetings,
> Rafael
>
>
> ---
> fs/select.c |6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> Index: linux-2.6.22-rc6-mm1/fs/select.c
> ===
> --- linux-2.6.22-rc6-mm1.orig/fs/select.c
> +++ linux-2.6.22-rc6-mm1/fs/select.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -593,6 +594,8 @@ static int do_poll(unsigned int nfds, s
> struct poll_list *walk;
> long __timeout;
>
> + try_to_freeze();
> +
> set_current_state(TASK_INTERRUPTIBLE);
> for (walk = list; walk != NULL; walk = walk->next) {
> struct pollfd * pfd, * pfd_end;
> @@ -618,7 +621,8 @@ static int do_poll(unsigned int nfds, s
>* a poll_table to them on the next loop iteration.
>*/
> pt = NULL;
> - if (count || !*timeout || signal_pending(current))
> + if (count || !*timeout ||
> + (signal_pending(current) && !freezing(current)))
> break;
> count = wait->error;
> if (count)
>
>
--
"Premature optimization is the root of all evil." - Donald Knuth
-
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: which signal is sent to freeze process?
The other problem I am facing that read from socket returns with ENODATA
when resuming. any ideas?
-Original Message-
From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED]
Sent: Friday, July 20, 2007 3:10 PM
To: Agarwal, Lomesh
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: Re: which signal is sent to freeze process?
On Friday, 20 July 2007 20:07, Agarwal, Lomesh wrote:
> Can you suggest a way I can debug the issue why I am getting EINTR
error
> for system calls in resuming? What else can cause the system call
> failure with EINTR?
Well, I think I know what the problem is. do_poll checks
signal_pending(current) and breaks when it's set, but that may be caused
by the freezer.
You may try the patch below (untested) and see if that helps.
Greetings,
Rafael
---
fs/select.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Index: linux-2.6.22-rc6-mm1/fs/select.c
===
--- linux-2.6.22-rc6-mm1.orig/fs/select.c
+++ linux-2.6.22-rc6-mm1/fs/select.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
@@ -593,6 +594,8 @@ static int do_poll(unsigned int nfds, s
struct poll_list *walk;
long __timeout;
+ try_to_freeze();
+
set_current_state(TASK_INTERRUPTIBLE);
for (walk = list; walk != NULL; walk = walk->next) {
struct pollfd * pfd, * pfd_end;
@@ -618,7 +621,8 @@ static int do_poll(unsigned int nfds, s
* a poll_table to them on the next loop iteration.
*/
pt = NULL;
- if (count || !*timeout || signal_pending(current))
+ if (count || !*timeout ||
+ (signal_pending(current) && !freezing(current)))
break;
count = wait->error;
if (count)
-
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: where is the code for read system call?
For future how do I trace a system call to a function in a kernel? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Karsten Wiese Sent: Friday, July 20, 2007 5:09 PM To: Agarwal, Lomesh Cc: linux-kernel@vger.kernel.org Subject: Re: where is the code for read system call? Am Samstag, 21. Juli 2007 schrieb Agarwal, Lomesh: > My application reads from socket. I need to change the behavior of read > system call for an experiment. Can someone point me to code? fs/read_write.c: line 356 asmlinkage ssize_t sys_read(unsigned int fd, char __user * buf, size_t count) - 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/ - 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: where is the code for read system call?
For future how do I trace a system call to a function in a kernel? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Karsten Wiese Sent: Friday, July 20, 2007 5:09 PM To: Agarwal, Lomesh Cc: linux-kernel@vger.kernel.org Subject: Re: where is the code for read system call? Am Samstag, 21. Juli 2007 schrieb Agarwal, Lomesh: My application reads from socket. I need to change the behavior of read system call for an experiment. Can someone point me to code? fs/read_write.c: line 356 asmlinkage ssize_t sys_read(unsigned int fd, char __user * buf, size_t count) - 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/ - 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: which signal is sent to freeze process?
The other problem I am facing that read from socket returns with ENODATA
when resuming. any ideas?
-Original Message-
From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED]
Sent: Friday, July 20, 2007 3:10 PM
To: Agarwal, Lomesh
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: Re: which signal is sent to freeze process?
On Friday, 20 July 2007 20:07, Agarwal, Lomesh wrote:
Can you suggest a way I can debug the issue why I am getting EINTR
error
for system calls in resuming? What else can cause the system call
failure with EINTR?
Well, I think I know what the problem is. do_poll checks
signal_pending(current) and breaks when it's set, but that may be caused
by the freezer.
You may try the patch below (untested) and see if that helps.
Greetings,
Rafael
---
fs/select.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Index: linux-2.6.22-rc6-mm1/fs/select.c
===
--- linux-2.6.22-rc6-mm1.orig/fs/select.c
+++ linux-2.6.22-rc6-mm1/fs/select.c
@@ -23,6 +23,7 @@
#include linux/file.h
#include linux/fs.h
#include linux/rcupdate.h
+#include linux/freezer.h
#include asm/uaccess.h
@@ -593,6 +594,8 @@ static int do_poll(unsigned int nfds, s
struct poll_list *walk;
long __timeout;
+ try_to_freeze();
+
set_current_state(TASK_INTERRUPTIBLE);
for (walk = list; walk != NULL; walk = walk-next) {
struct pollfd * pfd, * pfd_end;
@@ -618,7 +621,8 @@ static int do_poll(unsigned int nfds, s
* a poll_table to them on the next loop iteration.
*/
pt = NULL;
- if (count || !*timeout || signal_pending(current))
+ if (count || !*timeout ||
+ (signal_pending(current) !freezing(current)))
break;
count = wait-error;
if (count)
-
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: which signal is sent to freeze process?
Then what would be the correct way to handle resume process. The other
way of course is to make all the applications check the errno in case of
failure. But that seems more more problematic then system call checking.
What do you say?
BTW can you point me to code where socket read checks for
signal_pending(current)?
-Original Message-
From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED]
Sent: Monday, July 23, 2007 12:25 PM
To: Agarwal, Lomesh
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Pavel Machek
Subject: Re: which signal is sent to freeze process?
On Monday, 23 July 2007 20:38, Agarwal, Lomesh wrote:
The other problem I am facing that read from socket returns with
ENODATA
when resuming. any ideas?
It's of similar kind: the system call checks signal_pending(current) and
exit
with an error if that's true.
Well, I'm afraid we can't place try_to_freeze() in every system call
that
does something like that ...
Greetings,
Rafael
-Original Message-
From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED]
Sent: Friday, July 20, 2007 3:10 PM
To: Agarwal, Lomesh
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: Re: which signal is sent to freeze process?
On Friday, 20 July 2007 20:07, Agarwal, Lomesh wrote:
Can you suggest a way I can debug the issue why I am getting EINTR
error
for system calls in resuming? What else can cause the system call
failure with EINTR?
Well, I think I know what the problem is. do_poll checks
signal_pending(current) and breaks when it's set, but that may be
caused
by the freezer.
You may try the patch below (untested) and see if that helps.
Greetings,
Rafael
---
fs/select.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Index: linux-2.6.22-rc6-mm1/fs/select.c
===
--- linux-2.6.22-rc6-mm1.orig/fs/select.c
+++ linux-2.6.22-rc6-mm1/fs/select.c
@@ -23,6 +23,7 @@
#include linux/file.h
#include linux/fs.h
#include linux/rcupdate.h
+#include linux/freezer.h
#include asm/uaccess.h
@@ -593,6 +594,8 @@ static int do_poll(unsigned int nfds, s
struct poll_list *walk;
long __timeout;
+ try_to_freeze();
+
set_current_state(TASK_INTERRUPTIBLE);
for (walk = list; walk != NULL; walk = walk-next) {
struct pollfd * pfd, * pfd_end;
@@ -618,7 +621,8 @@ static int do_poll(unsigned int nfds, s
* a poll_table to them on the next loop iteration.
*/
pt = NULL;
- if (count || !*timeout || signal_pending(current))
+ if (count || !*timeout ||
+ (signal_pending(current) !freezing(current)))
break;
count = wait-error;
if (count)
--
Premature optimization is the root of all evil. - Donald Knuth
-
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: which signal is sent to freeze process?
Why do you need try_to_freeze in below patch? Shouldn't
!freezing(current) checking is enough?
-Original Message-
From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED]
Sent: Friday, July 20, 2007 3:10 PM
To: Agarwal, Lomesh
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: Re: which signal is sent to freeze process?
On Friday, 20 July 2007 20:07, Agarwal, Lomesh wrote:
Can you suggest a way I can debug the issue why I am getting EINTR
error
for system calls in resuming? What else can cause the system call
failure with EINTR?
Well, I think I know what the problem is. do_poll checks
signal_pending(current) and breaks when it's set, but that may be caused
by the freezer.
You may try the patch below (untested) and see if that helps.
Greetings,
Rafael
---
fs/select.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Index: linux-2.6.22-rc6-mm1/fs/select.c
===
--- linux-2.6.22-rc6-mm1.orig/fs/select.c
+++ linux-2.6.22-rc6-mm1/fs/select.c
@@ -23,6 +23,7 @@
#include linux/file.h
#include linux/fs.h
#include linux/rcupdate.h
+#include linux/freezer.h
#include asm/uaccess.h
@@ -593,6 +594,8 @@ static int do_poll(unsigned int nfds, s
struct poll_list *walk;
long __timeout;
+ try_to_freeze();
+
set_current_state(TASK_INTERRUPTIBLE);
for (walk = list; walk != NULL; walk = walk-next) {
struct pollfd * pfd, * pfd_end;
@@ -618,7 +621,8 @@ static int do_poll(unsigned int nfds, s
* a poll_table to them on the next loop iteration.
*/
pt = NULL;
- if (count || !*timeout || signal_pending(current))
+ if (count || !*timeout ||
+ (signal_pending(current) !freezing(current)))
break;
count = wait-error;
if (count)
-
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: which signal is sent to freeze process?
The net effect would be same. Why would you choose one over other (do_sys_poll vs. do_poll)? Can you point me to code where socket read returns in case of signal_pending? I need to try couple of things. -Original Message- From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED] Sent: Monday, July 23, 2007 2:51 PM To: Agarwal, Lomesh Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org Subject: Re: which signal is sent to freeze process? On Monday, 23 July 2007 22:57, Agarwal, Lomesh wrote: Why do you need try_to_freeze in below patch? Shouldn't !freezing(current) checking is enough? The try_to_freeze() is needed so that the process doesn't block the freezing of tasks (it is supposed to call refrigerator() as soon as reasonably possible when freezing(current) is true). Alternatively, we might return 0 from do_sys_poll() if do_poll() has returned 0 and both signal_pending(current) and freezing(current) are true. Below is a patch that implements that. Could you please try it? Greetings, Rafael --- fs/select.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.22-rc6-mm1/fs/select.c === --- linux-2.6.22-rc6-mm1.orig/fs/select.c +++ linux-2.6.22-rc6-mm1/fs/select.c @@ -722,7 +722,7 @@ int do_sys_poll(struct pollfd __user *uf walk = walk-next; } err = fdcount; - if (!fdcount signal_pending(current)) + if (!fdcount (signal_pending(current) !freezing(current))) err = -EINTR; out_fds: walk = head; - 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/
where is the code for read system call?
My application reads from socket. I need to change the behavior of read system call for an experiment. Can someone point me to code? thanks - 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: which signal is sent to freeze process?
Can you suggest a way I can debug the issue why I am getting EINTR error for system calls in resuming? What else can cause the system call failure with EINTR? -Original Message- From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED] Sent: Friday, July 20, 2007 4:24 AM To: Agarwal, Lomesh Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org Subject: Re: which signal is sent to freeze process? On Friday, 20 July 2007 01:22, Agarwal, Lomesh wrote: > I am using Linux in an embedded platform with x86. Applications don't do > anything special. The system call which is returning EINTR is poll. Also > in one of the thread read is returning ENODATA after resume. If I just > try the system calls again in case of EINTR or ENODATA everything works > fine. > From your mail it looks like freezer is not supposed to be interrupting > system calls. Is that true? Yes, it is, or at least it should be. The signal handling is invoked when the process is exiting the kernel space and it shouldn't affect the execution or results of system calls. Greetings, Rafael > -Original Message- > From: Nigel Cunningham [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 19, 2007 3:19 PM > To: Agarwal, Lomesh > Cc: [EMAIL PROTECTED]; Rafael Wysocki; linux-kernel@vger.kernel.org > Subject: Re: which signal is sent to freeze process? > > Hi. > > On Friday 20 July 2007 07:06:01 Agarwal, Lomesh wrote: > > So basically I can not install a signal handler to catch freeze signal > > in the process. Right? > > Is there any other way to solve the problem I am facing? After resume > > some of the system calls are failing in some of my applications with > > errno set as EINTR. I wanted to explore a way to not check for this > > error all over the place and somehow retry failed system call. Any > > ideas? > > Well, if you tell us which syscalls are returning with EINTR, maybe we > can do > something on our side. The freezer is supposed to be as transparent as > possible to userspace, so it may be the case that we can do something to > > continue waiting or whatever you were doing after the freezing is done. > > Regards, > > Nigel -- "Premature optimization is the root of all evil." - Donald Knuth - 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: which signal is sent to freeze process?
Can you suggest a way I can debug the issue why I am getting EINTR error for system calls in resuming? What else can cause the system call failure with EINTR? -Original Message- From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED] Sent: Friday, July 20, 2007 4:24 AM To: Agarwal, Lomesh Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org Subject: Re: which signal is sent to freeze process? On Friday, 20 July 2007 01:22, Agarwal, Lomesh wrote: I am using Linux in an embedded platform with x86. Applications don't do anything special. The system call which is returning EINTR is poll. Also in one of the thread read is returning ENODATA after resume. If I just try the system calls again in case of EINTR or ENODATA everything works fine. From your mail it looks like freezer is not supposed to be interrupting system calls. Is that true? Yes, it is, or at least it should be. The signal handling is invoked when the process is exiting the kernel space and it shouldn't affect the execution or results of system calls. Greetings, Rafael -Original Message- From: Nigel Cunningham [mailto:[EMAIL PROTECTED] Sent: Thursday, July 19, 2007 3:19 PM To: Agarwal, Lomesh Cc: [EMAIL PROTECTED]; Rafael Wysocki; linux-kernel@vger.kernel.org Subject: Re: which signal is sent to freeze process? Hi. On Friday 20 July 2007 07:06:01 Agarwal, Lomesh wrote: So basically I can not install a signal handler to catch freeze signal in the process. Right? Is there any other way to solve the problem I am facing? After resume some of the system calls are failing in some of my applications with errno set as EINTR. I wanted to explore a way to not check for this error all over the place and somehow retry failed system call. Any ideas? Well, if you tell us which syscalls are returning with EINTR, maybe we can do something on our side. The freezer is supposed to be as transparent as possible to userspace, so it may be the case that we can do something to continue waiting or whatever you were doing after the freezing is done. Regards, Nigel -- Premature optimization is the root of all evil. - Donald Knuth - 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/
where is the code for read system call?
My application reads from socket. I need to change the behavior of read system call for an experiment. Can someone point me to code? thanks - 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: which signal is sent to freeze process?
I am using Linux in an embedded platform with x86. Applications don't do anything special. The system call which is returning EINTR is poll. Also in one of the thread read is returning ENODATA after resume. If I just try the system calls again in case of EINTR or ENODATA everything works fine. >From your mail it looks like freezer is not supposed to be interrupting system calls. Is that true? -Original Message- From: Nigel Cunningham [mailto:[EMAIL PROTECTED] Sent: Thursday, July 19, 2007 3:19 PM To: Agarwal, Lomesh Cc: [EMAIL PROTECTED]; Rafael Wysocki; linux-kernel@vger.kernel.org Subject: Re: which signal is sent to freeze process? Hi. On Friday 20 July 2007 07:06:01 Agarwal, Lomesh wrote: > So basically I can not install a signal handler to catch freeze signal > in the process. Right? > Is there any other way to solve the problem I am facing? After resume > some of the system calls are failing in some of my applications with > errno set as EINTR. I wanted to explore a way to not check for this > error all over the place and somehow retry failed system call. Any > ideas? Well, if you tell us which syscalls are returning with EINTR, maybe we can do something on our side. The freezer is supposed to be as transparent as possible to userspace, so it may be the case that we can do something to continue waiting or whatever you were doing after the freezing is done. Regards, Nigel -- See http://www.tuxonice.net for Howtos, FAQs, mailing lists, wiki and bugzilla info. - 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: which signal is sent to freeze process?
So basically I can not install a signal handler to catch freeze signal in the process. Right? Is there any other way to solve the problem I am facing? After resume some of the system calls are failing in some of my applications with errno set as EINTR. I wanted to explore a way to not check for this error all over the place and somehow retry failed system call. Any ideas? -Original Message- From: Nigel Cunningham [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 18, 2007 9:59 PM To: Agarwal, Lomesh; Rafael Wysocki Cc: linux-kernel@vger.kernel.org Subject: Re: which signal is sent to freeze process? Hi. On Thursday 19 July 2007 14:09:56 Agarwal, Lomesh wrote: > Can you point me to code where kernel captures process in signal > handling and code which runs after suspend to ram is finished? Sure. It's in kernel/signal.c (get_signal_to_deliver) for x86 and x86_64, and arch//kernel/signal.c for other arches. The support for other arches is the place x86 & x86_64 used to use - I wonder if they should be going away (Rafael cc'd to raise this point with him). Regards, Nigel -- See http://www.tuxonice.net for Howtos, FAQs, mailing lists, wiki and bugzilla info. - 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: which signal is sent to freeze process?
So basically I can not install a signal handler to catch freeze signal in the process. Right? Is there any other way to solve the problem I am facing? After resume some of the system calls are failing in some of my applications with errno set as EINTR. I wanted to explore a way to not check for this error all over the place and somehow retry failed system call. Any ideas? -Original Message- From: Nigel Cunningham [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 18, 2007 9:59 PM To: Agarwal, Lomesh; Rafael Wysocki Cc: linux-kernel@vger.kernel.org Subject: Re: which signal is sent to freeze process? Hi. On Thursday 19 July 2007 14:09:56 Agarwal, Lomesh wrote: Can you point me to code where kernel captures process in signal handling and code which runs after suspend to ram is finished? Sure. It's in kernel/signal.c (get_signal_to_deliver) for x86 and x86_64, and arch/name/kernel/signal.c for other arches. The support for other arches is the place x86 x86_64 used to use - I wonder if they should be going away (Rafael cc'd to raise this point with him). Regards, Nigel -- See http://www.tuxonice.net for Howtos, FAQs, mailing lists, wiki and bugzilla info. - 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: which signal is sent to freeze process?
I am using Linux in an embedded platform with x86. Applications don't do anything special. The system call which is returning EINTR is poll. Also in one of the thread read is returning ENODATA after resume. If I just try the system calls again in case of EINTR or ENODATA everything works fine. From your mail it looks like freezer is not supposed to be interrupting system calls. Is that true? -Original Message- From: Nigel Cunningham [mailto:[EMAIL PROTECTED] Sent: Thursday, July 19, 2007 3:19 PM To: Agarwal, Lomesh Cc: [EMAIL PROTECTED]; Rafael Wysocki; linux-kernel@vger.kernel.org Subject: Re: which signal is sent to freeze process? Hi. On Friday 20 July 2007 07:06:01 Agarwal, Lomesh wrote: So basically I can not install a signal handler to catch freeze signal in the process. Right? Is there any other way to solve the problem I am facing? After resume some of the system calls are failing in some of my applications with errno set as EINTR. I wanted to explore a way to not check for this error all over the place and somehow retry failed system call. Any ideas? Well, if you tell us which syscalls are returning with EINTR, maybe we can do something on our side. The freezer is supposed to be as transparent as possible to userspace, so it may be the case that we can do something to continue waiting or whatever you were doing after the freezing is done. Regards, Nigel -- See http://www.tuxonice.net for Howtos, FAQs, mailing lists, wiki and bugzilla info. - 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: which signal is sent to freeze process?
Can you point me to code where kernel captures process in signal handling and code which runs after suspend to ram is finished? -Original Message- From: Nigel Cunningham [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 18, 2007 7:19 PM To: Agarwal, Lomesh Cc: linux-kernel@vger.kernel.org Subject: Re: which signal is sent to freeze process? Hi. On Thursday 19 July 2007 09:42:02 Agarwal, Lomesh wrote: > My understanding is that Linux kernel sends a signal to freeze processes > during suspend2ram operation. Which signal is used to achieve this? > The problem I am facing is that some of the system calls are failing > with EINTR errno during suspend operation and I want to install a signal > handler for freeze signal with SA_RESTART flag. That should make the > kernel to retry the system calls. Right? No signal is sent. We tell affected processes that they have a signal pending, and capture them in the signal handling code while the suspend to ram is occuring. After the suspend to ram is finished, we recalculate whether they have a signal pending, and let them continue. Not being a guru on signal handling itself, I won't try to answer the question itself :\. Regards, Nigel - 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/
which signal is sent to freeze process?
My understanding is that Linux kernel sends a signal to freeze processes during suspend2ram operation. Which signal is used to achieve this? The problem I am facing is that some of the system calls are failing with EINTR errno during suspend operation and I want to install a signal handler for freeze signal with SA_RESTART flag. That should make the kernel to retry the system calls. Right? Thanks, Lomesh - 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/
which signal is sent to freeze process?
My understanding is that Linux kernel sends a signal to freeze processes during suspend2ram operation. Which signal is used to achieve this? The problem I am facing is that some of the system calls are failing with EINTR errno during suspend operation and I want to install a signal handler for freeze signal with SA_RESTART flag. That should make the kernel to retry the system calls. Right? Thanks, Lomesh - 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: which signal is sent to freeze process?
Can you point me to code where kernel captures process in signal handling and code which runs after suspend to ram is finished? -Original Message- From: Nigel Cunningham [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 18, 2007 7:19 PM To: Agarwal, Lomesh Cc: linux-kernel@vger.kernel.org Subject: Re: which signal is sent to freeze process? Hi. On Thursday 19 July 2007 09:42:02 Agarwal, Lomesh wrote: My understanding is that Linux kernel sends a signal to freeze processes during suspend2ram operation. Which signal is used to achieve this? The problem I am facing is that some of the system calls are failing with EINTR errno during suspend operation and I want to install a signal handler for freeze signal with SA_RESTART flag. That should make the kernel to retry the system calls. Right? No signal is sent. We tell affected processes that they have a signal pending, and capture them in the signal handling code while the suspend to ram is occuring. After the suspend to ram is finished, we recalculate whether they have a signal pending, and let them continue. Not being a guru on signal handling itself, I won't try to answer the question itself :\. Regards, Nigel - 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: S3 state transition
I searched the archives but couldn't get much. Can you point me to code? Thanks, Lomesh -Original Message- From: Pavel Machek [mailto:[EMAIL PROTECTED] Sent: Thursday, July 12, 2007 7:14 AM To: Agarwal, Lomesh Cc: linux-kernel@vger.kernel.org Subject: Re: S3 state transition On Wed 2007-07-11 16:15:37, Agarwal, Lomesh wrote: > I am trying to understand how Linux handles S3 state transition. > Specially I want to understand what it does anything for processes > loaded at the time of transition. Any pointers to code/document will be > helpful. Do you mean suspend2ram? Search archives for freezer flamewar. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: S3 state transition
I searched the archives but couldn't get much. Can you point me to code? Thanks, Lomesh -Original Message- From: Pavel Machek [mailto:[EMAIL PROTECTED] Sent: Thursday, July 12, 2007 7:14 AM To: Agarwal, Lomesh Cc: linux-kernel@vger.kernel.org Subject: Re: S3 state transition On Wed 2007-07-11 16:15:37, Agarwal, Lomesh wrote: I am trying to understand how Linux handles S3 state transition. Specially I want to understand what it does anything for processes loaded at the time of transition. Any pointers to code/document will be helpful. Do you mean suspend2ram? Search archives for freezer flamewar. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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/
S3 state transition
I am trying to understand how Linux handles S3 state transition. Specially I want to understand what it does anything for processes loaded at the time of transition. Any pointers to code/document will be helpful. Thanks, Lomesh - 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/
S3 state transition
I am trying to understand how Linux handles S3 state transition. Specially I want to understand what it does anything for processes loaded at the time of transition. Any pointers to code/document will be helpful. Thanks, Lomesh - 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/
