Custom Query (16363 matches)
Results (2365 - 2367 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #15573 | obsolete | The Gestalt selector gestaltSystemVersion is returning 10.9.5 instead of 10.11.5 | ||
| Description |
i am trying to install os-x El Capitan (64bit) as a Guest System. This is the same Version as the Hostsystem. After Starting the Guest the Guest-Windows is always black. No Output, no Errormessages. On the Hostcomputer i get this Errormessage in File /var/log/system.log: Jul 5 16:18:54 My-MacBook-Pro VirtualBoxVM[62548]: WARNING: The Gestalt selector gestaltSystemVersion is returning 10.9.5 instead of 10.11.5. This is not a bug in Gestalt -- it is a documented limitation. Use NSProcessInfo's operatingSys temVersion property to get correct system version number.
Jul 5 16:18:54 My-MacBook-Pro VirtualBoxVM[62548]: 0 CarbonCore 0x00007fff8fd776df _Gestalt_SystemVersion_block_invoke + 113 Jul 5 16:18:54 My-MacBook-Pro VirtualBoxVM[62548]: 1 libdispatch.dylib 0x00007fff8a0c040b _dispatch_client_callout + 8 Jul 5 16:18:54 My-MacBook-Pro VirtualBoxVM[62548]: 2 libdispatch.dylib 0x00007fff8a0c0303 dispatch_once_f + 67 Jul 5 16:18:54 My-MacBook-Pro VirtualBoxVM[62548]: 3 CarbonCore 0x00007fff8fd03fbc _Gestalt_SystemVersion + 987 Jul 5 16:18:54 My-MacBook-Pro VirtualBoxVM[62548]: 4 CarbonCore 0x00007fff8fd037d0 Gestalt + 139 Jul 5 16:18:54 My-MacBook-Pro VirtualBoxVM[62548]: 5 QtCoreVBox 0x000000010bf48766 QtCoreVBox + 14182 Jul 5 16:18:54 My-MacBook-Pro VirtualBoxVM[62548]: 6 ??? 0x00007fff633cc10b 0x0 + 140734858313995 I need your help. Thank you! |
|||
| #15571 | fixed | Solaris 8 Generic_108529-05 installer crashes Vbox 5.0.24 if VT-x is enabled | ||
| Description |
Discovered while trying to randomly boot a Solaris 8 x86 ISO I scrounged up on a Windows Server 2008R2 host. If the boot medium is SunOS 5.8 Generic_108529-05 and VT-x is enabled, then the installer will trigger a general protection fault when it tries to load the interactive installation. This fault also causes a NULL pointer deref attempt, which is caught by the Windows Host and that specific VM window is force-closed. The main VBox window then reports the Solaris 8 guest's status as "Aborted". I have two screenshots, one of the VM window containing the Solaris 8 kernel panic details, and the second is the dialog popup showing the NULL pointer deref attempt. I'll also attach the VBox.log file, though it appears the VM dies earlier enough that nothing significant about the error was logged. The problem is not present in a later release of Solaris 8, namely Generic_108529-11. Booting an install CD with that version works fine with VT-x enabled. So I assume the bug was more of a Solaris one, but I figured the crash generating a NULL deref attempt might be ticketable for you guys. |
|||
| #15569 | fixed | VBoxNetFlt: Failed to allocate packet buffer, dropping the packet. | ||
| Description |
In a setup of a Win2k8 VM on a openSUSE 13.2 host with a 4.2.5 kernel, I encounter: Jun 27 23:48:05 server kernel: VBoxNetFlt: Failed to allocate packet buffer, dropping the packet. Jun 27 23:46:55 server kernel: Last message 'VBoxNetFlt: Failed t' repeated 3350 times, suppressed by syslog-ng Jun 27 23:48:35 server kernel: VBoxNetFlt: Failed to allocate packet buffer, dropping the packet. Jun 27 23:47:25 server kernel: Last message 'VBoxNetFlt: Failed t' repeated 1318 times, suppressed by syslog-ng Jun 27 23:49:05 server kernel: VBoxNetFlt: Failed to allocate packet buffer, dropping the packet. Jun 27 23:47:55 server kernel: Last message 'VBoxNetFlt: Failed t' repeated 589 times, suppressed by syslog-ng Jun 27 23:49:35 server kernel: VBoxNetFlt: Failed to allocate packet buffer, dropping the packet. Jun 27 23:48:02 server kernel: Last message 'VBoxNetFlt: Failed t' repeated 5 times, suppressed by syslog-ng Jun 27 23:49:41 server kernel: VBoxNetFlt: Failed to allocate packet buffer, dropping the packet. Jun 27 23:48:32 server kernel: Last message 'VBoxNetFlt: Failed t' repeated 622 times, suppressed by syslog-ng Jun 27 23:50:12 server kernel: VBoxNetFlt: Failed to allocate packet buffer, dropping the packet. Jun 27 23:48:39 server kernel: Last message 'VBoxNetFlt: Failed t' repeated 140 times, suppressed by syslog-ng Jun 27 23:50:18 server kernel: VBoxNetFlt: Failed to allocate packet buffer, dropping the packet. Jun 27 23:49:08 server kernel: Last message 'VBoxNetFlt: Failed t' repeated 377 times, suppressed by syslog-ng Jun 27 23:50:47 server kernel: VBoxNetFlt: Failed to allocate packet buffer, dropping the packet. Jun 27 23:49:38 server kernel: Last message 'VBoxNetFlt: Failed t' repeated 1291 times, suppressed by syslog-ng Jun 27 23:51:18 server kernel: VBoxNetFlt: Failed to allocate packet buffer, dropping the packet. Jun 27 23:50:08 server kernel: Last message 'VBoxNetFlt: Failed t' repeated 29 times, suppressed by syslog-ng Jun 27 23:51:49 server kernel: VBoxNetFlt: Failed to allocate packet buffer, dropping the packet. Jun 27 23:50:10 server kernel: Last message 'VBoxNetFlt: Failed t' repeated 5 times, suppressed by syslog-ng flooding my syslog. Here, more than 6500 packets were dropped in about two minutes. Reading the source revealed, that this code path is only exercised, if VBOXNETFLT_SG_SUPPORT is not defined. Bears the questions, why does skb_copy fail this often and/or is VBoxNetFlt-linux.c able to deal with fragmented packets, which would avoid the copying (apart from making vbox VLAN support dysfunctional). This VM is a vSphere vServer instance, that has to run somewhere (preferably not on a vCenter host that it manages itself) in order to avoid "chicken and egg" problems). For that reason, it shares a NIC with the host in bridged mode. This is the third virtualization solution, that I'm evaluating now. 1) VMware Workstation: host drivers badly integrated in the host kernel (kind of not at all), significant _host_ stalls perceptible, VM control from host (save, restore, shutdown, start) is working fine. 2) kvm/libvirt: good kernel integration, high cpu load in idle state, acceptable impact on host, bad client driver support, really bad VM control from host (ACPI interface nearly dysfunctional, forced me to control VM from host with awful wmi commands), therefore went on to 3) VirtualBox: acceptable kernel integration, nice distribution support, best behaviour on host impact, great suspend/resume performance, good VM control from host, nice UI, minor glitch in host systemd integration (packaging issue), definitely my favorite, but I would like to solve the bridging issue with whatever it takes (dedicated NIC, NAT?) An attempt to discuss this on vbox-dev stalled already. Any enlightment to work around/solve this issue is much appreciated. Thanks, Pete |
|||

