VirtualBox

Custom Query (16363 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (472 - 474 of 16363)

Ticket Resolution Summary Owner Reporter
#6031 worksforme vboxdrv kernel stacktrace on Fedora 12 x86_64 John Southworth
Description

I'm using the latest release of VirtualBox on Fedora 12 x86_64. One of the virtualbox drivers is causing a kernel stacktrace when booting up the virtual machines. This makes virtualbox unusable. Its an intermittent problem. I can say that it was working fine in Fedora 11 before I upgraded to 12. I can also verify that this is not a problem with the i686 version as it doesn't happen on my laptop. I've tried to go back a version to 3.1.0 with the same issue. It is always a problem with the network collision statistics. It is a divide error, I'm assuming its because there are no collisions and its dividing by zero. The card varies if i disable vboxnet0 it will stacktrace on eth1, if i disable eth1 it stacktraces on eth0 etc.

This is a copy of the stacktrace:

divide error: 0000 #1 SMP last sysfs file: /sys/devices/virtual/net/vboxnet0/statistics/collisions CPU 2 Modules linked in: vboxnetadp vboxnetflt vboxdrv fuse nfs fscache nfsd lockd nfs_acl auth_rpcgss exportfs sunrpc ipv6 dm_multipath uinput snd_hda_codec_realtek snd_hda_intel snd_usb_audio snd_usb_lib snd_rawmidi snd_hda_codec snd_seq snd_seq_device nvidia(P) snd_pcm uvcvideo snd_timer snd_hwdep i2c_nforce2 amd64_edac_mod snd videodev v4l1_compat v4l2_compat_ioctl32 i2c_core edac_core snd_page_alloc soundcore firewire_ohci forcedeth k8temp firewire_core crc_itu_t serio_raw ata_generic pata_acpi pata_amd sata_nv floppy usb_storage [last unloaded: vboxdrv] Pid: 7115, comm: VirtualBox Tainted: P 2.6.31.9-174.fc12.x86_64 #1 empty RIP: 0010:[<ffffffffa0c91447>] [<ffffffffa0c91447>] g_abExecMemory+0x41687/0x180000 [vboxdrv] RSP: 0018:ffff8800c68c9ba8 EFLAGS: 00010a47 RAX: 93dd86875b893714 RBX: ffffc900140db000 RCX: 000000008f1809f4 RDX: 000000008f1809db RSI: 000000003b9aca00 RDI: ffffc900140db000 RBP: ffff8800c68c9bb8 R08: 0000000000000002 R09: 00000029c96d9833 R10: 0000000020000000 R11: 000000704d65e9b4 R12: ffffc900140c0000 R13: ffffc900140db000 R14: ffffc900140c0000 R15: 000000000000006e FS: 00007fb403d3b710(0000) GS:ffffc90000400000(0000) knlGS:00000000f77538e0 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000aefe18 CR3: 0000000231861000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process VirtualBox (pid: 7115, threadinfo ffff8800c68c8000, task ffff8801000f5e00) Stack:

ffffc900140db000 ffffc900140db980 ffff8800c68c9bd8 ffffffffa0c649f4

<0> ffffc9001409a000 ffffc900140db780 ffff8800c68c9d28 ffffffffa0c5a682 <0> ffff8800c68c9dd8 00000000000000b1 ffffffff000000ff ffff880000000001 Call Trace:

[<ffffffffa0c649f4>] g_abExecMemory+0x14c34/0x180000 [vboxdrv] [<ffffffffa0c5a682>] g_abExecMemory+0xa8c2/0x180000 [vboxdrv] [<ffffffff810c27e0>] ? generic_file_aio_write_nolock+0x251/0x286 [<ffffffffa0c5718d>] g_abExecMemory+0x73cd/0x180000 [vboxdrv] [<ffffffffa0c932f7>] g_abExecMemory+0x43537/0x180000 [vboxdrv] [<ffffffffa0c6178b>] g_abExecMemory+0x119cb/0x180000 [vboxdrv] [<ffffffffa0c3d6dd>] supdrvIOCtlFast+0x44/0x56 [vboxdrv] [<ffffffffa0c3d160>] VBoxDrvLinuxIOCtl+0x44/0x1a3 [vboxdrv] [<ffffffff81108c78>] vfs_ioctl+0x22/0x87 [<ffffffff811091d4>] do_vfs_ioctl+0x47b/0x4c1 [<ffffffff81109270>] sys_ioctl+0x56/0x79 [<ffffffff81011cf2>] system_call_fastpath+0x16/0x1b

Code: 00 eb bc 90 be 01 00 00 00 4c 89 e7 e8 d3 0e 00 00 48 3d 00 ca 9a 3b 74 e1 41 8b 8c 24 d0 84 00 00 31 d2 be 00 ca 9a 3b 48 f7 e1 <48> f7 f6 eb ca 48 8b 87 90 28 00 00 eb 9d 66 66 2e 0f 1f 84 00 RIP [<ffffffffa0c91447>] g_abExecMemory+0x41687/0x180000 [vboxdrv]

RSP <ffff8800c68c9ba8>

---[ end trace c78074dda487755b ]---

#6287 duplicate vboxdrv kernel module crash after suspend to disk Costin Grigoras
Description

A guest was running at the time of the suspend to disk, when the host was restarted the guest window was simply frozen, application not responding and so on then I found the below trace in dmesg.

Host: Ubuntu 9.10

Kernel: Linux fire 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 02:39:34 UTC 2010 x86_64 GNU/Linux

CPU: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz

Guest: Windows XP, 32 bit

The VM log is attached.

[ 7782.628581] invalid opcode: 0000 [#2] SMP
[ 7782.628586] last sysfs file: /sys/devices/system/cpu/cpu1/online
[ 7782.628588] CPU 0
[ 7782.628589] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat usb_storage ppdev vboxnetadp vboxnetflt vboxdrv autofs4 joydev snd_hda_codec_nvhdmi iptable_filter snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss arc4 snd_seq_midi snd_rawmidi ecb snd_seq_midi_event snd_seq iwlagn snd_timer snd_seq_device ip_tables x_tables iwlcore mac80211 snd uvcvideo videodev v4l1_compat sdhci_pci sdhci bridge stp soundcore bnep psmouse v4l2_compat_ioctl32 btusb ricoh_mmc asus_oled(C) snd_page_alloc serio_raw asus_laptop cfg80211 led_class nvidia(P) lp parport usbhid ohci1394 ieee1394 r8169 mii video output intel_agp
[ 7782.628631] Pid: 13087, comm: VirtualBox Tainted: P      D  C 2.6.31-19-generic #56-Ubuntu G50V
[ 7782.628634] RIP: 0010:[<ffffffffa0d29664>]  [<ffffffffa0d29664>] g_abExecMemory+0x83e4/0x180000 [vboxdrv]
[ 7782.628651] RSP: 0018:ffff8800a69e7c68  EFLAGS: 00010046
[ 7782.628653] RAX: 0000000000000000 RBX: ffffc9001192c000 RCX: 0000000000000001
[ 7782.628655] RDX: 000000000000000d RSI: 0000000000000000 RDI: 00000000a9344000
[ 7782.628657] RBP: ffff8800a69e7cb8 R08: 0000000000000000 R09: ffff880113462810
[ 7782.628658] R10: 0000000000010000 R11: 0000000000000000 R12: ffffc9001192c000
[ 7782.628660] R13: 0000000000000100 R14: 0000000000000000 R15: 0000000000000082
[ 7782.628663] FS:  00007f64c572d910(0000) GS:ffff880028022000(0000) knlGS:0000000000000000
[ 7782.628665] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 7782.628667] CR2: 00007f64d6823000 CR3: 0000000111bc0000 CR4: 00000000000026f0
[ 7782.628669] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 7782.628671] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 7782.628674] Process VirtualBox (pid: 13087, threadinfo ffff8800a69e6000, task ffff8800b9a516b0)
[ 7782.628675] Stack:
[ 7782.628676]  00000000a9344000 ffffffffa0d2cf2d 0000000000000002 ffff8800a69e7e48
[ 7782.628680] <0> 0000000000000046 ffffc9001192c000 0000000000000000 0000000000000000
[ 7782.628683] <0> ffff880088ce8d90 ffff880107518180 ffff8800a69e7cf8 ffffffffa0d28623
[ 7782.628687] Call Trace:
[ 7782.628696]  [<ffffffffa0d2cf2d>] ? g_abExecMemory+0xbcad/0x180000 [vboxdrv]
[ 7782.628704]  [<ffffffffa0d28623>] g_abExecMemory+0x73a3/0x180000 [vboxdrv]
[ 7782.628713]  [<ffffffffa0d335ec>] g_abExecMemory+0x1236c/0x180000 [vboxdrv]
[ 7782.628719]  [<ffffffff810dcbfb>] ? generic_file_aio_write+0x7b/0xf0
[ 7782.628727]  [<ffffffffa0d33a45>] g_abExecMemory+0x127c5/0x180000 [vboxdrv]
[ 7782.628732]  [<ffffffff811ae4e9>] ? ext4_file_write+0x49/0x160
[ 7782.628735]  [<ffffffff810da4a9>] ? find_get_page+0x19/0xa0
[ 7782.628745]  [<ffffffffa0d0f5ad>] supdrvIOCtl+0x12ad/0x2330 [vboxdrv]
[ 7782.628756]  [<ffffffffa0d144ee>] ? rtMemAlloc+0x3e/0xe0 [vboxdrv]
[ 7782.628766]  [<ffffffffa0d0b271>] VBoxDrvLinuxIOCtl+0x101/0x1c0 [vboxdrv]
[ 7782.628769]  [<ffffffff8112e47d>] vfs_ioctl+0x1d/0xa0
[ 7782.628772]  [<ffffffff8112eaa9>] do_vfs_ioctl+0x79/0x370
[ 7782.628776]  [<ffffffff8111f452>] ? vfs_write+0x132/0x1a0
[ 7782.628778]  [<ffffffff8112ee21>] sys_ioctl+0x81/0xa0
[ 7782.628782]  [<ffffffff81012002>] system_call_fastpath+0x16/0x1b
[ 7782.628784] Code: 57 f3 0f c7 34 24 73 07 b8 5e f0 ff ff eb 07 75 05 b8 5d f0 ff ff 48 83 c4 08 c3 cc cc cc cc 0f 01 c4 c3 cc cc cc cc 48 31 c0 57 <66> 0f c7 34 24 73 05 b8 5f f0 ff ff 48 83 c4 08 c3 cc cc cc cc
[ 7782.628812] RIP  [<ffffffffa0d29664>] g_abExecMemory+0x83e4/0x180000 [vboxdrv]
[ 7782.628821]  RSP <ffff8800a69e7c68>
[ 7782.628824] ---[ end trace acf33e109b4bd501 ]---

#3934 fixed vboxdrv init script makes boot slow => Fixed in SVN Ken Arnold
Description

According to bootchart, the vboxdrv init script wastes over 2 seconds on my machine running find in the module tree before trying modprobe. Why not just try modprobe first?

Here's how I modified that section of vboxdrv. But I'm sure you could do a whole lot better:

    if ! running vboxdrv; then
        if ! modprobe vboxdrv > /dev/null 2>&1; then
	    # modprobe failed. Find out why:
            if ! find /lib/modules/`uname -r` -name "vboxdrv\.*" 2>/dev/null|grep -q vboxdrv; then
		failure "No suitable module for running kernel found"
            fi
            failure "modprobe vboxdrv failed. Please use 'dmesg' to find out why"
        fi
        sleep .2
    fi
Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy