Custom Query (16363 matches)
Results (1873 - 1875 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #2763 | fixed | Vista (32 bit) host with ATI x1250 -> Linux guest -> BSOD / fixed in SVN/2.1.4 | ||
| Description |
Bug since (at least) version 1.6.0: Following combination leads to a BSOD:
Starting the virtual machine leads to a BSOD (host) after selecting something in linux (guest) bootmanager. Windows Eventmanager tells me something about a crash of the display driver (in german it says: Anzeigetreiber atikmdag reagiert nicht mehr und wurde erfolgreich wieder hergestellt., in english it's something like Display driver atikmdag stopped responding and was successfully recovered. Display driver and bios of laptop is up-to-date. A workaround is to enable AMD-V, guest will run normally then. BSOD will only appear with disabled AMD-V (which is the default setting after installation). |
|||
| #18093 | fixed | Error building the graphics driver module in a RHEL 7.6 guest -> fixed after (not in) 5.2.22 | ||
| Description |
Hello, I'm using VBox 5.2.20 r125813 (Qt5.6.1) on Ubuntu 16.04 Host with RHEL 7.5 guest. After updating the RHEL guest to 7.6 I tried to reinstall the guest additions but building the graphics driver module failed. So I tried with the test build 5.2.21 revision 126213 but building the graphics driver module failed, too. To reproduce this issue just try to install the guest additions in a RHEL 7.6 guest system. There is a topic to this issue at: https://forums.virtualbox.org/viewtopic.php?f=3&t=90103 I'm going to attach related log files to this case once it is open. If I could do anything else to track this down, please let me know. I'm not experienced in tracking down and debugging possible bugs in virtualbox, yet. |
|||
| #20009 | duplicate | MSS unexpected increase by VirtualBox | ||
| Description |
I setup Debian Buster64 guest OS using the VirtualBox provider in Vagrant on a Debian Testing. My VirtualBox version is 6.1.14_Debian r140239. According to my tests, the MSS set in the SYN packet of the TCP handshake that leaves the host is the host's MTU, and not the guest's MTU. This happens even if the latter is set lower than the host MTU. I run the following tests: 1) Guest and host default MTU
2) Guest and host modified MTU
3) Guest modified MTU and host default MTU
4) Guest default MTU and host modified MTU
For both tests 1 and 2, MTU and MSS are the same and there is no ambiguity to solve. So the observed behavior is the expected one. The MSS clamping behavior for test 4 is expected because the host cannot provide the MSS that the guest expects. I however think that the behavior of test 3 is incorrect because it increases the packet size received by the guest which may cause problems on the guest itself or in a virtualized network. This problem seems to be related to: #15256. |
|||

