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: Compiling BETA2 with clang fails
On 2011-09-09 05:45, Volodymyr Kostyrko wrote:
...
Like cleaning /usr/obj/ and then buildworld with clang but with
-march=athlon-xp instead of -march=native.
As the problem does not seem to be in your current world but rather in
the bootstrap clang compiled with -march=native, you should not have
to {build,install}world with gcc first.
I cleaned /usr/obj and made a build with -march=athlon-xp. Same errors.
I did a few test builds with 'high' CPU values for -march, and I ran
into various problems. I'd discourage the use of -march=native for now,
at least with clang. It will take some time to investigate.
...
# nm -D /usr/obj/usr/src/tmp/usr/lib/libc.so
...
That's the problem - libraries miss most symbols.
This is why I still think you have the stdin/out/err problem, in some
way. Can you please check /usr/obj/usr/src/lib/libc/Version.map? It
should have about 2775 lines, otherwise your libc build is busted.
___
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?
On 9 September 2011 06:33, Oliver Lehmann lehm...@ans-netz.de wrote: 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? 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. Of course, cvsup could probably do with fixing, but for now csup is literally a drop-in replacement; it'll read all your supfiles too. Chris ___ 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?
On Fri, Sep 09, 2011 at 11:30:46AM +0200, Oliver Lehmann wrote: 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? 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. pgpNzY8kGtDDW.pgp Description: PGP signature
Re: RELENG_8 / mpt / zpool Errors
On Sep 8, 2011 12:33 AM, Tim Gustafson t...@soe.ucsc.edu wrote: Advice is: Use -STABLE and not -RELEASE Upgrade firmware Avoid port multipliers As I'm using cheap 4K green drives I had to use wdidle3.exe to fix the 8 second head parking and I also had to use gnop to force my ZFS pool to use 4K transfers. We're already using -STABLE; we update to RELENG_8 periodically. LSI's web site is a little bizarre when it comes to their downloads section. I searched their drivers section for my specific model number and got a bunch of firmware upgrades for other cards with different port configurations. We can't avoid port multipliers. Nobody makes a 32-port SAS/SATA controller. And anyhow, the hardware is already purchased so I need to figure out how to make it work. :) WDC's web site says that the wdidle3.exe utility you suggested is not for this drive; the site says it's only for WD1000FYPS-01ZKB0, WD7500AYPS-01ZKB0, and WD7501AYPS-01ZKB0. I'm not sure what you mean about using gnop to force 4K transfers. The mps driver has problems with the LSI SAS2008 when using port multipliers (which are in the enclosures). If you go to the previous SAS 3G version of that chip I think you'll be OK. When you say go to the previous SAS 3G version of that chip, do you mean buy an older version of that controller card? Or are you talking about downgrading, rather than upgrading, the firmware? There are newer LSI cards out there as well. Would upgrading the card help any? The LSI SAS 9205-8e seems to be a workable solution, and not too expensive. Tim, The reference to wdidle3 is specific to my situation with the home user grade WDC20EARS drive. You have server class drives but are affected by a problem with the FreeBSD driver with port multipliers. Easiest solutions to your situation are: A) Don't use FreeBSD B) Switch to hardware that works with FreeBSD (the SAS 3G version of that LSI HBA chip) Harder solutions are: A) Fix the driver ___ 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: Shared libraries version bump?
Since I have plenty of disk space on the new computer, I was planning to keep the BETA1 partition and install BETA2 to a separate partition. FreeBSD 9.0 BETA1 is the first hard drive OS on the new computer, not counting the nonworking NetBSD installation; I am not upgrading from 8.x. Since I have nothing worth saving on my nonworking installation of NetBSD-current, I can delete those partitions and make a FreeBSD partition for BETA2. I can keep the already existing /home partition. That way, I already have the ports tree, can run 'portsnap fetch update', won't have to redownload the distfiles on those ports that haven't been updated since then. I will have no immediate need for portupgrade or portmaster but will in the near future. I will have the BETA1 to fall back on in the interim before BETA2 installation becomes more self-sufficient, for web browsing including online financial affairs. Tom ___ 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: RELENG_8 / mpt / zpool Errors
On 9 September 2011 18:32, Matt Thyer matt.th...@gmail.com wrote: Harder solutions are: A) Fix the driver .. which is the only way FreeBSD improves, so. You choose. :) Also: A1) Post lots of debugging info to the list, be very friendly and helpful, see if any developers are willing to help you figure and fix it A2) If not, look at paying a small (say $1k) bounty to get it fixed. :) Adrian ___ 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: RELENG_8 / mpt / zpool Errors
On Sep 9, 2011 8:38 PM, Adrian Chadd adr...@freebsd.org wrote: On 9 September 2011 18:32, Matt Thyer matt.th...@gmail.com wrote: Harder solutions are: A) Fix the driver .. which is the only way FreeBSD improves, so. You choose. :) Also: A1) Post lots of debugging info to the list, be very friendly and helpful, see if any developers are willing to help you figure and fix it A2) If not, look at paying a small (say $1k) bounty to get it fixed. :) Adrian Yes, Helping to fix the driver is a thing that Tim is in the unusual situation to be able to do as he has access to the affected hardware. However, if paid work demands a quicker solution, I'm hoping they'll fund use of the SAS 3G card (cheap) whilst allowing Tim to occasionally work with the SAS 6G card to work on a final solution! Ideally we don't want Tim to have to move away from FreeBSD. We want him to help fix the driver. ___ 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?
On Fri, Sep 09, 2011 at 01:47:37PM +0200, Oliver Lehmann wrote: 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? 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. 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; pgp2QJtgOP9FU.pgp Description: PGP signature
Re: NFS server File Handle changing upon reboot
On Thursday, September 08, 2011 9:45:17 am Rick Macklem wrote: Hiroki Sato spotted a problem with NFS server file handles (FHs) changing after a server upgrade, because the exported file system type(s) get configured in a different order and, therefore, assigned different vfs_typenum values. A patch has been worked out, after discussion with various folks, that uses a hash function to assign the vfs_typenum values. This fixes the problem, except it has one downside: - The first server boot after the patch has been applied will result in FHs changing and, as such, NFS clients will need to remount after this upgrade. So, finally to why I am posting, which is to ask for opinions on what should be done with this patch? 1 - Ask re@ for permission to commit this to -current for 9.0, so that the FH change happens at the 8.X-9.0 upgrade. (It does seem that if some variant of this should go in, then a major release seems like the correct time to do it?) 2 - Add a loader.conf variable to the patch, which would allow a sysadmin to flip the switch when it is convenient for them. (I do have a concern that this might just cause more confusion w.r.t. when/what needs to be done.) 3 - Do #2, for 8.X and make the patch the default for 9.0. 4 - Forget the patch and leave things the way the are now. Well, I would do 3a: Generate the patch in 2 and merge it to 8, but in 8 have the default be the existing behavior. In 10 you can remove the switch altogether. -- John Baldwin ___ 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: Compiling BETA2 with clang fails
09.09.2011 11:52, Dimitry Andric wrote:
I did a few test builds with 'high' CPU values for -march, and I ran
into various problems. I'd discourage the use of -march=native for now,
at least with clang. It will take some time to investigate.
Hey, I already posted results of build without -march at all.
...
# nm -D /usr/obj/usr/src/tmp/usr/lib/libc.so
...
That's the problem - libraries miss most symbols.
This is why I still think you have the stdin/out/err problem, in some
way. Can you please check /usr/obj/usr/src/lib/libc/Version.map? It
should have about 2775 lines, otherwise your libc build is busted.
This build was without ccache and CPUTYPE or march. Busted:
=== Version.map ===
FBSD_1.0 {
};
FBSD_1.1 {
} FBSD_1.0;
FBSD_1.2 {
} FBSD_1.1;
FBSDprivate_1.0 {
local:
*;
} FBSD_1.2;
=== Version.map ===
Smoking logs gives this:
cat /usr/src/lib/libc/i386/Symbol.map /usr/src/lib/libc/db/Symbol.map
/usr/src/lib/libc/compat-43/Symbol.map
/usr/src/lib/libc/gdtoa/Symbol.map /usr/src/lib/libc/gen/Symbol.map
/usr/src/lib/libc/gmon/Symbol.map /usr/src/lib/libc/inet/Symbol.map
/usr/src/lib/libc/locale/Symbol.map /usr/src/lib/libc/nameser/Symbol.map
/usr/src/lib/libc/net/Symbol.map /usr/src/lib/libc/nls/Symbol.map
/usr/src/lib/libc/posix1e/Symbol.map /usr/src/lib/libc/quad/Symbol.map
/usr/src/lib/libc/regex/Symbol.map /usr/src/lib/libc/resolv/Symbol.map
/usr/src/lib/libc/stdio/Symbol.map /usr/src/lib/libc/stdlib/Symbol.map
/usr/src/lib/libc/stdtime/Symbol.map /usr/src/lib/libc/string/Symbol.map
/usr/src/lib/libc/sys/Symbol.map /usr/src/lib/libc/rpc/Symbol.map
/usr/src/lib/libc/uuid/Symbol.map /usr/src/lib/libc/xdr/Symbol.map
/usr/src/lib/libc/yp/Symbol.map | clang++ - - | awk -v
vfile=/usr/src/lib/libc/Versions.def -f
/usr/src/share/mk/version_gen.awk Version.map
clang++: error: -E or -x required when input is from standard input
clang++: error: -E or -x required when input is from standard input
And this is purely my fault because I incorrectly redefined CPP.
Great thanks to everyone. I'll try to remember what I have learned this
week.
--
Sphinx of black quartz judge my vow.
___
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?
On 09/09/11 01:33, Oliver Lehmann wrote: Mike Tancsam...@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? I'm also using cvsup again, due to a problem I had with csup back in February 2011 http://www.mail-archive.com/freebsd-stable@freebsd.org/msg114813.html . I didn't open a PR; I was under some time pressure and cvsup worked. - Richard -- Richard Kuhns r...@wintek.com My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: Need a README to explain items in download directory
(Sorry, lost track of quoting) The style is okay, but I would suggest rearranging the order to demphasize the DVD with its quickly-obsolete packages. Media type is very important and should probably be mentioned first. FreeBSD-8.2-RELEASE-i386-disc1.iso- CD: Installer, FreeBSD OS FreeBSD-8.2-RELEASE-i386-memstick.img - USB: Installer, FreeBSD OS, image for memory sticks FreeBSD-8.2-RELEASE-i386-bootonly.iso - CD: Installer, installs from network FreeBSD-8.2-RELEASE-i386-dvd1.iso.xz - DVD: Installer, FreeBSD OS, many pre-compiled packages (large file) FreeBSD-8.2-RELEASE-i386-livefs.iso - CD: FreeBSD live CD for repairs For more information, consult the FreeBSD Handbook: http://www.freebsd.org/doc/handbook/install-diff-media.html Anybody downloading the Bootonly image should already know what they're getting into. A lot of the people who needlessly download the DVD would be better off with bootonly. It's not any harder to install. ___ 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
K3b cannot burn DVD-R .iso image
uname -a: FreeBSD shuttle0.lan 9.0-BETA2 FreeBSD 9.0-BETA2 #1: Wed Sep 7 09:37:08 WEST 2011 net...@shuttle0.lan:/usr/obj/usr/src/sys/GALILEO amd64 dmesg debug: http://pastie.org/private/e1cnddkdybtnjdltariq3g camcontrol devlist HL-DT-ST DVDRAM GH22NS40 NL02at scbus2 target 0 lun 0 (pass0,cd0) Cheers! -- netSys-- http://www.byteandbit.info ATI/AMD Graphics drivers to FreeBSD online petition http://www.petitiononline.com/amdgrbsd/petition.html Please help us and help you or others firm! ___ 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?
On Fri, Sep 09, 2011 at 04:19:42PM +0200, Oliver Lehmann wrote: 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 () Try to do disas 0x4d24c6 0x4d24c6+30 from gdb prompt with the loaded core. pgpz3aHMHVkEn.pgp Description: PGP signature
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?
On Fri, Sep 09, 2011 at 04:34:54PM +0200, Oliver Lehmann wrote: 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. 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 I suspect that modula 3 system uses the kind of green threads, and the default thread stack size is simply too small for amd64. This is consistent with SIGILL when running standalone, but SIGSEGV under debugger. pgpNkNsofaEKD.pgp Description: PGP signature
Re: cvsup broken on amd64?
On Fri, Sep 09, 2011 at 05:55:13PM +0300, Kostik Belousov wrote:
On Fri, Sep 09, 2011 at 04:34:54PM +0200, Oliver Lehmann wrote:
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.
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
I suspect that modula 3 system uses the kind of green threads, and
the default thread stack size is simply too small for amd64. This is
consistent with SIGILL when running standalone, but SIGSEGV under
debugger.
Also, you might try to test my guesswork, by adding the following
patch to lang/ezm3 and rebuilding it, then rebuilding cvsup port:
--- libs/m3core/src/thread/POSIX/ThreadPosix.m3.orig2011-09-09
17:58:12.867431639 +0300
+++ libs/m3core/src/thread/POSIX/ThreadPosix.m3 2011-09-09 17:58:30.380428486
+0300
@@ -180,7 +180,7 @@
pausedThreads : T;
selected_interval:= UTime{0, 100 * 1000};
- defaultStackSize := 3000;
+ defaultStackSize := 1;
stack_grows_down: BOOLEAN;
pgpf3Qfd6XtRX.pgp
Description: PGP signature
Re: Shared libraries version bump?
On Fri, Sep 9, 2011 at 4:06 AM, Thomas Mueller mueller6...@bellsouth.net wrote: Since I have plenty of disk space on the new computer, I was planning to keep the BETA1 partition and install BETA2 to a separate partition. FreeBSD 9.0 BETA1 is the first hard drive OS on the new computer, not counting the nonworking NetBSD installation; I am not upgrading from 8.x. Since I have nothing worth saving on my nonworking installation of NetBSD-current, I can delete those partitions and make a FreeBSD partition for BETA2. I can keep the already existing /home partition. That way, I already have the ports tree, can run 'portsnap fetch update', won't have to redownload the distfiles on those ports that haven't been updated since then. I will have no immediate need for portupgrade or portmaster but will in the near future. I will have the BETA1 to fall back on in the interim before BETA2 installation becomes more self-sufficient, for web browsing including online financial affairs. Thanks, but I've already pulled t trigger and am running 9.0-Beta2 (current). Works fine. I will need to re-build some ports. Probably will re-install all of them. I did hit a bug in the upgrade that I will report in a new thread, but it went pretty well. Thanks to all of the suggestions. -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6...@gmail.com ___ 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: RELENG_8 / mpt / zpool Errors
If not, look at paying a small (say $1k) bounty to get it fixed. :) Unfortunately, our budget situation would not allow this sort of thing right now. :\ Buying hardware is a lot easier than paying for something like this. Helping to fix the driver is a thing that Tim is in the unusual situation to be able to do as he has access to the affected hardware. However, if paid work demands a quicker solution, I'm hoping they'll fund use of the SAS 3G card (cheap) whilst allowing Tim to occasionally work with the SAS 6G card to work on a final solution! I can most likely switch to a different card. Just to make sure I get the right one, do you have a part number of the card that you are recommending? As I mentioned earlier, I was looking around on the LSI site and they have lots of options, but none with a port configuration that I need (2 external ports only). I'd be happy to help with debugging the 6G problem. I could probably install that card into another box and give some developers access to it, but I'd have to rustle up some disks and port expanders to make it a fair test. Ideally we don't want Tim to have to move away from FreeBSD. We want him to help fix the driver. I've been a FreeBSD man since 2.2.5, and I won't be switching off any time soon. :) We have several other FreeBSD servers at this point - 5 to be exact, plus my workstation, and there's talk of adopting it more because of Soracle's abandonment of various projects. We're primarily using them for bulk storage - most of them are ZFS with multi-terabyte ZFS file systems - but I've got one that's a workhorse for web and other such things. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Tim Gustafsont...@soe.ucsc.edu Baskin School of Engineering 831-459-5354 UC Santa Cruz Baskin Engineering 317B -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ___ 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: Need a README to explain items in download directory
On Fri, Sep 9, 2011 at 6:30 AM, Warren Block wbl...@wonkity.com wrote: (Sorry, lost track of quoting) The style is okay, but I would suggest rearranging the order to demphasize the DVD with its quickly-obsolete packages. Media type is very important and should probably be mentioned first. FreeBSD-8.2-RELEASE-i386-disc1.iso - CD: Installer, FreeBSD OS FreeBSD-8.2-RELEASE-i386-memstick.img - USB: Installer, FreeBSD OS, image for memory sticks FreeBSD-8.2-RELEASE-i386-bootonly.iso - CD: Installer, installs from network FreeBSD-8.2-RELEASE-i386-dvd1.iso.xz - DVD: Installer, FreeBSD OS, many pre-compiled packages (large file) FreeBSD-8.2-RELEASE-i386-livefs.iso - CD: FreeBSD live CD for repairs For more information, consult the FreeBSD Handbook: http://www.freebsd.org/doc/handbook/install-diff-media.html Anybody downloading the Bootonly image should already know what they're getting into. A lot of the people who needlessly download the DVD would be better off with bootonly. It's not any harder to install. Not necessarily true. Many people that pull down the DVD image may want the packages that correspond with the release version of the OS, for various reasons ;).. Thanks, -Garrett ___ 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?
On Fri, Sep 09, 2011 at 06:20:57PM +0200, Oliver Lehmann wrote: 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 %rsp value is 0x917000, so this is definitely stack overflow. 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) I need the same information from the gdb for this crash too, with cvsup rebuilt using the patched ezm3. pgpjB33Vzig07.pgp Description: PGP signature
Re: Compiling BETA2 with clang fails
On 2011-09-09 14:39, Volodymyr Kostyrko wrote:
09.09.2011 11:52, Dimitry Andric wrote:
...
This is why I still think you have the stdin/out/err problem, in some
way. Can you please check /usr/obj/usr/src/lib/libc/Version.map? It
should have about 2775 lines, otherwise your libc build is busted.
This build was without ccache and CPUTYPE or march. Busted:
=== Version.map ===
FBSD_1.0 {
};
FBSD_1.1 {
} FBSD_1.0;
FBSD_1.2 {
} FBSD_1.1;
FBSDprivate_1.0 {
local:
*;
} FBSD_1.2;
=== Version.map ===
Smoking logs gives this:
cat /usr/src/lib/libc/i386/Symbol.map /usr/src/lib/libc/db/Symbol.map
/usr/src/lib/libc/compat-43/Symbol.map
/usr/src/lib/libc/gdtoa/Symbol.map /usr/src/lib/libc/gen/Symbol.map
/usr/src/lib/libc/gmon/Symbol.map /usr/src/lib/libc/inet/Symbol.map
/usr/src/lib/libc/locale/Symbol.map /usr/src/lib/libc/nameser/Symbol.map
/usr/src/lib/libc/net/Symbol.map /usr/src/lib/libc/nls/Symbol.map
/usr/src/lib/libc/posix1e/Symbol.map /usr/src/lib/libc/quad/Symbol.map
/usr/src/lib/libc/regex/Symbol.map /usr/src/lib/libc/resolv/Symbol.map
/usr/src/lib/libc/stdio/Symbol.map /usr/src/lib/libc/stdlib/Symbol.map
/usr/src/lib/libc/stdtime/Symbol.map /usr/src/lib/libc/string/Symbol.map
/usr/src/lib/libc/sys/Symbol.map /usr/src/lib/libc/rpc/Symbol.map
/usr/src/lib/libc/uuid/Symbol.map /usr/src/lib/libc/xdr/Symbol.map
/usr/src/lib/libc/yp/Symbol.map | clang++ - - | awk -v
vfile=/usr/src/lib/libc/Versions.def -f
/usr/src/share/mk/version_gen.awk Version.map
clang++: error: -E or -x required when input is from standard input
clang++: error: -E or -x required when input is from standard input
And this is purely my fault because I incorrectly redefined CPP.
Well, it looks like there is not much error handling or sanity checking
in the map generation process. If anything fails in there, or if the
output is dodgy, the libc build should simply abort, IMHO.
Your problem also reminds me that we need a /usr/bin/clang-cpp hardlink,
I will try to get that into 9.0. Thanks. :)
___
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
Re: cvsup broken on amd64?
On 09/08/11 14:52, b. f. wrote: 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... It may be broken -- I seem to recall some earlier complaints about problems on one of the list. But is there a reason why you are attempting to use it, when /usr/bin/csup is available, and is generally thought to be superior? b. ___ 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 Does cvsup work for anyone? At what point should cvsup just be a symlink to csup? ___ 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
Failure upgrading from 8-stable to current (9.0-Beta2)
Last night I upgraded my laptop from 8-stable (Sept. 7) to head. I
almost worked, but I
did hit an issue during the installworld phase. The problem was when the make in
/usr/src/share/zoneinfo tried to run tzsetup that dialog failed to run
with the error:
/tmp/install.xtvA5ik4/libdialog.so.7: Undefined symbol _nc_wacs
I simply deleted the line tzsetup $${optC} -r; \ at line 76 of the
Makefile and re-ran the
installworld. Everything worked from that point. I then compared
/etc/localtime with
/usr/share/zoneinfo/America/Los_Angeles and they were identical, so I
already had
a localtime file built with the new zic.
After the installworld completed, I tried running tzsetup and dialog
ran fine, so I have
no idea why the failure during the instsallworld. I did a search and
found a very similar
report in questions@. The only difference I saw was that my error was
not prefaced
with /libexec/ld-elf.so.1: and, of course, the random string.
http://lists.freebsd.org/pipermail/freebsd-questions/2011-July/232421.html
Any ideas what might be happening here? It is a bit disconcerting as
userland is half
current and half stable when it dies. It would be very awkward to have
to back out and
may people updating to 9.0 after release might not know how to work around it.
--
R. Kevin Oberman, Network Engineer - Retired
E-mail: kob6...@gmail.com
___
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: Failure upgrading from 8-stable to current (9.0-Beta2)
On Fri, Sep 9, 2011 at 11:17 AM, Kevin Oberman kob6...@gmail.com wrote:
Last night I upgraded my laptop from 8-stable (Sept. 7) to head. I
almost worked, but I
did hit an issue during the installworld phase. The problem was when the make
in
/usr/src/share/zoneinfo tried to run tzsetup that dialog failed to run
with the error:
/tmp/install.xtvA5ik4/libdialog.so.7: Undefined symbol _nc_wacs
I simply deleted the line tzsetup $${optC} -r; \ at line 76 of the
Makefile and re-ran the
installworld. Everything worked from that point. I then compared
/etc/localtime with
/usr/share/zoneinfo/America/Los_Angeles and they were identical, so I
already had
a localtime file built with the new zic.
After the installworld completed, I tried running tzsetup and dialog
ran fine, so I have
no idea why the failure during the instsallworld. I did a search and
found a very similar
report in questions@. The only difference I saw was that my error was
not prefaced
with /libexec/ld-elf.so.1: and, of course, the random string.
http://lists.freebsd.org/pipermail/freebsd-questions/2011-July/232421.html
Any ideas what might be happening here? It is a bit disconcerting as
userland is half
current and half stable when it dies. It would be very awkward to have
to back out and
may people updating to 9.0 after release might not know how to work around it.
This might be required (the base library changed).
HTH,
-Garrett
Index: share/zoneinfo/Makefile
===
--- share/zoneinfo/Makefile (revision 224989)
+++ share/zoneinfo/Makefile (working copy)
@@ -72,7 +72,8 @@
optC=-C ${DESTDIR}; \
fi; \
echo Updating /etc/localtime; \
- tzsetup $${optC} -r; \
+ env LD_PRELOAD=${DESTDIR}/usr/lib/libodialog.so \
+ tzsetup $${optC} -r; \
fi; \
else \
echo Run tzsetup(8) manually to update /etc/localtime.; \
___
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: Failure upgrading from 8-stable to current (9.0-Beta2)
On Fri, Sep 9, 2011 at 11:21 AM, Garrett Cooper yaneg...@gmail.com wrote:
On Fri, Sep 9, 2011 at 11:17 AM, Kevin Oberman kob6...@gmail.com wrote:
Last night I upgraded my laptop from 8-stable (Sept. 7) to head. I
almost worked, but I
did hit an issue during the installworld phase. The problem was when the
make in
/usr/src/share/zoneinfo tried to run tzsetup that dialog failed to run
with the error:
/tmp/install.xtvA5ik4/libdialog.so.7: Undefined symbol _nc_wacs
I simply deleted the line tzsetup $${optC} -r; \ at line 76 of the
Makefile and re-ran the
installworld. Everything worked from that point. I then compared
/etc/localtime with
/usr/share/zoneinfo/America/Los_Angeles and they were identical, so I
already had
a localtime file built with the new zic.
After the installworld completed, I tried running tzsetup and dialog
ran fine, so I have
no idea why the failure during the instsallworld. I did a search and
found a very similar
report in questions@. The only difference I saw was that my error was
not prefaced
with /libexec/ld-elf.so.1: and, of course, the random string.
http://lists.freebsd.org/pipermail/freebsd-questions/2011-July/232421.html
Any ideas what might be happening here? It is a bit disconcerting as
userland is half
current and half stable when it dies. It would be very awkward to have
to back out and
may people updating to 9.0 after release might not know how to work around
it.
This might be required (the base library changed).
HTH,
-Garrett
Index: share/zoneinfo/Makefile
===
--- share/zoneinfo/Makefile (revision 224989)
+++ share/zoneinfo/Makefile (working copy)
@@ -72,7 +72,8 @@
optC=-C ${DESTDIR}; \
fi; \
echo Updating /etc/localtime; \
- tzsetup $${optC} -r; \
+ env LD_PRELOAD=${DESTDIR}/usr/lib/libodialog.so \
+ tzsetup $${optC} -r; \
fi; \
else \
echo Run tzsetup(8) manually to update /etc/localtime.; \
/me slaps forehead
Of course! I missed the one letter change between libdialog and
libodialog. Your patch looks
right and works for me.
Thanks!
--
R. Kevin Oberman, Network Engineer - Retired
E-mail: kob6...@gmail.com
___
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: ath0 no longer attaches, cardbus problems?
I found the commit that broke ath for me, r222753,
specifically, the change to /dev/cardbus/cardbus_cis.c.
To be sure, I updated to head using svn, and applied
the patch included below. ath attaches and works. Without
the patch, ath does not attach.
On another note, I've no idea why updating from a local
CVS repo lead me down a wrong path. It seems wrong that
a 'cvs update -P -d -A -D 31 Mar 2011' works and
a 'cvs update -P -d -A -D 1 Apr 2011' does not work.
r222753 did not occur until much later (June 6).
Once John asked me to try r220195, I switched to using
svn. When that worked, it seemed strange to me because
nothing else committed after that on Mar 31 should have
broke ath.
Anyway, culprit found. Now what is the correct fix?
Index: sys/dev/cardbus/cardbus_cis.c
===
--- sys/dev/cardbus/cardbus_cis.c (revision 225463)
+++ sys/dev/cardbus/cardbus_cis.c (working copy)
@@ -441,6 +441,7 @@
{
if (res != CIS_CONFIG_SPACE) {
bus_release_resource(child, SYS_RES_MEMORY, rid, res);
+ bus_delete_resource(child, SYS_RES_MEMORY, rid);
}
}
@@ -477,7 +478,11 @@
}
/* allocate the memory space to read CIS */
+#if 0
res = bus_alloc_resource_any(child, SYS_RES_MEMORY, rid,
+#else
+ res = bus_alloc_resource(child, SYS_RES_MEMORY, rid, 0, ~0, 1,
+#endif
rman_make_alignment_flags(4096) | RF_ACTIVE);
if (res == NULL) {
device_printf(cbdev, Unable to allocate resource
--
DE
___
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
Please explain syslog entry about gmirror
Hi, I have installed BETA2 and every time I boot up the system I get the following message in syslog: GEOM_MIRRORGEOM_MIRROR: : Device mirror/boot launched (1/2). Device mirror/encrypted launched (1/2). It's a bit mangled, but it's not the problem. The problem is this (1/2). I don't like the kernel think for even a second that my mirror could be inconsistent. I have the following setup: - 2xGPT on 1TB drives - bootblock on both drives - /boot on gmirror with UFS - everything else including rootfs: * geom_mirror - geom_eli - bsdlabel What's going on in the dmesg? gmirror status gives me (correctly): NameStatus Components mirror/boot COMPLETE ada0p2 (ACTIVE) ada2p2 (ACTIVE) mirror/encrypted COMPLETE ada0p4 (ACTIVE) ada2p4 (ACTIVE) -- Martin signature.asc Description: PGP signature
Re: ath0 no longer attaches, cardbus problems?
Hi Daniel!
On 09.09.11 21:22, Daniel Eischen wrote:
I found the commit that broke ath for me, r222753,
specifically, the change to /dev/cardbus/cardbus_cis.c.
To be sure, I updated to head using svn, and applied
the patch included below. ath attaches and works. Without
the patch, ath does not attach.
On another note, I've no idea why updating from a local
CVS repo lead me down a wrong path. It seems wrong that
a 'cvs update -P -d -A -D 31 Mar 2011' works and
a 'cvs update -P -d -A -D 1 Apr 2011' does not work.
r222753 did not occur until much later (June 6).
Once John asked me to try r220195, I switched to using
svn. When that worked, it seemed strange to me because
nothing else committed after that on Mar 31 should have
broke ath.
Anyway, culprit found. Now what is the correct fix?
THANK you very much!
I was following this thread with big interest since last weekend.
Here I found a Wireless card in the trash. An MSI card with a 'Ralink
Technology RT2560, RT2525'.
Under 8.2 it worked perfectly while under current I got a crappy
ethernet address.
Went back to 220194 and could prove that it was working there.
During this process your message came in and I immediately tried the
below patch:
ral0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290
ether 00:13:d3:7f:f8:48
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
status: associated
Whee!!! Again, thanks a lot.
I do not know if it is the right solution, but it works.
Gruss,
Andreas
Index: sys/dev/cardbus/cardbus_cis.c
===
--- sys/dev/cardbus/cardbus_cis.c (revision 225463)
+++ sys/dev/cardbus/cardbus_cis.c (working copy)
@@ -441,6 +441,7 @@
{
if (res != CIS_CONFIG_SPACE) {
bus_release_resource(child, SYS_RES_MEMORY, rid, res);
+ bus_delete_resource(child, SYS_RES_MEMORY, rid);
}
}
@@ -477,7 +478,11 @@
}
/* allocate the memory space to read CIS */
+#if 0
res = bus_alloc_resource_any(child, SYS_RES_MEMORY, rid,
+#else
+ res = bus_alloc_resource(child, SYS_RES_MEMORY, rid, 0, ~0, 1,
+#endif
rman_make_alignment_flags(4096) | RF_ACTIVE);
if (res == NULL) {
device_printf(cbdev, Unable to allocate resource
___
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: WITHOUT_GCC flag disables installation of /usr/bin/cpp too -- is it Ok?
On Wed, 7 Sep 2011, Lev Serebryakov wrote: Hello, Dimitry. You wrote 7 сентября 2011 г., 21:17:20: I think, that /usr/bin/cpp is valuable by itself, as it is handy generic preprocessor tool, useful for preparing complex ipfw scripts, for example. All others are bundled together, for sure. I am not really convinced. /usr/bin/cpp is the C preprocessor, and it is only required to emit output that its bundled C compiler will accept as input. In particular, it can do whatever it wants with whitespace, wrapping and unwrapping lines, outputting other spurious text, c.. From cpp(1): The C preprocessor is intended to be used only with C, C++, and Objec- tive-C source code. In the past, it has been abused as a general text processor. It will choke on input which does not obey C's lexical rules. For example, apostrophes will be interpreted as the beginning of character constants, and cause errors. Also, you cannot rely on it preserving characteristics of the input which are not significant to C-family languages. If a Makefile is preprocessed, all the hard tabs will be removed, and the Makefile will not work. The (incredibly brain-dead) build system at $work runs cpp on a Makefile, which I had to hack around in order to get things to work. It's really an ugly hack, though, and is not at all robust. I wish I didn't have to. If you want a general-purpose macro processor, please consider using something that was designed as a general-purpose macro processor (e.g. m4(1) which is in base) -- abusing cpp(1) is just asking for weird/subtle errors to be introduce in the future. -Ben Kaduk I think, it is good idea to exclude cpp from this list (but not from WITHOUT_TOOLCHAIN, of course).___ 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: truss
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/31/11 07:35, Anton Yuzhaninov wrote:
It seems to be truss(1) is broken on current
:~ truss /bin/echo x x truss: can not get etype: No such process
FreeBSD 9.0-BETA1 #0 r224884M i386
from ktrace of turss
3162 trussCALL
__sysctl(0xbfbfea00,0x4,0xbfbfe9e0,0xbfbfea10,0,0) 3162 truss
SCTL kern.proc.sv_name.3163 3162 trussRET __sysctl -1
errno 3 No such process
Can't seem to be reproducable here, did I missed anything? (note that
you may need a full world/kernel build).
truss /bin/echo x
mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34366255104 (0x800637000)
issetugid(0x800638015,0x80062cd9e,0x800848810,0x8008487e0,0xb277,0x0)
= 0 (0x0)
open(/etc/libmap.conf,O_RDONLY,0666) = 3 (0x3)
fstat(3,{ mode=-rw-r--r-- ,inode=1668471,size=712,blksize=4096 }) = 0
(0x0)
read(3,libpthread.so.2\tlibthr.so.2\nli...,4096) = 712 (0x2c8)
read(3,0x80063b000,4096) = 0 (0x0)
close(3) = 0 (0x0)
open(/var/run/ld-elf.so.hints,O_RDONLY,0160) = 3 (0x3)
read(3,Ehnt\^A\0\0\0\M^@\0\0\0\M-\\^A\0...,128) = 128 (0x80)
lseek(3,0x80,SEEK_SET) = 128 (0x80)
read(3,/lib:/usr/lib:/usr/lib/compat:/u...,476) = 476 (0x1dc)
close(3) = 0 (0x0)
mmap(0x0,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34366287872 (0x80063f000)
access(/lib/libc.so.7,0) = 0 (0x0)
open(/lib/libc.so.7,O_RDONLY,040737600)= 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=2664100,size=1310888,blksize=131072
}) = 0 (0x0)
pread(0x3,0x80083af60,0x1000,0x0,0x101010101010101,0x8080808080808080)
= 4096 (0x1000)
mmap(0x0,3432448,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) =
34368425984 (0x800849000)
mmap(0x800849000,1179648,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE,3,0x0)
= 34368425984 (0x800849000)
mmap(0x800b69000,45056,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0x12)
= 34371702784 (0x800b69000)
mprotect(0x800b74000,110592,PROT_READ|PROT_WRITE) = 0 (0x0)
close(3) = 0 (0x0)
sysarch(0x81,0x7fffcfc0,0x80063d6c8,0x0,0xffad0580,0x800865370)
= 0 (0x0)
munmap(0x800642000,24576)= 0 (0x0)
mmap(0x0,102400,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34366300160 (0x800642000)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
readlink(/etc/malloc.conf,aj,1024) = 2 (0x2)
issetugid(0x800945ba1,0x7fffd220,0x6a,0x0,0x2,0x2) = 0 (0x0)
break(0x80) = 0 (0x0)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34371858432 (0x800b8f000)
mmap(0x800f8f000,462848,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0)
= 34376052736 (0x800f8f000)
munmap(0x800b8f000,462848) = 0 (0x0)
x
writev(0x1,0x800c07040,0x2,0x7fffdad0,0x600d10,0x7fffcd60) = 2
(0x2)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
process exit, rval = 0
Cheers,
- --
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (FreeBSD)
iQEcBAEBCAAGBQJOapmpAAoJEATO+BI/yjfBgY8IANXc7pbkZHEa0I6N6eZPM2Mk
IuiK8Ei6p9jGI72DYS9VV+OPGerarkBw0CvYyKr9lNKV5rnB4fg04MiUflNGpSqN
2zQmnGewzr1+a/bC6txaLZr5ittUnpzXp85CB1sEZ5tXn34pMsW9MYmSSmL4SwMG
L8e4+U+QjdOMvH2BHEil3WdkqPDQKnz/mk+2wJX7gw3/ssf7QozyQ4vpE4Ed2jC8
dnpCmE++BtPRK+PzdbhcoT3/KpSCuWIpaAAcxh8RE994K3nwc27crPOKLA/7lQ2x
u4VIIcX27Jb1pKwugmcriTCIhCb0D7ge44fDTHAhY97W7p36JD3DbSUm5zs8I8o=
=v+hw
-END PGP SIGNATURE-
___
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: RELENG_8 / mpt / zpool Errors
On 10 September 2011 01:19, Tim Gustafson t...@soe.ucsc.edu wrote: I can most likely switch to a different card. Just to make sure I get the right one, do you have a part number of the card that you are recommending? As I mentioned earlier, I was looking around on the LSI site and they have lots of options, but none with a port configuration that I need (2 external ports only). I'm not sure what cards you can get now with the LSI 1068E chip. As LSI branded cards cost more, I went for for the LSI SAS2008 based Supermicro AOC-USAS2-L8i as I new I wasn't going to use port expanders. It could be hard to get cards with the older chip now (you might have to get something second hand). The Supermicro AOC-USAS-L4i wouldn't be enough for you as it's only got 1 external connector. http://www.supermicro.com/products/accessories/addon/AOC-USAS-L4i_R.cfm I'd be happy to help with debugging the 6G problem. I could probably install that card into another box and give some developers access to it, but I'd have to rustle up some disks and port expanders to make it a fair test. A port expander would be required and just a few older drives in the enclosure. A developer (of which I'm not) would need console access and ability to install new kernels, reboot etc. Good luck... ___ 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: WITHOUT_GCC flag disables installation of /usr/bin/cpp too -- is it Ok?
On Fri, 9 Sep 2011, Benjamin Kaduk wrote: On Wed, 7 Sep 2011, Lev Serebryakov wrote: Hello, Dimitry. You wrote 7 сентября 2011 г., 21:17:20: I think, that /usr/bin/cpp is valuable by itself, as it is handy generic preprocessor tool, useful for preparing complex ipfw scripts, for example. All others are bundled together, for sure. I am not really convinced. /usr/bin/cpp is the C preprocessor, and it is only required to emit output that its bundled C compiler will accept as input. In particular, it can do whatever it wants with whitespace, wrapping and unwrapping lines, outputting other spurious text, c.. From cpp(1): The C preprocessor is intended to be used only with C, C++, and Objec- tive-C source code. In the past, it has been abused as a general text processor. It will choke on input which does not obey C's lexical rules. For example, apostrophes will be interpreted as the beginning of character constants, and cause errors. Also, you cannot rely on it preserving characteristics of the input which are not significant to C-family languages. If a Makefile is preprocessed, all the hard tabs will be removed, and the Makefile will not work. The (incredibly brain-dead) build system at $work runs cpp on a Makefile, which I had to hack around in order to get things to work. It's really an ugly hack, though, and is not at all robust. I wish I didn't have to. If you want a general-purpose macro processor, please consider using something that was designed as a general-purpose macro processor (e.g. m4(1) which is in base) -- abusing cpp(1) is just asking for weird/subtle errors to be introduce in the future. Another option may be to install devel/ucpp. I have not used it before, but it may be good enough for preparing ipfw scripts. Sean -- s...@freebsd.org___ 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: truss
On Sep 9, 2011, at 3:56 PM, Xin LI delp...@delphij.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/31/11 07:35, Anton Yuzhaninov wrote:
It seems to be truss(1) is broken on current
:~ truss /bin/echo x x truss: can not get etype: No such process
FreeBSD 9.0-BETA1 #0 r224884M i386
from ktrace of turss
3162 trussCALL
__sysctl(0xbfbfea00,0x4,0xbfbfe9e0,0xbfbfea10,0,0) 3162 truss
SCTL kern.proc.sv_name.3163 3162 trussRET __sysctl -1
errno 3 No such process
Can't seem to be reproducable here, did I missed anything? (note that
you may need a full world/kernel build).
truss /bin/echo x
mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34366255104 (0x800637000)
issetugid(0x800638015,0x80062cd9e,0x800848810,0x8008487e0,0xb277,0x0)
= 0 (0x0)
open(/etc/libmap.conf,O_RDONLY,0666) = 3 (0x3)
fstat(3,{ mode=-rw-r--r-- ,inode=1668471,size=712,blksize=4096 }) = 0
(0x0)
read(3,libpthread.so.2\tlibthr.so.2\nli...,4096) = 712 (0x2c8)
read(3,0x80063b000,4096) = 0 (0x0)
close(3) = 0 (0x0)
open(/var/run/ld-elf.so.hints,O_RDONLY,0160) = 3 (0x3)
read(3,Ehnt\^A\0\0\0\M^@\0\0\0\M-\\^A\0...,128) = 128 (0x80)
lseek(3,0x80,SEEK_SET) = 128 (0x80)
read(3,/lib:/usr/lib:/usr/lib/compat:/u...,476) = 476 (0x1dc)
close(3) = 0 (0x0)
mmap(0x0,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34366287872 (0x80063f000)
access(/lib/libc.so.7,0) = 0 (0x0)
open(/lib/libc.so.7,O_RDONLY,040737600) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=2664100,size=1310888,blksize=131072
}) = 0 (0x0)
pread(0x3,0x80083af60,0x1000,0x0,0x101010101010101,0x8080808080808080)
= 4096 (0x1000)
mmap(0x0,3432448,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) =
34368425984 (0x800849000)
mmap(0x800849000,1179648,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE,3,0x0)
= 34368425984 (0x800849000)
mmap(0x800b69000,45056,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0x12)
= 34371702784 (0x800b69000)
mprotect(0x800b74000,110592,PROT_READ|PROT_WRITE) = 0 (0x0)
close(3) = 0 (0x0)
sysarch(0x81,0x7fffcfc0,0x80063d6c8,0x0,0xffad0580,0x800865370)
= 0 (0x0)
munmap(0x800642000,24576) = 0 (0x0)
mmap(0x0,102400,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34366300160 (0x800642000)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
readlink(/etc/malloc.conf,aj,1024) = 2 (0x2)
issetugid(0x800945ba1,0x7fffd220,0x6a,0x0,0x2,0x2) = 0 (0x0)
break(0x80) = 0 (0x0)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34371858432 (0x800b8f000)
mmap(0x800f8f000,462848,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0)
= 34376052736 (0x800f8f000)
munmap(0x800b8f000,462848) = 0 (0x0)
x
writev(0x1,0x800c07040,0x2,0x7fffdad0,0x600d10,0x7fffcd60) = 2
(0x2)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
process exit, rval = 0
Truss isn't broken for me this way either. It just doesn't detach from
processes properly if I do ctrl c, which seems like a ptrace bug to me.
It would help to know how truss was compiled (file would be helpful), and what
environment it's being executed in (32bit on 64bit, a chroot/jail, etc).
Thanks,
-Garrett___
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: ath0 no longer attaches, cardbus problems?
On Sep 9, 2011, at 1:22 PM, Daniel Eischen wrote:
I found the commit that broke ath for me, r222753,
specifically, the change to /dev/cardbus/cardbus_cis.c.
To be sure, I updated to head using svn, and applied
the patch included below. ath attaches and works. Without
the patch, ath does not attach.
On another note, I've no idea why updating from a local
CVS repo lead me down a wrong path. It seems wrong that
a 'cvs update -P -d -A -D 31 Mar 2011' works and
a 'cvs update -P -d -A -D 1 Apr 2011' does not work.
r222753 did not occur until much later (June 6).
Once John asked me to try r220195, I switched to using
svn. When that worked, it seemed strange to me because
nothing else committed after that on Mar 31 should have
broke ath.
Anyway, culprit found. Now what is the correct fix?
Do you need both chunks? The second one seems redundant given the definition
of bus_alloc_reosurce_any does exactly that.
Warner
Index: sys/dev/cardbus/cardbus_cis.c
===
--- sys/dev/cardbus/cardbus_cis.c (revision 225463)
+++ sys/dev/cardbus/cardbus_cis.c (working copy)
@@ -441,6 +441,7 @@
{
if (res != CIS_CONFIG_SPACE) {
bus_release_resource(child, SYS_RES_MEMORY, rid, res);
+ bus_delete_resource(child, SYS_RES_MEMORY, rid);
}
}
@@ -477,7 +478,11 @@
}
/* allocate the memory space to read CIS */
+#if 0
res = bus_alloc_resource_any(child, SYS_RES_MEMORY, rid,
+#else
+ res = bus_alloc_resource(child, SYS_RES_MEMORY, rid, 0, ~0, 1,
+#endif
rman_make_alignment_flags(4096) | RF_ACTIVE);
if (res == NULL) {
device_printf(cbdev, Unable to allocate resource
--
DE
___
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
