Re: use md device in /etc/rc.diskless{1,2}

[Harti Brandt]

On Tue, 27 Mar 2001, Warner Losh wrote:

WL>In 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>
WL>I think it is a bad idea.  rc.diskless* is often used in cases where no
WL>swap exists.  This is a very popular way to run of cf where you cannot
WL>configure swap due to excess wear and tear on the cf which has a very
WL>limited 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

Re: use md device in /etc/rc.diskless{1,2}

[Warner Losh]

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: newcard/cardbus instabilities

[Warner Losh]

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: ** HEADS UP ** portmap daemon renamed to rpcbind

[Warner Losh]

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

heads up, CAM error recovery changes committed

[Kenneth D. Merry]

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: Fixing ypbind with TI-RPC

[Bill Paul]

> > 
> > 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)) ||
   

Re: Whatever happened to CTM?

[Ulf Zimmermann]

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

is 'make release' broken?

[Juriy Goloveshkin]

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?

[Chuck Robey]

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

Re: Fixing ypbind with TI-RPC

[Alfred Perlstein]

* 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: Fixing ypbind with TI-RPC

[Alfred Perlstein]

* 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

page fault in mpu.c

[Jim Bloom]

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

Fixing ypbind with TI-RPC

[Bill Paul]

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

Re: ** HEADS UP **: bsd.man.mk changes

[Warner Losh]

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

Re: telnet broken with auto-negotiation of encrypt/decrypt change

[Robert Watson]

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: NFS over IPv6 is a reason????

[Kris Kennaway]

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

NFS over IPv6 is a reason????

[Mike O'Dell]

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: ** HEADS UP **: bsd.man.mk changes

[Peter Pentchev]

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

Re: ** HEADS UP **: bsd.man.mk changes

[Kris Kennaway]

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

buildworld dies

[Salvo Bartolotta]

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: use md device in /etc/rc.diskless{1,2}

[Falco Krepel]

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

** HEADS UP **: bsd.man.mk changes

[Ruslan Ermilov]

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: midi causes panic on boot? (update)

[Szilveszter Adam]

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

Re: use md device in /etc/rc.diskless{1,2}

[Mike Smith]

> 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 2>&1 >/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 2>&1 >/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//etc or /conf//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: newcard/cardbus instabilities

[Mike Smith]

> 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}

[Falco Krepel]

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: use md device in /etc/rc.diskless{1,2}

[Falco Krepel]

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: Recent interface/routing changes breaks on-demand PPP

[Brian Somers]

> 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]>
     
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: ** HEADS UP ** portmap daemon renamed to rpcbind

[Greg Lehey]

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: ** HEADS UP ** portmap daemon renamed to rpcbind

[Andrew Reilly]

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