From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Erich Focht <efocht@ess.nec.de>, Michael Hohnbaum <hohnbaum@us.ibm.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Crunch time -- the musical. (2.5 merge candidate list 1.5)
Date: Fri, 25 Oct 2002 16:26:39 -0700 [thread overview]
Message-ID: <515310000.1035588399@flay> (raw)
In-Reply-To: <200210251015.46388.efocht@ess.nec.de>
> You're talking about one of the first 2.5 versions of the patch. It
> changed a lot since then, thanks to your feedback, too.
Right. But I've been struggling to boot anything later than that ;-)
> I thought this problem is well understood! For some reasons independent of
> my patch you have to boot your machines with the "notsc" option. This
> leaves the cache_decay_ticks variable initialized to zero which my patch
> doesn't like. I'm trying to deal with this inside the patch but there is
> still a small window when the variable is zero. In my opinion this needs
> to be fixed somewhere in arch/i386/kernel/smpboot.c. Booting a machine
> with cache_decay_ticks=0 is pure nonsense, as it switches off cache
> affinity which you absolutely need! So even if "notsc" is a legal option,
> it should be fixed such that it doesn't leave your machine without cache
> affinity. That would anyway give you a falsified behavior of the O(1)
> scheduler.
OK, well we seem to have it working on one machine, but not on another.
Those should be identical, I suspect it's a timing thing. I'm playing around
with the differences. First major thing I noticed is that the working box has
gcc 3.1, and the non-working gcc 2.95.4 (debian woody). I suspect it's
a subtle timing thing, or something equally horrible.
Changing the non-working box to gcc 3.1 instead (which I *really* don't
want to do long term unless we prove there's a bug in 2.95 ... gcc 3.x
is disgustingly slow) resulted in it getting a little further, but then got the
following oops ... does this provide any clues?
CPU 7 IS NOW UP!
Starting migration thread for cpu 7
Bringing up 8
CPU 8 IS NOW UP!
Starting migration thread for cpu 8
divide error: 0000
CPU: 4
EIP: 0060:[<c011ac38>] Not tainted
EFLAGS: 00010002
EIP is at task_to_steal+0x118/0x260
eax: 00000001 ebx: f01c5040 ecx: 00000000 edx: 00000000
esi: 00000063 edi: f01c5020 ebp: f0197ee8 esp: f0197eac
ds: 0068 es: 0068 ss: 0068
Process swapper (pid: 0, threadinfo=f0196000 task=f01bf060)
Stack: 00000000 f01b4120 00000000 c02ec940 f0197ed4 00000004 00000000 c02ecd3c
c02ec93c 00000000 00000001 0000007d c02ec4a0 00000001 00000004 f0197f1c
c011829c c02ec4a0 00000004 00000004 00000001 00000000 c39376c0 00000000
Call Trace:
[<c011829c>] load_balance+0x8c/0x140
[<c0118588>] scheduler_tick+0x238/0x360
[<c0123347>] tasklet_hi_action+0x77/0xc0
[<c0105420>] default_idle+0x0/0x50
[<c0126bd5>] update_process_times+0x45/0x60
[<c0113faa>] smp_apic_timer_interrupt+0x11a/0x120
[<c0105420>] default_idle+0x0/0x50
[<c010815e>] apic_timer_interrupt+0x1a/0x20
[<c0105420>] default_idle+0x0/0x50
[<c0105420>] default_idle+0x0/0x50
[<c010544a>] default_idle+0x2a/0x50
[<c01054ea>] cpu_idle+0x3a/0x50
[<c011db20>] printk+0x140/0x180
Code: f7 75 cc 8b 55 c8 83 f8 64 0f 4c f0 39 4d ec 8d 46 64 0f 44
This is 2.5.44-mm4 + your patches 1,2,3,5, I think.
M.
next prev parent reply other threads:[~2002-10-25 23:25 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-23 21:26 Crunch time -- the musical. (2.5 merge candidate list 1.5) Rob Landley
2002-10-24 16:17 ` Michael Hohnbaum
[not found] ` <200210240750.09751.landley@trommello.org>
2002-10-24 19:01 ` Michael Hohnbaum
2002-10-24 21:51 ` Erich Focht
2002-10-24 22:38 ` Martin J. Bligh
2002-10-25 8:15 ` Erich Focht
2002-10-25 23:26 ` Martin J. Bligh [this message]
2002-10-25 23:45 ` Martin J. Bligh
2002-10-26 0:02 ` Martin J. Bligh
2002-10-26 18:58 ` Martin J. Bligh
2002-10-26 19:14 ` NUMA scheduler (was: 2.5 " Martin J. Bligh
2002-10-27 18:16 ` Martin J. Bligh
2002-10-28 0:32 ` Erich Focht
2002-10-27 23:52 ` Martin J. Bligh
2002-10-28 0:55 ` [Lse-tech] " Michael Hohnbaum
2002-10-28 4:23 ` Martin J. Bligh
2002-10-28 0:31 ` Martin J. Bligh
2002-10-28 16:34 ` Erich Focht
2002-10-28 16:57 ` Martin J. Bligh
2002-10-28 17:26 ` Erich Focht
2002-10-28 17:35 ` Martin J. Bligh
2002-10-29 0:07 ` [Lse-tech] " Erich Focht
2002-10-28 0:46 ` Martin J. Bligh
2002-10-28 17:11 ` Erich Focht
2002-10-28 18:32 ` Martin J. Bligh
2002-10-28 17:38 ` Erich Focht
2002-10-28 17:36 ` Martin J. Bligh
2002-10-28 23:49 ` Erich Focht
2002-10-29 0:00 ` Martin J. Bligh
2002-10-29 1:12 ` Gerrit Huizenga
2002-10-29 22:39 ` Erich Focht
2002-10-28 7:16 ` Martin J. Bligh
2002-10-25 14:46 ` Crunch time -- the musical. (2.5 " Kevin Corry
-- strict thread matches above, loose matches on Subject: below --
2002-10-25 0:25 Jim Houston
2002-10-25 17:58 ` george anzinger
2002-10-25 19:58 ` Rob Landley
2002-10-26 8:45 ` george anzinger
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=515310000.1035588399@flay \
--to=mbligh@aracnet.com \
--cc=efocht@ess.nec.de \
--cc=hohnbaum@us.ibm.com \
--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.