Re: ** HEADS UP ** portmap daemon renamed to rpcbind
On Mon, Mar 26, 2001 at 05:24:14PM +0930, Greg Lehey wrote: On Sunday, 25 March 2001 at 23:48:10 -0800, Doug Barton wrote: Greg Lehey wrote: On Wednesday, 21 March 2001 at 10:44:38 -0800, David O'Brien wrote: The Portmapper binary has been renamed from `portmap' to `rpcbind'. Why? So we can be more like sysV This is good? If it's the best path to NFS over IPv6, which seems to be the issue, then sure it's good. Play the ball, not the man. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP ** portmap daemon renamed to rpcbind
On Monday, 26 March 2001 at 18:19:06 +1000, Andrew Reilly wrote: On Mon, Mar 26, 2001 at 05:24:14PM +0930, Greg Lehey wrote: On Sunday, 25 March 2001 at 23:48:10 -0800, Doug Barton wrote: Greg Lehey wrote: On Wednesday, 21 March 2001 at 10:44:38 -0800, David O'Brien wrote: The Portmapper binary has been renamed from `portmap' to `rpcbind'. Why? So we can be more like sysV This is good? If it's the best path to NFS over IPv6, which seems to be the issue, then sure it's good. Play the ball, not the man. I don't have an objection to the change, I was just asking. And "because System V does it this way" has never been a good answer for us. And no, I'm not picking on Doug, just making a point. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent interface/routing changes breaks on-demand PPP
On Sun, Mar 25, 2001 at 02:46:22AM +0100, Brian Somers wrote: On Fri, Mar 23, 2001 at 23:11:56 +, Brian Somers wrote: 1. Ppp is in -auto mode (or a ``set mode auto'' has been done). Here, ppp configures the interface as soon as it sees the ``set ifaddr'' line and never undoes that configuration. An ``add'' with a fixed IP number would never have worked if it's before the ``set ifaddr''. If it's after the ``set ifaddr'', nothing should ever remove it (as the interface will stay configured). 2. Ppp is not in -auto mode. Here, ppp won't assign the interface address 'till IPCP is up. Any attempt to ``add'' a route with a static IP number in ppp.conf should fail. So, the recent routing changes shouldn't have made a difference. Anyone know what I'm missing ? Andre, what does your ppp.conf look like and how are you running ppp ? ppp in -auto mode, "add" is after "set ifaddr" In which case your interface should stay configured despite the link coming down and your route should *not* be deleted. I'll see if I can reproduce this here (I need to upgrade a machine first). This was happening because ppp was deleting then re-adding the interface address when IPCP came up, causing the new routing code to nuke the static route. I've added an optimisation to stop this from happening, so your configuration should work ok again with src/usr.sbin/ppp/iface.c 1.17. You mean, ppp(8) does not do this now if negotiated address does not change? Yep. -- Ruslan ErmilovOracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED]FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.orgThe Power To Serve http://www.oracle.com Enabling The Information Age -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: use md device in /etc/rc.diskless{1,2}
I sent a patch request: http://www.freebsd.org/cgi/query-pr.cgi?pr=25730 -- Falco KrepelPhone: +49-(0)30 - 34 63 - 7 276 GMD-FOKUS Fax:+49-(0)30 - 34 63 - 8 276 Kaiserin-Augusta-Allee 31 e-mail: [EMAIL PROTECTED] 10589 BerlinWWW:http://www.fokus.gmd.de/usr/krepel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: use md device in /etc/rc.diskless{1,2}
I have sent a patch request: http://www.freebsd.org/cgi/query-pr.cgi?pr=25730 -- Falco KrepelPhone: +49-(0)30 - 34 63 - 7 276 GMD-FOKUS Fax:+49-(0)30 - 34 63 - 8 276 Kaiserin-Augusta-Allee 31 e-mail: [EMAIL PROTECTED] 10589 BerlinWWW:http://www.fokus.gmd.de/usr/krepel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: newcard/cardbus instabilities
In message [EMAIL PROTECTED] Mike Smith writes: : This looks OK, though you might want to disable the pccard support, since : it's known to be broken right now. pccard support is not broken right now. If there's a "known" issue, I sure don't know about it. Oh, sorry, I'm obviously out of date. The problem that Johny was seeing was that 'device pccard' causes broken interrupt delivery for cardbus cards. If that's meant to work, I can see if I can reproduce it locally. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: use md device in /etc/rc.diskless{1,2}
Hi.
I have diskless-PC which was used /boot/pxeboot. But latest
FreeBSD-current is output below messages and some fsck_nfs problem.
WARNING: MFS is being phased out in preference for md devices
WARNING: Please see mdconfig(8) for details
WARNING: Continuing in 15 seconds
Does someone already rewrite and use mdconfig in /etc/rc.diskless1
and diskless2?
Yes, please find attached; if someone wants to clean these up and commit
them, I'd be greatly indebted.
You also need to apply this diff to /etc/rc (warning, cut-n-paste damage):
--- rc Sun Dec 17 00:24:49 2000
+++ /local0/pxeroot5/etc/rc Tue Jan 23 17:52:20 2001
@@ -201,7 +201,7 @@
# Run custom disk mounting function here
#
if [ -n "${diskless_mount}" -a -r "${diskless_mount}" ]; then
- sh ${diskless_mount}
+ . ${diskless_mount}
fi
# $FreeBSD: src/etc/rc.diskless2,v 1.6 2000/04/27 08:43:48 sheldonh Exp $
#
# rc.diskless2
#
# Build filesystems for diskless operation, potentially more complicated
# than can be handled by /etc/fstab.
#
# Reconstruct /var
mkmd ${diskless_var_size} /var
mtree -p /var -eU -f /etc/mtree/BSD.var.dist 21 /dev/null
touch /var/log/messages
# Copy the templated /dev into a locally-writable version
mkmd ${diskless_dev_size} /mnt
cp -Rp /dev/* /mnt
umount /mnt
mount $md_filesystem /dev
# Build a small /tmp
mkmd ${diskless_tmp_size} /tmp
# $FreeBSD: src/etc/rc.diskless1,v 1.5 2000/01/06 18:17:38 luigi Exp $
#
# /etc/rc.diskless1 - general BOOTP startup
#
# BOOTP has mounted / for us. Assume a read-only mount. We must then
# - figure out our IP by querying the interface
# - fill /mnt (writable) with files from /etc, and then update
# per-machine files from /conf/*/ where * is the IP of the host,
# the IP of the subnet, "default", or nothing.
# - mount /mnt over /etc so we can see the new files.
#
# WARNING: I think you should not change /etc/rc or strange things could
# happen.
#
# The operator is in charge of setting /conf/*/etc/* things as appropriate.
# Typically rc.conf and fstab need to be changed, but possibly
# also other files such as inetd.conf etc.
# chkerr:
#
# Routine to check for error
#
# checks error code and drops into shell on failure.
# if shell exits, terminates script as well as /etc/rc.
#
chkerr() {
case $1 in
0)
;;
*)
echo "$2 failed: dropping into /bin/sh"
/bin/sh
# RESUME
;;
esac
}
# mkmd:
#
# Builds an md(4) disk of the size in $1
# Labels and newfs' it.
# Mounts it on the destination in $2
# Returns the name of the created md device in md_device
# Returns the name of the device containing the filesystem in md_filesystem
mkmd() {
md_device=`mdconfig -a -t malloc -s $1`
chkerr $? "configuring md device"
disklabel -rw $md_device auto
chkerr $? "labelling md device"
md_filesystem=/dev/$md_device"c"
newfs $md_filesystem 21 /dev/null
chkerr $? "making md device filesystem"
mount $md_filesystem $2
chkerr $? "mounting md filesystem on $2"
}
# DEBUGGING
#
# set -v
# Figure out our interface and IP.
#
bootp_ifc=""
bootp_ipa=""
bootp_ipbca=""
iflist=`ifconfig -l`
for i in ${iflist} ; do
set `ifconfig ${i}`
while [ $# -ge 1 ] ; do
if [ "${bootp_ifc}" = "" -a "$1" = "inet" ] ; then
bootp_ifc=${i} ; bootp_ipa=${2} ; shift
fi
if [ "${bootp_ipbca}" = "" -a "$1" = "broadcast" ] ; then
bootp_ipbca=$2; shift
fi
shift
done
if [ "${bootp_ifc}" != "" ] ; then
break
fi
done
echo "Interface ${bootp_ifc} IP-Address ${bootp_ipa} Broadcast ${bootp_ipbca}"
# Build a writable copy of /etc from the initial /etc and files obtained
# from /conf/ip address/etc or /conf/broadcast/etc or /conf/etc.
#
mkmd 4m /mnt
cp -Rp /etc/* /mnt
chkerr $? "copy /etc template"
if [ -d /conf/${bootp_ipa} ] ; then
cp -Rp /conf/${bootp_ipa}/etc/* /mnt
elif [ -d /conf/${bootp_ipbca} ] ; then
cp -Rp /conf/${bootp_ipbca}/etc/* /mnt
else
cp -Rp /conf/default/etc/* /mnt
fi
# Make the new filesystem available as /etc
#
umount /mnt
mount $md_filesystem /etc
# Tell /etc/rc to run the specified script after
# it does its mounts but before it does anything
# else.
#
# This script is responsible for setting up the
# diskless mount environment. This can be
# overriden by /conf/ME/rc.conf.local if, for
# example, you do not want to run the standard
# system /etc/rc.diskless2
diskless_mount="/etc/rc.diskless2"
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
Re: midi causes panic on boot? (update)
Hello Jim, On Sun, Mar 25, 2001 at 07:20:04PM -0500, Jim Bloom wrote: I get a slightly different backtrace, but was able to use my palm pilot as the serial console. I have had this same problem for quit a while (about a month). I suspect a locking issue related to Seigo Tanimura's commit on Feb 25. My last cvsup was within the past 24 hours and the kernel was built in a clean directory. Yes, same experience here. But I unfortunately did not have a serial console handy. Tanimura's commits on March 14th were supposed to help the situation, but they appearently haven't...:-( I can try to get more information if necessary. I am still trying to figure out how to get more. I am not good with ddb, and since the machine will not dump, gdb is not usable locally. (And again, no serial connection handy:-( 'show witness' and 'show mutex' come to mind as two more things I will try in ddb. trace _mtx_lock_sleep(c0ecda08,0,c036d471,268) at _mtx_lock_sleep+0x29a mpu_uartmode(c0ecda00) at mpu_uartmode+0x63 mpu_attach(c0ebd100,c0ebd100,c0ebd100,c0e67080,c04e675c) at mpu_attach+0x25 mpusbc_attach(c0ebd100,c0ebd100,c0ea5ac0,c036e926,1) at mpusbc_attach+0x19 device_probe_and_attach(c0ebd100) at device_probe_and_attach+0x9a bus_generic_attach(c0ea2000,c0ebd080,c0ea5ac0,c0ea2000,c036e935) at bus_generic_attach+0x16 sbc_attach(c0ea2000,c0eadb00,c0ea2000,7,0) at sbc_attach+0x3cc device_probe_and_attach(c0ea2000,c0404c4c,c03f9030,4eb000,c0eadb00) at device_probe_and_attach+0x9a isa_probe_children(c0ea2980,c04e6ff8,c01b1f74,0,4e4c00) at isa_probe_children+0x143 configure(0,4e4c00,4e4000,0,c01277d2) at configure+0x39 mi_startup() at mi_startup+0x68 begin() at begin+0x29 Yes, I think we are looking at the same thing. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
** HEADS UP **: bsd.man.mk changes
Hi! The syntax for declaring manual pages has been changed. The manual pages to be installed can now be listed in a single MAN variable. The old MAN[1-9] syntax is still supported, for backwards compatibility. The plan is to MFC this feature after 4.3 release, and start the deorbit sequence for MAN[1-9] syntax. Developers, please make sure all new Makefiles use the new syntax. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: use md device in /etc/rc.diskless{1,2}
This is a fine solution. I hope it's OK when I add this to my patch request. But I have two remarks. 1. For example you could use the diskless boot procedure for smart clients with a small disk used as swap space. So I think it is better to use swap instead of malloc for var,dev, and tmp. This could be done with a variable (e.g. diskless_swap_enable). What do think about it? 2. Building a dev dir is obsolete when you use DEVFS. So you should distinguish between these two situations. I don't know if you could use one of the "vfs.devfs.*" variables to determine the usage of DEVFS. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildworld dies
Dear FreeBSD'ers with sources as of today, ~ 15:40 GMT (from the dutch mirror), my buildworld dies thus: === sbin/adjkerntz^M cc -O -pipe -march=pentiumpro -Wall -I/usr/obj/usr/src/i386/usr/include -c /usr/src/sbin/adj kerntz/adjkerntz.c^M cc -O -pipe -march=pentiumpro -Wall -I/usr/obj/usr/src/i386/usr/include -static -o adjkernt z adjkerntz.o ^M make: don't know how to make adjkerntz.1. Stop^M *** Error code 2^M ^M Stop in /usr/src/sbin.^M *** Error code 1^M ^M Stop in /usr/src.^M *** Error code 1^M ^M Stop in /usr/src.^M *** Error code 1^M ^M Stop in /usr/src.^M HTH Best regards/mes salutations les meilleures/mit freundlichen Gruessen, Salvo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP **: bsd.man.mk changes
On Mon, Mar 26, 2001 at 06:03:38PM +0300, Ruslan Ermilov wrote: Hi! The syntax for declaring manual pages has been changed. The manual pages to be installed can now be listed in a single MAN variable. The old MAN[1-9] syntax is still supported, for backwards compatibility. The plan is to MFC this feature after 4.3 release, and start the deorbit sequence for MAN[1-9] syntax. Developers, please make sure all new Makefiles use the new syntax. I welcome the changes, but don't think the old version should be removed: third party software uses it, and it would not serve any purpose to break them. Kris PGP signature
Re: ** HEADS UP **: bsd.man.mk changes
On Mon, Mar 26, 2001 at 01:28:09PM -0800, Kris Kennaway wrote: On Mon, Mar 26, 2001 at 06:03:38PM +0300, Ruslan Ermilov wrote: Hi! The syntax for declaring manual pages has been changed. The manual pages to be installed can now be listed in a single MAN variable. The old MAN[1-9] syntax is still supported, for backwards compatibility. The plan is to MFC this feature after 4.3 release, and start the deorbit sequence for MAN[1-9] syntax. Developers, please make sure all new Makefiles use the new syntax. I welcome the changes, but don't think the old version should be removed: third party software uses it, and it would not serve any purpose to break them. I'm definitely with Kris on this one; and I know of at least two other people, who are using the bsd.*.mk files (albeit a little modified), in their work. G'luck, Peter -- If wishes were fishes, the antecedent of this conditional would be true. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NFS over IPv6 is a reason????
gee - being like SysV is more comprehensible than worrying about IPv6 -mo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS over IPv6 is a reason????
On Mon, Mar 26, 2001 at 04:46:45PM -0500, Mike O'Dell wrote: gee - being like SysV is more comprehensible than worrying about IPv6 Perhaps if you're living in 1994 :-) Kris PGP signature
Re: telnet broken with auto-negotiation of encrypt/decrypt change
It's been a couple of days since you sent this e-mail -- did this change get MFC'd as yet, or are we still waiting for approval? Just want to make sure it gets in before the release. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On 23 Mar 2001, Assar Westerlund wrote: Robert Watson [EMAIL PROTECTED] writes: I'm baffled as to why SRA is enabled by default. I'm fine with it being compiled in, but it appears to be substantially interfering with normal TCP operation. Either the negotiation needs to be fixed, or this feature needs to be disabled for 4.3-RELEASE (either at compile-time or run-time is fine). Note that we don't even enable Kerberos* build by default, and even when it is built, negotiation is relatively non-interfering for non-Kerberos environments. I think somebody enabled SRA a long time ago but since autologin was not enabled, nobody noticed this. I've changed this in secure/lib/libtelnet/Makefile:1.19 Jordan: I think we should MFC this before 4.3. Opinions? /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP **: bsd.man.mk changes
In message [EMAIL PROTECTED] Peter Pentchev writes: : I welcome the changes, but don't think the old version should be : removed: third party software uses it, and it would not serve any : purpose to break them. : : I'm definitely with Kris on this one; and I know of at least two other : people, who are using the bsd.*.mk files (albeit a little modified), : in their work. We are using them as well, but don't make heavy use of MANx. However, it would be nice if our Makefiles worked on 4.x and -current systems unchanged like they do now. they even work on 3.x systems, but our glue layer is really gross to make that happen. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Fixing ypbind with TI-RPC
Ok. Friday I sat down and tried to make the -m option to ypbind work correctly using the new TI-RPC code. Unfortunately, my test machine chose that day to eat itself. Even more unfortunately, it was an AMD 900Mhz Thunderbird. Today, I started working on another box and managed to get things to work, but there are some problems that still need solving. I need some input to decide how to do this. The problem is with the code in yp_ping.c. This module contains a special version of clntudp_call() which has been modified in two ways: 1) If the XDR encode routine is specified as NULL, it skips the transmit portion of clntudp_send() and jumps straight to receiving and decoding the reply. 2) When processing a reply, the routine omits the check of the transaction ID, so that the reply will be processed even if its XID doesn't match the XID of the request that was last sent. This is done so that we can send a bunch of YPPROC_DOMAIN_NONACK requests to different servers, each with a different transaction ID, then wait to see who replies first. Distinguishing the servers based on the XID gets around the case where the server is multihomed and replies on an interface other than the one where it received the original RPC. This is basically an asynchronous RPC, where the request and response are handled separately rather than in the context of a single clntudp_call(). Anyway, now that we have the TI-RPC library, the magic clntudp_a_call() routine needs to be changed to a clnt_dg_a_call(). Unfortunately, when I tried to do this, I ran into a serious problem: - The clnt_dg.c module has several module-wide lock variables which are shared between the create/call/destroy methods. Trying to set up a private call method won't work, because the lock variables are static, hence not exported from the clnt_dg.o object module. As a hack I created a separate clnt_dg.c module which I linked directly into a test ypbind binary, but this is not what I consider a proper solution. Basically, I can't do things the way I did them with the older RPC code because of the threading/mutex locks. Even building a separate clnt_dg.o module with modifications was harder than it needed to be because the clnt_dg.c code #includes special header files within the libc source (src/lib/libc/include) which aren't available if you aren't building the world. The solution I'm leaning towards at the moment is adding the necessary hacks to src/lib/libc/rpc/clnt_dg.c in such a way that they can be enabled when needed with a special CLSET flag using clnt_control(). Then I can rip out the custom call method code from yp_ping.c entirely. I'm a little reluctant to do this since I was under the impression that creating a custom method should still work, but it looks as if this problem is endemic even to the original Sun TI-RPC code, not just us. Comments? Questions? Pie? -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
page fault in mpu.c
I finally tracked down the page fault I was seeing while probing the mpu.
The mutex was not being initialized before it was used. I have included a
patch below which fixes the problem. Will someone please review the style
and commit the fix.
Thanks.
Jim Bloom
[EMAIL PROTECTED]
Index: mpu.c
===
RCS file: /users/ncvs/src/sys/dev/sound/isa/mpu.c,v
retrieving revision 1.5
diff -u -r1.5 mpu.c
--- mpu.c 2001/03/14 07:29:46 1.5
+++ mpu.c 2001/03/27 02:20:29
@@ -358,6 +358,8 @@
DEB(printf("mpu: attaching.\n"));
+ mtx_init(scp-mtx, "mpumid", MTX_DEF);
+
/* Allocate the resources, switch to uart mode. */
if (mpu_allocres(scp, dev) || mpu_uartmode(scp)) {
mpu_releaseres(scp, dev);
@@ -368,7 +370,6 @@
/* Fill the softc. */
scp-dev = dev;
- mtx_init(scp-mtx, "mpumid", MTX_DEF);
scp-devinfo = devinfo = create_mididev_info_unit(MDT_MIDI, mpu_op_desc,
midisynth_op_desc);
/* Fill the midi info. */
@@ -751,6 +752,7 @@
bus_release_resource(dev, SYS_RES_IOPORT, scp-io_rid, scp-io);
scp-io = NULL;
}
+ mtx_destroy(scp-mtx);
}
static device_method_t mpu_methods[] = {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Fixing ypbind with TI-RPC
* Bill Paul [EMAIL PROTECTED] [010326 16:05] wrote: Ok. Friday I sat down and tried to make the -m option to ypbind work correctly using the new TI-RPC code. Unfortunately, my test machine chose that day to eat itself. Even more unfortunately, it was an AMD 900Mhz Thunderbird. Today, I started working on another box and managed to get things to work, but there are some problems that still need solving. I need some input to decide how to do this. The problem is with the code in yp_ping.c. This module contains a special version of clntudp_call() which has been modified in two ways: 1) If the XDR encode routine is specified as NULL, it skips the transmit portion of clntudp_send() and jumps straight to receiving and decoding the reply. 2) When processing a reply, the routine omits the check of the transaction ID, so that the reply will be processed even if its XID doesn't match the XID of the request that was last sent. This is done so that we can send a bunch of YPPROC_DOMAIN_NONACK requests to different servers, each with a different transaction ID, then wait to see who replies first. Distinguishing the servers based on the XID gets around the case where the server is multihomed and replies on an interface other than the one where it received the original RPC. This is basically an asynchronous RPC, where the request and response are handled separately rather than in the context of a single clntudp_call(). Anyway, now that we have the TI-RPC library, the magic clntudp_a_call() routine needs to be changed to a clnt_dg_a_call(). Unfortunately, when I tried to do this, I ran into a serious problem: - The clnt_dg.c module has several module-wide lock variables which are shared between the create/call/destroy methods. Trying to set up a private call method won't work, because the lock variables are static, hence not exported from the clnt_dg.o object module. As a hack I created a separate clnt_dg.c module which I linked directly into a test ypbind binary, but this is not what I consider a proper solution. Basically, I can't do things the way I did them with the older RPC code because of the threading/mutex locks. Even building a separate clnt_dg.o module with modifications was harder than it needed to be because the clnt_dg.c code #includes special header files within the libc source (src/lib/libc/include) which aren't available if you aren't building the world. The solution I'm leaning towards at the moment is adding the necessary hacks to src/lib/libc/rpc/clnt_dg.c in such a way that they can be enabled when needed with a special CLSET flag using clnt_control(). Then I can rip out the custom call method code from yp_ping.c entirely. I'm a little reluctant to do this since I was under the impression that creating a custom method should still work, but it looks as if this problem is endemic even to the original Sun TI-RPC code, not just us. Comments? Questions? Pie? Pie. Why can't you just enable sigio on the reply socket, send all the requests with a 0 timeout and then wait for a signal to either interrupt the sending or to notify you when you complete sending? Your solution seems awfully complex for what seems to be a simple problem; doing a directed broadcast and taking the first answer you get back. Is the whole reason you need to do this because you're using the xid to differentiate between the servers? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Represent yourself, show up at BABUG http://www.babug.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fixing ypbind with TI-RPC
* Alfred Perlstein [EMAIL PROTECTED] [010326 19:57] wrote: * Bill Paul [EMAIL PROTECTED] [010326 16:05] wrote: Why can't you just enable sigio on the reply socket, send all the requests with a 0 timeout and then wait for a signal to either interrupt the sending or to notify you when you complete sending? Your solution seems awfully complex for what seems to be a simple problem; doing a directed broadcast and taking the first answer you get back. Is the whole reason you need to do this because you're using the xid to differentiate between the servers? If that's true then you have a couple of options... We could add a hack to our version of the rpc library to allow manipulation/query of the xid. Or if the reply's source doesn't match any of the destinations you can remember it and send out another ping to that address. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Whatever happened to CTM?
On Wed, 21 Mar 2001, Stephen McKay wrote: unfortunatly my provider cut me off and I just got some access back, but not for the location the ctm machine is located at. At this time I do not know yet when it will have access again. Surely FreeBSD Inc (or whatever it is that owns the freebsd.org machines) could spring for a box. Assuming Ulf is still keen, it shouldn't be too hard for him to remote administer it. I've already announced this on the ctm-announce list, but in case some aren't subscribed, a new host has been located for ctm, and I expect it won't take too long to get it back up, hopefully by this weekend sometime. If Ulf's reading this, giving me a change to recover some files from the old host would be appreciated, if it's possible. I've mailed Ulf separately twice, but gotten no response. If the files just aren't any longer available, I will have to make do, it would make at least one item easier, is all. Chuck Robey | Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
is 'make release' broken?
Making fixit floppy. disklabel: ioctl DIOCWLABEL: Operation not supported by device Warning: Block size restricts cylinders per group to 6. Warning: 1216 sector(s) in last cylinder unallocated /dev/md0c: 2880 sectors in 1 cylinders of 1 tracks, 4096 sectors 1.4MB in 1 cyl groups (6 c/g, 12.00MB/g, 384 i/g) super-block backups (for fsck -b #) at: 32 /mnt: write failed, file system is full cpio: write error: No space left on device *** Error code 1 Stop in /usr/src/release. *** Error code 1 -- Bye Juriy Goloveshkin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Whatever happened to CTM?
On Tue, Mar 27, 2001 at 12:26:34AM -0500, Chuck Robey wrote: On Wed, 21 Mar 2001, Stephen McKay wrote: unfortunatly my provider cut me off and I just got some access back, but not for the location the ctm machine is located at. At this time I do not know yet when it will have access again. Surely FreeBSD Inc (or whatever it is that owns the freebsd.org machines) could spring for a box. Assuming Ulf is still keen, it shouldn't be too hard for him to remote administer it. I've already announced this on the ctm-announce list, but in case some aren't subscribed, a new host has been located for ctm, and I expect it won't take too long to get it back up, hopefully by this weekend sometime. If Ulf's reading this, giving me a change to recover some files from the old host would be appreciated, if it's possible. I've mailed Ulf separately twice, but gotten no response. If the files just aren't any longer available, I will have to make do, it would make at least one item easier, is all. I am very busy at work and not very open to anything else right now. Send me an email with the files and I can send you a tar. Chuck Robey | Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fixing ypbind with TI-RPC
Why can't you just enable sigio on the reply socket, send all the
requests with a 0 timeout and then wait for a signal to either
interrupt the sending or to notify you when you complete sending?
Your solution seems awfully complex for what seems to be a simple
problem; doing a directed broadcast and taking the first answer you
get back.
Is the whole reason you need to do this because you're using the
xid to differentiate between the servers?
Once upon a time, a young coder needed to be able to send multiple
RPC requests and then wait for a single reply, instead of adhering to
the strict request/reply mechanism in the existing code. So he studied
the problem over many long nights. He fretted. He fussed. He tried not
to reinvent the wheel or cure cancer while he was at it. Eventually,
he made a couple of minor changes to a piece of existing code that did
exactly what he wanted.
The end.
If that's true then you have a couple of options...
We could add a hack to our version of the rpc library to
allow manipulation/query of the xid. Or if the reply's source
doesn't match any of the destinations you can remember it and
send out another ping to that address.
You're already allowed to get/set the transaction ID using CLGET_XID
and CLSET_XID, and I intend to use this too. All I want to do is invoke
YPPROC_DOMAIN_NONACK on a bunch of servers and see which one replies
first, and I need to do it using unicasts because broadcasts won't get
forwarded across routers or point-to-point dialup links. I originally
created this monstrosity for NIS+, and decided it would be useful to
silence the people who insisted on putting their NIS clients on separate
networks from their NIS servers, and didn't want to set up NIS slaves
on the remote subnets like they were supposed to.
I'm including a patch to clnt_dg.c and clnt.h that adds the functionality
I need. It's quite small, and it's the path of least resistance in this
case, which is why I prefer it in this case in spite of the brokenness
it seeks to supress. Oh, there's also a fix for a bug in here. At least,
I think it's a bug. The clnt_dg_call() routine increments the transaction
ID before transmitting a request. It assumes that the XID is a 32-bit
value at a certain position in the block to be sent, and simply does a
cast to a u_int32_t and an in-place increment. The problem is, this value
is actually in network byte order, so to increment it properly, you need
to ntohl() it first, increment, then htonl() it back. Of course, if you
believe Sun, all the world's a SPARC, so for them it doesn't matter. This
really only becomes a problem if you actually use the CLGET_XID and
CLSET_XID control codes on a UDP client handle: the code in clnt_dg_control()
does the proper byte swapping, but clnt_dg_call() doesn't.
I'm not positive I'm doing the right thing here, but without this fix,
my newly hacked __yp_ping() routine produces some weird results.
-Bill
*** clnt_dg.c.orig Mon Mar 26 21:17:00 2001
--- clnt_dg.c Mon Mar 26 21:21:08 2001
***
*** 126,131
--- 126,132
char*cu_outbuf;
u_int cu_recvsz; /* recv size */
struct pollfd pfdp;
+ int cu_async;
charcu_inbuf[1];
};
***
*** 238,243
--- 239,245
cu-cu_total.tv_usec = -1;
cu-cu_sendsz = sendsz;
cu-cu_recvsz = recvsz;
+ cu-cu_async = FALSE;
(void) gettimeofday(now, NULL);
call_msg.rm_xid = __RPC_GETXID(now);
call_msg.rm_call.cb_prog = program;
***
*** 312,317
--- 314,320
socklen_t fromlen, inlen;
ssize_t recvlen = 0;
int rpc_lock_value;
+ u_int32_t xid;
sigfillset(newmask);
thr_sigsetmask(SIG_SETMASK, newmask, mask);
***
*** 336,347
call_again:
xdrs = (cu-cu_outxdrs);
xdrs-x_op = XDR_ENCODE;
XDR_SETPOS(xdrs, cu-cu_xdrpos);
/*
* the transaction is the first thing in the out buffer
*/
! (*(u_int32_t *)(void *)(cu-cu_outbuf))++;
if ((! XDR_PUTINT32(xdrs, proc)) ||
(! AUTH_MARSHALL(cl-cl_auth, xdrs)) ||
(! (*xargs)(xdrs, argsp))) {
--- 339,357
call_again:
xdrs = (cu-cu_outxdrs);
+ if (cu-cu_async == TRUE xargs == NULL)
+ goto get_reply;
xdrs-x_op = XDR_ENCODE;
XDR_SETPOS(xdrs, cu-cu_xdrpos);
/*
* the transaction is the first thing in the out buffer
+* XXX Yes, and it's in network byte order, so we should to
+* be careful when we increment it, shouldn't we.
*/
! xid = ntohl(*(u_int32_t *)(void *)(cu-cu_outbuf));
! xid++;
! *(u_int32_t *)(void *)(cu-cu_outbuf) = htonl(xid);
!
if ((! XDR_PUTINT32(xdrs, proc)) ||
(! AUTH_MARSHALL(cl-cl_auth, xdrs)) ||
heads up, CAM error recovery changes committed
I won't repeat the commit message here, but the new CAM error recovery code has been committed to -current. Note that error printouts are now a little more descriptive, so don't be alarmed at that. If there are any problems with the new code, send mail to [EMAIL PROTECTED], or to [EMAIL PROTECTED] and [EMAIL PROTECTED] Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP ** portmap daemon renamed to rpcbind
In message [EMAIL PROTECTED] Greg Lehey writes: : Play the ball, not the man. : : I don't have an objection to the change, I was just asking. And : "because System V does it this way" has never been a good answer for : us. And no, I'm not picking on Doug, just making a point. I see no reason why the name can't remain portmap. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: newcard/cardbus instabilities
In message [EMAIL PROTECTED] Mike Smith writes: : The problem that Johny was seeing was that 'device pccard' causes broken : interrupt delivery for cardbus cards. If that's meant to work, I can see : if I can reproduce it locally. It is ment to work and works for me on my VAIO all the time. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: use md device in /etc/rc.diskless{1,2}
In message [EMAIL PROTECTED] Falco Krepel writes: : 1. For example you could use the diskless boot procedure for smart : clients with a small disk used as swap space. So I think it is better to : use swap instead of malloc for var,dev, and tmp. This could be done with : a variable (e.g. diskless_swap_enable). What do think about it? I think it is a bad idea. rc.diskless* is often used in cases where no swap exists. This is a very popular way to run of cf where you cannot configure swap due to excess wear and tear on the cf which has a very limited number of writes. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: use md device in /etc/rc.diskless{1,2}
On Tue, 27 Mar 2001, Warner Losh wrote: WLIn message [EMAIL PROTECTED] Falco Krepel writes: WL: 1. For example you could use the diskless boot procedure for smart WL: clients with a small disk used as swap space. So I think it is better to WL: use swap instead of malloc for var,dev, and tmp. This could be done with WL: a variable (e.g. diskless_swap_enable). What do think about it? WL WLI think it is a bad idea. rc.diskless* is often used in cases where no WLswap exists. This is a very popular way to run of cf where you cannot WLconfigure swap due to excess wear and tear on the cf which has a very WLlimited number of writes. Well, the idea is to have a config knob, where you can tell to mdconfig whether it should use 'swap' or 'malloc'. This should, of course, default to malloc. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
