Re: 2.6.21-rc5-mm[12]: Oops on bootup in xor_see_2
On Saturday 31 March 2007, Neil Brown wrote: > > > 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? You're right -- I'm using the current Ark Linux 2007.1 experimental build (always the latest stuff) - the update to binutils 2.17.50.0.13 broke it, after upgrading binutils to 2.17.50.0.14 everything is working perfectly again. Thanks bero - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm[12]: Oops on bootup in xor_see_2
On Saturday 31 March 2007, Neil Brown wrote: 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? You're right -- I'm using the current Ark Linux 2007.1 experimental build (always the latest stuff) - the update to binutils 2.17.50.0.13 broke it, after upgrading binutils to 2.17.50.0.14 everything is working perfectly again. Thanks bero - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm[12]: Oops on bootup in xor_see_2
On Saturday March 31, [EMAIL PROTECTED] wrote: > On Sat, 31 Mar 2007 17:36:47 + Bernhard Rosenkraenzer <[EMAIL PROTECTED]> > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm[12]: Oops on bootup in xor_see_2
On Sat, 31 Mar 2007 17:36:47 + Bernhard Rosenkraenzer <[EMAIL PROTECTED]> 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 > > BUG: unable to handle kernel NULL pointer dereference at virtual address > 0010 > printing eip: > c02cb724 > *pde= > Oops: 0002 [#1] > last sysfs file: > Modules linked in: > CPU: 0 > EIP: 0060:[] Not tainted VLI > EFLAGS: 00010212 (2.6.12-rc5-mm2) > EIP is at xor_sse_2+0x34/0x200 > eax: 0010 ebx: fffea4df ecx: df8c3000 edx: df8c > esi: 8005003b edi: c03ebce0 ebp: df8c3000 esp: dfd01ef8 > ds: 007b es: 007b fs: 00d8 gs: ss: 0068 > Process swapper (pid: 1, ti=dfd00 task=c146aa10 task:ti=dfd0 > Stack: > >c13f1800 fffea4df c02caa83 c03ebce0 df8c c011bd7b > Call Trace: > [] do_xor_speed+0x53/0xf0 > [] printk+0x1b/0x20 > [] calibrate_xor_block+0x2e/0x1b0 > [] kernel_init+0x92/0x1c0 > [] ret_from_fork+0x6/0x1c > [] kernel_init+0x0/0x1c0 > [] kernel_init+0x0/0x1c0 > [] kernel_thread_helper+0x7/0x10 > === > 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 > - 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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm[12]: Oops on bootup in xor_see_2
On Sat, 31 Mar 2007 17:36:47 + Bernhard Rosenkraenzer [EMAIL PROTECTED]
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
BUG: unable to handle kernel NULL pointer dereference at virtual address
0010
printing eip:
c02cb724
*pde=
Oops: 0002 [#1]
last sysfs file:
Modules linked in:
CPU: 0
EIP: 0060:[c02cb724] Not tainted VLI
EFLAGS: 00010212 (2.6.12-rc5-mm2)
EIP is at xor_sse_2+0x34/0x200
eax: 0010 ebx: fffea4df ecx: df8c3000 edx: df8c
esi: 8005003b edi: c03ebce0 ebp: df8c3000 esp: dfd01ef8
ds: 007b es: 007b fs: 00d8 gs: ss: 0068
Process swapper (pid: 1, ti=dfd00 task=c146aa10 task:ti=dfd0
Stack:
c13f1800 fffea4df c02caa83 c03ebce0 df8c c011bd7b
Call Trace:
[c02caa83] do_xor_speed+0x53/0xf0
[c011bd7b] printk+0x1b/0x20
[c02cac02] calibrate_xor_block+0x2e/0x1b0
[c03fe7a2] kernel_init+0x92/0x1c0
[c0103dee] ret_from_fork+0x6/0x1c
[c03fe710] kernel_init+0x0/0x1c0
[c03fe710] kernel_init+0x0/0x1c0
[c0104937] kernel_thread_helper+0x7/0x10
===
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
-
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?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm[12]: Oops on bootup in xor_see_2
On Saturday March 31, [EMAIL PROTECTED] wrote: On Sat, 31 Mar 2007 17:36:47 + Bernhard Rosenkraenzer [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
