Custom Query (16363 matches)
Results (862 - 864 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #13579 | obsolete | USB packets sent from device to host are lost | ||
| Description |
This bug appears in VirtualBox versions 4.3.16 and 4.3.18 on several host machines, other VirtualBox versions have not yet been tested. Host and guest OS were always Windows 7 x64. A software is run on the VM that communicates heavily to an attached USB device. Sporadically USB packets sent from the device to the machine are lost. I verified this by recording the USB communication inside the VM and over the physical USB connection. For this I used USBPcap running inside the VM and a Total Phase Beagle USB 5000 sniffer that monitors the physical connection. By comparing both recordings I found out which packets are lost. I have attached relevant excerpts of Total Phase Data Center recording (In TDC format and as a CSV export for those who do not have the software) which shows the physical USB communication and the USBPcap recording showing the communication inside the VM. There are two different cases of packet loss I have observed. One is reproducible and the other occurs sporadically. In case of the reproducible one, the USB device driver requests status information from the device and the reply is not received. Here a simple workaround in the USB device driver was implemented, that simply requested the status information twice if running in a VirtualBox VM. The second packet is then received properly. In the attached recordings you can find the lost packet at index 21527 in the Total Phase recording and at index 481 in the USBPcap recording. In the USBPcap recording it is marked as a malformed packet. After the status information is requested for the second time and the device replies, that reply packet, although being the very same, is passed through correctly (Total Phase index 21724, USBPcap index 543). The other case is more elusive and happens sporadically. Here a bigger packet is being lost. You can find it in the Total Phase recording from index 21162 to 21268. In the USBPcap recording it appears as the malformed packet at index 61. This is not a device or driver issues as it does not occur on a real PC or ina VMWare VM. It appears to be VirtualBox specific. |
|||
| #19061 | invalid | Shared folders directory removal fails | ||
| Description |
Coming from bugs #18345 and #18569 I was told to open an individual ticket. The problem occurs currently with version 6.0.14 and does not with 5.2.32. In my example the user running VirtualBox has full control on the shared folder of the host (Windows 10 Enterprise, 1803). The user within the Linux guest (Ubuntu 18.04.02 LTS) is in the vboxfs group. The shared folder is mounted with the following options: rw,nodev,relatime,iocharset=utf8,uid=0,gid=999,dmode=0770,fmode=0770,tag=VBoxAutomounter On the guest within a shell the user is able to create and and delete files and directories: ~/shared$ mkdir test ~/shared$ rmdir test ~/shared$ touch file ~/shared$ rm file However under some conditions directory removal fails. Within the guest there is OpenFOAM running. One application namely foamListTimes which should remove files and directories fails to remove directories. I think it executes the rmdir function from POSIX.C The output I get from foamListTimes is: bool Foam::rm(const Foam::fileName&) : Removing : "/home/openfoam/OpenFOAM/projects/debug/transient/processor3/4/fluid_water/U.gz"
bool Foam::rm(const Foam::fileName&) : Removing : "/home/openfoam/OpenFOAM/projects/debug/transient/processor3/4/fluid_water"
--> FOAM Warning :
From function bool Foam::rmDir(const Foam::fileName&)
in file POSIX.C at line 1103
failed to remove directory "/home/openfoam/OpenFOAM/projects/debug/transient/processor3/4/fluid_water"
--> FOAM Warning :
From function bool Foam::rmDir(const Foam::fileName&)
in file POSIX.C at line 1073
failed to remove directory "fluid_water" while removing directory "/home/openfoam/OpenFOAM/projects/debug/transient/processor3/4"
So it successfully removes the files within the directory "U.gz" but then fails to remove the directory "fluid_water" itself. |
|||
| #10355 | duplicate | OSX crashes immediately when Video Memory is set above 64MB | ||
| Description |
When running virtual box with the os set to OSX and the video memory set above 64MB, the window with the virtual computer will crash when I start it. The virtual machine has the default settings with video memory set to any value above 64MB. |
|||

