From: Dave Hansen <haveblue@us.ibm.com>
To: PPC64 External List <linuxppc64-dev@lists.linuxppc.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Nick Piggin <piggin@cyberone.com.au>
Subject: Oops in find_busiest_group(): 2.6.8-rc1-mm1
Date: Wed, 14 Jul 2004 23:04:50 -0700 [thread overview]
Message-ID: <1089871489.10000.388.camel@nighthawk> (raw)
Looks like 'find_busiest_group()::this' is null:
cpu 0x1: Vector: 380 (Data SLB Access) at [c0000002ffe0b420]
pc: c000000000046644: .find_busiest_group+0x24c/0x470
lr: c00000000004681c: .find_busiest_group+0x424/0x470
sp: c0000002ffe0b6a0
msr: 8000000000001032
dar: 10
current = 0xc0000002fff70da0
paca = 0xc00000000033c900
pid = 0, comm = swapper
...
1:mon> r
R00 = 0000000000000080 R16 = 0000000000000080
R01 = c0000002ffe0b6a0 R17 = 0000000000000080
R02 = c0000000004a5470 R18 = 0000000000000080
R03 = 0000000000000046 R19 = c00000000adfb408
R04 = c00000000050dd27 R20 = 0000000000000001
R05 = c00000000052dd50 R21 = 0000000000000000
R06 = c0000000003b7828 R22 = 0000000000000000
R07 = fffffffffffe0cb8 R23 = c0000002ffe0b710
R08 = c00000000050d180 R24 = c0000000004a2008
R09 = c00000000050d918 R25 = c000000000330c38
R10 = 0000000000000000 R26 = c000000000330c38
R11 = 0000000000000001 R27 = 0000000000000001
R12 = 0000000000000010 R28 = c00000000050d198
R13 = c00000000033c900 R29 = 0000000000000080
R14 = 0000000000000000 R30 = c0000000003c29e8
R15 = c000000000330c38 R31 = c0000002ffe0b6a0
pc = c000000000046644 .find_busiest_group+0x24c/0x470
lr = c00000000004681c .find_busiest_group+0x424/0x470
msr = 8000000000001032 cr = 88428428
ctr = c0000000001527a8 xer = 0000000000000000 trap = 380
I put a little printk in:
/* How much load to actually move to equalise the imbalance */
if (!busiest || !this)
printk("%s() busiest: %p this: %p\n", __func__, busiest, this);
*imbalance = (*imbalance * min(busiest->cpu_power, this->cpu_power))
/ SCHED_LOAD_SCALE;
And sure enough, this showed up on the console:
find_busiest_group() busiest: c00000000050d180 this: 0000000000000000
This code also looks funny to begin with:
> if (local_group) {
> this_load = avg_load;
> this = group;
> goto nextgroup;
> } else if (avg_load > max_load) {
> max_load = avg_load;
> busiest = group;
> }
> nextgroup:
> group = group->next;
> } while (group != sd->groups);
Why bother with the 'goto nextgroup;'? Shouldn't the first if block
just fall through to the target of the goto anyway?
-- Dave
next reply other threads:[~2004-07-15 6:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-15 6:04 Dave Hansen [this message]
2004-07-15 6:15 ` Oops in find_busiest_group(): 2.6.8-rc1-mm1 Nick Piggin
2004-07-29 6:42 ` Paul Jackson
2004-07-29 8:33 ` Nick Piggin
2004-07-29 9:29 ` Paul Jackson
2004-07-29 10:36 ` Nick Piggin
2004-07-29 12:22 ` Dave Hansen
2004-07-29 15:35 ` Dimitri Sivanich
2004-07-29 15:49 ` Jesse Barnes
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=1089871489.10000.388.camel@nighthawk \
--to=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc64-dev@lists.linuxppc.org \
--cc=piggin@cyberone.com.au \
/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.