mirror of https://lore.kernel.org/lkml/
 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 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