.
There are several memory areas used by kernel bootstrap before e820 map
is consulted. You can refer to bad_addr for details. So I think it may
be not a stable/simple prototype to provide this information to
bootloader.
Best Regards,
Huang Ying
-
To unsubscribe from this list: send the line unsubscribe
On 10/20/07, Phillip Susi [EMAIL PROTECTED] wrote:
Huang, Ying wrote:
The hibernation procedure with the patch set is as follow:
1. Boot a kernel A
2. Work under kernel A
3. Kexec another kernel B (crash dump enabled) in kernel A.
4. Save the memory image of kernel A through
This patch defines a 32-bit boot protocol and adds corresponding
document. It is based on the proposal of Peter Anvin.
Signed-off-by: Huang Ying [EMAIL PROTECTED]
---
boot.txt | 68 ++
zero-page.txt | 129
according to the source code and move
them to zero-page.txt.
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
This patch add a field of 64-bit physical pointer to NULL terminated
single linked list of struct setup_data to real-mode kernel
header. This is used as a more extensible boot parameters passing
mechanism.
Signed-off-by: Huang Ying [EMAIL PROTECTED]
---
arch/x86/boot/header.S |8
This patch export the boot parameters via sysfs. This can be used for
debugging and kexec.
Signed-off-by: Huang Ying [EMAIL PROTECTED]
---
Makefile_32 |1
Makefile_64 |1
ksysfs.c| 236
setup64.c |2
setup_32.c
rewrite this myself, but it may be quicker for
you to update it.
OK, I will update it as soon as possible.
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
the boot protocol version number
- Check version number before parsing setup data.
- Revise zero page description according to the source code and move
them to zero-page.txt.
Best Regards,
Huang Ying
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
This patch add a field of 64-bit physical pointer to NULL terminated
single linked list of struct setup_data to real-mode kernel
header. This is used as a more extensible boot parameters passing
mechanism.
Signed-off-by: Huang Ying [EMAIL PROTECTED]
---
arch/x86/boot/header.S |6
This patch defines a 32-bit boot protocol and adds corresponding
document. It is based on the proposal of Peter Anvin.
Signed-off-by: Huang Ying [EMAIL PROTECTED]
---
boot.txt | 76 +
zero-page.txt | 130
This patch export the boot parameters via sysfs. This can be used for
debugging and kexec.
Signed-off-by: Huang Ying [EMAIL PROTECTED]
---
Makefile_32 |1
Makefile_64 |1
ksysfs.c| 236
setup64.c |2
setup_32.c
On Tue, 2007-10-23 at 15:06 -0700, H. Peter Anvin wrote:
Huang, Ying wrote:
This patch set defines a 32-bit boot protocol for x86 platform, adds
an extensible boot parameter passing mechanism, export the boot
parameters via sysfs.
The patch set has been tested against kernel of git
This patch documents the 32-bit boot protocol of x86. It has been used
by Kexec and LinuxBIOS. This patch is based on the proposal of Peter
Anvin.
Signed-off-by: Huang Ying [EMAIL PROTECTED]
---
boot.txt | 38
zero-page.txt | 130
This patch documents the 32-bit boot protocol of x86. It has been used
by Kexec and LinuxBIOS. This patch is based on the proposal of Peter
Anvin.
Signed-off-by: Huang Ying [EMAIL PROTECTED]
v2:
- Fixes a bug about which registers should be set to zero.
---
boot.txt | 38
~796M memory area. So
some early reserve memory area can not be revered with bootmem allocator
later. Should we fix bootmem allocator firstly?
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
the video information as
appropriate for EFI firmware.
The framebuffer driver has been tested in i386 kernel and x86_64
kernel on EFI platform.
Signed-off-by: Chandramouli Narayanan [EMAIL PROTECTED]
Signed-off-by: Huang Ying [EMAIL PROTECTED]
---
drivers/video/Kconfig | 11 ++
drivers/video
This patch adds document for EFI x86_64 boot support. The setup and
operation guide of EFI based system is documented in
Documentation/x86_64/uefi.txt.
Signed-off-by: Chandramouli Narayanan [EMAIL PROTECTED]
Signed-off-by: Huang Ying [EMAIL PROTECTED]
---
uefi.txt | 29
/UEFI
firmware and the support of bootloader is required. Detailed usage
guide can be found in Documentation/x86_64/uefi.txt, which is added in
the patch: EFI boot document
v2:
- The include files of efifb.c is cleaned up.
- Make CONFIG_FB_EFI not depend on CONFIG_EFI.
Best Regards,
Huang Ying
the error message with elilo 3.8?
It should be noted somewhere that with Huangs patches, elilo version 3.8
is needed.
Yes. I will add this.
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
in early_mapping_set_exec(). This eliminates the
duplicated implementation.
This patch has been tested on Intel x86_64 platform with EFI64/32
firmware.
Signed-off-by: Huang Ying [EMAIL PROTECTED]
---
arch/x86/kernel/efi.c|6 ++
arch/x86/kernel/efi_64.c | 30
On Wed, 2008-02-13 at 12:32 +0100, Andi Kleen wrote:
Huang, Ying wrote:
This patch enhances EFI runtime code memory mapping as following:
- Move __supported_pte_mask _PAGE_NX checking before invoking
runtime_code_page_mkexec(). This makes it possible for compiler to
eliminate
setup_noefi(char *arg)
Reviewed-by: Huang Ying [EMAIL PROTECTED]
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
you don't need to worry about fixing up any aliases.
This is the original method. The issue is that it must be synced with
set_memory_*() and lookup_address() implementation. For example, it
lacked 1G support when that is added to lookup_address().
Best Regards,
Huang Ying
--
To unsubscribe from
Hi, Ingo,
Please revert this patch. Because it does not work with 1GB pages.
Although the original implementation does not work with 1GB pages too,
it can be fixed easier than this one. I will compose a new patch to fix
the original implementation.
Best Regards,
Huang Ying
On Wed, 2008-02-13
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/
? (this fix is also in the latest x86.git#mm)
I think the patch following may be better, because it is possible that
the EFI_PAGE_SHIFT and PAGE_SHIFT are different.
Best Regards,
Huang Ying
-
The EFI-runtime mapping code changed a larger memory area than it
should have, due
On Thu, 2008-02-14 at 21:44 -0800, Linus Torvalds wrote:
On Fri, 15 Feb 2008, Huang, Ying wrote:
I think the patch following may be better, because it is possible that
the EFI_PAGE_SHIFT and PAGE_SHIFT are different.
If this is a problem in practice, we'd be better off having a helper
On Fri, 2008-02-15 at 08:08 +0100, Ingo Molnar wrote:
* Huang, Ying [EMAIL PROTECTED] wrote:
On Thu, 2008-02-14 at 17:12 +0100, Ingo Molnar wrote:
this is indeed a bug (we change the attributes for a larger area than
needed), but your fix is unclean. Find below a cleaner solution
On Fri, 2008-02-15 at 09:48 +0100, Andi Kleen wrote:
On Fri, Feb 15, 2008 at 12:48:06PM +0800, Huang, Ying wrote:
This patch has been tested on Intel x86 platform with EFI 32/64.
Can EFI_PAGE_SIZE ever be 4k? If yes you would need to round up
first to linux page size before shifting
tested efi_ioremap with memmap=..., and it works fine on my 2G EFI
box.
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
) uses as well.
uuid_be complies RFC4122, it uses internet byte order. But EFI uses
little endian.
Best Regards,
Huang Ying
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
On Tue, 2012-10-30 at 00:48 -0400, Theodore Ts'o wrote:
On Tue, Oct 30, 2012 at 09:49:58AM +0800, Huang Ying wrote:
The uuid_le/be_gen() in lib/uuid.c has set UUID variants to be DCE,
that is done in __uuid_gen_common() with b[8] = (b[8] 0x3F) | 0x80.
Oh, I see, I missed that.
To deal
On Tue, 2012-10-30 at 22:38 -0400, Theodore Ts'o wrote:
On Wed, Oct 31, 2012 at 09:35:37AM +0800, Huang Ying wrote:
The intention of lib/uuid.c is to unify various UUID related code, and
put them in same place. In addition to UUID generation, it provide some
other utility and may
on to D0uninitialized state. These devices should be
resumed, so that they can get opportunity to go to low power state
later.
Signed-off-by: Huang Ying ying.hu...@intel.com
Acked-by: Rafael J. Wysocki r...@sisk.pl
---
drivers/acpi/pci_bind.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/acpi
off. When one of the device is
waked, the power resource will be turned on and all devices share it
will be powered on to D0uninitialized state. These devices should be
resumed, so that they can get opportunity to go to low power state
later.
Signed-off-by: Huang Ying ying.hu...@intel.com
Acked
On Fri, 2012-11-02 at 10:52 -0600, Bjorn Helgaas wrote:
On Wed, Oct 24, 2012 at 12:54 AM, Huang Ying ying.hu...@intel.com wrote:
Some actions during shutdown need device to be in D0 state, such as
MSI shutdown etc, so resume device before shutdown.
Is there a problem report or bugzilla
On Fri, 2012-11-02 at 10:50 -0600, Bjorn Helgaas wrote:
On Wed, Oct 24, 2012 at 12:54 AM, Huang Ying ying.hu...@intel.com wrote:
If a PCI device and its parents are put into D3cold, unbinding the
device will trigger deadlock as follow:
- driver_unbind
- device_release_driver
On Sat, 2012-11-03 at 11:22 -0600, Bjorn Helgaas wrote:
On Fri, Nov 2, 2012 at 11:06 PM, Huang Ying ying.hu...@intel.com wrote:
On Fri, 2012-11-02 at 10:50 -0600, Bjorn Helgaas wrote:
On Wed, Oct 24, 2012 at 12:54 AM, Huang Ying ying.hu...@intel.com wrote:
If a PCI device and its parents
On Sat, 2012-11-03 at 11:21 -0600, Bjorn Helgaas wrote:
On Fri, Nov 2, 2012 at 11:05 PM, Huang Ying ying.hu...@intel.com wrote:
On Fri, 2012-11-02 at 10:52 -0600, Bjorn Helgaas wrote:
On Wed, Oct 24, 2012 at 12:54 AM, Huang Ying ying.hu...@intel.com wrote:
Some actions during shutdown need
children are
suspended, and may cause issue.
This issue is fixed via checking the usage count of the child device
because if the runtime PM of the child device is forbidden, the
usage_count of the child device will be non-zero.
Signed-off-by: Huang Ying ying.hu...@intel.com
---
drivers/base/power
On Mon, 2012-11-05 at 17:02 -0700, Bjorn Helgaas wrote:
On Wed, Sep 26, 2012 at 7:59 AM, Huang Ying ying.hu...@intel.com wrote:
Sorry for bothering. It appears that this patch should go through ACPI
tree because code changed are under drivers/acpi.
A set of power resources may be shared
On Sun, 2012-11-04 at 20:56 -0500, Alan Stern wrote:
On Mon, 5 Nov 2012, Huang Ying wrote:
In current runtime PM implementation, the active child count of the
parent device may be decreased if the runtime PM of the child device
is disabled and forbidden. For example, to unbind a PCI
On Tue, 2012-11-06 at 10:17 -0500, Alan Stern wrote:
On Tue, 6 Nov 2012, Huang Ying wrote:
On Sun, 2012-11-04 at 20:56 -0500, Alan Stern wrote:
On Mon, 5 Nov 2012, Huang Ying wrote:
In current runtime PM implementation, the active child count of the
parent device may
on to D0uninitialized state. These devices should be
resumed, so that they can get opportunity to go to low power state
later.
v2:
- Fix build error
Signed-off-by: Huang Ying ying.hu...@intel.com
Acked-by: Rafael J. Wysocki r...@sisk.pl
Cc: Bjorn Helgaas bhelg...@google.com
---
drivers/acpi/pci_bind.c
. The driver configures the autosuspend timeout to 5s for
this reason, and I think the PCI layer config accesses should respect
the autosuspend.
Cc: Huang Ying ying.hu...@intel.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Rafael J. Wysocki r...@sisk.pl
Signed-off-by: Dave Airlie airl
On Wed, 2012-11-07 at 01:15 -0500, David Airlie wrote:
Cc: Huang Ying ying.hu...@intel.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Rafael J. Wysocki r...@sisk.pl
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/pci/pci-sysfs.c | 2 +-
1 file changed, 1
,
Huang Ying
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, 2012-11-08 at 02:35 +0100, Rafael J. Wysocki wrote:
On Thursday, November 08, 2012 09:15:08 AM Huang Ying wrote:
On Thu, 2012-11-08 at 00:09 +0100, Rafael J. Wysocki wrote:
On Wednesday, November 07, 2012 11:51:15 PM Rafael J. Wysocki wrote:
On Wednesday, November 07, 2012 04:56
Some actions during shutdown need device to be in D0 state, such as
MSI shutdown etc, so resume device before shutdown.
Signed-off-by: Huang Ying ying.hu...@intel.com
---
drivers/pci/pci-driver.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
--- a/drivers/pci/pci
callback function.
So I fixed the dead lock as follow:
- remove device_lock from pci_walk_bus
- add device_lock into callback if callback will call driver's callback
I checked pci_walk_bus users one by one, and found only PCIe aer needs
device lock.
Signed-off-by: Huang Ying ying.hu...@intel.com
Cc
...@intel.com
Reviewed-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Huang Ying ying.hu...@intel.com
Best Regards,
Huang Ying
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
.
This is the same as /sys/bus/pci/devices/:??:??.?/config access
issue. So the function used to solve sysfs issue is used to solve
this issue.
Cc: sta...@vger.kernel.org
Reported-by: Peter lekenst...@gmail.com
Signed-off-by: Huang Ying ying.hu...@intel.com
---
drivers/pci/pci-sysfs.c | 34
of commit:
379021d5c0899fcf9410cae4ca7a59a5a94ca769
Cc: Rafael J. Wysocki rafael.j.wyso...@intel.com
Signed-off-by: Huang Ying ying.hu...@intel.com
---
drivers/pci/pci.c | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
--- a/drivers/pci/pci.c
+++ b/drivers
may be a little low level and error-prone to the invoker (mainly bus
code).
Best Regards,
Huang Ying
Also when the
device's status is ACTIVE, but its parent's child count is 0.
__pm_runtime_set_status prevents this situation from arising. When the
device's status is set to ACTIVE
On Fri, 2012-11-09 at 11:41 -0500, Alan Stern wrote:
On Fri, 9 Nov 2012, Huang Ying wrote:
On Thu, 2012-11-08 at 12:07 -0500, Alan Stern wrote:
On Thu, 8 Nov 2012, Rafael J. Wysocki wrote:
is it a good idea to allow to set device state to SUSPENDED if
the device
On Sun, 2012-11-11 at 21:36 -0500, Alan Stern wrote:
On Mon, 12 Nov 2012, Huang Ying wrote:
The first question: How should the PCI subsystem prevent the parents of
driverless VGA devices from being runtime suspended while userspace is
accessing them?
I think Rafael's patch
On Mon, 2012-11-12 at 11:32 -0500, Alan Stern wrote:
On Mon, 12 Nov 2012, Huang Ying wrote:
Is it absolute necessary to call pm_runtime_set_suspended? If the
device is disabled, the transition to SUSPENDED state will not be
triggered even if the device is ACTIVE.
It's
On Mon, 2012-11-12 at 21:32 -0500, Alan Stern wrote:
On Tue, 13 Nov 2012, Huang Ying wrote:
Sorry, my original idea is:
pm_runtime_disable will put device into SUSPENDED state if
dev-power.runtime_auto is clear. pm_runtime_allow will put
device into SUSPENDED state
On Tue, 2012-11-13 at 11:10 -0500, Alan Stern wrote:
On Tue, 13 Nov 2012, Huang Ying wrote:
This is not quite right. Consider a device that is in runtime suspend
when a system sleep starts. When the system sleep ends, the device
will be resumed but the PM core will still think its
On Wed, 2012-11-14 at 10:52 +0100, Rafael J. Wysocki wrote:
On Wednesday, November 14, 2012 09:08:28 AM Huang Ying wrote:
On Tue, 2012-11-13 at 11:10 -0500, Alan Stern wrote:
On Tue, 13 Nov 2012, Huang Ying wrote:
This is not quite right. Consider a device that is in runtime
proven to be the
panacea for all the issues.
Configuration is a problem, we will work on it.
But, because it is based on kexec/kdump instead of starting from
scratch, the duplicated part between hibernation and kexec/kdump can be
eliminated.
Best Regards,
Huang Ying
-
To unsubscribe from
On Fri, 2007-09-21 at 12:25 +1000, Nigel Cunningham wrote:
Hi.
On Friday 21 September 2007 12:18:57 Huang, Ying wrote:
That's not true. Kexec will itself be an implementation, otherwise you'd
end
up with people screaming about no hibernation support. And it won't
result
On Thu, 2007-09-20 at 20:55 -0600, Eric W. Biederman wrote:
Huang, Ying [EMAIL PROTECTED] writes:
This patch implements the functionality of jumping between the kexeced
kernel and the original kernel.
A new reboot command named LINUX_REBOOT_CMD_KJUMP is defined to
trigger the jumping
On Thu, 2007-09-20 at 22:01 -0600, Eric W. Biederman wrote:
Huang, Ying [EMAIL PROTECTED] writes:
Index: linux-2.6.23-rc6/include/linux/kexec.h
===
--- linux-2.6.23-rc6.orig/include/linux/kexec.h 2007-09-20
11:24
On Fri, 2007-09-21 at 10:43 +0200, Stefan Rompf wrote:
Am Donnerstag, 20. September 2007 07:34 schrieb Huang, Ying:
The hibernation procedure with the patch set is as follow:
1. Boot a kernel A
2. Work under kernel A
3. Kexec another kernel B (crash dump enabled) in kernel
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
in a compatible way on top of the
kexec-based solution.]
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
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
Hi, Peter,
On Wed, 2007-09-19 at 09:04 -0700, H. Peter Anvin wrote:
Huang, Ying wrote:
Known Issues:
1. Where is safe to place the linked list of setup_data?
Because the length of the linked list of setup_data is variable, it
can not be copied into BSS segment of kernel
. For example, it is possible that there is only one user
process -- the image-writing process running in image-writing kernel.
So, no freezer or blkdev snapshot is needed.
Best Regards,
Huang Ying
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
them to zero-page.txt.
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/
This patch add a field of 64-bit physical pointer to NULL terminated
single linked list of struct setup_data to real-mode kernel
header. This is used as a more extensible boot parameters passing
mechanism.
Signed-off-by: Huang Ying [EMAIL PROTECTED]
---
arch/i386/Kconfig|3
This patch export the boot parameters via sysfs. This can be used for
debugging and kexec.
Signed-off-by: Huang Ying [EMAIL PROTECTED]
---
i386/kernel/Makefile|1
i386/kernel/ksysfs.c| 242
i386/kernel/setup.c |2
x86_64
This patch defines a 32-bit boot protocol and adds corresponding
document. It is based on the proposal of Peter Anvin.
Signed-off-by: Huang Ying [EMAIL PROTECTED]
---
boot.txt | 70 +++
zero-page.txt | 129
On Tue, 2007-10-09 at 01:25 +1000, Nick Piggin wrote:
On Tuesday 09 October 2007 16:40, Huang, Ying wrote:
+unsigned long copy_from_phys(void *to, unsigned long from_phys,
+unsigned long n)
+{
+ struct page *page;
+ void *from;
+ unsigned long remain
On Tue, 2007-10-09 at 02:06 +1000, Nick Piggin wrote:
On Tuesday 09 October 2007 18:22, Huang, Ying wrote:
On Tue, 2007-10-09 at 01:25 +1000, Nick Piggin wrote:
On Tuesday 09 October 2007 16:40, Huang, Ying wrote:
+unsigned long copy_from_phys(void *to, unsigned long from_phys
On Tue, 2007-10-09 at 02:28 +1000, Nick Piggin wrote:
On Tuesday 09 October 2007 18:55, Huang, Ying wrote:
On Tue, 2007-10-09 at 02:06 +1000, Nick Piggin wrote:
I'm just wondering whether you really need to access highmem in
boot code...
Because the zero page (boot_parameters
, the virtual memory space of ioremap is limited too.
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
On Tue, 2007-10-09 at 12:23 -0700, H. Peter Anvin wrote:
Huang, Ying wrote:
- Which fields of boot parameters should be exported directly in
sysfs? Export all fields of boot parameters in sysfs is too complex
and unnecessary. Which fields should be?
The main this is that since
On Tue, 2007-09-11 at 20:23 -0700, Andrew Morton wrote:
On Fri, 17 Aug 2007 13:28:38 +0800 Huang, Ying [EMAIL PROTECTED] wrote:
This patch fixes a bug of change_page_attr/change_page_attr_addr on
Intel x86_64 CPU. After changing page attribute to be executable with
these functions
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/
: tmp=dest; dest=src; src=tmp
If memory is swapped, no information is lost, both that of kexec kernel
and kexeced kernel.
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
state and
system is put into suspend state; or the image is written to disk
(through snapshot/uswsusp or kexeced kernel).
4. After resuming from RAM/DISK, devices are put into normal state and
the syscall entries replaced in step 2 are restored.
Best Regards,
Huang Ying
-
To unsubscribe from this list
RAM and all kinds of reserved regions, which is backed by
iomem_resource. On x86_64, it is initialized in the exact same way as
nosave region initialization.
I think maybe we can replace the nosave region concepts with
iomem_resource (maybe need some enhancement).
Best Regards,
Huang Ying
a full kexec based hibernation prototype,
including kexec, write out the image, reboot, restore the memory and
jump back. I will release it recently. :)
Best Regards,
Huang Ying
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
instead of zero page protocol.
In the future, when all bootloaders use new protocol, the zero page
is made internal formally.
Any comment is welcome.
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
On Thu, 2007-08-23 at 00:28 +0800, H. Peter Anvin wrote:
huang ying wrote:
My proposal: Use Peter proposed linked list of struct setup_data
style boot protocol as long term goal.
To smooth the transforming process, the following back compatible
scheme can be taken:
1. Keep zero
Kexec base hibernation has some potential advantages over uswsusp and
TuxOnIce (suspend2). Some most obvious advantages are:
1. The hibernation image size can exceed half of memory size easily.
2. The hibernation image can be written to and read from almost
anywhere, such as USB disk, NFS.
, the state of devices and CPU are restored
accordingly. The devices/CPU state save/restore code of software
suspend is called to implement corresponding function.
Signed-off-by: Huang Ying [EMAIL PROTECTED]
---
Documentation/kernel-parameters.txt |8 +++
arch/i386/Kconfig
This patch adds writing support for /dev/oldmem. This is used to
restore the memory contents of hibernated system.
Signed-off-by: Huang Ying [EMAIL PROTECTED]
---
arch/i386/kernel/crash_dump.c | 27 +++
drivers/char/mem.c| 32
directly.
Best Regards,
Huang Ying
Best regards
Hu, Fenghua
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Huang, Ying
Sent: 2007年8月27日 9:14
To: Eric W. Biederman; Pavel Machek; [EMAIL PROTECTED]; Andrew Morton; Jeremy
Maitin-Shepard; Alan Stern
Cc
On Mon, 2007-08-27 at 10:30 +0530, Vivek Goyal wrote:
On Mon, Aug 27, 2007 at 09:14:05AM +0800, Huang, Ying wrote:
Kexec base hibernation has some potential advantages over uswsusp and
TuxOnIce (suspend2). Some most obvious advantages are:
1. The hibernation image size can exceed half
in grub 2.0
in a manageable way. :)
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/
On Mon, 2007-08-27 at 23:31 +0200, Pavel Machek wrote:
Hi!
This patch adds writing support for /dev/oldmem. This is used to
restore the memory contents of hibernated system.
Signed-off-by: Huang Ying [EMAIL PROTECTED]
+ssize_t write_oldmem_page(unsigned long pfn, const char *buf
, the state of devices and CPU are restored
accordingly. The devices/CPU state save/restore code of software
suspend is called to implement corresponding function.
Signed-off-by: Huang Ying [EMAIL PROTECTED]
Looks quite ok to me...
Index: linux-2.6.23-rc3/include/asm-i386/kexec.h
Narayanan [EMAIL PROTECTED]
Signed-off-by: Huang Ying [EMAIL PROTECTED]
Index: linux-2.6.23-rc2/Documentation/i386/zero-page.txt
===
--- linux-2.6.23-rc2.orig/Documentation/i386/zero-page.txt 2007-08-13
13:08:39.0 +0800
with kernel boot options.
Signed-off-by: Chandramouli Narayanan [EMAIL PROTECTED]
Signed-off-by: Huang Ying [EMAIL PROTECTED]
---
arch/x86_64/kernel/reboot.c| 19 -
arch/x86_64/kernel/time.c | 48 ++---
include/asm-x86_64
is the number of
parameters) are implemented. EFI function calls are wrapped before
calling the firmware service.
Signed-off-by: Chandramouli Narayanan [EMAIL PROTECTED]
Signed-off-by: Huang Ying [EMAIL PROTECTED]
---
arch/x86_64/Kconfig | 13
arch/x86_64/kernel/Makefile
comments,
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/
On Thu, 2007-08-16 at 06:42 +0800, Andrew Morton wrote:
On Mon, 13 Aug 2007 15:30:19 +0800
Huang, Ying [EMAIL PROTECTED] wrote:
Following sets of patches add EFI/UEFI (Unified Extensible Firmware
Interface) runtime services support to x86_64 architecture.
I had to rework these a bit due
101 - 200 of 3349 matches
Mail list logo
