Answers to select questions (that I can do off the top of my head).
> In addition, however, I do have a question. I haven't tracked every bit
> of MM code in ia64 land yet and I'm wondering how are the page table
> translations faulted in ? via a SW miss handler ? Or some HW handler ?
The page ta
Add base support for implementing platform_irq_to_vector().
Signed-off-by: Kenji Kaneshige <[EMAIL PROTECTED]>
---
arch/ia64/kernel/irq.c |5 +
include/asm-ia64/hw_irq.h |7 ++-
include/asm-ia64/machvec.h |7 +++
include/asm-ia64/machvec_init.h |1
Implement platform_irq_to_vector() for SN platform.
Signed-off-by: Kenji Kaneshige <[EMAIL PROTECTED]>
---
arch/ia64/sn/kernel/irq.c |5 +
include/asm-ia64/machvec_sn2.h |2 ++
2 files changed, 7 insertions(+)
Index: linux-2.6.23-rc1/arch/ia64/sn/kernel/irq.c
==
Hi Jes-san, Russ-san, Christoph-san and SN platform developers,
I glanced over the SN code, and I found SN platform doesn't have SN
specific irq_to_vector() function, though it has SN specific
local_vector_to_irq() function. I guess it was OK because maybe SN
platform depends on irq == vector and
CC'ing [EMAIL PROTECTED] For those who haven't followed, this
is a discussion I'm having about the rework of mmu_gather I'm in, to
making sure I do the right thing as far as ia64 is concerned.
> I suspect I just wanted to use something stable, so I wouldn't have to
> check tlb->nr. It looks like
> 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 PROTECTED]>
> commit
> I didn't really expect to see no udev messages in boot.log
> wine3:/var/log # grep udev boot.msg
> wine3:/var/log #
I see this same behaviour on x86_64 as well as ia64.
Keith
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to [EMAIL PROTECTED]
M
> With those two patches the kernel boots on SN2.
> Life is good.
Yes, I can boot on SN2 now with these two patches also. However,
I didn't really expect to see no udev messages in boot.log
wine3:/var/log # grep udev boot.msg
wine3:/var/log #
wine3:/var/log # grep udev boot.omsg
boot.udev star
Hi Linus,
please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release
This will update the files shown below.
Thanks!
-Tony
arch/ia64/ia32/sys_ia32.c |1 -
arch/ia64/kernel/iosapic.c | 19 ++-
arch/ia64/kernel/irq_ia64.c
Add additional support for CPU disable on SN platforms.
Correctly setup the smp_affinity mask for I/O error IRQs.
Restrict the use of the feature to Altix 4000 and 450 systems
running with a CPU disable capable PROM, and do not allow disabling
of CPU 0.
Signed-off-by: John Keller <[EMAIL PROTECTED
>From 497cb18db5c53eeb7e07b44d2e7ed8fff35d102f Mon Sep 17 00:00:00 2001
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Wed, 1 Aug 2007 13:49:45 -0700
Subject: [PATCH] ITC: Reduce rating for ITC clock if ITCs are drifty
Make sure to reduce the rating of the ITC clock if ITCs are drifty. If they
Christoph Lameter wrote:
>
> On Wed, 1 Aug 2007, Russ Anderson wrote:
>
> > The bad news is the kernel boot on SN2 still hangs in udevsettle.
>
> We found two problems with clocks that account for the udevsettle hang.
>
> Kenji's patch is still necessary to get rid of the spinlock problems.
Th
On Wed, 1 Aug 2007, Russ Anderson wrote:
> The bad news is the kernel boot on SN2 still hangs in udevsettle.
We found two problems with clocks that account for the udevsettle hang.
Kenji's patch is still necessary to get rid of the spinlock problems.
-
To unsubscribe from this list: send the l
>From cbddfb36b77f8c96b2d5685c898c73025bb86a90 Mon Sep 17 00:00:00 2001
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Wed, 1 Aug 2007 12:37:17 -0700
Subject: [PATCH] SN2: Fix up sn2_rtc clock
If the sn2_rtc clock is present then it is a must have since sn2_rtc
provides a synchronized time sour
Kenji Kaneshige wrote:
>
> 2007-07-31 ($B2P(B) $B$N(B 22:48 -0700 $B$K(B Christoph Lameter
> $B$5$s$O=q$-$^$7$?(B:
> > With todays git I get (sn2_defconfig w/ spinlock debuggin):
>
> (snip.)
>
> > ACPI: Error parsing MADT - no IOSAPIC entries
> > register_intr: No IOSAPIC for GSI 52
> >
On 8/1/07, Zoltan Menyhart <[EMAIL PROTECTED]> wrote:
> You do have model specific I cache semantics.
> Not taking it into account will oblige you to flush in vain for the models
> which do not require it. Why do you want to take this option?
Given unlimited resources, your proposal makes perfect
> "Kenji" == Kenji Kaneshige <[EMAIL PROTECTED]> writes:
Kenji> Hi,
Kenji> I don't know why no IOSAPIC entries was found on your system.
Kenji> But I think the cause of this stack trace is a bug in the code
Kenji> path of interrupt registering failure. Here is a patch to fix
Kenji> this bug.
2007-07-31 (火) の 22:48 -0700 に Christoph Lameter さんは書きました:
> With todays git I get (sn2_defconfig w/ spinlock debuggin):
(snip.)
> ACPI: Error parsing MADT - no IOSAPIC entries
> register_intr: No IOSAPIC for GSI 52
> BUG: spinlock bad magic on CPU#0, swapper/0
> lock: a00100bf66d0, .magic:
Luck, Tony wrote:
This seems crazy to me. Flushing should occur according to the
*architecture*, not model-by-model. Even if we happen to get "lucky"
on pre-Montecito CPUs, that doesn't justify such ugly hacks. Or you
really want to debug this *again* come next CPU?
Ditto. The only reason
Jim Hull wrote:
Not just crazy, but wrong - this *can* happen on pre-Montecito. Even though
L1D is write-through and L2 was mixed I/D, the L1 I-cache could contain
stale instrutions if there are missing flushes.
I cannot agree with you.
In order to consider an L1 I-cache entry as valid, a cor
20 matches
Mail list logo
