> IA64
>
> Subject : Regression in serial console on ia64 after 2.6.22
> References : http://marc.info/?l=linux-ia64&m=118483645914066&w=2
> Last known good : ?
> Submitter : Horms <[EMAIL PROTECTED]>
> Caused-By : Yinghai Lu <[EMAIL
On Wed, Jul 25, 2007 at 11:26:42AM -0400, Doug Chapman wrote:
> On Wed, 2007-07-25 at 22:37 +0900, Horms wrote:
>
> > I was also seeing a strange problem relating to the
> > vector domain patch which seemed to be causing
> > corruption of vectors_in_migration, which caus
On Wed, Jul 25, 2007 at 11:26:42AM -0400, Doug Chapman wrote:
> On Wed, 2007-07-25 at 22:37 +0900, Horms wrote:
>
> > I was also seeing a strange problem relating to the
> > vector domain patch which seemed to be causing
> > corruption of vectors_in_migration, which caus
uption of vectors_in_migration, which caused migrate_irqs()
to emmit suprious IRQ errors (when called by kexec).
I'll try and confirm that this patch soles the problem that
I was seeing tomorrow.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe
On Tue, Jul 24, 2007 at 04:57:32PM -0700, Yinghai Lu wrote:
>
> IA64
>
> Subject : Regression in serial console on ia64 after 2.6.22
> References : http://marc.info/?l=linux-ia64&m=118483645914066&w=2
> Last known good : ?
> Submitter : Horms &l
n parsing.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Short Description
Parse the machvec command line option outside of the early_param()
so that ia64_mv is set before any console intialisation that
may result from early_param parsing.
Long Description
18a8bd949d6adb311ea816125ff65050df1f3f6e appears to have caused
a regression in the serial conso
I have not investigated the effects of
18a8bd949d6adb311ea816125ff65050df1f3f6e on
sn_serial_console_early_setup()
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a m
On Fri, May 25, 2007 at 02:46:37PM +0900, Satoru Takeuchi wrote:
> Conform ia64 signal code to the 80-characters-per-line rule.
> It has no functional change.
I have a bunch of simmilar changes for other files.
Tony, are you interested in this kind of change?
--
Horms
H
27; and
> 'acpi_request_vector')
>
> Looks like acpi_get_sysname() can be marked __init...
It seems like Tony has put the same fix in.
In any case, no warnings over here on
Linus' 1c1ee4c3e7e16d23166a624a132889df3c540a18
--
Horms
H: http://www.vergenet.net/~horms/
W: h
On Tue, Mar 20, 2007 at 01:53:51PM +1100, Keith Owens wrote:
> Horms (on Tue, 20 Mar 2007 11:34:28 +0900) wrote:
> >On Mon, Mar 19, 2007 at 07:12:44PM -0700, Jay Lan wrote:
> >> Since DIE_INIT_SLAVE_ENTER is a non-zero value, thus "nd->sos->rv_rc
> >> ==1&
ia64_mca_notify_die *)args->err;
> /* Reason code 1 means machine check rendezous*/
> - if ((val == DIE_INIT_MONARCH_ENTER || DIE_INIT_SLAVE_ENTER) &&
> + if ((val == DIE_INIT_MONARCH_ENTER || val == DIE_INIT_SLAVE_ENTER) &&
>nd->sos->rv_rc == 1)
+35,7 @@ extern void reserve_memory (void);
> extern void find_initrd (void);
> extern int filter_rsvd_memory (unsigned long start, unsigned long end, void
> *arg);
> extern void efi_memmap_init(unsigned long *, unsigned long *);
> +extern int find_max_min_low_pfn (unsigned long , unsigned long, void *);
>
> /*
> * For rounding an address to the next IA64_GRANULE_SIZE or order
>
>
>
>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ot kexec-tools-testing git tree and
> i no longer see the zero-size-vmcore problem.
I take it that elfcorehdr is also correct in this environment?
The latest (ia64) kernels need a fairly recent kexec-tools-testing
because of the change "kexec: Use EFI_LOADER_DATA for ELF core header".
A
On Wed, Mar 07, 2007 at 10:47:43AM +0100, Bernhard Walle wrote:
> * Horms <[EMAIL PROTECTED]> [2007-03-07 09:24]:
> > As only md is used to calculate saved_max_pfn it seems reasonable
> > to move setting saved_max_pfn to imediately after md is validated.
> > This should
On Wed, Mar 07, 2007 at 05:06:39PM +0800, Zou, Nanhai wrote:
> > -Original Message-
> > From: Horms [mailto:[EMAIL PROTECTED]
> > Sent: 2007年3月7日 15:55
> > To: Zou, Nanhai
> > Cc: Linux-IA64; fastboot@lists.osdl.org; Luck, Tony; Magnus Damm
> > Subje
suggested to me that if this change is going to be made,
then the whole chunk may as well be moved up to just after md is
validated. See below:
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
As only md is used to calculate saved_max_pfn it seems reasonable
to move s
On Wed, Mar 07, 2007 at 12:50:12PM +0800, Zou, Nanhai wrote:
> On Wed, Mar 07, 2007 at 11:46, Horms wrote:
> >
> > I think that the manual option is also important because it
> > maintains feature-compatibility with other architectures. I don't
> > consider it a
On Wed, Mar 07, 2007 at 10:15:20AM +0800, Zou, Nanhai wrote:
> > -Original Message-
> > From: Horms [mailto:[EMAIL PROTECTED]
> > Sent: 2007年3月7日 8:50
> > To: Zou, Nanhai
> > Cc: Linux-IA64; fastboot@lists.osdl.org; Luck, Tony; Magnus Damm
> > Subject: R
Hi,
Here is a minor update to this patch, which makes the use
of log priorities more consistent.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
This patch adds a faclilty to print out a message regarding the success or
failure of inserting the crashkernel
Hi Aron,
thanks for picking up these silly errors. An updated version is below.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
When the crashkernel command line argument is supplied, it may optionally
include the base address at which to locate the region. If
Hi,
Here is a minor update to this patch, which makes the use
of log priorities more consistent.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
Date: Tue, 06 Mar 2007 16:28:51 +0900
To: Linux-IA64 ,
fastboot@lists.osdl.org
Cc: Tony Luck <[EMAIL PROTEC
On Tue, Mar 06, 2007 at 04:34:44PM +0800, Zou, Nanhai wrote:
> > -Original Message-
> > From: Horms [mailto:[EMAIL PROTECTED]
> > Sent: 2007年3月6日 15:29
> > To: Linux-IA64; fastboot@lists.osdl.org
> > Cc: Luck, Tony; Zou, Nanhai; Magnus Damm
>
On Tue, Mar 06, 2007 at 04:23:37PM +0800, Zou, Nanhai wrote:
>
> Hi Horms,
> I feel this is over-designed.
> I think to specify crash kernel base address in command line is only
> useful for debug, on platform like SN this feature is totally unusable.At the
>
On Tue, Mar 06, 2007 at 10:32:09AM +0800, Zou Nan hai wrote:
> On Tue, 2007-03-06 at 09:56, Horms wrote:
> > Hi,
> >
> > I am currently looking over the code that places the crashdump
> > region into /proc/iomem, and the code that determines its base
> > address
Hi,
the following 3 patches address some minor issues in the
functions handling the crashkernel command line argument.
A related patch by Nanhai can be found at
http://permalink.gmane.org/gmane.comp.boot-loaders.fastboot.general/3905
-
To unsubscribe from this list: send the line "unsubscribe lin
(KERN_WARNING "Cannot reserve 0x%lx byte of memory for crashdump\n",
- size);
+ printk(KERN_WARNING "Kdump: failed to find a base address for 0x%lx bytes"
+"of memory for crashdump\n", size);
return ~0UL;
}
#endif
--
--
Horms
H: http://www.vergen
t rsvd_region *rsvd_regions, int n);
extern unsigned long kdump_find_rsvd_region(unsigned long size,
struct rsvd_region *rsvd_regions, int n);
extern void kdump_cpu_freeze(struct unw_frame_info *info, void *arg);
--
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
efi_initialize_iomem_resources() is declared in both include/linux/efi.h
and arch/ia64/kernel/setup.c. This patch removes the latter.
Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/arch/ia64/kernel/setup.c
===
--- l
signed long
+unsigned long __init
kdump_find_rsvd_region (unsigned long size,
struct rsvd_region *r, int n)
{
--
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64"
On Tue, Mar 06, 2007 at 10:18:59AM +0800, Zou, Nanhai wrote:
> > -Original Message-
> > From: Zou, Nanhai
> > Sent: 2007年3月6日 10:11
> > To: 'Horms'
> > Cc: Linux-IA64; fastboot
> > Subject: RE: Crash Dump Region
> >
> > >
. Is this behaviour correct?
If not, should it be restricted to "System RAM" regions?
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to [EMAIL PROTE
from certain hardware errors.
>
> Signed-off-by: John Keller <[EMAIL PROTECTED]>
I made a similar change when porting to xen, but I hadn't thought
to see if mainline linux needs it to.
Acked-by: Simon Horman <[EMAIL PROTECTED]>
--
Horms
H: http://www.vergenet.net/~horms/
W:
On Fri, Feb 16, 2007 at 07:35:05PM +0900, Horms wrote:
> On Thu, Feb 15, 2007 at 10:52:35PM +0900, Magnus Damm wrote:
> > kexec: Use EFI_LOADER_DATA for ELF core header (ia64)
> >
> > The address where the ELF core header is stored is passed to the secondary
> > kern
On Thu, Feb 15, 2007 at 10:52:35PM +0900, Magnus Damm wrote:
> kexec: Use EFI_LOADER_DATA for ELF core header (ia64)
>
> The address where the ELF core header is stored is passed to the secondary
> kernel as a kernel command line option. The memory area for this header is
> also marked as a sepa
On Thu, Feb 15, 2007 at 10:06:12AM +0800, Zou, Nanhai wrote:
> >
> > I think that the dummy efi function is already way to hacky.
> Yes it is. However the benefit of it is that you can kexec to an old
> kernel even a 2.4 based kernel.
That is a good point.
-
On Thu, Feb 15, 2007 at 11:15:56AM +0900, Magnus Damm wrote:
> On 2/15/07, Bernhard Walle <[EMAIL PROTECTED]> wrote:
> >* Horms <[EMAIL PROTECTED]> [2007-02-14 02:38]:
> >> On Tue, Feb 13, 2007 at 06:03:20PM +0100, Bernhard Walle wrote:
> >> > > Index:
ire system.
>
> So, as the patch works here also and it's necessary to make kdump
> working, I suggest including it mainline.
Agreed, below is a version of the patch for Linus' tree as of this morning.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.c
4096) < 0)
>
> Why not using EFI_PAGE_SIZE here? It would also be good to find a
> suitable constant name for 1024.
Indeed, I meant to use EFI_PAGE_SIZE instead of 4096.
I'll fix that up and apply.
As for a good constant name, I'm open to sugg
On Thu, Feb 08, 2007 at 08:16:04PM -0600, Jack Steiner wrote:
> On Fri, Feb 09, 2007 at 09:41:37AM +0900, Horms wrote:
> > On Thu, Feb 08, 2007 at 01:48:56PM -0800, Jay Lan wrote:
> > > Horms wrote:
> > > > Hi,
> > > >
> > > > I am resend
On Thu, Feb 08, 2007 at 01:48:56PM -0800, Jay Lan wrote:
> Horms wrote:
> > Hi,
> >
> > I am resending this patch, which builds on the patch sent earlier
> > in this thread to allow physical mode SAL/EFI to work.
> >
>
> Hi Horms,
>
> Do you plan
27;s old tree cross compiling doesn't really work)?
Or perhaps my kernel config is odd.
> Also it will be helpful to print efi_memmap in purgatory code.
Indeed. Do you have any way to dump purgatory's console across
a serial port? The vga console and I are on opposite sides o
On Thu, Feb 08, 2007 at 12:21:02PM +0800, Zou Nan hai wrote:
> On Thu, 2007-02-08 at 13:34, Vivek Goyal wrote:
> > On Thu, Feb 08, 2007 at 12:06:53PM +0900, Horms wrote:
> > > On Thu, Feb 08, 2007 at 10:07:48AM +0800, Zou, Nanhai wrote:
> > > >
> > > &
On Wed, Feb 07, 2007 at 03:19:06PM +0900, Horms wrote:
> Hi,
>
> I am resending this patch, which is a consolidated version of 3 or 4
> patches sent late last year. It includes a few minor fixes, and
> I have removed the portion which caused the pal code not to be mapped.
>
&
are more comfortable with the stub
approach, I have no objections.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
be right that we can just remove the check all together,
though perhaps it is there for the case where the range information
in the vmcode are corrupted. Then again, should we care about this?
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe
.
--
Simon Horman (Horms)
[EMAIL PROTECTED]
http://verge.net.au/~horms/
[IA64] physical mode SAL calls
Currently the EFI code will fall back to making real mode calls if the call
to map the EFI code fails. Unfortunately this only takes into account EFI
calls, but if EFI calls are made in physical
Hi,
I am resending this patch, which builds on the patch sent earlier
in this thread to allow physical mode SAL/EFI to work.
--
Simon Horman (Horms)
[EMAIL PROTECTED]
http://verge.net.au/~horms/
[IA64] Add phys_efi command line option
This patch adds a command line option, phys_efi, which
* Make use of spaces and tabs consistent
* Make long line < 80col
Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/include/asm-ia64/sal.h
===
--- linux-2.6.orig/include/asm-ia64/sal.h 2007-02-07 11:53:12.000
kexec.h is needed by arch/ia64/kernel/process.c so for the
declaration of kexec_disable_iosapic() which is used in machine_shutdown().
Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/arch/ia64/kernel/process.c
===
--
On Mon, Feb 05, 2007 at 01:18:16PM +0100, Gerald Pfeifer wrote:
> On Mon, 5 Feb 2007, Horms wrote:
> > Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
> > - printk(KERN_WARNING "%s: no PAL-code memory-descriptor found",
> > + printk(KERN_WARNING "
Fix a typo in the saved_max_pfn description in contig.c
Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
diff --git a/arch/ia64/mm/contig.c b/arch/ia64/mm/contig.c
index 1e79551..ec8657b 100644
--- a/arch/ia64/mm/contig.c
+++ b/arch/ia64/mm/contig.c
@@ -177,7 +177,7 @@ find_memory (void)
#ifdef
e been around since at least 2.6.19-rc6
I have a Tiger2 system using disctontig memory
The problem also seems to manifest when using contig memory
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
Set saved_max_pfn when discontig memory is in use.
This sets up saved
This moves the ia64 implementation of machine_shutdown() from
machine_kexec.c to process.c, which is in keeping with the implelmentation
on other architectures, and seems like a much more appropriate home for it.
Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/arch/ia64/kernel/ma
linux/uaccess.h was being included, but it seems that
really the following includes are needed.
asm/page.h: for __va() and PAGE_SHIFT
asm/uaccess.h: for copy_to_user()
I guess that linux/uaccess.h pulls in both asm/page.h and asm/uaccess.h.
I notices this while backporting the code to xen's linu
Remove the Remove inline declaration of efi_get_pal_addr() as it is
declared in linux/efi.h.
Signed-Off-By: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/arch/ia64/kernel/machine_kexec.c
===
--- linux-2.6.o
Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/arch/ia64/kernel/efi.c
===
--- linux-2.6.orig/arch/ia64/kernel/efi.c 2007-01-31 16:54:43.0
+0900
+++ linux-2.6/arch/ia64/kernel/efi.c2007-01-31 16:54:
better to fail miserably during the build than
> fail silently in the case of CONFIG_SMP=y but CONFIG_HOTPLUG_CPU=n.
There used to be alternate code for the CONFIG_SMP +
!CONFIG_HOTPLUG_CPU, but this was removed because it was determined to
be flakey and not maintainable (I can dig up the thr
and is used to dynamically allocate the two arrays.
>
>
> Signed-off-by: Jay Lan <[EMAIL PROTECTED]>
>
Thanks, applied.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64&quo
gt; I trust ia64_jump_to_sal doesn't return.
> >
> > So do I. The main problem with the compilation seems to be that
> > ia64_jump_to_sal() only exists if CONFIG_HOTPLUG_CPU=y.
> > (include/asm-ia64/sal.h, arch/ia64/kernel/head.S)
> >
> This may cause problem on SN
;
> This patch would let kexec allocate the efi_memmap at run time using
> the actual size allocated in the production kernel.
>
>
> Signed-off-by: Jay Lan <[EMAIL PROTECTED]>
Thanks, applied.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
On Tue, Jan 30, 2007 at 05:19:51PM +0900, Magnus Damm wrote:
> kexec: Avoid migration of already disabled irqs (ia64)
>
> This patch fixes up ia64 kexec support for HP rx2620 hardware. It does this
> by skipping migration of already disabled irqs. This is most likely a problem
> on other ia64 pla
arg);
> +
> #ifdef CONFIG_VIRTUAL_MEM_MAP
> # define LARGE_GAP 0x4000 /* Use virtual mem map if hole is > than
> this */
>extern unsigned long vmalloc_end;
>extern struct page *vmem_map;
>extern int find_largest_hole (u64 start, u64 end, void *arg);
> - ext
On Fri, Jan 12, 2007 at 11:46:39AM -0800, Jay Lan wrote:
> Horms wrote:
> > Hi,
> >
> > this patch fills in the portions for ia64 kexec.
> >
> > I'm actually not sure what options are required for the dump-capture
> > kernel, but "init 1 irqpol
Hi,
this patch fills in the portions for ia64 kexec.
I'm actually not sure what options are required for the dump-capture
kernel, but "init 1 irqpoll maxcpus=1" has been working fine for me.
Or more to the point, I'm not sure if irqpoll is needed or not.
This patch requires the documentation pat
Hi,
this patch fills in the portions for ia64 kexec.
I'm actually not sure what options are required for the dump-capture
kernel, but "init 1 irqpoll maxcpus=1" has been working fine for me.
Or more to the point, I'm not sure if irqpoll is needed or not.
This patch requires the documentation pat
12
14:37:18.0 +0900
+++ linux-2.6/Documentation/kdump/kdump.txt 2007-01-12 14:56:42.0
+0900
@@ -61,7 +61,12 @@
2) Download the kexec-tools user-space package from the following URL:
-http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools-testing-20
Hi,
this patch fills in the portions for ia64 kexec.
I'm actually not sure what options are required for the dump-capture
kernel, but "init 1 irqpoll maxcpus=1" has been working fine for me.
Or more to the point, I'm not sure if irqpoll is needed or not.
This patch requires the documentation pat
On Mon, Dec 18, 2006 at 02:52:44PM +, Mel Gorman wrote:
> On (12/12/06 18:10), Horms didst pronounce:
> > On Mon, Nov 20, 2006 at 09:40:32AM +0800, Zou, Nanhai wrote:
> > > > -Original Message-
> > > > From: Luck, Tony
> > > > Sent: 2006?$B
On Mon, Dec 18, 2006 at 02:52:44PM +, Mel Gorman wrote:
> On (12/12/06 18:10), Horms didst pronounce:
[snip]
> > Now that ia64 kexec/kdump has been merged into Linus tree this
> > really ought to be fixed. What is the best way forward?
> >
>
> Sorry for the del
Remove the Remove inline declaration of efi_get_pal_addr() as it is
declared in linux/efi.h.
Signed-Off-By: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/arch/ia64/kernel/machine_kexec.c
===
--- linux-2.6.o
gt; 1);
> tmp = xmalloc(size);
> memset(tmp, 0, size);
Hi,
that patch looks correct to me. However, I believe that the problem is
already resolved in kexec-tools-testing by using the generic /proc/iomem
handling code that was introduced in changesets
Sorry, the previous version of this patch was against my development tree.
Here is a version that should apply to the current kexec-tools-testing
tree.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
*** kexec-tools portion of this patch, kernel portion posted
kernel so it knew it was a second kernel and drivers could take
evasive action as needed. I'm not sure what happened to that idea.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64&qu
*** kexec-tools portion of this patch, kernel portion posted separately ***
Currently the purgatory code for ia64 has the PAGE_OFFSET hardcoded,
and uses this to perform the equivalent of __pa() on some of the
data contained inside ia64_boot_param.
This is problematic if the kernel (or hyperviso
*** Kernel portion of this patch, kexec-tools portion to follow ***
Currently the purgatory code for ia64 has the PAGE_OFFSET hardcoded,
and uses this to perform the equivalent of __pa() on some of the
data contained inside ia64_boot_param.
This is problematic if the kernel (or hypervisor or what
stems (linux, xen, ...)
agree to use that. But that idea is farily complex, and I'm not
even sure it can work.
> In addition, I think there may be additional problems with our SAL
> if we try to run only in physical mode. I'll take a look.
Thanks
--
Horms
H: http://w
On Tue, Oct 24, 2006 at 02:47:38PM -0500, Jack Steiner wrote:
> On Mon, Oct 23, 2006 at 05:48:43PM +0900, Horms wrote:
> > There seems to be no reason to map the PAL code into memory if
> > physical calls are going to be made.
>
>
> If you don't map PAL, I assume th
problem on booting up a crashdump kernel at Altix.
>
> Here is the patch that detects the second sn_cpu_init
> call and skips the second call to SN_SAL_SET_CPU_NUMBER.
>
> Signed-Off-By: Jay Lan <[EMAIL PROTECTED]>
That looks fine to me.
Acked: Simon Horman <[EMAIL PROTEC
On Fri, Dec 01, 2006 at 03:08:53PM +0900, Horms wrote:
> On Tue, Nov 21, 2006 at 07:13:56AM +0800, Zou Nan hai wrote:
> > This patch make normal "kexec -l" first try physical address suggested
> > by vmlinux.
> >
> > If there is no enough memory, kexec tools
[IA64] Kexec/Kdump: honour non-zero crashkernel offset.
There seems to be a value in both allowing the kernel to determine
the base offset of the crashkernel automatically and allowing
users's to sepcify it.
The old behaviour on ia64, which is still the current behaviour on
most architectures is
* Make NORET_TYPE and ATTRIB_NORET in line with the
declaration for other architectures
* Add parameter names
Signed-Off-By: Simon Horman <[EMAIL PROTECTED]>
Index: kexec-ia64-2.6/arch/ia64/kernel/machine_kexec.c
===
--- kexec-ia64
On Tue, Dec 12, 2006 at 03:54:51PM +0900, Horms wrote:
> On Mon, Dec 11, 2006 at 03:58:18PM -0800, Luck, Tony wrote:
> > The kexec/crash_dump patches for ia64 have gone into Linus'
> > tree ... but there are some loose ends to tidy up. One of them
> > is what is suppose
On Tue, Nov 21, 2006 at 07:13:56AM +0800, Zou Nan hai wrote:
> This patch make normal "kexec -l" first try physical address suggested
> by vmlinux.
>
> If there is no enough memory, kexec tools will search /proc/iomem and
> find a place to put the new kernel.
>
> This is necessary for "kexec -l"
c int __init
> >>>>>>+filter_pernode_memory (unsigned long start, unsigned long end, void
> >>*arg)
> >>>>>>+{
> >>>>>>+ void (*func)(unsigned long, unsigned long, int);
> >>>>>>+ func = arg;
>
ion.
>
>
> Signed-off-by: Jay Lan <[EMAIL PROTECTED]>
Thanks.
I have applied this patch to kexec-tools-testing
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
th
86 matches
Mail list logo
