From bugmaster at FreeBSD.org Mon Dec 1 03:06:54 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Dec 1 03:07:42 2008 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org Message-ID: <200812011106.mB1B6rMS052512@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/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 14 problems total. From tijl at ulyssis.org Tue Dec 2 08:50:47 2008 From: tijl at ulyssis.org (Tijl Coosemans) Date: Tue Dec 2 08:50:54 2008 Subject: wine-1.1.8 regression -- wine: could not load L"...": Invalid address In-Reply-To: <20081130221935.GA79764@ravenloft.kiev.ua> References: <20081130221935.GA79764@ravenloft.kiev.ua> Message-ID: <200812021750.43465.tijl@ulyssis.org> On Sunday 30 November 2008 23:19:35 Alex Kozlov wrote: >> On Wed, 26 Nov 2008, Alex Kozlov wrote: >>>> The patch moves this to (address_space_limit - 10 * VIRTUAL_HEAP_SIZE). >>>> I'm not sure that's correct. I think simply 0x80000000 would be better, >>>> but that's what Alexandre can tell you. >>> >>> I'm also not sure. That why this patch quick and dirty. Let see what >>> Julliard has to say. > > From Alexandre POV most correct action will be to fix reserve_areas logic > on FreeBSD. (I try that on this weekend, but with limited success. Very > limited. Need more work, and I'm not sure that I will have enough time) You tried porting the preloader? > As for the patch, place when alloc virtual_heap don't matter. So I think > 0x80000000 is ok. On second thought, you'll probably need something like 0x81000000 or even further, because the win9x shared heap is supposed to be at 0x80000000. Will you submit a patch for this (perhaps as a follow-up to ports/128926), then Daichi can commit it and we'll be settled for the time being. From regisr at pobox.com Fri Dec 5 15:13:54 2008 From: regisr at pobox.com (regisr) Date: Fri Dec 5 15:14:00 2008 Subject: wine-1.1.8 regression -- wine: could not load L"...": Invalid address Message-ID: <20081206001351.218fa05c.regisr@pobox.com> (I apologize, I don't have the previous message to follow the thread) With the patch of dlls/ntdll/virtual.c and 1.1.9.1,1 version of wine I can launch a program named "international.exe" which lauch "C:\\windows\\temp\\mvu87c.tmp\\pxplay.exe" : I have the sound but not the display. (previously without the patch the error 'could not load L"Z:\\...": Invalid address ' was displayed) Messages on xterm are: ------------------------------------------ %wine international.exe fixme:win:EnumDisplayDevicesW ((null),0,0x34f15c,0x00000000), stub! fixme:d3d:IWineD3DDeviceImpl_Release (0x1e65c48) Device released with resources still bound, acceptable but unexpected fixme:d3d:dumpResources Leftover resource 0x1e69968 with type 1,WINED3DRTYPE_SURFACE ----------------------------------------- It is a FreeBSD port trouble, it is OK with Ubuntu. Another program which had the same problem run, I have the display but I can't use the mouse, is this a wine configuration problem? I made some tries and ... the X server closed and return to xdm :-( I don't yet tried it with Linux. ... and a good new: without the patch a program which was OK with previous releases crashed with a memory error, now with the patch it is Ok. All programs use the full screen to display slideshows. -- regis From nox at jelal.kn-bremen.de Sat Dec 6 14:11:21 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sat Dec 6 14:11:28 2008 Subject: testing qemu svn r5890 on FreeBSD - virtio, and a patch enabling -clock dynticks Message-ID: <20081206220906.GA34210@saturn.kn-bremen.de> Hi! Jung-uk Kim sent me a patch to enable -clock dynticks on FreeBSD hosts (the configure check is mine, only FreeBSD >= 7.x has posix timers that this uses), I'll append it below. This is the experimental qemu-devel port update I used: http://people.freebsd.org/~nox/qemu/qemu-devel-20081206.patch As already mentioned I had to add a missing `#include ' (files/patch-qemu-common.h), as also posted here: http://lists.gnu.org/archive/html/qemu-devel/2008-12/msg00216.html I only had one (type of) guest that actually had virtio drivers (three versions of sidux isos), and the speed difference between virtio-blk and scsi was small. (I tested dd bs=64k count=500 /dev/null and similar with a raw image, both scsi and virtio were always faster than ide.) I noted tho that even virtio there was not half as fast as ide (and scsi) on KNOPPIX_V5.3.1DVD-2008-03-26-EN.iso, so either overhead has increased greatly from 2.6.24.4 to 2.6.26, or this has something to do with the sidux kernel using CONFIG_NO_HZ and the Knoppix one (apparently) not and qemu (possibly, I also suspected that with the usb slowness) not handling CONFIG_NO_HZ guests too well. scsi on a FreeBSD 7.1-BETA-i386-livefs.iso guest btw was even yet (noticeably) faster than on the Knoppix iso. It will be interesting how virtio-net will fare once that gets committed... Here comes the dynticks patch (files/patch-dynticks), it assumes that NetBSD either always has posix timers, or -lrt is not needed otherwise there. (FreeBSD before 7.x doesn't have -lrt.) --- qemu/Makefile.target.orig 2008-11-21 11:49:37.000000000 -0500 +++ qemu/Makefile.target 2008-12-03 15:46:24.000000000 -0500 @@ -598,7 +598,7 @@ OBJS+=block-raw-posix.o endif -LIBS+=-lz +LIBS += $(RTLIBS) -lz ifdef CONFIG_ALSA LIBS += -lasound endif Index: qemu/configure @@ -99,6 +99,7 @@ fmod_lib="" fmod_inc="" oss_lib="" +rt_lib="" vnc_tls="yes" bsd="no" linux="no" @@ -157,13 +158,15 @@ if [ "$cpu" = "i386" -o "$cpu" = "x86_64" ] ; then kqemu="yes" fi +rt_lib="-lrt" ;; NetBSD) bsd="yes" audio_drv_list="oss" audio_possible_drivers="oss sdl esd" oss_lib="-lossaudio" -aio_lib="-lrt -lpthread" +aio_lib="-lpthread" +rt_lib="-lrt" ;; OpenBSD) bsd="yes" @@ -231,6 +234,7 @@ kqemu="yes" audio_possible_drivers="$audio_possible_drivers fmod" fi +rt_lib="-lrt" ;; esac @@ -1053,6 +1057,20 @@ iovec=yes fi +########################################## +# posix timer probe +cat > $TMPC < +int main(void) { timer_create(CLOCK_REALTIME, (struct sigevent *)NULL, (timer_t *)NULL); return 0; } +EOF +posixtimer=no +if $cc $ARCH_CFLAGS -o $TMPE $TMPC $rt_lib 2> /dev/null ; then + posixtimer=yes +else + rt_lib="" +fi +RTLIBS="$rt_lib" + # Check if tools are available to build documentation. if [ "x$NOPORTDOCS" != "x" -o -x "`which texi2html 2>/dev/null`" ] && \ [ -x "`which pod2man 2>/dev/null`" ]; then @@ -1174,6 +1192,7 @@ echo "LDFLAGS=$LDFLAGS" >> $config_mak echo "EXESUF=$EXESUF" >> $config_mak echo "AIOLIBS=$AIOLIBS" >> $config_mak +echo "RTLIBS=$RTLIBS" >> $config_mak case "$cpu" in i386) echo "ARCH=i386" >> $config_mak @@ -1425,6 +1444,9 @@ if test "$iovec" = "yes" ; then echo "#define HAVE_IOVEC 1" >> $config_h fi +if test "$posixtimer" = "yes" ; then + echo "#define HAVE_POSIX_TIMER 1" >> $config_h +fi # XXX: suppress that if [ "$bsd" = "yes" ] ; then Index: qemu/vl.c @@ -918,12 +918,16 @@ static int unix_start_timer(struct qemu_alarm_timer *t); static void unix_stop_timer(struct qemu_alarm_timer *t); -#ifdef __linux__ +#ifdef HAVE_POSIX_TIMER static int dynticks_start_timer(struct qemu_alarm_timer *t); static void dynticks_stop_timer(struct qemu_alarm_timer *t); static void dynticks_rearm_timer(struct qemu_alarm_timer *t); +#endif + +#ifdef __linux__ + static int hpet_start_timer(struct qemu_alarm_timer *t); static void hpet_stop_timer(struct qemu_alarm_timer *t); @@ -1001,9 +1005,11 @@ static struct qemu_alarm_timer alarm_timers[] = { #ifndef _WIN32 -#ifdef __linux__ +#ifdef HAVE_POSIX_TIMER {"dynticks", ALARM_FLAG_DYNTICKS, dynticks_start_timer, dynticks_stop_timer, dynticks_rearm_timer, NULL}, +#endif +#ifdef __linux__ /* HPET - if available - is preferred */ {"hpet", 0, hpet_start_timer, hpet_stop_timer, NULL, NULL}, /* ...otherwise try RTC */ @@ -1361,7 +1367,7 @@ return delta; } -#if defined(__linux__) || defined(_WIN32) +#if defined(HAVE_POSIX_TIMER) || defined(_WIN32) static uint64_t qemu_next_deadline_dyntick(void) { int64_t delta; @@ -1506,6 +1512,10 @@ close(rtc_fd); } +#endif /* defined(__linux__) */ + +#ifdef HAVE_POSIX_TIMER + static int dynticks_start_timer(struct qemu_alarm_timer *t) { struct sigevent ev; @@ -1577,7 +1587,7 @@ } } -#endif /* defined(__linux__) */ +#endif /* defined(HAVE_POSIX_TIMER) */ static int unix_start_timer(struct qemu_alarm_timer *t) { From nox at jelal.kn-bremen.de Sat Dec 6 14:32:58 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sat Dec 6 14:33:04 2008 Subject: usb slowness again (was: testing qemu svn r5890 on FreeBSD - virtio, and a patch enabling -clock dynticks) In-Reply-To: <20081206220906.GA34210@saturn.kn-bremen.de> References: <20081206220906.GA34210@saturn.kn-bremen.de> Message-ID: <20081206223140.GA37972@saturn.kn-bremen.de> On Sat, Dec 06, 2008 at 11:09:06PM +0100, Juergen Lock wrote: > Hi! > > Jung-uk Kim sent me a patch to enable -clock dynticks on FreeBSD hosts > (the configure check is mine, only FreeBSD >= 7.x has posix timers that > this uses), I'll append it below. > > This is the experimental qemu-devel port update I used: > http://people.freebsd.org/~nox/qemu/qemu-devel-20081206.patch > As already mentioned I had to add a missing `#include ' > (files/patch-qemu-common.h), as also posted here: > http://lists.gnu.org/archive/html/qemu-devel/2008-12/msg00216.html > > I only had one (type of) guest that actually had virtio drivers (three > versions of sidux isos), and the speed difference between virtio-blk and > scsi was small. (I tested dd bs=64k count=500 /dev/null and > similar with a raw image, both scsi and virtio were always faster than ide.) > I noted tho that even virtio there was not half as fast as ide (and scsi) > on KNOPPIX_V5.3.1DVD-2008-03-26-EN.iso, so either overhead has increased > greatly from 2.6.24.4 to 2.6.26, or this has something to do with > the sidux kernel using CONFIG_NO_HZ and the Knoppix one (apparently) not > and qemu (possibly, I also suspected that with the usb slowness) not > handling CONFIG_NO_HZ guests too well. [...] Well I just tried -usb -usbdevice net:vlan=1 -net user,vlan=1 with the Knoppix iso and got the same thruput (< 40 K/s) for wget on a local file than I got with sidux. So its probably not CONFIG_NO_HZ, at least not the usb slowness. Just thought I'd mention... Juergen From anthony at codemonkey.ws Sat Dec 6 19:02:38 2008 From: anthony at codemonkey.ws (Anthony Liguori) Date: Sat Dec 6 19:02:45 2008 Subject: [Qemu-devel] testing qemu svn r5890 on FreeBSD - virtio, and a patch enabling -clock dynticks In-Reply-To: <20081206220906.GA34210@saturn.kn-bremen.de> References: <20081206220906.GA34210@saturn.kn-bremen.de> Message-ID: <493B35AB.1050301@codemonkey.ws> Juergen Lock wrote: > Hi! > > Jung-uk Kim sent me a patch to enable -clock dynticks on FreeBSD hosts > (the configure check is mine, only FreeBSD >= 7.x has posix timers that > this uses), I'll append it below. > > This is the experimental qemu-devel port update I used: > http://people.freebsd.org/~nox/qemu/qemu-devel-20081206.patch > As already mentioned I had to add a missing `#include ' > (files/patch-qemu-common.h), as also posted here: > http://lists.gnu.org/archive/html/qemu-devel/2008-12/msg00216.html > > I only had one (type of) guest that actually had virtio drivers (three > versions of sidux isos), and the speed difference between virtio-blk and > scsi was small. (I tested dd bs=64k count=500 /dev/null and > similar with a raw image, both scsi and virtio were always faster than ide.) > I noted tho that even virtio there was not half as fast as ide (and scsi) > on KNOPPIX_V5.3.1DVD-2008-03-26-EN.iso, so either overhead has increased > greatly from 2.6.24.4 to 2.6.26, or this has something to do with > the sidux kernel using CONFIG_NO_HZ and the Knoppix one (apparently) not > and qemu (possibly, I also suspected that with the usb slowness) not > handling CONFIG_NO_HZ guests too well. scsi on a FreeBSD > 7.1-BETA-i386-livefs.iso guest btw was even yet (noticeably) faster than > on the Knoppix iso. It will be interesting how virtio-net will fare once > that gets committed... > I don't have much experience with perf benchmarking and TCG. TCG may has interesting side effects. For instance, it's more expensive to do things in the guest instead of the host so the emulation overhead of IDE/SCSI shouldn't matter much. A straight dd test is not the best test BTW. If you want to measure performance, you should use O_DIRECT in the guest (iflag=direct) and probably O_DIRECT in the host (cache=none). Regards, Anthony Liguori > Here comes the dynticks patch (files/patch-dynticks), it assumes that > NetBSD either always has posix timers, or -lrt is not needed otherwise > there. (FreeBSD before 7.x doesn't have -lrt.) > > --- qemu/Makefile.target.orig 2008-11-21 11:49:37.000000000 -0500 > +++ qemu/Makefile.target 2008-12-03 15:46:24.000000000 -0500 > @@ -598,7 +598,7 @@ > OBJS+=block-raw-posix.o > endif > > -LIBS+=-lz > +LIBS += $(RTLIBS) -lz > ifdef CONFIG_ALSA > LIBS += -lasound > endif > Index: qemu/configure > @@ -99,6 +99,7 @@ > fmod_lib="" > fmod_inc="" > oss_lib="" > +rt_lib="" > vnc_tls="yes" > bsd="no" > linux="no" > @@ -157,13 +158,15 @@ > if [ "$cpu" = "i386" -o "$cpu" = "x86_64" ] ; then > kqemu="yes" > fi > +rt_lib="-lrt" > ;; > NetBSD) > bsd="yes" > audio_drv_list="oss" > audio_possible_drivers="oss sdl esd" > oss_lib="-lossaudio" > -aio_lib="-lrt -lpthread" > +aio_lib="-lpthread" > +rt_lib="-lrt" > ;; > OpenBSD) > bsd="yes" > @@ -231,6 +234,7 @@ > kqemu="yes" > audio_possible_drivers="$audio_possible_drivers fmod" > fi > +rt_lib="-lrt" > ;; > esac > > @@ -1053,6 +1057,20 @@ > iovec=yes > fi > > +########################################## > +# posix timer probe > +cat > $TMPC < +#include > +int main(void) { timer_create(CLOCK_REALTIME, (struct sigevent *)NULL, (timer_t *)NULL); return 0; } > +EOF > +posixtimer=no > +if $cc $ARCH_CFLAGS -o $TMPE $TMPC $rt_lib 2> /dev/null ; then > + posixtimer=yes > +else > + rt_lib="" > +fi > +RTLIBS="$rt_lib" > + > # Check if tools are available to build documentation. > if [ "x$NOPORTDOCS" != "x" -o -x "`which texi2html 2>/dev/null`" ] && \ > [ -x "`which pod2man 2>/dev/null`" ]; then > @@ -1174,6 +1192,7 @@ > echo "LDFLAGS=$LDFLAGS" >> $config_mak > echo "EXESUF=$EXESUF" >> $config_mak > echo "AIOLIBS=$AIOLIBS" >> $config_mak > +echo "RTLIBS=$RTLIBS" >> $config_mak > case "$cpu" in > i386) > echo "ARCH=i386" >> $config_mak > @@ -1425,6 +1444,9 @@ > if test "$iovec" = "yes" ; then > echo "#define HAVE_IOVEC 1" >> $config_h > fi > +if test "$posixtimer" = "yes" ; then > + echo "#define HAVE_POSIX_TIMER 1" >> $config_h > +fi > > # XXX: suppress that > if [ "$bsd" = "yes" ] ; then > Index: qemu/vl.c > @@ -918,12 +918,16 @@ > static int unix_start_timer(struct qemu_alarm_timer *t); > static void unix_stop_timer(struct qemu_alarm_timer *t); > > -#ifdef __linux__ > +#ifdef HAVE_POSIX_TIMER > > static int dynticks_start_timer(struct qemu_alarm_timer *t); > static void dynticks_stop_timer(struct qemu_alarm_timer *t); > static void dynticks_rearm_timer(struct qemu_alarm_timer *t); > > +#endif > + > +#ifdef __linux__ > + > static int hpet_start_timer(struct qemu_alarm_timer *t); > static void hpet_stop_timer(struct qemu_alarm_timer *t); > > @@ -1001,9 +1005,11 @@ > > static struct qemu_alarm_timer alarm_timers[] = { > #ifndef _WIN32 > -#ifdef __linux__ > +#ifdef HAVE_POSIX_TIMER > {"dynticks", ALARM_FLAG_DYNTICKS, dynticks_start_timer, > dynticks_stop_timer, dynticks_rearm_timer, NULL}, > +#endif > +#ifdef __linux__ > /* HPET - if available - is preferred */ > {"hpet", 0, hpet_start_timer, hpet_stop_timer, NULL, NULL}, > /* ...otherwise try RTC */ > @@ -1361,7 +1367,7 @@ > return delta; > } > > -#if defined(__linux__) || defined(_WIN32) > +#if defined(HAVE_POSIX_TIMER) || defined(_WIN32) > static uint64_t qemu_next_deadline_dyntick(void) > { > int64_t delta; > @@ -1506,6 +1512,10 @@ > close(rtc_fd); > } > > +#endif /* defined(__linux__) */ > + > +#ifdef HAVE_POSIX_TIMER > + > static int dynticks_start_timer(struct qemu_alarm_timer *t) > { > struct sigevent ev; > @@ -1577,7 +1587,7 @@ > } > } > > -#endif /* defined(__linux__) */ > +#endif /* defined(HAVE_POSIX_TIMER) */ > > static int unix_start_timer(struct qemu_alarm_timer *t) > { > > > From tijl at ulyssis.org Sun Dec 7 03:49:59 2008 From: tijl at ulyssis.org (Tijl Coosemans) Date: Sun Dec 7 03:50:06 2008 Subject: wine-1.1.8 regression -- wine: could not load L"...": Invalid address In-Reply-To: <20081206001351.218fa05c.regisr@pobox.com> References: <20081206001351.218fa05c.regisr@pobox.com> Message-ID: <200812071249.49807.tijl@ulyssis.org> On Saturday 06 December 2008 00:13:51 regisr wrote: > (I apologize, I don't have the previous message to follow the thread) > > With the patch of dlls/ntdll/virtual.c and 1.1.9.1,1 version of wine I > can launch a program named "international.exe" which lauch > "C:\\windows\\temp\\mvu87c.tmp\\pxplay.exe" : I have the sound but not > the display. > (previously without the patch the error 'could not load L"Z:\\...": > Invalid address ' was displayed) > > Messages on xterm are: > ------------------------------------------ > %wine international.exe > fixme:win:EnumDisplayDevicesW ((null),0,0x34f15c,0x00000000), stub! > fixme:d3d:IWineD3DDeviceImpl_Release (0x1e65c48) Device released with > resources still bound, acceptable but unexpected > fixme:d3d:dumpResources Leftover resource 0x1e69968 with type > 1,WINED3DRTYPE_SURFACE > ----------------------------------------- > It is a FreeBSD port trouble, it is OK with Ubuntu. > > > Another program which had the same problem run, I have the display but > I can't use the mouse, is this a wine configuration problem? > I made some tries and ... the X server closed and return to xdm :-( > I don't yet tried it with Linux. > > ... and a good new: without the patch a program which was OK with > previous releases crashed with a memory error, now with the patch it is > Ok. > > All programs use the full screen to display slideshows. Do FreeBSD and Ubuntu run on the same machine? What graphics drivers are you using? From regisr at pobox.com Sun Dec 7 06:41:25 2008 From: regisr at pobox.com (regisr) Date: Sun Dec 7 06:41:32 2008 Subject: wine-1.1.8 regression -- wine: could not load L"...": Invalid address In-Reply-To: <200812071249.49807.tijl@ulyssis.org> References: <20081206001351.218fa05c.regisr@pobox.com> <200812071249.49807.tijl@ulyssis.org> Message-ID: <20081207154123.d6f6e640.regisr@pobox.com> Le Sun, 7 Dec 2008 12:49:48 +0100 Tijl Coosemans a ?crit: > > All programs use the full screen to display slideshows. To resume: One is running fine and the two others which had previously the 'could not load L"Z:\\ ... " ' error don't run correctly. For one there sound but no display and the mouse don't work on the second. > Do FreeBSD and Ubuntu run on the same machine? Not the same machine. And I have no space to install ubuntu on the same machine. I can check if there is wine on a Linux live CD to test it. > What graphics drivers are you using? (II) LoadModule: "radeon" (II) Loading /usr/local/lib/xorg/modules/drivers//radeon_drv.so (II) Module radeon: vendor="X.Org Foundation" compiled for 1.4.2, module version = 4.3.0 -- regis From regisr at pobox.com Sun Dec 7 07:16:37 2008 From: regisr at pobox.com (regisr) Date: Sun Dec 7 07:16:43 2008 Subject: wine-1.1.8 regression -- wine: could not load L"...": Invalid address In-Reply-To: <200812071249.49807.tijl@ulyssis.org> References: <20081206001351.218fa05c.regisr@pobox.com> <200812071249.49807.tijl@ulyssis.org> Message-ID: <20081207161635.492aa7b7.regisr@pobox.com> I find why the mouse seems to not work! Le Sun, 7 Dec 2008 12:49:48 +0100 Tijl Coosemans a ?crit: > > All programs use the full screen to display slideshows. When I press the mouse button a programm is launched but in the background and it is masked by the main screen (full scree size and it is only a menu written in flash! :-( The sound is not fine but it is not important in this case. For information I have errors: fixme:ddraw:IDirectDrawImpl_WaitForVerticalBlank (0x1e9198)->(1,0x0): Stub -- regis From tijl at ulyssis.org Sun Dec 7 08:06:42 2008 From: tijl at ulyssis.org (Tijl Coosemans) Date: Sun Dec 7 08:06:48 2008 Subject: wine-1.1.8 regression -- wine: could not load L"...": Invalid address In-Reply-To: <20081207161635.492aa7b7.regisr@pobox.com> References: <20081206001351.218fa05c.regisr@pobox.com> <200812071249.49807.tijl@ulyssis.org> <20081207161635.492aa7b7.regisr@pobox.com> Message-ID: <200812071706.35856.tijl@ulyssis.org> On Sunday 07 December 2008 16:16:35 regisr wrote: > I find why the mouse seems to not work! > > Le Sun, 7 Dec 2008 12:49:48 +0100 Tijl Coosemans a > ?crit: > >>> All programs use the full screen to display slideshows. > > When I press the mouse button a programm is launched but in the > background and it is masked by the main screen (full scree size and > it is only a menu written in flash! :-( Is this a FreeBSD only problem? If it happens on Linux as well you should file a bug report at http://bugs.winehq.org/ From sfourman at gmail.com Sun Dec 7 08:39:42 2008 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Sun Dec 7 08:39:52 2008 Subject: wine-1.1.8 regression -- wine: could not load L"...": Invalid address In-Reply-To: <200812071706.35856.tijl@ulyssis.org> References: <20081206001351.218fa05c.regisr@pobox.com> <200812071249.49807.tijl@ulyssis.org> <20081207161635.492aa7b7.regisr@pobox.com> <200812071706.35856.tijl@ulyssis.org> Message-ID: <11167f520812070839s3aef1502veee28cfccbc9d2ed@mail.gmail.com> > Is this a FreeBSD only problem? If it happens on Linux as well you > should file a bug report at http://bugs.winehq.org/ > _______________________________________________ > freebsd-emulation@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-emulation > To unsubscribe, send any mail to "freebsd-emulation-unsubscribe@freebsd.org" I thought someone wrote a patch about a week ago to fix the invalid address problem I don't think it is committed yet, because the maintainer is on vacation. I assume he will get to applying the patch when wine 1.1.10 is in the ports tree. From regisr at pobox.com Sun Dec 7 09:48:42 2008 From: regisr at pobox.com (regisr) Date: Sun Dec 7 09:48:48 2008 Subject: wine 1.1.9,1 Display problem In-Reply-To: <200812071706.35856.tijl@ulyssis.org> References: <20081206001351.218fa05c.regisr@pobox.com> <200812071249.49807.tijl@ulyssis.org> <20081207161635.492aa7b7.regisr@pobox.com> <200812071706.35856.tijl@ulyssis.org> Message-ID: <20081207184839.001ba311.regisr@pobox.com> Le Sun, 7 Dec 2008 17:06:34 +0100 Tijl Coosemans a ?crit: > Is this a FreeBSD only problem? If it happens on Linux as well you > should file a bug report at http://bugs.winehq.org/ I can test this tomorrow. (this is for the program index.exe). Now, for it, I have a workaround. > I thought someone wrote a patch about a week ago to fix the invalid > address problem I have apply the patch by Alex Kozlov, Doest I need to revert it to apply the patch modified by Tijl? About he trouble which is pending from my wine use: The program name is international.exe. A 538M file... It is running fine under Ubuntu, and I don't have display with FreeBSD, only sound. The error messages: fixme:win:EnumDisplayDevicesW ((null),0,0x34f15c,0x00000000), stub! fixme:d3d:IWineD3DDeviceImpl_Release (0x1e65c48) Device released with resources still bound, acceptable but unexpected fixme:d3d:dumpResources Leftover resource 0x1e69968 with type 1,WINED3DRTYPE_SURFACE The wine threads: 44617 ?? Rs 0:26,07 /usr/local/lib/../bin/wineserver 44620 ?? I 0:00,02 c:\\windows\\system32\\services.exe 44621 ?? I 0:00,02 c:\\windows\\system32\\winedevice.exe 44623 ?? Ss 0:00,10 c:\\windows\\system32\\explorer.exe 44615 p2 S+ 0:01,06 international.exe 44637 p2 S+ 0:52,68 C:\\windows\\temp\\mvu899.tmp\\pxplay.exe -- regis From nox at jelal.kn-bremen.de Sun Dec 7 10:21:50 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sun Dec 7 10:21:56 2008 Subject: [Qemu-devel] testing qemu svn r5890 on FreeBSD - virtio, and a patch enabling -clock dynticks In-Reply-To: <493B35AB.1050301@codemonkey.ws> References: <20081206220906.GA34210@saturn.kn-bremen.de> Message-ID: <200812071819.mB7IJQOT062178@saturn.kn-bremen.de> In article <493B35AB.1050301@codemonkey.ws> you write: >Juergen Lock wrote: >> Hi! >> >> Jung-uk Kim sent me a patch to enable -clock dynticks on FreeBSD hosts >> (the configure check is mine, only FreeBSD >= 7.x has posix timers that >> this uses), I'll append it below. >> >> This is the experimental qemu-devel port update I used: >> http://people.freebsd.org/~nox/qemu/qemu-devel-20081206.patch >> As already mentioned I had to add a missing `#include ' >> (files/patch-qemu-common.h), as also posted here: >> http://lists.gnu.org/archive/html/qemu-devel/2008-12/msg00216.html >> >> I only had one (type of) guest that actually had virtio drivers (three >> versions of sidux isos), and the speed difference between virtio-blk and >> scsi was small. (I tested dd bs=64k count=500 /dev/null and >> similar with a raw image, both scsi and virtio were always faster than ide.) >> I noted tho that even virtio there was not half as fast as ide (and scsi) >> on KNOPPIX_V5.3.1DVD-2008-03-26-EN.iso, so either overhead has increased >> greatly from 2.6.24.4 to 2.6.26, or this has something to do with >> the sidux kernel using CONFIG_NO_HZ and the Knoppix one (apparently) not >> and qemu (possibly, I also suspected that with the usb slowness) not >> handling CONFIG_NO_HZ guests too well. scsi on a FreeBSD >> 7.1-BETA-i386-livefs.iso guest btw was even yet (noticeably) faster than >> on the Knoppix iso. It will be interesting how virtio-net will fare once >> that gets committed... >> > >I don't have much experience with perf benchmarking and TCG. TCG may >has interesting side effects. For instance, it's more expensive to do >things in the guest instead of the host so the emulation overhead of >IDE/SCSI shouldn't matter much. > Actually most of those tests were with -kernel-kqemu sice that is what I usually run linux guests with. >A straight dd test is not the best test BTW. If you want to measure >performance, you should use O_DIRECT in the guest (iflag=direct) Hmm, how many guest processes will use that? Or is that what fses end up doing when the guest does things like, say, cp'ing files around? > and >probably O_DIRECT in the host (cache=none). Ok, will do next time... Thanx, Juergen From tijl at ulyssis.org Sun Dec 7 10:44:33 2008 From: tijl at ulyssis.org (Tijl Coosemans) Date: Sun Dec 7 10:44:40 2008 Subject: wine 1.1.9,1 Display problem In-Reply-To: <20081207184839.001ba311.regisr@pobox.com> References: <20081206001351.218fa05c.regisr@pobox.com> <200812071706.35856.tijl@ulyssis.org> <20081207184839.001ba311.regisr@pobox.com> Message-ID: <200812071944.30328.tijl@ulyssis.org> On Sunday 07 December 2008 18:48:39 regisr wrote: > I have apply the patch by Alex Kozlov, Doest I need to revert it to > apply the patch modified by Tijl? > > About he trouble which is pending from my wine use: > The program name is international.exe. A 538M file... > It is running fine under Ubuntu, and I don't have display with > FreeBSD, only sound. > > The error messages: > fixme:win:EnumDisplayDevicesW ((null),0,0x34f15c,0x00000000), stub! > fixme:d3d:IWineD3DDeviceImpl_Release (0x1e65c48) Device released with > resources still bound, acceptable but unexpected > fixme:d3d:dumpResources Leftover resource 0x1e69968 with type > 1,WINED3DRTYPE_SURFACE > > The wine threads: > 44617 ?? Rs 0:26,07 /usr/local/lib/../bin/wineserver > 44620 ?? I 0:00,02 c:\\windows\\system32\\services.exe > 44621 ?? I 0:00,02 c:\\windows\\system32\\winedevice.exe > 44623 ?? Ss 0:00,10 c:\\windows\\system32\\explorer.exe > 44615 p2 S+ 0:01,06 international.exe > 44637 p2 S+ 0:52,68 C:\\windows\\temp\\mvu899.tmp\\pxplay.exe pxplay.exe is Photodex Presenter which is a plugin like Flash. In a browser window it seems to work, not perfectly, but it works. Switching to full screen however doesn't. There's only sound and no display. So I can confirm the problem, but I have no idea what could be causing this. From regisr at pobox.com Sun Dec 7 12:26:04 2008 From: regisr at pobox.com (regisr) Date: Sun Dec 7 12:26:10 2008 Subject: wine 1.1.9,1 Display problem In-Reply-To: <200812071944.30328.tijl@ulyssis.org> References: <20081206001351.218fa05c.regisr@pobox.com> <200812071706.35856.tijl@ulyssis.org> <20081207184839.001ba311.regisr@pobox.com> <200812071944.30328.tijl@ulyssis.org> Message-ID: <20081207212601.9d4da40d.regisr@pobox.com> Le Sun, 7 Dec 2008 19:44:28 +0100 Tijl Coosemans a ?crit: > pxplay.exe is Photodex Presenter which is a plugin like Flash. > In a browser window it seems to work, not perfectly, but it works. > Switching to full screen however doesn't. There's only sound and no > display. So I can confirm the problem, but I have no idea what could > be causing this. The others programs that I run with wine are also Photodesk Presenter. ( I have suggested to the company to comppatible viewer, at least for mac and linux!). For index.exe, which is a flash executable, it launch windows with Photodex Presenter but masked by this menu! I can launch each slideshow separately, not in full screen. But for international.exe I have only one big binary. I don't know how it is made. It can be an archive file: running it create some files in the drive C: On Ubuntu it use a full screen mode. It is not my main request: I want to see the slideshow, in windows at least ;-) Photodex seems be the more used software for slideshow and AV in international photography exhibitions (replacing Scala IMHO). -- regis From bugmaster at FreeBSD.org Mon Dec 8 03:06:54 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Dec 8 03:07:40 2008 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org Message-ID: <200812081106.mB8B6r70014225@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/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 14 problems total. From beech at alaskaparadise.com Wed Dec 10 21:56:34 2008 From: beech at alaskaparadise.com (Beech Rintoul) Date: Wed Dec 10 21:56:44 2008 Subject: Time wrong with f8 Message-ID: <200812102040.29488.beech@alaskaparadise.com> I'm having a problem with f8 and skype. Since I switched from f7 to f8 linux apps are reading my time as GMT instead of localtime. Is there something I need to setup to get the proper time? Suggestions would be appreciated, Beech -- --------------------------------------------------------------------------------------- Beech Rintoul - FreeBSD Developer - beech@FreeBSD.org /"\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://people.freebsd.org/~beech X - NO Word docs in e-mail | Skype: akbeech / \ - http://www.FreeBSD.org/releases/7.0R/announce.html --------------------------------------------------------------------------------------- From kama at pvp.se Thu Dec 11 00:56:27 2008 From: kama at pvp.se (kama) Date: Thu Dec 11 00:56:35 2008 Subject: Time wrong with f8 In-Reply-To: <200812102040.29488.beech@alaskaparadise.com> References: <200812102040.29488.beech@alaskaparadise.com> Message-ID: <20081211090543.E11937@ns1.as.pvp.se> On Wed, 10 Dec 2008, Beech Rintoul wrote: > I'm having a problem with f8 and skype. Since I switched from f7 to f8 linux > apps are reading my time as GMT instead of localtime. Is there something I > need to setup to get the proper time? You need to set the timezone within the linuxulator. In gentoo, which I use, you can just copy /etc/localtime to /compat/linux/etc. But if I recall correctly f8 uses a different version and need todo it in the same way as f8 does. I believe the zonefiles are located under /usr/share/zoneinfo so... cp /compat/linux/usr/share/zoneinfo/CET /compat/linux/etc/localtime ... should to the trick if the zonefiles even are installed, otherwise you need to add that rpm package. tzdata-2008h-1.fc8.noarch.rpm should probably be used, it apperently have some changes when DST is used on a couple of zones. (http://n2.nabble.com/change-timezone--td1400491.html) /Bjorn From Alexander at Leidinger.net Thu Dec 11 01:38:55 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Thu Dec 11 01:39:02 2008 Subject: Time wrong with f8 In-Reply-To: <20081211090543.E11937@ns1.as.pvp.se> References: <200812102040.29488.beech@alaskaparadise.com> <20081211090543.E11937@ns1.as.pvp.se> Message-ID: <20081211103840.18715so8q06f72ko@webmail.leidinger.net> Quoting kama (from Thu, 11 Dec 2008 09:25:38 +0100 (CET)): > > On Wed, 10 Dec 2008, Beech Rintoul wrote: > >> I'm having a problem with f8 and skype. Since I switched from f7 to f8 linux >> apps are reading my time as GMT instead of localtime. Is there something I >> need to setup to get the proper time? > > You need to set the timezone within the linuxulator. > > In gentoo, which I use, you can just copy /etc/localtime to > /compat/linux/etc. But if I recall correctly f8 uses a different version > and need todo it in the same way as f8 does. > > I believe the zonefiles are located under /usr/share/zoneinfo so... > > cp /compat/linux/usr/share/zoneinfo/CET /compat/linux/etc/localtime > > ... should to the trick if the zonefiles even are installed, otherwise you > need to add that rpm package. tzdata-2008h-1.fc8.noarch.rpm should > probably be used, it apperently have some changes when DST is used on a > couple of zones. (http://n2.nabble.com/change-timezone--td1400491.html) It's a known issue. Search the archives. Maybe Boris has a fix for f8 (wait for the ports tree to be unfrozen). We hope that the import a the new tzcode into FreeBSD solves the issue (by using the same new format for /etc/localtime). I don't know when this will be imported. Bye, Alexander. -- If you laid all of our laws end to end, there would be no end. -- Mark Twain http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From bsam at ipt.ru Thu Dec 11 01:43:14 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Thu Dec 11 01:43:21 2008 Subject: Time wrong with f8 In-Reply-To: <200812102040.29488.beech@alaskaparadise.com> (Beech Rintoul's message of "Wed\, 10 Dec 2008 20\:40\:29 -0900") References: <200812102040.29488.beech@alaskaparadise.com> Message-ID: <14239263@bb.ipt.ru> Beech Rintoul writes: > I'm having a problem with f8 and skype. Since I switched from f7 to f8 linux > apps are reading my time as GMT instead of localtime. Is there something I > need to setup to get the proper time? > > Suggestions would be appreciated, > > Beech It was discussed at October. Jeremy Messenger found a workaround. Please, look archives for thread "Linux compat 2.6.16 reports time incorrect". WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From beech at alaskaparadise.com Thu Dec 11 01:44:33 2008 From: beech at alaskaparadise.com (Beech Rintoul) Date: Thu Dec 11 01:44:40 2008 Subject: Time wrong with f8 In-Reply-To: <20081211103840.18715so8q06f72ko@webmail.leidinger.net> References: <200812102040.29488.beech@alaskaparadise.com> <20081211090543.E11937@ns1.as.pvp.se> <20081211103840.18715so8q06f72ko@webmail.leidinger.net> Message-ID: <200812110044.32148.beech@alaskaparadise.com> On Thursday 11 December 2008 00:38:40 Alexander Leidinger wrote: > Quoting kama (from Thu, 11 Dec 2008 09:25:38 +0100 (CET)): > > On Wed, 10 Dec 2008, Beech Rintoul wrote: > >> I'm having a problem with f8 and skype. Since I switched from f7 to f8 > >> linux apps are reading my time as GMT instead of localtime. Is there > >> something I need to setup to get the proper time? > > > > You need to set the timezone within the linuxulator. > > > > In gentoo, which I use, you can just copy /etc/localtime to > > /compat/linux/etc. But if I recall correctly f8 uses a different version > > and need todo it in the same way as f8 does. > > > > I believe the zonefiles are located under /usr/share/zoneinfo so... > > > > cp /compat/linux/usr/share/zoneinfo/CET /compat/linux/etc/localtime > > > > ... should to the trick if the zonefiles even are installed, otherwise > > you need to add that rpm package. tzdata-2008h-1.fc8.noarch.rpm should > > probably be used, it apperently have some changes when DST is used on a > > couple of zones. (http://n2.nabble.com/change-timezone--td1400491.html) > > It's a known issue. Search the archives. Maybe Boris has a fix for f8 > (wait for the ports tree to be unfrozen). We hope that the import a > the new tzcode into FreeBSD solves the issue (by using the same new > format for /etc/localtime). I don't know when this will be imported. > > Bye, > Alexander. Thanks, I just downloaded the latest rpm extracted it with rpm2cpio and installed by hand. Seems to work :-) Beech -- --------------------------------------------------------------------------------------- Beech Rintoul - FreeBSD Developer - beech@FreeBSD.org /"\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://people.freebsd.org/~beech X - NO Word docs in e-mail | Skype: akbeech / \ - http://www.FreeBSD.org/releases/7.0R/announce.html --------------------------------------------------------------------------------------- From bsam at ipt.ru Thu Dec 11 01:46:45 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Thu Dec 11 01:46:51 2008 Subject: Time wrong with f8 In-Reply-To: <20081211103840.18715so8q06f72ko@webmail.leidinger.net> (Alexander Leidinger's message of "Thu\, 11 Dec 2008 10\:38\:40 +0100") References: <200812102040.29488.beech@alaskaparadise.com> <20081211090543.E11937@ns1.as.pvp.se> <20081211103840.18715so8q06f72ko@webmail.leidinger.net> Message-ID: <48159052@bb.ipt.ru> Alexander Leidinger writes: >> On Wed, 10 Dec 2008, Beech Rintoul wrote: >> >>> I'm having a problem with f8 and skype. Since I switched from f7 to f8 linux >>> apps are reading my time as GMT instead of localtime. Is there something I >>> need to setup to get the proper time? > > It's a known issue. Search the archives. Maybe Boris has a fix for f8 > (wait for the ports tree to be unfrozen). Sorry, didn't have time so far. :-( > We hope that the import a > the new tzcode into FreeBSD solves the issue (by using the same new > format for /etc/localtime). Yes, it should. >I don't know when this will be imported. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From bsam at ipt.ru Thu Dec 11 01:52:10 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Thu Dec 11 01:52:16 2008 Subject: Time wrong with f8 In-Reply-To: <200812110044.32148.beech@alaskaparadise.com> (Beech Rintoul's message of "Thu\, 11 Dec 2008 00\:44\:31 -0900") References: <200812102040.29488.beech@alaskaparadise.com> <20081211090543.E11937@ns1.as.pvp.se> <20081211103840.18715so8q06f72ko@webmail.leidinger.net> <200812110044.32148.beech@alaskaparadise.com> Message-ID: <82078727@bb.ipt.ru> Beech Rintoul writes: > On Thursday 11 December 2008 00:38:40 Alexander Leidinger wrote: >> It's a known issue. Search the archives. Maybe Boris has a fix for f8 >> (wait for the ports tree to be unfrozen). We hope that the import a >> the new tzcode into FreeBSD solves the issue (by using the same new >> format for /etc/localtime). I don't know when this will be imported. > > Thanks, I just downloaded the latest rpm extracted it with rpm2cpio and > installed by hand. Seems to work :-) Openning a PR will be The Right Thing. :-) WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From jhein at timing.com Thu Dec 11 02:03:21 2008 From: jhein at timing.com (John Hein) Date: Thu Dec 11 02:03:28 2008 Subject: Time wrong with f8 In-Reply-To: <200812102040.29488.beech@alaskaparadise.com> References: <200812102040.29488.beech@alaskaparadise.com> Message-ID: <18752.54476.213252.934478@gromit.timing.com> Beech Rintoul wrote at 20:40 -0900 on Dec 10, 2008: > I'm having a problem with f8 and skype. Since I switched from f7 to f8 linux > apps are reading my time as GMT instead of localtime. Is there something I > need to setup to get the proper time? This was discussed in Oct in these threads... http://thread.gmane.org/gmane.os.freebsd.devel.emulation/5885 and http://thread.gmane.org/gmane.os.freebsd.devel.emulation/5893 From bengta at sics.se Fri Dec 12 05:07:56 2008 From: bengta at sics.se (Bengt Ahlgren) Date: Fri Dec 12 05:08:34 2008 Subject: Proper use of LD_LIBRARY_PATH for Linux progs? Message-ID: Hi! I ran into a problem with programs exec:ed by print/acroread8 picking up Linux libraries and thus failed to run. This includes the print program in the print dialogue and the browser configured in edit/preferences/internet. The reason is that the acroread launch script sets LD_LIBRARY_PATH which is propagated to its childs. See this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/129553 Question 1: anybody else that sees this problem? Question 2: what is the "proper" way to fix this problem? (specifically for acroread8, but also in general.) Bengt Ps. Sorry for cross-posting - don't know which list to use for this issue. From Kevin at RawFedDogs.net Fri Dec 12 08:16:43 2008 From: Kevin at RawFedDogs.net (Kevin Monceaux) Date: Fri Dec 12 08:16:50 2008 Subject: flash9 checklist In-Reply-To: <49086F1A.2090500@comcast.net> References: <200810280859.24048@aldan> <20081028181731.GA30591@saturn.kn-bremen.de> <49086F1A.2090500@comcast.net> Message-ID: On Wed, 29 Oct 2008, Steve Polyack wrote: > Thanks for this. I was able to get linux-flashplugin9 working in native > Firefox 3.0.3 on FreeBSD 7-STABLE i386. The only additional thing I had > to do was copy > /usr/X11R6/lib/browser_plugins/npwrapper.libflashplayer.so into > ~/.mozilla/plugins/ for Firefox to recognize the plugin. I'll second that motion. Many thanks for making a usable flash plugin a reality. I also had to perform the above copy, so the above info helped me. I don't necessarily like sites that try to force flash upon people, but at the same time it's a pain to be among the flash impaired. I ended up switching from FreeBSD back to Linux for a while due to the lack of a stable flash plugin. Anyway, for reference this is what I have on my box which appears to be working well so far: FreeBSD: RELENG_7 Firefox: native firefox-3.0.4,1 compat.linux.osrelease=2.6.16 OVERRIDE_LINUX_BASE_PORT=f8 On my previous FreeBSD install I was also having problems with acroread. It would segfault every time I tried to start it. With the above it's also working well. I did have a minor problem with the above setup and one of acroread8's dependencies, linux-nvu. It wanted libgobject-2.0.so.0 from devel/linux-glib2 under ${LINUXBASE}/usr/lib/. emulators/linux_base-f8 installed libgobject-2.0.so.0 at ${LINUXBASE}/lib/. I tried changing the dependency line in the linux-nvu port's Makefile accordingly but it kept trying to pull in linux-glib2 as a dependency. The install of linux-glib2 would fail as it has some file conflicts with linux_base-f8. I finally just removed the dependency line for libgobject-2.0.so.0 from linux-nvu all together, since I knew the library was installed and available, and all appears well. Kevin http://www.RawFedDogs.net http://www.WacoAgilityGroup.org Bruceville, TX Si hoc legere scis nimium eruditionis habes. Longum iter est per praecepta, breve et efficax per exempla!!! From Alexander at Leidinger.net Sat Dec 13 12:11:26 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sat Dec 13 12:11:33 2008 Subject: Proper use of LD_LIBRARY_PATH for Linux progs? In-Reply-To: References: Message-ID: <20081213211115.1274360bbklovuas@webmail.leidinger.net> Quoting Bengt Ahlgren (from Fri, 12 Dec 2008 13:37:25 +0100): > The reason is that the acroread launch script sets LD_LIBRARY_PATH > which is propagated to its childs. See this PR: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/129553 > Question 2: what is the "proper" way to fix this problem? > (specifically for acroread8, but also in general.) Search the archive for the ports mailinglist, in the mail "print/acroread8: LD_LIBRARY_PATH breaks helper programs" is a fix for the problem. In general: there's no general fix. It all depends why LD_LIBRARY_PATH is used and what is done. There are multiple ways, some are workarounds ("env LD_LIBRARY_PATH='' lpr ..." ), some (like the one for acroread in the mail) are good fixes. Bye, Alexander. -- Disclose classified information only when a NEED TO KNOW exists. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From Alexander at Leidinger.net Sat Dec 13 12:18:05 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sat Dec 13 12:18:11 2008 Subject: Proper use of LD_LIBRARY_PATH for Linux progs? In-Reply-To: <20081213211115.1274360bbklovuas@webmail.leidinger.net> References: <20081213211115.1274360bbklovuas@webmail.leidinger.net> Message-ID: <20081213211753.172124oke0p9oqdc@webmail.leidinger.net> Quoting Alexander Leidinger (from Sat, 13 Dec 2008 21:11:15 +0100): > Quoting Bengt Ahlgren (from Fri, 12 Dec 2008 > 13:37:25 +0100): > >> The reason is that the acroread launch script sets LD_LIBRARY_PATH >> which is propagated to its childs. See this PR: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/129553 > >> Question 2: what is the "proper" way to fix this problem? >> (specifically for acroread8, but also in general.) > > Search the archive for the ports mailinglist, in the mail > "print/acroread8: LD_LIBRARY_PATH breaks helper programs" is a fix > for the problem. ROTFL... this mail on ports@ is from you... :-) I suggest to contact the port maintainer with the fix. If he doesn't answer, send a PR. As soon as someone (maintainer / other committer in the PR case) has time and motivation, the fix will get committed. Bye, Alexander (ENOTIME ATM, else I would have taken care about this already). -- Gordon's first law: If a research project is not worth doing, it is not worth doing well. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From shurd at sasktel.net Sat Dec 13 23:42:38 2008 From: shurd at sasktel.net (Stephen Hurd) Date: Sat Dec 13 23:42:44 2008 Subject: BSDulator? Message-ID: <4944B1E3.1040208@sasktel.net> Rather than build and maintain a cross toolchain to build Linux binaries, it was much simpler to merely install emulators/linux_dist-gentoo-stage3. Since I also build OpenBSD and NetBSD binaries, the obvious question came to mind "Why does FreeBSD not have BSDulators?" A cursory poke around suggests that it should be relatively simple to do since the ABIs between the BSDs are generally a lot closer to each other than the ABIs between FreeBSD and Linux. Has anyone done any work in this area, and if not, does anyone have any pointers regarding how to get started on this? From bugmaster at FreeBSD.org Mon Dec 15 03:06:50 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Dec 15 03:07:46 2008 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org Message-ID: <200812151106.mBFB6omw004294@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/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 14 problems total. From nox at jelal.kn-bremen.de Thu Dec 18 15:21:58 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Thu Dec 18 15:22:05 2008 Subject: testing qemu svn r6082 on FreeBSD - virtio-net, hpet, vmmouse/vga, got bsd-user to build, and an updated version of the FreeBSD -clock dynticks patch Message-ID: <20081218231724.GA17338@saturn.kn-bremen.de> Hi! I have made another experimental FreeBSD qemu-devel port update, http://people.freebsd.org/~nox/qemu/qemu-devel-20081218.patch and can report that the new aio code, hpet and virtio-net all seem to work so far at least for the two guests I tried: sidux-2008-04-pontos-pre1-kde-lite-i386-200812141731.iso and 7.1-RC1-i386-dvd1.iso (tho both only in livecd resp. livefs i.e. fixit->cdrom mode.) Also with _this_ sidux iso even vmmouse works with cirrus emulation (and userland kqemu), the earlier vmmouse breakage I saw was in fact due to a bug in sidux. (it also wasn't enabled by default there for cirrus before.) I also was able to run this sidux iso with vmware vga emulation after disabling HW_MOUSE_ACCEL in my version of qemu/hw/vmware_vga.c, otherwise keeping the same patch as posted before. (With HW_MOUSE_ACCEL enabled my host mouse cursor still disappeared completely as soon as the guest xserver started, and either the guest hung soon after that too or I didn't wait long enough.) vmmouse as well as the vmware vga emulation itself still don't work with -kernel-kqemu tho, but I've since been told this is a known problem (something to do with userspace pio.) Oh and usb still is slow at least with sidux guests, no change there... Now bsd-user - I have no sparc64 guest, but the following patches got it to at least build on FreeBSD 6.3/i386 and 7.1pre/amd64: (the -Wl,-shared hack in qemu/Makefile.target causes the resulting binary not to start and if I try qemu's i386.ld I get a link error with libm iirc, so I guess at least the i386 case needs more work before it can actually work...) Index: qemu/cpu-exec.c @@ -1158,6 +1158,12 @@ # define EIP_sig(context) (*((unsigned long*)&(context)->uc_mcontext->ss.eip)) # define TRAP_sig(context) ((context)->uc_mcontext->es.trapno) # define ERROR_sig(context) ((context)->uc_mcontext->es.err) +#elif defined(__FreeBSD__) +# include + +# define EIP_sig(context) (*((unsigned long*)&(context)->uc_mcontext.mc_eip)) +# define TRAP_sig(context) ((context)->uc_mcontext.mc_trapno) +# define ERROR_sig(context) ((context)->uc_mcontext.mc_err) #else # define EIP_sig(context) ((context)->uc_mcontext.gregs[REG_EIP]) # define TRAP_sig(context) ((context)->uc_mcontext.gregs[REG_TRAPNO]) @@ -1168,7 +1174,11 @@ void *puc) { siginfo_t *info = pinfo; +#ifdef __FreeBSD__ + ucontext_t *uc = puc; +#else struct ucontext *uc = puc; +#endif unsigned long pc; int trapno; @@ -1194,6 +1204,12 @@ #define QEMU_UC_MCONTEXT_GREGS(uc, reg) (uc)->uc_mcontext.__gregs[(reg)] #define QEMU_UC_MACHINE_PC(uc) _UC_MACHINE_PC(uc) +#elif defined(__FreeBSD__) +# include + +# define RIP_sig(context) (*((unsigned long*)&(context)->uc_mcontext.mc_rip)) +# define TRAP_sig(context) ((context)->uc_mcontext.mc_trapno) +# define ERROR_sig(context) ((context)->uc_mcontext.mc_err) #else #define QEMU_UC_MCONTEXT_GREGS(uc, reg) (uc)->uc_mcontext.gregs[(reg)] #define QEMU_UC_MACHINE_PC(uc) QEMU_UC_MCONTEXT_GREGS(uc, REG_RIP) @@ -1204,17 +1220,25 @@ { siginfo_t *info = pinfo; unsigned long pc; -#ifdef __NetBSD__ +#if defined(__NetBSD__) || defined(__FreeBSD__) ucontext_t *uc = puc; #else struct ucontext *uc = puc; #endif +#ifdef __FreeBSD__ + pc = RIP_sig(uc); + return handle_cpu_signal(pc, (unsigned long)info->si_addr, + TRAP_sig(uc) == 0xe ? + (ERROR_sig(uc) >> 1) & 1 : 0, + &uc->uc_sigmask, puc); +#else pc = QEMU_UC_MACHINE_PC(uc); return handle_cpu_signal(pc, (unsigned long)info->si_addr, QEMU_UC_MCONTEXT_GREGS(uc, REG_TRAPNO) == 0xe ? (QEMU_UC_MCONTEXT_GREGS(uc, REG_ERR) >> 1) & 1 : 0, &uc->uc_sigmask, puc); +#endif } #elif defined(__powerpc__) Index: qemu/Makefile.target @@ -472,7 +472,7 @@ # WARNING: this LDFLAGS is _very_ tricky : qemu is an ELF shared object # that the kernel ELF loader considers as an executable. I think this # is the simplest way to make it self virtualizable! -LDFLAGS+=-Wl,-shared +#LDFLAGS+=-Wl,-shared endif endif Index: qemu/x86_64.ld @@ -2,7 +2,7 @@ OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64", "elf64-x86-64") OUTPUT_ARCH(i386:x86-64) ENTRY(_start) -SEARCH_DIR("/lib64"); SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/local/lib64"); +SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/local/lib"); SECTIONS { /* Read-only sections, merged into text segment: */ @@ -59,8 +59,6 @@ .rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) } .rodata1 : { *(.rodata1) } .eh_frame_hdr : { *(.eh_frame_hdr) } - .eh_frame : ONLY_IF_RO { KEEP (*(.eh_frame)) } - .gcc_except_table : ONLY_IF_RO { *(.gcc_except_table) } /* Adjust the address for the data segment. We want to adjust up to the same address within the page on the next page up. */ . = ALIGN (0x100000) - ((0x100000 - .) & (0x100000 - 1)); . = DATA_SEGMENT_ALIGN (0x100000, 0x1000); @@ -86,8 +84,8 @@ .data1 : { *(.data1) } .tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) } .tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) } - .eh_frame : ONLY_IF_RW { KEEP (*(.eh_frame)) } - .gcc_except_table : ONLY_IF_RW { *(.gcc_except_table) } + .eh_frame : { KEEP (*(.eh_frame)) } + .gcc_except_table : { *(.gcc_except_table) } .dynamic : { *(.dynamic) } .ctors : { And finally the updated dynticks patch: Index: qemu/configure @@ -1025,11 +1025,26 @@ rt=yes fi +########################################## +# posix timer probe +cat > $TMPC < +int main(void) { timer_create(CLOCK_REALTIME, (struct sigevent *)NULL, (timer_t *)NULL); return 0; } +EOF +posixtimer=no +if $cc $ARCH_CFLAGS -o $TMPE $TMPC 2> /dev/null ; then + posixtimer=yes +elif $cc $ARCH_CFLAGS -o $TMPE $TMPC -lrt 2> /dev/null ; then + posixtimer=yes + rt=yes +fi + if test "$rt" = "yes" ; then # Hack, we should have a general purpose LIBS for this sort of thing AIOLIBS="$AIOLIBS -lrt" fi + if test "$mingw32" = "yes" ; then if test -z "$prefix" ; then prefix="c:\\\\Program Files\\\\Qemu" @@ -1403,6 +1418,9 @@ echo "#define HAVE_FDT 1" >> $config_h echo "FDT_LIBS=-lfdt" >> $config_mak fi +if test "$posixtimer" = "yes" ; then + echo "#define HAVE_POSIX_TIMER 1" >> $config_h +fi # XXX: suppress that if [ "$bsd" = "yes" ] ; then Index: qemu/vl.c @@ -918,12 +918,16 @@ static int unix_start_timer(struct qemu_alarm_timer *t); static void unix_stop_timer(struct qemu_alarm_timer *t); -#ifdef __linux__ +#ifdef HAVE_POSIX_TIMER static int dynticks_start_timer(struct qemu_alarm_timer *t); static void dynticks_stop_timer(struct qemu_alarm_timer *t); static void dynticks_rearm_timer(struct qemu_alarm_timer *t); +#endif + +#ifdef __linux__ + static int hpet_start_timer(struct qemu_alarm_timer *t); static void hpet_stop_timer(struct qemu_alarm_timer *t); @@ -1001,9 +1005,11 @@ static struct qemu_alarm_timer alarm_timers[] = { #ifndef _WIN32 -#ifdef __linux__ +#ifdef HAVE_POSIX_TIMER {"dynticks", ALARM_FLAG_DYNTICKS, dynticks_start_timer, dynticks_stop_timer, dynticks_rearm_timer, NULL}, +#endif +#ifdef __linux__ /* HPET - if available - is preferred */ {"hpet", 0, hpet_start_timer, hpet_stop_timer, NULL, NULL}, /* ...otherwise try RTC */ @@ -1361,7 +1367,7 @@ return delta; } -#if defined(__linux__) || defined(_WIN32) +#if defined(HAVE_POSIX_TIMER) || defined(_WIN32) static uint64_t qemu_next_deadline_dyntick(void) { int64_t delta; @@ -1506,6 +1512,10 @@ close(rtc_fd); } +#endif /* defined(__linux__) */ + +#ifdef HAVE_POSIX_TIMER + static int dynticks_start_timer(struct qemu_alarm_timer *t) { struct sigevent ev; @@ -1577,7 +1587,7 @@ } } -#endif /* defined(__linux__) */ +#endif /* defined(HAVE_POSIX_TIMER) */ static int unix_start_timer(struct qemu_alarm_timer *t) { Thanx, Juergen From eagletree at hughes.net Sat Dec 20 12:45:01 2008 From: eagletree at hughes.net (Chris) Date: Sat Dec 20 12:45:07 2008 Subject: fam/gamin incompatibility Message-ID: <68D93E20-AA47-4A87-B85E-716DC59499CC@hughes.net> Hi, I apologize in advance for hitting a development list but someone on questions suggested this is the only list which could perhaps provide the answer. I'm trying to use linux compat to run an intuit (non-open-source) daemon required to make quickbooks work on Linux. I was attempting this on FreeBSD as I've never had a linux server in my net to date and was hoping to integrate the functionality into my existing FreeBSD servers. I have compat_linux set up with linux_base_fc7 port, the kern.fallback_elf_brand set to 3. compat.linux.osrelease is 2.6.16. All seems to be in order with the exception of it's use of the fam library (libfam.so) which was not found. I've attempted to use a linux fedora 9 version of the latest gamin within compatibility mode and the gam_server is unable to run because of inotify not implemented. I installed the port for FreeBSD and attempted to run the gam_server natively hoping that the linux libfam.so.0 would operate with it. The application is unable to open the socket when run. The port doesn't create directly into /tmp but into /tmp/fam it appears. Lastly I'd cluelessly tried to use the native library on the compat side which I'm assuming should never work and of course didn't due to an ABI error. Am I up against a hopeless incompatibility here or is there a way to implement the native library while not having the source for the daemon? I realize the answer may be to bite the bullet and put up a linux server. Please reply all as I'm not subscribed to the emulation list. Thanks and again sorry for bothering if this is really an off-topic. From blauwirbel at gmail.com Sat Dec 20 13:21:26 2008 From: blauwirbel at gmail.com (Blue Swirl) Date: Sat Dec 20 13:21:33 2008 Subject: [Qemu-devel] testing qemu svn r6082 on FreeBSD - virtio-net, hpet, vmmouse/vga, got bsd-user to build, and an updated version of the FreeBSD -clock dynticks patch In-Reply-To: <20081218231724.GA17338@saturn.kn-bremen.de> References: <20081218231724.GA17338@saturn.kn-bremen.de> Message-ID: On 12/19/08, Juergen Lock wrote: > +#elif defined(__FreeBSD__) > +# include > + > +# define RIP_sig(context) (*((unsigned long*)&(context)->uc_mcontext.mc_rip)) > +# define TRAP_sig(context) ((context)->uc_mcontext.mc_trapno) > +# define ERROR_sig(context) ((context)->uc_mcontext.mc_err) > #else > #define QEMU_UC_MCONTEXT_GREGS(uc, reg) (uc)->uc_mcontext.gregs[(reg)] > #define QEMU_UC_MACHINE_PC(uc) QEMU_UC_MCONTEXT_GREGS(uc, REG_RIP) > +#ifdef __FreeBSD__ > + pc = RIP_sig(uc); > + return handle_cpu_signal(pc, (unsigned long)info->si_addr, > + TRAP_sig(uc) == 0xe ? > + (ERROR_sig(uc) >> 1) & 1 : 0, > + &uc->uc_sigmask, puc); > +#else > pc = QEMU_UC_MACHINE_PC(uc); > return handle_cpu_signal(pc, (unsigned long)info->si_addr, > QEMU_UC_MCONTEXT_GREGS(uc, REG_TRAPNO) == 0xe ? > (QEMU_UC_MCONTEXT_GREGS(uc, REG_ERR) >> 1) & 1 : 0, > &uc->uc_sigmask, puc); > +#endif The idea here was that all OS define macros with same names so that the code below does not get any more complex. Maybe the GREGS macro was too generic, and should be replaced with one that only returns the trap and error values. > And finally the updated dynticks patch: This looks OK, please submit separately. From nox at jelal.kn-bremen.de Sat Dec 20 15:57:44 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sat Dec 20 15:57:51 2008 Subject: [Qemu-devel] testing qemu svn r6082 on FreeBSD - virtio-net, hpet, vmmouse/vga, got bsd-user to build, and an updated version of the FreeBSD -clock dynticks patch In-Reply-To: References: <20081218231724.GA17338@saturn.kn-bremen.de> Message-ID: <200812202345.mBKNjCUm055346@saturn.kn-bremen.de> In article you write: >On 12/19/08, Juergen Lock wrote: >> +#elif defined(__FreeBSD__) >> +# include >> + >> +# define RIP_sig(context) (*((unsigned long*)&(context)->uc_mcontext.mc_rip)) >> +# define TRAP_sig(context) ((context)->uc_mcontext.mc_trapno) >> +# define ERROR_sig(context) ((context)->uc_mcontext.mc_err) >> #else >> #define QEMU_UC_MCONTEXT_GREGS(uc, reg) (uc)->uc_mcontext.gregs[(reg)] >> #define QEMU_UC_MACHINE_PC(uc) QEMU_UC_MCONTEXT_GREGS(uc, REG_RIP) > >> +#ifdef __FreeBSD__ >> + pc = RIP_sig(uc); >> + return handle_cpu_signal(pc, (unsigned long)info->si_addr, >> + TRAP_sig(uc) == 0xe ? >> + (ERROR_sig(uc) >> 1) & 1 : 0, >> + &uc->uc_sigmask, puc); >> +#else >> pc = QEMU_UC_MACHINE_PC(uc); >> return handle_cpu_signal(pc, (unsigned long)info->si_addr, >> QEMU_UC_MCONTEXT_GREGS(uc, REG_TRAPNO) == 0xe ? >> (QEMU_UC_MCONTEXT_GREGS(uc, REG_ERR) >> 1) & 1 : 0, >> &uc->uc_sigmask, puc); >> +#endif > >The idea here was that all OS define macros with same names so that >the code below does not get any more complex. Maybe the GREGS macro >was too generic, and should be replaced with one that only returns the >trap and error values. > Yeah I was too lazy to figure out the preprocessor magic needed to get the GREGS way working so I simply reused the macros from the i386 case. :) >> And finally the updated dynticks patch: > >This looks OK, please submit separately. OK will do. Thanx, Juergen From dchagin at freebsd.org Sun Dec 21 10:18:48 2008 From: dchagin at freebsd.org (Chagin Dmitry) Date: Sun Dec 21 10:18:55 2008 Subject: [PATCH] futexes, flash9 related Message-ID: <20081221174939.GA33531@dchagin.dialup.corbina.ru> 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! -- Have fun! chd From kabaev at gmail.com Sun Dec 21 11:40:42 2008 From: kabaev at gmail.com (Alexander Kabaev) Date: Sun Dec 21 11:40:48 2008 Subject: [PATCH] futexes, flash9 related In-Reply-To: <20081221174939.GA33531@dchagin.dialup.corbina.ru> References: <20081221174939.GA33531@dchagin.dialup.corbina.ru> Message-ID: <20081221141410.169d13e3@kan.dnsalias.net> On Sun, 21 Dec 2008 20:49:39 +0300 Chagin Dmitry wrote: > http://people.freebsd.org/~timur/dchagin/mega-head.linux.patch The patch contains lots of unrelated changes which should go in separately. -- Alexander Kabaev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20081221/bb442663/signature.pgp From bugmaster at FreeBSD.org Mon Dec 22 03:06:50 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Dec 22 03:07:45 2008 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org Message-ID: <200812221106.mBMB6n0D060535@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/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 14 problems total. From arno at heho.snv.jussieu.fr Sat Dec 27 13:07:15 2008 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Sat Dec 27 13:07:22 2008 Subject: LORs on 8-current kernel with 7-stable world Message-ID: Hello, I get these when running a 8-current kernel with 7-stable world. I can'f access http://sources.zabbadoz.net/freebsd/lor.html to see if they are known. fyi, Arno #### lock order reversal: 1st 0xffffff0001305070 user map (user map) @ /raid1/bsd/src-current/sys/vm/vm_map.c:3115 2nd 0xffffff0001502270 ufs (ufs) @ /raid1/bsd/src-current/sys/kern/vfs_subr.c:2079 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x65 witness_checkorder() at witness_checkorder+0x859 __lockmgr_args() at __lockmgr_args+0xcb8 ffs_lock() at ffs_lock+0x8f VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x57 vget() at vget+0x8b vnode_pager_lock() at vnode_pager_lock+0x1d0 vm_fault() at vm_fault+0x22a trap_pfault() at trap_pfault+0x127 trap() at trap+0x51c calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x40014f, rsp = 0x7fffffffee70, rbp = 0x7fffffffee90 --- lock order reversal: 1st 0xffffff0001aa3098 pseudofs (pseudofs) @ /raid1/bsd/src-current/sys/kern/vfs_vnops.c:531 2nd 0xffffff00015027f8 ufs (ufs) @ /raid1/bsd/src-current/sys/kern/vfs_lookup.c:442 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x65 witness_checkorder() at witness_checkorder+0x859 __lockmgr_args() at __lockmgr_args+0xcb8 ffs_lock() at ffs_lock+0x8f VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x57 lookup() at lookup+0x103 namei() at namei+0x52d linprocfs_domtab() at linprocfs_domtab+0x76 pfs_read() at pfs_read+0x53c vn_read() at vn_read+0x267 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 ia32_syscall() at ia32_syscall+0x1ab Xint0x80_syscall() at Xint0x80_syscall+0x60 --- syscall (3, Linux ELF32, read), rip = 0x28162cee, rsp = 0xffffdca8, rbp = 0xffffdcbc --- lock order reversal: 1st 0xfffffffe68494f20 bufwait (bufwait) @ /raid1/bsd/src-current/sys/kern/vfs_bio.c:2443 2nd 0xffffff0001c7d000 dirhash (dirhash) @ /raid1/bsd/src-current/sys/ufs/ufs/ufs_dirhash.c:263 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x65 witness_checkorder() at witness_checkorder+0x859 _sx_xlock() at _sx_xlock+0x55 ufsdirhash_acquire() at ufsdirhash_acquire+0x33 ufsdirhash_remove() at ufsdirhash_remove+0x16 ufs_dirremove() at ufs_dirremove+0x181 ufs_remove() at ufs_remove+0x92 VOP_REMOVE_APV() at VOP_REMOVE_APV+0x93 kern_unlinkat() at kern_unlinkat+0x249 linux_unlinkat() at linux_unlinkat+0xa6 ia32_syscall() at ia32_syscall+0x1ab Xint0x80_syscall() at Xint0x80_syscall+0x60 --- syscall (301, Linux ELF32, linux_unlinkat), rip = 0x28126968, rsp = 0xffffd4e8, rbp = 0xffffd508 --- From arno at heho.snv.jussieu.fr Sat Dec 27 13:41:30 2008 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Sat Dec 27 13:41:37 2008 Subject: 7-stable: linux_dist-gentoo-stage3 wonn't bootstrap Message-ID: Hello, I'm having serious problems to get MedInria (a medical imaging toolchain) run under Linux emulation ( http://gforge.inria.fr/frs/?group_id=727&release_id=2488 if ever someone would like to try : at my place even the simplest graphical action (change tool, open file, etc) literally exploses the X-server ...) so I thought to run it in debugger etc in the chroot gentoo : but its bootstrap.sh will not complete, for the time being because of : - compat.linux.osrelease 2.4.2 is not supported - so I installed fc6 and set compat.linux.osrelease to 2.6.16 but then the chroot complains with many errors like : - (find): syscall fstatat64 not implemented - (rm): syscall unlinkat not implemented - (tar): syscall futimesat not implemented - (chmod): syscall fchmodat not implemented So : - does someone have a patch with these at-functions (or the svn command to create it) - or can I even bluntly copy the linuxulator from head to releng_7 ? Thanx in advance. Arno From rdivacky at freebsd.org Sat Dec 27 14:28:33 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Sat Dec 27 14:28:39 2008 Subject: 7-stable: linux_dist-gentoo-stage3 wonn't bootstrap In-Reply-To: References: Message-ID: <20081227220645.GA13295@freebsd.org> On Sat, Dec 27, 2008 at 09:55:05PM +0100, Arno J. Klaassen wrote: > > Hello, > > I'm having serious problems to get MedInria (a medical imaging > toolchain) run under Linux emulation > ( http://gforge.inria.fr/frs/?group_id=727&release_id=2488 > if ever someone would like to try : at my place even the > simplest graphical action (change tool, open file, etc) > literally exploses the X-server ...) > > so I thought to run it in debugger etc in the > chroot gentoo : but its bootstrap.sh will not complete, > for the time being because of : > > > - compat.linux.osrelease 2.4.2 is not supported > > - so I installed fc6 and set compat.linux.osrelease to 2.6.16 > but then the chroot complains with many errors like : > > - (find): syscall fstatat64 not implemented > - (rm): syscall unlinkat not implemented > - (tar): syscall futimesat not implemented > - (chmod): syscall fchmodat not implemented > > So : > - does someone have a patch with these at-functions > (or the svn command to create it) that would not be easy.... but 8-current implements those > - or can I even bluntly copy the linuxulator from head > to releng_7 ? no... I doubt that would work. try 8-current and stick with that if it works From yanefbsd at gmail.com Sat Dec 27 15:07:56 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Sat Dec 27 15:08:03 2008 Subject: LORs on 8-current kernel with 7-stable world In-Reply-To: References: Message-ID: <57AC84CF-CFA9-4F27-A643-954DD3195221@gmail.com> On Dec 27, 2008, at 13:07, "Arno J. Klaassen" wrote: > > Hello, > > I get these when running a 8-current kernel with 7-stable world. > I can'f access http://sources.zabbadoz.net/freebsd/lor.html > to see if they are known. > > fyi, Arno > > #### > > > lock order reversal: > 1st 0xffffff0001305070 user map (user map) @ /raid1/bsd/src-current/ > sys/vm/vm_map.c:3115 > 2nd 0xffffff0001502270 ufs (ufs) @ /raid1/bsd/src-current/sys/kern/ > vfs_subr.c:2079 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x65 > witness_checkorder() at witness_checkorder+0x859 > __lockmgr_args() at __lockmgr_args+0xcb8 > ffs_lock() at ffs_lock+0x8f > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > _vn_lock() at _vn_lock+0x57 > vget() at vget+0x8b > vnode_pager_lock() at vnode_pager_lock+0x1d0 > vm_fault() at vm_fault+0x22a > trap_pfault() at trap_pfault+0x127 > trap() at trap+0x51c > calltrap() at calltrap+0x8 > --- trap 0xc, rip = 0x40014f, rsp = 0x7fffffffee70, rbp = > 0x7fffffffee90 --- > > > lock order reversal: > 1st 0xffffff0001aa3098 pseudofs (pseudofs) @ /raid1/bsd/src-current/ > sys/kern/vfs_vnops.c:531 > 2nd 0xffffff00015027f8 ufs (ufs) @ /raid1/bsd/src-current/sys/kern/ > vfs_lookup.c:442 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x65 > witness_checkorder() at witness_checkorder+0x859 > __lockmgr_args() at __lockmgr_args+0xcb8 > ffs_lock() at ffs_lock+0x8f > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > _vn_lock() at _vn_lock+0x57 > lookup() at lookup+0x103 > namei() at namei+0x52d > linprocfs_domtab() at linprocfs_domtab+0x76 > pfs_read() at pfs_read+0x53c > vn_read() at vn_read+0x267 > dofileread() at dofileread+0xa1 > kern_readv() at kern_readv+0x60 > read() at read+0x54 > ia32_syscall() at ia32_syscall+0x1ab > Xint0x80_syscall() at Xint0x80_syscall+0x60 > --- syscall (3, Linux ELF32, read), rip = 0x28162cee, rsp = > 0xffffdca8, rbp = 0xffffdcbc --- > > > lock order reversal: > 1st 0xfffffffe68494f20 bufwait (bufwait) @ /raid1/bsd/src-current/ > sys/kern/vfs_bio.c:2443 > 2nd 0xffffff0001c7d000 dirhash (dirhash) @ /raid1/bsd/src-current/ > sys/ufs/ufs/ufs_dirhash.c:263 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x65 > witness_checkorder() at witness_checkorder+0x859 > _sx_xlock() at _sx_xlock+0x55 > ufsdirhash_acquire() at ufsdirhash_acquire+0x33 > ufsdirhash_remove() at ufsdirhash_remove+0x16 > ufs_dirremove() at ufs_dirremove+0x181 > ufs_remove() at ufs_remove+0x92 > VOP_REMOVE_APV() at VOP_REMOVE_APV+0x93 > kern_unlinkat() at kern_unlinkat+0x249 > linux_unlinkat() at linux_unlinkat+0xa6 > ia32_syscall() at ia32_syscall+0x1ab > Xint0x80_syscall() at Xint0x80_syscall+0x60 > --- syscall (301, Linux ELF32, linux_unlinkat), rip = 0x28126968, > rsp = 0xffffd4e8, rbp = 0xffffd508 --- Do an installworld and reboot? This datapoint shouldn't have any relevance because you're mixing and matching major versions of components which I wouldn't expect to work necessarily. -Garrett From rdivacky at freebsd.org Sun Dec 28 00:36:09 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Sun Dec 28 00:36:21 2008 Subject: LORs on 8-current kernel with 7-stable world In-Reply-To: <57AC84CF-CFA9-4F27-A643-954DD3195221@gmail.com> References: <57AC84CF-CFA9-4F27-A643-954DD3195221@gmail.com> Message-ID: <20081228083043.GA80332@freebsd.org> > Do an installworld and reboot? This datapoint shouldn't have any > relevance because you're mixing and matching major versions of > components which I wouldn't expect to work necessarily. I believe that kernel should survive just fine anything that userland throws at it... including 7-world :) From arno at heho.snv.jussieu.fr Sun Dec 28 05:56:56 2008 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Sun Dec 28 05:57:04 2008 Subject: 7-stable: linux_dist-gentoo-stage3 wonn't bootstrap In-Reply-To: <20081227220645.GA13295@freebsd.org> References: <20081227220645.GA13295@freebsd.org> Message-ID: Roman Divacky writes: > On Sat, Dec 27, 2008 at 09:55:05PM +0100, Arno J. Klaassen wrote: > > > > Hello, > > > > I'm having serious problems to get MedInria (a medical imaging > > toolchain) run under Linux emulation > > ( http://gforge.inria.fr/frs/?group_id=727&release_id=2488 > > if ever someone would like to try : at my place even the > > simplest graphical action (change tool, open file, etc) > > literally exploses the X-server ...) > > > > so I thought to run it in debugger etc in the > > chroot gentoo : but its bootstrap.sh will not complete, > > for the time being because of : > > > > > > - compat.linux.osrelease 2.4.2 is not supported > > > > - so I installed fc6 and set compat.linux.osrelease to 2.6.16 > > but then the chroot complains with many errors like : > > > > - (find): syscall fstatat64 not implemented > > - (rm): syscall unlinkat not implemented > > - (tar): syscall futimesat not implemented > > - (chmod): syscall fchmodat not implemented > > > > So : > > - does someone have a patch with these at-functions > > (or the svn command to create it) > > that would not be easy.... but 8-current implements those OK, but the maybe the linux_dist-gentoo-stage3 should be marked BROKEN on <8 > > - or can I even bluntly copy the linuxulator from head > > to releng_7 ? > > no... I doubt that would work. > > > try 8-current and stick with that if it works OK, I upgraded this box to 8-current; now the bootstrap.sh 'hangs' when compiling gconv_simple.c (I can provide whole command line ) : top(1) shows : 17547 root 1 76 0 4640K 4048K ppwait 0:05 0.00% gmake 23865 root 1 76 0 4596K 4176K ppwait 0:02 0.00% gmake 23899 root 1 76 0 18152K 16808K pipewr 0:01 0.00% cc1 15076 root 1 76 0 1672K 872K wait 0:00 0.00% sandbox 23898 root 1 76 0 2296K 1428K ppwait 0:00 0.00% i486-pc-linux and dmesg(1) says : t_delta 15.fcd4d7d810818e80 too short lock order reversal: 1st 0xffffff0024436ba8 pseudofs (pseudofs) @ /raid1/bsd/src-current/sys/kern/vfs_vnops.c:531 2nd 0xffffffff80729360 sysctl lock (sysctl lock) @ /raid1/bsd/src-current/sys/kern/kern_sysctl.c:1088 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x65 witness_checkorder() at witness_checkorder+0x859 _sx_xlock() at _sx_xlock+0x55 kernel_sysctl() at kernel_sysctl+0xbc linprocfs_docpuinfo() at linprocfs_docpuinfo+0x84 pfs_read() at pfs_read+0x53c vn_read() at vn_read+0x267 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 ia32_syscall() at ia32_syscall+0x1ab Xint0x80_syscall() at Xint0x80_syscall+0x60 --- syscall (3, Linux ELF32, read), rip = 0x2812ae7e, rsp = 0xffff9c24, rbp = 0xffff9c38 --- NB, linprocfs is mounted on /compat/linux/proc as well as /usr/local/gentoo-stage3/proc Let me know if you need more info; I'll leave the box in this state for a while Arno From patfbsd at davenulle.org Sun Dec 28 07:32:15 2008 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Sun Dec 28 07:32:22 2008 Subject: LORs on 8-current kernel with 7-stable world In-Reply-To: References: Message-ID: <20081228161343.3cfa62a3@baby-jane-lamaiziere-net.local> Le 27 Dec 2008 22:07:12 +0100, "Arno J. Klaassen" a ?crit : > Hello, > > I get these when running a 8-current kernel with 7-stable world. > I can'f access http://sources.zabbadoz.net/freebsd/lor.html > to see if they are known. > lock order reversal: > 1st 0xfffffffe68494f20 bufwait (bufwait) > @ /raid1/bsd/src-current/sys/kern/vfs_bio.c:2443 2nd > 0xffffff0001c7d000 dirhash (dirhash) > @ /raid1/bsd/src-current/sys/ufs/ufs/ufs_dirhash.c:263 KDB: stack > backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x65 witness_checkorder() at > witness_checkorder+0x859 _sx_xlock() at _sx_xlock+0x55 > ufsdirhash_acquire() at ufsdirhash_acquire+0x33 > ufsdirhash_remove() at ufsdirhash_remove+0x16 > ufs_dirremove() at ufs_dirremove+0x181 > ufs_remove() at ufs_remove+0x92 > VOP_REMOVE_APV() at VOP_REMOVE_APV+0x93 > kern_unlinkat() at kern_unlinkat+0x249 > linux_unlinkat() at linux_unlinkat+0xa6 > ia32_syscall() at ia32_syscall+0x1ab > Xint0x80_syscall() at Xint0x80_syscall+0x60 > --- syscall (301, Linux ELF32, linux_unlinkat), rip = 0x28126968, rsp > = 0xffffd4e8, rbp = 0xffffd508 --- I see this one on a 'pure' CURRENT lock order reversal: 1st 0xc297ba60 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 2nd 0xc2ec8c00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:263 KDB: stack backtrace: db_trace_self_wrapper(c080b620,d6108778,c05aaf45,4,c08070aa,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c08070aa,c2c0f128,c2c11d08,d61087d4,...) at kdb_backtrace+0x29 _witness_debugger(c080e0d7,c2ec8c00,c082aef4,c2c11d08,c082ab8d,...) at _witness_debugger+0x25 witness_checkorder(c2ec8c00,9,c082ab8d,107,0,...) at witness_checkorder+0x839 _sx_xlock(c2ec8c00,0,c082ab8d,107,c31010f0,...) at _sx_xlock+0x85 ufsdirhash_acquire(c297ba00,cde06800,200,cde06818,d61088a4,...) at ufsdirhash_acquire+0x35 ufsdirhash_add(c31010f0,d61088ec,818,d6108890,d6108894,...) at ufsdirhash_add+0x13 ufs_direnter(c2edd10c,c31cd10c,d61088ec,d6108bd4,0,...) at ufs_direnter+0x729 ufs_makeinode(d6108bd4,d6108acc,d6108acc,d6108a34,c07d0295,...) at ufs_makeinode+0x519 ufs_create(d6108acc,d6108acc,0,d6108acc,d6108ba8,...) at ufs_create+0x30 VOP_CREATE_APV(c0876c20,d6108acc,2,c0801ca7,3,...) at VOP_CREATE_APV+0xa5 vn_open_cred(d6108ba8,d6108c5c,1e4,c31a5800,c31922a0,...) at vn_open_cred+0x1d0 vn_open(d6108ba8,d6108c5c,1e4,c31922a0,246,...) at vn_open+0x33 kern_openat(c2e81000,ffffff9c,bfbfe640,0,a02,...) at kern_openat+0x110 kern_open(c2e81000,bfbfe640,0,a01,1e4,...) at kern_open+0x35 open(c2e81000,d6108cf8,c,c080ec0b,c0854438,...) at open+0x30 syscall(d6108d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip = 0x2075d2b3, esp = 0xbfbfdf6c, ebp = 0xbfbfdf98 --- From pluknet at gmail.com Sun Dec 28 08:56:14 2008 From: pluknet at gmail.com (pluknet) Date: Sun Dec 28 08:56:21 2008 Subject: LORs on 8-current kernel with 7-stable world In-Reply-To: <20081228161343.3cfa62a3@baby-jane-lamaiziere-net.local> References: <20081228161343.3cfa62a3@baby-jane-lamaiziere-net.local> Message-ID: 2008/12/28 Patrick Lamaizi?re : > Le 27 Dec 2008 22:07:12 +0100, > "Arno J. Klaassen" a ?crit : > >> Hello, >> >> I get these when running a 8-current kernel with 7-stable world. >> I can'f access http://sources.zabbadoz.net/freebsd/lor.html >> to see if they are known. > >> lock order reversal: >> 1st 0xfffffffe68494f20 bufwait (bufwait) >> @ /raid1/bsd/src-current/sys/kern/vfs_bio.c:2443 2nd >> 0xffffff0001c7d000 dirhash (dirhash) >> @ /raid1/bsd/src-current/sys/ufs/ufs/ufs_dirhash.c:263 KDB: stack >> backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >> _witness_debugger() at _witness_debugger+0x65 witness_checkorder() at >> witness_checkorder+0x859 _sx_xlock() at _sx_xlock+0x55 >> ufsdirhash_acquire() at ufsdirhash_acquire+0x33 >> ufsdirhash_remove() at ufsdirhash_remove+0x16 >> ufs_dirremove() at ufs_dirremove+0x181 >> ufs_remove() at ufs_remove+0x92 >> VOP_REMOVE_APV() at VOP_REMOVE_APV+0x93 >> kern_unlinkat() at kern_unlinkat+0x249 >> linux_unlinkat() at linux_unlinkat+0xa6 >> ia32_syscall() at ia32_syscall+0x1ab >> Xint0x80_syscall() at Xint0x80_syscall+0x60 >> --- syscall (301, Linux ELF32, linux_unlinkat), rip = 0x28126968, rsp >> = 0xffffd4e8, rbp = 0xffffd508 --- > > I see this one on a 'pure' CURRENT > lock order reversal: > 1st 0xc297ba60 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 > 2nd 0xc2ec8c00 dirhash (dirhash) > @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:263 KDB: stack backtrace: > db_trace_self_wrapper(c080b620,d6108778,c05aaf45,4,c08070aa,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(4,c08070aa,c2c0f128,c2c11d08,d61087d4,...) at > kdb_backtrace+0x29 > _witness_debugger(c080e0d7,c2ec8c00,c082aef4,c2c11d08,c082ab8d,...) at > _witness_debugger+0x25 > witness_checkorder(c2ec8c00,9,c082ab8d,107,0,...) at > witness_checkorder+0x839 > _sx_xlock(c2ec8c00,0,c082ab8d,107,c31010f0,...) at _sx_xlock+0x85 > ufsdirhash_acquire(c297ba00,cde06800,200,cde06818,d61088a4,...) at > ufsdirhash_acquire+0x35 > ufsdirhash_add(c31010f0,d61088ec,818,d6108890,d6108894,...) at > ufsdirhash_add+0x13 > ufs_direnter(c2edd10c,c31cd10c,d61088ec,d6108bd4,0,...) at > ufs_direnter+0x729 > ufs_makeinode(d6108bd4,d6108acc,d6108acc,d6108a34,c07d0295,...) at > ufs_makeinode+0x519 > ufs_create(d6108acc,d6108acc,0,d6108acc,d6108ba8,...) at > ufs_create+0x30 VOP_CREATE_APV(c0876c20,d6108acc,2,c0801ca7,3,...) at > VOP_CREATE_APV+0xa5 > vn_open_cred(d6108ba8,d6108c5c,1e4,c31a5800,c31922a0,...) at > vn_open_cred+0x1d0 vn_open(d6108ba8,d6108c5c,1e4,c31922a0,246,...) at > vn_open+0x33 kern_openat(c2e81000,ffffff9c,bfbfe640,0,a02,...) at > kern_openat+0x110 kern_open(c2e81000,bfbfe640,0,a01,1e4,...) at > kern_open+0x35 open(c2e81000,d6108cf8,c,c080ec0b,c0854438,...) at > open+0x30 syscall(d6108d38) at syscall+0x2a3 Xint0x80_syscall() at > Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip = > 0x2075d2b3, esp = 0xbfbfdf6c, ebp = 0xbfbfdf98 --- These all are known. See -current archives. -- wbr, pluknet From rdivacky at freebsd.org Sun Dec 28 10:21:42 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Sun Dec 28 10:21:49 2008 Subject: 7-stable: linux_dist-gentoo-stage3 wonn't bootstrap In-Reply-To: References: <20081227220645.GA13295@freebsd.org> Message-ID: <20081228175745.GA56640@freebsd.org> > > > So : > > > - does someone have a patch with these at-functions > > > (or the svn command to create it) > > > > that would not be easy.... but 8-current implements those > > OK, but the maybe the linux_dist-gentoo-stage3 should be marked > BROKEN on <8 maybe, can someone commit a fix to this? > > > - or can I even bluntly copy the linuxulator from head > > > to releng_7 ? > > > > no... I doubt that would work. > > > > > > try 8-current and stick with that if it works > > OK, I upgraded this box to 8-current; now the bootstrap.sh > 'hangs' when compiling gconv_simple.c (I can provide > whole command line ) : > > top(1) shows : > > 17547 root 1 76 0 4640K 4048K ppwait 0:05 0.00% gmake > 23865 root 1 76 0 4596K 4176K ppwait 0:02 0.00% gmake > 23899 root 1 76 0 18152K 16808K pipewr 0:01 0.00% cc1 > 15076 root 1 76 0 1672K 872K wait 0:00 0.00% sandbox > 23898 root 1 76 0 2296K 1428K ppwait 0:00 0.00% i486-pc-linux > > and dmesg(1) says : > > t_delta 15.fcd4d7d810818e80 too short > lock order reversal: > 1st 0xffffff0024436ba8 pseudofs (pseudofs) @ /raid1/bsd/src-current/sys/kern/vfs_vnops.c:531 > 2nd 0xffffffff80729360 sysctl lock (sysctl lock) @ /raid1/bsd/src-current/sys/kern/kern_sysctl.c:1088 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x65 > witness_checkorder() at witness_checkorder+0x859 > _sx_xlock() at _sx_xlock+0x55 > kernel_sysctl() at kernel_sysctl+0xbc > linprocfs_docpuinfo() at linprocfs_docpuinfo+0x84 > pfs_read() at pfs_read+0x53c > vn_read() at vn_read+0x267 > dofileread() at dofileread+0xa1 > kern_readv() at kern_readv+0x60 > read() at read+0x54 > ia32_syscall() at ia32_syscall+0x1ab > Xint0x80_syscall() at Xint0x80_syscall+0x60 > --- syscall (3, Linux ELF32, read), rip = 0x2812ae7e, rsp = 0xffff9c24, rbp = 0xffff9c38 --- > > > NB, linprocfs is mounted on /compat/linux/proc as well > as /usr/local/gentoo-stage3/proc > > Let me know if you need more info; I'll leave the box in this state > for a while does this patch fix the hang? www.vlakno.cz/~rdivacky/linprocfs.patch roman From arno at heho.snv.jussieu.fr Sun Dec 28 13:42:48 2008 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Sun Dec 28 13:42:56 2008 Subject: 7-stable: linux_dist-gentoo-stage3 wonn't bootstrap In-Reply-To: <20081228211505.GA80323@freebsd.org> References: <20081227220645.GA13295@freebsd.org> <20081228175745.GA56640@freebsd.org> <20081228202526.GA74948@freebsd.org> <20081228211505.GA80323@freebsd.org> Message-ID: Roman Divacky writes: > On Sun, Dec 28, 2008 at 09:38:09PM +0100, Arno J. Klaassen wrote: > > > > Roman Divacky writes: > > > > > > > > > > > > does this patch fix the hang? > > > > > > > > > > www.vlakno.cz/~rdivacky/linprocfs.patch > > > > > > > > nope, though it does fix the lock order reversal > > > > (I attach the slightly modified patch for linprocfs.c to > > > > make it compile) > > > > > > the LOR is probably harmless.... dont bother with that patch :) > > > > > > > funny enough, it again hangs in compiling gconv_simple.c > > > > with cc1 in pipewr state and no assembler showing up in > > > > ps(1) after having succesfully compiled a bunch of other > > > > files. > > > > > > you mean native cc1? or linux one? > > > > linux : > > > > # ps axuww | fgrep 1129 > > root 11290 0.0 0.1 2296 1432 0 D 8:29PM 0:00.01 [i486-pc-linux-gnu-g] > > root 11291 0.0 0.8 18152 16808 0 I 8:29PM 0:00.96 [cc1] > > > > and no trace of gconv_simple.o > > > > last line of log-file is : > > > > i486-pc-linux-gnu-gcc gconv_simple.c -c -std=gnu99 -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -fno-strict-aliasing -mtune=i686 -pipe -Wstrict-prototypes -mpreferred-stack-boundary=2 -I../include -I/var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv -I/var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl -I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sysv/linux/i386/i486 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../ports/sysdeps/unix/sysv/linux -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../ports/sysdeps/unix/sysv/i386 -I../sysdeps/unix/sysv/i386 -I../nptl/sysdeps/unix/sysv -I../ports/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../nptl/sysdeps/unix -I../ports/sysdeps/unix -I../sysdeps/unix! -I.! > > ./sysdeps/posix -I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../nptl/sysdeps/i386 -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I../ports -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/include -isystem /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/include-fixed -isystem /usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -o /var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv/gconv_simple.o -MD -MP -MF /var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv/gconv_simple.o.dt -MT /var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv/gconv_simple.o > > > > > > ++, Arno > > > > can you break into DDB and extract a backtrace of the stuck process? OK, I'll hook up a serconsole tomorrow .. for now some good old quick n dirty copy paste by pen and paper : 11290 (i486-pc-linux-gnu-gcc] sched_switch mi_switch sleepq_switch sleepq_wait _sleep linux_vfork ia32_syscall Xint0x80_syscall syscall (190, Linux ELF32, linux_vfork) 11291 (cc1) sched_switch mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep pipe_write dofilewrite kern_writev write ia32_syscall Xint80_syscall syscall (4, Linux ELF32, write) Thanx for your help. Arno From rdivacky at freebsd.org Sun Dec 28 13:50:04 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Sun Dec 28 13:50:12 2008 Subject: 7-stable: linux_dist-gentoo-stage3 wonn't bootstrap In-Reply-To: References: <20081227220645.GA13295@freebsd.org> <20081228175745.GA56640@freebsd.org> <20081228202526.GA74948@freebsd.org> <20081228211505.GA80323@freebsd.org> Message-ID: <20081228214438.GA83007@freebsd.org> On Sun, Dec 28, 2008 at 10:42:44PM +0100, Arno J. Klaassen wrote: > Roman Divacky writes: > > > On Sun, Dec 28, 2008 at 09:38:09PM +0100, Arno J. Klaassen wrote: > > > > > > Roman Divacky writes: > > > > > > > > > > > > > > > does this patch fix the hang? > > > > > > > > > > > > www.vlakno.cz/~rdivacky/linprocfs.patch > > > > > > > > > > nope, though it does fix the lock order reversal > > > > > (I attach the slightly modified patch for linprocfs.c to > > > > > make it compile) > > > > > > > > the LOR is probably harmless.... dont bother with that patch :) > > > > > > > > > funny enough, it again hangs in compiling gconv_simple.c > > > > > with cc1 in pipewr state and no assembler showing up in > > > > > ps(1) after having succesfully compiled a bunch of other > > > > > files. > > > > > > > > you mean native cc1? or linux one? > > > > > > linux : > > > > > > # ps axuww | fgrep 1129 > > > root 11290 0.0 0.1 2296 1432 0 D 8:29PM 0:00.01 [i486-pc-linux-gnu-g] > > > root 11291 0.0 0.8 18152 16808 0 I 8:29PM 0:00.96 [cc1] > > > > > > and no trace of gconv_simple.o > > > > > > last line of log-file is : > > > > > > i486-pc-linux-gnu-gcc gconv_simple.c -c -std=gnu99 -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -fno-strict-aliasing -mtune=i686 -pipe -Wstrict-prototypes -mpreferred-stack-boundary=2 -I../include -I/var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv -I/var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl -I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sysv/linux/i386/i486 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../ports/sysdeps/unix/sysv/linux -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../ports/sysdeps/unix/sysv/i386 -I../sysdeps/unix/sysv/i386 -I../nptl/sysdeps/unix/sysv -I../ports/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../nptl/sysdeps/unix -I../ports/sysdeps/unix -I../sysdeps/unix! > -I.! > > > ./sysdeps/posix -I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../nptl/sysdeps/i386 -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I../ports -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/include -isystem /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/include-fixed -isystem /usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -o /var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv/gconv_simple.o -MD -MP -MF /var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv/gconv_simple.o.dt -MT /var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv/gconv_simple.o > > > > > > > > > ++, Arno > > > > > > > can you break into DDB and extract a backtrace of the stuck process? > > OK, I'll hook up a serconsole tomorrow .. > > for now some good old quick n dirty copy paste by pen and paper : > > 11290 (i486-pc-linux-gnu-gcc] > > sched_switch > mi_switch > sleepq_switch > sleepq_wait > _sleep > linux_vfork > ia32_syscall > Xint0x80_syscall > syscall (190, Linux ELF32, linux_vfork) > > > 11291 (cc1) > > sched_switch > mi_switch > sleepq_switch > sleepq_catch_signals > sleepq_wait_sig > _sleep > pipe_write > dofilewrite > kern_writev > write > ia32_syscall > Xint80_syscall > syscall (4, Linux ELF32, write) I dont see anything obvious.. can you do "ps axl" and see what the MWCHAN is? that might shed some light to this... From arno at heho.snv.jussieu.fr Sun Dec 28 14:59:12 2008 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Sun Dec 28 14:59:19 2008 Subject: 7-stable: linux_dist-gentoo-stage3 wonn't bootstrap In-Reply-To: <20081228214438.GA83007@freebsd.org> References: <20081227220645.GA13295@freebsd.org> <20081228175745.GA56640@freebsd.org> <20081228202526.GA74948@freebsd.org> <20081228211505.GA80323@freebsd.org> <20081228214438.GA83007@freebsd.org> Message-ID: Roman Divacky writes: > On Sun, Dec 28, 2008 at 10:42:44PM +0100, Arno J. Klaassen wrote: > > Roman Divacky writes: > > > > > On Sun, Dec 28, 2008 at 09:38:09PM +0100, Arno J. Klaassen wrote: > > > > > > > > Roman Divacky writes: > > > > > > > > > > > > > > > > > > does this patch fix the hang? > > > > > > > > > > > > > > www.vlakno.cz/~rdivacky/linprocfs.patch > > > > > > > > > > > > nope, though it does fix the lock order reversal > > > > > > (I attach the slightly modified patch for linprocfs.c to > > > > > > make it compile) > > > > > > > > > > the LOR is probably harmless.... dont bother with that patch :) > > > > > > > > > > > funny enough, it again hangs in compiling gconv_simple.c > > > > > > with cc1 in pipewr state and no assembler showing up in > > > > > > ps(1) after having succesfully compiled a bunch of other > > > > > > files. > > > > > > > > > > you mean native cc1? or linux one? > > > > > > > > linux : > > > > > > > > # ps axuww | fgrep 1129 > > > > root 11290 0.0 0.1 2296 1432 0 D 8:29PM 0:00.01 [i486-pc-linux-gnu-g] > > > > root 11291 0.0 0.8 18152 16808 0 I 8:29PM 0:00.96 [cc1] > > > > > > > > and no trace of gconv_simple.o > > > > > > > > last line of log-file is : > > > > > > > > i486-pc-linux-gnu-gcc gconv_simple.c -c -std=gnu99 -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -fno-strict-aliasing -mtune=i686 -pipe -Wstrict-prototypes -mpreferred-stack-boundary=2 -I../include -I/var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv -I/var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl -I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sysv/linux/i386/i486 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../ports/sysdeps/unix/sysv/linux -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../ports/sysdeps/unix/sysv/i386 -I../sysdeps/unix/sysv/i386 -I../nptl/sysdeps/unix/sysv -I../ports/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../nptl/sysdeps/unix -I../ports/sysdeps/unix -I../sysdeps/! unix! > > -I.! > > > > ./sysdeps/posix -I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../nptl/sysdeps/i386 -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I../ports -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/include -isystem /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/include-fixed -isystem /usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -o /var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv/gconv_simple.o -MD -MP -MF /var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv/gconv_simple.o.dt -MT /var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv/gconv_simple.o > > > > > > > > > > > > ++, Arno > > > > > > > > > > can you break into DDB and extract a backtrace of the stuck process? > > > > OK, I'll hook up a serconsole tomorrow .. > > > > for now some good old quick n dirty copy paste by pen and paper : > > > > 11290 (i486-pc-linux-gnu-gcc] > > > > sched_switch > > mi_switch > > sleepq_switch > > sleepq_wait > > _sleep > > linux_vfork > > ia32_syscall > > Xint0x80_syscall > > syscall (190, Linux ELF32, linux_vfork) > > > > > > 11291 (cc1) > > > > sched_switch > > mi_switch > > sleepq_switch > > sleepq_catch_signals > > sleepq_wait_sig > > _sleep > > pipe_write > > dofilewrite > > kern_writev > > write > > ia32_syscall > > Xint80_syscall > > syscall (4, Linux ELF32, write) > > I dont see anything obvious.. can you do "ps axl" and see what the MWCHAN is? > that might shed some light to this... 0 11290 11257 0 76 0 2296 1432 ppwait D 0 0:00.00 [i486-pc-linux-gnu-g] 0 11291 11290 0 76 0 18152 16808 pipewr I 0 0:00.01 [cc1] ++, Arno From arno at heho.snv.jussieu.fr Mon Dec 29 01:47:52 2008 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Mon Dec 29 01:47:59 2008 Subject: 8-current: linux_dist-gentoo-stage3 wonn't bootstrap In-Reply-To: <20081228214438.GA83007@freebsd.org> References: <20081227220645.GA13295@freebsd.org> <20081228175745.GA56640@freebsd.org> <20081228202526.GA74948@freebsd.org> <20081228211505.GA80323@freebsd.org> <20081228214438.GA83007@freebsd.org> Message-ID: [NB, subject changed; this bug is produce now on -current ] Roman Divacky writes: > On Sun, Dec 28, 2008 at 10:42:44PM +0100, Arno J. Klaassen wrote: > > Roman Divacky writes: > > > > > On Sun, Dec 28, 2008 at 09:38:09PM +0100, Arno J. Klaassen wrote: > > > > > > > > Roman Divacky writes: > > > > > > > > > > > > > > > > > > does this patch fix the hang? > > > > > > > > > > > > > > www.vlakno.cz/~rdivacky/linprocfs.patch > > > > > > > > > > > > nope, though it does fix the lock order reversal > > > > > > (I attach the slightly modified patch for linprocfs.c to > > > > > > make it compile) > > > > > > > > > > the LOR is probably harmless.... dont bother with that patch :) > > > > > > > > > > > funny enough, it again hangs in compiling gconv_simple.c > > > > > > with cc1 in pipewr state and no assembler showing up in > > > > > > ps(1) after having succesfully compiled a bunch of other > > > > > > files. > > > > > > > > > > you mean native cc1? or linux one? > > > > > > > > linux : > > > > > > > > # ps axuww | fgrep 1129 > > > > root 11290 0.0 0.1 2296 1432 0 D 8:29PM 0:00.01 [i486-pc-linux-gnu-g] > > > > root 11291 0.0 0.8 18152 16808 0 I 8:29PM 0:00.96 [cc1] > > > > > > > > and no trace of gconv_simple.o > > > > > > > > last line of log-file is : > > > > > > > > i486-pc-linux-gnu-gcc gconv_simple.c -c -std=gnu99 -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -fno-strict-aliasing -mtune=i686 -pipe -Wstrict-prototypes -mpreferred-stack-boundary=2 -I../include -I/var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv -I/var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl -I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sysv/linux/i386/i486 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../ports/sysdeps/unix/sysv/linux -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../ports/sysdeps/unix/sysv/i386 -I../sysdeps/unix/sysv/i386 -I../nptl/sysdeps/unix/sysv -I../ports/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../nptl/sysdeps/unix -I../ports/sysdeps/unix -I../sysdeps/! unix! > > -I.! > > > > ./sysdeps/posix -I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../nptl/sysdeps/i386 -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I../ports -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/include -isystem /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/include-fixed -isystem /usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -o /var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv/gconv_simple.o -MD -MP -MF /var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv/gconv_simple.o.dt -MT /var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv/gconv_simple.o > > > > > > > > > > > > ++, Arno > > > > > > > > > > can you break into DDB and extract a backtrace of the stuck process? > > > > OK, I'll hook up a serconsole tomorrow .. > > > > for now some good old quick n dirty copy paste by pen and paper : > > > > 11290 (i486-pc-linux-gnu-gcc] > > > > sched_switch > > mi_switch > > sleepq_switch > > sleepq_wait > > _sleep > > linux_vfork > > ia32_syscall > > Xint0x80_syscall > > syscall (190, Linux ELF32, linux_vfork) > > > > > > 11291 (cc1) > > > > sched_switch > > mi_switch > > sleepq_switch > > sleepq_catch_signals > > sleepq_wait_sig > > _sleep > > pipe_write > > dofilewrite > > kern_writev > > write > > ia32_syscall > > Xint80_syscall > > syscall (4, Linux ELF32, write) > > I dont see anything obvious.. can you do "ps axl" and see what the MWCHAN is? > that might shed some light to this... bon, in fact when I launce the command by hand adding a '-v ' to gcc, output says : /usr/libexec/gcc/i486-pc-linux-gnu/4.1.2/cc1 ... | /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/../../../../i486-pc-linux-gnu/bin/as -V -Qy -o /var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv/gconv_simple.o - but, cc1 is stuck in 'pipewr' and no .../bin/as process is running (any longer) nor the file .../gconv_simple.o created Arno From bugmaster at FreeBSD.org Mon Dec 29 03:06:53 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Dec 29 03:07:41 2008 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org Message-ID: <200812291106.mBTB6qe9024405@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/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 14 problems total. From daichi at ongs.co.jp Tue Dec 30 02:02:01 2008 From: daichi at ongs.co.jp (Daichi GOTO) Date: Tue Dec 30 02:02:08 2008 Subject: wine build fail on current Message-ID: <49598116.4020506@ongs.co.jp> Wine build fails since 1.1.11, with following message: ipstats.c: In function 'getNumArpEntries': ipstats.c:1253: error: 'RTF_LLINFO' undeclared (first use in this function) ipstats.c:1253: error: (Each undeclared identifier is reported only once ipstats.c:1253: error: for each function it appears in.) ipstats.c: In function 'getArpTable': ipstats.c:1311: error: 'RTF_LLINFO' undeclared (first use in this function) ipstats.c:1311: warning: initialization makes integer from pointer without a cast gmake[2]: *** [ipstats.o] Error 1 gmake[2]: Leaving directory `/usr/ports/emulators/wine/work/wine-1.1.11/dlls/iphlpapi' gmake[1]: *** [iphlpapi] Error 2 gmake[1]: Leaving directory `/usr/ports/emulators/wine/work/wine-1.1.11/dlls' gmake: *** [dlls] Error 2 *** Error code 2 Stop in /usr/ports/emulators/wine. Anyone has any ideas? Thanks -- Daichi GOTO, http://people.freebsd.org/~daichi From tijl at ulyssis.org Tue Dec 30 13:34:50 2008 From: tijl at ulyssis.org (Tijl Coosemans) Date: Tue Dec 30 13:34:56 2008 Subject: wine build fail on current In-Reply-To: <49598116.4020506@ongs.co.jp> References: <49598116.4020506@ongs.co.jp> Message-ID: <200812301434.40010.tijl@ulyssis.org> On Tuesday 30 December 2008 03:01:58 Daichi GOTO wrote: > Wine build fails since 1.1.11, with following message: > > ipstats.c: In function 'getNumArpEntries': > ipstats.c:1253: error: 'RTF_LLINFO' undeclared (first use in this function) > ipstats.c:1253: error: (Each undeclared identifier is reported only once > ipstats.c:1253: error: for each function it appears in.) > ipstats.c: In function 'getArpTable': > ipstats.c:1311: error: 'RTF_LLINFO' undeclared (first use in this function) > ipstats.c:1311: warning: initialization makes integer from pointer without a cast > gmake[2]: *** [ipstats.o] Error 1 > gmake[2]: Leaving directory `/usr/ports/emulators/wine/work/wine-1.1.11/dlls/iphlpapi' > gmake[1]: *** [iphlpapi] Error 2 > gmake[1]: Leaving directory `/usr/ports/emulators/wine/work/wine-1.1.11/dlls' > gmake: *** [dlls] Error 2 > *** Error code 2 > > Stop in /usr/ports/emulators/wine. > > Anyone has any ideas? http://lists.freebsd.org/pipermail/freebsd-ports/2008-December/051919.html From arno at heho.snv.jussieu.fr Wed Dec 31 14:11:45 2008 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Wed Dec 31 14:11:51 2008 Subject: 8-current: linux_dist-gentoo-stage3 wonn't bootstrap In-Reply-To: References: <20081227220645.GA13295@freebsd.org> <20081228175745.GA56640@freebsd.org> <20081228202526.GA74948@freebsd.org> <20081228211505.GA80323@freebsd.org> <20081228214438.GA83007@freebsd.org> Message-ID: "Arno J. Klaassen" writes: > [NB, subject changed; this bug is produce now on -current ] > > Roman Divacky writes: > > > On Sun, Dec 28, 2008 at 10:42:44PM +0100, Arno J. Klaassen wrote: > > > Roman Divacky writes: > > > > > > > On Sun, Dec 28, 2008 at 09:38:09PM +0100, Arno J. Klaassen wrote: > > > > > > > > > > Roman Divacky writes: > > > > > > > > > > > > > > > > > > > > > does this patch fix the hang? > > > > > > > > > > > > > > > > www.vlakno.cz/~rdivacky/linprocfs.patch > > > > > > > > > > > > > > nope, though it does fix the lock order reversal > > > > > > > (I attach the slightly modified patch for linprocfs.c to > > > > > > > make it compile) > > > > > > > > > > > > the LOR is probably harmless.... dont bother with that patch :) > > > > > > > > > > > > > funny enough, it again hangs in compiling gconv_simple.c > > > > > > > with cc1 in pipewr state and no assembler showing up in > > > > > > > ps(1) after having succesfully compiled a bunch of other > > > > > > > files. > > > > > > > > > > > > you mean native cc1? or linux one? > > > > > > > > > > linux : > > > > > > > > > > # ps axuww | fgrep 1129 > > > > > root 11290 0.0 0.1 2296 1432 0 D 8:29PM 0:00.01 [i486-pc-linux-gnu-g] > > > > > root 11291 0.0 0.8 18152 16808 0 I 8:29PM 0:00.96 [cc1] > > > > > > > > > > and no trace of gconv_simple.o > > > > > > > > > > last line of log-file is : > > > > > > > > > > i486-pc-linux-gnu-gcc gconv_simple.c -c -std=gnu99 -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -fno-strict-aliasing -mtune=i686 -pipe -Wstrict-prototypes -mpreferred-stack-boundary=2 -I../include -I/var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv -I/var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl -I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sysv/linux/i386/i486 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../ports/sysdeps/unix/sysv/linux -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../ports/sysdeps/unix/sysv/i386 -I../sysdeps/unix/sysv/i386 -I../nptl/sysdeps/unix/sysv -I../ports/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../nptl/sysdeps/unix -I../ports/sysdeps/unix -I../sysdep! s/! > unix! > > > -I.! > > > > > ./sysdeps/posix -I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../nptl/sysdeps/i386 -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I../ports -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/include -isystem /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/include-fixed -isystem /usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -o /var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv/gconv_simple.o -MD -MP -MF /var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv/gconv_simple.o.dt -MT /var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv/gconv_simple.o > > > > > > > > > > > > > > > ++, Arno > > > > > > > > > > > > > can you break into DDB and extract a backtrace of the stuck process? > > > > > > OK, I'll hook up a serconsole tomorrow .. > > > > > > for now some good old quick n dirty copy paste by pen and paper : > > > > > > 11290 (i486-pc-linux-gnu-gcc] > > > > > > sched_switch > > > mi_switch > > > sleepq_switch > > > sleepq_wait > > > _sleep > > > linux_vfork > > > ia32_syscall > > > Xint0x80_syscall > > > syscall (190, Linux ELF32, linux_vfork) > > > > > > > > > 11291 (cc1) > > > > > > sched_switch > > > mi_switch > > > sleepq_switch > > > sleepq_catch_signals > > > sleepq_wait_sig > > > _sleep > > > pipe_write > > > dofilewrite > > > kern_writev > > > write > > > ia32_syscall > > > Xint80_syscall > > > syscall (4, Linux ELF32, write) > > > > I dont see anything obvious.. can you do "ps axl" and see what the MWCHAN is? > > that might shed some light to this... > > bon, in fact when I launce the command by hand adding a '-v ' to gcc, output > says : > > /usr/libexec/gcc/i486-pc-linux-gnu/4.1.2/cc1 ... | /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/../../../../i486-pc-linux-gnu/bin/as -V -Qy -o /var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv/gconv_simple.o - > > > but, cc1 is stuck in 'pipewr' and no .../bin/as process is running (any longer) > nor the file .../gconv_simple.o created I investigated this a bit more (still chrooted to /usr/local/gentoo-stage3) : i486-pc-linux-gnu-gcc gconv_open.c -c : OK i486-pc-linux-gnu-gcc gconv_open.c -c -pipe : OK i486-pc-linux-gnu-gcc gconv_simple.c -c : OK i486-pc-linux-gnu-gcc gconv_simple.c -c -pipe : pipe to as(1) fails I tried to play with kern.ipc.maxpipekva (I vaguely remember that was necessary for linux testsuites) pumping it up to "536608768", but no difference. If someone has another suggestion? Thanx, Arno