All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Vitezslav Samel <samel@mail.cz>
Cc: linux-kernel@vger.kernel.org, Andi Kleen <ak@muc.de>
Subject: Re: too low MAX_MP_BUSSES
Date: Tue, 1 Aug 2006 01:38:26 -0700	[thread overview]
Message-ID: <20060801013826.09c9324d.akpm@osdl.org> (raw)
In-Reply-To: <20060731115545.GA3292@pc11.op.pod.cz>

On Mon, 31 Jul 2006 13:55:45 +0200
Vitezslav Samel <samel@mail.cz> wrote:

> 	Hi!
> 
>   I tried upgrading our server (i386 arch) from 2.6.16 to 2.6.17 but there
> were some odd messages in dmesg:
> 
> 	MP table busid value (32) for bustype ISA is too large, max. supported is 31
> 
> and (repeated 315 times):
> 
> 	unknown bus type 32
> 
> I found out that 50% of the processor time was spent in softirq and the timers
> ran too fast. I didn't look for what else was wrong.
> 
>   Tracked down to this change in 2.6.17-rc2:
> 
> diff -urN linux-2.6.17-rc1/arch/i386/kernel/mpparse.c linux-2.6.17-rc2/arch/i386/kernel/mpparse.c
> +       if (m->mpc_busid >= MAX_MP_BUSSES) {
> +               printk(KERN_WARNING "MP table busid value (%d) for bustype %s "
> +                       " is too large, max. supported is %d\n",
> +                       m->mpc_busid, str, MAX_MP_BUSSES - 1);
> +               return;
> +       }
> 
>  Uping the MAX_MP_BUSSES value in include/asm-i386/mach-default/mach_mpspec.h
> to 64 makes the machine work O.K.
> The system is HP DL380 g4 with 1 Xeon CPU, kernel compiled non-SMP.
> 
>   Here is excerpt from mptable output:
> ---
> Bus:            Bus ID  Type
>                  0       PCI
>                  1       PCI
>                  2       PCI
>                  3       PCI
>                  4       PCI
>                  5       PCI
>                  6       PCI
>                 10       PCI
>                 32       ISA
> ---
> The last item is the offending one.
> 
> Please, can you consider up the default value of MAX_MP_BUSSES?
> 
> P.S.: also tested 2.6.18-rc3, the same - bad - result
> 

mach-default uses 32 and mach-generic uses 260, so I doubt if there's a big
downside to increasing mach-default.  I expect distros ship with
mach-generic, so you're a rare case.

<tries to remember who works on this and fails>

Andi?  Can you see any problems with increasing the mach-default setting?

Thanks.

  reply	other threads:[~2006-08-01  8:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-31 11:55 too low MAX_MP_BUSSES Vitezslav Samel
2006-08-01  8:38 ` Andrew Morton [this message]
2006-08-01  8:46   ` Andi Kleen
2006-08-01  8:53     ` Andrew Morton

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=20060801013826.09c9324d.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=ak@muc.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=samel@mail.cz \
    /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.