Fwd: [REL - head-i386-default][games/heretic] Failed for heretic-1.2_7 in build
Hi, can someone tell me what happend to netipx/ipx.h on CURRENT? Is there a replacement? === Building for heretic-1.2_7 gmake[1]: Entering directory `/wrkdirs/usr/ports/games/heretic/work/glheretic-1.2' cc -E -M -O2 -pipe -fno-strict-aliasing -DUNIX -DHAVE_USLEEP -DHAVE_MATH_H -DLINUX_MOUSE -DUDP_PROTOCOL -DI_GGI_HERETIC -DNEED_SHMGETEVENTBASE -D__NEWVGALIB__ -D__32BIT__ -DHOMEDIR='\/usr/local/share/heretic\' -I. -I.. -I/usr/local/include -I/usr/local/include -D__DOSOUND__ -DSNDSERV -Isoundclient -D__DOMUSIC__ -DMUSSERV -L/usr/local/lib *.c soundclient/i_sound.c soundclient/soundst.c soundclient/sounds.c m_misc.c \ graphics/i_x11.c .depend cc: warning: argument unused during compilation: '-L/usr/local/lib' i_ipx.c:23:10: fatal error: 'netipx/ipx.h' file not found #include netipx/ipx.h ^ 1 error generated. gmake[1]: *** [depx11] Error 1 gmake[1]: Leaving directory `/wrkdirs/usr/ports/games/heretic/work/glheretic-1.2' *** Error code 1 ---BeginMessage--- You are receiving this mail as a port that you maintain is failing to build on the FreeBSD package build server. Please investigate the failure and submit a PR to fix build. Maintainer: oli...@freebsd.org Last committer: oli...@freebsd.org Ident: $FreeBSD: head/games/heretic/Makefile 330725 2013-10-18 07:05:40Z oliver $ Log URL: http://beefy1.isc.freebsd.org/bulk/head-i386-default/2014-03-28_06h01m03s/logs/heretic-1.2_7.log Build URL: http://beefy1.isc.freebsd.org/bulk/head-i386-default/2014-03-28_06h01m03s Log: Building games/heretic build started at Fri Mar 28 17:08:12 UTC 2014 port directory: /usr/ports/games/heretic building for: FreeBSD head-i386-default-job-08 11.0-CURRENT FreeBSD 11.0-CURRENT r263175 i386 maintained by: oli...@freebsd.org Makefile ident: $FreeBSD: head/games/heretic/Makefile 330725 2013-10-18 07:05:40Z oliver $ Poudriere version: 3.1-pre ---Begin Environment--- UNAME_m=i386 UNAME_p=i386 OSVERSION=1100013 UNAME_v=FreeBSD 11.0-CURRENT r263175 UNAME_r=11.0-CURRENT BLOCKSIZE=K MAIL=/var/mail/root STATUS=1 MASTERMNT=/usr/local/poudriere/data/build/head-i386-default/ref PKG_EXT=txz tpid=42651 PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin POUDRIERE_BUILD_TYPE=bulk PKGNG=1 PKGNAME=heretic-1.2_7 PKG_DELETE=/usr/local/sbin/pkg-static delete -y -f PKG_ADD=/usr/local/sbin/pkg-static add PWD=/root MASTERNAME=head-i386-default USER=root HOME=/root POUDRIERE_VERSION=3.1-pre LOCALBASE=/usr/local PACKAGE_BUILDING=yes PKG_VERSION=/poudriere/pkg-static version PKG_BIN=/usr/local/sbin/pkg-static ---End Environment--- ---Begin OPTIONS List--- === The following configuration options are available for heretic-1.2_7: WAD=on: With shareware WAD Graphics Selections: you have to select exactly one of them X11=on: X11 (graphics) support FASTX11=off: Use FastX11 SDL=off: Simple Direct Media Layer support === Use 'make config' to modify these settings ---End OPTIONS List--- --CONFIGURE_ARGS-- --End CONFIGURE_ARGS-- --CONFIGURE_ENV-- TMPDIR=/tmp TMPDIR=/tmp MAKE=gmake SHELL=/bin/sh CONFIG_SHELL=/bin/sh --End CONFIGURE_ENV-- --MAKE_ENV-- PTHREAD_LIBS=-pthread TMPDIR=/tmp TMPDIR=/tmp SHELL=/bin/sh NO_LINT=YES PREFIX=/usr/local LOCALBASE=/usr/local LIBDIR=/usr/lib CC=cc CFLAGS=-O2 -pipe -fno-strict-aliasing CPP=cpp CPPFLAGS= LDFLAGS= CXX=c++ CXXFLAGS=-O2 -pipe -fno-strict-aliasing MANPREFIX=/usr/local BSD_INSTALL_PROGRAM=install -s -o root -g wheel -m 555 BSD_INSTALL_LIB=install -s -o root -g wheel -m 444 BSD_INSTALL_SCRIPT=install -o root -g wheel -m 555 BSD_INSTALL_DATA=install -o root -g wheel -m 444 BSD_INSTALL_MAN=install -o root -g wheel -m 444 --End MAKE_ENV-- --SUB_LIST-- PREFIX=/usr/local LOCALBASE=/usr/local DATADIR=/usr/local/share/heretic DOCSDIR=/usr/local/share/doc/heretic EXAMPLESDIR=/usr/local/share/examples/heretic WWWDIR=/usr/local/www/heretic ETCDIR=/usr/local/etc/heretic --End SUB_LIST-- ---Begin make.conf--- ARCH=i386 MACHINE=i386 MACHINE_ARCH=i386 USE_PACKAGE_DEPENDS=yes BATCH=yes WRKDIRPREFIX=/wrkdirs PORTSDIR=/usr/ports PACKAGES=/packages DISTDIR=/distfiles /usr/local/etc/poudriere.d/make.conf WITH_PKGNG=yes NO_RESTRICTED=yes DISABLE_MAKE_JOBS=poudriere ---End make.conf--- === Cleaning for heretic-1.2_7 ===phase: check-config === ===phase: pkg-depends === heretic-1.2_7 depends on file: /usr/local/sbin/pkg - not found ===Verifying install for /usr/local/sbin/pkg in /usr/ports/ports-mgmt/pkg === Installing existing package /packages/All/pkg-1.2.7.txz Installing pkg-1.2.7... done If you are upgrading from the old package format, first run: # pkg2ng === Returning to build of heretic-1.2_7 ===
Re: cvsup broken on amd64?
Adrian Chadd adr...@freebsd.org wrote: So I've taken a look at the csup source. [...] What about this patch: [...] Oliver, would you please try that? I have a problem with cvsup, not csup - Alexander mentioned a csup problem. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
Kostik Belousov kostik...@gmail.com wrote: Did you saw the message with the patch for tzcode I mailed to you ? Mmmh... no didn't reached my mailbox - can you resend it please? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
Mike Tancsa m...@sentex.net wrote: Just curious as to why you need cvsup and not instead use csup that is in the base ? I got used to it in the past 12 years? But this is not realy the question. If it is BROKEN it should be marked as BROKEN or there should be a statement that it will not work with FreeBSD 9 on at least amd64 or we will have other users complaining about the same at least when 9.0 RELEASE is out - right? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
gmirror: how to make your system reboot
Hi, shouldn't there be a failsafe to not be able to destroy the gmirror as long as it is still in use like mounted? 1. create a gmirror with n=1 disks 2. newfs the gmirror device 3. mount the gmirror device 4. remove all disks from the gmirror 5. system reboots (gmirror gone but still mounted) nudel# gmirror status nudel# gmirror label -b prefer test /dev/ada1p2 nudel# newfs /dev/mirror/test /dev/mirror/test: 4096.0MB (8388600 sectors) block size 32768, fragment size 4096 using 6 cylinder groups of 740.00MB, 23680 blks, 47360 inodes. super-block backups (for fsck -b #) at: 192, 1515712, 3031232, 4546752, 6062272, 7577792 nudel# mount /dev/mirror/test /mnt/tmp nudel# gmirror remove test ada1p2 reboot uname -a FreeBSD nudel.salatschuessel.net 9.0-BETA2 FreeBSD 9.0-BETA2 #0: Thu Sep 8 19:59:40 CEST 2011 olivl...@nudel.salatschuessel.net:/usr/obj/usr/src/sys/GENERIC amd64 I'm just having remote access right now to the system so I'm not able to provide any dumps but the system instantly reboots. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
Chris Rees cr...@freebsd.org wrote: On 9 September 2011 06:33, Oliver Lehmann lehm...@ans-netz.de wrote: I got used to it in the past 12 years? But this is not realy the question. If it is BROKEN it should be marked as BROKEN or there should be a statement that it will not work with FreeBSD 9 on at least amd64 or we will have other users complaining about the same at least when 9.0 RELEASE is out - right? The cvsup port is normally used now only for cvsupd, for which there is no csupd analog. As far as I know, and perhaps mux (CC'd) could confirm every feature present in cvsup is present in csup-- and it's a fair amount faster too. Ok, but this again is not the point of my email ;) This is not about just me. I know how to help me in that case. I want to prevent users facing the same problem and writing mails like my initial mail. I'm quiet sure that there are numerous users out there still using cvsup as client so they will start like me with cvsup on ther new instaled system. It would be better if they just would not be able to install cvsup if it will not run and we don't want it to run. I was also curious if it is only me where it fails on amd64 or if it is because it was compiled on an Atom 330 with some amd64 flags determined by the system which does not fit the Atom 330 (gcc 4.2 is older than the CPU design). With other words: If the support for cvsup on amd64 is dropped, it has to be marked as BROKEN/IGNORE/whatever. Otherwise it need to get fixed for 9.0? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
Kostik Belousov kostik...@gmail.com wrote: For start, you should provide the information what exactly is the instruction that caused the fault. Show the disassembly from gdb for the function that caused the fault. Ok, I'm trying. I recompiled cvsup for purpose with -DSTATIC How do I continue from the gdb output below to help? nudel# gdb GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd. (gdb) file ./client/FBSD_AMD64/cvsup Reading symbols from ./client/FBSD_AMD64/cvsup...done. (gdb) exec-file ./client/FBSD_AMD64/cvsup (gdb) set args -g /usr/share/examples/cvsup/9-supfile (gdb) run Starting program: /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile Connected to cvsup.de.FreeBSD.org Updating collection src-all/cvs Edit src/crypto/openssl/ssl/s3_lib.c Program received signal SIGSEGV, Segmentation fault. 0x004d24c6 in tzload () (gdb) bt #0 0x004d24c6 in tzload () #1 0x004d1f89 in tzparse () #2 0x004d2c27 in tzload () #3 0x004d2e36 in gmtload () #4 0x004eac15 in _once () #5 0x004d1c8b in gmtsub () #6 0x004d33e9 in gmtime () #7 0x004a3d4a in Date__FromTime (M3_CtKayy_t=1314794791, M3_Ab1PrR_z=0x7ed538, M3_D5xROs__result=0x934c08) at DateBsd.m3:31 #8 0x004387d7 in RCSDate__FromTime (M3_CtKayy_t=1314794791) at RCSDate.m3:54 #9 0x004467ba in RCSFile__Import (M3_Bd56fi_p=0xa74040, M3_Bd56fi_revNum=0x9f4828, M3_Bd56fi_author=0x763020, M3_Bd56fi_state=0x763040, M3_AcxOUs_logLines=12) at RCSFile.m3:413 #10 0x004077de in CheckoutUpdater__Update (M3_CTVCUv_self=0x9f49e0, M3_CzVV2w_sfr=0x7ff2e0, M3_Bd56fi_name=0x9f47e8, M3_AicXUJ_toAttic=0 '\0', M3_DsoVVS_proto=0x7f74a8, M3_AeHwgK_trace=0x7f8710, M3_EkTcCb_protoRd=0x9c98f8, M3_BxxOH1_wr=0x9f4ef8, M3_AQMw24_status=0x935f48) at CheckoutUpdater.m3:111 #11 0x00416ab4 in Updater__UpdateFile (M3_DBUV6k_self=0x7fee38, M3_CzVV2w_sfr=0x7ff2e0, M3_Bd56fi_name=0x9f47e8, M3_AicXUJ_toAttic=0 '\0', M3_DMoNGc_fup=0x9f49e0, M3_AicXUJ_isFixup=0 '\0') at Updater.m3:641 #12 0x004155ce in Updater__UpdateCollection (M3_DBUV6k_self=0x7fee38, M3_CzVV2w_sfr=0x7ff2e0, M3_AicXUJ_isFixups=0 '\0') at Updater.m3:458 #13 0x00412baf in Updater__UpdateBatch (M3_DBUV6k_self=0x7fee38, M3_AicXUJ_isFixups=0 '\0') at Updater.m3:151 #14 0x0041268a in Updater__Apply (M3_DBUV6k_self=0x7fee38) at Updater.m3:90 #15 0x0049d290 in ThreadPosix__DetermineContext (M3_AJWxb1_oldSP=0x7edfd0) at ThreadPosix.m3:1127 #16 0x0048d34d in RTCollector__LongAlloc (M3_Cwb5VA_dataSize=4337239, M3_Cwb5VA_dataAlignment=8577024, M3_AOtCKl_currentPtr=0x7f8, M3_AOtCKl_currentBoundary=0x76c8f8, M3_CCsHD8_currentPage=0x0, M3_CCsHD8_stack=0x0, M3_D8qd0n_allocMode=48 '0', M3_AicXUJ_pure=16 '\020') at RTCollector.m3:1530 #17 0x7fffc3c8 in ?? () #18 0x7fffd930 in ?? () #19 0x7fffda10 in ?? () #20 0x7fffd9f0 in ?? () #21 0x in ?? () #22 0x in ?? () #23 0x1fa0037f in ?? () #24 0x in ?? () #25 0x007f76c0 in ?? () #26 0x007f76c0 in ?? () #27 0x00492699 in RTMisc__Copy (M3_AJWxb1_src=Error accessing memory address 0xfffb: Bad address. ) at RTMisc.m3:19 Previous frame inner to this frame (corrupt stack?) (gdb) RTMisc.m3:19 is PROCEDURE Copy (src, dest: ADDRESS; len: INTEGER) = BEGIN EVAL Cstring.memcpy (dest, src, len); END Copy; ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
Kostik Belousov kostik...@gmail.com wrote: I do not know, I was curious about 'illegal instruction' signal, which would indicate a problem in the compilation environment. Now you get segmentation violation, that is usually caused by a bug in the program itself. running it outside gdb still results in an 'illegal instruction' error. Why it gets to segmentation violation inside gdb I just don't know. nudel# ./client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile Connected to cvsup.de.FreeBSD.org Updating collection src-all/cvs Edit src/crypto/openssl/ssl/s3_lib.c Illegal instruction (core dumped) nudel# gdb ./client/FBSD_AMD64/cvsup cvsup.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Core was generated by `cvsup'. Program terminated with signal 4, Illegal instruction. #0 0x004d24c6 in tzload () (gdb) bt #0 0x004d24c6 in tzload () #1 0x004d1f89 in tzparse () #2 0x004d2c27 in tzload () #3 0x004d2e36 in gmtload () #4 0x004eac15 in _once () #5 0x004d1c8b in gmtsub () #6 0x004d33e9 in gmtime () #7 0x004a3d4a in Date__FromTime (M3_CtKayy_t=1314794791, M3_Ab1PrR_z=0x7ed538, M3_D5xROs__result=0x934c08) at DateBsd.m3:31 #8 0x004387d7 in RCSDate__FromTime (M3_CtKayy_t=1314794791) at RCSDate.m3:54 #9 0x004467ba in RCSFile__Import (M3_Bd56fi_p=0x9d9008, M3_Bd56fi_revNum=0x9d87c8, M3_Bd56fi_author=0x763020, M3_Bd56fi_state=0x763040, M3_AcxOUs_logLines=12) at RCSFile.m3:413 #10 0x004077de in CheckoutUpdater__Update (M3_CTVCUv_self=0x9d8980, M3_CzVV2w_sfr=0x7ff2e0, M3_Bd56fi_name=0x9d8788, M3_AicXUJ_toAttic=0 '\0', M3_DsoVVS_proto=0x7f74a8, M3_AeHwgK_trace=0x7f8710, M3_EkTcCb_protoRd=0x9d05b8, M3_BxxOH1_wr=0x9d8e98, M3_AQMw24_status=0x935f48) at CheckoutUpdater.m3:111 #11 0x00416ab4 in Updater__UpdateFile (M3_DBUV6k_self=0x7fee38, M3_CzVV2w_sfr=0x7ff2e0, M3_Bd56fi_name=0x9d8788, M3_AicXUJ_toAttic=0 '\0', M3_DMoNGc_fup=0x9d8980, M3_AicXUJ_isFixup=0 '\0') at Updater.m3:641 #12 0x004155ce in Updater__UpdateCollection (M3_DBUV6k_self=0x7fee38, M3_CzVV2w_sfr=0x7ff2e0, M3_AicXUJ_isFixups=0 '\0') at Updater.m3:458 #13 0x00412baf in Updater__UpdateBatch (M3_DBUV6k_self=0x7fee38, M3_AicXUJ_isFixups=0 '\0') at Updater.m3:151 #14 0x0041268a in Updater__Apply (M3_DBUV6k_self=0x7fee38) at Updater.m3:90 #15 0x0049d290 in ThreadPosix__DetermineContext (M3_AJWxb1_oldSP=0x7edfd0) at ThreadPosix.m3:1127 #16 0x0048d34d in RTCollector__LongAlloc (M3_Cwb5VA_dataSize=4337239, M3_Cwb5VA_dataAlignment=8577024, M3_AOtCKl_currentPtr=0x7f8, M3_AOtCKl_currentBoundary=0x76c8f8, M3_CCsHD8_currentPage=0x0, M3_CCsHD8_stack=0x0, M3_D8qd0n_allocMode=144 '\220', M3_AicXUJ_pure=120 'x') at RTCollector.m3:1530 #17 0x7fffc428 in ?? () #18 0x7fffd990 in ?? () #19 0x7fffda78 in ?? () #20 0x7fffda58 in ?? () #21 0x in ?? () #22 0x in ?? () #23 0x1fa0037f in ?? () #24 0x in ?? () #25 0x007f76c0 in ?? () #26 0x007f76c0 in ?? () #27 0x00492699 in RTMisc__Copy (M3_AJWxb1_src=Cannot access memory at address 0xfffb ) at RTMisc.m3:19 Previous frame inner to this frame (corrupt stack?) (gdb) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
Kostik Belousov kostik...@gmail.com wrote: On Fri, Sep 09, 2011 at 04:19:42PM +0200, Oliver Lehmann wrote: (gdb) bt #0 0x004d24c6 in tzload () Try to do disas 0x4d24c6 0x4d24c6+30 from gdb prompt with the loaded core. (gdb) disas 0x4d24c6 0x4d24c6+30 Dump of assembler code from 0x4d24c6 to 0x4d24e4: 0x004d24c6 tzload+86: callq 0x4db370 issetugid 0x004d24cb tzload+91: test %eax,%eax 0x004d24cd tzload+93: jne0x4d25e0 tzload+368 0x004d24d3 tzload+99: movzbl (%rbx),%ebp 0x004d24d6 tzload+102:cmp$0x3a,%bpl 0x004d24da tzload+106:jne0x4d24e3 tzload+115 0x004d24dc tzload+108:add$0x1,%rbx 0x004d24e0 tzload+112:movzbl (%rbx),%ebp 0x004d24e3 tzload+115:cmp$0x2f,%bpl End of assembler dump. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
Kostik Belousov kostik...@gmail.com wrote: On Fri, Sep 09, 2011 at 05:55:13PM +0300, Kostik Belousov wrote: Ok, please do the following: run cvsup under the gdb. When SIGSEGV is raised, from the gdb prompt, do: 1. info registers $rsp 2. info program This should print you the pid of the process, then do 3. shell procstat -v pid (gdb) run Starting program: /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile Connected to cvsup.de.FreeBSD.org Updating collection src-all/cvs Edit src/crypto/openssl/ssl/s3_lib.c Program received signal SIGSEGV, Segmentation fault. 0x004d24c6 in tzload () (gdb) info registers $rsp rsp0x916c98 0x916c98 (gdb) info program Using the running image of child process 14704. Program stopped at 0x4d24c6. It stopped with signal SIGSEGV, Segmentation fault. (gdb) nudel# procstat -v 14704 PID STARTEND PRT RES PRES REF SHD FL TP PATH 14704 0x40 0x53f000 r-x 2190 1 0 C- vn /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup 14704 0x73f000 0x7bf000 rw- 1280 1 0 C- vn /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup 14704 0x7bf000 0x844000 rw- 1190 15 0 -- df 14704 0x844000 0x845000 r--10 15 0 -- df 14704 0x845000 0x867000 rw- 340 15 0 -- df 14704 0x867000 0x868000 r--10 15 0 -- df 14704 0x868000 0x88a000 rw- 340 15 0 -- df 14704 0x88a000 0x88b000 r--10 15 0 -- df 14704 0x88b000 0x8ad000 rw- 340 15 0 -- df 14704 0x8ad000 0x8ae000 r--10 15 0 -- df 14704 0x8ae000 0x8d rw- 340 15 0 -- df 14704 0x8d 0x8d1000 r--10 15 0 -- df 14704 0x8d1000 0x8f3000 rw- 340 15 0 -- df 14704 0x8f3000 0x8f4000 r--10 15 0 -- df 14704 0x8f4000 0x916000 rw- 340 15 0 -- df 14704 0x916000 0x917000 r--10 15 0 -- df 14704 0x917000 0xa87000 rw- 3440 15 0 -- df 147040x800740x800743000 rw-20 1 0 -- df 147040x8007430000x800751000 r-- 120 1 0 -- vn /mnt/files/FreeBSD/9.0/src/crypto/openssl/ssl/s3_lib.c 14704 0x7ffbf000 0x7ffdf000 rwx10 1 0 -- df 14704 0x7ffdf000 0x7000 rwx 110 1 0 -- df 14704 0x7000 0x8000 r-x10 47 0 CN ph nudel# Also, you might try to test my guesswork, by adding the following patch to lang/ezm3 and rebuilding it, then rebuilding cvsup port: [made a file below ezm3/files, cleaned the workdir, reinstalled it cleaned cvsup, rebuilt it] no change so far (gdb) run Starting program: /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile Connected to cvsup.de.FreeBSD.org Updating collection src-all/cvs Edit src/crypto/openssl/ssl/s3_lib.c Program received signal SIGSEGV, Segmentation fault. 0x004d24c6 in tzload () (gdb) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
Kostik Belousov kostik...@gmail.com wrote: On Fri, Sep 09, 2011 at 06:20:57PM +0200, Oliver Lehmann wrote: (gdb) run Starting program: /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile Connected to cvsup.de.FreeBSD.org Updating collection src-all/cvs Edit src/crypto/openssl/ssl/s3_lib.c Program received signal SIGSEGV, Segmentation fault. 0x004d24c6 in tzload () (gdb) I need the same information from the gdb for this crash too, with cvsup rebuilt using the patched ezm3. Mh... looks like the same output to me (gdb) info registers $rsp rsp0x916c98 0x916c98 (gdb) info program Using the running image of child process 62191. Program stopped at 0x4d24c6. It stopped with signal SIGSEGV, Segmentation fault. (gdb) nudel# procstat -v 62191 PID STARTEND PRT RES PRES REF SHD FL TP PATH 62191 0x40 0x53f000 r-x 2180 1 0 C- vn /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup 62191 0x73f000 0x7bf000 rw- 930 1 0 C- vn /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup 62191 0x7bf000 0x844000 rw- 1190 15 0 -- df 62191 0x844000 0x845000 r--10 15 0 -- df 62191 0x845000 0x867000 rw- 340 15 0 -- df 62191 0x867000 0x868000 r--10 15 0 -- df 62191 0x868000 0x88a000 rw- 340 15 0 -- df 62191 0x88a000 0x88b000 r--10 15 0 -- df 62191 0x88b000 0x8ad000 rw- 340 15 0 -- df 62191 0x8ad000 0x8ae000 r--10 15 0 -- df 62191 0x8ae000 0x8d rw- 340 15 0 -- df 62191 0x8d 0x8d1000 r--10 15 0 -- df 62191 0x8d1000 0x8f3000 rw- 340 15 0 -- df 62191 0x8f3000 0x8f4000 r--10 15 0 -- df 62191 0x8f4000 0x916000 rw- 340 15 0 -- df 62191 0x916000 0x917000 r--10 15 0 -- df 62191 0x917000 0xa87000 rw- 3440 15 0 -- df 621910x800740x800743000 rw-20 1 0 -- df 621910x8007430000x800751000 r-- 120 1 0 -- vn /mnt/files/FreeBSD/9.0/src/crypto/openssl/ssl/s3_lib.c 62191 0x7ffbf000 0x7ffdf000 rwx10 1 0 -- df 62191 0x7ffdf000 0x7000 rwx 110 1 0 -- df 62191 0x7000 0x8000 r-x10 50 0 CN ph nudel# ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
cvsup broken on amd64?
Hi,
I have an Atom 330 with 9.0-BETA2/amd64 installed.
I did a pkg_add -r cvsup-without-gui at first after installation.
Using cvsup, resulted in a core dump (illegal instruction).
I then removed all ports, and installed cvsup-without-gui from source.
Started cvsup... core dump again.
I then got the cvsup binary from a FreeBSD 8 i386 system, installed
compat8x and also copied the missing libutil.so.8 from FreeBSD/i386
and cvsuped the source (8.2-STABLE i386 cvsup worked).
Then I rebuilt world, kernel (removed all debugging options from GENERIC).
Then I removed all ports once more and reinstalled cvsup-without-gui
from ports once more.
And now again...
nudel# cvsup -g /usr/share/examples/cvsup/9-supfile
Connected to cvsup.de.FreeBSD.org
Updating collection src-all/cvs
Edit src/crypto/openssl/ssl/s3_lib.c
Illegal instruction (core dumped)
nudel# gdb /usr/local/bin/cvsup cvsup.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...(no debugging
symbols found)...
Core was generated by `cvsup'.
Program terminated with signal 4, Illegal instruction.
Reading symbols from /lib/libz.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libz.so.6
Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols
found)...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x000800e12359 in gmtime_r () from /lib/libc.so.7
(gdb) bt
#0 0x000800e12359 in gmtime_r () from /lib/libc.so.7
#1 0x000800e11dde in gmtime_r () from /lib/libc.so.7
#2 0x000800e12ab4 in gmtime_r () from /lib/libc.so.7
#3 0x000800e12cc8 in gmtime_r () from /lib/libc.so.7
#4 0x000800e30928 in sysctl () from /lib/libc.so.7
#5 0x000800e11a9f in timegm () from /lib/libc.so.7
#6 0x000800e13346 in gmtime () from /lib/libc.so.7
#7 0x004a63aa in calloc ()
#8 0x0043ae3b in ?? ()
#9 0x00448e1e in ?? ()
#10 0x00409e42 in ?? ()
#11 0x00419118 in ?? ()
#12 0x00417c32 in ?? ()
#13 0x00415213 in ?? ()
#14 0x00414cee in ?? ()
#15 0x0049f8f0 in calloc ()
#16 0x0048f9ad in fnmatch ()
#17 0x7fffc498 in ?? ()
#18 0x7fffda00 in ?? ()
#19 0x7fffdaf8 in ?? ()
#20 0x7fffdad8 in ?? ()
#21 0x in ?? ()
#22 0x in ?? ()
#23 0x1fa0037f in ?? ()
#24 0x in ?? ()
#25 0x0074c6c0 in ?? ()
#26 0x0074c6c0 in ?? ()
#27 0x00494cf9 in fnmatch ()
Previous frame inner to this frame (corrupt stack?)
(gdb)
cat /etc/make.conf
X_WINDOW_SYSTEM=xorg
WRKDIRPREFIX=/usr/obj/${MACHINE_ARCH}
head -7 /usr/share/examples/cvsup/9-supfile
*default host=cvsup.de.FreeBSD.org
*default base=/mnt/files/FreeBSD/9.0
*default prefix=/mnt/files/FreeBSD/9.0
*default release=cvs tag=.
*default delete use-rel-suffix
*default compress
src-all
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Where did the 9.0 BETA1 images go?
Hi, I'm about to replace some harddisks in my fileserver and plan to reinstall FreeBSD this weekend on it. I'll also switch from i386 to amd64 as the hardware the system runs on has changed last year as well. I don't want to install 8 again as I don't want to reinstall / upgrade 8 - 9 later when 9 is finally released. I did this as well when 8 was about to be released and used images from some japanese snapshot server back those days (as far as I can remember). I now saw announces from august, that some BETA1 images of 9.0 where released and wanted to use those: http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026181.html http://www.freebsdnews.net/2011/08/01/freebsd-9-beta1-testing/ But sadly they seem to be gone from the FTP servers. The system has beside its harddisks only a floppy drive (no space for a CD-ROM) so I would need the memstick image Any idea where I could get FreeBSD-9.0-BETA1-amd64-memstick.img from? I'd like to do the upgrade this weekend as the system runs actually a degraded gmirror (2 already broken drives and no spare drive left...) and who knows when the last remaining drive fails as well... Greetings, Oliver ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Floppy drive not found by RELENG_5_1
Ok,
to get back a working and floppydrive detection on FreeBSD/alpha:
What's about the attached patch?
I moved in fd_probe()
if (fd-type == FDT_NONE (fd-fdu == 0 || fd-fdu == 1)) {
out of the
#if defined(__i386__) || defined(__amd64__)
block and created an #else section (like it was in RELENG_4) where the
fd-type is set to 144 by force.
Why not just re-create the #else block? Why moving the if statement out of
the #ifdef block? Doing it that way, it's still possible to set
hint.fd.0.flags for example to 3 (720KB Floppy), and only set the 1.44M
type as a fallback when flags is NULL (FDT_NONE) which means in that case,
hint.fd.0.flags isn't defined. (Because we don't query the BIOS as we do
it for x86 to get the info what kind of floppy is attached to fdc.)
Greetings, Oliver
--
Oliver Lehmann
@home: [EMAIL PROTECTED]
@office: [EMAIL PROTECTED]
@www: http://www.pofo.de/ | http://wishlist.ans-netz.de/
src::sys::isa::fd.c
Description: Binary data
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
