Opened 12 years ago
Closed 12 years ago
#11035 closed defect (fixed)
failed to start kernel module vboxdrv (custom kernel) => Fixed in SVN
Reported by: | skywk | Owned by: | |
---|---|---|---|
Component: | other | Version: | VirtualBox 4.2.0 |
Keywords: | custom kernel module starting failed | Cc: | |
Guest type: | all | Host type: | Linux |
Description (last modified by )
The kernel module vboxdrv failed to start, when modprobe vboxdrv, the dmesg shows these:
[ 48.500393] vboxdrv: Found 2 processor cores. [ 48.500524] BUG: unable to handle kernel NULL pointer dereference at 00000600 [ 48.502986] IP: [<f8de458a>] VBoxHost_RTR0MemObjFree+0x294/0x294 [vboxdrv] [ 48.503333] *pde = 00000000 [ 48.503333] Oops: 0000 [#1] PREEMPT SMP [ 48.503333] Modules linked in: vboxdrv(O+) coretemp tp_smapi(O) thinkpad_ec(O) loop firewire_sbp2 fuse snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep thinkpad_acpi snd_pcm snd_page_alloc nvram snd_seq snd_seq_device snd_timer arc4 psmouse serio_raw i2c_i801 rng_core iwl3945 snd iwl_legacy mac80211 cfg80211 soundcore rfkill battery ac evdev processor microcode i915 i2c_algo_bit drm_kms_helper drm i2c_core sg usbhid hid sd_mod crc_t10dif ide_pci_generic uhci_hcd ahci libahci libata scsi_mod piix ide_core sdhci_pci sdhci mmc_core firewire_ohci firewire_core crc_itu_t ehci_hcd usbcore e1000e usb_common video thermal thermal_sys button [last unloaded: scsi_wait_scan] [ 48.503333] [ 48.503333] Pid: 2324, comm: modprobe Tainted: G O 3.2.1-ck1-bfs416 #1 LENOVO 636386U/636386U [ 48.503333] EIP: 0060:[<f8de458a>] EFLAGS: 00010293 CPU: 0 [ 48.503333] EIP is at VBoxHost_RTR0MemObjGetPagePhysAddr+0x0/0x67 [vboxdrv] [ 48.503333] EAX: f4cac000 EBX: f8dff158 ECX: 00000000 EDX: 00000002 [ 48.503333] ESI: f4cac000 EDI: 00000600 EBP: 00000000 ESP: f5673e98 [ 48.503333] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 48.503333] Process modprobe (pid: 2324, ti=f5672000 task=f4f7b930 task.ti=f5672000) [ 48.503333] Stack: [ 48.503333] f8ddd112 f4e9c850 00000000 f4e9c850 0000e444 00000020 000000d0 00000000 [ 48.503333] 00000010 f5673ee0 00000020 f8de4ef3 00000002 00000002 f4caa200 f4caa224 [ 48.503333] f8d72000 f8de3757 f4edcbc0 f8de378a f8de7362 00000010 f8df951f 00000000 [ 48.503333] Call Trace: [ 48.503333] [<f8ddd112>] ? supdrvInitDevExt+0x103/0x697 [vboxdrv] [ 48.503333] [<f8de4ef3>] ? rtR0MemAllocEx+0x4a/0x9d [vboxdrv] [ 48.503333] [<f8d72000>] ? 0xf8d71fff [ 48.503333] [<f8de3757>] ? rtR0MemAlloc+0x8/0x15 [vboxdrv] [ 48.503333] [<f8de378a>] ? VBoxHost_RTMemAllocTag+0xb/0x18 [vboxdrv] [ 48.503333] [<f8de7362>] ? VBoxHost_RTSpinlockCreate+0x1b/0x4f [vboxdrv] [ 48.503333] [<f8de4ca7>] ? rtR0PowerNotificationInit+0x11/0x15 [vboxdrv] [ 48.503333] [<f8d72000>] ? 0xf8d71fff [ 48.503333] [<f8d72050>] ? VBoxDrvLinuxInit+0x50/0xc7 [vboxdrv] [ 48.503333] [<c1001202>] ? do_one_initcall+0x66/0x10c [ 48.503333] [<c104ffab>] ? sys_init_module+0x136c/0x153f [ 48.503333] [<c12bff9f>] ? sysenter_do_call+0x12/0x28 [ 48.503333] Code: fe ff ff e9 cf fe ff ff 8b 4a 1c 85 c9 0f 84 47 ff ff ff 8d 34 8d fc ff ff ff 89 4c 24 04 e9 5c ff ff ff 83 c4 08 5b 5e 5f 5d c3 <8b> 0f 8b 47 04 8d 91 00 10 00 00 81 fa ff 1f 00 00 76 45 81 39 [ 48.503333] EIP: [<f8de458a>] VBoxHost_RTR0MemObjGetPagePhysAddr+0x0/0x67 [vboxdrv] SS:ESP 0068:f5673e98 [ 48.503333] CR2: 0000000000000600 [ 48.608313] ---[ end trace 4eecccc0ba5c7023 ]---
I run a custom compiled kernel:
Linux debian.zzx.x60 3.5.4-bfs-424 #2 SMP Thu Sep 27 09:20:10 CST 2012 i686 GNU/Linux
and ...3.2.1-ck1-bfs416...
both failed.
but when run the kernel supplied by debian, i.e. ...3.2.0-3-686-pae... it works fine.
The VBOX version is 4.2.0, 4.1.18 also tried, and is the same as the former.
Attachments (5)
Change History (32)
by , 12 years ago
Attachment: | vbox.kernel.log added |
---|
comment:1 by , 12 years ago
comment:2 by , 12 years ago
I can confirm this bug on VBox 4.2.4
I am running a "vanilla" kernel directly from git from Linus stable branch with no extra patches, .config attached for 3.6.10
I have tried with earlier kernels as well: 3.5.4 and 3.4.2 since I have had vbox running succesfully with those before, but the error is the same.
For me it does not help to downgrade to vbox 4.1.18 though.
comment:3 by , 12 years ago
Forgot something. I've also tried with latest stable kernel: 3.7.0 but with this the vbox modules no longer builds.
Snippet from my dmesg when loading vboxdrv:
vboxdrv: Found 2 processor cores. BUG: unable to handle kernel NULL pointer dereference at 00000700 IP: [<f977dac2>] VBoxHost_RTR0MemObjFree+0x294/0x294 [vboxdrv] *pdpt = 0000000026144001 *pde = 0000000000000000 Oops: 0000 [#1] PREEMPT SMP Modules linked in: vboxdrv(O+) Pid: 14395, comm: modprobe Tainted: G O 3.6.10 #14 LENOVO 74585NG/74585NG EIP: 0060:[<f977dac2>] EFLAGS: 00210293 CPU: 1 EIP is at VBoxHost_RTR0MemObjGetPagePhysAddr+0x0/0x67 [vboxdrv] EAX: e64b6000 EBX: e64b6000 ECX: 264b6000 EDX: 00000002 ESI: f97963c8 EDI: 00000700 EBP: 00000000 ESP: e8ad9e84 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 CR0: 8005003b CR2: 00000700 CR3: 30243000 CR4: 000407f0 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process modprobe (pid: 14395, ti=e8ad8000 task=e9f5e6c0 task.ti=e8ad8000) Stack: f9779067 e9dfbb50 00000000 e9dfbb50 c10674fe e9f5e2e0 00000000 00000000 c10ccb9b 000000d0 f977e4fb 00000000 00000008 e8ad9edc 00000018 f977e4fb 00000004 00000000 f9796288 e3300f80 f979f000 f977cc8f d4d28960 f977ccc2 Call Trace: [<f9779067>] ? supdrvInitDevExt+0xdd/0x72d [vboxdrv] [<c10674fe>] ? ttwu_do_wakeup+0xb/0xa3 [<c10ccb9b>] ? __kmalloc+0x88/0xaa [<f977e4fb>] ? rtR0MemAllocEx+0x69/0xbc [vboxdrv] [<f977e4fb>] ? rtR0MemAllocEx+0x69/0xbc [vboxdrv] [<f979f000>] ? 0xf979efff [<f977cc8f>] ? rtR0MemAlloc+0x8/0x15 [vboxdrv] [<f977ccc2>] ? VBoxHost_RTMemAllocTag+0xb/0x18 [vboxdrv] [<f9780a1c>] ? VBoxHost_RTSpinlockCreate+0xc/0x30 [vboxdrv] [<f979f000>] ? 0xf979efff [<f979f050>] ? VBoxDrvLinuxInit+0x50/0xc7 [vboxdrv] [<c100114e>] ? do_one_initcall+0x66/0x104 [<c1083912>] ? sys_init_module+0x11d7/0x13de [<c15f5bcc>] ? sysenter_do_call+0x12/0x22 Code: fe ff ff e9 cf fe ff ff 8b 4a 1c 85 c9 0f 84 47 ff ff ff 8d 34 8d fc ff ff ff 89 4c 24 04 e9 5c ff ff ff 83 c4 08 5b 5e 5f 5d c3 <8b> 0f 8b 47 04 8d 91 00 10 00 00 81 fa ff 1f 00 00 76 45 81 39 EIP: [<f977dac2>] VBoxHost_RTR0MemObjGetPagePhysAddr+0x0/0x67 [vboxdrv] SS:ESP 0068:e8ad9e84 CR2: 0000000000000700 ---[ end trace af95c3bddf7757dd ]---
comment:4 by , 12 years ago
Please attach your compiled vboxdrv.ko module. Which Linux distribution are you using?
comment:5 by , 12 years ago
Description: | modified (diff) |
---|---|
Summary: | failed to start kernel module vboxdrv → failed to start kernel module vboxdrv (custom kernel) |
comment:6 by , 12 years ago
I'm using Exherbo Linux www.exherbo.org
uname -a Linux exherbo-work-laptop 3.6.10 #14 SMP PREEMPT Mon Dec 17 00:32:07 CET 2012 i686 GNU/Linux
Do you have some documentation on debugging this kind of errors with the kernel modules? I've been trying to figure out how to build the kernel module with debug symbols.
attached the module
comment:7 by , 12 years ago
GNU gdb (GDB) 7.5 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv.ko...done. (gdb) list *(supdrvInitDevExt)+0xdd 0x20c4 is in supdrvInitDevExt (/usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/SUPDrv.c:4947). 4942 * Allocate a contiguous set of pages with a default kernel mapping. 4943 */ 4944 rc = RTR0MemObjAllocCont(&pDevExt->GipMemObj, RT_UOFFSETOF(SUPGLOBALINFOPAGE, aCPUs[cCpus]), false /*fExecutable*/); 4945 if (RT_FAILURE(rc)) 4946 { 4947 OSDBGPRINT(("supdrvGipCreate: failed to allocate the GIP page. rc=%d\n", rc)); 4948 return rc; 4949 } 4950 pGip = (PSUPGLOBALINFOPAGE)RTR0MemObjAddress(pDevExt->GipMemObj); AssertPtr(pGip); 4951 HCPhysGip = RTR0MemObjGetPagePhysAddr(pDevExt->GipMemObj, 0); Assert(HCPhysGip != NIL_RTHCPHYS); (gdb)
comment:8 by , 12 years ago
To me it looks like the module you attached does not fit the text in comment 3. Can you recheck?
comment:9 by , 12 years ago
sorry yes, this was rebuild with debug info and perhaps another compiler (been trying to figure out what change made this happen)
Attaching the module build with debug, and the new dmesg as well as information from GDB again.
dmesg:
vboxdrv: Found 2 processor cores. BUG: unable to handle kernel NULL pointer dereference at 00000700 IP: [<f8c0a55e>] VBoxHost_RTR0MemObjFree+0x294/0x294 [vboxdrv] *pdpt = 0000000024679001 *pde = 0000000000000000 Oops: 0000 [#1] PREEMPT SMP Modules linked in: vboxdrv(O+) Pid: 4826, comm: modprobe Tainted: G O 3.6.10 #17 LENOVO 74585NG/74585NG EIP: 0060:[<f8c0a55e>] EFLAGS: 00210293 CPU: 0 EIP is at VBoxHost_RTR0MemObjGetPagePhysAddr+0x0/0x67 [vboxdrv] EAX: e46a2000 EBX: f8c24c60 ECX: 246a2000 EDX: 00000002 ESI: e46a2000 EDI: 00000700 EBP: 00000000 ESP: e5c43e84 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 CR0: 8005003b CR2: 00000700 CR3: 2b2d5000 CR4: 000407f0 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process modprobe (pid: 4826, ti=e5c42000 task=e46bd360 task.ti=e5c42000) Stack: f8c030ea eb02d0d0 00000000 eb02d0d0 001ad0b0 f8c0aedb f8c0aedb 00000000 00000010 e5c43ecc 00000020 f8c0aedb 00000004 00000002 eb0ed6c0 eb0ed6e4 f8c61000 f8c0972b ee5ceba0 f8c0975e f8c0d436 00000010 f8c1f013 00000000 Call Trace: [<f8c030ea>] ? supdrvInitDevExt+0x103/0x697 [vboxdrv] [<f8c0aedb>] ? rtR0MemAllocEx+0x69/0xbc [vboxdrv] [<f8c0aedb>] ? rtR0MemAllocEx+0x69/0xbc [vboxdrv] [<f8c0aedb>] ? rtR0MemAllocEx+0x69/0xbc [vboxdrv] [<f8c61000>] ? 0xf8c60fff [<f8c0972b>] ? rtR0MemAlloc+0x8/0x15 [vboxdrv] [<f8c0975e>] ? VBoxHost_RTMemAllocTag+0xb/0x18 [vboxdrv] [<f8c0d436>] ? VBoxHost_RTSpinlockCreate+0x1b/0x4f [vboxdrv] [<f8c0ac7b>] ? rtR0PowerNotificationInit+0x11/0x15 [vboxdrv] [<f8c61000>] ? 0xf8c60fff [<f8c61050>] ? VBoxDrvLinuxInit+0x50/0xc7 [vboxdrv] [<c100114e>] ? do_one_initcall+0x66/0x104 [<c1085f2d>] ? sys_init_module+0x11c7/0x139d [<c15f574c>] ? sysenter_do_call+0x12/0x22 Code: fe ff ff e9 cf fe ff ff 8b 4a 1c 85 c9 0f 84 47 ff ff ff 8d 34 8d fc ff ff ff 89 4c 24 04 e9 5c ff ff ff 83 c4 08 5b 5e 5f 5d c3 <8b> 0f 8b 47 04 8d 91 00 10 00 00 81 fa ff 1f 00 00 76 45 81 39 EIP: [<f8c0a55e>] VBoxHost_RTR0MemObjGetPagePhysAddr+0x0/0x67 [vboxdrv] SS:ESP 0068:e5c43e84 CR2: 0000000000000700 ---[ end trace dc295d7efa9a1199 ]---
GDB:
GNU gdb (GDB) 7.5 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv.ko...done. (gdb) list *(supdrvInitDevExt)+0x103 0x20ea is in supdrvInitDevExt (/usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/SUPDrv.c:4951). 4946 { 4947 OSDBGPRINT(("supdrvGipCreate: failed to allocate the GIP page. rc=%d\n", rc)); 4948 return rc; 4949 } 4950 pGip = (PSUPGLOBALINFOPAGE)RTR0MemObjAddress(pDevExt->GipMemObj); AssertPtr(pGip); 4951 HCPhysGip = RTR0MemObjGetPagePhysAddr(pDevExt->GipMemObj, 0); Assert(HCPhysGip != NIL_RTHCPHYS); 4952 4953 /* 4954 * Find a reasonable update interval and initialize the structure. 4955 */ (gdb)
comment:10 by , 12 years ago
It took my a while to try this out, but I suspected it was compiler related, and indeed, switching back to GCC 4.5.4 the module loads just fine.
Other compiler versions used was: GCC 4.6.3 and 4.7.2
comment:11 by , 12 years ago
Yes, I know that modules compiled with some gcc-4.7 compilers are buggy. I still don't know if this is really a compiler bug (I'm using gcc-4.7 from Debian and don't see any issue) or if this is some imprecise code.
comment:12 by , 12 years ago
Yes, the calling convention of the function RTR0MemObjGetPagePhysAddr() is wrongly respected by gcc. Please recompile the complete vboxdrv.ko module, then touch the file r0drv/memobj-r0drv.c. Then compile again with passing V=1. To compile the module, go directly to the vboxdrv directory. Copy the command line used to compile memobj-r0drv.c here.
Then use the same command line but replace '-c' by '-E -dD' and the suffix of the file name after '-o' from .o to .i. Attention, when you execute this command line then you first have to go to the Linux source code directory (otherwise the pathes will be incorrect). This is usually /lib/modules/uname -r
/build.
Then attach the compressed memobj-r0drv.i file to this ticket.
comment:14 by , 12 years ago
just to make sure I did it correctly, make V=1 gave me:
gcc -Wp,-MD,/usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/r0drv/.memobj-r0drv.o.d -nostdinc -isystem /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/include -I/usr/src/linux-stable/arch/x86/include -Iarch/x86/include/generated -Iinclude -include /usr/src/linux-stable/include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -m32 -msoft-float -mregparm=3 -freg-struct-return -fno-pic -mpreferred-stack-boundary=2 -march=i686 -mtune=core2 -mtune=generic -Wa,-mtune=generic32 -ffreestanding -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_AVX=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -g -femit-struct-debug-baseonly -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO -include /usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/include/VBox/SUPDrvMangling.h -I/lib/modules/3.6.10/build/include -I/usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/ -I/usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/include -I/usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/r0drv/linux -I/usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/vboxdrv/ -I/usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/vboxdrv/include -I/usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/vboxdrv/r0drv/linux -D__KERNEL__ -DMODULE -DRT_OS_LINUX -DIN_RING0 -DIN_RT_R0 -DIN_SUP_R0 -DVBOX -DRT_WITH_VBOX -DVBOX_WITH_HARDENING -DCONFIG_VBOXDRV_AS_MISC -DRT_ARCH_X86 -DVBOX_WITH_64_BITS_GUESTS -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(memobj_r0drv)" -D"KBUILD_MODNAME=KBUILD_STR(vboxdrv)" -c -o /usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/r0drv/memobj-r0drv.o /usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/r0drv/memobj-r0drv.c
replaced .o with .i, and -c with -e -dD, file attached
by , 12 years ago
Attachment: | memobj-r0drv.i.gz added |
---|
comment:15 by , 12 years ago
Thank you! This looks definitely like a gcc bug to me. Have a look at line 39219 of memobj-r0drv.i: Here starts the implementation of VBoxHost_RTR0MemObjGetPagePhysAddr(). This function was declared at line 8278. Both, the declaration and the implementation contain the attribute regparm(0) which means that when calling this function, all parameters must be passed using the stack, no parameters must be passed in registers. regparm(3) would be the opposite (allow up to 3 parameters to be passed in registers). Passing parameters using registers is a performance optimization.
When looking at your vboxdrv.ko file with 'objdump -ld vboxdrv.ko' and search for SUPDrv.c:4951, it is clearly visible that both parameters are passed on the stack:
20de: 6a 00 push $0x0 20e0: ff 73 4c pushl 0x4c(%ebx) 20e3: 89 c6 mov %eax,%esi 20e5: e8 fc ff ff ff call 20e6
But the function implementation which starts at address 0x955e at the same file shows that the compiler expects the parameter MemObj as passed in the register edi. Line 272 of r0drv/memobj-r0drv.c is implemented like this
VBoxHost_RTR0MemObjGetPagePhysAddr(): 955e: 8b 0f mov (%edi),%ecx 9560: 8b 47 04 mov 0x4(%edi),%eax 9563: 8d 91 00 10 00 00 lea 0x1000(%ecx),%edx 9569: 81 fa ff 1f 00 00 cmp $0x1fff,%edx 956f: 76 45 jbe 95b6 ... 95b6: 83 c8 ff or $0xffffffff,%eax 95b9: 89 c2 mov %eax,%edx 95bb: c3 ret
This is completely bogus and must be a gcc bug. For 32-bit targets, gcc never passes any parameter in register edi:
- esi, edi, ebx and ebp are callee-saved registers
- if the function prototype has the regparm(0) attribute, all parameters are passed on the stack
- if the function prototype has the regparm(3) attribute, up to three parameters can be passed using the register eax, edx and ecx
comment:16 by , 12 years ago
heh, that is a bit beyond my debugging skills, will you take this to GCC upstream or should I ? It would not be nice to be stuck on gcc-4.5 for vbox :)
comment:17 by , 12 years ago
Can you tell me which gcc compiler you used to produce this code (complete output of 'gcc -v' please)? And which Linux distribution are you using?
comment:18 by , 12 years ago
kimrhh@exherbo-work-laptop ~ $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.7.2/lto-wrapper Target: i686-pc-linux-gnu Configured with: /var/tmp/paludis/build/sys-devel-gcc-4.7.2-r2/work/gcc-4.7.2/configure --prefix=/usr --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --enable-fast-install --libdir=/usr/lib --disable-multilib --libdir=/usr/lib --enable-clocale=gnu --enable-languages=c++,fortran,java --enable-libstdcxx-pch=yes --enable-nls --program-suffix=-4.7 --enable-lto --with-pkgversion='Exherbo gcc-4.7.2-r2' --with-system-zlib --disable-graphite --without-cloog --without-ppl --enable-libgomp --disable-libssp Thread model: posix gcc version 4.7.2 (Exherbo gcc-4.7.2-r2)
I'm using Exherbo Linux: www.exherbo.org
comment:19 by , 12 years ago
Ok. But before I file the bug report, are you sure that there is no update for gcc on your distribution?
comment:21 by , 12 years ago
I've created bug 55940 in the gcc bugzilla.
kimrhh, could you also attach the command line (may be as text file) which you used to create the memobj-r0drv.i file? I would like to know the exact command line.
comment:22 by , 12 years ago
it is already in comment #14 sort of, if I understand you correctly, but here you go (with replaced arguments)
gcc -Wp,-MD,/usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/r0drv/.memobj-r0drv.o.d -nostdinc -isystem /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/include -I/usr/src/linux-stable/arch/x86/include -Iarch/x86/include/generated -Iinclude -include /usr/src/linux-stable/include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -m32 -msoft-float -mregparm=3 -freg-struct-return -fno-pic -mpreferred-stack-boundary=2 -march=i686 -mtune=core2 -mtune=generic -Wa,-mtune=generic32 -ffreestanding -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_AVX=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -g -femit-struct-debug-baseonly -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO -include /usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/include/VBox/SUPDrvMangling.h -I/lib/modules/3.6.10/build/include -I/usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/ -I/usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/include -I/usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/r0drv/linux -I/usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/vboxdrv/ -I/usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/vboxdrv/include -I/usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/vboxdrv/r0drv/linux -D__KERNEL__ -DMODULE -DRT_OS_LINUX -DIN_RING0 -DIN_RT_R0 -DIN_SUP_R0 -DVBOX -DRT_WITH_VBOX -DVBOX_WITH_HARDENING -DCONFIG_VBOXDRV_AS_MISC -DRT_ARCH_X86 -DVBOX_WITH_64_BITS_GUESTS -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(memobj_r0drv)" -D"KBUILD_MODNAME=KBUILD_STR(vboxdrv)" -e -dD -o /usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/r0drv/memobj-r0drv.i /usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/r0drv/memobj-r0drv.c
comment:23 by , 12 years ago
Thanks. We now have confirmation that this is indeed a gcc bug, see the other comments in gcc bug 55940.
comment:24 by , 12 years ago
I have committed a workaround. Could you apply r44302 to your VirtualBox kernel modules in /usr/src/vboxhost-x.y.z/vboxdrv, recompile the kernel modules and verify if it works for you now?
comment:26 by , 12 years ago
Summary: | failed to start kernel module vboxdrv (custom kernel) → failed to start kernel module vboxdrv (custom kernel) => Fixed in SVN |
---|
Thanks for the feedback. The workaround will be part of the next maintenance release.
comment:27 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
The workaround is part of the 4.2.8 kernel module sources.
Still relevant with VBox 4.2.4? This looks to me like a special Linux kernel, does it have some extra patches applied?