Re: [ros-svn] [hbirr] 13102: - Set the limit of the user mode code/data segment back to 4GB.

[Alex Ionescu]

hbirr(a)svn.reactos.com wrote:

>  - Set the limit of the user mode code/data segment back
> to 4GB.
>
>
>
> Updated files:
> trunk/reactos/ntoskrnl/ke/i386/gdt.c
>
>   
>  
Thanks!

Do you know however if any of ROS Kernel depends on the old GDT? There 
are two weird issues with SYSEXIT:

1) GvG reported that FPU is broken
2) Explorer now crashes in shlwapi when clicking on a disk.

Best regards,
Alex Ionescu

[Ge van Geldorp]

>   From: Alex Ionescu
>  
>  Do you know however if any of ROS Kernel depends on the old 
>  GDT? There are two weird issues with SYSEXIT:
>  
>  1) GvG reported that FPU is broken
>  2) Explorer now crashes in shlwapi when clicking on a disk. 
Actually, it's only one issue. The crash in shlwapi is in
StrFormatByteSizeW(), which uses floating point.

Gé van Geldorp.

[Hartmut Birr]

Ge van Geldorp schrieb:

> >  From: Alex
> > Ionescu
> >
> > Do you know however if any of ROS Kernel depends on the old 
> > GDT? There are two weird issues with SYSEXIT:
> >
> > 1) GvG reported that FPU is broken
> > 2) Explorer now crashes in shlwapi when clicking on a disk.
> >     
> >  
> Actually, it's only one issue. The crash in shlwapi is in
> StrFormatByteSizeW(), which uses floating point.
>
> Gé van Geldorp.
>   
>  
Hi,

adding the stack segment register to one instruction at the begin of 
_KiFastCallEntry does fix the fpu problem for me. And I don't understand 
why the interrupt flag is manipulated after sysenter and before sysexit.

- Hartmut



E:\Sandbox\ros_mp\reactos>set SVN_EDITOR=notepad 

E:\Sandbox\ros_mp\reactos>d:\programme\subversion\bin\svn.exe diff
ntoskrnl\ke\i386\syscall.s        
Index: ntoskrnl/ke/i386/syscall.S
===================================================================
--- ntoskrnl/ke/i386/syscall.S	(Revision 13103)
+++ ntoskrnl/ke/i386/syscall.S	(Arbeitskopie)
@@ -26,21 +26,22 @@
 .globl _KiSystemService
 
 _KiFastCallEntry:
-
+    sti
+    
     /* Set FS to PCR */
     movl $PCR_SELECTOR, %ecx
     movw %cx, %fs
     
     /* Set the current stack to Kernel Stack */
     movl %fs:KPCR_TSS, %ecx
-    movl KTSS_ESP0(%ecx), %ecx
+    movl %ss:KTSS_ESP0(%ecx), %ecx
     movl %ecx, %esp
     
     /* Set up a fake INT Stack. */
     pushl $USER_DS
     pushl %edx                  /* Ring 3 SS:ESP */
     pushfl
-    orl $200, (%esp)            /* Re-enable IRQs in EFLAGS, to fake INT */
+//    orl $200, (%esp)            /* Re-enable IRQs in EFLAGS, to fake INT */
     pushl $USER_CS
     pushl $KUSER_SHARED_SYSCALL_RET
     
@@ -205,7 +206,7 @@
     /* Save pointer to Trap Frame */
     movl %esp, %ebx
     
-    /* Raise IRQL to HIGH_LEVEL */
+    /* Raise IRQL to APC_LEVEL */
     movl $1, %ecx
     call @KfRaiseIrql@4
     
@@ -280,7 +281,6 @@
     /* We will be cleaning up the stack ourselves */
     popl %edx                 /* New Ring 3 EIP */
     add $0x4, %esp            /* Skip Ring 3 DS */
-    andl $0xFD, 9(%esp)       /* Remove IRQ hack from EFLAGS */
     popfl                     /* Restore old EFLAGS */
     popl %ecx                 /* Old Ring 3 SS:ESP */

[Alex Ionescu]

Hi,

>  
>  adding the stack segment register to one instruction at the begin of 
>  _KiFastCallEntry does fix the fpu problem for me.  

That's really great! But how did you come to discover this? i.e, what is 
the reason for the behavior? I'm glad it's fixed but I would like to 
understand what's up.

>   And I don't understand why the interrupt flag is
> manipulated after 
>  sysenter and before sysexit. 
Because on SYSENTER, the interrupt flag is not on, while in INT3, it is. 
Therefore, if any function tries to read saved EFLAGS in the trap frame, 
we must be sure that it thinks IF is on. All the examples I've seen do 
this hack to IF.

>  
>  - Hartmut
>  
Best regards,
Alex Ionescu

[Hartmut Birr]

Alex Ionescu schrieb:

>   Hi,
>
> >  
> >  adding the stack segment register to one instruction at the begin of 
> >  _KiFastCallEntry does fix the fpu problem for me.  
>
>
>  That's really great! But how did you come to discover this? i.e, what 
>  is the reason for the behavior? I'm glad it's fixed but I would like 
>  to understand what's up.
>  
I got the fpu crash while compiling ntoskrnl on ros. The dependency 
files were build successful. The crash occurs at the first real 
compilation. I've added many debug prints. I've never seen a fpu trap. 
The crash was a page fault on address 0xffffffff. Eip and an other 
register was 0xffffffff. The return address has point after a fpu 
instruction. I've disabled sysenter and no crash occurs. So I had the 
feeling that something was wrong with the stack, because the address 
0xffffffff is very dirty. Currently I don't understand what is going on. 
Finding the real bug was a little bit try and error.

- Hartmut

[Alex Ionescu]

Hartmut Birr wrote:

> >  
> >  
>  I got the fpu crash while compiling ntoskrnl on ros. The dependency 
>  files were build successful. The crash occurs at the first real 
>  compilation. I've added many debug prints. I've never seen a fpu trap. 
>  The crash was a page fault on address 0xffffffff. Eip and an other 
>  register was 0xffffffff. The return address has point after a fpu 
>  instruction. I've disabled sysenter and no crash occurs. So I had the 
>  feeling that something was wrong with the stack, because the address 
>  0xffffffff is very dirty. Currently I don't understand what is going 
>  on. Finding the real bug was a little bit try and error.
>
>  - Hartmut
>  
Thanks for your last fix as well...I can't believe I hadn' t noticed 
it... originally 9(esp) was correct but I ended up moving stuff later 
and not noticing.

Best regards,
Alex Ionescu

[Alex Ionescu]

Hartmut Birr wrote:

>   Hi,
>
>  adding the stack segment register to one instruction at the begin of 
>  _KiFastCallEntry does fix the fpu problem for me. And I don't 
>  understand why the interrupt flag is manipulated after sysenter and 
>  before sysexit.
>
>  - Hartmut
>
> -
> +    sti
> +    
>   
>  
Adding this makes the handler crash with a Stack Underflow at the next 
function...

>  -    movl KTSS_ESP0(%ecx), %ecx
> +    movl %ss:KTSS_ESP0(%ecx), %ecx
>   
>  
Adding this does nothing to fix Explorer :(

Best regards,
Alex Ionescu

[Alex Ionescu]

Adding this makes the handler crash with a Stack Underflow at the next 
function...

>  
> >   -    movl KTSS_ESP0(%ecx), %ecx
> >  +    movl %ss:KTSS_ESP0(%ecx), %ecx
> >   
> >  
>  Adding this does nothing to fix Explorer :(
>
>  Best regards,
>  Alex Ionescu
>  _______________________________________________ 
Nevermind, make clean was on drugs. See commit.

Thank you SO much.

Best regards,
Alex Ionescu