Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace broken implementation of HalpCalibrateStallExecution with a new implementation by a mysterious HAL ninja and myself. The old implementation calculated the stall count factor incorrectly and produced bogus resu

[Gabriel ilardi]

This commit introduces a noticeable delay in VirtualBox:

1) When booting from the CD to install ROS, after FreeLDR has initially loaded and the
screen becomes black, here I notice a delay of 6~7 seconds until I see the blue screen to
choose the language in usetup. Before the commit it was about 1 sec.

2) In second stage when loading UniATA, it stays there for about 4-5 seconds, there was no
delay before.


Best regards,
Gabriel.


>   Date: Tue, 27 Oct 2009 01:03:41 +0000
>  To: ros-diffs(a)reactos.org
>  From: sginsberg(a)svn.reactos.org
>  Subject: [ros-diffs] [sginsberg] 43789: - Replace broken implementation of
> HalpCalibrateStallExecution with a new implementation by a mysterious HAL ninja and
> myself. The old implementation calculated the stall count factor incorrectly and produced
> bogus results that were off by several thousand, and varied by as much for each boot, and
> can best be described as "rand() made complicated". The new implementation
> installs its own RTC interrupt handler to accurately calculate the stall scale factor, all
> done in assembler instead of broken C. Fixes the hang at boot when initializing Uniata as
> stalls no longer takes 10 times or more as long to execute then they should.
>  
>  Author: sginsberg
>  Date: Tue Oct 27 02:03:41 2009
>  New Revision: 43789
>  
>  URL: http://svn.reactos.org/svn/reactos?rev=43789&view=rev
>  Log:
>  - Replace broken implementation of HalpCalibrateStallExecution with a new implementation
> by a mysterious HAL ninja and myself. The old implementation calculated the stall count
> factor incorrectly and produced bogus results that were off by several thousand, and
> varied by as much for each boot, and can best be described as "rand() made
> complicated". The new implementation installs its own RTC interrupt handler to
> accurately calculate the stall scale factor, all done in assembler instead of broken C.
> Fixes the hang at boot when initializing Uniata as stalls no longer takes 10 times or more
> as long to execute then they should.
>  
>  Modified:
>      trunk/reactos/hal/halx86/generic/halinit.c
>      trunk/reactos/hal/halx86/generic/systimer.S
>      trunk/reactos/hal/halx86/generic/timer.c
>  
>  Modified: trunk/reactos/hal/halx86/generic/halinit.c
>  URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/halinit…
>  ==============================================================================
>  --- trunk/reactos/hal/halx86/generic/halinit.c [iso-8859-1] (original)
>  +++ trunk/reactos/hal/halx86/generic/halinit.c [iso-8859-1] Tue Oct 27 02:03:41 2009
>  @@ -97,11 +97,11 @@
>           /* Force initial PIC state */
>           KfRaiseIrql(KeGetCurrentIrql());
>   
>  +        /* Setup busy waiting */
>  +        HalpCalibrateStallExecution();
>  +
>           /* Initialize the clock */
>           HalpInitializeClock();
>  -
>  -        /* Setup busy waiting */
>  -        HalpCalibrateStallExecution();
>   
>           /* Fill out the dispatch tables */
>           HalQuerySystemInformation = HaliQuerySystemInformation;
>  
>  Modified: trunk/reactos/hal/halx86/generic/systimer.S
>  URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/systime…
>  ==============================================================================
>  --- trunk/reactos/hal/halx86/generic/systimer.S [iso-8859-1] (original)
>  +++ trunk/reactos/hal/halx86/generic/systimer.S [iso-8859-1] Tue Oct 27 02:03:41 2009
>  @@ -17,11 +17,386 @@
>   _HalpLastPerfCounterHigh:   .long 0
>   _HalpPerfCounterLow:        .long 0
>   _HalpPerfCounterHigh:       .long 0
>  +_HalpSystemHardwareLock:    .long 0
>  +_HalpSystemHardwareFlags:   .long 0
>   
>   _UnhandledMsg:
>       .asciz "\n\x7\x7!!! Unhandled or Unexpected Code at line: %lx!!!\n"
>   
>   /* FUNCTIONS *****************************************************************/
>  +
>  +.global _HalpReleaseCmosSpinLock@0
>  +.func HalpReleaseCmosSpinLock@0
>  +_HalpReleaseCmosSpinLock@0:
>  +
>  +#ifdef CONFIG_SMP
>  +    /* Save clobbered register */
>  +    push eax
>  +    
>  +    /* Push saved EFLAGS */
>  +    push _HalpSystemHardwareFlags
>  +    
>  +    /* Release the lock */
>  +    lea eax, _HalpSystemHardwareLock
>  +    RELEASE_SPINLOCK(eax)
>  +    
>  +    /* Restore EFLAGS */
>  +    popf
>  +    
>  +    /* Return */
>  +    pop eax
>  +    ret
>  +#else
>  +    /* Restore EFLAGS and return */
>  +    push _HalpSystemHardwareFlags
>  +    popf
>  +    ret
>  +#endif
>  +.endfunc
>  +
>  +.global _HalpAcquireSystemHardwareSpinLock@0
>  +.func HalpAcquireSystemHardwareSpinLock@0
>  +_HalpAcquireSystemHardwareSpinLock@0:
>  +
>  +#ifdef CONFIG_SMP
>  +    /* Save clobbered register */
>  +    push eax
>  +    
>  +HardwareLock:
>  +    /* Save EFLAGS and disable interrupts */
>  +    pushf
>  +    cli
>  +    
>  +    /* This is the CMOS lock, acquire it */
>  +    lea eax, _HalpSystemHardwareLock
>  +    ACQUIRE_SPINLOCK(eax, CmosSpin)
>  +    
>  +    /* We have it, return the flags */
>  +    pop _HalpSystemHardwareFlags
>  +    pop eax
>  +    ret
>  +    
>  +CmosSpin:
>  +
>  +    /* Restore EFLAGS */
>  +    pushf _HalpSystemHardwareLock
>  +    popf 
>  +
>  +    /* Spin */
>  +    SPIN_ON_LOCK(eax, HardwareLock)
>  +
>  +#else
>  +    /* Save EFLAGS, disable interrupts and return */
>  +    pushf
>  +    cli
>  +    pop _HalpSystemHardwareFlags
>  +    ret
>  +#endif
>  +.endfunc
>  +
>  +.global _HalpCalibrateStallExecution@0
>  +.func HalpCalibrateStallExecution@0
>  +_HalpCalibrateStallExecution@0:
>  +
>  +    /* Setup the stack frame */
>  +    push ebp
>  +    mov ebp, esp
>  +    sub esp, 12
>  +
>  +    /* Save EFLAGS and kill interrupts */
>  +    pushf
>  +    cli
>  +    
>  +    /* Get the current interrupt mask on the PICs */
>  +    xor eax, eax
>  +    in al, 0xA1
>  +    shl eax, 8
>  +    in al, 0x21
>  +    
>  +    /* Save it */
>  +    push eax
>  +    
>  +    /* Now mask everything except the RTC and PIC 2 chain-interrupt */
>  +    mov eax, ~((1 << 2) | (1 << 8))
>  +    
>  +    /* Program the PICs */
>  +    out 0x21, al
>  +    shr eax, 8
>  +    out 0xA1, al
>  +    
>  +    /* Now get the IDT */
>  +    sidt [ebp-8]
>  +    mov ecx, [ebp-6]
>  +    
>  +    /* Get the IDT entry for the RTC */
>  +    mov eax, 0x38
>  +    shl eax, 3
>  +    add ecx, eax
>  +    
>  +    /* Save the original RTC ISR */
>  +    push [ecx]
>  +    push [ecx+4]
>  +    push ecx
>  +    
>  +    /* Now load our new handler */
>  +    mov eax, offset OnlyOnePersonCanWriteHalCode
>  +    mov [ecx], ax
>  +    mov word ptr [ecx+2], KGDT_R0_CODE
>  +    mov word ptr [ecx+4], 0x8E00
>  +    shr eax, 16
>  +    mov [ecx+6], ax
>  +
>  +    /* Reset our counter */
>  +    mov dword ptr [ebp-12], 0
>  +    
>  +    /* Acquire CMOS lock */
>  +    call _HalpAcquireSystemHardwareSpinLock@0
>  +    
>  +    /* Now initialize register A on the CMOS */
>  +    mov ax, (0x2D << 8) | 0xA
>  +    out 0x70, al
>  +    jmp $+2
>  +    mov al, ah
>  +    out 0x71, al
>  +    jmp $+2
>  +    
>  +    /* Read register B */
>  +    mov ax, 0xB
>  +    out 0x70, al
>  +    jmp $+2
>  +    in al, 0x71
>  +    jmp $+2
>  +    
>  +    /* Don't touch the LastKnownGoodConfig hack */
>  +    and al, 1
>  +    mov ah, al
>  +    
>  +    /* Enable the interrupt */
>  +    or ah, 0x42
>  +    
>  +    /* Now write the register B */
>  +    mov al, 0xB
>  +    out 0x70, al
>  +    jmp $+2
>  +    mov al, ah
>  +    out 0x71, al
>  +    jmp $+2
>  +    
>  +    /* Read register C */
>  +    mov al, 0xC
>  +    out 0x70, al
>  +    jmp $+2
>  +    in al, 0x71
>  +    jmp $+2
>  +    
>  +    /* Read register D */
>  +    mov al, 0xD
>  +    out 0x70, al
>  +    jmp $+2
>  +    in al, 0x71
>  +    jmp $+2
>  +    
>  +    /* Release CMOS lock */
>  +    mov dword ptr [ebp-12], 0
>  +    call _HalpReleaseCmosSpinLock@0
>  +    
>  +    /* Initialize looper */
>  +    xor eax, eax
>  +    
>  +    /* Align to 16 bytes */
>  +    .align 16
>  +    
>  +    /* Enable interrupts! */
>  +    sti
>  +    jmp Looper
>  +    
>  +    /* Align to 16 bytes */
>  +    .align 16
>  +    
>  +    /* Subtract one count */
>  +Looper:
>  +    sub eax, 1
>  +    jnz Looper
>  +    
>  +    /* ASSERT: If we got here, then the RTC never fired */
>  +    call _DbgBreakPoint@0
>  +    jmp Looper
>  +    
>  +OnlyOnePersonCanWriteHalCode:
>  +    /*********************** THIS IS THE RTC HANDLER **************************/
>  +
>  +    /* Increment the interrupt count and check if this is the first one */
>  +    inc dword ptr [ebp-12]
>  +    cmp dword ptr [ebp-12], 1
>  +    jnz ComputeStall
>  +    
>  +    /*
>  +     * It is the first one -- we'll ignore it, since it fires randomly!
>  +     * Get rid of the old return address and push the new one in (our looper)
>  +     */
>  +    pop eax
>  +    push offset Looper
>  +    
>  +    /* Acquire CMOS lock */
>  +    call _HalpAcquireSystemHardwareSpinLock@0
>  +    
>  +    /* Now initialize register A on the CMOS */
>  +    mov ax, (0x2D << 8) | 0xA
>  +    out 0x70, al
>  +    jmp $+2
>  +    mov al, ah
>  +    out 0x71, al
>  +    jmp $+2
>  +    
>  +    /* Read register B */
>  +    mov ax, 0xB
>  +    out 0x70, al
>  +    jmp $+2
>  +    in al, 0x71
>  +    jmp $+2
>  +    
>  +    /* Don't touch the LastKnownGoodConfig hack */
>  +    and al, 1
>  +    mov ah, al
>  +    
>  +    /* Enable the interrupt */
>  +    or ah, 0x42
>  +    
>  +    /* Now write the register B */
>  +    mov al, 0xB
>  +    out 0x70, al
>  +    jmp $+2
>  +    mov al, ah
>  +    out 0x71, al
>  +    jmp $+2
>  +    
>  +    /* Read register C */
>  +    mov al, 0xC
>  +    out 0x70, al
>  +    jmp $+2
>  +    in al, 0x71
>  +    jmp $+2
>  +    
>  +    /* Read register D */
>  +    mov al, 0xD
>  +    out 0x70, al
>  +    jmp $+2
>  +    in al, 0x71
>  +    jmp $+2
>  +    
>  +    /* Release CMOS lock */
>  +    call _HalpReleaseCmosSpinLock@0
>  +    
>  +    /* Dismiss the interrupt */
>  +    mov al, 0x20
>  +    out 0xA0, al
>  +    mov al, 0x62
>  +    out 0x20, al
>  +    
>  +    /* Reset the counter and return back to the looper */
>  +    xor eax, eax
>  +    iretd
>  +    
>  +    /******************* THIS IS THE 2ND RTC HANDLER **************************/
>  +ComputeStall:
>  +
>  +    /* Do the calculation */
>  +    neg eax
>  +    xor edx, edx
>  +    mov ecx, 125000 /* RTC fires every 125 ms */
>  +    div ecx
>  +    
>  +    /* Is the remainder 0? */
>  +    cmp edx, 0
>  +    jz FoundFactor
>  +    
>  +    /* Otherwise fix-up the loop count */
>  +    inc eax
>  +    
>  +FoundFactor:
>  +    /* Save the stall scale factor */
>  +    mov fs:[KPCR_STALL_SCALE_FACTOR], eax
>  +    
>  +    /* Prepare for interrupt return */
>  +    pop eax
>  +    push offset AndItsNotYou
>  +    mov eax, 0x13
>  +    
>  +    /* Acquire CMOS lock */
>  +    call _HalpAcquireSystemHardwareSpinLock@0
>  +    
>  +    /* Now initialize register A on the CMOS */
>  +    mov ax, (0x2D << 8) | 0xA
>  +    out 0x70, al
>  +    jmp $+2
>  +    mov al, ah
>  +    out 0x71, al
>  +    jmp $+2
>  +    
>  +    /* Read register B */
>  +    mov ax, 0xB
>  +    out 0x70, al
>  +    jmp $+2
>  +    in al, 0x71
>  +    jmp $+2
>  +    
>  +    /* Don't touch the LastKnownGoodConfig hack */
>  +    and al, 1
>  +    mov ah, al
>  +    
>  +    /* Disable the interrupt */
>  +    or ah, 0x2
>  +    
>  +    /* Now write the register B */
>  +    mov al, 0xB
>  +    out 0x70, al
>  +    jmp $+2
>  +    mov al, ah
>  +    out 0x71, al
>  +    jmp $+2
>  +    
>  +    /* Read register C */
>  +    mov al, 0xC
>  +    out 0x70, al
>  +    jmp $+2
>  +    in al, 0x71
>  +    jmp $+2
>  +    
>  +    /* Release CMOS lock */
>  +    call _HalpReleaseCmosSpinLock@0
>  +    
>  +    /* Dismiss the interrupt */
>  +    mov al, 0x20
>  +    out 0xA0, al
>  +    mov al, 0x62
>  +    out 0x20, al
>  +    
>  +    /* Disable interrupts on return */
>  +    and word ptr [esp+8], ~EFLAGS_INTERRUPT_MASK
>  +    iretd
>  +    
>  +    /************************* WE ARE BACK FROM RTC ***************************/
>  +AndItsNotYou:
>  +
>  +    /* Restore the IDT */
>  +    pop ecx
>  +    pop [ecx+4]
>  +    pop [ecx]
>  +    
>  +    /* Restore the mask */
>  +    pop eax
>  +    out 0x21, al
>  +    shr eax, 8
>  +    out 0xA1, al
>  +    
>  +    /* Restore EFLAGS */
>  +    popf
>  +    
>  +    /* Restore stack and return */
>  +    mov esp, ebp
>  +    pop ebp
>  +    ret
>  +.endfunc
>   
>   .globl _KeStallExecutionProcessor@4
>   .func KeStallExecutionProcessor@4
>  @@ -53,34 +428,6 @@
>       /* Return */
>       ret 4
>   .endfunc
>  -
>  -
>  -.globl _HalpQuery8254Counter@0
>  -.func HalpQuery8254Counter@0
>  -_HalpQuery8254Counter@0:
>  -
>  -    /* Save EFLAGS and disable interrupts */
>  -    pushfd
>  -    cli
>  -    
>  -    /* Set timer data */
>  -    mov al, 0
>  -    out 0x43, al
>  -    jmp $+2
>  -
>  -    /* Read current timer */
>  -    in al, 0x40
>  -    jmp $+2
>  -    movzx ecx, al
>  -    in al, 0x40
>  -    mov ch, al
>  -
>  -    /* Return it and restore interrupt state */
>  -    mov eax, ecx
>  -    popfd
>  -    ret
>  -.endfunc
>  -
>   
>   .global _KeQueryPerformanceCounter@4
>   .func KeQueryPerformanceCounter@4
>  
>  Modified: trunk/reactos/hal/halx86/generic/timer.c
>  URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/timer.c…
>  ==============================================================================
>  --- trunk/reactos/hal/halx86/generic/timer.c [iso-8859-1] (original)
>  +++ trunk/reactos/hal/halx86/generic/timer.c [iso-8859-1] Tue Oct 27 02:03:41 2009
>  @@ -13,11 +13,6 @@
>   #include <debug.h>
>   
>   /* GLOBALS *******************************************************************/
>  -
>  -/* time to wait */
>  -#define MICROSECOND_TO_WAIT 1000
>  -/* the tick count for 1 ms is 1193.182 (1193182 Hz) round it up */
>  -#define TICKCOUNT_TO_WAIT  1194
>   
>   BOOLEAN HalpClockSetMSRate;
>   ULONG HalpCurrentTimeIncrement;
>  @@ -135,161 +130,4 @@
>       return HalpRolloverTable[Increment - 1].HighPart;
>   }
>   
>  -ULONG
>  -WaitFor8254Wraparound(VOID)
>  -{
>  -    ULONG StartTicks;
>  -    ULONG PrevTicks;
>  -    LONG Delta;
>  -
>  -    StartTicks = HalpQuery8254Counter();
>  -
>  -    do
>  -    {
>  -        PrevTicks = StartTicks;
>  -        StartTicks = HalpQuery8254Counter();
>  -        Delta = StartTicks - PrevTicks;
>  -
>  -        /*
>  -         * This limit for delta seems arbitrary, but it isn't, it's
>  -         * slightly above the level of error a buggy Mercury/Neptune
>  -         * chipset timer can cause.
>  -         */
>  -
>  -    }
>  -    while (Delta < 300);
>  -
>  -    return StartTicks;
>  -}
>  -
>  -VOID
>  -NTAPI
>  -HalpCalibrateStallExecution(VOID)
>  -{
>  -    ULONG CalibrationBit;
>  -    ULONG EndTicks;
>  -    ULONG StartTicks;
>  -    ULONG OverheadTicks;
>  -    PKIPCR Pcr;
>  -
>  -    Pcr = (PKIPCR)KeGetPcr();
>  -
>  -    /* Measure the delay for the minimum call overhead in ticks */
>  -    Pcr->StallScaleFactor = 1;
>  -    StartTicks = WaitFor8254Wraparound();
>  -    KeStallExecutionProcessor(1);
>  -    EndTicks = HalpQuery8254Counter();
>  -    OverheadTicks = (StartTicks - EndTicks);
>  -
>  -    do
>  -    {
>  -        /* Increase the StallScaleFactor */
>  -        Pcr->StallScaleFactor = Pcr->StallScaleFactor * 2;
>  -
>  -        if (Pcr->StallScaleFactor == 0)
>  -        {
>  -           /* Nothing found */
>  -           break;
>  -        }
>  -
>  -        /* Get the start ticks */
>  -        StartTicks = WaitFor8254Wraparound();
>  -
>  -        /* Wait for a defined time */
>  -        KeStallExecutionProcessor(MICROSECOND_TO_WAIT);
>  -
>  -        /* Get the end ticks */
>  -        EndTicks = HalpQuery8254Counter();
>  -
>  -        DPRINT("Pcr->StallScaleFactor: %d\n", Pcr->StallScaleFactor);
>  -        DPRINT("Time1 : StartTicks %i - EndTicks %i = %i\n",
>  -            StartTicks, EndTicks, StartTicks - EndTicks);
>  -    } while ((StartTicks - EndTicks) <= (TICKCOUNT_TO_WAIT + OverheadTicks));
>  -
>  -    /* A StallScaleFactor lesser than INITIAL_STALL_COUNT makes no sense */
>  -    if (Pcr->StallScaleFactor >= (INITIAL_STALL_COUNT * 2))
>  -    {
>  -        /* Adjust the StallScaleFactor */
>  -        Pcr->StallScaleFactor  = Pcr->StallScaleFactor / 2;
>  -
>  -        /* Setup the CalibrationBit */
>  -        CalibrationBit = Pcr->StallScaleFactor;
>  -
>  -        for (;;)
>  -        {
>  -            /* Lower the CalibrationBit */
>  -            CalibrationBit = CalibrationBit / 2;
>  -            if (CalibrationBit == 0)
>  -            {
>  -                break;
>  -            }
>  -
>  -            /* Add the CalibrationBit */
>  -            Pcr->StallScaleFactor = Pcr->StallScaleFactor + CalibrationBit;
>  -
>  -            /* Get the start ticks */
>  -            StartTicks = WaitFor8254Wraparound();
>  -
>  -            /* Wait for a defined time */
>  -            KeStallExecutionProcessor(MICROSECOND_TO_WAIT);
>  -
>  -            /* Get the end ticks */
>  -            EndTicks = HalpQuery8254Counter();
>  -
>  -            DPRINT("Pcr->StallScaleFactor: %d\n",
> Pcr->StallScaleFactor);
>  -            DPRINT("Time2 : StartTicks %i - EndTicks %i = %i\n",
>  -                StartTicks, EndTicks, StartTicks - EndTicks);
>  -
>  -            if ((StartTicks-EndTicks) > (TICKCOUNT_TO_WAIT+OverheadTicks))
>  -            {
>  -                /* Too big so subtract the CalibrationBit */
>  -                Pcr->StallScaleFactor = Pcr->StallScaleFactor - CalibrationBit;
>  -            }
>  -        }
>  -        DPRINT("New StallScaleFactor: %d\n", Pcr->StallScaleFactor);
>  -    }
>  -    else
>  -    {
>  -       /* Set StallScaleFactor to the default */
>  -       Pcr->StallScaleFactor = INITIAL_STALL_COUNT;
>  -    }
>  -
>  -#if 0
>  -    /* For debugging */
>  -    ULONG i;
>  -
>  -    DPRINT1("About to start delay loop test\n");
>  -    DPRINT1("Waiting for a minute...");
>  -    for (i = 0; i < (60*1000*20); i++)
>  -    {
>  -        KeStallExecutionProcessor(50);
>  -    }
>  -    DPRINT1("finished\n");
>  -
>  -
>  -    DPRINT1("About to start delay loop test\n");
>  -    DPRINT1("Waiting for a minute...");
>  -    for (i = 0; i < (60*1000); i++)
>  -    {
>  -        KeStallExecutionProcessor(1000);
>  -    }
>  -    DPRINT1("finished\n");
>  -
>  -
>  -    DPRINT1("About to start delay loop test\n");
>  -    DPRINT1("Waiting for a minute...");
>  -    for (i = 0; i < (60*1000*1000); i++)
>  -    {
>  -        KeStallExecutionProcessor(1);
>  -    }
>  -    DPRINT1("finished\n");
>  -
>  -    DPRINT1("About to start delay loop test\n");
>  -    DPRINT1("Waiting for a minute...");
>  -    KeStallExecutionProcessor(60*1000000);
>  -    DPRINT1("finished\n");
>  -#endif
>  -}
>  -
>  -
>   /* EOF */
>  
>   
 		 	   		  
_________________________________________________________________
Nuovo Windows 7: trova il PC più adatto alle tue esigenze. Scopri di più.
http://windows.microsoft.com/shop

[Johannes Anderwald]

Gabriel ilardi schrieb:
>   2) In second stage when loading UniATA, it stays there
> for about 4-5 
>  seconds, there was no delay before.
>  
Hi,

The UniATA delay in 2nd stage was already present before that commit. 
However, only in VMware.
>  
>  Best regards,
>  Gabriel.
>  
Best regards,
Johannes Anderwald

[Gabriel ilardi]

Hi Johannes,

It wasn't present for VirtualBox though, at least for me.

Best regards,
Gabriel.

>   Date: Tue, 27 Oct 2009 11:34:03 +0100
>  From: janderwald(a)reactos.org
>  To: ros-dev(a)reactos.org
>  Subject: Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace broken implementation of
> HalpCalibrateStallExecution with a new implementation by a mysterious HAL ninja and
> myself. The old implementation calculated the stall count factor incorrectly and produced
> bogus resu
>  
>  Gabriel ilardi schrieb:
> >   2) In second stage when loading UniATA, it stays
> > there for about 4-5 
> >  seconds, there was no delay before.
> >  
>  Hi,
>  
>  The UniATA delay in 2nd stage was already present before that commit. 
>  However, only in VMware.
> >  
> >  Best regards,
> >  Gabriel.
> >  
>  Best regards,
>  Johannes Anderwald
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 
 		 	   		  
_________________________________________________________________
Racconta la tua estate, crea il tuo blog.
http://www.windowslive.it/spaces.aspx

[Sylvain Petreolle]

It was present here in VirtualBox  3.0.8 for some time 
and disappeared after Stefan's change for exception management.
 Kind regards,
Sylvain Petreolle


>  
> De : Gabriel ilardi <gabrielilardi(a)hotmail.it>
> À : ros-dev <ros-dev(a)reactos.org>
> Envoyé le : Mar 27 Octobre 2009, 11 h 44 min 19 s
> Objet : Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace broken implementation of
> HalpCalibrateStallExecution with a new implementation by a mysterious HAL ninja and
> myself. The old implementation calculated the stall count factor incorrectly and produced
>
>  
> Hi Johannes,
>
> It wasn't present for VirtualBox though, at least for me.
>
> Best regards,
> Gabriel.
>
> >   Date: Tue, 27 Oct 2009 11:34:03 +0100
> >  From: janderwald(a)reactos.org
> >  To: ros-dev(a)reactos.org
> >  Subject: Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace broken implementation of
> > HalpCalibrateStallExecution with a new implementation by a mysterious HAL ninja and
> > myself. The old implementation calculated the stall count factor incorrectly and produced
> > bogus resu
> >  
> >  Gabriel ilardi schrieb:
> > >   2) In second stage when loading UniATA, it stays
> > > there for about 4-5 
> > >  seconds, there was no delay before.
> > >  
> >  Hi,
> >  
> >  The UniATA delay in 2nd stage was already present before that commit. 
> >  However, only in VMware.
> > >  
> > >  Best regards,
> > >  Gabriel.
> > >  
> >  Best regards,
> >  Johannes Anderwald
> >  
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev 
> ________________________________ 
Conosci il tuo Messenger? Scopri tutte le novità

[Alex Ionescu]

The real problem is that UniATA is full of shit code from Aleksey that  
does things like StallExecution(100000). Microsoft says not to go over  
50, but hey, this is ReactOS....reading docs?? HAHAHA!!

I've looked over Stefan's code and it is perfect, and sets a correct  
stall factor.

On 2009-10-27, at 8:24 AM, Sylvain Petreolle wrote:

>   It was present here in VirtualBox  3.0.8 for some
> time
>  and disappeared after Stefan's change for exception management.
>
>  Kind regards,
>  Sylvain Petreolle
>
>
>  De : Gabriel ilardi <gabrielilardi(a)hotmail.it>
>  À : ros-dev <ros-dev(a)reactos.org>
>  Envoyé le : Mar 27 Octobre 2009, 11 h 44 min 19 s
>  Objet : Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace  
>  broken implementation of HalpCalibrateStallExecution with a new  
>  implementation by a mysterious HAL ninja and myself. The old  
>  implementation calculated the stall count factor incorrectly and  
>  produced
>
>  Hi Johannes,
>
>  It wasn't present for VirtualBox though, at least for me.
>
>  Best regards,
>  Gabriel.
>
> >   Date: Tue, 27 Oct 2009 11:34:03 +0100
> >  From: janderwald(a)reactos.org
> >  To: ros-dev(a)reactos.org
> >  Subject: Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace   
>  broken
> implementation of HalpCalibrateStallExecution with a new  
>  implementation by a mysterious HAL ninja and myself. The old  
>  implementation calculated the stall count factor incorrectly and  
>  produced bogus resu
> >  
> >  Gabriel ilardi schrieb:
> >  > 2) In second stage when loading UniATA, it stays there for about   
>  4-5
> > >   seconds,
> > > there was no delay before.
> > >  
> >  Hi,
> >
> >  The UniATA delay in 2nd stage was already present before that   
>  commit.
> >   However, only in VMware.
> > >  
> > >  Best regards,
> > >  Gabriel.
> > >  
> >  Best regards,
> >  Johannes Anderwald
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev 
>  Conosci il tuo Messenger? Scopri tutte le novità
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 
Best regards,
Alex Ionescu

[Daniel Reimer]

These timers were added because some SATA adapters are fucking slow in 
initializing and uniata would continue too early for them and this 
results in failures. Maybe theres a better way to get this done, but it 
was enough for testing and did its job well.

Alex Ionescu schrieb:
>   The real problem is that UniATA is full of shit code
> from Aleksey that 
>  does things like StallExecution(100000). Microsoft says not to go over 
>  50, but hey, this is ReactOS....reading docs?? HAHAHA!!
>
>  I've looked over Stefan's code and it is perfect, and sets a correct 
>  stall factor.
>
>  On 2009-10-27, at 8:24 AM, Sylvain Petreolle wrote:
>
> >   It was present here in VirtualBox  3.0.8 for some
> > time
> >  and disappeared after Stefan's change for exception management.
> >  Kind regards,
> >  Sylvain Petreolle
> >
> >
> >      *De :* Gabriel ilardi <gabrielilardi(a)hotmail.it
> >      <mailto:[e-mail]>>
> >      *À :* ros-dev &lt;ros-dev(a)reactos.org <mailto:[e-mail]>>
> >      *Envoyé le :* Mar 27 Octobre 2009, 11 h 44 min 19 s
> >      *Objet :* Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace
> >      broken implementation of HalpCalibrateStallExecution with a new
> >      implementation by a mysterious HAL ninja and myself. The old
> >      implementation calculated the stall count factor incorrectly and
> >      produced
> >
> >      Hi Johannes,
> >
> >      It wasn't present for VirtualBox though, at least for me.
> >
> >      Best regards,
> >      Gabriel.
> >
> > >   Date: Tue, 27 Oct 2009 11:34:03 +0100
> > >  From: janderwald(a)reactos.org <mailto:[e-mail]>
> > >  To: ros-dev(a)reactos.org <mailto:[e-mail]>
> > >  Subject: Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace 
> >      broken
> > implementation of HalpCalibrateStallExecution with a new
> >      implementation by a mysterious HAL ninja and myself. The old
> >      implementation calculated the stall count factor incorrectly and
> >      produced bogus resu
> > >  
> > >  Gabriel ilardi schrieb:
> > >  > 2) In second stage when loading UniATA, it stays there for 
> >      about 4-5
> > > >   seconds,
> > > > there was no delay before.
> > > >  
> > >  Hi,
> > >
> > >  The UniATA delay in 2nd stage was already present before that 
> >      commit.
> > >   However, only in VMware.
> > > >  
> > > >  Best regards,
> > > >  Gabriel.
> > > >  
> > >  Best regards,
> > >  Johannes Anderwald
> > >
> > >  _______________________________________________
> > >  Ros-dev mailing list
> > >  Ros-dev(a)reactos.org <mailto:[e-mail]>
> > >  http://www.reactos.org/mailman/listinfo/ros-dev 
> >      ------------------------------------------------------------------------
> >      Conosci il tuo Messenger? Scopri tutte le novità
> >      <http://www.messenger.it/home_novita.aspx>
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org <mailto:[e-mail]>
> >  http://www.reactos.org/mailman/listinfo/ros-dev 
>  Best regards,
>  Alex Ionescu
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Alex Ionescu]

And it continues to do its job today -- you added code telling UniATA  
"wait between 500ms and 5seconds", and it's working fine in trunk.

Why are people complaining "it takes UniATA up to 5 seconds to boot"  
when this is exactly the code you intended to add?

Also:

"Maybe theres a better way to get this done, but it was enough for  
testing and did its job well."

Is now my all-time favourite quote, ever.

I bet Hitler would've said the same at Nuremberg....

On 2009-10-27, at 8:50 AM, Daniel Reimer wrote:

>   These timers were added because some SATA adapters are
> fucking slow in
>  initializing and uniata would continue too early for them and this
>  results in failures. Maybe theres a better way to get this done, but  
>  it
>  was enough for testing and did its job well.
>
>  Alex Ionescu schrieb:
> >   The real problem is that UniATA is full of shit
> > code from Aleksey  
> >  that
> >  does things like StallExecution(100000). Microsoft says not to go  
> >  over
> >  50, but hey, this is ReactOS....reading docs?? HAHAHA!!
> >
> >  I've looked over Stefan's code and it is perfect, and sets a correct
> >  stall factor.
> >
> >  On 2009-10-27, at 8:24 AM, Sylvain Petreolle wrote:
> >
> > >   It was present here in VirtualBox  3.0.8 for some
> > > time
> > >  and disappeared after Stefan's change for exception management.
> > >  Kind regards,
> > >  Sylvain Petreolle
> > >
> > >
> > >     *De :* Gabriel ilardi <gabrielilardi(a)hotmail.it
> > >     <mailto:[e-mail]>>
> > >     *À :* ros-dev &lt;ros-dev(a)reactos.org <mailto:[e-mail]>>
> > >     *Envoyé le :* Mar 27 Octobre 2009, 11 h 44 min 19 s
> > >     *Objet :* Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace
> > >     broken implementation of HalpCalibrateStallExecution with a new
> > >     implementation by a mysterious HAL ninja and myself. The old
> > >     implementation calculated the stall count factor incorrectly and
> > >     produced
> > >
> > >     Hi Johannes,
> > >
> > >     It wasn't present for VirtualBox though, at least for me.
> > >
> > >     Best regards,
> > >     Gabriel.
> > >
> > > >   Date: Tue, 27 Oct 2009 11:34:03 +0100
> > > >  From: janderwald(a)reactos.org <mailto:[e-mail]>
> > > >  To: ros-dev(a)reactos.org <mailto:[e-mail]>
> > > >  Subject: Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace 
> > >     broken
> > > implementation of HalpCalibrateStallExecution with a new
> > >     implementation by a mysterious HAL ninja and myself. The old
> > >     implementation calculated the stall count factor incorrectly and
> > >     produced bogus resu
> > > >  
> > > >  Gabriel ilardi schrieb:
> > > > > 2) In second stage when loading UniATA, it stays there for 
> > >     about 4-5
> > > >  > seconds, there was no delay before.
> > > > >
> > > >  Hi,
> > > >
> > > >  The UniATA delay in 2nd stage was already present before that 
> > >     commit.
> > > >   However, only in VMware.
> > > > >
> > > > > Best regards,
> > > > > Gabriel.
> > > > >
> > > >  Best regards,
> > > >  Johannes Anderwald
> > > >
> > > >  _______________________________________________
> > > >  Ros-dev mailing list
> > > >  Ros-dev(a)reactos.org <mailto:[e-mail]>
> > > >  http://www.reactos.org/mailman/listinfo/ros-dev 
> > >      
> > >  ------------------------------------------------------------------------
> > >     Conosci il tuo Messenger? Scopri tutte le novità
> > >     <http://www.messenger.it/home_novita.aspx>
> > >
> > >  _______________________________________________
> > >  Ros-dev mailing list
> > >  Ros-dev(a)reactos.org <mailto:[e-mail]>
> > >  http://www.reactos.org/mailman/listinfo/ros-dev 
> >  Best regards,
> >  Alex Ionescu
> >
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev 
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 
Best regards,
Alex Ionescu

[KJK::Hyperion]

Alex Ionescu wrote:
>   I bet Hitler would've said the same at
> Nuremberg.... 
he wouldn't have, unlike us he had written a specification beforehand

[Sylvain Petreolle]

It was reported taking 10-20s in the past.
 Kind regards,
Sylvain Petreolle

----- Message d'origine ----
>   De : Alex Ionescu <ionucu(a)videotron.ca>
>  À : ReactOS Development List <ros-dev(a)reactos.org>
>  Envoyé le : Mar 27 Octobre 2009, 14 h 15 min 53 s
>  Objet : Re: [ros-dev] Re : [ros-diffs] [sginsberg] 43789: - Replace broken implementation
> of HalpCalibrateStallExecution with a new implementation by a mysterious HAL ninja and
> myself. The old implementation calculated the stall count factor incorrectly and produced
>  
>  And it continues to do its job today -- you added code telling UniATA  
>  "wait between 500ms and 5seconds", and it's working fine in trunk.
>  
>  Why are people complaining "it takes UniATA up to 5 seconds to boot"  
>  when this is exactly the code you intended to add?
>  
>  Also:
>  
>  "Maybe theres a better way to get this done, but it was enough for  
>  testing and did its job well."
>  
>  Is now my all-time favourite quote, ever.
>  
>  I bet Hitler would've said the same at Nuremberg....
>  
>  On 2009-10-27, at 8:50 AM, Daniel Reimer wrote:
>  
> >   These timers were added because some SATA
> > adapters are fucking slow in
> >  initializing and uniata would continue too early for them and this
> >  results in failures. Maybe theres a better way to get this done, but  
> >  it
> >  was enough for testing and did its job well.
> >
> >  Alex Ionescu schrieb:
> > >   The real problem is that UniATA is full of shit
> > > code from Aleksey  
> > >  that
> > >  does things like StallExecution(100000). Microsoft says not to go  
> > >  over
> > >  50, but hey, this is ReactOS....reading docs?? HAHAHA!!
> > >
> > >  I've looked over Stefan's code and it is perfect, and sets a correct
> > >  stall factor.
> > >
> > >  On 2009-10-27, at 8:24 AM, Sylvain Petreolle wrote:
> > >
> > > >   It was present here in VirtualBox  3.0.8 for some
> > > > time
> > > >  and disappeared after Stefan's change for exception management.
> > > >  Kind regards,
> > > >  Sylvain Petreolle
> > > >
> > > >
> > > >     *De :* Gabriel ilardi 
> > > >     >
> > > >     *À :* ros-dev >
> > > >     *Envoyé le :* Mar 27 Octobre 2009, 11 h 44 min 19 s
> > > >     *Objet :* Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace
> > > >     broken implementation of HalpCalibrateStallExecution with a new
> > > >     implementation by a mysterious HAL ninja and myself. The old
> > > >     implementation calculated the stall count factor incorrectly and
> > > >     produced
> > > >
> > > >     Hi Johannes,
> > > >
> > > >     It wasn't present for VirtualBox though, at least for me.
> > > >
> > > >     Best regards,
> > > >     Gabriel.
> > > >
> > > > > Date: Tue, 27 Oct 2009 11:34:03 +0100
> > > > > From: janderwald(a)reactos.org 
> > > > > To: ros-dev(a)reactos.org 
> > > > > Subject: Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace
> > > >     broken implementation of HalpCalibrateStallExecution with a new
> > > >     implementation by a mysterious HAL ninja and myself. The old
> > > >     implementation calculated the stall count factor incorrectly and
> > > >     produced bogus resu
> > > > >
> > > > > Gabriel ilardi schrieb:
> > > > >> 2) In second stage when loading UniATA, it stays there for
> > > >     about 4-5
> > > > >> seconds, there was no delay before.
> > > > >>
> > > > > Hi,
> > > > >
> > > > > The UniATA delay in 2nd stage was already present before that
> > > >     commit.
> > > > > However, only in VMware.
> > > > >>
> > > > >> Best regards,
> > > > >> Gabriel.
> > > > >>
> > > > > Best regards,
> > > > > Johannes Anderwald
> > > > >
> > > > > _______________________________________________
> > > > > Ros-dev mailing list
> > > > > Ros-dev(a)reactos.org 
> > > > > http://www.reactos.org/mailman/listinfo/ros-dev
> > > >
> > > >     
> > > >  ------------------------------------------------------------------------
> > > >     Conosci il tuo Messenger? Scopri tutte le novità
> > > >     
> > > >
> > > >  _______________________________________________
> > > >  Ros-dev mailing list
> > > >  Ros-dev(a)reactos.org 
> > > >  http://www.reactos.org/mailman/listinfo/ros-dev 
> > >  Best regards,
> > >  Alex Ionescu
> > >
> > >
> > >  _______________________________________________
> > >  Ros-dev mailing list
> > >  Ros-dev(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-dev 
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev 
>  
>  Best regards,
>  Alex Ionescu
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Aleksey Bragin]

I tested the new implementation in same vmware environment, 5 boot  
ups, here are values of the stall factor:
921
2426
873
2405
2405

I can't say it's a huge success over the old implementation (it  
provided values in the 1000 - 4000 range in the same environment),  
taking in mind how more complex the code became (it even has its own  
ISR handler embedded into the function!!).

WBR,
Aleksey Bragin.

On Oct 27, 2009, at 4:15 PM, Alex Ionescu wrote:

>   And it continues to do its job today -- you added code
> telling UniATA
>  "wait between 500ms and 5seconds", and it's working fine in trunk.
>
>  Why are people complaining "it takes UniATA up to 5 seconds to boot"
>  when this is exactly the code you intended to add?
>
>  Also:
>
>  "Maybe theres a better way to get this done, but it was enough for
>  testing and did its job well."
>
>  Is now my all-time favourite quote, ever.
>
>  I bet Hitler would've said the same at Nuremberg....
>
>  On 2009-10-27, at 8:50 AM, Daniel Reimer wrote:
>
> >   These timers were added because some SATA
> > adapters are fucking  
> >  slow in
> >  initializing and uniata would continue too early for them and this
> >  results in failures. Maybe theres a better way to get this done, but
> >  it
> >  was enough for testing and did its job well.
> >
> >  Alex Ionescu schrieb:
> > > The real problem is that UniATA is full of shit code from Aleksey
> > > that
> > > does things like StallExecution(100000). Microsoft says not to go
> > > over
> > > 50, but hey, this is ReactOS....reading docs?? HAHAHA!!
> > >
> > > I've looked over Stefan's code and it is perfect, and sets a correct
> > > stall factor.
> > >
> > > On 2009-10-27, at 8:24 AM, Sylvain Petreolle wrote:
> > >
> > >> It was present here in VirtualBox  3.0.8 for some time
> > >> and disappeared after Stefan's change for exception management.
> > >> Kind regards,
> > >> Sylvain Petreolle
> > >>
> > >>
> > >>    *De :* Gabriel ilardi <gabrielilardi(a)hotmail.it
> > >>    <mailto:[e-mail]>>
> > >>    *À :* ros-dev &lt;ros-dev(a)reactos.org <mailto:[e-mail]>>
> > >>    *Envoyé le :* Mar 27 Octobre 2009, 11 h 44 min 19 s
> > >>    *Objet :* Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace
> > >>    broken implementation of HalpCalibrateStallExecution with a new
> > >>    implementation by a mysterious HAL ninja and myself. The old
> > >>    implementation calculated the stall count factor incorrectly and
> > >>    produced
> > >>
> > >>    Hi Johannes,
> > >>
> > >>    It wasn't present for VirtualBox though, at least for me.
> > >>
> > >>    Best regards,
> > >>    Gabriel.
> > >>
> > >>> Date: Tue, 27 Oct 2009 11:34:03 +0100
> > >>> From: janderwald(a)reactos.org <mailto:[e-mail]>
> > >>> To: ros-dev(a)reactos.org <mailto:[e-mail]>
> > >>> Subject: Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace
> > >>    broken implementation of HalpCalibrateStallExecution with a new
> > >>    implementation by a mysterious HAL ninja and myself. The old
> > >>    implementation calculated the stall count factor incorrectly and
> > >>    produced bogus resu
> > >>>
> > >>> Gabriel ilardi schrieb:
> > >>>> 2) In second stage when loading UniATA, it stays there for
> > >>    about 4-5
> > >>>> seconds, there was no delay before.
> > >>>>
> > >>> Hi,
> > >>>
> > >>> The UniATA delay in 2nd stage was already present before that
> > >>    commit.
> > >>> However, only in VMware.
> > >>>>
> > >>>> Best regards,
> > >>>> Gabriel.
> > >>>>
> > >>> Best regards,
> > >>> Johannes Anderwald
> > >
> > > Best regards,
> > > Alex Ionescu 
>  Best regards,
>  Alex Ionescu

[Alex Ionescu]

Hi,

Maybe you could try not moving the mouse during VMWare?! How can you  
even test this in a VM?!? It doesn't make ANY SENSE. There are a  
MILLION things going on in the background of your VM whenever you test  
this.

*THREE* of your 5 tests all gave nearly the SAME answer, and the two  
different value are ALSO the same, simply meaning that some event  
happened 2/5th of the time which slowed down the VM (like an interrupt).

Your output shows that the code is working PERFECTLY.

The code is not complex at all, it's barely 10 lines of pseudo-code.

You people don't understand the very BASICS of hardware-level  
development, emulation, virtualization, timers and RTCs. it is  
outrageous that you're even posting these kinds of e-mails on a public  
e-mail list. You should be ****EMBARRASSED*****.

Hint: What results are better on a VM?

500, 490, 510, 8000, 7900, 8100, 5000, 4900, 5100

OR

500, 800, 1000, 1400, 1600, 1800, 2000

???

Based on your e-mail and comparing old/new output, it seems you  
believe #2 is better, because "the values are only between 500 and  
2000, but new implementation goes between 500 and 5100!".

If you don't understand why #1 is better, please don't even bother  
replying.

And now, for the other geniuses on this list, there is a BIG BUG in  
ReactOS, that NOBODY CAN FIGURE OUT.

Can *YOU* solve it???

Here it is:

We have a function:

void a(int waitTime)
{
     for (int i = waitTime * Factor; i > 0; i--);
}

And a Factor that used to be 64 or some other low value.

People called a with a very large number.

Now, the Factor is a large number, in the thousands.

People have NO idea why, now, calling a "takes much longer now?!? :(".

5000$ if you can figure it out, paid straight out of ROS foundation!  
Only a genius could figure this out...

But you know what the STRANGEST thing is?

Windows behaves the same way in Vmware!

In fact, Windows drivers even DEPEND on this behavior!

Quick, someone, tell Microsoft! Their engineers are stupid too! This  
kind of code should give random values between 1000 and 4000 in a VM,  
not accurate timing counts based on interruptions of the VM emulation  
code!

On 2009-10-27, at 12:36 PM, Aleksey Bragin wrote:

>   I tested the new implementation in same vmware
> environment, 5 boot
>  ups, here are values of the stall factor:
>  921
>  2426
>  873
>  2405
>  2405
>
>  I can't say it's a huge success over the old implementation (it
>  provided values in the 1000 - 4000 range in the same environment),
>  taking in mind how more complex the code became (it even has its own
>  ISR handler embedded into the function!!).
>
>  WBR,
>  Aleksey Bragin.
>
>  On Oct 27, 2009, at 4:15 PM, Alex Ionescu wrote:
>
> >   And it continues to do its job today -- you added
> > code telling UniATA
> >  "wait between 500ms and 5seconds", and it's working fine in trunk.
> >
> >  Why are people complaining "it takes UniATA up to 5 seconds to boot"
> >  when this is exactly the code you intended to add?
> >
> >  Also:
> >
> >  "Maybe theres a better way to get this done, but it was enough for
> >  testing and did its job well."
> >
> >  Is now my all-time favourite quote, ever.
> >
> >  I bet Hitler would've said the same at Nuremberg....
> >
> >  On 2009-10-27, at 8:50 AM, Daniel Reimer wrote:
> >
> > >   These timers were added because some SATA
> > > adapters are fucking
> > >  slow in
> > >  initializing and uniata would continue too early for them and this
> > >  results in failures. Maybe theres a better way to get this done, but
> > >  it
> > >  was enough for testing and did its job well.
> > >
> > >  Alex Ionescu schrieb:
> > > > The real problem is that UniATA is full of shit code from Aleksey
> > > > that
> > > > does things like StallExecution(100000). Microsoft says not to go
> > > > over
> > > > 50, but hey, this is ReactOS....reading docs?? HAHAHA!!
> > > >
> > > > I've looked over Stefan's code and it is perfect, and sets a  
> > > > correct
> > > > stall factor.
> > > >
> > > > On 2009-10-27, at 8:24 AM, Sylvain Petreolle wrote:
> > > >
> > > >> It was present here in VirtualBox  3.0.8 for some time
> > > >> and disappeared after Stefan's change for exception management.
> > > >> Kind regards,
> > > >> Sylvain Petreolle
> > > >>
> > > >>
> > > >>   *De :* Gabriel ilardi <gabrielilardi(a)hotmail.it
> > > >>   <mailto:[e-mail]>>
> > > >>   *À :* ros-dev &lt;ros-dev(a)reactos.org <mailto:[e-mail]>>
> > > >>   *Envoyé le :* Mar 27 Octobre 2009, 11 h 44 min 19 s
> > > >>   *Objet :* Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace
> > > >>   broken implementation of HalpCalibrateStallExecution with a new
> > > >>   implementation by a mysterious HAL ninja and myself. The old
> > > >>   implementation calculated the stall count factor incorrectly and
> > > >>   produced
> > > >>
> > > >>   Hi Johannes,
> > > >>
> > > >>   It wasn't present for VirtualBox though, at least for me.
> > > >>
> > > >>   Best regards,
> > > >>   Gabriel.
> > > >>
> > > >>> Date: Tue, 27 Oct 2009 11:34:03 +0100
> > > >>> From: janderwald(a)reactos.org <mailto:[e-mail]>
> > > >>> To: ros-dev(a)reactos.org <mailto:[e-mail]>
> > > >>> Subject: Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace
> > > >>   broken implementation of HalpCalibrateStallExecution with a new
> > > >>   implementation by a mysterious HAL ninja and myself. The old
> > > >>   implementation calculated the stall count factor incorrectly and
> > > >>   produced bogus resu
> > > >>>
> > > >>> Gabriel ilardi schrieb:
> > > >>>> 2) In second stage when loading UniATA, it stays there for
> > > >>   about 4-5
> > > >>>> seconds, there was no delay before.
> > > >>>>
> > > >>> Hi,
> > > >>>
> > > >>> The UniATA delay in 2nd stage was already present before that
> > > >>   commit.
> > > >>> However, only in VMware.
> > > >>>>
> > > >>>> Best regards,
> > > >>>> Gabriel.
> > > >>>>
> > > >>> Best regards,
> > > >>> Johannes Anderwald
> > > >
> > > > Best regards,
> > > > Alex Ionescu 
> >  Best regards,
> >  Alex Ionescu 
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 
Best regards,
Alex Ionescu

[KJK::Hyperion]

Alex, I don't have the slightest clue what you just said. Nobody knows
where you are being serious, where you are being sarcastic, and where
you are being cute by pretending to be sarcastic but actually being...
serious? I have no fucking idea. Please give us a straight explaination,
or... shut up. I won't deny the entertainment value of our very own,
harmless Dave Cutler wannabe, but this sounds like a serious issue about
which you have a serious opinion... somewhere.

[Aleksey Bragin]

I didn't say old implementation was correct, it wasn't really.  
Neither I try pretend to be a non-understanding troll.

I'm just nitpicking to the commit message which named a number of  
reasons, none of them being correct except the first one:
>   Subject: [ros-diffs] [sginsberg] 43789:
>  - Replace broken implementation of HalpCalibrateStallExecution   
with a new
implementation by a mysterious HAL ninja and myself. The old
Yes, it was broken.

>   implementation calculated the stall count factor
> incorrectly and   
produced bogus results that were off by several thousand, and
varied  
by as much for
>   each boot, and can best be described as "rand()
> made complicated".   
The new implementation installs its own RTC interrupt
handler to  
accurately
Total lie, Alex explained why. It can't be called "totally broken" if  
tested in a virtual machine! Though results were used to judge the  
implementation I committed previously. Did anyone test in real  
hardware, collected stall factors statistics and performed the tests  
attached to the end of this function? Noone? You should be  
****EMBARRASSED*****!

>   calculate the stall scale factor, all done in
> assembler instead of   
broken C.
Let's write whole OS in assembler, it's gonna be less broken then!  
This is the lamest excuse ever.

>   Fixes the hang at boot when initializing Uniata as
> stalls no   
longer takes 10 times or more as long to execute then they should.
As I quoted in my test results, it was only ~2.5-3 times more than  
necessary, not 10. So another part of a problem is in uniata having  
too long delays (I took the figures from reference Microsoft DDK  
storage drivers, if I recall correctly).

WBR,
Aleksey Bragin.

On Oct 27, 2009, at 8:27 PM, Alex Ionescu wrote:

>   Hi,
>
>  Maybe you could try not moving the mouse during VMWare?! How can you
>  even test this in a VM?!? It doesn't make ANY SENSE. There are a
>  MILLION things going on in the background of your VM whenever you test
>  this.
>
>  *THREE* of your 5 tests all gave nearly the SAME answer, and the two
>  different value are ALSO the same, simply meaning that some event
>  happened 2/5th of the time which slowed down the VM (like an  
>  interrupt).
>
>  Your output shows that the code is working PERFECTLY.
>
>  The code is not complex at all, it's barely 10 lines of pseudo-code.
>
>  You people don't understand the very BASICS of hardware-level
>  development, emulation, virtualization, timers and RTCs. it is
>  outrageous that you're even posting these kinds of e-mails on a public
>  e-mail list. You should be ****EMBARRASSED*****.
>
>  Hint: What results are better on a VM?
>
>  500, 490, 510, 8000, 7900, 8100, 5000, 4900, 5100
>
>  OR
>
>  500, 800, 1000, 1400, 1600, 1800, 2000
>
>  ???
>
>  Based on your e-mail and comparing old/new output, it seems you
>  believe #2 is better, because "the values are only between 500 and
>  2000, but new implementation goes between 500 and 5100!".
>
>  If you don't understand why #1 is better, please don't even bother
>  replying.
>
>  And now, for the other geniuses on this list, there is a BIG BUG in
>  ReactOS, that NOBODY CAN FIGURE OUT.
>
>  Can *YOU* solve it???
>
>  Here it is:
>
>  We have a function:
>
>  void a(int waitTime)
>  {
>       for (int i = waitTime * Factor; i > 0; i--);
>  }
>
>  And a Factor that used to be 64 or some other low value.
>
>  People called a with a very large number.
>
>  Now, the Factor is a large number, in the thousands.
>
>  People have NO idea why, now, calling a "takes much longer now?!? :(".
>
>  5000$ if you can figure it out, paid straight out of ROS foundation!
>  Only a genius could figure this out...
>
>  But you know what the STRANGEST thing is?
>
>  Windows behaves the same way in Vmware!
>
>  In fact, Windows drivers even DEPEND on this behavior!
>
>  Quick, someone, tell Microsoft! Their engineers are stupid too! This
>  kind of code should give random values between 1000 and 4000 in a VM,
>  not accurate timing counts based on interruptions of the VM emulation
>  code!
>
>  On 2009-10-27, at 12:36 PM, Aleksey Bragin wrote:
>
> >   I tested the new implementation in same vmware
> > environment, 5 boot
> >  ups, here are values of the stall factor:
> >  921
> >  2426
> >  873
> >  2405
> >  2405
> >
> >  I can't say it's a huge success over the old implementation (it
> >  provided values in the 1000 - 4000 range in the same environment),
> >  taking in mind how more complex the code became (it even has its own
> >  ISR handler embedded into the function!!).
> >
> >  WBR,
> >  Aleksey Bragin.
> >
> >  On Oct 27, 2009, at 4:15 PM, Alex Ionescu wrote:
> >
> > >   And it continues to do its job today -- you added
> > > code telling  
> > >  UniATA
> > >  "wait between 500ms and 5seconds", and it's working fine in trunk.
> > >
> > >  Why are people complaining "it takes UniATA up to 5 seconds to boot"
> > >  when this is exactly the code you intended to add?
> > >
> > >  Also:
> > >
> > >  "Maybe theres a better way to get this done, but it was enough for
> > >  testing and did its job well."
> > >
> > >  Is now my all-time favourite quote, ever.
> > >
> > >  I bet Hitler would've said the same at Nuremberg....
> > >
> > >  On 2009-10-27, at 8:50 AM, Daniel Reimer wrote:
> > >
> > > >   These timers were added because some SATA
> > > > adapters are fucking
> > > >  slow in
> > > >  initializing and uniata would continue too early for them and this
> > > >  results in failures. Maybe theres a better way to get this done,  
> > > >  but
> > > >  it
> > > >  was enough for testing and did its job well.
> > > >
> > > >  Alex Ionescu schrieb:
> > > > > The real problem is that UniATA is full of shit code from Aleksey
> > > > > that
> > > > > does things like StallExecution(100000). Microsoft says not to go
> > > > > over
> > > > > 50, but hey, this is ReactOS....reading docs?? HAHAHA!!
> > > > >
> > > > > I've looked over Stefan's code and it is perfect, and sets a
> > > > > correct
> > > > > stall factor.
> > > > >
> > > > > On 2009-10-27, at 8:24 AM, Sylvain Petreolle wrote:
> > > > >
> > > > >> It was present here in VirtualBox  3.0.8 for some time
> > > > >> and disappeared after Stefan's change for exception management.
> > > > >> Kind regards,
> > > > >> Sylvain Petreolle
> > > > >>
> > > > >>
> > > > >>   *De :* Gabriel ilardi <gabrielilardi(a)hotmail.it
> > > > >>   <mailto:[e-mail]>>
> > > > >>   *À :* ros-dev &lt;ros-dev(a)reactos.org <mailto:ros- 
> > > > >> dev(a)reactos.org&gt;&gt;
> > > > >>   *Envoyé le :* Mar 27 Octobre 2009, 11 h 44 min 19 s
> > > > >>   *Objet :* Re: [ros-dev] [ros-diffs] [sginsberg] 43789: -  
> > > > >> Replace
> > > > >>   broken implementation of HalpCalibrateStallExecution with a new
> > > > >>   implementation by a mysterious HAL ninja and myself. The old
> > > > >>   implementation calculated the stall count factor incorrectly  
> > > > >> and
> > > > >>   produced
> > > > >>
> > > > >>   Hi Johannes,
> > > > >>
> > > > >>   It wasn't present for VirtualBox though, at least for me.
> > > > >>
> > > > >>   Best regards,
> > > > >>   Gabriel.
> > > > >>
> > > > >>> Date: Tue, 27 Oct 2009 11:34:03 +0100
> > > > >>> From: janderwald(a)reactos.org <mailto:[e-mail]>
> > > > >>> To: ros-dev(a)reactos.org <mailto:[e-mail]>
> > > > >>> Subject: Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace
> > > > >>   broken implementation of HalpCalibrateStallExecution with a new
> > > > >>   implementation by a mysterious HAL ninja and myself. The old
> > > > >>   implementation calculated the stall count factor incorrectly  
> > > > >> and
> > > > >>   produced bogus resu
> > > > >>>
> > > > >>> Gabriel ilardi schrieb:
> > > > >>>> 2) In second stage when loading UniATA, it stays there for
> > > > >>   about 4-5
> > > > >>>> seconds, there was no delay before.
> > > > >>>>
> > > > >>> Hi,
> > > > >>>
> > > > >>> The UniATA delay in 2nd stage was already present before that
> > > > >>   commit.
> > > > >>> However, only in VMware.
> > > > >>>>
> > > > >>>> Best regards,
> > > > >>>> Gabriel.
> > > > >>>>
> > > > >>> Best regards,
> > > > >>> Johannes Anderwald
> > > > >
> > > > > Best regards,
> > > > > Alex Ionescu 
> > >  Best regards,
> > >  Alex Ionescu 
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev 
>  Best regards,
>  Alex Ionescu
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev