Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 117696 - Vmware-workstation 4.5.3.19414 does not compile with >= 2.6.14
Summary: Vmware-workstation 4.5.3.19414 does not compile with >= 2.6.14
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo VMWare Bug Squashers [disabled]
URL:
Whiteboard:
Keywords:
: 117903 122238 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-01-03 20:42 UTC by Paul Kronenwetter
Modified: 2006-03-20 11:24 UTC (History)
16 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch to ebuild to re-include update96 contents. (vmware.update.patch,1.74 KB, patch)
2006-01-03 20:43 UTC, Paul Kronenwetter
Details | Diff
Kernel 2.6.14-gentoo-r5 config file showing the problem (.config,33.36 KB, text/plain)
2006-01-06 01:40 UTC, Jakob Schiotz
Details
New ebuild with vmnet patch. (vmware-workstation-4.5.3.19414-r1.ebuild,8.75 KB, text/plain)
2006-01-13 05:23 UTC, Paul Kronenwetter
Details
Patch for new kernel structure in 2.6.14+ (vmnet_2.6.14.patch,419 bytes, patch)
2006-01-13 05:24 UTC, Paul Kronenwetter
Details | Diff
Patch for new kernel structure in 2.6.14+ (vmnet_2.6.14.patch,1.85 KB, patch)
2006-01-13 08:43 UTC, Paul Kronenwetter
Details | Diff
Patch for new kernel structure in 2.6.14+ (vmnet_2.6.14.patch,2.25 KB, patch)
2006-01-23 19:25 UTC, Paul Kronenwetter
Details | Diff
Updated ebuild used with attachment #77964 (vmware-workstation-4.5.3.19414-r2.ebuild,8.75 KB, text/plain)
2006-01-24 10:07 UTC, Paul Kronenwetter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Kronenwetter 2006-01-03 20:42:57 UTC
For some reason the update96 contents were omitted from the latest vmware ebuild.  The changelog does not indicate that update96 was intentionally removed from the package and it appears to be necessary when using the suspend2-sources kernel.
Comment 1 Paul Kronenwetter 2006-01-03 20:43:43 UTC
Created attachment 76127 [details, diff]
Patch to ebuild to re-include update96 contents.

Included patch that makes things work for me again.
Comment 2 Byeong-taek Lee 2006-01-04 00:15:38 UTC
I have had the same problem on x86 and amd64.
This problem was fixed by attached solution.
Thanks a lot.
Comment 3 Chris Gianelloni (RETIRED) gentoo-dev 2006-01-04 06:02:35 UTC
The update should not be necessary with this build, which was why it was removed.  Adding the patch back restores support for suspend2-sources?
Comment 4 Paul Kronenwetter 2006-01-04 06:19:06 UTC
Yes, the vnmet.tar file in particular is much smaller, probably with an earlier date stamp, than from update96.  I can't speak to whether the update program does useful things for the binaries.
Comment 5 Chris Gianelloni (RETIRED) gentoo-dev 2006-01-04 07:28:14 UTC
OK.  After looking through some more information I've come to the conclusion that you guys are just out of luck until update97 comes out.  The reason you guys are out of luck is because of security bug #116238 which is a remotely executable overflow.  The newer VMware Workstation version fixes this bug, while the vmnet.tar from update96 does not.  Since VMware did not provide a patch, but rather a complete new build, there's little I can do about it.  I suggest contacting VMware for support.

I also fear that this affects gentoo-sources, since they are nearly the same codebase.
Comment 6 calvin 2006-01-04 13:37:35 UTC
If it helps I'm currently on:

2.6.14-gentoo-r5 (Gentoo-sources)

and vmware-workstation-5.5.1.19175

and all went well with vmware-config.pl...
Comment 7 Jakob Schiotz 2006-01-05 12:18:02 UTC
I am on exactly the same kernel, and my build failed, see bug 117903

/Jakob
Comment 8 Chris Gianelloni (RETIRED) gentoo-dev 2006-01-05 13:42:26 UTC
*** Bug 117903 has been marked as a duplicate of this bug. ***
Comment 9 Chris Gianelloni (RETIRED) gentoo-dev 2006-01-05 13:45:36 UTC
I'm reopening this bug since it doesn't compile, but I am not applying this fix.  I don't want to reintroduce the security bug.  Instead I am trying to find an actual patch for the security bug versus update96 (or hopefully get an update97) for everyone.

Strangely enough, I have 0 issues getting it to compile here.
Comment 10 Jakob Schiotz 2006-01-06 01:40:17 UTC
Created attachment 76310 [details]
Kernel 2.6.14-gentoo-r5 config file showing the problem

I am attaching my kernel config.  Maybe that will make it possible for you to reproduce the problem / test a solution.  There might be a kernel config parameter that triggers the problem.

In the meantime, I will await update97 (im)patiently :-)

/Jakob
Comment 11 Andre Hinrichs 2006-01-11 04:31:53 UTC
I'm now really upset because of this bug.
Why is the old version immediately removed?
Why is this new version set stable without test it?

I HIGHLY recommend to either fix this ASAP or put the old version in again
and mark this new version unstable.

I tried with several kernel version without any success.
On my system the emergeing workes fine, but the vmware-config.pl failes with
the following error:

Building the vmnet module.

Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-config9/vmnet-only'
make -C /lib/modules/2.6.15/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. modules
make[1]: Entering directory `/usr/src/linux-2.6.15'
  CC [M]  /tmp/vmware-config9/vmnet-only/driver.o
/tmp/vmware-config9/vmnet-only/driver.c: In function `VNetProcessOwnsPort':
/tmp/vmware-config9/vmnet-only/driver.c:1396: error: structure has no member named `max_fds'
make[2]: *** [/tmp/vmware-config9/vmnet-only/driver.o] Error 1
make[1]: *** [_module_/tmp/vmware-config9/vmnet-only] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.15'
make: *** [vmnet.ko] Error 2
make: Leaving directory `/tmp/vmware-config9/vmnet-only'
Unable to build the vmnet module.

For more information on how to troubleshoot module-related problems, please
visit our Web site at "http://www.vmware.com/download/modules/modules.html" and
"http://www.vmware.com/support/reference/linux/prebuilt_modules_linux.html".

Execution aborted.

Comment 12 Jakob Schiotz 2006-01-11 05:04:08 UTC
I would like to add a comment too: Since this is not a remote exploitable bug, but requires a malicious user with an "evil" virtual machine, I think it is an overreaction to remove the old version completely as long as the new version is not usable with the default kernel (gentoo-sources).  I suggest that the old version is put back, but hard-masked.  Then we have to make an effort to reopen the security hole, but we have the option if the new package does not work.

VMware version 4.5 is anyway a security hole (bug 104480), or it that perhaps also fixed in the new version ...

Comment 13 Maik Musall 2006-01-11 17:30:16 UTC
I'd like to second that. My system is now broken because my setup relies on the vmnet interfaces, and I can't do anything right now without having this fixed. I'm not amused by deleting the old version completely. Would you PLEASE put the old version back into portage?!

Maik
Comment 14 Chris Gianelloni (RETIRED) gentoo-dev 2006-01-11 17:57:42 UTC
I really hate repeating myself, but I apparently did not make it clear enough.  I will *NOT* add the old version back into portage proper.  You are free to pull the old version from viewcvs.gentoo.org and use it in your overlay.  You are free to switch to vanilla-sources, which works fine.  You're also free to update the current ebuild using the patch attached in this bug, but I am not reintroducing a vulnerable package in the tree and no amount of begging or whining is going to change my position on this.  I have already explained myself and really would appreciate it if you guys would actually listen to what I have to say rather than continuing to spam this bug with incessant whimpering about my refusal to backpedal on a security issue.  The VMware team for Gentoo is effectually only myself and I am trying to find the cause of this error, but there's only so much that I can do.  If you want to be actually helpful, you could try finding the changes between update96 and the package's vmnet that resolves the compilation issue, without reintroducing the security bug.  Begging and pleading doesn't help anyone.
Comment 15 Andre Hinrichs 2006-01-11 22:35:12 UTC
If you would have looked into comment #11 you would have seen that I AM using
the vanilla-sources. So, you're not right...

All I to say about your comment is... a lot...

Making a program unusable is also a way to make it secure.
Why are you blaming us personally? Did we?
It sounds a bit like "What do you insignificant users want?"

BTW, do you know "How to irritate people" with John Clease???
Comment 16 Andrzej 2006-01-12 09:09:05 UTC
Just confirming that I hit the same problem on Linux sancy 2.6.14-gentoo-r5 #1 PREEMPT Thu Jan 12 09:03:32 CET 2006 i686 Intel(R) Pentium(R) M processor 1400MHz GenuineIntel GNU/Linux.

In fact I was stupid enough to upgrade the kernel today. I should not have done that.  I have seen this issue immediately after the new vmware release was out: it would not compile against 2.6.14-gentoo-r4.  Fortunately I could get by with just removing /etc/vmware/not_configured and using the modules from the previous release.  That worked, though might have been insecure.

However this breakes if you upgrade your kernel.  I either have to go back to my old kernel or do major hacking on modules.  So if you have not upgraded your kernel since your old working vmware installation, you may still find a workaround in removing /etc/vmware/not_configured.
Comment 17 Ian Coleman 2006-01-12 15:31:21 UTC
Just to be explicit about the workaround:  The patch that is attached to this bug will allow you to compile the modules under 2.6.14-r5 (at least).  Because it's the only way I could find to get up and running again (and not obvious to the end-user):

1) Download this patch (also above):  
         http://bugs.gentoo.org/attachment.cgi?id=76127

2) `cd /usr/portage/app-emulation/vmware-workstation`
3) `patch vmware-workstation-4.5.3.19414.ebuild ~/<the_patch_file>`
4) `ebuild /usr/portage/app-emulation/vmware-workstation digest`
5) `emerge -av vmware-workstation`

Now vmware-config.pl should work (with the security caveats above, etc...)
Comment 18 Paul Kronenwetter 2006-01-12 19:55:53 UTC
I have a question - The sources to vmnet & friends are in a tarball.  Does portage have a way to patch a binary file, or should I extract it, patch the file and re-generate the tarball?

I can do either, if binary patching is supported, but it may be easier to do binary.

PS: I'm planning to figure out the bare minimum patch necessary to allow vmnet to compile.  It shouldn't be *that* hard... It's only C after all ;)
Comment 19 Paul Kronenwetter 2006-01-13 04:52:20 UTC
I have the patch, but I need some help with the kernel #defines.  Since this problem appeared only recently, there is a specific version where it was introduced.  I'll try to find exactly what version that is, but I'm not really familiar with how the kernel identifies itself so that I can #ifdef out the patched section appropriately.

Anyone?
Comment 20 Paul Kronenwetter 2006-01-13 05:23:42 UTC
Created attachment 76981 [details]
New ebuild with vmnet patch.

A first-cut at a new ebuild and patch.  This patch *ASSUMES* that the new structure went in at 2.6.14 vanilla.  If that's incorrect in some way, this patch will break vmnet builds for some people.  But, it's something that can be tweaked if necessary.
I did figure out the kernel versioning so that's set, it's just the precise numbers that'll need to be tweaked.
Comment 21 Paul Kronenwetter 2006-01-13 05:24:37 UTC
Created attachment 76982 [details, diff]
Patch for new kernel structure in 2.6.14+

This is the additional patch for vmnet to work with kernels >= 2.6.14.
Comment 22 Chris Gianelloni (RETIRED) gentoo-dev 2006-01-13 06:22:10 UTC
Paul, you are a giant among men, and don't let anyone tell you otherwise... :P

Can some of the rest of you try this ebuild and verify that this works?  I'll try it out this weekend and see what my results are, if I don't get some confirmations before then.
Comment 23 Jakob Schiotz 2006-01-13 07:04:11 UTC
Thanks for the new ebuild!  Unfortunately, it does not quite solve the problem.  The module builds, but it cannot load into the kernel.


   [ ... ]
Building the vmnet module.

Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-config4/vmnet-only'
make -C /lib/modules/2.6.14-gentoo-r5/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. modules
make[1]: Entering directory `/usr/src/linux-2.6.14-gentoo-r5'
  CC [M]  /tmp/vmware-config4/vmnet-only/driver.o
  CC [M]  /tmp/vmware-config4/vmnet-only/hub.o
  CC [M]  /tmp/vmware-config4/vmnet-only/userif.o
In file included from /tmp/vmware-config4/vmnet-only/userif.c:45:
/tmp/vmware-config4/vmnet-only/pgtbl.h: In function `PgtblVa2PTELocked':
/tmp/vmware-config4/vmnet-only/pgtbl.h:81: warning: passing arg 1 of `pmd_offset' from incompatible pointer type
/tmp/vmware-config4/vmnet-only/userif.c: In function `VNetUserIfMapUint32Ptr':
/tmp/vmware-config4/vmnet-only/userif.c:156: warning: implicit declaration of function `verify_area'
/tmp/vmware-config4/vmnet-only/userif.c: In function `VNetCopyDatagramToUser':
/tmp/vmware-config4/vmnet-only/userif.c:563: warning: implicit declaration of function `skb_copy_datagram'
  CC [M]  /tmp/vmware-config4/vmnet-only/netif.o
  CC [M]  /tmp/vmware-config4/vmnet-only/bridge.o
/tmp/vmware-config4/vmnet-only/bridge.c: In function `VNetBridgeUp':
/tmp/vmware-config4/vmnet-only/bridge.c:586: warning: passing arg 3 of `sk_alloc' makes pointer from integer without a cast
/tmp/vmware-config4/vmnet-only/bridge.c:586: warning: passing arg 4 of `sk_alloc' makes integer from pointer without a cast
/tmp/vmware-config4/vmnet-only/bridge.c:598: warning: assignment from incompatible pointer type
  CC [M]  /tmp/vmware-config4/vmnet-only/procfs.o
  LD [M]  /tmp/vmware-config4/vmnet-only/vmnet.o
  Building modules, stage 2.
  MODPOST
*** Warning: "verify_area" [/tmp/vmware-config4/vmnet-only/vmnet.ko] undefined!
*** Warning: "skb_copy_datagram" [/tmp/vmware-config4/vmnet-only/vmnet.ko] undefined!
  CC      /tmp/vmware-config4/vmnet-only/vmnet.mod.o
  LD [M]  /tmp/vmware-config4/vmnet-only/vmnet.ko
make[1]: Leaving directory `/usr/src/linux-2.6.14-gentoo-r5'
cp -f vmnet.ko ./../vmnet.o
make: Leaving directory `/tmp/vmware-config4/vmnet-only'
Unable to make a vmnet module that can be loaded in the running kernel:
insmod: error inserting '/tmp/vmware-config4/vmnet.o': -1 Unknown symbol in module
There is probably a slight difference in the kernel configuration between the
set of C header files you specified and your running kernel.  You may want to
rebuild a kernel based on that directory, or specify another directory.

For more information on how to troubleshoot module-related problems, please
visit our Web site at "http://www.vmware.com/download/modules/modules.html" and
"http://www.vmware.com/support/reference/linux/prebuilt_modules_linux.html".

Execution aborted.

Comment 24 Paul Kronenwetter 2006-01-13 07:06:29 UTC
Looks like I'll need to a little more work.  I couldn't test it as I'm using the VMware installation for "real" work right now.  I'll see what else needs to be done, unless someone else gets to it first.
Comment 25 Chris Gianelloni (RETIRED) gentoo-dev 2006-01-13 07:13:09 UTC
Jakob, are you sure your /usr/src/linux link is pointing to your current kernel's sources and it has the same .config as your running kernel?
Comment 26 Jakob Schiotz 2006-01-13 07:52:55 UTC
(In reply to comment #25)
> Jakob, are you sure your /usr/src/linux link is pointing to your current
> kernel's sources and it has the same .config as your running kernel?
> 

Yes, I am sure.  But just to double-check, I went to that directory, did a "make" and a "make install modules_install" and rebooted.  No change.

/Jakob
Comment 27 Paul Kronenwetter 2006-01-13 08:43:26 UTC
Created attachment 77001 [details, diff]
Patch for new kernel structure in 2.6.14+

Updated vmnet_2.6.14.patch. - Still untested...
It now compiles without errors so it *should* work.  Please test.
Comment 28 Paul Kronenwetter 2006-01-13 15:45:24 UTC
This patch doesn't work.  It causes kernel panics and outputs these errors:
Jan 13 18:05:10 ex1503 vmnet-dhcpd: receive_packet failed on vmnet1: Bad address

Also for vmnet8 and vmnet0...  Bad patch!
I'm not sure I have the expertise to fix it unfortunately.
Comment 29 Christian Zuckschwerdt 2006-01-22 15:46:59 UTC
Hi Paul,

skb_copy_datagram can't simply be renamed to skb_copy_datagram_iovec. You have to include a short wrapper, e.g. from http://lkml.org/lkml/2005/1/22/60
(No need to patch the kernel. Just cut and paste the wrapper to some vmware source file.)
Comment 30 Paul Kronenwetter 2006-01-23 16:17:45 UTC
Ooh.  Ok, I'll give that a stab and post another patch.  I'll try to test it a bit first too ;)
Comment 31 Paul Kronenwetter 2006-01-23 17:03:44 UTC
Well, I have a patch that doesn't cause the box to immediately crash.  However I'm sitll seeing these errors:
Jan 23 20:00:58 ex1503 vmnet-dhcpd: receive_packet failed on vmnet1: Bad address
Jan 23 20:02:10 ex1503 vmnet-dhcpd: receive_packet failed on vmnet8: Bad address

And no network connectivity from the virtual machine...  Any additional thoughts or pointers?
Comment 32 Paul Kronenwetter 2006-01-23 19:25:21 UTC
Created attachment 77964 [details, diff]
Patch for new kernel structure in 2.6.14+

This is the slightly updated patch with the skb_copy_datagram wrapper applied.  I hadn't applied the patch properly in comment #31 so I have corrected that problem.  Since this one doesn't crash my box, I wanted to update it here.  And...

This patch appears to work...  I'll run it tomorrow and see what happens!
Comment 33 Paul Kronenwetter 2006-01-24 09:50:39 UTC
Well, I've been running this for 12 hours and have transferred more than 192MB up and 77MB down through the NAT interface on my VMWare workstation and nothing but happy messages from vmnet in the messages file.

I'd request that others try the patch and provide feedback as well.  Note, that the LKML reference stated that the skb_datagram wrapper was removed at 2.6.11-r2, so the #if version checks start working for that code at 2.6.11.  If this describes your kernel and it doesn't work, please post something and we'll adjust it for the Gentoo / Suspend2 variants.
Comment 34 Chris Gianelloni (RETIRED) gentoo-dev 2006-01-24 10:04:11 UTC
Please don't resolve this when there's no fix in the tree.

I'm guessing you're pretty much using your earlier ebuild for this, correct?
Comment 35 Paul Kronenwetter 2006-01-24 10:07:20 UTC
Created attachment 78007 [details]
Updated ebuild used with attachment #77964 [details, diff]

Ooh, sorry about that.  I'm uploading the exact ebuild I used to apply the patch in attachment #77964 [details, diff].
Comment 36 Paul Kronenwetter 2006-01-25 05:39:16 UTC
Unfortunately when I booted my machine this morning vmnet oops'd.  Back to the drawing board I guess...

There's a NULL pointer dereference somewhere...  I'm guessing it's in the non-skb_datagram code because I put that together...  Hmm...

Jan 25 08:14:34 ex1503 /dev/vmmon: Module vmmon: registered with major=10 minor=165
Jan 25 08:14:34 ex1503 /dev/vmmon: Module vmmon: initialized
Jan 25 08:14:34 ex1503 /dev/vmmon: Module vmmon: unloaded
Jan 25 08:14:46 ex1503 /dev/vmmon: Module vmmon: registered with major=10 minor=165
Jan 25 08:14:46 ex1503 /dev/vmmon: Module vmmon: initialized
Jan 25 08:14:46 ex1503 parport0: PC-style at 0x378 (0x778), irq 7, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
Jan 25 08:14:47 ex1503 /dev/vmnet: open called by PID 15765 (vmnet-bridge)
Jan 25 08:14:47 ex1503 /dev/vmnet: hub 0 does not exist, allocating memory.
Jan 25 08:14:47 ex1503 /dev/vmnet: port on hub 0 successfully opened
Jan 25 08:14:47 ex1503 bridge-eth0: peer interface eth0 not found, will wait for it to come up
Jan 25 08:14:47 ex1503 bridge-eth0: attached
Jan 25 08:14:47 ex1503 /dev/vmnet: open called by PID 15783 (vmnet-bridge)
Jan 25 08:14:47 ex1503 /dev/vmnet: hub 2 does not exist, allocating memory.
Jan 25 08:14:47 ex1503 /dev/vmnet: port on hub 2 successfully opened
Jan 25 08:14:47 ex1503 bridge-eth1: enabling the bridge
Jan 25 08:14:47 ex1503 Unable to handle kernel NULL pointer dereference at virtual address 00000069
Jan 25 08:14:47 ex1503 printing eip:
Jan 25 08:14:47 ex1503 c02311bd
Jan 25 08:14:47 ex1503 *pde = 00000000
Jan 25 08:14:47 ex1503 Oops: 0000 [#1]
Jan 25 08:14:47 ex1503 PREEMPT 
Jan 25 08:14:47 ex1503 Modules linked in: vmnet parport_pc vmmon ndiswrapper ipt_MASQUERADE iptable_nat ip_nat ipt_REJECT ipt_LOG ipt_state iptable_filter ip_tables snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_intel8x0m ohci_hcd ehci_hcd 8250_pnp floppy eth1394 ohci1394 ieee1394 nvidia snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc i8xx_tco usbhid uhci_hcd intel_agp agpgart tun irtty_sir sir_dev irda crc_ccitt ppdev parport 8250_pci 8250 serial_core twofish dm_crypt dm_mod loop vfat fat ide_cd cdrom ip_conntrack_ftp ip_conntrack 3c59x mii ac battery thermal acpi_cpufreq processor yenta_socket rsrc_nonstatic pcmcia pcmcia_core firmware_class crc32 cpufreq_ondemand cpufreq_powersave capability commoncap joydev
Jan 25 08:14:47 ex1503 CPU:    0
Jan 25 08:14:47 ex1503 EIP:    0060:[<c02311bd>]    Tainted: P      VLI
Jan 25 08:14:47 ex1503 EFLAGS: 00010282   (2.6.15-suspend2-r2) 
Jan 25 08:14:47 ex1503 EIP is at sk_alloc+0xf/0x110
Jan 25 08:14:47 ex1503 eax: 00000020   ebx: f2660a0c   ecx: 0000000b   edx: 00000001
Jan 25 08:14:47 ex1503 esi: f2660a00   edi: 00000000   ebp: f0285e78   esp: f0285e4c
Jan 25 08:14:47 ex1503 ds: 007b   es: 007b   ss: 0068
Jan 25 08:14:47 ex1503 Process vmnet-bridge (pid: 15783, threadinfo=f0284000 task=f0a7a030)
Jan 25 08:14:47 ex1503 Stack: f0a7a15c ffffffff f0a7a030 00000003 f0285e6c c028225b 00000001 00000286 
Jan 25 08:14:47 ex1503 f2660a0c f2660a00 00000000 f0285e9c f8d3cb7b 00000010 00000020 00000001 
Jan 25 08:14:47 ex1503 00000000 f2660a0c f78d1805 f2660a11 f0285ebc f8d3cd51 f2660a00 f8d3d962 
Jan 25 08:14:47 ex1503 Call Trace:
Jan 25 08:14:47 ex1503 [<c010320d>] show_stack+0x74/0x7c
Jan 25 08:14:47 ex1503 [<c010331b>] show_registers+0xee/0x157
Jan 25 08:14:47 ex1503 [<c01034cc>] die+0xd1/0x157
Jan 25 08:14:47 ex1503 [<c01107ed>] do_page_fault+0x358/0x486
Jan 25 08:14:47 ex1503 [<c0102ef7>] error_code+0x4f/0x54
Jan 25 08:14:47 ex1503 [<f8d3cb7b>] VNetBridgeUp+0xbe/0x199 [vmnet]
Jan 25 08:14:47 ex1503 [<f8d3cd51>] VNetBridgeNotify+0xab/0x116 [vmnet]
Jan 25 08:14:47 ex1503 [<c023720f>] register_netdevice_notifier+0x40/0x57
Jan 25 08:14:47 ex1503 [<f8d3c5a7>] VNetBridge_Create+0x77/0x212 [vmnet]
Jan 25 08:14:47 ex1503 [<f8d3a46c>] VNetFileOpIoctl+0x136/0x365 [vmnet]
Jan 25 08:14:47 ex1503 [<c01636f0>] do_ioctl+0x54/0x68
Jan 25 08:14:47 ex1503 [<c016398e>] vfs_ioctl+0x18a/0x19b
Jan 25 08:14:47 ex1503 [<c01639e5>] sys_ioctl+0x46/0x65
Jan 25 08:14:47 ex1503 [<c0102c73>] sysenter_past_esp+0x54/0x75
Jan 25 08:14:47 ex1503 Code: 8b 4d 18 e8 ca a7 f8 ff 83 f8 01 19 d2 f7 d2 83 e2 f2 8d 65 f4 89 d0 5b 5e 5f 5d c3 55 89 e5 57 56 53 83 ec 20 8b 55 10 8b 45 0c <8b> 52 68 85 d2 89 55 e0 74 0d 50 52 e8 65 f9 f0 ff 5f 89 c6 58 
Jan 25 08:14:47 ex1503 <6>note: vmnet-bridge[15783] exited with preempt_count 1
Jan 25 08:14:47 ex1503 /dev/vmnet: open called by PID 15790 (vmnet-natd)
Jan 25 08:14:47 ex1503 /dev/vmnet: hub 8 does not exist, allocating memory.
Jan 25 08:14:47 ex1503 /dev/vmnet: port on hub 8 successfully opened
Jan 25 08:14:53 ex1503 dhcpcd[14051]: timed out waiting for a valid DHCP server response
Jan 25 08:14:57 ex1503 /dev/vmnet: open called by PID 15798 (vmnet-netifup)
Jan 25 08:14:57 ex1503 /dev/vmnet: hub 1 does not exist, allocating memory.
Jan 25 08:14:57 ex1503 /dev/vmnet: port on hub 1 successfully opened
Jan 25 08:14:57 ex1503 /dev/vmnet: open called by PID 15799 (vmnet-netifup)
Jan 25 08:14:57 ex1503 /dev/vmnet: port on hub 8 successfully opened
Jan 25 08:15:58 ex1503 /dev/vmnet: open called by PID 15820 (vmware-vmx)
Jan 25 08:15:58 ex1503 /dev/vmnet: port on hub 8 successfully opened
Jan 25 08:15:59 ex1503 /dev/vmmon: fast clock rate 0 -> 19
Jan 25 08:16:12 ex1503 /dev/vmmon: fast clock rate 19 -> 0
Jan 25 08:16:12 ex1503 /dev/vmmon: fast clock rate 0 -> 100
Jan 25 08:16:13 ex1503 /dev/vmmon: fast clock rate 100 -> 101
Jan 25 08:20:16 ex1503 /dev/vmmon: fast clock rate 101 -> 1
Jan 25 08:20:16 ex1503 /dev/vmmon: fast clock rate 1 -> 251
Jan 25 08:21:40 ex1503 /dev/vmmon: fast clock rate 251 -> 1
Jan 25 08:21:40 ex1503 /dev/vmmon: fast clock rate 1 -> 101
Jan 25 08:21:44 ex1503 /dev/vmmon: fast clock rate 101 -> 251
Jan 25 08:22:03 ex1503 /dev/vmmon: fast clock rate 251 -> 101
Jan 25 08:23:06 ex1503 /dev/vmmon: fast clock rate 101 -> 0
Jan 25 08:23:06 ex1503 vmmon: Had to deallocate locked 98165 pages from vm driver f2661000
Jan 25 08:23:06 ex1503 vmmon: Had to deallocate AWE 4116 pages from vm driver f2661000
Jan 25 08:29:08 ex1503 /dev/vmmon: Module vmmon: unloaded
Jan 25 08:29:08 ex1503 bridge-eth0: detached
Jan 25 08:30:24 ex1503 shutdown[17075]: shutting down for system reboot
Comment 37 Henrik Brix Andersen 2006-01-25 07:07:05 UTC
This is not related to suspend2-sources.
Comment 38 Paul Kronenwetter 2006-01-25 07:23:42 UTC
Henrik - Could you elaborate on that assertion?  I'm running suspend2-sources and experienced (reported) the problem...  Is there a version of suspend2-sources where this no longer occurs?
Comment 39 Henrik Brix Andersen 2006-01-25 07:29:54 UTC
(In reply to comment #38)
> Henrik - Could you elaborate on that assertion?  I'm running suspend2-sources
> and experienced (reported) the problem...  Is there a version of
> suspend2-sources where this no longer occurs?

Not that I am aware of, but according to at least comment #7, comment #15 and comment #16 this issue appears with gentoo-sources and vanilla-sources too.
Comment 40 Paul Kronenwetter 2006-01-25 07:34:44 UTC
Then let's call it linux sources >=2.6.xx where xx is appropriate...
Comment 41 Jakub Moc (RETIRED) gentoo-dev 2006-02-09 04:32:16 UTC
*** Bug 122238 has been marked as a duplicate of this bug. ***
Comment 42 A. Person 2006-03-14 09:42:42 UTC
Is anything happening with this?  I'm still using the old ebuild because the modules with the new one won't compile with hardened-sources.
Comment 43 Paul Kronenwetter 2006-03-14 09:52:29 UTC
The last one I wasa able to figure out still crashed or panic'd the box.  I don't have any more ideas on how to go about fixing this.
Comment 44 Chris Gianelloni (RETIRED) gentoo-dev 2006-03-20 11:24:41 UTC
This should be fixed in the latest revisions of the vmware-workstation and vmware-player ebuilds.  I apologize that this took so long to get fixed.