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
next prev 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