Custom Query (16363 matches)
Results (2518 - 2520 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #13214 | invalid | Possible source of panics (definitely in *BSD guests, possibly others) | ||
| Description |
Marked OS type as 'all' because found on FreeBSD, reproduced on OSX. Pertinent Config: IDE controller (any - tested with ICH6), HostIO cache on Not tested: Other controllers (eg SATA), HostIO cache off (it's very difficult to catch) Guest OS: FreeBSD (not tested OSX guest or linux) A guest drive becomes unavailable during write (loading cache etc, slow to respond OS etc) Guest gets (correctly) 'Drive Not Ready' from host. Host retries command Guest gets 'Drive Not Ready' from host. (Immediately) Host retries command Guest gets 'Drive Not Ready' from host. (Immediately) Host retries command Guest gets 'Drive Not Ready' from host. (Immediately) Host retries command Guest gets 'Drive Not Ready' from host. (Immediately) Host retries command Guest gets 'Drive Not Ready' from host. (Immediately) Kernel panics (rootfs unavailable), vnode/inode get corrupt, zfs panics kernel. Drive corrupted on reboot - causes subsequent panics. This was caught on my VM (finally - the retries were in a split second, real hardware would have taken over a minute): ZFS filesystem version: 5 ZFS storage pool version: features support (5000) (ada1:ata0:0:1:0): WRITE_DMA. ACB: ca 00 bf 8d b0 40 00 00 00 00 06 00 (ada1:ata0:0:1:0): CAM status: ATA Status Error (ada1:ata0:0:1:0): ATA status: 41 (DRDY ERR), error: 10 (IDNF ) (ada1:ata0:0:1:0): RES: 41 10 bf 8d b0 00 00 00 00 06 00 (ada1:ata0:0:1:0): Retrying command (ada1:ata0:0:1:0): WRITE_DMA. ACB: ca 00 bf 8d b0 40 00 00 00 00 06 00 (ada1:ata0:0:1:0): CAM status: ATA Status Error (ada1:ata0:0:1:0): ATA status: 41 (DRDY ERR), error: 10 (IDNF ) (ada1:ata0:0:1:0): RES: 41 10 bf 8d b0 00 00 00 00 06 00 (ada1:ata0:0:1:0): Retrying command (ada1:ata0:0:1:0): WRITE_DMA. ACB: ca 00 bf 8d b0 40 00 00 00 00 06 00 (ada1:ata0:0:1:0): CAM status: ATA Status Error (ada1:ata0:0:1:0): ATA status: 41 (DRDY ERR), error: 10 (IDNF ) (ada1:ata0:0:1:0): RES: 41 10 bf 8d b0 00 00 00 00 06 00 (ada1:ata0:0:1:0): Retrying command (ada1:ata0:0:1:0): WRITE_DMA. ACB: ca 00 bf 8d b0 40 00 00 00 00 06 00 (ada1:ata0:0:1:0): CAM status: ATA Status Error (ada1:ata0:0:1:0): ATA status: 41 (DRDY ERR), error: 10 (IDNF ) (ada1:ata0:0:1:0): RES: 41 10 bf 8d b0 00 00 00 00 06 00 (ada1:ata0:0:1:0): Retrying command (ada1:ata0:0:1:0): WRITE_DMA. ACB: ca 00 bf 8d b0 40 00 00 00 00 06 00 (ada1:ata0:0:1:0): CAM status: ATA Status Error (ada1:ata0:0:1:0): ATA status: 41 (DRDY ERR), error: 10 (IDNF ) (ada1:ata0:0:1:0): RES: 41 10 bf 8d b0 00 00 00 00 06 00 (ada1:ata0:0:1:0): Error 5, Retries exhausted (ada1:ata0:0:1:0): WRITE_DMA. ACB: ca 00 bf 8d b0 40 00 00 00 00 06 00 (ada1:ata0:0:1:0): CAM status: ATA Status Error (ada1:ata0:0:1:0): ATA status: 41 (DRDY ERR), error: 10 (IDNF ) (ada1:ata0:0:1:0): RES: 41 10 bf 8d b0 00 00 00 00 06 00 (ada1:ata0:0:1:0): Retrying command (ada1:ata0:0:1:0): WRITE_DMA. ACB: ca 00 bf 8d b0 40 00 00 00 00 06 00 (ada1:ata0:0:1:0): CAM status: ATA Status Error (ada1:ata0:0:1:0): ATA status: 41 (DRDY ERR), error: 10 (IDNF ) (ada1:ata0:0:1:0): RES: 41 10 bf 8d b0 00 00 00 00 06 00 (ada1:ata0:0:1:0): Retrying command (ada1:ata0:0:1:0): WRITE_DMA. ACB: ca 00 bf 8d b0 40 00 00 00 00 06 00 (ada1:ata0:0:1:0): CAM status: ATA Status Error (ada1:ata0:0:1:0): ATA status: 41 (DRDY ERR), error: 10 (IDNF ) (ada1:ata0:0:1:0): RES: 41 10 bf 8d b0 00 00 00 00 06 00 (ada1:ata0:0:1:0): Retrying command (ada1:ata0:0:1:0): WRITE_DMA. ACB: ca 00 bf 8d b0 40 00 00 00 00 06 00 (ada1:ata0:0:1:0): CAM status: ATA Status Error (ada1:ata0:0:1:0): ATA status: 41 (DRDY ERR), error: 10 (IDNF ) (ada1:ata0:0:1:0): RES: 41 10 bf 8d b0 00 00 00 00 06 00 (ada1:ata0:0:1:0): Retrying command (ada1:ata0:0:1:0): WRITE_DMA. ACB: ca 00 bf 8d b0 40 00 00 00 00 06 00 (ada1:ata0:0:1:0): CAM status: ATA Status Error (ada1:ata0:0:1:0): ATA status: 41 (DRDY ERR), error: 10 (IDNF ) (ada1:ata0:0:1:0): RES: 41 10 bf 8d b0 00 00 00 00 06 00 (ada1:ata0:0:1:0): Error 5, Retries exhausted (Retries by default in FreeBSD are set to '5' - other OSes vary - then will give up the operation) Real hardware/drives & controllers will pause retrying the command - Server Drives 7 seconds before failing, Desktopdrives 30 seconds before failing. (Well actually they will pause before failing, continually re-trying) If the fault is caused by a Host OS hardware/drive error the pause is correct. If the cause is not a host/hardware drive error (eg slow software load/seek of the drive image) this error presents as vbox doesn't get blocked and it presents the immediate 'drive not ready' to the guest as real hardware would. I am not a C++ programmer so have not looked at the code, it's possible racecondition related, but certainly one would expect a fix would be to suspend hardware emulation replies whilst retrying the operation (loading sectors, scanning cache etc) before presenting 'drive not ready' to the guest. |
|||
| #17573 | fixed | Regression: "Use Host I/O cache" setting seems to be inverted in 5.2 => fixed in SVN/next maintenance | ||
| Description |
I believe that between 5.1 and 5.2 some change led to an inversion of the "Use Host I/O cache" setting. I mark this bug as critical as people that explicitly disable Host I/O caching to ensure data integrity in case of a power outage may now actually have Host I/O caching enabled and are in danger of loosing data in power outage/reset situations. Using VirtualBox for testing system installations I activate the Host I/O caching setting to increase performance when installing a lot of RPMs in the virtual machine, particularly because the VDI file on the host resides on a mechanical HDD. When switching from VirtualBox 5.1 to 5.2, I noticed a considerable slowdown. I measured the slowdown with an ansible playlist that brings a minimal system (installed with Fedora kickstart) to a production level system. The script spends most time on installing RPMs. Some stats of the RPM installation: Number of RPM packages before: 324 Number of RPM packages after: 1490 Total file size of all RPMs before: 734 MiB Total file size of all RPMs after: 3.9 GiB It is Fedora (guest) on Fedora (host). This is with the old VirtualBox 5.1, where everything worked as expected. Installation run on VirtualBox 5.1.32, "Use Host I/O cache" activated: real 7m38.936s user 0m19.646s sys 0m3.937s Going to VirtualBox 5.2 the effect of the setting seems inverted: Installation run on VirtualBox 5.2.6, "Use Host I/O cache" activated: real 52m17.548s user 1m22.884s sys 0m17.828s Installation run on VirtualBox 5.2.6, "Use Host I/O cache" deactivated: real 10m3.771s user 0m22.089s sys 0m5.119s And here I confirm that the test version is still affected: Installation run on VirtualBox 5.2.7, "Use Host I/O cache" activated: real 37m57.730s user 1m13.114s sys 0m15.521s Installation run on VirtualBox 5.2.7, "Use Host I/O cache" deactivated: real 11m1.805s user 0m29.377s sys 0m5.790s |
|||
| #10441 | fixed | Network error about WLAN (ping fails) on special device | ||
| Description |
My ping command to device "AXIS 5400+" (print server) fails if I activate/using my network card "Realtek RTL8191SE" (bridge) in Virtual Box (4.1.12r77245). It's strange because a) on host system (win 7) pings are successful (to print server) b) pings (in VM) to other devices works well If I change to my LAN card "Atheros AR8131" (in VM settings, bridge mode) and connect my print server directly, all works!? For more details, please contact me. |
|||

