Re: Depreciate and remove gbde
If I can open the soapbox for a moment. If you want a secure filesystem I think that at this particular time it would be entirely reasonable to use both gbde and geli stacked on top of each other, assuming you have CPU/battery to spare. (there should be enough cores but the battery might be unhappy) Nobody is going to go at your encrypted filesystem at the cipher level. The problem with using a less-testing system like either of these is that there might be errors in setup that have reduced the search space for the correct key. That happens all the time. The protocols to set up the actual cipher aren't trivial to get right. So if you stack both you would guard yourself against screwups in either, even if you use the same actual cipher for both layers. In addition there is a fashion right now that people with lots of brain and time go after the block chaining modes for block device encryption. It looks semi-ugly I'd say although not really spectacular right now. If you stack both gbde and geli on top of each other you can use different block chaining modes and you would also guard yourself against a failure there. Just don't do it on top of a consumer SATA SSD... Having said this, now that I looked at gbde's block chaining, it seems it simply inherits CBC from geom_aes.c, is that right? Martin Yonas Yanfa wrote on Mon, Oct 19, 2015 at 08:43:00PM -0400: > Hi Martin, thanks, that raises some interesting points. After reading PHK's > paper on GBDE, I can see enough differences between GDBE and GELI that > warrant keeping GDBE. > > [ At this point for me, this part is theoretical, but it's still > interesting ] I've seen the concerned made a few times that we need to > support existing users. That's true up to a point. There's always going to > be a way to transition from GDBE to GELI if we really want to (eg. a > conversion tool), or were forced to for any reason (full decrypt and > re-encrypt), so we shouldn't be keeping GDBE in the tree solely for this > reason alone. GDBE should be in the tree for it's technical merits (which > I've found it does have). However, if it turns out in X years from today > GELI can do everything GDBE can do and better, then I would say we should > figure out a way to remove GDBE. > > On Mon, Oct 19, 2015 at 7:44 PM, Martin Cracauer <craca...@cons.org> wrote: > > > Yonas Yanfa wrote on Sun, Oct 18, 2015 at 06:36:19AM -0400: > > > > > > Is there any objection to removing gbde? How many people use gbde? When > > > have you used gbde over geli, and why? > > > > You would exclude all current users from accessing their existing > > filesystems or whatever they put into that block device. > > > > A conversion tool would pretty much be forced to use the current > > kernel layers (doing the block chaining in userspace would be > > annoying), and it would be fundamentally unsafe to have your > > half-converted filesystem on disk in case of an interruption. Plus I > > think GELI uses a bigger header so you might fall short by a couple of > > bytes and you can't do anything about it on the block level with no > > access to the filesystem. > > > > And people might not have their gbde units accessible right now, it > > might be on a laptop in a closet on a different continent. > > > > Martin > > -- > > %%%%%%% > > Martin Cracauer <craca...@cons.org> http://www.cons.org/cracauer/ > > -- %%% Martin Cracauer <craca...@cons.org> http://www.cons.org/cracauer/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Depreciate and remove gbde
Yonas Yanfa wrote on Sun, Oct 18, 2015 at 06:36:19AM -0400: > > Is there any objection to removing gbde? How many people use gbde? When > have you used gbde over geli, and why? You would exclude all current users from accessing their existing filesystems or whatever they put into that block device. A conversion tool would pretty much be forced to use the current kernel layers (doing the block chaining in userspace would be annoying), and it would be fundamentally unsafe to have your half-converted filesystem on disk in case of an interruption. Plus I think GELI uses a bigger header so you might fall short by a couple of bytes and you can't do anything about it on the block level with no access to the filesystem. And people might not have their gbde units accessible right now, it might be on a laptop in a closet on a different continent. Martin -- %%%%%%% Martin Cracauer <craca...@cons.org> http://www.cons.org/cracauer/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Data corruption over NFS in -current
More findings. Reminder, with the original report I found: - files for no reason changing ownership and group to root/owngroupname - data corruption as in inserting binary junk obviously from ports - data corruption as in malformed ascii text that might be a bug I have in my code that is only exposed in FreeBSD I ran the script on a Linux machine in the same situation again the same NFS server, it worked fine. I haven't look at blocksizes, NFS versions etc in play yet. I ran with oldnfs (reboot), which showed only the third problem. I re-ran with newfs (reboot) which worked (all three problems absent). I then started building ports/land/gcc47 at the same time as I re-started my crazy script and it too only a few seconds for an unexpected ownership to root to occur. My next steps are: - trying block sizes and other parameters, maybe use a different NFS version with the Linux client. My NFS server is newly upgraded to Linux kernel 3.1.5 - running my script on a FreeBSD host with local disk to see whether problem #3 is a general problem that appears or is exposed only on FreeBSD - capture tcpdump as mentioned earlier I will probably have to turn debug off since this script run is dominated by system time now and gets 10x slower as it is now. Martin -- %%% Martin Cracauer craca...@cons.org http://www.cons.org/cracauer/ ___ 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
Data corruption over NFS in -current
I'm sorry for the unspecific bug report but I thought a heads-up is better than none. $ uname -a FreeBSD wings.cons.org 10.0-CURRENT FreeBSD 10.0-CURRENT #2: Wed Dec 28 12:19:21 EST 2011 craca...@wings.cons.org:/usr/src/sys/amd64/compile/WINGS amd64 I see filesystem corruption on NFS filesystems here. I am running a heavy shellscript that is noodling around with ascii files assembling them with awk and whatnot. Some actions are concurrent with up to 21 forks doing full-CPU load scripting. This machine is a K8 with a total of 8 cores, diskless NFS and memory filesystem for /tmp. I observe two problems: - for no reason whatsoever, some files change from my (user/group) cracauer/wheel to root/cracauer - the same files will later be corrupted. The beginning of the file is normal but then it has what looks like parts of /usr/ports, including our CVS files and binary junk, mostly zeros I did do some ports building lately but not at the same time that this problem manifested itself. I speculate some ports blocks were still resident in the filesystem buffer cache. Server is Linux. Martin -- %%% Martin Cracauer craca...@cons.org http://www.cons.org/cracauer/ ___ 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: Data corruption over NFS in -current
Stefan Bethke wrote on Wed, Jan 11, 2012 at 07:14:44PM +0100: Am 11.01.2012 um 17:57 schrieb Martin Cracauer: I'm sorry for the unspecific bug report but I thought a heads-up is better than none. $ uname -a FreeBSD wings.cons.org 10.0-CURRENT FreeBSD 10.0-CURRENT #2: Wed Dec 28 12:19:21 EST 2011 craca...@wings.cons.org:/usr/src/sys/amd64/compile/WINGS amd64 I'm sure Rick will want to know which NFS version, which client code (default new code I'm assuming) and which mount options... It's all default both in fstab and as reported by mount(8). This is a diskless PXE boot but the mount affected (usr) is not the root filesystem, so this should come in via fstab. BTW, my /usr/ports is another mount so the corruption is cross-mount (garbage from /usr/ports entering /usr). Appending nfsstat output. I am re-running things contiguously to see how reproducible this is. This machine was recently updated from a -current almost a year old, so it's its first time with the new NFS client code. Martin I see filesystem corruption on NFS filesystems here. I am running a heavy shellscript that is noodling around with ascii files assembling them with awk and whatnot. Some actions are concurrent with up to 21 forks doing full-CPU load scripting. This machine is a K8 with a total of 8 cores, diskless NFS and memory filesystem for /tmp. I observe two problems: - for no reason whatsoever, some files change from my (user/group) cracauer/wheel to root/cracauer - the same files will later be corrupted. The beginning of the file is normal but then it has what looks like parts of /usr/ports, including our CVS files and binary junk, mostly zeros I did do some ports building lately but not at the same time that this problem manifested itself. I speculate some ports blocks were still resident in the filesystem buffer cache. Server is Linux. Martin -- %%% Martin Cracauer craca...@cons.org http://www.cons.org/cracauer/ ___ 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 -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 -- %%% Martin Cracauer craca...@cons.org http://www.cons.org/cracauer/ Client Info: Rpc Counts: Getattr SetattrLookup Readlink Read WriteCreateRemove 94392942513117 3637266 2577 40227237 2824593333832304567 Rename Link Symlink Mkdir Rmdir Readdir RdirPlusAccess 32522 5121 4856 20363 13954179035 0 3534382 MknodFsstatFsinfo PathConfCommit 5 21127240 3 2999521782 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 167678419 Cache Info: Attr HitsMisses Lkup HitsMisses BioR HitsMisses BioW HitsMisses 1933340911 73265447 1123380719 3636242 90975094450509 4917135 2824593 BioRLHitsMisses BioD HitsMisses DirE HitsMisses Accs HitsMisses 54732346 2577599049142917352394 0 733726346 3534382 Server Info: Getattr SetattrLookup Readlink Read WriteCreateRemove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlusAccess 0 0 0 0 0 0 0 0 MknodFsstatFsinfo PathConfCommit 0 0 0 0 0 Server Ret-Failed 0 Server Faults 0 Server Cache Stats: Inprog Idem Non-idemMisses 0 0 0 0 Server Write Gathering: WriteOps WriteRPC Opsaved 0 0 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: Data corruption over NFS in -current
Rick Macklem wrote on Wed, Jan 11, 2012 at 08:42:25PM -0500: Martin Cracauer wrote: Stefan Bethke wrote on Wed, Jan 11, 2012 at 07:14:44PM +0100: Am 11.01.2012 um 17:57 schrieb Martin Cracauer: I'm sorry for the unspecific bug report but I thought a heads-up is better than none. $ uname -a FreeBSD wings.cons.org 10.0-CURRENT FreeBSD 10.0-CURRENT #2: Wed Dec 28 12:19:21 EST 2011 craca...@wings.cons.org:/usr/src/sys/amd64/compile/WINGS amd64 I'm sure Rick will want to know which NFS version, which client code (default new code I'm assuming) and which mount options... It's all default both in fstab and as reported by mount(8). I assume that by the above statement, you mean that you don't specify any mount options in your /etc/fstab entry except rw? (If this isn't correct, please post your /etc/fstab entries for the NFS mounts.) 172.18.30.2:/home/diskless/freebsd-current-usr /usrnfs rw 0 0 172.18.30.2:/home/diskless/usr-ports/usr/ports nfs rw 0 0 - If I am correct, in that you just specify rw, the main difference between the old and new NFS client will be the rsize/wsize used. The new NFS client will use MAX_BSIZE (64Kb) decreased to whatever the server says is the largest it can handle. This should be fine, unless the server says it can handle = 64Kb, but actually only works correctly for 32Kb (which is what the old NFS client will default to, I think?). I'll try 32 KB. A few things to try/check: - Look locally on the server to see if the file is corrupted there. Yes it has the corrupted version of the file, and in a new run I had another file changed to root ownership and that is the same from server and client standpoint. The good news is that this seems fairly reproducible, the root ownership is back. This time I stopped the script when ownership changed so I don't know whether it would have gone forward with corrupting the file afterwards. - Try the old NFS client. (Set the fs type to oldnfs instead of nfs on the lines in your /etc/fstab.) - If switching to the old client helps, it might be a bug in the way the new client generates the create verifier. I just looked at the code and I'm not certain the code in the new client would work correctly for a amd64. (I only have i386 to test with.) - I can easily generate a patch that changes the new client to do this the same way as the old client, but there is no point, unless the old client doesn't have the problem. -- Exclusive create problems might explain the incorrect ownership, since it first does a create that will fill in user/group in whatever default way the Linux server chooses to and then does a Setattr RPC to change them to the correct values. If the Setattr RPC fails, then the file exists owned by whatever the server chooses. (I don't know if Linux servers use the gid of the directory or the gid of the requestor or ???) - If you have a non-Linux NFS server, try running against that to see if it is a Linux server specific problem. (Since I haven't seen any other reports like this, I suspect it might be an interoperability problem related to the Linux server.) I should mention that I also updated the server to Linux-3.1.5 two weeks ago. I'm not sure I put I put heavy load on it since then. I will have a Linux NFS client do the same thing and try the FreeBSD things you mention. Also, if you can reproduce the problem fairly easily, capture a packet trace via # tcpdump -s 0 -w xxx host server running on the client (or similar). Then email me xxx as an attachment and I can look at it in wireshark. (If you choose to look at it in wireshark, I would suggest you look for Create RPCs to see if they are Exclusive Creates, plus try and see where the data for the corrupt file is written.) Even if the capture is pretty large, it should be easy to find the interesting part, so long as you know the name of the corrupt file and search for that. That's probably not practical, we are talking about hammering the NFS server with several CPU hours worth of parallel activity in a shellscript but I'll do my best :-) Martin This is a diskless PXE boot but the mount affected (usr) is not the root filesystem, so this should come in via fstab. BTW, my /usr/ports is another mount so the corruption is cross-mount (garbage from /usr/ports entering /usr). Appending nfsstat output. nfsstat output is pretty useless for this kind of situation. I did find it interesting that you do so many Fsstat RPCs, but that shouldn't be a problem, it's just weird to see that. rick I am re-running things contiguously to see how reproducible this is. This machine was recently updated from a -current almost a year old, so it's its first time with the new NFS client code. Martin I see filesystem corruption on NFS
Re: HEADS UP: utmp.h gone. All welcome utmpx.h.
editors/emacs21 and emacs22 are still broken with this. Changing utmp to utmpx in #include and in the struct declares I still get: filelock.c:297: error: 'struct utmpx' has no member named 'ut_time' filelock.c:299: error: 'struct utmpx' has no member named 'ut_time' Any suggestions? The manpage is still for utmp, not utmpx, unless my -current got hopelessly out of sync. Martin -- %%% Martin Cracauer craca...@cons.org http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.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: HEADS UP: utmp.h gone. All welcome utmpx.h.
Martin Cracauer wrote on Fri, Feb 12, 2010 at 05:24:06PM -0500: editors/emacs21 and emacs22 are still broken with this. Changing utmp to utmpx in #include and in the struct declares I still get: filelock.c:297: error: 'struct utmpx' has no member named 'ut_time' filelock.c:299: error: 'struct utmpx' has no member named 'ut_time' Any suggestions? The manpage is still for utmp, not utmpx, unless my -current got hopelessly out of sync. Never mind. Suggested patch sent to port maintainer. Thanks Martin -- %%% Martin Cracauer craca...@cons.org http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.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: Please review sh SIGSTOP fix
In [EMAIL PROTECTED], Randell Jesup wrote: Martin Cracauer [EMAIL PROTECTED] writes: would you please have a look at the following sh fix? My brain is a bit rusty and maybe I overlook a drawback. When a child is receiving SIGSTOP, eval continues with the next command. While that is correct for the interactive case (Control-Z and you get the prompt back), it is wrong for a shellscript, which just continues with the next command, never again waiting for the stopped child. Noted when childs from cronjobs were stopped, just to make more processes (by wosch). Careful - is this behavior used as a feature during boot when starting services? I.e. you can ^Z and it will continue with the next service; effectively backgrounding the service that's waiting. I.e. is this a feature (perhaps accidental) that people assume and rely on? I hope not, thats definitivly a bug. Do you intent to continue the stopped proccess anytime? I don't think that are many cases where they were hung so that backgrounding them is needed but where they are not completely hung. And if so, is there another way to get the functionality, and is it important to people? Control-C kills the currently starting process and Control-\ makes the whole /etc/rc return to singleuser-mode. That are the only documented ways to interact with /etc/rc. If you really want to background one process from /etc/rc, you would still do that by writing a wrapped that catches SIGINT and send SIGSTOP to its child (which is the original thing to start). Martin -- Martin Cracauer [EMAIL PROTECTED]http://www.cons.org/cracauer/ As far as I'm concerned, if something is so complicated that you can't ex- plain it in 10 seconds, then it's probably not worth knowing anyway -Calvin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please review sh SIGSTOP fix
In [EMAIL PROTECTED], Martin Cracauer wrote: If you really want to background one process from /etc/rc, you would still do that by writing a wrapped that catches SIGINT and send ^^^ ^ wrapper shellscript s SIGSTOP to its child (which is the original thing to start). Sorry Martin -- Martin Cracauer [EMAIL PROTECTED]http://www.cons.org/cracauer/ As far as I'm concerned, if something is so complicated that you can't ex- plain it in 10 seconds, then it's probably not worth knowing anyway -Calvin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Please review sh SIGSTOP fix
Bruce (or other -currenter's)
would you please have a look at the following sh fix? My brain is a
bit rusty and maybe I overlook a drawback.
When a child is receiving SIGSTOP, eval continues with the next
command. While that is correct for the interactive case (Control-Z
and you get the prompt back), it is wrong for a shellscript, which
just continues with the next command, never again waiting for the
stopped child. Noted when childs from cronjobs were stopped, just to
make more processes (by wosch).
The fix is not to return from a job wait when the wait returned for a
stopped child while in non-interactive mode. This bahaviour seems to
be what bash2 and ksh implement. I tested for correct behaviour for
finnaly killing the child with and without forgrounding it first.
When not foregrouding before killing, the shell continues with the
script, which is what the other shells do as well.
Thanks
Martin
Index: jobs.c
===
RCS file: /home/CVS-FreeBSD/src/bin/sh/jobs.c,v
retrieving revision 1.27.2.1
diff -u -r1.27.2.1 jobs.c
--- jobs.c 2000/06/14 13:42:25 1.27.2.1
+++ jobs.c 2001/02/02 10:28:08
@@ -782,7 +782,8 @@
do {
pid = waitproc(block, status);
TRACE(("wait returns %d, status=%d\n", pid, status));
- } while (pid == -1 errno == EINTR breakwaitcmd == 0);
+ } while ((pid == -1 errno == EINTR breakwaitcmd == 0) ||
+ (WIFSTOPPED(status) !iflag));
in_dowait--;
if (breakwaitcmd != 0) {
breakwaitcmd = 0;
--
%%%%%%%%
Martin Cracauer [EMAIL PROTECTED]http://www.cons.org/cracauer/
As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway -Calvin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
vn broken?
-current from Aug, 22, cd9660 image file mounted via vn reports this:
Aug 28 13:45:51 counter /kernel: unexpected vn driver lock: 0xccf008c0: type VREG,
usecount 2, writecount 1, refcount 452, flags (VOBJBUF)
Aug 28 13:45:51 counter /kernel: tag VT_UFS, ino 357635, on dev #da/6 (13, 6) lock
type inode: EXCL (count 1) by pid 5
This happens when multiple parallel things are done to the iso
filesystem inside the vnode, i.e.:
A single
find /mnt -type f -exec cat {} \; | wc -c
works without problems, two of them started with a delay cause these
messages.
Martin
--
%
Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/
BSD User Group Hamburg, Germany http://www.bsdhh.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: vn broken?
:0:4:0): PAUSE/RESUME. CDB: 4b 0 0 0 0 0 0 0 0 0 (cd0:ahc1:0:4:0): ILLEGAL REQUEST asc:2c,0 (cd0:ahc1:0:4:0): Command sequence error /dev/vmmon: Vmx86_DestroyVM: unlocked pages: 11716, unlocked dirty pages: 11665 [more cd error of the same kind deleted] (cd0:ahc1:0:4:0): READ SUB-CHANNEL. CDB: 42 0 40 1 0 0 0 0 18 0 (cd0:ahc1:0:4:0): NOT READY asc:3a,0 (cd0:ahc1:0:4:0): Medium not present /dev/vmmon: Vmx86_DestroyVM: unlocked pages: 3517994, unlocked dirty pages: 1967598 (cd0:ahc1:0:4:0): PAUSE/RESUME. CDB: 4b 0 0 0 0 0 0 0 0 0 (cd0:ahc1:0:4:0): ILLEGAL REQUEST asc:2c,0 (cd0:ahc1:0:4:0): Command sequence error (cd0:ahc1:0:4:0): PAUSE/RESUME. CDB: 4b 0 0 0 0 0 0 0 0 0 (cd0:ahc1:0:4:0): ILLEGAL REQUEST asc:2c,0 (cd0:ahc1:0:4:0): Command sequence error sa0 at ahc1 bus 0 target 2 lun 0 sa0: Quantum DLT4000 D474 Removable Sequential Access SCSI-2 device sa0: 8.064MB/s transfers (8.064MHz, offset 15) sa1 at ahc1 bus 0 target 3 lun 0 sa1: HP C1533A 9503 Removable Sequential Access SCSI-2 device sa1: 8.064MB/s transfers (8.064MHz, offset 8) cd1 at ahc1 bus 0 target 6 lun 0 cd1: YAMAHA CRW4260 1.0j Removable CD-ROM SCSI-2 device cd1: 3.300MB/s transfers cd1: cd present [1 x 2048 byte records] cd9660: RockRidge Extension /dev/vmmon: Vmx86_DestroyVM: unlocked pages: 976, unlocked dirty pages: 696805 (cd0:ahc1:0:4:0): PAUSE/RESUME. CDB: 4b 0 0 0 0 0 0 0 0 0 (cd0:ahc1:0:4:0): ILLEGAL REQUEST asc:2c,0 (cd0:ahc1:0:4:0): Command sequence error /dev/vmmon: Vmx86_DestroyVM: unlocked pages: 462622, unlocked dirty pages: 303701 (cd0:ahc1:0:4:0): PAUSE/RESUME. CDB: 4b 0 0 0 0 0 0 0 0 0 (cd0:ahc1:0:4:0): ILLEGAL REQUEST asc:2c,0 (cd0:ahc1:0:4:0): Command sequence error /dev/vmmon: Vmx86_DestroyVM: unlocked pages: 372415, unlocked dirty pages: 249684 (cd0:ahc1:0:4:0): PAUSE/RESUME. CDB: 4b 0 0 0 0 0 0 0 0 0 (cd0:ahc1:0:4:0): ILLEGAL REQUEST asc:2c,0 (cd0:ahc1:0:4:0): Command sequence error /dev/vmmon: Vmx86_DestroyVM: unlocked pages: 135922, unlocked dirty pages: 73338 (cd0:ahc1:0:4:0): PAUSE/RESUME. CDB: 4b 0 0 0 0 0 0 0 0 0 (cd0:ahc1:0:4:0): ILLEGAL REQUEST asc:2c,0 (cd0:ahc1:0:4:0): Command sequence error (cd0:ahc1:0:4:0): READ SUB-CHANNEL. CDB: 42 0 40 1 0 0 0 0 18 0 (cd0:ahc1:0:4:0): NOT READY asc:3a,0 (cd0:ahc1:0:4:0): Medium not present (cd0:ahc1:0:4:0): READ SUB-CHANNEL. CDB: 42 0 40 1 0 0 0 0 18 0 (cd0:ahc1:0:4:0): NOT READY asc:3a,0 (cd0:ahc1:0:4:0): Medium not present pid 79277 (tosha), uid 0: exited on signal 11 (core dumped) pid 79278 (tosha), uid 0: exited on signal 11 (core dumped) pid 79719 (tosha), uid 0: exited on signal 11 (core dumped) (cd0:ahc1:0:4:0): READ(10). CDB: 28 0 0 3 93 20 0 0 20 0 (cd0:ahc1:0:4:0): ILLEGAL REQUEST asc:21,0 (cd0:ahc1:0:4:0): Logical block address out of range (cd0:ahc1:0:4:0): cddone: got error 0x16 back cd9660: Joliet Extension unexpected vn driver lock: 0xccf008c0: type VREG, usecount 2, writecount 1, refcount 227, flags (VOBJBUF) tag VT_UFS, ino 357635, on dev #da/6 (13, 6) lock type inode: EXCL (count 1) by pid 5 (cd0:ahc1:0:4:0): READ SUB-CHANNEL. CDB: 42 0 40 1 0 0 0 0 18 0 (cd0:ahc1:0:4:0): NOT READY asc:3a,0 (cd0:ahc1:0:4:0): Medium not present (cd0:ahc1:0:4:0): READ SUB-CHANNEL. CDB: 42 0 40 1 0 0 0 0 18 0 (cd0:ahc1:0:4:0): NOT READY asc:3a,0 (cd0:ahc1:0:4:0): Medium not present (cd0:ahc1:0:4:0): READ SUB-CHANNEL. CDB: 42 0 40 1 0 0 0 0 18 0 (cd0:ahc1:0:4:0): NOT READY asc:3a,0 (cd0:ahc1:0:4:0): Medium not present (cd0:ahc1:0:4:0): READ SUB-CHANNEL. CDB: 42 0 40 1 0 0 0 0 18 0 (cd0:ahc1:0:4:0): NOT READY asc:3a,0 (cd0:ahc1:0:4:0): Medium not present (cd0:ahc1:0:4:0): READ SUB-CHANNEL. CDB: 42 0 40 1 0 0 0 0 18 0 (cd0:ahc1:0:4:0): NOT READY asc:3a,0 (cd0:ahc1:0:4:0): Medium not present (cd0:ahc1:0:4:0): READ SUB-CHANNEL. CDB: 42 0 40 1 0 0 0 0 18 0 (cd0:ahc1:0:4:0): NOT READY asc:3a,0 (cd0:ahc1:0:4:0): Medium not present (cd0:ahc1:0:4:0): READ SUB-CHANNEL. CDB: 42 0 40 1 0 0 0 0 18 0 (cd0:ahc1:0:4:0): NOT READY asc:3a,0 (cd0:ahc1:0:4:0): Medium not present unexpected vn driver lock: 0xccf008c0: type VREG, usecount 2, writecount 1, refcount 452, flags (VOBJBUF) tag VT_UFS, ino 357635, on dev #da/6 (13, 6) lock type inode: EXCL (count 1) by pid 5 unexpected vn driver lock: 0xccf008c0: type VREG, usecount 2, writecount 1, refcount 740, flags (VOBJBUF) tag VT_UFS, ino 357635, on dev #da/6 (13, 6) lock type inode: EXCL (count 1) by pid 82130 unexpected vn driver lock: 0xccf008c0: type VREG, usecount 2, writecount 1, refcount 731, flags (VOBJBUF) tag VT_UFS, ino 357635, on dev #da/6 (13, 6) lock type inode: EXCL (count 1) by pid 82131 [truncated] Martin -- %%%%% Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /bin/sh dumps core with here-document of 8bit text
In [EMAIL PROTECTED], Jun Kuriyama wrote: #!/bin/sh cat EOF [8bit text which contains 0x82 character] EOF I'm very short of time these days, but here are thoughts and a backtrace: 0x82 == \202 == CTLVAR in the parser. For real variable expansion, the parser inserts \202 into the input string. Furthermore, it is an error that the forking shell doesn't detect that its forked counterpart dumped core. I see two solutions: 1) It seems that you can work around the coredump by looking at the next char after \202. For real expansions of variables in here-documents that is \201. Once can probably determine all possible legal combinations and ignore others. However, that would just prevent this coredump and would not support processing the CTL* chars as literal chars in here-documents, at the very least they will be eaten. 2) move the CTL* stuff from expand.h to values outside the char domain. Do do this, all input strings must be converted from char* to int* in the first steps of the parser, all buffers must hold int*, which means that they cannot be displayed to the terminal or presented as input to external programs without converting them back. Of course, I will do the latter :-) However, I'm in the middle of preparation for a job interview, so that is not possible right now. Anyone trying to fix this, especially going the first path, keep in mind that you must not break variable expansion in here-documents: foo=42 cat EOF echo $foo EOF (gdb) bt #0 evalvar (p=0x80b998c "\na;sldk\n", flag=0) at expand.c:783 #1 0x804ce8e in argstr (p=0x80b9980 "jhsdd903kd\n\202\na;sldk\n", flag=0) at expand.c:245 #2 0x804cc26 in expandarg (arg=0x80b9998, arglist=0x0, flag=0) at expand.c:169 #3 0x804cbbb in expandhere (arg=0x80b9998, fd=3) at expand.c:144 #4 0x8056d22 in openhere (redir=0x80b994c) at redir.c:269 #5 0x8056bd5 in openredirect (redir=0x80b994c, memory=0xbfbff1f8 "") at redir.c:226 #6 0x8056a59 in redirect (redir=0x80b994c, flags=0) at redir.c:157 #7 0x804b9ae in evalcommand (cmd=0x80b9970, flags=1, backcmd=0x0) at eval.c:888 #8 0x804a920 in evaltree (n=0x80b9970, flags=0) at eval.c:269 #9 0x8051a47 in cmdloop (top=1) at main.c:253 #10 0x80519b5 in main (argc=2, argv=0xbfbff3f8) at main.c:202 #11 0x8048135 in _start () -- %%%%% Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /bin/sh dumps core with here-document of 8bit text
In [EMAIL PROTECTED], Hajimu UMEMOTO wrote:
On Fri, 28 Jul 2000 12:09:51 +0900
Jun Kuriyama [EMAIL PROTECTED] said:
kuriyama Shell script which contains here-document of 8bit text sometimes dumps
kuriyama core. For example, please test this script in 4.1 or -current.
I'm using this for workaround on IMASY's main server. 3.5-RELEASE or
later have this problem.
--- bin/sh/parser.c.orig Mon Mar 20 19:51:04 2000
+++ bin/sh/parser.c Fri Jun 30 17:15:38 2000
@@ -909,9 +909,11 @@
for (;;) { /* until end of line or end of word */
CHECKSTRSPACE(3, out); /* permit 3 calls to USTPUTC */
+#if 0
if (c 0 c != PEOF)
synentry = CWORD;
else
+#endif
synentry = syntax[c];
switch(synentry) {
Hm, looks like I broke that in my 8-bit fixes. This code is native in
that it passed control chars further down in the hope noone will
execute them anymore, just taking them for real chars. Nice try.
The problem is also not limited to here-documents:
echo \202 # A real \202
will also dump core.
Since literal strings cannot be made 8-bit clean without further
cleanup, I think we should make this official, although in the
following form, otherwise wrong characters are echoed.
Anyone for whom this fix doesn't work?
Martin
--
%
Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/
BSD User Group Hamburg, Germany http://www.bsdhh.org/
? test2
? test1
? l
? Makefile.cra
? builtins.c
? builtins.h
? mknodes
? nodes.h
? nodes.c
? mksyntax
? syntax.c
? syntax.h
? token.h
? y.tab.h
? y.tab.c
? arith.c
? arith_lex.c
? sh
? l4
? mkinit
? init.c
? sh.1.gz
? .depend
? l3
? l2
? foo
? l5
Index: parser.c
===
RCS file: /home/CVS-FreeBSD/src/bin/sh/parser.c,v
retrieving revision 1.31
diff -c -r1.31 parser.c
*** parser.c2000/05/15 13:02:07 1.31
--- parser.c2000/07/28 07:46:22
***
*** 909,918
for (;;) { /* until end of line or end of word */
CHECKSTRSPACE(3, out); /* permit 3 calls to USTPUTC */
! if (c 0 c != PEOF)
synentry = CWORD;
! else
! synentry = syntax[c];
switch(synentry) {
case CNL: /* '\n' */
--- 909,923
for (;;) { /* until end of line or end of word */
CHECKSTRSPACE(3, out); /* permit 3 calls to USTPUTC */
! if (c = CTLESC c = CTLQUOTEMARK) {
synentry = CWORD;
! fprintf(stderr,
! "Warning: internal control character in "
! "literal text, using '?' instead\n");
! c = '?';
! }
!
! synentry = syntax[c];
switch(synentry) {
case CNL: /* '\n' */
Re: /bin/sh dumps core with here-document of 8bit text
In [EMAIL PROTECTED], Andrey A. Chernov wrote:
On Fri, Jul 28, 2000 at 09:47:08AM +0200, Martin Cracauer wrote:
! if (c = CTLESC c = CTLQUOTEMARK) {
synentry = CWORD;
! fprintf(stderr,
! "Warning: internal control character in "
! "literal text, using '?' instead\n");
! c = '?';
! }
I disagree. It is not the fix, just admitting the bug. Better try to fix it via
some escaping of control characters via some prefix char. Bash is 8bit clean
in that place, f.e.
Please refer to my previous mail. I think it's better to extend the
internal character handling to int* instead of obfuscating it even
more with escape sequences (remember that they are processed multiple
times and such things as taking the length of something, see related
PR fix recently).
Until that is done, we should commit this diff, because it *fixes* the
breakage of coredumping and eating all input (not only th offending
chars), even when it does not solve the problem of not being 8-bit
clean.
Martin
--
%%%%%
Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/
BSD User Group Hamburg, Germany http://www.bsdhh.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: -current of 3 hours ago, can't get GENERIC kernel compiled
In [EMAIL PROTECTED], Andreas Klemm wrote: current of today, very recent. Just to drop you a note. cc -pipe -O -nostdinc -I/usr/src/sys/compile/GENERIC/../.. -I. -I/usr/include-o aicasm aicasm_gram.o aicasm_scan.o aicasm.o aicasm_symbol.o -ll ./aicasm -nostdinc -I- -I. -I../.. -I../../../include -o aic7xxx_seq.h -r aic7xxx_reg.h ../../dev/aic7xxx/aic7xxx.seq ./aicasm: 725 instructions used make: don't know how to make ../../crypto/blowfish/bf_cbc.c. Stop 5.922u 1.575s 0:11.54 64.9% 1350+1091k 312+4io 103pf+0w You need the full crypto stuff, including src/sys/crypto. See example cvsup files. Yes, a HEADS up or an entry to /usr/src/UPDATE would have been great. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Bootstrapping perl (Re: cvs commit: src/gnu/usr.bin/perl Makefile.inc src/gnu/usr.bin/perl/libperl Makefile src/gnu/usr.bin/perl/miniperl Makefile)
[CC'ed to current] In [EMAIL PROTECTED], Martin Cracauer wrote: In [EMAIL PROTECTED], Mark Murray wrote: May I have a login on your build box to have a look? It would be more useful if you could put a log of your buildworld (at least the perl-related parts) somewhere so I can look how EXTERN.h is supposed to be built and where it ends up. Never mind, I'm now through it, this time my tree has hosed due to the testing I did earlier today. Message to others for bootstrapping: Checkout perl (contrib/perl5 and gnu/usr.bin/perl) from -D 2624, build and install it manually, then update both dirs to HEAD and do a world with the new perl in place. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping perl (Re: cvs commit: src/gnu/usr.bin/perl Makefile.inc src/gnu/usr.bin/perl/libperl Makefile src/gnu/usr.bin/perl/miniperl Makefile)
In [EMAIL PROTECTED], Warner Losh wrote: In message [EMAIL PROTECTED] Martin Cracauer writes: : [CC'ed to current] : Message to others for bootstrapping: : : Checkout perl (contrib/perl5 and gnu/usr.bin/perl) from -D 2624, : build and install it manually, then update both dirs to HEAD and do a : world with the new perl in place. Does this mean that I need to add a ntoe to UPDATING? I rather think that it should be fixed. Imagine going from 4-stable to 5-current: in that case you probably can't build the 2624 version manually due to other reasons. Since I'm now through it, I don't know the latest problem, but the last thing I saw that the old lib got used with the new perl (or the other way round) and that looks like it can be fixed with some path adjustments. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping perl (Re: cvs commit: src/gnu/usr.bin/perl Makefile.inc src/gnu/usr.bin/perl/libperl Makefile src/gnu/usr.bin/perl/miniperl Makefile)
In [EMAIL PROTECTED], Mark Murray wrote: Message to others for bootstrapping: Checkout perl (contrib/perl5 and gnu/usr.bin/perl) from -D 2624, build and install it manually, then update both dirs to HEAD and do a world with the new perl in place. Now you can colour me flummoxed. :-(. Have you a script(1) of that? Sorry, my -current box is now through it. If I'm not mistaken, all open problems are like "Perl lib version (v5.6.0) doesn't match executable version (5.00503) at Config.pm line 18." That should be easy to reproduce on your development system by just copying an old /usr/bin/perl executable to it and trying to build. Martin -- %%%%% Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)
In [EMAIL PROTECTED], Poul-Henning Kamp wrote: Am I the only person who miss a brief document which tells what the outcome of the meeting was ? Who was there, anyway? Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
In [EMAIL PROTECTED], Luoqi Chen wrote: In [EMAIL PROTECTED], Luoqi Chen wrote: It is not the loader's job to detect the underlying hardware configuration. I disagree. I would like to tell which machine I am booting on to choose an appropriate kernel. Eventually (it may take a while) we should be able to boot any i386/AT based machine with a single kernel which dynamically loads drivers for available hardware (and different locking modules for UP and SMP for that matter). I have such a kernel for all my machines except SMP. However, I still boot different UP kernels on each machines for testing purposes: - different 'cpu I..._CPU' settings - different floating emulators - much or few RAM I don't want to detect all hardware, what I need is one way to tell each machine from each other, like a hostid. The ethernet address of the first card could be. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Oddities with the new binutils
In [EMAIL PROTECTED], Martin Cracauer wrote: In [EMAIL PROTECTED], David O'Brien wrote: On Fri, Jun 02, 2000 at 04:42:29PM +0930, Matthew Thyer wrote: Three issues: - floating point math doesn't seem to work properly: I don't have a -current machine I want to delete all ports from, but I have a -current from yesterday, I compiled xaos on it and libpng, which is the only dependency of xaos. That leave XFree as the only non-recompiled thing in the chain. Works fine. OK, now I am pissed. I also recompiled and restarted X11 to trace this down, only to find that some stupid error in Xwrapper breaks xinit and I had to roll my own xinit. Anyway, now I am running everything in the pipe compiled within the last 24 hours on a fresh -current and xaos work just fine. It could also be poorly written ASM code in the things you were running. The old Binutils let people write inconsistent and illegal ASM. xoas and png themself do not have assembler files. Xfree servers have some, but not in floating point related things. Where is the information that this is a floating-point problem from? Matthew, do you possibly use a custom gcc from /usr/local/bin and the native assembler or vice versa? Also, what level of optimization do you use? Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Internal compiler error: program ld got fatal signal 10
In [EMAIL PROTECTED], Steve Kargl wrote: First, the error message: cc -fpic -DPIC -I/usr/src/lib/libmd -DSHA1_ASM -DELF -DRMD160_ASM -DELF -I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libmd/i386/rmd160.S -o rmd160.So building shared library libmd.so.2 cc: Internal compiler error: program ld got fatal signal 10 *** Error code 1 Stop in /usr/src/lib/libmd. *** Error code 1 Now, the details. I started on Monday trying to update a 15 March 00 -current to current -current. I get the above error message with a source tree after *default date=2000.05.23.00.00.00 Have you tried building and installing the new binutils before compiling the rest of the world? Some assembler files are not compatible with the old binutils. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Internal compiler error: program ld got fatal signal 10
In [EMAIL PROTECTED], Warner Losh wrote: In message [EMAIL PROTECTED] Martin Cracauer writes: : Have you tried building and installing the new binutils before : compiling the rest of the world? This shouldn't be required for buildworld. If it is, then it is a bug in the buildworld process. Buildworld makes all the stuff it needs to build things, unlike the kernel. I know that it is supposed to do so, I suspect that might not be the case here. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic: pmap_enter: attempted pmap_enter on 4MB page
I'm getting the appended panic when starting Xfree86 under a -current
from today. I rebuild/reinstalled binutils (and kernel afterwards)
and sys/boot.
This is a single-processor machine (I noted that SMP people got the
same error).
#0 boot (howto=256) at ../../kern/kern_shutdown.c:303
#1 0xc01e9e71 in panic (
fmt=0xc03a1d20 "pmap_enter: attempted pmap_enter on 4MB page")
at ../../kern/kern_shutdown.c:553
#2 0xc032b4d2 in pmap_enter (pmap=0xc0419240, va=3229622272, m=0xc09238d4,
prot=7 '\a', wired=0) at ../../i386/i386/pmap.c:2023
#3 0xc02e926c in vm_fault (map=0xc040bd8c, vaddr=3229622272,
fault_type=1 '\001', fault_flags=0) at ../../vm/vm_fault.c:829
#4 0xc032ddda in trap_pfault (frame=0xc8b12d68, usermode=0, eva=3229624448)
at ../../i386/i386/trap.c:809
#5 0xc032d9e7 in trap (frame={tf_fs = -1069940720, tf_es = -928055280,
tf_ds = 16973840, tf_edi = -1077968896, tf_esi = -1065342848,
tf_ebp = -927912488, tf_isp = -927912556, tf_ebx = 1920, tf_edx = 0,
tf_ecx = 480, tf_eax = -1077966976, tf_trapno = 12, tf_err = 9,
tf_eip = -1070413303, tf_cs = 8, tf_eflags = 78338, tf_esp = 1920,
tf_ss = -927912228}) at ../../i386/i386/trap.c:426
#6 0xc032ca09 in generic_copyout ()
#7 0xc0328af6 in mmrw (dev=0xc0401348, uio=0xc8b12edc, flags=0)
at ../../i386/i386/mem.c:184
#8 0xc02246af in spec_read (ap=0xc8b12e90)
at ../../miscfs/specfs/spec_vnops.c:261
#9 0xc02e610c in ufsspec_read (ap=0xc8b12e90)
at ../../ufs/ufs/ufs_vnops.c:1828
#10 0xc02e6609 in ufs_vnoperatespec (ap=0xc8b12e90)
at ../../ufs/ufs/ufs_vnops.c:2305
#11 0xc021fa34 in vn_read (fp=0xc0f7f9c0, uio=0xc8b12edc, cred=0xc0f90a00,
flags=0, p=0xc811a3c0) at vnode_if.h:334
#12 0xc01f9ea5 in dofileread (p=0xc811a3c0, fp=0xc0f7f9c0, fd=4,
buf=0xbfbf7780, nbyte=32768, offset=-1, flags=0) at ../../sys/file.h:141
#13 0xc01f9dab in read (p=0xc811a3c0, uap=0xc8b12f80)
at ../../kern/sys_generic.c:111
#14 0xc032e42d in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 0, tf_esi = 32768, tf_ebp = -1077971160, tf_isp = -927911980,
tf_ebx = 4, tf_edx = 0, tf_ecx = 0, tf_eax = 3, tf_trapno = 12,
tf_err = 2, tf_eip = 674549244, tf_cs = 31, tf_eflags = 12870,
tf_esp = -1077971184, tf_ss = 47}) at ../../i386/i386/trap.c:1126
#15 0xc0322365 in Xint0x80_syscall ()
#16 0x80925af in ?? ()
#17 0x811e317 in ?? ()
#18 0x814f1d0 in ?? ()
#19 0x814d235 in ?? ()
#20 0x8173a48 in ?? ()
#21 0x807c309 in ?? ()
(kgdb)
--
%%%%%
Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/
BSD User Group Hamburg, Germany http://www.bsdhh.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: One more question (different now)
In [EMAIL PROTECTED], Sheldon Hearn wrote: On Thu, 11 May 2000 03:58:57 +0200, Bernd Luevelsmeyer wrote: The Standard itself is a book and can be bought as such in bookstores. Can you give us details? Do I just hunt Amazon.com for "C99", or does it have a proper title? I need this one. "Not yet" is what comp.std.c says, but any time soon. It is excepted to be available as a cheap PDF like the C++ standard. [info could be out of date, didn't check news for weeks] Martin -- %%%%% Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libstand ext2fs
In [EMAIL PROTECTED], Adam wrote: On Sat, 29 Apr 2000, Jonathan Lemon wrote: On Sun, Apr 30, 2000 at 11:15:47AM +0930, Greg Lehey wrote: On Saturday, 29 April 2000 at 13:44:08 -0700, Jonathan Lemon wrote: jlemon 2000/04/29 13:44:08 PDT Added files: lib/libstand ext2fs.c Log: Add ext2fs support to the loader. What's the need for this? It allows us to see linux partition types, and load from them; I should be able to boot a freebsd kernel and memory image from a pure linux box, although I've only used it to load the kernel at this point. -- Jonathan wishlist Not sure if this is a silly question or not, but could the kernel somehow view a specific dir on a ext2fs disk as the freebsd root and boot a freebsd system from it? Also being able to access the stuff below the freebsd root on the ext2fs partition would be cool. Any idea how much work it might take someone to do this? An alternative would be mounting a file on the ext2fs via vn as the freebsd root containing a freebsd install on ffs or ext2. This way might make it easier to have access to the underlying ext2 and make it easier for the base linux system to populate / modify if linux has trouble with ffs. /wishlist Just modify /sbin/init to do a changeroot before anything else. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Floating point exceptions.
In [EMAIL PROTECTED], David Malone wrote: Floating point exceptions seem to have been turned off by default: [...] There was a discussion on one of the list about what to do for floating point excpetions recently, and I thought people decided that causing a signal by default was a right thing? The outcome was that applications that care must set the control word themself and that we go the way of least resistance for the rest. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Floating point exceptions.
In [EMAIL PROTECTED], David Malone wrote: There was a discussion on one of the list about what to do for floating point excpetions recently, and I thought people decided that causing a signal by default was a right thing? The outcome was that applications that care must set the control word themself and that we go the way of least resistance for the rest. OK - I just did a quick scout around. Digital Unix gives a SIGFPE; Solaris, AIX and Redhat print some captalisation of "Inf"; HP/UX prints "++.00" ;-) Is there a way of setting the control word which is in any sense portable? It is an i386 assembler instruction. Obviously, operating system vendors thought it's not their business, but the compiler's. Unfortunately, gcc doesn't care (although most other native compilers like SRC m3, CMUCL, SML/NJ do). FreeBSD's fpsetmask(3) stuff is simple inline assembler that I personally used in Linux, it should be relativly easy to carry it around with your application on i386 machines. Martin -- %%%%% Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Best NIC for FBSD (was: Buffer Problems and hangs in 4.0-CURRENT..)
In [EMAIL PROTECTED], Mike Smith wrote: fxp0: The Intel driver is by far the highest preformance model, beats the 3com (second best) hands down with much lower CPU overhead. Do you actually have any numbers to quantify this? There's nothing in the driver architecture nor any of my testing that would suggest this is actually the case at this point. I appended an old posting of mine. No 3com cards, though. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ Date: Mon, 8 Feb 1999 14:53:25 +0100 From: Martin Cracauer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: 100Mbit ethernet card comparision Message-ID: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i I just had three 100MBit/sec ethernet cards in reach and though I could do a little experimenting: Operating Systems: FreeBSD: FreeBSD-current from Jan, 22, 1999 (before 4.0 branch) Linux: 2.2.0-pre9, userland mostly Debian-1.3.1 Ethernet cards: de - DEC 21140 fxp - Intel 82558 rl - Realtek 8139 Machine: Celeron 300A in Asus P2B (BX) at 4.5x83.5MHz Benchmark: Send 1 GB of data over a rsh connection, using cstream (a dd replacement with accurate timing, bandwidth limiting and /dev/null built in), using 8 KB blocks. The CPU numbers are taken from top(1) with a delay of 15 seconds. OS CardMioByte/sec %user %sys%interrupt -- Linux de 10.93-10.96 3 26-28 - FreeBSD de 10.70-10.72 3 29-31 4-5 FreeBSD fxp 10.66-10.67 3 25-28 5-6 FreeBSD rl 10.55-10.56 3 28-31 14-16 Linux rl 10.85-11.14 3 28-30 - Linux fxp doesn't work The fxp module (eepro100) on Linux loads, but ifconfiging hangs the machine (reset button mode). The de (tulip) driver on Linux needs manual selection of media type, whereas none of the other test combinations did (rl on Linux worked out of the box). Of course, Linux doesn't have section 4 manpages for drivers, so I went through the linux-src/Documentation - C-source - Web site mentioned in there cicle as well. And had to specify options at module load time (as compared to anytime with ifconfig under FreeBSD) and had to calculate hex number OR combinations (where FreeBSD has cleartext options). The Intel chip got hot, the Realtek and DEC stayed cool. Well, one intersting question is: Where's that interrupt handler CPU time on Linux? In system CPU time? Hidden? To get a clearer picture, I did a benchmark that approached the question "If two processes compete, and one just consumes userland CPU and the other just tries to TCP stream over a more or less interrupt intensive device, how much CPU does the CPU-intensive process get?" I run a number of dhrystones one after another so that the time for all of them was about 1 min. Just before the first dhrystone starts, the same TCP streaming benchmark as above is being started, and immedeatly after the dhrystones end SIGHUP is sent to the cstream tool, which ends its loop then and reports the throughput. OS/card seconds r/u/s onthroughput of on CPU process network process - FreeBSD/de: 10.36/10.26/0.022.10 MioB/sec FreeBSD/de: 10.36/10.26/0.022.21 MioB/sec FreeBSD/rl: 10.41/10.24/0.020.38 MioB/sec FreeBSD/rl: 10.39/10.24/0.020.28 MioB/sec FreeBSD/rl: 10.41/10.24/0.020.24 MioB/sec Linux/rl: 27.8/14.7/0.6 8.44 MioB/sec Linux/rl: 22.9/14.4/4.4 6.50 MioB/sec Linux/rl: 26.4/14.7/5.8 7.81 MioB/sec Linux/de: 20.7/14.6/0.9 9.21 MioB/sec Linux/de: 20.5/13.8/1.0 9.14 MioB/sec Linux/de: 21.0/14.2/1.2 9.64 MioB/sec Example read: With rl Ethernet, Linux leaves half the CPU for the CPU intensive process and gets ~8 MB/sec for the networking process, while FreeBSD leaves 99% CPU for the CPU eater and gets 0.25-0.4 MB/sec out of the networking connection. Remark: Don't ask me why a dhrystone takes more CPU on Linux than on FreeBSD. Identical source, gcc-2.7.2.x, timings verified with stopwatch etc. Probably a symbol more in a shared library. It is not a typo that time(1) reports significant system CPU for the dhrystones on some (but not all) of the Linux/rl runs. Definitivly bad accounting here. Quick shot answer: this looks like the time spent in the interrupt handle is being added to unrelated userland processes. Glad I asked: The supposed ninja-macho networker's tool FreeBSD is actually a little slower, while the supposed we-have-more-drivers-and-every-idiot-can-configure-them OS runs on one out of three cards without problems, one with enough digging to drive
Re: extern variables in shared libraries broken (ld.so or mmap bug)
Updates on the -fpic bug: Satoshi has been so kind to point me to the ports build logs. Out of 1672 files compiled with -fpic, 1033 of them with -O1, none triggered the assembler warning message. I would now feel reasonably comfortable to resolve the issue for Release 4.0 by : - committing Bruce' "wave-dead-chicken" fix for localtime.c (remove the "const" so that gcc doesn't try its wrong optimization). -O2 world for localtime.c as well, BTW. - turning the assembler warning message into an error, using Bruce' diff (I originally feared that we would break more ports than we could handle). Except that I would extend the error message with "try different optimization settings" to give people a chance to recover. - hope that gcc and gas agree over their capabilities when 4.1 comes... Any objections? If none, Jordan, would you please approve us to do so? Martin -- %%%%% Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: extern variables in shared libraries broken (ld.so or mmap bug)
In [EMAIL PROTECTED], Bruce Evans wrote: On Fri, 25 Feb 2000, Martin Cracauer wrote: It is possible that we indroduced the bug by our profiling changes? The line in i386.c that generates the code in question is from revision 1.5, which is the profiling delta from the original gcc. In that case we can't count on a new gas fixing it for us. Reverting to the FSF version of i386.c didn't fix the problem. I build libc with an unchanged gcc-2.95.2 (except assert.c, which needs our compiler) and it has the problem as well. What do you think, is this a showstopper for 4.0? Yes, me thinks. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: extern variables in shared libraries broken (ld.so or mmap bug)
In [EMAIL PROTECTED], David O'Brien wrote: On Wed, Feb 23, 2000 at 02:31:01PM +0100, Martin Cracauer wrote: Where's the bug, anyway? Do we need to fix the compiler or would it be better to get a newer assembler? A new assembler (whole binutils) is on the way, probably around the end of March. In my opinion, we need a fix before 4.0. At the very least the assembler warning must be turned into an error. It is also not clear to me that the new assembler really fixes the bug. While I cannot judge over the correctness of the syntax, I think it is possible that the new assembler still works on the same syntax, not recognizing the parameterless GOTOFF our gcc generates. It is possible that we indroduced the bug by our profiling changes? The line in i386.c that generates the code in question is from revision 1.5, which is the profiling delta from the original gcc. In that case we can't count on a new gas fixing it for us. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: extern variables in shared libraries broken (ld.so or mmap bug)
Updates on the "moving" symbols problem: The problem with gdb not finding out the type of tzname[] is caused by the shared libs not being built with -g. It probably doesn't have to do with the problem. I appended a tarfile with some test cases. Case 1-3 show different occasions of the error, all dump core when linked dynamically and work fine with -static. 'shlib3.gdb' fed into gdb will show that the symbol address is a moving target. Case 4 is an attempt to reproduce the error I get with tzname[] from libc.so with a newly constructed shared library and a similar symbol. However, this case works fine and I don't understand the difference so far. Set LD_LIBRARY_PATH=`pwd` to run this test case. I have updated two machines to -current from yesterday, no change in the problem. As I suspect the MMU hardwware may influence the problem, here are the CPU ids from the machine I can reproduce the error on (that doesn't mean I have -current machines where the error does not show up): CPU: Pentium Pro (199.31-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping = 9 Features=0xf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV CPU: Pentium/P54C (99.95-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping = 12 Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 Let me repeat that this looks like a serious memory mapping bug and that we must not ship 4.0 until we gain more knowledge about it. Martin -- %%%%% Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 shlib.tar.gz
Re: extern variables in shared libraries broken (ld.so or mmap bug)
[CC'ed David, since the new compiler seems to cause the problems]
Sorry for the update bombing, but I found that the file where the
tzname symbol is being defined in triggers this error mesage in a
`make world`:
cc -fpic -DPIC -O -pipe -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/include
-D__DBINTERFACE_PRIVATE -DINET6 -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale
-DBROKEN_DES -DYP -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/lib/libc/../libc/stdtime/localtime.c -o localtime.So
{standard input}: Assembler messages:
{standard input}:87: Warning: warning: unrecognized characters
`@GOTOFF' in expression
{standard input}:114: Warning: warning: unrecognized characters
`@GOTOFF' in expression
The assembler code looks like this (not that it is surrounding the
symbol we have problems with):
.L18:
leal (%edi,%edi,4),%edx
leal 1868+lclmem@GOTOFF(%ebx),%eax [1]
leal (%eax,%edx,4),%edx
movl tzname@GOT(%ebx),%esi
movl 4(%edx),%ecx
sall $2,%ecx
movl %ebx,%eax
addl 8(%edx),%eax
addl $6988+lclmem@GOTOFF,%eax [2]
movl %eax,(%ecx,%esi)
incl %edi
movl -4(%ebp),%eax
cmpl 8(%eax),%edi
jl .L18
Note that 'as' complains about [2], [1] is fine.
I'm not that familar with gas syntax, but it seems to be that this is
a syntax error generated by the new gcc, that @GOTOFF must be passed
one argument.
/usr/src/contrib/gcc/config/i386/i386.c:2988 seems to be the line that
writes the GOTOFF without an argument.
Martin
--
%
Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: extern variables in shared libraries broken (ld.so or mmap bug)
In [EMAIL PROTECTED], Bruce Evans wrote:
diff -c2 localtime.c~ localtime.c
*** localtime.c~ Fri Jan 28 17:29:18 2000
--- localtime.c Wed Feb 23 22:51:34 2000
***
*** 220,224
settzname P((void))
{
! register struct state * const sp = lclptr;
register inti;
--- 220,224
settzname P((void))
{
! register struct state * sp = lclptr;
register inti;
This seems to fix some of your prooblems.
It works as follows: when sp is declared as const, gcc decides not to
keep in a register in the default !ALL_STATE case (lclptr is lclmem in
this case), since it can "easily" be recovered by computing the address
constant lclmem. However, computing the constant turns out to be not
so easy in the -fpic case -- it takes an extra 8 instructions, including
a pessimization which gives the bug.
My initial next question would be how this bad code in localtime.c can
affect straight references from the calling program to the symbol
tzname[] without calling code in localtime. And why write accesses
succeed and read accesses fail.
Looking on the assembler code, I guess that the wrong code in
localtime.c leave a wrong value in %ecx, why is used as a base address
by rtld.
Once the wrong code is called, the symbol table is messed up. However,
some calls such as the write test in my shlibs3 example still succeed
because the compiler saved/cached the address from a previous call
(which he is allowed to since the address is constant). Once the code
goes through normal rtld lookup again, it bombs.
Right?
I am not sure how harmless this bug is. `make world` output shows that
the as warning message only occurs in localtime.c. I think a
workaround might be to fix as you suggest and turn the assembler
warning into an error, although in that case users might not be able
to compile valid code into shared libraries.
Where's the bug, anyway? Do we need to fix the compiler or would it be
better to get a newer assembler?
Martin
--
%%%%%
Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Interesting failure mode for static linking with shared libs.
In [EMAIL PROTECTED], Jordan K. Hubbard wrote: root@zippy- cc -fPIC -c stub.c root@zippy- ld -shared -o stub.so stub.o root@zippy- cc -static test.c -o test stub.so root@zippy- ./test ELF interpreter /usr/lib/libc.so.1 not found Abort trap root@zippy- cc -static test.c -o test stub.o root@zippy- ./test Now in the client, calling doit() You have reached the stub. Please leave a message. As a workaround for a static binary, you should be able to use -Xlinker -Bstatic instead of -static -static links the libs statically and also leaves out the dynamic loading code from the binary. The former leaves the dynamic loading code in the binary, but links the libs statically. You have a slightly bigger binary, but you don't need the libs at runtime and you are resistent against changed/faked libs, which might do the job you want static linking for. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crashing netscape?
In [EMAIL PROTECTED], Alex Le Heux wrote: Hi, Am I the only one who's experiencing an amzing amount of crashes on Netscape? This made a real difference in stability for me: Before installing a new Netscape, rm -rf /usr/local/lib/netscape rm -rf /home/*/.netscape Seriously, when I had old config stuff lying around, Netscape's crash frequency was about 10 times as much as it is now that I clean up before upgrading. Turning off Javascript also helps, but may be contraproductive. Also, consider Netscape 3.04 for stability. BTW, does anyone know if its possible to write a plugin for the BSDI version of Navigator 3.04 so that it display *.png files as it displays *.gif files now? As I understand, a plugin doesn't have fine enough access to the display code to do this, right? Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
extern variables in shared libraries broken (ld.so or mmap bug)
I am trying to hunt the strptime(..., "%+", ...) bug down. It looks
like a showstopper dynamic linker bug in 4.0 now. I suspect that
extern variables located in shared variables are broken, either by a
ld.so or a mmap bug.
In a dynamically linked program, it looks like the address of the
symbol "extern char *tzname[];" changes at runtime. You can write to
it as much as you like, but if you read it, the address points to the
void and the program dumps core. gdb displays very odd stuff, probably
reflecting a change in the underlying memory mapping.
When you link the program statically, it runs fine.
Try this program:
#include stdio.h
#include time.h
int
main(void)
{
fprintf(stderr, "Address of tzname: %p\n", tzname);
tzname[0] = "ERA";
fprintf(stderr, "Address of tzname: %p\n", tzname);
tzname[1] = "ERA";
fprintf(stderr, "Address of tzname: %p\n", tzname);
tzset();
fprintf(stderr, "Address of tzname: %p\n", tzname);
fprintf(stderr, "Values: '%s', '%s'\n", tzname[0], tzname[1]);
return 0;
}
Run it in gdb, using this .gdbinit:
file test2
b main
r
display tzname
n
n
Breakpoint 1, 0x80484ab in main () at test2.c:7
7 fprintf(stderr, "Address of tzname: %p\n", tzname);
Address of tzname: 0x8049638
9 tzname[0] = "ERA";
1: {data variable, no debug info} (void *) 0x8049638 = 671997369
10fprintf(stderr, "Address of tzname: %p\n", tzname);
1: {data variable, no debug info} (void *) 0x8049638 = 134514018
Now, look at the addresses printed by gdb: The hex addresses are the
same, but the decimal ones are not.
Also, the type of variable tzname is defined in scope, gdb should be
able to gather it.
Further down, when accessing tzname[0] or tzname[1] for reading, the
program dumps core, both when running in gdb and running standalone.
As I said, everything works fine when linking statically. In
3.4-stable, all is well for static and dynamic linking.
Martin
--
%
Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Hardwiring SCSI device ID broken?
In [EMAIL PROTECTED], Peter Wemm wrote: Igor Timkin wrote: Martin Cracauer wrote: It seem hardwiring SCSI devices is broken in -current: dmesg would be useful, otherwise we can't even begin to guess what happened. I can't provide it now. The machine is in production use this week (which I didn't expect when I posted the question). Sorry Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hardwiring SCSI device ID broken?
In [EMAIL PROTECTED], tele danmarQ kvindeservice wrote: On Mon, 7 Feb 19100, Martin Cracauer wrote: It seem hardwiring SCSI devices is broken in -current: dmesg would be useful, otherwise we can't even begin to guess what happened. I can't provide it now. I don't have it in /var/log/messages, but I can reboot my machine (that has this problem) and copy down what I see. If it has been thrown out by newer kernel messages, try /var/run/dmesg.boot Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Hardwiring SCSI device ID broken?
It seem hardwiring SCSI devices is broken in -current: LINT seems to recommend: device ahc device scbus0 at ahc0 device scbus1 at ahc1 bus 0 device sa0 at scbus1 target 4 device sa1 at scbus1 target 5 device cd0 at scbus1 target 6 device cd1 at scbus1 target 2 However, config rejects it: config: line 239: ahc 0 not defined config: line 240: ahc 1 not defined Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 4.0-RELEASE hardware specs, advice/experience requested
In [EMAIL PROTECTED], Nathan Kinsman wrote: Intel EtherExpress PRO/100+ Dual Port NIC (this is recognized as two fxp devices?) I have not been running CURRENT extensively, so I would like to know anyone's experiences with any of the above hardware, or any recommendations on hardware with a better price/performance ratio at a low thermal (chassis is very compact). Last time I checked the fxp chips got much hotter than either a DEC 21143 or a realtek 8139 (which is otherwise unrecommended). Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sh(1) broken caching [was: Re: Broken sh(1)?]
In [EMAIL PROTECTED], Brian Fundakowski Feldman wrote: On Fri, 17 Dec 1999, Martin Cracauer wrote: I still think we should *seriously* consider switching to pdksh. As I said before, pdksh has other bugs. Also we would loose all the PRs we received in the past. This testing effort by our user base is a valuable resource. From the tests I ran on all available shells, only bash2 is considerably better than the other shells, pdksh has other bugs than our ash, not less. HAHAHAHAHAHAHAHAHAHAhahahahahahahahahahahaha *cough, HACK, wheeze*. Ahem. Heh, bash2 considerably better. *continues ROFL* Over the last year, I did an extensive amount of testinging on bourne shell behaviour. bash2 was the only free sh clone that I never had to complain over. Is there something substantially you'd like to contribute to the discussion, like - say - an example where bash-2.03 doesn't work well? If your experience is based on old bash1 stuff, forget it. bash got improved greatly since it is used as the standard shell for a UNIX clone in wide use. Just like our shell improved from the beatings it got because it has been the standard script-executing shell on FreeBSD and NetBSD for (together) 10 years now. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sh(1) broken caching [was: Re: Broken sh(1)?]
In [EMAIL PROTECTED], Brian Fundakowski Feldman wrote: Is there something substantially you'd like to contribute to the discussion, like - say - an example where bash-2.03 doesn't work well? It's definitely broken on some of my scripts before. If you want me to go try to find one of those cases, I will. That would be nice. I'm collecting items for a formal, automatic test suite. That goes to every reader of this list, of course :-). Thanks Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sh(1) broken caching [was: Re: Broken sh(1)?]
In [EMAIL PROTECTED], David O'Brien wrote: On Thu, Dec 16, 1999 at 03:40:20PM +0100, Martin Cracauer wrote: You can also fool sh into running the *wrong* binary if if you have two in showdowed paths: pdksh does not suffer from either this problem or the problem that started this thread (and does not coredump). We've shown in the past that pdksh is actually smaller (when linked statically) than ash. I still think we should *seriously* consider switching to pdksh. As I said before, pdksh has other bugs. Try this in pdksh: #! /bin/sh emacs -nw /tmp/bla mv /tmp/bla /tmp/bla2 Two times: - first run, do not hit C-g in emacs - second run, use C-g in emacs In the second run, the `mv` will not be executed, while in the first it will. This is not a bug, but a design decision in pdksh (see also my homepage - sigint.html). It's poor man's workaround about programs that don't exit with a proper signal status when they exit on a signal. Also we would loose all the PRs we received in the past. This testing effort by our user base is a valuable resource. From the tests I ran on all available shells, only bash2 is considerably better than the other shells, pdksh has other bugs than our ash, not less. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sh(1) broken caching [was: Re: Broken sh(1)?]
You can also fool sh into running the *wrong* binary if if you have two in showdowed paths: #! /bin/sh test -d foo1 || mkdir foo1 test -d foo2 || mkdir foo2 test -d foo2 || mkdir foo3 echo 'echo :one' foo1/run echo 'echo :two' foo2/run echo 'echo :three' foo2/run3 chmod a+x */run* hash -r echo echo Expect one: PATH=./foo3:./foo1:./foo2:./foo5 echo Expect two: PATH=./foo3:./foo3:./foo1 run echo run should be in in foo1: hash -v echo $PATH echo Should give one: run == runs foo2/run, not foo1/run. This is still covered by the quick fix I sent. Looking for cases that aren't... Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sh(1) broken caching [was: Re: Broken sh(1)?]
In [EMAIL PROTECTED], Marcel Moolenaar wrote: Sheldon Hearn wrote: On Tue, 14 Dec 1999 15:42:11 +0100, Marcel Moolenaar wrote: You set all those variables for the first make command, but not for the second. What did you expect to happen? That make(1) would execute. But what was the PATH set to _before_ you set it for the first execution of make? That's what's important, surely? It is. Try this: scones% sh % echo $PATH /sbin:/bin:/usr/sbin:/usr/bin: % hash -v builtin hash builtin echo % which ls /bin/ls % hash -v builtin hash builtin echo /usr/bin/which % PATH=/foo:/bar:/bin ls This line does *not* change $PATH for the next lines. some output % hash -v builtin hash builtin echo /usr/bin/which /usr/sbin/ls Caching index based on temp. path % ls ls: not found $PATH is still /sbin:/bin:/usr/sbin:/usr/bin: Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sh(1) broken caching [was: Re: Broken sh(1)?]
OK, the problem is real. BTW, its worse: #! /bin/sh hash -v PATH=/sbin:/bin PATH=/foo:/bar:/bin ls hash -v ls = coredump Working on it. -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sh(1) broken caching [was: Re: Broken sh(1)?]
In [EMAIL PROTECTED], Marcel Moolenaar wrote:
It seems to me that when there's a PATH= assignment you don't want to
add anything to the cache or alternatively, clear the cache after
execution of the command having a PATH= assignment.
The first solution is better, but the source messes with the hashtable
too directly in too many places.
Appended diff does the second route. Does it fix your problems?
Martin
--
%
Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
? test2
? l
? test1
? sh.core
? builtins.c
? builtins.h
? mknodes
? nodes.h
? nodes.c
? mksyntax
? syntax.c
? syntax.h
? token.h
? y.tab.h
? y.tab.c
? arith.c
? arith_lex.c
? sh
? mkinit
? init.c
? sh.1.gz
Index: Makefile
===
RCS file: /home/CVS-FreeBSD/src/bin/sh/Makefile,v
retrieving revision 1.30
diff -c -r1.30 Makefile
*** Makefile1999/09/08 15:40:43 1.30
--- Makefile1999/12/15 11:24:05
***
*** 18,24
LDADD+= -ll -ledit -ltermcap
LFLAGS= -8# 8-bit lex scanner for arithmetic
! CFLAGS+=-DSHELL -I. -I${.CURDIR}
# for debug:
# CFLAGS+= -g -DDEBUG=2
--- 18,24
LDADD+= -ll -ledit -ltermcap
LFLAGS= -8# 8-bit lex scanner for arithmetic
! CFLAGS+=-DSHELL -I. -I${.CURDIR} -g -Werror
# for debug:
# CFLAGS+= -g -DDEBUG=2
Index: eval.c
===
RCS file: /home/CVS-FreeBSD/src/bin/sh/eval.c,v
retrieving revision 1.26
diff -c -r1.26 eval.c
*** eval.c 1999/11/29 19:10:59 1.26
--- eval.c 1999/12/15 11:24:05
***
*** 612,623
--- 612,625
volatile int e;
char *lastarg;
int realstatus;
+ int do_clearcmdentry;
#if __GNUC__
/* Avoid longjmp clobbering */
(void) argv;
(void) argc;
(void) lastarg;
(void) flags;
+ (void) do_clearcmdentry;
#endif
/* First expand the arguments. */
***
*** 626,631
--- 628,634
arglist.lastp = arglist.list;
varlist.lastp = varlist.list;
varflag = 1;
+ do_clearcmdentry = 0;
oexitstatus = exitstatus;
exitstatus = 0;
for (argp = cmd-ncmd.args ; argp ; argp = argp-narg.next) {
***
*** 688,695
* is present
*/
for (sp = varlist.list ; sp ; sp = sp-next)
! if (strncmp(sp-text, PATH, sizeof(PATH) - 1) == 0)
path = sp-text + sizeof(PATH) - 1;
find_command(argv[0], cmdentry, 1, path);
if (cmdentry.cmdtype == CMDUNKNOWN) { /* command not found */
--- 691,700
* is present
*/
for (sp = varlist.list ; sp ; sp = sp-next)
! if (strncmp(sp-text, PATH, sizeof(PATH) - 1) == 0) {
path = sp-text + sizeof(PATH) - 1;
+ do_clearcmdentry = 1;
+ }
find_command(argv[0], cmdentry, 1, path);
if (cmdentry.cmdtype == CMDUNKNOWN) { /* command not found */
***
*** 887,892
--- 892,899
out:
if (lastarg)
setvar("_", lastarg, 0);
+ if (do_clearcmdentry)
+ clearcmdentry(0);
popstackmark(smark);
}
Index: exec.c
===
RCS file: /home/CVS-FreeBSD/src/bin/sh/exec.c,v
retrieving revision 1.13
diff -c -r1.13 exec.c
*** exec.c 1999/08/27 23:15:11 1.13
--- exec.c 1999/12/15 11:24:05
***
*** 104,110
STATIC void execinterp __P((char **, char **));
#endif
STATIC void printentry __P((struct tblentry *, int));
- STATIC void clearcmdentry __P((int));
STATIC struct tblentry *cmdlookup __P((char *, int));
STATIC void delete_cmd_entry __P((void));
--- 104,109
***
*** 640,646
* PATH which has changed.
*/
! STATIC void
clearcmdentry(firstchange)
int firstchange;
{
--- 639,645
* PATH which has changed.
*/
! void
clearcmdentry(firstchange)
int firstchange;
{
Index: exec.h
===
RCS file: /home/CVS-FreeBSD/src/bin/sh/exec.h,v
retrieving revision 1.8
diff -c -r1.8 exec.h
*** exec.h 1999/08/27 23:15:12 1.8
--- exec.h 1999/12/15 11:24:05
***
*** 69,71
--- 69,72
void defun __P((char *, union node *));
int unsetfunc __P((char *));
int typecmd __P((int, char **));
+ void clearcmdentry __P((int));
Re: sh(1) broken caching [was: Re: Broken sh(1)?]
In [EMAIL PROTECTED], Marcel Moolenaar wrote: Martin Cracauer wrote: In [EMAIL PROTECTED], Marcel Moolenaar wrote: It seems to me that when there's a PATH= assignment you don't want to add anything to the cache or alternatively, clear the cache after execution of the command having a PATH= assignment. The first solution is better, but the source messes with the hashtable too directly in too many places. Appended diff does the second route. Does it fix your problems? It fixes the examples and thus my problems :-) I already created a work-around in `make buildworld' so it works on older shells without the need to build sh(1) in the bootstrap stage, because the bug only pops up when doing a parallel make (ie make -jN) because each command will be executed by the same shell instance in that case. I would like you to do so, since I'd like to give the better solution a shot over the weekend. BTW: Don't forget to remove '-g' from CFLAGS when you commit the patch :-) Ops :-) Now working with a seperate Makefile (for bumping Warning levels). Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sh bug
In [EMAIL PROTECTED], Jean-Marc Zucconi wrote:
Steve Price writes:
On Mon, 8 Nov 1999, Jean-Marc Zucconi wrote:
# Jean-Marc Zucconi writes:
#
# Try this in -current
# $ cat some_file | head
#
# I have to use ^C to regain control.
#
# ... and reverting to rev. 1.22 of eval.c fixes the problem.
Does revision 1.24 work?
I told you that it worked, but in fact it does not :-)
Please watch your 'To: ', you didn't address me.
Today I encountered again the problem when doing `man MIME::*' (you
have to install /usr/ports/mail/p5-MIME-Tools). Curiously, I have no
problem with `man \*'
Again reverting to eval.c r1.22 solve the problem.
I can now reproduce the problem. Please test the appended diff which
should fix this problem while still working for the
here-backquote-three-stage-pipeline case.
My apology especially to Bruce, I managed to pass your test case by
not copy/pasting it, but typing it in with "bits" missing :-(
Martin
--
%%%%%
Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/
BSD User Group Hamburg, Germany http://www.bsdhh.org/
? l
? builtins.c
? builtins.h
? mknodes
? nodes.h
? nodes.c
? mksyntax
? syntax.c
? syntax.h
? token.h
? y.tab.h
? y.tab.c
? arith.c
? arith_lex.c
? sh
? mkinit
? init.c
? sh.1.gz
Index: eval.c
===
RCS file: /home/CVS-FreeBSD/src/bin/sh/eval.c,v
retrieving revision 1.24
diff -c -r1.24 eval.c
*** eval.c 1999/11/07 17:07:05 1.24
--- eval.c 1999/11/17 14:07:13
***
*** 499,505
close(prevfd);
}
if (pip[1] = 0) {
! if (prevfd 0)
close(pip[0]);
if (pip[1] != 1) {
close(1);
--- 499,505
close(prevfd);
}
if (pip[1] = 0) {
! if (!(prevfd = 0 pip[0] == 0))
close(pip[0]);
if (pip[1] != 1) {
close(1);
Re: shell pipeline bug
In [EMAIL PROTECTED], Bruce Evans wrote: `man sh' now hangs when the pager is exited. This is caused by the recent change to sh/eval.c My fix in 1.23 of eval.c was broken, but Steve repaired it in 1.24. Do you have 1.24? Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: shell pipeline bug
In [EMAIL PROTECTED], Bruce Evans wrote: On Fri, 12 Nov 1999, Martin Cracauer wrote: In [EMAIL PROTECTED], Bruce Evans wrote: `man sh' now hangs when the pager is exited. This is caused by the recent change to sh/eval.c My fix in 1.23 of eval.c was broken, but Steve repaired it in 1.24. Do you have 1.24? Yes, of course. Sorry, I can reproduce the hangs with 1.23, while I can't with 1.24. The problem is: A pipe with more data that sh's threshold for forking is and the receiving end process exits before the sending process, not consuming all of the pipe's contents. That exactly what 1.24 fixed (for me :-). Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gdb-4.17 in FreeBSD 4.0-CURRENT
In [EMAIL PROTECTED], Daniel Eischen wrote: Did anyone of you took care that you can build an aout gdb on an ELF FreeBSD system? I don't mean a gdb that is aout, but one that can debug aout binaries. I thought the gdb in our base system could debug aout binaries. Or am I sadly mistaken. You can compile it so that the gdb binary is aout (`cd /usr/src/gnu/usr.bin/binutils make OBJFORMAT=aout), but that's still a debugger that debugs ELF binaries. It can't handle aout binaries unless you explicitly configure it to do so and this ability seems to be broken by the FreeBSD-specific changes. That would be most useful to have as a port. Just step to `/usr/ports/devel/aout-gdb make install` and it uses /usr/src/gnu/usr.bin/gdb or fetches some other source by itself if it can't use native sources. The modula-3 port does something in that line, uses /usr/src if it can. I haven't tested the port on aout. The main reason I did the port was to make an Ada-aware version of gdb. The GNAT maintainers release patches to a specific version of gdb (in this case gdb-4.17), so basing a port of gdb on what's in our base system was a bad idea. The gdb port I mentioned wasn't the Ada-aware gdb port, it was just a step to get there. Well, on second thinking the idea to build from /usr/src might not save much. You need the binutils libraries and friends as aout, so it might be easier to start from a source that carries everything you need with it and link it statically. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
DDB: How to find address of static symbol?
I want to examine and switch a variable in ddb. The variable is static to a source file, I don't have a symbol in ddb. I see the address of the symbol with `nm /kernel | grep symname`, but the addresses listed here are obviously subject to file-specific offsets. The addresses show up twice and I can verify that the data is wrong when I just use the hex address in ddb. How can I get an address suitable for ddb? What are the offsets to add to the symbol addresses I get from nm? Thanks Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DDB: How to find address of static symbol?
In [EMAIL PROTECTED], Bruce Evans wrote: I want to examine and switch a variable in ddb. The variable is static to a source file, I don't have a symbol in ddb. You should have static symbols in ddb, except in the following broken cases: Ops, I did assume this isn't done due to the problem of multiple uses of the same static symbol name and hence I didn't try. In fact it works for me. Thanks. Now down with that FPU thing :-) Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Using float emulator on a system with FPU?
In [EMAIL PROTECTED], Bruce Evans wrote: I'm going to work on FreeBSD's floating point support, but I need to test my changes on systems using the FPU emulators (non-GPL and GPL). Is there any way to use these emulators on a system that has a hardware FPU? Toggling `npx_exists' using ddb used to work. Now, toggling it off on i586 systems causes a panic in the i586-optimised copy routines. This particular problem has a hook in npx.c: device npx0 [...] flags 7 seems to do the trick (disables usage of FPU-optimized mem stuff). I am now able to switch "npx_exists" between npx_probe1() and npx_attach(), which let me run with the emulator on a Pentium. But only from serial kgdb, since as you noted in your other message, symbols are not available to ddb in ELF kernels started with -d. I assume you use kdb_init() from db_elf.c, you how do you call it given that you neither have the symbol (not loaded yet) nor the address (`nm /kernel` output not useful)? [Throwing an egg after the chicken that fails to produce the egg] Martin -- %%%%% Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FP exceptions broken (Re: Interesting bogons from last night's 4.0 snapshot.)
In 17751.927941...@zippy.cdrom.com, Jordan K. Hubbard wrote:
[...]
JFYI - don't want us getting *too* complacent with -current now, do we? :-)
Floating point exceptions are also broken, they always behave like
masked, even if you unmask some explicitly with fpsetmask().
Even worse, a wrong result is returned if an exception had to be
thrown, while the result is right for masked exceptions.
#include stdio.h
#include stdlib.h
#include machine/floatingpoint.h
int main(void)
{
fpsetmask(0);
fprintf(stderr, I want no exception, but an exception value\n);
fprintf(stderr, res: %g\n, atof(1.0) / atof(0.0));
fpsetmask(FP_X_INV|FP_X_DNML|FP_X_DZ|FP_X_OFL|FP_X_UFL);
fprintf(stderr, I want an exception. Or at least an exceptional value\n);
fprintf(stderr, res: %g\n, atof(1.0) / atof(0.0));
fprintf(stderr, I didn't get one!\n);
return 0;
}
output on -current:
I want no exception, but an exception value
res: Inf
I want an exception. Or at least an exception value
res: 1
I didn't get one!
output on anything else:
I want no exception, but an exception value
res: Inf
I want an exception. Or at least an exception value
Floating point exception (core dumped)
Martin
--
%
Martin Cracauer craca...@cons.org http://www.cons.org/cracauer/
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: sh(1) -- exec vs. fork
In 199902191644.laa08...@misha.cisco.com, Mikhail Teterin wrote:
I just finished going through a couple of crontabs prepending the
command-lines with ``exec'', when it hit me.
Can shell itself recognize, there will be no more commands and just
proceed to exec without forking? What would this break?
This should never, of course, happen in interactive mode...
The shell's source requires studying, but, may be, a knowledgeable
person can answer right away?
FreeBSD's /bin/sh does a forkless exec in some cases, which is why we
have the echo -n in /etc/rc:
(trap 'exit 1' 2 ; ${script} start ; echo -n)
The problem with not forking is that trap handling is being
broken. Currently, our /bin/sh eliminates one instance when subshells
are started with '(...)', the last command in the brackets is just
exec'ed without fork.
Example:
#! /bin/sh
echo $$
(
echo $$
cat
)
The subshell replaces the outer instances, the pids echoed are the
same.
But this will break asynchronous traps (which are not Posix, BTW),
hence it doesn't do this for the outermost shell of a shell script:
#! /bin/sh
echo $$
cat
The outer shell still exists when cat is exec'ed.
Obviously, while this inconsistent behaviour gets most cases right, it
isn't perfect, as seen in the /etc/rc hack above.
What is needed here is that the process elimination happens only when
no traps are set.
I looked into this in September (with help from Tor Egge), we need a
count of active traps and if traps are active, don't do subshell
elimination. The problem here is that counting active traps isn't that
easy. Also, this would only solve the lower half of the problem, that
too much elimination happens for subshells.
The upper half, that elimination could/should happen for toplevel
shells when the last command of a script is being exectued needs more
thought. I feel uncomfortable having a shellscript running without a
handle to the toplevel controlling shell process. For example, you
might want to use it get the whole process group of everything it
started.
Martin
--
%
Martin Cracauer craca...@cons.org http://www.cons.org/cracauer/
BSD User Group Hamburg, Germany http://www.bsdhh.org/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Promise IDE board docs
In 199902230725.caa02...@y.dyson.net, John S. Dyson wrote: Søren Schmidt said: It should work, but the promise support in the old system is, well, hacky at best. I'm not sure if Promise supports more than one card at a time, but from looking at the chip specs, it should work just fine, and if the hardware works, at least the new driver will support it. I run with two (2) boards, but it appears that certain (all?) versions of the bios require that you remove the chip from all but one board. I did run such a setup as well, but the disks on the first controller with BIOS ran much faster than those on the BIOSless controller. Martin -- % Martin Cracauer craca...@cons.org http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: C++ compliler unable to produce excutables
In pine.bsf.4.05.9901191201190.22232-100...@access1_1.kuniv.edu.kw, Joss Roots wrote: Hi there, Some ports are complaining during early configuration phase using configure that c++ compiler is unable to produce excutables, and the options are -O -pipe is there anything I am missing here, as this is the first time I hear this complain, please help. thanks Do you have egcs or gcc-2.8 or anything else installaed that installs /usr/local/bin/g++? Such extra compilers from ports tend to break. Make sure you use /usr/bin/g++. If it still fails, please post the log of error messages and the usual stuff `uname -a` and such. Martin -- % Martin Cracauer craca...@cons.org http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Please test latest /bin/sh
There had been some trouble with fixing a pipeline bug in /bin/sh. The last version appears to work, although it was developed on observation, not understanding, if you know what I mean ;-) If you have complicated shell scripts, would you please test -current's /bin/sh (with eval.c v. 1.25) on it? Critical are long pipelines, especially in backquote or here-documents and when receivers (not senders) terminate the run. Thanks Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
