* Re: 2.6.12-rc2-mm3
2005-04-11 8:25 2.6.12-rc2-mm3 Andrew Morton
@ 2005-04-11 8:56 ` J.A. Magallon
2005-04-11 9:43 ` 2.6.12-rc2-mm3 Andrew Morton
2005-04-11 10:34 ` 2.6.12-rc2-mm3 Jan Dittmer
` (13 subsequent siblings)
14 siblings, 1 reply; 68+ messages in thread
From: J.A. Magallon @ 2005-04-11 8:56 UTC (permalink / raw)
To: linux-kernel
On 04.11, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>
>
Is this not needed anymore ?
--- 25/arch/i386/kernel/entry.S~nmi_stack_correct-fix 2005-04-05 00:02:48.000000000 -0700
+++ 25-akpm/arch/i386/kernel/entry.S 2005-04-05 00:02:48.000000000 -0700
@@ -178,9 +178,9 @@ ENTRY(resume_kernel)
need_resched:
movl TI_flags(%ebp), %ecx # need_resched set ?
testb $_TIF_NEED_RESCHED, %cl
- jz restore_all
+ jz restore_nocheck
testl $IF_MASK,EFLAGS(%esp) # interrupts off (exception path) ?
- jz restore_all
+ jz restore_nocheck
call preempt_schedule_irq
jmp need_resched
#endif
@@ -587,7 +587,7 @@ nmi_stack_correct:
xorl %edx,%edx # zero error code
movl %esp,%eax # pt_regs pointer
call do_nmi
- jmp restore_all
+ jmp restore_nocheck
nmi_stack_fixup:
FIX_STACK(12,nmi_stack_correct, 1)
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandrakelinux release 10.2 (Limited Edition 2005) for i586
Linux 2.6.11-jam12 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk)) #1
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-11 8:56 ` 2.6.12-rc2-mm3 J.A. Magallon
@ 2005-04-11 9:43 ` Andrew Morton
2005-04-11 21:59 ` 2.6.12-rc2-mm3 Borislav Petkov
0 siblings, 1 reply; 68+ messages in thread
From: Andrew Morton @ 2005-04-11 9:43 UTC (permalink / raw)
To: J.A. Magallon; +Cc: linux-kernel
(Please do reply-to-all)
"J.A. Magallon" <jamagallon@able.es> wrote:
>
> On 04.11, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
> >
> >
>
> Is this not needed anymore ?
>
> --- 25/arch/i386/kernel/entry.S~nmi_stack_correct-fix 2005-04-05 00:02:48.000000000 -0700
> +++ 25-akpm/arch/i386/kernel/entry.S 2005-04-05 00:02:48.000000000 -0700
Hopefully not. fix-crash-in-entrys-restore_all.patch works around the problem.
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-11 9:43 ` 2.6.12-rc2-mm3 Andrew Morton
@ 2005-04-11 21:59 ` Borislav Petkov
2005-04-11 22:22 ` 2.6.12-rc2-mm3 Andrew Morton
0 siblings, 1 reply; 68+ messages in thread
From: Borislav Petkov @ 2005-04-11 21:59 UTC (permalink / raw)
To: Andrew Morton; +Cc: J.A. Magallon, linux-kernel
On Monday 11 April 2005 11:43, Andrew Morton wrote:
> (Please do reply-to-all)
>
> "J.A. Magallon" <jamagallon@able.es> wrote:
> > On 04.11, Andrew Morton wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-r
> > >c2/2.6.12-rc2-mm3/
> >
> > Is this not needed anymore ?
> >
> > --- 25/arch/i386/kernel/entry.S~nmi_stack_correct-fix 2005-04-05
> > 00:02:48.000000000 -0700 +++ 25-akpm/arch/i386/kernel/entry.S 2005-04-05
> > 00:02:48.000000000 -0700
>
> Hopefully not. fix-crash-in-entrys-restore_all.patch works around the
> problem. -
Hello Andrew,
I don't know whether you remember the mysterious crashes I was telling you
about last week and me rookiesh-ly trying to debug them with kgdb over the
serial console. Well, today I tried for the n-th time again and after rc2-mm3
blocked again while loading, here's what I did:
<snip>
[ 12.335438] NET: Registered protocol family 17
[ 12.362483] Testing NMI watchdog ... OK.
[ 12.416195] Starting balanced_irq
[ 12.443099] VFS: Mounted root (ext2 filesystem) readonly.
[ 12.472490] Freeing unused kernel memory: 196k freed
[ 12.521004] logips2pp: Detected unknown logitech mouse model 1
[ 12.572581] Warning: unable to open an initial console.
[ 12.972518] input: PS/2 Logitech Mouse on isa0060/serio1
Program received signal SIGTRAP, Trace/breakpoint trap.
0xc0102ee7 in resume_kernelX () at atomic.h:175 <--- this one is wrong for a
mysterious reason
175 {
(gdb) p $eip
$1 = (void *) 0xc0102ee7
(gdb) disas 0xc0102ee7
Dump of assembler code for function resume_kernelX:
0xc0102ee7 <resume_kernelX+0>: mov 0x30(%esp),%eax
0xc0102eeb <resume_kernelX+4>: mov 0x38(%esp),%ah
0xc0102eef <resume_kernelX+8>: mov 0x2c(%esp),%al
0xc0102ef3 <resume_kernelX+12>: and $0x20403,%eax
0xc0102ef8 <resume_kernelX+17>: cmp $0x403,%eax
0xc0102efd <resume_kernelX+22>: je 0xc0102f0c <ldt_ss>
End of assembler dump.
(gdb)
And as we see, we're at the "mov 0x30(%esp),%eax" which accesses above the
bottom of the stack. After applying nmi_stack_correct-fix.patch, rc2-mm3
booted just fine, so I IMHO think that we might still be needing this, after
all.
Regards,
Boris.
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-11 21:59 ` 2.6.12-rc2-mm3 Borislav Petkov
@ 2005-04-11 22:22 ` Andrew Morton
2005-04-12 4:20 ` 2.6.12-rc2-mm3 Stas Sergeev
0 siblings, 1 reply; 68+ messages in thread
From: Andrew Morton @ 2005-04-11 22:22 UTC (permalink / raw)
To: Borislav Petkov; +Cc: jamagallon, linux-kernel, Stas Sergeev
Borislav Petkov <petkov@uni-muenster.de> wrote:
>
> On Monday 11 April 2005 11:43, Andrew Morton wrote:
> > (Please do reply-to-all)
> >
> > "J.A. Magallon" <jamagallon@able.es> wrote:
> > > On 04.11, Andrew Morton wrote:
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-r
> > > >c2/2.6.12-rc2-mm3/
> > >
> > > Is this not needed anymore ?
> > >
> > > --- 25/arch/i386/kernel/entry.S~nmi_stack_correct-fix 2005-04-05
> > > 00:02:48.000000000 -0700 +++ 25-akpm/arch/i386/kernel/entry.S 2005-04-05
> > > 00:02:48.000000000 -0700
> >
> > Hopefully not. fix-crash-in-entrys-restore_all.patch works around the
> > problem. -
>
> Hello Andrew,
> I don't know whether you remember the mysterious crashes I was telling you
> about last week and me rookiesh-ly trying to debug them with kgdb over the
> serial console. Well, today I tried for the n-th time again and after rc2-mm3
> blocked again while loading, here's what I did:
>
> <snip>
> [ 12.335438] NET: Registered protocol family 17
> [ 12.362483] Testing NMI watchdog ... OK.
> [ 12.416195] Starting balanced_irq
> [ 12.443099] VFS: Mounted root (ext2 filesystem) readonly.
> [ 12.472490] Freeing unused kernel memory: 196k freed
> [ 12.521004] logips2pp: Detected unknown logitech mouse model 1
> [ 12.572581] Warning: unable to open an initial console.
> [ 12.972518] input: PS/2 Logitech Mouse on isa0060/serio1
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0xc0102ee7 in resume_kernelX () at atomic.h:175 <--- this one is wrong for a
> mysterious reason
> 175 {
> (gdb) p $eip
> $1 = (void *) 0xc0102ee7
>
> (gdb) disas 0xc0102ee7
> Dump of assembler code for function resume_kernelX:
> 0xc0102ee7 <resume_kernelX+0>: mov 0x30(%esp),%eax
> 0xc0102eeb <resume_kernelX+4>: mov 0x38(%esp),%ah
> 0xc0102eef <resume_kernelX+8>: mov 0x2c(%esp),%al
> 0xc0102ef3 <resume_kernelX+12>: and $0x20403,%eax
> 0xc0102ef8 <resume_kernelX+17>: cmp $0x403,%eax
> 0xc0102efd <resume_kernelX+22>: je 0xc0102f0c <ldt_ss>
> End of assembler dump.
> (gdb)
>
> And as we see, we're at the "mov 0x30(%esp),%eax" which accesses above the
> bottom of the stack. After applying nmi_stack_correct-fix.patch, rc2-mm3
> booted just fine, so I IMHO think that we might still be needing this, after
> all.
Interesting. It could be an interaction between the kgdb patch and the new
vm86 checking code. (looks. I don't think that's the case).
Stas, could you please take a look at 2.6.12-rc2-mm3's entry.S sometime,
see if you think my theory is correct?
It seems that you have CONFIG_TRAP_BAD_SYSCALL_EXITS enabled - I can't say
that I've ever used that, and I really should remove it. But I doubt if
that is the cause of this bug.
The above code is accessing esp+56, but Stas's patch only offsets the stack
pointer by 32 bytes, so I assume this, in copy_thread():
- p->thread.esp0 = (unsigned long) (childregs+1) - 8;
+ p->thread.esp0 = (unsigned long) (childregs+1) - 15;
fixes it?
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-11 22:22 ` 2.6.12-rc2-mm3 Andrew Morton
@ 2005-04-12 4:20 ` Stas Sergeev
2005-04-12 4:27 ` 2.6.12-rc2-mm3 Andrew Morton
2005-04-12 12:22 ` 2.6.12-rc2-mm3 Borislav Petkov
0 siblings, 2 replies; 68+ messages in thread
From: Stas Sergeev @ 2005-04-12 4:20 UTC (permalink / raw)
To: Andrew Morton; +Cc: Borislav Petkov, jamagallon, linux-kernel
Hello.
Andrew Morton wrote:
>> Program received signal SIGTRAP, Trace/breakpoint trap.
SIGTRAP - it looks like the "int $3"
triggered, not "mov 0x30(%esp),%eax",
which is just the next insn and so the
%eip points to it, but it might be
innocent. And besides, 0x30(%esp) is
EFLAGS, not OLDSS. So I think maybe my
patch is not guilty this time, it is
just the non-zero preempt count on the
return path caused by something else.
>> (gdb) p $eip
>> $1 = (void *) 0xc0102ee7
Could you please also do
"p $esp" or "info reg", so that we can
see the rest of the registers?
>> And as we see, we're at the "mov 0x30(%esp),%eax" which accesses above the
>> bottom of the stack.
But that's strange. Another instance of
the 0x30(%esp) is there a few instructions
above this one, see it with "disas restore_all".
It is much more likely that the real offender
is the previous instruction. $eip points on
the instruction *after* the trap, which might
be innocent.
>> After applying nmi_stack_correct-fix.patch, rc2-mm3
I can't find this one in an -mm broken-outs.
Where is this patch?
Could you please also test this one:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0504.0/1287.html
> Interesting. It could be an interaction between the kgdb patch and the new
> vm86 checking code.
I think so too, will have a look if I can
reproduce it.
> The above code is accessing esp+56,
Yes, but this particular instruction was
not reached. "int $3" killed the system
for some reasons.
> - p->thread.esp0 = (unsigned long) (childregs+1) - 8;
> + p->thread.esp0 = (unsigned long) (childregs+1) - 15;
15 is somewhat nasty - it will make the
stack unaligned, should better be 16 I
think. But I don't see why, the only
scenario we've seen were the not stored
SS/ESP, which is 8 bytes only.
If we definitely think my patch is guilty
again, then probably something like this
is necessary:
--- linux/include/asm-i386/processor.h.old 2005-03-20 14:13:02.000000000 +0300
+++ linux/include/asm-i386/processor.h 2005-04-12 07:50:11.000000000 +0400
@@ -458,7 +458,7 @@
* be within the limit.
*/
#define INIT_TSS { \
- .esp0 = sizeof(init_stack) + (long)&init_stack, \
+ .esp0 = sizeof(init_stack) - 8 + (long)&init_stack, \
.ss0 = __KERNEL_DS, \
.ss1 = __KERNEL_CS, \
.ldt = GDT_ENTRY_LDT, \
But I don't think the init_stack can be
abused on the sysenter path, so this is
just a wild guess.
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-12 4:20 ` 2.6.12-rc2-mm3 Stas Sergeev
@ 2005-04-12 4:27 ` Andrew Morton
2005-04-12 19:37 ` [patch 0/3] 2.6.12-rc2-mm3 Stas Sergeev
` (3 more replies)
2005-04-12 12:22 ` 2.6.12-rc2-mm3 Borislav Petkov
1 sibling, 4 replies; 68+ messages in thread
From: Andrew Morton @ 2005-04-12 4:27 UTC (permalink / raw)
To: Stas Sergeev; +Cc: petkov, jamagallon, linux-kernel
Stas Sergeev <stsp@aknet.ru> wrote:
>
> Hello.
>
> Andrew Morton wrote:
> >> Program received signal SIGTRAP, Trace/breakpoint trap.
> SIGTRAP - it looks like the "int $3"
> triggered, not "mov 0x30(%esp),%eax",
> which is just the next insn and so the
> %eip points to it, but it might be
> innocent. And besides, 0x30(%esp) is
> EFLAGS, not OLDSS. So I think maybe my
> patch is not guilty this time, it is
> just the non-zero preempt count on the
> return path caused by something else.
OK, the `int $3' is part of the CONFIG_TRAP_BAD_SYSCALL_EXITS thing which I
never use.
I'm not sure what problem is actually being reported here, now you mention it.
> >> (gdb) p $eip
> >> $1 = (void *) 0xc0102ee7
> Could you please also do
> "p $esp" or "info reg", so that we can
> see the rest of the registers?
>
> >> And as we see, we're at the "mov 0x30(%esp),%eax" which accesses above the
> >> bottom of the stack.
> But that's strange. Another instance of
> the 0x30(%esp) is there a few instructions
> above this one, see it with "disas restore_all".
> It is much more likely that the real offender
> is the previous instruction. $eip points on
> the instruction *after* the trap, which might
> be innocent.
Yup. But are you sure that the "+ 8" is correct, given these offsets are
larger than that?
> >> After applying nmi_stack_correct-fix.patch, rc2-mm3
> I can't find this one in an -mm broken-outs.
It was in rc2-mm2.
> Where is this patch?
> Could you please also test this one:
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0504.0/1287.html
>
> > Interesting. It could be an interaction between the kgdb patch and the new
> > vm86 checking code.
> I think so too, will have a look if I can
> reproduce it.
>
> > The above code is accessing esp+56,
> Yes, but this particular instruction was
> not reached. "int $3" killed the system
> for some reasons.
Probably it decided that some syscall got a "bad exit". Disable
CONFIG_TRAP_BAD_SYSCALL_EXITS.
> > - p->thread.esp0 = (unsigned long) (childregs+1) - 8;
> > + p->thread.esp0 = (unsigned long) (childregs+1) - 15;
> 15 is somewhat nasty - it will make the
> stack unaligned, should better be 16 I
> think.
? It's still 4-byte-aligned.
> But I don't see why, the only
> scenario we've seen were the not stored
> SS/ESP, which is 8 bytes only.
> But the
> If we definitely think my patch is guilty
> again, then probably something like this
> is necessary:
>
> --- linux/include/asm-i386/processor.h.old 2005-03-20 14:13:02.000000000 +0300
> +++ linux/include/asm-i386/processor.h 2005-04-12 07:50:11.000000000 +0400
> @@ -458,7 +458,7 @@
> * be within the limit.
> */
> #define INIT_TSS { \
> - .esp0 = sizeof(init_stack) + (long)&init_stack, \
> + .esp0 = sizeof(init_stack) - 8 + (long)&init_stack, \
> .ss0 = __KERNEL_DS, \
> .ss1 = __KERNEL_CS, \
> .ldt = GDT_ENTRY_LDT, \
>
> But I don't think the init_stack can be
> abused on the sysenter path, so this is
> just a wild guess.
I'm suspecting this is all due to CONFIG_TRAP_BAD_SYSCALL_EXITS taking the
debug trap..
^ permalink raw reply [flat|nested] 68+ messages in thread* [patch 0/3] Re: 2.6.12-rc2-mm3
2005-04-12 4:27 ` 2.6.12-rc2-mm3 Andrew Morton
@ 2005-04-12 19:37 ` Stas Sergeev
2005-04-12 19:42 ` [patch 1/3]: move config option for BAD_SYSCALL_EXIT Stas Sergeev
` (2 subsequent siblings)
3 siblings, 0 replies; 68+ messages in thread
From: Stas Sergeev @ 2005-04-12 19:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: petkov, jamagallon, linux-kernel
Hello.
Andrew Morton wrote:
> OK, the `int $3' is part of the CONFIG_TRAP_BAD_SYSCALL_EXITS thing which I
> never use.
> I'm not sure what problem is actually being reported here, now you mention it.
The problem being reported here is that
CONFIG_TRAP_BAD_SYSCALL_EXITS does nothing
but locking up your machine. Actually the
bug was so obvious, that I had real troubles
finding it (the obvious things are difficult
to spot), so I found some more bugs in a
mean time.
What was the bug? GET_THREAD_INFO(%ebp) was
missing before TI_preempt_count(%ebp), hence
the accesses beyond the stack. I'll have
troubles beleiving this code worked without
a lock-ups for someone sometimes.
I fixed it differently though. The subsequent
patches are addressing the issue.
> Yup. But are you sure that the "+ 8" is correct, given these offsets are<>
> larger than that?
I don't think they are indeed larger. The %esp
points to "struct pt_regs", which is 60 bytes
in size, and without the xss/esp = 52. Adding
8 to this gives 60, so 56(+3) looks safe to me.
> Probably it decided that some syscall got a "bad exit". Disable
> CONFIG_TRAP_BAD_SYSCALL_EXITS.
Yes, that's the fix too.
>> > - p->thread.esp0 = (unsigned long) (childregs+1) - 8;
>> > + p->thread.esp0 = (unsigned long) (childregs+1) - 15;
>> 15 is somewhat nasty - it will make the
>> stack unaligned, should better be 16 I
>> think.
> ? It's still 4-byte-aligned.
I don't see your point. Why do you think that
I substract the stack pointer by 32 bytes, for
example? I literally substract it by 8 bytes,
you propose to substract it by 15 *bytes* (not
dwords), so why would it still be aligned?
But anyway, fortunately this bug is not about
the esp0 stuff at all.
> I'm suspecting this is all due to CONFIG_TRAP_BAD_SYSCALL_EXITS taking the
> debug trap..
Sure. And that looks silly. I removed "int $3".
Patches follow. Seems to work reliable now,
but I don't know how to test it since there
seem to be no such an offending syscalls here
to test.
^ permalink raw reply [flat|nested] 68+ messages in thread* [patch 1/3]: move config option for BAD_SYSCALL_EXIT
2005-04-12 4:27 ` 2.6.12-rc2-mm3 Andrew Morton
2005-04-12 19:37 ` [patch 0/3] 2.6.12-rc2-mm3 Stas Sergeev
@ 2005-04-12 19:42 ` Stas Sergeev
2005-04-12 19:47 ` [patch 2/3]: entry.S trap return fixes Stas Sergeev
2005-04-12 19:54 ` [patch 3/3]: fix BAD_SYSCALL_EXIT lockup Stas Sergeev
3 siblings, 0 replies; 68+ messages in thread
From: Stas Sergeev @ 2005-04-12 19:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: petkov, jamagallon, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 217 bytes --]
Hello.
This patch moves the CONFIG_TRAP_BAD_SYSCALL_EXIT
from "Executable file formats" section to the
KGDB section. I had real problems finding that
option where it was.
Signed-off-by: Stas Sergeev <stsp@aknet.ru>
[-- Attachment #2: kgdbconf.diff --]
[-- Type: text/x-patch, Size: 1032 bytes --]
--- linux/arch/i386/Kconfig.old 2005-04-12 09:47:38.000000000 +0400
+++ linux/arch/i386/Kconfig 2005-04-12 09:56:48.000000000 +0400
@@ -1267,14 +1267,6 @@
source "fs/Kconfig.binfmt"
-config TRAP_BAD_SYSCALL_EXITS
- bool "Debug bad system call exits"
- depends on KGDB
- help
- If you say Y here the kernel will check for system calls which
- return without clearing preempt.
- default n
-
endmenu
source "drivers/Kconfig"
--- linux/arch/i386/Kconfig.kgdb.old 2005-04-12 09:47:38.000000000 +0400
+++ linux/arch/i386/Kconfig.kgdb 2005-04-12 09:57:11.000000000 +0400
@@ -140,6 +140,14 @@
to check for kernel stack overflow on interrupts and system
calls. This is part of the kgdb code on x86 systems.
+config TRAP_BAD_SYSCALL_EXITS
+ bool "Debug bad system call exits"
+ depends on KGDB
+ help
+ If you say Y here the kernel will check for system calls which
+ return without clearing preempt.
+ default n
+
config KGDB_CONSOLE
bool "Enable serial console thru kgdb port"
depends on KGDB
^ permalink raw reply [flat|nested] 68+ messages in thread
* [patch 2/3]: entry.S trap return fixes
2005-04-12 4:27 ` 2.6.12-rc2-mm3 Andrew Morton
2005-04-12 19:37 ` [patch 0/3] 2.6.12-rc2-mm3 Stas Sergeev
2005-04-12 19:42 ` [patch 1/3]: move config option for BAD_SYSCALL_EXIT Stas Sergeev
@ 2005-04-12 19:47 ` Stas Sergeev
2005-04-13 2:09 ` Andrew Morton
2005-04-12 19:54 ` [patch 3/3]: fix BAD_SYSCALL_EXIT lockup Stas Sergeev
3 siblings, 1 reply; 68+ messages in thread
From: Stas Sergeev @ 2005-04-12 19:47 UTC (permalink / raw)
To: Andrew Morton; +Cc: petkov, jamagallon, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 228 bytes --]
Hello.
do_debug() returns void, do_int3() too when
!CONFIG_KPROBES.
This patch fixes the CONFIG_KPROBES variant
of do_int3() to return void too and adjusts
the entry.S accordingly.
Signed-off-by: Stas Sergeev <stsp@aknet.ru>
[-- Attachment #2: kgdbfix1.diff --]
[-- Type: text/x-patch, Size: 1158 bytes --]
--- linux/arch/i386/kernel/entry.S.old 2005-04-12 09:47:38.000000000 +0400
+++ linux/arch/i386/kernel/entry.S 2005-04-12 11:13:03.000000000 +0400
@@ -550,8 +550,6 @@
xorl %edx,%edx # error code 0
movl %esp,%eax # pt_regs pointer
call do_debug
- testl %eax,%eax
- jnz restore_all
jmp ret_from_exception
/*
@@ -632,8 +630,6 @@
xorl %edx,%edx # zero error code
movl %esp,%eax # pt_regs pointer
call do_int3
- testl %eax,%eax
- jnz restore_all
jmp ret_from_exception
ENTRY(overflow)
--- linux/arch/i386/kernel/traps.c.old 2005-04-12 09:47:38.000000000 +0400
+++ linux/arch/i386/kernel/traps.c 2005-04-12 10:59:54.000000000 +0400
@@ -695,16 +695,15 @@
}
#ifdef CONFIG_KPROBES
-fastcall int do_int3(struct pt_regs *regs, long error_code)
+fastcall void do_int3(struct pt_regs *regs, long error_code)
{
if (notify_die(DIE_INT3, "int3", regs, error_code, 3, SIGTRAP)
== NOTIFY_STOP)
- return 1;
+ return;
/* This is an interrupt gate, because kprobes wants interrupts
disabled. Normal trap handlers don't. */
restore_interrupts(regs);
do_trap(3, SIGTRAP, "int3", 1, regs, error_code, NULL);
- return 0;
}
#endif
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: [patch 2/3]: entry.S trap return fixes
2005-04-12 19:47 ` [patch 2/3]: entry.S trap return fixes Stas Sergeev
@ 2005-04-13 2:09 ` Andrew Morton
2005-04-13 3:18 ` Stas Sergeev
0 siblings, 1 reply; 68+ messages in thread
From: Andrew Morton @ 2005-04-13 2:09 UTC (permalink / raw)
To: Stas Sergeev; +Cc: petkov, jamagallon, linux-kernel
Stas Sergeev <stsp@aknet.ru> wrote:
>
> do_debug() returns void, do_int3() too when
> !CONFIG_KPROBES.
> This patch fixes the CONFIG_KPROBES variant
> of do_int3() to return void too and adjusts
> the entry.S accordingly.
>
This patch is applicable to the mainline kernel, is it not?
>
>
>
> [kgdbfix1.diff text/x-patch (1297 bytes)]
> --- linux/arch/i386/kernel/entry.S.old 2005-04-12 09:47:38.000000000 +0400
> +++ linux/arch/i386/kernel/entry.S 2005-04-12 11:13:03.000000000 +0400
> @@ -550,8 +550,6 @@
> xorl %edx,%edx # error code 0
> movl %esp,%eax # pt_regs pointer
> call do_debug
> - testl %eax,%eax
> - jnz restore_all
> jmp ret_from_exception
>
> /*
> @@ -632,8 +630,6 @@
> xorl %edx,%edx # zero error code
> movl %esp,%eax # pt_regs pointer
> call do_int3
> - testl %eax,%eax
> - jnz restore_all
> jmp ret_from_exception
>
> ENTRY(overflow)
> --- linux/arch/i386/kernel/traps.c.old 2005-04-12 09:47:38.000000000 +0400
> +++ linux/arch/i386/kernel/traps.c 2005-04-12 10:59:54.000000000 +0400
> @@ -695,16 +695,15 @@
> }
>
> #ifdef CONFIG_KPROBES
> -fastcall int do_int3(struct pt_regs *regs, long error_code)
> +fastcall void do_int3(struct pt_regs *regs, long error_code)
> {
> if (notify_die(DIE_INT3, "int3", regs, error_code, 3, SIGTRAP)
> == NOTIFY_STOP)
> - return 1;
> + return;
> /* This is an interrupt gate, because kprobes wants interrupts
> disabled. Normal trap handlers don't. */
> restore_interrupts(regs);
> do_trap(3, SIGTRAP, "int3", 1, regs, error_code, NULL);
> - return 0;
> }
> #endif
^ permalink raw reply [flat|nested] 68+ messages in thread
* [patch 3/3]: fix BAD_SYSCALL_EXIT lockup
2005-04-12 4:27 ` 2.6.12-rc2-mm3 Andrew Morton
` (2 preceding siblings ...)
2005-04-12 19:47 ` [patch 2/3]: entry.S trap return fixes Stas Sergeev
@ 2005-04-12 19:54 ` Stas Sergeev
3 siblings, 0 replies; 68+ messages in thread
From: Stas Sergeev @ 2005-04-12 19:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: petkov, jamagallon, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 608 bytes --]
Hello.
CONFIG_TRAP_BAD_SYSCALL_EXITS forgets to do
GET_THREAD_INFO(%ebp) before accessing the
TI_preempt_count(%ebp). This leads to an
accesses to the random addresses and kills
the machine. Also "int $3" does nothing good
by itself (it would just Oops AFAICS). And
it is misplaced, too. Obviously it never worked.
The attached patch moves the check to the
right place (to the syscall_exit path) and
replaces the "int $3" by the call to the
helper function that only prints some debug
info and doesn't crash the system.
This fully solves the reported problem.
Signed-off-by: Stas Sergeev <stsp@aknet.ru>
[-- Attachment #2: kgdbfix2.diff --]
[-- Type: text/x-patch, Size: 1723 bytes --]
--- linux/arch/i386/kernel/entry.S 2005-04-12 09:47:38.000000000 +0400
+++ linux/arch/i386/kernel/entry.S 2005-04-12 11:51:49.000000000 +0400
@@ -253,24 +253,15 @@
cli # make sure we don't miss an interrupt
# setting need_resched or sigpending
# between sampling and the iret
+#ifdef CONFIG_TRAP_BAD_SYSCALL_EXITS
+ movl %esp, %eax # pt_regs pointer
+ call sys_call_exit
+#endif
movl TI_flags(%ebp), %ecx
testw $_TIF_ALLWORK_MASK, %cx # current->work
jne syscall_exit_work
restore_all:
-#ifdef CONFIG_TRAP_BAD_SYSCALL_EXITS
- movl EFLAGS(%esp), %eax # mix EFLAGS and CS
- movb CS(%esp), %al
- testl $(VM_MASK | 3), %eax
- jz resume_kernelX # returning to kernel or vm86-space
-
- cmpl $0,TI_preempt_count(%ebp) # non-zero preempt_count ?
- jz resume_kernelX
-
- int $3
-
-resume_kernelX:
-#endif
movl EFLAGS(%esp), %eax # mix EFLAGS, SS and CS
movb OLDSS(%esp), %ah
movb CS(%esp), %al
--- linux/arch/i386/kernel/kgdb_stub.c 2005-04-12 09:47:38.000000000 +0400
+++ linux/arch/i386/kernel/kgdb_stub.c 2005-04-12 13:23:57.000000000 +0400
@@ -2135,18 +2135,16 @@
#endif
#undef regs
#ifdef CONFIG_TRAP_BAD_SYSCALL_EXITS
-asmlinkage void
-bad_sys_call_exit(int stuff)
+fastcall void sys_call_exit(struct pt_regs *regs)
{
- struct pt_regs *regs = (struct pt_regs *) &stuff;
- printk("Sys call %d return with %x preempt_count\n",
- (int) regs->orig_eax, preempt_count());
+ if (preempt_count())
+ printk("Sys call %d return with %x preempt_count\n",
+ (int) regs->orig_eax, preempt_count());
}
#endif
#ifdef CONFIG_STACK_OVERFLOW_TEST
#include <asm/kgdb.h>
-asmlinkage void
-stack_overflow(void)
+fastcall void stack_overflow(void)
{
#ifdef BREAKPOINT
BREAKPOINT;
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-12 4:20 ` 2.6.12-rc2-mm3 Stas Sergeev
2005-04-12 4:27 ` 2.6.12-rc2-mm3 Andrew Morton
@ 2005-04-12 12:22 ` Borislav Petkov
1 sibling, 0 replies; 68+ messages in thread
From: Borislav Petkov @ 2005-04-12 12:22 UTC (permalink / raw)
To: Stas Sergeev; +Cc: Andrew Morton, jamagallon, linux-kernel
On Tuesday 12 April 2005 06:20, Stas Sergeev wrote:
Here we go again:
You might be right about the int3 instruction:
(gdb) disas 0xc0102ee0
Dump of assembler code for function restore_all:
0xc0102ed1 <restore_all+0>: mov 0x30(%esp),%eax
0xc0102ed5 <restore_all+4>: mov 0x2c(%esp),%al
0xc0102ed9 <restore_all+8>: test $0x20003,%eax
0xc0102ede <restore_all+13>: je 0xc0102ee7 <resume_kernelX>
0xc0102ee0 <restore_all+15>: cmpl $0x0,0x14(%ebp)
0xc0102ee4 <restore_all+19>: je 0xc0102ee7 <resume_kernelX>
0xc0102ee6 <restore_all+21>: int3
End of assembler dump.
> Could you please also do
> "p $esp" or "info reg", so that we can
> see the rest of the registers?
Program received signal SIGTRAP, Trace/breakpoint trap.
0xc0102ee7 in resume_kernelX () at atomic.h:175
175 {
(gdb) p $esp
$1 = (void *) 0xdfcb4fc4
(gdb) info reg
eax 0x273 627
ecx 0x0 0
edx 0x10000 65536
ebx 0xb7fd9c00 -1208116224
esp 0xdfcb4fc4 0xdfcb4fc4
ebp 0xbfbd5948 0xbfbd5948
esi 0x77 119
edi 0x1cb 459
eip 0xc0102ee7 0xc0102ee7
eflags 0x82 130
cs 0x60 96
ss 0x68 104
ds 0xc010007b -1072693125
es 0xdfcb007b -540344197
fs 0xffff 65535
gs 0xffff 65535
(gdb)
> >> And as we see, we're at the "mov 0x30(%esp),%eax" which accesses
> >> above the bottom of the stack.
>
> But that's strange. Another instance of
> the 0x30(%esp) is there a few instructions
> above this one, see it with "disas restore_all".
> It is much more likely that the real offender
> is the previous instruction. $eip points on
> the instruction *after* the trap, which might
> be innocent.
>
> >> After applying nmi_stack_correct-fix.patch, rc2-mm3
>
> I can't find this one in an -mm broken-outs.
> Where is this patch?
> Could you please also test this one:
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0504.0/1287.html
>
> > Interesting. It could be an interaction between the kgdb patch and the
> > new vm86 checking code.
>
> I think so too, will have a look if I can
> reproduce it.
>
> > The above code is accessing esp+56,
>
> Yes, but this particular instruction was
> not reached. "int $3" killed the system
> for some reasons.
>
> > - p->thread.esp0 = (unsigned long) (childregs+1) - 8;
> > + p->thread.esp0 = (unsigned long) (childregs+1) - 15;
<snip>
So, as next I'm gonna try disabling CONFIG_TRAP_BAD_SYSCALL_EXITS and see what
happens there and then the stack-aligned process.c one liner above.
/me open to testing suggestions.
Regards,
Boris.
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-11 8:25 2.6.12-rc2-mm3 Andrew Morton
2005-04-11 8:56 ` 2.6.12-rc2-mm3 J.A. Magallon
@ 2005-04-11 10:34 ` Jan Dittmer
2005-04-11 17:33 ` 2.6.12-rc2-mm3 Benoit Boissinot
` (12 subsequent siblings)
14 siblings, 0 replies; 68+ messages in thread
From: Jan Dittmer @ 2005-04-11 10:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, sfrench
Andrew Morton wrote:
> bk-cifs.patch
This breaks the build on mips, ppc64, sparc, sparc64 with the
following error (defconfig, compared to mm2):
CC [M] fs/cifs/misc.o
fs/cifs/misc.c: In function `cifs_convertUCSpath':
fs/cifs/misc.c:546: error: case label does not reduce to an integer constant
fs/cifs/misc.c:549: error: case label does not reduce to an integer constant
fs/cifs/misc.c:552: error: case label does not reduce to an integer constant
fs/cifs/misc.c:561: error: case label does not reduce to an integer constant
fs/cifs/misc.c:564: error: case label does not reduce to an integer constant
fs/cifs/misc.c:567: error: case label does not reduce to an integer constant
make[2]: *** [fs/cifs/misc.o] Error 1
make[1]: *** [fs/cifs] Error 2
make: *** [fs] Error 2
See http://l4x.org/k for details.
Jan
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-11 8:25 2.6.12-rc2-mm3 Andrew Morton
2005-04-11 8:56 ` 2.6.12-rc2-mm3 J.A. Magallon
2005-04-11 10:34 ` 2.6.12-rc2-mm3 Jan Dittmer
@ 2005-04-11 17:33 ` Benoit Boissinot
2005-04-11 19:11 ` 2.6.12-rc2-mm3 Jindrich Makovicka
` (11 subsequent siblings)
14 siblings, 0 replies; 68+ messages in thread
From: Benoit Boissinot @ 2005-04-11 17:33 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, sfrench, Jan Dittmer
On Mon, Apr 11, 2005 at 01:25:32AM -0700, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>
>
> Changes since 2.6.12-rc2-mm2:
>
>
> bk-cifs.patch
The following patch correct an error in bk-cifs:
fs/cifs/misc.c: In function ‘cifs_convertUCSpath’:
fs/cifs/misc.c:546: error: case label does not reduce to an integer constant
fs/cifs/misc.c:549: error: case label does not reduce to an integer constant
fs/cifs/misc.c:552: error: case label does not reduce to an integer constant
fs/cifs/misc.c:561: error: case label does not reduce to an integer constant
fs/cifs/misc.c:564: error: case label does not reduce to an integer constant
fs/cifs/misc.c:567: error: case label does not reduce to an integer constant
The utilisations of UNI_* constants show that it is should in cpu format:
for example line 542, src_char is converted in cpu_format:
src_char = le16_to_cpu(source[i]);
switch (src_char) {
...
case UNI_COLON:
...
or line 610, it is unlikely that you want to have cpu_to_le16(cpu_to_le16(x)):
target[j] = cpu_to_le16(UNI_COLON);
the following patch fixes it.
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
--- ./fs/cifs/misc.c.orig 2005-04-11 19:18:11.000000000 +0200
+++ ./fs/cifs/misc.c 2005-04-11 19:18:30.000000000 +0200
@@ -519,13 +519,13 @@ dump_smb(struct smb_hdr *smb_buf, int sm
/* Windows maps these to the user defined 16 bit Unicode range since they are
reserved symbols (along with \ and /), otherwise illegal to store
in filenames in NTFS */
-#define UNI_ASTERIK cpu_to_le16('*' + 0xF000)
-#define UNI_QUESTION cpu_to_le16('?' + 0xF000)
-#define UNI_COLON cpu_to_le16(':' + 0xF000)
-#define UNI_GRTRTHAN cpu_to_le16('>' + 0xF000)
-#define UNI_LESSTHAN cpu_to_le16('<' + 0xF000)
-#define UNI_PIPE cpu_to_le16('|' + 0xF000)
-#define UNI_SLASH cpu_to_le16('\\' + 0xF000)
+#define UNI_ASTERIK ('*' + 0xF000)
+#define UNI_QUESTION ('?' + 0xF000)
+#define UNI_COLON (':' + 0xF000)
+#define UNI_GRTRTHAN ('>' + 0xF000)
+#define UNI_LESSTHAN ('<' + 0xF000)
+#define UNI_PIPE ('|' + 0xF000)
+#define UNI_SLASH ('\\' + 0xF000)
/* Convert 16 bit Unicode pathname from wire format to string in current code
page. Conversion may involve remapping up the seven characters that are
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-11 8:25 2.6.12-rc2-mm3 Andrew Morton
` (2 preceding siblings ...)
2005-04-11 17:33 ` 2.6.12-rc2-mm3 Benoit Boissinot
@ 2005-04-11 19:11 ` Jindrich Makovicka
2005-04-12 0:22 ` 2.6.12-rc2-mm3 Andrew Morton
2005-04-11 20:46 ` 2.6.12-rc2-mm3 Martin J. Bligh
` (10 subsequent siblings)
14 siblings, 1 reply; 68+ messages in thread
From: Jindrich Makovicka @ 2005-04-11 19:11 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 335 bytes --]
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
MPlayer randomly crashes in various pthread_* calls when using binary
codecs. 2.6.12-rc2-mm2 was ok. I tried to reverse
fix-crash-in-entrys-restore_all.patch, but it didn't help.
.config attached.
--
Jindrich Makovicka
[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 40122 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.12-rc2-mm3
# Mon Apr 11 20:58:23 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_USE_3DNOW=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
# CONFIG_X86_MCE_P4THERMAL is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_MICROCODE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_HIGHMEM=y
CONFIG_FLATMEM=y
# CONFIG_DISCONTIGMEM is not set
# CONFIG_HIGHPTE is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_HAVE_DEC_LOCK=y
# CONFIG_REGPARM is not set
CONFIG_SECCOMP=y
#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
CONFIG_PHYSICAL_START=0x100000
# CONFIG_KEXEC is not set
#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION=""
#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_HOTKEY=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_IBM is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_X86_PM_TIMER is not set
# CONFIG_ACPI_CONTAINER is not set
#
# APM (Advanced Power Management) BIOS Support
#
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
CONFIG_APM_CPU_IDLE=y
# CONFIG_APM_DISPLAY_BLANK is not set
CONFIG_APM_RTC_IS_GMT=y
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set
#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_STAT_DETAILS=y
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_GOV_ONDEMAND is not set
#
# CPUFreq processor drivers
#
# CONFIG_X86_ACPI_CPUFREQ is not set
# CONFIG_X86_POWERNOW_K6 is not set
CONFIG_X86_POWERNOW_K7=y
CONFIG_X86_POWERNOW_K7_ACPI=y
# CONFIG_X86_POWERNOW_K8 is not set
# CONFIG_X86_GX_SUSPMOD is not set
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
# CONFIG_X86_SPEEDSTEP_ICH is not set
# CONFIG_X86_SPEEDSTEP_SMI is not set
# CONFIG_X86_P4_CLOCKMOD is not set
# CONFIG_X86_CPUFREQ_NFORCE2 is not set
# CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set
#
# shared options
#
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
# CONFIG_X86_SPEEDSTEP_LIB is not set
#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
# CONFIG_PCIEPORTBUS is not set
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
# CONFIG_PCI_DEBUG is not set
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set
#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set
#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y
#
# Networking
#
CONFIG_NET=y
#
# Networking protocols
#
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_IP_TCPDIAG=y
# CONFIG_IP_TCPDIAG_IPV6 is not set
#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
# CONFIG_IP_SCTP is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
#
# Network packet filtering
#
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_IP_NF_CONNTRACK=y
# CONFIG_IP_NF_CT_ACCT is not set
CONFIG_IP_NF_CONNTRACK_MARK=y
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IRC=y
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_PKTTYPE=y
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_DSCP=y
CONFIG_IP_NF_MATCH_AH_ESP=y
CONFIG_IP_NF_MATCH_LENGTH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_TCPMSS=y
CONFIG_IP_NF_MATCH_HELPER=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_MATCH_CONNTRACK=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_MATCH_ADDRTYPE=y
CONFIG_IP_NF_MATCH_REALM=y
CONFIG_IP_NF_MATCH_SCTP=y
CONFIG_IP_NF_MATCH_COMMENT=y
CONFIG_IP_NF_MATCH_CONNMARK=y
CONFIG_IP_NF_MATCH_HASHLIMIT=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
# CONFIG_IP_NF_NAT_SNMP_BASIC is not set
CONFIG_IP_NF_NAT_IRC=y
CONFIG_IP_NF_NAT_FTP=y
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_CLASSIFY=m
CONFIG_IP_NF_TARGET_CONNMARK=m
# CONFIG_IP_NF_TARGET_CLUSTERIP is not set
# CONFIG_IP_NF_RAW is not set
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
CONFIG_NET_CLS_ROUTE=y
# CONFIG_NET_KEY is not set
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_WAN_ROUTER is not set
#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set
#
# IrDA (infrared) subsystem support
#
CONFIG_IRDA=m
#
# IrDA protocols
#
CONFIG_IRLAN=m
CONFIG_IRNET=m
CONFIG_IRCOMM=m
# CONFIG_IRDA_ULTRA is not set
#
# IrDA options
#
CONFIG_IRDA_CACHE_LAST_LSAP=y
CONFIG_IRDA_FAST_RR=y
CONFIG_IRDA_DEBUG=y
#
# Infrared-port device drivers
#
#
# SIR device drivers
#
CONFIG_IRTTY_SIR=m
#
# Dongle support
#
# CONFIG_DONGLE is not set
#
# Old SIR device drivers
#
# CONFIG_IRPORT_SIR is not set
#
# Old Serial dongle support
#
#
# FIR device drivers
#
# CONFIG_USB_IRDA is not set
# CONFIG_SIGMATEL_FIR is not set
# CONFIG_NSC_FIR is not set
# CONFIG_WINBOND_FIR is not set
# CONFIG_TOSHIBA_FIR is not set
# CONFIG_SMC_IRCC_FIR is not set
# CONFIG_ALI_FIR is not set
# CONFIG_VLSI_FIR is not set
# CONFIG_VIA_FIR is not set
#
# Bluetooth subsystem support
#
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set
#
# Asynchronous Transfer Mode (ATM)
#
# CONFIG_ATM is not set
#
# Network testing
#
# CONFIG_NET_DIVERT is not set
# CONFIG_NET_PKTGEN is not set
# CONFIG_KGDBOE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
# CONFIG_NET_POLL_CONTROLLER is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
# CONFIG_DEBUG_DRIVER is not set
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
# CONFIG_PARPORT_SERIAL is not set
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_PC_SUPERIO=y
# CONFIG_PARPORT_GSC is not set
CONFIG_PARPORT_1284=y
#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set
#
# Protocols
#
CONFIG_ISAPNP=y
CONFIG_PNPBIOS=y
CONFIG_PNPBIOS_PROC_FS=y
# CONFIG_PNPACPI is not set
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_ATA_OVER_ETH is not set
#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_IDE_TASK_IOCTL=y
#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
CONFIG_BLK_DEV_HPT366=y
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=y
# CONFIG_IDE_ARM is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set
#
# SCSI device support
#
CONFIG_SCSI=m
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set
#
# SCSI Transport Attributes
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
CONFIG_SCSI_QLA2XXX=m
# CONFIG_SCSI_QLA21XX is not set
# CONFIG_SCSI_QLA22XX is not set
# CONFIG_SCSI_QLA2300 is not set
# CONFIG_SCSI_QLA2322 is not set
# CONFIG_SCSI_QLA6312 is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set
#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
# CONFIG_MD_RAID10 is not set
CONFIG_MD_RAID5=m
# CONFIG_MD_RAID6 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_MD_FAULTY is not set
CONFIG_BLK_DEV_DM=m
CONFIG_DM_CRYPT=m
# CONFIG_DM_SNAPSHOT is not set
# CONFIG_DM_MIRROR is not set
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set
#
# I2O device support
#
# CONFIG_I2O is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_NET_SB1000 is not set
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
CONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
CONFIG_VIA_RHINE=m
CONFIG_VIA_RHINE_MMIO=y
# CONFIG_NET_POCKET is not set
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SKGE is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=m
# CONFIG_PPP_MULTILINK is not set
# CONFIG_PPP_FILTER is not set
CONFIG_PPP_ASYNC=m
# CONFIG_PPP_SYNC_TTY is not set
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
# CONFIG_PPPOE is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=y
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=m
CONFIG_MOUSE_SERIAL=m
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA is not set
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
CONFIG_JOYSTICK_A3D=m
CONFIG_JOYSTICK_ADI=m
CONFIG_JOYSTICK_COBRA=m
CONFIG_JOYSTICK_GF2K=m
CONFIG_JOYSTICK_GRIP=m
CONFIG_JOYSTICK_GRIP_MP=m
CONFIG_JOYSTICK_GUILLEMOT=m
CONFIG_JOYSTICK_INTERACT=m
CONFIG_JOYSTICK_SIDEWINDER=m
CONFIG_JOYSTICK_TMDC=m
CONFIG_JOYSTICK_IFORCE=m
CONFIG_JOYSTICK_IFORCE_USB=y
CONFIG_JOYSTICK_IFORCE_232=y
CONFIG_JOYSTICK_WARRIOR=m
CONFIG_JOYSTICK_MAGELLAN=m
CONFIG_JOYSTICK_SPACEORB=m
CONFIG_JOYSTICK_SPACEBALL=m
CONFIG_JOYSTICK_STINGER=m
# CONFIG_JOYSTICK_TWIDJOY is not set
CONFIG_JOYSTICK_DB9=m
CONFIG_JOYSTICK_GAMECON=m
CONFIG_JOYSTICK_TURBOGRAFX=m
# CONFIG_JOYSTICK_JOYDUMP is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
CONFIG_INPUT_UINPUT=y
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
CONFIG_GAMEPORT=m
CONFIG_GAMEPORT_NS558=m
# CONFIG_GAMEPORT_L4 is not set
CONFIG_GAMEPORT_EMU10K1=m
# CONFIG_GAMEPORT_FM801 is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_CONSOLE is not set
# CONFIG_SERIAL_8250_ACPI is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_MULTIPORT is not set
# CONFIG_SERIAL_8250_RSA is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_PRINTER=y
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set
#
# Linux InfraRed Controller
#
CONFIG_LIRC_SUPPORT=m
CONFIG_LIRC_MAX_DEV=2
# CONFIG_LIRC_BT829 is not set
# CONFIG_LIRC_IT87 is not set
# CONFIG_LIRC_ATIUSB is not set
# CONFIG_LIRC_MCEUSB is not set
# CONFIG_LIRC_PARALLEL is not set
CONFIG_LIRC_SERIAL=m
CONFIG_LIRC_HOMEBREW=y
# CONFIG_LIRC_SERIAL_ANIMAX is not set
# CONFIG_LIRC_SERIAL_IRDEO is not set
# CONFIG_LIRC_SERIAL_IRDEO_REMOTE is not set
# CONFIG_LIRC_SERIAL_TRANSMITTER is not set
# CONFIG_LIRC_SERIAL_IGOR is not set
CONFIG_LIRC_SERIAL_COM1=y
# CONFIG_LIRC_SERIAL_COM2 is not set
# CONFIG_LIRC_SERIAL_COM3 is not set
# CONFIG_LIRC_SERIAL_COM4 is not set
# CONFIG_LIRC_SERIAL_OTHER is not set
CONFIG_LIRC_PORT_SERIAL=0x3f8
CONFIG_LIRC_IRQ_SERIAL=0x4
# CONFIG_LIRC_SIR is not set
#
# IPMI
#
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=m
# CONFIG_IPMI_SI is not set
# CONFIG_IPMI_WATCHDOG is not set
# CONFIG_IPMI_POWEROFF is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
CONFIG_NVRAM=y
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=m
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
CONFIG_AGP_VIA=m
# CONFIG_AGP_EFFICEON is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set
#
# TPM devices
#
# CONFIG_TCG_TPM is not set
#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set
#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_ELEKTOR is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
CONFIG_I2C_ISA=m
# CONFIG_I2C_NFORCE2 is not set
CONFIG_I2C_PARPORT=m
CONFIG_I2C_PARPORT_LIGHT=m
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set
#
# Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=m
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_VIA686A is not set
CONFIG_SENSORS_W83781D=m
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
#
# Other I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
CONFIG_SENSORS_EEPROM=m
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set
#
# Misc devices
#
# CONFIG_IBM_ASM is not set
#
# Multimedia devices
#
CONFIG_VIDEO_DEV=y
#
# Video For Linux
#
#
# Video Adapters
#
# CONFIG_VIDEO_BT848 is not set
# CONFIG_VIDEO_PMS is not set
# CONFIG_VIDEO_BWQCAM is not set
# CONFIG_VIDEO_CQCAM is not set
# CONFIG_VIDEO_W9966 is not set
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
CONFIG_VIDEO_SAA7134=m
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_CX88 is not set
# CONFIG_VIDEO_OVCAMCHIP is not set
#
# Radio Adapters
#
# CONFIG_RADIO_CADET is not set
# CONFIG_RADIO_RTRACK is not set
# CONFIG_RADIO_RTRACK2 is not set
# CONFIG_RADIO_AZTECH is not set
# CONFIG_RADIO_GEMTEK is not set
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_RADIO_SF16FMI is not set
# CONFIG_RADIO_SF16FMR2 is not set
# CONFIG_RADIO_TERRATEC is not set
# CONFIG_RADIO_TRUST is not set
# CONFIG_RADIO_TYPHOON is not set
# CONFIG_RADIO_ZOLTRIX is not set
#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
CONFIG_VIDEO_TUNER=m
CONFIG_VIDEO_BUF=m
CONFIG_VIDEO_IR=m
#
# Graphics support
#
# CONFIG_FB is not set
CONFIG_VIDEO_SELECT=y
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
#
# Sound
#
CONFIG_SOUND=y
#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
#
# Generic devices
#
CONFIG_SND_MPU401_UART=m
CONFIG_SND_DUMMY=m
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
CONFIG_SND_MPU401=m
#
# ISA devices
#
# CONFIG_SND_AD1816A is not set
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES968 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_WAVEFRONT is not set
# CONFIG_SND_ALS100 is not set
# CONFIG_SND_AZT2320 is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_DT019X is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set
#
# PCI devices
#
CONFIG_SND_AC97_CODEC=m
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS4281 is not set
CONFIG_SND_EMU10K1=m
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_SONICVIBES is not set
CONFIG_SND_VIA82XX=m
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_HDA_INTEL is not set
#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set
#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set
#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
# CONFIG_USB_EHCI_SPLIT_ISO is not set
CONFIG_USB_EHCI_ROOT_HUB_TT=y
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=m
# CONFIG_USB_SL811_HCD is not set
#
# USB Device Class drivers
#
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH_TTY is not set
# CONFIG_USB_MIDI is not set
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=m
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
#
# USB Input Devices
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
# CONFIG_HID_FF is not set
CONFIG_USB_HIDDEV=y
#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_MTOUCH is not set
# CONFIG_USB_ITMTOUCH is not set
# CONFIG_USB_EGALAX is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set
# CONFIG_USB_VICAM is not set
# CONFIG_USB_DSBR is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_KONICAWC is not set
# CONFIG_USB_OV511 is not set
# CONFIG_USB_SE401 is not set
# CONFIG_USB_SN9C102 is not set
# CONFIG_USB_STV680 is not set
# CONFIG_USB_PWC is not set
#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
CONFIG_USB_MON=m
#
# USB port drivers
#
# CONFIG_USB_USS720 is not set
#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
# CONFIG_USB_SERIAL_GENERIC is not set
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_CP2101 is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
CONFIG_USB_SERIAL_VISOR=m
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_GARMIN is not set
# CONFIG_USB_SERIAL_IPW is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_TI is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OMNINET is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGETKIT is not set
# CONFIG_USB_PHIDGETSERVO is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_TEST is not set
#
# USB ATM/DSL drivers
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
#
# MMC/SD Card support
#
# CONFIG_MMC is not set
#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set
#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
CONFIG_EXT3_FS=m
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_JBD=m
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISER4_FS=y
# CONFIG_REISER4_DEBUG is not set
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_REISERFS_FS_XATTR is not set
CONFIG_JFS_FS=m
# CONFIG_JFS_POSIX_ACL is not set
# CONFIG_JFS_SECURITY is not set
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not set
#
# XFS support
#
CONFIG_XFS_FS=m
# CONFIG_XFS_RT is not set
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_SECURITY is not set
# CONFIG_XFS_POSIX_ACL is not set
CONFIG_MINIX_FS=m
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
#
# Caches
#
# CONFIG_FSCACHE is not set
# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=852
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-2"
CONFIG_NTFS_FS=y
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# CONFIG_RELAYFS_FS is not set
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=y
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
CONFIG_SMB_FS=y
# CONFIG_SMB_NLS_DEFAULT is not set
# CONFIG_CIFS is not set
CONFIG_NCP_FS=y
# CONFIG_NCPFS_PACKET_SIGNING is not set
# CONFIG_NCPFS_IOCTL_LOCKING is not set
CONFIG_NCPFS_STRONG=y
CONFIG_NCPFS_NFS_NS=y
CONFIG_NCPFS_OS2_NS=y
CONFIG_NCPFS_SMALLDOS=y
CONFIG_NCPFS_NLS=y
CONFIG_NCPFS_EXTRAS=y
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="cp437"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
CONFIG_NLS_CODEPAGE_852=y
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
CONFIG_NLS_CODEPAGE_1250=y
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_2=y
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y
#
# Profiling support
#
# CONFIG_PROFILING is not set
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_DETECT_SOFTLOCKUP is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_PAGE_OWNER is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_FRAME_POINTER is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
#
# Page alloc debug is incompatible with Software Suspend on i386
#
# CONFIG_4KSTACKS is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
# CONFIG_KGDB is not set
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
CONFIG_CRYPTO_WP512=y
CONFIG_CRYPTO_TGR192=y
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_AES_586=y
CONFIG_CRYPTO_CAST5=y
CONFIG_CRYPTO_CAST6=y
CONFIG_CRYPTO_TEA=y
CONFIG_CRYPTO_ARC4=y
CONFIG_CRYPTO_KHAZAD=y
CONFIG_CRYPTO_ANUBIS=y
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_MICHAEL_MIC=y
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_TEST is not set
#
# Hardware crypto devices
#
# CONFIG_CRYPTO_DEV_PADLOCK is not set
#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=m
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-11 8:25 2.6.12-rc2-mm3 Andrew Morton
` (3 preceding siblings ...)
2005-04-11 19:11 ` 2.6.12-rc2-mm3 Jindrich Makovicka
@ 2005-04-11 20:46 ` Martin J. Bligh
2005-04-11 22:24 ` 2.6.12-rc2-mm3 Benoit Boissinot
2005-04-11 21:05 ` 2.6.12-rc2-mm3: CONFIG_MODULES=n MTD compile error Adrian Bunk
` (9 subsequent siblings)
14 siblings, 1 reply; 68+ messages in thread
From: Martin J. Bligh @ 2005-04-11 20:46 UTC (permalink / raw)
To: Andrew Morton, linux-kernel
--On Monday, April 11, 2005 01:25:32 -0700 Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>
>
> - The anticipatory I/O scheduler has always been fairly useless with SCSI
> disks which perform tagged command queueing. There's a patch here from Jens
> which is designed to fix that up by constraining the number of requests
> which we'll leave pending in the device.
>
> The depth currently defaults to 1. Tunable in
> /sys/block/hdX/queue/iosched/queue_depth
>
> This patch hasn't been performance tested at all yet. If you think it is
> misbehaving (the usual symptom is processes stuck in D state) then please
> report it, then boot with `elevator=cfq' or `elevator=deadline' to work
> around it.
>
> - More CPU scheduler work. I hope someone is testing this stuff.
Trying ... having some build problems that seem to be part test-harness,
part bugs.
Meanwhile on PPC64:
fs/cifs/misc.c: In function `cifs_convertUCSpath':
fs/cifs/misc.c:546: error: case label does not reduce to an integer constant
fs/cifs/misc.c:549: error: case label does not reduce to an integer constant
fs/cifs/misc.c:552: error: case label does not reduce to an integer constant
fs/cifs/misc.c:561: error: case label does not reduce to an integer constant
fs/cifs/misc.c:564: error: case label does not reduce to an integer constant
fs/cifs/misc.c:567: error: case label does not reduce to an integer constant
make[2]: *** [fs/cifs/misc.o] Error 1
make[1]: *** [fs/cifs] Error 2
make[1]: *** Waiting for unfinished jobs....
M.
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-11 20:46 ` 2.6.12-rc2-mm3 Martin J. Bligh
@ 2005-04-11 22:24 ` Benoit Boissinot
2005-04-12 22:32 ` 2.6.12-rc2-mm3 Martin J. Bligh
0 siblings, 1 reply; 68+ messages in thread
From: Benoit Boissinot @ 2005-04-11 22:24 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Andrew Morton, linux-kernel
On Apr 11, 2005 10:46 PM, Martin J. Bligh <mbligh@aracnet.com> wrote:
>
>
> --On Monday, April 11, 2005 01:25:32 -0700 Andrew Morton <akpm@osdl.org> wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
> >
> >
> > - The anticipatory I/O scheduler has always been fairly useless with SCSI
> > disks which perform tagged command queueing. There's a patch here from Jens
> > which is designed to fix that up by constraining the number of requests
> > which we'll leave pending in the device.
> >
> > The depth currently defaults to 1. Tunable in
> > /sys/block/hdX/queue/iosched/queue_depth
> >
> > This patch hasn't been performance tested at all yet. If you think it is
> > misbehaving (the usual symptom is processes stuck in D state) then please
> > report it, then boot with `elevator=cfq' or `elevator=deadline' to work
> > around it.
> >
> > - More CPU scheduler work. I hope someone is testing this stuff.
>
> Trying ... having some build problems that seem to be part test-harness,
> part bugs.
>
> Meanwhile on PPC64:
>
> fs/cifs/misc.c: In function `cifs_convertUCSpath':
> fs/cifs/misc.c:546: error: case label does not reduce to an integer constant
> fs/cifs/misc.c:549: error: case label does not reduce to an integer constant
> fs/cifs/misc.c:552: error: case label does not reduce to an integer constant
> fs/cifs/misc.c:561: error: case label does not reduce to an integer constant
> fs/cifs/misc.c:564: error: case label does not reduce to an integer constant
> fs/cifs/misc.c:567: error: case label does not reduce to an integer constant
> make[2]: *** [fs/cifs/misc.o] Error 1
> make[1]: *** [fs/cifs] Error 2
> make[1]: *** Waiting for unfinished jobs....
>
>
See this patch from Steve French:
http://cifs.bkbits.net:8080/linux-2.5cifs/gnupatch@4259f2138nVCJQt3SmaZowdXd8KB7A
> M.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 68+ messages in thread
* 2.6.12-rc2-mm3: CONFIG_MODULES=n MTD compile error
2005-04-11 8:25 2.6.12-rc2-mm3 Andrew Morton
` (4 preceding siblings ...)
2005-04-11 20:46 ` 2.6.12-rc2-mm3 Martin J. Bligh
@ 2005-04-11 21:05 ` Adrian Bunk
2005-04-12 1:18 ` 2.6.12-rc2-mm3 Juergen Kreileder
` (8 subsequent siblings)
14 siblings, 0 replies; 68+ messages in thread
From: Adrian Bunk @ 2005-04-11 21:05 UTC (permalink / raw)
To: Andrew Morton, Rusty Russell; +Cc: linux-kernel, dwmw2, linux-mtd
On Mon, Apr 11, 2005 at 01:25:32AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.12-rc2-mm2:
>...
> +remove-inter-module-mtd.patch
>
> Remove intermodule_foo() usage from mtd.
>...
This breaks the compilation with CONFIG_MODULES=n:
<-- snip -->
...
CC drivers/mtd/devices/docprobe.o
drivers/mtd/devices/docprobe.c: In function `DoC_Probe':
drivers/mtd/devices/docprobe.c:311: warning: implicit declaration of
function `__symbol_get'
drivers/mtd/devices/docprobe.c:311: warning: assignment makes pointer
from integer without a cast
drivers/mtd/devices/docprobe.c:315: warning: implicit declaration of function `__symbol_put'
...
LD .tmp_vmlinux1
drivers/built-in.o(.init.text+0x60f20): In function `DoC_Probe':
: undefined reference to `__symbol_get'
drivers/built-in.o(.init.text+0x60f3b): In function `DoC_Probe':
: undefined reference to `__symbol_put'
drivers/built-in.o(.init.text+0x610a4): In function `DoC_Probe':
: undefined reference to `__symbol_get'
make: *** [.tmp_vmlinux1] Error 1
<-- snip -->
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-11 8:25 2.6.12-rc2-mm3 Andrew Morton
` (5 preceding siblings ...)
2005-04-11 21:05 ` 2.6.12-rc2-mm3: CONFIG_MODULES=n MTD compile error Adrian Bunk
@ 2005-04-12 1:18 ` Juergen Kreileder
2005-04-12 2:09 ` 2.6.12-rc2-mm3 Benjamin Herrenschmidt
` (2 more replies)
2005-04-12 5:00 ` 2.6.12-rc2-mm3 Andrew Morton
` (7 subsequent siblings)
14 siblings, 3 replies; 68+ messages in thread
From: Juergen Kreileder @ 2005-04-12 1:18 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 602 bytes --]
Andrew Morton <akpm@osdl.org> writes:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
2.6.11-mm4 works fine but all 2.6.12 versions I've tried (all since
-rc1-mm3) lock up randomly. The easiest way to reproduce the problem
seems to be running Azareus. So it might be network related, but I'm
not 100% sure about that, there was a least one deadlock with
virtually no network usage.
BTW, what's the SysRq key on recent Apple USB keyboards? Alt/Cmd-F13
doesn't work for me.
Juergen
[-- Attachment #2: config-2.6.12-rc2-mm3 --]
[-- Type: text/plain, Size: 5905 bytes --]
CONFIG_64BIT=y
CONFIG_MMU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_EARLY_PRINTK=y
CONFIG_COMPAT=y
CONFIG_FORCE_MAX_ZONEORDER=13
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_KALLSYMS=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_PPC_MULTIPLATFORM=y
CONFIG_PPC_PMAC=y
CONFIG_PPC=y
CONFIG_PPC64=y
CONFIG_PPC_OF=y
CONFIG_ALTIVEC=y
CONFIG_U3_DART=y
CONFIG_PPC_PMAC64=y
CONFIG_BOOTX_TEXT=y
CONFIG_POWER4_ONLY=y
CONFIG_IOMMU_VMERGE=y
CONFIG_SMP=y
CONFIG_NR_CPUS=2
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_FLATMEM=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_SECCOMP=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_PCI_NAMES=y
CONFIG_PROC_DEVICETREE=y
CONFIG_NET=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_SYN_COOKIES=y
CONFIG_IP_TCPDIAG=y
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_HCIUSB=m
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CDROM_PKTCDVD=y
CONFIG_CDROM_PKTCDVD_BUFFERS=8
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_IDE_TASK_IOCTL=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDE_PMAC=y
CONFIG_BLK_DEV_IDE_PMAC_ATA100FIRST=y
CONFIG_BLK_DEV_IDEDMA_PMAC=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_SCSI=y
CONFIG_SCSI_PROC_FS=y
CONFIG_BLK_DEV_SD=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SATA=y
CONFIG_SCSI_SATA_SVW=y
CONFIG_SCSI_QLA2XXX=y
CONFIG_MD=y
CONFIG_BLK_DEV_DM=y
CONFIG_DM_CRYPT=y
CONFIG_DM_SNAPSHOT=y
CONFIG_DM_MIRROR=y
CONFIG_DM_ZERO=y
CONFIG_ADB_PMU=y
CONFIG_THERM_PM72=y
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_SUNGEM=y
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1600
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1200
CONFIG_INPUT_EVDEV=m
CONFIG_INPUT_KEYBOARD=y
CONFIG_INPUT_MOUSE=y
CONFIG_INPUT_MISC=y
CONFIG_INPUT_UINPUT=m
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_RTC=y
CONFIG_AGP=y
CONFIG_AGP_UNINORTH=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_KEYWEST=y
CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_SOFT_CURSOR=y
CONFIG_FB_MACMODES=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_OF=y
CONFIG_FB_RADEON=y
CONFIG_FB_RADEON_I2C=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_SOUND=m
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
CONFIG_SND_POWERMAC=m
CONFIG_SND_USB_AUDIO=m
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_BANDWIDTH=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_STORAGE=m
CONFIG_USB_HID=y
CONFIG_USB_HIDINPUT=y
CONFIG_USB_HIDDEV=y
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_JBD=y
CONFIG_FS_MBCACHE=y
CONFIG_FS_POSIX_ACL=y
CONFIG_INOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_FUSE_FS=m
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=850
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_DEVPTS_FS_XATTR=y
CONFIG_TMPFS=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y
CONFIG_RELAYFS_FS=m
CONFIG_HFS_FS=y
CONFIG_HFSPLUS_FS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V4=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_RPCSEC_GSS_SPKM3=m
CONFIG_PARTITION_ADVANCED=y
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_UTF8=y
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_IRQSTACKS=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
CONFIG_CRYPTO_WP512=y
CONFIG_CRYPTO_TGR192=y
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_CAST5=y
CONFIG_CRYPTO_CAST6=y
CONFIG_CRYPTO_TEA=y
CONFIG_CRYPTO_ARC4=y
CONFIG_CRYPTO_KHAZAD=y
CONFIG_CRYPTO_ANUBIS=y
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_MICHAEL_MIC=y
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRC32=y
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
[-- Attachment #3: Type: text/plain, Size: 76 bytes --]
--
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-12 1:18 ` 2.6.12-rc2-mm3 Juergen Kreileder
@ 2005-04-12 2:09 ` Benjamin Herrenschmidt
2005-04-12 3:26 ` 2.6.12-rc2-mm3 Benjamin Herrenschmidt
2005-04-15 18:23 ` 2.6.12-rc2-mm3 Juergen Kreileder
2 siblings, 0 replies; 68+ messages in thread
From: Benjamin Herrenschmidt @ 2005-04-12 2:09 UTC (permalink / raw)
To: Juergen Kreileder; +Cc: Andrew Morton, Linux Kernel list
On Tue, 2005-04-12 at 03:18 +0200, Juergen Kreileder wrote:
> Andrew Morton <akpm@osdl.org> writes:
>
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>
> I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
>
> 2.6.11-mm4 works fine but all 2.6.12 versions I've tried (all since
> -rc1-mm3) lock up randomly. The easiest way to reproduce the problem
> seems to be running Azareus. So it might be network related, but I'm
> not 100% sure about that, there was a least one deadlock with
> virtually no network usage.
>
> BTW, what's the SysRq key on recent Apple USB keyboards? Alt/Cmd-F13
> doesn't work for me.
No idea about sysrq, i don't use it. However, I haven't experienced any
such problem with the various G5s we have here (and no other G5 user
reported such a problem).
So it would be useful if you could provide a bit more informations here
though. For example, what exact G5 model is this, do you have any 3rd
party PCI card, what video card are you using, can you reproduce the
crash in console mode, that sort of thing ...
Also, did you run a memtest equivalent on the machine ?
Finally, it would be useful if you could point out which specific patch
or bk snapshot, or at least -mm rev. introduced the bug. As I said
previously, you are the only one to report that and none of the G5s here
is showing such a problem.
Ben.
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-12 1:18 ` 2.6.12-rc2-mm3 Juergen Kreileder
2005-04-12 2:09 ` 2.6.12-rc2-mm3 Benjamin Herrenschmidt
@ 2005-04-12 3:26 ` Benjamin Herrenschmidt
2005-04-12 4:42 ` 2.6.12-rc2-mm3 Juergen Kreileder
2005-04-15 18:23 ` 2.6.12-rc2-mm3 Juergen Kreileder
2 siblings, 1 reply; 68+ messages in thread
From: Benjamin Herrenschmidt @ 2005-04-12 3:26 UTC (permalink / raw)
To: Juergen Kreileder; +Cc: Andrew Morton, Linux Kernel list
On Tue, 2005-04-12 at 03:18 +0200, Juergen Kreileder wrote:
> Andrew Morton <akpm@osdl.org> writes:
>
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>
> I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
>
> 2.6.11-mm4 works fine but all 2.6.12 versions I've tried (all since
> -rc1-mm3) lock up randomly. The easiest way to reproduce the problem
> seems to be running Azareus. So it might be network related, but I'm
> not 100% sure about that, there was a least one deadlock with
> virtually no network usage.
>
> BTW, what's the SysRq key on recent Apple USB keyboards? Alt/Cmd-F13
> doesn't work for me.
>
Hrm... I just noticed you have CONFIG_PREEMPT enabled... Can you test
without it and let me know if it makes a difference ?
Ben.
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-12 3:26 ` 2.6.12-rc2-mm3 Benjamin Herrenschmidt
@ 2005-04-12 4:42 ` Juergen Kreileder
2005-04-12 6:34 ` 2.6.12-rc2-mm3 Benjamin Herrenschmidt
0 siblings, 1 reply; 68+ messages in thread
From: Juergen Kreileder @ 2005-04-12 4:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Andrew Morton, Linux Kernel list
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Tue, 2005-04-12 at 03:18 +0200, Juergen Kreileder wrote:
>> Andrew Morton <akpm@osdl.org> writes:
>>
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>>
>> I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
>>
>> 2.6.11-mm4 works fine but all 2.6.12 versions I've tried (all since
>> -rc1-mm3) lock up randomly. The easiest way to reproduce the
>> problem seems to be running Azareus. So it might be network
>> related, but I'm not 100% sure about that, there was a least one
>> deadlock with virtually no network usage.
>
> Hrm... I just noticed you have CONFIG_PREEMPT enabled... Can you
> test without it and let me know if it makes a difference ?
IIRC I had disabled that for rc2-mm2 and it didn't make a difference.
I'll disable it again when I try older versions.
I just got another crash with rc2-mm3. The crash was a bit different
this time, I still could move the mouse pointer and the logs contained
some info:
Badness in slb_flush_and_rebolt at arch/ppc64/mm/slb.c:52
[c00000017690b860] [0000000000069a73] 0x69a73 (unreliable)
[c00000017690b900] [c00000000003b300] .__schedule_tail+0x9c/0x1b4
[c00000017690b9a0] [c0000000003162b0] .schedule+0x324/0x610
[c00000017690ba80] [c0000000003177e8] .schedule_timeout+0xfc/0x104
[c00000017690bb60] [c0000000000b6118] .do_select+0x278/0x4c4
[c00000017690bcb0] [c0000000000d6f4c] .compat_sys_select+0x390/0x690
[c00000017690bdc0] [c000000000019eb8] .ppc32_select+0x14/0x28
[c00000017690be30] [c00000000000da00] syscall_exit+0x0/0x18
Badness in slb_flush_and_rebolt at arch/ppc64/mm/slb.c:52
Call Trace:
[c00000016fe23860] [0000000000000413] 0x413 (unreliable)
[c00000016fe23900] [c00000000003b300] .__schedule_tail+0x9c/0x1b4
[c00000016fe239a0] [c0000000003162b0] .schedule+0x324/0x610
[c00000016fe23a80] [c000000000317774] .schedule_timeout+0x88/0x104
[c00000016fe23b60] [c0000000000b6118] .do_select+0x278/0x4c4
[c00000016fe23cb0] [c0000000000d6f4c] .compat_sys_select+0x390/0x690
[c00000016fe23dc0] [c000000000019eb8] .ppc32_select+0x14/0x28
[c00000016fe23e30] [c00000000000da00] syscall_exit+0x0/0x18
Badness in slb_flush_and_rebolt at arch/ppc64/mm/slb.c:52
Call Trace:
[c000000175d2b860] [0000000000000163] 0x163 (unreliable)
[c000000175d2b900] [c00000000003b300] .__schedule_tail+0x9c/0x1b4
[c000000175d2b9a0] [c0000000003162b0] .schedule+0x324/0x610
[c000000175d2ba80] [c000000000317774] .schedule_timeout+0x88/0x104
[c000000175d2bb60] [c0000000000b6118] .do_select+0x278/0x4c4
[c000000175d2bcb0] [c0000000000d6f4c] .compat_sys_select+0x390/0x690
[c000000175d2bdc0] [c000000000019eb8] .ppc32_select+0x14/0x28
[c000000175d2be30] [c00000000000da00] syscall_exit+0x0/0x18
Badness in slb_flush_and_rebolt at arch/ppc64/mm/slb.c:52
Call Trace:
[c000000178a17860] [0000000000000eb1] 0xeb1 (unreliable)
[c000000178a17900] [c00000000003b300] .__schedule_tail+0x9c/0x1b4
[c000000178a179a0] [c0000000003162b0] .schedule+0x324/0x610
[c000000178a17a80] [c000000000317774] .schedule_timeout+0x88/0x104
[c000000178a17b60] [c0000000000b6118] .do_select+0x278/0x4c4
[c000000178a17cb0] [c0000000000d6f4c] .compat_sys_select+0x390/0x690
[c000000178a17dc0] [c000000000019eb8] .ppc32_select+0x14/0x28
[c000000178a17e30] [c00000000000da00] syscall_exit+0x0/0x18
Badness in slb_flush_and_rebolt at arch/ppc64/mm/slb.c:52
Call Trace:
[c0000001767fba10] [0000000000001bca] 0x1bca (unreliable)
and so on until the machine switched into jet-fighter mode after:
[c00000016f887a10] [000000000001fc8c] 0x1fc8c (unreliable)
[c00000016f887ab0] [c00000000003b300] .__schedule_tail+0x9c/0x1b4
[c00000016f887b50] [c0000000003162b0] .schedule+0x324/0x610
[c00000016f887c30] [c000000000317774] .schedule_timeout+0x88/0x104
[c00000016f887d10] [c0000000000b6bb4] .sys_poll+0x3b8/0x4dc
[c00000016f887e30] [c00000000000da00] syscall_exit+0x0/0x18
Oops: Machine check, sig: 0 [#1]
Machine info:
* PowerMac7,2 with 2x 2GHz
* 4GB RAM
* 2 disks with ext3 partitions on top of LVM2
* Radeon 9800Pro with radeonfb and X (from Debian sid) at 1600x1200
* USB Mouse via evdev
* Bluetooth enabled but unused
* Firewire disabled
* No PCI cards
* Kernel compiled with gcc-3.4.2
Juergen
--
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-12 4:42 ` 2.6.12-rc2-mm3 Juergen Kreileder
@ 2005-04-12 6:34 ` Benjamin Herrenschmidt
2005-04-12 18:08 ` 2.6.12-rc2-mm3 Juergen Kreileder
0 siblings, 1 reply; 68+ messages in thread
From: Benjamin Herrenschmidt @ 2005-04-12 6:34 UTC (permalink / raw)
To: Juergen Kreileder; +Cc: Andrew Morton, Linux Kernel list
On Tue, 2005-04-12 at 06:42 +0200, Juergen Kreileder wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> > On Tue, 2005-04-12 at 03:18 +0200, Juergen Kreileder wrote:
> >> Andrew Morton <akpm@osdl.org> writes:
> >>
> >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
> >>
> >> I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
> >>
> >> 2.6.11-mm4 works fine but all 2.6.12 versions I've tried (all since
> >> -rc1-mm3) lock up randomly. The easiest way to reproduce the
> >> problem seems to be running Azareus. So it might be network
> >> related, but I'm not 100% sure about that, there was a least one
> >> deadlock with virtually no network usage.
> >
> > Hrm... I just noticed you have CONFIG_PREEMPT enabled... Can you
> > test without it and let me know if it makes a difference ?
>
> IIRC I had disabled that for rc2-mm2 and it didn't make a difference.
> I'll disable it again when I try older versions.
>
> I just got another crash with rc2-mm3. The crash was a bit different
> this time, I still could move the mouse pointer and the logs contained
> some info:
Ok, what about non-mm ? (just plain rc2)
Ben.
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-12 6:34 ` 2.6.12-rc2-mm3 Benjamin Herrenschmidt
@ 2005-04-12 18:08 ` Juergen Kreileder
2005-04-12 22:40 ` 2.6.12-rc2-mm3 Benjamin Herrenschmidt
0 siblings, 1 reply; 68+ messages in thread
From: Juergen Kreileder @ 2005-04-12 18:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Andrew Morton, Linux Kernel list
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Tue, 2005-04-12 at 06:42 +0200, Juergen Kreileder wrote:
>> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>>
>>> On Tue, 2005-04-12 at 03:18 +0200, Juergen Kreileder wrote:
>>>> Andrew Morton <akpm@osdl.org> writes:
>>>>
>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>>>>
>>>> I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
>>>>
>>>> 2.6.11-mm4 works fine but all 2.6.12 versions I've tried (all
>>>> since -rc1-mm3) lock up randomly. The easiest way to reproduce
>>>> the problem seems to be running Azareus. So it might be network
>>>> related, but I'm not 100% sure about that, there was a least one
>>>> deadlock with virtually no network usage.
>>>
>>> Hrm... I just noticed you have CONFIG_PREEMPT enabled... Can you
>>> test without it and let me know if it makes a difference ?
>>
>> IIRC I had disabled that for rc2-mm2 and it didn't make a
>> difference. I'll disable it again when I try older versions.
>>
>> I just got another crash with rc2-mm3. The crash was a bit
>> different this time, I still could move the mouse pointer and the
>> logs contained some info:
>
> Ok, what about non-mm ? (just plain rc2)
I've tried older kernels now. rc1-mm1 locks up (no logs); plain rc1
seems to be OK (running fine for several hours now).
Juergen
--
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-12 18:08 ` 2.6.12-rc2-mm3 Juergen Kreileder
@ 2005-04-12 22:40 ` Benjamin Herrenschmidt
2005-04-13 1:44 ` 2.6.12-rc2-mm3 Juergen Kreileder
0 siblings, 1 reply; 68+ messages in thread
From: Benjamin Herrenschmidt @ 2005-04-12 22:40 UTC (permalink / raw)
To: Juergen Kreileder; +Cc: Andrew Morton, Linux Kernel list
> >>> Hrm... I just noticed you have CONFIG_PREEMPT enabled... Can you
> >>> test without it and let me know if it makes a difference ?
> >>
> >> IIRC I had disabled that for rc2-mm2 and it didn't make a
> >> difference. I'll disable it again when I try older versions.
> >>
> >> I just got another crash with rc2-mm3. The crash was a bit
> >> different this time, I still could move the mouse pointer and the
> >> logs contained some info:
> >
> > Ok, what about non-mm ? (just plain rc2)
>
> I've tried older kernels now. rc1-mm1 locks up (no logs); plain rc1
> seems to be OK (running fine for several hours now).
Interesting. Please try -rc2 too...
Ben.
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-12 22:40 ` 2.6.12-rc2-mm3 Benjamin Herrenschmidt
@ 2005-04-13 1:44 ` Juergen Kreileder
0 siblings, 0 replies; 68+ messages in thread
From: Juergen Kreileder @ 2005-04-13 1:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Andrew Morton, Linux Kernel list
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>>>>> Hrm... I just noticed you have CONFIG_PREEMPT enabled... Can you
>>>>> test without it and let me know if it makes a difference ?
>>>>
>>>> IIRC I had disabled that for rc2-mm2 and it didn't make a
>>>> difference. I'll disable it again when I try older versions.
>>>>
>>>> I just got another crash with rc2-mm3. The crash was a bit
>>>> different this time, I still could move the mouse pointer and the
>>>> logs contained some info:
>>>
>>> Ok, what about non-mm ? (just plain rc2)
>>
>> I've tried older kernels now. rc1-mm1 locks up (no logs); plain
>> rc1 seems to be OK (running fine for several hours now).
>
> Interesting. Please try -rc2 too...
Works fine so far.
Juergen
--
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-12 1:18 ` 2.6.12-rc2-mm3 Juergen Kreileder
2005-04-12 2:09 ` 2.6.12-rc2-mm3 Benjamin Herrenschmidt
2005-04-12 3:26 ` 2.6.12-rc2-mm3 Benjamin Herrenschmidt
@ 2005-04-15 18:23 ` Juergen Kreileder
2005-04-15 23:23 ` 2.6.12-rc2-mm3 Benjamin Herrenschmidt
2 siblings, 1 reply; 68+ messages in thread
From: Juergen Kreileder @ 2005-04-15 18:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Andrew Morton, linux-kernel
Juergen Kreileder <jk@blackdown.de> writes:
> Andrew Morton <akpm@osdl.org> writes:
>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>
> I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
I think I finally found the culprit. Both rc2-mm3 and rc1-mm1 work
fine when I reverse the timer-* patches.
Any idea? Bug in my ppc64 gcc?
Juergen
--
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-15 18:23 ` 2.6.12-rc2-mm3 Juergen Kreileder
@ 2005-04-15 23:23 ` Benjamin Herrenschmidt
2005-04-17 8:40 ` 2.6.12-rc2-mm3 Juergen Kreileder
0 siblings, 1 reply; 68+ messages in thread
From: Benjamin Herrenschmidt @ 2005-04-15 23:23 UTC (permalink / raw)
To: Juergen Kreileder; +Cc: Andrew Morton, Linux Kernel list
On Fri, 2005-04-15 at 20:23 +0200, Juergen Kreileder wrote:
> Juergen Kreileder <jk@blackdown.de> writes:
>
> > Andrew Morton <akpm@osdl.org> writes:
> >
> >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
> >
> > I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
>
> I think I finally found the culprit. Both rc2-mm3 and rc1-mm1 work
> fine when I reverse the timer-* patches.
>
> Any idea? Bug in my ppc64 gcc?
Or a bug in those patches, I'll have a look as soon as I find 5 minutes.
Ben.
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-15 23:23 ` 2.6.12-rc2-mm3 Benjamin Herrenschmidt
@ 2005-04-17 8:40 ` Juergen Kreileder
2005-04-24 0:01 ` 2.6.12-rc2-mm3 Andrew Morton
0 siblings, 1 reply; 68+ messages in thread
From: Juergen Kreileder @ 2005-04-17 8:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Andrew Morton, Linux Kernel list
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Fri, 2005-04-15 at 20:23 +0200, Juergen Kreileder wrote:
>> Juergen Kreileder <jk@blackdown.de> writes:
>>
>>> Andrew Morton <akpm@osdl.org> writes:
>>>
>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>>>
>>> I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
>>
>> I think I finally found the culprit. Both rc2-mm3 and rc1-mm1 work
>> fine when I reverse the timer-* patches.
>>
>> Any idea? Bug in my ppc64 gcc?
>
> Or a bug in those patches,
Probably. I've tried a different toolchain now (3.4.3), didn't help.
Juergen
--
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-17 8:40 ` 2.6.12-rc2-mm3 Juergen Kreileder
@ 2005-04-24 0:01 ` Andrew Morton
2005-04-24 1:59 ` 2.6.12-rc2-mm3 Juergen Kreileder
0 siblings, 1 reply; 68+ messages in thread
From: Andrew Morton @ 2005-04-24 0:01 UTC (permalink / raw)
To: Juergen Kreileder; +Cc: benh, linux-kernel, Oleg Nesterov
Juergen Kreileder <jk@blackdown.de> wrote:
>
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> > On Fri, 2005-04-15 at 20:23 +0200, Juergen Kreileder wrote:
> >> Juergen Kreileder <jk@blackdown.de> writes:
> >>
> >>> Andrew Morton <akpm@osdl.org> writes:
> >>>
> >>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
> >>>
> >>> I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
> >>
> >> I think I finally found the culprit. Both rc2-mm3 and rc1-mm1 work
> >> fine when I reverse the timer-* patches.
> >>
> >> Any idea? Bug in my ppc64 gcc?
> >
> > Or a bug in those patches,
(cc'ed Oleg)
> Probably. I've tried a different toolchain now (3.4.3), didn't help.
That is bad news.
I wonder why you're the only person who has noticed this.
How frequent are the lockups?
Is it possible to perform any additional debugging?
Do you think there's anything unusual in your driver lineup or in your
workload which would cause you to be the only person who is observing this?
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-24 0:01 ` 2.6.12-rc2-mm3 Andrew Morton
@ 2005-04-24 1:59 ` Juergen Kreileder
2005-04-24 2:15 ` 2.6.12-rc2-mm3 Benjamin Herrenschmidt
0 siblings, 1 reply; 68+ messages in thread
From: Juergen Kreileder @ 2005-04-24 1:59 UTC (permalink / raw)
To: Andrew Morton; +Cc: benh, linux-kernel, Oleg Nesterov
Andrew Morton <akpm@osdl.org> writes:
> Juergen Kreileder <jk@blackdown.de> wrote:
>>
>> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>>
>>> On Fri, 2005-04-15 at 20:23 +0200, Juergen Kreileder wrote:
>>>> Juergen Kreileder <jk@blackdown.de> writes:
>>>>> I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
>>>>
>>>> I think I finally found the culprit. Both rc2-mm3 and rc1-mm1
>>>> work fine when I reverse the timer-* patches.
>>>>
>>>> Any idea? Bug in my ppc64 gcc?
>>>
>>> Or a bug in those patches,
>>
>> Probably. I've tried a different toolchain now (3.4.3), didn't
>> help.
>
> That is bad news.
>
> I wonder why you're the only person who has noticed this.
Me too.
> How frequent are the lockups?
It only happens when running Azareus with IBM's Java (our's isn't
ready yet).
So far I was able to reproduce the problem on all -mm versions within
one hour. Otherwise the kernels seem to work fine -- no lockup unless
I run Azareus.
I'm running rc2-mm3 without the timer- patches now. It's up for 6
days now and survived downloading all Ubuntu torrents over ten times.
> Is it possible to perform any additional debugging?
> Do you think there's anything unusual in your driver lineup or in
> your workload which would cause you to be the only person who is
> observing this?
I'm might be the only one using evdev on ppc64.
And I don't know how popular LVM2 is on disks with Macintosh labels.
I had to set it up manually when I installed the machine, Debian's
installer couldn't handle it at that time.
Workload is normal, the lockups happen with just X and Azaereus.
(The machine also runs mysqld, apache, and a few other daemons. But I
don't have to put load on these to make the machine lock up.)
Juergen
--
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-24 1:59 ` 2.6.12-rc2-mm3 Juergen Kreileder
@ 2005-04-24 2:15 ` Benjamin Herrenschmidt
2005-04-24 3:14 ` 2.6.12-rc2-mm3 Juergen Kreileder
` (2 more replies)
0 siblings, 3 replies; 68+ messages in thread
From: Benjamin Herrenschmidt @ 2005-04-24 2:15 UTC (permalink / raw)
To: Juergen Kreileder; +Cc: Andrew Morton, Linux Kernel list, Oleg Nesterov
On Sun, 2005-04-24 at 03:59 +0200, Juergen Kreileder wrote:
> I'm might be the only one using evdev on ppc64.
>
> And I don't know how popular LVM2 is on disks with Macintosh labels.
> I had to set it up manually when I installed the machine, Debian's
> installer couldn't handle it at that time.
>
> Workload is normal, the lockups happen with just X and Azaereus.
> (The machine also runs mysqld, apache, and a few other daemons. But I
> don't have to put load on these to make the machine lock up.)
If you make sure you have CONFIG_XMON enabled and CONFIG_BOOTX_TEXT, and
make sure X has "UseFBDev" option, do you drop into xmon before the
lockup ?
Also, do you have another machine at hand ? if yes, then we can try to
revive my old firewire based debug tools we used to track things down in
linus tree.
I'll have a look at the timer patch next week, they might have some
subtle race caused by a lack of memory barrier. I've had to debug some
of those in early timer code, and those are really nasty, they usually
only trigger under some subtle conditions, like ... heavy networking.
Ben.
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-24 2:15 ` 2.6.12-rc2-mm3 Benjamin Herrenschmidt
@ 2005-04-24 3:14 ` Juergen Kreileder
2005-04-24 4:25 ` 2.6.12-rc2-mm3 Juergen Kreileder
2005-04-24 9:53 ` 2.6.12-rc2-mm3 Oleg Nesterov
2 siblings, 0 replies; 68+ messages in thread
From: Juergen Kreileder @ 2005-04-24 3:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Andrew Morton, Linux Kernel list, Oleg Nesterov
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Sun, 2005-04-24 at 03:59 +0200, Juergen Kreileder wrote:
>
>> I'm might be the only one using evdev on ppc64.
>>
>> And I don't know how popular LVM2 is on disks with Macintosh
>> labels. I had to set it up manually when I installed the machine,
>> Debian's installer couldn't handle it at that time.
>>
>> Workload is normal, the lockups happen with just X and Azaereus.
>> (The machine also runs mysqld, apache, and a few other daemons.
>> But I don't have to put load on these to make the machine lock up.)
>
> If you make sure you have CONFIG_XMON enabled and CONFIG_BOOTX_TEXT,
> and make sure X has "UseFBDev" option, do you drop into xmon before
> the lockup ?
I'll check that.
> Also, do you have another machine at hand ? if yes, then we can try
> to revive my old firewire based debug tools we used to track things
> down in linus tree.
I'd have to organize a firewire cable for that first.
> I'll have a look at the timer patch next week, they might have some
> subtle race caused by a lack of memory barrier. I've had to debug
> some of those in early timer code, and those are really nasty, they
> usually only trigger under some subtle conditions, like ... heavy
> networking.
I wouldn't call it "heavy" in my case. Azareus uses quite a few
sockets but that isn't that uncommon and external traffic is limited
by a ADSL connection.
Juergen
--
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-24 2:15 ` 2.6.12-rc2-mm3 Benjamin Herrenschmidt
2005-04-24 3:14 ` 2.6.12-rc2-mm3 Juergen Kreileder
@ 2005-04-24 4:25 ` Juergen Kreileder
2005-04-24 9:53 ` 2.6.12-rc2-mm3 Oleg Nesterov
2 siblings, 0 replies; 68+ messages in thread
From: Juergen Kreileder @ 2005-04-24 4:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Andrew Morton, Linux Kernel list, Oleg Nesterov
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> If you make sure you have CONFIG_XMON enabled and CONFIG_BOOTX_TEXT,
> and make sure X has "UseFBDev" option, do you drop into xmon before
> the lockup ?
No, instant lockup.
Juergen
--
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-24 2:15 ` 2.6.12-rc2-mm3 Benjamin Herrenschmidt
2005-04-24 3:14 ` 2.6.12-rc2-mm3 Juergen Kreileder
2005-04-24 4:25 ` 2.6.12-rc2-mm3 Juergen Kreileder
@ 2005-04-24 9:53 ` Oleg Nesterov
2005-04-24 23:11 ` 2.6.12-rc2-mm3 Juergen Kreileder
2005-05-03 6:29 ` 2.6.12-rc2-mm3 Andrew Morton
2 siblings, 2 replies; 68+ messages in thread
From: Oleg Nesterov @ 2005-04-24 9:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Juergen Kreileder, Andrew Morton, Linux Kernel list
Benjamin Herrenschmidt wrote:
>
> I'll have a look at the timer patch next week, they might have some
> subtle race caused by a lack of memory barrier. I've had to debug some
> of those in early timer code, and those are really nasty, they usually
> only trigger under some subtle conditions, like ... heavy networking.
Before this timer patch del_timer(pending_timer) worked as
a memory barrier for the caller, now it does not.
For example, sk_stop_timer() does:
if (del_timer(timer))
// no more wmb() here
atomic_dec(&sk->sk_refcnt);
I think that this particular case is ok, but may be there is
some user of timers which lacks the memory barrier?
Juergen Kreileder wrote:
>
> It only happens when running Azareus with IBM's Java (our's isn't ready yet).
> So far I was able to reproduce the problem on all -mm versions within
> one hour. Otherwise the kernels seem to work fine -- no lockup unless
> I run Azareus.
By any chance, could you please try this patch?
It restores "deleting timer acts as a barrier" behaviour.
--- 2.6.12-rc2+timer_patches/kernel/timer.c~ Sun Apr 24 11:59:31 2005
+++ 2.6.12-rc2+timer_patches/kernel/timer.c Sun Apr 24 13:35:01 2005
@@ -341,6 +341,9 @@ int del_timer(struct timer_list *timer)
spin_unlock_irqrestore(&base->lock, flags);
}
+ if (ret)
+ smp_wmb();
+
return ret;
}
@@ -387,6 +390,10 @@ unlock:
spin_unlock_irqrestore(&base->lock, flags);
} while (ret < 0);
+ if (ret)
+ smp_wmb();
+ smp_rmb();
+
return ret;
}
@@ -457,6 +464,7 @@ repeat:
set_running_timer(base, timer);
detach_timer(timer, 1);
+ smp_wmb();
spin_unlock_irq(&base->t_base.lock);
{
u32 preempt_count = preempt_count();
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-24 9:53 ` 2.6.12-rc2-mm3 Oleg Nesterov
@ 2005-04-24 23:11 ` Juergen Kreileder
2005-04-25 0:09 ` 2.6.12-rc2-mm3 Benjamin Herrenschmidt
2005-05-03 6:29 ` 2.6.12-rc2-mm3 Andrew Morton
1 sibling, 1 reply; 68+ messages in thread
From: Juergen Kreileder @ 2005-04-24 23:11 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: Benjamin Herrenschmidt, Andrew Morton, Linux Kernel list
Oleg Nesterov <oleg@tv-sign.ru> writes:
> Juergen Kreileder wrote:
>>
>> It only happens when running Azareus with IBM's Java (our's isn't
>> ready yet). So far I was able to reproduce the problem on all -mm
>> versions within one hour. Otherwise the kernels seem to work fine
>> -- no lockup unless I run Azareus.
>
> By any chance, could you please try this patch?
Doesn't help.
Juergen
--
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-24 23:11 ` 2.6.12-rc2-mm3 Juergen Kreileder
@ 2005-04-25 0:09 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 68+ messages in thread
From: Benjamin Herrenschmidt @ 2005-04-25 0:09 UTC (permalink / raw)
To: Juergen Kreileder; +Cc: Oleg Nesterov, Andrew Morton, Linux Kernel list
On Mon, 2005-04-25 at 01:11 +0200, Juergen Kreileder wrote:
> Oleg Nesterov <oleg@tv-sign.ru> writes:
>
> > Juergen Kreileder wrote:
> >>
> >> It only happens when running Azareus with IBM's Java (our's isn't
> >> ready yet). So far I was able to reproduce the problem on all -mm
> >> versions within one hour. Otherwise the kernels seem to work fine
> >> -- no lockup unless I run Azareus.
> >
> > By any chance, could you please try this patch?
>
> Doesn't help.
Ok, try to mail me privately a HOWTO to reproduce your exact testcase,
knowing that I don't know anything about this Azareus thing ...
Ben.
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-24 9:53 ` 2.6.12-rc2-mm3 Oleg Nesterov
2005-04-24 23:11 ` 2.6.12-rc2-mm3 Juergen Kreileder
@ 2005-05-03 6:29 ` Andrew Morton
2005-05-03 10:42 ` 2.6.12-rc2-mm3 Oleg Nesterov
1 sibling, 1 reply; 68+ messages in thread
From: Andrew Morton @ 2005-05-03 6:29 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: benh, jk, linux-kernel
Oleg Nesterov <oleg@tv-sign.ru> wrote:
>
> Benjamin Herrenschmidt wrote:
> >
> > I'll have a look at the timer patch next week, they might have some
> > subtle race caused by a lack of memory barrier. I've had to debug some
> > of those in early timer code, and those are really nasty, they usually
> > only trigger under some subtle conditions, like ... heavy networking.
>
> Before this timer patch del_timer(pending_timer) worked as
> a memory barrier for the caller, now it does not.
>
> For example, sk_stop_timer() does:
>
> if (del_timer(timer))
> // no more wmb() here
> atomic_dec(&sk->sk_refcnt);
>
> I think that this particular case is ok, but may be there is
> some user of timers which lacks the memory barrier?
>
> ...
> --- 2.6.12-rc2+timer_patches/kernel/timer.c~ Sun Apr 24 11:59:31 2005
> +++ 2.6.12-rc2+timer_patches/kernel/timer.c Sun Apr 24 13:35:01 2005
> @@ -341,6 +341,9 @@ int del_timer(struct timer_list *timer)
> spin_unlock_irqrestore(&base->lock, flags);
> }
>
> + if (ret)
> + smp_wmb();
> +
> return ret;
> }
>
> @@ -387,6 +390,10 @@ unlock:
> spin_unlock_irqrestore(&base->lock, flags);
> } while (ret < 0);
>
> + if (ret)
> + smp_wmb();
> + smp_rmb();
> +
> return ret;
> }
>
> @@ -457,6 +464,7 @@ repeat:
>
> set_running_timer(base, timer);
> detach_timer(timer, 1);
> + smp_wmb();
> spin_unlock_irq(&base->t_base.lock);
> {
> u32 preempt_count = preempt_count();
I wonder if we should still do this? It would seem to be a safer approach.
(This barrier stuff continues to give me the creeps. Imagine being
dependent upon accidental barriers in the add/del/mod_timer code. Ugh).
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-05-03 6:29 ` 2.6.12-rc2-mm3 Andrew Morton
@ 2005-05-03 10:42 ` Oleg Nesterov
0 siblings, 0 replies; 68+ messages in thread
From: Oleg Nesterov @ 2005-05-03 10:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: benh, jk, linux-kernel
Andrew Morton wrote:
>
> Oleg Nesterov <oleg@tv-sign.ru> wrote:
> >
> > ...
> > Before this timer patch del_timer(pending_timer) worked as
> > a memory barrier for the caller, now it does not.
> >
>
> I wonder if we should still do this? It would seem to be a safer approach.
>
> (This barrier stuff continues to give me the creeps. Imagine being
> dependent upon accidental barriers in the add/del/mod_timer code. Ugh).
I can't judge. But if we added barriers now, it would be
very hard to remove them later. And I think it's not good
to have these barriers "just in case".
Oleg.
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-11 8:25 2.6.12-rc2-mm3 Andrew Morton
` (6 preceding siblings ...)
2005-04-12 1:18 ` 2.6.12-rc2-mm3 Juergen Kreileder
@ 2005-04-12 5:00 ` Andrew Morton
2005-04-12 5:51 ` 2.6.12-rc2-mm3 Nick Piggin
2005-04-12 7:06 ` 2.6.12-rc2-mm3 Jens Axboe
2005-04-12 11:32 ` 2.6.12-rc2-mm3 Ed Tomlinson
` (6 subsequent siblings)
14 siblings, 2 replies; 68+ messages in thread
From: Andrew Morton @ 2005-04-12 5:00 UTC (permalink / raw)
To: linux-kernel; +Cc: Jens Axboe, Nick Piggin
Andrew Morton <akpm@osdl.org> wrote:
>
> - The anticipatory I/O scheduler has always been fairly useless with SCSI
> disks which perform tagged command queueing. There's a patch here from Jens
> which is designed to fix that up by constraining the number of requests
> which we'll leave pending in the device.
>
> The depth currently defaults to 1. Tunable in
> /sys/block/hdX/queue/iosched/queue_depth
>
> This patch hasn't been performance tested at all yet. If you think it is
> misbehaving (the usual symptom is processes stuck in D state) then please
> report it, then boot with `elevator=cfq' or `elevator=deadline' to work
> around it.
So it turns out that patch was broken. I've fixed it locally and the
results are good, but odd.
The machine is a 4GB x86_64 with aic79xx controllers and MAXTOR
ATLAS10K4_73WLS disks. ext2 filesystem.
The workload is continuous pagecache writeback versus
read-lots-of-little-files:
while true
do
dd if=/dev/zero of=/mnt/sdb2/x bs=40M count=100 conv=notrunc
done
versus
find /mnt/sdb2/linux-2.4.25 -type f | xargs cat > /dev/null
we measure how long the find+cat takes.
2.6.12-rc2, as, tcq depth=2: 7.241 seconds
2.6.12-rc2, as, tcq depth=64: 12.172 seconds
2.6.12-rc2+patch,as, tcq depth=64: 7.199 seconds
2.6.12-rc2, cfq2, tcq depth=64: much more than 5 minutes
2.6.12-rc2, cfq3, tcq depth=64: much more than 5 minutes
So
- The effects of tcq on AS are much less disastrous than I thought they
were. Do I have the wrong workload? Memory fails me. Or did we fix the
anticipatory scheduler?
- as-limit-queue-depth.patch fixes things right up anyway. Seems to be
doing the right thing.
- CFQ is seriously, seriously read-starved on this workload.
CFQ2:
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
2 3 1116 25504 4868 3854008 4 0 8 61976 1112 291 0 4 39 58
0 4 1112 24992 4868 3855120 0 568 4 53804 1124 452 0 4 54 43
0 4 1112 24032 4868 3856004 0 0 8 44652 1110 303 0 3 45 53
0 2 1112 25912 4872 3854164 0 0 4 51108 1122 321 0 3 52 45
2 3 1112 24312 4872 3855728 0 0 32 52240 1113 300 0 4 44 52
1 3 1112 25728 4876 3854432 0 0 20 48128 1118 296 0 3 58 39
0 2 1112 23872 4876 3856336 0 0 4 48136 1116 288 0 4 47 49
0 4 1112 25856 4876 3854300 0 4 16 50260 1117 294 0 3 55 42
CFQ3:
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 5 1008 25888 4204 3845820 0 0 12 50544 1119 116 0 3 49 48
0 5 1008 24096 4204 3847520 0 0 8 51200 1112 110 0 3 49 48
0 5 1008 25824 4204 3845820 0 0 8 54816 1117 120 0 4 49 48
0 5 1008 25440 4204 3846160 0 0 8 52880 1113 115 0 3 49 48
0 5 1008 25888 4208 3845748 0 0 16 51024 1121 116 0 3 49 48
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-12 5:00 ` 2.6.12-rc2-mm3 Andrew Morton
@ 2005-04-12 5:51 ` Nick Piggin
2005-04-12 6:19 ` 2.6.12-rc2-mm3 Andrew Morton
2005-04-12 7:06 ` 2.6.12-rc2-mm3 Jens Axboe
1 sibling, 1 reply; 68+ messages in thread
From: Nick Piggin @ 2005-04-12 5:51 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Jens Axboe
Andrew Morton wrote:
>
>So it turns out that patch was broken. I've fixed it locally and the
>results are good, but odd.
>
>The machine is a 4GB x86_64 with aic79xx controllers and MAXTOR
>ATLAS10K4_73WLS disks. ext2 filesystem.
>
>The workload is continuous pagecache writeback versus
>read-lots-of-little-files:
>
> while true
> do
> dd if=/dev/zero of=/mnt/sdb2/x bs=40M count=100 conv=notrunc
> done
>
>versus
>
> find /mnt/sdb2/linux-2.4.25 -type f | xargs cat > /dev/null
>
>we measure how long the find+cat takes.
>
>2.6.12-rc2, as, tcq depth=2: 7.241 seconds
>2.6.12-rc2, as, tcq depth=64: 12.172 seconds
>2.6.12-rc2+patch,as, tcq depth=64: 7.199 seconds
>2.6.12-rc2, cfq2, tcq depth=64: much more than 5 minutes
>2.6.12-rc2, cfq3, tcq depth=64: much more than 5 minutes
>
>So
>
>- The effects of tcq on AS are much less disastrous than I thought they
> were. Do I have the wrong workload? Memory fails me. Or did we fix the
> anticipatory scheduler?
>
>
Yes, we did fix it ;)
Quite a long time ago, so maybe you are thinking of something else
(I haven't been able to work it out).
AS basically does its own TCQ strangulation, which IIRC involves things
like completing all reads before issuing new writes, and completing all
reads from one process before reads from another. As well as the
fundamental way that waiting for a 'dependant read' throttles TCQ.
>- as-limit-queue-depth.patch fixes things right up anyway. Seems to be
> doing the right thing.
>
>
Well it depends on what we want to do. If we hard limit the AS queue
like this, I can remove some of that TCQ throttling logic from AS.
OTOH, the throttling was intended to allow us to sanely use a large
TCQ depth without getting really bad behaviour. Theoretically a process
can make use of TCQ if it is doing a lot of writing, or if it is not
determined to be doing dependant reads.
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-12 5:51 ` 2.6.12-rc2-mm3 Nick Piggin
@ 2005-04-12 6:19 ` Andrew Morton
2005-04-12 6:49 ` 2.6.12-rc2-mm3 Nick Piggin
2005-04-12 17:01 ` 2.6.12-rc2-mm3 Steven Pratt
0 siblings, 2 replies; 68+ messages in thread
From: Andrew Morton @ 2005-04-12 6:19 UTC (permalink / raw)
To: Nick Piggin; +Cc: linux-kernel, axboe, Steven Pratt
Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
> >- The effects of tcq on AS are much less disastrous than I thought they
> > were. Do I have the wrong workload? Memory fails me. Or did we fix the
> > anticipatory scheduler?
> >
> >
>
> Yes, we did fix it ;)
> Quite a long time ago, so maybe you are thinking of something else
> (I haven't been able to work it out).
Steve Pratt's ols2004 presentation made AS look pretty bad. However the
numbers in the proceedings
(http://www.finux.org/proceedings/LinuxSymposium2004_V2.pdf) are much less
stark.
Steve, what's up with that? The slides which you talked to had some awful
numbers. Was it the same set of tests?
Seems that software RAID might have muddied the waters as well.
That was 2.6.5. Do you recall if we did significant AS work after that?
> AS basically does its own TCQ strangulation, which IIRC involves things
> like completing all reads before issuing new writes, and completing all
> reads from one process before reads from another. As well as the
> fundamental way that waiting for a 'dependant read' throttles TCQ.
My (mpt-fusion-based) workstation is still really slow when there's a lot
of writeout happening. Just from a quick test:
> 2.6.12-rc2, as, tcq depth=2: 7.241 seconds
> 2.6.12-rc2, as, tcq depth=64: 12.172 seconds
> 2.6.12-rc2+patch,as, tcq depth=64: 7.199 seconds
> 2.6.12-rc2, cfq2, tcq depth=64: much more than 5 minutes
> 2.6.12-rc2, cfq3, tcq depth=64: much more than 5 minutes
2.6.11-rc4-mm1, as, mpt-f 39.349 seconds
That was really really slow but had a sudden burst of read I/O at the end
which made the thing look better than it really is. I wouldn't have a clue
what tag depth it's using, and it's the only mpt-fusion based machine I
have handy...
> >- as-limit-queue-depth.patch fixes things right up anyway. Seems to be
> > doing the right thing.
> >
> >
>
> Well it depends on what we want to do. If we hard limit the AS queue
> like this, I can remove some of that TCQ throttling logic from AS.
>
> OTOH, the throttling was intended to allow us to sanely use a large
> TCQ depth without getting really bad behaviour. Theoretically a process
> can make use of TCQ if it is doing a lot of writing, or if it is not
> determined to be doing dependant reads.
OK, I'll have a bit more of a poke at the LSI53C1030 driver, see if I can
characterise what's going on.
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-12 6:19 ` 2.6.12-rc2-mm3 Andrew Morton
@ 2005-04-12 6:49 ` Nick Piggin
2005-04-12 7:50 ` 2.6.12-rc2-mm3 Andrew Morton
2005-04-12 17:01 ` 2.6.12-rc2-mm3 Steven Pratt
1 sibling, 1 reply; 68+ messages in thread
From: Nick Piggin @ 2005-04-12 6:49 UTC (permalink / raw)
To: Andrew Morton; +Cc: lkml, axboe, Steven Pratt
On Mon, 2005-04-11 at 23:19 -0700, Andrew Morton wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> >
> > >- The effects of tcq on AS are much less disastrous than I thought they
> > > were. Do I have the wrong workload? Memory fails me. Or did we fix the
> > > anticipatory scheduler?
> > >
> > >
> >
> > Yes, we did fix it ;)
> > Quite a long time ago, so maybe you are thinking of something else
> > (I haven't been able to work it out).
>
> Steve Pratt's ols2004 presentation made AS look pretty bad. However the
> numbers in the proceedings
> (http://www.finux.org/proceedings/LinuxSymposium2004_V2.pdf) are much less
> stark.
>
> Steve, what's up with that? The slides which you talked to had some awful
> numbers. Was it the same set of tests?
>
Yes, they still do... :P
> Seems that software RAID might have muddied the waters as well.
>
This may be the big issue, and yes software (and hardware) RAID isn't
very good for AS - mainly because it can't make a good guess as to
where "the head" is.
Probably software RAID should default to using deadline if possible.
I think we can do that easily with Jens' recent ioscheduler work.
> That was 2.6.5. Do you recall if we did significant AS work after that?
>
I don't think there was.
> > AS basically does its own TCQ strangulation, which IIRC involves things
> > like completing all reads before issuing new writes, and completing all
> > reads from one process before reads from another. As well as the
> > fundamental way that waiting for a 'dependant read' throttles TCQ.
>
> My (mpt-fusion-based) workstation is still really slow when there's a lot
> of writeout happening. Just from a quick test:
>
> > 2.6.12-rc2, as, tcq depth=2: 7.241 seconds
> > 2.6.12-rc2, as, tcq depth=64: 12.172 seconds
> > 2.6.12-rc2+patch,as, tcq depth=64: 7.199 seconds
> > 2.6.12-rc2, cfq2, tcq depth=64: much more than 5 minutes
> > 2.6.12-rc2, cfq3, tcq depth=64: much more than 5 minutes
>
> 2.6.11-rc4-mm1, as, mpt-f 39.349 seconds
>
> That was really really slow but had a sudden burst of read I/O at the end
> which made the thing look better than it really is. I wouldn't have a clue
> what tag depth it's using, and it's the only mpt-fusion based machine I
> have handy...
>
Heh.
> > >- as-limit-queue-depth.patch fixes things right up anyway. Seems to be
> > > doing the right thing.
> > >
> > >
> >
> > Well it depends on what we want to do. If we hard limit the AS queue
> > like this, I can remove some of that TCQ throttling logic from AS.
> >
> > OTOH, the throttling was intended to allow us to sanely use a large
> > TCQ depth without getting really bad behaviour. Theoretically a process
> > can make use of TCQ if it is doing a lot of writing, or if it is not
> > determined to be doing dependant reads.
>
> OK, I'll have a bit more of a poke at the LSI53C1030 driver, see if I can
> characterise what's going on.
OK. I'd like to start doing a bit of work on AS again too. Hopefully
after the current CPU scheduler work gets resolved.
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-12 6:49 ` 2.6.12-rc2-mm3 Nick Piggin
@ 2005-04-12 7:50 ` Andrew Morton
2005-04-12 19:03 ` 2.6.12-rc2-mm3 Steven Pratt
0 siblings, 1 reply; 68+ messages in thread
From: Andrew Morton @ 2005-04-12 7:50 UTC (permalink / raw)
To: Nick Piggin; +Cc: linux-kernel, axboe, Steven Pratt
Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
> > > AS basically does its own TCQ strangulation, which IIRC involves things
> > > like completing all reads before issuing new writes, and completing all
> > > reads from one process before reads from another. As well as the
> > > fundamental way that waiting for a 'dependant read' throttles TCQ.
> >
> > My (mpt-fusion-based) workstation is still really slow when there's a lot
> > of writeout happening. Just from a quick test:
> >
> > > 2.6.12-rc2, as, tcq depth=2: 7.241 seconds
> > > 2.6.12-rc2, as, tcq depth=64: 12.172 seconds
> > > 2.6.12-rc2+patch,as, tcq depth=64: 7.199 seconds
> > > 2.6.12-rc2, cfq2, tcq depth=64: much more than 5 minutes
> > > 2.6.12-rc2, cfq3, tcq depth=64: much more than 5 minutes
> >
> > 2.6.11-rc4-mm1, as, mpt-f 39.349 seconds
> >
> > That was really really slow but had a sudden burst of read I/O at the end
> > which made the thing look better than it really is. I wouldn't have a clue
> > what tag depth it's using, and it's the only mpt-fusion based machine I
> > have handy...
> >
>
> Heh.
Well with my current lineup on the mpt-fusion driver and no
as-limit-queue-depth.patch that test takes 17 seconds. With
as-limit-queue-depth.patch it's down to 10 seconds. Which is pretty darn
good btw. I assume from this:
scsi0 : ioc0: LSI53C1030, FwRev=01030600h, Ports=1, MaxQ=222, IRQ=25
scsi1 : ioc1: LSI53C1030, FwRev=01030600h, Ports=1, MaxQ=222, IRQ=26
that it's using a tag depth of 222.
int req_depth; /* Number of request frames */
I wonder if that's true...
One thing which changed is that this kernel now has the fixed-up mpt-fusion
chipset tuning. That doubles the IO bandwidth, which would pretty well
account for that difference. I'll wait and see how irritating things get
under writeout load.
Yes, we'll need to decide if we want to retain as-limit-queue-depth.patch
and toss out some of the older AS logic which was designed to address the
TCQ problem.
Steve, could you help to identify a not-too-hard-to-set-up workload at
which AS was particularly poor? Thanks.
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-12 7:50 ` 2.6.12-rc2-mm3 Andrew Morton
@ 2005-04-12 19:03 ` Steven Pratt
0 siblings, 0 replies; 68+ messages in thread
From: Steven Pratt @ 2005-04-12 19:03 UTC (permalink / raw)
To: Andrew Morton; +Cc: Nick Piggin, linux-kernel, axboe
Andrew Morton wrote:
>Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
>
>>>> AS basically does its own TCQ strangulation, which IIRC involves things
>>>>
>>>>
>> > > like completing all reads before issuing new writes, and completing all
>> > > reads from one process before reads from another. As well as the
>> > > fundamental way that waiting for a 'dependant read' throttles TCQ.
>> >
>> > My (mpt-fusion-based) workstation is still really slow when there's a lot
>> > of writeout happening. Just from a quick test:
>> >
>> > > 2.6.12-rc2, as, tcq depth=2: 7.241 seconds
>> > > 2.6.12-rc2, as, tcq depth=64: 12.172 seconds
>> > > 2.6.12-rc2+patch,as, tcq depth=64: 7.199 seconds
>> > > 2.6.12-rc2, cfq2, tcq depth=64: much more than 5 minutes
>> > > 2.6.12-rc2, cfq3, tcq depth=64: much more than 5 minutes
>> >
>> > 2.6.11-rc4-mm1, as, mpt-f 39.349 seconds
>> >
>> > That was really really slow but had a sudden burst of read I/O at the end
>> > which made the thing look better than it really is. I wouldn't have a clue
>> > what tag depth it's using, and it's the only mpt-fusion based machine I
>> > have handy...
>> >
>>
>> Heh.
>>
>>
>
>Well with my current lineup on the mpt-fusion driver and no
>as-limit-queue-depth.patch that test takes 17 seconds. With
>as-limit-queue-depth.patch it's down to 10 seconds. Which is pretty darn
>good btw. I assume from this:
>
>scsi0 : ioc0: LSI53C1030, FwRev=01030600h, Ports=1, MaxQ=222, IRQ=25
>scsi1 : ioc1: LSI53C1030, FwRev=01030600h, Ports=1, MaxQ=222, IRQ=26
>
>that it's using a tag depth of 222.
>
> int req_depth; /* Number of request frames */
>
>I wonder if that's true...
>
>
>One thing which changed is that this kernel now has the fixed-up mpt-fusion
>chipset tuning. That doubles the IO bandwidth, which would pretty well
>account for that difference. I'll wait and see how irritating things get
>under writeout load.
>
>Yes, we'll need to decide if we want to retain as-limit-queue-depth.patch
>and toss out some of the older AS logic which was designed to address the
>TCQ problem.
>
>Steve, could you help to identify a not-too-hard-to-set-up workload at
>which AS was particularly poor? Thanks.
>
>
AS with XFS was pretty bad on a couple of workloads. random 4k reads
and "metadata" which was 40%create, 40%append, 20%delete multithreaded
workloads. I'll try to run a few tests with and without this patch on
my hardware setup over the next day or so and see how it does. I have
not really looked at AS performance since about 2.6.6/7. Our database
team recently re-checked IO Scheduler performance, and on the Ad Hoc
Decision Support Workload we still saw a 15-20% lower throughput on
RHEL4 with AS compared to other schedulers which were all within a
couple of %.
Steve
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-12 6:19 ` 2.6.12-rc2-mm3 Andrew Morton
2005-04-12 6:49 ` 2.6.12-rc2-mm3 Nick Piggin
@ 2005-04-12 17:01 ` Steven Pratt
1 sibling, 0 replies; 68+ messages in thread
From: Steven Pratt @ 2005-04-12 17:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: Nick Piggin, linux-kernel, axboe
Andrew Morton wrote:
>Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
>
>>>- The effects of tcq on AS are much less disastrous than I thought they
>>>
>>>
>> > were. Do I have the wrong workload? Memory fails me. Or did we fix the
>> > anticipatory scheduler?
>> >
>> >
>>
>> Yes, we did fix it ;)
>> Quite a long time ago, so maybe you are thinking of something else
>> (I haven't been able to work it out).
>>
>>
>
>Steve Pratt's ols2004 presentation made AS look pretty bad. However the
>numbers in the proceedings
>(http://www.finux.org/proceedings/LinuxSymposium2004_V2.pdf) are much less
>stark.
>
>Steve, what's up with that? The slides which you talked to had some awful
>numbers. Was it the same set of tests?
>
>
I highlighted a few cases where AS went really wrong during the
presentation, like on really large RAID 0 arrays, but in general
(referring back to slides) AS trailed other schedulers by 5-10% on ext3,
but had real trouble with XFS, losing by as much as %145 on 5disk raid5
system for a mix of workloads. Perhaps this is the piece you remember.
Steve
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-12 5:00 ` 2.6.12-rc2-mm3 Andrew Morton
2005-04-12 5:51 ` 2.6.12-rc2-mm3 Nick Piggin
@ 2005-04-12 7:06 ` Jens Axboe
1 sibling, 0 replies; 68+ messages in thread
From: Jens Axboe @ 2005-04-12 7:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Nick Piggin
On Mon, Apr 11 2005, Andrew Morton wrote:
> - CFQ is seriously, seriously read-starved on this workload.
>
> CFQ3:
>
> procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
> r b swpd free buff cache si so bi bo in cs us sy id wa
> 1 5 1008 25888 4204 3845820 0 0 12 50544 1119 116 0 3 49 48
> 0 5 1008 24096 4204 3847520 0 0 8 51200 1112 110 0 3 49 48
> 0 5 1008 25824 4204 3845820 0 0 8 54816 1117 120 0 4 49 48
> 0 5 1008 25440 4204 3846160 0 0 8 52880 1113 115 0 3 49 48
> 0 5 1008 25888 4208 3845748 0 0 16 51024 1121 116 0 3 49 48
Looks very bad, I'll have a look at this.
--
Jens Axboe
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-11 8:25 2.6.12-rc2-mm3 Andrew Morton
` (7 preceding siblings ...)
2005-04-12 5:00 ` 2.6.12-rc2-mm3 Andrew Morton
@ 2005-04-12 11:32 ` Ed Tomlinson
2005-04-12 11:39 ` 2.6.12-rc2-mm3 Andrew Morton
2005-04-17 21:32 ` [-mm patch] fix "make mandocs" Adrian Bunk
` (5 subsequent siblings)
14 siblings, 1 reply; 68+ messages in thread
From: Ed Tomlinson @ 2005-04-12 11:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Monday 11 April 2005 04:25, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>
>
> - The anticipatory I/O scheduler has always been fairly useless with SCSI
> disks which perform tagged command queueing. There's a patch here from Jens
> which is designed to fix that up by constraining the number of requests
> which we'll leave pending in the device.
>
> The depth currently defaults to 1. Tunable in
> /sys/block/hdX/queue/iosched/queue_depth
>
> This patch hasn't been performance tested at all yet. If you think it is
> misbehaving (the usual symptom is processes stuck in D state) then please
> report it, then boot with `elevator=cfq' or `elevator=deadline' to work
> around it.
>
> - More CPU scheduler work. I hope someone is testing this stuff.
Something is not quite right here. I built rc2-mm3 and booted (uni processor, amd64, preempt on).
mm3 lasted about 30 mins before locking up with a dead keyboard. I had mm2 reboot a few times
over the last couple of days too.
11-mm3 uptime of 2 weeks+
12-rc2-mm2 reboots once every couple of days
12-rc2-mm3 locked up within 30 mins using X using kmail/bogofilter
My serial console does not seem to want to work. Has anything changed with this support?
TIA,
Ed Tomlinson
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-12 11:32 ` 2.6.12-rc2-mm3 Ed Tomlinson
@ 2005-04-12 11:39 ` Andrew Morton
2005-04-14 0:15 ` 2.6.12-rc2-mm3 Ed Tomlinson
0 siblings, 1 reply; 68+ messages in thread
From: Andrew Morton @ 2005-04-12 11:39 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: linux-kernel
Ed Tomlinson <tomlins@cam.org> wrote:
>
> On Monday 11 April 2005 04:25, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
> >
> >
> > - The anticipatory I/O scheduler has always been fairly useless with SCSI
> > disks which perform tagged command queueing. There's a patch here from Jens
> > which is designed to fix that up by constraining the number of requests
> > which we'll leave pending in the device.
> >
> > The depth currently defaults to 1. Tunable in
> > /sys/block/hdX/queue/iosched/queue_depth
> >
> > This patch hasn't been performance tested at all yet. If you think it is
> > misbehaving (the usual symptom is processes stuck in D state) then please
> > report it, then boot with `elevator=cfq' or `elevator=deadline' to work
> > around it.
> >
> > - More CPU scheduler work. I hope someone is testing this stuff.
>
> Something is not quite right here. I built rc2-mm3 and booted (uni processor, amd64, preempt on).
> mm3 lasted about 30 mins before locking up with a dead keyboard. I had mm2 reboot a few times
> over the last couple of days too.
>
> 11-mm3 uptime of 2 weeks+
> 12-rc2-mm2 reboots once every couple of days
> 12-rc2-mm3 locked up within 30 mins using X using kmail/bogofilter
Unpleasant. Serial console would be nice ;)
> My serial console does not seem to want to work. Has anything changed with this support?
>
Don't think so - it works OK here. Checked the .config? Does the serial
port work if you do `echo foo > /dev/ttyS0'? ACPI?
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-12 11:39 ` 2.6.12-rc2-mm3 Andrew Morton
@ 2005-04-14 0:15 ` Ed Tomlinson
2005-04-14 0:20 ` 2.6.12-rc2-mm3 Andrew Morton
0 siblings, 1 reply; 68+ messages in thread
From: Ed Tomlinson @ 2005-04-14 0:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Tuesday 12 April 2005 07:39, Andrew Morton wrote:
> Ed Tomlinson <tomlins@cam.org> wrote:
> >
> > On Monday 11 April 2005 04:25, Andrew Morton wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
> > >
> > >
> > > - The anticipatory I/O scheduler has always been fairly useless with SCSI
> > > disks which perform tagged command queueing. There's a patch here from Jens
> > > which is designed to fix that up by constraining the number of requests
> > > which we'll leave pending in the device.
> > >
> > > The depth currently defaults to 1. Tunable in
> > > /sys/block/hdX/queue/iosched/queue_depth
> > >
> > > This patch hasn't been performance tested at all yet. If you think it is
> > > misbehaving (the usual symptom is processes stuck in D state) then please
> > > report it, then boot with `elevator=cfq' or `elevator=deadline' to work
> > > around it.
> > >
> > > - More CPU scheduler work. I hope someone is testing this stuff.
> >
> > Something is not quite right here. I built rc2-mm3 and booted (uni processor, amd64, preempt on).
> > mm3 lasted about 30 mins before locking up with a dead keyboard. I had mm2 reboot a few times
> > over the last couple of days too.
> >
> > 11-mm3 uptime of 2 weeks+
> > 12-rc2-mm2 reboots once every couple of days
> > 12-rc2-mm3 locked up within 30 mins using X using kmail/bogofilter
>
> Unpleasant. Serial console would be nice ;)
>
> > My serial console does not seem to want to work. Has anything changed with this support?
> >
>
> Don't think so - it works OK here. Checked the .config? Does the serial
> port work if you do `echo foo > /dev/ttyS0'? ACPI?
Turned out it was some old ups software that got reactivated on the box displaying the
console - was a pain to disable it....
In any case, when the box reboots there are not any messages. Any ideas on what debug
options to enable or suggestions on how we can figure out the cause of the reboots.
TIA,
Ed Tomlinson
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-14 0:15 ` 2.6.12-rc2-mm3 Ed Tomlinson
@ 2005-04-14 0:20 ` Andrew Morton
2005-04-14 0:38 ` 2.6.12-rc2-mm3 Ed Tomlinson
0 siblings, 1 reply; 68+ messages in thread
From: Andrew Morton @ 2005-04-14 0:20 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: linux-kernel
Ed Tomlinson <tomlins@cam.org> wrote:
>
> > Don't think so - it works OK here. Checked the .config? Does the serial
> > port work if you do `echo foo > /dev/ttyS0'? ACPI?
>
> Turned out it was some old ups software that got reactivated on the box displaying the
> console - was a pain to disable it....
OK.
> In any case, when the box reboots there are not any messages. Any ideas on what debug
> options to enable or suggestions on how we can figure out the cause of the reboots.
There were a few problems in the task switching area - maybe that.
From: Ingo Molnar <mingo@elte.hu>
delay the reloading of segment registers into switch_mm(), so that if
the LDT size changes we dont get a (silent) fault and a zeroed selector
register upon reloading.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
25-akpm/arch/i386/kernel/process.c | 10 +++++-----
25-akpm/include/asm-i386/mmu_context.h | 7 +++++++
2 files changed, 12 insertions(+), 5 deletions(-)
diff -puN arch/i386/kernel/process.c~sched-unlocked-context-switches-fix arch/i386/kernel/process.c
--- 25/arch/i386/kernel/process.c~sched-unlocked-context-switches-fix 2005-04-12 03:43:07.254363568 -0700
+++ 25-akpm/arch/i386/kernel/process.c 2005-04-12 03:43:07.259362808 -0700
@@ -653,12 +653,12 @@ struct task_struct fastcall * __switch_t
asm volatile("mov %%gs,%0":"=m" (prev->gs));
/*
- * Restore %fs and %gs if needed.
+ * Clear selectors if needed:
*/
- if (unlikely(prev->fs | prev->gs | next->fs | next->gs)) {
- loadsegment(fs, next->fs);
- loadsegment(gs, next->gs);
- }
+ if (unlikely((prev->fs | prev->gs) && !(next->fs | next->gs))) {
+ loadsegment(fs, next->fs);
+ loadsegment(gs, next->gs);
+ }
/*
* Now maybe reload the debug registers
diff -puN include/asm-i386/mmu_context.h~sched-unlocked-context-switches-fix include/asm-i386/mmu_context.h
--- 25/include/asm-i386/mmu_context.h~sched-unlocked-context-switches-fix 2005-04-12 03:43:07.256363264 -0700
+++ 25-akpm/include/asm-i386/mmu_context.h 2005-04-12 03:43:07.260362656 -0700
@@ -61,6 +61,13 @@ static inline void switch_mm(struct mm_s
}
}
#endif
+ /*
+ * Now that we've switched the LDT, load segments:
+ */
+ if (unlikely(current->thread.fs | current->thread.gs)) {
+ loadsegment(fs, current->thread.fs);
+ loadsegment(gs, current->thread.gs);
+ }
}
#define deactivate_mm(tsk, mm) \
_
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-14 0:20 ` 2.6.12-rc2-mm3 Andrew Morton
@ 2005-04-14 0:38 ` Ed Tomlinson
2005-04-14 0:54 ` 2.6.12-rc2-mm3 Andrew Morton
0 siblings, 1 reply; 68+ messages in thread
From: Ed Tomlinson @ 2005-04-14 0:38 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Wednesday 13 April 2005 20:20, Andrew Morton wrote:
> Ed Tomlinson <tomlins@cam.org> wrote:
> >
> > > Don't think so - it works OK here. Checked the .config? Does the serial
> > > port work if you do `echo foo > /dev/ttyS0'? ACPI?
> >
> > Turned out it was some old ups software that got reactivated on the box displaying the
> > console - was a pain to disable it....
>
> OK.
>
> > In any case, when the box reboots there are not any messages. Any ideas on what debug
> > options to enable or suggestions on how we can figure out the cause of the reboots.
>
> There were a few problems in the task switching area - maybe that.
These hit arch/i386. Are they going to help on an x86_64 box?
Ed
> From: Ingo Molnar <mingo@elte.hu>
>
> delay the reloading of segment registers into switch_mm(), so that if
> the LDT size changes we dont get a (silent) fault and a zeroed selector
> register upon reloading.
>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> ---
>
> 25-akpm/arch/i386/kernel/process.c | 10 +++++-----
> 25-akpm/include/asm-i386/mmu_context.h | 7 +++++++
> 2 files changed, 12 insertions(+), 5 deletions(-)
>
> diff -puN arch/i386/kernel/process.c~sched-unlocked-context-switches-fix arch/i386/kernel/process.c
> --- 25/arch/i386/kernel/process.c~sched-unlocked-context-switches-fix 2005-04-12 03:43:07.254363568 -0700
> +++ 25-akpm/arch/i386/kernel/process.c 2005-04-12 03:43:07.259362808 -0700
> @@ -653,12 +653,12 @@ struct task_struct fastcall * __switch_t
> asm volatile("mov %%gs,%0":"=m" (prev->gs));
>
> /*
> - * Restore %fs and %gs if needed.
> + * Clear selectors if needed:
> */
> - if (unlikely(prev->fs | prev->gs | next->fs | next->gs)) {
> - loadsegment(fs, next->fs);
> - loadsegment(gs, next->gs);
> - }
> + if (unlikely((prev->fs | prev->gs) && !(next->fs | next->gs))) {
> + loadsegment(fs, next->fs);
> + loadsegment(gs, next->gs);
> + }
>
> /*
> * Now maybe reload the debug registers
> diff -puN include/asm-i386/mmu_context.h~sched-unlocked-context-switches-fix include/asm-i386/mmu_context.h
> --- 25/include/asm-i386/mmu_context.h~sched-unlocked-context-switches-fix 2005-04-12 03:43:07.256363264 -0700
> +++ 25-akpm/include/asm-i386/mmu_context.h 2005-04-12 03:43:07.260362656 -0700
> @@ -61,6 +61,13 @@ static inline void switch_mm(struct mm_s
> }
> }
> #endif
> + /*
> + * Now that we've switched the LDT, load segments:
> + */
> + if (unlikely(current->thread.fs | current->thread.gs)) {
> + loadsegment(fs, current->thread.fs);
> + loadsegment(gs, current->thread.gs);
> + }
> }
>
> #define deactivate_mm(tsk, mm) \
> _
>
>
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-14 0:38 ` 2.6.12-rc2-mm3 Ed Tomlinson
@ 2005-04-14 0:54 ` Andrew Morton
0 siblings, 0 replies; 68+ messages in thread
From: Andrew Morton @ 2005-04-14 0:54 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: linux-kernel
Ed Tomlinson <tomlins@cam.org> wrote:
>
> On Wednesday 13 April 2005 20:20, Andrew Morton wrote:
> > Ed Tomlinson <tomlins@cam.org> wrote:
> > >
> > > > Don't think so - it works OK here. Checked the .config? Does the serial
> > > > port work if you do `echo foo > /dev/ttyS0'? ACPI?
> > >
> > > Turned out it was some old ups software that got reactivated on the box displaying the
> > > console - was a pain to disable it....
> >
> > OK.
> >
> > > In any case, when the box reboots there are not any messages. Any ideas on what debug
> > > options to enable or suggestions on how we can figure out the cause of the reboots.
> >
> > There were a few problems in the task switching area - maybe that.
>
> These hit arch/i386. Are they going to help on an x86_64 box?
nope.
^ permalink raw reply [flat|nested] 68+ messages in thread
* [-mm patch] fix "make mandocs"
2005-04-11 8:25 2.6.12-rc2-mm3 Andrew Morton
` (8 preceding siblings ...)
2005-04-12 11:32 ` 2.6.12-rc2-mm3 Ed Tomlinson
@ 2005-04-17 21:32 ` Adrian Bunk
2005-04-17 22:27 ` 2.6.12-rc2-mm3 Alexander Nyberg
` (4 subsequent siblings)
14 siblings, 0 replies; 68+ messages in thread
From: Adrian Bunk @ 2005-04-17 21:32 UTC (permalink / raw)
To: Andrew Morton, gregkh; +Cc: linux-kernel
On Mon, Apr 11, 2005 at 01:25:32AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.12-rc2-mm2:
>...
> gregkh-driver.patch
>...
Due to the removal of class_simple.c, "make mandocs" no longer works.
This patch fixes this issue.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.12-rc2-mm3-full/Documentation/DocBook/kernel-api.tmpl.old 2005-04-17 23:26:10.000000000 +0200
+++ linux-2.6.12-rc2-mm3-full/Documentation/DocBook/kernel-api.tmpl 2005-04-17 23:26:17.000000000 +0200
@@ -338,7 +338,6 @@
X!Iinclude/linux/device.h
-->
!Edrivers/base/driver.c
-!Edrivers/base/class_simple.c
!Edrivers/base/core.c
!Edrivers/base/firmware_class.c
!Edrivers/base/transport_class.c
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-11 8:25 2.6.12-rc2-mm3 Andrew Morton
` (9 preceding siblings ...)
2005-04-17 21:32 ` [-mm patch] fix "make mandocs" Adrian Bunk
@ 2005-04-17 22:27 ` Alexander Nyberg
2005-04-17 22:36 ` 2.6.12-rc2-mm3 Alexander Nyberg
` (3 subsequent siblings)
14 siblings, 0 replies; 68+ messages in thread
From: Alexander Nyberg @ 2005-04-17 22:27 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, mikpe
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>
>
[Mikael Pettersson on CC, would like your advice]
This patch fixes the NMI checking problems in -mm x64 for me. It
changes the perfctr selection to use RETIRED_UOPS instead
(makes both processors tick even on my box).
This makes the NMI tick once per second while running which is quite much,
I'd like to get it down to every fourth second and herein lies the problem.
Multiplying nmi_interval() in patch below with 4 does not help, still ticks
at about the same pace. I'm puzzled...
Index: x64_mm/arch/x86_64/kernel/nmi.c
===================================================================
--- x64_mm.orig/arch/x86_64/kernel/nmi.c 2005-04-17 14:34:09.000000000 +0200
+++ x64_mm/arch/x86_64/kernel/nmi.c 2005-04-18 02:11:37.000000000 +0200
@@ -58,7 +58,7 @@
int panic_on_timeout;
unsigned int nmi_watchdog = NMI_DEFAULT;
-static unsigned int nmi_hz = HZ;
+static unsigned long nmi_hz = HZ;
unsigned int nmi_perfctr_msr; /* the MSR to reset in NMI handler */
/* Note that these events don't tick when the CPU idles. This means
@@ -70,6 +70,7 @@
#define K7_EVNTSEL_USR (1 << 16)
#define K7_EVENT_CYCLES_PROCESSOR_IS_RUNNING 0x76
#define K7_NMI_EVENT K7_EVENT_CYCLES_PROCESSOR_IS_RUNNING
+#define K7_RETIRED_UOPS 0xC1 /* always running */
#define P6_EVNTSEL0_ENABLE (1 << 22)
#define P6_EVNTSEL_INT (1 << 20)
@@ -78,6 +79,11 @@
#define P6_EVENT_CPU_CLOCKS_NOT_HALTED 0x79
#define P6_NMI_EVENT P6_EVENT_CPU_CLOCKS_NOT_HALTED
+static inline unsigned long nmi_interval(void)
+{
+ return (((unsigned long)cpu_khz * 1000UL) / nmi_hz);
+}
+
/* Run after command line and cpu_init init, but before all other checks */
void __init nmi_watchdog_default(void)
{
@@ -129,8 +135,8 @@
for (cpu = 0; cpu < NR_CPUS; cpu++)
counts[cpu] = cpu_pda[cpu].__nmi_count;
- local_irq_enable();
- mdelay((10*1000)/nmi_hz); // wait 10 ticks
+
+ mdelay((10*1000) / nmi_hz); /* wait 10 NMI ticks */
for (cpu = 0; cpu < NR_CPUS; cpu++) {
if (cpu_pda[cpu].__nmi_count - counts[cpu] <= 5) {
@@ -305,9 +311,6 @@
int i;
unsigned int evntsel;
- /* No check, so can start with slow frequency */
- nmi_hz = 1;
-
/* XXX should check these in EFER */
nmi_perfctr_msr = MSR_K7_PERFCTR0;
@@ -322,10 +325,10 @@
evntsel = K7_EVNTSEL_INT
| K7_EVNTSEL_OS
| K7_EVNTSEL_USR
- | K7_NMI_EVENT;
+ | K7_RETIRED_UOPS;
wrmsr(MSR_K7_EVNTSEL0, evntsel, 0);
- wrmsrl(MSR_K7_PERFCTR0, -((u64)cpu_khz*1000) / nmi_hz);
+ wrmsrl(MSR_K7_PERFCTR0, -nmi_interval());
apic_write(APIC_LVTPC, APIC_DM_NMI);
evntsel |= K7_EVNTSEL_ENABLE;
wrmsr(MSR_K7_EVNTSEL0, evntsel, 0);
@@ -409,7 +412,7 @@
alert_counter[cpu] = 0;
}
if (nmi_perfctr_msr)
- wrmsr(nmi_perfctr_msr, -(cpu_khz/nmi_hz*1000), -1);
+ wrmsr(nmi_perfctr_msr, -nmi_interval(), -1);
}
static int dummy_nmi_callback(struct pt_regs * regs, int cpu)
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-11 8:25 2.6.12-rc2-mm3 Andrew Morton
` (10 preceding siblings ...)
2005-04-17 22:27 ` 2.6.12-rc2-mm3 Alexander Nyberg
@ 2005-04-17 22:36 ` Alexander Nyberg
2005-04-19 2:03 ` 2.6.12-rc2-mm3: hostap: do not #include .c files Adrian Bunk
` (2 subsequent siblings)
14 siblings, 0 replies; 68+ messages in thread
From: Alexander Nyberg @ 2005-04-17 22:36 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, vgoyal, ebiederm
mån 2005-04-11 klockan 01:25 -0700 skrev Andrew Morton:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>
I tried to kexec on my x64 and it hangs up in calibrate_delay() because
the PIT never fires any interrupts so jiffies is never updated. Has
kexec been tested on x64 and should be working? I want to know if I
should start looking at weirdness with my hardware or if it is like this
on all x64 boxes.
Also, patch at bottom is needed to compile kexec on x64 without ia32
emulation support (the includes are not used at the moment).
CC arch/x86_64/kernel/crash.o
In file included from arch/x86_64/kernel/crash.c:18:
include/linux/elfcore.h: I funktion `elf_core_copy_regs':
include/linux/elfcore.h:92: error: dereferencing pointer to incomplete type
include/linux/elfcore.h:92: error: dereferencing pointer to incomplete type
Index: x64_mm/arch/x86_64/kernel/crash.c
===================================================================
--- x64_mm.orig/arch/x86_64/kernel/crash.c 2005-04-16 19:23:58.000000000 +0200
+++ x64_mm/arch/x86_64/kernel/crash.c 2005-04-16 19:47:56.000000000 +0200
@@ -14,8 +14,6 @@
#include <linux/irq.h>
#include <linux/reboot.h>
#include <linux/kexec.h>
-#include <linux/elf.h>
-#include <linux/elfcore.h>
#include <asm/processor.h>
#include <asm/hardirq.h>
^ permalink raw reply [flat|nested] 68+ messages in thread* 2.6.12-rc2-mm3: hostap: do not #include .c files
2005-04-11 8:25 2.6.12-rc2-mm3 Andrew Morton
` (11 preceding siblings ...)
2005-04-17 22:36 ` 2.6.12-rc2-mm3 Alexander Nyberg
@ 2005-04-19 2:03 ` Adrian Bunk
2005-04-19 2:12 ` Jouni Malinen
2005-04-26 0:49 ` 2.6.12-rc2-mm3 Randy.Dunlap
2005-04-27 10:41 ` 2.6.12-rc2-mm3 Alexander Nyberg
14 siblings, 1 reply; 68+ messages in thread
From: Adrian Bunk @ 2005-04-19 2:03 UTC (permalink / raw)
To: Andrew Morton, jkmaline; +Cc: linux-kernel, hostap, jgarzik, netdev
On Mon, Apr 11, 2005 at 01:25:32AM -0700, Andrew Morton wrote:
>...
> All 819 patches:
>...
> bk-netdev.patch
>...
drivers/net/wireless/hostap/hostap.c:#include "hostap_crypt.c"
drivers/net/wireless/hostap/hostap.c:#include "hostap_ap.c"
drivers/net/wireless/hostap/hostap.c:#include "hostap_info.c"
drivers/net/wireless/hostap/hostap.c:#include "hostap_ioctl.c"
drivers/net/wireless/hostap/hostap.c:#include "hostap_proc.c"
drivers/net/wireless/hostap/hostap.c:#include "hostap_80211_rx.c"
drivers/net/wireless/hostap/hostap.c:#include "hostap_80211_tx.c"
drivers/net/wireless/hostap/hostap_cs.c:#include "hostap_hw.c"
drivers/net/wireless/hostap/hostap_hw.c:#include "hostap_download.c"
drivers/net/wireless/hostap/hostap_hw.c:#include "hostap_callback.c"
drivers/net/wireless/hostap/hostap_pci.c:#include "hostap_hw.c"
drivers/net/wireless/hostap/hostap_plx.c:#include "hostap_hw.c"
Please do not #include .c files.
A proper separation in a .c file and a header file is the better
solution.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3: hostap: do not #include .c files
2005-04-19 2:03 ` 2.6.12-rc2-mm3: hostap: do not #include .c files Adrian Bunk
@ 2005-04-19 2:12 ` Jouni Malinen
0 siblings, 0 replies; 68+ messages in thread
From: Jouni Malinen @ 2005-04-19 2:12 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, linux-kernel, hostap, jgarzik, netdev
On Tue, Apr 19, 2005 at 04:03:12AM +0200, Adrian Bunk wrote:
> drivers/net/wireless/hostap/hostap.c:#include "hostap_crypt.c"
> Please do not #include .c files.
A tested patch would be appreciated.. ;-)
> A proper separation in a .c file and a header file is the better
> solution.
Agreed and this is on my to-do list, but not very high on it. Some of
these would be relatively easy to fix, but the hardware specific ones
(different register offsets for PC Card/PLX/PCI) would require quite a
bit of changes to get rid of this.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-11 8:25 2.6.12-rc2-mm3 Andrew Morton
` (12 preceding siblings ...)
2005-04-19 2:03 ` 2.6.12-rc2-mm3: hostap: do not #include .c files Adrian Bunk
@ 2005-04-26 0:49 ` Randy.Dunlap
2005-04-26 1:06 ` 2.6.12-rc2-mm3 Andrew Morton
2005-04-26 3:17 ` 2.6.12-rc2-mm3 Greg KH
2005-04-27 10:41 ` 2.6.12-rc2-mm3 Alexander Nyberg
14 siblings, 2 replies; 68+ messages in thread
From: Randy.Dunlap @ 2005-04-26 0:49 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, greg, eike-kernel
On Mon, 11 Apr 2005 01:25:32 -0700
Andrew Morton <akpm@osdl.org> wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
I'm seeing some badness and a panic, goes away if I disable
PCI Express.
gargoyle login: Linux version 2.6.12-rc2-mm3 (rddunlap@gargoyle) (gcc version 3.3.3 (SuSE Linux)) #12 Mon Apr 25 16:25:48 PDT 2005
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
BIOS-e820: 000000003fff0000 - 000000003fff3000 (ACPI NVS)
BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
127MB HIGHMEM available.
896MB LOWMEM available.
On node 0 totalpages: 262128
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 225280 pages, LIFO batch:16
HighMem zone: 32752 pages, LIFO batch:7
DMI 2.3 present.
Allocating PCI resources starting at 40000000 (gap: 40000000:bec00000)
Built 1 zonelists
Initializing CPU#0
Kernel command line: auto BOOT_IMAGE=lin2612rc2mm3EX root=309 elevator=cfq splash=silent desktop showopts console=ttyS0,115200n8 console=tty0 crashkernel=64M@16M debug
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 1685.942 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x30
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 962204k/1048512k available (2603k kernel code, 85708k reserved, 1325k data, 224k init, 131008k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 3325.95 BogoMIPS (lpj=1662976)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 3febfbff 00000000 00000000 00000000 00000000 00000000 00000000
CPU: After vendor identify, caps: 3febfbff 00000000 00000000 00000000 00000000 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 256K
CPU: After all inits, caps: 3febfbf7 00000000 00000000 00000080 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU: Intel(R) Xeon(TM) CPU 1.70GHz stepping 02
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
softlockup thread 0 started up.
NET: Registered protocol family 16
EISA bus registered
PCI: PCI BIOS revision 2.10 entry at 0xfb110, last bus=4
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
Linux Plug and Play Support v0.97 (c) Adam Belay
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
Boot video device is 0000:01:00.0
PCI: Using IRQ router PIIX/ICH [8086/2440] at 0000:00:1f.0
fscache: general fs caching registered
CacheFS: general fs caching v0.1 registered
highmem bounce pool size: 64 pages
inotify device minor=63
Initializing Cryptographic API
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
fakephp: Fake PCI Hot Plug Controller Driver
Badness in kref_get at lib/kref.c:32
[<c1003368>] dump_stack+0x16/0x18
[<c10f7b32>] kref_get+0x28/0x32
[<c10f7173>] kobject_get+0x14/0x1c
[<c114b216>] get_bus+0x1a/0x2c
[<c114b0e1>] bus_add_driver+0x12/0x93
[<c13e67f7>] pcied_init+0x31/0x9d
[<c13da714>] do_initcalls+0x4e/0xa0
[<c10002a7>] init+0x25/0xce
[<c1000b09>] kernel_thread_helper+0x5/0xb
Badness in kref_get at lib/kref.c:32
[<c1003368>] dump_stack+0x16/0x18
[<c10f7b32>] kref_get+0x28/0x32
[<c10f7173>] kobject_get+0x14/0x1c
[<c10f6d52>] kobject_init+0x2c/0x3f
[<c10f7024>] kobject_register+0x17/0x4f
[<c114b118>] bus_add_driver+0x49/0x93
[<c13e67f7>] pcied_init+0x31/0x9d
[<c13da714>] do_initcalls+0x4e/0xa0
[<c10002a7>] init+0x25/0xce
[<c1000b09>] kernel_thread_helper+0x5/0xb
lib/kobject.c:171: spin_is_locked on uninitialized spinlock c133e1b8.
Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
c10f6f6f
*pde = 00000000
Oops: 0002 [#1]
DEBUG_PAGEALLOC
Modules linked in:
CPU: 0
EIP: 0060:[<c10f6f6f>] Not tainted VLI
EFLAGS: 00010292 (2.6.12-rc2-mm3)
EIP is at kobject_add+0xed/0x18b
eax: c133df00 ebx: c133dee4 ecx: 00000000 edx: c133e1b0
esi: ffffffea edi: c133e1d0 ebp: c6341f90 esp: c6341f84
ds: 007b es: 007b ss: 0068
Process swapper (pid: 1, threadinfo=c6340000 task=c631cac0)
Stack: c133dee4 ffffffea c133dee4 c6341fa8 c10f702a c133dee4 c133dee4 c133deb8
c133e120 c6341fc4 c114b118 c133dee4 00000000 00000000 00000000 00000000
c6341fd4 c13e67f7 c133deb8 c1408814 c6341fe4 c13da714 c1000282 00000000
Call Trace:
[<c100334a>] show_stack+0x7a/0x82
[<c1003453>] show_registers+0xe9/0x153
[<c100369f>] die+0x15c/0x23d
[<c100e962>] do_page_fault+0x431/0x5a8
[<c1002ed3>] error_code+0x4f/0x54
[<c10f702a>] kobject_register+0x1d/0x4f
[<c114b118>] bus_add_driver+0x49/0x93
[<c13e67f7>] pcied_init+0x31/0x9d
[<c13da714>] do_initcalls+0x4e/0xa0
[<c10002a7>] init+0x25/0xce
[<c1000b09>] kernel_thread_helper+0x5/0xb
Code: 28 c7 40 24 ab 00 00 00 75 0f 8b 43 28 83 c0 28 50 e8 05 02 00 00 89 c7 58 8b 53 28 8d 43 1c 83 c2 08 89 53 1c 8b 4a 04 89 42 04 <89> 01 89 48 04 8b 43 28 81 78 10 3c 4b 24 1d 74 1b 83 c0 10 50
<0>Kernel panic - not syncing: Attempted to kill init!
--
~Randy
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.12-rc2-mm3
2005-04-26 0:49 ` 2.6.12-rc2-mm3 Randy.Dunlap
@ 2005-04-26 1:06 ` Andrew Morton
2005-04-26 3:17 ` 2.6.12-rc2-mm3 Greg KH
1 sibling, 0 replies; 68+ messages in thread
From: Andrew Morton @ 2005-04-26 1:06 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: linux-kernel, greg, eike-kernel
"Randy.Dunlap" <rddunlap@osdl.org> wrote:
>
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>
>
> I'm seeing some badness and a panic, goes away if I disable
> PCI Express.
OK, it looks like Greg's stuff broke. I'm not in much of a position to
think about this at present - please keep an eye on things as -mm ramps up
again, remind us if it's still happening?
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-26 0:49 ` 2.6.12-rc2-mm3 Randy.Dunlap
2005-04-26 1:06 ` 2.6.12-rc2-mm3 Andrew Morton
@ 2005-04-26 3:17 ` Greg KH
2005-04-26 16:15 ` 2.6.12-rc2-mm3 Randy.Dunlap
1 sibling, 1 reply; 68+ messages in thread
From: Greg KH @ 2005-04-26 3:17 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: Andrew Morton, linux-kernel, eike-kernel
On Mon, Apr 25, 2005 at 05:49:00PM -0700, Randy.Dunlap wrote:
> On Mon, 11 Apr 2005 01:25:32 -0700
> Andrew Morton <akpm@osdl.org> wrote:
>
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>
>
> I'm seeing some badness and a panic, goes away if I disable
> PCI Express.
>
> pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> fakephp: Fake PCI Hot Plug Controller Driver
> Badness in kref_get at lib/kref.c:32
> [<c1003368>] dump_stack+0x16/0x18
> [<c10f7b32>] kref_get+0x28/0x32
> [<c10f7173>] kobject_get+0x14/0x1c
> [<c114b216>] get_bus+0x1a/0x2c
> [<c114b0e1>] bus_add_driver+0x12/0x93
> [<c13e67f7>] pcied_init+0x31/0x9d
> [<c13da714>] do_initcalls+0x4e/0xa0
> [<c10002a7>] init+0x25/0xce
> [<c1000b09>] kernel_thread_helper+0x5/0xb
> Badness in kref_get at lib/kref.c:32
> [<c1003368>] dump_stack+0x16/0x18
> [<c10f7b32>] kref_get+0x28/0x32
> [<c10f7173>] kobject_get+0x14/0x1c
> [<c10f6d52>] kobject_init+0x2c/0x3f
> [<c10f7024>] kobject_register+0x17/0x4f
> [<c114b118>] bus_add_driver+0x49/0x93
> [<c13e67f7>] pcied_init+0x31/0x9d
> [<c13da714>] do_initcalls+0x4e/0xa0
> [<c10002a7>] init+0x25/0xce
> [<c1000b09>] kernel_thread_helper+0x5/0xb
> lib/kobject.c:171: spin_is_locked on uninitialized spinlock c133e1b8.
Hm, what happens if you disable the fakephp driver? I haven't tried
that out with pci express. Do you have pci express slots on this box?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-26 3:17 ` 2.6.12-rc2-mm3 Greg KH
@ 2005-04-26 16:15 ` Randy.Dunlap
0 siblings, 0 replies; 68+ messages in thread
From: Randy.Dunlap @ 2005-04-26 16:15 UTC (permalink / raw)
To: Greg KH; +Cc: akpm, linux-kernel, eike-kernel
On Mon, 25 Apr 2005 20:17:50 -0700
Greg KH <greg@kroah.com> wrote:
> On Mon, Apr 25, 2005 at 05:49:00PM -0700, Randy.Dunlap wrote:
> > On Mon, 11 Apr 2005 01:25:32 -0700
> > Andrew Morton <akpm@osdl.org> wrote:
> >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
> >
> >
> > I'm seeing some badness and a panic, goes away if I disable
> > PCI Express.
> >
> > pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> > fakephp: Fake PCI Hot Plug Controller Driver
> > Badness in kref_get at lib/kref.c:32
> > [<c1003368>] dump_stack+0x16/0x18
> > [<c10f7b32>] kref_get+0x28/0x32
> > [<c10f7173>] kobject_get+0x14/0x1c
> > [<c114b216>] get_bus+0x1a/0x2c
> > [<c114b0e1>] bus_add_driver+0x12/0x93
> > [<c13e67f7>] pcied_init+0x31/0x9d
> > [<c13da714>] do_initcalls+0x4e/0xa0
> > [<c10002a7>] init+0x25/0xce
> > [<c1000b09>] kernel_thread_helper+0x5/0xb
> > Badness in kref_get at lib/kref.c:32
> > [<c1003368>] dump_stack+0x16/0x18
> > [<c10f7b32>] kref_get+0x28/0x32
> > [<c10f7173>] kobject_get+0x14/0x1c
> > [<c10f6d52>] kobject_init+0x2c/0x3f
> > [<c10f7024>] kobject_register+0x17/0x4f
> > [<c114b118>] bus_add_driver+0x49/0x93
> > [<c13e67f7>] pcied_init+0x31/0x9d
> > [<c13da714>] do_initcalls+0x4e/0xa0
> > [<c10002a7>] init+0x25/0xce
> > [<c1000b09>] kernel_thread_helper+0x5/0xb
> > lib/kobject.c:171: spin_is_locked on uninitialized spinlock c133e1b8.
>
> Hm, what happens if you disable the fakephp driver? I haven't tried
> that out with pci express. Do you have pci express slots on this box?
Same still happens without fakephp (this is in pciehp_core).
Same OOPS still happens also (pcied_init near middle of stack trace).
No, I don't have *any* PCI Express slots....
--
~Randy
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.12-rc2-mm3
2005-04-11 8:25 2.6.12-rc2-mm3 Andrew Morton
` (13 preceding siblings ...)
2005-04-26 0:49 ` 2.6.12-rc2-mm3 Randy.Dunlap
@ 2005-04-27 10:41 ` Alexander Nyberg
14 siblings, 0 replies; 68+ messages in thread
From: Alexander Nyberg @ 2005-04-27 10:41 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, vgoyal
The two functions:
crash_kexec()
smp_send_stop()
called from panic() wants preempt to be disabled which it may not be if
coming from a direct panic assertion (and not via the do_exit
assertions...).
Signed-off-by: Alexander Nyberg <alexn@telia.com>
Index: mm/kernel/panic.c
===================================================================
--- mm.orig/kernel/panic.c 2005-04-26 11:15:29.000000000 +0200
+++ mm/kernel/panic.c 2005-04-26 23:18:07.000000000 +0200
@@ -64,6 +64,12 @@
unsigned long caller = (unsigned long) __builtin_return_address(0);
#endif
+ /* It's possible to come here directly from a panic-assertion and not
+ * have preempt disabled. Some functions called from here want
+ * preempt to be disabled. No point enabling it later though...
+ */
+ preempt_disable();
+
bust_spinlocks(1);
va_start(args, fmt);
vsnprintf(buf, sizeof(buf), fmt, args);
^ permalink raw reply [flat|nested] 68+ messages in thread