Re: [OOPS] repeatable 2.4.8-ac7, 2.4.7-ac6 just run xdos

Re: [OOPS] repeatable 2.4.8-ac7, 2.4.7-ac6 just run xdos

[Andi Kleen]

Brian Gerst <bgerst@didntduck.org> writes:

> > 
> > CPU:    0
> > EIP:    0010:[<c0180a18>]
> > Using defaults from ksymoops -t elf32-i386 -a i386
> > EFLAGS: 00010002
> > eax: 00001000   ebx: c4562368   ecx: 00000000   edx: 00000001
> > esi: c4562368   edi: c4a954d4   ebp: 00000001   esp: c6887d88
> > ds: 008   es: 0000   ss: 0018
>                 ^^^^
> Here is your problem.  %es is set to the null segment.  I had my
> suspicions about the segment reload optimisation in the -ac kernels, and
> this proves it.  Try backing out the changes to arch/i386/kernel/entry.S
> and include/asm-i386/hw_irq.h and see if that fixes the problem.

This patch should fix the problem. One assumption coded into the reload
optimization is violated by vm86 mode. Please test.

--- linux-2.4.8-ac7-work/include/asm-i386/hw_irq.h-SEG2	Mon Aug 20 02:54:53 2001
+++ linux-2.4.8-ac7-work/include/asm-i386/hw_irq.h	Wed Aug 22 13:02:16 2001
@@ -114,8 +114,10 @@
 	"cmpl %eax,7*4(%esp)\n\t"  \
 	"je 1f\n\t"  \
 	"movl %eax,%ds\n\t" \
+	"1: cmpl %eax,8*4(%esp)\n\t" \
+	"je 2f\n\t" \
 	"movl %eax,%es\n\t" \
-	"1:\n\t"
+	"2:\n\t"
 
 #define IRQ_NAME2(nr) nr##_interrupt(void)
 #define IRQ_NAME(nr) IRQ_NAME2(IRQ##nr)


-Andi

Re: [OOPS] repeatable 2.4.8-ac7, 2.4.7-ac6 just run xdos

[Brian Gerst]

Andi Kleen wrote:
> 
> Brian Gerst <bgerst@didntduck.org> writes:
> 
> > >
> > > CPU:    0
> > > EIP:    0010:[<c0180a18>]
> > > Using defaults from ksymoops -t elf32-i386 -a i386
> > > EFLAGS: 00010002
> > > eax: 00001000   ebx: c4562368   ecx: 00000000   edx: 00000001
> > > esi: c4562368   edi: c4a954d4   ebp: 00000001   esp: c6887d88
> > > ds: 008   es: 0000   ss: 0018
> >                 ^^^^
> > Here is your problem.  %es is set to the null segment.  I had my
> > suspicions about the segment reload optimisation in the -ac kernels, and
> > this proves it.  Try backing out the changes to arch/i386/kernel/entry.S
> > and include/asm-i386/hw_irq.h and see if that fixes the problem.
> 
> This patch should fix the problem. One assumption coded into the reload
> optimization is violated by vm86 mode. Please test.

Yes.  What happened here is that %ds and %es were not being updated
atomically.  Under normal operation, this would just leave %es with
USER_DS, which is sufficiently equivalent to KERNEL_DS to not cause a
fault.  Coming out of vm86 mode however forces the data segment
registers to null after saving the real mode values on the stack.  If an
interrupt happened between setting %ds and %es (what are the odds?) then
that assumption would fail and leave %es null, causing the next string
instruction to go boom.  The same fix should be applied to entry.S as
well.

-- 

						Brian Gerst

Re: [OOPS] repeatable 2.4.8-ac7, 2.4.7-ac6 just run xdos

[Andi Kleen]

On Wed, Aug 22, 2001 at 07:57:59AM -0400, Brian Gerst wrote:
> Yes.  What happened here is that %ds and %es were not being updated
> atomically.  Under normal operation, this would just leave %es with
> USER_DS, which is sufficiently equivalent to KERNEL_DS to not cause a
> fault.  Coming out of vm86 mode however forces the data segment
> registers to null after saving the real mode values on the stack.  If an
> interrupt happened between setting %ds and %es (what are the odds?) then
> that assumption would fail and leave %es null, causing the next string
> instruction to go boom.  The same fix should be applied to entry.S as
> well.

No that's not the problem. interrupt gates come in with interrupts off, 
so there are no other interrupts that could race here. The syscall entry
always updates %ds/%es unconditionally and %ds first, so there is no
race.

It was much simpler. It assumed that __KERNEL_DS could not be loaded 
from user space because of the segment register priviledge checking; and
that was obviously not true from vm86 mode.

-Andi

Re: [OOPS] repeatable 2.4.8-ac7, 2.4.7-ac6 just run xdos

[Brian Gerst]

Andi Kleen wrote:
> 
> On Wed, Aug 22, 2001 at 07:57:59AM -0400, Brian Gerst wrote:
> > Yes.  What happened here is that %ds and %es were not being updated
> > atomically.  Under normal operation, this would just leave %es with
> > USER_DS, which is sufficiently equivalent to KERNEL_DS to not cause a
> > fault.  Coming out of vm86 mode however forces the data segment
> > registers to null after saving the real mode values on the stack.  If an
> > interrupt happened between setting %ds and %es (what are the odds?) then
> > that assumption would fail and leave %es null, causing the next string
> > instruction to go boom.  The same fix should be applied to entry.S as
> > well.
> 
> No that's not the problem. interrupt gates come in with interrupts off,
> so there are no other interrupts that could race here. The syscall entry
> always updates %ds/%es unconditionally and %ds first, so there is no
> race.
> 
> It was much simpler. It assumed that __KERNEL_DS could not be loaded
> from user space because of the segment register priviledge checking; and
> that was obviously not true from vm86 mode.
> 
> -Andi

The kernel was initially entered throught the general protection fault
trap gate, with interupts on.  The syscall entry was left on the stack
because of the way sys_vm86 works.

-- 

						Brian Gerst

Re: [OOPS] repeatable 2.4.8-ac7, 2.4.7-ac6 just run xdos

[Andi Kleen]

On Wed, Aug 22, 2001 at 08:11:40AM -0400, Brian Gerst wrote:
> Andi Kleen wrote:
> > 
> > On Wed, Aug 22, 2001 at 07:57:59AM -0400, Brian Gerst wrote:
> > > Yes.  What happened here is that %ds and %es were not being updated
> > > atomically.  Under normal operation, this would just leave %es with
> > > USER_DS, which is sufficiently equivalent to KERNEL_DS to not cause a
> > > fault.  Coming out of vm86 mode however forces the data segment
> > > registers to null after saving the real mode values on the stack.  If an
> > > interrupt happened between setting %ds and %es (what are the odds?) then
> > > that assumption would fail and leave %es null, causing the next string
> > > instruction to go boom.  The same fix should be applied to entry.S as
> > > well.
> > 
> > No that's not the problem. interrupt gates come in with interrupts off,
> > so there are no other interrupts that could race here. The syscall entry
> > always updates %ds/%es unconditionally and %ds first, so there is no
> > race.
> > 
> > It was much simpler. It assumed that __KERNEL_DS could not be loaded
> > from user space because of the segment register priviledge checking; and
> > that was obviously not true from vm86 mode.
> > 
> > -Andi
> 
> The kernel was initially entered throught the general protection fault
> trap gate, with interupts on.  The syscall entry was left on the stack
> because of the way sys_vm86 works.

The GPF handler first sets %ds then %es. Interrupt checks %ds first.
I don't see any race, as soon as %ds is changed the interrupt handler does
the right thing (not reloading), and before that also.

The check I added with the previous patch for ds and es being out of 
sync however was also missing from exception handler entry. That probably
caused the crash.

Here is a new patch with both checks.


--- include/asm-i386/hw_irq.h-SEG2	Mon Aug 20 02:54:53 2001
+++ include/asm-i386/hw_irq.h	Wed Aug 22 13:02:16 2001
@@ -114,8 +114,10 @@
 	"cmpl %eax,7*4(%esp)\n\t"  \
 	"je 1f\n\t"  \
 	"movl %eax,%ds\n\t" \
+	"1: cmpl %eax,8*4(%esp)\n\t" \
+	"je 2f\n\t" \
 	"movl %eax,%es\n\t" \
-	"1:\n\t"
+	"2:\n\t"
 
 #define IRQ_NAME2(nr) nr##_interrupt(void)
 #define IRQ_NAME(nr) IRQ_NAME2(IRQ##nr)
--- arch/i386/kernel/entry.S-SEG2	Sat Aug 18 08:41:53 2001
+++ arch/i386/kernel/entry.S	Wed Aug 22 15:07:44 2001
@@ -292,8 +292,11 @@
 	cmpl %edx,%ecx
 	jz	1f
 	movl %edx,%ds
+1:	movl %ds,%ecx
+	cmpl $(__KERNEL_DS),%edx
+	jz   2f	
 	movl %edx,%es
-1:	GET_CURRENT(%ebx)
+2:	GET_CURRENT(%ebx)
 	call *%edi
 	addl $8,%esp
 	jmp ret_from_exception


-Andi

Re: [OOPS] repeatable 2.4.8-ac7, 2.4.7-ac6 just run xdos

[Paul]

Andi Kleen <ak@suse.de>, on Wed Aug 22, 2001 [03:22:03 PM] said:
> 
> Here is a new patch with both checks.
> 

	Dear Andi;

	Well, with this patch, the kernel doesnt oops, but vm86
seems to be busted now. save_v86_state() pops out:
	'vm86: could not access userspace vm86_info'
and gives dosemu a segv.

Paul
set@pobox.com

> 
> --- include/asm-i386/hw_irq.h-SEG2	Mon Aug 20 02:54:53 2001
> +++ include/asm-i386/hw_irq.h	Wed Aug 22 13:02:16 2001
> @@ -114,8 +114,10 @@
>  	"cmpl %eax,7*4(%esp)\n\t"  \
>  	"je 1f\n\t"  \
>  	"movl %eax,%ds\n\t" \
> +	"1: cmpl %eax,8*4(%esp)\n\t" \
> +	"je 2f\n\t" \
>  	"movl %eax,%es\n\t" \
> -	"1:\n\t"
> +	"2:\n\t"
>  
>  #define IRQ_NAME2(nr) nr##_interrupt(void)
>  #define IRQ_NAME(nr) IRQ_NAME2(IRQ##nr)
> --- arch/i386/kernel/entry.S-SEG2	Sat Aug 18 08:41:53 2001
> +++ arch/i386/kernel/entry.S	Wed Aug 22 15:07:44 2001
> @@ -292,8 +292,11 @@
>  	cmpl %edx,%ecx
>  	jz	1f
>  	movl %edx,%ds
> +1:	movl %ds,%ecx
> +	cmpl $(__KERNEL_DS),%edx
> +	jz   2f	
>  	movl %edx,%es
> -1:	GET_CURRENT(%ebx)
> +2:	GET_CURRENT(%ebx)
>  	call *%edi
>  	addl $8,%esp
>  	jmp ret_from_exception
> 
> 
> -Andi

Re: [OOPS] repeatable 2.4.8-ac7, 2.4.7-ac6 just run xdos

[Andi Kleen]

On Wed, Aug 22, 2001 at 03:52:26PM -0400, Paul wrote:
> Andi Kleen <ak@suse.de>, on Wed Aug 22, 2001 [03:22:03 PM] said:
> > 
> > Here is a new patch with both checks.
> > 
> 
> 	Dear Andi;
> 
> 	Well, with this patch, the kernel doesnt oops, but vm86
> seems to be busted now. save_v86_state() pops out:
> 	'vm86: could not access userspace vm86_info'
> and gives dosemu a segv.

I found the problem in the previous patch. Here is an updated one.
Please test again. Again against -ac7 (or later if Alan hasn't applied 
the earlier patch) 


-Andi




--- include/asm-i386/hw_irq.h-SEG2	Mon Aug 20 02:54:53 2001
+++ include/asm-i386/hw_irq.h	Wed Aug 22 13:02:16 2001
@@ -114,8 +114,10 @@
 	"cmpl %eax,7*4(%esp)\n\t"  \
 	"je 1f\n\t"  \
 	"movl %eax,%ds\n\t" \
+	"1: cmpl %eax,8*4(%esp)\n\t" \
+	"je 2f\n\t" \
 	"movl %eax,%es\n\t" \
-	"1:\n\t"
+	"2:\n\t"
 
 #define IRQ_NAME2(nr) nr##_interrupt(void)
 #define IRQ_NAME(nr) IRQ_NAME2(IRQ##nr)
--- arch/i386/kernel/entry.S-SEG2	Sat Aug 18 08:41:53 2001
+++ arch/i386/kernel/entry.S	Thu Aug 23 15:20:21 2001
@@ -291,9 +291,11 @@
 	movl $(__KERNEL_DS),%edx
 	cmpl %edx,%ecx
 	jz	1f
-	movl %edx,%ds
 	movl %edx,%es
-1:	GET_CURRENT(%ebx)
+1:	cmpl %edx,9*4(%esp)	# check ds on the stack
+	jz   2f	
+	movl %edx,%ds
+2:	GET_CURRENT(%ebx)
 	call *%edi
 	addl $8,%esp
 	jmp ret_from_exception

Re: [OOPS] repeatable 2.4.8-ac7, 2.4.7-ac6 just run xdos

[Paul]

Andi Kleen <ak@suse.de>, on Thu Aug 23, 2001 [03:34:19 PM] said:

> I found the problem in the previous patch. Here is an updated one.
> Please test again. Again against -ac7 (or later if Alan hasn't applied 
> the earlier patch) 
> 
> 
> -Andi
> 
> 
	Good! I have beaten on this a bit, and it is holding up
for me, and there are no problems using dosemu. My thanks to
everyone who responded to this bug.

Paul
set@pobox.com

> 
> 
> --- include/asm-i386/hw_irq.h-SEG2	Mon Aug 20 02:54:53 2001
> +++ include/asm-i386/hw_irq.h	Wed Aug 22 13:02:16 2001
> @@ -114,8 +114,10 @@
>  	"cmpl %eax,7*4(%esp)\n\t"  \
>  	"je 1f\n\t"  \
>  	"movl %eax,%ds\n\t" \
> +	"1: cmpl %eax,8*4(%esp)\n\t" \
> +	"je 2f\n\t" \
>  	"movl %eax,%es\n\t" \
> -	"1:\n\t"
> +	"2:\n\t"
>  
>  #define IRQ_NAME2(nr) nr##_interrupt(void)
>  #define IRQ_NAME(nr) IRQ_NAME2(IRQ##nr)
> --- arch/i386/kernel/entry.S-SEG2	Sat Aug 18 08:41:53 2001
> +++ arch/i386/kernel/entry.S	Thu Aug 23 15:20:21 2001
> @@ -291,9 +291,11 @@
>  	movl $(__KERNEL_DS),%edx
>  	cmpl %edx,%ecx
>  	jz	1f
> -	movl %edx,%ds
>  	movl %edx,%es
> -1:	GET_CURRENT(%ebx)
> +1:	cmpl %edx,9*4(%esp)	# check ds on the stack
> +	jz   2f	
> +	movl %edx,%ds
> +2:	GET_CURRENT(%ebx)
>  	call *%edi
>  	addl $8,%esp
>  	jmp ret_from_exception

Re: [OOPS] repeatable 2.4.8-ac7, 2.4.7-ac6 just run xdos

[Wayne Whitney]

In mailing-lists.linux-kernel, you wrote:

> 	Good! I have beaten on this a bit, and it is holding up
> for me, and there are no problems using dosemu. My thanks to
> everyone who responded to this bug.

FWIW, "me too" on 2.4.8-ac9.  dos -X would lock the machine after
about 15 minutes (Alt-Sysrq-B would work), with this patch it is gone.

Wayne

Re: [OOPS] repeatable 2.4.8-ac7, 2.4.7-ac6 just run xdos

[Brian Gerst]

Paul wrote:
> 
> * Kernel oops, and locks up when I run xdos (dosemu)
> 
> * Occuring in both 2.4.7-ac6 and 2.4.8-ac7. Run 'xdos' in X, and
>   machine locks hard, only output to console is oops. (no sysrq)
>   Tried once with strace, but no oops. (didnt wait long, though)
>   Some oops before window is placed, some a little while after.
>   (mouse movement?) Repeatable.
> 
> * Kernels are virgin linus patched with ac. AMD-K6(tm) 3D
>   processor
> 
> * If anyone wants any more info or for me to do anything, just
>   ask.
> 
> Paul
> set@pobox.com
> 
> (2.4.7-ac6 -- two captured, identitcal, first shown)
> 
> ksymoops 2.4.1 on i586 2.4.7-ac6.  Options used
>      -V (default)
>      -k /proc/ksyms (default)
>      -l /proc/modules (default)
>      -o /lib/modules/2.4.7-ac6/ (default)
>      -m /boot/System.map-2.4.7-ac6 (specified)
> 
> CPU:    0
> EIP:    0010:[<c0180a18>]
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010002
> eax: 00001000   ebx: c4562368   ecx: 00000000   edx: 00000001
> esi: c4562368   edi: c4a954d4   ebp: 00000001   esp: c6887d88
> ds: 008   es: 0000   ss: 0018
                ^^^^
Here is your problem.  %es is set to the null segment.  I had my
suspicions about the segment reload optimisation in the -ac kernels, and
this proves it.  Try backing out the changes to arch/i386/kernel/entry.S
and include/asm-i386/hw_irq.h and see if that fixes the problem.

-- 

						Brian Gerst

Re: [OOPS] repeatable 2.4.8-ac7, 2.4.7-ac6 just run xdos

[Eric W. Biederman]

Jeff Chua <jeffchua@silk.corp.fedex.com> writes:

> On Sun, 19 Aug 2001, Paul wrote:
> > 	Actually, it works fine for me too, _if_ I use DOS 5 as
> > the boot image, but I changed to DOS 6.22, and its has oops'd
> > every time Ive tried it that way. Its just a trigger for whatever
> > the real problem is.
> >
> > Paul
> > set@pobox.com
> 
> I'm using dosemu-1.1.1.tgz with Windows 98 [Version 4.10.2222]
> 
> Does "dos" command works for you instead of "xdos" ?
> 
> Did you check your shmmax?
> 
> Try ...
> 	echo 1000000000 >/proc/sys/kernel/shmmax

This should be totally irrelevant.  You shouldn't be able to
crash linux with dosemu unless you are doing direct hardware access.

There are a number of cases, where dosemu is different enough it has
been known to cause code to go down buggy non-common paths and cause
things to fail.  This has happened with both X and the kernel.
I suspect that is what is happening here.

Paul is dosemu configured to do any direct hardware access?

Also of interest is that this crash is not even directly triggered by
the dosemu process.  Instead an interrupt handler is doing something
bad.  

Paul If you can verify that dosemu isn't doing any direct hardware
access.  i.e. Dosemu isn't suid root, and you have no ports lines
you should be fine.

Eric

Re: [OOPS] repeatable 2.4.8-ac7, 2.4.7-ac6 just run xdos

[Jeff Chua]

On Sun, 19 Aug 2001, Paul wrote:
> 	Actually, it works fine for me too, _if_ I use DOS 5 as
> the boot image, but I changed to DOS 6.22, and its has oops'd
> every time Ive tried it that way. Its just a trigger for whatever
> the real problem is.
>
> Paul
> set@pobox.com

I'm using dosemu-1.1.1.tgz with Windows 98 [Version 4.10.2222]

Does "dos" command works for you instead of "xdos" ?

Did you check your shmmax?

Try ...
	echo 1000000000 >/proc/sys/kernel/shmmax



Jeff

Re: [OOPS] repeatable 2.4.8-ac7, 2.4.7-ac6 just run xdos

[Paul]

Jeff Chua <jchua@fedex.com>, on Sun Aug 19, 2001 [01:09:26 PM] said:
> xdos runs fine for me for all of 2.4.x. Mine is P3.
> 
> Thanks,
> Jeff
> [ jchua@fedex.com ]
> 

	Actually, it works fine for me too, _if_ I use DOS 5 as
the boot image, but I changed to DOS 6.22, and its has oops'd
every time Ive tried it that way. Its just a trigger for whatever
the real problem is.

Paul
set@pobox.com

Re: [OOPS] repeatable 2.4.8-ac7, 2.4.7-ac6 just run xdos

[Jeff Chua]

Xdos runs fine for me for all of 2.4.x. Mine is P3.

Thanks,
Jeff
[ jchua@fedex.com ]

On Sun, 19 Aug 2001, Paul wrote:

> * Kernel oops, and locks up when I run xdos (dosemu)
>
> * Occuring in both 2.4.7-ac6 and 2.4.8-ac7. Run 'xdos' in X, and
>   machine locks hard, only output to console is oops. (no sysrq)
>   Tried once with strace, but no oops. (didnt wait long, though)
>   Some oops before window is placed, some a little while after.
>   (mouse movement?) Repeatable.
>
> * Kernels are virgin linus patched with ac. AMD-K6(tm) 3D
>   processor
>
> * If anyone wants any more info or for me to do anything, just
>   ask.
>
> Paul
> set@pobox.com
>
> (2.4.7-ac6 -- two captured, identitcal, first shown)
>
> ksymoops 2.4.1 on i586 2.4.7-ac6.  Options used
>      -V (default)
>      -k /proc/ksyms (default)
>      -l /proc/modules (default)
>      -o /lib/modules/2.4.7-ac6/ (default)
>      -m /boot/System.map-2.4.7-ac6 (specified)
>
> CPU:    0
> EIP:    0010:[<c0180a18>]
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010002
> eax: 00001000   ebx: c4562368   ecx: 00000000   edx: 00000001
> esi: c4562368   edi: c4a954d4   ebp: 00000001   esp: c6887d88
> ds: 008   es: 0000   ss: 0018
> Process xdos (pid: 28039, stackpage=c6887000)
> Stack: c4562768 c4562368 00000001 00000000 c4562000 c4a954d4 00000202 00000001
>        00000001 c0181815 c4562000 c4562568 c4562168 00000001 00000000 0000000e
>        00000001 00000202 00000000 00000282 0000000e c0117554 0000000e 00000001
> Call Trace: [<c0181815>] [<c0117554>] [<c01173cc>] [<c01174ac>] [<c017fc3f>]
>    [<c0113e24>] [<c01163f6>] [<c0113d7e>] [<c0113c61>] [<c01139fb>] [<c0107ece>]
>    [<c010760c>] [<c0109cfe>] [<c010760c>] [<c0106bed>] [<c0106ad3>]
> Code: a4 8b 7c 24 1c 8b 8c 24 b0 00 00 00 01 d3 29 d5 ba 00 10 00
>
> >>EIP; c0180a18 <n_tty_receive_buf+a4/edc>   <=====
> Trace; c0181815 <n_tty_receive_buf+ea1/edc>
> Trace; c0117554 <send_sig_info+74/98>
> Trace; c01173cc <send_signal+2c/f0>
> Trace; c01174ac <deliver_signal+1c/50>
> Trace; c017fc3f <flush_to_ldisc+db/e4>
> Trace; c0113e24 <__run_task_queue+4c/60>
> Trace; c01163f6 <tqueue_bh+16/1c>
> Trace; c0113d7e <bh_action+1a/30>
> Trace; c0113c61 <tasklet_hi_action+51/b4>
> Trace; c01139fb <do_softirq+5b/ac>
> Trace; c0107ece <do_IRQ+9e/b0>
> Trace; c010760c <do_general_protection+0/6c>
> Trace; c0109cfe <call_do_IRQ+5/17>
> Trace; c010760c <do_general_protection+0/6c>
> Trace; c0106bed <error_code+2d/40>
> Trace; c0106ad3 <system_call+33/40>
> Code;  c0180a18 <n_tty_receive_buf+a4/edc>
> 00000000 <_EIP>:
> Code;  c0180a18 <n_tty_receive_buf+a4/edc>   <=====
>    0:   a4                        movsb  %ds:(%esi),%es:(%edi)   <=====
> Code;  c0180a19 <n_tty_receive_buf+a5/edc>
>    1:   8b 7c 24 1c               mov    0x1c(%esp,1),%edi
> Code;  c0180a1d <n_tty_receive_buf+a9/edc>
>    5:   8b 8c 24 b0 00 00 00      mov    0xb0(%esp,1),%ecx
> Code;  c0180a24 <n_tty_receive_buf+b0/edc>
>    c:   01 d3                     add    %edx,%ebx
> Code;  c0180a26 <n_tty_receive_buf+b2/edc>
>    e:   29 d5                     sub    %edx,%ebp
> Code;  c0180a28 <n_tty_receive_buf+b4/edc>
>   10:   ba 00 10 00 00            mov    $0x1000,%edx
>
>  <0>Kernel panic: Aiee, killing interrupt handler!
>
> ===================================================================
>
> (2.4.8-ac7)
>
> ksymoops 2.4.1 on i586 2.4.8-ac7.  Options used
>      -V (default)
>      -k /proc/ksyms (default)
>      -l /proc/modules (default)
>      -o /lib/modules/2.4.8-ac7/ (default)
>      -m /boot/System.map-2.4.8-ac7 (specified)
>
> CPU:    0
> EIP:    0010:[<c0180ab8>]
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010002
> eax: 00001000   ebx: c77dc168   ecx: 00000000   edx: 00000001
> esi: c77dc168   edi: c524c1aa   ebp: 00000001   esp: c7195d88
> ds: 0018   es: 0000   ss: 0018
> Process xdos (pid: 252, stackpage=c7195000)
> Stack: c77dc568 c77dc168 00000000 00000000 00000046 c7195dbc 00000202 00000001
>        007dc000 c524c1aa c77dc984 00000282 00000001 c01818b5 c77dc000 c77dc768
>       c77dc368 00000000 00000000 00000286 0000000e 00000202 00000000 00000001
> Call Trace: [<c01818b5>] [<c0112fe4>] [<c011735c>] [<c011743c>] [<c017fcdf>]
>    [<c0113d94>] [<c0116366>] [<c0113cde>] [<c0113c12>] [<c0113a3b>] [<c0107eee>]
>    [<c010762c>] [<c0109d1e>] [<c010762c>] [<c0106c0d>] [<c0106af3>]
> Code: a4 8b 7c 24 1c 8b 8c 24 b0 00 00 00 01 d3 29 d5 ba 00 10 00
>
> >>EIP; c0180ab8 <n_tty_receive_buf+a4/edc>   <=====
> Trace; c01818b5 <n_tty_receive_buf+ea1/edc>
> Trace; c0112fe4 <it_real_fn+0/44>
> Trace; c011735c <send_signal+2c/f0>
> Trace; c011743c <deliver_signal+1c/50>
> Trace; c017fcdf <flush_to_ldisc+db/e4>
> Trace; c0113d94 <__run_task_queue+4c/60>
> Trace; c0116366 <tqueue_bh+16/1c>
> Trace; c0113cde <bh_action+1a/40>
> Trace; c0113c12 <tasklet_hi_action+42/64>
> Trace; c0113a3b <do_softirq+5b/ac>
> Trace; c0107eee <do_IRQ+9e/b0>
> Trace; c010762c <do_general_protection+0/6c>
> Trace; c0109d1e <call_do_IRQ+5/17>
> Trace; c010762c <do_general_protection+0/6c>
> Trace; c0106c0d <error_code+2d/40>
> Trace; c0106af3 <system_call+33/40>
> Code;  c0180ab8 <n_tty_receive_buf+a4/edc>
> 00000000 <_EIP>:
> Code;  c0180ab8 <n_tty_receive_buf+a4/edc>   <=====
>    0:   a4                        movsb  %ds:(%esi),%es:(%edi)   <=====
> Code;  c0180ab9 <n_tty_receive_buf+a5/edc>
>    1:   8b 7c 24 1c               mov    0x1c(%esp,1),%edi
> Code;  c0180abd <n_tty_receive_buf+a9/edc>
>    5:   8b 8c 24 b0 00 00 00      mov    0xb0(%esp,1),%ecx
> Code;  c0180ac4 <n_tty_receive_buf+b0/edc>
>    c:   01 d3                     add    %edx,%ebx
> Code;  c0180ac6 <n_tty_receive_buf+b2/edc>
>    e:   29 d5                     sub    %edx,%ebp
> Code;  c0180ac8 <n_tty_receive_buf+b4/edc>
>   10:   ba 00 10 00 00            mov    $0x1000,%edx
>
>  <0>Kernel panic: Aiee, killing interrupt handler!
>
> -
> 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/
>

Re: [OOPS] repeatable 2.4.8-ac7, 2.4.7-ac6 just run xdos

[Jeff Chua]

xdos runs fine for me for all of 2.4.x. Mine is P3.

Thanks,
Jeff
[ jchua@fedex.com ]

On Sun, 19 Aug 2001, Paul wrote:

> * Kernel oops, and locks up when I run xdos (dosemu)
>
> * Occuring in both 2.4.7-ac6 and 2.4.8-ac7. Run 'xdos' in X, and
>   machine locks hard, only output to console is oops. (no sysrq)
>   Tried once with strace, but no oops. (didnt wait long, though)
>   Some oops before window is placed, some a little while after.
>   (mouse movement?) Repeatable.
>
> * Kernels are virgin linus patched with ac. AMD-K6(tm) 3D
>   processor
>
> * If anyone wants any more info or for me to do anything, just
>   ask.
>
> Paul
> set@pobox.com
>
> (2.4.7-ac6 -- two captured, identitcal, first shown)
>
> ksymoops 2.4.1 on i586 2.4.7-ac6.  Options used
>      -V (default)
>      -k /proc/ksyms (default)
>      -l /proc/modules (default)
>      -o /lib/modules/2.4.7-ac6/ (default)
>      -m /boot/System.map-2.4.7-ac6 (specified)
>
> CPU:    0
> EIP:    0010:[<c0180a18>]
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010002
> eax: 00001000   ebx: c4562368   ecx: 00000000   edx: 00000001
> esi: c4562368   edi: c4a954d4   ebp: 00000001   esp: c6887d88
> ds: 008   es: 0000   ss: 0018
> Process xdos (pid: 28039, stackpage=c6887000)
> Stack: c4562768 c4562368 00000001 00000000 c4562000 c4a954d4 00000202 00000001
>        00000001 c0181815 c4562000 c4562568 c4562168 00000001 00000000 0000000e
>        00000001 00000202 00000000 00000282 0000000e c0117554 0000000e 00000001
> Call Trace: [<c0181815>] [<c0117554>] [<c01173cc>] [<c01174ac>] [<c017fc3f>]
>    [<c0113e24>] [<c01163f6>] [<c0113d7e>] [<c0113c61>] [<c01139fb>] [<c0107ece>]
>    [<c010760c>] [<c0109cfe>] [<c010760c>] [<c0106bed>] [<c0106ad3>]
> Code: a4 8b 7c 24 1c 8b 8c 24 b0 00 00 00 01 d3 29 d5 ba 00 10 00
>
> >>EIP; c0180a18 <n_tty_receive_buf+a4/edc>   <=====
> Trace; c0181815 <n_tty_receive_buf+ea1/edc>
> Trace; c0117554 <send_sig_info+74/98>
> Trace; c01173cc <send_signal+2c/f0>
> Trace; c01174ac <deliver_signal+1c/50>
> Trace; c017fc3f <flush_to_ldisc+db/e4>
> Trace; c0113e24 <__run_task_queue+4c/60>
> Trace; c01163f6 <tqueue_bh+16/1c>
> Trace; c0113d7e <bh_action+1a/30>
> Trace; c0113c61 <tasklet_hi_action+51/b4>
> Trace; c01139fb <do_softirq+5b/ac>
> Trace; c0107ece <do_IRQ+9e/b0>
> Trace; c010760c <do_general_protection+0/6c>
> Trace; c0109cfe <call_do_IRQ+5/17>
> Trace; c010760c <do_general_protection+0/6c>
> Trace; c0106bed <error_code+2d/40>
> Trace; c0106ad3 <system_call+33/40>
> Code;  c0180a18 <n_tty_receive_buf+a4/edc>
> 00000000 <_EIP>:
> Code;  c0180a18 <n_tty_receive_buf+a4/edc>   <=====
>    0:   a4                        movsb  %ds:(%esi),%es:(%edi)   <=====
> Code;  c0180a19 <n_tty_receive_buf+a5/edc>
>    1:   8b 7c 24 1c               mov    0x1c(%esp,1),%edi
> Code;  c0180a1d <n_tty_receive_buf+a9/edc>
>    5:   8b 8c 24 b0 00 00 00      mov    0xb0(%esp,1),%ecx
> Code;  c0180a24 <n_tty_receive_buf+b0/edc>
>    c:   01 d3                     add    %edx,%ebx
> Code;  c0180a26 <n_tty_receive_buf+b2/edc>
>    e:   29 d5                     sub    %edx,%ebp
> Code;  c0180a28 <n_tty_receive_buf+b4/edc>
>   10:   ba 00 10 00 00            mov    $0x1000,%edx
>
>  <0>Kernel panic: Aiee, killing interrupt handler!
>
> ===================================================================
>
> (2.4.8-ac7)
>
> ksymoops 2.4.1 on i586 2.4.8-ac7.  Options used
>      -V (default)
>      -k /proc/ksyms (default)
>      -l /proc/modules (default)
>      -o /lib/modules/2.4.8-ac7/ (default)
>      -m /boot/System.map-2.4.8-ac7 (specified)
>
> CPU:    0
> EIP:    0010:[<c0180ab8>]
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010002
> eax: 00001000   ebx: c77dc168   ecx: 00000000   edx: 00000001
> esi: c77dc168   edi: c524c1aa   ebp: 00000001   esp: c7195d88
> ds: 0018   es: 0000   ss: 0018
> Process xdos (pid: 252, stackpage=c7195000)
> Stack: c77dc568 c77dc168 00000000 00000000 00000046 c7195dbc 00000202 00000001
>        007dc000 c524c1aa c77dc984 00000282 00000001 c01818b5 c77dc000 c77dc768
>       c77dc368 00000000 00000000 00000286 0000000e 00000202 00000000 00000001
> Call Trace: [<c01818b5>] [<c0112fe4>] [<c011735c>] [<c011743c>] [<c017fcdf>]
>    [<c0113d94>] [<c0116366>] [<c0113cde>] [<c0113c12>] [<c0113a3b>] [<c0107eee>]
>    [<c010762c>] [<c0109d1e>] [<c010762c>] [<c0106c0d>] [<c0106af3>]
> Code: a4 8b 7c 24 1c 8b 8c 24 b0 00 00 00 01 d3 29 d5 ba 00 10 00
>
> >>EIP; c0180ab8 <n_tty_receive_buf+a4/edc>   <=====
> Trace; c01818b5 <n_tty_receive_buf+ea1/edc>
> Trace; c0112fe4 <it_real_fn+0/44>
> Trace; c011735c <send_signal+2c/f0>
> Trace; c011743c <deliver_signal+1c/50>
> Trace; c017fcdf <flush_to_ldisc+db/e4>
> Trace; c0113d94 <__run_task_queue+4c/60>
> Trace; c0116366 <tqueue_bh+16/1c>
> Trace; c0113cde <bh_action+1a/40>
> Trace; c0113c12 <tasklet_hi_action+42/64>
> Trace; c0113a3b <do_softirq+5b/ac>
> Trace; c0107eee <do_IRQ+9e/b0>
> Trace; c010762c <do_general_protection+0/6c>
> Trace; c0109d1e <call_do_IRQ+5/17>
> Trace; c010762c <do_general_protection+0/6c>
> Trace; c0106c0d <error_code+2d/40>
> Trace; c0106af3 <system_call+33/40>
> Code;  c0180ab8 <n_tty_receive_buf+a4/edc>
> 00000000 <_EIP>:
> Code;  c0180ab8 <n_tty_receive_buf+a4/edc>   <=====
>    0:   a4                        movsb  %ds:(%esi),%es:(%edi)   <=====
> Code;  c0180ab9 <n_tty_receive_buf+a5/edc>
>    1:   8b 7c 24 1c               mov    0x1c(%esp,1),%edi
> Code;  c0180abd <n_tty_receive_buf+a9/edc>
>    5:   8b 8c 24 b0 00 00 00      mov    0xb0(%esp,1),%ecx
> Code;  c0180ac4 <n_tty_receive_buf+b0/edc>
>    c:   01 d3                     add    %edx,%ebx
> Code;  c0180ac6 <n_tty_receive_buf+b2/edc>
>    e:   29 d5                     sub    %edx,%ebp
> Code;  c0180ac8 <n_tty_receive_buf+b4/edc>
>   10:   ba 00 10 00 00            mov    $0x1000,%edx
>
>  <0>Kernel panic: Aiee, killing interrupt handler!
>
> -
> 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/
>

[OOPS] repeatable 2.4.8-ac7, 2.4.7-ac6 just run xdos

[Paul]

* Kernel oops, and locks up when I run xdos (dosemu)

* Occuring in both 2.4.7-ac6 and 2.4.8-ac7. Run 'xdos' in X, and
  machine locks hard, only output to console is oops. (no sysrq)
  Tried once with strace, but no oops. (didnt wait long, though)
  Some oops before window is placed, some a little while after. 
  (mouse movement?) Repeatable.

* Kernels are virgin linus patched with ac. AMD-K6(tm) 3D
  processor

* If anyone wants any more info or for me to do anything, just
  ask.

Paul
set@pobox.com

(2.4.7-ac6 -- two captured, identitcal, first shown)

ksymoops 2.4.1 on i586 2.4.7-ac6.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.7-ac6/ (default)
     -m /boot/System.map-2.4.7-ac6 (specified)

CPU:    0
EIP:    0010:[<c0180a18>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010002
eax: 00001000   ebx: c4562368   ecx: 00000000   edx: 00000001
esi: c4562368   edi: c4a954d4   ebp: 00000001   esp: c6887d88
ds: 008   es: 0000   ss: 0018
Process xdos (pid: 28039, stackpage=c6887000)
Stack: c4562768 c4562368 00000001 00000000 c4562000 c4a954d4 00000202 00000001 
       00000001 c0181815 c4562000 c4562568 c4562168 00000001 00000000 0000000e 
       00000001 00000202 00000000 00000282 0000000e c0117554 0000000e 00000001 
Call Trace: [<c0181815>] [<c0117554>] [<c01173cc>] [<c01174ac>] [<c017fc3f>] 
   [<c0113e24>] [<c01163f6>] [<c0113d7e>] [<c0113c61>] [<c01139fb>] [<c0107ece>] 
   [<c010760c>] [<c0109cfe>] [<c010760c>] [<c0106bed>] [<c0106ad3>] 
Code: a4 8b 7c 24 1c 8b 8c 24 b0 00 00 00 01 d3 29 d5 ba 00 10 00 

>>EIP; c0180a18 <n_tty_receive_buf+a4/edc>   <=====
Trace; c0181815 <n_tty_receive_buf+ea1/edc>
Trace; c0117554 <send_sig_info+74/98>
Trace; c01173cc <send_signal+2c/f0>
Trace; c01174ac <deliver_signal+1c/50>
Trace; c017fc3f <flush_to_ldisc+db/e4>
Trace; c0113e24 <__run_task_queue+4c/60>
Trace; c01163f6 <tqueue_bh+16/1c>
Trace; c0113d7e <bh_action+1a/30>
Trace; c0113c61 <tasklet_hi_action+51/b4>
Trace; c01139fb <do_softirq+5b/ac>
Trace; c0107ece <do_IRQ+9e/b0>
Trace; c010760c <do_general_protection+0/6c>
Trace; c0109cfe <call_do_IRQ+5/17>
Trace; c010760c <do_general_protection+0/6c>
Trace; c0106bed <error_code+2d/40>
Trace; c0106ad3 <system_call+33/40>
Code;  c0180a18 <n_tty_receive_buf+a4/edc>
00000000 <_EIP>:
Code;  c0180a18 <n_tty_receive_buf+a4/edc>   <=====
   0:   a4                        movsb  %ds:(%esi),%es:(%edi)   <=====
Code;  c0180a19 <n_tty_receive_buf+a5/edc>
   1:   8b 7c 24 1c               mov    0x1c(%esp,1),%edi
Code;  c0180a1d <n_tty_receive_buf+a9/edc>
   5:   8b 8c 24 b0 00 00 00      mov    0xb0(%esp,1),%ecx
Code;  c0180a24 <n_tty_receive_buf+b0/edc>
   c:   01 d3                     add    %edx,%ebx
Code;  c0180a26 <n_tty_receive_buf+b2/edc>
   e:   29 d5                     sub    %edx,%ebp
Code;  c0180a28 <n_tty_receive_buf+b4/edc>
  10:   ba 00 10 00 00            mov    $0x1000,%edx

 <0>Kernel panic: Aiee, killing interrupt handler!

===================================================================

(2.4.8-ac7)

ksymoops 2.4.1 on i586 2.4.8-ac7.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.8-ac7/ (default)
     -m /boot/System.map-2.4.8-ac7 (specified)

CPU:    0
EIP:    0010:[<c0180ab8>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010002
eax: 00001000   ebx: c77dc168   ecx: 00000000   edx: 00000001
esi: c77dc168   edi: c524c1aa   ebp: 00000001   esp: c7195d88
ds: 0018   es: 0000   ss: 0018
Process xdos (pid: 252, stackpage=c7195000)
Stack: c77dc568 c77dc168 00000000 00000000 00000046 c7195dbc 00000202 00000001 
       007dc000 c524c1aa c77dc984 00000282 00000001 c01818b5 c77dc000 c77dc768 
      c77dc368 00000000 00000000 00000286 0000000e 00000202 00000000 00000001 
Call Trace: [<c01818b5>] [<c0112fe4>] [<c011735c>] [<c011743c>] [<c017fcdf>] 
   [<c0113d94>] [<c0116366>] [<c0113cde>] [<c0113c12>] [<c0113a3b>] [<c0107eee>] 
   [<c010762c>] [<c0109d1e>] [<c010762c>] [<c0106c0d>] [<c0106af3>] 
Code: a4 8b 7c 24 1c 8b 8c 24 b0 00 00 00 01 d3 29 d5 ba 00 10 00 

>>EIP; c0180ab8 <n_tty_receive_buf+a4/edc>   <=====
Trace; c01818b5 <n_tty_receive_buf+ea1/edc>
Trace; c0112fe4 <it_real_fn+0/44>
Trace; c011735c <send_signal+2c/f0>
Trace; c011743c <deliver_signal+1c/50>
Trace; c017fcdf <flush_to_ldisc+db/e4>
Trace; c0113d94 <__run_task_queue+4c/60>
Trace; c0116366 <tqueue_bh+16/1c>
Trace; c0113cde <bh_action+1a/40>
Trace; c0113c12 <tasklet_hi_action+42/64>
Trace; c0113a3b <do_softirq+5b/ac>
Trace; c0107eee <do_IRQ+9e/b0>
Trace; c010762c <do_general_protection+0/6c>
Trace; c0109d1e <call_do_IRQ+5/17>
Trace; c010762c <do_general_protection+0/6c>
Trace; c0106c0d <error_code+2d/40>
Trace; c0106af3 <system_call+33/40>
Code;  c0180ab8 <n_tty_receive_buf+a4/edc>
00000000 <_EIP>:
Code;  c0180ab8 <n_tty_receive_buf+a4/edc>   <=====
   0:   a4                        movsb  %ds:(%esi),%es:(%edi)   <=====
Code;  c0180ab9 <n_tty_receive_buf+a5/edc>
   1:   8b 7c 24 1c               mov    0x1c(%esp,1),%edi
Code;  c0180abd <n_tty_receive_buf+a9/edc>
   5:   8b 8c 24 b0 00 00 00      mov    0xb0(%esp,1),%ecx
Code;  c0180ac4 <n_tty_receive_buf+b0/edc>
   c:   01 d3                     add    %edx,%ebx
Code;  c0180ac6 <n_tty_receive_buf+b2/edc>
   e:   29 d5                     sub    %edx,%ebp
Code;  c0180ac8 <n_tty_receive_buf+b4/edc>
  10:   ba 00 10 00 00            mov    $0x1000,%edx

 <0>Kernel panic: Aiee, killing interrupt handler!