Re: NEW: games/eduke32 (again)
On Wednesday 07 March 2012 01:15:30 Ryan Freeman wrote: > Attached is the still-building port of eduke32 that I have > been sitting on for far too long. Antti Harri did most of > the initial work of getting fixes pushed upstream. > > I have pulled a recent snapshot from their repos, and > as those are done daily, we may wish to wait for a real > release, if those happen. Here you go, Edd! > > -ryan Hi, I took a quick look at this. Was the port honoring CC for you? Didn't seem to work for me. Anyway using MAKE_FLAGS is cleaner. Removed the hard-coded optimizations and disabled debugging. PS. The entry pointing to my dist site isn't working anymore because it only contains the previous snapshot. Let me know if it's still needed and I'll put the new one on my server where I have all the other distfiles. -- Antti Harri diff -uNr eduke32/Makefile /usr/ports/games/eduke32/Makefile --- eduke32/MakefileWed Mar 7 01:01:18 2012 +++ /usr/ports/games/eduke32/Makefile Wed Mar 7 09:44:39 2012 @@ -41,7 +41,7 @@ 3dduke13.zip:0 SEPERATE_BUILD = concurrent -MAKE_FLAGS = PRETTY_OUTPUT=0 DEBUGANYWAY=1 +MAKE_FLAGS = PRETTY_OUTPUT=0 CC="${CC}" CXX="${CXX}" USE_GMAKE =Yes NO_REGRESS = Yes diff -uNr eduke32/patches/patch-Makefile_common /usr/ports/games/eduke32/patches/patch-Makefile_common --- eduke32/patches/patch-Makefile_common Thu May 26 00:44:16 2011 +++ /usr/ports/games/eduke32/patches/patch-Makefile_common Wed Mar 7 09:48:33 2012 @@ -1,15 +1,11 @@ $OpenBSD$ - -Make build honor CC - Makefile.common.orig Wed May 25 10:52:37 2011 -+++ Makefile.commonWed May 25 10:53:18 2011 -@@ -56,8 +56,6 @@ endif +--- Makefile.common.orig Wed Mar 7 09:48:09 2012 Makefile.commonWed Mar 7 09:48:29 2012 +@@ -89,7 +89,6 @@ endif - - # Tools --CC=gcc --CXX=g++ - AS=nasm - AR=ar - RC=windres + ifneq (0,$(RELEASE)) + # Debugging disabled +-debug+= -O$(OPTLEVEL) + ifneq ($(CC),clang) + debug+= -funswitch-loops + endif diff -uNr eduke32/patches/patch-build_src_glbuild_c /usr/ports/games/eduke32/patches/patch-build_src_glbuild_c --- eduke32/patches/patch-build_src_glbuild_c Thu May 26 00:45:35 2011 +++ /usr/ports/games/eduke32/patches/patch-build_src_glbuild_c Wed Mar 7 09:45:40 2012 @@ -3,9 +3,9 @@ allow dlopen to find our libGL.so, falling back to libGL.so.1 for linux or others. build/src/glbuild.c.orig Sat Jan 15 18:50:27 2011 -+++ build/src/glbuild.cWed May 25 11:28:36 2011 -@@ -330,6 +330,8 @@ int32_t loadgldriver(const char *driver) +--- build/src/glbuild.c.orig Tue Oct 11 19:52:53 2011 build/src/glbuild.cWed Mar 7 09:45:03 2012 +@@ -338,6 +338,8 @@ int32_t loadgldriver(const char *driver) driver = "opengl32.dll"; #elif defined __APPLE__ driver = "/System/Library/Frameworks/OpenGL.framework/OpenGL"; @@ -14,7 +14,7 @@ #else driver = "libGL.so.1"; #endif -@@ -921,6 +923,8 @@ int32_t loadglulibrary(const char *driver) +@@ -936,6 +938,8 @@ int32_t loadglulibrary(const char *driver) driver = "glu32.dll"; #elif defined __APPLE__ driver = "/System/Library/Frameworks/OpenGL.framework/OpenGL"; // FIXME: like I know anything about Apple. Hah.
Re: NEW: games/eduke32 (again)
On Wed, Mar 07, 2012 at 09:58:21AM +0200, Antti Harri wrote: > On Wednesday 07 March 2012 01:15:30 Ryan Freeman wrote: > > Attached is the still-building port of eduke32 that I have > > been sitting on for far too long. Antti Harri did most of > > the initial work of getting fixes pushed upstream. > > > > I have pulled a recent snapshot from their repos, and > > as those are done daily, we may wish to wait for a real > > release, if those happen. Here you go, Edd! > > > > -ryan > > Hi, I took a quick look at this. Was the port honoring CC for you? > Didn't seem to work for me. Anyway using MAKE_FLAGS is cleaner. > Removed the hard-coded optimizations and disabled debugging. This game is serious fun. I'm still seeing a lot of '-fomgz-so-fast': ===> Building for eduke32-2.0.0.2394 if cc -O2 -pipe -funswitch-loops -fomit-frame-pointer -DNDEBUG -fno-stack-protector -W -Wall -Wimplicit -Werror-implicit-function-declaration -funsigned-char -fno-strict-aliasing -DNO_GCC_BUILTINS -D_FORTIFY_SOURCE=2 -fjump-tables -Wextra -Wstrict-overflow=1 -DUSE_LIBVPX -Isource -Ibuild/include -Isource/jmact -Isource/jaudiolib/include -Isource/enet/include -I/usr/local/include -I/usr/local/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/X11R6/include -DXTHREADS -DHAVE_GTK2 -I/usr/local/include/gtk-2.0 -I/usr/local/lib/gtk-2.0/include -I/usr/local/include/pango-1.0 -I/usr/local/include/gio-unix-2.0/ -I/usr/X11R6/include -I/usr/local/include/cairo -I/usr/local/include/atk-1.0 -I/usr/X11R6/include/pixman-1 -I/usr/include/dev/pci/drm -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/libpng -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/X11R6/include/freetype2 -DHAVE_INTTYPES -DRENDERTYPESDL=1 -DUSE_OPENGL -DNOASM -DPOLYMER -c source/game.c -o obj/game.o; then true; else false; exit 1; fi The other thing I wonder, should the data be a separate port, like it is for doom? -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
[update] libassuan
Hi, Small diff to update libassuan. Tested on @amd64 with rthreads. ok ? Regards, -- Pierre-Emmanuel André GPG key: 0x7AE329DC Index: Makefile === RCS file: /cvs/ports/security/libassuan/Makefile,v retrieving revision 1.8 diff -u -p -r1.8 Makefile --- Makefile6 Jul 2011 15:03:13 - 1.8 +++ Makefile7 Mar 2012 15:45:00 - @@ -2,7 +2,7 @@ COMMENT= IPC library used by GnuPG and gpgme -DISTNAME= libassuan-2.0.2 +DISTNAME= libassuan-2.0.3 SHARED_LIBS += assuan1.0 # 2.0 Index: distinfo === RCS file: /cvs/ports/security/libassuan/distinfo,v retrieving revision 1.5 diff -u -p -r1.5 distinfo --- distinfo6 Jul 2011 15:03:13 - 1.5 +++ distinfo7 Mar 2012 15:45:00 - @@ -1,5 +1,5 @@ -MD5 (libassuan-2.0.2.tar.bz2) = Pn0A/S7ooLnFGsdhbvPx7A== -RMD160 (libassuan-2.0.2.tar.bz2) = e6ATjYPyQto/0uuub53u9jgzKaY= -SHA1 (libassuan-2.0.2.tar.bz2) = 282W4lJdTDotqegFSgb6UX8goYU= -SHA256 (libassuan-2.0.2.tar.bz2) = YeDLoz3LreLc6VO5Xwa4Q68qc96HUwPyWFIn7NR1tNg= -SIZE (libassuan-2.0.2.tar.bz2) = 491172 +MD5 (libassuan-2.0.3.tar.bz2) = F50ZGDJf25KMe9kLilFPxw== +RMD160 (libassuan-2.0.3.tar.bz2) = JD0vWejY/0h1rLV/9uY6Rm8rdXQ= +SHA1 (libassuan-2.0.3.tar.bz2) = K/Tro7WIdY40mXan656KUJlgw7U= +SHA256 (libassuan-2.0.3.tar.bz2) = utVoI3THa8wKuxp6NMlVevaHSkd1AHSOZKfT3vecrBs= +SIZE (libassuan-2.0.3.tar.bz2) = 529149
Re: NEW: games/eduke32 (again)
On Wed, Mar 7, 2012 at 12:15 AM, Ryan Freeman wrote: > Attached is the still-building port of eduke32 that I have > been sitting on for far too long. Antti Harri did most of > the initial work of getting fixes pushed upstream. > > I have pulled a recent snapshot from their repos, and > as those are done daily, we may wish to wait for a real > release, if those happen. Here you go, Edd! Duke Nukem 3D... How many memories! I will try this port asap. cheers, David
Re: [update] libassuan
On Wed, Mar 7, 2012 at 4:46 PM, Pierre-Emmanuel André wrote: > Hi, > > Small diff to update libassuan. > Tested on @amd64 with rthreads. > > ok ? sure. ok for me ciao, David
NEW: net/weechat
Hi ports -- pkg/DESCR WeeChat is a fast, light and extensible chat client. It runs on many platforms (including Linux, BSD and Mac OS). I've been using this as my IRC client for a few months. Works for me on amd64 and loongson. I'm sure my do-install and post-install routines could be cleaner, but I'm unsure of the variables needed to make it cleaner. Comments/OK? Thanks. ~Brian weechat.tar.gz Description: application/gzip
[Update] Vnstat-1.11
Hi, Update for Vnstat to 1.11. Comments, Ok? Cheers. -- Sending from my VCR vnstat-1.11.diff Description: Binary data
[Update] ntop
Hi, A little update for ntop. Comments, Ok? Cheers. -- Sending from my VCR ntop-1.1p1.diff Description: Binary data
Re: Remove libao plugin's "write_size" constraint from mpd
On Mon, Mar 05, 2012 at 11:04:00AM +0100, David Coppa wrote: > I'd like to remove this "write_size" constraint, as suggested by > jakemsr@ some time ago: > afaiu, removing it is desirable, but might be tricky (see below). Does removing it improve stability? > http://marc.info/?l=openbsd-ports&m=128630571914847 > > http://marc.info/?l=openbsd-ports&m=128630890119517 > > As jake said, 1024 bytes is only 256 samples of 16-bit stereo. > At 44.1kHz, that's only 5.8 miliseconds. If mpd takes more than > 5.8 ms between writes, for whatever reason, it will skip. > So, this represents a performance penalty on fast machines and > afaik sndiod should already cope with eventual stuffups just > fine on slower ones... > > Alexandre, what do you think about this? Is it reasonable? write() blocks until the last byte of the chuck is stored in the device buffer. If the chuck is very large then write() will block for very long and the program will idle instead of decoding more data; in this case, the program doesn't use the cpu optimally which may cause drops on slow or busy systems. So it's more efficient to write small chuncks of audio, ideally a small multiple of the device block size. Unfortunately, libao doesn't expose the device block size, afaiu that's why mpd lets the user enter it manually. Using a small chuck like 1024, should make mpd work on most setups. I see no elegant fix that wouldn't involve libao api change or switching to another backend. -- Alexandre
UPDATE: games/chocolate-doom
I have had this sitting around for about a year, this patch cleans up this port by removing the need for the patches, instead opting to use some perl. it also fixes the port correctly ignoring python. I am unsure if the revision bump is required, as the resulting packing list is exactly the same. comments/ok? -ryan Index: Makefile === RCS file: /cvs/ports/games/chocolate-doom/Makefile,v retrieving revision 1.10 diff -u -p -u -r1.10 Makefile --- Makefile24 May 2011 00:11:48 - 1.10 +++ Makefile7 Mar 2012 04:11:26 - @@ -2,6 +2,7 @@ COMMENT = portable version of iD Software's Doom DISTNAME = chocolate-doom-1.6.0 +REVISION = 0 CATEGORIES = games x11 HOMEPAGE = http://www.chocolate-doom.org/ @@ -28,14 +29,23 @@ USE_GROFF = Yes USE_GMAKE =Yes CONFIGURE_STYLE = gnu -CONFIGURE_ARGS += --without-python -MAN_5= chocolate-doom.cfg default.cfg -MAN_6= chocolate-doom chocolate-server chocolate-setup +# we don't need to require python to build +CONFIGURE_ENV += HAVE_PYTHON=false + +MAN_5 =chocolate-doom.cfg default.cfg +MAN_6 =chocolate-doom chocolate-server chocolate-setup + +post-extract: + # set correct bin directory and data directory + @perl -pi -e "s,/games,/bin," ${WRKSRC}/src/Makefile.in + @perl -pi -e "s,/games,/bin," ${WRKSRC}/setup/Makefile.in + @perl -pi -e "s,/usr/share/games/doom,${TRUEPREFIX}/share/doom," \ + ${WRKSRC}/src/d_iwad.c post-install: # Data files get installed to this directory. - ${INSTALL_DATA_DIR} ${PREFIX}/share/games/doom/ + ${INSTALL_DATA_DIR} ${PREFIX}/share/doom/ .for m in ${MAN_5} ${INSTALL_MAN} ${WRKBUILD}/man/$m.5 ${PREFIX}/man/man5/ .endfor Index: patches/patch-setup_Makefile_in === RCS file: patches/patch-setup_Makefile_in diff -N patches/patch-setup_Makefile_in --- patches/patch-setup_Makefile_in 13 Jan 2011 10:30:49 - 1.3 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,12 +0,0 @@ -$OpenBSD: patch-setup_Makefile_in,v 1.3 2011/01/13 10:30:49 jasper Exp $ setup/Makefile.in.orig Sun Jan 2 10:17:16 2011 -+++ setup/Makefile.in Tue Jan 11 12:40:52 2011 -@@ -181,7 +181,7 @@ target_alias = @target_alias@ - top_build_prefix = @top_build_prefix@ - top_builddir = @top_builddir@ - top_srcdir = @top_srcdir@ --gamesdir = $(prefix)/games -+gamesdir = $(prefix)/bin - AM_CFLAGS = -I../textscreen -I../src @SDLMIXER_CFLAGS@ - SOURCE_FILES = \ - compatibility.c compatibility.h \ Index: patches/patch-src_Makefile_in === RCS file: patches/patch-src_Makefile_in diff -N patches/patch-src_Makefile_in --- patches/patch-src_Makefile_in 13 Jan 2011 10:30:49 - 1.3 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,12 +0,0 @@ -$OpenBSD: patch-src_Makefile_in,v 1.3 2011/01/13 10:30:49 jasper Exp $ src/Makefile.in.orig Sun Jan 2 10:17:17 2011 -+++ src/Makefile.inTue Jan 11 12:41:03 2011 -@@ -252,7 +252,7 @@ target_alias = @target_alias@ - top_build_prefix = @top_build_prefix@ - top_builddir = @top_builddir@ - top_srcdir = @top_srcdir@ --gamesdir = $(prefix)/games -+gamesdir = $(prefix)/bin - AM_CFLAGS = -I../opl -I../textscreen -I../pcsound @SDLMIXER_CFLAGS@ @SDLNET_CFLAGS@ - DEDSERV_FILES = \ - d_dedicated.c \ Index: pkg/MESSAGE === RCS file: /cvs/ports/games/chocolate-doom/pkg/MESSAGE,v retrieving revision 1.3 diff -u -p -u -r1.3 MESSAGE --- pkg/MESSAGE 24 May 2011 00:11:48 - 1.3 +++ pkg/MESSAGE 7 Mar 2012 04:11:26 - @@ -1,6 +1,7 @@ To play the game you will need an original Doom, Ultimate Doom, Doom II or Final Doom IWAD. Place the doom.wad, doom2.wad, plutonia.wad, -tnt.wad, or all of the above in ${PREFIX}/share/games/doom/ to play. +tnt.wad, or all of the above in ${PREFIX}/share/doom/ to play. + If multiple IWADs are installed, you may specify the one you want to play via the -iwad command-line parameter e.g. @@ -9,7 +10,3 @@ play via the -iwad command-line paramete The Shareware IWAD is available in the doomdata package. Run `chocolate-setup' to generate a configuration file to your liking. -If you would like to enjoy the classic in-game Doom music, you may -install audio/timidity and Chocolate Doom will automatically make use -of it at runtime, no recompilation required. Be sure that the music is -enabled within chocolate-setup. Index: pkg/PLIST === RCS file: /cvs/ports/games/chocolate-doom/pkg/PLIST,v retrieving revision 1.2 diff -u -p -u -r1.2 PLIST --- pkg/PLIST 24 May 2011 00:11:48 - 1.2 +++ pkg/PLIST 7 Mar 2012 04:11:26 - @@ -18,8 +18,7 @@ share/doc/cho
Re: sox-14.4.0 - mandoc glitches
Hi Jan, Jan Stary wrote on Mon, Mar 05, 2012 at 04:46:26PM +0100: > Attached is a port of audio/sox, bringing it to 14.4.0. > Tested on i386 and amd. > > make package complains: > > warning: file `man1/sox.1', around line 2667: table wider than line width > grotty: (man1/sox.1):47303: character above first line > discarded These are *not* mandoc(1) glitches, but groff error messages produced by grotty(1). > Indeed, sox.1 includes this table that is too wide. > > What do? Shall I persuade upstream to wrap the lines > to make mandoc happy? Or provide a patch? (That would > be a good excuse to finally learn the man(doc) syntax.) Please don't, this is a tricky case and not the right place to start learning man(7) and tbl(7). Don't try to talk to upstream about so difficult stuff; making good recommendations upstream requires thorough knowledge in this case, which you don't appear to have yet. These pages exhibit groff bugs, mandoc bugs *and* questionable formatting - to talk to upstream, you must be able to tell apart the three classes of problems, or you would cause more confusion than help. Since groff(1) actually wraps the tables better than mandoc(1), even though it complains, i suggest to keep USE_GROFF and simply ignore the groff warnings in this particular case. Yours, Ingo
Re: sox-14.4.0 update
On Mar 07 23:13:57, Ingo Schwarze wrote: > > warning: file `man1/sox.1', around line 2667: table wider than line width > > grotty: (man1/sox.1):47303: character above first line > > discarded > > These are *not* mandoc(1) glitches, but groff error messages > produced by grotty(1). Sorry; by this unfortunate wording, I didn't mean that these are glitches of mandoc itself of course. > > What do? Shall I persuade upstream to wrap the lines > > to make mandoc happy? Or provide a patch? (That would > > be a good excuse to finally learn the man(doc) syntax.) > > Please don't, this is a tricky case and not the right place > to start learning man(7) and tbl(7). Don't try to talk to > upstream about so difficult stuff; making good recommendations > upstream requires thorough knowledge in this case, which you > don't appear to have yet. Exactly; I was hoping to get an attention of someone man/mandoc/groff-savvy. > These pages exhibit groff bugs, > mandoc bugs *and* questionable formatting - to talk to upstream, > you must be able to tell apart the three classes of problems, > or you would cause more confusion than help. > Since groff(1) actually wraps the tables better than mandoc(1), > even though it complains, i suggest to keep USE_GROFF > and simply ignore the groff warnings in this particular case. OK. Thanks for the insight. So, appart from this: any comments to the port update? Jan
Re: UPDATE: QEMU 1.0.1
On Fri, Feb 24, 2012 at 8:02 PM, Brad Smith wrote: > Here is an update to QEMU 1.0.1. anyone tested this? come on, don't cry later. you know who you are. f.- > Index: Makefile > === > RCS file: /home/cvs/ports/emulators/qemu/Makefile,v > retrieving revision 1.84 > diff -u -p -r1.84 Makefile > --- Makefile 2 Feb 2012 22:07:33 - 1.84 > +++ Makefile 24 Feb 2012 20:01:07 - > @@ -1,14 +1,13 @@ > # $OpenBSD: Makefile,v 1.84 2012/02/02 22:07:33 sthen Exp $ > > -ONLY_FOR_ARCHS= amd64 i386 mips64 mips64el powerpc sparc sparc64 > +ONLY_FOR_ARCHS= amd64 arm hppa i386 mips64 mips64el powerpc sparc > sparc64 > +BROKEN-hppa= compiler bug with gcc 4.2 > > COMMENT= multi system emulator > > -DISTNAME= qemu-1.0 > -REVISION= 1 > +DISTNAME= qemu-1.0.1 > CATEGORIES= emulators > -MASTER_SITES= http://wiki.qemu.org/download/ \ > - http://comstyle.com/source/ > +MASTER_SITES= http://wiki.qemu.org/download/ > > HOMEPAGE= http://www.qemu.org/ > > Index: distinfo > === > RCS file: /home/cvs/ports/emulators/qemu/distinfo,v > retrieving revision 1.18 > diff -u -p -r1.18 distinfo > --- distinfo 12 Dec 2011 10:56:56 - 1.18 > +++ distinfo 17 Feb 2012 20:59:39 - > @@ -1,5 +1,5 @@ > -MD5 (qemu-1.0.tar.gz) = pks2BnoZFFEyOw0067RJVA== > -RMD160 (qemu-1.0.tar.gz) = OmCu9s/rumiWvbEsmVJdpUVhcv0= > -SHA1 (qemu-1.0.tar.gz) = fcsbNRZVTW2JnXSIzURNu3ch/O4= > -SHA256 (qemu-1.0.tar.gz) = R2dLfaVZ1eG0TMQBr5rFrZYtFOnu3hJWexPkuEGYlzc= > -SIZE (qemu-1.0.tar.gz) = 10848714 > +MD5 (qemu-1.0.1.tar.gz) = Xv0QkfAeO8Mb/ewnuO3rAA== > +RMD160 (qemu-1.0.1.tar.gz) = 3O80TxUOI4iAhxdo8vB8y26OzOc= > +SHA1 (qemu-1.0.1.tar.gz) = TQi1qDU4/NeyIr7G8cWE2o0SSXo= > +SHA256 (qemu-1.0.1.tar.gz) = GYkC4QeCUX9gfJ7Z5im153COo56zc+0+w/HIoWnZg3g= > +SIZE (qemu-1.0.1.tar.gz) = 10853005 > Index: patches/patch-configure > === > RCS file: /home/cvs/ports/emulators/qemu/patches/patch-configure,v > retrieving revision 1.21 > diff -u -p -r1.21 patch-configure > --- patches/patch-configure 12 Dec 2011 10:56:56 - 1.21 > +++ patches/patch-configure 17 Feb 2012 21:03:10 - > @@ -1,6 +1,6 @@ > $OpenBSD: patch-configure,v 1.21 2011/12/12 10:56:56 sthen Exp $ > configure.orig Mon Nov 28 17:22:15 2011 > -+++ configure Mon Nov 28 18:32:45 2011 > +--- configure.orig Fri Feb 17 14:45:39 2012 > configure Fri Feb 17 16:02:57 2012 > @@ -235,13 +235,11 @@ sdl_config="${SDL_CONFIG-${cross_prefix}sdl-config}" > > # default flags for all hosts > @@ -15,15 +15,6 @@ $OpenBSD: patch-configure,v 1.21 2011/12 > > # make source path absolute > source_path=`cd "$source_path"; pwd` > -@@ -1116,7 +1114,7 @@ fi > - > - if test "$pie" = ""; then > - case "$cpu-$targetos" in > -- i386-Linux|x86_64-Linux) > -+ i386-Linux|x86_64-Linux|i386-OpenBSD|x86_64-OpenBSD) > - ;; > - *) > - pie="no" > @@ -2684,8 +2682,9 @@ fi > # End of CC checks > # After here, no more $cc or $ld runs > Index: patches/patch-hw_e1000_c > === > RCS file: patches/patch-hw_e1000_c > diff -N patches/patch-hw_e1000_c > --- patches/patch-hw_e1000_c 2 Feb 2012 22:07:33 - 1.4 > +++ /dev/null 1 Jan 1970 00:00:00 - > @@ -1,26 +0,0 @@ > -$OpenBSD: patch-hw_e1000_c,v 1.4 2012/02/02 22:07:33 sthen Exp $ > - > -Bounds packet size against buffer size, otherwise we can write beyond > -the buffer and corrupt memory. CVE-2012-0029. > - > -http://git.qemu.org/?p=qemu.git;a=commitdiff;h=65f82df0d7a71ce1b10cd4c5ab0d176ac840 > - > hw/e1000.c.orig Thu Feb 2 20:07:37 2012 > -+++ hw/e1000.c Thu Feb 2 20:11:43 2012 > -@@ -466,6 +466,8 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *d > - bytes = split_size; > - if (tp->size + bytes > msh) > - bytes = msh - tp->size; > -+ > -+ bytes = MIN(sizeof(tp->data) - tp->size, bytes); > - pci_dma_read(&s->dev, addr, tp->data + tp->size, bytes); > - if ((sz = tp->size + bytes) >= hdr && tp->size < hdr) > - memmove(tp->header, tp->data, hdr); > -@@ -481,6 +483,7 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *d > - // context descriptor TSE is not set, while data descriptor TSE is > set > - DBGOUT(TXERR, "TCP segmentaion Error\n"); > - } else { > -+ split_size = MIN(sizeof(tp->data) - tp->size, split_size); > - pci_dma_read(&s->dev, addr, tp->data + tp->size, split_size); > - tp->size += split_size; > - } > Index: patches/patch-target-i386_translate_c > === > RCS file: patches/patch-target-i386_translate_c > diff -N patches/patch-target-i386_translate_c > ---
Re: UPDATE: QEMU 1.0.1
On Wed, Mar 07, 2012 at 10:39:25PM +, Federico Schwindt wrote: > On Fri, Feb 24, 2012 at 8:02 PM, Brad Smith wrote: > > Here is an update to QEMU 1.0.1. > > anyone tested this? > come on, don't cry later. you know who you are. > on amd64 it segfaults and generally doesn't work with rthreads. qemu-system-x86_64 -m 64 Floating point exception (core dumped) trace has no symbols, can look into it some more over the weekend
Re: UPDATE: QEMU 1.0.1
On 07/03/12 5:54 PM, Jonathan Gray wrote: On Wed, Mar 07, 2012 at 10:39:25PM +, Federico Schwindt wrote: On Fri, Feb 24, 2012 at 8:02 PM, Brad Smith wrote: Here is an update to QEMU 1.0.1. anyone tested this? come on, don't cry later. you know who you are. on amd64 it segfaults and generally doesn't work with rthreads. Strange. All I use is amd64 and it runs fine for me. If you build both 1.0 and 1.0.1 on the same system do both versions exhibit the same behavior? qemu-system-x86_64 -m 64 Floating point exception (core dumped) I have seen a crash like this with a particular test with VLC which is fully reproducible. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.