Wine and even more specifically (or easy to replicate) winecfg crashes. [2:9:309]dgilbert@canoe:~/.wine> winecfg Segmentation fault: 11 (core dumped) [2:11:311]dgilbert@canoe:~/.wine> gdb wine-pthread wine-pthread.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `wine-pthread'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libwine.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libwine.so.1 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/wine/ntdll.dll.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/wine/ntdll.dll.so Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x7e1e7161 in thread_init () from /usr/local/lib/wine/ntdll.dll.so [New Thread 0x7c003100 (LWP 100233)] (gdb) bt #0 0x7e1e7161 in thread_init () from /usr/local/lib/wine/ntdll.dll.so #1 0x7e1c38a8 in __wine_process_init () from /usr/local/lib/wine/ntdll.dll.so #2 0x7df3bd84 in wine_init () from /usr/local/lib/libwine.so.1 #3 0x7df571eb in wine_casemap_upper () from /usr/local/lib/libwine.so.1 #4 0x7fbfe108 in ?? () #5 0x00000400 in ?? () #6 0x00000000 in ?? () #7 0x00000001 in ?? () #8 0x7df03419 in ?? () from /libexec/ld-elf.so.1 #9 0x7c008060 in ?? () #10 0x00000000 in ?? () #11 0x7df30200 in ?? () #12 0x7fbfe108 in ?? () #13 0x7fbfe6d0 in ?? () #14 0x7bf0134c in pthread_functions () #15 0x7fbfe518 in ?? () #16 0x00000003 in ?? () #17 0x7c009070 in ?? () #18 0x7c00908d in ?? () #19 0x0000000a in ?? () #20 0x00000000 in ?? () #21 0x7fbfe108 in ?? () #22 0x7fbfe6d0 in ?? () #23 0x7bf0134c in pthread_functions () #24 0x7fbfe518 in ?? () #25 0x7bf0125d in main () Fix: Not known. How-To-Repeat: run winecfg
Responsible Changed From-To: freebsd-ports-bugs->gerald Over to maintainer (via the GNATS Auto Assign Tool)
Hi David, Could you give more information about what kind of machine you have and how you've setup FreeBSD and Wine? System: FreeBSD canoe.dclg.ca 7.0-STABLE FreeBSD 7.0-STABLE #1: Thu May 8 11:55:48 EDT 2008 dgilbert@canoe.dclg.ca:/canoe/32/usr/obj/canoe/32/usr/src/sys/CANOE32 i386 =46rom this, am I right in assuming this is a i386 jail? Perhaps running on an amd64 kernel? Because in that case I'd expect Wine to crash like you're seeing because it uses some features of i386 that the amd64 kernel doesn't support (yet).
>>>>> "Tijl" == Tijl Coosemans <tijl@ulyssis.org> writes: Tijl> Hi David, Could you give more information about what kind of Tijl> machine you have and how you've setup FreeBSD and Wine? Tijl> System: FreeBSD canoe.dclg.ca 7.0-STABLE FreeBSD 7.0-STABLE #1: Tijl> Thu May 8 11:55:48 EDT 2008 Tijl> dgilbert@canoe.dclg.ca:/canoe/32/usr/obj/canoe/32/usr/src/sys/CANOE32 Tijl> i386 Tijl> From this, am I right in assuming this is a i386 jail? Perhaps Tijl> running on an amd64 kernel? Because in that case I'd expect Wine Tijl> to crash like you're seeing because it uses some features of Tijl> i386 that the amd64 kernel doesn't support (yet). No. I didn't say more because it's a simple i386 machine (my laptop). It is a core-2-duo processor, but running in 32 bit mode with a 32 bit kernel. The crazy path is due to a zfs dual-boot setup that allows me to boot in amd64 mode. ZFS is used for /usr and /var. UFS is used for / and /tmp (mfs). So... nothing hugely unusual. I thought it might be my fancy graphics card and whatnot, but I expect winecfg doesn't use that. To be precise: - It's a Dell XPS-1730 laptop w/ dual nvidia 8800M video cards. - Intel core-2-duo X7900 - in 32 bit mode - with one of the cpu's pegged by interrupts coming from the nvidia driver (bug) - 4G RAM (3.2G showing, no PAE) - 2x 320G sata drives. - multi-boot XP, Vista, FreeBSD-i386, FreeBSD-amd64 - / UFS - /usr, /var ZFS in mirror mode - ntfs not mounted (in this test) - 1920x1200 screen running xord locally with latest nvidia binary driver - FreeBSD-7.0-STABLE as of shortly before the kernel compile - i386 kernel and userland in sync (buildworld/installworld) - wine freshly recompiled after the reboot with that kernel - wine is running on ZFS, but to test, I copied all the libraries to /tmp in case zfs was the problem. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================
On Sunday 18 May 2008 16:28:11 David Gilbert wrote: > No. I didn't say more because it's a simple i386 machine (my > laptop). It is a core-2-duo processor, but running in 32 bit mode > with a 32 bit kernel. The crazy path is due to a zfs dual-boot setup > that allows me to boot in amd64 mode. ZFS is used for /usr and /var. > UFS is used for / and /tmp (mfs). Ok, can you rebuild/install wine with WITH_DEBUG defined and examine a new core file with gdb?
>>>>> "Tijl" == Tijl Coosemans <tijl@ulyssis.org> writes: Tijl> Ok, can you rebuild/install wine with WITH_DEBUG defined and Tijl> examine a new core file with gdb? Here's the basic stack trace. Is there anything else you'd like? The core file compressed nicely, so I'm sending it to you along with my executable. [2:6:306]dgilbert@canoe:~/.wine> winecfg Segmentation fault: 11 (core dumped) [2:7:307]dgilbert@canoe:~/.wine> gdb wine-pthread wine-pthread.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Core was generated by `wine-pthread'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libwine.so.1...done. Loaded symbols for /usr/local/lib/libwine.so.1 Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/wine/ntdll.dll.so...done. Loaded symbols for /usr/local/lib/wine/ntdll.dll.so Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x7e1f4bb9 in thread_init () at thread.c:338 338 user_shared_data->SystemTime.LowPart = now.u.LowPart; [New Thread 0x7c003100 (LWP 100189)] (gdb) bt #0 0x7e1f4bb9 in thread_init () at thread.c:338 #1 0x7e1cc9b7 in __wine_process_init () at loader.c:2602 #2 0x7df3d25e in wine_init (argc=2, argv=0x7fbfe554, error=0x7fbfe110 "", error_size=1024) at loader.c:656 #3 0x7bf01518 in main (argc=2, argv=0x7fbfe554) at main.c:110 (gdb)
For the record, does this still occur with the latest version of the port (-rc4 right now)? Tijl, any ideas of what might be going on here?
State Changed From-To: open->closed I believe this should be fixed now based on conversations with other users.
State Changed From-To: closed->open Unfortunatelly it's not fixed.
I reopened this PR because I'm seeing the same issue on my desktop: 7.0-STABLE FreeBSD 7.0-STABLE #30: Tue Aug 12 20:39:59 EEST 2008 i386 with 4GB RAM, ULE scheduler, wine-1.1.2,1 (but it's not version dependent, I tried every version since 1.0.0). I have a report from an other user that doesn't have this problem with wine-0.9.48 or the current version on FreeBSD 7.0-STABLE #8: Sun Jun 22 23:40:53 MSD 2008 (OSVERISION 700101, with older world, also ULE, only 1GB RAM). I get the same bt as the submitter both if compiled w/o debug and with -DWITH_DEBUG: #0 0x7e1fffa9 in thread_init () at thread.c:338 338 user_shared_data->SystemTime.LowPart = now.u.LowPart; [New Thread 0x7c002100 (LWP 100150)] (gdb) bt full #0 0x7e1fffa9 in thread_init () at thread.c:338 peb = (PEB *) 0x110000 teb = (TEB *) 0x114000 addr = (void *) 0x114000 size = 16384 info_size = 0 exe_file = 0x0 now = {u = {LowPart = 2114567916, HighPart = 29949224}, {LowPart = 2114567916, HighPart = 29949224}, QuadPart = 128630939735146220} thread_data = (struct ntdll_thread_data *) 0x1141d4 thread_info = {stack_base = 0x0, stack_size = 0, teb_base = 0x114000, teb_size = 16384, teb_sel = 19, pid = 92943, tid = 100150, entry = 0x1, exit_status = 0} debug_info = {str_pos = 0x7e23af88 "", out_pos = 0x7e23b388 "", strings = '\0' <repeats 1023 times>, output = '\0' <repeats 1023 times>} __func__ = "thread_init" #1 0x7e1d7d37 in __wine_process_init () at loader.c:2598 wm = (WINE_MODREF *) 0x0 status = 518 func_name = {Length = 52628, MaximumLength = 32279, Buffer = 0x7e1d7d20 "U\211__S\203__4____'____\201__t\025\005"} init_func = (void (*)(void)) 0x50 kernel32W = {107, 101, 114, 110, 101, 108, 51, 50, 46, 100, 108, 108, 0} #2 0x7df4624e in wine_init (argc=2, argv=0x7fbfe980, error=0x7fbfe540 "", error_size=1024) at loader.c:656 context = {index = 3, buffer = 0x7c008070 " __\030~", name = 0x7c00808d "", namelen = 10, win16 = 0} path = 0x7c00807a "\001|" ntdll = (void *) 0x7df30800 init_func = (void (*)(void)) 0x7e1d7d20 <__wine_process_init> #3 0x7bf01518 in main (argc=2, argv=0x7fbfe980) at main.c:110 error = "\000____\177\204____\177__Y__})__\a~____s\006\000\006__}@\201__}\001\000\000\000\b____\177__A__}____s\006)__\a~__t\t~\000\006__}__\226__}@\201__}\000\000\000\000\004____\177__Z__}______\177@\201__}\001\000\000\000______\177\001\000\000\000\000\000__}\000\002__}\000\004__}\000\006__}____\b~\000\006__}__\226__}@\201__}\000\000\000\000D____\177__Z__}4____\177______\177\001\000\000\000\000\004__}____s\006)__\a~\000\006__}______\177\004\000\000\000\004\000\000\000\000\006__}__\226__}@\201__}\00 0\004__}D____\177"... i = 184 (gdb) l *0x7e1fffa9 0x7e1fffa9 is in thread_init (thread.c:338). 333 /* initialize LDT locking */ 334 wine_ldt_init_locking( ldt_lock, ldt_unlock ); 335 336 /* initialize time values in user_shared_data */ 337 NtQuerySystemTime( &now ); 338 user_shared_data->SystemTime.LowPart = now.u.LowPart; 339 user_shared_data->SystemTime.High1Time = user_shared_data->SystemTime.High2Time = now.u.HighPart; 340 user_shared_data->u.TickCountQuad = (now.QuadPart - server_start_time) / 10000; 341 user_shared_data->u.TickCount.High2Time = user_shared_data->u.TickCount.High1Time; 342 user_shared_data->TickCountLowDeprecated = user_shared_data->u.TickCount.LowPart; (gdb) l *0x7e1d7d37 0x7e1d7d37 is in __wine_process_init (loader.c:2598). 2593 NTSTATUS status; 2594 ANSI_STRING func_name; 2595 void (* DECLSPEC_NORETURN init_func)(void); 2596 extern mode_t FILE_umask; 2597 2598 main_exe_file = thread_init(); 2599 2600 /* retrieve current umask */ 2601 FILE_umask = umask(0777); 2602 umask( FILE_umask ); (gdb) l *0x7df4624e 0x7df4624e is in wine_init (loader.c:657). 652 free_dll_path( &context ); 653 654 if (!ntdll) return; 655 if (!(init_func = wine_dlsym( ntdll, "__wine_process_init", error, error_size ))) return; 656 init_func(); 657 } 658 659 660 /* 661 * These functions provide wrappers around dlopen() and associated (gdb) l *0x7bf01518 0x7bf01518 is in main (main.c:111). 106 reserve_area( wine_main_preload_info[i].addr, wine_main_preload_info[i].size ); 107 } 108 109 wine_pthread_set_functions( &pthread_functions, sizeof(pthread_functions) ); 110 wine_init( argc, argv, error, sizeof(error) ); 111 fprintf( stderr, "wine: failed to initialize: %s\n", error ); 112 exit(1); 113 } -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B
On Wed, 13 Aug 2008 16:59:15 -0400 David Gilbert <dgilbert@dclg.ca> wrote: > >>>>> "itetcu" == itetcu <itetcu@FreeBSD.org> writes: > > itetcu> Synopsis: emulators/Wine crashes (even winecfg) > itetcu> State-Changed-From-To: closed->open State-Changed-By: itetcu > itetcu> State-Changed-When: Wed Aug 13 09:00:40 UTC 2008 > itetcu> State-Changed-Why: Unfortunatelly it's not fixed. > > itetcu> http://www.freebsd.org/cgi/query-pr.cgi?pr=123526 > > I had determined that my problem was due to increasing the kernel > memory for ZFS. The increased kernel memory caused wine to crash > (unfortunately it doesn't give a helpful hint on why it crashes). The > kernel KVM space parameters are untouched, wine does work for me. ZFS here also. The bad thing is that I can't lower my vm.kmem_size_max="1024M" else I get to many zfs-related problems. -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B
>>>>> "Ion-Mihai" == Ion-Mihai Tetcu <itetcu@FreeBSD.org> writes: Ion-Mihai> On Wed, 13 Aug 2008 16:59:15 -0400 David Gilbert Ion-Mihai> <dgilbert@dclg.ca> wrote: Ion-Mihai> ZFS here also. The bad thing is that I can't lower my Ion-Mihai> vm.kmem_size_max="1024M" else I get to many zfs-related Ion-Mihai> problems. Actually, the ZFS thing is a tiny bit fixable, it seems. The tuning page now talks about the following for i386: * vm.kmem_slze="330M" * vm.kmem_size_max="330M" * vfs.zfs.arc_max="40M" * vfs.zfs.vdev.cache.size="5M" I actually have: zfs_load="YES" vfs.zfs.debug=1 vm.kmem_size="512M" vm.kmem_size_max="512M" vfs.zfs.arc_max="40M" vfs.zfs.vdev.cache.size="5M" ... which seems to both allow wine to run _and_ zfs to perform /usr, /var and /u tasks adequately. I may yet try the 330M line as some time after boot, my ability to run applications that use shaders vanishes. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================
Let me say this is reproduceable without ZFS under FreeBSD 7-STABLE. Core dump backtrace attached. # uname -a FreeBSD here.here.here 7.0-STABLE FreeBSD 7.0-STABLE #5: Fri Aug 1 11:53:17 BRT 2008 lioux@here:/usr/obj/usr/src/sys/LIOUX i386 # ls /var/db/pkg | grep -i wine wine-1.1.4,1 # sysctl vm. | grep kmem vm.kmem_size: 1073741824 vm.kmem_size_min: 0 vm.kmem_size_max: 1073741824 vm.kmem_size_scale: 2 # sysctl -a |grep -i zfs (NOTHING) $ wine-freebsd /tmp/Notepad2.exe Memory fault (core dumped) $ rm -rf /usr/home/lioux/.wine $ winecfg wine: created the configuration directory '/usr/home/lioux/.wine' Memory fault (core dumped) $ cd /usr/ports/emulators/wine $ make DEBUG=1 -V CFLAGS -O2 -fno-strict-aliasing -pipe -ggdb -W -Wall $ gdb -v GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". $ gcc -v Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] -- Mario S F Ferreira - DF - Brazil - "I guess this is a signature." feature, n: a documented bug | bug, n: an undocumented feature
David Gilbert <dgilbert@dclg.ca> wrote: > I actually have: > > zfs_load="YES" > vfs.zfs.debug=1 > vm.kmem_size="512M" > vm.kmem_size_max="512M" > vfs.zfs.arc_max="40M" > vfs.zfs.vdev.cache.size="5M" A very similar configuration here. zfs_load="YES" vfs.zfs.debug="1" vm.kmem_size="512M" vm.kmem_size_max="512M" vfs.zfs.arc_max="160M" vfs.zfs.vdev.cache.size="5M" > ... which seems to both allow wine to run _and_ zfs to perform /usr, > /var and /u tasks adequately. I may yet try the 330M line as some > time after boot, my ability to run applications that use shaders > vanishes. Unfortunately, I'm not fortunate enough to share in this experience. I see essentially the same segfault and backtrace that is being reported in this PR (my own details attached). -- Anthony Chavez http://hexadecagram.org/ mailto:acc@hexadecagram.org xmpp:acc@hexadecagram.org
State Changed From-To: open->suspended There is some work going on in upstream Wine (partly driven by some needs on the FreeBSD side) that may help with this; nothing we can actively do about it at this point, though.
http://www.freebsd.org/cgi/query-pr.cgi?pr=123526 What does "sysctl kern.usrstack" say? It's 3217031168 (0xbfc00000) on my system and I suspect it'll be 2143289344 (0x7fc00000) on your systems. On 32bit systems there's 4G of virtual address space, which is normally split up in 3G user space and 1G kernel space. On your systems it must be 2G/2G. Wine cannot work in that case. There are some Windows heaps in the 3th G and the user_shared_data structure mentioned in the backtraces has to be located at 0x7ffe0000 which in the 2G/2G case is taken by the stack. The only thing you can do is to tweak those sysctl and kernel config options until you have a 3G/1G address space.
On Mon, 6 Apr 2009 16:29:33 +0200 Tijl Coosemans <tijl@ulyssis.org> wrote: > http://www.freebsd.org/cgi/query-pr.cgi?pr=123526 > > What does "sysctl kern.usrstack" say? It's 3217031168 (0xbfc00000) on > my system and I suspect it'll be 2143289344 (0x7fc00000) on your > systems. kern.usrstack: 2143289344 > On 32bit systems there's 4G of virtual address space, which is > normally split up in 3G user space and 1G kernel space. On your > systems it must be 2G/2G. Wine cannot work in that case. There are > some Windows heaps in the 3th G and the user_shared_data structure > mentioned in the backtraces has to be located at 0x7ffe0000 which in > the 2G/2G case is taken by the stack. > > The only thing you can do is to tweak those sysctl and kernel config > options until you have a 3G/1G address space. Problem is that without something like : vm.kmem_size="1024M" vfs.zfs.arc_max="200M" vm.kmem_size_max="1024M" ZFS will crash my machine in a few days and with them it's stable. I'm using qemu as a wordaround, thankfully I don't have time for games, but still it would be nice not to have to fire up qemu for each little thing. -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B
On Monday 06 April 2009 19:46:14 Ion-Mihai Tetcu wrote: > On Mon, 6 Apr 2009 16:29:33 +0200 > Tijl Coosemans <tijl@ulyssis.org> wrote: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=123526 >> >> What does "sysctl kern.usrstack" say? It's 3217031168 (0xbfc00000) >> on my system and I suspect it'll be 2143289344 (0x7fc00000) on your >> systems. > > kern.usrstack: 2143289344 > >> On 32bit systems there's 4G of virtual address space, which is >> normally split up in 3G user space and 1G kernel space. On your >> systems it must be 2G/2G. Wine cannot work in that case. There are >> some Windows heaps in the 3th G and the user_shared_data structure >> mentioned in the backtraces has to be located at 0x7ffe0000 which in >> the 2G/2G case is taken by the stack. >> >> The only thing you can do is to tweak those sysctl and kernel config >> options until you have a 3G/1G address space. > > Problem is that without something like : > vm.kmem_size="1024M" > vfs.zfs.arc_max="200M" > vm.kmem_size_max="1024M" > ZFS will crash my machine in a few days and with them it's stable. Wine needs access up to about address 0x82000000 + some room for the stack. With KVA_PAGES=512 the kernel starts at 0x80000000 and has 2048M available. With KVA_PAGES=500 it starts at 0x83000000 and has 2000M available. That gets Wine running and should still be enough for ZFS. You also need kern.maxdsiz="96M" in /boot/loader.conf. This is the space used by malloc(3), but since FreeBSD 7, malloc can use mmap(2) as well so reducing this to 96M shouldn't affect any program.
Tijl Coosemans wrote: > On Monday 06 April 2009 19:46:14 Ion-Mihai Tetcu wrote: > >> On Mon, 6 Apr 2009 16:29:33 +0200 >> Tijl Coosemans <tijl@ulyssis.org> wrote: >> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=123526 >>> >>> What does "sysctl kern.usrstack" say? It's 3217031168 (0xbfc00000) >>> on my system and I suspect it'll be 2143289344 (0x7fc00000) on your >>> systems. >>> >> kern.usrstack: 2143289344 >> >> >>> On 32bit systems there's 4G of virtual address space, which is >>> normally split up in 3G user space and 1G kernel space. On your >>> systems it must be 2G/2G. Wine cannot work in that case. There are >>> some Windows heaps in the 3th G and the user_shared_data structure >>> mentioned in the backtraces has to be located at 0x7ffe0000 which in >>> the 2G/2G case is taken by the stack. >>> >>> The only thing you can do is to tweak those sysctl and kernel config >>> options until you have a 3G/1G address space. >>> >> Problem is that without something like : >> vm.kmem_size="1024M" >> vfs.zfs.arc_max="200M" >> vm.kmem_size_max="1024M" >> ZFS will crash my machine in a few days and with them it's stable. >> > > Wine needs access up to about address 0x82000000 + some room for the > stack. With KVA_PAGES=512 the kernel starts at 0x80000000 and has > 2048M available. With KVA_PAGES=500 it starts at 0x83000000 and has > 2000M available. That gets Wine running and should still be enough > for ZFS. > > You also need kern.maxdsiz="96M" in /boot/loader.conf. This is the > space used by malloc(3), but since FreeBSD 7, malloc can use mmap(2) > as well so reducing this to 96M shouldn't affect any program. > I found that this was insufficient for any 3D application running with hardware drivers from nvidia. I found that adjusting KVA_PAGES nearly at all from it's default would cause 3D (ie: directX programs) to fail. An example is the eve-online client.
On Wednesday 08 April 2009 15:51:55 David Gilbert wrote: > Tijl Coosemans wrote: >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=123526 >> >> Wine needs access up to about address 0x82000000 + some room for the >> stack. With KVA_PAGES=512 the kernel starts at 0x80000000 and has >> 2048M available. With KVA_PAGES=500 it starts at 0x83000000 and has >> 2000M available. That gets Wine running and should still be enough >> for ZFS. >> >> You also need kern.maxdsiz="96M" in /boot/loader.conf. This is the >> space used by malloc(3), but since FreeBSD 7, malloc can use mmap(2) >> as well so reducing this to 96M shouldn't affect any program. > > I found that this was insufficient for any 3D application running > with hardware drivers from nvidia. I found that adjusting KVA_PAGES > nearly at all from it's default would cause 3D (ie: directX programs) > to fail. An example is the eve-online client. Right, but that's a different problem. The wine executable is located close to 0x80000000 and mmap(2) on FreeBSD (unless given a specific address) only looks for free space after the executable. The graphics driver is running out of address space when there's still plenty left before 0x80000000. It's something that needs to be fixed.
On Wed, 8 Apr 2009 20:24:43 +0200 Tijl Coosemans <tijl@ulyssis.org> wrote: > On Wednesday 08 April 2009 15:51:55 David Gilbert wrote: > > Tijl Coosemans wrote: > >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=123526 > >> > >> Wine needs access up to about address 0x82000000 + some room for > >> the stack. With KVA_PAGES=512 the kernel starts at 0x80000000 and > >> has 2048M available. With KVA_PAGES=500 it starts at 0x83000000 > >> and has 2000M available. That gets Wine running and should still > >> be enough for ZFS. > >> > >> You also need kern.maxdsiz="96M" in /boot/loader.conf. This is the > >> space used by malloc(3), but since FreeBSD 7, malloc can use > >> mmap(2) as well so reducing this to 96M shouldn't affect any > >> program. > > > > I found that this was insufficient for any 3D application running > > with hardware drivers from nvidia. I found that adjusting KVA_PAGES > > nearly at all from it's default would cause 3D (ie: directX > > programs) to fail. An example is the eve-online client. > > Right, but that's a different problem. The wine executable is located > close to 0x80000000 and mmap(2) on FreeBSD (unless given a specific > address) only looks for free space after the executable. The graphics > driver is running out of address space when there's still plenty left > before 0x80000000. It's something that needs to be fixed. > After rebuilding the kernel and setting the sysctl, I get to run winecfg. On the first run I got the two err bellow, on the next run, I didn't: > winecfg Could not load Mozilla. HTML rendering will be disabled. err:module:load_builtin_dll failed to load .so lib for builtin L"glu32.dll": /usr/local/lib/libGLcore.so.1: mmap of entire address space failed: Cannot allocate memory err:module:load_builtin_dll failed to load .so lib for builtin L"opengl32.dll": /usr/local/lib/libGLcore.so.1: mmap of entire address space failed: Cannot allocate memory wine: configuration in '/home/itetcu/.wine' has been updated. fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet Starcraft works, but without sound; strangely, I get sound in the scenario editor. -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B
On Wednesday 08 April 2009 21:38:44 Ion-Mihai Tetcu wrote: >>> Tijl Coosemans wrote: >>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=123526 >>>> >>>> Wine needs access up to about address 0x82000000 + some room for >>>> the stack. With KVA_PAGES=512 the kernel starts at 0x80000000 and >>>> has 2048M available. With KVA_PAGES=500 it starts at 0x83000000 >>>> and has 2000M available. That gets Wine running and should still >>>> be enough for ZFS. >>>> >>>> You also need kern.maxdsiz="96M" in /boot/loader.conf. This is the >>>> space used by malloc(3), but since FreeBSD 7, malloc can use >>>> mmap(2) as well so reducing this to 96M shouldn't affect any >>>> program. > > After rebuilding the kernel and setting the sysctl, I get to run > winecfg. On the first run I got the two err bellow, on the next run, > I didn't: Has it completely disappeared? What if you rename ~/.wine and then run winecfg to create a new one? > Starcraft works, but without sound; strangely, I get sound in the > scenario editor. In winecfg on the audio tab, try setting hardware acceleration to emulation.
On Fri, 10 Apr 2009 11:19:29 +0200 Tijl Coosemans <tijl@ulyssis.org> wrote: > On Wednesday 08 April 2009 21:38:44 Ion-Mihai Tetcu wrote: > >>> Tijl Coosemans wrote: > >>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=123526 > >>>> > >>>> Wine needs access up to about address 0x82000000 + some room for > >>>> the stack. With KVA_PAGES=512 the kernel starts at 0x80000000 and > >>>> has 2048M available. With KVA_PAGES=500 it starts at 0x83000000 > >>>> and has 2000M available. That gets Wine running and should still > >>>> be enough for ZFS. > >>>> > >>>> You also need kern.maxdsiz="96M" in /boot/loader.conf. This is > >>>> the space used by malloc(3), but since FreeBSD 7, malloc can use > >>>> mmap(2) as well so reducing this to 96M shouldn't affect any > >>>> program. > > > > After rebuilding the kernel and setting the sysctl, I get to run > > winecfg. On the first run I got the two err bellow, on the next run, > > I didn't: > > Has it completely disappeared? What if you rename ~/.wine and then run > winecfg to create a new one? Good catch: itetcu@it> /home/itetcu [DING!] 0 > mv .wine .wine.o itetcu@it> /home/itetcu [12:53:40] 0 > winecfg wine: created the configuration directory '/home/itetcu/.wine' Could not load Mozilla. HTML rendering will be disabled. err:module:load_builtin_dll failed to load .so lib for builtin L"glu32.dll": /usr/local/lib/libGLcore.so.1: mmap of entire address space failed: Cannot allocate memory err:module:load_builtin_dll failed to load .so lib for builtin L"opengl32.dll": /usr/local/lib/libGLcore.so.1: mmap of entire address space failed: Cannot allocate memory wine: configuration in '/home/itetcu/.wine' has been updated. > > Starcraft works, but without sound; strangely, I get sound in the > > scenario editor. > > In winecfg on the audio tab, try setting hardware acceleration to > emulation. Actually I found out that the pcm volume is set to 0 when starting starcraft. A nuisance but I can upper it via a terminal or kmix and get sound. David seems to be right about directX programs (I'm yet to be able to run anything besides starcraft and opera). -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B
On Saturday 11 April 2009 18:32:07 Ion-Mihai Tetcu wrote: > On Fri, 10 Apr 2009 11:19:29 +0200 > Tijl Coosemans <tijl@ulyssis.org> wrote: >> On Wednesday 08 April 2009 21:38:44 Ion-Mihai Tetcu wrote: >>> After rebuilding the kernel and setting the sysctl, I get to run >>> winecfg. On the first run I got the two err bellow, on the next >>> run, I didn't: >> >> Has it completely disappeared? What if you rename ~/.wine and then >> run winecfg to create a new one? > > Good catch: > itetcu@it> /home/itetcu [DING!] 0 > > mv .wine .wine.o > itetcu@it> /home/itetcu [12:53:40] 0 > > winecfg > wine: created the configuration directory '/home/itetcu/.wine' > Could not load Mozilla. HTML rendering will be disabled. > err:module:load_builtin_dll failed to load .so lib for builtin L"glu32.dll": /usr/local/lib/libGLcore.so.1: mmap of entire address space failed: Cannot allocate memory > err:module:load_builtin_dll failed to load .so lib for builtin L"opengl32.dll": /usr/local/lib/libGLcore.so.1: mmap of entire address space failed: Cannot allocate memory > wine: configuration in '/home/itetcu/.wine' has been updated. Do you use the nvidia driver? >>> Starcraft works, but without sound; strangely, I get sound in the >>> scenario editor. >> >> In winecfg on the audio tab, try setting hardware acceleration to >> emulation. > > Actually I found out that the pcm volume is set to 0 when starting > starcraft. A nuisance but I can upper it via a terminal or kmix and > get sound. Another case of http://bugs.winehq.org/show_bug.cgi?id=15710 > David seems to be right about directX programs (I'm yet to be able to > run anything besides starcraft and opera). Besides lowering KVA_PAGES not much can be done about this for now. There's a similar problem on Linux where libGL runs out of address space (http://bugs.winehq.org/show_bug.cgi?id=13335) and the solution for that will probably fix this problem as well.
On Sat, 11 Apr 2009 20:58:18 +0200 Tijl Coosemans <tijl@ulyssis.org> wrote: > On Saturday 11 April 2009 18:32:07 Ion-Mihai Tetcu wrote: > > On Fri, 10 Apr 2009 11:19:29 +0200 > > Tijl Coosemans <tijl@ulyssis.org> wrote: > >> On Wednesday 08 April 2009 21:38:44 Ion-Mihai Tetcu wrote: > >>> After rebuilding the kernel and setting the sysctl, I get to run > >>> winecfg. On the first run I got the two err bellow, on the next > >>> run, I didn't: > >> > >> Has it completely disappeared? What if you rename ~/.wine and then > >> run winecfg to create a new one? > > > > Good catch: > > itetcu@it> /home/itetcu [DING!] 0 > > > mv .wine .wine.o > > itetcu@it> /home/itetcu [12:53:40] 0 > > > winecfg > > wine: created the configuration directory '/home/itetcu/.wine' > > Could not load Mozilla. HTML rendering will be disabled. > > err:module:load_builtin_dll failed to load .so lib for builtin > > L"glu32.dll": /usr/local/lib/libGLcore.so.1: mmap of entire address > > space failed: Cannot allocate memory err:module:load_builtin_dll > > failed to load .so lib for builtin > > L"opengl32.dll": /usr/local/lib/libGLcore.so.1: mmap of entire > > address space failed: Cannot allocate memory wine: configuration in > > '/home/itetcu/.wine' has been updated. > > Do you use the nvidia driver? Yes. With this version of xorg, nv driver doesn't work with my card. > >>> Starcraft works, but without sound; strangely, I get sound in the > >>> scenario editor. > >> > >> In winecfg on the audio tab, try setting hardware acceleration to > >> emulation. > > > > Actually I found out that the pcm volume is set to 0 when starting > > starcraft. A nuisance but I can upper it via a terminal or kmix and > > get sound. > > Another case of http://bugs.winehq.org/show_bug.cgi?id=15710 > > > David seems to be right about directX programs (I'm yet to be able > > to run anything besides starcraft and opera). > > Besides lowering KVA_PAGES not much can be done about this for now. > There's a similar problem on Linux where libGL runs out of address > space (http://bugs.winehq.org/show_bug.cgi?id=13335) and the solution > for that will probably fix this problem as well. I'll look at those two bug, thanks. -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B
gerald 2009-04-25 20:35:52 UTC FreeBSD ports repository Modified files: emulators/wine/files pkg-message.in Log: Add a note on KVA_PAGES settings (as recommended by some ZFS tuning guides) being incompatible with Wine. PR: 123526 Submitted by: Tijl Coosemans <tijl@ulyssis.org> Revision Changes Path 1.6 +4 -0 ports/emulators/wine/files/pkg-message.in _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
http://www.freebsd.org/cgi/query-pr.cgi?pr=123526 Are there still problems with OpenGL/DirectX games on recent versions of Wine and KVA_PAGES == 500?
State Changed From-To: suspended->closed Closing this as handled by means of documentation (pkg-message) and since after adding this I have not received nor seen any report in that direction.