From nox at jelal.kn-bremen.de Sun Feb 1 15:58:53 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sun Feb 1 15:59:14 2009 Subject: testing qemu svn r6490 on FreeBSD - vmmouse working again... Message-ID: <20090201235720.GA83120@saturn.kn-bremen.de> Hi! I made another experimental FreeBSD qemu-devl port update, http://people.freebsd.org/~nox/qemu/qemu-devel-20090201.patch and can report that vmmouse is working again (well, except for the fact that it still doesn't work with -kernel-kqemu as mentioned before) and the console and monitor on vc are back to their usual speed; only -vga vmware is still broken. As usual, more testing is welcome... enjoy, Juergen From bugmaster at FreeBSD.org Mon Feb 2 03:06:50 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Feb 2 03:07:37 2009 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org Message-ID: <200902021106.n12B6nNK094391@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/131099 emulation [linux] [patch] readdir broken on Linux emulation. o kern/130724 emulation [linprocfs] [patch] cpuinfo in linprocfs is dated, cau o kern/129169 emulation [linux] [patch] Linux Emulation ENOTCONN error using n f ports/127018 emulation Linuxulator incapable of using FreeBSD's LDAP environm o kern/126232 emulation [linux] Linux ioctl TCGETS (0x5401) always fails o ports/121800 emulation x11-toolkits/linux-openmotif - OpenMotif upgrade to 2. o kern/97326 emulation [linux] file descriptor leakage in linux emulation o ports/91318 emulation [fix] graphics/linux_dri: works on amd64 too o kern/91293 emulation [svr4] [patch] *Experimental* Update to the SVR4 emula o kern/73777 emulation [linux] [patch] linux emulation: root dir special hand a kern/72920 emulation [linux]: path "prefixing" is not done on unix domain s o kern/41543 emulation [patch] [request] easier wine/w23 support o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/29698 emulation [linux] [patch] linux ipcs doesn'work o kern/21463 emulation [linux] Linux compatability mode should not allow setu o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 16 problems total. From daichi at ongs.co.jp Wed Feb 4 19:40:03 2009 From: daichi at ongs.co.jp (Daichi GOTO) Date: Wed Feb 4 19:40:10 2009 Subject: emulators/qemu: build fail on current amd64 Message-ID: <498A5F90.1030004@ongs.co.jp> Hi qemu folks :) I got build fail of emulators/qemu on amd64 8-current. any ideas? thanks /usr/ports/emulators/qemu/work/qemu-0.9.1/vl.c: In function `pp_ioctl': /usr/ports/emulators/qemu/work/qemu-0.9.1/vl.c:1729: warning: cast from pointer to integer of different size /usr/ports/emulators/qemu/work/qemu-0.9.1/vl.c: In function `qemu_chr_open_pp': /usr/ports/emulators/qemu/work/qemu-0.9.1/vl.c:1778: warning: cast to pointer from integer of different size /usr/ports/emulators/qemu/work/qemu-0.9.1/vl.c: At top level: /usr/ports/emulators/qemu/work/qemu-0.9.1/vl.c:1219: warning: 'qemu_next_deadline' defined but not used gmake[1]: *** [vl.o] Error 1 gmake[1]: Leaving directory `/usr/ports/emulators/qemu/work/qemu-0.9.1/i386-softmmu' gmake: *** [subdir-i386-softmmu] Error 2 *** Error code 2 -- Daichi GOTO, http://people.freebsd.org/~daichi From rbgarga at gmail.com Thu Feb 5 02:50:31 2009 From: rbgarga at gmail.com (Renato Botelho) Date: Thu Feb 5 02:50:38 2009 Subject: [PATCH] futexes, flash9 related In-Reply-To: <20081221174939.GA33531@dchagin.dialup.corbina.ru> References: <20081221174939.GA33531@dchagin.dialup.corbina.ru> Message-ID: <747dc8f30902050220y7b1d726bj9f6f83afa843b520@mail.gmail.com> On Sun, Dec 21, 2008 at 3:49 PM, Chagin Dmitry wrote: > > Hi, > /me ready to present patches for testing (nor review). > > The primary goal - the futexes code is rewrited, Giant removed. > > head: http://people.freebsd.org/~timur/dchagin/mega-head.linux.patch > stable/7: http://people.freebsd.org/~timur/dchagin/mega-st7.linux.patch > > Please, test and report any problems. thnx! Hello, I would like to test this because i'm having some freezes on firefox3 + flash9 + 8.0-current i386 r188003 but the patch doesn't apply cleanly here, is there a new version that i've missed? Regards -- Renato Botelho From dchagin at freebsd.org Thu Feb 5 22:55:09 2009 From: dchagin at freebsd.org (Chagin Dmitry) Date: Thu Feb 5 22:55:16 2009 Subject: [PATCH] futexes, flash9 related In-Reply-To: <747dc8f30902050220y7b1d726bj9f6f83afa843b520@mail.gmail.com> References: <20081221174939.GA33531@dchagin.dialup.corbina.ru> <747dc8f30902050220y7b1d726bj9f6f83afa843b520@mail.gmail.com> Message-ID: <20090206063550.GA2123@dchagin.static.corbina.ru> On Thu, Feb 05, 2009 at 08:20:13AM -0200, Renato Botelho wrote: > On Sun, Dec 21, 2008 at 3:49 PM, Chagin Dmitry wrote: > > > > Hi, > > /me ready to present patches for testing (nor review). > > > > The primary goal - the futexes code is rewrited, Giant removed. > > > > head: http://people.freebsd.org/~timur/dchagin/mega-head.linux.patch > > stable/7: http://people.freebsd.org/~timur/dchagin/mega-st7.linux.patch > > > > Please, test and report any problems. thnx! > > Hello, > > I would like to test this because i'm having some freezes on > firefox3 + flash9 + 8.0-current i386 r188003 but the patch > doesn't apply cleanly here, is there a new version that i've > missed? > hi, try http://lnxx64.googlecode.com/files/futexes_partial.patch -- Have fun! chd From vova at fbsd.ru Fri Feb 6 00:06:33 2009 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Fri Feb 6 00:06:40 2009 Subject: astro/google-earth do not work with recent Xorg Message-ID: <1233906496.1746.28.camel@localhost> Hi It starts, then shows on console: -- unknown chip id 0x7145, can't guess. libGL warning: 3D driver returned no fbconfigs. libGL error: InitDriver failed libGL error: reverting to (slow) indirect rendering -- Then shows pop-up with "Google Earth can't runon your machine as it could not access the graphics card. ..." Then crashes with: terminate called after throwing an instance of 'QString' Google Earth has caught signal 6. Stacktrace from glibc: ./googleearth-bin [0x806c3a3] ./googleearth-bin [0x806c916] [0xbfbfffbb] /lib/libc.so.6(abort+0x101) [0x493d0301] ./libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x179) [0x4816a019] ./libstdc++.so.6 [0x481679a5] ./libstdc++.so.6 [0x481679e2] ./libstdc++.so.6 [0x48167b4a] ./librender.so(_ZN12RenderWidget6SetApiEPN5earth4evll3APIE+0x34e) [0x49f3b57e] ./librender.so(_ZN5earth6render12RenderWindow12createWidgetEv+0xb2) [0x49f1cf62] ./libgoogleearth_lib.so(_ZN5earth6client12ModuleWidget9showEventEP10QShowEvent+0x8e) [0x4931af6e] ./libQtGui.so.4(_ZN7QWidget5eventEP6QEvent+0x7cf) [0x4851715f] ... (full crash log attached) I have working openGL for FreeBSD applications (radeonhd driver, ATI X1400 card): $ glinfo Xlib: extension "Generic Event Extension" missing on display ":0.0". Xlib: extension "Generic Event Extension" missing on display ":0.0". GL_VERSION: 1.3 Mesa 7.3 GL_EXTENSIONS: GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_point_parameters GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_MESAX_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_logic_op GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_convolution GL_EXT_copy_texture GL_EXT_draw_range_elements GL_EXT_gpu_program_parameters GL_EXT_histogram GL_EXT_multi_draw_arrays GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_secondary_c! olor GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array GL_APPLE_packed_pixels GL_ATI_blend_equation_separate GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_blend_square GL_NV_light_max_exponent GL_NV_texture_rectangle GL_NV_texgen_reflection GL_NV_vertex_program GL_OES_read_format GL_SGI_color_matrix GL_SGI_color_table GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow_ambient GL_SUN_multi_draw_! arrays GL_RENDERER: Mesa DRI R300 20060815 x86/MMX/SSE2 TCL GL_VENDOR: DRI R300 Project GLU_VERSION: 1.3 GLU_EXTENSIONS: GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess GLUT_API_VERSION: 5 GLUT_XLIB_IMPLEMENTATION: 15 $ Probably reason is in outdated X libraries: xorg-7.4 X.Org complete distribution metaport xorg-apps-7.4_1 X.org apps meta-port xorg-drivers-7.4 X.org drivers meta-port xorg-libraries-7.4 X.org libraries meta-port xorg-server-1.5.3_4,1 X.Org X server and related programs dri-7.3,2 OpenGL hardware acceleration drivers for the DRI libGL-7.3_1 OpenGL library that renders using GLX or DRI libGLU-7.3 OpenGL utility library ... linux-xorg-libs-6.8.2_5 Xorg libraries, linux binaries linux_base-f8-8_11 Base set of packages needed in Linux mode (for i386/amd64) linux_dri-7.0 Binary Linux DRI libraries for 3D hardware acceleration of ... Any hints will be very appreciated. PPS: Also, looks like binary get lost in home on non-first start: $ googleearth Warning: Unable to create prefs directory '/home/vova/.googleearth'. File exists. ... $ file /home/vova /home/vova/.googleearth /compat/linux/home/vova /home/vova: directory /home/vova/.googleearth: directory /compat/linux/home/vova: cannot open `/compat/linux/home/vova' (No such file or directory) -- Vladimir B. Grebenschikov vova@fbsd.ru -------------- next part -------------- CRASHLOGVER 1 CRASHLOGID 0xC3886AC0 APPVERMAJOR 5 APPVERMINOR 0 APPVERBUILD 11337 APPBUILDDATE Jan 28 2009 APPBUILDTIME 15:42:23 OSTYPE 11 OSVERMAJOR 2 OSVERMINOR 6 OSVERBUILD 16 OSVERPATCH 0 PID 2580 CRASHSIGNAL 6 CRASHTIME 1233905118 PROGRAMUPTIME 142 STACK 0x806c3a3 STACK 0x806c916 STACK 0xbfbfffbb STACK 0x493d0301 STACK 0x4816a019 STACK 0x481679a5 STACK 0x481679e2 STACK 0x48167b4a STACK 0x49f3b57e STACK 0x49f1cf62 STACK 0x4931af6e STACK 0x4851715f STACK 0x484d5130 STACK 0x484dc916 STACK 0x482a82f2 STACK 0x48519fc3 STACK 0x48519d0f STACK 0x48519e98 STACK 0x48519ee6 STACK 0x4851a4bb STACK 0x48519e82 STACK 0x48519ee6 STACK 0x48519d0f STACK 0x48519e98 STACK 0x48519ee6 STACK 0x4851a4bb STACK 0x48519e82 STACK 0x48519ee6 STACK 0x4851a4bb STACK 0x48519e82 STACK 0x48519ee6 STACK 0x4851a4bb STACK 0x48519e82 STACK 0x48519ee6 STACK 0x4851a4bb STACK 0x48519e82 STACK 0x48519ee6 STACK 0x4851a4bb STACK 0x4850f865 STACK 0x492ec6ed STACK 0x493547d0 STACK 0x49357140 STACK 0x806da3a STACK 0x493bb390 STACK 0x806bb31 DSO googleearth-bin/0x8048000/298704 DSO libgcc_s.so.1/0x480af000/39096 DSO libstdc++.so.6/0x480ba000/849472 DSO libQtCore.so.4/0x48194000/2207040 DSO libQtGui.so.4/0x483b8000/7148520 DSO libQtNetwork.so.4/0x48aaf000/759340 DSO libQtWebKit.so.4/0x48b6e000/6704984 DSO libgoogleearth_lib.so/0x49260000/1111581 DSO libm.so.6/0x4937c000/159236 DSO libc.so.6/0x493a5000/1400956 DSO libpthread.so.0/0x49502000/81340 DSO libbase.so/0x4951b000/708424 DSO libge_net.so/0x495ce000/313988 DSO libgeobase.so/0x4961d000/3167376 DSO libz.so.1/0x49940000/86972 DSO libgthread-2.0.so.0/0x49957000/13260 DSO librt.so.1/0x4995d000/26320 DSO libglib-2.0.so.0/0x49966000/825192 DSO libdl.so.2/0x49a31000/8440 DSO libfreetype.so.6/0x49a36000/555108 DSO libSM.so.6/0x49ac2000/30508 DSO libICE.so.6/0x49acb000/90184 DSO libXi.so.6/0x49ae6000/27232 DSO libXrender.so.1/0x49aee000/28052 DSO libXrandr.so.2/0x49af6000/9040 DSO libXext.so.6/0x49afa000/55420 DSO libX11.so.6/0x49b09000/846860 DSO libIGCore.so/0x49bdd000/953748 DSO libIGUtils.so/0x49cd4000/146568 DSO libapiloader.so/0x49cfb000/11404 DSO libauth.so/0x49cff000/595472 DSO libcommon.so/0x49d97000/908532 DSO libcomponentframework.so/0x49e7c000/34568 DSO libmath.so/0x49e86000/210756 DSO libmoduleframework.so/0x49ebb000/52172 DSO libport.so/0x49ec9000/35032 DSO librender.so/0x49ed4000/587066 DSO ld-linux.so.2/0x48091000/106644 DSO libIGMath.so/0x49f69000/278124 DSO libminizip.so/0x49fb2000/21592 DSO libfusioncommon.so/0x49fba000/14260 DSO libcurl.so.4/0x49fbf000/201204 DSO libGL.so.1/0x49ff2000/357564 DSO libGLU.so.1/0x4a04d000/507779 DSO libXxf86vm.so.1/0x4a0cc000/15428 DSO libXdamage.so.1/0x4a0d1000/5044 DSO libXfixes.so.3/0x4a0d4000/13696 DSO libdrm.so.2/0x4a0d9000/31240 DSO libXcursor.so.1/0x4e2e5000/33196 DSO libXinerama.so.1/0x4e2ef000/5428 DSO libnss_files.so.2/0x4e2f2000/38440 DSO libqgif.so/0x522fe000/17104 DSO libqjpeg.so/0x52304000/139652 DSO xlcDef.so.2/0x49379000/6468 DSO libIGGfx.so/0x52328000/2970232 DSO libevll.so/0x52615000/8667396 DSO libalchemyext.so/0x52e71000/11492 DSO libIGAttrs.so/0x52e75000/382324 DSO libIGSg.so/0x52edb000/1035108 DSO libicuuc.so.38/0x5304f000/1052797 DSO libcollada.so/0x5315a000/3292858 DSO libIGExportCommon.so/0x53482000/517320 DSO libIGOpt.so/0x5350a000/841416 DSO libIGDisplay.so/0x535e5000/70544 DSO libIGGui.so/0x535f9000/246068 DSO ximcp.so.2/0x5374b000/116084 DSO libnss_dns.so.2/0x5b76e000/15240 DSO libresolv.so.2/0x5b774000/64564 DSO libgobject-2.0.so.0/0x5b799000/254432 DSO libnavigate.so/0x637d9000/1302424 DSO liblayer.so/0x6f922000/1737990 DSO libwmsbase.so/0x6fad6000/323232 DSO libmeasure.so/0x6fb29000/483408 DSO libbasicingest.so/0x6fba5000/783603 DSO libgps.so/0x6fc6e000/471920 DSO libgooglesearch.so/0x6fce7000/553680 DSO libinput_plugin.so/0x6fd74000/280415 DSO libflightsim.so/0x6fdbc000/1236438 DSO r300_dri.so/0x70359000/2122344 DSO libexpat.so.1/0x7057a000/119304 From Alexander at Leidinger.net Fri Feb 6 01:05:40 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Fri Feb 6 01:05:47 2009 Subject: [PATCH] futexes, flash9 related In-Reply-To: <20090206063550.GA2123@dchagin.static.corbina.ru> References: <20081221174939.GA33531@dchagin.dialup.corbina.ru> <747dc8f30902050220y7b1d726bj9f6f83afa843b520@mail.gmail.com> <20090206063550.GA2123@dchagin.static.corbina.ru> Message-ID: <20090206094728.10822rj93nm7s280@webmail.leidinger.net> Quoting Chagin Dmitry (from Fri, 6 Feb 2009 09:35:50 +0300): > On Thu, Feb 05, 2009 at 08:20:13AM -0200, Renato Botelho wrote: >> On Sun, Dec 21, 2008 at 3:49 PM, Chagin Dmitry wrote: >> > >> > Hi, >> > /me ready to present patches for testing (nor review). >> > >> > The primary goal - the futexes code is rewrited, Giant removed. >> > >> > head: http://people.freebsd.org/~timur/dchagin/mega-head.linux.patch >> > stable/7: http://people.freebsd.org/~timur/dchagin/mega-st7.linux.patch >> > >> > Please, test and report any problems. thnx! >> >> Hello, >> >> I would like to test this because i'm having some freezes on >> firefox3 + flash9 + 8.0-current i386 r188003 but the patch >> doesn't apply cleanly here, is there a new version that i've >> missed? >> > > hi, > try http://lnxx64.googlecode.com/files/futexes_partial.patch Please let the DEBUG part as it is, I'm in the process of converting it to DTrace (http://svnweb.freebsd.org/viewvc/base/user/netchild/linuxulator-dtrace/). Bye, Alexander. -- BOFH excuse #397: T1's congested due to porn traffic to the news server http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From kostikbel at gmail.com Fri Feb 6 02:10:22 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Feb 6 02:10:29 2009 Subject: [PATCH] futexes, flash9 related In-Reply-To: <20090206094728.10822rj93nm7s280@webmail.leidinger.net> References: <20081221174939.GA33531@dchagin.dialup.corbina.ru> <747dc8f30902050220y7b1d726bj9f6f83afa843b520@mail.gmail.com> <20090206063550.GA2123@dchagin.static.corbina.ru> <20090206094728.10822rj93nm7s280@webmail.leidinger.net> Message-ID: <20090206092821.GM9427@deviant.kiev.zoral.com.ua> On Fri, Feb 06, 2009 at 09:47:28AM +0100, Alexander Leidinger wrote: > Quoting Chagin Dmitry (from Fri, 6 Feb 2009 > 09:35:50 +0300): > > >On Thu, Feb 05, 2009 at 08:20:13AM -0200, Renato Botelho wrote: > >>On Sun, Dec 21, 2008 at 3:49 PM, Chagin Dmitry > >>wrote: > >>> > >>> Hi, > >>> /me ready to present patches for testing (nor review). > >>> > >>> The primary goal - the futexes code is rewrited, Giant removed. > >>> > >>> head: http://people.freebsd.org/~timur/dchagin/mega-head.linux.patch > >>> stable/7: http://people.freebsd.org/~timur/dchagin/mega-st7.linux.patch > >>> > >>> Please, test and report any problems. thnx! > >> > >>Hello, > >> > >>I would like to test this because i'm having some freezes on > >>firefox3 + flash9 + 8.0-current i386 r188003 but the patch > >>doesn't apply cleanly here, is there a new version that i've > >>missed? > >> > > > >hi, > >try http://lnxx64.googlecode.com/files/futexes_partial.patch > > Please let the DEBUG part as it is, I'm in the process of converting > it to DTrace > (http://svnweb.freebsd.org/viewvc/base/user/netchild/linuxulator-dtrace/). DTrace is absolutely unsuitable for getting the _traces_ from the kernel, as well as the kernel printfs. Moreover, use of KTR is in-line with other tracing points in *our* kernel. DTrace probes are orthogonal to traces. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20090206/060a58a3/attachment.pgp From Alexander at Leidinger.net Fri Feb 6 03:21:17 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Fri Feb 6 03:21:23 2009 Subject: [PATCH] futexes, flash9 related In-Reply-To: <20090206092821.GM9427@deviant.kiev.zoral.com.ua> References: <20081221174939.GA33531@dchagin.dialup.corbina.ru> <747dc8f30902050220y7b1d726bj9f6f83afa843b520@mail.gmail.com> <20090206063550.GA2123@dchagin.static.corbina.ru> <20090206094728.10822rj93nm7s280@webmail.leidinger.net> <20090206092821.GM9427@deviant.kiev.zoral.com.ua> Message-ID: <20090206122103.9886475rqvyhdt2c@webmail.leidinger.net> Quoting Kostik Belousov (from Fri, 6 Feb 2009 11:28:21 +0200): > On Fri, Feb 06, 2009 at 09:47:28AM +0100, Alexander Leidinger wrote: >> Quoting Chagin Dmitry (from Fri, 6 Feb 2009 >> 09:35:50 +0300): >> >> >On Thu, Feb 05, 2009 at 08:20:13AM -0200, Renato Botelho wrote: >> >>On Sun, Dec 21, 2008 at 3:49 PM, Chagin Dmitry >> >>wrote: >> >>> >> >>> Hi, >> >>> /me ready to present patches for testing (nor review). >> >>> >> >>> The primary goal - the futexes code is rewrited, Giant removed. >> >>> >> >>> head: http://people.freebsd.org/~timur/dchagin/mega-head.linux.patch >> >>> stable/7: http://people.freebsd.org/~timur/dchagin/mega-st7.linux.patch >> >>> >> >>> Please, test and report any problems. thnx! >> >> >> >>Hello, >> >> >> >>I would like to test this because i'm having some freezes on >> >>firefox3 + flash9 + 8.0-current i386 r188003 but the patch >> >>doesn't apply cleanly here, is there a new version that i've >> >>missed? >> >> >> > >> >hi, >> >try http://lnxx64.googlecode.com/files/futexes_partial.patch >> >> Please let the DEBUG part as it is, I'm in the process of converting >> it to DTrace >> (http://svnweb.freebsd.org/viewvc/base/user/netchild/linuxulator-dtrace/). > > DTrace is absolutely unsuitable for getting the _traces_ from the kernel, > as well as the kernel printfs. Moreover, use of KTR is in-line with other > tracing points in *our* kernel. Could you please be more specific (maybe some examples) about what you mean by "unsuitable"? Maybe I have a different understanding of "traces" than you have. For the places where KTR is used in _this patch_, DTrace seems to be suitable to me. AFAIR KTR needs to be specially enabled at compile time, while DTrace can be enabled at run-time. Is the KTR part correct? If yes, I see a benefit in using DTrace instead of KTR. Apart from that, DTrace has some advantages (DTrace scripts, limiting the tracing to just use within a specific application, conditional tracing, ...) over KTR, so if it is not something performance critical where DTrace is not able to handle it but KTR is, or something which DTrace is not able to handle at all, I see no point in not converting to DTrace (it has the advantage that it can be used even on a production system, where I wouldn't let KTR in the kernel on a production system). Bye, Alexander. -- BOFH excuse #170: popper unable to process jumbo kernel http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From vova at fbsd.ru Fri Feb 6 03:36:34 2009 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Fri Feb 6 03:36:41 2009 Subject: [PATCH] futexes, flash9 related In-Reply-To: <20090206063550.GA2123@dchagin.static.corbina.ru> References: <20081221174939.GA33531@dchagin.dialup.corbina.ru> <747dc8f30902050220y7b1d726bj9f6f83afa843b520@mail.gmail.com> <20090206063550.GA2123@dchagin.static.corbina.ru> Message-ID: <1233919189.1866.13.camel@localhost> On Fri, 2009-02-06 at 09:35 +0300, Chagin Dmitry wrote: > hi, > try http://lnxx64.googlecode.com/files/futexes_partial.patch For me, with this patch skype leads to kernel panic (vm_fault) on start. SMP System, recent 8-CURRENT. -- Vladimir B. Grebenschikov vova@fbsd.ru From kostikbel at gmail.com Fri Feb 6 04:00:59 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Feb 6 04:01:06 2009 Subject: [PATCH] futexes, flash9 related In-Reply-To: <20090206122103.9886475rqvyhdt2c@webmail.leidinger.net> References: <20081221174939.GA33531@dchagin.dialup.corbina.ru> <747dc8f30902050220y7b1d726bj9f6f83afa843b520@mail.gmail.com> <20090206063550.GA2123@dchagin.static.corbina.ru> <20090206094728.10822rj93nm7s280@webmail.leidinger.net> <20090206092821.GM9427@deviant.kiev.zoral.com.ua> <20090206122103.9886475rqvyhdt2c@webmail.leidinger.net> Message-ID: <20090206120051.GO9427@deviant.kiev.zoral.com.ua> On Fri, Feb 06, 2009 at 12:21:03PM +0100, Alexander Leidinger wrote: > Quoting Kostik Belousov (from Fri, 6 Feb 2009 > 11:28:21 +0200): > > >On Fri, Feb 06, 2009 at 09:47:28AM +0100, Alexander Leidinger wrote: > >>Quoting Chagin Dmitry (from Fri, 6 Feb 2009 > >>09:35:50 +0300): > >> > >>>On Thu, Feb 05, 2009 at 08:20:13AM -0200, Renato Botelho wrote: > >>>>On Sun, Dec 21, 2008 at 3:49 PM, Chagin Dmitry > >>>>wrote: > >>>>> > >>>>> Hi, > >>>>> /me ready to present patches for testing (nor review). > >>>>> > >>>>> The primary goal - the futexes code is rewrited, Giant removed. > >>>>> > >>>>> head: http://people.freebsd.org/~timur/dchagin/mega-head.linux.patch > >>>>> stable/7: > >>http://people.freebsd.org/~timur/dchagin/mega-st7.linux.patch > >>>>> > >>>>> Please, test and report any problems. thnx! > >>>> > >>>>Hello, > >>>> > >>>>I would like to test this because i'm having some freezes on > >>>>firefox3 + flash9 + 8.0-current i386 r188003 but the patch > >>>>doesn't apply cleanly here, is there a new version that i've > >>>>missed? > >>>> > >>> > >>>hi, > >>>try http://lnxx64.googlecode.com/files/futexes_partial.patch > >> > >>Please let the DEBUG part as it is, I'm in the process of converting > >>it to DTrace > >>(http://svnweb.freebsd.org/viewvc/base/user/netchild/linuxulator-dtrace/). > > > >DTrace is absolutely unsuitable for getting the _traces_ from the kernel, > >as well as the kernel printfs. Moreover, use of KTR is in-line with other > >tracing points in *our* kernel. > > Could you please be more specific (maybe some examples) about what you > mean by "unsuitable"? Maybe I have a different understanding of > "traces" than you have. For the places where KTR is used in _this > patch_, DTrace seems to be suitable to me. > > AFAIR KTR needs to be specially enabled at compile time, while DTrace > can be enabled at run-time. Is the KTR part correct? If yes, I see a > benefit in using DTrace instead of KTR. Apart from that, DTrace has > some advantages (DTrace scripts, limiting the tracing to just use > within a specific application, conditional tracing, ...) over KTR, so > if it is not something performance critical where DTrace is not able > to handle it but KTR is, or something which DTrace is not able to > handle at all, I see no point in not converting to DTrace (it has the > advantage that it can be used even on a production system, where I > wouldn't let KTR in the kernel on a production system). 1. KTR does not require any user-mode support or action; in particular, it is useful for after-the-panic analysis, while DTrace is not. 2. Our DTrace support, is, to say it mildly, not quite matured. DTrace to be yseful also needs specially compiled kernel, that is not absolutely trivial at the moment. 3. As I said, DTrace probes are orthogonal to KTR. Put them in, if you want. It is not /instead/. Said this, I do not see a reason to block KTR patch. Absolutely different question is when to commit it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20090206/a4db684e/attachment.pgp From vova at fbsd.ru Fri Feb 6 04:35:42 2009 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Fri Feb 6 04:35:58 2009 Subject: [PATCH] futexes, flash9 related In-Reply-To: <20090206122354.GA5670@dchagin.static.corbina.ru> References: <20081221174939.GA33531@dchagin.dialup.corbina.ru> <747dc8f30902050220y7b1d726bj9f6f83afa843b520@mail.gmail.com> <20090206063550.GA2123@dchagin.static.corbina.ru> <1233919189.1866.13.camel@localhost> <20090206122354.GA5670@dchagin.static.corbina.ru> Message-ID: <1233923734.1866.33.camel@localhost> On Fri, 2009-02-06 at 15:23 +0300, Chagin Dmitry wrote: > On Fri, Feb 06, 2009 at 02:19:49PM +0300, Vladimir Grebenschikov wrote: > > On Fri, 2009-02-06 at 09:35 +0300, Chagin Dmitry wrote: > > > > > hi, > > > try http://lnxx64.googlecode.com/files/futexes_partial.patch > > > > For me, with this patch skype leads to kernel panic (vm_fault) on start. > > > > SMP System, recent 8-CURRENT. > > > > what about? > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html1~ I've did 'call doadump' from KDB console, and it even write something according to messages. But after boot /var/crash was empty. Something broken with dumping ... I've not dig further. Probably will dig at home, but did you just try to start skype (net/skype) ? $ fgrep dump /etc/rc.conf dumpdev="/dev/ad0s2b" $ > thnx! -- Vladimir B. Grebenschikov vova@fbsd.ru From dchagin at freebsd.org Fri Feb 6 04:45:10 2009 From: dchagin at freebsd.org (Chagin Dmitry) Date: Fri Feb 6 04:45:17 2009 Subject: [PATCH] futexes, flash9 related In-Reply-To: <1233919189.1866.13.camel@localhost> References: <20081221174939.GA33531@dchagin.dialup.corbina.ru> <747dc8f30902050220y7b1d726bj9f6f83afa843b520@mail.gmail.com> <20090206063550.GA2123@dchagin.static.corbina.ru> <1233919189.1866.13.camel@localhost> Message-ID: <20090206122354.GA5670@dchagin.static.corbina.ru> On Fri, Feb 06, 2009 at 02:19:49PM +0300, Vladimir Grebenschikov wrote: > On Fri, 2009-02-06 at 09:35 +0300, Chagin Dmitry wrote: > > > hi, > > try http://lnxx64.googlecode.com/files/futexes_partial.patch > > For me, with this patch skype leads to kernel panic (vm_fault) on start. > > SMP System, recent 8-CURRENT. > what about? http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html1~ thnx! -- Have fun! chd From Alexander at Leidinger.net Fri Feb 6 05:08:37 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Fri Feb 6 05:08:44 2009 Subject: [PATCH] futexes, flash9 related In-Reply-To: <20090206120051.GO9427@deviant.kiev.zoral.com.ua> References: <20081221174939.GA33531@dchagin.dialup.corbina.ru> <747dc8f30902050220y7b1d726bj9f6f83afa843b520@mail.gmail.com> <20090206063550.GA2123@dchagin.static.corbina.ru> <20090206094728.10822rj93nm7s280@webmail.leidinger.net> <20090206092821.GM9427@deviant.kiev.zoral.com.ua> <20090206122103.9886475rqvyhdt2c@webmail.leidinger.net> <20090206120051.GO9427@deviant.kiev.zoral.com.ua> Message-ID: <20090206140817.56246os28cq390o4@webmail.leidinger.net> Quoting Kostik Belousov (from Fri, 6 Feb 2009 14:00:51 +0200): > On Fri, Feb 06, 2009 at 12:21:03PM +0100, Alexander Leidinger wrote: >> Quoting Kostik Belousov (from Fri, 6 Feb 2009 >> 11:28:21 +0200): >> >> >On Fri, Feb 06, 2009 at 09:47:28AM +0100, Alexander Leidinger wrote: >> >>Quoting Chagin Dmitry (from Fri, 6 Feb 2009 >> >>09:35:50 +0300): >> >> >> >>>On Thu, Feb 05, 2009 at 08:20:13AM -0200, Renato Botelho wrote: >> >>>>On Sun, Dec 21, 2008 at 3:49 PM, Chagin Dmitry >> >>>>wrote: >> >>>>> >> >>>>> Hi, >> >>>>> /me ready to present patches for testing (nor review). >> >>>>> >> >>>>> The primary goal - the futexes code is rewrited, Giant removed. >> >>>>> >> >>>>> head: http://people.freebsd.org/~timur/dchagin/mega-head.linux.patch >> >>>>> stable/7: >> >>http://people.freebsd.org/~timur/dchagin/mega-st7.linux.patch >> >>>>> >> >>>>> Please, test and report any problems. thnx! >> >>>> >> >>>>Hello, >> >>>> >> >>>>I would like to test this because i'm having some freezes on >> >>>>firefox3 + flash9 + 8.0-current i386 r188003 but the patch >> >>>>doesn't apply cleanly here, is there a new version that i've >> >>>>missed? >> >>>> >> >>> >> >>>hi, >> >>>try http://lnxx64.googlecode.com/files/futexes_partial.patch >> >> >> >>Please let the DEBUG part as it is, I'm in the process of converting >> >>it to DTrace >> >>(http://svnweb.freebsd.org/viewvc/base/user/netchild/linuxulator-dtrace/). >> > >> >DTrace is absolutely unsuitable for getting the _traces_ from the kernel, >> >as well as the kernel printfs. Moreover, use of KTR is in-line with other >> >tracing points in *our* kernel. >> >> Could you please be more specific (maybe some examples) about what you >> mean by "unsuitable"? Maybe I have a different understanding of >> "traces" than you have. For the places where KTR is used in _this >> patch_, DTrace seems to be suitable to me. >> >> AFAIR KTR needs to be specially enabled at compile time, while DTrace >> can be enabled at run-time. Is the KTR part correct? If yes, I see a >> benefit in using DTrace instead of KTR. Apart from that, DTrace has >> some advantages (DTrace scripts, limiting the tracing to just use >> within a specific application, conditional tracing, ...) over KTR, so >> if it is not something performance critical where DTrace is not able >> to handle it but KTR is, or something which DTrace is not able to >> handle at all, I see no point in not converting to DTrace (it has the >> advantage that it can be used even on a production system, where I >> wouldn't let KTR in the kernel on a production system). > > 1. KTR does not require any user-mode support or action; in particular, > it is useful for after-the-panic analysis, while DTrace is not. Yes, but you need to have KTR compiled in for this to work. And when you compile it it, it will generate traces for all events within the mask. So either you have a -1 mask to trace everything at any time, or you can not really do an after-the-panic analysis at all. If you only want to enable it when you reproduce the panic, then DTrace can be used too (the DTrace probes will fire before a panic, as the KTR events will be generated before a panic). You can even limit the tracing in the kernel depending on the program which initiated the call of kernel functions, so you can narrow down the trace to the really interesting stuff, instead of creating a pile of KTR logs and try to filter out uninteresting stuff yourself. All in all I see KTR as something for pure debugging in an controlled environment. Nothing to enable by default in GENERIC. KDTRACE_HOOKS on the other hand is something for GENERIC and for controlled debugging environments (except for time critical stuff). > 2. Our DTrace support, is, to say it mildly, not quite matured. > DTrace to be yseful also needs specially compiled kernel, that is not > absolutely trivial at the moment. You need "options KDTRACE_HOOKS", the rest can be loaded as a module. I would say this is trivial. For KTR you need to have "options KTR" and maybe some more options. So the argument of a specially compiled kernel does not matter. AFAIK KDTRACE_HOOKS was supposed to be activated by default, now that the licensing issues are resolved, but I don't remember why it isn't. I also don't remember why WITH_CTF is not the default at least in -current, so yes, there's room for improvement, but even without CTF enabled during buildworld you can already do useful stuff with dtrace (at least regarding kernel stuff). > 3. As I said, DTrace probes are orthogonal to KTR. Put them in, if > you want. It is not /instead/. I asked to not remove the ifdef DEBUG stuff, as I already remove it while I add DTrace probes (I hope this will make the merging more easy in case I commit my stuff after his stuff comes in). It also serves as some kind of TODO item for me. I did _not_ ask to remove the KTR stuff. I agree that both can coexists (but I don't see a point in having the KTR stuff in the linuxulator when DTrace is mature in FreeBSD). > Said this, I do not see a reason to block KTR patch. Absolutely different > question is when to commit it. That's the reason why I asked to let the ifdef DEBUG part there. I would not be surprised if this patch is committed before I commit the DTrace stuff, and I hope that it will be more easy for me to merge the DTrace stuff when the DEBUG parts stay. Bye, Alexander. -- If some people didn't tell you, you'd never know they'd been away on vacation. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From nox at jelal.kn-bremen.de Fri Feb 6 14:22:51 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Fri Feb 6 14:22:58 2009 Subject: emulators/qemu: build fail on current amd64 In-Reply-To: <498A5F90.1030004@ongs.co.jp> References: <498A5F90.1030004@ongs.co.jp> Message-ID: <20090206214916.GA14653@saturn.kn-bremen.de> On Thu, Feb 05, 2009 at 12:40:00PM +0900, Daichi GOTO wrote: > Hi qemu folks :) Hi :) > > I got build fail of emulators/qemu on amd64 8-current. > any ideas? thanks > > /usr/ports/emulators/qemu/work/qemu-0.9.1/vl.c: In function `pp_ioctl': > /usr/ports/emulators/qemu/work/qemu-0.9.1/vl.c:1729: warning: cast from > pointer to integer of different size > /usr/ports/emulators/qemu/work/qemu-0.9.1/vl.c: In function `qemu_chr_open_pp': > /usr/ports/emulators/qemu/work/qemu-0.9.1/vl.c:1778: warning: cast to > pointer from integer of different size > /usr/ports/emulators/qemu/work/qemu-0.9.1/vl.c: At top level: > /usr/ports/emulators/qemu/work/qemu-0.9.1/vl.c:1219: warning: 'qemu_next_deadline' defined but not used > gmake[1]: *** [vl.o] Error 1 > gmake[1]: Leaving directory `/usr/ports/emulators/qemu/work/qemu-0.9.1/i386-softmmu' > gmake: *** [subdir-i386-softmmu] Error 2 > *** Error code 2 Hmm. Was there more above that? Warnings alone shouldn't cause the compiler to abort, if you see something like that happen its usually another problem like the box running out of memory/swap... If its not that, maybe you can compare with a buildlog from pointyhat: http://pointyhat.freebsd.org/errorlogs/amd64-8-latest-logs/qemu-0.9.1_9.log HTH, Juergen From nox at jelal.kn-bremen.de Fri Feb 6 14:40:32 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Fri Feb 6 14:40:45 2009 Subject: astro/google-earth do not work with recent Xorg In-Reply-To: <1233906496.1746.28.camel@localhost> References: <1233906496.1746.28.camel@localhost> Message-ID: <20090206222042.GB14653@saturn.kn-bremen.de> On Fri, Feb 06, 2009 at 10:48:16AM +0300, Vladimir Grebenschikov wrote: > Hi Hi! > > It starts, then shows on console: > -- > unknown chip id 0x7145, can't guess. > libGL warning: 3D driver returned no fbconfigs. > libGL error: InitDriver failed > libGL error: reverting to (slow) indirect rendering > -- > > Then shows pop-up with "Google Earth can't runon your machine as it > could not access the graphics card. ..." > > Then crashes with: > > terminate called after throwing an instance of 'QString' > Google Earth has caught signal 6. > > Stacktrace from glibc: > ./googleearth-bin [0x806c3a3] > ./googleearth-bin [0x806c916] > [0xbfbfffbb] > /lib/libc.so.6(abort+0x101) [0x493d0301] > ./libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x179) [0x4816a019] > ./libstdc++.so.6 [0x481679a5] > ./libstdc++.so.6 [0x481679e2] > ./libstdc++.so.6 [0x48167b4a] > ./librender.so(_ZN12RenderWidget6SetApiEPN5earth4evll3APIE+0x34e) [0x49f3b57e] > ./librender.so(_ZN5earth6render12RenderWindow12createWidgetEv+0xb2) [0x49f1cf62] > ./libgoogleearth_lib.so(_ZN5earth6client12ModuleWidget9showEventEP10QShowEvent+0x8e) [0x4931af6e] > ./libQtGui.so.4(_ZN7QWidget5eventEP6QEvent+0x7cf) [0x4851715f] > ... (full crash log attached) > > I have working openGL for FreeBSD applications (radeonhd driver, ATI X1400 card): > > $ glinfo > Xlib: extension "Generic Event Extension" missing on display ":0.0". > Xlib: extension "Generic Event Extension" missing on display ":0.0". > GL_VERSION: 1.3 Mesa 7.3 > GL_EXTENSIONS: GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_point_parameters GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_MESAX_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_logic_op GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_convolution GL_EXT_copy_texture GL_EXT_draw_range_elements GL_EXT_gpu_program_parameters GL_EXT_histogram GL_EXT_multi_draw_arrays GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_secondary_c! > olor GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array GL_APPLE_packed_pixels GL_ATI_blend_equation_separate GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_blend_square GL_NV_light_max_exponent GL_NV_texture_rectangle GL_NV_texgen_reflection GL_NV_vertex_program GL_OES_read_format GL_SGI_color_matrix GL_SGI_color_table GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow_ambient GL_SUN_multi_draw_! > arrays > GL_RENDERER: Mesa DRI R300 20060815 x86/MMX/SSE2 TCL > GL_VENDOR: DRI R300 Project > GLU_VERSION: 1.3 > GLU_EXTENSIONS: GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess > GLUT_API_VERSION: 5 > GLUT_XLIB_IMPLEMENTATION: 15 > $ > > Probably reason is in outdated X libraries: > > xorg-7.4 X.Org complete distribution metaport > xorg-apps-7.4_1 X.org apps meta-port > xorg-drivers-7.4 X.org drivers meta-port > xorg-libraries-7.4 X.org libraries meta-port > xorg-server-1.5.3_4,1 X.Org X server and related programs > dri-7.3,2 OpenGL hardware acceleration drivers for the DRI > libGL-7.3_1 OpenGL library that renders using GLX or DRI > libGLU-7.3 OpenGL utility library > ... > linux-xorg-libs-6.8.2_5 Xorg libraries, linux binaries > linux_base-f8-8_11 Base set of packages needed in Linux mode (for i386/amd64) > linux_dri-7.0 Binary Linux DRI libraries for 3D hardware acceleration of > > ... > > Any hints will be very appreciated. > Hmm. does this work for anyone else? Did the old version work for you? I must say I only tested the update on the old xorg with the nvidia blob so far where it worked, and we can't really go back to the old googleearth version now because they only give out the new distfile now... > PPS: > Also, looks like binary get lost in home on non-first start: > $ googleearth > Warning: Unable to create prefs directory '/home/vova/.googleearth'. File exists. Yeah I now get that too, seems to be harmless. (I guess it does a mkdir w/o checking first whether that dir already exists...) > ... > > $ file /home/vova /home/vova/.googleearth /compat/linux/home/vova > /home/vova: directory > /home/vova/.googleearth: directory > /compat/linux/home/vova: cannot open `/compat/linux/home/vova' (No such file or directory) > > -- > Vladimir B. Grebenschikov > vova@fbsd.ru > CRASHLOGVER 1 > CRASHLOGID 0xC3886AC0 > APPVERMAJOR 5 > APPVERMINOR 0 > APPVERBUILD 11337 > APPBUILDDATE Jan 28 2009 > APPBUILDTIME 15:42:23 > OSTYPE 11 > OSVERMAJOR 2 > OSVERMINOR 6 > OSVERBUILD 16 > OSVERPATCH 0 > PID 2580 > CRASHSIGNAL 6 > CRASHTIME 1233905118 > PROGRAMUPTIME 142 > > STACK 0x806c3a3 > STACK 0x806c916 > STACK 0xbfbfffbb > STACK 0x493d0301 > STACK 0x4816a019 > STACK 0x481679a5 > STACK 0x481679e2 > STACK 0x48167b4a > STACK 0x49f3b57e > STACK 0x49f1cf62 > STACK 0x4931af6e > STACK 0x4851715f > STACK 0x484d5130 > STACK 0x484dc916 > STACK 0x482a82f2 > STACK 0x48519fc3 > STACK 0x48519d0f > STACK 0x48519e98 > STACK 0x48519ee6 > STACK 0x4851a4bb > STACK 0x48519e82 > STACK 0x48519ee6 > STACK 0x48519d0f > STACK 0x48519e98 > STACK 0x48519ee6 > STACK 0x4851a4bb > STACK 0x48519e82 > STACK 0x48519ee6 > STACK 0x4851a4bb > STACK 0x48519e82 > STACK 0x48519ee6 > STACK 0x4851a4bb > STACK 0x48519e82 > STACK 0x48519ee6 > STACK 0x4851a4bb > STACK 0x48519e82 > STACK 0x48519ee6 > STACK 0x4851a4bb > STACK 0x4850f865 > STACK 0x492ec6ed > STACK 0x493547d0 > STACK 0x49357140 > STACK 0x806da3a > STACK 0x493bb390 > STACK 0x806bb31 > > DSO googleearth-bin/0x8048000/298704 > DSO libgcc_s.so.1/0x480af000/39096 > DSO libstdc++.so.6/0x480ba000/849472 > DSO libQtCore.so.4/0x48194000/2207040 > DSO libQtGui.so.4/0x483b8000/7148520 > DSO libQtNetwork.so.4/0x48aaf000/759340 > DSO libQtWebKit.so.4/0x48b6e000/6704984 > DSO libgoogleearth_lib.so/0x49260000/1111581 > DSO libm.so.6/0x4937c000/159236 > DSO libc.so.6/0x493a5000/1400956 > DSO libpthread.so.0/0x49502000/81340 > DSO libbase.so/0x4951b000/708424 > DSO libge_net.so/0x495ce000/313988 > DSO libgeobase.so/0x4961d000/3167376 > DSO libz.so.1/0x49940000/86972 > DSO libgthread-2.0.so.0/0x49957000/13260 > DSO librt.so.1/0x4995d000/26320 > DSO libglib-2.0.so.0/0x49966000/825192 > DSO libdl.so.2/0x49a31000/8440 > DSO libfreetype.so.6/0x49a36000/555108 > DSO libSM.so.6/0x49ac2000/30508 > DSO libICE.so.6/0x49acb000/90184 > DSO libXi.so.6/0x49ae6000/27232 > DSO libXrender.so.1/0x49aee000/28052 > DSO libXrandr.so.2/0x49af6000/9040 > DSO libXext.so.6/0x49afa000/55420 > DSO libX11.so.6/0x49b09000/846860 > DSO libIGCore.so/0x49bdd000/953748 > DSO libIGUtils.so/0x49cd4000/146568 > DSO libapiloader.so/0x49cfb000/11404 > DSO libauth.so/0x49cff000/595472 > DSO libcommon.so/0x49d97000/908532 > DSO libcomponentframework.so/0x49e7c000/34568 > DSO libmath.so/0x49e86000/210756 > DSO libmoduleframework.so/0x49ebb000/52172 > DSO libport.so/0x49ec9000/35032 > DSO librender.so/0x49ed4000/587066 > DSO ld-linux.so.2/0x48091000/106644 > DSO libIGMath.so/0x49f69000/278124 > DSO libminizip.so/0x49fb2000/21592 > DSO libfusioncommon.so/0x49fba000/14260 > DSO libcurl.so.4/0x49fbf000/201204 > DSO libGL.so.1/0x49ff2000/357564 > DSO libGLU.so.1/0x4a04d000/507779 > DSO libXxf86vm.so.1/0x4a0cc000/15428 > DSO libXdamage.so.1/0x4a0d1000/5044 > DSO libXfixes.so.3/0x4a0d4000/13696 > DSO libdrm.so.2/0x4a0d9000/31240 > DSO libXcursor.so.1/0x4e2e5000/33196 > DSO libXinerama.so.1/0x4e2ef000/5428 > DSO libnss_files.so.2/0x4e2f2000/38440 > DSO libqgif.so/0x522fe000/17104 > DSO libqjpeg.so/0x52304000/139652 > DSO xlcDef.so.2/0x49379000/6468 > DSO libIGGfx.so/0x52328000/2970232 > DSO libevll.so/0x52615000/8667396 > DSO libalchemyext.so/0x52e71000/11492 > DSO libIGAttrs.so/0x52e75000/382324 > DSO libIGSg.so/0x52edb000/1035108 > DSO libicuuc.so.38/0x5304f000/1052797 > DSO libcollada.so/0x5315a000/3292858 > DSO libIGExportCommon.so/0x53482000/517320 > DSO libIGOpt.so/0x5350a000/841416 > DSO libIGDisplay.so/0x535e5000/70544 > DSO libIGGui.so/0x535f9000/246068 > DSO ximcp.so.2/0x5374b000/116084 > DSO libnss_dns.so.2/0x5b76e000/15240 > DSO libresolv.so.2/0x5b774000/64564 > DSO libgobject-2.0.so.0/0x5b799000/254432 > DSO libnavigate.so/0x637d9000/1302424 > DSO liblayer.so/0x6f922000/1737990 > DSO libwmsbase.so/0x6fad6000/323232 > DSO libmeasure.so/0x6fb29000/483408 > DSO libbasicingest.so/0x6fba5000/783603 > DSO libgps.so/0x6fc6e000/471920 > DSO libgooglesearch.so/0x6fce7000/553680 > DSO libinput_plugin.so/0x6fd74000/280415 > DSO libflightsim.so/0x6fdbc000/1236438 > DSO r300_dri.so/0x70359000/2122344 > DSO libexpat.so.1/0x7057a000/119304 > > From rnoland at FreeBSD.org Sat Feb 7 08:43:15 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Sat Feb 7 08:43:21 2009 Subject: astro/google-earth do not work with recent Xorg In-Reply-To: <1233906496.1746.28.camel@localhost> References: <1233906496.1746.28.camel@localhost> Message-ID: <1234023100.1562.30.camel@ferret.2hip.net> On Fri, 2009-02-06 at 10:48 +0300, Vladimir Grebenschikov wrote: > Hi > > It starts, then shows on console: > -- > unknown chip id 0x7145, can't guess. > libGL warning: 3D driver returned no fbconfigs. > libGL error: InitDriver failed > libGL error: reverting to (slow) indirect rendering > -- > > Then shows pop-up with "Google Earth can't runon your machine as it > could not access the graphics card. ..." Try setting LIBGL_ALWAYS_INDIRECT=1 It is usually required to run google-earth. robert. > Then crashes with: > > terminate called after throwing an instance of 'QString' > Google Earth has caught signal 6. > > Stacktrace from glibc: > ./googleearth-bin [0x806c3a3] > ./googleearth-bin [0x806c916] > [0xbfbfffbb] > /lib/libc.so.6(abort+0x101) [0x493d0301] > ./libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x179) [0x4816a019] > ./libstdc++.so.6 [0x481679a5] > ./libstdc++.so.6 [0x481679e2] > ./libstdc++.so.6 [0x48167b4a] > ./librender.so(_ZN12RenderWidget6SetApiEPN5earth4evll3APIE+0x34e) [0x49f3b57e] > ./librender.so(_ZN5earth6render12RenderWindow12createWidgetEv+0xb2) [0x49f1cf62] > ./libgoogleearth_lib.so(_ZN5earth6client12ModuleWidget9showEventEP10QShowEvent+0x8e) [0x4931af6e] > ./libQtGui.so.4(_ZN7QWidget5eventEP6QEvent+0x7cf) [0x4851715f] > ... (full crash log attached) > > I have working openGL for FreeBSD applications (radeonhd driver, ATI X1400 card): > > $ glinfo > Xlib: extension "Generic Event Extension" missing on display ":0.0". > Xlib: extension "Generic Event Extension" missing on display ":0.0". > GL_VERSION: 1.3 Mesa 7.3 > GL_EXTENSIONS: GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_point_parameters GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_MESAX_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_logic_op GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_convolution GL_EXT_copy_texture GL_EXT_draw_range_elements GL_EXT_gpu_program_parameters GL_EXT_histogram GL_EXT_multi_draw_arrays GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_secondary_c! > olor GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array GL_APPLE_packed_pixels GL_ATI_blend_equation_separate GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_blend_square GL_NV_light_max_exponent GL_NV_texture_rectangle GL_NV_texgen_reflection GL_NV_vertex_program GL_OES_read_format GL_SGI_color_matrix GL_SGI_color_table GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow_ambient GL_SUN_multi_draw_! > arrays > GL_RENDERER: Mesa DRI R300 20060815 x86/MMX/SSE2 TCL > GL_VENDOR: DRI R300 Project > GLU_VERSION: 1.3 > GLU_EXTENSIONS: GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess > GLUT_API_VERSION: 5 > GLUT_XLIB_IMPLEMENTATION: 15 > $ > > Probably reason is in outdated X libraries: > > xorg-7.4 X.Org complete distribution metaport > xorg-apps-7.4_1 X.org apps meta-port > xorg-drivers-7.4 X.org drivers meta-port > xorg-libraries-7.4 X.org libraries meta-port > xorg-server-1.5.3_4,1 X.Org X server and related programs > dri-7.3,2 OpenGL hardware acceleration drivers for the DRI > libGL-7.3_1 OpenGL library that renders using GLX or DRI > libGLU-7.3 OpenGL utility library > ... > linux-xorg-libs-6.8.2_5 Xorg libraries, linux binaries > linux_base-f8-8_11 Base set of packages needed in Linux mode (for i386/amd64) > linux_dri-7.0 Binary Linux DRI libraries for 3D hardware acceleration of > > ... > > Any hints will be very appreciated. > > PPS: > Also, looks like binary get lost in home on non-first start: > $ googleearth > Warning: Unable to create prefs directory '/home/vova/.googleearth'. File exists. > ... > > $ file /home/vova /home/vova/.googleearth /compat/linux/home/vova > /home/vova: directory > /home/vova/.googleearth: directory > /compat/linux/home/vova: cannot open `/compat/linux/home/vova' (No such file or directory) > > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20090207/54f3508c/attachment.pgp From vova at fbsd.ru Sat Feb 7 13:57:52 2009 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Sat Feb 7 13:58:04 2009 Subject: astro/google-earth do not work with recent Xorg In-Reply-To: <1234023100.1562.30.camel@ferret.2hip.net> References: <1233906496.1746.28.camel@localhost> <1234023100.1562.30.camel@ferret.2hip.net> Message-ID: <1234043859.3298.44.camel@localhost> On Sat, 2009-02-07 at 11:11 -0500, Robert Noland wrote: > On Fri, 2009-02-06 at 10:48 +0300, Vladimir Grebenschikov wrote: > > Hi > > > > It starts, then shows on console: > > -- > > unknown chip id 0x7145, can't guess. > > libGL warning: 3D driver returned no fbconfigs. > > libGL error: InitDriver failed > > libGL error: reverting to (slow) indirect rendering > > -- > > > > Then shows pop-up with "Google Earth can't runon your machine as it > > could not access the graphics card. ..." > > Try setting LIBGL_ALWAYS_INDIRECT=1 > > It is usually required to run google-earth. Unfortunately, it does not helps, everything the same. > robert. > > > Then crashes with: > > > > terminate called after throwing an instance of 'QString' > > Google Earth has caught signal 6. > > > > Stacktrace from glibc: > > ./googleearth-bin [0x806c3a3] > > ./googleearth-bin [0x806c916] > > [0xbfbfffbb] > > /lib/libc.so.6(abort+0x101) [0x493d0301] > > ./libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x179) [0x4816a019] > > ./libstdc++.so.6 [0x481679a5] > > ./libstdc++.so.6 [0x481679e2] > > ./libstdc++.so.6 [0x48167b4a] > > ./librender.so(_ZN12RenderWidget6SetApiEPN5earth4evll3APIE+0x34e) [0x49f3b57e] > > ./librender.so(_ZN5earth6render12RenderWindow12createWidgetEv+0xb2) [0x49f1cf62] > > ./libgoogleearth_lib.so(_ZN5earth6client12ModuleWidget9showEventEP10QShowEvent+0x8e) [0x4931af6e] > > ./libQtGui.so.4(_ZN7QWidget5eventEP6QEvent+0x7cf) [0x4851715f] > > ... (full crash log attached) > > > > I have working openGL for FreeBSD applications (radeonhd driver, ATI X1400 card): > > > > $ glinfo > > Xlib: extension "Generic Event Extension" missing on display ":0.0". > > Xlib: extension "Generic Event Extension" missing on display ":0.0". > > GL_VERSION: 1.3 Mesa 7.3 > > GL_EXTENSIONS: GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_point_parameters GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_MESAX_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_logic_op GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_convolution GL_EXT_copy_texture GL_EXT_draw_range_elements GL_EXT_gpu_program_parameters GL_EXT_histogram GL_EXT_multi_draw_arrays GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_seconda! ry_c! > > olor GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array GL_APPLE_packed_pixels GL_ATI_blend_equation_separate GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_blend_square GL_NV_light_max_exponent GL_NV_texture_rectangle GL_NV_texgen_reflection GL_NV_vertex_program GL_OES_read_format GL_SGI_color_matrix GL_SGI_color_table GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow_ambient GL_SUN_multi_d! raw_! > > arrays > > GL_RENDERER: Mesa DRI R300 20060815 x86/MMX/SSE2 TCL > > GL_VENDOR: DRI R300 Project > > GLU_VERSION: 1.3 > > GLU_EXTENSIONS: GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess > > GLUT_API_VERSION: 5 > > GLUT_XLIB_IMPLEMENTATION: 15 > > $ > > > > Probably reason is in outdated X libraries: > > > > xorg-7.4 X.Org complete distribution metaport > > xorg-apps-7.4_1 X.org apps meta-port > > xorg-drivers-7.4 X.org drivers meta-port > > xorg-libraries-7.4 X.org libraries meta-port > > xorg-server-1.5.3_4,1 X.Org X server and related programs > > dri-7.3,2 OpenGL hardware acceleration drivers for the DRI > > libGL-7.3_1 OpenGL library that renders using GLX or DRI > > libGLU-7.3 OpenGL utility library > > ... > > linux-xorg-libs-6.8.2_5 Xorg libraries, linux binaries > > linux_base-f8-8_11 Base set of packages needed in Linux mode (for i386/amd64) > > linux_dri-7.0 Binary Linux DRI libraries for 3D hardware acceleration of > > > > ... > > > > Any hints will be very appreciated. > > > > PPS: > > Also, looks like binary get lost in home on non-first start: > > $ googleearth > > Warning: Unable to create prefs directory '/home/vova/.googleearth'. File exists. > > ... > > > > $ file /home/vova /home/vova/.googleearth /compat/linux/home/vova > > /home/vova: directory > > /home/vova/.googleearth: directory > > /compat/linux/home/vova: cannot open `/compat/linux/home/vova' (No such file or directory) > > > > _______________________________________________ > > freebsd-x11@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" -- Vladimir B. Grebenschikov vova@fbsd.ru From dchagin at freebsd.org Sun Feb 8 12:05:50 2009 From: dchagin at freebsd.org (Chagin Dmitry) Date: Sun Feb 8 12:05:57 2009 Subject: [PATCH] futexes, flash9 related In-Reply-To: <1233923734.1866.33.camel@localhost> References: <20081221174939.GA33531@dchagin.dialup.corbina.ru> <747dc8f30902050220y7b1d726bj9f6f83afa843b520@mail.gmail.com> <20090206063550.GA2123@dchagin.static.corbina.ru> <1233919189.1866.13.camel@localhost> <20090206122354.GA5670@dchagin.static.corbina.ru> <1233923734.1866.33.camel@localhost> Message-ID: <20090208200541.GA59299@dchagin.static.corbina.ru> On Fri, Feb 06, 2009 at 03:35:34PM +0300, Vladimir Grebenschikov wrote: > On Fri, 2009-02-06 at 15:23 +0300, Chagin Dmitry wrote: > > On Fri, Feb 06, 2009 at 02:19:49PM +0300, Vladimir Grebenschikov wrote: > > > On Fri, 2009-02-06 at 09:35 +0300, Chagin Dmitry wrote: > > > > > > > hi, > > > > try http://lnxx64.googlecode.com/files/futexes_partial.patch > > > > > > For me, with this patch skype leads to kernel panic (vm_fault) on start. > > > > > > SMP System, recent 8-CURRENT. > > > > > > > what about? > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html1~ > > I've did 'call doadump' from KDB console, and it even write something > according to messages. But after boot /var/crash was empty. > > Something broken with dumping ... > > I've not dig further. > Probably will dig at home, > but did you just try to start skype (net/skype) ? > > $ fgrep dump /etc/rc.conf > dumpdev="/dev/ad0s2b" > $ > hi, please, try http://lnxx64.googlecode.com/files/futexes_partial_II.patch first patch fail at i386... -- Have fun! chd From bugmaster at FreeBSD.org Mon Feb 9 03:06:50 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Feb 9 03:07:43 2009 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org Message-ID: <200902091106.n19B6nqA009072@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/131099 emulation [linux] [patch] readdir broken on Linux emulation. o kern/130724 emulation [linprocfs] [patch] cpuinfo in linprocfs is dated, cau o kern/129169 emulation [linux] [patch] Linux Emulation ENOTCONN error using n f ports/127018 emulation Linuxulator incapable of using FreeBSD's LDAP environm o kern/126232 emulation [linux] Linux ioctl TCGETS (0x5401) always fails o ports/121800 emulation x11-toolkits/linux-openmotif - OpenMotif upgrade to 2. o kern/97326 emulation [linux] file descriptor leakage in linux emulation o ports/91318 emulation [fix] graphics/linux_dri: works on amd64 too o kern/91293 emulation [svr4] [patch] *Experimental* Update to the SVR4 emula o kern/73777 emulation [linux] [patch] linux emulation: root dir special hand a kern/72920 emulation [linux]: path "prefixing" is not done on unix domain s o kern/41543 emulation [patch] [request] easier wine/w23 support o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/29698 emulation [linux] [patch] linux ipcs doesn'work o kern/21463 emulation [linux] Linux compatability mode should not allow setu o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 16 problems total. From rbgarga at gmail.com Mon Feb 9 05:01:55 2009 From: rbgarga at gmail.com (Renato Botelho) Date: Mon Feb 9 05:02:02 2009 Subject: [PATCH] futexes, flash9 related In-Reply-To: <20090208200541.GA59299@dchagin.static.corbina.ru> References: <20081221174939.GA33531@dchagin.dialup.corbina.ru> <747dc8f30902050220y7b1d726bj9f6f83afa843b520@mail.gmail.com> <20090206063550.GA2123@dchagin.static.corbina.ru> <1233919189.1866.13.camel@localhost> <20090206122354.GA5670@dchagin.static.corbina.ru> <1233923734.1866.33.camel@localhost> <20090208200541.GA59299@dchagin.static.corbina.ru> Message-ID: <747dc8f30902090501l58979723l8e0de51482131991@mail.gmail.com> On Sun, Feb 8, 2009 at 6:05 PM, Chagin Dmitry wrote: > On Fri, Feb 06, 2009 at 03:35:34PM +0300, Vladimir Grebenschikov wrote: >> On Fri, 2009-02-06 at 15:23 +0300, Chagin Dmitry wrote: >> > On Fri, Feb 06, 2009 at 02:19:49PM +0300, Vladimir Grebenschikov wrote: >> > > On Fri, 2009-02-06 at 09:35 +0300, Chagin Dmitry wrote: >> > > >> > > > hi, >> > > > try http://lnxx64.googlecode.com/files/futexes_partial.patch >> > > >> > > For me, with this patch skype leads to kernel panic (vm_fault) on start. >> > > >> > > SMP System, recent 8-CURRENT. >> > > >> > >> > what about? >> > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html1~ >> >> I've did 'call doadump' from KDB console, and it even write something >> according to messages. But after boot /var/crash was empty. >> >> Something broken with dumping ... >> >> I've not dig further. >> Probably will dig at home, >> but did you just try to start skype (net/skype) ? >> >> $ fgrep dump /etc/rc.conf >> dumpdev="/dev/ad0s2b" >> $ >> > > hi, > please, try http://lnxx64.googlecode.com/files/futexes_partial_II.patch > first patch fail at i386... It seems to be working really fine here, flash9 under firefox 3 is much better than before. -- Renato Botelho From sfourman at gmail.com Mon Feb 9 05:11:50 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Mon Feb 9 05:11:57 2009 Subject: [PATCH] futexes, flash9 related In-Reply-To: <747dc8f30902090501l58979723l8e0de51482131991@mail.gmail.com> References: <20081221174939.GA33531@dchagin.dialup.corbina.ru> <747dc8f30902050220y7b1d726bj9f6f83afa843b520@mail.gmail.com> <20090206063550.GA2123@dchagin.static.corbina.ru> <1233919189.1866.13.camel@localhost> <20090206122354.GA5670@dchagin.static.corbina.ru> <1233923734.1866.33.camel@localhost> <20090208200541.GA59299@dchagin.static.corbina.ru> <747dc8f30902090501l58979723l8e0de51482131991@mail.gmail.com> Message-ID: <11167f520902090511i52adaa7dm9c44025578aecf2c@mail.gmail.com> >> please, try http://lnxx64.googlecode.com/files/futexes_partial_II.patch >> first patch fail at i386... What is the syntax to apply this patch to -CURRENT, also can this patch be applied to i386 as well as amd64? Sam From dchagin at freebsd.org Mon Feb 9 05:21:15 2009 From: dchagin at freebsd.org (Chagin Dmitry) Date: Mon Feb 9 05:21:22 2009 Subject: [PATCH] futexes, flash9 related In-Reply-To: <11167f520902090511i52adaa7dm9c44025578aecf2c@mail.gmail.com> References: <20081221174939.GA33531@dchagin.dialup.corbina.ru> <747dc8f30902050220y7b1d726bj9f6f83afa843b520@mail.gmail.com> <20090206063550.GA2123@dchagin.static.corbina.ru> <1233919189.1866.13.camel@localhost> <20090206122354.GA5670@dchagin.static.corbina.ru> <1233923734.1866.33.camel@localhost> <20090208200541.GA59299@dchagin.static.corbina.ru> <747dc8f30902090501l58979723l8e0de51482131991@mail.gmail.com> <11167f520902090511i52adaa7dm9c44025578aecf2c@mail.gmail.com> Message-ID: <20090209132108.GA27104@dchagin.static.corbina.ru> On Mon, Feb 09, 2009 at 07:11:36AM -0600, Sam Fourman Jr. wrote: > >> please, try http://lnxx64.googlecode.com/files/futexes_partial_II.patch > >> first patch fail at i386... > > What is the syntax to apply this patch to -CURRENT, also can this > patch be applied to i386 as well as amd64? > > Sam hi, yes, of course. I usually make only compile-test for the i386, but this time tested on a workstation :) previous version of the patch did not work on i386. ps. I suspect that flash9 have problems that can not be solved in the emulator. can someone test flash_v10? -- Have fun! chd From rbgarga at gmail.com Mon Feb 9 06:42:06 2009 From: rbgarga at gmail.com (Renato Botelho) Date: Mon Feb 9 06:42:13 2009 Subject: [PATCH] futexes, flash9 related In-Reply-To: <20090209132108.GA27104@dchagin.static.corbina.ru> References: <20081221174939.GA33531@dchagin.dialup.corbina.ru> <747dc8f30902050220y7b1d726bj9f6f83afa843b520@mail.gmail.com> <20090206063550.GA2123@dchagin.static.corbina.ru> <1233919189.1866.13.camel@localhost> <20090206122354.GA5670@dchagin.static.corbina.ru> <1233923734.1866.33.camel@localhost> <20090208200541.GA59299@dchagin.static.corbina.ru> <747dc8f30902090501l58979723l8e0de51482131991@mail.gmail.com> <11167f520902090511i52adaa7dm9c44025578aecf2c@mail.gmail.com> <20090209132108.GA27104@dchagin.static.corbina.ru> Message-ID: <747dc8f30902090635u205e8f55x19cfa201bdfd7028@mail.gmail.com> On Mon, Feb 9, 2009 at 11:21 AM, Chagin Dmitry wrote: > On Mon, Feb 09, 2009 at 07:11:36AM -0600, Sam Fourman Jr. wrote: >> >> please, try http://lnxx64.googlecode.com/files/futexes_partial_II.patch >> >> first patch fail at i386... >> >> What is the syntax to apply this patch to -CURRENT, also can this >> patch be applied to i386 as well as amd64? >> >> Sam > > hi, yes, of course. I usually make only compile-test for the i386, > but this time tested on a workstation :) > > previous version of the patch did not work on i386. > > > ps. I suspect that flash9 have problems that can not be solved > in the emulator. can someone test flash_v10? Is there any patch available to install flash v10 + native ff3 + nspluginwrapper? -- Renato Botelho From daichi at ongs.co.jp Mon Feb 9 19:06:40 2009 From: daichi at ongs.co.jp (Daichi GOTO) Date: Mon Feb 9 19:06:47 2009 Subject: emulators/qemu: build fail on current amd64 In-Reply-To: <20090206214916.GA14653@saturn.kn-bremen.de> References: <498A5F90.1030004@ongs.co.jp> <20090206214916.GA14653@saturn.kn-bremen.de> Message-ID: <4990EF3E.5090908@ongs.co.jp> After some days, I have tried to build qemu and kqemu with latest amd64 current system, and I have gottten it success :) FYI, qemu works well but without kqemu. # /usr/local/etc/rc.d/kqemu start kldload: can't load kqemu: Exec format error /usr/local/etc/rc.d/kqemu: WARNING: kqemu module failed to load. # Juergen Lock wrote: > On Thu, Feb 05, 2009 at 12:40:00PM +0900, Daichi GOTO wrote: >> Hi qemu folks :) > Hi :) >> I got build fail of emulators/qemu on amd64 8-current. >> any ideas? thanks >> >> /usr/ports/emulators/qemu/work/qemu-0.9.1/vl.c: In function `pp_ioctl': >> /usr/ports/emulators/qemu/work/qemu-0.9.1/vl.c:1729: warning: cast from >> pointer to integer of different size >> /usr/ports/emulators/qemu/work/qemu-0.9.1/vl.c: In function `qemu_chr_open_pp': >> /usr/ports/emulators/qemu/work/qemu-0.9.1/vl.c:1778: warning: cast to >> pointer from integer of different size >> /usr/ports/emulators/qemu/work/qemu-0.9.1/vl.c: At top level: >> /usr/ports/emulators/qemu/work/qemu-0.9.1/vl.c:1219: warning: 'qemu_next_deadline' defined but not used >> gmake[1]: *** [vl.o] Error 1 >> gmake[1]: Leaving directory `/usr/ports/emulators/qemu/work/qemu-0.9.1/i386-softmmu' >> gmake: *** [subdir-i386-softmmu] Error 2 >> *** Error code 2 > > Hmm. Was there more above that? Warnings alone shouldn't cause the > compiler to abort, if you see something like that happen its usually > another problem like the box running out of memory/swap... > > If its not that, maybe you can compare with a buildlog from pointyhat: > http://pointyhat.freebsd.org/errorlogs/amd64-8-latest-logs/qemu-0.9.1_9.log > > HTH, > Juergen -- Daichi GOTO, http://people.freebsd.org/~daichi From vova at fbsd.ru Tue Feb 10 00:58:24 2009 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Tue Feb 10 00:58:31 2009 Subject: [PATCH] futexes, flash9 related In-Reply-To: <20090208200541.GA59299@dchagin.static.corbina.ru> References: <20081221174939.GA33531@dchagin.dialup.corbina.ru> <747dc8f30902050220y7b1d726bj9f6f83afa843b520@mail.gmail.com> <20090206063550.GA2123@dchagin.static.corbina.ru> <1233919189.1866.13.camel@localhost> <20090206122354.GA5670@dchagin.static.corbina.ru> <1233923734.1866.33.camel@localhost> <20090208200541.GA59299@dchagin.static.corbina.ru> Message-ID: <1234256298.1659.45.camel@localhost> On Sun, 2009-02-08 at 23:05 +0300, Chagin Dmitry wrote: > please, try http://lnxx64.googlecode.com/files/futexes_partial_II.patch > first patch fail at i386... Works for me well enough so far (few hours), no more panics, flash play is not blocked yet. Thanks a lot. -- Vladimir B. Grebenschikov vova@fbsd.ru From gavin at FreeBSD.org Tue Feb 10 05:47:59 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Tue Feb 10 05:48:10 2009 Subject: kern/131506: pipes in forked procs sometimes hang under Linux emulation 2.6.16 Message-ID: <200902101347.n1ADlw96066449@freefall.freebsd.org> Synopsis: pipes in forked procs sometimes hang under Linux emulation 2.6.16 Responsible-Changed-From-To: freebsd-bugs->freebsd-emulation Responsible-Changed-By: gavin Responsible-Changed-When: Tue Feb 10 13:47:31 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=131506 From nwsadm at piekmarketing.eu Tue Feb 10 06:29:57 2009 From: nwsadm at piekmarketing.eu (Piek International Education Centre (I.E.C.)) Date: Tue Feb 10 06:30:48 2009 Subject: Newsletter PIEK International Education Center I.E.C. Message-ID: <4B7CBB7698A1426393BFD31A7693C31C@ZRE001> From dchagin at freebsd.org Tue Feb 10 08:41:17 2009 From: dchagin at freebsd.org (Chagin Dmitry) Date: Tue Feb 10 08:41:25 2009 Subject: [PATCH] futexes, flash9 related In-Reply-To: <1234256298.1659.45.camel@localhost> References: <20081221174939.GA33531@dchagin.dialup.corbina.ru> <747dc8f30902050220y7b1d726bj9f6f83afa843b520@mail.gmail.com> <20090206063550.GA2123@dchagin.static.corbina.ru> <1233919189.1866.13.camel@localhost> <20090206122354.GA5670@dchagin.static.corbina.ru> <1233923734.1866.33.camel@localhost> <20090208200541.GA59299@dchagin.static.corbina.ru> <1234256298.1659.45.camel@localhost> Message-ID: <20090210164107.GA9041@dchagin.static.corbina.ru> On Tue, Feb 10, 2009 at 11:58:18AM +0300, Vladimir Grebenschikov wrote: > On Sun, 2009-02-08 at 23:05 +0300, Chagin Dmitry wrote: > > > please, try http://lnxx64.googlecode.com/files/futexes_partial_II.patch > > first patch fail at i386... > > Works for me well enough so far (few hours), no more panics, flash play > is not blocked yet. > i386? Can you check the videos with heineken ads (in any order), I am on amd64, they usually fail. http://www.youtube.com/watch?v=3M8Dp7wGBe4&feature=related thnx! -- Have fun! chd From vova at fbsd.ru Tue Feb 10 08:57:12 2009 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Tue Feb 10 08:57:19 2009 Subject: [PATCH] futexes, flash9 related In-Reply-To: <20090210164107.GA9041@dchagin.static.corbina.ru> References: <20081221174939.GA33531@dchagin.dialup.corbina.ru> <747dc8f30902050220y7b1d726bj9f6f83afa843b520@mail.gmail.com> <20090206063550.GA2123@dchagin.static.corbina.ru> <1233919189.1866.13.camel@localhost> <20090206122354.GA5670@dchagin.static.corbina.ru> <1233923734.1866.33.camel@localhost> <20090208200541.GA59299@dchagin.static.corbina.ru> <1234256298.1659.45.camel@localhost> <20090210164107.GA9041@dchagin.static.corbina.ru> Message-ID: <1234285027.1659.95.camel@localhost> On Tue, 2009-02-10 at 19:41 +0300, Chagin Dmitry wrote: > i386? Can you check the videos with heineken ads (in any order), > I am on amd64, they usually fail. Hm, this one plays without problems for me. > http://www.youtube.com/watch?v=3M8Dp7wGBe4&feature=related -- Vladimir B. Grebenschikov vova@fbsd.ru From rbgarga at gmail.com Tue Feb 10 09:29:30 2009 From: rbgarga at gmail.com (Renato Botelho) Date: Tue Feb 10 09:29:36 2009 Subject: [PATCH] futexes, flash9 related In-Reply-To: <20090210164107.GA9041@dchagin.static.corbina.ru> References: <20081221174939.GA33531@dchagin.dialup.corbina.ru> <747dc8f30902050220y7b1d726bj9f6f83afa843b520@mail.gmail.com> <20090206063550.GA2123@dchagin.static.corbina.ru> <1233919189.1866.13.camel@localhost> <20090206122354.GA5670@dchagin.static.corbina.ru> <1233923734.1866.33.camel@localhost> <20090208200541.GA59299@dchagin.static.corbina.ru> <1234256298.1659.45.camel@localhost> <20090210164107.GA9041@dchagin.static.corbina.ru> Message-ID: <747dc8f30902100929m1310c9b7w728f9f316f4bfabf@mail.gmail.com> On Tue, Feb 10, 2009 at 2:41 PM, Chagin Dmitry wrote: > On Tue, Feb 10, 2009 at 11:58:18AM +0300, Vladimir Grebenschikov wrote: >> On Sun, 2009-02-08 at 23:05 +0300, Chagin Dmitry wrote: >> >> > please, try http://lnxx64.googlecode.com/files/futexes_partial_II.patch >> > first patch fail at i386... >> >> Works for me well enough so far (few hours), no more panics, flash play >> is not blocked yet. >> > > i386? Can you check the videos with heineken ads (in any order), > I am on amd64, they usually fail. > > http://www.youtube.com/watch?v=3M8Dp7wGBe4&feature=related I'm on 8.0-current i386, start to get some fails exporadically, and a strange thing, sometimes it open a flash content on a separate window, a window for npviewer.bin Anyway, it's better than before. Thanks. -- Renato Botelho From nox at jelal.kn-bremen.de Tue Feb 10 14:58:45 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Tue Feb 10 14:58:52 2009 Subject: emulators/qemu: build fail on current amd64 In-Reply-To: <4990EF3E.5090908@ongs.co.jp> References: <498A5F90.1030004@ongs.co.jp> <20090206214916.GA14653@saturn.kn-bremen.de> Message-ID: <200902102257.n1AMvF9v013733@saturn.kn-bremen.de> In article <4990EF3E.5090908@ongs.co.jp> you write: >After some days, I have tried to build qemu and kqemu with >latest amd64 current system, and I have gottten it success :) > >FYI, qemu works well but without kqemu. > ># /usr/local/etc/rc.d/kqemu start >kldload: can't load kqemu: Exec format error >/usr/local/etc/rc.d/kqemu: WARNING: kqemu module failed to load. ># Oh? Is there anything in dmesg, like a missing symbol? Or did you update your world/kernel after building kqemu? In that case you should rebuild your kqemu port... HTH, Juergen From daichi at ongs.co.jp Wed Feb 11 00:54:38 2009 From: daichi at ongs.co.jp (Daichi GOTO) Date: Wed Feb 11 00:54:45 2009 Subject: emulators/qemu: build fail on current amd64 In-Reply-To: <200902102257.n1AMvF9v013733@saturn.kn-bremen.de> References: <498A5F90.1030004@ongs.co.jp> <20090206214916.GA14653@saturn.kn-bremen.de> <200902102257.n1AMvF9v013733@saturn.kn-bremen.de> Message-ID: <4992924E.4090604@ongs.co.jp> Juergen Lock wrote: > In article <4990EF3E.5090908@ongs.co.jp> you write: >> After some days, I have tried to build qemu and kqemu with >> latest amd64 current system, and I have gottten it success :) >> >> FYI, qemu works well but without kqemu. >> >> # /usr/local/etc/rc.d/kqemu start >> kldload: can't load kqemu: Exec format error >> /usr/local/etc/rc.d/kqemu: WARNING: kqemu module failed to load. >> # > > Oh? Is there anything in dmesg, like a missing symbol? Or did you > update your world/kernel after building kqemu? In that case you should > rebuild your kqemu port... # uname -a FreeBSD parancell.ongs.co.jp 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Mon Feb 9 14:18:09 JST 2009 root@parancell.ongs.co.jp:/usr/obj/usr/src/sys/PARANCELL amd64 # dmesg (snip) link_elf_obj: symbol unit2minor undefined kldload: /boot/modules/kqemu.ko: Unsupported file type (snip) # After rebuild system and kernel, always I have rebuilt some applications depend on ABI of kernel/system useing included script ;-) > HTH, > Juergen -- Daichi GOTO, http://people.freebsd.org/~daichi -------------- next part -------------- #!/bin/sh export BATCH=YES portupgrade -f \ sysutils/hal \ emulators/kqemu-kmod \ x11/nvidia-driver \ www/linux-flashplugin9 \ sysutils/jfbterm do_post_jfbterm() { type jfbterm > /dev/null 2>&1 || return termcapfile=/usr/share/misc/termcap jfbtermtermcalfile=/usr/local/share/jfbterm/termcap.jfbterm jfbtermconffile=/usr/local/etc/jfbterm.conf jfbtermconfsamplefile=/usr/local/etc/jfbterm.conf.sample if [ -z "$(grep jfbterm ${termcapfile})" ] then echo cat '"'${jfbtermtermcalfile}'" >> "'${termcapfile}'"' cat "${jfbtermtermcalfile}" >> "${termcapfile}" echo cap_mkdb '"'${termcapfile}'"' cap_mkdb "${termcapfile}" fi if [ ! -f "${jfbtermconffile}" ] then echo cp '"'${jfbtermconfsamplefile}'" "'${jfbtermconffile}'"' cp "${jfbtermconfsamplefile}" "${jfbtermconffile}" fi } do_post_jfbterm From jhein at timing.com Wed Feb 11 02:54:40 2009 From: jhein at timing.com (John Hein) Date: Wed Feb 11 02:54:47 2009 Subject: emulators/qemu: build fail on current amd64 In-Reply-To: <4992924E.4090604@ongs.co.jp> References: <498A5F90.1030004@ongs.co.jp> <20090206214916.GA14653@saturn.kn-bremen.de> <200902102257.n1AMvF9v013733@saturn.kn-bremen.de> <4992924E.4090604@ongs.co.jp> Message-ID: <18834.42024.739091.493218@gromit.timing.com> Daichi GOTO wrote at 17:54 +0900 on Feb 11, 2009: > Juergen Lock wrote: > > In article <4990EF3E.5090908@ongs.co.jp> you write: > >> After some days, I have tried to build qemu and kqemu with > >> latest amd64 current system, and I have gottten it success :) > >> > >> FYI, qemu works well but without kqemu. > >> > >> # /usr/local/etc/rc.d/kqemu start > >> kldload: can't load kqemu: Exec format error > >> /usr/local/etc/rc.d/kqemu: WARNING: kqemu module failed to load. > >> # > > > > Oh? Is there anything in dmesg, like a missing symbol? Or did you > > update your world/kernel after building kqemu? In that case you should > > rebuild your kqemu port... > > # uname -a > FreeBSD parancell.ongs.co.jp 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Mon Feb 9 14:18:09 JST 2009 > root@parancell.ongs.co.jp:/usr/obj/usr/src/sys/PARANCELL amd64 > # dmesg > (snip) > link_elf_obj: symbol unit2minor undefined > kldload: /boot/modules/kqemu.ko: Unsupported file type > (snip) unit2minor was removed recently. See recent commit to sys/sys/conf.h Any in-tree drivers left that used unit2minor were fixed at the same time. For kqemu-kmod, try this... --- kqemu-1.3.0pre11/kqemu-freebsd.c.orig 2007-02-06 14:02:00.000000000 -0700 +++ kqemu-1.3.0pre11/kqemu-freebsd.c 2009-02-11 03:04:50.000000000 -0700 @@ -296,7 +296,11 @@ r = clone_create(&kqemuclones, &kqemu_cdevsw, &unit, dev, 0); if (r) { +#if __FreeBSD_version > 800061 + *dev = make_dev(&kqemu_cdevsw, unit, +#else *dev = make_dev(&kqemu_cdevsw, unit2minor(unit), +#endif UID_ROOT, GID_WHEEL, 0660, "kqemu%d", unit); if (*dev != NULL) { dev_ref(*dev); From daichi at ongs.co.jp Thu Feb 12 04:45:19 2009 From: daichi at ongs.co.jp (Daichi GOTO) Date: Thu Feb 12 04:45:26 2009 Subject: emulators/qemu: build fail on current amd64 In-Reply-To: <18834.42024.739091.493218@gromit.timing.com> References: <498A5F90.1030004@ongs.co.jp> <20090206214916.GA14653@saturn.kn-bremen.de> <200902102257.n1AMvF9v013733@saturn.kn-bremen.de> <4992924E.4090604@ongs.co.jp> <18834.42024.739091.493218@gromit.timing.com> Message-ID: <499419DC.1050102@ongs.co.jp> John Hein wrote: > Daichi GOTO wrote at 17:54 +0900 on Feb 11, 2009: > > Juergen Lock wrote: > > > In article <4990EF3E.5090908@ongs.co.jp> you write: > > >> After some days, I have tried to build qemu and kqemu with > > >> latest amd64 current system, and I have gottten it success :) > > >> > > >> FYI, qemu works well but without kqemu. > > >> > > >> # /usr/local/etc/rc.d/kqemu start > > >> kldload: can't load kqemu: Exec format error > > >> /usr/local/etc/rc.d/kqemu: WARNING: kqemu module failed to load. > > >> # > > > > > > Oh? Is there anything in dmesg, like a missing symbol? Or did you > > > update your world/kernel after building kqemu? In that case you should > > > rebuild your kqemu port... > > > > # uname -a > > FreeBSD parancell.ongs.co.jp 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Mon Feb 9 14:18:09 JST 2009 > > root@parancell.ongs.co.jp:/usr/obj/usr/src/sys/PARANCELL amd64 > > # dmesg > > (snip) > > link_elf_obj: symbol unit2minor undefined > > kldload: /boot/modules/kqemu.ko: Unsupported file type > > (snip) > > unit2minor was removed recently. > See recent commit to sys/sys/conf.h > Any in-tree drivers left that used unit2minor were fixed at the same time. > > For kqemu-kmod, try this... > > --- kqemu-1.3.0pre11/kqemu-freebsd.c.orig 2007-02-06 14:02:00.000000000 -0700 > +++ kqemu-1.3.0pre11/kqemu-freebsd.c 2009-02-11 03:04:50.000000000 -0700 > @@ -296,7 +296,11 @@ > > r = clone_create(&kqemuclones, &kqemu_cdevsw, &unit, dev, 0); > if (r) { > +#if __FreeBSD_version > 800061 > + *dev = make_dev(&kqemu_cdevsw, unit, > +#else > *dev = make_dev(&kqemu_cdevsw, unit2minor(unit), > +#endif > UID_ROOT, GID_WHEEL, 0660, "kqemu%d", unit); > if (*dev != NULL) { > dev_ref(*dev); Adove patch works well :) Now I can load kqemu and run qemu with it! I guess it should be under files dir of emulators/kqemu-kmod. And another problem comming X-( After startup WinXP on qemu+kqemu, at user logs in, qemu gets Segmentation fault. It looks like fails at the same point always. Any one have any ideas? Someone have the same situation? Thanks -- Daichi GOTO, http://people.freebsd.org/~daichi From nox at jelal.kn-bremen.de Thu Feb 12 10:20:31 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Thu Feb 12 10:20:39 2009 Subject: emulators/qemu: build fail on current amd64 In-Reply-To: <499419DC.1050102@ongs.co.jp> References: <498A5F90.1030004@ongs.co.jp> <20090206214916.GA14653@saturn.kn-bremen.de> <200902102257.n1AMvF9v013733@saturn.kn-bremen.de> <4992924E.4090604@ongs.co.jp> <18834.42024.739091.493218@gromit.timing.com> <499419DC.1050102@ongs.co.jp> Message-ID: <20090212181713.GA13229@saturn.kn-bremen.de> On Thu, Feb 12, 2009 at 09:45:16PM +0900, Daichi GOTO wrote: > John Hein wrote: >> Daichi GOTO wrote at 17:54 +0900 on Feb 11, 2009: >> > Juergen Lock wrote: >> > > In article <4990EF3E.5090908@ongs.co.jp> you write: >> > >> After some days, I have tried to build qemu and kqemu with >> > >> latest amd64 current system, and I have gottten it success :) >> > >> >> > >> FYI, qemu works well but without kqemu. >> > >> >> > >> # /usr/local/etc/rc.d/kqemu start >> > >> kldload: can't load kqemu: Exec format error >> > >> /usr/local/etc/rc.d/kqemu: WARNING: kqemu module failed to load. >> > >> # >> > > > > Oh? Is there anything in dmesg, like a missing symbol? Or did >> you >> > > update your world/kernel after building kqemu? In that case you should >> > > rebuild your kqemu port... >> > > # uname -a >> > FreeBSD parancell.ongs.co.jp 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Mon >> Feb 9 14:18:09 JST 2009 > >> root@parancell.ongs.co.jp:/usr/obj/usr/src/sys/PARANCELL amd64 >> > # dmesg >> > (snip) >> > link_elf_obj: symbol unit2minor undefined >> > kldload: /boot/modules/kqemu.ko: Unsupported file type >> > (snip) >> >> unit2minor was removed recently. >> See recent commit to sys/sys/conf.h >> Any in-tree drivers left that used unit2minor were fixed at the same time. >> >> For kqemu-kmod, try this... >> >> --- kqemu-1.3.0pre11/kqemu-freebsd.c.orig 2007-02-06 14:02:00.000000000 -0700 >> +++ kqemu-1.3.0pre11/kqemu-freebsd.c 2009-02-11 03:04:50.000000000 -0700 >> @@ -296,7 +296,11 @@ >> r = clone_create(&kqemuclones, &kqemu_cdevsw, &unit, dev, 0); >> if (r) { >> +#if __FreeBSD_version > 800061 >> + *dev = make_dev(&kqemu_cdevsw, unit, >> +#else >> *dev = make_dev(&kqemu_cdevsw, unit2minor(unit), >> +#endif >> UID_ROOT, GID_WHEEL, 0660, "kqemu%d", unit); >> if (*dev != NULL) { >> dev_ref(*dev); > > Adove patch works well :) Now I can load kqemu and run > qemu with it! I guess it should be under files dir of > emulators/kqemu-kmod. > Yeah I just committed ports/131603 which contains the same fix, just written a little different. > And another problem comming X-( > After startup WinXP on qemu+kqemu, at user logs in, > qemu gets Segmentation fault. It looks like fails > at the same point always. > Any one have any ideas? Someone have the same situation? A backtrace could be useful here, do something like gdb /usr/ports/emulators/qemu/work/qemu-0.9.1/i386-softmmu/qemu qemu.core and then in gdb `bt'. My crystal ball :) tells me you are using slirp on amd64 (-net user which is the default nat-kinda networking) and the guest may be trying to access the network when you login (slirp is unstable on 64 bit hosts in the qemu versions in ports which is also documented in the pkg-message.s) If its that you could either try using tuntap networking instead, or try qemu svn, a snapshot of which I posted a qemu-devel port update for here: http://lists.freebsd.org/pipermail/freebsd-emulation/2009-February/005650.html (qemu-devel uses the kqemu-kmod-devel port which CONFLICTS with kqemu-kmod, so if you are upgrading from qemu 0.9.1 pkg_delete the old kqemu first.) Good luck, Juergen From vova at fbsd.ru Thu Feb 12 21:55:47 2009 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Thu Feb 12 21:55:54 2009 Subject: [PATCH] futexes, flash9 related In-Reply-To: <20081221174939.GA33531@dchagin.dialup.corbina.ru> References: <20081221174939.GA33531@dchagin.dialup.corbina.ru> Message-ID: <1234504540.1631.44.camel@localhost> On Sun, 2008-12-21 at 20:49 +0300, Chagin Dmitry wrote: > /me ready to present patches for testing (nor review). Probably, Moonshine + Moonlight plugin also will work ? http://go-mono.com/moonlight/ http://abock.org/moonshine/ -- Vladimir B. Grebenschikov vova@fbsd.ru From netchild at FreeBSD.org Fri Feb 13 03:56:21 2009 From: netchild at FreeBSD.org (netchild@FreeBSD.org) Date: Fri Feb 13 03:56:27 2009 Subject: kern/131099: [linux] [patch] readdir broken on Linux emulation. Message-ID: <200902131156.n1DBuKCV026093@freefall.freebsd.org> Synopsis: [linux] [patch] readdir broken on Linux emulation. State-Changed-From-To: open->patched State-Changed-By: netchild State-Changed-When: Fri Feb 13 11:55:34 UTC 2009 State-Changed-Why: Patched in -current, MTS in about 2 weeks. http://www.freebsd.org/cgi/query-pr.cgi?pr=131099 From dfilter at FreeBSD.ORG Fri Feb 13 04:00:15 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Fri Feb 13 04:00:21 2009 Subject: kern/131099: commit references a PR Message-ID: <200902131200.n1DC0AZx026255@freefall.freebsd.org> The following reply was made to PR kern/131099; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/131099: commit references a PR Date: Fri, 13 Feb 2009 11:55:34 +0000 (UTC) Author: netchild Date: Fri Feb 13 11:55:19 2009 New Revision: 188572 URL: http://svn.freebsd.org/changeset/base/188572 Log: Fix an edge-case of the linux readdir: We need the size of a linux dirent structure, not the size of a pointer to it. PR: 131099 Submitted by: Andreas Kies MFC after: 2 weeks Modified: head/sys/compat/linux/linux_file.c Modified: head/sys/compat/linux/linux_file.c ============================================================================== --- head/sys/compat/linux/linux_file.c Fri Feb 13 11:36:32 2009 (r188571) +++ head/sys/compat/linux/linux_file.c Fri Feb 13 11:55:19 2009 (r188572) @@ -345,7 +345,7 @@ getdents_common(struct thread *td, struc /* readdir(2) case. Always struct dirent. */ if (is64bit) return (EINVAL); - nbytes = sizeof(linux_dirent); + nbytes = sizeof(*linux_dirent); justone = 1; } else justone = 0; _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From daichi at ongs.co.jp Fri Feb 13 17:14:12 2009 From: daichi at ongs.co.jp (Daichi GOTO) Date: Fri Feb 13 17:14:19 2009 Subject: emulators/qemu: build fail on current amd64 In-Reply-To: <20090212181713.GA13229@saturn.kn-bremen.de> References: <498A5F90.1030004@ongs.co.jp> <20090206214916.GA14653@saturn.kn-bremen.de> <200902102257.n1AMvF9v013733@saturn.kn-bremen.de> <4992924E.4090604@ongs.co.jp> <18834.42024.739091.493218@gromit.timing.com> <499419DC.1050102@ongs.co.jp> <20090212181713.GA13229@saturn.kn-bremen.de> Message-ID: <49961AE1.5080001@ongs.co.jp> Juergen Lock wrote: >> And another problem comming X-( >> After startup WinXP on qemu+kqemu, at user logs in, >> qemu gets Segmentation fault. It looks like fails >> at the same point always. >> Any one have any ideas? Someone have the same situation? > > A backtrace could be useful here, do something like > gdb /usr/ports/emulators/qemu/work/qemu-0.9.1/i386-softmmu/qemu qemu.core > and then in gdb `bt'. Exactly yes, slirp is cause of that. (gdb) bt #0 tcp_close (tp=0x802167f80) at slirp/tcp_subr.c:278 #1 0x000000000046d773 in tcp_input (m=0x80211b600, iphlen=8760, inso=0x0) at slirp/tcp_input.c:1260 #2 0x0000000000408bf1 in qemu_send_packet (vc1=0x8021377c0, buf=0x81b5e3876 "RT", size=60) at /usr/ports/emulators/qemu/work/qemu-0.9.1/vl.c:3747 #3 0x000000000041d618 in ne2000_ioport_write (opaque=0x81b5df228, addr=8760, val=4) at /usr/ports/emulators/qemu/work/qemu-0.9.1/hw/ne2000.c:347 #4 0x0000000001f14a0c in code_gen_buffer () #5 0x0000000000000000 in ?? () #6 0x0000000000488e6d in cpu_x86_exec (env1=0x802167f80) at /usr/ports/emulators/qemu/work/qemu-0.9.1/cpu-exec.c:679 #7 0x000000000040ef8c in main (argc=13, argv=0xc100) at /usr/ports/emulators/qemu/work/qemu-0.9.1/vl.c:7599 (gdb) > My crystal ball :) tells me you are using slirp on amd64 (-net user which > is the default nat-kinda networking) and the guest may be trying to access > the network when you login (slirp is unstable on 64 bit hosts in the qemu > versions in ports which is also documented in the pkg-message.s) If its > that you could either try using tuntap networking instead, or try qemu svn, > a snapshot of which I posted a qemu-devel port update for here: > http://lists.freebsd.org/pipermail/freebsd-emulation/2009-February/005650.html > (qemu-devel uses the kqemu-kmod-devel port which CONFLICTS with kqemu-kmod, > so if you are upgrading from qemu 0.9.1 pkg_delete the old kqemu first.) I have tried to use tap and bridge network, and qemu looks like well working ;-) From my reseach, current amd64 cannot destroy tap and and bridge interface, do "ifconfig tap0 destroy", "kldunload if_tap" or "ifconfig bridge0 destroy" leads system stop. So I have created attached script to use qemu with tap/bridge interface. Thanks > Good luck, > Juergen -- Daichi GOTO, http://people.freebsd.org/~daichi -------------- next part -------------- #!/bin/sh # default configuration nicname="re0" bridgename="bridge0" basedir="${HOME}/Library/qemu" debugmode="on" # debug mode case "${debugmode}" in off) ulimit -c 0 esac # setting up bridge network if ! ifconfig "${bridgename}" > /dev/null 2>&1 then ifconfig "${bridgename}" create ifconfig "${bridgename}" addm "${nicname}" up fi # setting up tap interface for target in $(ls /dev/ | grep -E "^tap[0-9]") do case "$(fstat /dev/"${target}" | wc -l | awk '{print $1}')" in 1) tapname="${target}" ifconfig "${tapname}" up ifconfig "${bridgename}" addm "${tapname}" break ;; esac done if [ -z "${tapname}" ] then tapname=$(ifconfig tap create) ifconfig "${tapname}" up ifconfig "${bridgename}" addm "${tapname}" fi # start up qemu qemu \ -net nic -net tap,ifname="${tapname}" \ -localtime \ -m 1024 \ -soundhw es1370 \ -usb -usbdevice tablet \ -hda ${basedir}/DISK0_YOURDISK_HERE \ -hdb ${basedir}/DISK1_YOURDISK_HERE # free tap interface ifconfig "${bridgename}" deletem "${tapname}" From agent59624285 at spamcorptastic.com Sat Feb 14 19:00:45 2009 From: agent59624285 at spamcorptastic.com (agent59624285) Date: Sat Feb 14 19:00:52 2009 Subject: linux_base-fc4 In-Reply-To: <02067965@ipt.ru> References: <02067965@ipt.ru> Message-ID: <22019307.post@talk.nabble.com> Boris Samorodov wrote: > > On Sun, 16 Nov 2008 21:58:58 +0100 cyrill62 wrote: > > It is available at: > http://archives.fedoraproject.org/pub/archive/fedora/linux/core/updates/4/i386/ > >> Can you update the package 'emulators/linux_base-fc4' ? > It would be nice if the port would try to download it there. -- View this message in context: http://www.nabble.com/linux_base-fc4-tp20530308p22019307.html Sent from the freebsd-emulation mailing list archive at Nabble.com. From bsam at ipt.ru Sun Feb 15 03:19:56 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Sun Feb 15 03:20:03 2009 Subject: linux_base-fc4 In-Reply-To: <22019307.post@talk.nabble.com> (agent's message of "Sat\, 14 Feb 2009 18\:45\:29 -0800 \(PST\)") References: <02067965@ipt.ru> <22019307.post@talk.nabble.com> Message-ID: <00886262@bs1.sp34.ru> agent59624285 writes: > Boris Samorodov wrote: >> >> On Sun, 16 Nov 2008 21:58:58 +0100 cyrill62 wrote: >> >> It is available at: >> http://archives.fedoraproject.org/pub/archive/fedora/linux/core/updates/4/i386/ >> >>> Can you update the package 'emulators/linux_base-fc4' ? > > It would be nice if the port would try to download it there. What do you want to download where? Anyway this package is a part of linux_base-fc4 since it's introduction, i.e. 2 years and 8 months. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From rdivacky at freebsd.org Sun Feb 15 14:05:15 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Sun Feb 15 14:05:22 2009 Subject: qemu booting amd64 fbsd Message-ID: <20090215214304.GA17635@freebsd.org> hi I am trying to boot fbsd@amd64 7.1R in qemu-0.9.1_11 but it panics early in the boot. usually. sometimes it gets upto the root mounting but then hangs... am I doing something wrong or is this just broken? is there any other (reliable) way how to boot amd64 fbsd in sw? thnx! roman From kostikbel at gmail.com Mon Feb 16 01:50:36 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon Feb 16 01:50:42 2009 Subject: qemu booting amd64 fbsd In-Reply-To: <20090215214304.GA17635@freebsd.org> References: <20090215214304.GA17635@freebsd.org> Message-ID: <20090216091141.GD41617@deviant.kiev.zoral.com.ua> On Sun, Feb 15, 2009 at 10:43:04PM +0100, Roman Divacky wrote: > hi > > I am trying to boot fbsd@amd64 7.1R in qemu-0.9.1_11 but it panics > early in the boot. usually. sometimes it gets upto the root mounting > but then hangs... > > am I doing something wrong or is this just broken? > > is there any other (reliable) way how to boot amd64 fbsd in sw? I use the patch below for the long time. Not sure whether this is your case. --- cpu-exec.c.orig 2008-02-16 18:23:53.134009488 +0200 +++ cpu-exec.c 2008-02-16 18:24:47.127662872 +0200 @@ -452,13 +452,15 @@ svm_check_intercept(SVM_EXIT_INTR); env->interrupt_request &= ~(CPU_INTERRUPT_HARD | CPU_INTERRUPT_VIRQ); intno = cpu_get_pic_interrupt(env); - if (loglevel & CPU_LOG_TB_IN_ASM) { - fprintf(logfile, "Servicing hardware INT=0x%02x\n", intno); - } - do_interrupt(intno, 0, 0, 0, 1); - /* ensure that no TB jump will be modified as - the program flow was changed */ - BREAK_CHAIN; + if (intno != -1) { + if (loglevel & CPU_LOG_TB_IN_ASM) { + fprintf(logfile, "Servicing hardware INT=0x%02x\n", intno); + } + do_interrupt(intno, 0, 0, 0, 1); + /* ensure that no TB jump will be modified as + the program flow was changed */ + BREAK_CHAIN; + } #if !defined(CONFIG_USER_ONLY) } else if ((interrupt_request & CPU_INTERRUPT_VIRQ) && (env->eflags & IF_MASK) && !(env->hflags & HF_INHIBIT_IRQ_MASK)) { -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20090216/7874acc9/attachment.pgp From bugmaster at FreeBSD.org Mon Feb 16 03:06:50 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Feb 16 03:07:41 2009 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org Message-ID: <200902161106.n1GB6nkX096082@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/131506 emulation [linux] pipes in forked procs sometimes hang under Lin p kern/131099 emulation [linux] [patch] readdir broken on Linux emulation. o kern/130724 emulation [linprocfs] [patch] cpuinfo in linprocfs is dated, cau o kern/129169 emulation [linux] [patch] Linux Emulation ENOTCONN error using n f ports/127018 emulation Linuxulator incapable of using FreeBSD's LDAP environm o kern/126232 emulation [linux] Linux ioctl TCGETS (0x5401) always fails o ports/121800 emulation x11-toolkits/linux-openmotif - OpenMotif upgrade to 2. o kern/97326 emulation [linux] file descriptor leakage in linux emulation o ports/91318 emulation [fix] graphics/linux_dri: works on amd64 too o kern/91293 emulation [svr4] [patch] *Experimental* Update to the SVR4 emula o kern/73777 emulation [linux] [patch] linux emulation: root dir special hand a kern/72920 emulation [linux]: path "prefixing" is not done on unix domain s o kern/41543 emulation [patch] [request] easier wine/w23 support o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/29698 emulation [linux] [patch] linux ipcs doesn'work o kern/21463 emulation [linux] Linux compatability mode should not allow setu o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 17 problems total. From rdivacky at freebsd.org Mon Feb 16 10:18:42 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Mon Feb 16 10:18:49 2009 Subject: qemu booting amd64 fbsd In-Reply-To: <20090216091141.GD41617@deviant.kiev.zoral.com.ua> References: <20090215214304.GA17635@freebsd.org> <20090216091141.GD41617@deviant.kiev.zoral.com.ua> Message-ID: <20090216181539.GA18949@freebsd.org> On Mon, Feb 16, 2009 at 11:11:41AM +0200, Kostik Belousov wrote: > On Sun, Feb 15, 2009 at 10:43:04PM +0100, Roman Divacky wrote: > > hi > > > > I am trying to boot fbsd@amd64 7.1R in qemu-0.9.1_11 but it panics > > early in the boot. usually. sometimes it gets upto the root mounting > > but then hangs... > > > > am I doing something wrong or is this just broken? > > > > is there any other (reliable) way how to boot amd64 fbsd in sw? > > I use the patch below for the long time. Not sure whether this is your > case. qemu-devel works ok... thnx! From nox at jelal.kn-bremen.de Mon Feb 16 16:23:21 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Mon Feb 16 16:23:28 2009 Subject: qemu booting amd64 fbsd In-Reply-To: <20090216091141.GD41617@deviant.kiev.zoral.com.ua> References: <20090215214304.GA17635@freebsd.org> <20090216091141.GD41617@deviant.kiev.zoral.com.ua> Message-ID: <20090217002152.GA12435@saturn.kn-bremen.de> On Mon, Feb 16, 2009 at 11:11:41AM +0200, Kostik Belousov wrote: > On Sun, Feb 15, 2009 at 10:43:04PM +0100, Roman Divacky wrote: > > hi > > > > I am trying to boot fbsd@amd64 7.1R in qemu-0.9.1_11 but it panics > > early in the boot. usually. sometimes it gets upto the root mounting > > but then hangs... > > > > am I doing something wrong or is this just broken? > > > > is there any other (reliable) way how to boot amd64 fbsd in sw? > > I use the patch below for the long time. Not sure whether this is your > case. > > --- cpu-exec.c.orig 2008-02-16 18:23:53.134009488 +0200 > +++ cpu-exec.c 2008-02-16 18:24:47.127662872 +0200 > @@ -452,13 +452,15 @@ >[...] ..or you can try the qemu-devel port which has that patch. Also, at least -kernel-kqemu still is broken for FreeBSD/amd64 guests, even with qemu svn (which no longer needs that patch), see this post if you want to try my latest snapshot: http://lists.freebsd.org/pipermail/freebsd-emulation/2009-February/005650.html Oh and btw there just have been reports of image corruption with qcow(2) images in qemu svn, so better use raw images for now... (they're faster anyway.) HTH, Juergen From subhraveti at gmail.com Mon Feb 16 21:14:49 2009 From: subhraveti at gmail.com (Dinesh Subhraveti) Date: Mon Feb 16 21:14:55 2009 Subject: qemu bsd-user Message-ID: <00a201c990ba$078763c0$8301a8c0@DineshThinkpad> This may not be the right place for a newbie question, but venturing anyway with some hope... I am interested in the Qemu bsd user emulation, but can't find a copy of Qemu source with bsd-user that I can build. The mainline Qemu trunk doesn't directly build on FreeBSD and the qemu ports in /usr/ports/emulators/ don't have bsd-user. Any responses greatly appreciated. Regards, From nox at jelal.kn-bremen.de Tue Feb 17 14:58:52 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Tue Feb 17 14:58:59 2009 Subject: qemu bsd-user In-Reply-To: <00a201c990ba$078763c0$8301a8c0@DineshThinkpad> References: <00a201c990ba$078763c0$8301a8c0@DineshThinkpad> Message-ID: <20090217225655.GA12991@saturn.kn-bremen.de> On Mon, Feb 16, 2009 at 08:41:40PM -0800, "Dinesh Subhraveti" wrote: > This may not be the right place for a newbie question, but venturing anyway with some hope... > > I am interested in the Qemu bsd user emulation, but can't find a copy of Qemu source with bsd-user that I can build. The mainline Qemu trunk doesn't directly build on FreeBSD and the qemu ports in /usr/ports/emulators/ don't have bsd-user. Well, I got bsd-user to build a while ago, http://lists.freebsd.org/pipermail/freebsd-emulation/2008-December/005579.html (it still builds in my latest snapshot, http://lists.freebsd.org/pipermail/freebsd-emulation/2009-February/005650.html ) but it is entirely untested, and as said in the first post it looks like at least the i386 (host) case needs someone with linker script fu to look at it before it can actually work. If you want to help you are more than welcome tho... :) (you are actually the first one to ask about bsd-user on FreeBSD that I have seen!) Good luck, Juergen From takahiro.kurosawa at gmail.com Wed Feb 18 05:20:02 2009 From: takahiro.kurosawa at gmail.com (Takahiro Kurosawa) Date: Wed Feb 18 05:20:09 2009 Subject: kern/131506: pipes in forked procs sometimes hang under Linux emulation 2.6.16 Message-ID: <200902181320.n1IDK2Zh024098@freefall.freebsd.org> The following reply was made to PR kern/131506; it has been noted by GNATS. From: Takahiro Kurosawa To: bug-followup@freebsd.org, arno@heho.snv.jussieu.fr Cc: Subject: Re: kern/131506: pipes in forked procs sometimes hang under Linux emulation 2.6.16 Date: Wed, 18 Feb 2009 21:44:13 +0900 --000e0cd156a4ef843b046330c6a5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit (resending to bug-followup@, sorry if duplicate) It seems that vfork/exec synchronization was changed recently but the linux emulation code keeps using the obsolete mechanism. The attached patch may fix the problem. --000e0cd156a4ef843b046330c6a5 Content-Type: text/x-diff; charset=US-ASCII; name="pwaitfix.diff" Content-Disposition: attachment; filename="pwaitfix.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_frapwkae0 PT09IHN5cy9hbWQ2NC9saW51eDMyL2xpbnV4MzJfbWFjaGRlcC5jCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lz L2FtZDY0L2xpbnV4MzIvbGludXgzMl9tYWNoZGVwLmMJKHJldmlzaW9uIDE4ODc0MSkKKysrIHN5 cy9hbWQ2NC9saW51eDMyL2xpbnV4MzJfbWFjaGRlcC5jCShsb2NhbCkKQEAgLTU2MCw3ICs1NjAs NyBAQAogCS8qIHdhaXQgZm9yIHRoZSBjaGlsZHJlbiB0byBleGl0LCBpZS4gZW11bGF0ZSB2Zm9y ayAqLwogCVBST0NfTE9DSyhwMik7CiAJd2hpbGUgKHAyLT5wX2ZsYWcgJiBQX1BQV0FJVCkKLQkg ICAJbXNsZWVwKHRkLT50ZF9wcm9jLCAmcDItPnBfbXR4LCBQV0FJVCwgInBwd2FpdCIsIDApOwor CQljdl93YWl0KCZwMi0+cF9wd2FpdCwgJnAyLT5wX210eCk7CiAJUFJPQ19VTkxPQ0socDIpOwog CiAJcmV0dXJuICgwKTsKQEAgLTc0OSw3ICs3NDksNyBAQAogCQkvKiB3YWl0IGZvciB0aGUgY2hp bGRyZW4gdG8gZXhpdCwgaWUuIGVtdWxhdGUgdmZvcmsgKi8KIAkJUFJPQ19MT0NLKHAyKTsKIAkJ d2hpbGUgKHAyLT5wX2ZsYWcgJiBQX1BQV0FJVCkKLQkJCW1zbGVlcCh0ZC0+dGRfcHJvYywgJnAy LT5wX210eCwgUFdBSVQsICJwcHdhaXQiLCAwKTsKKwkJCWN2X3dhaXQoJnAyLT5wX3B3YWl0LCAm cDItPnBfbXR4KTsKIAkJUFJPQ19VTkxPQ0socDIpOwogCX0KIAo9PT0gc3lzL2kzODYvbGludXgv bGludXhfbWFjaGRlcC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2kzODYvbGludXgvbGludXhfbWFjaGRl cC5jCShyZXZpc2lvbiAxODg3NDEpCisrKyBzeXMvaTM4Ni9saW51eC9saW51eF9tYWNoZGVwLmMJ KGxvY2FsKQpAQCAtMzc2LDcgKzM3Niw3IEBACiAJLyogd2FpdCBmb3IgdGhlIGNoaWxkcmVuIHRv IGV4aXQsIGllLiBlbXVsYXRlIHZmb3JrICovCiAJUFJPQ19MT0NLKHAyKTsKIAl3aGlsZSAocDIt PnBfZmxhZyAmIFBfUFBXQUlUKQotCSAgIAltc2xlZXAodGQtPnRkX3Byb2MsICZwMi0+cF9tdHgs IFBXQUlULCAicHB3YWl0IiwgMCk7CisJCWN2X3dhaXQoJnAyLT5wX3B3YWl0LCAmcDItPnBfbXR4 KTsKIAlQUk9DX1VOTE9DSyhwMik7CiAKIAlyZXR1cm4gKDApOwpAQCAtNTgxLDcgKzU4MSw3IEBA CiAgICAJICAgCS8qIHdhaXQgZm9yIHRoZSBjaGlsZHJlbiB0byBleGl0LCBpZS4gZW11bGF0ZSB2 Zm9yayAqLwogICAgCSAgIAlQUk9DX0xPQ0socDIpOwogCQl3aGlsZSAocDItPnBfZmxhZyAmIFBf UFBXQUlUKQotICAgCQkgICAJbXNsZWVwKHRkLT50ZF9wcm9jLCAmcDItPnBfbXR4LCBQV0FJVCwg InBwd2FpdCIsIDApOworCQkJY3Zfd2FpdCgmcDItPnBfcHdhaXQsICZwMi0+cF9tdHgpOwogCQlQ Uk9DX1VOTE9DSyhwMik7CiAJfQogCg== --000e0cd156a4ef843b046330c6a5-- From kostikbel at gmail.com Wed Feb 18 05:34:55 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Feb 18 05:35:03 2009 Subject: kern/131506: pipes in forked procs sometimes hang under Linux emulation 2.6.16 In-Reply-To: <200902181320.n1IDK2Zh024098@freefall.freebsd.org> References: <200902181320.n1IDK2Zh024098@freefall.freebsd.org> Message-ID: <20090218133448.GP41617@deviant.kiev.zoral.com.ua> On Wed, Feb 18, 2009 at 01:20:02PM +0000, Takahiro Kurosawa wrote: > The following reply was made to PR kern/131506; it has been noted by GNATS. > > From: Takahiro Kurosawa > To: bug-followup@freebsd.org, arno@heho.snv.jussieu.fr > Cc: > Subject: Re: kern/131506: pipes in forked procs sometimes hang under Linux > emulation 2.6.16 > Date: Wed, 18 Feb 2009 21:44:13 +0900 > > --000e0cd156a4ef843b046330c6a5 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > > (resending to bug-followup@, sorry if duplicate) > > It seems that vfork/exec synchronization was changed recently > but the linux emulation code keeps using the obsolete mechanism. > > The attached patch may fix the problem. > > --000e0cd156a4ef843b046330c6a5 > Content-Type: text/x-diff; charset=US-ASCII; name="pwaitfix.diff" > Content-Disposition: attachment; filename="pwaitfix.diff" > Content-Transfer-Encoding: base64 > X-Attachment-Id: f_frapwkae0 > > PT09IHN5cy9hbWQ2NC9saW51eDMyL2xpbnV4MzJfbWFjaGRlcC5jCj09PT09PT09PT09PT09PT09 > PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lz > L2FtZDY0L2xpbnV4MzIvbGludXgzMl9tYWNoZGVwLmMJKHJldmlzaW9uIDE4ODc0MSkKKysrIHN5 > cy9hbWQ2NC9saW51eDMyL2xpbnV4MzJfbWFjaGRlcC5jCShsb2NhbCkKQEAgLTU2MCw3ICs1NjAs > NyBAQAogCS8qIHdhaXQgZm9yIHRoZSBjaGlsZHJlbiB0byBleGl0LCBpZS4gZW11bGF0ZSB2Zm9y > ayAqLwogCVBST0NfTE9DSyhwMik7CiAJd2hpbGUgKHAyLT5wX2ZsYWcgJiBQX1BQV0FJVCkKLQkg > ICAJbXNsZWVwKHRkLT50ZF9wcm9jLCAmcDItPnBfbXR4LCBQV0FJVCwgInBwd2FpdCIsIDApOwor > CQljdl93YWl0KCZwMi0+cF9wd2FpdCwgJnAyLT5wX210eCk7CiAJUFJPQ19VTkxPQ0socDIpOwog > CiAJcmV0dXJuICgwKTsKQEAgLTc0OSw3ICs3NDksNyBAQAogCQkvKiB3YWl0IGZvciB0aGUgY2hp > bGRyZW4gdG8gZXhpdCwgaWUuIGVtdWxhdGUgdmZvcmsgKi8KIAkJUFJPQ19MT0NLKHAyKTsKIAkJ > d2hpbGUgKHAyLT5wX2ZsYWcgJiBQX1BQV0FJVCkKLQkJCW1zbGVlcCh0ZC0+dGRfcHJvYywgJnAy > LT5wX210eCwgUFdBSVQsICJwcHdhaXQiLCAwKTsKKwkJCWN2X3dhaXQoJnAyLT5wX3B3YWl0LCAm > cDItPnBfbXR4KTsKIAkJUFJPQ19VTkxPQ0socDIpOwogCX0KIAo9PT0gc3lzL2kzODYvbGludXgv > bGludXhfbWFjaGRlcC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 > PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2kzODYvbGludXgvbGludXhfbWFjaGRl > cC5jCShyZXZpc2lvbiAxODg3NDEpCisrKyBzeXMvaTM4Ni9saW51eC9saW51eF9tYWNoZGVwLmMJ > KGxvY2FsKQpAQCAtMzc2LDcgKzM3Niw3IEBACiAJLyogd2FpdCBmb3IgdGhlIGNoaWxkcmVuIHRv > IGV4aXQsIGllLiBlbXVsYXRlIHZmb3JrICovCiAJUFJPQ19MT0NLKHAyKTsKIAl3aGlsZSAocDIt > PnBfZmxhZyAmIFBfUFBXQUlUKQotCSAgIAltc2xlZXAodGQtPnRkX3Byb2MsICZwMi0+cF9tdHgs > IFBXQUlULCAicHB3YWl0IiwgMCk7CisJCWN2X3dhaXQoJnAyLT5wX3B3YWl0LCAmcDItPnBfbXR4 > KTsKIAlQUk9DX1VOTE9DSyhwMik7CiAKIAlyZXR1cm4gKDApOwpAQCAtNTgxLDcgKzU4MSw3IEBA > CiAgICAJICAgCS8qIHdhaXQgZm9yIHRoZSBjaGlsZHJlbiB0byBleGl0LCBpZS4gZW11bGF0ZSB2 > Zm9yayAqLwogICAgCSAgIAlQUk9DX0xPQ0socDIpOwogCQl3aGlsZSAocDItPnBfZmxhZyAmIFBf > UFBXQUlUKQotICAgCQkgICAJbXNsZWVwKHRkLT50ZF9wcm9jLCAmcDItPnBfbXR4LCBQV0FJVCwg > InBwd2FpdCIsIDApOworCQkJY3Zfd2FpdCgmcDItPnBfcHdhaXQsICZwMi0+cF9tdHgpOwogCQlQ > Uk9DX1VOTE9DSyhwMik7CiAJfQogCg== > --000e0cd156a4ef843b046330c6a5-- Please, resend the patch without base64-encoding, best as a plain/text attachment. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20090218/400a8e75/attachment.pgp From takahiro.kurosawa at gmail.com Wed Feb 18 06:10:05 2009 From: takahiro.kurosawa at gmail.com (Takahiro Kurosawa) Date: Wed Feb 18 06:10:11 2009 Subject: kern/131506: pipes in forked procs sometimes hang under Linux emulation 2.6.16 Message-ID: <200902181410.n1IEA5Vq060807@freefall.freebsd.org> The following reply was made to PR kern/131506; it has been noted by GNATS. From: Takahiro Kurosawa To: Kostik Belousov Cc: bug-followup@freebsd.org Subject: Re: kern/131506: pipes in forked procs sometimes hang under Linux emulation 2.6.16 Date: Wed, 18 Feb 2009 23:08:05 +0900 2009/2/18 Kostik Belousov : > Please, resend the patch without base64-encoding, best as a plain/text > attachment. Sure. Sending the patch inline... The attachment of my previous mail looks broken to me too. === sys/amd64/linux32/linux32_machdep.c ================================================================== --- sys/amd64/linux32/linux32_machdep.c (revision 188741) +++ sys/amd64/linux32/linux32_machdep.c (local) @@ -560,7 +560,7 @@ /* wait for the children to exit, ie. emulate vfork */ PROC_LOCK(p2); while (p2->p_flag & P_PPWAIT) - msleep(td->td_proc, &p2->p_mtx, PWAIT, "ppwait", 0); + cv_wait(&p2->p_pwait, &p2->p_mtx); PROC_UNLOCK(p2); return (0); @@ -749,7 +749,7 @@ /* wait for the children to exit, ie. emulate vfork */ PROC_LOCK(p2); while (p2->p_flag & P_PPWAIT) - msleep(td->td_proc, &p2->p_mtx, PWAIT, "ppwait", 0); + cv_wait(&p2->p_pwait, &p2->p_mtx); PROC_UNLOCK(p2); } === sys/i386/linux/linux_machdep.c ================================================================== --- sys/i386/linux/linux_machdep.c (revision 188741) +++ sys/i386/linux/linux_machdep.c (local) @@ -376,7 +376,7 @@ /* wait for the children to exit, ie. emulate vfork */ PROC_LOCK(p2); while (p2->p_flag & P_PPWAIT) - msleep(td->td_proc, &p2->p_mtx, PWAIT, "ppwait", 0); + cv_wait(&p2->p_pwait, &p2->p_mtx); PROC_UNLOCK(p2); return (0); @@ -581,7 +581,7 @@ /* wait for the children to exit, ie. emulate vfork */ PROC_LOCK(p2); while (p2->p_flag & P_PPWAIT) - msleep(td->td_proc, &p2->p_mtx, PWAIT, "ppwait", 0); + cv_wait(&p2->p_pwait, &p2->p_mtx); PROC_UNLOCK(p2); } From rdivacky at FreeBSD.org Wed Feb 18 06:12:40 2009 From: rdivacky at FreeBSD.org (Roman Divacky) Date: Wed Feb 18 06:12:47 2009 Subject: kern/131506: pipes in forked procs sometimes hang under Linux emulation 2.6.16 In-Reply-To: <200902181410.n1IEA5Vq060807@freefall.freebsd.org> References: <200902181410.n1IEA5Vq060807@freefall.freebsd.org> Message-ID: <20090218140936.GA52973@freebsd.org> On Wed, Feb 18, 2009 at 02:10:05PM +0000, Takahiro Kurosawa wrote: > The following reply was made to PR kern/131506; it has been noted by GNATS. > > From: Takahiro Kurosawa > To: Kostik Belousov > Cc: bug-followup@freebsd.org > Subject: Re: kern/131506: pipes in forked procs sometimes hang under Linux > emulation 2.6.16 > Date: Wed, 18 Feb 2009 23:08:05 +0900 > > 2009/2/18 Kostik Belousov : > > > Please, resend the patch without base64-encoding, best as a plain/text > > attachment. > > Sure. Sending the patch inline... > The attachment of my previous mail looks broken to me too. > > === sys/amd64/linux32/linux32_machdep.c > ================================================================== > --- sys/amd64/linux32/linux32_machdep.c (revision 188741) > +++ sys/amd64/linux32/linux32_machdep.c (local) > @@ -560,7 +560,7 @@ > /* wait for the children to exit, ie. emulate vfork */ > PROC_LOCK(p2); > while (p2->p_flag & P_PPWAIT) > - msleep(td->td_proc, &p2->p_mtx, PWAIT, "ppwait", 0); > + cv_wait(&p2->p_pwait, &p2->p_mtx); > PROC_UNLOCK(p2); > > return (0); > @@ -749,7 +749,7 @@ > /* wait for the children to exit, ie. emulate vfork */ > PROC_LOCK(p2); > while (p2->p_flag & P_PPWAIT) > - msleep(td->td_proc, &p2->p_mtx, PWAIT, "ppwait", 0); > + cv_wait(&p2->p_pwait, &p2->p_mtx); > PROC_UNLOCK(p2); > } > > === sys/i386/linux/linux_machdep.c > ================================================================== > --- sys/i386/linux/linux_machdep.c (revision 188741) > +++ sys/i386/linux/linux_machdep.c (local) > @@ -376,7 +376,7 @@ > /* wait for the children to exit, ie. emulate vfork */ > PROC_LOCK(p2); > while (p2->p_flag & P_PPWAIT) > - msleep(td->td_proc, &p2->p_mtx, PWAIT, "ppwait", 0); > + cv_wait(&p2->p_pwait, &p2->p_mtx); > PROC_UNLOCK(p2); > > return (0); > @@ -581,7 +581,7 @@ > /* wait for the children to exit, ie. emulate vfork */ > PROC_LOCK(p2); > while (p2->p_flag & P_PPWAIT) > - msleep(td->td_proc, &p2->p_mtx, PWAIT, "ppwait", 0); > + cv_wait(&p2->p_pwait, &p2->p_mtx); > PROC_UNLOCK(p2); > } looks correct to me... fork1() indeed uses cv_wait() instead of msleep(). it should be changed to cv_wait From kib at FreeBSD.org Wed Feb 18 08:13:06 2009 From: kib at FreeBSD.org (kib@FreeBSD.org) Date: Wed Feb 18 08:13:12 2009 Subject: kern/131506: [linux] pipes in forked procs sometimes hang under Linux emulation 2.6.16 Message-ID: <200902181613.n1IGD51v057606@freefall.freebsd.org> Synopsis: [linux] pipes in forked procs sometimes hang under Linux emulation 2.6.16 State-Changed-From-To: open->closed State-Changed-By: kib State-Changed-When: Wed Feb 18 16:12:45 UTC 2009 State-Changed-Why: Patch committed, thanks. http://www.freebsd.org/cgi/query-pr.cgi?pr=131506 From dfilter at FreeBSD.ORG Wed Feb 18 08:20:05 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Wed Feb 18 08:20:12 2009 Subject: kern/131506: commit references a PR Message-ID: <200902181620.n1IGK4oI058962@freefall.freebsd.org> The following reply was made to PR kern/131506; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/131506: commit references a PR Date: Wed, 18 Feb 2009 16:11:52 +0000 (UTC) Author: kib Date: Wed Feb 18 16:11:39 2009 New Revision: 188750 URL: http://svn.freebsd.org/changeset/base/188750 Log: Adapt linux emulation to use cv for vfork wait. Submitted by: Takahiro Kurosawa PR: kern/131506 Modified: head/sys/amd64/linux32/linux32_machdep.c head/sys/i386/linux/linux_machdep.c Modified: head/sys/amd64/linux32/linux32_machdep.c ============================================================================== --- head/sys/amd64/linux32/linux32_machdep.c Wed Feb 18 10:02:32 2009 (r188749) +++ head/sys/amd64/linux32/linux32_machdep.c Wed Feb 18 16:11:39 2009 (r188750) @@ -560,7 +560,7 @@ linux_vfork(struct thread *td, struct li /* wait for the children to exit, ie. emulate vfork */ PROC_LOCK(p2); while (p2->p_flag & P_PPWAIT) - msleep(td->td_proc, &p2->p_mtx, PWAIT, "ppwait", 0); + cv_wait(&p2->p_pwait, &p2->p_mtx); PROC_UNLOCK(p2); return (0); @@ -749,7 +749,7 @@ linux_clone(struct thread *td, struct li /* wait for the children to exit, ie. emulate vfork */ PROC_LOCK(p2); while (p2->p_flag & P_PPWAIT) - msleep(td->td_proc, &p2->p_mtx, PWAIT, "ppwait", 0); + cv_wait(&p2->p_pwait, &p2->p_mtx); PROC_UNLOCK(p2); } Modified: head/sys/i386/linux/linux_machdep.c ============================================================================== --- head/sys/i386/linux/linux_machdep.c Wed Feb 18 10:02:32 2009 (r188749) +++ head/sys/i386/linux/linux_machdep.c Wed Feb 18 16:11:39 2009 (r188750) @@ -376,7 +376,7 @@ linux_vfork(struct thread *td, struct li /* wait for the children to exit, ie. emulate vfork */ PROC_LOCK(p2); while (p2->p_flag & P_PPWAIT) - msleep(td->td_proc, &p2->p_mtx, PWAIT, "ppwait", 0); + cv_wait(&p2->p_pwait, &p2->p_mtx); PROC_UNLOCK(p2); return (0); @@ -581,7 +581,7 @@ linux_clone(struct thread *td, struct li /* wait for the children to exit, ie. emulate vfork */ PROC_LOCK(p2); while (p2->p_flag & P_PPWAIT) - msleep(td->td_proc, &p2->p_mtx, PWAIT, "ppwait", 0); + cv_wait(&p2->p_pwait, &p2->p_mtx); PROC_UNLOCK(p2); } _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From subhraveti at gmail.com Wed Feb 18 11:04:23 2009 From: subhraveti at gmail.com (Dinesh Subhraveti) Date: Wed Feb 18 11:04:29 2009 Subject: qemu bsd-user References: <00a201c990ba$078763c0$8301a8c0@DineshThinkpad> <20090217225655.GA12991@saturn.kn-bremen.de> Message-ID: <00d001c991fb$b2582630$8301a8c0@DineshThinkpad> > On Mon, Feb 16, 2009 at 08:41:40PM -0800, "Dinesh Subhraveti" wrote: >> This may not be the right place for a newbie question, but venturing >> anyway with some hope... >> >> I am interested in the Qemu bsd user emulation, but can't find a copy of >> Qemu source with bsd-user that I can build. The mainline Qemu trunk >> doesn't directly build on FreeBSD and the qemu ports in >> /usr/ports/emulators/ don't have bsd-user. > > Well, I got bsd-user to build a while ago, > http://lists.freebsd.org/pipermail/freebsd-emulation/2008-December/005579.html > (it still builds in my latest snapshot, > http://lists.freebsd.org/pipermail/freebsd-emulation/2009-February/005650.html > ) but it is entirely untested, and as said in the first post it looks like > at least the i386 (host) case needs someone with linker script fu to look > at > it before it can actually work. If you want to help you are more than > welcome tho... :) (you are actually the first one to ask about bsd-user > on FreeBSD that I have seen!) Thanks for the pointers. I wish I could help or at least help myself for now. I have an upcoming research deadline before which I need to figure this magic out... Regards, From arno at heho.snv.jussieu.fr Thu Feb 19 10:00:51 2009 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Thu Feb 19 10:01:00 2009 Subject: kern/131506: pipes in forked procs sometimes hang under Linux emulation 2.6.16 In-Reply-To: (Takahiro Kurosawa's message of "Wed\, 18 Feb 2009 00\:19\:56 +0900") References: <200902081700.n18H0EvJ046014@freefall.freebsd.org> Message-ID: Takahiro Kurosawa writes: > It seems that vfork/exec synchronization was changed recently > but the linux emulation code keeps using the obsolete mechanism. > > The attached patch may fix the problem. yes it seems to do so. Thank you for finding this and thanks to kib@FreeBSD.org for committing. Best regards, Arno From lawrence.auster at att.net Thu Feb 19 10:54:16 2009 From: lawrence.auster at att.net (Lawrence Auster) Date: Thu Feb 19 10:54:23 2009 Subject: "My race is just nothing": Some thoughts on the political psychology of women Message-ID: <20090219185410.XLGJ4162.cdptpa-omta04.mail.rr.com@k4k6l> "My race is just nothing": Some thoughts on the political psychology of women By Kevin MacDonald February 19, 2009 It seems that the signs of white dispossession are everywhere these days. Edmund Connelly describes how non-Jewish whites are being pushed out of elite institutions like Harvard. An article titled “The end of white America” catalogues the lack of cultural confidence of whites these days. It quotes a student who says “To be white is to be culturally broke." Writing in vdare.com, David A. Yeagley quotes one of his female students saying “Look ... I don’t see anything about my culture to be proud of. It’s all nothing. My race is just nothing.” Yeagley notes the Cheyenne saying, “A nation is never defeated until the hearts of its women are on the ground.” And he places this in the context of the recent election in which 46% of white women voted for Obama compared to 41% of white men. These percentages are somewhat inflated because they include Jews and immigrants, such as South Asians, who are classified as white but do not identify with the European-American majority. Nevertheless, they do point to a significant gender gap. While it is certainly true that voting for McCain-Palin is not a sign of white consciousness — even implicitly, it is also the case that voting for Obama is a good sign of a lack of racial consciousness for European Americans. The good news, of course, is that a majority of white women did not vote for Obama. And, as Steve Sailer has shown for the 2004 election, if one separated out women who are married and have children, the results would show an even greater tendency to vote against Obama. Nevertheless, there is a real problem. Those of us with some acquaintance with European-Americans who do have an explicit ethnic identity and a sense of their ethnic interests are quite aware that there is a very large sex ratio imbalance at gatherings of like-minded people. The attendees are almost all male — an exception being the redoubtable Virginia Abernethy. And there are stories of men who have stopped attending meetings or who provide support only in the most furtive manner, mainly because their wives are afraid that the attitudes of their husbands could become public and ruin their social life. Making such things public is just the sort of thing that organizations like the SPLC and the ADL love to do. Judith Warner of the New York Times describes the result of an informal "email inquiry" on women's reactions to Obama. Some imagined having sex with Obama and replacing Michelle Obama as First Lady. Others imagined themselves at social engagements with Obama. All wanted deeply to have some of the Obama aura rub off on them. Warner's email contacts doubtless reflect her liberal readership, but I wouldn't be at all surprised if they are quite general, especially among white women who voted for Obama. What does an evolutionary psychologist say about all this? Parenthetically, I realize that the great majority of Americans do not believe in evolution. Nevertheless, evolutionary theory is a very powerful and scientifically credible way of looking at human behavior. It is no accident that one of the main strands of Jewish intellectual activism over the last century has been to oppose evolutionary theory as an explanatory tool in the social sciences. Darwin did indeed have a dangerous idea — dangerous to Jews because it provides a rational grounding for the ethnic identity and interests of European-derived people. The evolutionary theory of sex is one of the bedrocks of evolutionary psychology — probably accounting for half of all the research in the field. The basic idea is simple: Females invest a relatively large amount of time and energy in reproduction. In the world we evolved in, the only way for women to reproduce was to endure a 38-week pregnancy and then nurse the child for an even longer period. Even after nursing, child care was mainly a female responsibility. Because women are committed to this very large investment, they become very valuable in the mating game. And because they are valuable, they become discriminating maters: Just as a worker who puts in more time and energy is in a better bargaining position than one who puts in little time and energy, women become the choosers in the mating game. And what do women want? Women are expected to want men who have high social status. From an evolutionary perspective, such men are attractive because they may be willing to provide valuable resources that would help in supporting the mother and raising the children. (When men do contribute resources, they also become choosy, but that's another story.) And even if a wealthy man does not provide resources, he is likely to have good genes — genes that predispose his children to be successful. In any case, women do indeed prefer wealthy, high-status men. For example, a recent study found that wealthy men give women more orgasms: "The pleasure women get from making love is directly linked to the size of their partner’s bank balance." Other research shows that women are likely to choose higher status men than their husbands when they have affairs, resulting in the possibility of a lower status male helping to raise the children of a higher-status male. What about the idea that evolutionary theory implies that people should be attracted to people who are genetically like themselves? Evolutionary theory predicts that women will be attracted to men who are genetically similar to themselves compared to men who are from a different race or ethnic group. For one thing, this makes them more closely related to their own children. The problem is that this attraction to genetically similar mates is only part of the story. It must compete with the tendency to be attracted to wealthy, powerful men. And quite clearly, the phenomenon where large numbers of white women fantasize about having a relationship with Obama reflects his power and social status, not attraction to a genetically similar person. The media is a major part of the hostile elite, so it is not surprising that it has played a leading role in the idolization of Obama — the slobbering love affair between the mainstream media and Obama. It's the same role that Edmund Connelly has called attention to in his writing on the images of blacks created by Hollywood in recent decades. Black action heroes are now household names, and more than one commentator has pointed out that there were several black presidents in the movies and on television long before Obama was elected. These images from the media tap into women's psychological attraction to high-status males. It was probably fairly common for white women to fantasize about having sex with Will Smith or Denzel Washington or even the "wise and saintly" Morgan Freeman long before the world had ever heard of Barack Obama. Another sex difference that contributes to women's political behavior is that women are generally more nurturant, affectionate, empathic, and caring than men. This is another aspect of female psychology that can easily be derived from evolutionary thinking — the vital importance of nurturing children and developing close family relationships in our evolutionary past. Thus it is not surprising that many of Judith Warner's women not only fantasize about having sex with Obama, they see themselves married to him and becoming first lady. They develop a close and caring relationship with him, or they see him as a good friend. I suppose this is also the reason why women are more likely than men to support social programs that promise to aid children and poor people. This relatively greater empathy and nurturance was certainly adaptive in a world of family groups and close relatives. But in the modern world, it can easily lead to maladaptive altruism and ignoring real dangers. For example, white women enamored of images of sexy, high-status black males are not informed by the mainstream media of the very large racial imbalance in crime, particularly black men raping white women. Another problem with women being relatively high in nurturance and empathy is that these traits are linked to greater compliance and greater inclination to seek the approval and affection of others. Again, these are very adaptive traits in the world of small groups and close relatives. But in a world dominated by elites that are hostile to the interests of whites, these traits can lead to mindless acceptance of anti-white cultural norms. Challenging social norms — even ones that are obviously against one's interests — carries a very high psychological cost to people who seek the approval and affection of others. This implies that once the intellectual and political movements described in The Culture of Critique had seized the intellectual and moral high ground, they became difficult indeed to dislodge. Challenging these norms brings accusations of moral turpitude ringing down from the most prestigious political, media and academic institutions of the society. People who seek the approval and affection of others are definitely not inclined to go there. This in turn may well be a large part of the explanation for why there are so few women at gatherings of European-Americans concerned about the future of their people and culture. This paints a fairly bleak picture. But there are some rays of hope. It is likely that at some point the gap between rhetoric and reality in American life will be so large that no one will believe what they are hearing from the hostile elites that dominate public discourse — much like the Soviet Union in the decades before its fall. When that happens, the cultural icons promoted by the media will lose their credibility and allure as well. And because of the internet, the opportunity to hear divergent opinions and become aware of information that is suppressed by the mainstream media has never been better. All around us we can see the collapse and increasing irrelevance of the old media. The internet has already created communities where prestige and social approval can be obtained completely outside the norms created by our hostile elites. And at least some of these communities are dedicated to transforming America by asserting the legitimacy of white identities and interests. The dispossession of whites is already substantial, but it promises to be a whole lot more obvious as time goes on. As whites become a minority, it is difficult to imagine that they won't develop more of a group consciousness and challenge the prevailing anti-white norms. And that includes even the more nurturant and empathic among us. Source with hyperlinks : http://www.theoccidentalobserver.net/articles/MacDonald-Women.html ------------------------------------- You or someone using your email adress is currently subscribed to Lawrence Auster's Newletter. If you wish to unsubscribe from our mailing list, please let us know by calling to 1 212 865 1284 Thanks, Lawrence Auster, 238 W 101 St Apt. 3B New York, NY 10025 Contact : lawrence.auster@att.net ------------------------------------- From ed at 80386.nl Thu Feb 19 12:56:46 2009 From: ed at 80386.nl (Ed Schouten) Date: Thu Feb 19 12:56:52 2009 Subject: Making Linux stat() less evil Message-ID: <20090219205645.GF19161@hoeg.nl> Hi folks, I may have mentioned this earlier, but our Linuxolator's stat() implementation calls kern_openat(), followed by an translate_fd_major_minor() to perform a device major/minor number lookup. This is very evil, because it causes random chardevs to be opened when you run ls -l /dev. I propose the following patch: http://80386.nl/pub/linux-stat.diff I've copied kern_stat() into the Linuxolator. Not the ideal solution, but it's better than what we have right now. Comments? -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20090219/a9c3e664/attachment.pgp From rdivacky at FreeBSD.org Thu Feb 19 13:00:01 2009 From: rdivacky at FreeBSD.org (Roman Divacky) Date: Thu Feb 19 13:00:07 2009 Subject: Making Linux stat() less evil In-Reply-To: <20090219205645.GF19161@hoeg.nl> References: <20090219205645.GF19161@hoeg.nl> Message-ID: <20090219205653.GA78242@freebsd.org> On Thu, Feb 19, 2009 at 09:56:45PM +0100, Ed Schouten wrote: > Hi folks, > > I may have mentioned this earlier, but our Linuxolator's stat() > implementation calls kern_openat(), followed by an > translate_fd_major_minor() to perform a device major/minor number > lookup. This is very evil, because it causes random chardevs to be > opened when you run ls -l /dev. > > I propose the following patch: > > http://80386.nl/pub/linux-stat.diff > > I've copied kern_stat() into the Linuxolator. Not the ideal solution, > but it's better than what we have right now. Comments? why cant you use kern_statat() and perform this after it returns? + if (S_ISCHR(sb.st_mode) && nd.ni_vp->v_un.vu_cdev != NULL && + linux_driver_get_major_minor( + nd.ni_vp->v_un.vu_cdev->si_name, &major, &minor) == 0) { + sb.st_rdev = (major << 8 | minor); + } From ed at 80386.nl Thu Feb 19 13:10:02 2009 From: ed at 80386.nl (Ed Schouten) Date: Thu Feb 19 13:10:09 2009 Subject: Making Linux stat() less evil In-Reply-To: <20090219205653.GA78242@freebsd.org> References: <20090219205645.GF19161@hoeg.nl> <20090219205653.GA78242@freebsd.org> Message-ID: <20090219210943.GG19161@hoeg.nl> * Roman Divacky wrote: > why cant you use kern_statat() and perform this after it returns? > > + if (S_ISCHR(sb.st_mode) && nd.ni_vp->v_un.vu_cdev != NULL && > + linux_driver_get_major_minor( > + nd.ni_vp->v_un.vu_cdev->si_name, &major, &minor) == 0) { > + sb.st_rdev = (major << 8 | minor); > + } Because I want to use the vnode used by kern_statat() directly. If we perform a second lookup after the call to kern_statat(), it's a race. There is no guarantee you're looking at the same vnode. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20090219/a702a6eb/attachment.pgp From ed at 80386.nl Thu Feb 19 13:27:50 2009 From: ed at 80386.nl (Ed Schouten) Date: Thu Feb 19 13:27:56 2009 Subject: Making Linux stat() less evil In-Reply-To: <20090219205645.GF19161@hoeg.nl> References: <20090219205645.GF19161@hoeg.nl> Message-ID: <20090219212749.GI19161@hoeg.nl> Roman, After some discussion with kib@ on IRC, I changed the patch a little: I added a new function called kern_statat_vnhook(). This function allows the Linuxolator to use a hook to modify struct stat, to reduce some redundant code: http://80386.nl/pub/linux-stat.diff Shall I commit this patch to SVN? -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20090219/dcdb0920/attachment.pgp From nox at jelal.kn-bremen.de Thu Feb 19 14:16:31 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Thu Feb 19 14:16:39 2009 Subject: kernel kqemu vs vmmouse/vmware svga in qemu (workaround) Message-ID: <20090219221400.GA17768@saturn.kn-bremen.de> Hi! The fix of the recent -vga vmware breakage in qemu svn... http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg01065.html ...inspired me to take a longer look at the userspace pio problem that renders vmmouse and -vga vmware unworkable with -kernel-kqemu, and now I found out that apparently in this case iopl changes made in the guest dont get propagated back to userland properly. The workaround below gets vmmouse and -vga vmware going again at least for my usual sidux live iso guest and also shows that iopl ends up still being 0 when it should be higher. I'll leave it to people knowing the kqemu code better than me to find the root cause of this bug... Thanx, Juergen Index: qemu/target-i386/op_helper.c @@ -517,6 +517,11 @@ #endif } +#if 1 +#define VMPORT 0x5658 +int vmware_svga_io_base; +#endif + /* check if Port I/O is allowed in TSS */ static inline void check_io(int addr, int size) { @@ -527,6 +532,27 @@ ((env->tr.flags >> DESC_TYPE_SHIFT) & 0xf) != 9 || env->tr.limit < 103) goto fail; +#if 1 + if (addr == VMPORT) { + static int last_vmport_iopl = -1; + int iopl = (env->eflags >> IOPL_SHIFT) & 3; + if (iopl != last_vmport_iopl) { + printf("check_io vmport workaround: iopl = %d\n", iopl); + last_vmport_iopl = iopl; + } + return; + } + if (vmware_svga_io_base && + addr >= vmware_svga_io_base && addr < vmware_svga_io_base + 3) { + static int last_svga_iopl = -1; + int iopl = (env->eflags >> IOPL_SHIFT) & 3; + if (iopl != last_svga_iopl) { + printf("check_io vmware svga workaround: iopl = %d\n", iopl); + last_svga_iopl = iopl; + } + return; + } +#endif io_offset = lduw_kernel(env->tr.base + 0x66); io_offset += (addr >> 3); /* Note: the check needs two bytes */ Index: qemu/hw/vmware_vga.c @@ -1175,12 +1175,19 @@ return 0; } +#if 1 +extern int vmware_svga_io_base; +#endif + static void pci_vmsvga_map_ioport(PCIDevice *pci_dev, int region_num, uint32_t addr, uint32_t size, int type) { struct pci_vmsvga_state_s *d = (struct pci_vmsvga_state_s *) pci_dev; struct vmsvga_state_s *s = &d->chip; +#if 1 + vmware_svga_io_base = addr + SVGA_IO_MUL * SVGA_INDEX_PORT; +#endif register_ioport_read(addr + SVGA_IO_MUL * SVGA_INDEX_PORT, 1, 4, vmsvga_index_read, s); register_ioport_write(addr + SVGA_IO_MUL * SVGA_INDEX_PORT, From rdivacky at FreeBSD.org Fri Feb 20 04:23:05 2009 From: rdivacky at FreeBSD.org (Roman Divacky) Date: Fri Feb 20 04:23:13 2009 Subject: Making Linux stat() less evil In-Reply-To: <20090219212749.GI19161@hoeg.nl> References: <20090219205645.GF19161@hoeg.nl> <20090219212749.GI19161@hoeg.nl> Message-ID: <20090220121952.GA70382@freebsd.org> On Thu, Feb 19, 2009 at 10:27:49PM +0100, Ed Schouten wrote: > Roman, > > After some discussion with kib@ on IRC, I changed the patch a little: I > added a new function called kern_statat_vnhook(). This function allows > the Linuxolator to use a hook to modify struct stat, to reduce some > redundant code: > > http://80386.nl/pub/linux-stat.diff looks ok to me.. I'd just use __predict_false() to the condition in the kern_statat_vnhook() so we dont pessimise the typical case I didnt test though (nor I plan to) From rdivacky at FreeBSD.org Fri Feb 20 04:25:49 2009 From: rdivacky at FreeBSD.org (Roman Divacky) Date: Fri Feb 20 04:25:55 2009 Subject: Making Linux stat() less evil In-Reply-To: <20090220121952.GA70382@freebsd.org> References: <20090219205645.GF19161@hoeg.nl> <20090219212749.GI19161@hoeg.nl> <20090220121952.GA70382@freebsd.org> Message-ID: <20090220122232.GA70879@freebsd.org> On Fri, Feb 20, 2009 at 01:19:52PM +0100, Roman Divacky wrote: > On Thu, Feb 19, 2009 at 10:27:49PM +0100, Ed Schouten wrote: > > Roman, > > > > After some discussion with kib@ on IRC, I changed the patch a little: I > > added a new function called kern_statat_vnhook(). This function allows > > the Linuxolator to use a hook to modify struct stat, to reduce some > > redundant code: > > > > http://80386.nl/pub/linux-stat.diff > > looks ok to me.. I'd just use __predict_false() to the condition ^^^ add From Alexander at Leidinger.net Fri Feb 20 04:40:21 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Fri Feb 20 04:40:29 2009 Subject: Making Linux stat() less evil In-Reply-To: <20090219212749.GI19161@hoeg.nl> References: <20090219205645.GF19161@hoeg.nl> <20090219212749.GI19161@hoeg.nl> Message-ID: <20090220134008.483828kdvanc31xc@webmail.leidinger.net> Quoting Ed Schouten (from Thu, 19 Feb 2009 22:27:49 +0100): > Roman, > > After some discussion with kib@ on IRC, I changed the patch a little: I > added a new function called kern_statat_vnhook(). This function allows > the Linuxolator to use a hook to modify struct stat, to reduce some > redundant code: > > http://80386.nl/pub/linux-stat.diff > > Shall I commit this patch to SVN? From your patch: ---snip--- @@ -2359,6 +2366,8 @@ vfslocked = NDHASGIANT(&nd); error = vn_stat(nd.ni_vp, &sb, td->td_ucred, NOCRED, td); if (!error) { + if (hook != NULL) + hook(nd.ni_vp, &sb); SDT_PROBE(vfs, , stat, mode, path, sb.st_mode, 0, 0, 0); if (S_ISREG(sb.st_mode)) SDT_PROBE(vfs, , stat, reg, path, pathseg, 0, 0, 0); ---snip--- I think you should call the hook after SDT_PROBE, not before. This way it doesn't matter what the hook does to sb, the dtrace probe will get what it expects (the FreeBSD style sb). I don't think we need to add another dtrace probe here after the probe, as I think this should be handled somewhere near the code of the hook (in this case in the linuxulator... which means I will take care about this in my linuxulator-dtrace branch). Bye, Alexander. -- You are a bundle of energy, always on the go. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From nox at jelal.kn-bremen.de Sat Feb 21 17:43:58 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sat Feb 21 17:44:06 2009 Subject: testing qemu svn r6636 on FreeBSD; future of qemu on FreeBSD... Message-ID: <20090222013747.GA21709@saturn.kn-bremen.de> Hi! After discovering a workaround for the -kernel-kqemu userspace pio bug in connection with vmware svga/vmmouse a few days ago I made another experimental FreeBSD qemu-devel port update today, http://people.freebsd.org/~nox/qemu/qemu-devel-20090218.patch with the mentioned patches added (the vmware_vga.c depth fix hasn't been committed yet so I added it to files/patch-hw-vmware_vga.c for now; the userspace pio workaround patch needed an additional TARGET_I386 check since vmware_vga.c now also gets built for mips targets, see files/patch-iopl-workaround .) Apart from the usb thruput regression with (some?) recent Linux guests that I already had been mentioning a few times (no change there) and the recent discussion of qcow2 corruption that was seen with (at least) win2k guests on recent kvm (which uses similar qcow2 code than qemu svn, see this thread: http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg00713.html - the consensus on that thread seems to be that qcow(2) code has always been experimental and you should use raw images if you want reliability; raw is also usually faster) - apart from these two issues this snapshot is looking pretty good in my (limited) testing so far; you are encouraged to test it with your various guests that you have lying around, if it works for you as well maybe we can indeed update the FreeBSD qemu-devel port again before the next official qemu release gets cut... For the curious, and to get more people testing this, :) here is a reiteration of a few of the improvements made since the snapshot thats currently in ports (qemu-devel), in no particular order: - tcg conversion complete (no longer depends on gcc3) - gdbstub improvements, like managing cpus as threads, working breakpoints etc with -smp, watchpoints... - added cdc ethernet usb nic (-usbdevice net:) - e1000 pxe rom, tso, vlan, and other fixes/improvements - scsi emulation fixes/improvements - 16550A uart (serial) emulation, reported to work with the new uart(4) in FreeBSD-current guests too (except for BREAK_TO_DEBUGGER, altho I don't know whether that even works on real hw now so it might not actually be qemu's fault) - no longer depends on aio(4) so no more chances to forget to kldload that (uses its own threads now) - 64 bit host fixes for slirp (-net user) - added instruction counter - emulate core2duo and phenom cpus, x86 CPUID extended family/model (for example emulate newer amd cpu as: -cpu qemu64,family=15,model=65,stepping=3) - added -clock dynticks support for FreeBSD hosts - added -serial msmouse (Microsoft serial mouse emulation) - virtio-{blk,net,balloon,console} (paravirtualization via emulated pci devices and corresponding guest drivers) - added -net channel ... to forward guest slirp tcp connections to qemu character devices - hpet emulation - (some?) ipv6 support for like vnc - added a -vga none cli option (the other vga options have been renamed too, now you do -vga {none,cirrus,std,vmware} ...) - fixed media detection on emulated cdroms (helps some Linux guests) - added -rtc-td-hack option to fix time drift with RTC on Windows - added "serial" parameter to -drive flag (to specify emulated disk's serial number) - added new option "werror" to -drive flag: possible values are: report - report errors to a guest as IO errors ignore - continue as if nothing happened stop - stop VM on any error and retry last command on resume enospc - stop vm on ENOSPC error and retry last command on resume all other errors are reported to a guest. default is "report" - added snapshot subcommand for qemu-img (to list, create, apply and delete snapshots on qcow2 images) - x86 now issues reset on triple faults - (untested on FreeBSD:) live migration support, basic audio functionality for vnc.c - malc's ad-hoc client for capturing A/V of running guests is here: http://repo.or.cz/w/qemu/malc.git?a=tree;f=vcap;hb=capture3 - and of course all kinds of bugfixes, bios updates (rumors are that vista guests work now?), and also improvements to non-x86 targets... And last, but far from least: FreeBSD host TODOs - help more than welcome here: (this stuff is working on Linux hosts, except maybe bsd-user...) - complete the usb host support (auto dis/connects, isochronous for eg webcams etc, support the new usb stack in FreeBSD-current - the original author of the FreeBSD usb host patches says he is too busy with other stuff now ): - same for bluetooth... - scsi passthru support (so you can use eg tape drives or maybe burn cds/dvds from guests) - add arm/ppc/sparc(?) host support to the port(s) - kvm port! There was a soc project but it never reached the state of entering ports, http://wiki.freebsd.org/FabioChecconi/PortingLinuxKVMToFreeBSD - and now of course both kvm and the FreeBSD kernel have evolved further, and also the first pieces of kvm userland support code have entered qemu svn, and it seems at least some people _might_ want to retire kqemu some time in the future too, see this thread... http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg00326.html - test/fix bsd-user (qemu-sparc64; i386 host linker script seems to be needed at the very least) - write/port virtio guest drivers for FreeBSD (will also be useful for kvm hosts which are getting more common even tho at least atm they have to run Linux...) If you have read until here, thanx! :) Juergen From takahiro.kurosawa at gmail.com Sun Feb 22 10:20:05 2009 From: takahiro.kurosawa at gmail.com (Takahiro Kurosawa) Date: Sun Feb 22 10:20:11 2009 Subject: kern/131506: pipes in forked procs sometimes hang under Linux emulation 2.6.16 Message-ID: <200902221820.n1MIK4Fm046903@freefall.freebsd.org> The following reply was made to PR kern/131506; it has been noted by GNATS. From: Takahiro Kurosawa To: "Arno J. Klaassen" Cc: freebsd-bugs@freebsd.org Subject: Re: kern/131506: pipes in forked procs sometimes hang under Linux emulation 2.6.16 Date: Wed, 18 Feb 2009 00:19:56 +0900 --0015175cddd8fa5fb404631ed549 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit It seems that vfork/exec synchronization was changed recently but the linux emulation code keeps using the obsolete mechanism. The attached patch may fix the problem. --0015175cddd8fa5fb404631ed549 Content-Type: text/x-diff; charset=US-ASCII; name="pwaitfix.diff" Content-Disposition: attachment; filename="pwaitfix.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_frapwkae0 PT09IHN5cy9hbWQ2NC9saW51eDMyL2xpbnV4MzJfbWFjaGRlcC5jCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lz L2FtZDY0L2xpbnV4MzIvbGludXgzMl9tYWNoZGVwLmMJKHJldmlzaW9uIDE4ODc0MSkKKysrIHN5 cy9hbWQ2NC9saW51eDMyL2xpbnV4MzJfbWFjaGRlcC5jCShsb2NhbCkKQEAgLTU2MCw3ICs1NjAs NyBAQAogCS8qIHdhaXQgZm9yIHRoZSBjaGlsZHJlbiB0byBleGl0LCBpZS4gZW11bGF0ZSB2Zm9y ayAqLwogCVBST0NfTE9DSyhwMik7CiAJd2hpbGUgKHAyLT5wX2ZsYWcgJiBQX1BQV0FJVCkKLQkg ICAJbXNsZWVwKHRkLT50ZF9wcm9jLCAmcDItPnBfbXR4LCBQV0FJVCwgInBwd2FpdCIsIDApOwor CQljdl93YWl0KCZwMi0+cF9wd2FpdCwgJnAyLT5wX210eCk7CiAJUFJPQ19VTkxPQ0socDIpOwog CiAJcmV0dXJuICgwKTsKQEAgLTc0OSw3ICs3NDksNyBAQAogCQkvKiB3YWl0IGZvciB0aGUgY2hp bGRyZW4gdG8gZXhpdCwgaWUuIGVtdWxhdGUgdmZvcmsgKi8KIAkJUFJPQ19MT0NLKHAyKTsKIAkJ d2hpbGUgKHAyLT5wX2ZsYWcgJiBQX1BQV0FJVCkKLQkJCW1zbGVlcCh0ZC0+dGRfcHJvYywgJnAy LT5wX210eCwgUFdBSVQsICJwcHdhaXQiLCAwKTsKKwkJCWN2X3dhaXQoJnAyLT5wX3B3YWl0LCAm cDItPnBfbXR4KTsKIAkJUFJPQ19VTkxPQ0socDIpOwogCX0KIAo9PT0gc3lzL2kzODYvbGludXgv bGludXhfbWFjaGRlcC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2kzODYvbGludXgvbGludXhfbWFjaGRl cC5jCShyZXZpc2lvbiAxODg3NDEpCisrKyBzeXMvaTM4Ni9saW51eC9saW51eF9tYWNoZGVwLmMJ KGxvY2FsKQpAQCAtMzc2LDcgKzM3Niw3IEBACiAJLyogd2FpdCBmb3IgdGhlIGNoaWxkcmVuIHRv IGV4aXQsIGllLiBlbXVsYXRlIHZmb3JrICovCiAJUFJPQ19MT0NLKHAyKTsKIAl3aGlsZSAocDIt PnBfZmxhZyAmIFBfUFBXQUlUKQotCSAgIAltc2xlZXAodGQtPnRkX3Byb2MsICZwMi0+cF9tdHgs IFBXQUlULCAicHB3YWl0IiwgMCk7CisJCWN2X3dhaXQoJnAyLT5wX3B3YWl0LCAmcDItPnBfbXR4 KTsKIAlQUk9DX1VOTE9DSyhwMik7CiAKIAlyZXR1cm4gKDApOwpAQCAtNTgxLDcgKzU4MSw3IEBA CiAgICAJICAgCS8qIHdhaXQgZm9yIHRoZSBjaGlsZHJlbiB0byBleGl0LCBpZS4gZW11bGF0ZSB2 Zm9yayAqLwogICAgCSAgIAlQUk9DX0xPQ0socDIpOwogCQl3aGlsZSAocDItPnBfZmxhZyAmIFBf UFBXQUlUKQotICAgCQkgICAJbXNsZWVwKHRkLT50ZF9wcm9jLCAmcDItPnBfbXR4LCBQV0FJVCwg InBwd2FpdCIsIDApOworCQkJY3Zfd2FpdCgmcDItPnBfcHdhaXQsICZwMi0+cF9tdHgpOwogCQlQ Uk9DX1VOTE9DSyhwMik7CiAJfQogCg== --0015175cddd8fa5fb404631ed549 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org" --0015175cddd8fa5fb404631ed549-- From bugmaster at FreeBSD.org Mon Feb 23 03:06:50 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Feb 23 03:07:29 2009 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org Message-ID: <200902231106.n1NB6nE1055460@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- p kern/131099 emulation [linux] [patch] readdir broken on Linux emulation. o kern/130724 emulation [linprocfs] [patch] cpuinfo in linprocfs is dated, cau o kern/129169 emulation [linux] [patch] Linux Emulation ENOTCONN error using n f ports/127018 emulation Linuxulator incapable of using FreeBSD's LDAP environm o kern/126232 emulation [linux] Linux ioctl TCGETS (0x5401) always fails o ports/121800 emulation x11-toolkits/linux-openmotif - OpenMotif upgrade to 2. o kern/97326 emulation [linux] file descriptor leakage in linux emulation o ports/91318 emulation [fix] graphics/linux_dri: works on amd64 too o kern/91293 emulation [svr4] [patch] *Experimental* Update to the SVR4 emula o kern/73777 emulation [linux] [patch] linux emulation: root dir special hand a kern/72920 emulation [linux]: path "prefixing" is not done on unix domain s o kern/41543 emulation [patch] [request] easier wine/w23 support o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/29698 emulation [linux] [patch] linux ipcs doesn'work o kern/21463 emulation [linux] Linux compatability mode should not allow setu o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 16 problems total. From gary.jennejohn at freenet.de Mon Feb 23 06:47:28 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Mon Feb 23 06:47:41 2009 Subject: testing qemu svn r6636 on FreeBSD; future of qemu on FreeBSD... In-Reply-To: <20090222013747.GA21709@saturn.kn-bremen.de> References: <20090222013747.GA21709@saturn.kn-bremen.de> Message-ID: <20090223154724.7d687b13@ernst.jennejohn.org> On Sun, 22 Feb 2009 02:37:47 +0100 Juergen Lock wrote: > been experimental and you should use raw images if you want reliability; > raw is also usually faster) - apart from these two issues this snapshot > is looking pretty good in my (limited) testing so far; you are encouraged > to test it with your various guests that you have lying around, if it > works for you as well maybe we can indeed update the FreeBSD qemu-devel > port again before the next official qemu release gets cut... > Well, I applied the patches and installed qemu. I tried installing openSUSELinux 10.3 because I had a DVD laying around. I used a 150GB raw image created using qemu-img. I did not use kqemu. I started qemu with this command line: qemu -boot d -cdrom /dev/acd0 -hda linux.img -localtime -m 1G Note I have an AMD64 X2 with 4GB of RAM installed running 8-current. It got up to the point where it actually started the install and then croaked with SIGSEGV, I think it was. The error message flashed by rather quickly. That means that I was able to partition the disks and specify some non-standard packages. It managed to create and format the disk partitions and figure out from the DVD which packages to install. Not too bad, I suppose. --- Gary Jennejohn From nox at jelal.kn-bremen.de Mon Feb 23 13:22:59 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Mon Feb 23 13:23:13 2009 Subject: testing qemu svn r6636 on FreeBSD; future of qemu on FreeBSD... In-Reply-To: <20090223154724.7d687b13@ernst.jennejohn.org> References: <20090222013747.GA21709@saturn.kn-bremen.de> <20090223154724.7d687b13@ernst.jennejohn.org> Message-ID: <20090223211933.GA79361@saturn.kn-bremen.de> On Mon, Feb 23, 2009 at 03:47:24PM +0100, Gary Jennejohn wrote: > On Sun, 22 Feb 2009 02:37:47 +0100 > Juergen Lock wrote: > > > been experimental and you should use raw images if you want reliability; > > raw is also usually faster) - apart from these two issues this snapshot > > is looking pretty good in my (limited) testing so far; you are encouraged > > to test it with your various guests that you have lying around, if it > > works for you as well maybe we can indeed update the FreeBSD qemu-devel > > port again before the next official qemu release gets cut... > > > > Well, I applied the patches and installed qemu. > > I tried installing openSUSELinux 10.3 because I had a DVD laying around. > > I used a 150GB raw image created using qemu-img. I did not use kqemu. > I started qemu with this command line: > > qemu -boot d -cdrom /dev/acd0 -hda linux.img -localtime -m 1G > > Note I have an AMD64 X2 with 4GB of RAM installed running 8-current. > > It got up to the point where it actually started the install and then > croaked with SIGSEGV, I think it was. The error message flashed by > rather quickly. > > That means that I was able to partition the disks and specify some > non-standard packages. It managed to create and format the disk > partitions and figure out from the DVD which packages to install. > > Not too bad, I suppose. A SIGSEGV, hmm. What I do see sometimes especially without kqemu is guest failures related to various kinds of timeouts, i.e. guests not expecting running as slowly... tho a SIGSEGV is probably something different. You could try a few things: a) the same with kqemu (userland), in case its a tcg bug (or indeed a timeout; remember to rebuild qemu in case you built it without the kqemu knob enabled or otherwise kqemu won't get used), and also b) another time with -kernel-kqemu in case its a tcg bug affecting guest kernel code (altho of course in both cases kqemu can cause its own kind of failures, even more so with amd64 guests...) c) try the same with the original qemu-devel port and also with qemu 0.9.1 (the qemu port), in case its a regression (possibly caused by the tcg conversion?) d) see if you can enable coredumps in the guest in order to find out more about your particular failure. Oh and if you do any of these you may want to also Cc the qemu list with your findings, they are probably interested as well... Thanx, Juergen From Greeting at Greetings.com Wed Feb 25 03:20:14 2009 From: Greeting at Greetings.com (Greetings.com) Date: Wed Feb 25 03:20:20 2009 Subject: Hey, you have a new Greeting !!! Message-ID: Hello friend ! You have just received a postcard Greeting from someone who cares about you... Just click [1]here to receive your Animated Greeting ! Thank you for using www.Greetings.com services !!! Please take this opportunity to let your friends hear about us by sending them a postcard from our collection ! References 1. http://summitsteelinc.com/views/e-greetings.exe From gary.jennejohn at freenet.de Wed Feb 25 07:24:44 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Wed Feb 25 07:24:51 2009 Subject: testing qemu svn r6636 on FreeBSD; future of qemu on FreeBSD... In-Reply-To: <20090223211933.GA79361@saturn.kn-bremen.de> References: <20090222013747.GA21709@saturn.kn-bremen.de> <20090223154724.7d687b13@ernst.jennejohn.org> <20090223211933.GA79361@saturn.kn-bremen.de> Message-ID: <20090225162439.11f8265b@ernst.jennejohn.org> On Mon, 23 Feb 2009 22:19:33 +0100 Juergen Lock wrote: > On Mon, Feb 23, 2009 at 03:47:24PM +0100, Gary Jennejohn wrote: > > On Sun, 22 Feb 2009 02:37:47 +0100 > > Juergen Lock wrote: > > > > > been experimental and you should use raw images if you want reliability; > > > raw is also usually faster) - apart from these two issues this snapshot > > > is looking pretty good in my (limited) testing so far; you are encouraged > > > to test it with your various guests that you have lying around, if it > > > works for you as well maybe we can indeed update the FreeBSD qemu-devel > > > port again before the next official qemu release gets cut... > > > > > > > Well, I applied the patches and installed qemu. > > > > I tried installing openSUSELinux 10.3 because I had a DVD laying around. > > > > I used a 150GB raw image created using qemu-img. I did not use kqemu. > > I started qemu with this command line: > > > > qemu -boot d -cdrom /dev/acd0 -hda linux.img -localtime -m 1G > > > > Note I have an AMD64 X2 with 4GB of RAM installed running 8-current. > > > > It got up to the point where it actually started the install and then > > croaked with SIGSEGV, I think it was. The error message flashed by > > rather quickly. > > > > That means that I was able to partition the disks and specify some > > non-standard packages. It managed to create and format the disk > > partitions and figure out from the DVD which packages to install. > > > > Not too bad, I suppose. > > A SIGSEGV, hmm. What I do see sometimes especially without kqemu is guest > failures related to various kinds of timeouts, i.e. guests not expecting > running as slowly... tho a SIGSEGV is probably something different. > I tried the installation a few more times using the patched qemu-devel and was able to see that the error was indeed a segmentation violation in Yast.call, whatever that may mean. > You could try a few things: > a) the same with kqemu (userland), in case its a tcg bug (or indeed a > timeout; remember to rebuild qemu in case you built it without the > kqemu knob enabled or otherwise kqemu won't get used), and also > b) another time with -kernel-kqemu in case its a tcg bug affecting > guest kernel code (altho of course in both cases kqemu can cause its > own kind of failures, even more so with amd64 guests...) > I'll consider doing these steps with the patched qemu-devel later. > c) try the same with the original qemu-devel port and also with qemu 0.9.1 > (the qemu port), in case its a regression (possibly caused by the tcg > conversion?) > qemu never gets past the initial openSUSE install screen. It just sits there eating 100% of the CPU without any visible progress. I tried qemu-devel with kqemu.ko loaded but it never got past loading the Linux kernel. It hung at various boot stages with no apparent pattern. Without kqemu.ko it is actually doing the install as I write this. Have to wait and see just how far it gets. One difference between now and before is that I have vfs_aio in the kernel. I'm also running a brand-new kernel from today. BTW this is the command line which I used: qemu -net none -m 1G -boot d -cdrom /dev/acd0 -hda linux.img -localtime -std-vga > d) see if you can enable coredumps in the guest in order to find out more > about your particular failure. > Well, supposedly Yast.call dumped core, but since the Linux install runs out of a memory disk there's no way for me to see it. I have no idea how to enable coredumps such that I can acccess any coredumps which may be made. > Oh and if you do any of these you may want to also Cc the qemu list with > your findings, they are probably interested as well... > OK, added. --- Gary Jennejohn From gary.jennejohn at freenet.de Wed Feb 25 11:15:56 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Wed Feb 25 11:16:02 2009 Subject: testing qemu svn r6636 on FreeBSD; future of qemu on FreeBSD... Message-ID: <20090225201550.3d3032b5@ernst.jennejohn.org> On Mon, 23 Feb 2009 22:19:33 +0100 Juergen Lock wrote: > You could try a few things: > a) the same with kqemu (userland), in case its a tcg bug (or indeed a > timeout; remember to rebuild qemu in case you built it without the > kqemu knob enabled or otherwise kqemu won't get used), and also > b) another time with -kernel-kqemu in case its a tcg bug affecting > guest kernel code (altho of course in both cases kqemu can cause its > own kind of failures, even more so with amd64 guests...) > Neither of these work. The only way I can get past loading the kernel is with -no-kqemu. I still see the segmentation fault in Yast.call. Now I know that it's in line 486, if that's of any interest. Sorry, I'm not going to invest any more time in this. --- Gary Jennejohn From lwindschuh at googlemail.com Fri Feb 27 08:47:04 2009 From: lwindschuh at googlemail.com (Lucius Windschuh) Date: Fri Feb 27 08:47:10 2009 Subject: [PATCH] futexes / now: duplicate lock of same type Message-ID: <90a5caac0902270822t5740dea4l9e9fa5cda2bada48@mail.gmail.com> 2009/2/10 Chagin Dmitry : >> > please, try http://lnxx64.googlecode.com/files/futexes_partial_II.patch >> > first patch fail at i386... I am using your patch and Flash got a bit faster. :-) But witness reported this when I start my opera and load mail.google.com: acquiring duplicate lock of same type: "futex lock" 1st futex lock @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:179 2nd futex lock @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:211 KDB: stack backtrace: db_trace_self_wrapper(c09b535c,eb1d7b50,c06da5a5,4,c09b0871,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c09b0871,c0d62685,c6112d88,eb1d7bac,...) at kdb_backtrace+0x29 _witness_debugger(c09b7f74,c0d626e7,c0d62685,d3,c09ab01b,...) at _witness_debugger+0x25 witness_checkorder(c7526b80,9,c0d62685,d3,0,...) at witness_checkorder+0x469 _sx_xlock(c7526b80,0,c0d62685,d3,0,...) at _sx_xlock+0x85 futex_get0(0,0,102,c7526b80,0,...) at futex_get0+0x28c futex_get_op(eb1d7c44,eb1d7c58,c068ba4c,c770f088,4,...) at futex_get_op+0x93 linux_sys_futex(c77336c0,eb1d7cf8,eb1d7d18,eb1d7d1c,c0d65b20,...) at linux_sys_futex+0x6a syscall(eb1d7d38) at syscall+0x283 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (240, Linux ELF, linux_sys_futex), eip = 0x28cd69b3, esp = 0xbfbfde6c, ebp = 0x4000001 --- Is this message potentially harmful? More information can be gathered on request (e.g. textdump with a custom ddb script). Regards Lucius From eitanadlerlist at gmail.com Fri Feb 27 11:33:19 2009 From: eitanadlerlist at gmail.com (Eitan Adler) Date: Fri Feb 27 11:33:25 2009 Subject: Linux gtk2.10+ Message-ID: <49A838D3.2010408@gmail.com> This is a follow up to a previous message I sent to this list about updating linux-gtk to a more recent version of GTK. At the time the response was "Boris has a patch, wait for the ports to melt (unfreeze)". Any updates? -- Eitan Adler "Security is increased by designing for the way humans actually behave." -Jakob Nielsen From dchagin at freebsd.org Fri Feb 27 15:20:44 2009 From: dchagin at freebsd.org (Chagin Dmitry) Date: Fri Feb 27 15:20:51 2009 Subject: [PATCH] futexes / now: duplicate lock of same type In-Reply-To: <90a5caac0902270822t5740dea4l9e9fa5cda2bada48@mail.gmail.com> References: <90a5caac0902270822t5740dea4l9e9fa5cda2bada48@mail.gmail.com> Message-ID: <20090227225341.GA83061@dchagin.static.corbina.ru> On Fri, Feb 27, 2009 at 05:22:52PM +0100, Lucius Windschuh wrote: > 2009/2/10 Chagin Dmitry : > >> > please, try http://lnxx64.googlecode.com/files/futexes_partial_II.patch > >> > first patch fail at i386... > > I am using your patch and Flash got a bit faster. :-) > But witness reported this when I start my opera and load mail.google.com: > > acquiring duplicate lock of same type: "futex lock" > 1st futex lock @ > /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:179 > 2nd futex lock @ > /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:211 > KDB: stack backtrace: > db_trace_self_wrapper(c09b535c,eb1d7b50,c06da5a5,4,c09b0871,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(4,c09b0871,c0d62685,c6112d88,eb1d7bac,...) at kdb_backtrace+0x29 > _witness_debugger(c09b7f74,c0d626e7,c0d62685,d3,c09ab01b,...) at > _witness_debugger+0x25 > witness_checkorder(c7526b80,9,c0d62685,d3,0,...) at witness_checkorder+0x469 > _sx_xlock(c7526b80,0,c0d62685,d3,0,...) at _sx_xlock+0x85 > futex_get0(0,0,102,c7526b80,0,...) at futex_get0+0x28c > futex_get_op(eb1d7c44,eb1d7c58,c068ba4c,c770f088,4,...) at futex_get_op+0x93 > linux_sys_futex(c77336c0,eb1d7cf8,eb1d7d18,eb1d7d1c,c0d65b20,...) at > linux_sys_futex+0x6a > syscall(eb1d7d38) at syscall+0x283 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (240, Linux ELF, linux_sys_futex), eip = 0x28cd69b3, esp = > 0xbfbfde6c, ebp = 0x4000001 --- > > Is this message potentially harmful? > > More information can be gathered on request (e.g. textdump with a > custom ddb script). > hi, thanks for the concern! this is expected behavior. this futexes design problem. anyway thnx! -- Have fun! chd From nox at jelal.kn-bremen.de Sat Feb 28 09:17:51 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sat Feb 28 09:18:02 2009 Subject: testing qemu svn r6636 on FreeBSD; future of qemu on FreeBSD... In-Reply-To: <20090225201550.3d3032b5@ernst.jennejohn.org> References: <20090225201550.3d3032b5@ernst.jennejohn.org> Message-ID: <20090228171520.GA56888@saturn.kn-bremen.de> On Wed, Feb 25, 2009 at 08:15:50PM +0100, Gary Jennejohn wrote: > On Mon, 23 Feb 2009 22:19:33 +0100 > Juergen Lock wrote: > > > You could try a few things: > > a) the same with kqemu (userland), in case its a tcg bug (or indeed a > > timeout; remember to rebuild qemu in case you built it without the > > kqemu knob enabled or otherwise kqemu won't get used), and also > > b) another time with -kernel-kqemu in case its a tcg bug affecting > > guest kernel code (altho of course in both cases kqemu can cause its > > own kind of failures, even more so with amd64 guests...) > > > > Neither of these work. The only way I can get past loading the kernel > is with -no-kqemu. > > I still see the segmentation fault in Yast.call. Now I know that it's > in line 486, if that's of any interest. > > Sorry, I'm not going to invest any more time in this. Thanx. Can someone else verify that kqemu still works on FreeBSD-current? It is possible that you got hit by the kqemu tsc vs smp problem, i.e. passing `notsc' to the guest kernel or forcing qemu onto one cpu (cpuset -l 0 qemu ...) may have helped there, sorry I should have thought of that earlier... Also, did I get that right that this opensuse 10.3 install worked with the original qemu-devel port (without kqemu)? So we do seem to have a regression here... (thats a 20080620 qemu svn snapshot, for the folks on the qemu list.) Thanx, Juergen From gary.jennejohn at freenet.de Sat Feb 28 11:16:55 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Sat Feb 28 11:17:08 2009 Subject: testing qemu svn r6636 on FreeBSD; future of qemu on FreeBSD... In-Reply-To: <20090228171520.GA56888@saturn.kn-bremen.de> References: <20090225201550.3d3032b5@ernst.jennejohn.org> <20090228171520.GA56888@saturn.kn-bremen.de> Message-ID: <20090228201650.064c0ee4@ernst.jennejohn.org> On Sat, 28 Feb 2009 18:15:20 +0100 Juergen Lock wrote: > On Wed, Feb 25, 2009 at 08:15:50PM +0100, Gary Jennejohn wrote: > > On Mon, 23 Feb 2009 22:19:33 +0100 > > Juergen Lock wrote: > > > > > You could try a few things: > > > a) the same with kqemu (userland), in case its a tcg bug (or indeed a > > > timeout; remember to rebuild qemu in case you built it without the > > > kqemu knob enabled or otherwise kqemu won't get used), and also > > > b) another time with -kernel-kqemu in case its a tcg bug affecting > > > guest kernel code (altho of course in both cases kqemu can cause its > > > own kind of failures, even more so with amd64 guests...) > > > > > > > Neither of these work. The only way I can get past loading the kernel > > is with -no-kqemu. > > > > I still see the segmentation fault in Yast.call. Now I know that it's > > in line 486, if that's of any interest. > > > > Sorry, I'm not going to invest any more time in this. > > Thanx. Can someone else verify that kqemu still works on FreeBSD-current? > I went back to openSUSE with the standard qemu-devel. I found that I could (usually) boot w/o problems if I put -no-acpi on the CL. Right now I have openSUSE runngin pretty well. It's nearly as fast as on my old (genuine) IBM X31 laptop :) > It is possible that you got hit by the kqemu tsc vs smp problem, i.e. > passing `notsc' to the guest kernel or forcing qemu onto one cpu > (cpuset -l 0 qemu ...) may have helped there, sorry I should have thought > of that earlier... > I just tried these suggestions (with the standard qemu-devel) and they don't seem to do any harm :-P > Also, did I get that right that this opensuse 10.3 install worked with > the original qemu-devel port (without kqemu)? So we do seem to have a > regression here... (thats a 20080620 qemu svn snapshot, for the folks > on the qemu list.) > See above. Now I'm thinking about giving the patched qemu-devel another try, since I've found some workarounds for booting. I'll see whether I can at least boot into the installed openSUSE using it. --- Gary Jennejohn From nox at jelal.kn-bremen.de Sat Feb 28 13:37:28 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sat Feb 28 13:37:35 2009 Subject: testing qemu svn r6636 on FreeBSD; future of qemu on FreeBSD... In-Reply-To: <20090228201650.064c0ee4@ernst.jennejohn.org> References: <20090225201550.3d3032b5@ernst.jennejohn.org> <20090228171520.GA56888@saturn.kn-bremen.de> <20090228201650.064c0ee4@ernst.jennejohn.org> Message-ID: <20090228213620.GA64626@saturn.kn-bremen.de> On Sat, Feb 28, 2009 at 08:16:50PM +0100, Gary Jennejohn wrote: > On Sat, 28 Feb 2009 18:15:20 +0100 > Juergen Lock wrote: > > > On Wed, Feb 25, 2009 at 08:15:50PM +0100, Gary Jennejohn wrote: > > > On Mon, 23 Feb 2009 22:19:33 +0100 > > > Juergen Lock wrote: > > > > > > > You could try a few things: > > > > a) the same with kqemu (userland), in case its a tcg bug (or indeed a > > > > timeout; remember to rebuild qemu in case you built it without the > > > > kqemu knob enabled or otherwise kqemu won't get used), and also > > > > b) another time with -kernel-kqemu in case its a tcg bug affecting > > > > guest kernel code (altho of course in both cases kqemu can cause its > > > > own kind of failures, even more so with amd64 guests...) > > > > > > > > > > Neither of these work. The only way I can get past loading the kernel > > > is with -no-kqemu. > > > > > > I still see the segmentation fault in Yast.call. Now I know that it's > > > in line 486, if that's of any interest. > > > > > > Sorry, I'm not going to invest any more time in this. > > > > Thanx. Can someone else verify that kqemu still works on FreeBSD-current? > > > > I went back to openSUSE with the standard qemu-devel. I found that I > could (usually) boot w/o problems if I put -no-acpi on the CL. > > Right now I have openSUSE runngin pretty well. It's nearly as fast as > on my old (genuine) IBM X31 laptop :) > > > It is possible that you got hit by the kqemu tsc vs smp problem, i.e. > > passing `notsc' to the guest kernel or forcing qemu onto one cpu > > (cpuset -l 0 qemu ...) may have helped there, sorry I should have thought > > of that earlier... > > > > I just tried these suggestions (with the standard qemu-devel) and they > don't seem to do any harm :-P > ..but they didn't help either? (i.e. w/o -no-acpi) > > Also, did I get that right that this opensuse 10.3 install worked with > > the original qemu-devel port (without kqemu)? So we do seem to have a > > regression here... (thats a 20080620 qemu svn snapshot, for the folks > > on the qemu list.) > > > > See above. > > Now I'm thinking about giving the patched qemu-devel another try, since > I've found some workarounds for booting. I'll see whether I can at least > boot into the installed openSUSE using it. Thanx, :) Juergen