Custom Query (16363 matches)
Results (1429 - 1431 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #2524 | fixed | data corruption under heavy I/O load on host | ||
| 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 | ||
| Description |
Host machine: Core 2 Duo 6600, 2 GB RAM.
Partially the problem is mentioned in the forum threads: 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:
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 factorsI 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 | ||
| 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. |
|||

