Custom Query (16363 matches)
Results (1249 - 1251 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #7604 | obsolete | abort / TrustedError / supR3HardenedStaticFatalMsg | ||
| Description |
I'm not quite sure what I was doing when this happened. 3 libSystem.B.dylib 0x95db96e4 abort + 93 4 QtCoreVBox 0x010038c5 qt_message_output(QtMsgType, char const*) + 149 5 QtCoreVBox 0x01003ab6 qt_message(QtMsgType, char const*, char*) + 182 6 QtCoreVBox 0x01003bf9 qFatal(char const*, ...) + 25 7 VirtualBox.dylib 0x0020ebdc TrustedError + 620 8 VirtualBoxVM 0x0000351a supR3HardenedStaticFatalMsgV + 426 9 VirtualBoxVM 0x00003580 supR3HardenedStaticFatalMsg + 48 10 VirtualBoxVM 0x00003a59 SUPR3HardenedMain + 1225 11 VirtualBoxVM 0x00002c81 main + 65 12 VirtualBoxVM 0x00002c06 start + 54 |
|||
| #7607 | obsolete | Windows Terminal Server 2008 unusably slow after upgrade from 3.2.4 and databases getting corrupted | ||
| Description |
Hi All, This bug is being reported as critical as it corrupted one of my customers databases. Host: Motherboard: Supermicro X8SAX Processor: x5650 (6 hard cores costing $1,200.00) Memory: 12 GB OS: CentOS 5.5 x64 Guest: Windows Terminal Server 2008 x32, Service Pack 2 VM: VBox 3.2.10 Before I get started, please note that bug 6928 was a Nested Paging bug and does not apply to this bug. The bug I am now reporting was uncovered while working on 6928. On 2010-09-15 under bug 6928, I reported that when I upgrade from 3.2.4 to 3.2.8, with one software processor, that my Windows Terminal Server 2008 slowed to an excruciating crawl. I then reverted to 3.1.8 and got back to normal, still on one software processor. On 10-18-2010 on bug 6928, I upgraded from 3.1.8 to 3.2.10 and from one soft processor to four hardware cores. The good news in that bug 6928 is fixed. The CPU storm is gone. But the massive slow down when I tried upgrading from 3.2.4 to 3.2.8 is still there. And it does not matter if you are using a single soft processor or multiple hard processors. Note that Windows Terminal Server 2003, x32 worked beautifully under bug 6928's 3.2.10 patch. So, this bug is confined to Windows Terminal Server 2008 x32, SP2. Also, in my 10-18-2010 testing of 3.2.10 on my Windows Terminal Server 2008 x32, SP2, a customer's database got corrupted. The report from the customer was that his program slowed down so excruciatingly slow that the whole thing eventually seized up. (I restored his database to Saturday night's snapshot. Fortunately, he did not use the server on Sunday.) Please correct this bug as soon as possible. My Windows Terminal Server 2008 x32, SP2 is highly impacted, being relegated to one soft processor, and my customers are being poorly served. It would also be nice to FINALLY start being able to use my $1,200.00 processor. I have attached both the 3.1.8 and the 3.2.10 XML files. Please let me know if I can be of assistance in resolving this bug. Many thanks, -T |
|||
| #7609 | obsolete | Windows XP Guest - timeBeginPeriod( ) slows system clock | ||
| Description |
A system service running in a Windows XP SP3 Guest can use the Windows "timeBeginPeriod( )" function to change the system time tick resolution. That is common with multimedia or real-time applications. I have such a system service. After the service has changed the Windows XP Guest timer resolution a problem occurs when running on a Windows 7 Host. The system time in the Guest updates at a much slower rate than normal and the time in the Guest falls behind the correct time. Any time related events occur at a slower than normal rate. For example, desktop fade effects, animated mouse pointers, Task Manager refreshing, and multimedia applications all appear to be "slow" due to the system time updating at a slower rate. When the Windows time resolution is set back to the default by the system service then the time behaves normally again. If the Windows clock is reset to the correct time then it remains correct. The service changes the time using this code. TIMECAPS tc;
/* Get time capabilities of system */
if (timeGetDevCaps(&tc, sizeof(TIMECAPS)) != TIMERR_NOERROR)
{
Critical( );
}
/* Set the highest possible timer resolution (1 ms. if possible) */
gwTimerRes = min(max(tc.wPeriodMin, 1), tc.wPeriodMax);
if ( timeBeginPeriod(gwTimerRes) != TIMERR_NOERROR )
{
Critical( );
}
When the service is stopped it sets the time resolution back to normal. /* Set the timer resolution back to normal */
if ( timeEndPeriod(gwTimerRes) != TIMERR_NOERROR ) {}
Other than the system time and timers being "slow" there are no other apparent problems in the Guest OS. I did not see excessive CPU usage, I/O or Interrupt activity. Although many things appear "slow" due to the incorrect time updates the execution of CPU instructions in the Guest does not seem to be affected. I verified that the "timeBeginPeriod( )" Windows function causes the problem to occur and that the problem stops after calling "timeEndPeriod( )". This problem might explain some of the "Slow Windows Guest" complaints that are unresolved. The curious thing about the problem is that it does not appear to happen with Linux Host OS. I have also tested the system service on a number of real PCs in order to verify that the problem is not the system service. After only seeing the problem in a VirtualBox guest I decided to investigate the problem further. I removed code from the system service until I found the functions causing the problem. The problem also occurs with version 3.2.8 of VirtualBox under the same conditions. The problem occurs with or without the Guest Additions installed. |
|||

