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@reactos.org From: sginsberg@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/systimer... ============================================================================== --- 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
Gabriel ilardi schrieb:
- 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
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@reactos.org To: ros-dev@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:
- 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
_________________________________________________________________ Racconta la tua estate, crea il tuo blog. http://www.windowslive.it/spaces.aspx
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@hotmail.it À : ros-dev ros-dev@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@reactos.org To: ros-dev@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:
- 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Conosci il tuo Messenger? Scopri tutte le novità
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@hotmail.it À : ros-dev ros-dev@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@reactos.org To: ros-dev@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:
- 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Conosci il tuo Messenger? Scopri tutte le novità _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
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@hotmail.it <mailto:gabrielilardi@hotmail.it>> *À :* ros-dev <ros-dev@reactos.org <mailto:ros-dev@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@reactos.org <mailto:janderwald@reactos.org> > To: ros-dev@reactos.org <mailto:ros-dev@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@reactos.org <mailto:Ros-dev@reactos.org> > 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@reactos.org mailto:Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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@hotmail.it mailto:gabrielilardi@hotmail.it> *À :* ros-dev <ros-dev@reactos.org mailto:ros-dev@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@reactos.org mailto:janderwald@reactos.org To: ros-dev@reactos.org mailto:ros-dev@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:
- 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@reactos.org mailto:Ros-dev@reactos.org 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@reactos.org mailto:Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
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
It was reported taking 10-20s in the past. Kind regards, Sylvain Petreolle
----- Message d'origine ----
De : Alex Ionescu ionucu@videotron.ca À : ReactOS Development List ros-dev@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@reactos.org To: ros-dev@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:
- 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Conosci il tuo Messenger? Scopri tutte le novità
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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@hotmail.it mailto:gabrielilardi@hotmail.it> *À :* ros-dev <ros-dev@reactos.org mailto:ros-dev@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@reactos.org mailto:janderwald@reactos.org To: ros-dev@reactos.org mailto:ros-dev@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:
- 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
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@hotmail.it mailto:gabrielilardi@hotmail.it> *À :* ros-dev <ros-dev@reactos.org mailto:ros-dev@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@reactos.org mailto:janderwald@reactos.org To: ros-dev@reactos.org mailto:ros-dev@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
Best regards, Alex Ionescu
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
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.
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@hotmail.it mailto:gabrielilardi@hotmail.it> *À :* ros-dev <ros-dev@reactos.org <mailto:ros- dev@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@reactos.org mailto:janderwald@reactos.org > To: ros-dev@reactos.org mailto:ros-dev@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
Best regards, Alex Ionescu
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev