Re: [PATCH] [v2] x86, suspend: Save/restore extra MSR registers for suspend
Hi Chen. Is there any issue with saving and restoring MSRs unconditionally? That would simplify the patch and make things 'just work'. Regards, Nigel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [v2] x86, suspend: Save/restore extra MSR registers for suspend
Hi Chen. Is there any issue with saving and restoring MSRs unconditionally? That would simplify the patch and make things 'just work'. Regards, Nigel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support
Hi Yao. On 17/08/15 13:59, Yao Yuan wrote: > On Sat, Aug 15, 2015 at 7:48 AM, pku.leo < pku@gmail.com > wrote: >> On Fri, Aug 14, 2015 at 1:24 AM, Yao Yuan wrote: >>> Hi Leo, >>> >>> Thanks for your review. >>> About those two methods for DMA suspend that you have mentioned. We >> have a lot of the discussions in other DMA driver like DMA for Freescale >> PowerPC. >>> Finally, we think the device which used the DMA transmission service should >> cancel the transmission service in its suspend. >>> So DMA in suspend should be idle. >> If that's the case you should clearly state this in the commit message and in >> code, although I don't know if it is safe to make such assumption. There >> could >> be user of the DMA that doesn't track the completion of transfers. > I think it should be safe. In my opinion, even some client(the user of the > DMA) forget to cancel its DMA transmission, > It will just lead to PM failed but no other system and data risk. > Although we should first fix the behavior of the client. > Once you are no need the DMA transmission, why not stop it? > > Is it right? Think of it from the end user perspective. Would you like your laptop (or whatever) to refuse to suspend because of this condition? The user may well expect that closing the lid on their laptop will reliably lead to it suspending to ram. Returning a failure here could result in a loss of data if the condition is not detected and the machine subsequently runs out of power. I do agree that whatever is submitting DMA should be stopped first; ideally this driver would always be idle because whatever producers of work exist would already have been quiesced and output flushed. Regards, Nigel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 08/16] x86/efi: Carrying hibernation key by setup data
Hi all. I've rejoined LKML, so I'll try to help with reviewing PM patches. I'd forgotten how much it is a case of sipping at a fire hydrant! Regards, Nigel On 17/08/15 07:23, Jiri Kosina wrote: > On Sat, 15 Aug 2015, Pavel Machek wrote: > >>> For forwarding hibernation key from EFI stub to boot kernel, this patch >>> allocates setup data for carrying hibernation key, size and the status >>> of efi operating. >>> >>> Reviewed-by: Jiri Kosina >> Jiri, are you sure you reviewed these? This is not really >> english, afaict, and efi/EFI should be spelled consistently. > Yes, I did review the code and the fact that it is still in compliance > with my original idea. I think you can blame me on not reviewing > changelogs super-rigorously though, so all suggestions for improvements > are absolutely welcome. > > Thanks, > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support
Hi Yao. On 17/08/15 13:59, Yao Yuan wrote: On Sat, Aug 15, 2015 at 7:48 AM, pku.leo pku@gmail.com wrote: On Fri, Aug 14, 2015 at 1:24 AM, Yao Yuan yao.y...@freescale.com wrote: Hi Leo, Thanks for your review. About those two methods for DMA suspend that you have mentioned. We have a lot of the discussions in other DMA driver like DMA for Freescale PowerPC. Finally, we think the device which used the DMA transmission service should cancel the transmission service in its suspend. So DMA in suspend should be idle. If that's the case you should clearly state this in the commit message and in code, although I don't know if it is safe to make such assumption. There could be user of the DMA that doesn't track the completion of transfers. I think it should be safe. In my opinion, even some client(the user of the DMA) forget to cancel its DMA transmission, It will just lead to PM failed but no other system and data risk. Although we should first fix the behavior of the client. Once you are no need the DMA transmission, why not stop it? Is it right? Think of it from the end user perspective. Would you like your laptop (or whatever) to refuse to suspend because of this condition? The user may well expect that closing the lid on their laptop will reliably lead to it suspending to ram. Returning a failure here could result in a loss of data if the condition is not detected and the machine subsequently runs out of power. I do agree that whatever is submitting DMA should be stopped first; ideally this driver would always be idle because whatever producers of work exist would already have been quiesced and output flushed. Regards, Nigel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 08/16] x86/efi: Carrying hibernation key by setup data
Hi all. I've rejoined LKML, so I'll try to help with reviewing PM patches. I'd forgotten how much it is a case of sipping at a fire hydrant! Regards, Nigel On 17/08/15 07:23, Jiri Kosina wrote: On Sat, 15 Aug 2015, Pavel Machek wrote: For forwarding hibernation key from EFI stub to boot kernel, this patch allocates setup data for carrying hibernation key, size and the status of efi operating. Reviewed-by: Jiri Kosina jkos...@suse.com Jiri, are you sure you reviewed these? This is not really english, afaict, and efi/EFI should be spelled consistently. Yes, I did review the code and the fact that it is still in compliance with my original idea. I think you can blame me on not reviewing changelogs super-rigorously though, so all suggestions for improvements are absolutely welcome. Thanks, -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libata, freezer: avoid block device removal while system is frozen
Hi. On 15/12/13 07:36, Tejun Heo wrote: On Sat, Dec 14, 2013 at 03:31:21PM -0500, Tejun Heo wrote: So, all this is about hibernation? Does that mean that it's safe to unfreeze before invoking resume? ie. we currently do, freeze suspend devs resume devs unfreeze If we can just do, freeze suspend devs unfreeze resume devs Ummm... even better, does that mean, in the long term, we can decouple freezing and device pm operations? If this is just about hibernation, there's no reason to wrap device driver pm ops with freezer, right? Thanks. Rafael has spent far more time than me thinking about the semantics here, so I'd like to defer to him. Rafael?... Regards, Nigel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libata, freezer: avoid block device removal while system is frozen
Hi. On 15/12/13 07:36, Tejun Heo wrote: On Sat, Dec 14, 2013 at 03:31:21PM -0500, Tejun Heo wrote: So, all this is about hibernation? Does that mean that it's safe to unfreeze before invoking resume? ie. we currently do, freeze suspend devs resume devs unfreeze If we can just do, freeze suspend devs unfreeze resume devs Ummm... even better, does that mean, in the long term, we can decouple freezing and device pm operations? If this is just about hibernation, there's no reason to wrap device driver pm ops with freezer, right? Thanks. Rafael has spent far more time than me thinking about the semantics here, so I'd like to defer to him. Rafael?... Regards, Nigel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libata, freezer: avoid block device removal while system is frozen
Hi again. On 14/12/13 10:07, Tejun Heo wrote: Hello, Nigel. On Sat, Dec 14, 2013 at 09:45:59AM +1100, Nigel Cunningham wrote: In your first email, in the first substantial paragraph (starting "Now, if the rest.."), you say "libata device removal waits for the scheduled writeback work item to finish". I wonder if that's the lynchpin. If we know the device is gone, why are we trying to write to it? It's just a standard part of block device removal - invalidate_partition(), bdi_wb_shutdown(). Mmm. But perhaps there needs to be some special code in there to handle the "we can't write to this device anymore" case? All pending I/O should have been flushed when suspend/hibernate started, and there's no point in trying to update metadata on a Frozen or not, it isn't guaranteed that bdi wb queue is empty when the system went to suspend. They're likely to be empty but there's no guarantee. Conversion to workqueue only makes the behavior more deterministic. device we can't access, so there should be no writeback needed (and anything that does somehow get there should just be discarded since it will never succeed anyway). Even if they'll never succeed, they still need to be issued and drained; otherwise, we'll end up with leaked items and hung issuers. Yeah - I get that, but drained needs to work differently if the device doesn't exist? Having said the above, I agree that we shouldn't need to freeze kernel threads and workqueues themselves. I think we should be giving the producers of I/O the nous needed to avoid producing I/O during suspend/hibernate. But perhaps I'm missing something here, too. I never understood that part. Why do we need to control the producers? The chain between the producer and consumer is a long one and no matter what we do with the producers, the consumers need to be plugged all the same. Why bother with the producers at all? I think that's where all this freezable kthreads started but I don't understand what the benefit of that is. Not only that, freezer is awefully inadequate in its role too. There are flurry of activities which happen in the IO path without any thread involved and many of them can lead to issuance of new IO, so the only thing freezer is achieving is making existing bugs less visible, which is a bad thing especially for suspend/resume as the failure mode often doesn't yield to easy debugging. I asked the same question years ago and ISTR getting only fairly vague answers but this whole freezable kthread is expectedly proving to be a continuous source of problems. Let's at least find out whether we need it and why if so. Not some "I feel better knowing things are calmer" type vagueness but actual technical necessity of it. My understanding is that the point is ensuring that - particularly in the case of hibernation - we don't cause filesystem corruption by writing one thing while writing the image and then doing something else (without knowledge of what happened while the image was being written) while reading the image or after restoring it. Regards, Nigel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libata, freezer: avoid block device removal while system is frozen
Hi Tejun. Thanks for your work on this. In your first email, in the first substantial paragraph (starting "Now, if the rest.."), you say "libata device removal waits for the scheduled writeback work item to finish". I wonder if that's the lynchpin. If we know the device is gone, why are we trying to write to it? All pending I/O should have been flushed when suspend/hibernate started, and there's no point in trying to update metadata on a device we can't access, so there should be no writeback needed (and anything that does somehow get there should just be discarded since it will never succeed anyway). Or am I missing something? Having said the above, I agree that we shouldn't need to freeze kernel threads and workqueues themselves. I think we should be giving the producers of I/O the nous needed to avoid producing I/O during suspend/hibernate. But perhaps I'm missing something here, too. Regards, Nigel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libata, freezer: avoid block device removal while system is frozen
Hi Tejun. Thanks for your work on this. In your first email, in the first substantial paragraph (starting Now, if the rest..), you say libata device removal waits for the scheduled writeback work item to finish. I wonder if that's the lynchpin. If we know the device is gone, why are we trying to write to it? All pending I/O should have been flushed when suspend/hibernate started, and there's no point in trying to update metadata on a device we can't access, so there should be no writeback needed (and anything that does somehow get there should just be discarded since it will never succeed anyway). Or am I missing something? Having said the above, I agree that we shouldn't need to freeze kernel threads and workqueues themselves. I think we should be giving the producers of I/O the nous needed to avoid producing I/O during suspend/hibernate. But perhaps I'm missing something here, too. Regards, Nigel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libata, freezer: avoid block device removal while system is frozen
Hi again. On 14/12/13 10:07, Tejun Heo wrote: Hello, Nigel. On Sat, Dec 14, 2013 at 09:45:59AM +1100, Nigel Cunningham wrote: In your first email, in the first substantial paragraph (starting Now, if the rest..), you say libata device removal waits for the scheduled writeback work item to finish. I wonder if that's the lynchpin. If we know the device is gone, why are we trying to write to it? It's just a standard part of block device removal - invalidate_partition(), bdi_wb_shutdown(). Mmm. But perhaps there needs to be some special code in there to handle the we can't write to this device anymore case? All pending I/O should have been flushed when suspend/hibernate started, and there's no point in trying to update metadata on a Frozen or not, it isn't guaranteed that bdi wb queue is empty when the system went to suspend. They're likely to be empty but there's no guarantee. Conversion to workqueue only makes the behavior more deterministic. device we can't access, so there should be no writeback needed (and anything that does somehow get there should just be discarded since it will never succeed anyway). Even if they'll never succeed, they still need to be issued and drained; otherwise, we'll end up with leaked items and hung issuers. Yeah - I get that, but drained needs to work differently if the device doesn't exist? Having said the above, I agree that we shouldn't need to freeze kernel threads and workqueues themselves. I think we should be giving the producers of I/O the nous needed to avoid producing I/O during suspend/hibernate. But perhaps I'm missing something here, too. I never understood that part. Why do we need to control the producers? The chain between the producer and consumer is a long one and no matter what we do with the producers, the consumers need to be plugged all the same. Why bother with the producers at all? I think that's where all this freezable kthreads started but I don't understand what the benefit of that is. Not only that, freezer is awefully inadequate in its role too. There are flurry of activities which happen in the IO path without any thread involved and many of them can lead to issuance of new IO, so the only thing freezer is achieving is making existing bugs less visible, which is a bad thing especially for suspend/resume as the failure mode often doesn't yield to easy debugging. I asked the same question years ago and ISTR getting only fairly vague answers but this whole freezable kthread is expectedly proving to be a continuous source of problems. Let's at least find out whether we need it and why if so. Not some I feel better knowing things are calmer type vagueness but actual technical necessity of it. My understanding is that the point is ensuring that - particularly in the case of hibernation - we don't cause filesystem corruption by writing one thing while writing the image and then doing something else (without knowledge of what happened while the image was being written) while reading the image or after restoring it. Regards, Nigel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2] Re: New Defect(s) reported by Coverity Scan
From 68e866b8eac534405ae16b79b7ffd9de05c11c67 Mon Sep 17 00:00:00 2001
From: Nigel Cunningham
Date: Tue, 1 Jan 2013 13:50:22 +1100
Subject: [PATCH] Fix uninitialised variable in rbd_dev_probe_update_spec.
The local variable ret can be used uninitialised in the error path
if the kstrdup at line 2631 fails. Set ret to -ENOMEM in that case.
This patch addresses Coverity #753111.
Signed-off-by: Nigel Cunningham
---
drivers/block/rbd.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index dfb7ef8..ba4dd66 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -2629,8 +2629,10 @@ static int rbd_dev_probe_update_spec(struct
rbd_device *rbd_dev)
goto out_err;
}
rbd_dev->spec->snap_name = kstrdup(name, GFP_KERNEL);
-if(!rbd_dev->spec->snap_name)
+if(!rbd_dev->spec->snap_name) {
+ret = -ENOMEM;
goto out_err;
+}
return 0;
out_err:
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3] Re: New Defect(s) reported by Coverity Scan
From b4a7ab768df17e1cda7d0ae8744e986215a644c3 Mon Sep 17 00:00:00 2001
From: Nigel Cunningham
Date: Tue, 1 Jan 2013 13:53:51 +1100
Subject: [PATCH] Remove unused variable in rbd_dev_probe_update_spec.
As an aside to the previous patch, remove the unused local
variable reply_buf in that function.
Signed-off-by: Nigel Cunningham
---
drivers/block/rbd.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index ba4dd66..dccb6e4 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -2592,7 +2592,6 @@ static int rbd_dev_probe_update_spec(struct
rbd_device *rbd_dev)
{
struct ceph_osd_client *osdc;
const char *name;
-void *reply_buf = NULL;
int ret;
if (rbd_dev->spec->pool_name)
@@ -2636,7 +2635,6 @@ static int rbd_dev_probe_update_spec(struct
rbd_device *rbd_dev)
return 0;
out_err:
-kfree(reply_buf);
kfree(rbd_dev->spec->pool_name);
rbd_dev->spec->pool_name = NULL;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: New Defect(s) reported by Coverity Scan
From b41864867464bfe0e2d114528bc9b39e2d9f546e Mon Sep 17 00:00:00 2001 From: Nigel Cunningham Date: Tue, 1 Jan 2013 13:03:50 +1100 Subject: [PATCH] Fix rbd use after free. This patch addresses Coverity #753114. The use of ceph_opts in rbd_add is currently confusing - there are three possible outcomes of the call to rbd_get_client: 1) An existing, matching and usable rdb client is found and returned by rbd_client_find. ceph_opts is freed by rbd_get_client and should not be freed by rbd_add. This the code path triggering the Coverity warning. 2) An existing, matching and usable rdb client is NOT found and returned by rbd_client_find. rbd_client_create successfully executes, passing responsibility for ceph_opts to the newly created client. It should not be freed by rbd_add. 3) An existing, matching and usable rdb client is NOT found and returned by rbd_client_find. rbd_client_create fails to create a new client, freeing ceph_opts in its error path. It should not be freed by rbd_add. So then, regardless of the outcome of rbd_get_client, if it is called, we should not attempt to free ceph_opts. The solution is then simple: there is no need to seek to free ceph_opts in rbd_add (or do anything with it) because rbd_get_client is called immediately after the structure is allocated by rbd_add_parse_args. Signed-off-by: Nigel Cunningham --- drivers/block/rbd.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c index 89576a0..dfb7ef8 100644 --- a/drivers/block/rbd.c +++ b/drivers/block/rbd.c @@ -3629,7 +3629,6 @@ static ssize_t rbd_add(struct bus_type *bus, rc = PTR_ERR(rbdc); goto err_out_args; } -ceph_opts = NULL;/* rbd_dev client now owns this */ /* pick the pool */ osdc = >client->osdc; @@ -3658,8 +3657,6 @@ err_out_rbd_dev: err_out_client: rbd_put_client(rbdc); err_out_args: -if (ceph_opts) -ceph_destroy_options(ceph_opts); kfree(rbd_opts); rbd_spec_put(spec); err_out_module: -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: New Defect(s) reported by Coverity Scan
From b41864867464bfe0e2d114528bc9b39e2d9f546e Mon Sep 17 00:00:00 2001 From: Nigel Cunningham ni...@nigelcunningham.com.au Date: Tue, 1 Jan 2013 13:03:50 +1100 Subject: [PATCH] Fix rbd use after free. This patch addresses Coverity #753114. The use of ceph_opts in rbd_add is currently confusing - there are three possible outcomes of the call to rbd_get_client: 1) An existing, matching and usable rdb client is found and returned by rbd_client_find. ceph_opts is freed by rbd_get_client and should not be freed by rbd_add. This the code path triggering the Coverity warning. 2) An existing, matching and usable rdb client is NOT found and returned by rbd_client_find. rbd_client_create successfully executes, passing responsibility for ceph_opts to the newly created client. It should not be freed by rbd_add. 3) An existing, matching and usable rdb client is NOT found and returned by rbd_client_find. rbd_client_create fails to create a new client, freeing ceph_opts in its error path. It should not be freed by rbd_add. So then, regardless of the outcome of rbd_get_client, if it is called, we should not attempt to free ceph_opts. The solution is then simple: there is no need to seek to free ceph_opts in rbd_add (or do anything with it) because rbd_get_client is called immediately after the structure is allocated by rbd_add_parse_args. Signed-off-by: Nigel Cunningham ni...@nigelcunningham.com.au --- drivers/block/rbd.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c index 89576a0..dfb7ef8 100644 --- a/drivers/block/rbd.c +++ b/drivers/block/rbd.c @@ -3629,7 +3629,6 @@ static ssize_t rbd_add(struct bus_type *bus, rc = PTR_ERR(rbdc); goto err_out_args; } -ceph_opts = NULL;/* rbd_dev client now owns this */ /* pick the pool */ osdc = rbdc-client-osdc; @@ -3658,8 +3657,6 @@ err_out_rbd_dev: err_out_client: rbd_put_client(rbdc); err_out_args: -if (ceph_opts) -ceph_destroy_options(ceph_opts); kfree(rbd_opts); rbd_spec_put(spec); err_out_module: -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3] Re: New Defect(s) reported by Coverity Scan
From b4a7ab768df17e1cda7d0ae8744e986215a644c3 Mon Sep 17 00:00:00 2001
From: Nigel Cunningham ni...@nigelcunningham.com.au
Date: Tue, 1 Jan 2013 13:53:51 +1100
Subject: [PATCH] Remove unused variable in rbd_dev_probe_update_spec.
As an aside to the previous patch, remove the unused local
variable reply_buf in that function.
Signed-off-by: Nigel Cunningham ni...@nigelcunningham.com.au
---
drivers/block/rbd.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index ba4dd66..dccb6e4 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -2592,7 +2592,6 @@ static int rbd_dev_probe_update_spec(struct
rbd_device *rbd_dev)
{
struct ceph_osd_client *osdc;
const char *name;
-void *reply_buf = NULL;
int ret;
if (rbd_dev-spec-pool_name)
@@ -2636,7 +2635,6 @@ static int rbd_dev_probe_update_spec(struct
rbd_device *rbd_dev)
return 0;
out_err:
-kfree(reply_buf);
kfree(rbd_dev-spec-pool_name);
rbd_dev-spec-pool_name = NULL;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2] Re: New Defect(s) reported by Coverity Scan
From 68e866b8eac534405ae16b79b7ffd9de05c11c67 Mon Sep 17 00:00:00 2001
From: Nigel Cunningham ni...@nigelcunningham.com.au
Date: Tue, 1 Jan 2013 13:50:22 +1100
Subject: [PATCH] Fix uninitialised variable in rbd_dev_probe_update_spec.
The local variable ret can be used uninitialised in the error path
if the kstrdup at line 2631 fails. Set ret to -ENOMEM in that case.
This patch addresses Coverity #753111.
Signed-off-by: Nigel Cunningham ni...@nigelcunningham.com.au
---
drivers/block/rbd.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index dfb7ef8..ba4dd66 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -2629,8 +2629,10 @@ static int rbd_dev_probe_update_spec(struct
rbd_device *rbd_dev)
goto out_err;
}
rbd_dev-spec-snap_name = kstrdup(name, GFP_KERNEL);
-if(!rbd_dev-spec-snap_name)
+if(!rbd_dev-spec-snap_name) {
+ret = -ENOMEM;
goto out_err;
+}
return 0;
out_err:
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Add support for DMI matching in calculating RTC_ALWAYS_BCD
From 037d9b44c9a18e6c2e3dedde2b8391215accc236 Mon Sep 17 00:00:00 2001
From: Nigel
Date: Mon, 31 Dec 2012 10:58:54 +1100
Subject: [PATCH] Add support for DMI matching in calculating RTC_ALWAYS_BCD.
The Sony Vaio VPCSE15FG needs RTC_ALWAYS_BCD to be false rather than the
otherwise universal value of true. Add support for catching this model
via DMI matching.
There have been no BIOS updates for the VPCSE15FG, so I've not specified
a BIOS version in the criteria for matching.
Signed-off-by: Nigel Cunningham
---
arch/x86/include/asm/mc146818rtc.h |2 +-
drivers/rtc/Makefile |1 +
drivers/rtc/dmi.c | 46
include/linux/rtc.h|6 +
4 files changed, 54 insertions(+), 1 deletion(-)
create mode 100644 drivers/rtc/dmi.c
diff --git a/arch/x86/include/asm/mc146818rtc.h
b/arch/x86/include/asm/mc146818rtc.h
index d354fb7..b88f2c6 100644
--- a/arch/x86/include/asm/mc146818rtc.h
+++ b/arch/x86/include/asm/mc146818rtc.h
@@ -10,7 +10,7 @@
#ifndef RTC_PORT
#define RTC_PORT(x)(0x70 + (x))
-#define RTC_ALWAYS_BCD1/* RTC operates in binary mode */
+#define RTC_ALWAYS_BCD(rtc_always_bcd)/* Does the RTC operate
in binary mode? */
#endif
#if defined(CONFIG_X86_32) && defined(__HAVE_ARCH_CMPXCHG)
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index c3f62c8..e008f65 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -12,6 +12,7 @@ rtc-core-y:= class.o interface.o
rtc-core-$(CONFIG_RTC_INTF_DEV)+= rtc-dev.o
rtc-core-$(CONFIG_RTC_INTF_PROC) += rtc-proc.o
rtc-core-$(CONFIG_RTC_INTF_SYSFS) += rtc-sysfs.o
+rtc-core-$(CONFIG_DMI) += dmi.o
# Keep the list ordered.
diff --git a/drivers/rtc/dmi.c b/drivers/rtc/dmi.c
new file mode 100644
index 000..609c2b5
--- /dev/null
+++ b/drivers/rtc/dmi.c
@@ -0,0 +1,46 @@
+/*
+ * RTC driver DMI matching.
+ *
+ * Most machines using the mc146818 RTC need RTC_ALWAYS_BCD set to 1.
+ * This file does DMI matching for the tiny number (1 so far!) of
machines
+ * that don't fit that mould.
+ *
+ * (C) 2012 Nigel Cunningham
+ *Add support for checking for the Sony Vaio VPCSE15FG.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as
published by
+ * the Free Software Foundation.
+ *
+ * Trademarks are the property of their respective owners.
+ */
+
+#include
+#include
+
+int __read_mostly rtc_always_bcd;
+EXPORT_SYMBOL_GPL(rtc_always_bcd);
+
+static const struct dmi_system_id __initconst nonbcd_dmi_table[] = {
+#if defined(CONFIG_DMI) && defined(CONFIG_X86)
+{
+/* Sony VAIO VPCSE15FG */
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+DMI_MATCH(DMI_PRODUCT_NAME, "VPCSE15FG"),
+},
+},
+#endif
+{ }
+};
+
+static int __init rtc_check_always_bcd(void)
+{
+if (dmi_check_system(nonbcd_dmi_table)) {
+printk("Non BCD RTC clock detected via DMI check.\n");
+} else
+rtc_always_bcd = 1;
+
+return 0;
+}
+core_initcall(rtc_check_always_bcd);
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index 9531845..0049f0f 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -164,6 +164,12 @@ extern int rtc_alarm_irq_enable(struct rtc_device
*rtc, unsigned int enabled);
extern int rtc_dev_update_irq_enable_emul(struct rtc_device *rtc,
unsigned int enabled);
+#ifdef CONFIG_DMI
+extern int rtc_always_bcd;
+#else
+#define rtc_always_bcd (1)
+#endif
+
void rtc_handle_legacy_irq(struct rtc_device *rtc, int num, int mode);
void rtc_aie_update_irq(void *private);
void rtc_uie_update_irq(void *private);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Add support for DMI matching in calculating RTC_ALWAYS_BCD
From 037d9b44c9a18e6c2e3dedde2b8391215accc236 Mon Sep 17 00:00:00 2001
From: Nigel ni...@tuxonice.net
Date: Mon, 31 Dec 2012 10:58:54 +1100
Subject: [PATCH] Add support for DMI matching in calculating RTC_ALWAYS_BCD.
The Sony Vaio VPCSE15FG needs RTC_ALWAYS_BCD to be false rather than the
otherwise universal value of true. Add support for catching this model
via DMI matching.
There have been no BIOS updates for the VPCSE15FG, so I've not specified
a BIOS version in the criteria for matching.
Signed-off-by: Nigel Cunningham ni...@nigelcunningham.com.au
---
arch/x86/include/asm/mc146818rtc.h |2 +-
drivers/rtc/Makefile |1 +
drivers/rtc/dmi.c | 46
include/linux/rtc.h|6 +
4 files changed, 54 insertions(+), 1 deletion(-)
create mode 100644 drivers/rtc/dmi.c
diff --git a/arch/x86/include/asm/mc146818rtc.h
b/arch/x86/include/asm/mc146818rtc.h
index d354fb7..b88f2c6 100644
--- a/arch/x86/include/asm/mc146818rtc.h
+++ b/arch/x86/include/asm/mc146818rtc.h
@@ -10,7 +10,7 @@
#ifndef RTC_PORT
#define RTC_PORT(x)(0x70 + (x))
-#define RTC_ALWAYS_BCD1/* RTC operates in binary mode */
+#define RTC_ALWAYS_BCD(rtc_always_bcd)/* Does the RTC operate
in binary mode? */
#endif
#if defined(CONFIG_X86_32) defined(__HAVE_ARCH_CMPXCHG)
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index c3f62c8..e008f65 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -12,6 +12,7 @@ rtc-core-y:= class.o interface.o
rtc-core-$(CONFIG_RTC_INTF_DEV)+= rtc-dev.o
rtc-core-$(CONFIG_RTC_INTF_PROC) += rtc-proc.o
rtc-core-$(CONFIG_RTC_INTF_SYSFS) += rtc-sysfs.o
+rtc-core-$(CONFIG_DMI) += dmi.o
# Keep the list ordered.
diff --git a/drivers/rtc/dmi.c b/drivers/rtc/dmi.c
new file mode 100644
index 000..609c2b5
--- /dev/null
+++ b/drivers/rtc/dmi.c
@@ -0,0 +1,46 @@
+/*
+ * RTC driver DMI matching.
+ *
+ * Most machines using the mc146818 RTC need RTC_ALWAYS_BCD set to 1.
+ * This file does DMI matching for the tiny number (1 so far!) of
machines
+ * that don't fit that mould.
+ *
+ * (C) 2012 Nigel Cunningham ni...@nigelcunningham.com.au
+ *Add support for checking for the Sony Vaio VPCSE15FG.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as
published by
+ * the Free Software Foundation.
+ *
+ * Trademarks are the property of their respective owners.
+ */
+
+#include linux/module.h
+#include linux/dmi.h
+
+int __read_mostly rtc_always_bcd;
+EXPORT_SYMBOL_GPL(rtc_always_bcd);
+
+static const struct dmi_system_id __initconst nonbcd_dmi_table[] = {
+#if defined(CONFIG_DMI) defined(CONFIG_X86)
+{
+/* Sony VAIO VPCSE15FG */
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, Sony Corporation),
+DMI_MATCH(DMI_PRODUCT_NAME, VPCSE15FG),
+},
+},
+#endif
+{ }
+};
+
+static int __init rtc_check_always_bcd(void)
+{
+if (dmi_check_system(nonbcd_dmi_table)) {
+printk(Non BCD RTC clock detected via DMI check.\n);
+} else
+rtc_always_bcd = 1;
+
+return 0;
+}
+core_initcall(rtc_check_always_bcd);
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index 9531845..0049f0f 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -164,6 +164,12 @@ extern int rtc_alarm_irq_enable(struct rtc_device
*rtc, unsigned int enabled);
extern int rtc_dev_update_irq_enable_emul(struct rtc_device *rtc,
unsigned int enabled);
+#ifdef CONFIG_DMI
+extern int rtc_always_bcd;
+#else
+#define rtc_always_bcd (1)
+#endif
+
void rtc_handle_legacy_irq(struct rtc_device *rtc, int num, int mode);
void rtc_aie_update_irq(void *private);
void rtc_uie_update_irq(void *private);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
Hi Greg. Greg KH wrote: On Thu, Feb 21, 2008 at 12:17:06PM +1100, Nigel Cunningham wrote: Hi. Greg KH wrote: On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote: Hi. Matthew Garrett wrote: On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote: - people keep talking about hibernating to an ext3 fs mounted on fuse as a limitation of the freezer. To do that with kexec, you're still going to have to bmap the ext3 fs and pass the block list (in which case we can also do it without kexec) or umount all the ext3/fuse part and remount in the kexec'd kernel. Sort of defeats the purpose, doesn't it? No, with a freezer-based model you can basically *never* suspend to anything related to FUSE or a userspace USB device or anything involving userspace iSCSI initiators or whatever. Sure, there are cases where moving away from the current model doesn't buy you anything, but that doesn't mean that the current model is a good thing. It's not. The freezer is a fundamentally broken concept. Putting drivers and filesystems in userspace is the fundamentally broken concept. Not just when it comes to the freezer. The whole idea is inherently racy. Racy with regards to other things becides trying to suspend a machine? If so, what? That depends on what sort of tangled web you want to weave. Lots of them :) We have tanks running Linux using userspace USB drivers for vision control systems (scary, I know...) They seem to be successfully running for many years now, and I'm interested in making sure those kinds of things keep working. We also have laser welding robots with userspace PCI drivers in car manufacturing plants. And other laser cutting robots slicing wood in patterns moving at a rate of over 3 meters a second. Again, with userspace drivers and Linux. Those users would also love to know of any potential problems you know of for this situation. Low memory situations is one other situation that occurs to me quickly, especially (though not only) if your ability to swap were to depend upon a userspace driver and/or filesystem. Sure, swap over a userspace filesystem or driver isn't a sane idea. And neither is swaping over NFS over a PPP connection attached to a USB to serial device. Yes, it's possible, and all in the kernel, but not a wise decision. Other than foolish configurations, if you come up with other issues surrounding userspace drivers that could cause problems, please let me know. A simple OOM condition isn't an issue? Surely a driver stalling because some of its memory gets swapped out just before it goes to use it would be a problem if it resulted in getting the length of a cut wrong or caused some distorted vision or a late turn :> Am I missing something? Maybe these drivers mlock memory to avoid those issues or something like that? 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: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
Hi. Matthew Garrett wrote: On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote: Matthew Garrett wrote: No, with a freezer-based model you can basically *never* suspend to anything related to FUSE or a userspace USB device or anything involving userspace iSCSI initiators or whatever. Sure, there are cases where moving away from the current model doesn't buy you anything, but that doesn't mean that the current model is a good thing. It's not. The freezer is a fundamentally broken concept. Putting drivers and filesystems in userspace is the fundamentally broken concept. Not just when it comes to the freezer. The whole idea is inherently racy. You can draw silly diagrams about how the freezer supposedly works in LCA slides and spread FUD as much as you like. In the end, though, it's not nearly as hit-and-miss as you say, and replacing the freezer with a kexec based freezer is only going to create as many problems as it removes. I'm really not interested in debating the matter. There are all sorts of potential uses for the freezer, but hibernation isn't one of them. We *need* to get rid of the freezer for suspend to RAM (because a band-aid to ensure atomicity is kind of pointless when the operation you're entering is inherently atomic), and once all the drivers are able to deal with that then it's trivial to get rid of it for hibernation as well. Arguing that the reality of userspace drivers is broken doesn't help here. It's what we have to work with. Re suspend to ram, I agree. No argument there. Re hibernation, I think your assertion that it will be trivial to get rid of it for hibernation is just plain wrong. Perhaps you don't understand the issues as well as you think you do. Re arguing that the reality of userspace drivers is broken doesn't help here: Yeah, I know. But sometimes if you point out broken ideas for long enough, people do actually listen. Or you learn. Or both. Frankly, I don't want to debate the issue either. What I really want is just to have a hibernation implementation that works, is flexibile, reliable and quick, and one that I don't have to keep maintaining. Unfortunately for me, most people seem to be more concerned with fixing hypothetical problems than with giving users something they can actually use. You're looking at a tiny amount of memory when compared to current systems. It's really not a problem. Please, quantify 'tiny'. In embedded, 5MB can be too much. I've worked on embedded solutions. I'm not pulling problems out of thin air. Then the in-kernel solution has already lost anyway, and I'm desperately unconcerned about out of tree stuff. I know. I'd submit it, or work on breaking it into pieces and submitting them one at a time, but that seems to me to be a waste of time. 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: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
Hi. Greg KH wrote: On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote: Hi. Matthew Garrett wrote: On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote: - people keep talking about hibernating to an ext3 fs mounted on fuse as a limitation of the freezer. To do that with kexec, you're still going to have to bmap the ext3 fs and pass the block list (in which case we can also do it without kexec) or umount all the ext3/fuse part and remount in the kexec'd kernel. Sort of defeats the purpose, doesn't it? No, with a freezer-based model you can basically *never* suspend to anything related to FUSE or a userspace USB device or anything involving userspace iSCSI initiators or whatever. Sure, there are cases where moving away from the current model doesn't buy you anything, but that doesn't mean that the current model is a good thing. It's not. The freezer is a fundamentally broken concept. Putting drivers and filesystems in userspace is the fundamentally broken concept. Not just when it comes to the freezer. The whole idea is inherently racy. Racy with regards to other things becides trying to suspend a machine? If so, what? That depends on what sort of tangled web you want to weave. Low memory situations is one other situation that occurs to me quickly, especially (though not only) if your ability to swap were to depend upon a userspace driver and/or filesystem. 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: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
Hi. Matthew Garrett wrote: On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote: - people keep talking about hibernating to an ext3 fs mounted on fuse as a limitation of the freezer. To do that with kexec, you're still going to have to bmap the ext3 fs and pass the block list (in which case we can also do it without kexec) or umount all the ext3/fuse part and remount in the kexec'd kernel. Sort of defeats the purpose, doesn't it? No, with a freezer-based model you can basically *never* suspend to anything related to FUSE or a userspace USB device or anything involving userspace iSCSI initiators or whatever. Sure, there are cases where moving away from the current model doesn't buy you anything, but that doesn't mean that the current model is a good thing. It's not. The freezer is a fundamentally broken concept. Putting drivers and filesystems in userspace is the fundamentally broken concept. Not just when it comes to the freezer. The whole idea is inherently racy. You can draw silly diagrams about how the freezer supposedly works in LCA slides and spread FUD as much as you like. In the end, though, it's not nearly as hit-and-miss as you say, and replacing the freezer with a kexec based freezer is only going to create as many problems as it removes. I also wonder about how much of a pain it's going to be setting up userspace for this kexec'd kernel. Will you need a separate partition just for it? If not, will the userspace be loaded into memory all the time (more memory wasted for normal use), or loaded from ordinary partitions at kexec time (how to do safely? - more info to transfer between kernels?). You're looking at a tiny amount of memory when compared to current systems. It's really not a problem. Please, quantify 'tiny'. In embedded, 5MB can be too much. I've worked on embedded solutions. I'm not pulling problems out of thin air. 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: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
Hi. Jesse Barnes wrote: Well, it seems like we'll have to fix drivers in either case, and isn't a kexec approach fundamentally more sound and simple, design-wise? Rafael pointed out some problems with properly setting wakeup states, but I think that could be overcome... No. AFAICS, kexec is going to be more complex and ugly in many ways. To summarise, a kexec based hibernation is going to need the following additional requirements to just replace what we already have: - get the original kernel to allocate storage while racing against the rest of the system (currently allocation is done post-atomic copy & post-freezing - no racing). This makes it potentially slower, too; - get the original kernel to transfer the information about what swap was allocated to the kexec'd kernel, probably together with a lot of other information (which pages are nosave etc). - get the original kernel to keep memory free for the kexec'd kernel which would otherwise be usable. Not a biggy on desktops or laptops, but think about embedded. - people keep talking about hibernating to an ext3 fs mounted on fuse as a limitation of the freezer. To do that with kexec, you're still going to have to bmap the ext3 fs and pass the block list (in which case we can also do it without kexec) or umount all the ext3/fuse part and remount in the kexec'd kernel. Sort of defeats the purpose, doesn't it? I also wonder about how much of a pain it's going to be setting up userspace for this kexec'd kernel. Will you need a separate partition just for it? If not, will the userspace be loaded into memory all the time (more memory wasted for normal use), or loaded from ordinary partitions at kexec time (how to do safely? - more info to transfer between kernels?). I'd love it if kexec really was the panacea to the freezer issues, but problems like these make me think it isn't a viable solution. 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: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
Hi. Jesse Barnes wrote: Well, it seems like we'll have to fix drivers in either case, and isn't a kexec approach fundamentally more sound and simple, design-wise? Rafael pointed out some problems with properly setting wakeup states, but I think that could be overcome... No. AFAICS, kexec is going to be more complex and ugly in many ways. To summarise, a kexec based hibernation is going to need the following additional requirements to just replace what we already have: - get the original kernel to allocate storage while racing against the rest of the system (currently allocation is done post-atomic copy post-freezing - no racing). This makes it potentially slower, too; - get the original kernel to transfer the information about what swap was allocated to the kexec'd kernel, probably together with a lot of other information (which pages are nosave etc). - get the original kernel to keep memory free for the kexec'd kernel which would otherwise be usable. Not a biggy on desktops or laptops, but think about embedded. - people keep talking about hibernating to an ext3 fs mounted on fuse as a limitation of the freezer. To do that with kexec, you're still going to have to bmap the ext3 fs and pass the block list (in which case we can also do it without kexec) or umount all the ext3/fuse part and remount in the kexec'd kernel. Sort of defeats the purpose, doesn't it? I also wonder about how much of a pain it's going to be setting up userspace for this kexec'd kernel. Will you need a separate partition just for it? If not, will the userspace be loaded into memory all the time (more memory wasted for normal use), or loaded from ordinary partitions at kexec time (how to do safely? - more info to transfer between kernels?). I'd love it if kexec really was the panacea to the freezer issues, but problems like these make me think it isn't a viable solution. 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: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
Hi. Matthew Garrett wrote: On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote: - people keep talking about hibernating to an ext3 fs mounted on fuse as a limitation of the freezer. To do that with kexec, you're still going to have to bmap the ext3 fs and pass the block list (in which case we can also do it without kexec) or umount all the ext3/fuse part and remount in the kexec'd kernel. Sort of defeats the purpose, doesn't it? No, with a freezer-based model you can basically *never* suspend to anything related to FUSE or a userspace USB device or anything involving userspace iSCSI initiators or whatever. Sure, there are cases where moving away from the current model doesn't buy you anything, but that doesn't mean that the current model is a good thing. It's not. The freezer is a fundamentally broken concept. Putting drivers and filesystems in userspace is the fundamentally broken concept. Not just when it comes to the freezer. The whole idea is inherently racy. You can draw silly diagrams about how the freezer supposedly works in LCA slides and spread FUD as much as you like. In the end, though, it's not nearly as hit-and-miss as you say, and replacing the freezer with a kexec based freezer is only going to create as many problems as it removes. I also wonder about how much of a pain it's going to be setting up userspace for this kexec'd kernel. Will you need a separate partition just for it? If not, will the userspace be loaded into memory all the time (more memory wasted for normal use), or loaded from ordinary partitions at kexec time (how to do safely? - more info to transfer between kernels?). You're looking at a tiny amount of memory when compared to current systems. It's really not a problem. Please, quantify 'tiny'. In embedded, 5MB can be too much. I've worked on embedded solutions. I'm not pulling problems out of thin air. 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: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
Hi. Greg KH wrote: On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote: Hi. Matthew Garrett wrote: On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote: - people keep talking about hibernating to an ext3 fs mounted on fuse as a limitation of the freezer. To do that with kexec, you're still going to have to bmap the ext3 fs and pass the block list (in which case we can also do it without kexec) or umount all the ext3/fuse part and remount in the kexec'd kernel. Sort of defeats the purpose, doesn't it? No, with a freezer-based model you can basically *never* suspend to anything related to FUSE or a userspace USB device or anything involving userspace iSCSI initiators or whatever. Sure, there are cases where moving away from the current model doesn't buy you anything, but that doesn't mean that the current model is a good thing. It's not. The freezer is a fundamentally broken concept. Putting drivers and filesystems in userspace is the fundamentally broken concept. Not just when it comes to the freezer. The whole idea is inherently racy. Racy with regards to other things becides trying to suspend a machine? If so, what? That depends on what sort of tangled web you want to weave. Low memory situations is one other situation that occurs to me quickly, especially (though not only) if your ability to swap were to depend upon a userspace driver and/or filesystem. 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: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
Hi. Matthew Garrett wrote: On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote: Matthew Garrett wrote: No, with a freezer-based model you can basically *never* suspend to anything related to FUSE or a userspace USB device or anything involving userspace iSCSI initiators or whatever. Sure, there are cases where moving away from the current model doesn't buy you anything, but that doesn't mean that the current model is a good thing. It's not. The freezer is a fundamentally broken concept. Putting drivers and filesystems in userspace is the fundamentally broken concept. Not just when it comes to the freezer. The whole idea is inherently racy. You can draw silly diagrams about how the freezer supposedly works in LCA slides and spread FUD as much as you like. In the end, though, it's not nearly as hit-and-miss as you say, and replacing the freezer with a kexec based freezer is only going to create as many problems as it removes. I'm really not interested in debating the matter. There are all sorts of potential uses for the freezer, but hibernation isn't one of them. We *need* to get rid of the freezer for suspend to RAM (because a band-aid to ensure atomicity is kind of pointless when the operation you're entering is inherently atomic), and once all the drivers are able to deal with that then it's trivial to get rid of it for hibernation as well. Arguing that the reality of userspace drivers is broken doesn't help here. It's what we have to work with. Re suspend to ram, I agree. No argument there. Re hibernation, I think your assertion that it will be trivial to get rid of it for hibernation is just plain wrong. Perhaps you don't understand the issues as well as you think you do. Re arguing that the reality of userspace drivers is broken doesn't help here: Yeah, I know. But sometimes if you point out broken ideas for long enough, people do actually listen. Or you learn. Or both. Frankly, I don't want to debate the issue either. What I really want is just to have a hibernation implementation that works, is flexibile, reliable and quick, and one that I don't have to keep maintaining. Unfortunately for me, most people seem to be more concerned with fixing hypothetical problems than with giving users something they can actually use. You're looking at a tiny amount of memory when compared to current systems. It's really not a problem. Please, quantify 'tiny'. In embedded, 5MB can be too much. I've worked on embedded solutions. I'm not pulling problems out of thin air. Then the in-kernel solution has already lost anyway, and I'm desperately unconcerned about out of tree stuff. I know. I'd submit it, or work on breaking it into pieces and submitting them one at a time, but that seems to me to be a waste of time. 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: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
Hi Greg. Greg KH wrote: On Thu, Feb 21, 2008 at 12:17:06PM +1100, Nigel Cunningham wrote: Hi. Greg KH wrote: On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote: Hi. Matthew Garrett wrote: On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote: - people keep talking about hibernating to an ext3 fs mounted on fuse as a limitation of the freezer. To do that with kexec, you're still going to have to bmap the ext3 fs and pass the block list (in which case we can also do it without kexec) or umount all the ext3/fuse part and remount in the kexec'd kernel. Sort of defeats the purpose, doesn't it? No, with a freezer-based model you can basically *never* suspend to anything related to FUSE or a userspace USB device or anything involving userspace iSCSI initiators or whatever. Sure, there are cases where moving away from the current model doesn't buy you anything, but that doesn't mean that the current model is a good thing. It's not. The freezer is a fundamentally broken concept. Putting drivers and filesystems in userspace is the fundamentally broken concept. Not just when it comes to the freezer. The whole idea is inherently racy. Racy with regards to other things becides trying to suspend a machine? If so, what? That depends on what sort of tangled web you want to weave. Lots of them :) We have tanks running Linux using userspace USB drivers for vision control systems (scary, I know...) They seem to be successfully running for many years now, and I'm interested in making sure those kinds of things keep working. We also have laser welding robots with userspace PCI drivers in car manufacturing plants. And other laser cutting robots slicing wood in patterns moving at a rate of over 3 meters a second. Again, with userspace drivers and Linux. Those users would also love to know of any potential problems you know of for this situation. Low memory situations is one other situation that occurs to me quickly, especially (though not only) if your ability to swap were to depend upon a userspace driver and/or filesystem. Sure, swap over a userspace filesystem or driver isn't a sane idea. And neither is swaping over NFS over a PPP connection attached to a USB to serial device. Yes, it's possible, and all in the kernel, but not a wise decision. Other than foolish configurations, if you come up with other issues surrounding userspace drivers that could cause problems, please let me know. A simple OOM condition isn't an issue? Surely a driver stalling because some of its memory gets swapped out just before it goes to use it would be a problem if it resulted in getting the length of a cut wrong or caused some distorted vision or a late turn : Am I missing something? Maybe these drivers mlock memory to avoid those issues or something like that? 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: [linux-pm] Re: Small pm documentation cleanups
Hi again.
Pavel Machek wrote:
Hi!
On Tuesday, 5 of February 2008, Pavel Machek wrote:
Small documentation fixes/additions that accumulated in my tree.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Acked-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
...
0
acpi_sleep= [HW,ACPI] Sleep options
- Format: { s3_bios, s3_mode }
- See Documentation/power/video.txt
+ Format: { s3_bios, s3_mode, s3_beep }
+ See Documentation/power/video.txt for s3_bios and
s3_mode.
+ s3_beep is for debugging; it beeps on PC speaker as
soon as
+ kernel's real-mode entry point is called.
s/kernel's/the kernel's/
Thanks for comments, I applied them.
You're welcome. Sorry for replying again, but I just noticed another one
in the line above - it should be something like "it makes the PC's
speaker beep as soon as" ('on PC speaker' isn't right).
Sorry for not getting that last time.
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: [linux-pm] Re: Small pm documentation cleanups
Hi again.
Pavel Machek wrote:
Hi!
On Tuesday, 5 of February 2008, Pavel Machek wrote:
Small documentation fixes/additions that accumulated in my tree.
Signed-off-by: Pavel Machek [EMAIL PROTECTED]
Acked-by: Rafael J. Wysocki [EMAIL PROTECTED]
...
0
acpi_sleep= [HW,ACPI] Sleep options
- Format: { s3_bios, s3_mode }
- See Documentation/power/video.txt
+ Format: { s3_bios, s3_mode, s3_beep }
+ See Documentation/power/video.txt for s3_bios and
s3_mode.
+ s3_beep is for debugging; it beeps on PC speaker as
soon as
+ kernel's real-mode entry point is called.
s/kernel's/the kernel's/
Thanks for comments, I applied them.
You're welcome. Sorry for replying again, but I just noticed another one
in the line above - it should be something like it makes the PC's
speaker beep as soon as ('on PC speaker' isn't right).
Sorry for not getting that last time.
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: [linux-pm] Re: Small pm documentation cleanups
Hi.
Rafael J. Wysocki wrote:
Len, please pick this up, thanks.
On Tuesday, 5 of February 2008, Pavel Machek wrote:
Small documentation fixes/additions that accumulated in my tree.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Acked-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index cf38689..3be3328 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -147,8 +147,10 @@ and is between 256 and 4096 characters.
default: 0
acpi_sleep= [HW,ACPI] Sleep options
- Format: { s3_bios, s3_mode }
- See Documentation/power/video.txt
+ Format: { s3_bios, s3_mode, s3_beep }
+ See Documentation/power/video.txt for s3_bios and
s3_mode.
+ s3_beep is for debugging; it beeps on PC speaker as
soon as
+ kernel's real-mode entry point is called.
s/kernel's/the kernel's/
acpi_sci= [HW,ACPI] ACPI System Control Interrupt trigger mode
Format: { level | edge | high | low }
diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt
index aea7e92..d3e5e4e 100644
--- a/Documentation/power/swsusp.txt
+++ b/Documentation/power/swsusp.txt
@@ -386,6 +386,11 @@ before suspending; then remount them aft
There is a work-around for this problem. For more information, see
Documentation/usb/persist.txt.
+Q: Can I suspend-to-disk using a swap partition under LVM?
+
+A: No. You can suspend successfully, but you'll not be able to
+resume. uswsusp should be able to work with LVM, see suspend.sf.net.
s/LVM, see/LVM. See/
+
Q: I upgraded the kernel from 2.6.15 to 2.6.16. Both kernels were
compiled with the similar configuration files. Anyway I found that
suspend to disk (and resume) is much slower on 2.6.16 compared to
diff --git a/drivers/acpi/hardware/hwsleep.c b/drivers/acpi/hardware/hwsleep.c
index fd1c4ba..058d0be 100644
--- a/drivers/acpi/hardware/hwsleep.c
+++ b/drivers/acpi/hardware/hwsleep.c
@@ -286,13 +286,13 @@ acpi_status asmlinkage acpi_enter_sleep_
}
/*
+* 1) Disable/Clear all GPEs
* 2) Enable all wakeup GPEs
*/
status = acpi_hw_disable_all_gpes();
if (ACPI_FAILURE(status)) {
return_ACPI_STATUS(status);
}
-
acpi_gbl_system_awake_and_running = FALSE;
status = acpi_hw_enable_all_wakeup_gpes();
diff --git a/drivers/acpi/sleep/main.c b/drivers/acpi/sleep/main.c
index 485de13..56e09cf 100644
--- a/drivers/acpi/sleep/main.c
+++ b/drivers/acpi/sleep/main.c
@@ -170,7 +170,7 @@ static int acpi_pm_enter(suspend_state_t
/* Reprogram control registers and execute _BFS */
acpi_leave_sleep_state_prep(acpi_state);
- /* ACPI 3.0 specs (P62) says that it's the responsabilty
+ /* ACPI 3.0 specs (P62) says that it's the responsibilty
s/responsibilty/responsibility/
* of the OSPM to clear the status bit [ implying that the
* POWER_BUTTON event should not reach userspace ]
*/
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index ef9b802..b275ffb 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -74,14 +74,14 @@ config PM_TRACE_RTC
RTC across reboots, so that you can debug a machine that just hangs
during suspend (or more commonly, during resume).
- To use this debugging feature you should attempt to suspend the machine,
- then reboot it, then run
+ To use this debugging feature you should attempt to suspend the
+ machine, then reboot it, then run
More readable would be "machine, reboot it and then run"
dmesg -s 100 | grep 'hash matches'
CAUTION: this option will cause your machine's real-time clock to be
set to an invalid time after a resume.
config PM_SLEEP_SMP
bool
depends on SMP
@@ -123,7 +129,8 @@ config HIBERNATION
called "hibernation" in user interfaces. STD checkpoints the
system and powers it off; and restores that checkpoint on reboot.
- You can suspend your machine with 'echo disk > /sys/power/state'.
+ You can suspend your machine with 'echo disk > /sys/power/state'
+ after placing resume=/dev/swappartition on kernel command line.
s/on kernel/on the kernel/
Maybe add "in your bootloader's configuration file"?
Alternatively, you can use the additional userland tools available
from .
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 6a6d5eb..d3df5af 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -223,6 +226,7 @@ void __attribute__ ((weak)) arch_suspend
* @state: state to enter
*
* This function should be called after devices have been suspended.
+ * May not sleep.
*/
static int suspend_enter(suspend_state_t state)
{
@@ -250,6
Re: [linux-pm] Re: Small pm documentation cleanups
Hi.
Rafael J. Wysocki wrote:
Len, please pick this up, thanks.
On Tuesday, 5 of February 2008, Pavel Machek wrote:
Small documentation fixes/additions that accumulated in my tree.
Signed-off-by: Pavel Machek [EMAIL PROTECTED]
Acked-by: Rafael J. Wysocki [EMAIL PROTECTED]
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index cf38689..3be3328 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -147,8 +147,10 @@ and is between 256 and 4096 characters.
default: 0
acpi_sleep= [HW,ACPI] Sleep options
- Format: { s3_bios, s3_mode }
- See Documentation/power/video.txt
+ Format: { s3_bios, s3_mode, s3_beep }
+ See Documentation/power/video.txt for s3_bios and
s3_mode.
+ s3_beep is for debugging; it beeps on PC speaker as
soon as
+ kernel's real-mode entry point is called.
s/kernel's/the kernel's/
acpi_sci= [HW,ACPI] ACPI System Control Interrupt trigger mode
Format: { level | edge | high | low }
diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt
index aea7e92..d3e5e4e 100644
--- a/Documentation/power/swsusp.txt
+++ b/Documentation/power/swsusp.txt
@@ -386,6 +386,11 @@ before suspending; then remount them aft
There is a work-around for this problem. For more information, see
Documentation/usb/persist.txt.
+Q: Can I suspend-to-disk using a swap partition under LVM?
+
+A: No. You can suspend successfully, but you'll not be able to
+resume. uswsusp should be able to work with LVM, see suspend.sf.net.
s/LVM, see/LVM. See/
+
Q: I upgraded the kernel from 2.6.15 to 2.6.16. Both kernels were
compiled with the similar configuration files. Anyway I found that
suspend to disk (and resume) is much slower on 2.6.16 compared to
diff --git a/drivers/acpi/hardware/hwsleep.c b/drivers/acpi/hardware/hwsleep.c
index fd1c4ba..058d0be 100644
--- a/drivers/acpi/hardware/hwsleep.c
+++ b/drivers/acpi/hardware/hwsleep.c
@@ -286,13 +286,13 @@ acpi_status asmlinkage acpi_enter_sleep_
}
/*
+* 1) Disable/Clear all GPEs
* 2) Enable all wakeup GPEs
*/
status = acpi_hw_disable_all_gpes();
if (ACPI_FAILURE(status)) {
return_ACPI_STATUS(status);
}
-
acpi_gbl_system_awake_and_running = FALSE;
status = acpi_hw_enable_all_wakeup_gpes();
diff --git a/drivers/acpi/sleep/main.c b/drivers/acpi/sleep/main.c
index 485de13..56e09cf 100644
--- a/drivers/acpi/sleep/main.c
+++ b/drivers/acpi/sleep/main.c
@@ -170,7 +170,7 @@ static int acpi_pm_enter(suspend_state_t
/* Reprogram control registers and execute _BFS */
acpi_leave_sleep_state_prep(acpi_state);
- /* ACPI 3.0 specs (P62) says that it's the responsabilty
+ /* ACPI 3.0 specs (P62) says that it's the responsibilty
s/responsibilty/responsibility/
* of the OSPM to clear the status bit [ implying that the
* POWER_BUTTON event should not reach userspace ]
*/
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index ef9b802..b275ffb 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -74,14 +74,14 @@ config PM_TRACE_RTC
RTC across reboots, so that you can debug a machine that just hangs
during suspend (or more commonly, during resume).
- To use this debugging feature you should attempt to suspend the machine,
- then reboot it, then run
+ To use this debugging feature you should attempt to suspend the
+ machine, then reboot it, then run
More readable would be machine, reboot it and then run
dmesg -s 100 | grep 'hash matches'
CAUTION: this option will cause your machine's real-time clock to be
set to an invalid time after a resume.
config PM_SLEEP_SMP
bool
depends on SMP
@@ -123,7 +129,8 @@ config HIBERNATION
called hibernation in user interfaces. STD checkpoints the
system and powers it off; and restores that checkpoint on reboot.
- You can suspend your machine with 'echo disk /sys/power/state'.
+ You can suspend your machine with 'echo disk /sys/power/state'
+ after placing resume=/dev/swappartition on kernel command line.
s/on kernel/on the kernel/
Maybe add in your bootloader's configuration file?
Alternatively, you can use the additional userland tools available
from http://suspend.sf.net.
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 6a6d5eb..d3df5af 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -223,6 +226,7 @@ void __attribute__ ((weak)) arch_suspend
* @state: state to enter
*
* This function should be called after devices have been suspended.
+ * May not sleep.
*/
static int suspend_enter(suspend_state_t state)
{
@@ -250,6 +255,8 @@ static
Re: hibernate/suspend-to-disk: to turn power or not?
Hi Michael. Michael Tokarev wrote: Nigel Cunningham wrote: [] That should be doable. How is your UPS connected? Presumably, with some modifications to the appropriate driver, we could send the commands when we're ready to shutdown. It would probably be useful whether or not your hibernating (if not, sending the commands could always be made an option). You mean adding stuff to some KERNEL driver? Like to a serial driver if the UPS is connected to a COM-port?? I'm afraid either I don't understand what you're talking about here, or, if I got you right, that YOU don't understand what you're talking about... Come on, teaching kernel about various idiotic UPSes out there is more than insane... ;) I wasn't meaning the kernel should have to know about various idiotic UPSses (yes, I've got experience with them too, so I understand what you're talking about there). What I was thinking was that maybe it might be possible to give the kernel some simple (configurable) string to send out the UPS port when it's time to power off. Of course you're going to point out that a simple string won't do in every case (though I think it would do for at least some of the idiotic UPS ones). I was just wondering aloud if there was a simpler way, but on further reflection, I guess there's no way around it. Whether this is done with kexec, uswsusp or TuxOnIce, it's going to involve creating (TuxOnIce / kexec ) or extending a userspace (uswsusp) binary that's got to somehow interface with the driver and get the job done. 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: hibernate/suspend-to-disk: to turn power or not?
Hi. Michael Tokarev wrote: I'm trying to "glue" hibernation and UPS control together, and have a question. When the system power comes off an UPS (Uninterruptable Power Supply I mean), it's probably a good idea to turn the UPS off when shutting the system down or hibernating. Even with shutdown (not related to hibernating) there's an interesting twist: modern systems can remember the previous on/off status when the power gets cut and restores - BIOS-controlled option that allows the system to automatically start when the input power returns. Now, when we shutting down a system, we need to turn the UPS *before* powering down the system but *after* the shutdown procedure has been completed. This is done by replacing poweroff with halt, and ordering the UPS to turn itself off after a small delay (needed for the poweroff command to complete) - this way, system will be on but in a safe-to-powercut mode, and in order to turn it back on only the UPS has to be turned on. But the question comes as how to control the UPS when we replace shutdown with hibernation. Ideally I want to send some commands to the UPS after hibernation has been completed (since I don't know how much time it will require to hibernate), but before the machine will be turned off by the kernel. Or at the very least, to be able to stop the kernel turning the machine off after hibernation process is complete - this way, I can order the UPS to turn the power off after some delay and hope hibernation process will finish when the UPS will finally cut the power (not all UPSes are able to do timely shutdown like this). What's my way here? That should be doable. How is your UPS connected? Presumably, with some modifications to the appropriate driver, we could send the commands when we're ready to shutdown. It would probably be useful whether or not your hibernating (if not, sending the commands could always be made an option). 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: hibernate/suspend-to-disk: to turn power or not?
Hi. Michael Tokarev wrote: I'm trying to glue hibernation and UPS control together, and have a question. When the system power comes off an UPS (Uninterruptable Power Supply I mean), it's probably a good idea to turn the UPS off when shutting the system down or hibernating. Even with shutdown (not related to hibernating) there's an interesting twist: modern systems can remember the previous on/off status when the power gets cut and restores - BIOS-controlled option that allows the system to automatically start when the input power returns. Now, when we shutting down a system, we need to turn the UPS *before* powering down the system but *after* the shutdown procedure has been completed. This is done by replacing poweroff with halt, and ordering the UPS to turn itself off after a small delay (needed for the poweroff command to complete) - this way, system will be on but in a safe-to-powercut mode, and in order to turn it back on only the UPS has to be turned on. But the question comes as how to control the UPS when we replace shutdown with hibernation. Ideally I want to send some commands to the UPS after hibernation has been completed (since I don't know how much time it will require to hibernate), but before the machine will be turned off by the kernel. Or at the very least, to be able to stop the kernel turning the machine off after hibernation process is complete - this way, I can order the UPS to turn the power off after some delay and hope hibernation process will finish when the UPS will finally cut the power (not all UPSes are able to do timely shutdown like this). What's my way here? That should be doable. How is your UPS connected? Presumably, with some modifications to the appropriate driver, we could send the commands when we're ready to shutdown. It would probably be useful whether or not your hibernating (if not, sending the commands could always be made an option). 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: hibernate/suspend-to-disk: to turn power or not?
Hi Michael. Michael Tokarev wrote: Nigel Cunningham wrote: [] That should be doable. How is your UPS connected? Presumably, with some modifications to the appropriate driver, we could send the commands when we're ready to shutdown. It would probably be useful whether or not your hibernating (if not, sending the commands could always be made an option). You mean adding stuff to some KERNEL driver? Like to a serial driver if the UPS is connected to a COM-port?? I'm afraid either I don't understand what you're talking about here, or, if I got you right, that YOU don't understand what you're talking about... Come on, teaching kernel about various idiotic UPSes out there is more than insane... ;) I wasn't meaning the kernel should have to know about various idiotic UPSses (yes, I've got experience with them too, so I understand what you're talking about there). What I was thinking was that maybe it might be possible to give the kernel some simple (configurable) string to send out the UPS port when it's time to power off. Of course you're going to point out that a simple string won't do in every case (though I think it would do for at least some of the idiotic UPS ones). I was just wondering aloud if there was a simpler way, but on further reflection, I guess there's no way around it. Whether this is done with kexec, uswsusp or TuxOnIce, it's going to involve creating (TuxOnIce / kexec ) or extending a userspace (uswsusp) binary that's got to somehow interface with the driver and get the job done. 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: echo mem > /sys/power/state
Hi. Rafael J. Wysocki wrote: > On Thursday, 17 of January 2008, Andrew Morton wrote: >> On Thu, 17 Jan 2008 10:36:51 -0700 Zan Lynx <[EMAIL PROTECTED]> wrote: >> >>> On Wed, 2008-01-16 at 22:24 -0800, Andrew Morton wrote: So I take everyone's latest and greatest product and injudiciously type the above command. The result five minutes later is at http://userweb.kernel.org/~akpm/borkage.jpg. See if you can count all the bugs. Sorry, but I've had it with this stuff and I'm tired of fixing everyone else's stuff. I'm just going to ship it. Good luck. >>> Heh. Laptop suspend to anything has been so broken for so long in the >>> -mm series on my Compaq R3000 that I didn't even know it was ever >>> supposed to work. >> It gets broken more often than anything else. I do test each release on >> two laptops and I get to do a lot of bisection searching and >> grumpygramming as a result. >> >> Probably it would be more efficient to have the people who wrote the code >> also test it. > > Well, that would certainly help. > > I do test all of my patches and generally all of the patches I sign off, but > surely that's not enough. It is far too easy to take a cursory glance, say 'That looks okay' and move on to the next thing, isn't it? I was horrified when I saw the list of acks etc (including me) on the commit with the helper_unlock issue we just fixed. It's truly scary to think that none of us looked closely enough to pick that up at the time. 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: echo mem /sys/power/state
Hi. Rafael J. Wysocki wrote: On Thursday, 17 of January 2008, Andrew Morton wrote: On Thu, 17 Jan 2008 10:36:51 -0700 Zan Lynx [EMAIL PROTECTED] wrote: On Wed, 2008-01-16 at 22:24 -0800, Andrew Morton wrote: So I take everyone's latest and greatest product and injudiciously type the above command. The result five minutes later is at http://userweb.kernel.org/~akpm/borkage.jpg. See if you can count all the bugs. Sorry, but I've had it with this stuff and I'm tired of fixing everyone else's stuff. I'm just going to ship it. Good luck. Heh. Laptop suspend to anything has been so broken for so long in the -mm series on my Compaq R3000 that I didn't even know it was ever supposed to work. It gets broken more often than anything else. I do test each release on two laptops and I get to do a lot of bisection searching and grumpygramming as a result. Probably it would be more efficient to have the people who wrote the code also test it. Well, that would certainly help. I do test all of my patches and generally all of the patches I sign off, but surely that's not enough. It is far too easy to take a cursory glance, say 'That looks okay' and move on to the next thing, isn't it? I was horrified when I saw the list of acks etc (including me) on the commit with the helper_unlock issue we just fixed. It's truly scary to think that none of us looked closely enough to pick that up at the time. 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/
[PATCH] (2.4.25 material?) Fix unbalanced helper_lock in kernel/kmod.c
Hi all.
First up, sorry for not inlining the patch - trouble with line wrapping.
In 2.6.24-rc8, call_usermodehelper_exec has an exit path that can leave
the helper_lock() call at the top of the routine unbalanced. The
attached patch fixes this issue.
Signed-off-by: Nigel Cunningham <[EMAIL PROTECTED]>
diff --git a/kernel/kmod.c b/kernel/kmod.c
index c6a4f8a..de27e15 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -468,8 +468,10 @@ int call_usermodehelper_exec(struct subprocess_info *sub_info,
sub_info->wait = wait;
queue_work(khelper_wq, _info->work);
- if (wait == UMH_NO_WAIT) /* task has freed sub_info */
+ if (wait == UMH_NO_WAIT) { /* task has freed sub_info */
+ helper_unlock();
return 0;
+ }
wait_for_completion();
retval = sub_info->retval;
[PATCH] (2.4.25 material?) Fix unbalanced helper_lock in kernel/kmod.c
Hi all.
First up, sorry for not inlining the patch - trouble with line wrapping.
In 2.6.24-rc8, call_usermodehelper_exec has an exit path that can leave
the helper_lock() call at the top of the routine unbalanced. The
attached patch fixes this issue.
Signed-off-by: Nigel Cunningham [EMAIL PROTECTED]
diff --git a/kernel/kmod.c b/kernel/kmod.c
index c6a4f8a..de27e15 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -468,8 +468,10 @@ int call_usermodehelper_exec(struct subprocess_info *sub_info,
sub_info-wait = wait;
queue_work(khelper_wq, sub_info-work);
- if (wait == UMH_NO_WAIT) /* task has freed sub_info */
+ if (wait == UMH_NO_WAIT) { /* task has freed sub_info */
+ helper_unlock();
return 0;
+ }
wait_for_completion(done);
retval = sub_info-retval;
Re: [patch 7/9] unprivileged mounts: allow unprivileged fuse mounts
Hi. Miklos Szeredi wrote: On Tue 2008-01-08 12:35:09, Miklos Szeredi wrote: > From: Miklos Szeredi <[EMAIL PROTECTED]> > > Use FS_SAFE for "fuse" fs type, but not for "fuseblk". > > FUSE was designed from the beginning to be safe for unprivileged users. > This > has also been verified in practice over many years. In addition > unprivileged Eh? So 'kill -9 no longer works' and 'suspend no longer works' is not considered important enough to even mention? >>> No. Because in practice they don't seem to matter. Also because >>> there's no way in which fuse could be done differently to address >>> these issues. >> Could you clarify, please? I hope I'm getting the wrong end of the stick >> - it sounds to me like you and Pavel are saying that this patch breaks >> suspending to ram (and hibernating?) but you want to push it anyway >> because you haven't been able to produce an instance, don't think >> suspending or hibernating matter and couldn't fix fuse anyway? > > This patch has nothing to do with suspend or hibernate. What this > patchset does, is help get rid of fusermount, a suid-root mount > helper. It also opens up new possibilities, which are not fuse > related. That's what I thought. So what was Pavel talking about with "kill -9 no longer works" and "suspend no longer works" above? I couldn't understand it from the context. > Fuse has bad interactions with the freezer, theoretically. In > practice, I remember just one bug report (that sparked off this whole > "do we need freezer, or don't we" flamefest), that actually got fixed > fairly quickly, ...maybe. Rafael probably remembers better. I think they just gave up and considered it unsolvable. I'm not sure it is. >>> The 'kill -9' thing is basically due to VFS level locking not being >>> interruptible. It could be changed, but I'm not sure it's worth it. >>> >>> For the suspend issue, there are also no easy solutions. >> What are the non-easy solutions? > > The ability to freeze tasks in uninterruptible sleep, or more > generally at any preempt point (except when drivers are poking > hardware). Couldn't some sort of scheduler based solution deal with the uninterruptible sleeping case? > I know this doesn't play well with userspace hibernate, and I don't > think it can be resolved without going the kexec way. I can see the desirability of kexec when it comes to avoiding the freezer, but comes with its own problems too - having the original context usable is handy, not having to set aside a large amount of space for a second kernel is also desirable and there are still greater issues of transferring information backwards and forwards between the two kernels. 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: [patch 7/9] unprivileged mounts: allow unprivileged fuse mounts
Hi. Miklos Szeredi wrote: On Tue 2008-01-08 12:35:09, Miklos Szeredi wrote: From: Miklos Szeredi [EMAIL PROTECTED] Use FS_SAFE for fuse fs type, but not for fuseblk. FUSE was designed from the beginning to be safe for unprivileged users. This has also been verified in practice over many years. In addition unprivileged Eh? So 'kill -9 no longer works' and 'suspend no longer works' is not considered important enough to even mention? No. Because in practice they don't seem to matter. Also because there's no way in which fuse could be done differently to address these issues. Could you clarify, please? I hope I'm getting the wrong end of the stick - it sounds to me like you and Pavel are saying that this patch breaks suspending to ram (and hibernating?) but you want to push it anyway because you haven't been able to produce an instance, don't think suspending or hibernating matter and couldn't fix fuse anyway? This patch has nothing to do with suspend or hibernate. What this patchset does, is help get rid of fusermount, a suid-root mount helper. It also opens up new possibilities, which are not fuse related. That's what I thought. So what was Pavel talking about with kill -9 no longer works and suspend no longer works above? I couldn't understand it from the context. Fuse has bad interactions with the freezer, theoretically. In practice, I remember just one bug report (that sparked off this whole do we need freezer, or don't we flamefest), that actually got fixed fairly quickly, ...maybe. Rafael probably remembers better. I think they just gave up and considered it unsolvable. I'm not sure it is. The 'kill -9' thing is basically due to VFS level locking not being interruptible. It could be changed, but I'm not sure it's worth it. For the suspend issue, there are also no easy solutions. What are the non-easy solutions? The ability to freeze tasks in uninterruptible sleep, or more generally at any preempt point (except when drivers are poking hardware). Couldn't some sort of scheduler based solution deal with the uninterruptible sleeping case? I know this doesn't play well with userspace hibernate, and I don't think it can be resolved without going the kexec way. I can see the desirability of kexec when it comes to avoiding the freezer, but comes with its own problems too - having the original context usable is handy, not having to set aside a large amount of space for a second kernel is also desirable and there are still greater issues of transferring information backwards and forwards between the two kernels. 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: [patch 7/9] unprivileged mounts: allow unprivileged fuse mounts
Hi. Miklos Szeredi wrote: >> On Tue 2008-01-08 12:35:09, Miklos Szeredi wrote: >>> From: Miklos Szeredi <[EMAIL PROTECTED]> >>> >>> Use FS_SAFE for "fuse" fs type, but not for "fuseblk". >>> >>> FUSE was designed from the beginning to be safe for unprivileged users. >>> This >>> has also been verified in practice over many years. In addition >>> unprivileged >> Eh? So 'kill -9 no longer works' and 'suspend no longer works' is not >> considered important enough to even mention? > > No. Because in practice they don't seem to matter. Also because > there's no way in which fuse could be done differently to address > these issues. Could you clarify, please? I hope I'm getting the wrong end of the stick - it sounds to me like you and Pavel are saying that this patch breaks suspending to ram (and hibernating?) but you want to push it anyway because you haven't been able to produce an instance, don't think suspending or hibernating matter and couldn't fix fuse anyway? > The 'kill -9' thing is basically due to VFS level locking not being > interruptible. It could be changed, but I'm not sure it's worth it. > > For the suspend issue, there are also no easy solutions. What are the non-easy solutions? 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: [patch 7/9] unprivileged mounts: allow unprivileged fuse mounts
Hi. Miklos Szeredi wrote: On Tue 2008-01-08 12:35:09, Miklos Szeredi wrote: From: Miklos Szeredi [EMAIL PROTECTED] Use FS_SAFE for fuse fs type, but not for fuseblk. FUSE was designed from the beginning to be safe for unprivileged users. This has also been verified in practice over many years. In addition unprivileged Eh? So 'kill -9 no longer works' and 'suspend no longer works' is not considered important enough to even mention? No. Because in practice they don't seem to matter. Also because there's no way in which fuse could be done differently to address these issues. Could you clarify, please? I hope I'm getting the wrong end of the stick - it sounds to me like you and Pavel are saying that this patch breaks suspending to ram (and hibernating?) but you want to push it anyway because you haven't been able to produce an instance, don't think suspending or hibernating matter and couldn't fix fuse anyway? The 'kill -9' thing is basically due to VFS level locking not being interruptible. It could be changed, but I'm not sure it's worth it. For the suspend issue, there are also no easy solutions. What are the non-easy solutions? 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: Oops in evdev_disconnect for kernel 2.6.23.12
Hi. Berthold Cogel wrote: > Al Viro schrieb: >> On Tue, Jan 01, 2008 at 08:26:05PM +0100, Berthold Cogel wrote: >> >>> Jan 1 17:34:39 wonderland kernel: BUG: unable to handle kernel >>> paging request at virtual address 00100100 >> >> LIST_POISON1 >> >>> Jan 1 17:34:39 wonderland kernel: EIP is at evdev_disconnect+0x65/0x9e >> >> and by the look of code, it's a bit before the call of something that >> gets >> 0x20006 as one of its arguments. Which, by the look of evdev.s, gets >> passed only to kill_fasync(). So it's POLL_HUP, so this code could be >> these days: >> spin_lock(>client_lock); >> list_for_each_entry(client, >client_list, node) >> kill_fasync(>fasync, SIGIO, POLL_HUP); >> spin_unlock(>client_lock); >> in evdev_hangup() >> prior to commit 6addb1d6de1968b84852f54561cc9a09b5a9: >> list_for_each_entry(client, >client_list, node) >> kill_fasync(>fasync, SIGIO, POLL_HUP); >> in evdev_disconnect() >> >> >>> I'm using Debian stable/testing/unstable with homemade kernel >>> 2.6.23.12 (patched with tuxonice-3.0-rc3-for-2.6.23.9). >> >> ... and seeing that this changeset postdates 2.6.23 *and* adds locking to >> the lists we are traversing in either variant, I'd bet that the kernel >> you >> have does *NOT* have the changeset in question, that you have list >> corruption >> from race and that your oops is list_for_each_entry() trying to walk >> forward from entry that just had list_del() poisoning its ->next. >> >> There are only 4 changesets between 2.6.23 and this one affecting >> drivers/input >> and only >> 8006479c9b75fb6594a7b746af3d7f1fbb68f18f and >> 6addb1d6de1968b84852f54561cc9a09b5a9 >> appear to be relevant. Apply to your kernel and see if it helps... > > Looks as if I have to start using git ... I always feared that this day > will come. ;-) > > If I'm able to reproduce the oops with my patched kernel, I will gladly > follow your advice. > > Regards, > > Berthold I can't do it immediately but I'll send you the patches to try a later in the day if you like. 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: freeze vs freezer
Hi. Pavel Machek wrote: > On Fri 2008-01-04 21:54:06, Oliver Neukum wrote: >> Am Donnerstag, 3. Januar 2008 23:06:07 schrieb Nigel Cunningham: >>> Oliver Neukum wrote: >>>> Am Donnerstag, 3. Januar 2008 10:52:53 schrieb Nigel Cunningham: >>>>> Oliver Neukum wrote: >>>>>> Am Donnerstag 03 Januar 2008 schrieb Nigel Cunningham: >>>>>>> On top of this, I made a (too simple at the moment) freeze_filesystems >>>>>>> function which iterates through _blocks in reverse order, freezing >>>>>>> fuse filesystems or ordinary ones. I say 'too simple' because it doesn't >>>>>>> currently allow for the possibility of someone mounting (say) ext3 on >>>>>>> fuse, but that would just be an extension of what's already done. >>>>>> How do you deal with fuse server tasks using other fuse filesystems? >>>>> Since they're frozen in reverse order, the dependant one would be frozen >>>>> first. >>>> Say I do: >>>> >>>> a) mount fuse on /tmp/first >>>> b) mount fuse on /tmp/second >>>> >>>> Then the server task for (a) does "ls /tmp/second". So it will be frozen, >>>> right? How do you then freeze (a)? And keep in mind that the server task >>>> may have forked. >>> I guess I should first ask, is this a real life problem or a >>> hypothetical twisted web? I don't see why you would want to make two >>> filesystems interdependent - it sounds like the way to create livelock >>> and deadlocks in normal use, before we even begin to think about >>> hibernating. >> Good questions. I personally don't use fuse, but I do care about power >> management. The problem I see is that an unprivileged user could make >> that dependency, even inadvertedly. > > Other problem is that unprivileged user can do it with evil intent. So > called "denial-of-service" attack. Only in this case it would be a denial-of-denial-of-service attack, since it would stop you hibernating or suspending :). This is still all hypothetical. If I could have a real life case where this could actually happen, it would help a lot. 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: freeze vs freezer
Hi. Pavel Machek wrote: On Fri 2008-01-04 21:54:06, Oliver Neukum wrote: Am Donnerstag, 3. Januar 2008 23:06:07 schrieb Nigel Cunningham: Oliver Neukum wrote: Am Donnerstag, 3. Januar 2008 10:52:53 schrieb Nigel Cunningham: Oliver Neukum wrote: Am Donnerstag 03 Januar 2008 schrieb Nigel Cunningham: On top of this, I made a (too simple at the moment) freeze_filesystems function which iterates through super_blocks in reverse order, freezing fuse filesystems or ordinary ones. I say 'too simple' because it doesn't currently allow for the possibility of someone mounting (say) ext3 on fuse, but that would just be an extension of what's already done. How do you deal with fuse server tasks using other fuse filesystems? Since they're frozen in reverse order, the dependant one would be frozen first. Say I do: a) mount fuse on /tmp/first b) mount fuse on /tmp/second Then the server task for (a) does ls /tmp/second. So it will be frozen, right? How do you then freeze (a)? And keep in mind that the server task may have forked. I guess I should first ask, is this a real life problem or a hypothetical twisted web? I don't see why you would want to make two filesystems interdependent - it sounds like the way to create livelock and deadlocks in normal use, before we even begin to think about hibernating. Good questions. I personally don't use fuse, but I do care about power management. The problem I see is that an unprivileged user could make that dependency, even inadvertedly. Other problem is that unprivileged user can do it with evil intent. So called denial-of-service attack. Only in this case it would be a denial-of-denial-of-service attack, since it would stop you hibernating or suspending :). This is still all hypothetical. If I could have a real life case where this could actually happen, it would help a lot. 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: Oops in evdev_disconnect for kernel 2.6.23.12
Hi. Berthold Cogel wrote: Al Viro schrieb: On Tue, Jan 01, 2008 at 08:26:05PM +0100, Berthold Cogel wrote: Jan 1 17:34:39 wonderland kernel: BUG: unable to handle kernel paging request at virtual address 00100100 LIST_POISON1 Jan 1 17:34:39 wonderland kernel: EIP is at evdev_disconnect+0x65/0x9e and by the look of code, it's a bit before the call of something that gets 0x20006 as one of its arguments. Which, by the look of evdev.s, gets passed only to kill_fasync(). So it's POLL_HUP, so this code could be these days: spin_lock(evdev-client_lock); list_for_each_entry(client, evdev-client_list, node) kill_fasync(client-fasync, SIGIO, POLL_HUP); spin_unlock(evdev-client_lock); in evdev_hangup() prior to commit 6addb1d6de1968b84852f54561cc9a09b5a9: list_for_each_entry(client, evdev-client_list, node) kill_fasync(client-fasync, SIGIO, POLL_HUP); in evdev_disconnect() I'm using Debian stable/testing/unstable with homemade kernel 2.6.23.12 (patched with tuxonice-3.0-rc3-for-2.6.23.9). ... and seeing that this changeset postdates 2.6.23 *and* adds locking to the lists we are traversing in either variant, I'd bet that the kernel you have does *NOT* have the changeset in question, that you have list corruption from race and that your oops is list_for_each_entry() trying to walk forward from entry that just had list_del() poisoning its -next. There are only 4 changesets between 2.6.23 and this one affecting drivers/input and only 8006479c9b75fb6594a7b746af3d7f1fbb68f18f and 6addb1d6de1968b84852f54561cc9a09b5a9 appear to be relevant. Apply to your kernel and see if it helps... Looks as if I have to start using git ... I always feared that this day will come. ;-) If I'm able to reproduce the oops with my patched kernel, I will gladly follow your advice. Regards, Berthold I can't do it immediately but I'll send you the patches to try a later in the day if you like. 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: freeze vs freezer
Hi. Oliver Neukum wrote: > Am Donnerstag, 3. Januar 2008 10:52:53 schrieb Nigel Cunningham: >> Hi. >> >> Oliver Neukum wrote: >>> Am Donnerstag 03 Januar 2008 schrieb Nigel Cunningham: >>>> On top of this, I made a (too simple at the moment) freeze_filesystems >>>> function which iterates through _blocks in reverse order, freezing >>>> fuse filesystems or ordinary ones. I say 'too simple' because it doesn't >>>> currently allow for the possibility of someone mounting (say) ext3 on >>>> fuse, but that would just be an extension of what's already done. >>> How do you deal with fuse server tasks using other fuse filesystems? >> Since they're frozen in reverse order, the dependant one would be frozen >> first. > > Say I do: > > a) mount fuse on /tmp/first > b) mount fuse on /tmp/second > > Then the server task for (a) does "ls /tmp/second". So it will be frozen, > right? How do you then freeze (a)? And keep in mind that the server task > may have forked. I guess I should first ask, is this a real life problem or a hypothetical twisted web? I don't see why you would want to make two filesystems interdependent - it sounds like the way to create livelock and deadlocks in normal use, before we even begin to think about hibernating. 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: freeze vs freezer
Hi.
Oliver Neukum wrote:
> Am Donnerstag 03 Januar 2008 schrieb Nigel Cunningham:
>> On top of this, I made a (too simple at the moment) freeze_filesystems
>> function which iterates through _blocks in reverse order, freezing
>> fuse filesystems or ordinary ones. I say 'too simple' because it doesn't
>> currently allow for the possibility of someone mounting (say) ext3 on
>> fuse, but that would just be an extension of what's already done.
>
> How do you deal with fuse server tasks using other fuse filesystems?
Since they're frozen in reverse order, the dependant one would be frozen
first.
> How does freeze_filesystems() look?
Removing my ugly debugging statements, it's currently:
/**
* freeze_filesystems - lock all filesystems and force them into a
consistent
* state
*/
void freeze_filesystems(int which)
{
struct super_block *sb;
lockdep_off();
/*
* Freeze in reverse order so filesystems dependant upon others are
* frozen in the right order (eg. loopback on ext3).
*/
list_for_each_entry_reverse(sb, _blocks, s_list) {
if (sb->s_type->fs_flags & FS_IS_FUSE &&
sb->s_frozen == SB_UNFROZEN &&
which & FS_FREEZER_FUSE) {
sb->s_frozen = SB_FREEZE_TRANS;
sb->s_flags |= MS_FROZEN;
continue;
}
if (!sb->s_root || !sb->s_bdev ||
(sb->s_frozen == SB_FREEZE_TRANS) ||
(sb->s_flags & MS_RDONLY) ||
(sb->s_flags & MS_FROZEN) ||
!(which & FS_FREEZER_NORMAL))
continue;
freeze_bdev(sb->s_bdev);
sb->s_flags |= MS_FROZEN;
}
lockdep_on();
}
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: freeze vs freezer
Hi.
Rafael J. Wysocki wrote:
> On Wednesday, 2 of January 2008, Nigel Cunningham wrote:
>> Pavel Machek wrote:
>>>>>>>> So how do you handle threads that are blocked on I/O or a lock
>>>>>>>> during the system freeze process, then?
>>>>>>> We wait until they can continue.
>>>>>> So if I have a process blocked on an unavilable NFS mount, I can't
>>>>>> suspend?
>>>>> That's correct, you can't.
>>>>>
>>>>> [And I know what you're going to say. ;-)]
>>>> Why exactly does suspend/hibernation depend on "TASK_INTERRUPTIBLE"
>>>> instead of a zero preempt_count()? Really what we should do is just
>>>> iterate over all of the actual physical devices and tell each one
>>>> "Block new IO requests preemptably, finish pending DMA, put the
>>>> hardware in low-power mode, and prepare for suspend/hibernate". As
>>>> long as each driver knows how to do those simple things we can have
>>>> an entirely consistent kernel image for both suspend and for
>>>> hibernation.
>>> "each driver" means this is a lot of work. But yes, that is probably
>>> way to go, and patch would be welcome.
>> Yes, that does work. It's what I've done in my (preliminary) support for
>> fuse.
>
> Hmm, can you please elaborate a bit?
Sorry. I wasn't very unambiguous, was I? And I'm not sure now whether
you're meaning "How does fuse support relate to freezing block devices?"
or "What's this about fuse support?". Let me therefore seek to answer
both questions:
Higher level, I know (filesystems rather than block devices), but I was
meaning the general concept of blocking new requests and completing
existing ones worked fine for the supposedly impossible fuse support.
Re fuse support, let me start by saying "I know this doesn't handle all
situations, but I think it's a good enough proof-of-concept implementation".
I added some simple hooks to the code for submitting new work to fuse
threads.
#define FUSE_MIGHT_FREEZE(superblock, desc) \
do { \
int printed = 0; \
while(superblock->s_frozen != SB_UNFROZEN) { \
if (!printed) { \
printk("%d frozen in " desc ".\n", current->pid); \
printed = 1; \
} \
try_to_freeze(); \
yield(); \
} \
} while (0)
On top of this, I made a (too simple at the moment) freeze_filesystems
function which iterates through _blocks in reverse order, freezing
fuse filesystems or ordinary ones. I say 'too simple' because it doesn't
currently allow for the possibility of someone mounting (say) ext3 on
fuse, but that would just be an extension of what's already done.
The end result is:
int freeze_processes(void)
{
int error;
printk(KERN_INFO "Stopping fuse filesystems.\n");
freeze_filesystems(FS_FREEZER_FUSE);
freezer_state = FREEZER_FILESYSTEMS_FROZEN;
printk(KERN_INFO "Freezing user space processes ... ");
error = try_to_freeze_tasks(FREEZER_USER_SPACE);
if (error)
goto Exit;
printk(KERN_INFO "done.\n");
sys_sync();
printk(KERN_INFO "Stopping normal filesystems.\n");
freeze_filesystems(FS_FREEZER_NORMAL);
freezer_state = FREEZER_USERSPACE_FROZEN;
printk(KERN_INFO "Freezing remaining freezable tasks ... ");
error = try_to_freeze_tasks(FREEZER_KERNEL_THREADS);
if (error)
goto Exit;
printk(KERN_INFO "done.");
freezer_state = FREEZER_FULLY_ON;
Exit:
BUG_ON(in_atomic());
printk("\n");
return error;
}
Sorry if that's more info than you wanted.
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: freeze vs freezer
Hi.
Rafael J. Wysocki wrote:
On Wednesday, 2 of January 2008, Nigel Cunningham wrote:
Pavel Machek wrote:
So how do you handle threads that are blocked on I/O or a lock
during the system freeze process, then?
We wait until they can continue.
So if I have a process blocked on an unavilable NFS mount, I can't
suspend?
That's correct, you can't.
[And I know what you're going to say. ;-)]
Why exactly does suspend/hibernation depend on TASK_INTERRUPTIBLE
instead of a zero preempt_count()? Really what we should do is just
iterate over all of the actual physical devices and tell each one
Block new IO requests preemptably, finish pending DMA, put the
hardware in low-power mode, and prepare for suspend/hibernate. As
long as each driver knows how to do those simple things we can have
an entirely consistent kernel image for both suspend and for
hibernation.
each driver means this is a lot of work. But yes, that is probably
way to go, and patch would be welcome.
Yes, that does work. It's what I've done in my (preliminary) support for
fuse.
Hmm, can you please elaborate a bit?
Sorry. I wasn't very unambiguous, was I? And I'm not sure now whether
you're meaning How does fuse support relate to freezing block devices?
or What's this about fuse support?. Let me therefore seek to answer
both questions:
Higher level, I know (filesystems rather than block devices), but I was
meaning the general concept of blocking new requests and completing
existing ones worked fine for the supposedly impossible fuse support.
Re fuse support, let me start by saying I know this doesn't handle all
situations, but I think it's a good enough proof-of-concept implementation.
I added some simple hooks to the code for submitting new work to fuse
threads.
#define FUSE_MIGHT_FREEZE(superblock, desc) \
do { \
int printed = 0; \
while(superblock-s_frozen != SB_UNFROZEN) { \
if (!printed) { \
printk(%d frozen in desc .\n, current-pid); \
printed = 1; \
} \
try_to_freeze(); \
yield(); \
} \
} while (0)
On top of this, I made a (too simple at the moment) freeze_filesystems
function which iterates through super_blocks in reverse order, freezing
fuse filesystems or ordinary ones. I say 'too simple' because it doesn't
currently allow for the possibility of someone mounting (say) ext3 on
fuse, but that would just be an extension of what's already done.
The end result is:
int freeze_processes(void)
{
int error;
printk(KERN_INFO Stopping fuse filesystems.\n);
freeze_filesystems(FS_FREEZER_FUSE);
freezer_state = FREEZER_FILESYSTEMS_FROZEN;
printk(KERN_INFO Freezing user space processes ... );
error = try_to_freeze_tasks(FREEZER_USER_SPACE);
if (error)
goto Exit;
printk(KERN_INFO done.\n);
sys_sync();
printk(KERN_INFO Stopping normal filesystems.\n);
freeze_filesystems(FS_FREEZER_NORMAL);
freezer_state = FREEZER_USERSPACE_FROZEN;
printk(KERN_INFO Freezing remaining freezable tasks ... );
error = try_to_freeze_tasks(FREEZER_KERNEL_THREADS);
if (error)
goto Exit;
printk(KERN_INFO done.);
freezer_state = FREEZER_FULLY_ON;
Exit:
BUG_ON(in_atomic());
printk(\n);
return error;
}
Sorry if that's more info than you wanted.
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: freeze vs freezer
Hi.
Oliver Neukum wrote:
Am Donnerstag 03 Januar 2008 schrieb Nigel Cunningham:
On top of this, I made a (too simple at the moment) freeze_filesystems
function which iterates through super_blocks in reverse order, freezing
fuse filesystems or ordinary ones. I say 'too simple' because it doesn't
currently allow for the possibility of someone mounting (say) ext3 on
fuse, but that would just be an extension of what's already done.
How do you deal with fuse server tasks using other fuse filesystems?
Since they're frozen in reverse order, the dependant one would be frozen
first.
How does freeze_filesystems() look?
Removing my ugly debugging statements, it's currently:
/**
* freeze_filesystems - lock all filesystems and force them into a
consistent
* state
*/
void freeze_filesystems(int which)
{
struct super_block *sb;
lockdep_off();
/*
* Freeze in reverse order so filesystems dependant upon others are
* frozen in the right order (eg. loopback on ext3).
*/
list_for_each_entry_reverse(sb, super_blocks, s_list) {
if (sb-s_type-fs_flags FS_IS_FUSE
sb-s_frozen == SB_UNFROZEN
which FS_FREEZER_FUSE) {
sb-s_frozen = SB_FREEZE_TRANS;
sb-s_flags |= MS_FROZEN;
continue;
}
if (!sb-s_root || !sb-s_bdev ||
(sb-s_frozen == SB_FREEZE_TRANS) ||
(sb-s_flags MS_RDONLY) ||
(sb-s_flags MS_FROZEN) ||
!(which FS_FREEZER_NORMAL))
continue;
freeze_bdev(sb-s_bdev);
sb-s_flags |= MS_FROZEN;
}
lockdep_on();
}
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: freeze vs freezer
Hi. Oliver Neukum wrote: Am Donnerstag, 3. Januar 2008 10:52:53 schrieb Nigel Cunningham: Hi. Oliver Neukum wrote: Am Donnerstag 03 Januar 2008 schrieb Nigel Cunningham: On top of this, I made a (too simple at the moment) freeze_filesystems function which iterates through super_blocks in reverse order, freezing fuse filesystems or ordinary ones. I say 'too simple' because it doesn't currently allow for the possibility of someone mounting (say) ext3 on fuse, but that would just be an extension of what's already done. How do you deal with fuse server tasks using other fuse filesystems? Since they're frozen in reverse order, the dependant one would be frozen first. Say I do: a) mount fuse on /tmp/first b) mount fuse on /tmp/second Then the server task for (a) does ls /tmp/second. So it will be frozen, right? How do you then freeze (a)? And keep in mind that the server task may have forked. I guess I should first ask, is this a real life problem or a hypothetical twisted web? I don't see why you would want to make two filesystems interdependent - it sounds like the way to create livelock and deadlocks in normal use, before we even begin to think about hibernating. 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: [Suspend2-users] [Suspend2-devel] Freezing filesystems (Was Re: What's in store for 2008 for TuxOnIce?)
Hi Martin. Martin Steigerwald wrote: > Am Mittwoch 02 Januar 2008 schrieb Nigel Cunningham: >> Hi. > > Hi, > >> Rafael J. Wysocki wrote: >>> On Wednesday, 2 of January 2008, Theodore Tso wrote: >>>> On Wed, Jan 02, 2008 at 10:54:18AM +1100, Nigel Cunningham >>>> wrote: >>>>>> I would also like the TuxOnIce issues related to drivers, >>>>>> ACPI, etc. to go to one of the kernel-related lists, but I >>>>>> think linux-pm may be better for that due to the much lower >>>>>> traffic. >>>>> I guess that makes sense. I guess people can always be >>>>> referred to LKML for the issues where the appropriate person >>>>> isn't on linux-pm. >>>> Hi Nigel, >>>> >>>> I'd really recommend pushing the TuxOnIce discussions to LKML. >>> CCing linux-pm (or even linux-acpi) on problem reports would >>> still be recommended, though. :-) >> Right. And that may make things easier as far as TuxOnIce users go >> too. I have one user who currently subscribes to suspend2-users who >> already tried subscribing to LKML and said he didn't like the >> experience. Using linux-pm instead would save some pain there. > > I am a bit reluctant about LKML from some of the discussions I have > seen there and participated in during CFS / CK discussion. I really > didn't like the tone. Its one thing to say ones own oppinion, another > one to bash at each other as if there was no tomorrow. > > This has been refreshingly different on tuxonice mailing lists. I am > also a bit reluctant about the traffic. I already have some quite > high traffic mailinglists with 3-4 mails a year, but LKML > would top these easily I guess and I am not that sure I want to put > that load on my mail infrastructure to follow TuxOnIce developments. > I think this is a generic problem for testers of specific kernel > subsystems... > > But then LKML is were TuxOnIce is visible to the kernel developer > community. > > I would appreciate linux-pm I think maybe with a guideline to CC to > LKML in usual cases... Thanks for your feedback. I think that's the way to go. > BTW: toi-3.0-rc3 is rocking along nicely on my two ThinkPads (T42 and > T23)... I am using 2.6.23.12 with cfs-v24.1... Great to hear! 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: freeze vs freezer
Hi. Pavel Machek wrote: > Hi! > >> So how do you handle threads that are blocked on I/O or a lock >> during the system freeze process, then? > We wait until they can continue. So if I have a process blocked on an unavilable NFS mount, I can't suspend? >>> That's correct, you can't. >>> >>> [And I know what you're going to say. ;-)] >> Why exactly does suspend/hibernation depend on "TASK_INTERRUPTIBLE" >> instead of a zero preempt_count()? Really what we should do is just >> iterate over all of the actual physical devices and tell each one >> "Block new IO requests preemptably, finish pending DMA, put the >> hardware in low-power mode, and prepare for suspend/hibernate". As >> long as each driver knows how to do those simple things we can have >> an entirely consistent kernel image for both suspend and for >> hibernation. > > "each driver" means this is a lot of work. But yes, that is probably > way to go, and patch would be welcome. Yes, that does work. It's what I've done in my (preliminary) support for fuse. 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: [Suspend2-devel] Freezing filesystems (Was Re: What's in store for 2008 for TuxOnIce?)
Hi. Rafael J. Wysocki wrote: > On Wednesday, 2 of January 2008, Theodore Tso wrote: >> On Wed, Jan 02, 2008 at 10:54:18AM +1100, Nigel Cunningham wrote: >>>> I would also like the TuxOnIce issues related to drivers, ACPI, etc. to go >>>> to >>>> one of the kernel-related lists, but I think linux-pm may be better for >>>> that >>>> due to the much lower traffic. >>> I guess that makes sense. I guess people can always be referred to LKML >>> for the issues where the appropriate person isn't on linux-pm. >> Hi Nigel, >> >> I'd really recommend pushing the TuxOnIce discussions to LKML. > > CCing linux-pm (or even linux-acpi) on problem reports would still be > recommended, though. :-) Right. And that may make things easier as far as TuxOnIce users go too. I have one user who currently subscribes to suspend2-users who already tried subscribing to LKML and said he didn't like the experience. Using linux-pm instead would save some pain there. 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: [Suspend2-devel] Freezing filesystems (Was Re: What's in store for 2008 for TuxOnIce?)
Hi. Rafael J. Wysocki wrote: On Wednesday, 2 of January 2008, Theodore Tso wrote: On Wed, Jan 02, 2008 at 10:54:18AM +1100, Nigel Cunningham wrote: I would also like the TuxOnIce issues related to drivers, ACPI, etc. to go to one of the kernel-related lists, but I think linux-pm may be better for that due to the much lower traffic. I guess that makes sense. I guess people can always be referred to LKML for the issues where the appropriate person isn't on linux-pm. Hi Nigel, I'd really recommend pushing the TuxOnIce discussions to LKML. CCing linux-pm (or even linux-acpi) on problem reports would still be recommended, though. :-) Right. And that may make things easier as far as TuxOnIce users go too. I have one user who currently subscribes to suspend2-users who already tried subscribing to LKML and said he didn't like the experience. Using linux-pm instead would save some pain there. 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: freeze vs freezer
Hi. Pavel Machek wrote: Hi! So how do you handle threads that are blocked on I/O or a lock during the system freeze process, then? We wait until they can continue. So if I have a process blocked on an unavilable NFS mount, I can't suspend? That's correct, you can't. [And I know what you're going to say. ;-)] Why exactly does suspend/hibernation depend on TASK_INTERRUPTIBLE instead of a zero preempt_count()? Really what we should do is just iterate over all of the actual physical devices and tell each one Block new IO requests preemptably, finish pending DMA, put the hardware in low-power mode, and prepare for suspend/hibernate. As long as each driver knows how to do those simple things we can have an entirely consistent kernel image for both suspend and for hibernation. each driver means this is a lot of work. But yes, that is probably way to go, and patch would be welcome. Yes, that does work. It's what I've done in my (preliminary) support for fuse. 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: [Suspend2-users] [Suspend2-devel] Freezing filesystems (Was Re: What's in store for 2008 for TuxOnIce?)
Hi Martin. Martin Steigerwald wrote: Am Mittwoch 02 Januar 2008 schrieb Nigel Cunningham: Hi. Hi, Rafael J. Wysocki wrote: On Wednesday, 2 of January 2008, Theodore Tso wrote: On Wed, Jan 02, 2008 at 10:54:18AM +1100, Nigel Cunningham wrote: I would also like the TuxOnIce issues related to drivers, ACPI, etc. to go to one of the kernel-related lists, but I think linux-pm may be better for that due to the much lower traffic. I guess that makes sense. I guess people can always be referred to LKML for the issues where the appropriate person isn't on linux-pm. Hi Nigel, I'd really recommend pushing the TuxOnIce discussions to LKML. CCing linux-pm (or even linux-acpi) on problem reports would still be recommended, though. :-) Right. And that may make things easier as far as TuxOnIce users go too. I have one user who currently subscribes to suspend2-users who already tried subscribing to LKML and said he didn't like the experience. Using linux-pm instead would save some pain there. I am a bit reluctant about LKML from some of the discussions I have seen there and participated in during CFS / CK discussion. I really didn't like the tone. Its one thing to say ones own oppinion, another one to bash at each other as if there was no tomorrow. This has been refreshingly different on tuxonice mailing lists. I am also a bit reluctant about the traffic. I already have some quite high traffic mailinglists with 3-4 mails a year, but LKML would top these easily I guess and I am not that sure I want to put that load on my mail infrastructure to follow TuxOnIce developments. I think this is a generic problem for testers of specific kernel subsystems... But then LKML is were TuxOnIce is visible to the kernel developer community. I would appreciate linux-pm I think maybe with a guideline to CC to LKML in usual cases... Thanks for your feedback. I think that's the way to go. BTW: toi-3.0-rc3 is rocking along nicely on my two ThinkPads (T42 and T23)... I am using 2.6.23.12 with cfs-v24.1... Great to hear! 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: [Suspend2-devel] Freezing filesystems (Was Re: What's in store for 2008 for TuxOnIce?)
Hi Ted. Theodore Tso wrote: > On Wed, Jan 02, 2008 at 10:54:18AM +1100, Nigel Cunningham wrote: >>> I would also like the TuxOnIce issues related to drivers, ACPI, etc. to go >>> to >>> one of the kernel-related lists, but I think linux-pm may be better for that >>> due to the much lower traffic. >> I guess that makes sense. I guess people can always be referred to LKML >> for the issues where the appropriate person isn't on linux-pm. > > Hi Nigel, > > I'd really recommend pushing the TuxOnIce discussions to LKML. That > way people can see the size of the user community and Andrew and Linus > can see how many people are using TuxOnIce. They can also see how > well the TuxOnIce community helps address user problems, which is a > big consideration when Linus decides whether or not to merge a > particular technology. > > If the goal is eventual merger of TuxOnIce, LKML is really the best > place to have the discussions. Examples such as Realtime, CFS, and > others have shown that you really want to keep the discussion front > and center. When one developer says, "not my problem; my code is > perfect", and the other developer is working with users who report > problems, guess which technology generally ends up getting merged by > Linus? Yes. The goal is eventual merger. That's what I was thinking too. Thanks for the input! 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: [Suspend2-devel] Reboot problem
Hi Christian. Christian Hesse wrote: > On Tuesday 01 January 2008, Nigel Cunningham wrote: >> Third, regarding the patch itself, I'm taking my time in working towards >> the 3.0 release. We don't have any major bugs with 3.0-rc3 reported [...]. > > Well, I think I still have a bug, though it is possibly a mainline problem > and > it's not a showstopper. After a suspend/resume cycle the reboot does not > work. The system hangs with "Rebooting system" (or similar). After that you > have to hard reset the system, which is not really a problem as filesystems > have been unmounted before. Reboot without a suspend cycle before and halt > with and without suspend cycle work without problems. Just to clarify, do you mean rebooting after writing an image, or shutting down and rebooting? It could be that there's some change to the semantics in 2.6.24 that I haven't noticed yet. > I'm using toi 3.0-rc3 with kernel 2.6.24-rc6 and beside the problem described > above I'm really happy with toi. > > Happy new your to everybody! And to you too! 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/
Freezing filesystems (Was Re: What's in store for 2008 for TuxOnIce?)
Hi.
Rafael J. Wysocki wrote:
> On Tuesday, 1 of January 2008, Nigel Cunningham wrote:
>> Hi all.
>
> Hi Nigel,
Gidday :)
>> With the start of a new year, I suppose it's a good time to think about
>> what I'd like to do with TuxOnIce this year and see what feedback I get.
>>
>> First up, I'm thinking about closing the mailing lists and asking people
>> to use LKML instead for reporting issues and so on. I'm thinking about
>> this because it will help with allowing people who work on mainline to
>> see how stable (or otherwise!) TuxOnIce is now. It should also help when
>> (as often happens) bug reports aren't actually issues with the patch,
>> but with vanilla (ie drivers).
>
> I would also like the TuxOnIce issues related to drivers, ACPI, etc. to go to
> one of the kernel-related lists, but I think linux-pm may be better for that
> due to the much lower traffic.
I guess that makes sense. I guess people can always be referred to LKML
for the issues where the appropriate person isn't on linux-pm.
>> Perhaps it will also help with whatever effort I find time to make towards
>> convincing Andrew that it really does have significant advantages over
>> [u]swsusp and kexec based hibernation.
>>
>> Secondly, I'm planning on moving the website soonish. It's taken longer
>> than I planned because it will be sharing with another server I'm
>> maintaining, and it has taken longer than expected to find good hosting
>> for the other server (which was done first). Now that I'm happy with the
>> other server's state, I'm hoping to start shifting
>> suspend2.net/tuxonice.net soon.
>>
>> For those who might be looking for hosting themselves, I'm using
>> slicehost. I initially tried GoDaddy, but had terrible service, problems
>> with draconian limits on the volume of outgoing email (1000/day by
>> default - useless if you're doing mailing lists) and unexpected,
>> unexplained delays in mail delivery through the SMTP delay they force
>> you to use. Slicehost, on the other hand, are terrific to deal with in
>> everyway. If you sign up with them because of this email, please
>> consider putting my email (nigel at suspend2.net) as the referrer - I
>> then get a discount on the cost of the hosting.
>>
>> Third, regarding the patch itself, I'm taking my time in working towards
>> the 3.0 release. We don't have any major bugs with 3.0-rc3 reported, but
>> I have some things I want to complete before the final release:
>> * see it well tested;
>> * get a finished initial version of the cluster support;
>> * finish completing support for the new resume-from-other kernels
>> functionality that Rafael has added in 2.6.24. (We can resume from the
>> same kernel at the moment, but I need to convince myself that nosave
>> data is properly handled).
>
> Have you finished the support for freezing filesystems before freezing tasks
> that we talked about some time ago?
Hmm. I've had too many things going through my little brain since then.
What I currently have is support for freezing fuse filesystems
separately. It looks like:
int freeze_processes(void)
{
int error;
printk("Stopping fuse filesystems.\n");
freeze_filesystems(FS_FREEZER_FUSE);
freezer_state = FREEZER_FILESYSTEMS_FROZEN;
printk("Freezing user space processes ... ");
error = try_to_freeze_tasks(FREEZER_USER_SPACE);
if (error)
goto Exit;
printk("done.\n");
sys_sync();
printk("Stopping normal filesystems.\n");
freeze_filesystems(FS_FREEZER_NORMAL);
freezer_state = FREEZER_USERSPACE_FROZEN;
printk("Freezing remaining freezable tasks ... ");
error = try_to_freeze_tasks(FREEZER_KERNEL_THREADS);
if (error)
goto Exit;
printk("done.");
freezer_state = FREEZER_FULLY_ON;
Exit:
BUG_ON(in_atomic());
printk("\n");
return error;
}
(I'm not yet worrying about ext3 on fuse or such like, but it shouldn't
be hard to extend the model to do that).
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/
What's in store for 2008 for TuxOnIce?
Hi all. With the start of a new year, I suppose it's a good time to think about what I'd like to do with TuxOnIce this year and see what feedback I get. First up, I'm thinking about closing the mailing lists and asking people to use LKML instead for reporting issues and so on. I'm thinking about this because it will help with allowing people who work on mainline to see how stable (or otherwise!) TuxOnIce is now. It should also help when (as often happens) bug reports aren't actually issues with the patch, but with vanilla (ie drivers). Perhaps it will also help with whatever effort I find time to make towards convincing Andrew that it really does have significant advantages over [u]swsusp and kexec based hibernation. Secondly, I'm planning on moving the website soonish. It's taken longer than I planned because it will be sharing with another server I'm maintaining, and it has taken longer than expected to find good hosting for the other server (which was done first). Now that I'm happy with the other server's state, I'm hoping to start shifting suspend2.net/tuxonice.net soon. For those who might be looking for hosting themselves, I'm using slicehost. I initially tried GoDaddy, but had terrible service, problems with draconian limits on the volume of outgoing email (1000/day by default - useless if you're doing mailing lists) and unexpected, unexplained delays in mail delivery through the SMTP delay they force you to use. Slicehost, on the other hand, are terrific to deal with in everyway. If you sign up with them because of this email, please consider putting my email (nigel at suspend2.net) as the referrer - I then get a discount on the cost of the hosting. Third, regarding the patch itself, I'm taking my time in working towards the 3.0 release. We don't have any major bugs with 3.0-rc3 reported, but I have some things I want to complete before the final release: * see it well tested; * get a finished initial version of the cluster support; * finish completing support for the new resume-from-other kernels functionality that Rafael has added in 2.6.24. (We can resume from the same kernel at the moment, but I need to convince myself that nosave data is properly handled). 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: Oops in evdev_disconnect for kernel 2.6.23.12
Hi Berthold. Berthold Cogel wrote: > Jan 1 17:34:39 wonderland kernel: usb 2-2: USB disconnect, address 3 > Jan 1 17:34:39 wonderland kernel: usb 2-2.5: USB disconnect, address 4 > Jan 1 17:34:39 wonderland kernel: drivers/input/tablet/wacom_sys.c: > wacom_sys_irq - usb_submit_urb failed with result -19 > Jan 1 17:34:39 wonderland kernel: usb 2-2.6: USB disconnect, address 5 > Jan 1 17:34:39 wonderland kernel: BUG: unable to handle kernel paging > request at virtual address 00100100 > Jan 1 17:34:39 wonderland kernel: printing eip: > Jan 1 17:34:39 wonderland kernel: f8819668 > Jan 1 17:34:39 wonderland kernel: *pde = > Jan 1 17:34:39 wonderland kernel: Oops: [#1] > Jan 1 17:34:39 wonderland kernel: PREEMPT > Jan 1 17:34:39 wonderland kernel: Modules linked in: isofs > nls_iso8859_1 nls_cp437 vfat fat radeon drm rfcomm l2cap bluetooth ppdev > lp fan ac battery joydev dm_crypt wacom dm_snapshot dm_mirror sr_mod > sd_mod sbp2 usbhid hid ff_memless usb_storage snd_emu10k1_synth > snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_emu10k1 > firmware_class snd_ac97_codec ac97_bus snd_util_mem snd_hwdep > snd_pcm_oss snd_pcm snd_page_alloc snd_mixer_oss snd_seq_dummy > snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq > snd_timer snd_seq_device parport_pc parport rtc i2c_viapro ohci1394 > via_agp ide_cd agpgart snd ehci_hcd emu10k1_gp gameport 8139too > soundcore thermal uhci_hcd ieee1394 processor button evdev > Jan 1 17:34:39 wonderland kernel: CPU:0 > Jan 1 17:34:39 wonderland kernel: EIP:0060:[]Not > tainted VLI > Jan 1 17:34:39 wonderland kernel: EFLAGS: 00010206 (2.6.23.12 #1) > Jan 1 17:34:39 wonderland kernel: EIP is at evdev_disconnect+0x65/0x9e > [evdev] > Jan 1 17:34:39 wonderland kernel: eax: ebx: 000ffcf0 ecx: > c1926760 edx: 0033 > Jan 1 17:34:39 wonderland kernel: esi: f7415600 edi: f741564c ebp: > f7415654 esp: c1967e68 > Jan 1 17:34:39 wonderland kernel: ds: 007b es: 007b fs: gs: > ss: 0068 > Jan 1 17:34:39 wonderland kernel: Process khubd (pid: 136, ti=c1966000 > task=c1926570 task.ti=c1966000) > Jan 1 17:34:39 wonderland kernel: Stack: f7415800 f7402000 f7402758 > f740276c f7b94458 c03454b2 c03c6eb6 > Jan 1 17:34:39 wonderland kernel:f7bda054 c029178a f788f520 > f7bda000 f9b3c608 f9b3a3ab f7bda000 f7bda000 > Jan 1 17:34:39 wonderland kernel:f7bda01c c0337954 f7bda01c > f9b3c638 c02fdb59 f7bda01c f7bda01c > Jan 1 17:34:39 wonderland kernel: Call Trace: > Jan 1 17:34:39 wonderland kernel: [] > input_unregister_device+0x6f/0xff > Jan 1 17:34:39 wonderland kernel: [] klist_release+0x27/0x30 > Jan 1 17:34:39 wonderland kernel: [] kref_put+0x5f/0x6c > Jan 1 17:34:39 wonderland kernel: [] > wacom_disconnect+0x2b/0x66 [wacom] > Jan 1 17:34:39 wonderland kernel: [] > usb_unbind_interface+0x2d/0x6e > Jan 1 17:34:39 wonderland kernel: [] > __device_release_driver+0x6e/0x8b > Jan 1 17:34:39 wonderland kernel: [] > device_release_driver+0x1d/0x32 > Jan 1 17:34:39 wonderland kernel: [] > bus_remove_device+0x6a/0x7a > Jan 1 17:34:39 wonderland kernel: [] device_del+0x1c3/0x234 > Jan 1 17:34:39 wonderland kernel: [] > usb_disable_device+0x5c/0xbb > Jan 1 17:34:39 wonderland kernel: [] usb_disconnect+0x7e/0xe6 > Jan 1 17:34:39 wonderland kernel: [] usb_disconnect+0x6f/0xe6 > Jan 1 17:34:39 wonderland kernel: [] hub_thread+0x31c/0xa10 > Jan 1 17:34:39 wonderland kernel: [] update_curr+0x102/0x12c > Jan 1 17:34:39 wonderland kernel: [] > update_stats_wait_end+0x96/0xb9 > Jan 1 17:34:39 wonderland kernel: [] > autoremove_wake_function+0x0/0x33 > Jan 1 17:34:39 wonderland kernel: [] hub_thread+0x0/0xa10 > Jan 1 17:34:39 wonderland kernel: [] kthread+0x36/0x5c > Jan 1 17:34:39 wonderland kernel: [] kthread+0x0/0x5c > Jan 1 17:34:39 wonderland kernel: [] > kernel_thread_helper+0x7/0x10 > Jan 1 17:34:39 wonderland kernel: === > Jan 1 17:34:39 wonderland kernel: Code: 5e 4c 81 eb 10 04 00 00 eb 21 > 8d 83 08 04 00 00 b9 06 00 02 00 ba 1d 00 00 00 e8 6a 93 95 c7 8b 9b 10 > 04 00 00 81 eb 10 04 00 00 <8b> 83 10 04 00 00 0f 18 00 90 8d 83 10 04 > 00 00 39 f8 75 cb 8d > Jan 1 17:34:39 wonderland kernel: EIP: [] > evdev_disconnect+0x65/0x9e [evdev] SS:ESP 0068:c1967e68 > > > I'm using Debian stable/testing/unstable with homemade kernel 2.6.23.12 > (patched with tuxonice-3.0-rc3-for-2.6.23.9). > > I tried to get my Wacom Bamboo grafic tablet to work with linux and the > xorg driver from linuxwacom-0.7.9-4 > (http://linuxwacom.sourceforge.net/). After 'configure/make/make > install' from source and configuring Xorg, I got the tablet working for > a simple user. But each time I tried to login with X as root (I know > Bad idea :-)) xserver got restarted. I tried to trace the > situation with stracing gdm. I did this via an ssh session from a second > computer. Because I tried to follow the forks, I had to
Re: Oops in evdev_disconnect for kernel 2.6.23.12
Hi Berthold. Berthold Cogel wrote: Jan 1 17:34:39 wonderland kernel: usb 2-2: USB disconnect, address 3 Jan 1 17:34:39 wonderland kernel: usb 2-2.5: USB disconnect, address 4 Jan 1 17:34:39 wonderland kernel: drivers/input/tablet/wacom_sys.c: wacom_sys_irq - usb_submit_urb failed with result -19 Jan 1 17:34:39 wonderland kernel: usb 2-2.6: USB disconnect, address 5 Jan 1 17:34:39 wonderland kernel: BUG: unable to handle kernel paging request at virtual address 00100100 Jan 1 17:34:39 wonderland kernel: printing eip: Jan 1 17:34:39 wonderland kernel: f8819668 Jan 1 17:34:39 wonderland kernel: *pde = Jan 1 17:34:39 wonderland kernel: Oops: [#1] Jan 1 17:34:39 wonderland kernel: PREEMPT Jan 1 17:34:39 wonderland kernel: Modules linked in: isofs nls_iso8859_1 nls_cp437 vfat fat radeon drm rfcomm l2cap bluetooth ppdev lp fan ac battery joydev dm_crypt wacom dm_snapshot dm_mirror sr_mod sd_mod sbp2 usbhid hid ff_memless usb_storage snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_emu10k1 firmware_class snd_ac97_codec ac97_bus snd_util_mem snd_hwdep snd_pcm_oss snd_pcm snd_page_alloc snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device parport_pc parport rtc i2c_viapro ohci1394 via_agp ide_cd agpgart snd ehci_hcd emu10k1_gp gameport 8139too soundcore thermal uhci_hcd ieee1394 processor button evdev Jan 1 17:34:39 wonderland kernel: CPU:0 Jan 1 17:34:39 wonderland kernel: EIP:0060:[f8819668]Not tainted VLI Jan 1 17:34:39 wonderland kernel: EFLAGS: 00010206 (2.6.23.12 #1) Jan 1 17:34:39 wonderland kernel: EIP is at evdev_disconnect+0x65/0x9e [evdev] Jan 1 17:34:39 wonderland kernel: eax: ebx: 000ffcf0 ecx: c1926760 edx: 0033 Jan 1 17:34:39 wonderland kernel: esi: f7415600 edi: f741564c ebp: f7415654 esp: c1967e68 Jan 1 17:34:39 wonderland kernel: ds: 007b es: 007b fs: gs: ss: 0068 Jan 1 17:34:39 wonderland kernel: Process khubd (pid: 136, ti=c1966000 task=c1926570 task.ti=c1966000) Jan 1 17:34:39 wonderland kernel: Stack: f7415800 f7402000 f7402758 f740276c f7b94458 c03454b2 c03c6eb6 Jan 1 17:34:39 wonderland kernel:f7bda054 c029178a f788f520 f7bda000 f9b3c608 f9b3a3ab f7bda000 f7bda000 Jan 1 17:34:39 wonderland kernel:f7bda01c c0337954 f7bda01c f9b3c638 c02fdb59 f7bda01c f7bda01c Jan 1 17:34:39 wonderland kernel: Call Trace: Jan 1 17:34:39 wonderland kernel: [c03454b2] input_unregister_device+0x6f/0xff Jan 1 17:34:39 wonderland kernel: [c03c6eb6] klist_release+0x27/0x30 Jan 1 17:34:39 wonderland kernel: [c029178a] kref_put+0x5f/0x6c Jan 1 17:34:39 wonderland kernel: [f9b3a3ab] wacom_disconnect+0x2b/0x66 [wacom] Jan 1 17:34:39 wonderland kernel: [c0337954] usb_unbind_interface+0x2d/0x6e Jan 1 17:34:39 wonderland kernel: [c02fdb59] __device_release_driver+0x6e/0x8b Jan 1 17:34:39 wonderland kernel: [c02fdeaf] device_release_driver+0x1d/0x32 Jan 1 17:34:39 wonderland kernel: [c02fd599] bus_remove_device+0x6a/0x7a Jan 1 17:34:39 wonderland kernel: [c02fbde3] device_del+0x1c3/0x234 Jan 1 17:34:39 wonderland kernel: [c033567f] usb_disable_device+0x5c/0xbb Jan 1 17:34:39 wonderland kernel: [c0331ff9] usb_disconnect+0x7e/0xe6 Jan 1 17:34:39 wonderland kernel: [c0331fea] usb_disconnect+0x6f/0xe6 Jan 1 17:34:39 wonderland kernel: [c03324db] hub_thread+0x31c/0xa10 Jan 1 17:34:39 wonderland kernel: [c0114e17] update_curr+0x102/0x12c Jan 1 17:34:39 wonderland kernel: [c0114a13] update_stats_wait_end+0x96/0xb9 Jan 1 17:34:39 wonderland kernel: [c01281c7] autoremove_wake_function+0x0/0x33 Jan 1 17:34:39 wonderland kernel: [c03321bf] hub_thread+0x0/0xa10 Jan 1 17:34:39 wonderland kernel: [c012810e] kthread+0x36/0x5c Jan 1 17:34:39 wonderland kernel: [c01280d8] kthread+0x0/0x5c Jan 1 17:34:39 wonderland kernel: [c01048f7] kernel_thread_helper+0x7/0x10 Jan 1 17:34:39 wonderland kernel: === Jan 1 17:34:39 wonderland kernel: Code: 5e 4c 81 eb 10 04 00 00 eb 21 8d 83 08 04 00 00 b9 06 00 02 00 ba 1d 00 00 00 e8 6a 93 95 c7 8b 9b 10 04 00 00 81 eb 10 04 00 00 8b 83 10 04 00 00 0f 18 00 90 8d 83 10 04 00 00 39 f8 75 cb 8d Jan 1 17:34:39 wonderland kernel: EIP: [f8819668] evdev_disconnect+0x65/0x9e [evdev] SS:ESP 0068:c1967e68 I'm using Debian stable/testing/unstable with homemade kernel 2.6.23.12 (patched with tuxonice-3.0-rc3-for-2.6.23.9). I tried to get my Wacom Bamboo grafic tablet to work with linux and the xorg driver from linuxwacom-0.7.9-4 (http://linuxwacom.sourceforge.net/). After 'configure/make/make install' from source and configuring Xorg, I got the tablet working for a simple user. But each time I tried to login with X as root (I know Bad idea :-)) xserver got restarted. I tried to trace the situation with stracing gdm. I did this via an ssh
What's in store for 2008 for TuxOnIce?
Hi all. With the start of a new year, I suppose it's a good time to think about what I'd like to do with TuxOnIce this year and see what feedback I get. First up, I'm thinking about closing the mailing lists and asking people to use LKML instead for reporting issues and so on. I'm thinking about this because it will help with allowing people who work on mainline to see how stable (or otherwise!) TuxOnIce is now. It should also help when (as often happens) bug reports aren't actually issues with the patch, but with vanilla (ie drivers). Perhaps it will also help with whatever effort I find time to make towards convincing Andrew that it really does have significant advantages over [u]swsusp and kexec based hibernation. Secondly, I'm planning on moving the website soonish. It's taken longer than I planned because it will be sharing with another server I'm maintaining, and it has taken longer than expected to find good hosting for the other server (which was done first). Now that I'm happy with the other server's state, I'm hoping to start shifting suspend2.net/tuxonice.net soon. For those who might be looking for hosting themselves, I'm using slicehost. I initially tried GoDaddy, but had terrible service, problems with draconian limits on the volume of outgoing email (1000/day by default - useless if you're doing mailing lists) and unexpected, unexplained delays in mail delivery through the SMTP delay they force you to use. Slicehost, on the other hand, are terrific to deal with in everyway. If you sign up with them because of this email, please consider putting my email (nigel at suspend2.net) as the referrer - I then get a discount on the cost of the hosting. Third, regarding the patch itself, I'm taking my time in working towards the 3.0 release. We don't have any major bugs with 3.0-rc3 reported, but I have some things I want to complete before the final release: * see it well tested; * get a finished initial version of the cluster support; * finish completing support for the new resume-from-other kernels functionality that Rafael has added in 2.6.24. (We can resume from the same kernel at the moment, but I need to convince myself that nosave data is properly handled). 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/
Freezing filesystems (Was Re: What's in store for 2008 for TuxOnIce?)
Hi.
Rafael J. Wysocki wrote:
On Tuesday, 1 of January 2008, Nigel Cunningham wrote:
Hi all.
Hi Nigel,
Gidday :)
With the start of a new year, I suppose it's a good time to think about
what I'd like to do with TuxOnIce this year and see what feedback I get.
First up, I'm thinking about closing the mailing lists and asking people
to use LKML instead for reporting issues and so on. I'm thinking about
this because it will help with allowing people who work on mainline to
see how stable (or otherwise!) TuxOnIce is now. It should also help when
(as often happens) bug reports aren't actually issues with the patch,
but with vanilla (ie drivers).
I would also like the TuxOnIce issues related to drivers, ACPI, etc. to go to
one of the kernel-related lists, but I think linux-pm may be better for that
due to the much lower traffic.
I guess that makes sense. I guess people can always be referred to LKML
for the issues where the appropriate person isn't on linux-pm.
Perhaps it will also help with whatever effort I find time to make towards
convincing Andrew that it really does have significant advantages over
[u]swsusp and kexec based hibernation.
Secondly, I'm planning on moving the website soonish. It's taken longer
than I planned because it will be sharing with another server I'm
maintaining, and it has taken longer than expected to find good hosting
for the other server (which was done first). Now that I'm happy with the
other server's state, I'm hoping to start shifting
suspend2.net/tuxonice.net soon.
For those who might be looking for hosting themselves, I'm using
slicehost. I initially tried GoDaddy, but had terrible service, problems
with draconian limits on the volume of outgoing email (1000/day by
default - useless if you're doing mailing lists) and unexpected,
unexplained delays in mail delivery through the SMTP delay they force
you to use. Slicehost, on the other hand, are terrific to deal with in
everyway. If you sign up with them because of this email, please
consider putting my email (nigel at suspend2.net) as the referrer - I
then get a discount on the cost of the hosting.
Third, regarding the patch itself, I'm taking my time in working towards
the 3.0 release. We don't have any major bugs with 3.0-rc3 reported, but
I have some things I want to complete before the final release:
* see it well tested;
* get a finished initial version of the cluster support;
* finish completing support for the new resume-from-other kernels
functionality that Rafael has added in 2.6.24. (We can resume from the
same kernel at the moment, but I need to convince myself that nosave
data is properly handled).
Have you finished the support for freezing filesystems before freezing tasks
that we talked about some time ago?
Hmm. I've had too many things going through my little brain since then.
What I currently have is support for freezing fuse filesystems
separately. It looks like:
int freeze_processes(void)
{
int error;
printk(Stopping fuse filesystems.\n);
freeze_filesystems(FS_FREEZER_FUSE);
freezer_state = FREEZER_FILESYSTEMS_FROZEN;
printk(Freezing user space processes ... );
error = try_to_freeze_tasks(FREEZER_USER_SPACE);
if (error)
goto Exit;
printk(done.\n);
sys_sync();
printk(Stopping normal filesystems.\n);
freeze_filesystems(FS_FREEZER_NORMAL);
freezer_state = FREEZER_USERSPACE_FROZEN;
printk(Freezing remaining freezable tasks ... );
error = try_to_freeze_tasks(FREEZER_KERNEL_THREADS);
if (error)
goto Exit;
printk(done.);
freezer_state = FREEZER_FULLY_ON;
Exit:
BUG_ON(in_atomic());
printk(\n);
return error;
}
(I'm not yet worrying about ext3 on fuse or such like, but it shouldn't
be hard to extend the model to do that).
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: [Suspend2-devel] Reboot problem
Hi Christian. Christian Hesse wrote: On Tuesday 01 January 2008, Nigel Cunningham wrote: Third, regarding the patch itself, I'm taking my time in working towards the 3.0 release. We don't have any major bugs with 3.0-rc3 reported [...]. Well, I think I still have a bug, though it is possibly a mainline problem and it's not a showstopper. After a suspend/resume cycle the reboot does not work. The system hangs with Rebooting system (or similar). After that you have to hard reset the system, which is not really a problem as filesystems have been unmounted before. Reboot without a suspend cycle before and halt with and without suspend cycle work without problems. Just to clarify, do you mean rebooting after writing an image, or shutting down and rebooting? It could be that there's some change to the semantics in 2.6.24 that I haven't noticed yet. I'm using toi 3.0-rc3 with kernel 2.6.24-rc6 and beside the problem described above I'm really happy with toi. Happy new your to everybody! And to you too! 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: [Suspend2-devel] Freezing filesystems (Was Re: What's in store for 2008 for TuxOnIce?)
Hi Ted. Theodore Tso wrote: On Wed, Jan 02, 2008 at 10:54:18AM +1100, Nigel Cunningham wrote: I would also like the TuxOnIce issues related to drivers, ACPI, etc. to go to one of the kernel-related lists, but I think linux-pm may be better for that due to the much lower traffic. I guess that makes sense. I guess people can always be referred to LKML for the issues where the appropriate person isn't on linux-pm. Hi Nigel, I'd really recommend pushing the TuxOnIce discussions to LKML. That way people can see the size of the user community and Andrew and Linus can see how many people are using TuxOnIce. They can also see how well the TuxOnIce community helps address user problems, which is a big consideration when Linus decides whether or not to merge a particular technology. If the goal is eventual merger of TuxOnIce, LKML is really the best place to have the discussions. Examples such as Realtime, CFS, and others have shown that you really want to keep the discussion front and center. When one developer says, not my problem; my code is perfect, and the other developer is working with users who report problems, guess which technology generally ends up getting merged by Linus? Yes. The goal is eventual merger. That's what I was thinking too. Thanks for the input! 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: [PATCH 0/3 -mm] kexec jump -v8
Hi. Huang, Ying wrote: > This patchset provides an enhancement to kexec/kdump. It implements > the following features: > > - Backup/restore memory used both by the original kernel and the > kexeced kernel. Why the kexeced kernel as well? [...] > The features of this patchset can be used as follow: > > - Kernel/system debug through making system snapshot. You can make > system snapshot, jump back, do some thing and make another system > snapshot. Are you somehow recording all the filesystem changes after the first snapshot? If not, this is pointless (you'll end up with filesystem corruption). [...] > - Cooperative multi-kernel/system. With kexec jump, you can switch > between several kernels/systems quickly without boot process except > the first time. This appears like swap a whole kernel/system out/in. How is this useful to the end user? 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: [PATCH 0/3 -mm] kexec jump -v8
Hi. Huang, Ying wrote: This patchset provides an enhancement to kexec/kdump. It implements the following features: - Backup/restore memory used both by the original kernel and the kexeced kernel. Why the kexeced kernel as well? [...] The features of this patchset can be used as follow: - Kernel/system debug through making system snapshot. You can make system snapshot, jump back, do some thing and make another system snapshot. Are you somehow recording all the filesystem changes after the first snapshot? If not, this is pointless (you'll end up with filesystem corruption). [...] - Cooperative multi-kernel/system. With kexec jump, you can switch between several kernels/systems quickly without boot process except the first time. This appears like swap a whole kernel/system out/in. How is this useful to the end user? 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: [RFT] Port 0x80 I/O speed
Rene Herman wrote: > On 12-12-07 00:55, Nigel Cunningham wrote: > >> (AMD 1.8GHz Turion, running at 800MHz. ATI RS480 - Mitac 8350 mobo) >> >> [EMAIL PROTECTED]:~/Downloads$ gcc port80.c -o port80 >> [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 >> cycles: out 1235, in 1207 > > Looking good. > >> [EMAIL PROTECTED]:~/Downloads$ gcc -O2 port80.c -o port80 >> [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 >> cycles: out 1844674407370794, in 1844674407369408 > > Obviously not. I suppose this changes with -m32 on the GCC command line? > (sorry for missing that, I have no 64-bit machines). Yes, it does: [EMAIL PROTECTED]:~/Downloads$ gcc -m32 -o port80 port80.c [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 1231, in 1208 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 1233, in 1210 Incidentally: [EMAIL PROTECTED]:~/Downloads$ processor_speed (A little script I made because my lappy does a solid lock every now and then that seems to be cpu-freq related - locking it to one frequency makes the lock far less common). Speed is now 180. [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 2472, in 2505 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 2489, in 2515 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 2481, in 2503 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 2476, in 2507 So the same effect Maxim reported is seen here. 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: [RFT] Port 0x80 I/O speed
Rene Herman wrote: > Good day. > > Would some people on x86 (both 32 and 64) be kind enough to compile and > run the attached program? This is about testing how long I/O port access > to port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in > reporting. > > Posted a previous incarnation of this before, buried in the outb 0x80 > thread which had a serialising problem. This one should as far as I can > see measure the right thing though. Please yell if you disagree... > > For me, on a Duron 1300 (AMD756 chipset) I have a constant: > > [EMAIL PROTECTED]:~/src/port80$ su -c ./port80 > cycles: out 2400, in 2400 > > and on a PII 400 (Intel 440BX chipset) a constant: > > [EMAIL PROTECTED]:~/src/port80$ su -c ./port80 > cycles: out 553, in 251 > > Results are (mostly) independent of compiler optimisation, but testing > with an -O2 compile should be most useful. Thanks! (AMD 1.8GHz Turion, running at 800MHz. ATI RS480 - Mitac 8350 mobo) [EMAIL PROTECTED]:~/Downloads$ gcc port80.c -o port80 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 1235, in 1207 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 1238, in 1205 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 1237, in 1209 [EMAIL PROTECTED]:~/Downloads$ gcc -O2 port80.c -o port80 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 1844674407370794, in 1844674407369408 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 1844674407370795, in 1844674407369404 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 1844674407370795, in 1844674407369409 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 1844674407370798, in 1844674407369407 [EMAIL PROTECTED]:~/Downloads$ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 36 model name : AMD Turion(tm) 64 Mobile Technology ML-34 stepping: 2 cpu MHz : 800.000 cache size : 1024 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good pni lahf_lm bogomips: 1592.87 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc 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: [RFT] Port 0x80 I/O speed
Rene Herman wrote: Good day. Would some people on x86 (both 32 and 64) be kind enough to compile and run the attached program? This is about testing how long I/O port access to port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in reporting. Posted a previous incarnation of this before, buried in the outb 0x80 thread which had a serialising problem. This one should as far as I can see measure the right thing though. Please yell if you disagree... For me, on a Duron 1300 (AMD756 chipset) I have a constant: [EMAIL PROTECTED]:~/src/port80$ su -c ./port80 cycles: out 2400, in 2400 and on a PII 400 (Intel 440BX chipset) a constant: [EMAIL PROTECTED]:~/src/port80$ su -c ./port80 cycles: out 553, in 251 Results are (mostly) independent of compiler optimisation, but testing with an -O2 compile should be most useful. Thanks! (AMD 1.8GHz Turion, running at 800MHz. ATI RS480 - Mitac 8350 mobo) [EMAIL PROTECTED]:~/Downloads$ gcc port80.c -o port80 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 1235, in 1207 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 1238, in 1205 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 1237, in 1209 [EMAIL PROTECTED]:~/Downloads$ gcc -O2 port80.c -o port80 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 1844674407370794, in 1844674407369408 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 1844674407370795, in 1844674407369404 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 1844674407370795, in 1844674407369409 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 1844674407370798, in 1844674407369407 [EMAIL PROTECTED]:~/Downloads$ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 36 model name : AMD Turion(tm) 64 Mobile Technology ML-34 stepping: 2 cpu MHz : 800.000 cache size : 1024 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good pni lahf_lm bogomips: 1592.87 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc 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: [RFT] Port 0x80 I/O speed
Rene Herman wrote: On 12-12-07 00:55, Nigel Cunningham wrote: (AMD 1.8GHz Turion, running at 800MHz. ATI RS480 - Mitac 8350 mobo) [EMAIL PROTECTED]:~/Downloads$ gcc port80.c -o port80 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 1235, in 1207 Looking good. [EMAIL PROTECTED]:~/Downloads$ gcc -O2 port80.c -o port80 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 1844674407370794, in 1844674407369408 Obviously not. I suppose this changes with -m32 on the GCC command line? (sorry for missing that, I have no 64-bit machines). Yes, it does: [EMAIL PROTECTED]:~/Downloads$ gcc -m32 -o port80 port80.c [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 1231, in 1208 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 1233, in 1210 Incidentally: [EMAIL PROTECTED]:~/Downloads$ processor_speed (A little script I made because my lappy does a solid lock every now and then that seems to be cpu-freq related - locking it to one frequency makes the lock far less common). Speed is now 180. [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 2472, in 2505 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 2489, in 2515 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 2481, in 2503 [EMAIL PROTECTED]:~/Downloads$ sudo ./port80 cycles: out 2476, in 2507 So the same effect Maxim reported is seen here. 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/
PID namespaces break initrd+hibernate combination?
Hi all. Please excuse me if this has already been answered. I'm not currently subscribed to LKML. I've just been preparing a new tux-on-ice release against Linus' current tree, and encountered a failure to freeze pid 1 when seeking to resume, using an initrd: [ 74.192734] Freezing of tasks failed after 19.99 seconds (1 tasks refusing to freeze): [ 74.193502] taskPC stack pid father [ 74.193504] swapper S 810002023030 4968 1 0 [ 74.193512] 81000203fdb0 0046 810002023040 810003249140 [ 74.194296] 81000203fd80 803150a1 81000203fdb0 810002023180 [ 74.195087] 810002023030 0004 0001 0001 [ 74.195860] Call Trace: [ 74.196123] [] security_task_wait+0x11/0x20 [ 74.196692] [] do_wait+0x51d/0xda0 [ 74.197187] [] default_wake_function+0x0/0x10 [ 74.197772] [] sys_wait4+0x2c/0x30 [ 74.198264] [] initrd_load+0x175/0x370 [ 74.198794] [] prepare_namespace+0x8f/0x1d0 [ 74.199362] [] kernel_init+0x1ad/0x2b0 [ 74.199889] [] _spin_unlock_irq+0x26/0x60 [ 74.200439] [] finish_task_switch+0x67/0xc0 [ 74.201008] [] child_rip+0xa/0x12 [ 74.201494] [] acpi_os_acquire_lock+0x9/0xb [ 74.202063] [] kernel_init+0x0/0x2b0 [ 74.202570] [] child_rip+0x0/0x12 I believe it might be related to pid namespaces, but am not completely sure yet (will do a git bisect if needs be). So, then, I'm writing to ask: Is this a known issue? Is there any fix already available that I've not found in my googling? 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/
PID namespaces break initrd+hibernate combination?
Hi all. Please excuse me if this has already been answered. I'm not currently subscribed to LKML. I've just been preparing a new tux-on-ice release against Linus' current tree, and encountered a failure to freeze pid 1 when seeking to resume, using an initrd: [ 74.192734] Freezing of tasks failed after 19.99 seconds (1 tasks refusing to freeze): [ 74.193502] taskPC stack pid father [ 74.193504] swapper S 810002023030 4968 1 0 [ 74.193512] 81000203fdb0 0046 810002023040 810003249140 [ 74.194296] 81000203fd80 803150a1 81000203fdb0 810002023180 [ 74.195087] 810002023030 0004 0001 0001 [ 74.195860] Call Trace: [ 74.196123] [803150a1] security_task_wait+0x11/0x20 [ 74.196692] [802320cd] do_wait+0x51d/0xda0 [ 74.197187] [802292f0] default_wake_function+0x0/0x10 [ 74.197772] [8023297c] sys_wait4+0x2c/0x30 [ 74.198264] [805f4bb5] initrd_load+0x175/0x370 [ 74.198794] [805f211f] prepare_namespace+0x8f/0x1d0 [ 74.199362] [805f174d] kernel_init+0x1ad/0x2b0 [ 74.199889] [8047e526] _spin_unlock_irq+0x26/0x60 [ 74.200439] [8022afc7] finish_task_switch+0x67/0xc0 [ 74.201008] [8020c548] child_rip+0xa/0x12 [ 74.201494] [80364770] acpi_os_acquire_lock+0x9/0xb [ 74.202063] [805f15a0] kernel_init+0x0/0x2b0 [ 74.202570] [8020c53e] child_rip+0x0/0x12 I believe it might be related to pid namespaces, but am not completely sure yet (will do a git bisect if needs be). So, then, I'm writing to ask: Is this a known issue? Is there any fix already available that I've not found in my googling? 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: [RFC][PATCH -mm] Freezer: Do not allow freezing processes to clear TIF_SIGPENDING
Hi.
On Friday 19 October 2007 08:22:35 Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> Do not allow processes to clear their TIF_SIGPENDING if TIF_FREEZE is set,
> to prevent them from racing with the freezer (like mysqld does, for
example).
>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Nigel Cunningham <[EMAIL PROTECTED]>
> ---
> kernel/signal.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6.23-mm1/kernel/signal.c
> ===
> --- linux-2.6.23-mm1.orig/kernel/signal.c
> +++ linux-2.6.23-mm1/kernel/signal.c
> @@ -124,7 +124,7 @@ void recalc_sigpending_and_wake(struct t
>
> void recalc_sigpending(void)
> {
> - if (!recalc_sigpending_tsk(current))
> + if (!recalc_sigpending_tsk(current) && !freezing(current))
> clear_thread_flag(TIF_SIGPENDING);
>
> }
>
--
Nigel, Michelle, Alisdair and Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia
-
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: [RFC][PATCH -mm] Freezer: Do not allow freezing processes to clear TIF_SIGPENDING
Hi.
On Friday 19 October 2007 08:22:35 Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Do not allow processes to clear their TIF_SIGPENDING if TIF_FREEZE is set,
to prevent them from racing with the freezer (like mysqld does, for
example).
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: Nigel Cunningham [EMAIL PROTECTED]
---
kernel/signal.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.23-mm1/kernel/signal.c
===
--- linux-2.6.23-mm1.orig/kernel/signal.c
+++ linux-2.6.23-mm1/kernel/signal.c
@@ -124,7 +124,7 @@ void recalc_sigpending_and_wake(struct t
void recalc_sigpending(void)
{
- if (!recalc_sigpending_tsk(current))
+ if (!recalc_sigpending_tsk(current) !freezing(current))
clear_thread_flag(TIF_SIGPENDING);
}
--
Nigel, Michelle, Alisdair and Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia
-
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: Current Linus' git compilation breakage.
Hi Dave et al. On Saturday 13 October 2007 11:22:44 Dave Jones wrote: > On Sat, Oct 13, 2007 at 11:11:31AM +1000, Nigel Cunningham wrote: > > Hi all. > > > > Maybe I just picked a bad time to try, but... > > > > arch/x86/kernel/alternative.c: In function 'apply_alternatives': > > arch/x86/kernel/alternative.c:191: error: 'VSYSCALL_START' undeclared (first use in this function) > > arch/x86/kernel/alternative.c:191: error: (Each undeclared identifier is reported only once > > arch/x86/kernel/alternative.c:191: error: for each function it appears in.) > > arch/x86/kernel/alternative.c:191: error: 'VSYSCALL_END' undeclared (first use in this function) > > make[1]: *** [arch/x86/kernel/alternative.o] Error 1 > > make: *** [arch/x86/kernel] Error 2 > > Try this. > > Include missing header for vsyscall. > > Signed-off-by: Dave Jones <[EMAIL PROTECTED]> Thanks. Compile-Tested-by: Nigel Cunningham <[EMAIL PROTECTED]> > diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c > index bd72d94..11b03d3 100644 > --- a/arch/x86/kernel/alternative.c > +++ b/arch/x86/kernel/alternative.c > @@ -10,6 +10,7 @@ > #include > #include > #include > +#include > > #define MAX_PATCH_LEN (255-1) - 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: Current Linus' git compilation breakage.
Hi Dave et al. On Saturday 13 October 2007 11:22:44 Dave Jones wrote: On Sat, Oct 13, 2007 at 11:11:31AM +1000, Nigel Cunningham wrote: Hi all. Maybe I just picked a bad time to try, but... arch/x86/kernel/alternative.c: In function 'apply_alternatives': arch/x86/kernel/alternative.c:191: error: 'VSYSCALL_START' undeclared (first use in this function) arch/x86/kernel/alternative.c:191: error: (Each undeclared identifier is reported only once arch/x86/kernel/alternative.c:191: error: for each function it appears in.) arch/x86/kernel/alternative.c:191: error: 'VSYSCALL_END' undeclared (first use in this function) make[1]: *** [arch/x86/kernel/alternative.o] Error 1 make: *** [arch/x86/kernel] Error 2 Try this. Include missing header for vsyscall. Signed-off-by: Dave Jones [EMAIL PROTECTED] Thanks. Compile-Tested-by: Nigel Cunningham [EMAIL PROTECTED] diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c index bd72d94..11b03d3 100644 --- a/arch/x86/kernel/alternative.c +++ b/arch/x86/kernel/alternative.c @@ -10,6 +10,7 @@ #include asm/pgtable.h #include asm/mce.h #include asm/nmi.h +#include asm/vsyscall.h #define MAX_PATCH_LEN (255-1) - 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/
Current Linus' git compilation breakage.
Hi all. Maybe I just picked a bad time to try, but... arch/x86/kernel/alternative.c: In function 'apply_alternatives': arch/x86/kernel/alternative.c:191: error: 'VSYSCALL_START' undeclared (first use in this function) arch/x86/kernel/alternative.c:191: error: (Each undeclared identifier is reported only once arch/x86/kernel/alternative.c:191: error: for each function it appears in.) arch/x86/kernel/alternative.c:191: error: 'VSYSCALL_END' undeclared (first use in this function) make[1]: *** [arch/x86/kernel/alternative.o] Error 1 make: *** [arch/x86/kernel] Error 2 This is UP AMD64. Config attached. Regards, Nigel # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc9 # Sat Oct 6 07:44:19 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=21 CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=m CONFIG_IOSCHED_DEADLINE=m CONFIG_IOSCHED_CFQ=m # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set CONFIG_DEFAULT_NOOP=y CONFIG_DEFAULT_IOSCHED="noop" # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set # CONFIG_MK8 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set CONFIG_GENERIC_CPU=y CONFIG_X86_L1_CACHE_BYTES=128 CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_INTERNODE_CACHE_BYTES=128 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y # CONFIG_X86_CPUID is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_PHYSICAL_ALIGN=0x20 CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_INTEL is not set CONFIG_X86_MCE_AMD=y # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set # CONFIG_RELOCATABLE is not set CONFIG_PHYSICAL_START=0x20 # CONFIG_SECCOMP is not set # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_K8_NB=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_ISA_DMA_API=y # # Power management options # CONFIG_PM=y CONFIG_PM_LEGACY=y CONFIG_PM_DEBUG=y # CONFIG_PM_VERBOSE is not set # CONFIG_DISABLE_CONSOLE_SUSPEND is not set # CONFIG_PRINTK_NOSAVE is not set # CONFIG_PM_TRACE is not set CONFIG_PM_SLEEP=y CONFIG_SUSPEND_UP_POSSIBLE=y CONFIG_SUSPEND=y CONFIG_HIBERNATION_UP_POSSIBLE=y CONFIG_HIBERNATION=y CONFIG_PM_STD_PARTITION="" CONFIG_TOI_CORE=m # # Image Storage (you
Current Linus' git compilation breakage.
Hi all. Maybe I just picked a bad time to try, but... arch/x86/kernel/alternative.c: In function 'apply_alternatives': arch/x86/kernel/alternative.c:191: error: 'VSYSCALL_START' undeclared (first use in this function) arch/x86/kernel/alternative.c:191: error: (Each undeclared identifier is reported only once arch/x86/kernel/alternative.c:191: error: for each function it appears in.) arch/x86/kernel/alternative.c:191: error: 'VSYSCALL_END' undeclared (first use in this function) make[1]: *** [arch/x86/kernel/alternative.o] Error 1 make: *** [arch/x86/kernel] Error 2 This is UP AMD64. Config attached. Regards, Nigel # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc9 # Sat Oct 6 07:44:19 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=21 CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=m CONFIG_IOSCHED_DEADLINE=m CONFIG_IOSCHED_CFQ=m # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set CONFIG_DEFAULT_NOOP=y CONFIG_DEFAULT_IOSCHED=noop # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set # CONFIG_MK8 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set CONFIG_GENERIC_CPU=y CONFIG_X86_L1_CACHE_BYTES=128 CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_INTERNODE_CACHE_BYTES=128 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y # CONFIG_X86_CPUID is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_PHYSICAL_ALIGN=0x20 CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_INTEL is not set CONFIG_X86_MCE_AMD=y # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set # CONFIG_RELOCATABLE is not set CONFIG_PHYSICAL_START=0x20 # CONFIG_SECCOMP is not set # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_K8_NB=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_ISA_DMA_API=y # # Power management options # CONFIG_PM=y CONFIG_PM_LEGACY=y CONFIG_PM_DEBUG=y # CONFIG_PM_VERBOSE is not set # CONFIG_DISABLE_CONSOLE_SUSPEND is not set # CONFIG_PRINTK_NOSAVE is not set # CONFIG_PM_TRACE is not set CONFIG_PM_SLEEP=y CONFIG_SUSPEND_UP_POSSIBLE=y CONFIG_SUSPEND=y CONFIG_HIBERNATION_UP_POSSIBLE=y CONFIG_HIBERNATION=y CONFIG_PM_STD_PARTITION= CONFIG_TOI_CORE=m # # Image Storage (you need at
Re: Fwd: [Suspend2-devel] [patch] 2.2.10.3 build fixes
Hi. On Monday 01 October 2007 08:28:02 Rafael J. Wysocki wrote: > On Sunday, 30 September 2007 23:43, Nigel Cunningham wrote: > > On Monday 01 October 2007 05:56:45 Rafael J. Wysocki wrote: > > > On Sunday, 30 September 2007 13:44, Nigel Cunningham wrote: > > > > Hi Rafael et al. > > > > > > > > This looks like it will be vanilla material, maybe 2.6.23 material? > > > > > > Well, I wouldn't like to export freezer.h . Why exactly would that be > > > necessary? > > > > A module that starts a freezeable kthread? > > > > I can ask for more details, and will if you like. > > Yes, please. Ah. My bad. I should have looked at it more carefully before forwarding; it's a result of my modifications for fuse support. Sorry for the noise. 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: Fwd: [Suspend2-devel] [patch] 2.2.10.3 build fixes
Hi. On Monday 01 October 2007 08:28:02 Rafael J. Wysocki wrote: On Sunday, 30 September 2007 23:43, Nigel Cunningham wrote: On Monday 01 October 2007 05:56:45 Rafael J. Wysocki wrote: On Sunday, 30 September 2007 13:44, Nigel Cunningham wrote: Hi Rafael et al. This looks like it will be vanilla material, maybe 2.6.23 material? Well, I wouldn't like to export freezer.h . Why exactly would that be necessary? A module that starts a freezeable kthread? I can ask for more details, and will if you like. Yes, please. Ah. My bad. I should have looked at it more carefully before forwarding; it's a result of my modifications for fuse support. Sorry for the noise. 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: Fwd: [Suspend2-devel] [patch] 2.2.10.3 build fixes
Hi. On Monday 01 October 2007 05:56:45 Rafael J. Wysocki wrote: > Hi, > > On Sunday, 30 September 2007 13:44, Nigel Cunningham wrote: > > Hi Rafael et al. > > > > This looks like it will be vanilla material, maybe 2.6.23 material? > > Well, I wouldn't like to export freezer.h . Why exactly would that be > necessary? A module that starts a freezeable kthread? I can ask for more details, and will if you like. 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/
Fwd: [Suspend2-devel] [patch] 2.2.10.3 build fixes
Hi Rafael et al. This looks like it will be vanilla material, maybe 2.6.23 material? Regards, Nigel -- Forwarded Message -- Subject: [Suspend2-devel] [patch] 2.2.10.3 build fixes Date: Sunday 30 September 2007 From: "Roman Dubtsov" (dubtsov gmail com) Hi, I have recently run into build issue with 2.6.22 and tuxonice 2.2.10.3. When building custom kernel with make-kpkg the process failed with the message saying: "fs.h requires linux/freezer.h, which does not exist in exported headers". Here's quick-n-dirty patch which fixes this. Hope it is usefull. --- 2.6.22-toi/include/linux/Kbuild.orig 2007-09-30 01:21:30.0 +0700 +++ 2.6.22-toi/include/linux/Kbuild 2007-09-29 23:52:52.0 +0700 @@ -202,6 +202,7 @@ unifdef-y += filter.h unifdef-y += flat.h unifdef-y += futex.h unifdef-y += fs.h +unifdef-y += freezer.h unifdef-y += gameport.h unifdef-y += generic_serial.h unifdef-y += genhd.h - 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/
Fwd: [Suspend2-devel] [patch] 2.2.10.3 build fixes
Hi Rafael et al. This looks like it will be vanilla material, maybe 2.6.23 material? Regards, Nigel -- Forwarded Message -- Subject: [Suspend2-devel] [patch] 2.2.10.3 build fixes Date: Sunday 30 September 2007 From: Roman Dubtsov (dubtsov gmail com) Hi, I have recently run into build issue with 2.6.22 and tuxonice 2.2.10.3. When building custom kernel with make-kpkg the process failed with the message saying: fs.h requires linux/freezer.h, which does not exist in exported headers. Here's quick-n-dirty patch which fixes this. Hope it is usefull. --- 2.6.22-toi/include/linux/Kbuild.orig 2007-09-30 01:21:30.0 +0700 +++ 2.6.22-toi/include/linux/Kbuild 2007-09-29 23:52:52.0 +0700 @@ -202,6 +202,7 @@ unifdef-y += filter.h unifdef-y += flat.h unifdef-y += futex.h unifdef-y += fs.h +unifdef-y += freezer.h unifdef-y += gameport.h unifdef-y += generic_serial.h unifdef-y += genhd.h - 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: Fwd: [Suspend2-devel] [patch] 2.2.10.3 build fixes
Hi. On Monday 01 October 2007 05:56:45 Rafael J. Wysocki wrote: Hi, On Sunday, 30 September 2007 13:44, Nigel Cunningham wrote: Hi Rafael et al. This looks like it will be vanilla material, maybe 2.6.23 material? Well, I wouldn't like to export freezer.h . Why exactly would that be necessary? A module that starts a freezeable kthread? I can ask for more details, and will if you like. 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: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Hi. On Thursday 27 September 2007 16:33:54 Huang, Ying wrote: > On Wed, 2007-09-26 at 16:30 -0400, Joseph Fannin wrote: > > But, in my ignorance, I'm not sure even fixing the ext3 bug will > > guarantee you consistent metadata so that you can handle a > > swap/hibernate file. You can do a sync(), but how do you make that > > not race against running processes without the freezer, or blkdev > > snapshots? > > > > I guess uswsusp and the-patch-previously-known-as-suspend2 handle > > this somehow, though. > > The image-writing kernel of kexec based hibernation run in a controlled > way. It is not used by normal user, so only really necessary process > need to be run. For example, it is possible that there is only one user > process -- the image-writing process running in image-writing kernel. > So, no freezer or blkdev snapshot is needed. You're thinking of the wrong kernel - we were talking about prior to switching to the kexec'd kernel while suspending. 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: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Hi. On Thursday 27 September 2007 16:33:54 Huang, Ying wrote: On Wed, 2007-09-26 at 16:30 -0400, Joseph Fannin wrote: But, in my ignorance, I'm not sure even fixing the ext3 bug will guarantee you consistent metadata so that you can handle a swap/hibernate file. You can do a sync(), but how do you make that not race against running processes without the freezer, or blkdev snapshots? I guess uswsusp and the-patch-previously-known-as-suspend2 handle this somehow, though. The image-writing kernel of kexec based hibernation run in a controlled way. It is not used by normal user, so only really necessary process need to be run. For example, it is possible that there is only one user process -- the image-writing process running in image-writing kernel. So, no freezer or blkdev snapshot is needed. You're thinking of the wrong kernel - we were talking about prior to switching to the kexec'd kernel while suspending. 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: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Hi. On Thursday 27 September 2007 06:30:36 Joseph Fannin wrote: > On Fri, Sep 21, 2007 at 11:45:12AM +0200, Pavel Machek wrote: > > Hi! > > > > > > > > Sounds doable, as long as you can cope with long command lines (which > > > > shouldn't be a biggie). (If you've got a swapfile or parts of a swap > > > > partition already in use, it can be quite fragmented). > > > > > > Hmm. This is an interesting problem. Sharing a swap file or a swap > > > partition with the actual swap of user space pages does seem to be > > > a limitation of this approach. > > > > > > Although the fact that it is simple to write to a separate file may > > > be a reasonable compensation. > > > > I'm not sure how you'd write it to a separate file. Notice that kjump > > kernel may not mount journalling filesystems, not even > > read-only. (Ext3 replays journal in that case). You could pass block > > numbers from the original kernel... > > The ext3 thing is a bug, the case for which I don't think has been > adequately explained to the ext[34] folks. There should be at least a > no_replay mount flag available, or something. It has ramifications > for more than just hibernation. > > And yeah, I'm gonna bring up the swap files thing again. If you > can hibernate to a swap file, you can hibernate to a dedicated > hibernation file, and vice versa. > > If you can't hibernate to a swap file, then swap files are > effectively unsupported for any system you might want to hibernate. > I wonder what embedded folks would think about that > . > > But, in my ignorance, I'm not sure even fixing the ext3 bug will > guarantee you consistent metadata so that you can handle a > swap/hibernate file. You can do a sync(), but how do you make that > not race against running processes without the freezer, or blkdev > snapshots? > > I guess uswsusp and the-patch-previously-known-as-suspend2 handle > this somehow, though. > >(It's that same ignorance that has me waiting for someone with > established credit with kernel people to make that argument for the > ext3 bug, so I can hang my own reasons for thinking that it's bad off > of theirs). I haven't looked at swsusp support, but TuxOnIce handles all storage (swap partitions, swap files and ordinary files) by first allocating swap (if we're using swap), then bmapping the storage we're going to use. After that, we can freeze filesystems and processes with impunity. The allocated storage is then viewed as just a collection of bdevs, each with an ordered chain of extents defining which blocks we're going to read/write - a series of tapes if you like. In the image header, we store dev_ts and the block chains, together with the configuration information. As long as the same bdevs are configured at boot time prior to the echo > /sys/power/resume, we're in business. Filesystems don't need to be mounted because we don't use filesystem code anyway. (LVM etc does though in so far as it's needed to make the dev_t match the device again). This matches with what you said above about hibernating to swap files and dedicated hibernation files - TuxOnIce uses exactly the same code to do the i/o to both; the variation is in the code to recognise the image header and allocate/free/bmap storage. Personally, I don't think ext[34] is broken. If there's data being left in the journal that will need replaying, then mounting without replaying the journal sounds wrong. Perhaps you should instead be arguing that nothing should be left in the journal after a filesystem freeze. But, of course, current code isn't doing a filesystem freeze (just a process freeze) and the kexec guys want to take even that away. In short, I agree. AFAICS, you need both the process freezer and filesystem freezing to make this thing fly properly. 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: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Hi. On Thursday 27 September 2007 06:30:36 Joseph Fannin wrote: On Fri, Sep 21, 2007 at 11:45:12AM +0200, Pavel Machek wrote: Hi! Sounds doable, as long as you can cope with long command lines (which shouldn't be a biggie). (If you've got a swapfile or parts of a swap partition already in use, it can be quite fragmented). Hmm. This is an interesting problem. Sharing a swap file or a swap partition with the actual swap of user space pages does seem to be a limitation of this approach. Although the fact that it is simple to write to a separate file may be a reasonable compensation. I'm not sure how you'd write it to a separate file. Notice that kjump kernel may not mount journalling filesystems, not even read-only. (Ext3 replays journal in that case). You could pass block numbers from the original kernel... The ext3 thing is a bug, the case for which I don't think has been adequately explained to the ext[34] folks. There should be at least a no_replay mount flag available, or something. It has ramifications for more than just hibernation. And yeah, I'm gonna bring up the swap files thing again. If you can hibernate to a swap file, you can hibernate to a dedicated hibernation file, and vice versa. If you can't hibernate to a swap file, then swap files are effectively unsupported for any system you might want to hibernate. handwave I wonder what embedded folks would think about that /handwave. But, in my ignorance, I'm not sure even fixing the ext3 bug will guarantee you consistent metadata so that you can handle a swap/hibernate file. You can do a sync(), but how do you make that not race against running processes without the freezer, or blkdev snapshots? I guess uswsusp and the-patch-previously-known-as-suspend2 handle this somehow, though. (It's that same ignorance that has me waiting for someone with established credit with kernel people to make that argument for the ext3 bug, so I can hang my own reasons for thinking that it's bad off of theirs). I haven't looked at swsusp support, but TuxOnIce handles all storage (swap partitions, swap files and ordinary files) by first allocating swap (if we're using swap), then bmapping the storage we're going to use. After that, we can freeze filesystems and processes with impunity. The allocated storage is then viewed as just a collection of bdevs, each with an ordered chain of extents defining which blocks we're going to read/write - a series of tapes if you like. In the image header, we store dev_ts and the block chains, together with the configuration information. As long as the same bdevs are configured at boot time prior to the echo /sys/power/resume, we're in business. Filesystems don't need to be mounted because we don't use filesystem code anyway. (LVM etc does though in so far as it's needed to make the dev_t match the device again). This matches with what you said above about hibernating to swap files and dedicated hibernation files - TuxOnIce uses exactly the same code to do the i/o to both; the variation is in the code to recognise the image header and allocate/free/bmap storage. not a filesystem expert Personally, I don't think ext[34] is broken. If there's data being left in the journal that will need replaying, then mounting without replaying the journal sounds wrong. Perhaps you should instead be arguing that nothing should be left in the journal after a filesystem freeze. But, of course, current code isn't doing a filesystem freeze (just a process freeze) and the kexec guys want to take even that away. /not a filesystem expert In short, I agree. AFAICS, you need both the process freezer and filesystem freezing to make this thing fly properly. 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: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Hi. On Saturday 22 September 2007 09:19:18 Kyle Moffett wrote: > I think that in order for this to work, there would need to be some > ABI whereby the resume-ing kernel can pass its entire ACPI state and > a bunch of other ACPI-related device details to the resume-ed kernel, > which I believe it does not do at the moment. I believe that what > causes problems is the ACPI state data that the kernel stores is > *different* between identical sequential boots, especially when you > add/remove/replace batteries, AC, etc. That's certainly possible. We already pass a very small amount of data between the boot and resuming kernels at the moment, and it's done quite simply - by putting the variables we want to 'transfer' in a nosave page/section. I could conceive of a scheme wherein this was extended for driver data. Since the memory needed would depend on the drivers loaded, it would probably require that the space be allocated when hibernating, and the locations of structures be stored in the image header and then drivers notified of the locations to use when preparing to resume, but it could work... > Since we currently throw away most of that in-kernel ACPI interpreter > state data when we load the to-be-resumed image and replace it with > the state from the previous boot it looks to the ACPI code and > firmware like our system's hardware magically changed behind its > back. The result is that the ACPI and firmware code is justifiably > confused (although probably it should be more idempotent to begin > with). There's 2 potential solutions: >1) Formalize and copy a *lot* of ACPI state from the resume-ing > kernel to the resume-ed kernel. >2) Properly call the ACPI S4 methods in the proper order ... that said, I don't think the above should be necessary in most cases. I believe we're already calling the ACPI S4 methods in the proper order. If I understood correctly, Rafael put a lot of effort into learning what that was, and into ensuring it does get done. > Neither one is particularly easy or particularly pleasant, especially > given all the vendor bugs in this general area. Theoretically we > should be able to do both, since one will be more reliable than the > other on different systems depending on what kinds of firmware bugs > they have. 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: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Hi. On Friday 21 September 2007 22:18:19 Rafael J. Wysocki wrote: > On Friday, 21 September 2007 13:58, Nigel Cunningham wrote: > > Hi. > > > > On Friday 21 September 2007 21:56:29 Rafael J. Wysocki wrote: > > > [Besides, the current hibernation userland interface is used by default by > > > openSUSE and it's also used by quite some Debian users, so we can't drop > > > it overnight and it can't be implemented in a compatible way on top of the > > > kexec-based solution.] > > > > Could it be fudged by giving userland a null image and having (say) the first > > ioctl be one that triggers all the real work (with other ioctls being noops > > or such like, as appropriate)? > > Well, the "suspend" part is probably doable, but I'm afraid of the "resume" > one. 'k. I've occasionally thought about trying it, but haven't ever gotten around to actually doing it yet. (I'd like to make TuxOnIce transparently replace both swsusp and uswsusp if I could). 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: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Hi. On Friday 21 September 2007 21:56:29 Rafael J. Wysocki wrote: > [Besides, the current hibernation userland interface is used by default by > openSUSE and it's also used by quite some Debian users, so we can't drop > it overnight and it can't be implemented in a compatible way on top of the > kexec-based solution.] Could it be fudged by giving userland a null image and having (say) the first ioctl be one that triggers all the real work (with other ioctls being noops or such like, as appropriate)? 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: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Hi. On Friday 21 September 2007 21:56:29 Rafael J. Wysocki wrote: [Besides, the current hibernation userland interface is used by default by openSUSE and it's also used by quite some Debian users, so we can't drop it overnight and it can't be implemented in a compatible way on top of the kexec-based solution.] Could it be fudged by giving userland a null image and having (say) the first ioctl be one that triggers all the real work (with other ioctls being noops or such like, as appropriate)? 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/
