> On Thu, 10 Feb 2005 13:47:47 +1100, Keith Owens <[EMAIL PROTECTED]> said:
Keith> The problem is that some of the dirty registers will be in
Keith> the original stack, some will be in the MCA stack.
That's OK, libunwind already handles that. The only thing that's
needed to make this wor
On Wed, 9 Feb 2005 18:26:37 -0800,
David Mosberger <[EMAIL PROTECTED]> wrote:
>> On Thu, 10 Feb 2005 12:32:53 +1100, Keith Owens <[EMAIL PROTECTED]> said:
>
> Keith> I have a long term aim to make the MCA and INIT stacks look
> Keith> like normal process stacks
>
>That would indeed simplify
> On Thu, 10 Feb 2005 12:32:53 +1100, Keith Owens <[EMAIL PROTECTED]> said:
Keith> I have a long term aim to make the MCA and INIT stacks look
Keith> like normal process stacks
That would indeed simplify life for the unwinder a bit, though it's
not strictly needed. Alternatively, it migh
I have a long term aim to make the MCA and INIT stacks look like normal
process stacks, so we can get decent backtraces for both MCA and INIT.
This includes tracing problems in the MCA/INIT C code, even if we take
an MCA in the INIT handler :). Eventually we should be able to take a
crash dump fro
> On Wed, 9 Feb 2005 17:05:52 -0800, "Luck, Tony" <[EMAIL PROTECTED]> said:
>> Am I seeing this right: the path doesn't save practically nothing
>> other than what is saved in the PAL min-state area? The path
>> presumably also ought to switch the register-backing store (I
>> think Ke
>Am I seeing this right: the path doesn't save practically nothing
>other than what is saved in the PAL min-state area? The path
>presumably also ought to switch the register-backing store (I think
>Keith alluded to this previously).
No ... we jump down to ia64_os_mca_proc_state_dump that saves a
> On Wed, 9 Feb 2005 16:44:44 -0800, "Luck, Tony" <[EMAIL PROTECTED]> said:
>> It just went bang, saying that "f6" was corrupted ... but I'm not
>> doing the right things to tickle the corner case on a regular
>> basis ... so I only have the one data point so far.
Tony> Hmmm ... I'm n
>It just went bang, saying that "f6" was corrupted ... but I'm
>not doing the right things to tickle the corner case on a regular
>basis ... so I only have the one data point so far.
Hmmm ... I'm not seeing anyplace where f6 is saved in the MCA path
before we call up to ia64_mca_ucmc_handler() ...
>Likely yes.
>That's one of two errors I see on parisc-linux when a register
>is corrupted (segfaults are the symptom). And unfortunately
>the context switching has a corner case the tickles that bug
>on a regular basis. :^(
I wrote a test program that loads up random values into registers
(just r
On Wed, Feb 09, 2005 at 04:04:14PM -0700, Alex Williamson wrote:
> On Wed, 2005-02-09 at 14:38 -0800, Ashok Raj wrote:
>
> > Could you give it a try on your systems and give an udpate.
> >
> > In the meantime, i will try to incorporate the missing pieces as another
> > update
> > to this patch.
On Wed, 2005-02-09 at 14:38 -0800, Ashok Raj wrote:
> Could you give it a try on your systems and give an udpate.
>
> In the meantime, i will try to incorporate the missing pieces as another
> update
> to this patch.
Ashok,
I'm running it in a loop (not under load) on both a zx1 and an sx100
On Wed, Feb 09, 2005 at 11:19:43AM -0700, Alex Williamson wrote:
> Hi Ashok,
>
>Sorry I missed your patch. Your assembly is certainly cleaner than
> mine. We seem to have several differences in the state that actually
> gets saved and restored though. For instance, I see you're saving k0,
>
On Wed, 09 Feb 2005 17:08:23 -0500,
Eric Desjardins <[EMAIL PROTECTED]> wrote:
>Hi,
>
>I'm not to familiar with kernel code but I'm trying to port a kernel
>driver from x86 to ia64.
>
>I was just wondering how should I translate that:
>
>static int interrupts_blocked()
>{
> unsigned long flags =
> return (flags & X86_EFLAGS_IF)
I suspect that "irqs_disabled()" does what you want (and is
portable between x86, ia64 and others).
-Tony
-
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.ker
Thanks David,
More specifically I'm concerned about ITC/TOD on MCA, PMI, PM, or such
platform behaviors.
Is there any chance that these platform behaviors affect ITC/TOD?
Spec says ITC is unchanged by [SP]AL's MCA|PMI handling and continue to
clock. Does this mean it assures no ITC drift?
If no dr
Hi,
I'm not to familiar with kernel code but I'm trying to port a kernel
driver from x86 to ia64.
I was just wondering how should I translate that:
static int interrupts_blocked()
{
unsigned long flags = 0;
> On Wed, 09 Feb 2005 12:10:13 -0800, James E Wilson <[EMAIL PROTECTED]>
> said:
Jim> It is important that the assembler give an error if a problem is
Jim> detected, as otherwise a serious latent bug may go unfixed. I we give a
Jim> warning, then people may not notice it and fix th
On Wed, 2005-02-09 at 11:35, David Mosberger wrote:
> Why should it depend on IAS as to whether GAS does or does not produce
> an error?
I was wrong about IAS giving an error in this case (.proc/.endp). I
mentioned this in an earlier mail. See Jan's response for the
clarification.
It has always
On Wed, Feb 09, 2005 at 11:35:32AM -0800, David Mosberger wrote:
> > On Mon, 07 Feb 2005 12:11:48 -0800, James E Wilson <[EMAIL PROTECTED]>
> > said:
>
> >> "The assembler ignores the name operands of the
> >> directive."
>
> Jim> I'd call this is a bug in the manual.
>
> Perhaps.
On Wed, 2005-02-09 at 11:51 -0800, Luck, Tony wrote:
> > But the BSP doesn't need to save anything. We'll always have N-1 SAL
> >states saved and N-1 CPUs that can be taken offline. As long as we
> >don't hard link a state to a specific CPU, we're in good shape. I've
> >been testing on my boxe
> On Tue, 8 Feb 2005 18:27:01 -0800, "John Lee" <[EMAIL PROTECTED]> said:
John> Maybe too broad a question but,
John> 1. What in IA64 platform contributes to ITC drift?
Are you asking when the IA64_SAL_PLATFORM_FEATURE_ITC_DRIFT bit should
be set? If so, then the answer is that it shoul
> But the BSP doesn't need to save anything. We'll always have N-1 SAL
>states saved and N-1 CPUs that can be taken offline. As long as we
>don't hard link a state to a specific CPU, we're in good shape. I've
>been testing on my boxes with an order that intentionally gives CPUs the
>state save
On Wed, 2005-02-09 at 11:26 -0800, Ashok Raj wrote:
>
> Section 3.2.4 seemed to indicate that SAL versions executing IA32 BIOS code
> would have the IA32 I/O PORT block. That prompted me to save that even though
> it was listed as scratch in the following section. (Maybe just required for
> BSP?)
> On Mon, 07 Feb 2005 12:11:48 -0800, James E Wilson <[EMAIL PROTECTED]>
> said:
>> "The assembler ignores the name operands of the
>> directive."
Jim> I'd call this is a bug in the manual.
Perhaps.
Jim> Also, I'm told that current IAS gives an error in this case, which is
Ji
On Wed, Feb 09, 2005 at 11:19:43AM -0700, Alex Williamson wrote:
> Hi Ashok,
>
>Sorry I missed your patch. Your assembly is certainly cleaner than
> mine. We seem to have several differences in the state that actually
> gets saved and restored though. For instance, I see you're saving k0,
Hi Ashok,
Sorry I missed your patch. Your assembly is certainly cleaner than
mine. We seem to have several differences in the state that actually
gets saved and restored though. For instance, I see you're saving k0,
which is listed as scratch in the spec, but none of the fp, predicate,
branc
On Wed, Feb 09, 2005 at 09:40:28AM -0800, Alex Williamson wrote:
Hi Alex
In fact i did submit a patch for this about a month ago. I was sharing some
code from mca side for tlb purge, and this code has been in the swamp for
several weeks now. I hope they are settled now, and i will re submit my
When a CPU is sent offline, it currently goes into a dummy spin loop
and pretends to be gone. This patch returns the CPU back to SAL via the
mechanism described in the SAL spec. The state of secondary CPUs is
saved off to a dynamically allocated stack for use on return to SAL.
I've munged the
On Wed, 2005-02-02 at 14:50, David Mosberger wrote:
> While I'm in favor of fixing such typos, the Itanium Assembly Language
> Reference Manual states:
The Itanium Assembly Language Reference Manual is badly out of date, and
can no longer be trusted to be accurate. It hasn't been updated since
20
Hi All,
The generic and IA-64 versions of alloc_zeroed_user_highpage() don't check the
return value from alloc_page_vma(). This can lead to an oops if we're OOM.
This fixes my oops on PPC64, but I haven't got an IA-64 machine/compiler handy.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
30 matches
Mail list logo
