All of lore.kernel.org
 help / color / mirror / Atom feed
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"

  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 2.6.8 and 2.6.9 Dual Opteron glitches 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.