Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Thursday, 11 October 2007 22:54, Pavel Machek wrote: > Hi! > > > > 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. > > > > Well, if the boot and image kernels are different, which is now possible on > > x86_64 with some recent patches (currently in -mm), the nosave trick won't > > work. > > I guess we should remove the nosave at least from x86-64. If > someone tries to use it, he'll get a nasty surprise. Agreed. I'll try to prepare a patch for that when I have a bit of time. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Hi! > > 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. > > Well, if the boot and image kernels are different, which is now possible on > x86_64 with some recent patches (currently in -mm), the nosave trick won't > work. I guess we should remove the nosave at least from x86-64. If someone tries to use it, he'll get a nasty surprise. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Hi! 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. Well, if the boot and image kernels are different, which is now possible on x86_64 with some recent patches (currently in -mm), the nosave trick won't work. I guess we should remove the nosave at least from x86-64. If someone tries to use it, he'll get a nasty surprise. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Thursday, 11 October 2007 22:54, Pavel Machek wrote: Hi! 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. Well, if the boot and image kernels are different, which is now possible on x86_64 with some recent patches (currently in -mm), the nosave trick won't work. I guess we should remove the nosave at least from x86-64. If someone tries to use it, he'll get a nasty surprise. Agreed. I'll try to prepare a patch for that when I have a bit of time. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
FWIW, on all the hardware I have, Windows is able to deal with: (1) hibernate Windows (2) run $(OTHER_OS) (3) resume Windows ... which seems to me to say that Linux is doing it wrong if it can't handle other ACPI users between hibernate and resume. But maybe that's just my hardware. -- Joseph Fannin [EMAIL PROTECTED] - 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
FWIW, on all the hardware I have, Windows is able to deal with: (1) hibernate Windows (2) run $(OTHER_OS) (3) resume Windows ... which seems to me to say that Linux is doing it wrong if it can't handle other ACPI users between hibernate and resume. But maybe that's just my hardware. -- Joseph Fannin [EMAIL PROTECTED] - 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
On Saturday, 22 September 2007 20:00, Kyle Moffett wrote: > On Sep 22, 2007, at 06:34:17, Rafael J. Wysocki wrote: > > On Saturday, 22 September 2007 01:19, Kyle Moffett wrote: > >> On Sep 21, 2007, at 17:16:59, Jeremy Maitin-Shepard wrote: > >>> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > The ACPI platform firmware is allowed to preserve information > accross the hibernation-resume cycle, so this need not be the same. > >>> > >>> All of my comments related to the case where S4 is not being used > >>> (instead the system is just powered off normally), and a boot > >>> kernel that does not initialize ACPI is used. In that case, the > >>> ACPI platform firmware should not be able to distinguish a normal > >>> boot from a resume from hibernation. > >> > >> 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. > > > > In fact we don't need to do this. > > > > The solution is not to touch ACPI in the boot kernel (ie. the one > > that loads the image) and pass control to the image kernel. This > > is how it's supposed to work according to the spec, more or less > > (well, there are some ugly details that need handling, like the > > restoration of the NVS area). > > First of all, we will need to make the resumed kernel throw away > *ALL* of its ACPI state on S5 and completely reinitialize ACPI as > though it was booting for the first time on resume. Yes, if we entered S5 in the last step of the hibernation sequence, the right thing to do would be to make the resumed kernel reinitialize ACPI from scratch. > From what I can tell, we "throw away" all the ACPI state in the boot kernel > and reinitialize it there, but then the reinitialized state is > overwritten with the resumed kernel's state and the two don't always > happen to be the same. (Like if a battery got replaced or AC status > changed). Usually it goes like that. Still, you can pass "acpi=off" to the boot kernel, in which case it won't reinitialize ACPI. > Umm, I don't see how that can possibly work properly. For a laptop, > for example, the restore kernel will need to access the disk, the LCD > display, and possibly the AC/battery and current CPU frequency. From > what I understand of ACPI, both of the former may need ACPI code to > operate properly (Isn't there an ATA taskfile object of some kind?) > and the latter two almost definitely need ACPI. Well, this is not the case on any systems that I have access to, including two quite modern notebooks. Apparently, everything works without ACPI on these machines. Besides, in theory, it's possible to use an "intelligent" boot loader to read the hibernation image and that doesn't need ACPI for anything. > Ergo the boot kernel may need to initialize and use ACPI just to run an ATA > taskfile so it can read from the HDD efficiently. It is possible, but I haven't seen that yet. > >> 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. > > > > Rather the ACPI state data that the platform firmware stores may be > > different, depending on whether you enter S4 or S5 during "power > > off" and that determines the interactions between the kernel and > > the firmware after the next boot. > > That's not what he was talking about. The problem discussed was: >(A) You hibernate your box, entering S5 (IE: power off) >(B) You resume the box and the boot kernel inits all the ACPI stuff. >(C) The boot kernel's ACPI state is completely replaced by the > resumed kernel's state. >(D) Hardware stops working mysteriously because of ACPI problems. > > The only possible conclusion is that the state between the boot > kernel and the resume kernel was *different* and so the device failed > because the ACPI state in the resume kernel doesn't match the actual > state of the hardware. I think it's even more complicated. The ACPI state of the resumed kernel has to match whatever is preserved by the platform. Well, my impression is that our current ACPI resume code actually expects the platform to preserve something and if that's missing the devices in question are not handled properly. If that really is the case, there is the question whether we can do something about it in a reasonable way and I can't answer it right now. Besides, I really think that we should use the ACPI S4 state, because machines generally support that. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Sep 22, 2007, at 06:34:17, Rafael J. Wysocki wrote: On Saturday, 22 September 2007 01:19, Kyle Moffett wrote: On Sep 21, 2007, at 17:16:59, Jeremy Maitin-Shepard wrote: "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: The ACPI platform firmware is allowed to preserve information accross the hibernation-resume cycle, so this need not be the same. All of my comments related to the case where S4 is not being used (instead the system is just powered off normally), and a boot kernel that does not initialize ACPI is used. In that case, the ACPI platform firmware should not be able to distinguish a normal boot from a resume from hibernation. 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. In fact we don't need to do this. The solution is not to touch ACPI in the boot kernel (ie. the one that loads the image) and pass control to the image kernel. This is how it's supposed to work according to the spec, more or less (well, there are some ugly details that need handling, like the restoration of the NVS area). First of all, we will need to make the resumed kernel throw away *ALL* of its ACPI state on S5 and completely reinitialize ACPI as though it was booting for the first time on resume. From what I can tell, we "throw away" all the ACPI state in the boot kernel and reinitialize it there, but then the reinitialized state is overwritten with the resumed kernel's state and the two don't always happen to be the same. (Like if a battery got replaced or AC status changed). Umm, I don't see how that can possibly work properly. For a laptop, for example, the restore kernel will need to access the disk, the LCD display, and possibly the AC/battery and current CPU frequency. From what I understand of ACPI, both of the former may need ACPI code to operate properly (Isn't there an ATA taskfile object of some kind?) and the latter two almost definitely need ACPI. Ergo the boot kernel may need to initialize and use ACPI just to run an ATA taskfile so it can read from the HDD efficiently. 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. Rather the ACPI state data that the platform firmware stores may be different, depending on whether you enter S4 or S5 during "power off" and that determines the interactions between the kernel and the firmware after the next boot. That's not what he was talking about. The problem discussed was: (A) You hibernate your box, entering S5 (IE: power off) (B) You resume the box and the boot kernel inits all the ACPI stuff. (C) The boot kernel's ACPI state is completely replaced by the resumed kernel's state. (D) Hardware stops working mysteriously because of ACPI problems. The only possible conclusion is that the state between the boot kernel and the resume kernel was *different* and so the device failed because the ACPI state in the resume kernel doesn't match the actual state of the hardware. Cheers, Kyle Moffett - 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
On Saturday, 22 September 2007 01:47, Nigel Cunningham wrote: > 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. Well, if the boot and image kernels are different, which is now possible on x86_64 with some recent patches (currently in -mm), the nosave trick won't work. Still, I don't think we need to pass anything from the boot to the image kernel. Moreover, we shouldn't do that, IMO (arguably, the boot kernel could be replaced with a resume-aware boot loader). > 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. Yes, I did, but I can be wrong nevertheless. ;-) Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Saturday, 22 September 2007 01:19, Kyle Moffett wrote: > On Sep 21, 2007, at 17:16:59, Jeremy Maitin-Shepard wrote: > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > >> The ACPI platform firmware is allowed to preserve information > >> accross the hibernation-resume cycle, so this need not be the same. > > > > All of my comments related to the case where S4 is not being used > > (instead the system is just powered off normally), and a boot > > kernel that does not initialize ACPI is used. In that case, the > > ACPI platform firmware should not be able to distinguish a normal > > boot from a resume from hibernation. > > 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. In fact we don't need to do this. The solution is not to touch ACPI in the boot kernel (ie. the one that loads the image) and pass control to the image kernel. This is how it's supposed to work according to the spec, more or less (well, there are some ugly details that need handling, like the restoration of the NVS area). > 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. Rather the ACPI state data that the platform firmware stores may be different, depending on whether you enter S4 or S5 during "power off" and that determines the interactions between the kernel and the firmware after the next boot. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Saturday, 22 September 2007 01:19, Kyle Moffett wrote: On Sep 21, 2007, at 17:16:59, Jeremy Maitin-Shepard wrote: Rafael J. Wysocki [EMAIL PROTECTED] writes: The ACPI platform firmware is allowed to preserve information accross the hibernation-resume cycle, so this need not be the same. All of my comments related to the case where S4 is not being used (instead the system is just powered off normally), and a boot kernel that does not initialize ACPI is used. In that case, the ACPI platform firmware should not be able to distinguish a normal boot from a resume from hibernation. 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. In fact we don't need to do this. The solution is not to touch ACPI in the boot kernel (ie. the one that loads the image) and pass control to the image kernel. This is how it's supposed to work according to the spec, more or less (well, there are some ugly details that need handling, like the restoration of the NVS area). 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. Rather the ACPI state data that the platform firmware stores may be different, depending on whether you enter S4 or S5 during power off and that determines the interactions between the kernel and the firmware after the next boot. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Saturday, 22 September 2007 01:47, Nigel Cunningham wrote: 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. Well, if the boot and image kernels are different, which is now possible on x86_64 with some recent patches (currently in -mm), the nosave trick won't work. Still, I don't think we need to pass anything from the boot to the image kernel. Moreover, we shouldn't do that, IMO (arguably, the boot kernel could be replaced with a resume-aware boot loader). 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. Yes, I did, but I can be wrong nevertheless. ;-) Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Sep 22, 2007, at 06:34:17, Rafael J. Wysocki wrote: On Saturday, 22 September 2007 01:19, Kyle Moffett wrote: On Sep 21, 2007, at 17:16:59, Jeremy Maitin-Shepard wrote: Rafael J. Wysocki [EMAIL PROTECTED] writes: The ACPI platform firmware is allowed to preserve information accross the hibernation-resume cycle, so this need not be the same. All of my comments related to the case where S4 is not being used (instead the system is just powered off normally), and a boot kernel that does not initialize ACPI is used. In that case, the ACPI platform firmware should not be able to distinguish a normal boot from a resume from hibernation. 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. In fact we don't need to do this. The solution is not to touch ACPI in the boot kernel (ie. the one that loads the image) and pass control to the image kernel. This is how it's supposed to work according to the spec, more or less (well, there are some ugly details that need handling, like the restoration of the NVS area). First of all, we will need to make the resumed kernel throw away *ALL* of its ACPI state on S5 and completely reinitialize ACPI as though it was booting for the first time on resume. From what I can tell, we throw away all the ACPI state in the boot kernel and reinitialize it there, but then the reinitialized state is overwritten with the resumed kernel's state and the two don't always happen to be the same. (Like if a battery got replaced or AC status changed). Umm, I don't see how that can possibly work properly. For a laptop, for example, the restore kernel will need to access the disk, the LCD display, and possibly the AC/battery and current CPU frequency. From what I understand of ACPI, both of the former may need ACPI code to operate properly (Isn't there an ATA taskfile object of some kind?) and the latter two almost definitely need ACPI. Ergo the boot kernel may need to initialize and use ACPI just to run an ATA taskfile so it can read from the HDD efficiently. 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. Rather the ACPI state data that the platform firmware stores may be different, depending on whether you enter S4 or S5 during power off and that determines the interactions between the kernel and the firmware after the next boot. That's not what he was talking about. The problem discussed was: (A) You hibernate your box, entering S5 (IE: power off) (B) You resume the box and the boot kernel inits all the ACPI stuff. (C) The boot kernel's ACPI state is completely replaced by the resumed kernel's state. (D) Hardware stops working mysteriously because of ACPI problems. The only possible conclusion is that the state between the boot kernel and the resume kernel was *different* and so the device failed because the ACPI state in the resume kernel doesn't match the actual state of the hardware. Cheers, Kyle Moffett - 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
On Saturday, 22 September 2007 20:00, Kyle Moffett wrote: On Sep 22, 2007, at 06:34:17, Rafael J. Wysocki wrote: On Saturday, 22 September 2007 01:19, Kyle Moffett wrote: On Sep 21, 2007, at 17:16:59, Jeremy Maitin-Shepard wrote: Rafael J. Wysocki [EMAIL PROTECTED] writes: The ACPI platform firmware is allowed to preserve information accross the hibernation-resume cycle, so this need not be the same. All of my comments related to the case where S4 is not being used (instead the system is just powered off normally), and a boot kernel that does not initialize ACPI is used. In that case, the ACPI platform firmware should not be able to distinguish a normal boot from a resume from hibernation. 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. In fact we don't need to do this. The solution is not to touch ACPI in the boot kernel (ie. the one that loads the image) and pass control to the image kernel. This is how it's supposed to work according to the spec, more or less (well, there are some ugly details that need handling, like the restoration of the NVS area). First of all, we will need to make the resumed kernel throw away *ALL* of its ACPI state on S5 and completely reinitialize ACPI as though it was booting for the first time on resume. Yes, if we entered S5 in the last step of the hibernation sequence, the right thing to do would be to make the resumed kernel reinitialize ACPI from scratch. From what I can tell, we throw away all the ACPI state in the boot kernel and reinitialize it there, but then the reinitialized state is overwritten with the resumed kernel's state and the two don't always happen to be the same. (Like if a battery got replaced or AC status changed). Usually it goes like that. Still, you can pass acpi=off to the boot kernel, in which case it won't reinitialize ACPI. Umm, I don't see how that can possibly work properly. For a laptop, for example, the restore kernel will need to access the disk, the LCD display, and possibly the AC/battery and current CPU frequency. From what I understand of ACPI, both of the former may need ACPI code to operate properly (Isn't there an ATA taskfile object of some kind?) and the latter two almost definitely need ACPI. Well, this is not the case on any systems that I have access to, including two quite modern notebooks. Apparently, everything works without ACPI on these machines. Besides, in theory, it's possible to use an intelligent boot loader to read the hibernation image and that doesn't need ACPI for anything. Ergo the boot kernel may need to initialize and use ACPI just to run an ATA taskfile so it can read from the HDD efficiently. It is possible, but I haven't seen that yet. 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. Rather the ACPI state data that the platform firmware stores may be different, depending on whether you enter S4 or S5 during power off and that determines the interactions between the kernel and the firmware after the next boot. That's not what he was talking about. The problem discussed was: (A) You hibernate your box, entering S5 (IE: power off) (B) You resume the box and the boot kernel inits all the ACPI stuff. (C) The boot kernel's ACPI state is completely replaced by the resumed kernel's state. (D) Hardware stops working mysteriously because of ACPI problems. The only possible conclusion is that the state between the boot kernel and the resume kernel was *different* and so the device failed because the ACPI state in the resume kernel doesn't match the actual state of the hardware. I think it's even more complicated. The ACPI state of the resumed kernel has to match whatever is preserved by the platform. Well, my impression is that our current ACPI resume code actually expects the platform to preserve something and if that's missing the devices in question are not handled properly. If that really is the case, there is the question whether we can do something about it in a reasonable way and I can't answer it right now. Besides, I really think that we should use the ACPI S4 state, because machines generally support that. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [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: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Sep 21, 2007, at 17:16:59, Jeremy Maitin-Shepard wrote: "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: The ACPI platform firmware is allowed to preserve information accross the hibernation-resume cycle, so this need not be the same. All of my comments related to the case where S4 is not being used (instead the system is just powered off normally), and a boot kernel that does not initialize ACPI is used. In that case, the ACPI platform firmware should not be able to distinguish a normal boot from a resume from hibernation. 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. 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 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. Cheers, Kyle Moffett - 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
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > On Friday, 21 September 2007 23:08, Jeremy Maitin-Shepard wrote: >> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: >> >> > On Friday, 21 September 2007 22:26, Jeremy Maitin-Shepard wrote: >> >> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: >> >> >> >> [snip] >> >> >> >> > The ACPI NVS area is explicitly marked as reserved and we don't save it. >> >> > On x86_64 we don't save any memory areas marked as reserved and yet the >> > above >> >> > happens. >> >> >> >> I think you have mentioned before, though, that ACPI is first >> >> initialized by the boot kernel, before it is later initialized by >> >> resuming kernel. This could well be the source of the problem. >> >> > No, it's not. I have tested that too with an ACPI-less boot kernel. >> >> Well, it seems that there just must be some other bug. I would define >> anything that differs between the post-resume initialization of ACPI > I'm not sure what you mean. >> from the normal boot initialization of ACPI as a bug. If the interaction >> with the hardware is the same, then the behavior will be the same. > The ACPI platform firmware is allowed to preserve information accross the > hibernation-resume cycle, so this need not be the same. All of my comments related to the case where S4 is not being used (instead the system is just powered off normally), and a boot kernel that does not initialize ACPI is used. In that case, the ACPI platform firmware should not be able to distinguish a normal boot from a resume from hibernation. -- Jeremy Maitin-Shepard - 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
On Friday, 21 September 2007 23:08, Jeremy Maitin-Shepard wrote: > "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > > > On Friday, 21 September 2007 22:26, Jeremy Maitin-Shepard wrote: > >> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > >> > >> [snip] > >> > >> > The ACPI NVS area is explicitly marked as reserved and we don't save it. > >> > On x86_64 we don't save any memory areas marked as reserved and yet the > > above > >> > happens. > >> > >> I think you have mentioned before, though, that ACPI is first > >> initialized by the boot kernel, before it is later initialized by > >> resuming kernel. This could well be the source of the problem. > > > No, it's not. I have tested that too with an ACPI-less boot kernel. > > Well, it seems that there just must be some other bug. I would define > anything that differs between the post-resume initialization of ACPI I'm not sure what you mean. > from the normal boot initialization of ACPI as a bug. If the interaction > with the hardware is the same, then the behavior will be the same. The ACPI platform firmware is allowed to preserve information accross the hibernation-resume cycle, so this need not be the same. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > On Friday, 21 September 2007 22:26, Jeremy Maitin-Shepard wrote: >> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: >> >> [snip] >> >> > The ACPI NVS area is explicitly marked as reserved and we don't save it. >> > On x86_64 we don't save any memory areas marked as reserved and yet the > above >> > happens. >> >> I think you have mentioned before, though, that ACPI is first >> initialized by the boot kernel, before it is later initialized by >> resuming kernel. This could well be the source of the problem. > No, it's not. I have tested that too with an ACPI-less boot kernel. Well, it seems that there just must be some other bug. I would define anything that differs between the post-resume initialization of ACPI from the normal boot initialization of ACPI as a bug. If the interaction with the hardware is the same, then the behavior will be the same. -- Jeremy Maitin-Shepard - 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
On Friday, 21 September 2007 22:26, Jeremy Maitin-Shepard wrote: > "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > > [snip] > > > The ACPI NVS area is explicitly marked as reserved and we don't save it. > > On x86_64 we don't save any memory areas marked as reserved and yet the > > above > > happens. > > I think you have mentioned before, though, that ACPI is first > initialized by the boot kernel, before it is later initialized by > resuming kernel. This could well be the source of the problem. No, it's not. I have tested that too with an ACPI-less boot kernel. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: [snip] > The ACPI NVS area is explicitly marked as reserved and we don't save it. > On x86_64 we don't save any memory areas marked as reserved and yet the above > happens. I think you have mentioned before, though, that ACPI is first initialized by the boot kernel, before it is later initialized by resuming kernel. This could well be the source of the problem. In particular, isn't it the case that you also switch the devices to low power mode before resuming? -- Jeremy Maitin-Shepard - 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
On Friday, 21 September 2007 21:45, Alan Stern wrote: > On Fri, 21 Sep 2007, Rafael J. Wysocki wrote: > > > > > Well, the problem is that apparently some systems (eg. my HP nx6325) > > > > expect us > > > > to execute the _PTS ACPI global control method before creating the > > > > image _and_ > > > > to execute acpi_enter_sleep_state(ACPI_STATE_S4) in order to finally > > > > put the > > > > system into the sleep state. In particular, on nx6325, if we don't do > > > > that, > > > > then after the restore the status of the AC power will not be reported > > > > correctly (and if you replace the battery while in the sleep state, the > > > > battery status will not be updated correctly after the restore). > > > > Similar > > > > issues have been reported for other machines. > > > > > > Suppose that instead of using ACPI S4 state at all, you instead just > > > power off. Yes, you'll lose wakeup event functionality, and flashy > > > LEDs, but doesn't this take care of the problem? > > > > Nope. > > > > > The firmware shouldn't see the hibernate as anything other than a shutdown > > > and reboot. > > > > Actually, this assumption is apparently wrong. > > One gets the impression that the hibernation image includes a memory > area used by the firmware. That could explain why devices need to be > in a low-power state when the image is created -- so that when the > image is restored, the firmware doesn't get confused about the device > states. > > It would also explain why the firmware sees > resume-from-power-off-hibernation as different from a regular reboot: > because its data area gets overwritten as part of the resume. > > In reality it's probably more complicated than this, with weird > interactions between the firmware and the various ACPI methods. > Nevertheless, the main idea seems valid. I guess so, but I'm not sure. The ACPI NVS area is explicitly marked as reserved and we don't save it. On x86_64 we don't save any memory areas marked as reserved and yet the above happens. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Fri, 21 Sep 2007, Rafael J. Wysocki wrote: > > > Well, the problem is that apparently some systems (eg. my HP nx6325) > > > expect us > > > to execute the _PTS ACPI global control method before creating the image > > > _and_ > > > to execute acpi_enter_sleep_state(ACPI_STATE_S4) in order to finally put > > > the > > > system into the sleep state. In particular, on nx6325, if we don't do > > > that, > > > then after the restore the status of the AC power will not be reported > > > correctly (and if you replace the battery while in the sleep state, the > > > battery status will not be updated correctly after the restore). Similar > > > issues have been reported for other machines. > > > > Suppose that instead of using ACPI S4 state at all, you instead just > > power off. Yes, you'll lose wakeup event functionality, and flashy > > LEDs, but doesn't this take care of the problem? > > Nope. > > > The firmware shouldn't see the hibernate as anything other than a shutdown > > and reboot. > > Actually, this assumption is apparently wrong. One gets the impression that the hibernation image includes a memory area used by the firmware. That could explain why devices need to be in a low-power state when the image is created -- so that when the image is restored, the firmware doesn't get confused about the device states. It would also explain why the firmware sees resume-from-power-off-hibernation as different from a regular reboot: because its data area gets overwritten as part of the resume. In reality it's probably more complicated than this, with weird interactions between the firmware and the various ACPI methods. Nevertheless, the main idea seems valid. Alan Stern - 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
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > On Friday, 21 September 2007 15:14, huang ying wrote: >> On 9/21/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: >> > On Friday, 21 September 2007 05:33, Eric W. Biederman wrote: >> > > Nigel Cunningham <[EMAIL PROTECTED]> writes: > [--snip--] >> > > >> > > No one has yet attacked the hard problem of coming up with separate >> > > hibernate methods for drivers. >> > >> > Well, I've been playing a bit with that for some time, but it's not easy by > any >> > means. >> > >> > In short, I'm seeing some problems related to the handling of ACPI that >> > seem > to >> > shatter the entire idea of having separate hibernate methods, at least as > far >> > as ACPI systems are concerned. >> >> So sadly to hear this. Can you details it a little? Or a link? > Well, the problem is that apparently some systems (eg. my HP nx6325) expect us > to execute the _PTS ACPI global control method before creating the image _and_ > to execute acpi_enter_sleep_state(ACPI_STATE_S4) in order to finally put the > system into the sleep state. In particular, on nx6325, if we don't do that, > then after the restore the status of the AC power will not be reported > correctly (and if you replace the battery while in the sleep state, the > battery status will not be updated correctly after the restore). Similar > issues have been reported for other machines. Suppose that instead of using ACPI S4 state at all, you instead just power off. Yes, you'll lose wakeup event functionality, and flashy LEDs, but doesn't this take care of the problem? The firmware shouldn't see the hibernate as anything other than a shutdown and reboot. ACPI should be initialized normally when resuming, which should take care of getting AC power status reported properly. This should be the behavior, anyway, on the many systems that do not support S4. > Now, the ACPI specification requires us to put devices into low power states > before executing _PTS and that's exactly what we're doing before a suspend to > RAM. Thus, it seems that in general we need to do the same for hibernation on > ACPI systems. It seems that if ACPI S4 is going to be used, Switching to low power state is something that should be done only immediately before entering that state (i.e. after the image has already been saved). In particular, it should not be done just before the atomic copy. It is true that (during resume) after the atomic copy snapshot is restored, drivers will need to be prepared (i.e. have saved whatever information is necessary) to _resume_ devices from the low power state, but that does not mean they have to actually be put into that low power state before the copy is made. I agree that for the kexec implementation there may be additional issues. For swsusp, uswsusp, and tuxonice, though, I don't see why there should be a problem. I think that, as was recognized before, all of the issues are resolved by properly considering exactly what each callback should do and when it should be called. The problems stem from ambiguous specifications, or trying to use the same callback for two different purposes or in two different cases. Let me know if I'm mistaken. -- Jeremy Maitin-Shepard - 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
On Friday, 21 September 2007 20:11, Jeremy Maitin-Shepard wrote: > "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > > > On Friday, 21 September 2007 15:14, huang ying wrote: > >> On 9/21/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > >> > On Friday, 21 September 2007 05:33, Eric W. Biederman wrote: > >> > > Nigel Cunningham <[EMAIL PROTECTED]> writes: > > [--snip--] > >> > > > >> > > No one has yet attacked the hard problem of coming up with separate > >> > > hibernate methods for drivers. > >> > > >> > Well, I've been playing a bit with that for some time, but it's not easy > >> > by > > any > >> > means. > >> > > >> > In short, I'm seeing some problems related to the handling of ACPI that > >> > seem > > to > >> > shatter the entire idea of having separate hibernate methods, at least as > > far > >> > as ACPI systems are concerned. > >> > >> So sadly to hear this. Can you details it a little? Or a link? > > > Well, the problem is that apparently some systems (eg. my HP nx6325) expect > > us > > to execute the _PTS ACPI global control method before creating the image > > _and_ > > to execute acpi_enter_sleep_state(ACPI_STATE_S4) in order to finally put the > > system into the sleep state. In particular, on nx6325, if we don't do that, > > then after the restore the status of the AC power will not be reported > > correctly (and if you replace the battery while in the sleep state, the > > battery status will not be updated correctly after the restore). Similar > > issues have been reported for other machines. > > Suppose that instead of using ACPI S4 state at all, you instead just > power off. Yes, you'll lose wakeup event functionality, and flashy > LEDs, but doesn't this take care of the problem? Nope. > The firmware shouldn't see the hibernate as anything other than a shutdown > and reboot. Actually, this assumption is apparently wrong. > ACPI should be initialized normally when resuming, which should take care of > getting AC power status reported properly. Well, that doesn't work. I've tested it, really. :-) > This should be the behavior, anyway, on the many systems that do not > support S4. > > > Now, the ACPI specification requires us to put devices into low power states > > before executing _PTS and that's exactly what we're doing before a suspend > > to > > RAM. Thus, it seems that in general we need to do the same for hibernation > > on > > ACPI systems. > > It seems that if ACPI S4 is going to be used, Switching to low power > state is something that should be done only immediately before entering > that state (i.e. after the image has already been saved). Doesn't. Work. > In particular, it should not be done just before the atomic copy. It is > true that (during resume) after the atomic copy snapshot is restored, > drivers will need to be prepared (i.e. have saved whatever information > is necessary) to _resume_ devices from the low power state, but that > does not mean they have to actually be put into that low power state > before the copy is made. > > I agree that for the kexec implementation there may be additional > issues. For swsusp, uswsusp, and tuxonice, though, I don't see why > there should be a problem. I think that, as was recognized before, all > of the issues are resolved by properly considering exactly what each > callback should do and when it should be called. The problems stem from > ambiguous specifications, or trying to use the same callback for two > different purposes or in two different cases. > > Let me know if I'm mistaken. See above. :-) Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Friday, 21 September 2007 17:02, huang ying wrote: > On 9/21/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > On Friday, 21 September 2007 15:14, huang ying wrote: > > > On 9/21/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > > > On Friday, 21 September 2007 05:33, Eric W. Biederman wrote: > > > > > Nigel Cunningham <[EMAIL PROTECTED]> writes: > > [--snip--] > > > > > > > > > > No one has yet attacked the hard problem of coming up with separate > > > > > hibernate methods for drivers. > > > > > > > > Well, I've been playing a bit with that for some time, but it's not > > > > easy by any > > > > means. > > > > > > > > In short, I'm seeing some problems related to the handling of ACPI that > > > > seem to > > > > shatter the entire idea of having separate hibernate methods, at least > > > > as far > > > > as ACPI systems are concerned. > > > > > > So sadly to hear this. Can you details it a little? Or a link? > > > > Well, the problem is that apparently some systems (eg. my HP nx6325) expect > > us > > to execute the _PTS ACPI global control method before creating the image > > _and_ > > to execute acpi_enter_sleep_state(ACPI_STATE_S4) in order to finally put the > > system into the sleep state. In particular, on nx6325, if we don't do that, > > then after the restore the status of the AC power will not be reported > > correctly (and if you replace the battery while in the sleep state, the > > battery status will not be updated correctly after the restore). Similar > > issues have been reported for other machines. > > > > Now, the ACPI specification requires us to put devices into low power states > > before executing _PTS and that's exactly what we're doing before a suspend > > to > > RAM. Thus, it seems that in general we need to do the same for hibernation > > on > > ACPI systems. > > Then, is it possible to separate device quiesce from device suspend. It surely is possible, but I'm not sure if it's going to be useful. I mean, if we need to do exactly the same thing before a suspend to RAM and before a hibernation (ie. to put devices into low power states), why would we want to use different methods for that in both cases? > Perhaps not for swsusp, but for kexec based hibernation? Frankly, I don't know. Generally, changing the way in which device drivers handle suspend (to RAM) and hibernation is a huge task. After considering this issue for some time I think that we really should start from hardening suspend (to RAM) so that it doesn't need the freezer any more, because _that_ would require us to change the suspend-related drivers' callbacks anyway. When we are sure how we are going to eliminate the freezer from suspend (to RAM), we'll know how that affects hibernation and what to do about it. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On 9/21/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > On Friday, 21 September 2007 15:14, huang ying wrote: > > On 9/21/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > > On Friday, 21 September 2007 05:33, Eric W. Biederman wrote: > > > > Nigel Cunningham <[EMAIL PROTECTED]> writes: > [--snip--] > > > > > > > > No one has yet attacked the hard problem of coming up with separate > > > > hibernate methods for drivers. > > > > > > Well, I've been playing a bit with that for some time, but it's not easy > > > by any > > > means. > > > > > > In short, I'm seeing some problems related to the handling of ACPI that > > > seem to > > > shatter the entire idea of having separate hibernate methods, at least as > > > far > > > as ACPI systems are concerned. > > > > So sadly to hear this. Can you details it a little? Or a link? > > Well, the problem is that apparently some systems (eg. my HP nx6325) expect us > to execute the _PTS ACPI global control method before creating the image _and_ > to execute acpi_enter_sleep_state(ACPI_STATE_S4) in order to finally put the > system into the sleep state. In particular, on nx6325, if we don't do that, > then after the restore the status of the AC power will not be reported > correctly (and if you replace the battery while in the sleep state, the > battery status will not be updated correctly after the restore). Similar > issues have been reported for other machines. > > Now, the ACPI specification requires us to put devices into low power states > before executing _PTS and that's exactly what we're doing before a suspend to > RAM. Thus, it seems that in general we need to do the same for hibernation on > ACPI systems. Then, is it possible to separate device quiesce from device suspend. Perhaps not for swsusp, but for kexec based hibernation? Best Regards, Huang Ying - 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
On Friday, 21 September 2007 15:14, huang ying wrote: > On 9/21/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > On Friday, 21 September 2007 05:33, Eric W. Biederman wrote: > > > Nigel Cunningham <[EMAIL PROTECTED]> writes: [--snip--] > > > > > > No one has yet attacked the hard problem of coming up with separate > > > hibernate methods for drivers. > > > > Well, I've been playing a bit with that for some time, but it's not easy by > > any > > means. > > > > In short, I'm seeing some problems related to the handling of ACPI that > > seem to > > shatter the entire idea of having separate hibernate methods, at least as > > far > > as ACPI systems are concerned. > > So sadly to hear this. Can you details it a little? Or a link? Well, the problem is that apparently some systems (eg. my HP nx6325) expect us to execute the _PTS ACPI global control method before creating the image _and_ to execute acpi_enter_sleep_state(ACPI_STATE_S4) in order to finally put the system into the sleep state. In particular, on nx6325, if we don't do that, then after the restore the status of the AC power will not be reported correctly (and if you replace the battery while in the sleep state, the battery status will not be updated correctly after the restore). Similar issues have been reported for other machines. Now, the ACPI specification requires us to put devices into low power states before executing _PTS and that's exactly what we're doing before a suspend to RAM. Thus, it seems that in general we need to do the same for hibernation on ACPI systems. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On 9/21/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > On Friday, 21 September 2007 05:33, Eric W. Biederman wrote: > > Nigel Cunningham <[EMAIL PROTECTED]> writes: > > > > > > That's not true. Kexec will itself be an implementation, otherwise you'd > > > end > > > up with people screaming about no hibernation support. > > > > There needs to be an implementation of hibernation based on kexec with > > return yes. > > > > > And it won't result in > > > the complete removal of the existing hibernation code from the kernel. At > > > the > > > very least, it's going to want the kernel being hibernated to have an > > > interface by which it can find out which pages need to be saved. > > > > That interface should be running kernel -> user space -> target kernel. > > Not direct kernel to kernel. > > > > > I wouldn't > > > be surprised if it also ends up with an interface in which the kernel > > > being > > > hibernated tells it what bdev/sectors in which to save the image as well > > > (otherwise you're going to need a dedicated, otherwise untouched partition > > > exclusively for the kexec'd kernel to use), or what network settings to > > > use > > > if it wants to try to save the image to a network storage device. > > > > initramfs. We already seem to have that interface. And distros > > seems to do a pretty decent job of using it to configure systems. > > > > > On top of > > > that, there are all the issues related to device reinitialisation and so > > > on, > > > > Yes. > > > > > and it looks like there's greatly increased pain for users wanting to > > > configure this new implementation. > > > > Not to be callous but that really is a user space and distro issue. > > > > > Kexec is by no means proven to be the panacea for all the issues. > > > > I agree. I'm still not quite convinced it will do a satisfactory job. > > But I think it does make sense to implement a general kexec with > > return and see if that can reasonably be used for handling hibernation > > issues. If done cleanly and with care the implementation won't be > > hibernation specific. > > Yes, and that's worth doing anyway, IMO. > > > Frankly this looks like the best way I can see to implement a general > > mechanism for calling silly firmware/BIOS/EFI services after we > > have a kernel up and running. It's a little bit like allowing > > X to call iopl(3) and do inb/outb directly. > > > > The configuration issues you raise pretty much exist for kexec on > > panic, and they seem to be being resolved for that case in a > > reasonable way. I do agree that the current kexec+return effort seems > > to be one of those unfortunate cases where we give every mechanism in > > the kernel to do something in user space and then no one actually > > implements the user space. That doesn't do any one any good. > > > > For hibernation we don't have the absolute need to step outside of the > > current kernel that we do in the kexec on panic approach. However we > > have this practical fight about mechanism and policy, and kexec with > > return has this seductive allure that it appears to be the minimal > > necessary mechanism in the kernel. > > > > No one has yet attacked the hard problem of coming up with separate > > hibernate methods for drivers. > > Well, I've been playing a bit with that for some time, but it's not easy by > any > means. > > In short, I'm seeing some problems related to the handling of ACPI that seem > to > shatter the entire idea of having separate hibernate methods, at least as far > as ACPI systems are concerned. So sadly to hear this. Can you details it a little? Or a link? Best Regards, Huang Ying - 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
On Friday, 21 September 2007 11:49, Pavel Machek wrote: > Hi! > > > > Seems like good enough for -mm to me. > > (For the record, I do not think this is going to be > hibernation-replacement any time soon. But it is functionality useful > for other stuff -- dump memory and continue -- and yes it may be able > to do hibernation in the long term. > > It really comes from the other side of reliability: > > * swsusp is "if your kernel is perfectly healthy, it will work" > > while this, coming from kdump is > > * "if your kernel is not completely trashed, it should work" > > ...which is why can't use swsusp to do dump memory and continue -- you > want to do dumps on "slightly broken" systems. And yes, as a > sideeffect it may be able to do hibernation... why not, lets see how > it works out). I generally agree. :-) Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Friday, 21 September 2007 05:33, Eric W. Biederman wrote: > Nigel Cunningham <[EMAIL PROTECTED]> writes: > > > > That's not true. Kexec will itself be an implementation, otherwise you'd > > end > > up with people screaming about no hibernation support. > > There needs to be an implementation of hibernation based on kexec with > return yes. > > > And it won't result in > > the complete removal of the existing hibernation code from the kernel. At > > the > > very least, it's going to want the kernel being hibernated to have an > > interface by which it can find out which pages need to be saved. > > That interface should be running kernel -> user space -> target kernel. > Not direct kernel to kernel. > > > I wouldn't > > be surprised if it also ends up with an interface in which the kernel being > > hibernated tells it what bdev/sectors in which to save the image as well > > (otherwise you're going to need a dedicated, otherwise untouched partition > > exclusively for the kexec'd kernel to use), or what network settings to use > > if it wants to try to save the image to a network storage device. > > initramfs. We already seem to have that interface. And distros > seems to do a pretty decent job of using it to configure systems. > > > On top of > > that, there are all the issues related to device reinitialisation and so > > on, > > Yes. > > > and it looks like there's greatly increased pain for users wanting to > > configure this new implementation. > > Not to be callous but that really is a user space and distro issue. > > > Kexec is by no means proven to be the panacea for all the issues. > > I agree. I'm still not quite convinced it will do a satisfactory job. > But I think it does make sense to implement a general kexec with > return and see if that can reasonably be used for handling hibernation > issues. If done cleanly and with care the implementation won't be > hibernation specific. Yes, and that's worth doing anyway, IMO. > Frankly this looks like the best way I can see to implement a general > mechanism for calling silly firmware/BIOS/EFI services after we > have a kernel up and running. It's a little bit like allowing > X to call iopl(3) and do inb/outb directly. > > The configuration issues you raise pretty much exist for kexec on > panic, and they seem to be being resolved for that case in a > reasonable way. I do agree that the current kexec+return effort seems > to be one of those unfortunate cases where we give every mechanism in > the kernel to do something in user space and then no one actually > implements the user space. That doesn't do any one any good. > > For hibernation we don't have the absolute need to step outside of the > current kernel that we do in the kexec on panic approach. However we > have this practical fight about mechanism and policy, and kexec with > return has this seductive allure that it appears to be the minimal > necessary mechanism in the kernel. > > No one has yet attacked the hard problem of coming up with separate > hibernate methods for drivers. Well, I've been playing a bit with that for some time, but it's not easy by any means. In short, I'm seeing some problems related to the handling of ACPI that seem to shatter the entire idea of having separate hibernate methods, at least as far as ACPI systems are concerned. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Friday, 21 September 2007 05:33, Eric W. Biederman wrote: Nigel Cunningham [EMAIL PROTECTED] writes: That's not true. Kexec will itself be an implementation, otherwise you'd end up with people screaming about no hibernation support. There needs to be an implementation of hibernation based on kexec with return yes. And it won't result in the complete removal of the existing hibernation code from the kernel. At the very least, it's going to want the kernel being hibernated to have an interface by which it can find out which pages need to be saved. That interface should be running kernel - user space - target kernel. Not direct kernel to kernel. I wouldn't be surprised if it also ends up with an interface in which the kernel being hibernated tells it what bdev/sectors in which to save the image as well (otherwise you're going to need a dedicated, otherwise untouched partition exclusively for the kexec'd kernel to use), or what network settings to use if it wants to try to save the image to a network storage device. initramfs. We already seem to have that interface. And distros seems to do a pretty decent job of using it to configure systems. On top of that, there are all the issues related to device reinitialisation and so on, Yes. and it looks like there's greatly increased pain for users wanting to configure this new implementation. Not to be callous but that really is a user space and distro issue. Kexec is by no means proven to be the panacea for all the issues. I agree. I'm still not quite convinced it will do a satisfactory job. But I think it does make sense to implement a general kexec with return and see if that can reasonably be used for handling hibernation issues. If done cleanly and with care the implementation won't be hibernation specific. Yes, and that's worth doing anyway, IMO. Frankly this looks like the best way I can see to implement a general mechanism for calling silly firmware/BIOS/EFI services after we have a kernel up and running. It's a little bit like allowing X to call iopl(3) and do inb/outb directly. The configuration issues you raise pretty much exist for kexec on panic, and they seem to be being resolved for that case in a reasonable way. I do agree that the current kexec+return effort seems to be one of those unfortunate cases where we give every mechanism in the kernel to do something in user space and then no one actually implements the user space. That doesn't do any one any good. For hibernation we don't have the absolute need to step outside of the current kernel that we do in the kexec on panic approach. However we have this practical fight about mechanism and policy, and kexec with return has this seductive allure that it appears to be the minimal necessary mechanism in the kernel. No one has yet attacked the hard problem of coming up with separate hibernate methods for drivers. Well, I've been playing a bit with that for some time, but it's not easy by any means. In short, I'm seeing some problems related to the handling of ACPI that seem to shatter the entire idea of having separate hibernate methods, at least as far as ACPI systems are concerned. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Friday, 21 September 2007 11:49, Pavel Machek wrote: Hi! Seems like good enough for -mm to me. (For the record, I do not think this is going to be hibernation-replacement any time soon. But it is functionality useful for other stuff -- dump memory and continue -- and yes it may be able to do hibernation in the long term. It really comes from the other side of reliability: * swsusp is if your kernel is perfectly healthy, it will work while this, coming from kdump is * if your kernel is not completely trashed, it should work ...which is why can't use swsusp to do dump memory and continue -- you want to do dumps on slightly broken systems. And yes, as a sideeffect it may be able to do hibernation... why not, lets see how it works out). I generally agree. :-) Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On 9/21/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Friday, 21 September 2007 05:33, Eric W. Biederman wrote: Nigel Cunningham [EMAIL PROTECTED] writes: That's not true. Kexec will itself be an implementation, otherwise you'd end up with people screaming about no hibernation support. There needs to be an implementation of hibernation based on kexec with return yes. And it won't result in the complete removal of the existing hibernation code from the kernel. At the very least, it's going to want the kernel being hibernated to have an interface by which it can find out which pages need to be saved. That interface should be running kernel - user space - target kernel. Not direct kernel to kernel. I wouldn't be surprised if it also ends up with an interface in which the kernel being hibernated tells it what bdev/sectors in which to save the image as well (otherwise you're going to need a dedicated, otherwise untouched partition exclusively for the kexec'd kernel to use), or what network settings to use if it wants to try to save the image to a network storage device. initramfs. We already seem to have that interface. And distros seems to do a pretty decent job of using it to configure systems. On top of that, there are all the issues related to device reinitialisation and so on, Yes. and it looks like there's greatly increased pain for users wanting to configure this new implementation. Not to be callous but that really is a user space and distro issue. Kexec is by no means proven to be the panacea for all the issues. I agree. I'm still not quite convinced it will do a satisfactory job. But I think it does make sense to implement a general kexec with return and see if that can reasonably be used for handling hibernation issues. If done cleanly and with care the implementation won't be hibernation specific. Yes, and that's worth doing anyway, IMO. Frankly this looks like the best way I can see to implement a general mechanism for calling silly firmware/BIOS/EFI services after we have a kernel up and running. It's a little bit like allowing X to call iopl(3) and do inb/outb directly. The configuration issues you raise pretty much exist for kexec on panic, and they seem to be being resolved for that case in a reasonable way. I do agree that the current kexec+return effort seems to be one of those unfortunate cases where we give every mechanism in the kernel to do something in user space and then no one actually implements the user space. That doesn't do any one any good. For hibernation we don't have the absolute need to step outside of the current kernel that we do in the kexec on panic approach. However we have this practical fight about mechanism and policy, and kexec with return has this seductive allure that it appears to be the minimal necessary mechanism in the kernel. No one has yet attacked the hard problem of coming up with separate hibernate methods for drivers. Well, I've been playing a bit with that for some time, but it's not easy by any means. In short, I'm seeing some problems related to the handling of ACPI that seem to shatter the entire idea of having separate hibernate methods, at least as far as ACPI systems are concerned. So sadly to hear this. Can you details it a little? Or a link? Best Regards, Huang Ying - 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
On Friday, 21 September 2007 15:14, huang ying wrote: On 9/21/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Friday, 21 September 2007 05:33, Eric W. Biederman wrote: Nigel Cunningham [EMAIL PROTECTED] writes: [--snip--] No one has yet attacked the hard problem of coming up with separate hibernate methods for drivers. Well, I've been playing a bit with that for some time, but it's not easy by any means. In short, I'm seeing some problems related to the handling of ACPI that seem to shatter the entire idea of having separate hibernate methods, at least as far as ACPI systems are concerned. So sadly to hear this. Can you details it a little? Or a link? Well, the problem is that apparently some systems (eg. my HP nx6325) expect us to execute the _PTS ACPI global control method before creating the image _and_ to execute acpi_enter_sleep_state(ACPI_STATE_S4) in order to finally put the system into the sleep state. In particular, on nx6325, if we don't do that, then after the restore the status of the AC power will not be reported correctly (and if you replace the battery while in the sleep state, the battery status will not be updated correctly after the restore). Similar issues have been reported for other machines. Now, the ACPI specification requires us to put devices into low power states before executing _PTS and that's exactly what we're doing before a suspend to RAM. Thus, it seems that in general we need to do the same for hibernation on ACPI systems. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On 9/21/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Friday, 21 September 2007 15:14, huang ying wrote: On 9/21/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Friday, 21 September 2007 05:33, Eric W. Biederman wrote: Nigel Cunningham [EMAIL PROTECTED] writes: [--snip--] No one has yet attacked the hard problem of coming up with separate hibernate methods for drivers. Well, I've been playing a bit with that for some time, but it's not easy by any means. In short, I'm seeing some problems related to the handling of ACPI that seem to shatter the entire idea of having separate hibernate methods, at least as far as ACPI systems are concerned. So sadly to hear this. Can you details it a little? Or a link? Well, the problem is that apparently some systems (eg. my HP nx6325) expect us to execute the _PTS ACPI global control method before creating the image _and_ to execute acpi_enter_sleep_state(ACPI_STATE_S4) in order to finally put the system into the sleep state. In particular, on nx6325, if we don't do that, then after the restore the status of the AC power will not be reported correctly (and if you replace the battery while in the sleep state, the battery status will not be updated correctly after the restore). Similar issues have been reported for other machines. Now, the ACPI specification requires us to put devices into low power states before executing _PTS and that's exactly what we're doing before a suspend to RAM. Thus, it seems that in general we need to do the same for hibernation on ACPI systems. Then, is it possible to separate device quiesce from device suspend. Perhaps not for swsusp, but for kexec based hibernation? Best Regards, Huang Ying - 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
On Friday, 21 September 2007 17:02, huang ying wrote: On 9/21/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Friday, 21 September 2007 15:14, huang ying wrote: On 9/21/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Friday, 21 September 2007 05:33, Eric W. Biederman wrote: Nigel Cunningham [EMAIL PROTECTED] writes: [--snip--] No one has yet attacked the hard problem of coming up with separate hibernate methods for drivers. Well, I've been playing a bit with that for some time, but it's not easy by any means. In short, I'm seeing some problems related to the handling of ACPI that seem to shatter the entire idea of having separate hibernate methods, at least as far as ACPI systems are concerned. So sadly to hear this. Can you details it a little? Or a link? Well, the problem is that apparently some systems (eg. my HP nx6325) expect us to execute the _PTS ACPI global control method before creating the image _and_ to execute acpi_enter_sleep_state(ACPI_STATE_S4) in order to finally put the system into the sleep state. In particular, on nx6325, if we don't do that, then after the restore the status of the AC power will not be reported correctly (and if you replace the battery while in the sleep state, the battery status will not be updated correctly after the restore). Similar issues have been reported for other machines. Now, the ACPI specification requires us to put devices into low power states before executing _PTS and that's exactly what we're doing before a suspend to RAM. Thus, it seems that in general we need to do the same for hibernation on ACPI systems. Then, is it possible to separate device quiesce from device suspend. It surely is possible, but I'm not sure if it's going to be useful. I mean, if we need to do exactly the same thing before a suspend to RAM and before a hibernation (ie. to put devices into low power states), why would we want to use different methods for that in both cases? Perhaps not for swsusp, but for kexec based hibernation? Frankly, I don't know. Generally, changing the way in which device drivers handle suspend (to RAM) and hibernation is a huge task. After considering this issue for some time I think that we really should start from hardening suspend (to RAM) so that it doesn't need the freezer any more, because _that_ would require us to change the suspend-related drivers' callbacks anyway. When we are sure how we are going to eliminate the freezer from suspend (to RAM), we'll know how that affects hibernation and what to do about it. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Rafael J. Wysocki [EMAIL PROTECTED] writes: On Friday, 21 September 2007 15:14, huang ying wrote: On 9/21/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Friday, 21 September 2007 05:33, Eric W. Biederman wrote: Nigel Cunningham [EMAIL PROTECTED] writes: [--snip--] No one has yet attacked the hard problem of coming up with separate hibernate methods for drivers. Well, I've been playing a bit with that for some time, but it's not easy by any means. In short, I'm seeing some problems related to the handling of ACPI that seem to shatter the entire idea of having separate hibernate methods, at least as far as ACPI systems are concerned. So sadly to hear this. Can you details it a little? Or a link? Well, the problem is that apparently some systems (eg. my HP nx6325) expect us to execute the _PTS ACPI global control method before creating the image _and_ to execute acpi_enter_sleep_state(ACPI_STATE_S4) in order to finally put the system into the sleep state. In particular, on nx6325, if we don't do that, then after the restore the status of the AC power will not be reported correctly (and if you replace the battery while in the sleep state, the battery status will not be updated correctly after the restore). Similar issues have been reported for other machines. Suppose that instead of using ACPI S4 state at all, you instead just power off. Yes, you'll lose wakeup event functionality, and flashy LEDs, but doesn't this take care of the problem? The firmware shouldn't see the hibernate as anything other than a shutdown and reboot. ACPI should be initialized normally when resuming, which should take care of getting AC power status reported properly. This should be the behavior, anyway, on the many systems that do not support S4. Now, the ACPI specification requires us to put devices into low power states before executing _PTS and that's exactly what we're doing before a suspend to RAM. Thus, it seems that in general we need to do the same for hibernation on ACPI systems. It seems that if ACPI S4 is going to be used, Switching to low power state is something that should be done only immediately before entering that state (i.e. after the image has already been saved). In particular, it should not be done just before the atomic copy. It is true that (during resume) after the atomic copy snapshot is restored, drivers will need to be prepared (i.e. have saved whatever information is necessary) to _resume_ devices from the low power state, but that does not mean they have to actually be put into that low power state before the copy is made. I agree that for the kexec implementation there may be additional issues. For swsusp, uswsusp, and tuxonice, though, I don't see why there should be a problem. I think that, as was recognized before, all of the issues are resolved by properly considering exactly what each callback should do and when it should be called. The problems stem from ambiguous specifications, or trying to use the same callback for two different purposes or in two different cases. Let me know if I'm mistaken. -- Jeremy Maitin-Shepard - 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
On Friday, 21 September 2007 20:11, Jeremy Maitin-Shepard wrote: Rafael J. Wysocki [EMAIL PROTECTED] writes: On Friday, 21 September 2007 15:14, huang ying wrote: On 9/21/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Friday, 21 September 2007 05:33, Eric W. Biederman wrote: Nigel Cunningham [EMAIL PROTECTED] writes: [--snip--] No one has yet attacked the hard problem of coming up with separate hibernate methods for drivers. Well, I've been playing a bit with that for some time, but it's not easy by any means. In short, I'm seeing some problems related to the handling of ACPI that seem to shatter the entire idea of having separate hibernate methods, at least as far as ACPI systems are concerned. So sadly to hear this. Can you details it a little? Or a link? Well, the problem is that apparently some systems (eg. my HP nx6325) expect us to execute the _PTS ACPI global control method before creating the image _and_ to execute acpi_enter_sleep_state(ACPI_STATE_S4) in order to finally put the system into the sleep state. In particular, on nx6325, if we don't do that, then after the restore the status of the AC power will not be reported correctly (and if you replace the battery while in the sleep state, the battery status will not be updated correctly after the restore). Similar issues have been reported for other machines. Suppose that instead of using ACPI S4 state at all, you instead just power off. Yes, you'll lose wakeup event functionality, and flashy LEDs, but doesn't this take care of the problem? Nope. The firmware shouldn't see the hibernate as anything other than a shutdown and reboot. Actually, this assumption is apparently wrong. ACPI should be initialized normally when resuming, which should take care of getting AC power status reported properly. Well, that doesn't work. I've tested it, really. :-) This should be the behavior, anyway, on the many systems that do not support S4. Now, the ACPI specification requires us to put devices into low power states before executing _PTS and that's exactly what we're doing before a suspend to RAM. Thus, it seems that in general we need to do the same for hibernation on ACPI systems. It seems that if ACPI S4 is going to be used, Switching to low power state is something that should be done only immediately before entering that state (i.e. after the image has already been saved). Doesn't. Work. In particular, it should not be done just before the atomic copy. It is true that (during resume) after the atomic copy snapshot is restored, drivers will need to be prepared (i.e. have saved whatever information is necessary) to _resume_ devices from the low power state, but that does not mean they have to actually be put into that low power state before the copy is made. I agree that for the kexec implementation there may be additional issues. For swsusp, uswsusp, and tuxonice, though, I don't see why there should be a problem. I think that, as was recognized before, all of the issues are resolved by properly considering exactly what each callback should do and when it should be called. The problems stem from ambiguous specifications, or trying to use the same callback for two different purposes or in two different cases. Let me know if I'm mistaken. See above. :-) Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Fri, 21 Sep 2007, Rafael J. Wysocki wrote: Well, the problem is that apparently some systems (eg. my HP nx6325) expect us to execute the _PTS ACPI global control method before creating the image _and_ to execute acpi_enter_sleep_state(ACPI_STATE_S4) in order to finally put the system into the sleep state. In particular, on nx6325, if we don't do that, then after the restore the status of the AC power will not be reported correctly (and if you replace the battery while in the sleep state, the battery status will not be updated correctly after the restore). Similar issues have been reported for other machines. Suppose that instead of using ACPI S4 state at all, you instead just power off. Yes, you'll lose wakeup event functionality, and flashy LEDs, but doesn't this take care of the problem? Nope. The firmware shouldn't see the hibernate as anything other than a shutdown and reboot. Actually, this assumption is apparently wrong. One gets the impression that the hibernation image includes a memory area used by the firmware. That could explain why devices need to be in a low-power state when the image is created -- so that when the image is restored, the firmware doesn't get confused about the device states. It would also explain why the firmware sees resume-from-power-off-hibernation as different from a regular reboot: because its data area gets overwritten as part of the resume. In reality it's probably more complicated than this, with weird interactions between the firmware and the various ACPI methods. Nevertheless, the main idea seems valid. Alan Stern - 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
On Friday, 21 September 2007 21:45, Alan Stern wrote: On Fri, 21 Sep 2007, Rafael J. Wysocki wrote: Well, the problem is that apparently some systems (eg. my HP nx6325) expect us to execute the _PTS ACPI global control method before creating the image _and_ to execute acpi_enter_sleep_state(ACPI_STATE_S4) in order to finally put the system into the sleep state. In particular, on nx6325, if we don't do that, then after the restore the status of the AC power will not be reported correctly (and if you replace the battery while in the sleep state, the battery status will not be updated correctly after the restore). Similar issues have been reported for other machines. Suppose that instead of using ACPI S4 state at all, you instead just power off. Yes, you'll lose wakeup event functionality, and flashy LEDs, but doesn't this take care of the problem? Nope. The firmware shouldn't see the hibernate as anything other than a shutdown and reboot. Actually, this assumption is apparently wrong. One gets the impression that the hibernation image includes a memory area used by the firmware. That could explain why devices need to be in a low-power state when the image is created -- so that when the image is restored, the firmware doesn't get confused about the device states. It would also explain why the firmware sees resume-from-power-off-hibernation as different from a regular reboot: because its data area gets overwritten as part of the resume. In reality it's probably more complicated than this, with weird interactions between the firmware and the various ACPI methods. Nevertheless, the main idea seems valid. I guess so, but I'm not sure. The ACPI NVS area is explicitly marked as reserved and we don't save it. On x86_64 we don't save any memory areas marked as reserved and yet the above happens. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Rafael J. Wysocki [EMAIL PROTECTED] writes: [snip] The ACPI NVS area is explicitly marked as reserved and we don't save it. On x86_64 we don't save any memory areas marked as reserved and yet the above happens. I think you have mentioned before, though, that ACPI is first initialized by the boot kernel, before it is later initialized by resuming kernel. This could well be the source of the problem. In particular, isn't it the case that you also switch the devices to low power mode before resuming? -- Jeremy Maitin-Shepard - 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
On Friday, 21 September 2007 22:26, Jeremy Maitin-Shepard wrote: Rafael J. Wysocki [EMAIL PROTECTED] writes: [snip] The ACPI NVS area is explicitly marked as reserved and we don't save it. On x86_64 we don't save any memory areas marked as reserved and yet the above happens. I think you have mentioned before, though, that ACPI is first initialized by the boot kernel, before it is later initialized by resuming kernel. This could well be the source of the problem. No, it's not. I have tested that too with an ACPI-less boot kernel. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Rafael J. Wysocki [EMAIL PROTECTED] writes: On Friday, 21 September 2007 22:26, Jeremy Maitin-Shepard wrote: Rafael J. Wysocki [EMAIL PROTECTED] writes: [snip] The ACPI NVS area is explicitly marked as reserved and we don't save it. On x86_64 we don't save any memory areas marked as reserved and yet the above happens. I think you have mentioned before, though, that ACPI is first initialized by the boot kernel, before it is later initialized by resuming kernel. This could well be the source of the problem. No, it's not. I have tested that too with an ACPI-less boot kernel. Well, it seems that there just must be some other bug. I would define anything that differs between the post-resume initialization of ACPI from the normal boot initialization of ACPI as a bug. If the interaction with the hardware is the same, then the behavior will be the same. -- Jeremy Maitin-Shepard - 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
On Friday, 21 September 2007 23:08, Jeremy Maitin-Shepard wrote: Rafael J. Wysocki [EMAIL PROTECTED] writes: On Friday, 21 September 2007 22:26, Jeremy Maitin-Shepard wrote: Rafael J. Wysocki [EMAIL PROTECTED] writes: [snip] The ACPI NVS area is explicitly marked as reserved and we don't save it. On x86_64 we don't save any memory areas marked as reserved and yet the above happens. I think you have mentioned before, though, that ACPI is first initialized by the boot kernel, before it is later initialized by resuming kernel. This could well be the source of the problem. No, it's not. I have tested that too with an ACPI-less boot kernel. Well, it seems that there just must be some other bug. I would define anything that differs between the post-resume initialization of ACPI I'm not sure what you mean. from the normal boot initialization of ACPI as a bug. If the interaction with the hardware is the same, then the behavior will be the same. The ACPI platform firmware is allowed to preserve information accross the hibernation-resume cycle, so this need not be the same. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Rafael J. Wysocki [EMAIL PROTECTED] writes: On Friday, 21 September 2007 23:08, Jeremy Maitin-Shepard wrote: Rafael J. Wysocki [EMAIL PROTECTED] writes: On Friday, 21 September 2007 22:26, Jeremy Maitin-Shepard wrote: Rafael J. Wysocki [EMAIL PROTECTED] writes: [snip] The ACPI NVS area is explicitly marked as reserved and we don't save it. On x86_64 we don't save any memory areas marked as reserved and yet the above happens. I think you have mentioned before, though, that ACPI is first initialized by the boot kernel, before it is later initialized by resuming kernel. This could well be the source of the problem. No, it's not. I have tested that too with an ACPI-less boot kernel. Well, it seems that there just must be some other bug. I would define anything that differs between the post-resume initialization of ACPI I'm not sure what you mean. from the normal boot initialization of ACPI as a bug. If the interaction with the hardware is the same, then the behavior will be the same. The ACPI platform firmware is allowed to preserve information accross the hibernation-resume cycle, so this need not be the same. All of my comments related to the case where S4 is not being used (instead the system is just powered off normally), and a boot kernel that does not initialize ACPI is used. In that case, the ACPI platform firmware should not be able to distinguish a normal boot from a resume from hibernation. -- Jeremy Maitin-Shepard - 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
On Sep 21, 2007, at 17:16:59, Jeremy Maitin-Shepard wrote: Rafael J. Wysocki [EMAIL PROTECTED] writes: The ACPI platform firmware is allowed to preserve information accross the hibernation-resume cycle, so this need not be the same. All of my comments related to the case where S4 is not being used (instead the system is just powered off normally), and a boot kernel that does not initialize ACPI is used. In that case, the ACPI platform firmware should not be able to distinguish a normal boot from a resume from hibernation. 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. 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 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. Cheers, Kyle Moffett - 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/
