From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Daniel Egger <degger@fhm.edu>
Cc: Linux Mailing List Kernel <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.8 and 2.6.9 Dual Opteron glitches
Date: Tue, 2 Nov 2004 22:53:50 +0100 [thread overview]
Message-ID: <200411022253.51040.rjw@sisk.pl> (raw)
In-Reply-To: <5AC1EEB8-2CD7-11D9-BF00-000A958E35DC@fhm.edu>
Hi,
On Tuesday 02 of November 2004 14:59, Daniel Egger wrote:
> Hija,
>
> I've a few glitches with my brandnew dual Opteron System which I'd
> like to share with you. First of all, all those problems seem to
> be there with 2.6.8.1 and 2.6.9 but since this seemed to be the
> case I moved on with 2.6.9 and hadn't investigated any further
> on 2.6.8.1 so some of the issues might only apply to 2.6.9.
I'm using 2.6.10-rc1-mm2 currently, on a dual Opteron w/ Tyan Thunder K8W.
> 1) 32 bit kernel HPET calibration hang: If the kernel is compiled
> with HPET support, the kernel will hang on boot while
> calibrating the timer. The problem goes away if HPET support is
> not compiled in. I've no idea what information to provide to help
> debug this.
I can't confirm this. I've just set CONFIG_HPET and friends (except for
CONFIG_HPET_RTC_IRQ) and nothing wrong happens.
> 2) 64 bit kernel vgettimeofday panic: The kernel panics in
> arch/x64_64/vsyscall.c:169 on boot.
This does not happen on my system.
>
> static int __init vsyscall_init(void)
> {
> if ((unsigned long) &vgettimeofday !=
> VSYSCALL_ADDR(__NR_vgettimeofday))
> panic("vgettimeofday link addr broken");
>
> Replacing those panic(s) by printk make the machine boot just fine
> and also work (seemingly) without any problems under load.
>
> 3) Interrupt distribution 32 bit vs. 64 bit. Below is a copy of the
> current interrupt distribution for the 64 bit kernel which shows
> a huge shift towards CPU1. In a 32 bit kernel the distribution is
> reversed and even more visible than here since in total <100
> interupts will be handled by CPU1 after days of operation. The 64
> bit kernel has all relevant options for K8 (irq balancing,
> NUMA support, etc.) enabled.
>
> CPU0 CPU1
> 0: 15260 4196668 IO-APIC-edge timer
> 9: 0 0 IO-APIC-level acpi
> 169: 0 5 IO-APIC-level ehci_hcd
> 177: 0 3 IO-APIC-level uhci_hcd, ohci1394
> 185: 1999 934839 IO-APIC-level uhci_hcd, eth0
> NMI: 2698 2817
> LOC: 4211263 4211263
> ERR: 0
> MIS: 0
I see this effect too, but I'd attribute it to the fact that on my board the
whole I/O is attached to one of the processors (then it's CPU1, I'd bet).
> 4) ACPI powermanagement (32bit and 64bit): No matter which ACPI options
> I choose in the BIOS, ACPI will only handle the first CPU somewhat
> and leave the second CPU alone. I'd love to have some simple
> powermanagement because the system will get quite warm, even when
> idle, and warm == loud because the fans (which are barely noticeable
> when the system is cold) kick into gear quite fast.
>
> processor id: 0
> acpi id: 1
> bus mastering control: no
> power management: no
> throttling control: yes
> limit interface: yes
> active limit: P0:T0
> user limit: P0:T0
> thermal limit: P0:T0
> active state: C1
> default state: C1
> bus master activity: 00000000
> states:
> *C1: promotion[--] demotion[--] latency[000]
> usage[00000000]
> C2: <not supported>
> C3: <not supported>
> state count: 8
> active state: T0
> states:
> *T0: 00%
> T1: 12%
> T2: 25%
> T3: 37%
> T4: 50%
> T5: 62%
> T6: 75%
> T7: 87%
>
> processor id: 1
> acpi id: 2
> bus mastering control: no
> power management: no
> throttling control: no
> limit interface: no
> <not supported>
> active state: C1
> default state: C1
> bus master activity: 00000000
> states:
> *C1: promotion[--] demotion[--] latency[000]
> usage[00000000]
> C2: <not supported>
> C3: <not supported>
> <not supported>
This happens on my system too.
Greets,
RJW
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
next prev parent reply other threads:[~2004-11-02 22:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-02 13:59 Daniel Egger
2004-11-02 16:58 ` Thomas Zehetbauer
2004-11-02 17:55 ` Tomas Carnecky
2004-11-02 21:52 ` Thomas Zehetbauer
2004-11-02 22:37 ` Daniel Egger
2004-11-02 21:53 ` Rafael J. Wysocki [this message]
2004-11-06 23:06 ` Christopher E. Brown
2004-11-02 21:56 ` Jesse Pollard
[not found] <5AC1EEB8-2CD7-11D9-BF00-000A958E35DC@fhm.edu.suse.lists.linux.kernel>
2004-11-03 5:06 ` Andi Kleen
2004-11-03 10:53 ` Daniel Egger
2004-11-03 11:05 ` Andi Kleen
2004-11-03 15:06 ` Jesse Pollard
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=200411022253.51040.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=degger@fhm.edu \
--cc=linux-kernel@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
Powered by JetHome