<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/ia64/kernel/setup.c, branch linux-2.6.28.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.28.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.28.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2008-11-07T17:51:55Z</updated>
<entry>
<title>[IA64] Reserve elfcorehdr memory in CONFIG_CRASH_DUMP</title>
<updated>2008-11-07T17:51:55Z</updated>
<author>
<name>Jay Lan</name>
</author>
<published>2008-11-07T17:51:55Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=17c1f07ed70afa4f3941745fc3cc173e2a0365fe'/>
<id>urn:sha1:17c1f07ed70afa4f3941745fc3cc173e2a0365fe</id>
<content type='text'>
IA64 kdump kernel failed to initialize /proc/vmcore in 2.6.28-rc2.
A bug was introduced in this patch commit:

  d9a9855d0b06ca6d6cc92596fedcc03f8512e062
  always reserve elfcore header memory in crash kernel

The problem was that the call to reserve_elfcorehdr() should be placed
in CONFIG_CRASH_DUMP rather than in CONFIG_CRASH_KERNEL, which does
not exist.

Signed-off-by: Jay Lan &lt;jlan@sgi.com&gt;
Acked-by: Simon Hormon &lt;horms@verge.net.au&gt;
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</content>
</entry>
<entry>
<title>[IA64] fix boot panic caused by offline CPUs</title>
<updated>2008-11-06T17:28:27Z</updated>
<author>
<name>Doug Chapman</name>
</author>
<published>2008-11-05T22:57:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=62ee0540f5e5a804b79cae8b3c0185a85f02436b'/>
<id>urn:sha1:62ee0540f5e5a804b79cae8b3c0185a85f02436b</id>
<content type='text'>
This fixes a regression introduced by 2c6e6db41f01b6b4eb98809350827c9678996698
"Minimize per_cpu reservations."  That patch incorrectly used information about
what CPUs are possible that was not yet initialized by ACPI.  The end result
was that per_cpu structures for offline CPUs were not initialized causing a
NULL pointer reference.

Since we cannot do the full acpi_boot_init() call any earlier, the simplest
fix is to just parse the MADT for SAPIC entries early to find the CPU
info.  This should also allow for some cleanup of the code added by the
"Minimize per_cpu reservations".  This patch just fixes the regressions, the
cleanup will come in a later patch.

Signed-off-by: Doug Chapman &lt;doug.chapman@hp.com&gt;
Signed-off-by: Alex Chiang &lt;achiang@hp.com&gt;
CC: Robin Holt &lt;holt@sgi.com&gt;
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6</title>
<updated>2008-10-23T15:07:35Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2008-10-23T15:07:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=72441bdc76f7f71d7b75cdaa48f26dbb1f3d932e'/>
<id>urn:sha1:72441bdc76f7f71d7b75cdaa48f26dbb1f3d932e</id>
<content type='text'>
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6: (41 commits)
  [IA64] Fix annoying IA64_TR_ALLOC_MAX message.
  [IA64] kill sys32_pipe
  [IA64] remove sys32_pause
  [IA64] Add Variable Page Size and IA64 Support in Intel IOMMU
  ia64/pv_ops: paravirtualized instruction checker.
  ia64/xen: a recipe for using xen/ia64 with pv_ops.
  ia64/pv_ops: update Kconfig for paravirtualized guest and xen.
  ia64/xen: preliminary support for save/restore.
  ia64/xen: define xen machine vector for domU.
  ia64/pv_ops/xen: implement xen pv_time_ops.
  ia64/pv_ops/xen: implement xen pv_irq_ops.
  ia64/pv_ops/xen: define the nubmer of irqs which xen needs.
  ia64/pv_ops/xen: implement xen pv_iosapic_ops.
  ia64/pv_ops/xen: paravirtualize entry.S for ia64/xen.
  ia64/pv_ops/xen: paravirtualize ivt.S for xen.
  ia64/pv_ops/xen: paravirtualize DO_SAVE_MIN for xen.
  ia64/pv_ops/xen: define xen paravirtualized instructions for hand written assembly code
  ia64/pv_ops/xen: define xen pv_cpu_ops.
  ia64/pv_ops/xen: define xen pv_init_ops for various xen initialization.
  ia64/pv_ops/xen: elf note based xen startup.
  ...
</content>
</entry>
<entry>
<title>always reserve elfcore header memory in crash kernel</title>
<updated>2008-10-20T15:52:40Z</updated>
<author>
<name>Simon Horman</name>
</author>
<published>2008-10-19T03:28:29Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d9a9855d0b06ca6d6cc92596fedcc03f8512e062'/>
<id>urn:sha1:d9a9855d0b06ca6d6cc92596fedcc03f8512e062</id>
<content type='text'>
elfcore header memory needs to be reserved in a crash kernel.  This means
that the relevant code should be protected by CONFIG_CRASH_DUMP rather
than CONFIG_PROC_VMCORE.

Signed-off-by: Simon Horman &lt;horms@verge.net.au&gt;
Cc: Vivek Goyal &lt;vgoyal@redhat.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>kdump: add is_vmcore_usable() and vmcore_unusable()</title>
<updated>2008-10-20T15:52:40Z</updated>
<author>
<name>Simon Horman</name>
</author>
<published>2008-10-19T03:28:29Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=85a0ee342e0c06c19d78fdf48307211c6cf18fcb'/>
<id>urn:sha1:85a0ee342e0c06c19d78fdf48307211c6cf18fcb</id>
<content type='text'>
The usage of elfcorehdr_addr has changed recently such that being set to
ELFCORE_ADDR_MAX is used by is_kdump_kernel() to indicate if the code is
executing in a kernel executed as a crash kernel.

However, arch/ia64/kernel/setup.c:reserve_elfcorehdr will rest
elfcorehdr_addr to ELFCORE_ADDR_MAX on error, which means any subsequent
calls to is_kdump_kernel() will return 0, even though they should return
1.

Ok, at this point in time there are no subsequent calls, but I think its
fair to say that there is ample scope for error or at the very least
confusion.

This patch add an extra state, ELFCORE_ADDR_ERR, which indicates that
elfcorehdr_addr was passed on the command line, and thus execution is
taking place in a crashdump kernel, but vmcore can't be used for some
reason.  This is tested for using is_vmcore_usable() and set using
vmcore_unusable().  A subsequent patch makes use of this new code.

To summarise, the states that elfcorehdr_addr can now be in are as follows:

ELFCORE_ADDR_MAX: not a crashdump kernel
ELFCORE_ADDR_ERR: crashdump kernel but vmcore is unusable
any other value:  crash dump kernel and vmcore is usable

Signed-off-by: Simon Horman &lt;horms@verge.net.au&gt;
Cc: Vivek Goyal &lt;vgoyal@redhat.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>kdump: make elfcorehdr_addr independent of CONFIG_PROC_VMCORE</title>
<updated>2008-10-20T15:52:39Z</updated>
<author>
<name>Vivek Goyal</name>
</author>
<published>2008-10-19T03:28:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=57cac4d1880527e0baf6c2fda529d2ad1d815aec'/>
<id>urn:sha1:57cac4d1880527e0baf6c2fda529d2ad1d815aec</id>
<content type='text'>
o elfcorehdr_addr is used by not only the code under CONFIG_PROC_VMCORE
  but also by the code which is not inside CONFIG_PROC_VMCORE.  For
  example, is_kdump_kernel() is used by powerpc code to determine if
  kernel is booting after a panic then use previous kernel's TCE table.
  So even if CONFIG_PROC_VMCORE is not set in second kernel, one should be
  able to correctly determine that we are booting after a panic and setup
  calgary iommu accordingly.

o So remove the assumption that elfcorehdr_addr is under
  CONFIG_PROC_VMCORE.

o Move definition of elfcorehdr_addr to arch dependent crash files.
  (Unfortunately crash dump does not have an arch independent file
  otherwise that would have been the best place).

o kexec.c is not the right place as one can Have CRASH_DUMP enabled in
  second kernel without KEXEC being enabled.

o I don't see sh setup code parsing the command line for
  elfcorehdr_addr.  I am wondering how does vmcore interface work on sh.
  Anyway, I am atleast defining elfcoredhr_addr so that compilation is not
  broken on sh.

Signed-off-by: Vivek Goyal &lt;vgoyal@redhat.com&gt;
Acked-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Acked-by: Simon Horman &lt;horms@verge.net.au&gt;
Acked-by: Paul Mundt &lt;lethal@linux-sh.org&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>[IA64] Add Variable Page Size and IA64 Support in Intel IOMMU</title>
<updated>2008-10-17T19:14:13Z</updated>
<author>
<name>Fenghua Yu</name>
</author>
<published>2008-10-17T19:14:13Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=62fdd7678a26efadd6ac5c2869543caff77d2df0'/>
<id>urn:sha1:62fdd7678a26efadd6ac5c2869543caff77d2df0</id>
<content type='text'>
The patch contains Intel IOMMU IA64 specific code. It defines new
machvec dig_vtd, hooks for IOMMU, DMAR table detection, cache line flush
function, etc.

For a generic kernel with CONFIG_DMAR=y, if Intel IOMMU is detected,
dig_vtd is used for machinve vector. Otherwise, kernel falls back to
dig machine vector. Kernel parameter "machvec=dig" or "intel_iommu=off"
can be used to force kernel to boot dig machine vector.

Signed-off-by: Fenghua Yu &lt;fenghua.yu@intel.com&gt;
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</content>
</entry>
<entry>
<title>[IA64] Ski simulator doesn't need check_sal_cache_flush</title>
<updated>2008-09-22T21:13:32Z</updated>
<author>
<name>Alex Chiang</name>
</author>
<published>2008-09-17T00:25:33Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=06f95ea8988513b172080c419e4be8826c55a318'/>
<id>urn:sha1:06f95ea8988513b172080c419e4be8826c55a318</id>
<content type='text'>
Peter Chubb reported that commit 3463a93def55c309f3c0d0a8aaf216be3be42d64
(Update check_sal_cache_flush to use platform_send_ipi()) broke
Ski because it does not implement IPIs.

Tony Luck suggested we just #ifndef out the call (since the simulator
does not have the SAL bug that this code is attempting to detect and
workaround)

Signed-off-by: Alex Chiang &lt;achiang@hp.com&gt;
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</content>
</entry>
<entry>
<title>[IA64] Ensure cpu0 can access per-cpu variables in early boot code</title>
<updated>2008-08-12T17:34:20Z</updated>
<author>
<name>Tony Luck</name>
</author>
<published>2008-08-12T17:34:20Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=10617bbe84628eb18ab5f723d3ba35005adde143'/>
<id>urn:sha1:10617bbe84628eb18ab5f723d3ba35005adde143</id>
<content type='text'>
ia64 handles per-cpu variables a litle differently from other architectures
in that it maps the physical memory allocated for each cpu at a constant
virtual address (0xffffffffffff0000). This mapping is not enabled until
the architecture specific cpu_init() function is run, which causes problems
since some generic code is run before this point. In particular when
CONFIG_PRINTK_TIME is enabled, the boot cpu will trap on the access to
per-cpu memory at the first printk() call so the boot will fail without
the kernel printing anything to the console.

Fix this by allocating percpu memory for cpu0 in the kernel data section
and doing all initialization to enable percpu access in head.S before
calling any generic code.

Other cpus must take care not to access per-cpu variables too early, but
their code path from start_secondary() to cpu_init() is all in arch/ia64

Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</content>
</entry>
<entry>
<title>[IA64] Move include/asm-ia64 to arch/ia64/include/asm</title>
<updated>2008-08-01T17:21:21Z</updated>
<author>
<name>Tony Luck</name>
</author>
<published>2008-08-01T17:13:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7f30491ccd28627742e37899453ae20e3da8e18f'/>
<id>urn:sha1:7f30491ccd28627742e37899453ae20e3da8e18f</id>
<content type='text'>
After moving the the include files there were a few clean-ups:

1) Some files used #include &lt;asm-ia64/xyz.h&gt;, changed to &lt;asm/xyz.h&gt;

2) Some comments alerted maintainers to look at various header files to
make matching updates if certain code were to be changed. Updated these
comments to use the new include paths.

3) Some header files mentioned their own names in initial comments. Just
deleted these self references.

Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</content>
</entry>
</feed>
