The emulators/vmware2 port does not work on recent -STABLE, failing with "VMware Workstation PANIC: BUG F(571):1607 bugNr=2302". The usual fix for this is to rebuild the kernel modules, but (a) they do not build without patching and (b) the new kernel modules fail with the same error. No kernel messages were logged. Update: retrying it with syslogd recording debug messages, the vmware bugcheck no longer occurs, but vmware reports an inability to reserve memory and the following is syslogged: Aug 24 07:10:10 pyanfar /kernel: /dev/vmmon: HostIF_LockPage vpn=0x0287bc mpn=000000 already tracked Aug 24 07:10:22 pyanfar last message repeated 11 times Aug 24 07:10:30 pyanfar /kernel: /dev/vmmon: Vmx86_DestroyVM: unlocked pages: 0, unlocked dirty pages: 0 Aug 24 07:10:30 pyanfar /kernel: /dev/vmmon: PhysTrack_Cleanup: pfns still locked Fix: I used the following patch to get the modules to build; not being a kernel hacker, I don't know if it's correct (and would guess it's not, but have no idea what the correct fix is). How-To-Repeat: Attempt to boot a VMware virtual machine.
Please have a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=55928 What I can see from it is that it shouldn't fix it, but since I'm still running 4.7 on my machine I don't see the full problem yet. Edwin -- Edwin Groothuis edwin@freebsd.org http://www.mavetju.org
Hi, On Sun, Aug 24, 2003 at 07:14:29AM -0400, Brandon S. Allbery KF8NH wrote: > >Synopsis: vmware2 broken on -STABLE, presumably by PAE import >> (..) Your patch makes VmWare2 build, but it doesn't make it work: - VmWare fails to allocate memory (see http://anders.fix.no/test/vmware/1.png and http://anders.fix.no/test/vmware/2.png). - There seems to be something wrong with vmmon, some error messages are reported to my console log: Console log for noname.aftenposten.no /dev/vmmon: HostIF_LockPage vpn=0x048a65 mpn=000000 already tracked Sep 8 10:07:54 noname /kernel: /dev/vmmon: HostIF_LockPage vpn=0x048a65 mpn=000000 already tracked /dev/vmmon: HostIF_LockPage vpn=0x048a65 mpn=000000 already tracked /dev/vmmon: HostIF_LockPage vpn=0x048a65 mpn=000000 already tracked /dev/vmmon: HostIF_LockPage vpn=0x048a65 mpn=000000 already tracked /dev/vmmon: HostIF_LockPage vpn=0x048a65 mpn=000000 already tracked Sep 8 10:07:58 noname last message repeated 4 times Oh, and FreeBSD gets unstable with these patches of yours. I've seen several hard hangs. I cleaned up the patch to be relative to the current port (patch attached). I'm applying your patch (pmap.patch-stable) if OSVERSION is less than 500000, and higher or equal to 480101 (which was used at the time of the PAE MFC). For those on the Cc: list, I added you because you committed PAE/pmap things, are on the -stable list or maintain the vmware2 port. :) Any tips or improvements to the patch to make VmWare2 work in FreeBSD again is very welcome. If we want VmWare supported in -stable at all (4.9 being right around the corner and all), this must be dealt with ASAP. Feel free to use me for testing your suggestions. Cheers, -- Anders.
On Mon, 2003-09-08 at 05:21, Anders Nordby wrote: > Your patch makes VmWare2 build, but it doesn't make it work: I mentioned that in the bug report (and also said "almost certainly wrong"...). > Oh, and FreeBSD gets unstable with these patches of yours. I've seen > several hard hangs. I wouldn't have noticed as my FreeBSD was unstable anyway; this was before any patches for the PAE code appeared, so my machine was crashing every few hours anyway. :/ In any case, I had already guessed from the type change away from pointers that just using the provided values would do the wrong thing. I was hoping that getting the module to compile would at least produce some useful diagnostics before the incorrect page manipulations trashed too much of kernel memory.... (I am no kernel hacker, and in particular know approximately nothing about FreeBSD's memory management or how the PAE import changed it.) -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [WAY too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon univ. KF8NH URGENT! E-xpedient nuked APK subdomains; kf8nh.apk.net is DEAD. Sorry.
State Changed From-To: open->closed I committed the fix that uses already existing patches for 5.x.