From saper at system.pl Sat Jul 5 18:41:21 2008 From: saper at system.pl (Marcin Cieslak) Date: Sat Jul 5 18:41:28 2008 Subject: Lack of Flash support is no longer acceptable. alternatives? In-Reply-To: <20080624121734.171218nrcilz164k@intranet.encontacto.net> References: <20080619135114.Y1807@kozubik.com> <20080620083906.71332251xw1ckmu8@webmail.leidinger.net> <1213972236.1505.14.camel@scotth.emsphone.com> <20080624083829.T1807@kozubik.com> <20080624121734.171218nrcilz164k@intranet.encontacto.net> Message-ID: eculp wrote: > Quoting John Kozubik : > Thanks, for reminding me but I will put another 100 dollars for the same > but I need it to work on FreeBSD 7 and 8, amd64 and i386 although if > justifiable I could get by without amd64 but would rather not. (My A secret binary under NDA will not make users on all architectures happy (yes, you can compile once, but maintain the port...?). I hope that alternatives (silverlight / moonlight) and gnash will make matters better. Recent gnash snapshots are getting much more usable (0.8.2rc played Youtube movies just fine). Gnash has also some nice features - whitelist/blacklist and debugging so that you can see what URL's is your SWF really accessing. (I have blacklisted some YT statistics immediately). Another feature I like is that movies do not have to autostart - you can play them when you click them. This saves a lot of trouble with hanging/crashing SWF's. Plus, gnash runs as a separate standalone process, so a crash is not that bad. --Marcin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 273 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080705/7d589582/signature.pgp From kpeter at melbpc.org.au Sun Jul 6 02:26:59 2008 From: kpeter at melbpc.org.au (Peter Kostouros) Date: Sun Jul 6 02:27:06 2008 Subject: Linux 2.6 emulation and Linux Java problem Message-ID: <4870260D.1080203@melbpc.org.au> Hi Is anyone having difficulty running Java applications (specifically linux-netbeans 6.1, linux-glassfish V2 and some Java applets) using linux-sun-jdk1.6.0_xx under CURRENT with Linux 2.6 emulation? I am running CURRENT as of 21JUN2008 with linux_base-f8. Invoking linux-netbeans causes a java instance to crash during startup, with ktrace on that instance showing 1860 java RET open 97/0x61 1860 java CALL freebsd6_mmap(0x61, 0x2b639970, PROT_EXEC, MAP_FILE, 0xa5a5a5a5, ..., 0xa5a5a5a5, 0, ..., 0, 0xc, 0xdead0002, ... Note 1. These applications ran successfully with linux_base-fc4 and compat.linux.osrelease set to 2.4.2; 2. The success of running java applications also depends on debug.witness.watch: I get more mileage from java applications when this sysctl is 0. What can I do to help resolve the matter? Note, I do not know if my system is somehow corrupted or that I may have some stale libraries. -- Regards Peter As always the organisation disavows knowledge of this email From Alexander at Leidinger.net Sun Jul 6 07:41:31 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sun Jul 6 07:41:39 2008 Subject: Linux 2.6 emulation and Linux Java problem In-Reply-To: <4870260D.1080203@melbpc.org.au> References: <4870260D.1080203@melbpc.org.au> Message-ID: <20080706094332.4de443b0@deskjail> Quoting Peter Kostouros (Sun, 06 Jul 2008 01:55:25 +0000): > Hi > > Is anyone having difficulty running Java applications (specifically > linux-netbeans 6.1, linux-glassfish V2 and some Java applets) using > linux-sun-jdk1.6.0_xx under CURRENT with Linux 2.6 emulation? > > I am running CURRENT as of 21JUN2008 with linux_base-f8. Invoking > linux-netbeans causes a java instance to crash during startup, with > ktrace on that instance showing Are you using linux_kdump, or the normal kdump? If the later, you need to use the former. There's also the possibility to use dtrace (new feature in current, so no HOWTO for the linux dtrace script available yet). > 1860 java RET open 97/0x61 > > 1860 java CALL freebsd6_mmap(0x61, 0x2b639970, PROT_EXEC, MAP_FILE, 0xa5a5a5a5, ..., 0xa5a5a5a5, 0, ..., 0, 0xc, 0xdead0002, ... > > > Note > > 1. These applications ran successfully with linux_base-fc4 and > compat.linux.osrelease set to 2.4.2; > 2. The success of running java applications also depends on > debug.witness.watch: I get more mileage from java applications when this > sysctl is 0. Do you get witness warning/errors on the console? Please check and report them if there are any. Bye, Alexander. -- Everybody is ignorant, only on different subjects. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From eculp at encontacto.net Sun Jul 6 13:56:49 2008 From: eculp at encontacto.net (eculp) Date: Sun Jul 6 13:56:56 2008 Subject: Lack of Flash support is no longer acceptable. alternatives? In-Reply-To: References: <20080619135114.Y1807@kozubik.com> <20080620083906.71332251xw1ckmu8@webmail.leidinger.net> <1213972236.1505.14.camel@scotth.emsphone.com> <20080624083829.T1807@kozubik.com> <20080624121734.171218nrcilz164k@intranet.encontacto.net> Message-ID: <20080706085636.280786wmdmf7wq3c@intranet.encontacto.net> Quoting Marcin Cieslak : > eculp wrote: >> Quoting John Kozubik : > >> Thanks, for reminding me but I will put another 100 dollars for the >> same but I need it to work on FreeBSD 7 and 8, amd64 and i386 >> although if justifiable I could get by without amd64 but would >> rather not. (My > > A secret binary under NDA will not make users on all architectures > happy (yes, you can compile once, but maintain the port...?). > > I hope that alternatives (silverlight / moonlight) and gnash will > make matters better. Recent gnash snapshots are getting much more > usable (0.8.2rc played Youtube movies just fine). > > Gnash has also some nice features - whitelist/blacklist and > debugging so that you can see what URL's is your SWF really > accessing. (I have blacklisted some YT statistics immediately). > Another feature I like is that movies do not have to autostart - you > can play them when you click them. This saves a lot of trouble with > hanging/crashing SWF's. Plus, gnash runs as a separate standalone > process, so a crash is not that bad. I assume it doesn't do any flash 8+ sites, does it? Sites are changing to require flash [8,9] daily:( Youtube works fine with the flash7 plugin. Some bounties have been offered, there was one for 200 dls. and I offered to add 100 more. It was focused on the flashplugin but anything that a regular user (read wives) could use without complaining, would be great, EMO. Maybe someone who is a commiter and would take charge of judging and paying the bounty, I feel others would chip in and maybe we could make it worthwhile. Thanks, ed From nox at jelal.kn-bremen.de Sun Jul 6 19:46:18 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sun Jul 6 19:46:34 2008 Subject: please test experimental qemu-devel-20080620 snapshot and kqemu-1.4.0pre1 update! In-Reply-To: <20080622221933.GA12209@saturn.kn-bremen.de> References: <20080620211216.GA75382@saturn.kn-bremen.de> <20080622221933.GA12209@saturn.kn-bremen.de> Message-ID: <20080706194408.GA23575@saturn.kn-bremen.de> On Mon, Jun 23, 2008 at 12:19:33AM +0200, Juergen Lock wrote: > On Fri, Jun 20, 2008 at 11:12:16PM +0200, Juergen Lock wrote: > > Hi! > > > > I've been playing with a qemu-devel update again recently (which also > > includes a kqemu api change, therefore I have a new kqemu-kmod-devel > > port too), and these are the main news: > > > > - Many targets including x86 have been converted from dyngen to tcg > > completely, which should allow building them with newer gcc versions; > > I've added an ALL_TARGETS knob that can be turned off if you only need > > these targets, that avoids building the gcc34 port if you're on 7.0 or > > later. Here is the list out of the CONFIGURE_ARGS: > > i386-softmmu,sparc-softmmu,x86_64-softmmu,mips-softmmu,mipsel-softmmu,mips64-softmmu,mips64el-softmmu,arm-softmmu,m68k-softmmu > > (I only tested i386 and x86_64 a little bit. This knob also needs testing > > on 7.0 and later i386 hosts.) > > - kqemu now also works for i386-softmmu on amd64 hosts, i.e. you no longer > > need to use qemu-system-x86_64 there if you want kqemu. > > - And of course the usual round of bugfixes and optimizations, etc. > > > > The tcg conversions can cause regressions tho, and indeed I found > > that 7.0-RELEASE-amd64-livefs.iso causes qemu-system-x86_64 to crash on > > i386 hosts, it'd be interesting if you can find more. (I'll post a seperate > > message with details about that crash on the qemu list, and probably won't > > commit this version because of that.) > > > > I didn't inline the update and kqemu port this time since its two files, > > just fetch them from: > > http://people.freebsd.org/~nox/qemu/kqemu-kmod-devel.shar > > and > > http://people.freebsd.org/~nox/qemu/qemu-devel-20080620.patch > > Ok, kqemu-kmod-devel has now been repocopied from kqemu-kmod and I have > just updated it to the new version, and I also added D_NEEDMINOR to both > ports so they now should also be back to working order on -current (untested.) > > So what this means is now you can use the new kqemu-kmod-devel port from cvs > instead of the shar for this qemu-devel update patch. OK I have been hunting tcg regessions over the last few days and can now report that at least those amd64 guests that I tested are now (mostly) back to working order on i386 hosts (see http://people.freebsd.org/~nox/qemu/fix-cvtsi2ssq-etc.mail.txt and the previos qemu list posts linked from there if you are interested in the gory details.) On another note, and this might interest some people here more, 32 bit qemu on amd64 hosts with kqemu seems to now work almost(?) like as on i386 hosts, at least I got a report of xp sp2 even working with -kernel-kqemu there... :) Here comes the current version of the qemu-devel port update, which I'll probably commit in the course of next week assuming I get no new bugreports (or negative comments about my tcg fixes from the qemu folks.) - also at: http://people.freebsd.org/~nox/qemu/qemu-devel-20080620-2nd.patch Index: Makefile =================================================================== RCS file: /home/pcvs/ports/emulators/qemu-devel/Makefile,v retrieving revision 1.92 diff -u -p -r1.92 Makefile --- Makefile 6 Jun 2008 13:27:04 -0000 1.92 +++ Makefile 20 Jun 2008 20:04:20 -0000 @@ -6,17 +6,14 @@ # PORTNAME= qemu -PORTVERSION= 0.9.1s.20080302 -PORTREVISION= 9 +PORTVERSION= 0.9.1s.20080620 CATEGORIES= emulators -MASTER_SITES= http://qemu.org/:release \ +MASTER_SITES= http://bellard.org/qemu/:release \ http://qemu-forum.ipi.fi/qemu-snapshots/:snapshot \ http://people.fruitsalad.org/nox/qemu/:snapshot \ - http://www.volny.cz/xnavara/qemu/:snapshot \ - http://people.brandeis.edu/~jcoiner/qemu_idedma/:idedma \ - http://people.freebsd.org/~maho/qemu/:misc + ${MASTER_SITE_LOCAL}:snapshot PKGNAMESUFFIX= -devel -DISTNAME= ${PORTNAME}-snapshot-2008-03-02_05 +DISTNAME= ${PORTNAME}-snapshot-2008-06-20_19 DISTFILES= ${DISTNAME}${EXTRACT_SUFX}:snapshot DIST_SUBDIR= qemu EXTRACT_ONLY= ${DISTNAME}${EXTRACT_SUFX} @@ -28,7 +25,6 @@ HAS_CONFIGURE= yes USE_BZIP2= yes USE_GMAKE= yes USE_PERL5= yes -USE_GCC= 3.4 PATCH_STRIP= -lp1 MAKE_ENV+= BSD_MAKE="${MAKE}" CFLAGS="${CFLAGS}" LDFLAGS="${LDFLAGS}" MAN1= qemu.1 qemu-img.1 @@ -40,10 +36,19 @@ OPTIONS= KQEMU "Build with (alpha!) acce SAMBA "samba dependency (for -smb)" Off \ SDL "SDL/X dependency (graphical output)" On \ GNUTLS "gnutls dependency (vnc encryption)" On \ - CDROM_DMA "IDE CDROM DMA" On + CDROM_DMA "IDE CDROM DMA" On \ + ALL_TARGETS "Also build dyngen targets (requires gcc34)" On .include +.if defined(WITHOUT_ALL_TARGETS) +CONFIGURE_ARGS+= --disable-gcc-check --target-list=i386-softmmu,sparc-softmmu,x86_64-softmmu,mips-softmmu,mipsel-softmmu,mips64-softmmu,mips64el-softmmu,arm-softmmu,m68k-softmmu +PLIST_SUB+= DYNGEN="@comment " +.else +USE_GCC= 3.4 +PLIST_SUB+= DYNGEN="" +.endif + .if ${OSVERSION} < 600000 # 5.x base gcc segfaults in target-mips/op_mem.c BUILD_DEPENDS+= gcc34:${PORTSDIR}/lang/gcc34 @@ -66,16 +71,12 @@ CONFIGURE_ARGS+= --disable-vnc-tls LIB_DEPENDS+= gnutls:${PORTSDIR}/security/gnutls .endif -.if defined (WITH_HACKS_CIRRUS) || defined (WITH_HACKS) -DISTFILES+= patch3_cirrus:misc -.endif - .if defined(WITH_SAMBA) RUN_DEPENDS+= ${LOCALBASE}/sbin/smbd:${PORTSDIR}/net/samba3 .endif .if defined(WITH_KQEMU) -BUILD_DEPENDS+= kqemu-kmod>=1.3.0pre5:${PORTSDIR}/emulators/kqemu-kmod +BUILD_DEPENDS+= kqemu-kmod-devel>=1.4.0pre1:${PORTSDIR}/emulators/kqemu-kmod-devel .else CONFIGURE_ARGS+= --disable-kqemu .endif Index: distinfo =================================================================== RCS file: /home/pcvs/ports/emulators/qemu-devel/distinfo,v retrieving revision 1.49 diff -u -p -r1.49 distinfo --- distinfo 11 Mar 2008 23:34:13 -0000 1.49 +++ distinfo 20 Jun 2008 17:23:17 -0000 @@ -1,3 +1,3 @@ -MD5 (qemu/qemu-snapshot-2008-03-02_05.tar.bz2) = 832923647bb52f1f0408a707e98479ca -SHA256 (qemu/qemu-snapshot-2008-03-02_05.tar.bz2) = d4159530d7f6b7261a16346b013f303cfa703403e749ca49ce003ef61d7eaff1 -SIZE (qemu/qemu-snapshot-2008-03-02_05.tar.bz2) = 2394602 +MD5 (qemu/qemu-snapshot-2008-06-20_19.tar.bz2) = 7201553586b59e400664b2f9ae0b17a1 +SHA256 (qemu/qemu-snapshot-2008-06-20_19.tar.bz2) = e9a3654976b923c471f572961f244f2758d15a367cfc1b32054aa2cd4391cace +SIZE (qemu/qemu-snapshot-2008-06-20_19.tar.bz2) = 2629290 Index: pkg-message =================================================================== RCS file: /home/pcvs/ports/emulators/qemu-devel/pkg-message,v retrieving revision 1.27 diff -u -p -r1.27 pkg-message --- pkg-message 17 May 2008 18:53:43 -0000 1.27 +++ pkg-message 6 Jul 2008 18:55:50 -0000 @@ -88,14 +88,6 @@ to /etc/rc.conf (revision 1.25 of /usr/ports/emulators/kqemu-kmod/Makefile), so if your host is such you might want to make sure your kqemu-kmod port is new enough. (and don't forget to reload it...) -- also remember that on amd64 you need to run the amd64 (x86_64) system -emulation if you want to use kqemu, i.e. run qemu-system-x86_64 instead of -qemu (the latter only emulates a 32 bit system.) Unfortunately there can -still be guests that don't run correctly in the amd64 emulation even when -they do run in the 32 bit one, the same is true about kqemu and -kernel-kqemu -on amd64 - not much you can do about that other than help debugging (k)qemu's -amd64 emulation... (well or falling back to unaccellerated, possibly 32 bit -qemu/leaving out -kernel-kqemu if its that what's causing the problems.) - qemu's network boot roms (-boot n) have a bug when bootfiles sizes are a multiple of blksize, if this affects you (like with FreeBSD's /boot/pxeboot) you can do like @@ -107,6 +99,15 @@ extracted out of ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/200805/7.0-STABLE-200805-i386-bootonly.iso and placed it here: http://people.freebsd.org/~nox/qemu/pxeboot-qemu +- if you use slirp and want to nfs mount stuff into the guest and you are +not running qemu as root, then mountd on the exporting box needs to be run +with -n in order to accept requests from ports >= 1024. +- unfortunately there can still be guests that don't run correctly with +kqemu and -kernel-kqemu especially on amd64 - not much you can do about that +other than help debugging (k)qemu... (well or falling back to unaccellerated +qemu/leaving out -kernel-kqemu if its that what's causing the problems. +note however that kqemu now can also be used with the 32 bit qemu even +on amd64 hosts as of the 20080620 update.) - qemu now uses aio at least for ide dma, so if you get `Invalid system call' crashes that is because aio is not (kld)loaded. - The default configuration location (qemu-ifup script etc.) has been Index: pkg-plist =================================================================== RCS file: /home/pcvs/ports/emulators/qemu-devel/pkg-plist,v retrieving revision 1.24 diff -u -p -r1.24 pkg-plist --- pkg-plist 3 Apr 2008 20:18:40 -0000 1.24 +++ pkg-plist 20 Jun 2008 18:34:31 -0000 @@ -1,17 +1,17 @@ bin/qemu bin/qemu-img bin/qemu-system-arm -bin/qemu-system-cris +%%DYNGEN%%bin/qemu-system-cris bin/qemu-system-m68k bin/qemu-system-mips bin/qemu-system-mips64 bin/qemu-system-mips64el bin/qemu-system-mipsel -bin/qemu-system-ppc -bin/qemu-system-ppc64 -bin/qemu-system-ppcemb -bin/qemu-system-sh4 -bin/qemu-system-sh4eb +%%DYNGEN%%bin/qemu-system-ppc +%%DYNGEN%%bin/qemu-system-ppc64 +%%DYNGEN%%bin/qemu-system-ppcemb +%%DYNGEN%%bin/qemu-system-sh4 +%%DYNGEN%%bin/qemu-system-sh4eb bin/qemu-system-sparc bin/qemu-system-x86_64 @unexec if cmp -s %D/etc/qemu-ifup.sample %D/etc/qemu-ifup; then rm -f %D/etc/qemu-ifup; fi @@ -28,6 +28,7 @@ etc/qemu-ifdown.sample %%DATADIR%%/vgabios-cirrus.bin %%DATADIR%%/ppc_rom.bin %%DATADIR%%/openbios-sparc32 +%%DATADIR%%/openbios-sparc64 %%DATADIR%%/video.x %%DATADIR%%/pxe-ne2k_pci.bin %%DATADIR%%/pxe-rtl8139.bin Index: files/patch-90_security =================================================================== RCS file: /home/pcvs/ports/emulators/qemu-devel/files/patch-90_security,v retrieving revision 1.4 diff -u -p -r1.4 patch-90_security --- files/patch-90_security 11 Mar 2008 23:34:13 -0000 1.4 +++ files/patch-90_security 20 Jun 2008 19:45:28 -0000 @@ -1,148 +1,3 @@ -Index: qemu-0.8.2/hw/cirrus_vga.c -@@ -217,6 +217,20 @@ - #define CIRRUS_HOOK_NOT_HANDLED 0 - #define CIRRUS_HOOK_HANDLED 1 - -+#define BLTUNSAFE(s) \ -+ ( \ -+ ( /* check dst is within bounds */ \ -+ (s)->cirrus_blt_height * (s)->cirrus_blt_dstpitch \ -+ + ((s)->cirrus_blt_dstaddr & (s)->cirrus_addr_mask) > \ -+ (s)->vram_size \ -+ ) || \ -+ ( /* check src is within bounds */ \ -+ (s)->cirrus_blt_height * (s)->cirrus_blt_srcpitch \ -+ + ((s)->cirrus_blt_srcaddr & (s)->cirrus_addr_mask) > \ -+ (s)->vram_size \ -+ ) \ -+ ) -+ - struct CirrusVGAState; - typedef void (*cirrus_bitblt_rop_t) (struct CirrusVGAState *s, - uint8_t * dst, const uint8_t * src, -@@ -636,7 +650,7 @@ - - for (y = 0; y < lines; y++) { - off_cur = off_begin; -- off_cur_end = off_cur + bytesperline; -+ off_cur_end = (off_cur + bytesperline) & s->cirrus_addr_mask; - off_cur &= TARGET_PAGE_MASK; - while (off_cur < off_cur_end) { - cpu_physical_memory_set_dirty(s->vram_offset + off_cur); -@@ -651,7 +665,11 @@ - { - uint8_t *dst; - -- dst = s->vram_ptr + s->cirrus_blt_dstaddr; -+ dst = s->vram_ptr + (s->cirrus_blt_dstaddr & s->cirrus_addr_mask); -+ -+ if (BLTUNSAFE(s)) -+ return 0; -+ - (*s->cirrus_rop) (s, dst, src, - s->cirrus_blt_dstpitch, 0, - s->cirrus_blt_width, s->cirrus_blt_height); -@@ -667,8 +685,11 @@ - { - cirrus_fill_t rop_func; - -+ if (BLTUNSAFE(s)) -+ return 0; -+ - rop_func = cirrus_fill[rop_to_index[blt_rop]][s->cirrus_blt_pixelwidth - 1]; -- rop_func(s, s->vram_ptr + s->cirrus_blt_dstaddr, -+ rop_func(s, s->vram_ptr + (s->cirrus_blt_dstaddr & s->cirrus_addr_mask), - s->cirrus_blt_dstpitch, - s->cirrus_blt_width, s->cirrus_blt_height); - cirrus_invalidate_region(s, s->cirrus_blt_dstaddr, -@@ -687,8 +708,8 @@ - static int cirrus_bitblt_videotovideo_patterncopy(CirrusVGAState * s) - { - return cirrus_bitblt_common_patterncopy(s, -- s->vram_ptr + -- (s->cirrus_blt_srcaddr & ~7)); -+ s->vram_ptr + ((s->cirrus_blt_srcaddr & ~7) & -+ s->cirrus_addr_mask)); - } - - static void cirrus_do_copy(CirrusVGAState *s, int dst, int src, int w, int h) -@@ -738,8 +759,10 @@ - if (notify) - vga_hw_update(); - -- (*s->cirrus_rop) (s, s->vram_ptr + s->cirrus_blt_dstaddr, -- s->vram_ptr + s->cirrus_blt_srcaddr, -+ (*s->cirrus_rop) (s, s->vram_ptr + -+ (s->cirrus_blt_dstaddr & s->cirrus_addr_mask), -+ s->vram_ptr + -+ (s->cirrus_blt_srcaddr & s->cirrus_addr_mask), - s->cirrus_blt_dstpitch, s->cirrus_blt_srcpitch, - s->cirrus_blt_width, s->cirrus_blt_height); - -@@ -765,8 +788,14 @@ - s->cirrus_blt_srcaddr - s->start_addr, - s->cirrus_blt_width, s->cirrus_blt_height); - } else { -- (*s->cirrus_rop) (s, s->vram_ptr + s->cirrus_blt_dstaddr, -- s->vram_ptr + s->cirrus_blt_srcaddr, -+ -+ if (BLTUNSAFE(s)) -+ return 0; -+ -+ (*s->cirrus_rop) (s, s->vram_ptr + -+ (s->cirrus_blt_dstaddr & s->cirrus_addr_mask), -+ s->vram_ptr + -+ (s->cirrus_blt_srcaddr & s->cirrus_addr_mask), - s->cirrus_blt_dstpitch, s->cirrus_blt_srcpitch, - s->cirrus_blt_width, s->cirrus_blt_height); - -@@ -798,8 +827,9 @@ - } else { - /* at least one scan line */ - do { -- (*s->cirrus_rop)(s, s->vram_ptr + s->cirrus_blt_dstaddr, -- s->cirrus_bltbuf, 0, 0, s->cirrus_blt_width, 1); -+ (*s->cirrus_rop)(s, s->vram_ptr + -+ (s->cirrus_blt_dstaddr & s->cirrus_addr_mask), -+ s->cirrus_bltbuf, 0, 0, s->cirrus_blt_width, 1); - cirrus_invalidate_region(s, s->cirrus_blt_dstaddr, 0, - s->cirrus_blt_width, 1); - s->cirrus_blt_dstaddr += s->cirrus_blt_dstpitch; -@@ -1917,7 +1947,7 @@ - unsigned val = mem_value; - uint8_t *dst; - -- dst = s->vram_ptr + offset; -+ dst = s->vram_ptr + (offset &= s->cirrus_addr_mask); - for (x = 0; x < 8; x++) { - if (val & 0x80) { - *dst = s->cirrus_shadow_gr1; -@@ -1940,7 +1970,7 @@ - unsigned val = mem_value; - uint8_t *dst; - -- dst = s->vram_ptr + offset; -+ dst = s->vram_ptr + (offset &= s->cirrus_addr_mask); - for (x = 0; x < 8; x++) { - if (val & 0x80) { - *dst = s->cirrus_shadow_gr1; -Index: qemu-0.8.2/hw/cirrus_vga_rop.h -=================================================================== ---- qemu-0.8.2.orig/hw/cirrus_vga_rop.h 2006-07-22 20:23:34.000000000 +0300 -+++ qemu-0.8.2/hw/cirrus_vga_rop.h 2007-04-20 06:05:59.000000000 +0300 -@@ -31,6 +31,12 @@ glue(cirrus_bitblt_rop_fwd_, ROP_NAME)(C - int x,y; - dstpitch -= bltwidth; - srcpitch -= bltwidth; -+ -+ if (dstpitch < 0 || srcpitch < 0) { -+ /* is 0 valid? srcpitch == 0 could be useful */ -+ return; -+ } -+ - for (y = 0; y < bltheight; y++) { - for (x = 0; x < bltwidth; x++) { - ROP_OP(*dst, *src); Index: qemu-0.8.2/hw/dma.c =================================================================== --- qemu-0.8.2.orig/hw/dma.c 2006-07-22 20:23:34.000000000 +0300 @@ -162,21 +17,27 @@ Index: qemu-0.8.2/hw/dma.c ldebug ("dma_pos %d size %d\n", n, (r->base[COUNT] + 1) << ncont); } -Index: qemu-0.8.2/hw/fdc.c -@@ -1247,7 +1247,12 @@ - len = fdctrl->data_len - fdctrl->data_pos; - if (len > FD_SECTOR_LEN) - len = FD_SECTOR_LEN; -- bdrv_read(cur_drv->bs, fd_sector(cur_drv), fdctrl->fifo, 1); -+ if (cur_drv->bs) { -+ bdrv_read(cur_drv->bs, fd_sector(cur_drv), fdctrl->fifo, 1); -+ } else { -+ FLOPPY_ERROR("can't read data from drive\n"); -+ return 0; -+ } - } - } - retval = fdctrl->fifo[pos]; +Index: qemu/hw/fdc.c +@@ -1322,7 +1322,8 @@ + fd_sector(cur_drv)); + return 0; + } +- if (bdrv_read(cur_drv->bs, fd_sector(cur_drv), fdctrl->fifo, 1) < 0) { ++ if (cur_drv->bs == NULL || ++ bdrv_read(cur_drv->bs, fd_sector(cur_drv), fdctrl->fifo, 1) < 0) { + FLOPPY_DPRINTF("error getting sector %d\n", + fd_sector(cur_drv)); + /* Sure, image size is too small... */ +@@ -1776,7 +1777,8 @@ + if (pos == FD_SECTOR_LEN - 1 || + fdctrl->data_pos == fdctrl->data_len) { + cur_drv = get_cur_drv(fdctrl); +- if (bdrv_write(cur_drv->bs, fd_sector(cur_drv), fdctrl->fifo, 1) < 0) { ++ if (cur_drv->bs == NULL || ++ bdrv_write(cur_drv->bs, fd_sector(cur_drv), fdctrl->fifo, 1) < 0) { + FLOPPY_ERROR("writing sector %d\n", fd_sector(cur_drv)); + return; + } Index: qemu-0.8.2/hw/pc.c =================================================================== --- qemu-0.8.2.orig/hw/pc.c 2007-04-20 06:05:58.000000000 +0300 Index: files/patch-CVE-2008-2004 =================================================================== RCS file: /home/pcvs/ports/emulators/qemu-devel/files/patch-CVE-2008-2004,v retrieving revision 1.1 diff -u -p -r1.1 patch-CVE-2008-2004 --- files/patch-CVE-2008-2004 8 May 2008 20:45:10 -0000 1.1 +++ files/patch-CVE-2008-2004 20 Jun 2008 19:45:28 -0000 @@ -1,60 +0,0 @@ -Index: qemu/vl.c -=================================================================== ---- vl.c (revision 4276) -+++ vl.c (revision 4277) -@@ -4961,6 +4961,7 @@ - int bus_id, unit_id; - int cyls, heads, secs, translation; - BlockDriverState *bdrv; -+ BlockDriver *drv = NULL; - int max_devs; - int index; - int cache; -@@ -4968,7 +4969,7 @@ - char *str = arg->opt; - char *params[] = { "bus", "unit", "if", "index", "cyls", "heads", - "secs", "trans", "media", "snapshot", "file", -- "cache", NULL }; -+ "cache", "format", NULL }; - - if (check_params(buf, sizeof(buf), params, str) < 0) { - fprintf(stderr, "qemu: unknown parameter '%s' in '%s'\n", -@@ -5136,6 +5137,14 @@ - } - } - -+ if (get_param_value(buf, sizeof(buf), "format", str)) { -+ drv = bdrv_find_format(buf); -+ if (!drv) { -+ fprintf(stderr, "qemu: '%s' invalid format\n", buf); -+ return -1; -+ } -+ } -+ - if (arg->file == NULL) - get_param_value(file, sizeof(file), "file", str); - else -@@ -5238,7 +5247,7 @@ - bdrv_flags |= BDRV_O_SNAPSHOT; - if (!cache) - bdrv_flags |= BDRV_O_DIRECT; -- if (bdrv_open(bdrv, file, bdrv_flags) < 0 || qemu_key_check(bdrv, file)) { -+ if (bdrv_open2(bdrv, file, bdrv_flags, drv) < 0 || qemu_key_check(bdrv, file)) { - fprintf(stderr, "qemu: could not open disk image %s\n", - file); - return -1; -Index: qemu/qemu-doc.texi -=================================================================== ---- qemu-doc.texi (revision 4276) -+++ qemu-doc.texi (revision 4277) -@@ -261,6 +261,10 @@ - @var{snapshot} is "on" or "off" and allows to enable snapshot for given drive (see @option{-snapshot}). - @item cache=@var{cache} - @var{cache} is "on" or "off" and allows to disable host cache to access data. -+@item format=@var{format} -+Specify which disk @var{format} will be used rather than detecting -+the format. Can be used to specifiy format=raw to avoid interpreting -+an untrusted format header. - @end table - - Instead of @option{-cdrom} you can use: Index: files/patch-Makefile =================================================================== RCS file: /home/pcvs/ports/emulators/qemu-devel/files/patch-Makefile,v retrieving revision 1.5 diff -u -p -r1.5 patch-Makefile --- files/patch-Makefile 25 Mar 2007 16:33:01 -0000 1.5 +++ files/patch-Makefile 20 Jun 2008 19:45:28 -0000 @@ -1,17 +1,17 @@ Index: qemu/Makefile -@@ -19,7 +19,11 @@ - BASE_LDFLAGS += -static +@@ -17,7 +17,11 @@ + LDFLAGS += -static endif ifdef BUILD_DOCS +ifdef NOPORTDOCS -+DOCS=qemu.1 qemu-img.1 ++DOCS=qemu.1 qemu-img.1 qemu-nbd.8 +else - DOCS=qemu-doc.html qemu-tech.html qemu.1 qemu-img.1 + DOCS=qemu-doc.html qemu-tech.html qemu.1 qemu-img.1 qemu-nbd.8 +endif else DOCS= endif -@@ -60,8 +64,10 @@ +@@ -203,13 +211,13 @@ common de-ch es fo fr-ca hu ja mk nl-be pt sl tr install-doc: $(DOCS) @@ -22,3 +22,8 @@ Index: qemu/Makefile ifndef CONFIG_WIN32 mkdir -p "$(DESTDIR)$(mandir)/man1" $(INSTALL) qemu.1 qemu-img.1 "$(DESTDIR)$(mandir)/man1" +- mkdir -p "$(DESTDIR)$(mandir)/man8" +- $(INSTALL) qemu-nbd.8 "$(DESTDIR)$(mandir)/man8" + endif + + install: all $(if $(BUILD_DOCS),install-doc) Index: files/patch-cpu-exec.c =================================================================== RCS file: /home/pcvs/ports/emulators/qemu-devel/files/patch-cpu-exec.c,v retrieving revision 1.4 diff -u -p -r1.4 patch-cpu-exec.c --- files/patch-cpu-exec.c 11 Mar 2008 23:34:13 -0000 1.4 +++ files/patch-cpu-exec.c 20 Jun 2008 19:45:28 -0000 @@ -1,29 +1,27 @@ ---- qemu.orig/cpu-exec.c Mon Jan 14 11:11:02 2008 -+++ qemu/cpu-exec.c Thu Jan 17 23:03:00 2008 -@@ -449,16 +449,18 @@ int cpu_exec(CPUState *env1) - (env->eflags & IF_MASK || env->hflags & HF_HIF_MASK) && - !(env->hflags & HF_INHIBIT_IRQ_MASK)) { - int intno; -- svm_check_intercept(SVM_EXIT_INTR); - env->interrupt_request &= ~(CPU_INTERRUPT_HARD | CPU_INTERRUPT_VIRQ); - intno = cpu_get_pic_interrupt(env); -- if (loglevel & CPU_LOG_TB_IN_ASM) { -- fprintf(logfile, "Servicing hardware INT=0x%02x\n", intno); -- } -- do_interrupt(intno, 0, 0, 0, 1); -- /* ensure that no TB jump will be modified as -- the program flow was changed */ -- BREAK_CHAIN; -+ if(intno>=0) { -+ svm_check_intercept(SVM_EXIT_INTR); -+ if (loglevel & CPU_LOG_TB_IN_ASM) { -+ fprintf(logfile, "Servicing hardware INT=0x%02x\n", intno); -+ } -+ do_interrupt(intno, 0, 0, 0, 1); -+ /* ensure that no TB jump will be modified as -+ the program flow was changed */ -+ BREAK_CHAIN; -+ } +Index: qemu/cpu-exec.c +@@ -394,16 +394,18 @@ + (env->eflags & IF_MASK && + !(env->hflags & HF_INHIBIT_IRQ_MASK))))) { + int intno; +- svm_check_intercept(SVM_EXIT_INTR); + env->interrupt_request &= ~(CPU_INTERRUPT_HARD | CPU_INTERRUPT_VIRQ); + intno = cpu_get_pic_interrupt(env); +- if (loglevel & CPU_LOG_TB_IN_ASM) { +- fprintf(logfile, "Servicing hardware INT=0x%02x\n", intno); ++ if (intno>=0) { ++ svm_check_intercept(SVM_EXIT_INTR); ++ if (loglevel & CPU_LOG_TB_IN_ASM) { ++ fprintf(logfile, "Servicing hardware INT=0x%02x\n", intno); ++ } ++ do_interrupt(intno, 0, 0, 0, 1); ++ /* ensure that no TB jump will be modified as ++ the program flow was changed */ ++ next_tb = 0; + } +- do_interrupt(intno, 0, 0, 0, 1); +- /* ensure that no TB jump will be modified as +- the program flow was changed */ +- next_tb = 0; #if !defined(CONFIG_USER_ONLY) - } else if ((interrupt_request & CPU_INTERRUPT_VIRQ) && - (env->eflags & IF_MASK) && !(env->hflags & HF_INHIBIT_IRQ_MASK)) { + } else if ((interrupt_request & CPU_INTERRUPT_VIRQ) && + (env->eflags & IF_MASK) && Index: files/patch-curses_keys.h =================================================================== RCS file: /home/pcvs/ports/emulators/qemu-devel/files/patch-curses_keys.h,v retrieving revision 1.1 diff -u -p -r1.1 patch-curses_keys.h --- files/patch-curses_keys.h 21 Mar 2008 22:20:07 -0000 1.1 +++ files/patch-curses_keys.h 20 Jun 2008 19:45:28 -0000 @@ -1,17 +0,0 @@ -Index: qemu/curses_keys.h -=================================================================== -RCS file: /sources/qemu/qemu/curses_keys.h,v -retrieving revision 1.1 -retrieving revision 1.2 -diff -u -p -r1.1 -r1.2 ---- curses_keys.h 10 Feb 2008 16:33:13 -0000 1.1 -+++ curses_keys.h 18 Mar 2008 06:55:27 -0000 1.2 -@@ -198,7 +198,7 @@ int curses2keycode[CURSES_KEYS] = { - - [0x001] = 30 | CNTRL, /* Control + a */ - [0x013] = 31 | CNTRL, /* Control + s */ -- [0x014] = 32 | CNTRL, /* Control + d */ -+ [0x004] = 32 | CNTRL, /* Control + d */ - [0x006] = 33 | CNTRL, /* Control + f */ - [0x007] = 34 | CNTRL, /* Control + g */ - [0x008] = 35 | CNTRL, /* Control + h */ Index: files/patch-fbsd =================================================================== RCS file: /home/pcvs/ports/emulators/qemu-devel/files/patch-fbsd,v retrieving revision 1.11 diff -u -p -r1.11 patch-fbsd --- files/patch-fbsd 11 Mar 2008 23:34:13 -0000 1.11 +++ files/patch-fbsd 20 Jun 2008 19:45:28 -0000 @@ -20,14 +20,14 @@ Index: qemu/Makefile rm -f *.o *.a $(TOOLS) dyngen$(EXESUF) TAGS *.pod *~ */*~ $(MAKE) -C tests clean Index: qemu/Makefile.target -@@ -649,8 +649,8 @@ +@@ -651,8 +651,8 @@ main.o: CFLAGS+=-p endif -$(QEMU_PROG): $(OBJS) ../libqemu_common.a libqemu.a -- $(CC) $(LDFLAGS) -o $@ $^ $(LIBS) $(SDL_LIBS) $(COCOA_LIBS) $(CURSES_LIBS) +- $(CC) $(LDFLAGS) -o $@ $^ $(LIBS) $(SDL_LIBS) $(COCOA_LIBS) $(CURSES_LIBS) $(BRLAPI_LIBS) +$(QEMU_PROG): $(OBJS) ../libqemu_common.a libqemu.a ../bsd/libmath.a -+ $(CC) $(LDFLAGS) -o $@ $^ $(LIBS) $(SDL_LIBS) $(COCOA_LIBS) $(CURSES_LIBS) ../bsd/libmath.a ++ $(CC) $(LDFLAGS) -o $@ $^ $(LIBS) $(SDL_LIBS) $(COCOA_LIBS) $(CURSES_LIBS) $(BRLAPI_LIBS) ../bsd/libmath.a endif # !CONFIG_USER_ONLY Index: files/patch-hw-e1000.c =================================================================== RCS file: /home/pcvs/ports/emulators/qemu-devel/files/patch-hw-e1000.c,v retrieving revision 1.1 diff -u -p -r1.1 patch-hw-e1000.c --- files/patch-hw-e1000.c 12 Mar 2008 20:01:31 -0000 1.1 +++ files/patch-hw-e1000.c 20 Jun 2008 19:45:28 -0000 @@ -1,17 +0,0 @@ -Index: qemu/hw/e1000.c -=================================================================== -RCS file: /sources/qemu/qemu/hw/e1000.c,v -retrieving revision 1.3 -retrieving revision 1.4 -diff -u -p -r1.3 -r1.4 ---- hw/e1000.c 10 Feb 2008 13:34:48 -0000 1.3 -+++ hw/e1000.c 10 Mar 2008 00:02:10 -0000 1.4 -@@ -50,7 +50,7 @@ static int debugflags = DBGBIT(TXERR) | - #endif - - #define IOPORT_SIZE 0x40 --#define PNPMMIO_SIZE 0x60000 -+#define PNPMMIO_SIZE 0x20000 - - /* - * HW models: Index: files/patch-libmath2 =================================================================== RCS file: /home/pcvs/ports/emulators/qemu-devel/files/patch-libmath2,v retrieving revision 1.2 diff -u -p -r1.2 patch-libmath2 --- files/patch-libmath2 10 Mar 2007 17:03:05 -0000 1.2 +++ files/patch-libmath2 20 Jun 2008 19:45:28 -0000 @@ -55,13 +55,3 @@ Index: qemu/bsd/amd64/s_ldexpl.c +} + +weak_alias(__ldexpl,ldexpl) -Index: qemu/target-i386/helper.c -@@ -2886,6 +2886,8 @@ - ST0 = floatx_round_to_int(ST0, &env->fp_status); - } - -+long double ldexpl(long double, int); -+ - void helper_fscale(void) - { - ST0 = ldexp (ST0, (int)(ST1)); Index: files/patch-osdep.c =================================================================== RCS file: /home/pcvs/ports/emulators/qemu-devel/files/patch-osdep.c,v retrieving revision 1.3 diff -u -p -r1.3 patch-osdep.c --- files/patch-osdep.c 10 Mar 2007 17:03:05 -0000 1.3 +++ files/patch-osdep.c 20 Jun 2008 19:45:28 -0000 @@ -1,5 +1,5 @@ Index: qemu/osdep.c -@@ -79,7 +79,9 @@ +@@ -68,7 +68,9 @@ #if defined(USE_KQEMU) @@ -9,7 +9,7 @@ Index: qemu/osdep.c #include #include -@@ -90,6 +92,7 @@ +@@ -79,6 +81,7 @@ const char *tmpdir; char phys_ram_file[1024]; void *ptr; @@ -17,7 +17,7 @@ Index: qemu/osdep.c #ifdef HOST_SOLARIS struct statvfs stfs; #else -@@ -151,12 +154,20 @@ +@@ -138,7 +141,9 @@ } unlink(phys_ram_file); } @@ -25,16 +25,19 @@ Index: qemu/osdep.c size = (size + 4095) & ~4095; +#ifndef __FreeBSD__ ftruncate(phys_ram_fd, phys_ram_size + size); - ptr = mmap(NULL, - size, - PROT_WRITE | PROT_READ, MAP_SHARED, - phys_ram_fd, phys_ram_size); -+#else -+ ptr = mmap(NULL, -+ size, -+ PROT_WRITE | PROT_READ, MAP_PRIVATE|MAP_ANON, -+ -1, 0); -+#endif - if (ptr == MAP_FAILED) { + ptr = mmap(NULL, + size, +@@ -148,6 +153,13 @@ fprintf(stderr, "Could not map physical memory\n"); exit(1); + } ++#else ++ ptr = malloc(size); ++ if (ptr == NULL) { ++ fprintf(stderr, "Could not allocate physical memory\n"); ++ exit(1); ++ } ++#endif + phys_ram_size += size; + return ptr; + } Index: files/patch-qemu-img.texi =================================================================== RCS file: /home/pcvs/ports/emulators/qemu-devel/files/patch-qemu-img.texi,v retrieving revision 1.3 diff -u -p -r1.3 patch-qemu-img.texi --- files/patch-qemu-img.texi 11 Mar 2008 23:34:14 -0000 1.3 +++ files/patch-qemu-img.texi 20 Jun 2008 19:45:28 -0000 @@ -1,19 +0,0 @@ -Index: qemu/qemu-img.texi -@@ -10,7 +10,7 @@ - @table @option - @item create [-e] [-6] [-b @var{base_image}] [-f @var{fmt}] @var{filename} [@var{size}] - @item commit [-f @var{fmt}] @var{filename} --@item convert [-c] [-e] [-6] [-f @var{fmt}] @var{filename} [-O @var{output_fmt}] @var{output_filename} -+@item convert [-c] [-e] [-6] [-f @var{fmt}] [-O @var{output_fmt}] @var{filename} @var{output_filename} - @item info [-f @var{fmt}] @var{filename} - @end table - -@@ -83,7 +83,7 @@ - - Commit the changes recorded in @var{filename} in its base image. - --@item convert [-c] [-e] [-f @var{fmt}] @var{filename} [-O @var{output_fmt}] @var{output_filename} -+@item convert [-c] [-e] [-f @var{fmt}] [-O @var{output_fmt}] @var{filename} @var{output_filename} - - Convert the disk image @var{filename} to disk image @var{output_filename} - using format @var{output_fmt}. It can be optionnaly encrypted Index: files/patch-tcg-tcg-op.h =================================================================== RCS file: /home/pcvs/ports/emulators/qemu-devel/files/patch-tcg-tcg-op.h,v retrieving revision 1.1 diff -u -p -r1.1 patch-tcg-tcg-op.h --- files/patch-tcg-tcg-op.h 12 Mar 2008 20:01:31 -0000 1.1 +++ files/patch-tcg-tcg-op.h 20 Jun 2008 19:45:28 -0000 @@ -1,19 +0,0 @@ -Index: qemu/tcg/tcg-op.h -@@ -1172,7 +1172,7 @@ - tcg_gen_op3i(INDEX_op_qemu_ld8s, ret, addr, mem_index); - #else - tcg_gen_op4i(INDEX_op_qemu_ld8s, ret, addr, TCGV_HIGH(addr), mem_index); -- tcg_gen_ext8s_i32(TCGV_HIGH(ret), ret); -+ tcg_gen_sari_i32(TCGV_HIGH(ret), ret, 31); - #endif - } - -@@ -1192,7 +1192,7 @@ - tcg_gen_op3i(INDEX_op_qemu_ld16s, ret, addr, mem_index); - #else - tcg_gen_op4i(INDEX_op_qemu_ld16s, ret, addr, TCGV_HIGH(addr), mem_index); -- tcg_gen_ext16s_i32(TCGV_HIGH(ret), ret); -+ tcg_gen_sari_i32(TCGV_HIGH(ret), ret, 31); - #endif - } - Index: files/patch-vl.c =================================================================== RCS file: /home/pcvs/ports/emulators/qemu-devel/files/patch-vl.c,v retrieving revision 1.10 diff -u -p -r1.10 patch-vl.c --- files/patch-vl.c 21 Mar 2008 17:31:52 -0000 1.10 +++ files/patch-vl.c 20 Jun 2008 19:45:28 -0000 @@ -7,23 +7,15 @@ Index: qemu/vl.c #else CharDriverState *qemu_chr_open_pty(void) -@@ -1771,14 +1771,14 @@ - return chr; +@@ -2334,7 +2334,7 @@ } + #endif -#if defined(__linux__) || defined(__sun__) +#if defined(__linux__) || defined(__sun__) || defined(__FreeBSD__) static CharDriverState *qemu_chr_open_pty(void) { struct termios tty; - char slave_name[1024]; - int master_fd, slave_fd; - --#if defined(__linux__) -+#if defined(__linux__) || defined(__FreeBSD__) - /* Not satisfying */ - if (openpty(&master_fd, &slave_fd, slave_name, NULL, NULL) < 0) { - return NULL; @@ -3036,7 +3036,7 @@ return qemu_chr_open_pp(filename); } else Index: files/patch-vl.c-nographic =================================================================== RCS file: /home/pcvs/ports/emulators/qemu-devel/files/patch-vl.c-nographic,v retrieving revision 1.3 diff -u -p -r1.3 patch-vl.c-nographic --- files/patch-vl.c-nographic 10 Mar 2007 17:15:07 -0000 1.3 +++ files/patch-vl.c-nographic 20 Jun 2008 19:45:28 -0000 @@ -1,9 +0,0 @@ -Index: qemu/vl.c -@@ -7131,6 +7131,7 @@ - case QEMU_OPTION_nographic: - pstrcpy(serial_devices[0], sizeof(serial_devices[0]), "stdio"); - pstrcpy(monitor_device, sizeof(monitor_device), "stdio"); -+ pstrcpy(parallel_devices[0], sizeof(parallel_devices[0]), "null"); - nographic = 1; - break; - case QEMU_OPTION_kernel: Index: files/patch-exec.c @@ -0,0 +1,30 @@ +Index: qemu/exec.c +@@ -405,6 +405,28 @@ + exit(1); + } + } ++#elif defined(__FreeBSD__) ++ { ++ int flags; ++ void *addr = NULL; ++ flags = MAP_PRIVATE | MAP_ANONYMOUS; ++#if defined(__x86_64__) ++ /* FreeBSD doesn't have MAP_32BIT, use MAP_FIXED and assume ++ * 0x40000000 is free */ ++ flags |= MAP_FIXED; ++ addr = (void *)0x40000000; ++ /* Cannot map more than that */ ++ if (code_gen_buffer_size > (800 * 1024 * 1024)) ++ code_gen_buffer_size = (800 * 1024 * 1024); ++#endif ++ code_gen_buffer = mmap(addr, code_gen_buffer_size, ++ PROT_WRITE | PROT_READ | PROT_EXEC, ++ flags, -1, 0); ++ if (code_gen_buffer == MAP_FAILED) { ++ fprintf(stderr, "Could not allocate dynamic translator buffer\n"); ++ exit(1); ++ } ++ } + #else + code_gen_buffer = qemu_malloc(code_gen_buffer_size); + if (!code_gen_buffer) { Index: files/patch-exec-all.h @@ -0,0 +1,10 @@ +Index: qemu/exec-all.h +@@ -30,7 +30,7 @@ + struct TranslationBlock; + + /* XXX: make safe guess about sizes */ +-#define MAX_OP_PER_INSTR 64 ++#define MAX_OP_PER_INSTR 128 /* 64 */ + /* A Call op needs up to 6 + 2N parameters (N = number of arguments). */ + #define MAX_OPC_PARAM 10 + #define OPC_BUF_SIZE 512 Index: files/patch-tcg-i386-tcg-target.c @@ -0,0 +1,54 @@ +Index: qemu/tcg/i386/tcg-target.c +@@ -359,25 +359,36 @@ + break; + case TCG_COND_LT: + tcg_out_brcond(s, TCG_COND_LT, args[1], args[3], const_args[3], args[5]); ++ if (const_args[2] && !args[2]) ++ /* test r,r - carry can never be set */ ++ break; + tcg_out_jxx(s, JCC_JNE, label_next); +- tcg_out_brcond(s, TCG_COND_LT, args[0], args[2], const_args[2], args[5]); ++ tcg_out_brcond(s, TCG_COND_LTU, args[0], args[2], const_args[2], args[5]); + break; + case TCG_COND_LE: + tcg_out_brcond(s, TCG_COND_LT, args[1], args[3], const_args[3], args[5]); + tcg_out_jxx(s, JCC_JNE, label_next); +- tcg_out_brcond(s, TCG_COND_LE, args[0], args[2], const_args[2], args[5]); ++ tcg_out_brcond(s, TCG_COND_LEU, args[0], args[2], const_args[2], args[5]); + break; + case TCG_COND_GT: + tcg_out_brcond(s, TCG_COND_GT, args[1], args[3], const_args[3], args[5]); + tcg_out_jxx(s, JCC_JNE, label_next); +- tcg_out_brcond(s, TCG_COND_GT, args[0], args[2], const_args[2], args[5]); ++ tcg_out_brcond(s, TCG_COND_GTU, args[0], args[2], const_args[2], args[5]); + break; + case TCG_COND_GE: ++ if (const_args[2] && !args[2]) { ++ /* test r,r - carry can never be set */ ++ tcg_out_brcond(s, TCG_COND_GE, args[1], args[3], const_args[3], args[5]); ++ break; ++ } + tcg_out_brcond(s, TCG_COND_GT, args[1], args[3], const_args[3], args[5]); + tcg_out_jxx(s, JCC_JNE, label_next); +- tcg_out_brcond(s, TCG_COND_GE, args[0], args[2], const_args[2], args[5]); ++ tcg_out_brcond(s, TCG_COND_GEU, args[0], args[2], const_args[2], args[5]); + break; + case TCG_COND_LTU: ++ if (const_args[2] && !args[2]) ++ /* test r,r - carry can never be set */ ++ break; + tcg_out_brcond(s, TCG_COND_LTU, args[1], args[3], const_args[3], args[5]); + tcg_out_jxx(s, JCC_JNE, label_next); + tcg_out_brcond(s, TCG_COND_LTU, args[0], args[2], const_args[2], args[5]); +@@ -393,6 +404,11 @@ + tcg_out_brcond(s, TCG_COND_GTU, args[0], args[2], const_args[2], args[5]); + break; + case TCG_COND_GEU: ++ if (const_args[2] && !args[2]) { ++ /* test r,r - carry can never be set */ ++ tcg_out_jxx(s, JCC_JMP, args[5]); ++ break; ++ } + tcg_out_brcond(s, TCG_COND_GTU, args[1], args[3], const_args[3], args[5]); + tcg_out_jxx(s, JCC_JNE, label_next); + tcg_out_brcond(s, TCG_COND_GEU, args[0], args[2], const_args[2], args[5]); Index: files/patch-target-i386-translate.c @@ -0,0 +1,16 @@ +Index: qemu/target-i386/translate.c +@@ -3330,8 +3330,12 @@ + op1_offset = offsetof(CPUX86State,xmm_regs[reg]); + tcg_gen_addi_ptr(cpu_ptr0, cpu_env, op1_offset); + sse_op2 = sse_op_table3[(s->dflag == 2) * 2 + ((b >> 8) - 2)]; +- tcg_gen_trunc_tl_i32(cpu_tmp2_i32, cpu_T[0]); +- tcg_gen_helper_0_2(sse_op2, cpu_ptr0, cpu_tmp2_i32); ++ if (ot == OT_LONG) { ++ tcg_gen_trunc_tl_i32(cpu_tmp2_i32, cpu_T[0]); ++ tcg_gen_helper_0_2(sse_op2, cpu_ptr0, cpu_tmp2_i32); ++ } else { ++ tcg_gen_helper_0_2(sse_op2, cpu_ptr0, cpu_T[0]); ++ } + break; + case 0x02c: /* cvttps2pi */ + case 0x12c: /* cvttpd2pi */ From kpeter at melbpc.org.au Mon Jul 7 09:22:25 2008 From: kpeter at melbpc.org.au (Peter Kostouros) Date: Mon Jul 7 09:22:32 2008 Subject: Linux 2.6 emulation and Linux Java problem In-Reply-To: <20080706094332.4de443b0@deskjail> References: <4870260D.1080203@melbpc.org.au> <20080706094332.4de443b0@deskjail> Message-ID: <4871E04B.305@melbpc.org.au> Alexander Leidinger wrote: > Quoting Peter Kostouros (Sun, 06 Jul 2008 01:55:25 +0000): > > >> Hi >> >> Is anyone having difficulty running Java applications (specifically >> linux-netbeans 6.1, linux-glassfish V2 and some Java applets) using >> linux-sun-jdk1.6.0_xx under CURRENT with Linux 2.6 emulation? >> >> I am running CURRENT as of 21JUN2008 with linux_base-f8. Invoking >> linux-netbeans causes a java instance to crash during startup, with >> ktrace on that instance showing >> > > Are you using linux_kdump, or the normal kdump? If the later, you need > to use the former. There's also the possibility to use dtrace (new > feature in current, so no HOWTO for the linux dtrace script available > yet). > > I used the normal kdump; unfortunately I could not install linux_kdump and did not persevere with it ("does not build with the default linux base, use the package instead" and I had a hiccup installing the package, too). I will look into dtrace over the weekend. >> 1860 java RET open 97/0x61 >> >> 1860 java CALL freebsd6_mmap(0x61, 0x2b639970, PROT_EXEC, MAP_FILE, 0xa5a5a5a5, ..., 0xa5a5a5a5, 0, ..., 0, 0xc, 0xdead0002, ... >> >> >> Note >> >> 1. These applications ran successfully with linux_base-fc4 and >> compat.linux.osrelease set to 2.4.2; >> 2. The success of running java applications also depends on >> debug.witness.watch: I get more mileage from java applications when this >> sysctl is 0. >> > > Do you get witness warning/errors on the console? Please check and > report them if there are any. > > Sun Jul 6 18:10:13 EST 2008 lock order reversal: 1st 0xc488be44 user map (user map) @ /mnt/cvs/FreeBSD/usr/src/sys/modules/linprocfs/../../compat/linprocfs/linprocfs.c:902 2nd 0xc4baf594 ufs (ufs) @ /mnt/cvs/FreeBSD/usr/src/sys/modules/linprocfs/../../compat/linprocfs/linprocfs.c:937 KDB: stack backtrace: db_trace_self_wrapper(c0b8c918,e67be73c,c080cc7e,c0b8f245,c4baf594,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0b8f245,c4baf594,c0b835ea,c0b835ea,c468853e,...) at kdb_backtrace+0x29 witness_checkorder(c4baf594,1,c468853e,3a9,e67be77c,...) at witness_checkorder+0x6ee __lockmgr_args(c4baf594,200400,c4baf5b0,0,0,...) at __lockmgr_args+0x221 ffs_lock(e67be840,c4b3402c,0,200400,c4baf53c,...) at ffs_lock+0x82 VOP_LOCK1_APV(c0c87e00,e67be840,c0ca04a0,c4baf53c,200400,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c4baf53c,200400,c468853e,3a9,e67be8b0,...) at _vn_lock+0x5e linprocfs_doprocmaps(c4b2e460,c4b85538,c468b100,c4657600,e67bec60,...) at linprocfs_doprocmaps+0x293 pfs_read(e67bebc8,c4b2e460,c49191f8,c4b2e460,e67bebe8,...) at pfs_read+0x59f VOP_READ_APV(c0c61ec0,e67bebc8,c0b96946,212,c0d286c8,...) at VOP_READ_APV+0xa5 vn_read(c49191f8,e67bec60,c47b8b00,0,c4b2e460,...) at vn_read+0x1ee dofileread(e67bec60,ffffffff,ffffffff,0,c49191f8,...) at dofileread+0x96 kern_readv(c4b2e460,3,e67bec60,28071000,1000,...) at kern_readv+0x58 read(c4b2e460,e67becfc,e67becf8,e67bed1c,c0eae408,...) at read+0x4f syscall(e67bed38) at syscall+0x2d3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, Linux ELF, read), eip = 0x2815ef71, esp = 0x2841e534, ebp = 0x2841e54c --- lock order reversal: 1st 0xc4ccf8b8 pseudofs (pseudofs) @ /mnt/cvs/FreeBSD/usr/src/sys/kern/vfs_vnops.c:530 2nd 0xc0cd48e4 sysctl lock (sysctl lock) @ /mnt/cvs/FreeBSD/usr/src/sys/kern/kern_sysctl.c:1086 KDB: stack backtrace: db_trace_self_wrapper(c0b8c918,e67a5a08,c080cc7e,c0b8f245,c0cd48e4,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0b8f245,c0cd48e4,c0b8a47c,c0b8a47c,c0b8a39d,...) at kdb_backtrace+0x29 witness_checkorder(c0cd48e4,9,c0b8a39d,43e,e67a5a58,...) at witness_checkorder+0x6ee _sx_xlock(c0cd48e4,0,c0b8a39d,43e,c4b2ed20,...) at _sx_xlock+0x7d kernel_sysctl(c4b2ed20,e67a5b38,2,e67a5ab8,e67a5b40,...) at kernel_sysctl+0x91 linprocfs_docpuinfo(c4b2ed20,0,c45e7b00,c4bbc4e0,e67a5c60,...) at linprocfs_docpuinfo+0x88 pfs_read(e67a5bc8,c4b2ed20,c4c97d90,c4b2ed20,e67a5be8,...) at pfs_read+0x59f VOP_READ_APV(c0c61ec0,e67a5bc8,c0b96946,212,c0d28690,...) at VOP_READ_APV+0xa5 vn_read(c4c97d90,e67a5c60,c47b8b00,0,c4b2ed20,...) at vn_read+0x1ee dofileread(e67a5c60,ffffffff,ffffffff,0,c4c97d90,...) at dofileread+0x96 kern_readv(c4b2ed20,bf,e67a5c60,2c025550,2000,...) at kern_readv+0x58 read(c4b2ed20,e67a5cfc,e67a5cf8,e67a5d1c,c0eae408,...) at read+0x4f syscall(e67a5d38) at syscall+0x2d3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, Linux ELF, read), eip = 0x2807f141, esp = 0x2c0254e4, ebp = 0x2c025518 --- pid 1523 (java), uid 1001 inumber 235542 on /home: filesystem full Jul 6 18:11:26 baron kernel: pid 1523 (java), uid 1001 inumber 235542 on /home: filesystem full pid 1523 (java), uid 1001: exited on signal 11 Jul 6 18:13:15 baron su: peter to root on /dev/ttyp1 > Bye, > Alexander. > > -- Regards Peter As always the organisation disavows knowledge of this email From bugmaster at FreeBSD.org Mon Jul 7 11:06:57 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 7 11:07:50 2008 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org Message-ID: <200807071106.m67B6usw061999@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/21463 emulation [linux] Linux compatability mode should not allow setu o kern/97326 emulation [linux] file descriptor leakage in linux emulation o kern/117010 emulation [linux] linux_getdents() get something like buffer ove 3 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 o kern/29698 emulation [linux] [patch] linux ipcs doesn'work o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/41543 emulation [patch] [request] easier wine/w23 support a kern/72920 emulation [linux]: path "prefixing" is not done on unix domain s o kern/73777 emulation [linux] [patch] linux emulation: root dir special hand o kern/91293 emulation [svr4] [patch] *Experimental* Update to the SVR4 emula o ports/91318 emulation [fix] graphics/linux_dri: works on amd64 too o ports/121800 emulation x11-toolkits/linux-openmotif - OpenMotif upgrade to 2. o kern/122318 emulation [linux] [cmake]: Segmentation fault when running Linux o ports/123960 emulation Port fix: archivers/linux-par2cmdline - better handlin o ports/123964 emulation Mk fix: bsd.linux-rpm.mk - Handling of NOPORTDOCS 12 problems total. From rdivacky at freebsd.org Mon Jul 7 11:16:22 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Mon Jul 7 11:16:35 2008 Subject: Linux 2.6 emulation and Linux Java problem In-Reply-To: <4871E04B.305@melbpc.org.au> References: <4870260D.1080203@melbpc.org.au> <20080706094332.4de443b0@deskjail> <4871E04B.305@melbpc.org.au> Message-ID: <20080707111515.GA41171@freebsd.org> > I used the normal kdump; unfortunately I could not install linux_kdump > and did not persevere with it ("does not build with the default linux > base, use the package instead" and I had a hiccup installing the > package, too). I will look into dtrace over the weekend. try the linux_kdump... the dtrace might have problems on its own as it is really new code... > >>1860 java RET open 97/0x61 > >> > >>1860 java CALL freebsd6_mmap(0x61, 0x2b639970, PROT_EXEC, MAP_FILE, > >>0xa5a5a5a5, ..., 0xa5a5a5a5, 0, ..., 0, 0xc, 0xdead0002, ... > >> > >> > >>Note > >> > >>1. These applications ran successfully with linux_base-fc4 and > >>compat.linux.osrelease set to 2.4.2; > >>2. The success of running java applications also depends on > >>debug.witness.watch: I get more mileage from java applications when this > >>sysctl is 0. > >> > > > >Do you get witness warning/errors on the console? Please check and > >report them if there are any. a LOR could lead to a deadlock not a crash.... if you still have the ktrace.out I believe you can put it on a web and we can run our own linux_kdump on it to see what happened. can you make that available? From avg at icyb.net.ua Wed Jul 9 17:42:59 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Jul 9 17:43:06 2008 Subject: 6.3/amd64: linux guest hangs if kqemu is used Message-ID: <4874F262.9050608@icyb.net.ua> This report is quite low on details. My system is 6.3-RELEASE amd64. I have qemu-0.9.1_9 and kqemu-kmod-1.3.0.p11_9. Guest is 2.6.25.9-76.fc9.x86_64. kqemu.ko and aio.ko are loaded. Run like this is OK: qemu-system-x86_64 -no-kqemu -m 640 -hda box1.img -net nic -net tap Run like this - guest hangs during boot: qemu-system-x86_64 -m 640 -hda box1.img -net nic -net tap There are no messages on qemu output or in system log. qemu uses 100% CPU. Ctrl+Alt+2 works, I can execute commands in qemu console. BTW, info kqemu says "enabled for user code". Guest console messages: ... PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report NetLabel: Initializing NetLabel: domain hash size = 128 NetLabel: protocols = UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default PCI-GART: No AMD northbridge found. ! ! kqemu hang is here ! ! NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 6, 262144 bytes) TCP established hash table entries: 131072 (order: 9, 2097152 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered checking if image is initramfs...<7>Switched to high resolution mode on CPU 0 Clocksource tsc unstable (delta = 778613351 ns) it is ... -- Andriy Gapon From nox at jelal.kn-bremen.de Wed Jul 9 20:52:41 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Wed Jul 9 20:52:47 2008 Subject: 6.3/amd64: linux guest hangs if kqemu is used In-Reply-To: <4874F262.9050608@icyb.net.ua> References: <4874F262.9050608@icyb.net.ua> Message-ID: <20080709204910.GA11133@saturn.kn-bremen.de> On Wed, Jul 09, 2008 at 08:16:18PM +0300, Andriy Gapon wrote: > > This report is quite low on details. > > My system is 6.3-RELEASE amd64. > I have qemu-0.9.1_9 and kqemu-kmod-1.3.0.p11_9. > Guest is 2.6.25.9-76.fc9.x86_64. > > kqemu.ko and aio.ko are loaded. > > Run like this is OK: > qemu-system-x86_64 -no-kqemu -m 640 -hda box1.img -net nic -net tap > > Run like this - guest hangs during boot: > qemu-system-x86_64 -m 640 -hda box1.img -net nic -net tap > > There are no messages on qemu output or in system log. > qemu uses 100% CPU. > Ctrl+Alt+2 works, I can execute commands in qemu console. > BTW, info kqemu says "enabled for user code". > > Guest console messages: > ... > PCI: Using ACPI for IRQ routing > PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a > report > NetLabel: Initializing > NetLabel: domain hash size = 128 > NetLabel: protocols = UNLABELED CIPSOv4 > NetLabel: unlabeled traffic allowed by default > PCI-GART: No AMD northbridge found. > ! > ! kqemu hang is here ! > ! > NET: Registered protocol family 2 > IP route cache hash table entries: 32768 (order: 6, 262144 bytes) > TCP established hash table entries: 131072 (order: 9, 2097152 bytes) > TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) > TCP: Hash tables configured (established 131072 bind 65536) > TCP reno registered > checking if image is initramfs...<7>Switched to high resolution mode on > CPU 0 > Clocksource tsc unstable (delta = 778613351 ns) > it is > ... > > -- > Andriy Gapon It is true kqemu works less well on amd64 than on 32 bit hosts... (tho things have improved in qemu svn especially for 32 bit guests - the snapshot I just updated the qemu-devel port to can now also use kqemu for the 32 bit `qemu'.) Oh, if you host is SMP you probably need to pass `notsc' to your guest linux kernel, if its not that or you still get problems later you can still try the qemu-devel port (which also uses a new kqemu as mentioned in ports/UPDATING), but otherwise I guess you can only report the bug upstream i.e. on the qemu-devel mailinglist: http://lists.gnu.org/mailman/listinfo/qemu-devel HTH, Juergen From saper at system.pl Fri Jul 11 11:44:13 2008 From: saper at system.pl (Marcin Cieslak) Date: Fri Jul 11 11:44:19 2008 Subject: linux emulation: Preliminary support for more auxvec's Message-ID: Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 273 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080711/20e6db40/signature.pgp From kostikbel at gmail.com Fri Jul 11 12:35:56 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Jul 11 12:36:04 2008 Subject: linux emulation: Preliminary support for more auxvec's In-Reply-To: References: Message-ID: <20080711115436.GZ17123@deviant.kiev.zoral.com.ua> On Fri, Jul 11, 2008 at 01:43:55PM +0200, Marcin Cieslak wrote: > Hello, > > Attached please find a simple diff to implement additional loader > information (for background please see: > http://lists.freebsd.org/pipermail/freebsd-emulation/2006-September/002591.html) > > This patch creates linux_get_machine() making linux_new_uname > platform-independent. > > AT_PLATFORM is not yet implemented, since I need to allocate a string > for it on the user stack. I *could* use something on the SPARE_USRSPACE, > but I think we got rid of all such tricks long time ago. I think I dealt with the similar problem in the implementation of the $ORIGIN support for the rtld, that is WIP for long time. Namely, AT_EXECPATH (somewhat similar to the Solaris auxvec of the same name) provides (might be relative) path for the binary being executed. See http://people.freebsd.org/~kib/misc/rtld-origin.1.patch > > A bit better solution might be to change linux_copyout_strings to > allocate more space for the AT_PLATFORM (but how do I then pass the > pointer to the elf_linux_fixup?) > > This would also mean to bring the linux_copyout_strings to i386. > > What's the best way to do this? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080711/7e42d194/attachment.pgp From avg at icyb.net.ua Fri Jul 11 14:31:11 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri Jul 11 14:32:23 2008 Subject: 6.3/amd64: linux guest hangs if kqemu is used In-Reply-To: <20080709204910.GA11133@saturn.kn-bremen.de> References: <4874F262.9050608@icyb.net.ua> <20080709204910.GA11133@saturn.kn-bremen.de> Message-ID: <48776EA3.5040107@icyb.net.ua> on 09/07/2008 23:49 Juergen Lock said the following: > On Wed, Jul 09, 2008 at 08:16:18PM +0300, Andriy Gapon wrote: >> This report is quite low on details. >> >> My system is 6.3-RELEASE amd64. >> I have qemu-0.9.1_9 and kqemu-kmod-1.3.0.p11_9. >> Guest is 2.6.25.9-76.fc9.x86_64. >> >> kqemu.ko and aio.ko are loaded. >> >> Run like this is OK: >> qemu-system-x86_64 -no-kqemu -m 640 -hda box1.img -net nic -net tap >> >> Run like this - guest hangs during boot: >> qemu-system-x86_64 -m 640 -hda box1.img -net nic -net tap [snip] > > It is true kqemu works less well on amd64 than on 32 bit hosts... > (tho things have improved in qemu svn especially for 32 bit guests - the > snapshot I just updated the qemu-devel port to can now also use kqemu > for the 32 bit `qemu'.) > > Oh, if you host is SMP you probably need to pass `notsc' to your > guest linux kernel, if its not that or you still get problems later > you can still try the qemu-devel port (which also uses a new kqemu as > mentioned in ports/UPDATING), but otherwise I guess you can only report > the bug upstream i.e. on the qemu-devel mailinglist: > http://lists.gnu.org/mailman/listinfo/qemu-devel J?rgen, thank you very much for the advice! notsc allowed linux boot to proceed past the hand point, but later qemu process aborted with the following output: $ qemu-system-x86_64 -m 800 -hda box1.img -net nic -net tap RAX=00007f7e43358000 RBX=00007f7e43358560 RCX=0000003c10615c5a RDX=0000000000000001 RSI=0000003c10618934 RDI=0000000000000000 RBP=00007f7e43358000 RSP=00007fff4b3573b0 R8 =00000000ffffffff R9 =0000000000000000 R10=0000000000000022 R11=0000000000010246 R12=0000000000000000 R13=0000000000000000 R14=0000000000000010 R15=0000000000000001 RIP=0000003c1060a667 RFL=00010206 [-----P-] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES =0000 0000000000000000 00000000 00000000 CS =0033 0000000000000000 ffffffff 00affb00 SS =002b 0000000000000000 ffffffff 00cff300 DS =0000 0000000000000000 00000000 00000000 FS =0000 0000000000000000 00000000 00000000 GS =0000 0000000000000000 00000000 00000000 LDT=0000 0000000000000000 00000000 00008000 TR =0040 ffff810001009900 00002087 00008900 GDT= ffffffff81456000 00000080 IDT= ffffffff814c2000 00000fff CR0=8005003b CR2=00007f7e43358028 CR3=0000000030dfc000 CR4=000006e0 Unsupported return value: 0xffffffff This happened while starting userland daemons. I used "interactive startup" and the problem occurred on sendmail (sm-client) [!]. The problem is reliably reproducible. P.S. I disabled sendmail, services startup proceeded few more steps and then qemu reported same error again ("Unsupported return value") on some other service. I gave up after that. -- Andriy Gapon From avg at icyb.net.ua Fri Jul 11 14:37:24 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri Jul 11 14:37:31 2008 Subject: 6.3/amd64: linux guest hangs if kqemu is used In-Reply-To: <20080709204910.GA11133@saturn.kn-bremen.de> References: <4874F262.9050608@icyb.net.ua> <20080709204910.GA11133@saturn.kn-bremen.de> Message-ID: <4877701D.8060402@icyb.net.ua> on 09/07/2008 23:49 Juergen Lock said the following: > On Wed, Jul 09, 2008 at 08:16:18PM +0300, Andriy Gapon wrote: >> This report is quite low on details. >> >> My system is 6.3-RELEASE amd64. >> I have qemu-0.9.1_9 and kqemu-kmod-1.3.0.p11_9. >> Guest is 2.6.25.9-76.fc9.x86_64. >> >> kqemu.ko and aio.ko are loaded. >> >> Run like this is OK: >> qemu-system-x86_64 -no-kqemu -m 640 -hda box1.img -net nic -net tap >> >> Run like this - guest hangs during boot: >> qemu-system-x86_64 -m 640 -hda box1.img -net nic -net tap [snip] > > It is true kqemu works less well on amd64 than on 32 bit hosts... > (tho things have improved in qemu svn especially for 32 bit guests - the > snapshot I just updated the qemu-devel port to can now also use kqemu > for the 32 bit `qemu'.) > > Oh, if you host is SMP you probably need to pass `notsc' to your > guest linux kernel, if its not that or you still get problems later > you can still try the qemu-devel port (which also uses a new kqemu as > mentioned in ports/UPDATING), but otherwise I guess you can only report > the bug upstream i.e. on the qemu-devel mailinglist: > http://lists.gnu.org/mailman/listinfo/qemu-devel J?rgen, thank you very much for the advice! notsc allowed linux boot to proceed past the hand point, but later qemu process aborted with the following output: $ qemu-system-x86_64 -m 800 -hda box1.img -net nic -net tap RAX=00007f7e43358000 RBX=00007f7e43358560 RCX=0000003c10615c5a RDX=0000000000000001 RSI=0000003c10618934 RDI=0000000000000000 RBP=00007f7e43358000 RSP=00007fff4b3573b0 R8 =00000000ffffffff R9 =0000000000000000 R10=0000000000000022 R11=0000000000010246 R12=0000000000000000 R13=0000000000000000 R14=0000000000000010 R15=0000000000000001 RIP=0000003c1060a667 RFL=00010206 [-----P-] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES =0000 0000000000000000 00000000 00000000 CS =0033 0000000000000000 ffffffff 00affb00 SS =002b 0000000000000000 ffffffff 00cff300 DS =0000 0000000000000000 00000000 00000000 FS =0000 0000000000000000 00000000 00000000 GS =0000 0000000000000000 00000000 00000000 LDT=0000 0000000000000000 00000000 00008000 TR =0040 ffff810001009900 00002087 00008900 GDT= ffffffff81456000 00000080 IDT= ffffffff814c2000 00000fff CR0=8005003b CR2=00007f7e43358028 CR3=0000000030dfc000 CR4=000006e0 Unsupported return value: 0xffffffff This happened while starting userland daemons. I used "interactive startup" and the problem occurred on sendmail (sm-client) [!]. The problem is reliably reproducible. P.S. I disabled sendmail, services startup proceeded few more steps and then qemu reported same error again ("Unsupported return value") on some other service. I gave up after that. -- Andriy Gapon From avg at icyb.net.ua Fri Jul 11 14:40:39 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri Jul 11 14:40:46 2008 Subject: 6.3/amd64: linux guest hangs if kqemu is used In-Reply-To: <4877701D.8060402@icyb.net.ua> References: <4874F262.9050608@icyb.net.ua> <20080709204910.GA11133@saturn.kn-bremen.de> <4877701D.8060402@icyb.net.ua> Message-ID: <487770E4.8030005@icyb.net.ua> on 11/07/2008 17:37 Andriy Gapon said the following: > on 09/07/2008 23:49 Juergen Lock said the following: >> On Wed, Jul 09, 2008 at 08:16:18PM +0300, Andriy Gapon wrote: >>> This report is quite low on details. >>> >>> My system is 6.3-RELEASE amd64. >>> I have qemu-0.9.1_9 and kqemu-kmod-1.3.0.p11_9. >>> Guest is 2.6.25.9-76.fc9.x86_64. >>> >>> kqemu.ko and aio.ko are loaded. >>> >>> Run like this is OK: >>> qemu-system-x86_64 -no-kqemu -m 640 -hda box1.img -net nic -net tap >>> >>> Run like this - guest hangs during boot: >>> qemu-system-x86_64 -m 640 -hda box1.img -net nic -net tap > [snip] >> It is true kqemu works less well on amd64 than on 32 bit hosts... >> (tho things have improved in qemu svn especially for 32 bit guests - the >> snapshot I just updated the qemu-devel port to can now also use kqemu >> for the 32 bit `qemu'.) >> >> Oh, if you host is SMP you probably need to pass `notsc' to your >> guest linux kernel, if its not that or you still get problems later >> you can still try the qemu-devel port (which also uses a new kqemu as >> mentioned in ports/UPDATING), but otherwise I guess you can only report >> the bug upstream i.e. on the qemu-devel mailinglist: >> http://lists.gnu.org/mailman/listinfo/qemu-devel > > J?rgen, > > thank you very much for the advice! > notsc allowed linux boot to proceed past the hand point, but later qemu > process aborted with the following output: > > $ qemu-system-x86_64 -m 800 -hda box1.img -net nic -net tap > RAX=00007f7e43358000 RBX=00007f7e43358560 RCX=0000003c10615c5a > RDX=0000000000000001 > RSI=0000003c10618934 RDI=0000000000000000 RBP=00007f7e43358000 > RSP=00007fff4b3573b0 > R8 =00000000ffffffff R9 =0000000000000000 R10=0000000000000022 > R11=0000000000010246 > R12=0000000000000000 R13=0000000000000000 R14=0000000000000010 > R15=0000000000000001 > RIP=0000003c1060a667 RFL=00010206 [-----P-] CPL=3 II=0 A20=1 SMM=0 HLT=0 > ES =0000 0000000000000000 00000000 00000000 > CS =0033 0000000000000000 ffffffff 00affb00 > SS =002b 0000000000000000 ffffffff 00cff300 > DS =0000 0000000000000000 00000000 00000000 > FS =0000 0000000000000000 00000000 00000000 > GS =0000 0000000000000000 00000000 00000000 > LDT=0000 0000000000000000 00000000 00008000 > TR =0040 ffff810001009900 00002087 00008900 > GDT= ffffffff81456000 00000080 > IDT= ffffffff814c2000 00000fff > CR0=8005003b CR2=00007f7e43358028 CR3=0000000030dfc000 CR4=000006e0 > Unsupported return value: 0xffffffff > > This happened while starting userland daemons. I used "interactive > startup" and the problem occurred on sendmail (sm-client) [!]. > The problem is reliably reproducible. > > P.S. I disabled sendmail, services startup proceeded few more steps and > then qemu reported same error again ("Unsupported return value") on some > other service. I gave up after that. > Just noticed - the following was in system log: kqemu: aborting: Unexpected exception 0x0d in monitor space err=0000 CS:EIP=f180:00000000f0002806 SS:SP=0000:00000000f00c7e00 -- Andriy Gapon From saper at system.pl Fri Jul 11 19:55:51 2008 From: saper at system.pl (Marcin Cieslak) Date: Fri Jul 11 19:55:57 2008 Subject: linux emulation: Preliminary support for more auxvec's [patch] In-Reply-To: <20080711115436.GZ17123@deviant.kiev.zoral.com.ua> References: <20080711115436.GZ17123@deviant.kiev.zoral.com.ua> Message-ID: <4877BAB8.1030804@system.pl> Kostik Belousov wrote: > On Fri, Jul 11, 2008 at 01:43:55PM +0200, Marcin Cieslak wrote: >> Hello, >> >> Attached please find a simple diff to implement additional loader >> information (for background please see: >> http://lists.freebsd.org/pipermail/freebsd-emulation/2006-September/002591.html) > Namely, AT_EXECPATH (somewhat similar to the Solaris auxvec of the same > name) provides (might be relative) path for the binary being executed. Thank you very much. I have implemented the AT_PLATFORM, therefore all 2.6.16 (and later) i386/amd64 auxvecs are implemented, except for AT_SYSINFO and AT_SYSINFO_EHDR that are i386-specific and provide optional way of invoking linux syscalls (using so-called virtual dynamic shared object). I think we don't need those. The code is completely untested on i386. My first attempts show that skype and acroread8 launch faster (probably due to the "hz" effect). The patch is here: http://akson.sgh.waw.pl/~saper/FreeBSD/linux/auxvec.diff This was made against 7-STABLE, but there no major differences in -current. It is also trivial to port to 64-bit amd64 emulation. --Marcin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 273 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080711/defbdd21/signature.pgp From kostikbel at gmail.com Fri Jul 11 20:14:55 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Jul 11 20:15:02 2008 Subject: linux emulation: Preliminary support for more auxvec's [patch] In-Reply-To: <4877BAB8.1030804@system.pl> References: <20080711115436.GZ17123@deviant.kiev.zoral.com.ua> <4877BAB8.1030804@system.pl> Message-ID: <20080711201450.GB17123@deviant.kiev.zoral.com.ua> On Fri, Jul 11, 2008 at 09:55:36PM +0200, Marcin Cieslak wrote: > Kostik Belousov wrote: > >On Fri, Jul 11, 2008 at 01:43:55PM +0200, Marcin Cieslak wrote: > >>Hello, > >> > >>Attached please find a simple diff to implement additional loader > >>information (for background please see: > >>http://lists.freebsd.org/pipermail/freebsd-emulation/2006-September/002591.html) > >Namely, AT_EXECPATH (somewhat similar to the Solaris auxvec of the same > >name) provides (might be relative) path for the binary being executed. > > Thank you very much. > > I have implemented the AT_PLATFORM, therefore all 2.6.16 (and later) > i386/amd64 auxvecs are implemented, except for AT_SYSINFO and > AT_SYSINFO_EHDR that are i386-specific and provide optional way of > invoking linux syscalls (using so-called virtual dynamic shared object). > > I think we don't need those. Do you know of any situation where we _must_ have those new auxvec you implemented ? > > The code is completely untested on i386. My first attempts show that > skype and acroread8 launch faster (probably due to the "hz" effect). > > The patch is here: > > http://akson.sgh.waw.pl/~saper/FreeBSD/linux/auxvec.diff I only briefly looked over it. I suggest that the new AT_COUNT requires more thinking. Look at the src/libexec/rtld-elf/rtld.c, _rtld(), at line 338, where the auxvec is digested by FreeBSD dynamic linker. It seems to be harmless, but at least this is inconsistent. May be, AT_LINUX_PLATFORM etc defines would make more sense. Do you actually need imgp->machine member ? It seems that it is used only inside linux_copyout_strings ? > > This was made against 7-STABLE, but there no major differences in > -current. It is also trivial to port to 64-bit amd64 emulation. Hmm, what are you referencing there ? I know only about one mostly stalled effort. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080711/60ce0a7a/attachment.pgp From saper at SYSTEM.PL Fri Jul 11 21:10:04 2008 From: saper at SYSTEM.PL (Marcin Cieslak) Date: Fri Jul 11 21:10:11 2008 Subject: kern/97326: [linux] file descriptor leakage in linux emulation Message-ID: <200807112110.m6BLA3o4090145@freefall.freebsd.org> The following reply was made to PR kern/97326; it has been noted by GNATS. From: Marcin Cieslak To: bug-followup@FreeBSD.org, bakul@bitblocks.com Cc: Subject: Re: kern/97326: [linux] file descriptor leakage in linux emulation Date: Fri, 11 Jul 2008 23:02:36 +0200 This should be fixed in FreeBSD 7 as of November 2007: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/linux/linux_ioctl.c.diff?r1=1.138;r2=1.138.2.1 Can you check this? -- << Marcin Cieslak // saper@system.pl >> From saper at system.pl Fri Jul 11 21:39:07 2008 From: saper at system.pl (Marcin Cieslak) Date: Fri Jul 11 21:39:13 2008 Subject: linux emulation: Preliminary support for more auxvec's [patch] In-Reply-To: <20080711201450.GB17123@deviant.kiev.zoral.com.ua> References: <20080711115436.GZ17123@deviant.kiev.zoral.com.ua> <4877BAB8.1030804@system.pl> <20080711201450.GB17123@deviant.kiev.zoral.com.ua> Message-ID: <4877D2E7.9020408@system.pl> Kostik Belousov wrote: > Do you know of any situation where we _must_ have those new auxvec you > implemented ? No, I learned about them today when I analyzed my auxvec fingerprint from the real amd64 and i386 Linux boxes. > >> >> http://akson.sgh.waw.pl/~saper/FreeBSD/linux/auxvec.diff > I only briefly looked over it. > > I suggest that the new AT_COUNT requires more thinking. Look at the > src/libexec/rtld-elf/rtld.c, _rtld(), at line 338, where the auxvec is > digested by FreeBSD dynamic linker. It seems to be harmless, but at > least this is inconsistent. May be, AT_LINUX_PLATFORM etc defines > would make more sense. machine/elf.h will get updated with installworld (or make install in includes) and rtld should get be recompiled with this. I did this and it works fine as it worked. The impact of this is limited, since all the auxvec's rtld need are stored early. I don't think the AT_COUNT things is correct. > > Do you actually need imgp->machine member ? It seems that it is used > only inside linux_copyout_strings ? No, it's referenced in elf_linux_fixup - that's the reason I need it. >> This was made against 7-STABLE, but there no major differences in >> -current. It is also trivial to port to 64-bit amd64 emulation. > Hmm, what are you referencing there ? I know only about one mostly > stalled effort. Well, anyway the logic is pretty platform-independent and one needs to be careful about pointer sizes (AT_PLATFORM) and such. Newly introduced linux_get_machine should take care of the 64-bit case. If we are going to support dynamic switching between 32 and 64 bit code this will need to be dynamic as well ("x86_64" vs "i686"). I have my doubts about the linux_times() function in linux_misc.c, it tries to convert the clock tick to the FreeBSD value. Maybe it's no longer necessary. If this is a problem, we can hardcode value "100" as being returned. --Marcin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 273 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080711/eb32999b/signature.pgp From kpeter at melbpc.org.au Sat Jul 12 00:19:48 2008 From: kpeter at melbpc.org.au (Peter Kostouros) Date: Sat Jul 12 00:19:56 2008 Subject: Linux 2.6 emulation and Linux Java problem In-Reply-To: <20080707111515.GA41171@freebsd.org> References: <4870260D.1080203@melbpc.org.au> <20080706094332.4de443b0@deskjail> <4871E04B.305@melbpc.org.au> <20080707111515.GA41171@freebsd.org> Message-ID: <4877F898.9080905@melbpc.org.au> Roman Divacky wrote: >> I used the normal kdump; unfortunately I could not install linux_kdump >> and did not persevere with it ("does not build with the default linux >> base, use the package instead" and I had a hiccup installing the >> package, too). I will look into dtrace over the weekend. >> > > try the linux_kdump... the dtrace might have problems on its own as it > is really new code... > > OK, I installed linux_kdump. >>>> 1860 java RET open 97/0x61 >>>> >>>> 1860 java CALL freebsd6_mmap(0x61, 0x2b639970, PROT_EXEC, MAP_FILE, >>>> 0xa5a5a5a5, ..., 0xa5a5a5a5, 0, ..., 0, 0xc, 0xdead0002, ... >>>> >>>> >>>> Note >>>> >>>> 1. These applications ran successfully with linux_base-fc4 and >>>> compat.linux.osrelease set to 2.4.2; >>>> 2. The success of running java applications also depends on >>>> debug.witness.watch: I get more mileage from java applications when this >>>> sysctl is 0. >>>> >>>> >>> Do you get witness warning/errors on the console? Please check and >>> report them if there are any. >>> > > a LOR could lead to a deadlock not a crash.... if you still have the ktrace.out > I believe you can put it on a web and we can run our own linux_kdump on it to > see what happened. can you make that available? > > ktrace.out is about 500MB. Anyways, one java process looks to be looping: RET linux_sys_futex -1 errno 110 Unknown error: 110 CALL linux_sys_futex(0x8092528,0x81,0x1,0xfffffffd,0x8092528,0x2affd250) RET linux_sys_futex 1 CALL linux_clock_gettime(0x1,0x2affd290) RET linux_clock_gettime 0 CALL gettimeofday(0x2affd2a8,0) RET gettimeofday 0 CALL linux_clock_gettime(0x1,0x2affd290) RET linux_clock_gettime 0 CALL linux_clock_gettime(0x1,0x2affd290) RET linux_clock_gettime 0 CALL gettimeofday(0x2affd240,0) RET gettimeofday 0 CALL linux_clock_gettime(0x1,0x2affd21c) RET linux_clock_gettime 0 CALL linux_sys_futex(0x80e0acc,0x80,0x1,0x2affd21c,0x1,0x2affd280) and another over sched_yield (although I am uncertain as I have not examined the entire dump). Let me know if you want anything from the trace. From bakul at bitblocks.com Sat Jul 12 01:00:07 2008 From: bakul at bitblocks.com (Bakul Shah) Date: Sat Jul 12 01:00:13 2008 Subject: kern/97326: [linux] file descriptor leakage in linux emulation Message-ID: <200807120100.m6C1070D009343@freefall.freebsd.org> The following reply was made to PR kern/97326; it has been noted by GNATS. From: Bakul Shah To: Marcin Cieslak Cc: bug-followup@FreeBSD.org, bakul@bitblocks.com Subject: Re: kern/97326: [linux] file descriptor leakage in linux emulation Date: Fri, 11 Jul 2008 17:33:11 -0700 On Fri, 11 Jul 2008 23:02:36 +0200 Marcin Cieslak wrote: > > This should be fixed in FreeBSD 7 as of November 2007: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/linux/linux_ioctl.c.diff > ?r1=1.138;r2=1.138.2.1 > > Can you check this? I couldn't test on the original machine with linux_base-fc-4 so I tested it on amd64 machine with linux_base-fc-8. Skype still seems to keep open far too many descriptors (480 compared to 140 on the mac) and this number goes up to 663 when making a skype test call but there seems to be no further leakage. Thanks! From itetcu at FreeBSD.org Sat Jul 12 14:04:45 2008 From: itetcu at FreeBSD.org (QA Tindy) Date: Sat Jul 12 14:04:51 2008 Subject: graphics/linux-png - fails: FAIL Message-ID: <20080712064352.8E39812E3E81@quark.ds9.tecnik93.com> Hi, The build which triggered this email is done under tinderbox-2.4.3, on 7-STABLE on amd64, with tinderd_flags="-nullfs -plistcheck -onceonly" and ccache support, with the official up-to-date Ports Tree (for commit-triggered builds the files are fetched via CVSWeb), with the following vars set: NOPORTDOCS=yes, NOPORTEXAMPLES=yes, NOPORTDATA=yes, FORCE_PACKAGE=yes. Except from http://t64.tecnik93.com/logs/7-STABLE-FTP/linux-png-1.2.8_2.log: building linux-png-1.2.8_2 in directory /var/tinderbox/7-STABLE-FTP maintained by: freebsd-emulation@FreeBSD.org building for: 7.0-STABLE amd64 port directory: /usr/ports/graphics/linux-png Makefile ident: $FreeBSD: ports/graphics/linux-png/Makefile,v 1.24 2008/04/19 17:50:26 miwi Exp $ prefixes: LOCALBASE=usr/local X11BASE=usr/local NO* env vars: NOPORTDOCS=yes NOPORTEXAMPLES=yes NOPORTDATA=yes build started at Sat Jul 12 06:43:02 UTC 2008 ................................................... Let your lists for hosts, passwd and group be resolved via nsswitch.conf: passwd: files nis shadow: files nis group: files nis hosts: files dns nis WARNING: doing work which needs to chroot into the linux base may not work. In such cases (e.g. cross-development) you are better suited with a linux_dist port. ===> Installing for linux-png-1.2.8_2 ===> linux-png-1.2.8_2 depends on file: /compat/linux/etc/fedora-release - found ===> Generating temporary packing list ===> Checking if graphics/linux-png already installed cd /work/a/ports/graphics/linux-png/work && /usr/bin/find * -type d -exec /bin/mkdir -p "/compat/linux/{}" \; cd /work/a/ports/graphics/linux-png/work && /usr/bin/find * ! -type d | /usr/bin/cpio -pm -R root:wheel /compat/linux 790 blocks ===> Running linux ldconfig /compat/linux/sbin/ldconfig -r /compat/linux ===> Registering installation for linux-png-1.2.8_2 ================================================================ ======================================== ===> Building package for linux-png-1.2.8_2 Creating package /tmp/packages/All/linux-png-1.2.8_2.tbz Registering depends: linux_base-fc-4_13. Creating bzip'd tar ball in '/tmp/packages/All/linux-png-1.2.8_2.tbz' Deleting linux-png-1.2.8_2 ================================================================ === Checking filesystem state list of extra files and directories in / (not present before this port was installed but present after it was deinstalled) 15238400 4 drwxr-xr-x 2 root wheel 512 Jul 12 06:43 compat/linux/usr/share/doc/libpng-1.2.8 15238401 156 -rw-r--r-- 1 root wheel 79441 Jul 12 06:43 compat/linux/usr/share/doc/libpng-1.2.8/CHANGES 15238403 12 -rw-r--r-- 1 root wheel 4105 Jul 12 06:43 compat/linux/usr/share/doc/libpng-1.2.8/LICENSE 15238410 28 -rw-r--r-- 1 root wheel 13988 Jul 12 06:43 compat/linux/usr/share/doc/libpng-1.2.8/README 15238418 4 -rw-r--r-- 1 root wheel 1182 Jul 12 06:43 compat/linux/usr/share/doc/libpng-1.2.8/TODO 15238419 60 -rw-r--r-- 1 root wheel 29793 Jul 12 06:43 compat/linux/usr/share/doc/libpng-1.2.8/example.c 15238420 252 -rw-r--r-- 1 root wheel 127770 Jul 12 06:43 compat/linux/usr/share/doc/libpng-1.2.8/libpng.txt ================================================================ build of /usr/ports/graphics/linux-png ended at Sat Jul 12 06:43:49 UTC 2008 A description of the testing process can be found here: http://T32.TecNik93.com/FreeBSD/QA-Tindy/testing_process.txt Thanks for your work on making FreeBSD better, -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B From rdivacky at freebsd.org Sun Jul 13 06:21:28 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Sun Jul 13 06:21:36 2008 Subject: Linux 2.6 emulation and Linux Java problem In-Reply-To: <4877F898.9080905@melbpc.org.au> References: <4870260D.1080203@melbpc.org.au> <20080706094332.4de443b0@deskjail> <4871E04B.305@melbpc.org.au> <20080707111515.GA41171@freebsd.org> <4877F898.9080905@melbpc.org.au> Message-ID: <20080713061943.GA67395@freebsd.org> > ktrace.out is about 500MB. > > Anyways, one java process looks to be looping: > > RET linux_sys_futex -1 errno 110 Unknown error: 110 what is the call of the futex that causes this error to happen? that might be the culprit > CALL linux_sys_futex(0x8092528,0x81,0x1,0xfffffffd,0x8092528,0x2affd250) > > RET linux_sys_futex 1 .... > RET linux_clock_gettime 0 > > CALL linux_sys_futex(0x80e0acc,0x80,0x1,0x2affd21c,0x1,0x2affd280) it looks like it's looping waiting for some condition to happen, dont you have a simpler example that exhibits this behaviour than those (big) apps you mentioned? > and another over sched_yield (although I am uncertain as I have not > examined the entire dump). > > Let me know if you want anything from the trace. the futex call that causes error 110 :) From rdivacky at freebsd.org Sun Jul 13 06:25:42 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Sun Jul 13 06:25:48 2008 Subject: linux emulation: Preliminary support for more auxvec's [patch] In-Reply-To: <20080711201450.GB17123@deviant.kiev.zoral.com.ua> References: <20080711115436.GZ17123@deviant.kiev.zoral.com.ua> <4877BAB8.1030804@system.pl> <20080711201450.GB17123@deviant.kiev.zoral.com.ua> Message-ID: <20080713062433.GB67395@freebsd.org> > > This was made against 7-STABLE, but there no major differences in > > -current. It is also trivial to port to 64-bit amd64 emulation. > Hmm, what are you referencing there ? I know only about one mostly > stalled effort. dmitry still has not got his p4 account :( or at least he's not able to access it. I cant comment more... maybe dmitry can tell us about the progress he's made? roman From christof.schulze at gmx.net Sun Jul 13 22:02:11 2008 From: christof.schulze at gmx.net (Christof Schulze) Date: Sun Jul 13 22:02:18 2008 Subject: qemu + bridging + setup script Message-ID: <200807132335.27883.christof.schulze@gmx.net> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080713/7497124f/attachment.pgp From christof.schulze at gmx.net Mon Jul 14 00:49:12 2008 From: christof.schulze at gmx.net (Christof Schulze) Date: Mon Jul 14 00:49:19 2008 Subject: qemu + bridging + setup script In-Reply-To: <200807132335.27883.christof.schulze@gmx.net> References: <200807132335.27883.christof.schulze@gmx.net> Message-ID: <200807140249.08113.christof.schulze@gmx.net> Hello, Sorry for double posting, it seems that the mailing list software did not like my gpg signature and that the attachment did not get to the list because of that. So here it is again. Regards. Christof On Sunday 13 July 2008 23:35:21 Christof Schulze wrote: > Hello, > > this is my first post to this list. > Recently I have written a script to automatically set up bridgin with > qemu. So the script uses the tap devices passed to qemu to set up the > tap device. > I attached the script because I would like to contribute it to FreeBSD. > It works well enough for me but maybe some testing is still needed. > > I would be glad to read your feedback on this. > > Christof From christof.schulze at gmx.net Mon Jul 14 01:07:49 2008 From: christof.schulze at gmx.net (Christof Schulze) Date: Mon Jul 14 01:07:56 2008 Subject: qemu + bridging + setup script In-Reply-To: <200807140249.08113.christof.schulze@gmx.net> References: <200807132335.27883.christof.schulze@gmx.net> <200807140249.08113.christof.schulze@gmx.net> Message-ID: <200807140307.45720.christof.schulze@gmx.net> > [Mailinglist troubles] Since I do not want to put the script directly into an email and the mailinglist will not let me attach it, I put it into a pastebin: http://pastebin.com/f775380e1 I would be glad to receive your feedback. Christof From Alexander at Leidinger.net Mon Jul 14 08:44:12 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Mon Jul 14 08:44:19 2008 Subject: linux emulation: Preliminary support for more auxvec's [patch] In-Reply-To: <4877BAB8.1030804@system.pl> References: <20080711115436.GZ17123@deviant.kiev.zoral.com.ua> <4877BAB8.1030804@system.pl> Message-ID: <20080714104352.14951o38351fjnpc@webmail.leidinger.net> Quoting Marcin Cieslak (from Fri, 11 Jul 2008 21:55:36 +0200): > The patch is here: > > http://akson.sgh.waw.pl/~saper/FreeBSD/linux/auxvec.diff I'm a little bit worried about this: ---snip--- --- sys/i386/include/elf.h 4 Oct 2006 21:37:09 -0000 1.17 +++ sys/i386/include/elf.h 11 Jul 2008 11:20:03 -0000 @@ -104,8 +104,12 @@ #define AT_EUID 12 /* Effective uid. */ #define AT_GID 13 /* Real gid. */ #define AT_EGID 14 /* Effective gid. */ +#define AT_PLATFORM 15 /* CPU identification string. */ +#define AT_HWCAP 16 /* CPU capabilities (arch dependent). */ +#define AT_CLKTCK 17 /* Frequency at which times() increments */ +#define AT_SECURE 23 /* Secure mode */ -#define AT_COUNT 15 /* Count of defined aux entry types. */ +#define AT_COUNT 18 /* Count of defined aux entry types. */ ---snip--- I would expect that count is 24, not 18. But what happens if we increase it to 24, is it expected to have some valid data by some automatism based upon AT_COUNT then? What's in 18-22? Bye, Alexander. -- Only kings, presidents, editors, and people with tapeworms have the right to use the editorial "we". http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From saper at system.pl Mon Jul 14 10:23:34 2008 From: saper at system.pl (Marcin Cieslak) Date: Mon Jul 14 10:23:41 2008 Subject: linux emulation: Preliminary support for more auxvec's [patch] In-Reply-To: <20080714104352.14951o38351fjnpc@webmail.leidinger.net> References: <20080711115436.GZ17123@deviant.kiev.zoral.com.ua> <4877BAB8.1030804@system.pl> <20080714104352.14951o38351fjnpc@webmail.leidinger.net> Message-ID: <487B2914.9020409@system.pl> Alexander Leidinger wrote: > Quoting Marcin Cieslak (from Fri, 11 Jul 2008 21:55:36 > +0200): > >> The patch is here: >> >> http://akson.sgh.waw.pl/~saper/FreeBSD/linux/auxvec.diff > > > -#define AT_COUNT 15 /* Count of defined aux entry types. */ > +#define AT_COUNT 18 /* Count of defined aux entry types. */ > ---snip--- > > I would expect that count is 24, not 18. But what happens if we increase > it to 24, is it expected to have some valid data by some automatism > based upon AT_COUNT then? What's in 18-22? Well, the count is the count - it's number of slots in the table. It is used for the allocation of the structure space. As Kostik Belousov pointed, rtld uses this (incorrectly) in libexec/rtld-elf/rtld.c in _rtld() an array of AT_COUNT elements is created and only items with values (0..AT_COUNT) are included in the table. This should be probably be changed to something in similar to lib/libc/gen/tls.c (see _init_tls() at the very end). Solaris sys/auxv.h comments explain the 18-22 shift (Linux collided with PPC ABI values): http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/auxv.h You can also here that Solaris defines quite large AT_* values, so an approach taken by rtld is not practical in the long term. I think in the long term (upstream, not in the linuxolator) we should allow ELF stack fixup routine to dynamically allocate user stack and get rid of AT_COUNT completely. I guess this could be done by extending (struct sysentvec *) and changing the code around 457 of kern_exec.c to separate "copy out strings" and "separate stack base" functions. This work-in-progress patch (http://people.freebsd.org/~kib/misc/rtld-origin.1.patch) also requires some allocation on the user stack. --Marcin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 273 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080714/8c5c9abe/signature.pgp From bugmaster at FreeBSD.org Mon Jul 14 11:06:57 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 14 11:07:30 2008 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org Message-ID: <200807141106.m6EB6uLp014380@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/21463 emulation [linux] Linux compatability mode should not allow setu o kern/97326 emulation [linux] file descriptor leakage in linux emulation o kern/117010 emulation [linux] linux_getdents() get something like buffer ove 3 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 o kern/29698 emulation [linux] [patch] linux ipcs doesn'work o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/41543 emulation [patch] [request] easier wine/w23 support a kern/72920 emulation [linux]: path "prefixing" is not done on unix domain s o kern/73777 emulation [linux] [patch] linux emulation: root dir special hand o kern/91293 emulation [svr4] [patch] *Experimental* Update to the SVR4 emula o ports/91318 emulation [fix] graphics/linux_dri: works on amd64 too o ports/121800 emulation x11-toolkits/linux-openmotif - OpenMotif upgrade to 2. o kern/122318 emulation [linux] [cmake]: Segmentation fault when running Linux o ports/123960 emulation Port fix: archivers/linux-par2cmdline - better handlin o ports/123964 emulation Mk fix: bsd.linux-rpm.mk - Handling of NOPORTDOCS 12 problems total. From eculp at encontacto.net Mon Jul 14 12:15:55 2008 From: eculp at encontacto.net (eculp) Date: Mon Jul 14 12:16:02 2008 Subject: qemu + bridging + setup script In-Reply-To: <200807140249.08113.christof.schulze@gmx.net> References: <200807132335.27883.christof.schulze@gmx.net> <200807140249.08113.christof.schulze@gmx.net> Message-ID: <20080714071526.235574g9qopomfc4@intranet.encontacto.net> Quoting Christof Schulze : > Hello, > > Sorry for double posting, it seems that the mailing list software did not > like my gpg signature and that the attachment did not get to the list > because of that. > > So here it is again. Hi Christof. Maybe it is only I, but I still don't see your script. ed > > Regards. > > Christof > > On Sunday 13 July 2008 23:35:21 Christof Schulze wrote: >> Hello, >> >> this is my first post to this list. >> Recently I have written a script to automatically set up bridgin with >> qemu. So the script uses the tap devices passed to qemu to set up the >> tap device. >> I attached the script because I would like to contribute it to FreeBSD. >> It works well enough for me but maybe some testing is still needed. >> >> I would be glad to read your feedback on this. >> >> Christof > > > From sfourman at gmail.com Mon Jul 14 16:02:15 2008 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Mon Jul 14 16:02:21 2008 Subject: qemu + bridging + setup script In-Reply-To: <20080714071526.235574g9qopomfc4@intranet.encontacto.net> References: <200807132335.27883.christof.schulze@gmx.net> <200807140249.08113.christof.schulze@gmx.net> <20080714071526.235574g9qopomfc4@intranet.encontacto.net> Message-ID: <11167f520807140835i7abebc76l4ca1721135f24d7c@mail.gmail.com> > Hi Christof. > > Maybe it is only I, but I still don't see your script. > > ed here it is http://pastebin.com/f775380e1 Sam Fourman Jr. Fourman Networks From chagin.dmitry at gmail.com Tue Jul 15 18:04:54 2008 From: chagin.dmitry at gmail.com (Dmitry Chagin) Date: Tue Jul 15 18:05:01 2008 Subject: linux emulation: Preliminary support for more auxvec's [patch] In-Reply-To: <20080713062433.GB67395@freebsd.org> References: <20080711115436.GZ17123@deviant.kiev.zoral.com.ua> <4877BAB8.1030804@system.pl> <20080711201450.GB17123@deviant.kiev.zoral.com.ua> <20080713062433.GB67395@freebsd.org> Message-ID: <3cd3dd6a0807151037l5c14080am2fc13736b5b8239a@mail.gmail.com> 2008/7/13 Roman Divacky : > > > This was made against 7-STABLE, but there no major differences in > > > -current. It is also trivial to port to 64-bit amd64 emulation. > > Hmm, what are you referencing there ? I know only about one mostly > > stalled effort. > > dmitry still has not got his p4 account :( or at least he's not able > to access it. I cant comment more... maybe dmitry can tell us > about the progress he's made? > > Yesterday I have received the password to an account:) I shall setup p4 client now. about progress: All in the same place, I repair sendmsg/recvmsg, thnx! chd, Have fun! From kpeter at melbpc.org.au Wed Jul 16 07:36:07 2008 From: kpeter at melbpc.org.au (Peter Kostouros) Date: Wed Jul 16 07:36:14 2008 Subject: Linux 2.6 emulation and Linux Java problem In-Reply-To: <20080713061943.GA67395@freebsd.org> References: <4870260D.1080203@melbpc.org.au> <20080706094332.4de443b0@deskjail> <4871E04B.305@melbpc.org.au> <20080707111515.GA41171@freebsd.org> <4877F898.9080905@melbpc.org.au> <20080713061943.GA67395@freebsd.org> Message-ID: <487DA4E2.6080303@melbpc.org.au> Roman Divacky wrote: >> ktrace.out is about 500MB. >> >> Anyways, one java process looks to be looping: >> >> RET linux_sys_futex -1 errno 110 Unknown error: 110 >> > > what is the call of the futex that causes this error to happen? that might > be the culprit > > >> CALL linux_sys_futex(0x8092528,0x81,0x1,0xfffffffd,0x8092528,0x2affd250) >> >> RET linux_sys_futex 1 >> > > .... > > >> RET linux_clock_gettime 0 >> >> CALL linux_sys_futex(0x80e0acc,0x80,0x1,0x2affd21c,0x1,0x2affd280) >> > > it looks like it's looping waiting for some condition to happen, dont > you have a simpler example that exhibits this behaviour than those > (big) apps you mentioned? > > I will see what I can do. >> and another over sched_yield (although I am uncertain as I have not >> examined the entire dump). >> >> Let me know if you want anything from the trace. >> > > the futex call that causes error 110 :) > > 1615 java CALL gettimeofday(0x2841f118,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841f128,0) 1615 java RET gettimeofday 0 1615 java CALL linux_mmap2(0,0x80000,0x7,0x22,0xffffffff,0) 1615 java RET linux_mmap2 720887808/0x2af7e000 1615 java CALL linux_mprotect(0x2af7e000,0x1000,0) 1615 java RET linux_mprotect 0 1615 java CALL linux_clone(0x3d0f00,0x2affd4b4,0x2affdbd8,0x2841f13c,0x2affdbd8) 1622 java RET linux_fork 0 1622 java CALL linux_set_robust_list(0x2affdbe0,0xc) 1622 java RET linux_set_robust_list 0 1622 java CALL linux_sched_getaffinity(0x656,0x20,0x809cb80) 1622 java RET linux_sched_getaffinity 4 1622 java CALL linux_sched_getaffinity(0x656,0x20,0x809cb80) 1622 java RET linux_sched_getaffinity 4 1622 java CALL linux_gettid 1622 java RET linux_gettid 1622/0x656 1622 java CALL linux_rt_sigprocmask(0,0,0x2affd2f0,0x8) 1622 java RET linux_rt_sigprocmask 0 1622 java CALL linux_rt_sigprocmask(0x1,0x6448480,0,0x8) 1622 java RET linux_rt_sigprocmask 0 1622 java CALL linux_rt_sigprocmask(0,0x6448500,0,0x8) 1622 java RET linux_rt_sigprocmask 0 1622 java CALL linux_sys_futex(0x80814dc,0x85,0x1,0x1,0x80814d8,0x4000001) 1622 java RET linux_sys_futex 2 1622 java CALL linux_sys_futex(0x809cbac,0x80,0x1,0,0x1,0x2affd2a8) 1615 java RET linux_sys_futex 0 1615 java CALL linux_sys_futex(0x8059e28,0x81,0x1,0x8059e00,0x8059e28,0x2841f080) 1615 java RET linux_sys_futex 1 1615 java CALL linux_sys_futex(0x809cbac,0x85,0x1,0x1,0x809cba8,0x4000001) 1615 java RET linux_sys_futex 2 1622 java RET linux_sys_futex 0 1622 java CALL linux_sys_futex(0x8092728,0x80,0x2,0,0,0x2affd270) 1615 java CALL linux_sys_futex(0x8092728,0x81,0x1,0x8092700,0x8092728,0x2841f130) 1615 java RET linux_sys_futex 2 1622 java RET linux_sys_futex 0 1622 java CALL linux_sys_futex(0x8092728,0x81,0x1,0x8092700,0x8092728,0x2affd2a0) 1622 java RET linux_sys_futex 1 1622 java CALL linux_sched_getaffinity(0x656,0x20,0x809cb80) 1622 java RET linux_sched_getaffinity 4 1622 java CALL linux_sched_getaffinity(0x656,0x20,0x809cb80) 1622 java RET linux_sched_getaffinity 4 1622 java CALL linux_sched_getaffinity(0x656,0x20,0x809cb80) 1622 java RET linux_sched_getaffinity 4 1622 java CALL linux_sched_getaffinity(0x656,0x20,0x809cb80) 1622 java RET linux_sched_getaffinity 4 1622 java CALL linux_clock_gettime(0x1,0x2affd290) 1622 java RET linux_clock_gettime 0 1622 java CALL linux_clock_gettime(0x1,0x2affd290) 1622 java RET linux_clock_gettime 0 1622 java CALL gettimeofday(0x2affd240,0) 1622 java RET gettimeofday 0 1622 java CALL linux_clock_gettime(0,0x2affd21c) 1622 java RET linux_clock_gettime 0 1622 java CALL linux_sys_futex(0x809cc84,0x80,0x1,0x2affd21c,0x1,0x2affd280) <<<< Here? 1615 java CALL gettimeofday(0x2841f1d8,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841f2b8,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e838,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e838,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e658,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e658,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e718,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e718,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841ea88,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841ea88,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841eb48,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841eb48,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e554,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e554,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e614,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e614,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e0ec,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e0ec,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e05c,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e05c,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e1ac,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e1ac,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841dfa0,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841dfa0,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e060,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841d8e0,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841d8e0,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e060,0) 1615 java RET gettimeofday 0 1615 java CALL linux_stat64(0x80532d0,0x2841e200,0x281f1ff4) 1615 java NAMI "/compat/linux/usr/local/linux-sun-jdk1.6.0_10/jre/lib/ext/sunjce_provider.jar" 1615 java NAMI "/usr/local/linux-sun-jdk1.6.0_10/jre/lib/ext/sunjce_provider.jar" 1615 java UNKNOWN(8) 1615 java RET linux_stat64 0 1615 java CALL linux_stat64(0x8054100,0x2841e200,0x281f1ff4) 1615 java NAMI "/compat/linux/usr/local/linux-sun-jdk1.6.0_10/jre/lib/ext/sunpkcs11.jar" 1615 java NAMI "/usr/local/linux-sun-jdk1.6.0_10/jre/lib/ext/sunpkcs11.jar" 1615 java UNKNOWN(8) 1615 java RET linux_stat64 0 1615 java CALL linux_stat64(0x8054100,0x2841e200,0x281f1ff4) 1615 java NAMI "/compat/linux/usr/local/linux-sun-jdk1.6.0_10/jre/lib/ext/dnsns.jar" 1615 java NAMI "/usr/local/linux-sun-jdk1.6.0_10/jre/lib/ext/dnsns.jar" 1615 java UNKNOWN(8) 1615 java RET linux_stat64 0 1615 java CALL linux_stat64(0x8054100,0x2841e200,0x281f1ff4) 1615 java NAMI "/compat/linux/usr/local/linux-sun-jdk1.6.0_10/jre/lib/ext/localedata.jar" 1615 java NAMI "/usr/local/linux-sun-jdk1.6.0_10/jre/lib/ext/localedata.jar" 1615 java UNKNOWN(8) 1615 java RET linux_stat64 0 1615 java CALL gettimeofday(0x2841e698,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e698,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e758,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e758,0) 1615 java RET gettimeofday 0 1622 java RET linux_sys_futex -1 errno 110 Unknown error: 110 1622 java CALL linux_sys_futex(0x8092528,0x81,0x1,0xfffffffd,0x8092528,0x2affd250) 1622 java RET linux_sys_futex 1 1622 java CALL linux_clock_gettime(0x1,0x2affd290) 1622 java RET linux_clock_gettime 0 1622 java CALL gettimeofday(0x2affd2a8,0) 1622 java RET gettimeofday 0 1622 java CALL linux_clock_gettime(0x1,0x2affd290) 1622 java RET linux_clock_gettime 0 1622 java CALL linux_clock_gettime(0x1,0x2affd290) 1622 java RET linux_clock_gettime 0 1622 java CALL gettimeofday(0x2affd240,0) 1622 java RET gettimeofday 0 1622 java CALL linux_clock_gettime(0,0x2affd21c) 1622 java RET linux_clock_gettime 0 1622 java CALL linux_sys_futex(0x809cc84,0x80,0x1,0x2affd21c,0x1,0x2affd280) 1620 java CALL gettimeofday(0x2ad7d038,0) 1620 java RET gettimeofday 0 1620 java CALL gettimeofday(0x2ad7d188,0) 1620 java RET gettimeofday 0 1620 java CALL gettimeofday(0x2ad7d188,0) 1620 java RET gettimeofday 0 1620 java CALL gettimeofday(0x2ad7d048,0) 1620 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e0e8,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e0e8,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e1a8,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e1a8,0) 1615 java RET gettimeofday 0 1620 java CALL gettimeofday(0x2ad7d038,0) 1620 java RET gettimeofday 0 1620 java CALL linux_sys_futex(0x808e0c4,0x80,0x5,0,0x5,0x2ad7d098) 1615 java CALL gettimeofday(0x2841dc1c,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841dc1c,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841dcdc,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841dcdc,0) 1615 java RET gettimeofday 0 1615 java CALL linux_stat64(0x80532d0,0x2841dd40,0x281f1ff4) 1615 java NAMI "/compat/linux/mnt/cvs2/Desktop/netbeans/netbeans-6.1/platform8/lib/boot.jar" 1615 java NAMI "/mnt/cvs2/Desktop/netbeans/netbeans-6.1/platform8/lib/boot.jar" 1615 java UNKNOWN(8) 1615 java RET linux_stat64 0 1622 java RET linux_sys_futex -1 errno 110 Unknown error: 110 1622 java CALL linux_sys_futex(0x8092528,0x81,0x1,0xfffffffd,0x8092528,0x2affd250) 1622 java RET linux_sys_futex 1 1622 java CALL linux_clock_gettime(0x1,0x2affd290) 1622 java RET linux_clock_gettime 0 1622 java CALL gettimeofday(0x2affd2a8,0) 1622 java RET gettimeofday 0 1622 java CALL linux_clock_gettime(0x1,0x2affd290) 1622 java RET linux_clock_gettime 0 1622 java CALL linux_clock_gettime(0x1,0x2affd290) 1622 java RET linux_clock_gettime 0 1622 java CALL gettimeofday(0x2affd240,0) 1622 java RET gettimeofday 0 1622 java CALL linux_clock_gettime(0,0x2affd21c) 1622 java RET linux_clock_gettime 0 1622 java CALL linux_sys_futex(0x809cc84,0x80,0x1,0x2affd21c,0x1,0x2affd280) 1615 java CALL gettimeofday(0x2841dc1c,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841dc1c,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841db8c,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841db8c,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841dcdc,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841d83c,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841d83c,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841dcdc,0) 1615 java RET gettimeofday 0 1615 java CALL linux_stat64(0x80532d0,0x2841dd00,0x281f1ff4) 1615 java NAMI "/compat/linux/mnt/cvs2/Desktop/netbeans/netbeans-6.1/platform8/lib/boot.jar" 1615 java NAMI "/mnt/cvs2/Desktop/netbeans/netbeans-6.1/platform8/lib/boot.jar" 1615 java UNKNOWN(8) 1615 java RET linux_stat64 0 1615 java CALL linux_open(0x80532d0,0x8000,0) 1615 java NAMI "/compat/linux/mnt/cvs2/Desktop/netbeans/netbeans-6.1/platform8/lib/boot.jar" 1615 java NAMI "/mnt/cvs2/Desktop/netbeans/netbeans-6.1/platform8/lib/boot.jar" 1615 java RET linux_open 3 1615 java CALL linux_fstat64(0x3,0x2841dcc0,0x281f1ff4) 1615 java UNKNOWN(8) 1615 java RET linux_fstat64 0 1615 java CALL linux_fcntl64(0x3,0x1,0) 1615 java RET linux_fcntl64 0 1615 java CALL linux_fcntl64(0x3,0x2,0x1) 1615 java RET linux_fcntl64 0 1615 java CALL linux_llseek(0x3,0,0,0x2841dc90,0x2) 1615 java RET linux_llseek 0 1615 java CALL linux_llseek(0x3,0,0x3c3a3,0x2841dac0,0) 1615 java RET linux_llseek 0 1615 java CALL read(0x3,0x2841dbe0,0x80) 1615 java GIO fd 3 read 128 bytes "ageAccessibleClassLoader.classPK\^A\^B \0 \0\0\0\0\0\M-0\M^^\M^U8\^A\M-?h\^V\M-:1\0\0\M-:1\0\0\^W\0\0\0\0\0\0\0\0\0\0\0\0\0\M-?~\^C\0org/netbeans/Util.classPK\^E\^F\0\0\0\ \0=\0=\0X\^S\0\0\M-.\M-0\^C\0\a\0PACK200" 1615 java RET read 128/0x80 1615 java CALL linux_mmap2(0,0x141c,0x1,0x1,0x3,0x3b) 1615 java RET linux_mmap2 675479552/0x28430000 1615 java CALL gettimeofday(0x2841da4c,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841da4c,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841db0c,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841db0c,0) 1615 java RET gettimeofday 0 1622 java RET linux_sys_futex -1 errno 110 Unknown error: 110 1622 java CALL linux_sys_futex(0x8092528,0x81,0x1,0xfffffffd,0x8092528,0x2affd250) 1622 java RET linux_sys_futex 1 1622 java CALL linux_clock_gettime(0x1,0x2affd290) 1622 java RET linux_clock_gettime 0 1622 java CALL gettimeofday(0x2affd2a8,0) 1622 java RET gettimeofday 0 1622 java CALL linux_clock_gettime(0x1,0x2affd290) 1622 java RET linux_clock_gettime 0 1622 java CALL linux_clock_gettime(0x1,0x2affd290) 1622 java RET linux_clock_gettime 0 1622 java CALL gettimeofday(0x2affd240,0) 1622 java RET gettimeofday 0 1622 java CALL linux_clock_gettime(0,0x2affd21c) 1622 java RET linux_clock_gettime 0 1622 java CALL linux_sys_futex(0x809cc84,0x80,0x1,0x2affd21c,0x1,0x2affd280) 1615 java CALL gettimeofday(0x2841e364,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e364,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e424,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e424,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e460,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e460,0) 1615 java RET gettimeofday 0 1615 java CALL gettimeofday(0x2841e520,0) 1615 java RET gettimeofday 0 From itetcu at FreeBSD.org Thu Jul 17 22:24:00 2008 From: itetcu at FreeBSD.org (Ion-Mihai Tetcu) Date: Thu Jul 17 22:24:06 2008 Subject: ports/123964: Mk fix: bsd.linux-rpm.mk - Handling of NOPORTDOCS In-Reply-To: <200805242050.m4OKoANj032302@freefall.freebsd.org> References: <200805242050.m4OKoANj032302@freefall.freebsd.org> Message-ID: <20080718012352.66ad7829@it.buh.tecnik93.com> Is there anything wrong with this patch or can I commit it? Do you want me to do a tindy run over the ports that set AUTOMATIC_PLIST with NOPORTDOCS defined? Or anything else I can do to help get this in the tree? Thanks, -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080717/adcb0cb1/signature.pgp From itetcu at FreeBSD.org Thu Jul 17 22:24:48 2008 From: itetcu at FreeBSD.org (Ion-Mihai Tetcu) Date: Thu Jul 17 22:24:54 2008 Subject: archivers/linux-par2cmdline - fails: FAIL In-Reply-To: <20080717114042.M73703@martymac.com> References: <20080710023555.0E12612E434A@quark.ds9.tecnik93.com> <20080710065039.M30672@martymac.com> <20080710161135.161d4632@it.buh.tecnik93.com> <20080717114042.M73703@martymac.com> Message-ID: <20080718012436.3f895d44@it.buh.tecnik93.com> On Thu, 17 Jul 2008 13:40:42 +0200 (CEST) "Ganael LAPLANCHE" wrote: > On Thu, 10 Jul 2008 16:11:35 +0300, Ion-Mihai Tetcu wrote > > Hi, > > >> Please bug me in a week if a fix is not committed. Thanks, > > > > Ok, it is now on my TODO list ! > > As you asked me, here is a reminder :) Nothing has been committed > yet ; can you take a look at ports/123964 ? Ping'ed the "maintainer" about it, let see what happens ... -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080717/0a852cdf/signature.pgp From Alexander at Leidinger.net Fri Jul 18 06:23:55 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Fri Jul 18 06:24:02 2008 Subject: ports/123964: Mk fix: bsd.linux-rpm.mk - Handling of NOPORTDOCS In-Reply-To: <20080718012352.66ad7829@it.buh.tecnik93.com> References: <200805242050.m4OKoANj032302@freefall.freebsd.org> <20080718012352.66ad7829@it.buh.tecnik93.com> Message-ID: <20080718082335.59641it1ufxgg64k@webmail.leidinger.net> Quoting Ion-Mihai Tetcu (from Fri, 18 Jul 2008 01:23:52 +0300): > Is there anything wrong with this patch or can I commit it? Personally I don't like the "x" as a variable name, and I would use a shell loop instead of a make loop, but at this moment this is more cosmetics than a requirement. The real problem here is lack of time. Boris just returned from vacations and is catching up with whatever piled up, and I am still busy with more important things. > Do you want me to do a tindy run over the ports that set > AUTOMATIC_PLIST with NOPORTDOCS defined? Or anything else I can do to > help get this in the tree? That would be great. Bye, Alexander. -- Everyone was born right-handed. Only the greatest overcome it. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From chagin.dmitry at gmail.com Fri Jul 18 12:42:26 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Fri Jul 18 12:42:32 2008 Subject: linux emulation: Preliminary support for more auxvec's [patch] In-Reply-To: <20080711201450.GB17123@deviant.kiev.zoral.com.ua> References: <20080711115436.GZ17123@deviant.kiev.zoral.com.ua> <4877BAB8.1030804@system.pl> <20080711201450.GB17123@deviant.kiev.zoral.com.ua> Message-ID: On Fri, 11 Jul 2008, Kostik Belousov wrote: > On Fri, Jul 11, 2008 at 09:55:36PM +0200, Marcin Cieslak wrote: >> Kostik Belousov wrote: >>> On Fri, Jul 11, 2008 at 01:43:55PM +0200, Marcin Cieslak wrote: >>>> Hello, >>>> >> >> This was made against 7-STABLE, but there no major differences in >> -current. It is also trivial to port to 64-bit amd64 emulation. > Hmm, what are you referencing there ? I know only about one mostly > stalled effort. > I have created branch linuxolator64 on perforce.freebsd.org, welcome :) Now I work above corrections in sendmsg/recvmsg, the rest like works. thnx! -- Have fun! chd From bugmaster at FreeBSD.org Mon Jul 21 11:06:54 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 21 11:07:23 2008 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org Message-ID: <200807211106.m6LB6rqT031834@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/21463 emulation [linux] Linux compatability mode should not allow setu o kern/97326 emulation [linux] file descriptor leakage in linux emulation o kern/117010 emulation [linux] linux_getdents() get something like buffer ove 3 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 o kern/29698 emulation [linux] [patch] linux ipcs doesn'work o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/41543 emulation [patch] [request] easier wine/w23 support a kern/72920 emulation [linux]: path "prefixing" is not done on unix domain s o kern/73777 emulation [linux] [patch] linux emulation: root dir special hand o kern/91293 emulation [svr4] [patch] *Experimental* Update to the SVR4 emula o ports/91318 emulation [fix] graphics/linux_dri: works on amd64 too o ports/121800 emulation x11-toolkits/linux-openmotif - OpenMotif upgrade to 2. o kern/122318 emulation [linux] [cmake]: Segmentation fault when running Linux o ports/123960 emulation Port fix: archivers/linux-par2cmdline - better handlin o ports/123964 emulation Mk fix: bsd.linux-rpm.mk - Handling of NOPORTDOCS 12 problems total. From shild at sbcglobal.net Tue Jul 22 20:29:09 2008 From: shild at sbcglobal.net (Scott T. Hildreth) Date: Tue Jul 22 20:29:16 2008 Subject: Wine - sound not working Message-ID: <1216756899.46452.165.camel@fbsd1.dyndns.org> I am running the latest wine (wine-1.1.0,1) and FreeBSD 7.0 Stable. I have installed firefox with wine-doors and works great except there is now sound for videos. I have the same setup on my desktop at work, and sound works with firefox. I thought sound should just work on 7.0, but I am missing something. Any ideas? Thanks, STH From scf at FreeBSD.org Wed Jul 23 18:01:54 2008 From: scf at FreeBSD.org (Sean C. Farley) Date: Wed Jul 23 18:02:00 2008 Subject: kern/122318 (CMake core dumping, chroot exiting) Message-ID: I am seeing if anyone has any insight on this PR (kern/122318[1]). It would be nice to once again build using cmake within a Linux chroot. :) Basically, the bug is that not only that cmake is dumping core; it is also forcing the user out of the chroot environment. Here is the command used to start the chroot: /compat/linux/usr/sbin/chroot su - Thank you. Sean 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122318 -- scf@FreeBSD.org From rdivacky at FreeBSD.org Wed Jul 23 18:08:36 2008 From: rdivacky at FreeBSD.org (Roman Divacky) Date: Wed Jul 23 18:08:51 2008 Subject: kern/122318 (CMake core dumping, chroot exiting) In-Reply-To: References: Message-ID: <20080723180704.GA22714@freebsd.org> On Wed, Jul 23, 2008 at 12:50:51PM -0500, Sean C. Farley wrote: > I am seeing if anyone has any insight on this PR (kern/122318[1]). It > would be nice to once again build using cmake within a Linux chroot. :) > > Basically, the bug is that not only that cmake is dumping core; it is > also forcing the user out of the chroot environment. Here is the > command used to start the chroot: > /compat/linux/usr/sbin/chroot su - > > Thank you. > > Sean > 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122318 is cmake threaded? From scf at FreeBSD.org Wed Jul 23 18:45:16 2008 From: scf at FreeBSD.org (Sean C. Farley) Date: Wed Jul 23 18:45:26 2008 Subject: kern/122318 (CMake core dumping, chroot exiting) In-Reply-To: <20080723180704.GA22714@freebsd.org> References: <20080723180704.GA22714@freebsd.org> Message-ID: On Wed, 23 Jul 2008, Roman Divacky wrote: > On Wed, Jul 23, 2008 at 12:50:51PM -0500, Sean C. Farley wrote: >> I am seeing if anyone has any insight on this PR (kern/122318[1]). >> It would be nice to once again build using cmake within a Linux >> chroot. :) >> >> Basically, the bug is that not only that cmake is dumping core; it is >> also forcing the user out of the chroot environment. Here is the >> command used to start the chroot: >> /compat/linux/usr/sbin/chroot su - > > is cmake threaded? No. ldd output from a cmake on a different system and architecture (amd64): libdl.so.2 => /lib64/libdl.so.2 (0x00000039e1e00000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003332800000) libm.so.6 => /lib64/libm.so.6 (0x00000038a1e00000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000039e3a00000) libc.so.6 => /lib64/libc.so.6 (0x00000039e1600000) /lib64/ld-linux-x86-64.so.2 (0x00000039e1200000) Oddly enough, I cannot get anything from this binary within the chroot, outside of the chroot or even on a Linux system: not a dynamic executable strace does show it loading dynamic libraries: open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib/libdl.so.2", O_RDONLY) = 3 open("/usr/lib/libstdc++.so.5", O_RDONLY) = 3 open("/lib/libm.so.6", O_RDONLY) = 3 open("/lib/libgcc_s.so.1", O_RDONLY) = 3 open("/lib/libc.so.6", O_RDONLY) = 3 Heh. I tried to rebuild the RPM within the chroot, but it also cores during the build. Sean -- scf@FreeBSD.org From rdivacky at FreeBSD.org Wed Jul 23 18:46:03 2008 From: rdivacky at FreeBSD.org (Roman Divacky) Date: Wed Jul 23 18:46:09 2008 Subject: kern/122318 (CMake core dumping, chroot exiting) In-Reply-To: References: Message-ID: <20080723184450.GA25356@freebsd.org> On Wed, Jul 23, 2008 at 12:50:51PM -0500, Sean C. Farley wrote: > I am seeing if anyone has any insight on this PR (kern/122318[1]). It > would be nice to once again build using cmake within a Linux chroot. :) > > Basically, the bug is that not only that cmake is dumping core; it is > also forcing the user out of the chroot environment. Here is the > command used to start the chroot: > /compat/linux/usr/sbin/chroot su - > > Thank you. > > Sean > 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122318 looking at the trace you provided I guess this is what's going on: cmake forks/execs gcc and waits to be notified about the success of the command it tried, the notification comes (the SIGCHLD) the handler tries do something and then returns and now something is wrong and it receives the SIGSEGV.. or am I wrong and linux_ktrace does not translate signals and the SIGCHLD is in fact SIGTSTP? what is the fd 3 and 4? can you provide full ktrace.out? thnx, roman From scf at FreeBSD.org Wed Jul 23 20:01:27 2008 From: scf at FreeBSD.org (Sean C. Farley) Date: Wed Jul 23 20:01:39 2008 Subject: kern/122318 (CMake core dumping, chroot exiting) In-Reply-To: <20080723184450.GA25356@freebsd.org> References: <20080723184450.GA25356@freebsd.org> Message-ID: On Wed, 23 Jul 2008, Roman Divacky wrote: > On Wed, Jul 23, 2008 at 12:50:51PM -0500, Sean C. Farley wrote: >> I am seeing if anyone has any insight on this PR (kern/122318[1]). >> It would be nice to once again build using cmake within a Linux >> chroot. :) >> >> Basically, the bug is that not only that cmake is dumping core; it is >> also forcing the user out of the chroot environment. Here is the >> command used to start the chroot: >> /compat/linux/usr/sbin/chroot su - >> >> 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122318 > > looking at the trace you provided I guess this is what's going on: > > cmake forks/execs gcc and waits to be notified about the success of > the command it tried, the notification comes (the SIGCHLD) the handler > tries do something and then returns and now something is wrong and it > receives the SIGSEGV.. > > or am I wrong and linux_ktrace does not translate signals and the > SIGCHLD is in fact SIGTSTP? > > what is the fd 3 and 4? can you provide full ktrace.out? I have the full output of the execution here using ktrace -d: http://www.farley.org/freebsd/tmp/cmake-kdump.txt Sean -- scf@FreeBSD.org From chagin.dmitry at gmail.com Wed Jul 23 20:22:42 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Wed Jul 23 20:22:48 2008 Subject: kern/122318 (CMake core dumping, chroot exiting) In-Reply-To: References: <20080723184450.GA25356@freebsd.org> Message-ID: On Wed, 23 Jul 2008, Sean C. Farley wrote: > On Wed, 23 Jul 2008, Roman Divacky wrote: > >> On Wed, Jul 23, 2008 at 12:50:51PM -0500, Sean C. Farley wrote: >>> I am seeing if anyone has any insight on this PR (kern/122318[1]). >>> It would be nice to once again build using cmake within a Linux >>> chroot. :) >>> >>> Basically, the bug is that not only that cmake is dumping core; it is >>> also forcing the user out of the chroot environment. Here is the >>> command used to start the chroot: >>> /compat/linux/usr/sbin/chroot su - >>> >>> 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122318 >> >> looking at the trace you provided I guess this is what's going on: >> >> cmake forks/execs gcc and waits to be notified about the success of >> the command it tried, the notification comes (the SIGCHLD) the handler >> tries do something and then returns and now something is wrong and it >> receives the SIGSEGV.. >> >> or am I wrong and linux_ktrace does not translate signals and the >> SIGCHLD is in fact SIGTSTP? >> >> what is the fd 3 and 4? can you provide full ktrace.out? > > I have the full output of the execution here using ktrace -d: > http://www.farley.org/freebsd/tmp/cmake-kdump.txt > > Sean > hi! Please, can you run ktrace with -i flag? thnx! -- Have fun! chd From scf at FreeBSD.org Wed Jul 23 21:19:18 2008 From: scf at FreeBSD.org (Sean C. Farley) Date: Wed Jul 23 21:19:25 2008 Subject: kern/122318 (CMake core dumping, chroot exiting) In-Reply-To: References: <20080723184450.GA25356@freebsd.org> Message-ID: On Thu, 24 Jul 2008, Chagin Dmitry wrote: > On Wed, 23 Jul 2008, Sean C. Farley wrote: >> On Wed, 23 Jul 2008, Roman Divacky wrote: >>> On Wed, Jul 23, 2008 at 12:50:51PM -0500, Sean C. Farley wrote: >>>> I am seeing if anyone has any insight on this PR (kern/122318[1]). >>>> It would be nice to once again build using cmake within a Linux >>>> chroot. :) >>>> >>>> Basically, the bug is that not only that cmake is dumping core; it >>>> is also forcing the user out of the chroot environment. Here is >>>> the command used to start the chroot: >>>> /compat/linux/usr/sbin/chroot su - >>>> >>>> 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122318 >>> >>> looking at the trace you provided I guess this is what's going on: >>> >>> cmake forks/execs gcc and waits to be notified about the success of >>> the command it tried, the notification comes (the SIGCHLD) the >>> handler tries do something and then returns and now something is >>> wrong and it receives the SIGSEGV.. >>> >>> or am I wrong and linux_ktrace does not translate signals and the >>> SIGCHLD is in fact SIGTSTP? >>> >>> what is the fd 3 and 4? can you provide full ktrace.out? >> >> I have the full output of the execution here using ktrace -d: >> http://www.farley.org/freebsd/tmp/cmake-kdump.txt > > hi! > > Please, can you run ktrace with -i flag? > > thnx! No problem. Same URL. The countless meetings this week are destroying my mind; I was thinking -d did what -i actually does. :) Sean -- scf@FreeBSD.org From chagin.dmitry at gmail.com Thu Jul 24 06:31:52 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Thu Jul 24 06:31:59 2008 Subject: linuxulator64 status Message-ID: hi! I'm not subscribed on fbsd-current@, therefore I shall answer here... It is possible to tell that it works, now I investigate LTP results and search that does not work. ps. signals, dynamic loading of libs works. 100% know that there are problems with getdents syscall, at least at x86_64. If somebody is interesting, I shall prepare a patch and necessary packages (linux_base, linux_dev, linux_kdump for x86_64). thnx! -- Have fun! chd From Alexander at Leidinger.net Thu Jul 24 07:47:33 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Thu Jul 24 07:47:40 2008 Subject: linuxulator64 status In-Reply-To: References: Message-ID: <20080724094716.14505b96mmgg574s@webmail.leidinger.net> Quoting "Chagin Dmitry" (from Thu, 24 Jul 2008 10:30:41 +0400 (MSD)): > > hi! > I'm not subscribed on fbsd-current@, therefore I shall answer here... > > It is possible to tell that it works, now I investigate LTP results > and search that does not work. Congrats! You know about http://wiki.freebsd.org/linux-kernel/ and linux-kernel/ltp? If yes, do you want write access? Do you think you are at a stage where you can provide a patch for users to test (I don't have a 64bit system, so it's not for me)? > ps. signals, dynamic loading of libs works. > 100% know that there are problems with getdents syscall, at least at x86_64. I think the problem is not only there... > If somebody is interesting, I shall prepare a patch and necessary > packages (linux_base, linux_dev, linux_kdump for x86_64). For the ports stuff please coordinate with bsam@, he already has patches for all other supported architectures. Bye, Alexander. -- A key to the understanding of all religions is that a God's idea of a good time is a game of Snakes and Ladders with greased rungs. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From chagin.dmitry at gmail.com Thu Jul 24 08:38:57 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Thu Jul 24 08:39:10 2008 Subject: linuxulator64 status In-Reply-To: <20080724094716.14505b96mmgg574s@webmail.leidinger.net> References: <20080724094716.14505b96mmgg574s@webmail.leidinger.net> Message-ID: On Thu, 24 Jul 2008, Alexander Leidinger wrote: > Quoting "Chagin Dmitry" (from Thu, 24 Jul 2008 > 10:30:41 +0400 (MSD)): > >> >> hi! >> I'm not subscribed on fbsd-current@, therefore I shall answer here... >> >> It is possible to tell that it works, now I investigate LTP results and >> search that does not work. > > Congrats! You know about http://wiki.freebsd.org/linux-kernel/ and > linux-kernel/ltp? If yes, do you want write access? Yes, I know. If it is possible, I could store results of tests there > > Do you think you are at a stage where you can provide a patch for users to > test (I don't have a 64bit system, so it's not for me)? > just for developers. >> ps. signals, dynamic loading of libs works. >> 100% know that there are problems with getdents syscall, at least at >> x86_64. > > I think the problem is not only there... > Certainly, I write only about those that I know. >> If somebody is interesting, I shall prepare a patch and necessary packages >> (linux_base, linux_dev, linux_kdump for x86_64). > > For the ports stuff please coordinate with bsam@, he already has patches for > all other supported architectures. > ok. thnx! -- Have fun! chd From rdivacky at freebsd.org Thu Jul 24 08:48:20 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Thu Jul 24 08:48:27 2008 Subject: linuxulator64 status In-Reply-To: References: Message-ID: <20080724084705.GA92703@freebsd.org> On Thu, Jul 24, 2008 at 10:30:41AM +0400, Chagin Dmitry wrote: > > hi! > I'm not subscribed on fbsd-current@, therefore I shall answer here... > > It is possible to tell that it works, now I investigate LTP results and > search that does not work. > > ps. signals, dynamic loading of libs works. > 100% know that there are problems with getdents syscall, at least at > x86_64. I recall you telling me about glibc using getdents as readdir or something like that.. have you progressed on this front? I am more than willing to join you in trying to see whats going on if this is the main obstacle on getting linuxulator64 commited... I hope we can prepare a set of patches to commit to -current so it gets integrated. I propose to make another branch devoted to integrating your work to -current roman From chagin.dmitry at gmail.com Thu Jul 24 09:08:02 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Thu Jul 24 09:08:09 2008 Subject: linuxulator64 status In-Reply-To: <20080724084705.GA92703@freebsd.org> References: <20080724084705.GA92703@freebsd.org> Message-ID: On Thu, 24 Jul 2008, Roman Divacky wrote: > On Thu, Jul 24, 2008 at 10:30:41AM +0400, Chagin Dmitry wrote: >> >> hi! >> I'm not subscribed on fbsd-current@, therefore I shall answer here... >> >> It is possible to tell that it works, now I investigate LTP results and >> search that does not work. >> >> ps. signals, dynamic loading of libs works. >> 100% know that there are problems with getdents syscall, at least at >> x86_64. > > I recall you telling me about glibc using getdents as readdir or something > like that.. have you progressed on this front? > Yesterday I tried to compile glibc-2.7 in x86_64 emulation, look that happens: *** glibc detected *** gmake: double free or corruption (!prev): 0x0000000000693 d20 *** ======= Backtrace: ========= /lib64/libc.so.6[0x8008b4832] /lib64/libc.so.6(cfree+0x8c)[0x8008b7f2c] gmake[0x41d463] gmake[0x4045d9] gmake[0x404e3f] gmake[0x4082b7] Below a piece of ktrace dump: 29143 make CALL linux_open(0x7fffffffc9d0,O_NONBLOCK|O_DIRECTORY|O_CLOEXEC ,0x62fd70) 29143 make NAMI "string" 29143 make RET linux_open 5 29143 make CALL linux_newfstat(0x5,0x7fffffffc7d0) 29143 make STRU struct stat {dev=98, ino=3203960, mode=drwxrwxr-x , nlink= 3, uid=500, gid=500, rdev=12856072, atime=1216839073, stime=1192706475, ctime=12 16833980, birthtime=1192706475, size=3072, blksize=4096, blocks=8, flags=0x0 } 29143 make RET linux_newfstat 0 29143 make CALL linux_fcntl(0x5,F_SETFD,FD_CLOEXEC) 29143 make RET linux_fcntl 0 29143 make CALL linux_getdents(0x5,0x692e78,0x1000) !29143 make RET linux_getdents 4096/0x1000 29143 make CALL linux_open(0x80096312c,O_RDWR|O_NOCTTY|O_NONBLOCK,0x12) 29143 make NAMI "/compat/linux/dev/tty" 29143 make NAMI "/dev/tty" 29143 make RET linux_open 6 29143 make CALL writev(0x6,0x7fffffffbf60,0x7) 29143 make GIO fd 6 wrote 109 bytes "*** glibc detected *** /compat/linux/usr/bin/make: double free or corr\ uption (!prev): 0x0000000000693e80 *** getdents must be called at least twice, the last getdents call must return 0. You can try this on i386 :) > I am more than willing to join you in trying to see whats going on if this > is the main obstacle on getting linuxulator64 commited... > > I hope we can prepare a set of patches to commit to -current so it gets > integrated. I propose to make another branch devoted to integrating your > work to -current > -- Have fun! chd From matheus at eternamente.info Thu Jul 24 15:58:13 2008 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Thu Jul 24 15:58:19 2008 Subject: linuxulator64 status In-Reply-To: References: <20080724094716.14505b96mmgg574s@webmail.leidinger.net> Message-ID: <7ba32dd4cab3b0423dd90f71436e7546.squirrel@cygnus.homeunix.com> On Thu, July 24, 2008 05:37, Chagin Dmitry wrote: > On Thu, 24 Jul 2008, Alexander Leidinger wrote: > >> Quoting "Chagin Dmitry" (from Thu, 24 Jul 2008 >> 10:30:41 +0400 (MSD)): >> >>> >>> hi! >>> I'm not subscribed on fbsd-current@, therefore I shall answer here... >>> >>> It is possible to tell that it works, now I investigate LTP results and >>> search that does not work. >> >> Congrats! You know about http://wiki.freebsd.org/linux-kernel/ and >> linux-kernel/ltp? If yes, do you want write access? > > Yes, I know. If it is possible, I could store results of tests there > >> >> Do you think you are at a stage where you can provide a patch for users >> to >> test (I don't have a 64bit system, so it's not for me)? >> > > just for developers. as I'm not a FreeBSD developer. well, this may not be for me and I may be bothering some of you guys, but if all these patches and ports stuff is able or quite to run F@H I may test it. well, if so, mail me (list or not), if not, I wont bother you guys again :) thanks, matheus -- We will call you cygnus, The God of balance you shall be From chagin.dmitry at gmail.com Thu Jul 24 20:02:09 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Thu Jul 24 20:02:23 2008 Subject: linuxulator64 status In-Reply-To: <7ba32dd4cab3b0423dd90f71436e7546.squirrel@cygnus.homeunix.com> References: <20080724094716.14505b96mmgg574s@webmail.leidinger.net> <7ba32dd4cab3b0423dd90f71436e7546.squirrel@cygnus.homeunix.com> Message-ID: On Thu, 24 Jul 2008, Nenhum_de_Nos wrote: > > On Thu, July 24, 2008 05:37, Chagin Dmitry wrote: >> On Thu, 24 Jul 2008, Alexander Leidinger wrote: >> >>> Quoting "Chagin Dmitry" (from Thu, 24 Jul 2008 >>> 10:30:41 +0400 (MSD)): >>> >>>> >>>> hi! >>>> I'm not subscribed on fbsd-current@, therefore I shall answer here... >>>> >>>> It is possible to tell that it works, now I investigate LTP results and >>>> search that does not work. >>> >>> Congrats! You know about http://wiki.freebsd.org/linux-kernel/ and >>> linux-kernel/ltp? If yes, do you want write access? >> >> Yes, I know. If it is possible, I could store results of tests there >> >>> >>> Do you think you are at a stage where you can provide a patch for users >>> to >>> test (I don't have a 64bit system, so it's not for me)? >>> >> >> just for developers. > > as I'm not a FreeBSD developer. > > well, this may not be for me and I may be bothering some of you guys, but > if all these patches and ports stuff is able or quite to run F@H I may > test it. > > well, if so, mail me (list or not), if not, I wont bother you guys again :) > I speak about skills of programming, not about fbsd-hackers :) thnx! -- Have fun! chd From matheus at eternamente.info Thu Jul 24 20:05:10 2008 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Thu Jul 24 20:05:16 2008 Subject: linuxulator64 status In-Reply-To: References: <20080724094716.14505b96mmgg574s@webmail.leidinger.net> <7ba32dd4cab3b0423dd90f71436e7546.squirrel@cygnus.homeunix.com> Message-ID: <42c25619640bff177deb9aaf54f12c4b.squirrel@cygnus.homeunix.com> On Thu, July 24, 2008 17:01, Chagin Dmitry wrote: > On Thu, 24 Jul 2008, Nenhum_de_Nos wrote: > >> >> On Thu, July 24, 2008 05:37, Chagin Dmitry wrote: >>> On Thu, 24 Jul 2008, Alexander Leidinger wrote: >>> >>>> Quoting "Chagin Dmitry" (from Thu, 24 Jul >>>> 2008 >>>> 10:30:41 +0400 (MSD)): >>>> >>>>> >>>>> hi! >>>>> I'm not subscribed on fbsd-current@, therefore I shall answer here... >>>>> >>>>> It is possible to tell that it works, now I investigate LTP results >>>>> and >>>>> search that does not work. >>>> >>>> Congrats! You know about http://wiki.freebsd.org/linux-kernel/ and >>>> linux-kernel/ltp? If yes, do you want write access? >>> >>> Yes, I know. If it is possible, I could store results of tests there >>> >>>> >>>> Do you think you are at a stage where you can provide a patch for >>>> users >>>> to >>>> test (I don't have a 64bit system, so it's not for me)? >>>> >>> >>> just for developers. >> >> as I'm not a FreeBSD developer. >> >> well, this may not be for me and I may be bothering some of you guys, >> but >> if all these patches and ports stuff is able or quite to run F@H I may >> test it. >> >> well, if so, mail me (list or not), if not, I wont bother you guys again >> :) >> > > I speak about skills of programming, not about fbsd-hackers :) > > thnx! > > -- > Have fun! > chd hehe ok, but I'm not a skilled programmer also :( even though I plan to someday :) matheus -- We will call you cygnus, The God of balance you shall be From chagin.dmitry at gmail.com Fri Jul 25 07:00:16 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Fri Jul 25 07:00:22 2008 Subject: kern/117010: [linux] linux_getdents() get somethinng like buffer overflow Message-ID: <200807250700.m6P70FSF036132@freefall.freebsd.org> The following reply was made to PR kern/117010; it has been noted by GNATS. From: Chagin Dmitry To: bug-followup@freebsd.org, samflanker@gmail.com Cc: Subject: Re: kern/117010: [linux] linux_getdents() get somethinng like buffer overflow Date: Fri, 25 Jul 2008 10:22:46 +0400 (MSD) Please, try a patch below: diff --git a/src/sys/compat/linux/linux_file.c b/src/sys/compat/linux/linux_file index 303bc3f..d88f95f 100644 --- a/src/sys/compat/linux/linux_file.c +++ b/src/sys/compat/linux/linux_file.c @@ -303,8 +303,8 @@ struct l_dirent64 { char d_name[LINUX_NAME_MAX + 1]; }; -#define LINUX_RECLEN(de,namlen) \ - ALIGN((((char *)&(de)->d_name - (char *)de) + (namlen) + 1)) +#define LINUX_RECLEN(de,namlen,trail) \ + ALIGN((((char *)&(de)->d_name - (char *)de) + (namlen) + trail)) #define LINUX_DIRBLKSIZ 512 @@ -436,8 +436,8 @@ again: } linuxreclen = (is64bit) - ? LINUX_RECLEN(&linux_dirent64, bdp->d_namlen) - : LINUX_RECLEN(&linux_dirent, bdp->d_namlen); + ? LINUX_RECLEN(&linux_dirent64, bdp->d_namlen, 1) + : LINUX_RECLEN(&linux_dirent, bdp->d_namlen, 2); if (reclen > len || resid < linuxreclen) { outp++; it solves getdents() problem (at least at x86_64 emulation with linux_base-f8) ps, be not bared, linux really has such features... thnx! -- Have fun! chd From rdivacky at FreeBSD.org Fri Jul 25 08:23:15 2008 From: rdivacky at FreeBSD.org (Roman Divacky) Date: Fri Jul 25 08:23:29 2008 Subject: kern/122318 (CMake core dumping, chroot exiting) In-Reply-To: References: <20080723184450.GA25356@freebsd.org> Message-ID: <20080725082156.GA41887@freebsd.org> On Wed, Jul 23, 2008 at 04:19:16PM -0500, Sean C. Farley wrote: > On Thu, 24 Jul 2008, Chagin Dmitry wrote: > > >On Wed, 23 Jul 2008, Sean C. Farley wrote: > >>On Wed, 23 Jul 2008, Roman Divacky wrote: > >>>On Wed, Jul 23, 2008 at 12:50:51PM -0500, Sean C. Farley wrote: > >>>>I am seeing if anyone has any insight on this PR (kern/122318[1]). > >>>>It would be nice to once again build using cmake within a Linux > >>>>chroot. :) > >>>> > >>>>Basically, the bug is that not only that cmake is dumping core; it > >>>>is also forcing the user out of the chroot environment. Here is > >>>>the command used to start the chroot: > >>>>/compat/linux/usr/sbin/chroot su - > >>>> > >>>> 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122318 > >>> > >>>looking at the trace you provided I guess this is what's going on: > >>> > >>>cmake forks/execs gcc and waits to be notified about the success of > >>>the command it tried, the notification comes (the SIGCHLD) the > >>>handler tries do something and then returns and now something is > >>>wrong and it receives the SIGSEGV.. > >>> > >>>or am I wrong and linux_ktrace does not translate signals and the > >>>SIGCHLD is in fact SIGTSTP? > >>> > >>>what is the fd 3 and 4? can you provide full ktrace.out? > >> > >>I have the full output of the execution here using ktrace -d: > >>http://www.farley.org/freebsd/tmp/cmake-kdump.txt > > > >hi! > > > >Please, can you run ktrace with -i flag? > > > >thnx! > > No problem. Same URL. The countless meetings this week are destroying > my mind; I was thinking -d did what -i actually does. :) the cmake opens: 18279 ld CALL linux_open(0x7fffffffe5b4,0,0x1b6) 18279 ld NAMI "/usr/lib/crtend.o" 18279 ld RET linux_open 3 which is obviously wrong and probably causes the regression.. how is this possible I dont know. anyway, the trace is all strange... 1) it uses getpmsg/putpmsg which are unimplemented (hows that it work? does it work or just pretends to?) 2) what is this? 18267 gmake CALL [417](0x7fffffffcf90) 18267 gmake RET [417] JUSTRETURN 18267 gmake CALL linux_waitpid(0xffffffff,0x7fffffffd3f4,0,0) 18267 gmake RET linux_waitpid 18277/0x4765 18267 gmake CALL [340](0x1,0x529d90,0) 18267 gmake RET [340] 0 18267 gmake CALL [340](0x3,0x7fffffffd3c0,0) 18267 gmake RET [340] 0 anyway, try to investigate why the cmake does not open crtend.o under /compat but uses fbsd one, that should fix the proble I believe thnx! roman From rdivacky at FreeBSD.org Fri Jul 25 08:32:37 2008 From: rdivacky at FreeBSD.org (Roman Divacky) Date: Fri Jul 25 08:32:43 2008 Subject: kern/122318 (CMake core dumping, chroot exiting) In-Reply-To: <20080725082156.GA41887@freebsd.org> References: <20080723184450.GA25356@freebsd.org> <20080725082156.GA41887@freebsd.org> Message-ID: <20080725083122.GA42835@freebsd.org> On Fri, Jul 25, 2008 at 10:21:56AM +0200, Roman Divacky wrote: > On Wed, Jul 23, 2008 at 04:19:16PM -0500, Sean C. Farley wrote: > > On Thu, 24 Jul 2008, Chagin Dmitry wrote: > > > > >On Wed, 23 Jul 2008, Sean C. Farley wrote: > > >>On Wed, 23 Jul 2008, Roman Divacky wrote: > > >>>On Wed, Jul 23, 2008 at 12:50:51PM -0500, Sean C. Farley wrote: > > >>>>I am seeing if anyone has any insight on this PR (kern/122318[1]). > > >>>>It would be nice to once again build using cmake within a Linux > > >>>>chroot. :) > > >>>> > > >>>>Basically, the bug is that not only that cmake is dumping core; it > > >>>>is also forcing the user out of the chroot environment. Here is > > >>>>the command used to start the chroot: > > >>>>/compat/linux/usr/sbin/chroot su - > > >>>> > > >>>> 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122318 > > >>> > > >>>looking at the trace you provided I guess this is what's going on: > > >>> > > >>>cmake forks/execs gcc and waits to be notified about the success of > > >>>the command it tried, the notification comes (the SIGCHLD) the > > >>>handler tries do something and then returns and now something is > > >>>wrong and it receives the SIGSEGV.. > > >>> > > >>>or am I wrong and linux_ktrace does not translate signals and the > > >>>SIGCHLD is in fact SIGTSTP? > > >>> > > >>>what is the fd 3 and 4? can you provide full ktrace.out? > > >> > > >>I have the full output of the execution here using ktrace -d: > > >>http://www.farley.org/freebsd/tmp/cmake-kdump.txt > > > > > >hi! > > > > > >Please, can you run ktrace with -i flag? > > > > > >thnx! > > > > No problem. Same URL. The countless meetings this week are destroying > > my mind; I was thinking -d did what -i actually does. :) > > the cmake opens: > > 18279 ld CALL linux_open(0x7fffffffe5b4,0,0x1b6) > 18279 ld NAMI "/usr/lib/crtend.o" > 18279 ld RET linux_open 3 > > which is obviously wrong and probably causes the regression.. how is this possible I dont > know. > > anyway, the trace is all strange... > > 1) it uses getpmsg/putpmsg which are unimplemented (hows that it work? does it > work or just pretends to?) > > 2) what is this? > > 18267 gmake CALL [417](0x7fffffffcf90) > 18267 gmake RET [417] JUSTRETURN > 18267 gmake CALL linux_waitpid(0xffffffff,0x7fffffffd3f4,0,0) > 18267 gmake RET linux_waitpid 18277/0x4765 > 18267 gmake CALL [340](0x1,0x529d90,0) > 18267 gmake RET [340] 0 > 18267 gmake CALL [340](0x3,0x7fffffffd3c0,0) > 18267 gmake RET [340] 0 > > > anyway, try to investigate why the cmake does not open crtend.o under /compat but uses > fbsd one, that should fix the proble I believe erm... all wrong :) the gmake is a fbsd binary so its ok to open that file... From chagin.dmitry at gmail.com Fri Jul 25 08:36:11 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Fri Jul 25 08:36:18 2008 Subject: kern/122318 (CMake core dumping, chroot exiting) In-Reply-To: <20080725083122.GA42835@freebsd.org> References: <20080723184450.GA25356@freebsd.org> <20080725082156.GA41887@freebsd.org> <20080725083122.GA42835@freebsd.org> Message-ID: On Fri, 25 Jul 2008, Roman Divacky wrote: > On Fri, Jul 25, 2008 at 10:21:56AM +0200, Roman Divacky wrote: >> On Wed, Jul 23, 2008 at 04:19:16PM -0500, Sean C. Farley wrote: >>> On Thu, 24 Jul 2008, Chagin Dmitry wrote: >>> >>>> On Wed, 23 Jul 2008, Sean C. Farley wrote: >>>>> On Wed, 23 Jul 2008, Roman Divacky wrote: >>>>>> On Wed, Jul 23, 2008 at 12:50:51PM -0500, Sean C. Farley wrote: >>>>>>> I am seeing if anyone has any insight on this PR (kern/122318[1]). >>>>>>> It would be nice to once again build using cmake within a Linux >>>>>>> chroot. :) >>>>>>> >>>>>>> Basically, the bug is that not only that cmake is dumping core; it >>>>>>> is also forcing the user out of the chroot environment. Here is >>>>>>> the command used to start the chroot: >>>>>>> /compat/linux/usr/sbin/chroot su - >>>>>>> >>>>>>> 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122318 >>>>>> >>>>>> looking at the trace you provided I guess this is what's going on: >>>>>> >>>>>> cmake forks/execs gcc and waits to be notified about the success of >>>>>> the command it tried, the notification comes (the SIGCHLD) the >>>>>> handler tries do something and then returns and now something is >>>>>> wrong and it receives the SIGSEGV.. >>>>>> >>>>>> or am I wrong and linux_ktrace does not translate signals and the >>>>>> SIGCHLD is in fact SIGTSTP? >>>>>> >>>>>> what is the fd 3 and 4? can you provide full ktrace.out? >>>>> >>>>> I have the full output of the execution here using ktrace -d: >>>>> http://www.farley.org/freebsd/tmp/cmake-kdump.txt >>>> >>>> hi! >>>> >>>> Please, can you run ktrace with -i flag? >>>> >>>> thnx! >>> >>> No problem. Same URL. The countless meetings this week are destroying >>> my mind; I was thinking -d did what -i actually does. :) >> >> the cmake opens: >> >> 18279 ld CALL linux_open(0x7fffffffe5b4,0,0x1b6) >> 18279 ld NAMI "/usr/lib/crtend.o" >> 18279 ld RET linux_open 3 >> >> which is obviously wrong and probably causes the regression.. how is this possible I dont >> know. >> >> anyway, the trace is all strange... >> >> 1) it uses getpmsg/putpmsg which are unimplemented (hows that it work? does it >> work or just pretends to?) >> >> 2) what is this? >> >> 18267 gmake CALL [417](0x7fffffffcf90) >> 18267 gmake RET [417] JUSTRETURN >> 18267 gmake CALL linux_waitpid(0xffffffff,0x7fffffffd3f4,0,0) >> 18267 gmake RET linux_waitpid 18277/0x4765 >> 18267 gmake CALL [340](0x1,0x529d90,0) >> 18267 gmake RET [340] 0 >> 18267 gmake CALL [340](0x3,0x7fffffffd3c0,0) >> 18267 gmake RET [340] 0 >> >> >> anyway, try to investigate why the cmake does not open crtend.o under /compat but uses >> fbsd one, that should fix the proble I believe > > erm... all wrong :) the gmake is a fbsd binary so its ok to open that file... > yes, but I remember it was a question about chroot... Sean, can you provide full command which you run? -- Have fun! chd From scf at FreeBSD.org Fri Jul 25 17:57:24 2008 From: scf at FreeBSD.org (Sean C. Farley) Date: Fri Jul 25 17:57:31 2008 Subject: kern/122318 (CMake core dumping, chroot exiting) In-Reply-To: References: <20080723184450.GA25356@freebsd.org> <20080725082156.GA41887@freebsd.org> <20080725083122.GA42835@freebsd.org> Message-ID: On Fri, 25 Jul 2008, Chagin Dmitry wrote: > On Fri, 25 Jul 2008, Roman Divacky wrote: >> On Fri, Jul 25, 2008 at 10:21:56AM +0200, Roman Divacky wrote: >>> On Wed, Jul 23, 2008 at 04:19:16PM -0500, Sean C. Farley wrote: >>>> On Thu, 24 Jul 2008, Chagin Dmitry wrote: >>>>> On Wed, 23 Jul 2008, Sean C. Farley wrote: >>>>>> On Wed, 23 Jul 2008, Roman Divacky wrote: >>>>>>> On Wed, Jul 23, 2008 at 12:50:51PM -0500, Sean C. Farley wrote: >>>>>>>> I am seeing if anyone has any insight on this PR >>>>>>>> (kern/122318[1]). It would be nice to once again build using >>>>>>>> cmake within a Linux chroot. :) >>>>>>>> >>>>>>>> Basically, the bug is that not only that cmake is dumping core; >>>>>>>> it is also forcing the user out of the chroot environment. >>>>>>>> Here is the command used to start the chroot: >>>>>>>> /compat/linux/usr/sbin/chroot su - >>>>>>>> >>>>>>>> 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122318 >>>>>>> >>>>>>> looking at the trace you provided I guess this is what's going on: >>>>>>> >>>>>>> cmake forks/execs gcc and waits to be notified about the success >>>>>>> of the command it tried, the notification comes (the SIGCHLD) >>>>>>> the handler tries do something and then returns and now >>>>>>> something is wrong and it receives the SIGSEGV.. >>>>>>> >>>>>>> or am I wrong and linux_ktrace does not translate signals and >>>>>>> the SIGCHLD is in fact SIGTSTP? >>>>>>> >>>>>>> what is the fd 3 and 4? can you provide full ktrace.out? >>>>>> >>>>>> I have the full output of the execution here using ktrace -d: >>>>>> http://www.farley.org/freebsd/tmp/cmake-kdump.txt >>>>> >>>>> hi! >>>>> >>>>> Please, can you run ktrace with -i flag? >>>>> >>>>> thnx! >>>> >>>> No problem. Same URL. The countless meetings this week are >>>> destroying my mind; I was thinking -d did what -i actually does. >>>> :) *snip of all that is wrong :)* >> erm... all wrong :) the gmake is a fbsd binary so its ok to open that >> file... > > yes, but I remember it was a question about chroot... I have the trouble in and out of the chroot (FC2-based) but also with linux_base-f{c4,c6,8}. I just ran it outside of the chroot to get the ktrace much more easily. This is on a FreeBSD 7 amd64 system running a 32-bit chroot. > Sean, can you provide full command which you run? Steps to recreate: mkdir a cd a touch CMakeLists.txt /home/sfarley/chroot/usr/bin/cmake . System setup for 7-STABLE as of July 14th: compat.ia32.maxvmem: 0 compat.ia32.maxssiz: 67108864 compat.ia32.maxdsiz: 536870912 compat.linux.oss_version: 198144 compat.linux.osrelease: 2.6.16 compat.linux.osname: Linux compat.linux32.maxvmem: 0 compat.linux32.maxssiz: 67108864 compat.linux32.maxdsiz: 536870912 BTW, switching to compat.linux.osrelease=2.4.2, running some Linux applications and switching back to 2.6.16 does not leave Linux emulation in a happy state. Simple Linux applications such as uname start core dumping. Sean -- scf@FreeBSD.org From chagin.dmitry at gmail.com Fri Jul 25 19:31:56 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Fri Jul 25 19:32:03 2008 Subject: kern/122318 (CMake core dumping, chroot exiting) In-Reply-To: References: <20080723184450.GA25356@freebsd.org> <20080725082156.GA41887@freebsd.org> <20080725083122.GA42835@freebsd.org> Message-ID: On Fri, 25 Jul 2008, Sean C. Farley wrote: > On Fri, 25 Jul 2008, Chagin Dmitry wrote: > >> >> yes, but I remember it was a question about chroot... > > I have the trouble in and out of the chroot (FC2-based) but also with > linux_base-f{c4,c6,8}. I just ran it outside of the chroot to get the > ktrace much more easily. This is on a FreeBSD 7 amd64 system running a > 32-bit chroot. > ugh... my head, sorry ((( >> Sean, can you provide full command which you run? > > Steps to recreate: > mkdir a > cd a > touch CMakeLists.txt > /home/sfarley/chroot/usr/bin/cmake . > > System setup for 7-STABLE as of July 14th: > compat.ia32.maxvmem: 0 > compat.ia32.maxssiz: 67108864 > compat.ia32.maxdsiz: 536870912 > compat.linux.oss_version: 198144 > compat.linux.osrelease: 2.6.16 > compat.linux.osname: Linux > compat.linux32.maxvmem: 0 > compat.linux32.maxssiz: 67108864 > compat.linux32.maxdsiz: 536870912 > > BTW, switching to compat.linux.osrelease=2.4.2, running some Linux > applications and switching back to 2.6.16 does not leave Linux emulation > in a happy state. Simple Linux applications such as uname start core > dumping. > uname must work on all supported linuxulators I can't reproduce problem, my output on linuxulator64: ora# chroot /compat/linux /bin/bash bash-3.2# bash-3.2# whereis cmake cmake: /usr/bin/cmake /usr/share/cmake /usr/share/man/man1/cmake.1.gz bash-3.2# bash-3.2# cd /opt bash-3.2# mkdir a bash-3.2# cd a bash-3.2# touch CMakeLists.txt bash-3.2# /usr/bin/cmake . -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Configuring done -- Generating done -- Build files have been written to: /opt/a bash-3.2# at me only one idea - create shell script like this: #!/bin/sh sleep 30 /usr/bin/cmake . run it, ps -ax | grep you_script_name ktrace -di -p you_script_pid -f /ttt/tracefile.out and show result. thnx! -- Have fun! chd From scf at FreeBSD.org Fri Jul 25 20:36:56 2008 From: scf at FreeBSD.org (Sean C. Farley) Date: Fri Jul 25 20:37:02 2008 Subject: kern/122318 (CMake core dumping, chroot exiting) In-Reply-To: References: <20080723184450.GA25356@freebsd.org> <20080725082156.GA41887@freebsd.org> <20080725083122.GA42835@freebsd.org> Message-ID: On Fri, 25 Jul 2008, Chagin Dmitry wrote: > On Fri, 25 Jul 2008, Sean C. Farley wrote: >> On Fri, 25 Jul 2008, Chagin Dmitry wrote: >>> >>> yes, but I remember it was a question about chroot... >> >> I have the trouble in and out of the chroot (FC2-based) but also with >> linux_base-f{c4,c6,8}. I just ran it outside of the chroot to get >> the ktrace much more easily. This is on a FreeBSD 7 amd64 system >> running a 32-bit chroot. >> > > ugh... my head, sorry ((( > >>> Sean, can you provide full command which you run? >> >> Steps to recreate: >> mkdir a >> cd a >> touch CMakeLists.txt >> /home/sfarley/chroot/usr/bin/cmake . >> >> System setup for 7-STABLE as of July 14th: >> compat.ia32.maxvmem: 0 >> compat.ia32.maxssiz: 67108864 >> compat.ia32.maxdsiz: 536870912 >> compat.linux.oss_version: 198144 >> compat.linux.osrelease: 2.6.16 >> compat.linux.osname: Linux >> compat.linux32.maxvmem: 0 >> compat.linux32.maxssiz: 67108864 >> compat.linux32.maxdsiz: 536870912 >> >> BTW, switching to compat.linux.osrelease=2.4.2, running some Linux >> applications and switching back to 2.6.16 does not leave Linux >> emulation in a happy state. Simple Linux applications such as uname >> start core dumping. >> > > uname must work on all supported linuxulators I agree, and it does work until I start playing with the Linux version. This problem may or may not be related to the cmake issue. > I can't reproduce problem, my output on linuxulator64: 8-CURRENT vs 7-STABLE issue maybe? > at me only one idea - create shell script like this: > > #!/bin/sh > sleep 30 > /usr/bin/cmake . > > run it, > ps -ax | grep you_script_name > ktrace -di -p you_script_pid -f /ttt/tracefile.out > > and show result. thnx! OK. I obtained a trace file[1]. Amusingly, bash also died in this scenario. Sean 1. http://www.farley.org/freebsd/tmp/ktrace.out.bz2 -- scf@FreeBSD.org From chagin.dmitry at gmail.com Fri Jul 25 20:46:47 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Fri Jul 25 20:46:53 2008 Subject: kern/122318 (CMake core dumping, chroot exiting) In-Reply-To: References: <20080723184450.GA25356@freebsd.org> <20080725082156.GA41887@freebsd.org> <20080725083122.GA42835@freebsd.org> Message-ID: On Fri, 25 Jul 2008, Sean C. Farley wrote: > On Fri, 25 Jul 2008, Chagin Dmitry wrote: > >> On Fri, 25 Jul 2008, Sean C. Farley wrote: >>> On Fri, 25 Jul 2008, Chagin Dmitry wrote: >>>> >>>> yes, but I remember it was a question about chroot... >>> >>> I have the trouble in and out of the chroot (FC2-based) but also with >>> linux_base-f{c4,c6,8}. I just ran it outside of the chroot to get >>> the ktrace much more easily. This is on a FreeBSD 7 amd64 system >>> running a 32-bit chroot. >>> >> >> ugh... my head, sorry ((( >> >>>> Sean, can you provide full command which you run? >>> >>> Steps to recreate: >>> mkdir a >>> cd a >>> touch CMakeLists.txt >>> /home/sfarley/chroot/usr/bin/cmake . >>> >>> System setup for 7-STABLE as of July 14th: >>> compat.ia32.maxvmem: 0 >>> compat.ia32.maxssiz: 67108864 >>> compat.ia32.maxdsiz: 536870912 >>> compat.linux.oss_version: 198144 >>> compat.linux.osrelease: 2.6.16 >>> compat.linux.osname: Linux >>> compat.linux32.maxvmem: 0 >>> compat.linux32.maxssiz: 67108864 >>> compat.linux32.maxdsiz: 536870912 >>> >>> BTW, switching to compat.linux.osrelease=2.4.2, running some Linux >>> applications and switching back to 2.6.16 does not leave Linux >>> emulation in a happy state. Simple Linux applications such as uname >>> start core dumping. >>> >> >> uname must work on all supported linuxulators > > I agree, and it does work until I start playing with the Linux version. > This problem may or may not be related to the cmake issue. > >> I can't reproduce problem, my output on linuxulator64: > > 8-CURRENT vs 7-STABLE issue maybe? > don't think so >> at me only one idea - create shell script like this: >> >> #!/bin/sh >> sleep 30 >> /usr/bin/cmake . >> >> run it, >> ps -ax | grep you_script_name >> ktrace -di -p you_script_pid -f /ttt/tracefile.out >> >> and show result. thnx! > > OK. I obtained a trace file[1]. Amusingly, bash also died in this > scenario. > > Sean > 1. http://www.farley.org/freebsd/tmp/ktrace.out.bz2 > I can't use it on -current, ktrace abi was changed. please, make itself linux_kdump :) -- Have fun! chd From scf at FreeBSD.org Fri Jul 25 20:57:15 2008 From: scf at FreeBSD.org (Sean C. Farley) Date: Fri Jul 25 20:57:21 2008 Subject: kern/122318 (CMake core dumping, chroot exiting) In-Reply-To: References: <20080723184450.GA25356@freebsd.org> <20080725082156.GA41887@freebsd.org> <20080725083122.GA42835@freebsd.org> Message-ID: On Sat, 26 Jul 2008, Chagin Dmitry wrote: > On Fri, 25 Jul 2008, Sean C. Farley wrote: >> On Fri, 25 Jul 2008, Chagin Dmitry wrote: >>> On Fri, 25 Jul 2008, Sean C. Farley wrote: >>>> On Fri, 25 Jul 2008, Chagin Dmitry wrote: >>>>> >>>>> yes, but I remember it was a question about chroot... >>>> >>>> I have the trouble in and out of the chroot (FC2-based) but also >>>> with linux_base-f{c4,c6,8}. I just ran it outside of the chroot to >>>> get the ktrace much more easily. This is on a FreeBSD 7 amd64 >>>> system running a 32-bit chroot. >>>> >>> >>> ugh... my head, sorry ((( >>> >>>>> Sean, can you provide full command which you run? >>>> >>>> Steps to recreate: >>>> mkdir a >>>> cd a >>>> touch CMakeLists.txt >>>> /home/sfarley/chroot/usr/bin/cmake . >>>> >>>> System setup for 7-STABLE as of July 14th: >>>> compat.ia32.maxvmem: 0 >>>> compat.ia32.maxssiz: 67108864 >>>> compat.ia32.maxdsiz: 536870912 >>>> compat.linux.oss_version: 198144 >>>> compat.linux.osrelease: 2.6.16 >>>> compat.linux.osname: Linux >>>> compat.linux32.maxvmem: 0 >>>> compat.linux32.maxssiz: 67108864 >>>> compat.linux32.maxdsiz: 536870912 >>>> >>>> BTW, switching to compat.linux.osrelease=2.4.2, running some Linux >>>> applications and switching back to 2.6.16 does not leave Linux >>>> emulation in a happy state. Simple Linux applications such as >>>> uname start core dumping. >>>> >>> >>> uname must work on all supported linuxulators >> >> I agree, and it does work until I start playing with the Linux >> version. This problem may or may not be related to the cmake issue. >> >>> I can't reproduce problem, my output on linuxulator64: >> >> 8-CURRENT vs 7-STABLE issue maybe? >> > > don't think so > >>> at me only one idea - create shell script like this: >>> >>> #!/bin/sh >>> sleep 30 >>> /usr/bin/cmake . >>> >>> run it, >>> ps -ax | grep you_script_name >>> ktrace -di -p you_script_pid -f /ttt/tracefile.out >>> >>> and show result. thnx! >> >> OK. I obtained a trace file[1]. Amusingly, bash also died in this >> scenario. >> >> Sean >> 1. http://www.farley.org/freebsd/tmp/ktrace.out.bz2 > > I can't use it on -current, ktrace abi was changed. please, make > itself linux_kdump :) Picky, picky! :) Here[2] you go. Sean 2. http://www.farley.org/freebsd/tmp/ktrace.txt -- scf@FreeBSD.org From conrads at cox.net Fri Jul 25 21:12:14 2008 From: conrads at cox.net (Conrad J. Sabatier) Date: Fri Jul 25 21:12:20 2008 Subject: linuxulator64 status In-Reply-To: References: Message-ID: <20080725155916.2f2206f5@serene.no-ip.org> On Thu, 24 Jul 2008 10:30:41 +0400 (MSD) Chagin Dmitry wrote: > > hi! > I'm not subscribed on fbsd-current@, therefore I shall answer here... > > It is possible to tell that it works, now I investigate LTP results and > search that does not work. > > ps. signals, dynamic loading of libs works. > 100% know that there are problems with getdents syscall, at least at > x86_64. > > If somebody is interesting, I shall prepare a patch and necessary > packages (linux_base, linux_dev, linux_kdump for x86_64). > > thnx! Definitely interested here. Running amd64. Thanks! -- PROOF OF GOD #424. ARGUMENT FROM SNOTTY BRITISH BIOLOGIST (1) Richard Dawkins ridicules religion in some of his books. (2) Therefore, God exists. From chagin.dmitry at gmail.com Sat Jul 26 10:17:35 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Sat Jul 26 10:17:41 2008 Subject: kern/122318 (CMake core dumping, chroot exiting) In-Reply-To: References: <20080723184450.GA25356@freebsd.org> <20080725082156.GA41887@freebsd.org> <20080725083122.GA42835@freebsd.org> Message-ID: On Fri, 25 Jul 2008, Sean C. Farley wrote: >>>>> >>>> >>>> uname must work on all supported linuxulators >>> >>> I agree, and it does work until I start playing with the Linux >>> version. This problem may or may not be related to the cmake issue. >>> >>>> I can't reproduce problem, my output on linuxulator64: >>> >>> 8-CURRENT vs 7-STABLE issue maybe? >>> >> >> don't think so >> >>>> at me only one idea - create shell script like this: >>>> >>>> #!/bin/sh >>>> sleep 30 >>>> /usr/bin/cmake . >>>> >>>> run it, >>>> ps -ax | grep you_script_name >>>> ktrace -di -p you_script_pid -f /ttt/tracefile.out >>>> >>>> and show result. thnx! >>> >>> OK. I obtained a trace file[1]. Amusingly, bash also died in this >>> scenario. >>> >>> Sean >>> 1. http://www.farley.org/freebsd/tmp/ktrace.out.bz2 >> >> I can't use it on -current, ktrace abi was changed. please, make >> itself linux_kdump :) > > Picky, picky! :) Here[2] you go. > > Sean > 2. http://www.farley.org/freebsd/tmp/ktrace.txt > With COMPAT_LINUX32 the mistake really exists... ora# chroot /compat/linux /bin/bash bash-3.2# bash-3.2# uname -a Linux ora.chd.net 2.6.16 FreeBSD 8.0-CURRENT #4: Sat Jul 26 01:35:52 MSD 2008 i686 i686 i386 GNU/Linux bash-3.2# bash-3.2# cd /opt bash-3.2# mkdir a bash-3.2# cd a bash-3.2# touch CMakeLists.txt bash-3.2# whereis cmake cmake: /usr/bin/cmake /usr/share/cmake /usr/share/man/man1/cmake.1.gz bash-3.2# /usr/bin/cmake . -- Check for working C compiler: /usr/bin/gcc Segmentation fault (core dumped) bash-3.2# let's look :) -- Have fun! chd From shild at sbcglobal.net Sat Jul 26 22:45:36 2008 From: shild at sbcglobal.net (Scott T. Hildreth) Date: Sat Jul 26 22:45:42 2008 Subject: Wine - sound not working In-Reply-To: <4886AE3D.5020202@telus.net> References: <1216768993.00101726.1216758602@10.7.7.3> <4886AE3D.5020202@telus.net> Message-ID: <1217110659.27402.32.camel@fbsd1.dyndns.org> On Tue, 2008-07-22 at 21:06 -0700, unhooked wrote: > Scott T. Hildreth wrote: > > I am running the latest wine (wine-1.1.0,1) and FreeBSD 7.0 Stable. > > I have installed firefox with wine-doors and works great except there > > is now sound for videos. I have the same setup on my desktop at work, > > and sound works with firefox. I thought sound should just work on 7.0, > > but I am missing something. Any ideas? > > > > Thanks, > > STH > > > > Works for me, if you have sound everywhere else - check your sound > settings in wine with winecfg. > > There's also a newer version of wine in the ports, but sound has always > worked for me in wine. Thanks, ran it, turned on a sound driver and sound is working. > From ady at freebsd.ady.ro Sun Jul 27 08:22:22 2008 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Sun Jul 27 08:22:34 2008 Subject: Q: Is there any use for Oracle database port installation under Linux compat root ? In-Reply-To: <78cb3d3f0807260841k336f20a9jce857189c55adb16@mail.gmail.com> References: <78cb3d3f0807260841k336f20a9jce857189c55adb16@mail.gmail.com> Message-ID: <78cb3d3f0807270122r4d2377d9gbf4e3ed5386918fa@mail.gmail.com> Hi, I am working on a FreeBSD port for Oracle's XE database package[1] (Linux binaries) and I stumbled upon some issues related to USE_LINUX_PREFIX. Before going any further trying to support (as an option) installing the Oracle XE directly under the /compat/linux hierarchy (like the database/linux-oracle-instantclient-* ports are doing), I have to ask ask around the following: (1) Is there any real need/benefit to have an Oracle DB installation rooted under /compat/linux (e.g. /compat/linux/usr/lib/oracle/xe/...) ? Side note: in this case all shell scripts will need to be ran under /compat/linux/bin/bash. (2) How does one deal with installing manual pages and shared files with USE_LINUX_PREFIX -- do they also have to go under /compat/linux ? Using ${MANPREFIX} as a template gives wrong results in this case... PS: The port will try to install by default under /usr/lib/oracle/xe, per Oracle's Linux packaging specs (all of the shell/SQL scripts use this hardcoded path). References: [1] http://www.oracle.com/technology/products/database/xe/index.html Thank you for your time, Adrian Penisoara ROFUG / EnterpriseBSD From Alexander at Leidinger.net Sun Jul 27 08:38:49 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sun Jul 27 08:38:57 2008 Subject: kern/117010: [linux] linux_getdents() get somethinng like buffer overflow In-Reply-To: <200807250700.m6P70FSF036132@freefall.freebsd.org> References: <200807250700.m6P70FSF036132@freefall.freebsd.org> Message-ID: <20080726091045.4c617dc7@deskjail> Quoting Chagin Dmitry (Fri, 25 Jul 2008 07:00:15 GMT): > The following reply was made to PR kern/117010; it has been noted by GNATS. > > From: Chagin Dmitry > To: bug-followup@freebsd.org, samflanker@gmail.com > Cc: > Subject: Re: kern/117010: [linux] linux_getdents() get somethinng like buffer > overflow > Date: Fri, 25 Jul 2008 10:22:46 +0400 (MSD) > > Please, try a patch below: > > diff --git a/src/sys/compat/linux/linux_file.c b/src/sys/compat/linux/linux_file > index 303bc3f..d88f95f 100644 > --- a/src/sys/compat/linux/linux_file.c > +++ b/src/sys/compat/linux/linux_file.c > @@ -303,8 +303,8 @@ struct l_dirent64 { > char d_name[LINUX_NAME_MAX + 1]; > }; > > -#define LINUX_RECLEN(de,namlen) \ > - ALIGN((((char *)&(de)->d_name - (char *)de) + (namlen) + 1)) > +#define LINUX_RECLEN(de,namlen,trail) \ > + ALIGN((((char *)&(de)->d_name - (char *)de) + (namlen) + trail)) The start of de->d_name minus the start of de should be the same as the offset of d_name in de, so I would expect that this is expressed with the offsetof maro instead of handmade. So the result of this is the offset plus a len + something. > #define LINUX_DIRBLKSIZ 512 > > @@ -436,8 +436,8 @@ again: > } I try to understand the code before this. There's "if (reclen & 3)" error out. Does it mean it has to be a multiple of 4? If yes it should be changed to some modulo calculation to make it obvious (the compiler should be able to do such micro optimisations, but I doubt the error case needs to be micro optimized). > linuxreclen = (is64bit) > - ? LINUX_RECLEN(&linux_dirent64, bdp->d_namlen) > - : LINUX_RECLEN(&linux_dirent, bdp->d_namlen); > + ? LINUX_RECLEN(&linux_dirent64, bdp->d_namlen, 1) > + : LINUX_RECLEN(&linux_dirent, bdp->d_namlen, 2); Translated: The length of the linux record is the offset plus the FreeBSD size plus something. Doesn't make sense to me. sizeof(linux_dirent) sound more suitable for this variable name. From the code it can not be the length of the linux record, but the size of a linux dirent struct which would be required to put all info inside (+ some more space... very suspicious). > if (reclen > len || resid < linuxreclen) { > outp++; First part: if the length of the current record is larger than the remaining free space (if it does not fit) go out of the loop... ok. Second part: if the length (in bytes?) is smaller than the theoretical size of the linux struct, go out of the loop. Ouch. Please tell me this is wrong (I didn't had breakfast yet, I really hope I misanalysed this because of this fact). I smell buffer mismanagement because of the strange 1 or 2 being added to the size, and I smell some convoluted logic there. Instead of trying to poke the thing until it works, I suggest to step back and have a look at the big picture if the entire part of the function can be improved. > it solves getdents() problem (at least at x86_64 emulation with > linux_base-f8) > > ps, be not bared, linux really has such features... What I would expect is to compare the strlen of the FreeBSD record with the size of the place in linux_dirent. If the FreeBSD record does not fit, fail (ENAMETOOLONG?). Compare the remaining space with the size of linux_dirent, if it is '<=' fill in the data into the fixed size struct. Bye, Alexander. -- The best way to inspire fresh thoughts is to seal the letter. 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 Sun Jul 27 08:39:39 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sun Jul 27 08:39:46 2008 Subject: kern/122318 (CMake core dumping, chroot exiting) In-Reply-To: References: <20080723184450.GA25356@freebsd.org> <20080725082156.GA41887@freebsd.org> <20080725083122.GA42835@freebsd.org> Message-ID: <20080726083110.5d932695@deskjail> Quoting "Sean C. Farley" (Fri, 25 Jul 2008 15:36:52 -0500 (CDT)): > On Fri, 25 Jul 2008, Chagin Dmitry wrote: > > uname must work on all supported linuxulators > > I agree, and it does work until I start playing with the Linux version. Don't play with the linux version while linux programs are running. Changing the version from 2.4.x to 2.6.x and vice versa while a program is running is not supported at all and known to cause havoc. Roman, do we have the possibility to make an easy check in the sysctl handler if a linux program is still running and return an error from the handler? Did I forgot something which makes it impossible to switch when a program was run under 2.6 and stopped? Sean, can you rule out the possibility that a program was still running under another version when you've seen the problems with uname? Bye, Alexander. -- BOFH excuse #37: heavy gravity fluctuation, move computer to floor rapidly http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From ady at freebsd.ady.ro Sun Jul 27 09:04:21 2008 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Sun Jul 27 09:04:34 2008 Subject: Q: Is there any use for Oracle database port installation under Linux compat root ? Message-ID: <78cb3d3f0807260841k336f20a9jce857189c55adb16@mail.gmail.com> Hi, I am working on a FreeBSD port for Oracle's XE database package[1] (Linux binaries) and I stumbled upon some issues related to USE_LINUX_PREFIX. Before going any further trying to support (as an option) installing the Oracle XE directly under the /compat/linux hierarchy (like the database/linux-oracle-instantclient-* ports are doing), I have to ask ask around the following: (1) Is there any real need/benefit to have an Oracle DB installation rooted under /compat/linux (e.g. /compat/linux/usr/lib/oracle/xe/...) ? Side note: in this case all shell scripts will need to be ran under /compat/linux/bin/bash. (2) How does one deal with installing manual pages and shared files with USE_LINUX_PREFIX -- do they also have to go under /compat/linux ? Using ${MANPREFIX} as a template gives wrong results in this case... PS: The port will try to install by default under /usr/lib/oracle/xe, per Oracle's Linux packaging specs (all of the shell/SQL scripts use this hardcoded path). References: [1] http://www.oracle.com/technology/products/database/xe/index.html Thank you for your time, Adrian Penisoara ROFUG / EnterpriseBSD From rdivacky at FreeBSD.org Sun Jul 27 09:04:26 2008 From: rdivacky at FreeBSD.org (Roman Divacky) Date: Sun Jul 27 09:04:35 2008 Subject: kern/122318 (CMake core dumping, chroot exiting) In-Reply-To: <20080726083110.5d932695@deskjail> References: <20080725082156.GA41887@freebsd.org> <20080725083122.GA42835@freebsd.org> <20080726083110.5d932695@deskjail> Message-ID: <20080727090309.GA63345@freebsd.org> On Sat, Jul 26, 2008 at 08:31:10AM +0200, Alexander Leidinger wrote: > Quoting "Sean C. Farley" (Fri, 25 Jul 2008 15:36:52 > -0500 (CDT)): > > > On Fri, 25 Jul 2008, Chagin Dmitry wrote: > > > > uname must work on all supported linuxulators > > > > I agree, and it does work until I start playing with the Linux version. > > Don't play with the linux version while linux programs are running. > Changing the version from 2.4.x to 2.6.x and vice versa while a program > is running is not supported at all and known to cause havoc. Roman, do > we have the possibility to make an easy check in the sysctl handler if > a linux program is still running and return an error from the handler? > Did I forgot something which makes it impossible to switch when a > program was run under 2.6 and stopped? I'll submit a patch that makes it impossible to switch the veresion when programs are running... it's not hard (elf{32}_brand_inuse() for every elf brand the linuxulator registered) From rdivacky at FreeBSD.org Sun Jul 27 09:22:12 2008 From: rdivacky at FreeBSD.org (Roman Divacky) Date: Sun Jul 27 09:22:19 2008 Subject: [PATCH]: Re: kern/122318 (CMake core dumping, chroot exiting) In-Reply-To: <20080727090309.GA63345@freebsd.org> References: <20080725082156.GA41887@freebsd.org> <20080725083122.GA42835@freebsd.org> <20080726083110.5d932695@deskjail> <20080727090309.GA63345@freebsd.org> Message-ID: <20080727092055.GA64264@freebsd.org> On Sun, Jul 27, 2008 at 11:03:10AM +0200, Roman Divacky wrote: > On Sat, Jul 26, 2008 at 08:31:10AM +0200, Alexander Leidinger wrote: > > Quoting "Sean C. Farley" (Fri, 25 Jul 2008 15:36:52 > > -0500 (CDT)): > > > > > On Fri, 25 Jul 2008, Chagin Dmitry wrote: > > > > > > uname must work on all supported linuxulators > > > > > > I agree, and it does work until I start playing with the Linux version. > > > > Don't play with the linux version while linux programs are running. > > Changing the version from 2.4.x to 2.6.x and vice versa while a program > > is running is not supported at all and known to cause havoc. Roman, do > > we have the possibility to make an easy check in the sysctl handler if > > a linux program is still running and return an error from the handler? > > Did I forgot something which makes it impossible to switch when a > > program was run under 2.6 and stopped? > > I'll submit a patch that makes it impossible to switch the veresion when > programs are running... it's not hard (elf{32}_brand_inuse() for every > elf brand the linuxulator registered) here it is: Index: linux_mib.c =================================================================== --- linux_mib.c (revision 180831) +++ linux_mib.c (working copy) @@ -251,8 +251,17 @@ { struct prison *pr; struct linux_prison *lpr; + Elf32_Brandinfo **brandinfo; int use26; + for (brandinfo = &linux_brandlist[0]; *brandinfo != NULL; + ++brandinfo) + if (elf32_brand_inuse(*brandinfo)) { + printf("Cannot change osrelease while Linux binaries are running.\r\n"); + return (EBUSY); + } + + use26 = (strlen(osrelease) >= 3 && osrelease[2] == '6'); pr = linux_get_prison(td); it's a copy'n'paste from i386/linux/linux_sysvec.c so I didnt bother to test it ;) but I guess it works :) roman From Alexander at Leidinger.net Sun Jul 27 10:15:16 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sun Jul 27 10:15:22 2008 Subject: Q: Is there any use for Oracle database port installation under Linux compat root ? In-Reply-To: <78cb3d3f0807270122r4d2377d9gbf4e3ed5386918fa@mail.gmail.com> References: <78cb3d3f0807260841k336f20a9jce857189c55adb16@mail.gmail.com> <78cb3d3f0807270122r4d2377d9gbf4e3ed5386918fa@mail.gmail.com> Message-ID: <20080727121503.679bc598@deskjail> Quoting "Adrian Penisoara" (Sun, 27 Jul 2008 11:22:20 +0300): > Hi, > > I am working on a FreeBSD port for Oracle's XE database package[1] (Linux > binaries) and I stumbled upon some issues related to USE_LINUX_PREFIX. > Before going any further trying to support (as an option) installing the > Oracle XE directly under the /compat/linux hierarchy (like the > database/linux-oracle-instantclient-* ports are doing), I have to ask ask > around the following: > > (1) Is there any real need/benefit to have an Oracle DB installation rooted > under /compat/linux (e.g. /compat/linux/usr/lib/oracle/xe/...) ? Side note: > in this case all shell scripts will need to be ran under > /compat/linux/bin/bash. > > (2) How does one deal with installing manual pages and shared files with > USE_LINUX_PREFIX -- do they also have to go under /compat/linux ? Using > ${MANPREFIX} as a template gives wrong results in this case... A port has to install into LINUXPREFIX, if it is an infrastructure port (no part has to go outside this location). It has to install into the default location (PREFIX/LOCALBASE), if it is an enduser port. That's the easy part. Now the classification, what is what, is the hard part. The linux png/jpeg or whatever lib is for sure infrastructure. If this would land in the default FreeBSD lib path, rest assured it would hurt. A linux acroread port is an enduser application, a user will call it directly to work with it. It also does not come with libs in the default FreeBSD locations, so everything will be fine if it is installed in the default location. For the Oracle stuff I can imagine that it is a hard question. If it doesn't put libs into a FreeBSD lib directory (a subdirectory of a lib directory is ok, as it will not cause immediate problems), there are no immediate objections to putting it into the default FreeBSD location (and as the DBA as an enduser would use it, this would fit into the description above). But we also have the rule that nothing is allowed to be put into the basesystem (/usr/Y instead of /usr/local/Y). Think about jails where the base is mounted read-only and only additional programs are in a RW part. In the end it comes down to what you are able to do and how hard the software is to port. Maybe it is easy to install everything into LINUXBASE and install a wrapper into LOCALBASE (/usr/local/bin/Y would be a script with #!/compat/linux/bin/bash and start whatever is needed to start /compat/linux/bin/Y). Maybe the installation of the software allows to install into /usr/local/softwarename and you can make links from /usr/local/bin/ to it. The rules for this are strong suggestions. If it is possible to do, do everything you can to follow the rules, if you don't know how to make something follow the rules, ask specific questions on ports if someone has in idea. If there's no idea, forget the rule and try to do something as close as possible to the goal of the rule (and document what/why). Bye, Alexander. -- Absolutely nothing in the world is friendlier than a wet dog. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From ady at freebsd.ady.ro Sun Jul 27 17:03:06 2008 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Sun Jul 27 17:03:24 2008 Subject: Q: Is there any use for Oracle database port installation under Linux compat root ? In-Reply-To: <20080727121503.679bc598@deskjail> References: <78cb3d3f0807260841k336f20a9jce857189c55adb16@mail.gmail.com> <78cb3d3f0807270122r4d2377d9gbf4e3ed5386918fa@mail.gmail.com> <20080727121503.679bc598@deskjail> Message-ID: <78cb3d3f0807271003q3f5ab72dr2147cf7b1a3348fc@mail.gmail.com> Hi, On Sun, Jul 27, 2008 at 1:15 PM, Alexander Leidinger < Alexander@leidinger.net> wrote: > Quoting "Adrian Penisoara" (Sun, 27 Jul 2008 11:22:20 > +0300): > > > Hi, > > > > I am working on a FreeBSD port for Oracle's XE database package[1] > (Linux > > binaries) and I stumbled upon some issues related to USE_LINUX_PREFIX. > > Before going any further trying to support (as an option) installing the > > Oracle XE directly under the /compat/linux hierarchy (like the > > database/linux-oracle-instantclient-* ports are doing), I have to ask ask > > around the following: > > > > (1) Is there any real need/benefit to have an Oracle DB installation > rooted > > under /compat/linux (e.g. /compat/linux/usr/lib/oracle/xe/...) ? Side > note: > > in this case all shell scripts will need to be ran under > > /compat/linux/bin/bash. > > > > (2) How does one deal with installing manual pages and shared files with > > USE_LINUX_PREFIX -- do they also have to go under /compat/linux ? Using > > ${MANPREFIX} as a template gives wrong results in this case... > > A port has to install into LINUXPREFIX, if it is an infrastructure > port (no part has to go outside this location). It has to install into > the default location (PREFIX/LOCALBASE), if it is an enduser port. > That's the easy part. Good pointer, I was missing this bit. Thanks. > > > Now the classification, what is what, is the hard part. The linux > png/jpeg or whatever lib is for sure infrastructure. If this would land > in the default FreeBSD lib path, rest assured it would hurt. A linux > acroread port is an enduser application, a user will call it directly > to work with it. It also does not come with libs in the default FreeBSD > locations, so everything will be fine if it is installed in the default > location. > > For the Oracle stuff I can imagine that it is a hard question. If it > doesn't put libs into a FreeBSD lib directory (a subdirectory of a lib > directory is ok, as it will not cause immediate problems), there are no > immediate objections to putting it into the default FreeBSD location > (and as the DBA as an enduser would use it, this would fit into the > description above). But we also have the rule that nothing is allowed > to be put into the basesystem (/usr/Y instead of /usr/local/Y). Think > about jails where the base is mounted read-only and only additional > programs are in a RW part. In the default configuration the binaries (and I mean all of them!) would be placed under /usr/lib/oracle, since this is a hardcoded path in all places. I will also offer a "WITH_BSDHIER" option which will root the installation into /usr/local/oracle and just make a symlink under /usr/lib. Should I rather make this the default ? ;) There are no libraries (or other binaries for that fact) installed outside the Oracle hierarchy (this is the general strategy for Oracle RDBMS products at least). So I guess it very nicely fits into the "enduser" picture you describe above. I'm just wandering whether a /compat/linux rooted installation would make sense. I am still interested to hear opinions from Oracle DBAs/users on this subject -- would you need this option ? > > > In the end it comes down to what you are able to do and how hard the > software is to port. Maybe it is easy to install everything into > LINUXBASE and install a wrapper into LOCALBASE (/usr/local/bin/Y would > be a script with #!/compat/linux/bin/bash and start whatever is needed > to start /compat/linux/bin/Y). Maybe the installation of the software > allows to install into /usr/local/softwarename and you can make links > from /usr/local/bin/ to it. > > The rules for this are strong suggestions. If it is possible to do, > do everything you can to follow the rules, if you don't know how to > make something follow the rules, ask specific questions on ports if > someone has in idea. If there's no idea, forget the rule and try to do > something as close as possible to the goal of the rule (and document > what/why). > > Bye, > Alexander. > > Thank you for your time. Adrian. From chagin.dmitry at gmail.com Sun Jul 27 17:05:37 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Sun Jul 27 17:05:44 2008 Subject: kern/117010: [linux] linux_getdents() get somethinng like buffer overflow In-Reply-To: <20080726091045.4c617dc7@deskjail> References: <200807250700.m6P70FSF036132@freefall.freebsd.org> <20080726091045.4c617dc7@deskjail> Message-ID: On Sat, 26 Jul 2008, Alexander Leidinger wrote: > Quoting Chagin Dmitry (Fri, 25 Jul 2008 07:00:15 GMT): > >> The following reply was made to PR kern/117010; it has been noted by GNATS. >> >> From: Chagin Dmitry >> To: bug-followup@freebsd.org, samflanker@gmail.com >> Cc: >> Subject: Re: kern/117010: [linux] linux_getdents() get somethinng like buffer >> overflow >> Date: Fri, 25 Jul 2008 10:22:46 +0400 (MSD) >> >> Please, try a patch below: >> >> diff --git a/src/sys/compat/linux/linux_file.c b/src/sys/compat/linux/linux_file >> index 303bc3f..d88f95f 100644 >> --- a/src/sys/compat/linux/linux_file.c >> +++ b/src/sys/compat/linux/linux_file.c >> @@ -303,8 +303,8 @@ struct l_dirent64 { >> char d_name[LINUX_NAME_MAX + 1]; >> }; >> >> -#define LINUX_RECLEN(de,namlen) \ >> - ALIGN((((char *)&(de)->d_name - (char *)de) + (namlen) + 1)) >> +#define LINUX_RECLEN(de,namlen,trail) \ >> + ALIGN((((char *)&(de)->d_name - (char *)de) + (namlen) + trail)) > > > The start of de->d_name minus the start of de should be the same as the offset of d_name in de, so I would expect that this is expressed with the offsetof maro instead of handmade. > > So the result of this is the offset plus a len + something. > well... agree. >> #define LINUX_DIRBLKSIZ 512 >> >> @@ -436,8 +436,8 @@ again: >> } > > I try to understand the code before this. There's "if (reclen & 3)" error out. Does it mean it has to be a multiple of 4? If yes it should be changed to some modulo calculation to make it obvious (the compiler should be able to do such micro optimisations, but I doubt the error case needs to be micro optimized). > this code looks as a workaround... exists since v1.1, I don't understand what is it. >> linuxreclen = (is64bit) >> - ? LINUX_RECLEN(&linux_dirent64, bdp->d_namlen) >> - : LINUX_RECLEN(&linux_dirent, bdp->d_namlen); >> + ? LINUX_RECLEN(&linux_dirent64, bdp->d_namlen, 1) >> + : LINUX_RECLEN(&linux_dirent, bdp->d_namlen, 2); > > Translated: The length of the linux record is the offset plus the FreeBSD size plus something. Doesn't make sense to me. sizeof(linux_dirent) sound more suitable for this variable name. From the code it can not be the length of the linux record, but the size of a linux dirent struct which would be required to put all info inside (+ some more space... very suspicious). > >> if (reclen > len || resid < linuxreclen) { >> outp++; > > First part: if the length of the current record is larger than the remaining free space (if it does not fit) go out of the loop... ok. > no, here reclen is the length of FreeBSD record and len is the remaining space in FreeBSD records buffer. > Second part: if the length (in bytes?) is smaller than the theoretical size of the linux struct, go out of the loop. Ouch. Please tell me this is wrong (I didn't had breakfast yet, I really hope I misanalysed this because of this fact). > no, resid is the free space in Linux records buffer, linuxreclen is the length of the Linux record. > I smell buffer mismanagement because of the strange 1 or 2 being added to the size, and I smell some convoluted logic there. Instead of trying to poke the thing until it works, I suggest to step back and have a look at the big picture if the entire part of the function can be improved. This is the Linux, as Roman says - linux is a really strange :) See linux source fs/readdir.c implementation of filldir functions > >> it solves getdents() problem (at least at x86_64 emulation with >> linux_base-f8) >> >> ps, be not bared, linux really has such features... > > What I would expect is to compare the strlen of the FreeBSD record with the size of the place in linux_dirent. If the FreeBSD record does not fit, fail (ENAMETOOLONG?). Compare the remaining space with the size of linux_dirent, if it is '<=' fill in the data into the fixed size struct. > It's done in the 'Second part' thnx! -- Have fun! chd From chagin.dmitry at gmail.com Sun Jul 27 17:16:35 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Sun Jul 27 17:16:42 2008 Subject: Q: Is there any use for Oracle database port installation under Linux compat root ? In-Reply-To: <78cb3d3f0807271003q3f5ab72dr2147cf7b1a3348fc@mail.gmail.com> References: <78cb3d3f0807260841k336f20a9jce857189c55adb16@mail.gmail.com> <78cb3d3f0807270122r4d2377d9gbf4e3ed5386918fa@mail.gmail.com> <20080727121503.679bc598@deskjail> <78cb3d3f0807271003q3f5ab72dr2147cf7b1a3348fc@mail.gmail.com> Message-ID: On Sun, 27 Jul 2008, Adrian Penisoara wrote: > Hi, > > On Sun, Jul 27, 2008 at 1:15 PM, Alexander Leidinger < > Alexander@leidinger.net> wrote: > >> Quoting "Adrian Penisoara" (Sun, 27 Jul 2008 11:22:20 >> +0300): >> >>> Hi, >>> >>> I am working on a FreeBSD port for Oracle's XE database package[1] >> (Linux >>> binaries) and I stumbled upon some issues related to USE_LINUX_PREFIX. >>> Before going any further trying to support (as an option) installing the >>> Oracle XE directly under the /compat/linux hierarchy (like the >>> database/linux-oracle-instantclient-* ports are doing), I have to ask ask >>> around the following: >>> >>> (1) Is there any real need/benefit to have an Oracle DB installation >> rooted >>> under /compat/linux (e.g. /compat/linux/usr/lib/oracle/xe/...) ? Side >> note: >>> in this case all shell scripts will need to be ran under >>> /compat/linux/bin/bash. >>> >>> (2) How does one deal with installing manual pages and shared files with >>> USE_LINUX_PREFIX -- do they also have to go under /compat/linux ? Using >>> ${MANPREFIX} as a template gives wrong results in this case... >> >> A port has to install into LINUXPREFIX, if it is an infrastructure >> port (no part has to go outside this location). It has to install into >> the default location (PREFIX/LOCALBASE), if it is an enduser port. >> That's the easy part. > > > Good pointer, I was missing this bit. Thanks. > > >> >> >> Now the classification, what is what, is the hard part. The linux >> png/jpeg or whatever lib is for sure infrastructure. If this would land >> in the default FreeBSD lib path, rest assured it would hurt. A linux >> acroread port is an enduser application, a user will call it directly >> to work with it. It also does not come with libs in the default FreeBSD >> locations, so everything will be fine if it is installed in the default >> location. >> >> For the Oracle stuff I can imagine that it is a hard question. If it >> doesn't put libs into a FreeBSD lib directory (a subdirectory of a lib >> directory is ok, as it will not cause immediate problems), there are no >> immediate objections to putting it into the default FreeBSD location >> (and as the DBA as an enduser would use it, this would fit into the >> description above). But we also have the rule that nothing is allowed >> to be put into the basesystem (/usr/Y instead of /usr/local/Y). Think >> about jails where the base is mounted read-only and only additional >> programs are in a RW part. > > > In the default configuration the binaries (and I mean all of them!) would > be placed under /usr/lib/oracle, since this is a hardcoded path in all > places. > I will also offer a "WITH_BSDHIER" option which will root the installation > into /usr/local/oracle and just make a symlink under /usr/lib. Should I > rather make this the default ? ;) > > There are no libraries (or other binaries for that fact) installed outside > the Oracle hierarchy (this is the general strategy for Oracle RDBMS products > at least). So I guess it very nicely fits into the "enduser" picture you > describe above. I'm just wandering whether a /compat/linux rooted > installation would make sense. > > I am still interested to hear opinions from Oracle DBAs/users on this > subject -- would you need this option ? > hi! I think that ora DBAs will tell that the best place it /home/ORAUSERNAME and this user should have shell /compat/linux/bin/bash thnx! > >> >> >> In the end it comes down to what you are able to do and how hard the >> software is to port. Maybe it is easy to install everything into >> LINUXBASE and install a wrapper into LOCALBASE (/usr/local/bin/Y would >> be a script with #!/compat/linux/bin/bash and start whatever is needed >> to start /compat/linux/bin/Y). Maybe the installation of the software >> allows to install into /usr/local/softwarename and you can make links >> from /usr/local/bin/ to it. >> >> The rules for this are strong suggestions. If it is possible to do, >> do everything you can to follow the rules, if you don't know how to >> make something follow the rules, ask specific questions on ports if >> someone has in idea. If there's no idea, forget the rule and try to do >> something as close as possible to the goal of the rule (and document >> what/why). >> >> Bye, >> Alexander. >> >> > Thank you for your time. > Adrian. > _______________________________________________ > 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" > -- Have fun! chd From rdivacky at freebsd.org Sun Jul 27 18:41:34 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Sun Jul 27 18:41:43 2008 Subject: kern/117010: [linux] linux_getdents() get somethinng like buffer overflow In-Reply-To: References: <200807250700.m6P70FSF036132@freefall.freebsd.org> <20080726091045.4c617dc7@deskjail> Message-ID: <20080727184006.GA99255@freebsd.org> On Sun, Jul 27, 2008 at 09:05:03PM +0400, Chagin Dmitry wrote: > On Sat, 26 Jul 2008, Alexander Leidinger wrote: > > >Quoting Chagin Dmitry (Fri, 25 Jul 2008 07:00:15 > >GMT): > > > >>The following reply was made to PR kern/117010; it has been noted by > >>GNATS. > >> > >>From: Chagin Dmitry > >>To: bug-followup@freebsd.org, samflanker@gmail.com > >>Cc: > >>Subject: Re: kern/117010: [linux] linux_getdents() get somethinng like > >>buffer > >> overflow > >>Date: Fri, 25 Jul 2008 10:22:46 +0400 (MSD) > >> > >> Please, try a patch below: > >> > >> diff --git a/src/sys/compat/linux/linux_file.c > >> b/src/sys/compat/linux/linux_file > >> index 303bc3f..d88f95f 100644 > >> --- a/src/sys/compat/linux/linux_file.c > >> +++ b/src/sys/compat/linux/linux_file.c > >> @@ -303,8 +303,8 @@ struct l_dirent64 { > >> char d_name[LINUX_NAME_MAX + 1]; > >> }; > >> > >> -#define LINUX_RECLEN(de,namlen) \ > >> - ALIGN((((char *)&(de)->d_name - (char *)de) + (namlen) + 1)) > >> +#define LINUX_RECLEN(de,namlen,trail) \ > >> + ALIGN((((char *)&(de)->d_name - (char *)de) + (namlen) + trail)) > > > > > >The start of de->d_name minus the start of de should be the same as the > >offset of d_name in de, so I would expect that this is expressed with the > >offsetof maro instead of handmade. > > > >So the result of this is the offset plus a len + something. > > > > well... agree. > > >> #define LINUX_DIRBLKSIZ 512 > >> > >> @@ -436,8 +436,8 @@ again: > >> } > > > >I try to understand the code before this. There's "if (reclen & 3)" error > >out. Does it mean it has to be a multiple of 4? If yes it should be > >changed to some modulo calculation to make it obvious (the compiler should > >be able to do such micro optimisations, but I doubt the error case needs > >to be micro optimized). > > > > this code looks as a workaround... exists since v1.1, I don't understand > what is it. > > > >> linuxreclen = (is64bit) > >> - ? LINUX_RECLEN(&linux_dirent64, bdp->d_namlen) > >> - : LINUX_RECLEN(&linux_dirent, bdp->d_namlen); > >> + ? LINUX_RECLEN(&linux_dirent64, bdp->d_namlen, 1) > >> + : LINUX_RECLEN(&linux_dirent, bdp->d_namlen, 2); > > > >Translated: The length of the linux record is the offset plus the FreeBSD > >size plus something. Doesn't make sense to me. sizeof(linux_dirent) sound > >more suitable for this variable name. From the code it can not be the > >length of the linux record, but the size of a linux dirent struct which > >would be required to put all info inside (+ some more space... very > >suspicious). > > > >> if (reclen > len || resid < linuxreclen) { > >> outp++; > > > >First part: if the length of the current record is larger than the > >remaining free space (if it does not fit) go out of the loop... ok. > > > > no, here reclen is the length of FreeBSD record and len is the remaining > space in FreeBSD records buffer. > > > >Second part: if the length (in bytes?) is smaller than the theoretical > >size of the linux struct, go out of the loop. Ouch. Please tell me this is > >wrong (I didn't had breakfast yet, I really hope I misanalysed this > >because of this fact). > > > > no, resid is the free space in Linux records buffer, linuxreclen is the > length of the Linux record. > > >I smell buffer mismanagement because of the strange 1 or 2 being added to > >the size, and I smell some convoluted logic there. Instead of trying to > >poke the thing until it works, I suggest to step back and have a look at > >the big picture if the entire part of the function can be improved. > > This is the Linux, as Roman says - linux is a really strange :) > See linux source fs/readdir.c implementation of filldir functions I'll look at the readdir.c implementation, analyze it but I guess Dmitry's version is ok. if I find it correct I think we should wait for someone to test it but if noone does I think it can be commited with just Dmitry's testing and my analysis :) roman From Alexander at Leidinger.net Mon Jul 28 06:54:15 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Mon Jul 28 06:54:22 2008 Subject: kern/117010: [linux] linux_getdents() get somethinng like buffer overflow In-Reply-To: References: <200807250700.m6P70FSF036132@freefall.freebsd.org> <20080726091045.4c617dc7@deskjail> Message-ID: <20080728085403.58063b2gbchdjtic@webmail.leidinger.net> Quoting "Chagin Dmitry" (from Sun, 27 Jul 2008 21:05:03 +0400 (MSD)): > On Sat, 26 Jul 2008, Alexander Leidinger wrote: > >> Quoting Chagin Dmitry (Fri, 25 Jul 2008 >> 07:00:15 GMT): >> >>> The following reply was made to PR kern/117010; it has been noted by GNATS. >>> >>> From: Chagin Dmitry >>> To: bug-followup@freebsd.org, samflanker@gmail.com >>> Cc: >>> Subject: Re: kern/117010: [linux] linux_getdents() get somethinng >>> like buffer >>> overflow >>> Date: Fri, 25 Jul 2008 10:22:46 +0400 (MSD) >>> >>> Please, try a patch below: >>> >>> diff --git a/src/sys/compat/linux/linux_file.c >>> b/src/sys/compat/linux/linux_file >>> index 303bc3f..d88f95f 100644 >>> --- a/src/sys/compat/linux/linux_file.c >>> +++ b/src/sys/compat/linux/linux_file.c >>> @@ -303,8 +303,8 @@ struct l_dirent64 { >>> char d_name[LINUX_NAME_MAX + 1]; >>> }; >>> >>> -#define LINUX_RECLEN(de,namlen) \ >>> - ALIGN((((char *)&(de)->d_name - (char *)de) + (namlen) + 1)) >>> +#define LINUX_RECLEN(de,namlen,trail) \ >>> + ALIGN((((char *)&(de)->d_name - (char *)de) + (namlen) + trail)) >> >> >> The start of de->d_name minus the start of de should be the same as >> the offset of d_name in de, so I would expect that this is >> expressed with the offsetof maro instead of handmade. >> >> So the result of this is the offset plus a len + something. >> > > well... agree. > >>> #define LINUX_DIRBLKSIZ 512 >>> >>> @@ -436,8 +436,8 @@ again: >>> } >> >> I try to understand the code before this. There's "if (reclen & 3)" >> error out. Does it mean it has to be a multiple of 4? If yes it >> should be changed to some modulo calculation to make it obvious >> (the compiler should be able to do such micro optimisations, but I >> doubt the error case needs to be micro optimized). >> > > this code looks as a workaround... exists since v1.1, I don't > understand what is it. When you look at the FreeBSD manpage of dirent, it's not that surprising: ---snip--- /* * The dirent structure defines the format of directory entries returned by * the getdirentries(2) system call. * * A directory entry has a struct dirent at the front of it, containing its * inode number, the length of the entry, and the length of the name * contained in the entry. These are followed by the name padded to a 4 * byte boundary with null bytes. All names are guaranteed null terminated. * The maximum length of a name in a directory is MAXNAMLEN. */ ---snip--- >>> linuxreclen = (is64bit) >>> - ? LINUX_RECLEN(&linux_dirent64, bdp->d_namlen) >>> - : LINUX_RECLEN(&linux_dirent, bdp->d_namlen); >>> + ? LINUX_RECLEN(&linux_dirent64, bdp->d_namlen, 1) >>> + : LINUX_RECLEN(&linux_dirent, bdp->d_namlen, 2); >> >> Translated: The length of the linux record is the offset plus the >> FreeBSD size plus something. Doesn't make sense to me. >> sizeof(linux_dirent) sound more suitable for this variable name. >> From the code it can not be the length of the linux record, but the >> size of a linux dirent struct which would be required to put all >> info inside (+ some more space... very suspicious). >> >>> if (reclen > len || resid < linuxreclen) { >>> outp++; >> >> First part: if the length of the current record is larger than the >> remaining free space (if it does not fit) go out of the loop... ok. >> > > no, here reclen is the length of FreeBSD record and len is the > remaining space in FreeBSD records buffer. len is the memory region where you construct the linux response, isn't it? >> Second part: if the length (in bytes?) is smaller than the >> theoretical size of the linux struct, go out of the loop. Ouch. >> Please tell me this is wrong (I didn't had breakfast yet, I really >> hope I misanalysed this because of this fact). >> > > no, resid is the free space in Linux records buffer, linuxreclen is > the length of the Linux record. Seems there was a part missing above... "lenght in bytes" = remaining length in bytes. The important part is the use of the macro. The linux reclen macro calculates some linux stuff + some freebsd stuff without any limit checks. What happens if the size of the name member of the struct changes in FreeBSD!?! Even if they _may_ be the same currently, this is dangerous. >> I smell buffer mismanagement because of the strange 1 or 2 being >> added to the size, and I smell some convoluted logic there. Instead >> of trying to poke the thing until it works, I suggest to step back >> and have a look at the big picture if the entire part of the >> function can be improved. > > This is the Linux, as Roman says - linux is a really strange :) > See linux source fs/readdir.c implementation of filldir functions When I look at this, I even see more dragons in our code. In linux (2.6 kernel) linux_dirent is playing the ARRAY[1] + size trick, in FreeBSD it isn't. Some things are handled like in linux, but because the trick is not done in FreeBSD, those can not be handled like in linux. When I look at the patch you proposed, I also see a pitfall. In linux in the 64bit case, it's "int reclen = ALIGN(NAME_OFFSET(dirent) + namlen + 1, sizeof(u64));", in the 32bit case it's "int reclen = ALIGN(NAME_OFFSET(dirent) + namlen + 2, sizeof(long));". This means the length is aligned to 64bit for the 64bit case and 32bit in the 32bit case. >>> it solves getdents() problem (at least at x86_64 emulation with >>> linux_base-f8) >>> >>> ps, be not bared, linux really has such features... >> >> What I would expect is to compare the strlen of the FreeBSD record >> with the size of the place in linux_dirent. If the FreeBSD record >> does not fit, fail (ENAMETOOLONG?). Compare the remaining space >> with the size of linux_dirent, if it is '<=' fill in the data into >> the fixed size struct. >> > > It's done in the 'Second part' There should be a check before data is copied to the place. As the size is already available, it doesn't cost much. I try to get some time this week to produce a patch which addresses my concerns. Bye, Alexander. -- Moebius always does it on the same side. 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 Mon Jul 28 07:00:14 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Mon Jul 28 07:00:21 2008 Subject: kern/117010: [linux] linux_getdents() get somethinng like buffer overflow In-Reply-To: <20080727184006.GA99255@freebsd.org> References: <200807250700.m6P70FSF036132@freefall.freebsd.org> <20080726091045.4c617dc7@deskjail> <20080727184006.GA99255@freebsd.org> Message-ID: <20080728090005.17761bm27kjkasg0@webmail.leidinger.net> Quoting "Roman Divacky" (from Sun, 27 Jul 2008 20:40:06 +0200): > I'll look at the readdir.c implementation, analyze it but I guess > Dmitry's version is ok. if I find it correct I think we should > wait for someone to test it but if noone does I think it can be > commited with just Dmitry's testing and my analysis :) Can you confirm or deny http://www.cs.helsinki.fi/linux/linux-kernel/2001-02/1076.html ? Please give me a week, I try to come up with patches for review which address my concerns as expressed in my reply today to Dmitry. Bye, Alexander. -- There is hopeful symbolism in the fact that flags do not wave in a vacuum. -- Arthur C. Clarke http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From chagin.dmitry at gmail.com Mon Jul 28 10:23:22 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Mon Jul 28 10:23:30 2008 Subject: kern/117010: [linux] linux_getdents() get somethinng like buffer overflow In-Reply-To: <20080728085403.58063b2gbchdjtic@webmail.leidinger.net> References: <200807250700.m6P70FSF036132@freefall.freebsd.org> <20080726091045.4c617dc7@deskjail> <20080728085403.58063b2gbchdjtic@webmail.leidinger.net> Message-ID: On Mon, 28 Jul 2008, Alexander Leidinger wrote: > Quoting "Chagin Dmitry" (from Sun, 27 Jul 2008 > 21:05:03 +0400 (MSD)): > >> On Sat, 26 Jul 2008, Alexander Leidinger wrote: >> >>> Quoting Chagin Dmitry (Fri, 25 Jul 2008 07:00:15 >>> GMT): >>> >>>> The following reply was made to PR kern/117010; it has been noted by >>>> GNATS. >>>> >>>> From: Chagin Dmitry >>>> To: bug-followup@freebsd.org, samflanker@gmail.com >>>> Cc: >>>> Subject: Re: kern/117010: [linux] linux_getdents() get somethinng like >>>> buffer >>>> overflow >>>> Date: Fri, 25 Jul 2008 10:22:46 +0400 (MSD) >>>> >>>> Please, try a patch below: >>>> >>>> diff --git a/src/sys/compat/linux/linux_file.c >>>> b/src/sys/compat/linux/linux_file >>>> index 303bc3f..d88f95f 100644 >>>> --- a/src/sys/compat/linux/linux_file.c >>>> +++ b/src/sys/compat/linux/linux_file.c >>>> @@ -303,8 +303,8 @@ struct l_dirent64 { >>>> char d_name[LINUX_NAME_MAX + 1]; >>>> }; >>>> >>>> -#define LINUX_RECLEN(de,namlen) \ >>>> - ALIGN((((char *)&(de)->d_name - (char *)de) + (namlen) + 1)) >>>> +#define LINUX_RECLEN(de,namlen,trail) \ >>>> + ALIGN((((char *)&(de)->d_name - (char *)de) + (namlen) + trail)) >>> >>> >>> The start of de->d_name minus the start of de should be the same as the >>> offset of d_name in de, so I would expect that this is expressed with the >>> offsetof maro instead of handmade. >>> >>> So the result of this is the offset plus a len + something. >>> >> >> well... agree. >> >>>> #define LINUX_DIRBLKSIZ 512 >>>> >>>> @@ -436,8 +436,8 @@ again: >>>> } >>> >>> I try to understand the code before this. There's "if (reclen & 3)" error >>> out. Does it mean it has to be a multiple of 4? If yes it should be >>> changed to some modulo calculation to make it obvious (the compiler should >>> be able to do such micro optimisations, but I doubt the error case needs >>> to be micro optimized). >>> >> >> this code looks as a workaround... exists since v1.1, I don't understand >> what is it. > > When you look at the FreeBSD manpage of dirent, it's not that surprising: > ---snip--- > /* > * The dirent structure defines the format of directory entries returned > by > * the getdirentries(2) system call. > * > * A directory entry has a struct dirent at the front of it, containing > its > * inode number, the length of the entry, and the length of the name > * contained in the entry. These are followed by the name padded to a 4 > * byte boundary with null bytes. All names are guaranteed null > terminated. > * The maximum length of a name in a directory is MAXNAMLEN. > */ > ---snip--- > ups... tnhx!, but what for we do here this check? IMO, it is excessive. >>>> linuxreclen = (is64bit) >>>> - ? LINUX_RECLEN(&linux_dirent64, bdp->d_namlen) >>>> - : LINUX_RECLEN(&linux_dirent, bdp->d_namlen); >>>> + ? LINUX_RECLEN(&linux_dirent64, bdp->d_namlen, 1) >>>> + : LINUX_RECLEN(&linux_dirent, bdp->d_namlen, 2); >>> >>> Translated: The length of the linux record is the offset plus the FreeBSD >>> size plus something. Doesn't make sense to me. sizeof(linux_dirent) sound >>> more suitable for this variable name. From the code it can not be the >>> length of the linux record, but the size of a linux dirent struct which >>> would be required to put all info inside (+ some more space... very >>> suspicious). >>> >>>> if (reclen > len || resid < linuxreclen) { >>>> outp++; >>> >>> First part: if the length of the current record is larger than the >>> remaining free space (if it does not fit) go out of the loop... ok. >>> >> >> no, here reclen is the length of FreeBSD record and len is the remaining >> space in FreeBSD records buffer. > > len is the memory region where you construct the linux response, isn't it? > you are mistaken here, len points to FreeBSD buffer filled by vop_readdir >>> Second part: if the length (in bytes?) is smaller than the theoretical >>> size of the linux struct, go out of the loop. Ouch. Please tell me this is >>> wrong (I didn't had breakfast yet, I really hope I misanalysed this >>> because of this fact). >>> >> >> no, resid is the free space in Linux records buffer, linuxreclen is the >> length of the Linux record. > > Seems there was a part missing above... "lenght in bytes" = remaining length > in bytes. The important part is the use of the macro. The linux reclen macro > calculates some linux stuff + some freebsd stuff without any limit checks. > What happens if the size of the name member of the struct changes in > FreeBSD!?! Even if they _may_ be the same currently, this is dangerous. > agree, we should do check before calculating linuxreclen, like: if (bdp->d_namlen > LINUX_NAME_MAX) { error = ENAMETOOLONG; goto out; } >>> I smell buffer mismanagement because of the strange 1 or 2 being added to >>> the size, and I smell some convoluted logic there. Instead of trying to >>> poke the thing until it works, I suggest to step back and have a look at >>> the big picture if the entire part of the function can be improved. >> >> This is the Linux, as Roman says - linux is a really strange :) >> See linux source fs/readdir.c implementation of filldir functions > > When I look at this, I even see more dragons in our code. In linux (2.6 > kernel) linux_dirent is playing the ARRAY[1] + size trick, in FreeBSD it > isn't. Some things are handled like in linux, but because the trick is not > done in FreeBSD, those can not be handled like in linux. > > When I look at the patch you proposed, I also see a pitfall. In linux in the > 64bit case, it's "int reclen = ALIGN(NAME_OFFSET(dirent) + namlen + 1, > sizeof(u64));", in the 32bit case it's "int reclen = > ALIGN(NAME_OFFSET(dirent) + namlen + 2, sizeof(long));". This means the > length is aligned to 64bit for the 64bit case and 32bit in the 32bit case. > ah.., getdents64 on all $arch's uses 64bit alignment, we should follow this behaviour. >>>> it solves getdents() problem (at least at x86_64 emulation with >>>> linux_base-f8) >>>> >>>> ps, be not bared, linux really has such features... >>> >>> What I would expect is to compare the strlen of the FreeBSD record with >>> the size of the place in linux_dirent. If the FreeBSD record does not fit, >>> fail (ENAMETOOLONG?). Compare the remaining space with the size of >>> linux_dirent, if it is '<=' fill in the data into the fixed size struct. >>> >> >> It's done in the 'Second part' > > There should be a check before data is copied to the place. As the size is > already available, it doesn't cost much. > > I try to get some time this week to produce a patch which addresses my > concerns. > ok, I shall test on amd64 :) thnx! -- Have fun! chd From rdivacky at freebsd.org Mon Jul 28 10:28:43 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Mon Jul 28 10:28:50 2008 Subject: kern/117010: [linux] linux_getdents() get somethinng like buffer overflow In-Reply-To: References: <200807250700.m6P70FSF036132@freefall.freebsd.org> <20080726091045.4c617dc7@deskjail> <20080728085403.58063b2gbchdjtic@webmail.leidinger.net> Message-ID: <20080728102715.GA78842@freebsd.org> [snip of technical discussion] while I agree with the attitude that it should be fixed properly, we are in a situation where a simple patch fixes a problem. and the fix is correct. I think we should just commit Dmitry's patch and then talk about how to change linux_getdents() further. I looked at the Linux code and the alignment is really +2 for 32bit and +1 for 64 bit as Dmitry's patch does. do you guys agree that fixing the problem the simplest/fastest way now and then changing other things is the correct way? roman From bugmaster at FreeBSD.org Mon Jul 28 11:06:55 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 28 11:07:29 2008 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org Message-ID: <200807281106.m6SB6sd2078872@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/21463 emulation [linux] Linux compatability mode should not allow setu o kern/97326 emulation [linux] file descriptor leakage in linux emulation o kern/117010 emulation [linux] linux_getdents() get something like buffer ove 3 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 o kern/29698 emulation [linux] [patch] linux ipcs doesn'work o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/41543 emulation [patch] [request] easier wine/w23 support a kern/72920 emulation [linux]: path "prefixing" is not done on unix domain s o kern/73777 emulation [linux] [patch] linux emulation: root dir special hand o kern/91293 emulation [svr4] [patch] *Experimental* Update to the SVR4 emula o ports/91318 emulation [fix] graphics/linux_dri: works on amd64 too o ports/121800 emulation x11-toolkits/linux-openmotif - OpenMotif upgrade to 2. o kern/122318 emulation [linux] [cmake]: Segmentation fault when running Linux o ports/123960 emulation Port fix: archivers/linux-par2cmdline - better handlin o ports/123964 emulation Mk fix: bsd.linux-rpm.mk - Handling of NOPORTDOCS 12 problems total. From chagin.dmitry at gmail.com Mon Jul 28 11:12:47 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Mon Jul 28 11:12:54 2008 Subject: kern/117010: [linux] linux_getdents() get somethinng like buffer overflow In-Reply-To: References: <200807250700.m6P70FSF036132@freefall.freebsd.org> <20080726091045.4c617dc7@deskjail> <20080728085403.58063b2gbchdjtic@webmail.leidinger.net> Message-ID: On Mon, 28 Jul 2008, Chagin Dmitry wrote: > > agree, we should do check before calculating linuxreclen, like: > > if (bdp->d_namlen > LINUX_NAME_MAX) { > error = ENAMETOOLONG; > goto out; > } > d_namlen declared as uint8_t, so comparison is always false. lets's leave it will not changed FreeBSD d_namlen type? -- Have fun! chd From Alexander at Leidinger.net Mon Jul 28 11:37:23 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Mon Jul 28 11:37:31 2008 Subject: kern/117010: [linux] linux_getdents() get somethinng like buffer overflow In-Reply-To: <20080728102715.GA78842@freebsd.org> References: <200807250700.m6P70FSF036132@freefall.freebsd.org> <20080726091045.4c617dc7@deskjail> <20080728085403.58063b2gbchdjtic@webmail.leidinger.net> <20080728102715.GA78842@freebsd.org> Message-ID: <20080728133715.1670576xbp279u04@webmail.leidinger.net> Quoting "Roman Divacky" (from Mon, 28 Jul 2008 12:27:15 +0200): > > [snip of technical discussion] > > while I agree with the attitude that it should be fixed properly, we are > in a situation where a simple patch fixes a problem. and the fix is correct. > > I think we should just commit Dmitry's patch and then talk about how > to change > linux_getdents() further. I looked at the Linux code and the > alignment is really > +2 for 32bit and +1 for 64 bit as Dmitry's patch does. That's not the alignment, that's some simple but mandatory padding (a comment should be written there what this is, for the "1" it's the null byte of the name, for the second "1" (in the case of using "2"), I don't know yet what it is). I haven't checked yet if the size calculation (which has the wrong macro name ALIGN, it doesn't align, it just used in the align process) does the right thing on 64bit (padding to a 64bit boundary, so that the next entry starts at a 64bit boundary = alignment of the structure). > do you guys agree that fixing the problem the simplest/fastest way > now and then > changing other things is the correct way? It may fix the problem of some specific test cases, but I'm not sure it fixes all use cases. I see this as a partial fix to allow people to do some more tests in other areas of the linuxulator while someone is looking into a complete fix. I don't object if you commit it, but don't think dirent is bugfree after this (I would call it a temporary workaround). Bye, Alexander. -- A day without sunshine .... is like ... night! 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 Mon Jul 28 11:40:49 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Mon Jul 28 11:40:55 2008 Subject: kern/117010: [linux] linux_getdents() get somethinng like buffer overflow In-Reply-To: References: <200807250700.m6P70FSF036132@freefall.freebsd.org> <20080726091045.4c617dc7@deskjail> <20080728085403.58063b2gbchdjtic@webmail.leidinger.net> Message-ID: <20080728134037.545016bbrhzspi68@webmail.leidinger.net> Quoting "Chagin Dmitry" (from Mon, 28 Jul 2008 15:12:31 +0400 (MSD)): > On Mon, 28 Jul 2008, Chagin Dmitry wrote: > >> >> agree, we should do check before calculating linuxreclen, like: >> >> if (bdp->d_namlen > LINUX_NAME_MAX) { >> error = ENAMETOOLONG; >> goto out; >> } >> > > d_namlen declared as uint8_t, so comparison is always false. lets's > leave it will not changed FreeBSD d_namlen type? In the kernel I prefer defensive programming. Better safe than sorry. As long as there's no evidence that it is a performance bottleneck, there's no need to micro-optimize. Bye, Alexander. -- Capitalism can exist in one of only two states: welfare or warfare. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137