+327,11 @@ struct platform_hibernation_ops {
> > > > };
> > > >
> > > > #ifdef CONFIG_HIBERNATION
> > > > +
> > > > +/* HMAC Algorithm of Hibernate Signature */
> > > > +#define SWSUSP_HMAC"hmac(sha1)"
>
On Tue, Jul 28, 2015 at 02:35:23PM +0200, Pavel Machek wrote:
> Typo in patch subject.
>
> > And for earsing footbprints, the codes in this patch remove setup
>
> And two typos here.
>
Sorry for subject and above typos, I will fix it.
Thanks.
> > data that carrie
On Thu, Jul 30, 2015 at 05:30:09PM +0100, Matt Fleming wrote:
> On Thu, 2015-07-16 at 22:25 +0800, Lee, Chun-Yi wrote:
> > For forwarding swsusp key from EFI stub to boot kernel, this patch
> > allocates setup data for carrying swsusp key, size and the status
> > of efi opera
cd2a48 100644
> > > --- a/include/linux/suspend.h
> > > +++ b/include/linux/suspend.h
> > > @@ -327,6 +327,11 @@ struct platform_hibernation_ops {
> > > };
> > >
> > > #ifdef CONFIG_HIBERNATION
> > > +
> > > +/
struct platform_hibernation_ops {
> > };
> >
> > #ifdef CONFIG_HIBERNATION
> > +
> > +/* HMAC Algorithm of Hibernate Signature */
> > +#define SWSUSP_HMAC "hmac(sha1)"
> > +#define SWSUSP_DIGEST_SIZE 20
>
> I'd replace
On Thu, 2015-07-16 at 22:25 +0800, Lee, Chun-Yi wrote:
> For forwarding swsusp key from EFI stub to boot kernel, this patch
> allocates setup data for carrying swsusp key, size and the status
> of efi operating.
>
> Signed-off-by: Lee, Chun-Yi
> ---
> arch/x86/boot/compres
Typo in patch subject.
> And for earsing footbprints, the codes in this patch remove setup
And two typos here.
> data that carried swsusp key, and clean the memory space that
And don't call it swsusp. Please fix globally.
WSUSP_HMAC "hmac(sha1)"
> +#define SWSUSP_DIGEST_SIZE 20
I'd replace SWSUSP with HIBERNATION here, and pretty much everywhere.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To uns
This patch provides a ioctl for triggering swsusp key re-generating
process. It's allow user call ioctl to raise the flag of key re-generating.
Kernel writes a flag to a efi runtime variable, the GUID is
S4SignKeyRegen-fe141863-c070-478e-b8a3-878a5dc9ef21, then EFI stub will
re-generates s
Add handler to parse the setup data that carrying swsusp key, it
reserves swsusp key by memblock then copies key to a allocated page
in later initcall stage.
And for earsing footbprints, the codes in this patch remove setup
data that carried swsusp key, and clean the memory space that
reserved by
The HMAC key should only resides in kernel memory space but not leak
to outside. To avoid including swsusp key in hibernate snapshot image,
this patch adds the checking block in the code for asking saveable
pages to make sure the key page should not marked as saveable.
Signed-off-by: Lee, Chun-Yi
For forwarding swsusp key from EFI stub to boot kernel, this patch
allocates setup data for carrying swsusp key, size and the status
of efi operating.
Signed-off-by: Lee, Chun-Yi
---
arch/x86/boot/compressed/eboot.c | 29 +
arch/x86/include/uapi/asm/bootparam.h
Using HMAC-SHA1 to be the HMAC algorithm of signing hibernate
snapshot image. The digest size of HMAC-SHA1 is 160 bits (20 bytes),
this size will be also applied to the length of HMAC key.
In addition, add HIBERNATE_VERIFICATION kernel config.
Signed-off-by: Lee, Chun-Yi
---
include/linux/suspe
On Tue 2014-05-06 13:01:56, Pali Roh?r wrote:
> System can have mmaped also character devices (e.g dri devices by X) or
> deleted
> files. Running cat on character devices is really bad idea (system can hang)
> so
> run cat only on regular files. Also mmaped files can have spaces in filenames.
>
System can have mmaped also character devices (e.g dri devices by X) or deleted
files. Running cat on character devices is really bad idea (system can hang) so
run cat only on regular files. Also mmaped files can have spaces in filenames.
Signed-off-by: Pali Rohár
---
Documentation/power/swsusp.
Michael Tokarev wrote:
> Rafael J. Wysocki wrote:
[]
>> I guess it's a special variation of
>> http://bugzilla.kernel.org/show_bug.cgi?id=9528
>>
>> Please try to hibernate in the shutdown mode (ie. echo
>> "shutdown" into /sys/power/disk before hibernation).
[yes it works with shutdown...]
> In
Rafael J. Wysocki wrote:
> On Friday, 1 of February 2008, Michael Tokarev wrote:
[]
>> no_console_suspend it is. Tried that, the "S|" thing is still
>> here, but instead of "Suspending console(s)" it now shows
>> progress of suspending other devices. The end result is
>> the same - finally it sto
On Fri 2008-02-01 13:16:08, Michael Tokarev wrote:
> Pavel Machek wrote:
> > On Fri 2008-02-01 00:41:06, Michael Tokarev wrote:
> []
> >> With 2.6.24, it tries to suspend, saves pages to disk,
> >> when prints this:
> >>
> >> ..Saving pages... done.
> >> Sl
>
> It's actually "S|", not "Sl".
>
> >
On Friday, 1 of February 2008, Michael Tokarev wrote:
> Pavel Machek wrote:
> > On Fri 2008-02-01 00:41:06, Michael Tokarev wrote:
> []
> >> With 2.6.24, it tries to suspend, saves pages to disk,
> >> when prints this:
> >>
> >> ..Saving pages... done.
> >> Sl
>
> It's actually "S|", not "Sl".
>
Pavel Machek wrote:
> On Fri 2008-02-01 00:41:06, Michael Tokarev wrote:
[]
>> With 2.6.24, it tries to suspend, saves pages to disk,
>> when prints this:
>>
>> ..Saving pages... done.
>> Sl
It's actually "S|", not "Sl".
>> Suspending console(s)
>> _
>>
>> At this point, nothing more happens. It
On Fri 2008-02-01 00:41:06, Michael Tokarev wrote:
> Since I upgraded from 2.6.23 to 2.6.24, suspend to
> disk does not work anymore on this machine. I'm
> trying to debug this now, for several hours already,
> without much luck so far.
>
> The machine is based on AMD X2-64 (BE-2400) CPU and
> NV
Since I upgraded from 2.6.23 to 2.6.24, suspend to
disk does not work anymore on this machine. I'm
trying to debug this now, for several hours already,
without much luck so far.
The machine is based on AMD X2-64 (BE-2400) CPU and
NVidia MCP51PV (GeForce 6150/NForce 430) chipset.
Up until 2.6.23
On Saturday, 12 of January 2008, Rene Herman wrote:
> On 12-01-08 16:21, Pierre Ossman wrote:
>
> > Ah, sorry. It was a different thread. Look for a mail with the subject
> > "PNP: do not stop/start devices in suspend/resume path" in the LKML och
> > linux-pm archives.
>
> Right, and I see that
On Saturday, 12 of January 2008, Rene Herman wrote:
> On 12-01-08 12:12, Pierre Ossman wrote:
>
> > On Sat, 12 Jan 2008 02:23:27 +0100
> > Rene Herman <[EMAIL PROTECTED]> wrote:
> >
> >> Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for
> >> Ondrej after hibernation due
On 12-01-08 16:21, Pierre Ossman wrote:
Ah, sorry. It was a different thread. Look for a mail with the subject
"PNP: do not stop/start devices in suspend/resume path" in the LKML och
linux-pm archives.
Right, and I see that the removal of start/stop is already in -mm. That's
not going to wor
On Saturday 12 January 2008 16:21:50 Pierre Ossman wrote:
> On Sat, 12 Jan 2008 14:39:47 +0100
>
> Rene Herman <[EMAIL PROTECTED]> wrote:
> > On 12-01-08 12:12, Pierre Ossman wrote:
> > > I'm a bit confused here. Bjorn Helgaas wanted to remove the
> > > pnp_start/stop_dev() calls completely, and yo
On Sat, 12 Jan 2008 14:39:47 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
> On 12-01-08 12:12, Pierre Ossman wrote:
>
> > I'm a bit confused here. Bjorn Helgaas wanted to remove the
> > pnp_start/stop_dev() calls completely, and you want them called all the
> > time. :)
>
> Wanted where? Haven
On 12-01-08 12:12, Pierre Ossman wrote:
On Sat, 12 Jan 2008 02:23:27 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for
Ondrej after hibernation due to the PNP_DRIVER_RES_DO_NOT_CHANGE test
triggering in pnp_bus_resume() and
On Sat, 12 Jan 2008 02:23:27 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
>
> Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for
> Ondrej after hibernation due to the PNP_DRIVER_RES_DO_NOT_CHANGE test
> triggering in pnp_bus_resume() and keeping the card in a suspended s
ther
unexpected but doesn't change that suspend/resume wouldn't seem
to have any business testing the flag.
As reported by Ondrej Zary for snd-cs4236, ALSA driven ISAPnP
cards don't survive swsusp hibernation with the resume skipping
setting the resources d
On Friday 11 January 2008 15:21:55 Rene Herman wrote:
> On 11-01-08 08:01, Pierre Ossman wrote:
> > On Fri, 11 Jan 2008 02:19:07 +0100
> >
> > Rene Herman <[EMAIL PROTECTED]> wrote:
> >> I see a PnP resume _consists_ of setting the resources so I can see the
> >> test implementation wise, but yes,
On 11-01-08 08:01, Pierre Ossman wrote:
On Fri, 11 Jan 2008 02:19:07 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
I see a PnP resume _consists_ of setting the resources so I can see the test
implementation wise, but yes, conceptually it seems this test shouldn't be
present. So just like the a
On Fri, 11 Jan 2008 02:19:07 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
>
> I see a PnP resume _consists_ of setting the resources so I can see the test
> implementation wise, but yes, conceptually it seems this test shouldn't be
> present. So just like the attached then?
>
> Pierre, what wa
On 10-01-08 08:58, Jaroslav Kysela wrote:
On Thu, 10 Jan 2008, Rene Herman wrote:
On 09-01-08 23:43, Ondrej Zary wrote:
Jaroslav -- in your role as ISA-PnP maintainer and Bjorn, in yours as
having been foollish enough to touch PnP recently:
as hibernation (swsusp) started to work with my
On Thu, 10 Jan 2008, Rene Herman wrote:
> On 09-01-08 23:43, Ondrej Zary wrote:
>
> Jaroslav -- in your role as ISA-PnP maintainer and Bjorn, in yours as
> having been foollish enough to touch PnP recently:
>
> > as hibernation (swsusp) started to work with my CPU, I
On 09-01-08 23:43, Ondrej Zary wrote:
Jaroslav -- in your role as ISA-PnP maintainer and Bjorn, in yours as having
been foollish enough to touch PnP recently:
as hibernation (swsusp) started to work with my CPU, I found that my Turtle
Beach Malibu stops working after resume from hibernation
Hello,
as hibernation (swsusp) started to work with my CPU, I found that my Turtle
Beach Malibu stops working after resume from hibernation. It's caused by fact
that the card is not enabled on the pnp layer during resume - and thus card
registers are inaccessible (reads return FFs, writ
This makes the altivec code in swsusp_32.S depend on CONFIG_ALTIVEC to
avoid build failures for systems that don't have altivec. I'm not sure
whether the code will actually work for other systems, but it was merged
for just ppc32 rather than powermac a very long time ago.
Signed-off-by: Johannes B
On Wednesday, 17 October 2007 05:44, Qi Yong wrote:
> On Wed, Oct 17, 2007 at 10:46:12AM +0800, Qi Yong wrote:
> > On 12/05/2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > > On Fri, 11 May 2007, Rafael J. Wysocki wrote:
[--snip--]
>
> please apply.
>
> Signed-off-by: Qi Yong <[EMAIL PROTECTED
On Wed, Oct 17, 2007 at 10:46:12AM +0800, Qi Yong wrote:
> On 12/05/2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Fri, 11 May 2007, Rafael J. Wysocki wrote:
> > >
> > > We're working on fixing the breakage, but currently it's difficult,
> > > because
> > > none of my testboxes has
On Wed, 17 Oct 2007, Qi Yong wrote:
>
> The key point is "fall back to shutdown _only_ if !ops, otherwise
> don't touch hibernation_mode". And that solves my problem.
Please, when resurrecting a five-month-old discussion, give more of the
old context.
I don't know about anybody else, but I ge
On 12/05/2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, 11 May 2007, Rafael J. Wysocki wrote:
> >
> > We're working on fixing the breakage, but currently it's difficult, because
> > none of my testboxes has problems with the 'platform' hibernation and I
> > cannot reproduce the repor
On 14/05/2007, Stefan Seyfried <[EMAIL PROTECTED]> wrote:
> On Fri, May 11, 2007 at 03:51:38PM -0700, Linus Torvalds wrote:
> >
> >
> > On Fri, 11 May 2007, Rafael J. Wysocki wrote:
> > >
> > > Just to clarify, the change in question isn't new. It was introduced by
> > > the
> > > commit 9185cfa9
On Tue, 14 Aug 2007, Rafael J. Wysocki wrote:
> On Tuesday, 14 August 2007 00:12, Thomas Voegtle wrote:
> > On Mon, 13 Aug 2007, Rafael J. Wysocki wrote:
> >
> > > On Monday, 13 August 2007 23:31, Thomas Voegtle wrote:
> > > > On Mon, 13 Aug 2007, Rafael J. Wysocki wrote:
> > > >
> > > > > On Su
On Wednesday, 15 August 2007 04:51, Kyle Moffett wrote:
> On Aug 14, 2007, at 19:24:30, Dave Jones wrote:
> > On Tue, Aug 14, 2007 at 11:22:37AM -0700, Andrew Morton wrote:
> >> On Tue, 14 Aug 2007 11:15:41 -0700 (PDT) Linus Torvalds
> >> <[EMAIL PROTECTED]> wrote:
> >>> In other words, it would
On Aug 14, 2007, at 19:24:30, Dave Jones wrote:
On Tue, Aug 14, 2007 at 11:22:37AM -0700, Andrew Morton wrote:
On Tue, 14 Aug 2007 11:15:41 -0700 (PDT) Linus Torvalds
<[EMAIL PROTECTED]> wrote:
In other words, it would be much better to just have per-file
markers, along with some per-subdirec
On Tue, 2007-08-14 at 11:15 -0700, Linus Torvalds wrote:
> In other words, it would be much better to just have per-file markers,
> along with some per-subdirectory stuff or similar.
So that there would be no hot single file, I cut the
MAINTAINER file into single file segments in maintainers/*
0
On Tue, Aug 14, 2007 at 11:22:37AM -0700, Andrew Morton wrote:
> On Tue, 14 Aug 2007 11:15:41 -0700 (PDT)
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > In other words, it would be much better to just have per-file markers,
> > along with some per-subdirectory stuff or similar.
>
> And
On Tue, 2007-08-14 at 11:15 -0700, Linus Torvalds wrote:
> Quite frankly, I think the MAINTAINERS file gets a whole lot uglier this
> way.
Me too.
Chopping up the current file is simple.
How about keeping the whole thing in git?
Please look at thread:
[PATCH] [1/2many] - Find the maintainer(s) f
On 08/14/2007 08:15 PM, Linus Torvalds wrote:
Quite frankly, I think the MAINTAINERS file gets a whole lot uglier this
way.
There's also a rather fundamental issue: this will likely make people
touch the MAINTAINERS file *more*, and from a maintenance standpoint, that
is exactly the wrong th
On Tue, 14 Aug 2007 11:15:41 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> In other words, it would be much better to just have per-file markers,
> along with some per-subdirectory stuff or similar.
And a `make maintainers' target to pull it all together..
(perhaps we could add a
On Tue, 14 Aug 2007, Joe Perches wrote:
>
> SUSPEND TO RAM:
> P:Pavel Machek
> M:[EMAIL PROTECTED]
> P:Rafael J. Wysocki
> M:[EMAIL PROTECTED]
> L:[EMAIL PROTECTED]
> S:Maintained
> F:Documentation/power/
> F:arch/i386/kernel/acpi/
> F:arch/x86_64/kernel/acpi/
tation/power/
> F:arch/i386/kernel/acpi/
> F:arch/x86_64/kernel/acpi/
> F:arch/x86_64/kernel/suspend.c
> F:drivers/base/power/
> F: kernel/power/
> F:include/linux/suspend.h
> F:include/linux/freezer.h
> F:include/linux/pm.h
> F:include/a
nclude/linux/freezer.h
F: include/linux/pm.h
F: include/asm-*/suspend.h
HIBERNATION (aka Software Suspend, aka swsusp)
P: Pavel Machek
M: [EMAIL PROTECTED]
P: Rafael J. Wysocki
M: [EMAIL PROTECTED]
L: [EMAIL PROTECTED]
S: Supported
F: Documentation/power
e/linux/pm.h
F: include/asm-*/suspend.h
(2) suspend
F: Documentation/power/
F: arch/i386/kernel/acpi/
F: arch/x86_64/kernel/acpi/
F: arch/x86_64/kernel/suspend.c
F: drivers/base/power/
F: kernel/power/
F: include/linux/suspend.h
F: include/linux/freezer
suspend to RAM and hibernation would be better?
> >
> > Maybe just collapse the 2 maintainers blocks into one?
No, please don't.
> > HIBERNATION (aka Software Suspend, aka swsusp) and SUSPEND TO RAM:
> > P: Pavel Machek
> > M: [EMAIL PROTECTED]
> > P: R
On Tuesday, 14 August 2007 00:12, Thomas Voegtle wrote:
> On Mon, 13 Aug 2007, Rafael J. Wysocki wrote:
>
> > On Monday, 13 August 2007 23:31, Thomas Voegtle wrote:
> > > On Mon, 13 Aug 2007, Rafael J. Wysocki wrote:
> > >
> > > > On Sunday, 12 August 2007 21:39, Thomas Voegtle wrote:
> > > > >
On Mon, 13 Aug 2007, Rafael J. Wysocki wrote:
> On Monday, 13 August 2007 23:31, Thomas Voegtle wrote:
> > On Mon, 13 Aug 2007, Rafael J. Wysocki wrote:
> >
> > > On Sunday, 12 August 2007 21:39, Thomas Voegtle wrote:
> > > >
> > > > Hi,
> > > >
> > > > today I saw this (output from my suspend
On Monday, 13 August 2007 23:31, Thomas Voegtle wrote:
> On Mon, 13 Aug 2007, Rafael J. Wysocki wrote:
>
> > On Sunday, 12 August 2007 21:39, Thomas Voegtle wrote:
> > >
> > > Hi,
> > >
> > > today I saw this (output from my suspend script):
> > >
> > > -> woke up at Sun Aug 12 11:39:17 CEST 20
On Mon, 13 Aug 2007, Rafael J. Wysocki wrote:
> On Sunday, 12 August 2007 21:39, Thomas Voegtle wrote:
> >
> > Hi,
> >
> > today I saw this (output from my suspend script):
> >
> > -> woke up at Sun Aug 12 11:39:17 CEST 2007
> > -> uptime is
> > 11:39am up 8 days 0:41, 10 users, load avera
relevant for suspend to RAM, so perhaps one common
> > list of files for suspend to RAM and hibernation would be better?
>
> Maybe just collapse the 2 maintainers blocks into one?
>
> HIBERNATION (aka Software Suspend, aka swsusp) and SUSPEND TO RAM:
> P:Pavel Machek
> M
and hibernation would be better?
Maybe just collapse the 2 maintainers blocks into one?
HIBERNATION (aka Software Suspend, aka swsusp) and SUSPEND TO RAM:
P: Pavel Machek
M: [EMAIL PROTECTED]
P: Rafael J. Wysocki
M: [EMAIL PROTECTED]
L: [EMAIL PROTECTED]
S: Supported
uspend to RAM and hibernation would be better?
> HIBERNATION (aka Software Suspend, aka swsusp):
> P:Pavel Machek
> M:[EMAIL PROTECTED]
> P:Rafael J. Wysocki
> M:[EMAIL PROTECTED]
> L:[EMAIL PROTECTED]
> S:Supported
> F:Documentation/power/swsusp*
> F:a
On Sunday, 12 August 2007 21:39, Thomas Voegtle wrote:
>
> Hi,
>
> today I saw this (output from my suspend script):
>
> -> woke up at Sun Aug 12 11:39:17 CEST 2007
> -> uptime is
> 11:39am up 8 days 0:41, 10 users, load average: 26.12, 6.35, 2.17
>
>
> Then I did a software suspend. Afte
HIBERNATION (aka Software Suspend, aka swsusp):
P: Pavel Machek
M: [EMAIL PROTECTED]
P: Rafael J. Wysocki
M: [EMAIL PROTECTED]
L: [EMAIL PROTECTED]
S: Supported
F: Documentation/power/swsusp*
F: arch/i386/power/
F: arch/x86_64/kernel/suspend*
F:
NERS
> @@ -4215,6 +4215,9 @@ P: Rafael J. Wysocki
> M: [EMAIL PROTECTED]
> L: [EMAIL PROTECTED]
> S: Supported
> +F: Documentation/power/swsusp*
> +F: arch/i386/power/swsusp.S
> +F: kernel/power/
Well, the list isn't complete. Please add
arch/i386/po
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
ACK.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo
ED]
S: Supported
+F: Documentation/power/swsusp*
+F: arch/i386/power/swsusp.S
+F: kernel/power/
SUSPEND TO RAM:
P: Pavel Machek
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordo
Hi,
today I saw this (output from my suspend script):
-> woke up at Sun Aug 12 11:39:17 CEST 2007
-> uptime is
11:39am up 8 days 0:41, 10 users, load average: 26.12, 6.35, 2.17
Then I did a software suspend. After waking up, I saw this:
-> woke up at Sun Aug 12 14:41:56 CEST 2007
-> upt
diusz Miskiewicz, and
> make it impossible to thaw tasks with the help of the swsusp userland
> interface
> while there is a snapshot image ready to save.
>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
ACK.
[2.6.22 candidate, IMHO]
---
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Fix oops caused by 'cat /dev/snapshot', reported by Arkadiusz Miskiewicz, and
make it impossible to thaw tasks with the help of the swsusp userland interface
while there is a snapshot image ready to save
quot;PM: writing image.\n");
- error = swsusp_write();
+ error = swsusp_write(flags);
swsusp_free();
if (!error)
power_down();
@@ -295,6 +330,7 @@ int hibernate(void)
static int software_resume(void)
{
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Change the code ordering so that hibernation_ops->prepare() is called after
device_suspend(). This is needed so that we don't violate the ACPI
specification, which states that the _PTS and _GTS system-control methods,
executed from acpi_sleep_prepare(),
/* Control returns here after successful restore */
+ } else {
+ printk("swsusp debug: Waiting for 5 seconds.\n");
+ mdelay(5000);
+ }
+ }
+ enable_nonboot_cpus();
+ Resume_devices:
+ platform_fini
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Make the code hibernation code in kernel/power/user.c be functionally equivalent
to the corresponding code in kernel/power/disk.c , as it should be.
The calls to the platform functions removed by this patch are incorrect. They
should be replaced with s
Hi,
In the face of the recent change of suspend code ordering
(cf. http://marc.info/?l=linux-acpi&m=117938245931603&w=2) we should also
modify the code ordering in swsusp so that hibernation_ops->prepare() is
executed after device_suspend().
However, for this purpose it seems re
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
The sysfs files /sys/power/disk and /sys/power/state do not work as documented,
since they allow the user to write only a few initial characters of the
input string to trigger the option (eg. 'echo pl > /sys/power/disk' activates
the platform mode of hib
On Fri, May 11, 2007 at 03:51:38PM -0700, Linus Torvalds wrote:
>
>
> On Fri, 11 May 2007, Rafael J. Wysocki wrote:
> >
> > Just to clarify, the change in question isn't new. It was introduced by the
> > commit 9185cfa92507d07ac787bc73d06c4eec7239 before 2.6.20, at Seife's
> > request and w
Rafael J. Wysocki wrote:
On Friday, 11 May 2007 18:30, Linus Torvalds wrote:
On Fri, 11 May 2007, Rafael J. Wysocki wrote:
We're working on fixing the breakage, but currently it's difficult, because
none of my testboxes has problems with the 'platform' hibernation and I
cannot reproduce the rep
I agree that we should keep the "platform" default,
as it went in 2 releases ago (nearly 6 months) without
any reported failures until this one -- and it fixed
a longstanding issue documented on many machines.
We should debug Qi's failure like any other.
We are actually in better shape on this one
Hi!
> > Just to clarify, the change in question isn't new. It was introduced by the
> > commit 9185cfa92507d07ac787bc73d06c4eec7239 before 2.6.20, at Seife's
> > request and with Pavel's acceptance.
>
> Ok, if it's that old, we migt as leave it in. Clearly there weren't many
> regressions,
On Fri, 11 May 2007, Rafael J. Wysocki wrote:
>
> Just to clarify, the change in question isn't new. It was introduced by the
> commit 9185cfa92507d07ac787bc73d06c4eec7239 before 2.6.20, at Seife's
> request and with Pavel's acceptance.
Ok, if it's that old, we migt as leave it in. Clearly
On Friday, 11 May 2007 18:30, Linus Torvalds wrote:
>
> On Fri, 11 May 2007, Rafael J. Wysocki wrote:
> >
> > We're working on fixing the breakage, but currently it's difficult, because
> > none of my testboxes has problems with the 'platform' hibernation and I
> > cannot reproduce the reported i
On Fri, 11 May 2007, Rafael J. Wysocki wrote:
>
> We're working on fixing the breakage, but currently it's difficult, because
> none of my testboxes has problems with the 'platform' hibernation and I
> cannot reproduce the reported issues.
The rule for anything ACPI-related has been: no regress
Hi!
> today I experienced OOPS when connected via BT/GPRS to the internet, then
> swsup and resumed with dongle in HID proxy mode. Please see details in dmesg
> log:
I have had similar problems --but never quite repeatable. I believe I
even have patch somewhere, but I was not able to properly t
t; from disk is limited if the system is simply powered off during the
> > > suspend
> > > instead of using the ACPI S4 suspend (aka platform mode).
> > >
> > > Unfortunately the default is currently to power off the system during the
> > > suspend so the users o
't switch to the platform mode explicitly. This patch makes swsusp
> use the platform mode by default to avoid such situations.
>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
> ---
> kernel/power/disk.c |8 +---
> kernel/power/main.c |2 +-
> 2 f
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Fix a typo in the comment before register_nosave_region().
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
kernel/power/snapshot.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.21/kernel/power/snapshot.c
==
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Make sure that hibernation_mode is set to a reasonable value by default.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
kernel/power/disk.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
Index: linux-2.6.21/kernel/power/di
Hi Stefan,
thanks for verification on not tainted kernel. I made same test with same
error with/without tainted kernel too.
Michal
Dne pondělí 07 květen 2007 09:40 Stefan Seyfried napsal(a):
> On Mon, May 07, 2007 at 12:05:33AM +0200, CIJOML wrote:
> > Hi all,
> >
> > today I experienced OOPS w
On Mon, May 07, 2007 at 12:05:33AM +0200, CIJOML wrote:
> Hi all,
>
> today I experienced OOPS when connected via BT/GPRS to the internet, then
> swsup and resumed with dongle in HID proxy mode. Please see details in dmesg
> log:
I got two similar looking oopsen when my mobile phone crashed and
On Mon, May 07, 2007 at 07:04:29AM +0200, CIJOML wrote:
> Hi Michal,
>
> my kernel is tainted with madwifi opensource driver :). Only binary part is
> ath_hal module, which doesn't have anythink to do with this part of kernel.
Any module can change any part of the kernel, e.g. a part of the code
Hi Michal,
my kernel is tainted with madwifi opensource driver :). Only binary part is
ath_hal module, which doesn't have anythink to do with this part of kernel.
Ath_hal is doing RF part of card to protect others tune/transmit in other
frequency than 2.5/5.8GHz (Wifi 802.11a/b/g).
My kernel is
Hi all,
today I experienced OOPS when connected via BT/GPRS to the internet, then
swsup and resumed with dongle in HID proxy mode. Please see details in dmesg
log:
Restarting tasks ... <6>usb 3-1: USB disconnect, address 3
done.
BUG: unable to handle kernel NULL pointer dereference at virtual a
On 5/5/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
On Saturday, 5 May 2007 01:11, Ray Lee wrote:
> On 5/4/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > The change of the hibernation/suspend code ordering made before 2.6.21 has
> > caused some systems to have problems related to ACPI.
On Saturday, 5 May 2007 01:11, Ray Lee wrote:
> On 5/4/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > The change of the hibernation/suspend code ordering made before 2.6.21 has
> > caused some systems to have problems related to ACPI. In particular, the
> > 'platform' hibernation mode doesn'
On 5/4/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
The change of the hibernation/suspend code ordering made before 2.6.21 has
caused some systems to have problems related to ACPI. In particular, the
'platform' hibernation mode doesn't work any more on some systems.
It seems that somewhere
7;platform' hibernation mode doesn't work any more on some systems.
> > >
> > > It has been confirmed that the appended patch fixes the problem, but it's
> > > not
> > > certain if this changes don't break some other systems. For this reaso
e appended patch fixes the problem, but it's not
> certain if this changes don't break some other systems. For this reason, all
> users of hibernation (swsusp, uswsusp) are gently requested to verify if this
> patch doesn't break their systems.
>
> Greetings,
>
I. In particular, the
'platform' hibernation mode doesn't work any more on some systems.
It has been confirmed that the appended patch fixes the problem, but it's not
certain if this changes don't break some other systems. For this reason, all
users of hibernation (swsusp
1 - 100 of 818 matches
Mail list logo
