public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Russ Anderson <rja@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: Tiger oops in ia64_sal_physical_id_info (was [RFC] regression:113134fcbca83619be4c68d0ca66db6093
Date: Wed, 27 Feb 2008 01:05:01 +0000	[thread overview]
Message-ID: <20080227010500.GC23088@sgi.com> (raw)
In-Reply-To: <200802251027.15107.bjorn.helgaas@hp.com>

On Tue, Feb 26, 2008 at 05:34:19PM -0700, Alex Chiang wrote:
> * Russ Anderson <rja@sgi.com>:
> > 
> > That causes ia64_sal_physical_id_info() to fail on my Altix.  :-(
> 
> Did it work before?

Yes.
 
> > ------------------------------------------------------------------
> > Shell> fs1:efi\suse\elilo net0:rja/vmlinux.rja.2624 root=/dev/sda8 console=ttySG0 kdb=on
> > ELILO
> > Uncompressing Linux... done
> > Initializing cgroup subsys cpuset
> > Linux version 2.6.24 (rja@attica) (gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)) #39 SMP Tue Feb 26 18:08:59 CST 2008
> > EFI v1.10 by INTEL: SALsystab=0x6002c25290 ACPI 2.0=0x6002c25b10
> > console [sn_sal0] enabled
> > ACPI: RSDP 6002C25B10, 0024 (r2    SGI)
> > ACPI: XSDT 6002C29270, 0044 (r1    SGI  XSDTSN2    10001           5C)
> > ACPI: APIC 6002C25BB0, 00D4 (r1    SGI  APICSN2    10001            1)
> > ACPI: SRAT 6002C25CA0, 0200 (r1    SGI  SRATSN2    10001            1)
> > ACPI: SLIT 6002C25EB0, 0050 (r1    SGI  SLITSN2    10001            1)
> > ACPI: FACP 6002C25F20, 00F4 (r3    SGI  FACPSN2    30001            1)
> > ACPI: DSDT 6002C28D90, 0024 (r2    SGI  DSDTSN2    20001          4C4)
> > ACPI: FACS 6002C25380, 0040
> > Number of logical nodes in system = 6
> > Number of memory chunks in system = 6
> > SAL 2.9: SGI SN2 version 1.30
> 
> I wouldn't expect SAL 2.9 to implement a call defined in SAL 3.2,
> unless I'm seriously misunderstanding something?

I will ask one of our SAL developers where the 2.9 comes from.
The 1.30 number is our SAL (prom) version.  It started at 1.00 with
SGI Altix 4700.
 
> > SAL Platform features: ITC_Drift
> > SAL: AP wakeup using external interrupt vector 0x12
> > ia64_sal_pltid failed with -1
> 
> Annoying noise, I agree with you.

More than annoying.  An indication of a problem.

> > ACPI: Local APIC address c0000000fee00000
> > register_intr: No IOSAPIC for GSI 52
> > 14 CPUs available, 14 CPUs total
> 
> More annoying noise; I thought about removing or changing that
> printk the first time around to something like KERN_INFO since
> failure of that particular SAL call doesn't really affect any
> functionality.
> 
> Opinions?
> 
> > Brought up 14 CPUs
> > Total of 14 processors activated (44793.85 BogoMIPS).
> > ------------------------------------------------------------------------------
> > 
> > 
> > saturn1-10:~ # cat /proc/cpuinfo
> > processor  : 0
> > vendor     : GenuineIntel
> > arch       : IA-64
> > family     : 32
> > model      : 1
> > model name : Dual-Core Intel(R) Itanium(R) Processor 9150M
> 
> This looks like a Montvale? That means we *should* be getting
> meaningful "physical id" information from /proc/cpuinfo. :(

Correct.  

> What values were you getting before my workaround above?

See below.

> And again, the more interesting question is, why is your SAL
> reporting a revision of 2.9?

I'll find out.  

> Thanks.
> 
> /ac
> 
> > revision   : 0
> > archrev    : 0
> > features   : branchlong, 16-byte atomic ops
> > cpu number : 0
> > cpu regs   : 4
> > cpu MHz    : 1669.503
> > itc MHz    : 416.875000
> > BogoMIPS   : 3325.95
> > siblings   : 1
-----------------------------------------------------------

Without the change:

saturn1-10:~ # cat /proc/cpuinfo
processor  : 0
vendor     : GenuineIntel
arch       : IA-64
family     : 32
model      : 1
model name : Dual-Core Intel(R) Itanium(R) Processor 9150M
revision   : 0
archrev    : 0
features   : branchlong, 16-byte atomic ops
cpu number : 0
cpu regs   : 4
cpu MHz    : 1669.000503
itc MHz    : 416.875000
BogoMIPS   : 3325.95
siblings   : 2
physical id: 0
core id    : 0
thread id  : 0

processor  : 1
vendor     : GenuineIntel
arch       : IA-64
family     : 32
model      : 1
model name : Dual-Core Intel(R) Itanium(R) Processor 9150M
revision   : 0
archrev    : 0
features   : branchlong, 16-byte atomic ops
cpu number : 0
cpu regs   : 4
cpu MHz    : 1669.000503
itc MHz    : 416.875000
BogoMIPS   : 3325.95
siblings   : 2
physical id: 0
core id    : 1
thread id  : 0



-- 
Russ Anderson, OS RAS/Partitioning Project Lead  
SGI - Silicon Graphics Inc          rja@sgi.com

  parent reply	other threads:[~2008-02-27  1:05 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-25 17:27 Tiger oops in ia64_sal_physical_id_info (was [RFC] regression: 113134fcbca83619be4c68d0ca66db609 Bjorn Helgaas
2008-02-25 23:08 ` Tiger oops in ia64_sal_physical_id_info (was [RFC] regression: Alex Chiang
2008-02-26  1:11 ` Shaohua Li
2008-02-26  7:15 ` Alex Chiang
2008-02-26  9:24 ` Tiger oops in ia64_sal_physical_id_info (was [RFC] regression:113134fcbca83619be4c68d0ca66db6093 Li, Shaohua
2008-02-26 17:51 ` Tiger oops in ia64_sal_physical_id_info (was [RFC] Alex Chiang
2008-02-26 22:45 ` Alex Chiang
2008-02-26 23:07 ` Tiger oops in ia64_sal_physical_id_info (was [RFC] regression:113134fcbca83619be4c68d0ca66db6093 Matthew Wilcox
2008-02-26 23:46 ` Russ Anderson
2008-02-26 23:50 ` Tiger oops in ia64_sal_physical_id_info (was [RFC] Alex Chiang
2008-02-27  0:00 ` Tiger oops in ia64_sal_physical_id_info (was [RFC] regression:113134fcbca83619be4c68d0ca66db6093 Matthew Wilcox
2008-02-27  0:10 ` Tiger oops in ia64_sal_physical_id_info (was [RFC] Alex Chiang
2008-02-27  0:15 ` Shaohua Li
2008-02-27  0:23 ` Tiger oops in ia64_sal_physical_id_info (was [RFC] regression:113134fcbca83619be4c68d0ca66db6093 Russ Anderson
2008-02-27  0:34 ` Tiger oops in ia64_sal_physical_id_info (was [RFC] Alex Chiang
2008-02-27  1:05 ` Russ Anderson [this message]
2008-02-27 14:38 ` Tiger oops in ia64_sal_physical_id_info (was [RFC] regression:113134fcbca83619be4c68d0ca66db6093 Luck, Tony
2008-02-27 15:19 ` Russ Anderson
2008-02-27 16:50 ` Russ Anderson
2008-02-27 23:43 ` Tiger oops in ia64_sal_physical_id_info (was [RFC] Alex Chiang
2008-02-28  0:12 ` Alex Chiang
2008-02-28  0:30 ` Tiger oops in ia64_sal_physical_id_info (was [RFC] regression:113134fcbca83619be4c68d0ca66db6093 Matthew Wilcox
2008-02-28  0:31 ` Tiger oops in ia64_sal_physical_id_info (was [RFC] Alex Chiang
2008-02-28  0:34 ` Tiger oops in ia64_sal_physical_id_info (was [RFC] regression:113134fcbca83619be4c68d0ca66db6093 Russ Anderson
2008-02-28  0:42 ` Matthew Wilcox
2008-02-28  1:41 ` Tiger oops in ia64_sal_physical_id_info (was [RFC] Alex Chiang
2008-02-28  3:47 ` Tiger oops in ia64_sal_physical_id_info (was [RFC] regression:113134fcbca83619be4c68d0ca66db6093 Russ Anderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080227010500.GC23088@sgi.com \
    --to=rja@sgi.com \
    --cc=linux-ia64@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox