Re: cvs commit: src/etc/defaults make.conf src/secure/lib/libcrypto Makefile Makefile.inc

[Jun Kuriyama]

At Fri, 14 Jul 2000 02:18:21 -0700 (PDT),
Peter Wemm <[EMAIL PROTECTED]> wrote:
>   Be consistant about WITH_ vs MAKE_ flags.  We have a precedent of using
>   MAKE_foo for things like MAKE_KERBEROS etc.  Use that.  I managed to
>   confuse myself last time and made make.conf different to the code. ;-(

Hmm, my box failed with WITH_IDEA=YES and USA_RESIDENT=NO.  Do you
have any idea about this?


cc -g -DMONOLITH -I/usr/src/secure/usr.bin/openssl   
-I/usr/obj/usr/src/i386/usr/include  -o openssl app_rand.o apps.o asn1pars.o ca.o 
ciphers.o crl.o crl2p7.o dgst.o dh.o dhparam.o dsa.o dsaparam.o enc.o errstr.o gendh.o 
gendsa.o genrsa.o nseq.o openssl.o passwd.o pkcs12.o pkcs7.o pkcs8.o rand.o req.o 
rsa.o s_cb.o s_client.o s_server.o s_socket.o s_time.o sess_id.o smime.o speed.o 
spkac.o verify.o version.o x509.o  -lssl -lcrypto
gendsa.o: In function `gendsa_main':
/usr/src/secure/usr.bin/openssl/../../../crypto/openssl/apps/gendsa.c(.text+0x209): 
undefined reference to `EVP_idea_cbc'
genrsa.o: In function `genrsa_main':
/usr/src/secure/usr.bin/openssl/../../../crypto/openssl/apps/genrsa.c(.text+0x22d): 
undefined reference to `EVP_idea_cbc'
pkcs12.o: In function `pkcs12_main':
/usr/src/secure/usr.bin/openssl/../../../crypto/openssl/apps/pkcs12.c:146: undefined 
reference to `EVP_idea_cbc'
speed.o: In function `speed_main':
/usr/src/secure/usr.bin/openssl/../../../crypto/openssl/apps/speed.c:594: undefined 
reference to `idea_set_encrypt_key'
/usr/src/secure/usr.bin/openssl/../../../crypto/openssl/apps/speed.c:881: undefined 
reference to `idea_cbc_encrypt'
/usr/src/secure/usr.bin/openssl/../../../crypto/openssl/apps/speed.c:1108: undefined 
reference to `idea_options'
version.o: In function `version_main':
/usr/src/secure/usr.bin/openssl/../../../crypto/openssl/apps/version.c(.text+0x310): 
undefined reference to `idea_options'
*** Error code 1

Stop in /usr/src/secure/usr.bin/openssl.
*** Error code 1


-- 
Jun Kuriyama <[EMAIL PROTECTED]> // FreeBSD Project


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Request for comments: new `lpd' suite feature

[Thomas D. Dean]

How would this work with printers on local networks?

Say, a print server 192.168.1.73?

tomdean


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Request for comments: new `lpd' suite feature

[Louis A. Mamakos]

I almost hate to bring this up, but I think the unnamed-here proposed
replacement for our lpd allows you to set your PRINTER environment
variable to something like

[EMAIL PROTECTED]

louie


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: dc driver and underruns (was: Strangeness with 4.0-S)

[Rodney W. Grimes]

[cc: trimmed to -current]

> >>>Does anyone here actually measure these latencies?  I know for a fact
> >>>that nothing I've ever done would or could be affected by extra latencies
> >>>that are as small as the ones we are discussing.  Does anybody at all
> >>>depend on the start-transmitting-before-DMA-completed feature we are
> >>>discussing?
> >> 
> >> I don't like the idea of removing that feature.  Perhaps it should be a
> >> sysctl or ifconfig option, but it should definitely remain available.
> >> Those minute latencies are critical to those of us who use MPI for
> >> complex parallel calculations.
> >
> >I have to agree here.  The store and forward adds an approximate
> >11uS (by theory under ideal conditions 1500bytes@132MB/s = 11uS,
> >practice actually makes this worse as typical PCI does something
> >less than 100MB/s or 15uS) to a 120uS packet time on the wire (again,
> >ideal, but here given that switches, and infact often cut-through
> >switches, are used for these types of things, ideal and practice
> >are very close.)
> >
> >I don't think these folks, nor myself, are wanting^H^H^H^H^H^H^Hilling
> >to give up 12.5%.
> 
> OK.  It seems that repairing the feature, rather than disabling it is
> the most popular option.  Still, I am quite interested in finding anyone
> who actually measures these things, and is affected by them. 

As already pointed out, anyone running computational code on a compute
cluster that is passing data around is directly affected by this.  I know
of at least 3 sites that converting to store and forward would destroy
as far as ``operational'' status goes.  They have gone the extra mile to
even use cut-through ethernet switches and I can assure you that an 11uS
delay per packet would have a significant impact on cluster performance.
They don't directly measure these values, but none the less they would
have an impact.

Also for those using dc21x4x cards in high load router and/or firewall
situations would notice this, though it would be harder to measure (well,
actually a pps test should show it quite clearly, as my above 12.5% was
based on full size packets, this becomes a larger percentage as packet
size is decreased).

> These very
> same people might be able to trace why we get the underruns in the first
> place.

Of the sites I know of they don't get these messages :-). 
I have noticed that I see them more often with the dc driver than I
do with the de driver, ie now that I am upgrading more and more of
our systems to 4.x from 3.x I have started to see these on machines
that have never reported them before.  Now this may be the driver,
or it could be some other part of system that has changed.

>  I suspect an interaction between the ATA driver and VIA chipsets,
> because other than the network, that's all that is operating when I see
> the underruns.  And my Celeron with a ZX chipset is immune.

I've seen them on just about everything, chipset doesn't seem to matter,
IDE or SCSI doesn't seem to matter.

> Back to the technical, for a moment.  I have verified that stopping the
> transmitter on the 21143 is both sufficient and necessary to enable the
> thresholds to be set.  I have code that works on my machine.  I intend
> to commit it when I think it looks neat enough.

Good.  That should help the folks with the major complaint of 2 to 3 second
network outages when one of the occur.  It may also be possible to simply
start out one step further down on the fifo level and eliminate the message
for most people.  (When I do see these it usually only happens once or
maybe twice, then the box is silent about it from then on.  I have never
seen a box back off to store and forward mode that didn't have some other
serious hardware related problem.)

> Getting even more technical, it appears to me that the current driver
> instructs the 21143 to poll for transmit packets (ie a small DMA)
> every 80us even if there are none to be sent.  I don't know what percentage
> of bus time this might be, or even how to calculate it (got some time Rod?)

I'll have to look at that.  If it is a simple 32 bit read every 80uS
thats something like .1515% of the PCI bandwidth, something that shouldn't
matter much.  (I assumed a simple 4 cycle PCI operation).  Just how big
is this DMA operation every 80uS?

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: tcpdump malloc bug

[Matthew Hunt]

On Fri, Jul 14, 2000 at 04:03:08PM -0700, Kris Kennaway wrote:

> citusc17# ln -s AJ /etc/malloc.conf
> citusc17# tcpdump
> tcpdump: [CRAP DELETED]: Device not configured
> 
> This is true on 4.0-S as well, where I actually first found it.

It's fixed in the tcpdump.org libpcap sources, but we haven't
caught up yet.  It's due to using memory after it's free'd,
and I suggested to Bill Fenner (that is the right Bill F, right?)
that we ought to update.

-- 
Matthew Hunt <[EMAIL PROTECTED]> * Stay close to the Vorlon.
http://www.pobox.com/~mph/   *


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Request for comments: new `lpd' suite feature

[Garance A Drosihn]

At 5:39 PM -0400 7/14/00, Garrett Wollman wrote:
>Around here, we have a convention that each printer has a record
>in the DNS for printername.lpd-spooler which points to the print
>server for that printer.  It occurred to me that, if there are no
>local printers, no additional information is needed for lpr and
>lpd to operate -- thus obviating the need for that pesky
>`/etc/printcap' file which never seems to be stay up-to-date.

and in the update, he wrote comments which said:
>   This is intended for large sites where distributing the
>   printcap file is a pain; it will infer from the presence
>   of spool directories in _PATH_DEFSPOOLDIR a printcap entry
>   with rm=%s.lpd-spooler and rp=%s (following the convention
>   used at MIT-LCS where the author currently works).

I can sympathize with the idea of getting rid of /etc/printcap,
but I admit this strategy perplexes me.  How is it easier for
you to keep the "presence of spool directories" up to date, than
it is to keep /etc/printcap up-to-date?  Speaking for my lpd use
here at RPI, it is MUCH easier for us (RPI) to keep printcap files
in sync than it is to rely that the contents of a directory on the
local hard disk is magically correct.

Further, if you really CAN keep that up-to-date easier, then it
seems to me pretty trivial to write some perl script or routine
in chkprinter which simply creates /etc/printcap from those
directories.  From my reading of your update, you have this
"synthetic" printcap file which lpd knows about, but you never
write that out anywhere.  At least at RPI, we do have other
processes which check the /etc/printcap file to make decisions.
If that file does not exist, or is not accurate, then those
other processes will not work right.

I would also say that here at RPI (at least), we have plenty
of things in the printcap entries which are not covered by
this strategy.  Most notably, printer aliases.  Every printer
we have has multiple names.  How are multiple names handled
in this situation?

Obviously I am just writing the first things which come to my
mind in ten minutes of me looking at this update (late on a
friday evening!), but it strikes me that this is too much a
matter of codifying into freebsd's lpd something which is
rather specific to MIT practices.  This may very well be useful
for other people too, but I can't imagine how I would make any
use of this at RPI.

That by itself is not important, but (if I am reading your update
correctly) it means that there are now "two ways" that the code
will deal with printcap files.  When someone makes an update (such
as adding new fields to 'struct printer'), they will have to be
sure to make the update in both places.  This makes me queasy.

Also, I wonder how all this fits in with the discussion in -arch
which has been going (on and off) about replacing lpr in FreeBSD
with lprNG.  That's not my idea, but I do know I have been
holding off some lpr/lpd updates of my own until I have some idea
what is going to happen with that.  If freebsd is going to switch
to lprNG, then this is just one more little oddity which (I think)
lprNG will not handle quite the same way.

Me, I am interested in ways to make printcap files more automated,
but this strategy which may work well in MIT's environment would
not make any sense in ours...

Disclaimer Reminder: I've only SKIMMED through the actual update,
so I may misunderstand what it's doing...  Apologies if I have
done that.


---
Garance Alistair Drosehn   =   [EMAIL PROTECTED]
Senior Systems Programmer  or  [EMAIL PROTECTED]
Rensselaer Polytechnic Institute


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

tcpdump malloc bug

[Kris Kennaway]

citusc17# ln -s AJ /etc/malloc.conf
citusc17# tcpdump
tcpdump: [CRAP DELETED]: Device not configured

This is true on 4.0-S as well, where I actually first found it.

Kris

--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Request for comments: new `lpd' suite feature

[Garrett Wollman]

Around here, we have a convention that each printer has a record in
the DNS for printername.lpd-spooler which points to the print server for
that printer.  It occurred to me that, if there are no local printers,
no additional information is needed for lpr and lpd to operate -- thus
obviating the need for that pesky `/etc/printcap' file which never
seems to be stay up-to-date.  Here is some code which I am planning to
commit soon (after I've actually tested it) which does precisely
that.  The patch also contains a few bug fixes and enhancements for
chkprintcap(8).  (I've already noticed some bugs in reading this
patch.)

Index: chkprintcap/chkprintcap.8
===
RCS file: /home/cvs/src/usr.sbin/lpr/chkprintcap/chkprintcap.8,v
retrieving revision 1.3
diff -u -r1.3 chkprintcap.8
--- chkprintcap/chkprintcap.8   1999/08/28 01:16:46 1.3
+++ chkprintcap/chkprintcap.8   2000/07/14 19:35:10
@@ -26,7 +26,7 @@
 .\" SUCH DAMAGE.
 .\"
 .\" $FreeBSD: src/usr.sbin/lpr/chkprintcap/chkprintcap.8,v 1.3 1999/08/28 01:16:46 
peter Exp $
-.Dd November 30, 1997
+.Dd July 14, 2000
 .Dt CHKPRINTCAP 8
 .Os
 .Sh NAME
@@ -34,7 +34,7 @@
 .Nd check validity of entries in the print spooler database
 .Sh SYNOPSIS
 .Nm chkprintcap
-.Op Fl d
+.Op Fl ds
 .Op Fl f Ar printcap
 .Sh DESCRIPTION
 .Nm Chkprintcap
@@ -60,6 +60,13 @@
 .Sq Li sd=
 capability
 .Pc .
+.It
+Every spool directory is owned by the daemon user
+.Po
+.Sq Li du#
+capability
+.Pc ,
+and is only writable by that user.
 .El
 .Pp
 .Nm Chkprintcap
@@ -68,6 +75,15 @@
 entire file is scanned.)
 .Pp
 If the
+.Fl s
+flag is used,
+.Nm chkprintcap
+will
+.Dq synthesize
+a printer database, as described in
+.Xr lpd 8 .
+.Pp
+If the
 .Fl d
 flag is given,
 .Nm chkprintcap
@@ -79,6 +95,13 @@
 .Sq Li du=
 capability in the database (default 1, which corresponds to user
 .Sq Li daemon ) .
+.Sh FILES
+.Bl -tag -width "/var/spool/output"
+.It Pa /var/spool/output
+default directory scanned for spool directories by the
+.Fl s
+option.
+.El
 .Sh SEE ALSO
 .Xr lpr 1 ,
 .Xr printcap 5 ,
@@ -89,8 +112,6 @@
 command was written by
 .An Garrett A. Wollman Aq [EMAIL PROTECTED] .
 .Sh BUGS
-Not enough sanity-checking is done.  At a minimum, the ownership and
-mode of the spool directories should also be checked.  Other
-parameters whose value could cause
+Other parameters whose value could cause
 .Xr lpd 8
 to fail should be diagnosed.
Index: chkprintcap/chkprintcap.c
===
RCS file: /home/cvs/src/usr.sbin/lpr/chkprintcap/chkprintcap.c,v
retrieving revision 1.5
diff -u -r1.5 chkprintcap.c
--- chkprintcap/chkprintcap.c   2000/05/26 02:08:31 1.5
+++ chkprintcap/chkprintcap.c   2000/07/14 20:23:18
@@ -1,5 +1,5 @@
 /*
- * Copyright 1997 Massachusetts Institute of Technology
+ * Copyright 1997, 2000 Massachusetts Institute of Technology
  *
  * Permission to use, copy, modify, and distribute this software and
  * its documentation for any purpose and without fee is hereby
@@ -28,7 +28,7 @@
  */
 
 static const char copyright[] =
-   "Copyright (C) 1997, Massachusetts Institute of Technology\r\n";
+   "Copyright 1997, 2000 Massachusetts Institute of Technology\r\n";
 static const char rcsid[] =
   "$FreeBSD: src/usr.sbin/lpr/chkprintcap/chkprintcap.c,v 1.5 2000/05/26 02:08:31 
jake Exp $";
 
@@ -38,7 +38,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -57,6 +57,15 @@
 
 static int problems;   /* number of problems encountered */
 
+#ifndef SPOOL_DIR_MODE
+#defineSPOOL_DIR_MODE  (S_IRUSR | S_IWUSR | S_IXUSR \
+| S_IRGRP | S_IXGRP | S_IROTH | S_IXOTH)
+#endif
+#define ALL_MODE_BITS  (S_IRUSR | S_IWUSR | S_IXUSR \
+| S_IRGRP | S_IWGRP | S_IXGRP \
+| S_IROTH | S_IWOTH | S_IXOTH \
+| S_ISUID | S_ISGID | S_ISVTX)
+
 /*
  * chkprintcap - check the printcap file for syntactic and semantic errors
  * Returns the number of problems found.
@@ -64,13 +73,14 @@
 int
 main(int argc, char **argv)
 {
-   int c, error, makedirs, more;
+   int c, error, makedirs, gotone;
struct printer myprinter, *pp;
 
+   do_synthesize_printcap = 0;
makedirs = 0;
pp = &myprinter;
 
-   while ((c = getopt(argc, argv, "df:")) != -1) {
+   while ((c = getopt(argc, argv, "df:s")) != -1) {
switch (c) {
case 'd':
makedirs = 1;
@@ -80,6 +90,10 @@
setprintcap(optarg);
break;
 
+   case 's':
+   do_synthesize_printcap = 1;
+   break;
+
default:
usage();
}
@@ -87,12 +101,13 @@
 
if (optind != argc)
usage();
+
+   gotone = firstprinter(pp, &error);
 
-   more = firstprinter(pp, &er

Re: -current, racoon, ipsec

[Kris Kennaway]

On Fri, 14 Jul 2000, Mark Huizer wrote:

> Grr... ok, that might be solved when putting IPSEC in the kernel config,
> but the second part still stands, I guess. (Why include libipsec code
> when it is in the base tree... they should be compatible)

Just use the port. I presume the included copy of ipsec is there for other
platforms.

Kris

--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: New boot0 not work with ahc

[John Baldwin]

On 14-Jul-00 Andrey A. Chernov wrote:
> New boot0 cause dead hang (nothing appearse on the screen)
> with Adaptec SCSI BIOS
>   ahc0: 
> Standard MBR works fine. All in first 1024 cyls.

Errm, do you have some more details?

> dmesg | egrep 'ah|da'
ahc0:  port 0x9c00-0x9cff mem
0xe1102000-0xe1102fff irq 10 at device 13.0 on pci0
ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs
ppc0:  at port 0x378-0x37b irq 7 on isa0
Mounting root from ufs:/dev/da0s1a
da0 at ahc0 bus 0 target 1 lun 0
da0:  Fixed Direct Access SCSI-2 device
da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled
da0: 8682MB (17781520 512 byte sectors: 255H 63S/T 1106C)
> sudo boot0cfg -v da0
#   flag start chs   type   end chs   offset size
1   0x80  0:  1: 1   0xa5   1023:254:63   63 17767827

version=1.1  drive=0x80  mask=0xf  ticks=182
options=packet,update,nosetdrv
> sudo fdisk
*** Working on device /dev/da0 ***
parameters extracted from in-core disklabel are:
cylinders=1106 heads=255 sectors/track=63 (16065 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=1106 heads=255 sectors/track=63 (16065 blks/cyl)

fdisk: invalid fdisk partition table found
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:

The data for partition 2 is:

The data for partition 3 is:

The data for partition 4 is:
sysid 165,(FreeBSD/NetBSD/386BSD)
start 63, size 17751825 (8667 Meg), flag 80 (active)
beg: cyl 0/ sector 1/ head 1;
end: cyl 81/ sector 63/ head 0
> uname -a
FreeBSD bar.osd.bsdi.com 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Thu Jul 13
16:02:28 PDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/BAR  i386


Boots fine.

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: about Kern/15436

[Nick Hibma]

Could people, when posting these kinds of requests, add a one sentence
outline of what the PR / web page contains? Most people do not take the
time to look at the page if there is no barebones description of what
the information contains.

Thanks in advance.

Nick

P.S.: Keep posting them. It is one of the best ways to get people
interested in the larger PRs and change requests.

On Wed, 5 Jul 2000, Michael C. Wu wrote:

> 
> Will you consider looking at :
> 
> http://dorifer.heim3.tu-clausthal.de/~olli/propellers/
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=15436
> 
> It is an additional functionality and should not
> pose a stability/tradition/POLA issue.
> 
> Perhaps we can get this done in time for for 4.1-R?
> 
> Regards,
> --
> +--+
> | [EMAIL PROTECTED] | [EMAIL PROTECTED] |
> | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. |
> +--+
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]  USB project
http://www.etla.net/~n_hibma/



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

parallel port zip patch - committer needed

[j mckitrick]

hi all,
i have been working with nicholas souchu to fix the parallel port zip drive
bug.  we think we have it beat.  however, nicholas doesn't have a devbox, so
he has asked me if someone could contact me for the corresponding fix.  i
have a few minor details to ask him about, and he will then contact you with
the patch.

jm
-- 
---
Jonathon McKitrick -- [EMAIL PROTECTED]   To Microsoft:
"Your tyranny I was part of, is now cracking on every side.
Now your own life is in danger.  Your Empire is on fire." Front 242
---


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

New boot0 not work with ahc

[Andrey A. Chernov]

New boot0 cause dead hang (nothing appearse on the screen)
with Adaptec SCSI BIOS
ahc0: 
Standard MBR works fine. All in first 1024 cyls.

-- 
Andrey A. Chernov
<[EMAIL PROTECTED]>
http://ache.pp.ru/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: config/hints changes: panic booting pcvt kernel

[Hellmuth Michaelis]

>From the keyboard of Hellmuth Michaelis:

> I'm currently re-cvsupping/recompiling a completly fresh tree to reproduce
> this to make shure it is really this single printf.

Its reproducible. Different machine/location/hardware, cvsupped 3 hr's
ago, rm /usr/src, /usr/obj, make world, make kernel. This one single printf 
makes the difference between a the panic or run fine.

hellmuth
-- 
Hellmuth MichaelisTel   +49 40 55 97 47-70
HCS Hanseatischer Computerservice GmbHFax   +49 40 55 97 47-77
Oldesloer Strasse 97-99   Mail  hm [at] hcs.de
D-22457 Hamburg   WWW   http://www.hcs.de


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: **HEADS UP** if you used to cvsup the crypto repo from internat !

[Brian Somers]

cd /usr/src/whereever && cvs diff

or just check your ``cvs checkout'' output for lines beginning with M.

> How can I tell if I need to nuke my crypto files?  Sounds like I should
> have this problem but it doen't look like I do.  I looked through the
> commits for the past few days searching for crypto, and I have all of the
> files that were commited.  (secure/lib/libcrypto/Makefile & Makefile.inc from
> earlier today & crypto/openssh/ readconf.c, servconf.c, ssh_config, sshd.8,
> & /telnet/libtelnet/auth.c from 7/11/00)
> 
> thanks,
> -Charlie
> On Wed, Jul 12, 2000 at 03:05:25PM +0100, Brian Somers wrote:
> > I haven't looked into it too deeply yet because of other source tree 
> > problems, but if you used to get your crypto ,v files from internat, 
> > you will suffer some funny problems unless you nuke the old checked-out 
> > files.
> > 
> > My apologies if this is old news, but I see nothing in UPDATING.
> > 
> > The problem occurs when you cvsup the new crypto-in-src-all sources 
> > and replace RCS files with different contents and the same version 
> > number.  cvs update/checkout compares the repo version number against 
> > the checked out version number and considers the file an ``M'' 
> > (modified source).  The file isn't updated and your world gets 
> > corrupted.
> > 
> > This is probably a candidate for UPDATING.
[.]
> -- 
> Charles Anderson  [EMAIL PROTECTED]
> 
> No quote, no nothin'
> 

-- 
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: smbfs problem

[Ollivier Robert]

According to Boris Popov:
>   New version (1.2.4) can be downloaded from
> ftp://ftp.butya.kz/pub/smbfs/smbfs.tar.gz

Please please pretty please, do commit it!
-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun  4 22:44:19 CEST 2000



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: -current, racoon, ipsec

[Mark Huizer]

> I'm trying to get racoon to work on my -current machine, but so far
> compiling is a horror.
> 
> It tries to compile using it's own libipsec, which gives troubles when
> starting racoon (pfkey: no such protocol).

Grr... ok, that might be solved when putting IPSEC in the kernel config,
but the second part still stands, I guess. (Why include libipsec code
when it is in the base tree... they should be compatible)

> So... I tried using the system libipsec, which has pfkey and pfkey_dump
> commented in the source file. Tried to put these in, and ipsec_hexdump
> is missing.
> 
> Does anyone have this working and how?
> 
> Mark
> -- 
> Nice testing in little China...
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

-- 
Nice testing in little China...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: possible NETGRAPH/NG_ETHER bug

[Archie Cobbs]

Julian Elischer writes:
> > i was working on integration of Ethernet TAP driver and NETGRAPH
> > and found strange thing. the problem is that NG_ETHER nodes do not
> > detach correctly when interface is gone. i was taking a very quick
> > look at it, and, it seems to me that we are missing one reference
> > to a node. i think it is ng_name_node/ng_unname pair.
> 
> This is quite possible because until recently interfaces could never
> be removed. Therefore the act of removing a node was really
> just a case of RESETTING the node. It was not removed.

Here's some more info that may be helpful.

First of all, until yesterday, if you detach an ethernet interface
that was using netgraph you'd get a kernel panic (or somesuch) --
it was simply broken. This change will be MFC'd soon but it hasn't
yet so we're talking -current only at this point.

Now, it all should work as designed... where "as designed" means:

  1.  Ethernet nodes appear for each Ethernet interface at the first moment
  when the following conditions *both* become true:

   (a) ng_ether.ko KLD is loaded (or kernel has options NETGRAPH_ETHER)
   (b) The interface is attached (e.g., at boot time, or when the
   PCCARD or USB device is connected).

  2.  Ethernet nodes disappear when/if the interface is detached
  (e.g., you pop out your Ethernet PCCARD).

  3.  Telling an Ethernet node to shutdown (e.g., "ngctl kill fxp0:")
  simply *resets* the node, i.e., breaks all connections to other
  nodes. The node does NOT go away until #2 happens.

  4.  You cannot kldunload ng_ether.ko until all Ethernet nodes
  are detached (for obvious reasons, considering #1 and #2).

If you are seeing other behavior that this using -current sources,
please let me know, as there is a BUG.

OTOH, if you think the behavior "as designed" is incorrect, let's discuss.

-Archie

___
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: **HEADS UP** if you used to cvsup the crypto repo from internat !

[Brian Somers]

> 
> 
> On Thu, 13 Jul 2000 19:19:48 +0200, Mark Murray wrote:
> 
> > > 2711:
> > >   If you used to get your crypto files from internat, AND you
> > >   used cvsup to get cvs' ,v files, then the latest changes
> > >   to the source collections will impact you.  You will need to
> > >   remove all the crypto files and start over.
> 
> Warner, Mark says that this applies if you used CTM to get cvs's ,v
> files, not CTM.  Also, he clarified the last sentence for me, by saying
> that it's the crypto ,v files that need to be removed and not the
> checked out crypto files.

It applies if you overwrite your ,v files with the src-all ones, 
whether by CTM or cvsup.  ``cvs checkout'' will compare the checked 
out version with the repo version and think it has nothing to do, 
emitting

M src/crypto/whatever

> Ciao,
> Sheldon.

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

-current, racoon, ipsec

[Mark Huizer]

Hi,

I'm trying to get racoon to work on my -current machine, but so far
compiling is a horror.

It tries to compile using it's own libipsec, which gives troubles when
starting racoon (pfkey: no such protocol).
So... I tried using the system libipsec, which has pfkey and pfkey_dump
commented in the source file. Tried to put these in, and ipsec_hexdump
is missing.

Does anyone have this working and how?

Mark
-- 
Nice testing in little China...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SB Live (or RAM parity?) crash on today's -CURRENT

[Mike Bristow]

On Thu, Jul 06, 2000 at 06:32:49PM -0700, Doug Barton wrote:
> On Thu, 6 Jul 2000, Thomas Stromberg wrote:
> 
> > 'panic: RAM parity error, likely hardware failure.'
> > 
> > This one had me confused at first, because it blamed a RAM parity
> > error. As this is a brand new machine (Gateway GP-800), so I first thought
> > I got a bad batch. Then I realized this only happens with apps that try to
> > do sound stuff.
> 
>   This is a known problem with all PCI sound cards. It happens most
> often with ECC ram, but it also happens without. What kind of NIC do you
> have, and specifically, is it a PCI card or ISA? We're trying to track
> that bit down too. 

I see it with:
mike@gurgle:~$ dmesg | grep vr0
vr0:  port 0xb000-0xb07f mem 0xdf80-0xdf80007f 
irq 10 at device 10.0 on pci0

The machine does have ECC ram.  If you need more, let me know and I'll give
you what you need... 

-- 
Mike Bristow, seebitwopie  


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ether_ifattach() change and VMware

[Archie Cobbs]

Munehiro Matsuda writes:
> ::  Make all Ethernet drivers attach using ether_ifattach() and detach using
> ::  ether_ifdetach().
> 
> After the commit, VMware seems to hang the system at boot time.
> The "vmnet" module, that comes with VMware, needs the included patch.

OK, I'm CC:'ing the port maintainer..

> Shouldn't we bump version or something, due to the kernel API change?

Good idea.. I just did that.

> --- vmnet-only/freebsd/vmnet.c.orgFri Jul 14 16:18:50 2000
> +++ vmnet-only/freebsd/vmnet.cFri Jul 14 16:21:51 2000
> @@ -156,9 +156,7 @@
>   DLog(Linfo, DEVICE_NAME "%d: Ethernet address: %6D", ifp->if_unit, 
>sc->iface.arpcom.ac_enaddr, ":");
>  
>   s = splimp();
> - if_attach(ifp);
> - ether_ifattach(ifp);
> - bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header));
> + ether_ifattach(ifp, ETHER_BPF_SUPPORTED);
>   splx(s);
>   
>   return 0;

-Archie

___
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: config/hints changes: panic booting pcvt kernel

[Hellmuth Michaelis]

>From the keyboard of Steve O'Hara-Smith:
> On 13-Jul-00 Hellmuth Michaelis wrote:
> > I'm now completely out of ideas 
> 
> Try and pin down which printf really makes a difference ?

Ok, did that. Surprise: i removed all the debugging code and all changes
i made to track down what happenes in the kbd driver as well as the pcvt
driver - everything now is completely as it was and it tracks down to
a single printf in /sys/dev/kbd.c: adding it lets a pcvt kernel boot
as happily as before, removing this printf gives the described panic:

/* find the keyboard specified by a driver name and a unit number */
int
kbd_find_keyboard(char *driver, int unit)
{
int i;

printf("kbd_find_keyboard\n");
^^
for (i = 0; i < keyboards; ++i) {
...

I'm currently re-cvsupping/recompiling a completly fresh tree to reproduce
this to make shure it is really this single printf. Also i will try out
something to make shure it is not a timing problem somewhere.

> I recall a long time ago a bit of code that had calls to a function
> that did nothing, the comment was that it prevented an MSC optimiser bug from
> screwing things up.

Oh oh ... 

I would really appreciate it if someone else would have a look at this.

hellmuth
-- 
Hellmuth MichaelisTel   +49 40 55 97 47-70
HCS Hanseatischer Computerservice GmbHFax   +49 40 55 97 47-77
Oldesloer Strasse 97-99   Mail  hm [at] hcs.de
D-22457 Hamburg   WWW   http://www.hcs.de


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: dc driver and underruns (was: Strangeness with 4.0-S)

[Stephen McKay]

On Friday, 14th July 2000, Matthew Jacob wrote:

>
>> That theory is not correct, I have seen multiple Alpha machines reporting 
>> buffer underruns as well. No ATA disk in sight there..
>
>This has been a reported feature of the tulip chip and alphas (de driver
>usually) forever forever forever.

And there's no guarantee that there is just one cause.  If the dc driver
with BX and ZX chipsets never has an underrun, and the 2 VIA chipsets I've
tried always cause underruns, there might be something we can fix.  Even
if we never manage to fix it on Alphas.

>It's not a bug, per se, IMO.

In the i386 case, there's some sort of PCI bus starvation.  Maybe we can
fix it.  Maybe not.  We can at least try to categorise it.  Maybe it's
as simple as a BIOS option we should tweak.

Stephen.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: **HEADS UP** if you used to cvsup the crypto repo from internat !

[Udo Erdelhoff]

On Fri, Jul 14, 2000 at 01:56:31PM +0200, Sheldon Hearn wrote:
> Also, he clarified the last sentence for me, by saying that it's the
> crypto ,v files that need to be removed and not the checked out crypto
> files.

What about the non-US cvsup mirrors? Most of them used cvsup to mirror
the crypto distributions from internat. Does this mean that these mirrors
have to nuke theier local copies (of the crypto files), too? That would
be a major problem for all users of these mirrors. They would have to
wait until "their" mirror fixed it's copy...

Is it possible to check if a repository is affected? Something along the
lines of "/home/ncvs/src/crypto/foo.c should have revision bar, last
commit by ... on ..., the md5 should be ..."

/s/Udo
-- 
"People who claim Windows in superior to Unix are the same people who'd
 argue that you better use your hand instead of toilet paper to wipe your
 ass. I can hear them now - 'It's colourful and it's intuitive and easy
 to use and even a child could do it.'".


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: **HEADS UP** if you used to cvsup the crypto repo from internat !

[Charles Anderson]

How can I tell if I need to nuke my crypto files?  Sounds like I should
have this problem but it doen't look like I do.  I looked through the
commits for the past few days searching for crypto, and I have all of the
files that were commited.  (secure/lib/libcrypto/Makefile & Makefile.inc from
earlier today & crypto/openssh/ readconf.c, servconf.c, ssh_config, sshd.8,
& /telnet/libtelnet/auth.c from 7/11/00)

thanks,
-Charlie
On Wed, Jul 12, 2000 at 03:05:25PM +0100, Brian Somers wrote:
> I haven't looked into it too deeply yet because of other source tree 
> problems, but if you used to get your crypto ,v files from internat, 
> you will suffer some funny problems unless you nuke the old checked-out 
> files.
> 
> My apologies if this is old news, but I see nothing in UPDATING.
> 
> The problem occurs when you cvsup the new crypto-in-src-all sources 
> and replace RCS files with different contents and the same version 
> number.  cvs update/checkout compares the repo version number against 
> the checked out version number and considers the file an ``M'' 
> (modified source).  The file isn't updated and your world gets 
> corrupted.
> 
> This is probably a candidate for UPDATING.
> -- 
> 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

-- 
Charles Anderson[EMAIL PROTECTED]

No quote, no nothin'


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: **HEADS UP** if you used to cvsup the crypto repo from internat !

[Sheldon Hearn]

On Fri, 14 Jul 2000 07:36:38 EST, David Scheidt wrote:

> :Warner, Mark says that this applies if you used CTM to get cvs's ,v
> :files, not CTM.  Also, he clarified the last sentence for me, by saying
> 
> Should this read "used CTM ... not CVS" or "used CVS ... not CTM"?  

Argh, what is it about this one? :-)

That should have read:

Warner, Mark says that this applies if you used CTM and not
CVSup to get cvs's ,v files.

Sorry,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: **HEADS UP** if you used to cvsup the crypto repo from internat !

[David Scheidt]

On Fri, 14 Jul 2000, Sheldon Hearn wrote:

:
:
:On Thu, 13 Jul 2000 19:19:48 +0200, Mark Murray wrote:
:
:> > 2711:
:> >If you used to get your crypto files from internat, AND you
:> >used cvsup to get cvs' ,v files, then the latest changes
:> >to the source collections will impact you.  You will need to
:> >remove all the crypto files and start over.
:
:Warner, Mark says that this applies if you used CTM to get cvs's ,v
:files, not CTM.  Also, he clarified the last sentence for me, by saying

Should this read "used CTM ... not CVS" or "used CVS ... not CTM"?  

DAvid



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: **HEADS UP** if you used to cvsup the crypto repo from internat !

[Sheldon Hearn]

On Thu, 13 Jul 2000 19:19:48 +0200, Mark Murray wrote:

> > 2711:
> > If you used to get your crypto files from internat, AND you
> > used cvsup to get cvs' ,v files, then the latest changes
> > to the source collections will impact you.  You will need to
> > remove all the crypto files and start over.

Warner, Mark says that this applies if you used CTM to get cvs's ,v
files, not CTM.  Also, he clarified the last sentence for me, by saying
that it's the crypto ,v files that need to be removed and not the
checked out crypto files.

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

ports/fetch problem on Current

[Shaun Courtney]

Hi 

I'm having two problems on current (5.0-CURRENT FreeBSD 5.0-CURRENT #6:
Fri Jul 7 20:04:56 SAST 2000 for kernel, binaries Jul 13, libfetch
and fetch 14 Jul) with the ports.

One: fetch never stops! 
For example:

su-2.03# make
>> GnuPG-Interface-0.09.tar.gz doesn't seem to exist on this system.
>> Attempting to fetch from 
>ftp://ftp.digital.com/pub/plan/perl/CPAN/modules/by-module/GnuPG/.

65755 bytes transferred in 591.1 seconds (111.24 Bps)
>> Attempting to fetch from ftp://ftp.cpan.org/CPAN/modules/by-module/GnuPG/.

65755 bytes transferred in 42.5 seconds (1.51 kBps)
>> Attempting to fetch from 
>ftp://ftp.freesoftware.com/pub/perl/CPAN/modules/by-module/GnuPG/.

65755 bytes transferred in 18.4 seconds (3.50 kBps)
>> Attempting to fetch from 
>ftp://ftp.sourceforge.net/pub/mirrors/CPAN/modules/by-module/GnuPG/.

Basically what happens it that for each master site listed in the Makefile a
fetch is done.

Secondly:

if I do a "make" in a port and then ^c to abort the fetch continues...
(I do this because in Africa overseas sites can be very slow - so I do
an archie on local sites to pull source from something closer...) Okay 
so I kill the fetch - it just moves to the next site listed - now 
for apache13 that is about 15 sites... I notice that 
 9059  p0  S  0:00.00 /bin/sh -ec (cd /usr/ports/distfiles/;  for file in
a
 9060  p0  S  0:00.01 /bin/sh -ec (cd /usr/ports/distfiles/;  for file in
A
runs for each make in a port directory.

My /etc/make.conf is:
USA_RESIDENT=NO
NO_SENDMAIL=true# do not build sendmail and related programs


Can anyone suggest a fix or workaround. This does not occur on my 3.5-STABLE
and 4.0-STABLE boxes.

Thanks

Shaun



-- 
Faculty of Engineering and the Built Environment
 Information Technology Manager
0 828 228822 / 650 2800


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

ether_ifattach() change and VMware

[Munehiro Matsuda]

Date: Thu, 13 Jul 2000 15:54:35 -0700 (PDT)
From: Archie Cobbs <[EMAIL PROTECTED]>
::
::archie  2000/07/13 15:54:35 PDT
::
::  Modified files:

::  Log:
::  Make all Ethernet drivers attach using ether_ifattach() and detach using
::  ether_ifdetach().
::  
::  The former consolidates the operations of if_attach(), ng_ether_attach(),
::  and bpfattach(). The latter consolidates the corresponding detach operations.
::  
::  Reviewed by:julian, freebsd-net

Hello,

After the commit, VMware seems to hang the system at boot time.
The "vmnet" module, that comes with VMware, needs the included patch.

Shouldn't we bump version or something, due to the kernel API change?

---8<--8<--8<-- patch for VMware --8<--8<--8<--8<---
--- vmnet-only/freebsd/vmnet.c.org  Fri Jul 14 16:18:50 2000
+++ vmnet-only/freebsd/vmnet.c  Fri Jul 14 16:21:51 2000
@@ -156,9 +156,7 @@
DLog(Linfo, DEVICE_NAME "%d: Ethernet address: %6D", ifp->if_unit, 
sc->iface.arpcom.ac_enaddr, ":");
 
s = splimp();
-   if_attach(ifp);
-   ether_ifattach(ifp);
-   bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header));
+   ether_ifattach(ifp, ETHER_BPF_SUPPORTED);
splx(s);

return 0;
---8<--8<--8<--8<--8<--8<--8<--8<--8<---

Thank you,
  Haro
=--
   _ _Munehiro (haro) Matsuda
 -|- /_\  |_|_|   Business Incubation Dept., Kubota Corp.
 /|\ |_|  |_|_|   1-3 Nihonbashi-Muromachi 3-Chome
  Chuo-ku Tokyo 103-8310, Japan
  Tel: +81-3-3245-3318  Fax: +81-3-3245-3315
  Email: [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: config/hints changes: panic booting pcvt kernel

[Hellmuth Michaelis]

>From the keyboard of John Polstra:

> > i added a printf statement to the beginning of every subroutine in 
> > file /sys/dev/kbd/kbd.c and with this additions the panic disappears
> > and pcvt runs fine as ever.
> > 
> > Removing the printf's from kbd.c shows the usual described panic.
> > 
> > I'm now completely out of ideas 
> 
> It sounds like maybe an uninitialized local variable in one of the
> functions.

This should cause a warning from the compiler, shouldn't it ?
All the files in question compile without any warning at all.

hellmuth
-- 
Hellmuth MichaelisTel   +49 40 55 97 47-70
HCS Hanseatischer Computerservice GmbHFax   +49 40 55 97 47-77
Oldesloer Strasse 97-99   Mail  hm [at] hcs.de
D-22457 Hamburg   WWW   http://www.hcs.de


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: fetch appears to be broken

[Dag-Erling Smorgrav]

Greg Lehey <[EMAIL PROTECTED]> writes:
> On Friday, 14 July 2000 at 10:53:42 +0200, Dag-Erling Smorgrav wrote:
> > Looks like stale sources. The -1 bug was fixed a few days ago.
> Well, this was a buildworld of 10 July.  I haven't updated since then
> because the kernel keeps crashing.

Update libfetch and fetch and try again. If you're still having
trouble, rebuild libfetch with debugging enabled, run fetch -vvv and
mail me the output.

# cd /usr/src
# cvs update -A lib/libfetch usr.bin/fetch
# cd lib/libfetch
# make clean && make depend && make -DDEBUG && make install
# cd ../../usr.bin/fetch
# make && make install

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: fetch appears to be broken

[Greg Lehey]

On Friday, 14 July 2000 at 10:53:42 +0200, Dag-Erling Smorgrav wrote:
> Greg Lehey <[EMAIL PROTECTED]> writes:
>> Since my last buildworld, fetch no longer works properly:
>>
>>   $ fetch http://www.bom.gov.au/cgi-bin/wrap_fwo.pl?IDS10034.txt
>>   Receiving wrap_fwo.pl?IDS10034.txt
>>   -1 bytes transferred in 0.7 seconds (-1.47 Bps)
>
> Looks like stale sources. The -1 bug was fixed a few days ago.

Well, this was a buildworld of 10 July.  I haven't updated since then
because the kernel keeps crashing.

> It's purely cosmetic, BTW; the file whould be there all right.

That's not what the embedded script found.

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: fetch appears to be broken

[Dag-Erling Smorgrav]

Greg Lehey <[EMAIL PROTECTED]> writes:
> Since my last buildworld, fetch no longer works properly:
> 
>   $ fetch http://www.bom.gov.au/cgi-bin/wrap_fwo.pl?IDS10034.txt
>   Receiving wrap_fwo.pl?IDS10034.txt
>   -1 bytes transferred in 0.7 seconds (-1.47 Bps)

Looks like stale sources. The -1 bug was fixed a few days ago. It's
purely cosmetic, BTW; the file whould be there all right.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: kerneld for -current

[Neil Blakey-Milner]

On Thu 2000-07-13 (13:46), Yevmenkin, Maksim N, CSCIO wrote:
> long time back there was a discussion about kerneld for FreeBSD.
> some people have found it useless, but some not :)
> 
> anyway, alpha version of code can be found at sourceforge.net.
> 
> http://sourceforge.net/projects/kerneld/
> 
> changes:
> 
> - minor bug fixes
> - kd device improvements (now support select)
> - kerneld now has access control list
>   to accept/deny request from users/group
>  (thanks to Someone from the list for the idea,
>   sorry don't remember The Name :)

What, exactly, does it do?  Can you write a quick blurb about it, so we
can see what the features are, what it buys us, why we want it, and
things like that?

Neil
-- 
Neil Blakey-Milner
Sunesi Clinical Systems
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

fetch appears to be broken

[Greg Lehey]

Since my last buildworld, fetch no longer works properly:

  $ fetch http://www.bom.gov.au/cgi-bin/wrap_fwo.pl?IDS10034.txt
  Receiving wrap_fwo.pl?IDS10034.txt
  -1 bytes transferred in 0.7 seconds (-1.47 Bps)

It would be nice to have an error message here, not to mention a more
accurate bottom line, but in fact there doesn't seem to be anything
wrong with the site:

  $ ftp http://www.bom.gov.au/cgi-bin/wrap_fwo.pl?IDS10034.txt
  Requesting http://www.bom.gov.au/cgi-bin/wrap_fwo.pl?IDS10034.txt
  Successfully retrieved file.

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: dc driver and underruns (was: Strangeness with 4.0-S)

[Matthew Jacob]

> That theory is not correct, I have seen multiple Alpha machines reporting 
> buffer underruns as well. No ATA disk in sight there..

This has been a reported feature of the tulip chip and alphas (de driver
usually) forever forever forever.

It's not a bug, per se, IMO.




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

$B:G=i$G:G8e$N>pJsDs6!!*(B

[fuuyan]

$B$3$N%a!=%k$N%"%I%l%9$O<}=86He$2$^$9!#(B

$B;d$O2<5-#3E@$N%S%8%M%9$GKh7n(B40$B!A(B85$BK|$N<}F~$,$"$j$^$9!#(B
$B!J3+;O8e#3%v7nL\0L$G!"K\?&$N<}F~$OF~$l$:!*!K(B

$B!c!cI,8+!*9bB.9b<}F~>pJs!*!*!d!d(B
$B%"%a%j%+$rH/>MCO$H$7$?6<0RE*$J9b<}F~:_Bp%S%8%M%9$G$9!*(B
$B:#7n$K$J$C$F;22Ce$N<}F~$rF@(B
$B$F$$$^$9!*(B
$B:n6HFbMF$b4JC1$G$9!#@kEA$9$k$@$1!*K\Ev$K6u$$$F$k;~4V$G$G$-$^$9!#(B
$BL5NA@kEA>l=j>pJs$bL5NA$GDs6!$7$^$9!*(B
$BL5NAEj9F%a%k%^%,%5%$%H(B100$B0J>e!"4uK>http://www.sensyu.ne.jp/fuji/index.htm

$B!c0u@GE*!uM%NI3tE*<}F~!d(B
$BG/2qHq(B1$BK|1_$G$=$N8e$O2?$b$7$J$/$F$bKhG/(B2048000$B1_$N%\!<%J%9$,=P$k(B
Wax$B%S%8%M%9!*(B
$B$I$&$7$?$i$3$&8@$C$?%7%9%F%`$K$J$k$N$+>\:Y@bL@$7$F$$$^$9!*(B
7/17$B%5!<%S%93+;O!*$G$9$N$G(B
$B8=:_EPO?u$OF|$K(B80$B$[$IEPO?http://www.sensyu.ne.jp/fuji/p1.htm 
$B!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a(B
$B<+F0%@%&%s9=C[%W%m%0%i%`(B1$B!W!JL5NA!K(B
$BBg9%$-$J%$%s%?!<%M%C%H$r$9$k$@$1$GKh7n(B85$BK|1_$NJs=73[(B
$B$3$N%W%m%0%i%`$O9-9p<}F~7O%W%m%0%i%`!J(Balladvantag,be paid$BEy$=$N(B
$BB>?t==http://www.sensyu.ne.jp/fuji/dm.htm
$B!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a(B

 $B:G8e$^$G8fFI$_D:$-M-Fq$&8f:B$$$^$7$?!#(B




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: dc driver and underruns (was: Strangeness with 4.0-S)

[Wilko Bulte]

On Fri, Jul 14, 2000 at 12:51:14PM +1000, Stephen McKay wrote:
> On Thursday, 13th July 2000, "Rodney W. Grimes" wrote:
> 
> >>On Thu, 13 Jul 2000, Stephen McKay wrote:
> >> 
> >>>Does anyone here actually measure these latencies?  I know for a fact
> >>>that nothing I've ever done would or could be affected by extra latencies
> >>>that are as small as the ones we are discussing.  Does anybody at all
> >>>depend on the start-transmitting-before-DMA-completed feature we are
> >>>discussing?
> >> 
> >> I don't like the idea of removing that feature.  Perhaps it should be a
> >> sysctl or ifconfig option, but it should definitely remain available.
> >> Those minute latencies are critical to those of us who use MPI for
> >> complex parallel calculations.
> >
> >I have to agree here.  The store and forward adds an approximate
> >11uS (by theory under ideal conditions 1500bytes@132MB/s = 11uS,
> >practice actually makes this worse as typical PCI does something
> >less than 100MB/s or 15uS) to a 120uS packet time on the wire (again,
> >ideal, but here given that switches, and infact often cut-through
> >switches, are used for these types of things, ideal and practice
> >are very close.)
> >
> >I don't think these folks, nor myself, are wanting^H^H^H^H^H^H^Hilling
> >to give up 12.5%.
> 
> OK.  It seems that repairing the feature, rather than disabling it is
> the most popular option.  Still, I am quite interested in finding anyone
> who actually measures these things, and is affected by them.  These very
> same people might be able to trace why we get the underruns in the first
> place.  I suspect an interaction between the ATA driver and VIA chipsets,
> because other than the network, that's all that is operating when I see
> the underruns.  And my Celeron with a ZX chipset is immune.

That theory is not correct, I have seen multiple Alpha machines reporting 
buffer underruns as well. No ATA disk in sight there..

-- 
Wilko Bulte http://www.freebsd.org  "Do, or do not. There is no try"
[EMAIL PROTECTED]   http://www.nlfug.nl Yoda - The Empire Strikes Back


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message