From: Neil Brown <neilb@suse.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Bernhard Rosenkraenzer <bero@arklinux.org>,
linux-kernel@vger.kernel.org,
Dan Williams <dan.j.williams@intel.com>
Subject: Re: 2.6.21-rc5-mm[12]: Oops on bootup in xor_see_2
Date: Sun, 1 Apr 2007 07:46:47 +1000 [thread overview]
Message-ID: <17934.54983.192724.145829@notabene.brown> (raw)
In-Reply-To: message from Andrew Morton on Saturday March 31
On Saturday March 31, akpm@linux-foundation.org wrote:
> On Sat, 31 Mar 2007 17:36:47 +0000 Bernhard Rosenkraenzer <bero@arklinux.org> wrote:
>
> > I'm getting this Oops when booting an 2.6.21-rc5-mm1 or 2.6.21-rc5-mm2 on an
> > Acer Aspire 1501 LMi in 32 bit mode (2.6.21-rc4-mm1 + hotfixes works
> > perfectly):
> >
> > xor: automatically using best checksumming function: pIII_sse
Hmmm... I've seen that before
> > Code: 44 89 74 24 48 0f 20 c6 0f 06 0f 11 04 24 0f 11 4c 24 10 0f 11 54 24 20
> > 0f
> > 11 5c 24 30 0f 18 82 00 01 00 00 0f 18 82 20 01 00 00 <00> 00 00 00 00
> > 00
> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > -
Them bytes that look like '00' are mostly supposed to look like 'F0' -
an x86 'noop'.
Apparently a bin-utils bug. An alpha of OpenSUSE-10.3 was compiling
kernels like this. I'm told it has been fixed.
What distro/gcc version/binutils version was this compiled on?
It is possible that we should change the ".align 32" in
include/asm-i386/xor.h to ".align 32, 0xf0" or similar, but my
assembler knowledge stopped growing when it reached 6809, so I'd
rather someone who knew something about it did anything that was
required....
>
> Dan, I'm assuming your changes in there are the cause of this. AFAICT all
> you're doing is moving code around, so it's a bit odd.
>
> Bernhard, the config would be useful please.
>
> Neil, is calibrate_xor_block() being rational?
>
> b1 = (void *) __get_free_pages(GFP_KERNEL, 2);
> ...
> b2 = b1 + 2*PAGE_SIZE + BENCH_SIZE;
>
> Is it correct to add BENCH_SIZE to b2 here?
I think it is intentional. I cannot say if it is correct.
The purpose is to defeat cache effects somehow.
The result of that code together with the value of BENCH_SIZE being
PAGE_SIZE is that 4 pages are allocated, and the first and last are
used.
I have no idea how any cache would treat this, but that seems to be
the intent of the code.
NeilBrown
next prev parent reply other threads:[~2007-03-31 21:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-31 17:36 Bernhard Rosenkraenzer
2007-03-31 19:40 ` Andrew Morton
2007-03-31 21:46 ` Neil Brown [this message]
2007-04-03 11:02 ` Bernhard Rosenkraenzer
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=17934.54983.192724.145829@notabene.brown \
--to=neilb@suse.de \
--cc=akpm@linux-foundation.org \
--cc=bero@arklinux.org \
--cc=dan.j.williams@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®