VirtualBox

Custom Query (16363 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (1429 - 1431 of 16363)

Ticket Resolution Summary Owner Reporter
#2524 fixed data corruption under heavy I/O load on host Georg Moritz
Description

Heavy I/O load on the host leads to ide dma timeouts, device resets, incorrect read/write operations and ultimately to data corruption in the VBox.

It looks like iowait conditions on the host don't lead to a blocking of the virtual

vb10:~# tail -n 0 -f /var/log/messages
Oct 27 18:28:35 vb10 kernel: [ 1559.569320] hdb: dma_timer_expiry: dma status == 0x61
Oct 27 18:28:45 vb10 kernel: [ 1569.569594] hdb: DMA timeout error
Oct 27 18:28:45 vb10 kernel: [ 1569.570105] hdb: dma timeout error: status=0x48 { DriveReady DataRequest }
Oct 27 18:28:45 vb10 kernel: [ 1569.570127] ide: failed opcode was: unknown
Oct 27 18:28:45 vb10 kernel: [ 1569.570766] hda: DMA disabled
Oct 27 18:28:45 vb10 kernel: [ 1569.572039] hdb: DMA disabled
Oct 27 18:29:20 vb10 kernel: [ 1599.568186] ide0: reset timed-out, status=0x90
Oct 27 18:29:20 vb10 kernel: [ 1604.572374] hda: status timeout: status=0x90 { Busy }
Oct 27 18:29:20 vb10 kernel: [ 1604.572396] ide: failed opcode was: unknown
Oct 27 18:29:20 vb10 kernel: [ 1604.580286] Clocksource tsc unstable (delta = 4687228551 ns)
Oct 27 18:30:00 vb10 kernel: quest: I/O error, dev hdb, sector 506799
Oct 27 18:30:01 vb10 kernel: [ 1635.421648] __ratelimit: 5022 messages suppressed
Oct 27 18:30:01 vb10 kernel: [ 1635.421648] lost page write due to I/O error on hdb1
Oct 27 18:31:02 vb10 kernel: nd_request: I/O error, dev hdb, sector 551111
Oct 27 18:31:09 vb10 kernel: [ 1714.280038] __ratelimit: 5014 messages suppressed
Oct 27 18:31:09 vb10 kernel: [ 1714.280038] lost page write due to I/O error on hdb1
Oct 27 18:31:20 vb10 kernel: [ 1725.024393] lost page write due to I/O error on hdb1
Oct 27 18:31:26 vb10 kernel: [ 1730.728966] lost page write due to I/O error on hdb1
Oct 27 18:31:29 vb10 kernel: [ 1733.614585] lost page write due to I/O error on hdb1
Oct 27 18:31:29 vb10 kernel: [ 1733.905566] lost page write due to I/O error on hdb1
Oct 27 18:31:31 vb10 kernel: [ 1736.305170] __ratelimit: 10 messages suppressed
Oct 27 18:31:31 vb10 kernel: [ 1736.305403] lost page write due to I/O error on hdb1
Oct 27 18:31:36 vb10 kernel: [ 1741.416768] __ratelimit: 23 messages suppressed
Oct 27 18:31:36 vb10 kernel: [ 1741.417144] lost page write due to I/O error on hdb1
Oct 27 18:31:41 vb10 kernel: [ 1746.255712] __ratelimit: 21 messages suppressed
Oct 27 18:31:41 vb10 kernel: [ 1746.255917] lost page write due to I/O error on hdb1
Oct 27 18:31:46 vb10 kernel: [ 1751.279075] __ratelimit: 22 messages suppressed
Oct 27 18:31:46 vb10 kernel: [ 1751.279288] lost page write due to I/O error on hdb1
Oct 27 18:31:51 vb10 kernel: [ 1756.235377] __ratelimit: 20 messages suppressed
Oct 27 18:31:51 vb10 kernel: [ 1756.235377] lost page write due to I/O error on hdb1
Oct 27 18:31:56 vb10 kernel: [ 1761.304274] __ratelimit: 20 messages suppressed
Oct 27 18:31:56 vb10 kernel: [ 1761.304455] lost page write due to I/O error on hdb1
Oct 27 18:32:01 vb10 kernel: 009488] end_request: I/O error, dev hdb, sector 580247
Oct 27 18:32:03 vb10 kernel: r, dev hdb, sector 601439
Oct 27 18:32:03 vb10 kernel: [ 1767.301521] __journal_remove_journal_head: freeing b_frozen_data
^C
vb10:~# ls -l /data
ls: cannot access /data/lost+found: Input/output error
total 260968
-rw-r----- 1 root root 266964992 2008-10-27 18:30 foo.img
d????????? ? ?    ?            ?                ? lost+found
vb10:~#

It looks like iowait conditions on the host don't lead to the blocking of the virtual pci bus, which results in the disk driver to run into timeouts as per the pci spec.

Setup:

Host: 8 CPUs, 32 GB RAM, 2.8 TB RAID 5 divided into 32 logical volumes of 83 GB each, running debian lenny

VBoxes: 768 MB RAM, 1 GB ext3 root fs (hda), 11 GB ext3 data fs (hdb), running debian lenny

I have been testing throughput and stability running iozone simultaneously in different numbers of VBoxes. Corruption rate was 0 out of 4 (0/4), 5/8 and 16/16.

#2526 fixed Non-uniform internal timer in guest OS Konstantin Vlasov
Description

Host machine: Core 2 Duo 6600, 2 GB RAM.
Host OS: WinXP SP3
Guest OS: SUSE Linux Enterprise Server 10 SP2
GA installed

Partially the problem is mentioned in the forum threads:
http://forums.virtualbox.org/viewtopic.php?t=10396
http://forums.virtualbox.org/viewtopic.php?t=1335
and probably here:
http://forums.virtualbox.org/viewtopic.php?t=10745

However, I could find some more details which may be of use for reproducing and fixing the problem.


Problem description

The internal timer inside VM sometimes runs non-uniformly. It looks like following:

  1. At first the guest OS looks somewhat slow in every aspect (including system clock which shows seconds passing more slowly than on the host clock). So, as time passes, the guest clock become more and more mistimed with the host one.
  2. Then suddenly the virtual machine starts to catch up the host clock: guest OS works much faster than before, keyboard delays are extremely low (so when I try to type e.g. "grep", I get something like "ggggggrrrrrreeeeeppppp"), the guest clock are running very fast (several seconds pass within only one "host second").
  3. When guest timer equals to the host one, the speed returns back to normal, then again slows down, and then speeds up, and so on.

Lengths of the periods described can be different. Sometimes, it is slow for couple of minutes, then fast for 7-10 seconds; sometimes it's slow for several seconds, then fast for 0,5-1 second.

Additional factors

I wanted to record a video with this behaviour. However, each time I run video recorder (I'm using UVScreenCamera), the problem became unreproducable. Finally, I noticed that UVScreenCamera's recording process performs something that forces VirtualBox's guest clock catch up the host clock. And the more frames per second I set in the recorder's options, the more smoothly runs VirtualBox. So, it seems that each additional redraw operation (or something like that) makes VB forcibly perform that "catch up" operation, which otherwise would be delayed for the future.

#2528 fixed running ddd/gdb halts my Debian Etch 64-bit guest Stéphane Charette
Description

Host: Ubuntu 8.04 64-bit Guest: Debian Etch 64-bit VB: 2.0.4 64-bit Guest additions installed EXCEPT for vboxadd-timesync which is disabled due to ticket #2288. Mouse integration turned off due to ticket #2306.

I have a C++ application I want to debug. I start "ddd path/app" and as soon as I click on "run" my Debian Etch 64-bit guest comes to a halt. I'm presented with the following text:

"A critical error has occurred while running the virtual machine and the machine execution has been stopped. For help, please see the Community section...etc... Press OK if you want to power off the machine or press Ignore if you want to leave it as is for debugging. ...etc..."

I'll attach the files VBox.log and VBox.png.

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy