Re: Problem with dlopen()/dlsym() after recent crt* changes

[Maxim Sobolev]

Jordan Hubbard wrote:

  After the crt changes the following piece of code, which worked previously,
  gives a 'host: dlopen() failed: ./module.so: Undefined symbol
  "__register_frame_info' error message (yeah, I know that it's better to check
  handle == NULL first, but it's the way some apps work).

 Huh!  So that's why my XFree86 server no longer loads its glx.so
 module (thought I rebuilt it several times just to make sure it wasn't
 something which rotted on my system).  This one's kinda serious! :-(
 I get the exact same message from the X server.

Don't bother - I've already made a fix (workarround) and will commit it shortly. ;)

-Maxim



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

Re: Problem with dlopen()/dlsym() after recent crt* changes

[Maxim Sobolev]

Jordan Hubbard wrote:

  After the crt changes the following piece of code, which worked previously,
  gives a 'host: dlopen() failed: ./module.so: Undefined symbol
  "__register_frame_info' error message (yeah, I know that it's better to check
  handle == NULL first, but it's the way some apps work).

 Huh!  So that's why my XFree86 server no longer loads its glx.so
 module (thought I rebuilt it several times just to make sure it wasn't
 something which rotted on my system).  This one's kinda serious! :-(
 I get the exact same message from the X server.

Just committed a fix. Please update your ports and try again.

-Maxim



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

Re: Problem with dlopen()/dlsym() after recent crt* changes

[Kris Kennaway]

On Mon, Nov 06, 2000 at 10:14:32AM +0200, Maxim Sobolev wrote:

 Jordan Hubbard wrote:
 
   After the crt changes the following piece of code, which worked previously,
   gives a 'host: dlopen() failed: ./module.so: Undefined symbol
   "__register_frame_info' error message (yeah, I know that it's better to check
   handle == NULL first, but it's the way some apps work).
 
  Huh!  So that's why my XFree86 server no longer loads its glx.so
  module (thought I rebuilt it several times just to make sure it wasn't
  something which rotted on my system).  This one's kinda serious! :-(
  I get the exact same message from the X server.
 
 Don't bother - I've already made a fix (workarround) and will commit it shortly. ;)

I see the same thing with gnupg plugins. Obviously a workaround won't
work if we've broken binary compatability :-(

Kris

 PGP signature

Re: Problem with dlopen()/dlsym() after recent crt* changes

[Maxim Sobolev]

Kris Kennaway wrote:

 On Mon, Nov 06, 2000 at 10:14:32AM +0200, Maxim Sobolev wrote:

  Jordan Hubbard wrote:
 
After the crt changes the following piece of code, which worked previously,
gives a 'host: dlopen() failed: ./module.so: Undefined symbol
"__register_frame_info' error message (yeah, I know that it's better to check
handle == NULL first, but it's the way some apps work).
  
   Huh!  So that's why my XFree86 server no longer loads its glx.so
   module (thought I rebuilt it several times just to make sure it wasn't
   something which rotted on my system).  This one's kinda serious! :-(
   I get the exact same message from the X server.
 
  Don't bother - I've already made a fix (workarround) and will commit it shortly. ;)

 I see the same thing with gnupg plugins. Obviously a workaround won't
 work if we've broken binary compatability :-(

I hope jdp/obrien will come with appropriate fix *before* 4.2-RELESE.

-Maxim



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

Re: -current hangs during boot

[Mark Murray]

 Did I miss something on the /dev/random hang?

I don't know...

 During a `shutdown -r now`, the boot process hangs for more than an
 hour.  I thought this was supposed to work.  However, jwd's receipe
 for recovery works.  I repeated this three times, although I only
 waited an hour the last time (dinner!).
 
 I am running a recent SMP system, uname and dmesg below.

Are you _completely_ up to date with /etc/*? Dou you run mergemaster
after each make world/make kernel?

M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org


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

auth 04723f85 subscribe freebsd-current mfl@alcove.fr

[Christophe Le Bars]

auth 04723f85 subscribe freebsd-current [EMAIL PROTECTED]



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

i-mode$BMQ%j%"%k%?%$%`E9J^9-(B$B9p(BHP$B$N$40FFb(B

[ittoku.net$B?d?J;v6HIt(B]

$B$O$8$a$^$7$F!"FMA3$N%a!<%k$r$*5v$7$/$@$5$$!#(B$B$b$7$4IT2w$@$H;W$o$l$?>l9g$OJV?.$7$F$$$?$@$-$^$7$?$i!!%j%9%H$+$i:o=|$5$;$F$$$?$@$-$^$9!#(B

$B;d6&(Bittoku.net$B$O!"#1#17n#1F|$K@5<0H/B-$7$^$7$?7HBS%3%s%F%s%DAm9g%M%C%H$G$9!#(B
$B:#$d8\5R3MF@$NHs>o$KFq$7$$K\Ev$KNI$$$b$N$@$1$rE,@5$J2A3J$GDs6!$7$J$1$l$P!"@8$-;D$l$J$$;~Be$H$J$j$^$7$?!#(B
$B%$%s%?!<%M%C%H$dOCBj$N(Bi$B%b!<%I$r3hMQ$7$h$&$K$bJ}K!O@$,2r$i$J$$!"$"$k$$$O!"%$%s%?!<%M%C%H$G%5!<%P!<$rN)$A>e$2$k$N$K$O%3%9%H$,3]$+$j$9$.$kEy!"Fq$7$$LdBj$,;3@Q$_$G$9!#(B
$B$=$3$G!"$3$NEY$^$C$?$/?7$7$$(Bi-mode$BMQ%j%"%k%?%$%`E9J^9-9p(BHP$B$r%9%?!<%H$$$?$7$^$9!#(B

$BEv%M%C%H$O!"8\5R$G$"$k>&7w$N?M$?$A$r3MF@$9$k0Y$N%5%$%H$rL\;X$7$F$$$^$9!#(B
$B$D$^$j!"K\Ev$N0UL#$G$N%T%s%]%$%s%H@oN,$r%$%s%?!<%M%C%H$N(Bi$B%b!<%I$rMxMQ$9$k;v$G!"9T$&$3$H$,=PMh$k$N$G$9!#(B
$BJ8;zDL$j!"E9J^$N99?7!$,%Q%=%3%s$O$b$A$m$s(Bi-mode$B$+$i$G$b4JC1$K=PMh$k0Y!"E9$N>u67$r8+$J$,$i(B$B$=$N>l$G>pJs$rH/?.$9$k$3$H$,=PMh$^$9!#(B

$B2A3J$b!!(B3$B%v7n#1K|1_$HHs>o$K0B2A(B$B$K2!$5$(!"%*%W%7%g%s$GE9$NCO?^$b7G:\2DG=$G$9!#(B
$B$5$i$K:#$J$i(B1$B%v7n4V$N$*;n$74|4V!"(B11$B7n@.LspJs$b$4$6$$$^$9!#(B



$B$D$-$^$7$F$OFC$K2<5-$N$h$&$JJ}$K@'HsCN$C$FD:$-$?$/;W$C$F$$$^$9$N$G6=L#$"$kJ}$O0lEY>R2p(BHP$B$r$4Mw2<$5$$(B*$B!!E9J^$r7P1D$^$?$O7H$o$C$F$$$kJ}(B*$B!!E9J^$r7P1D$^$?$O7H$o$C$F$$$kJ}$NG:$_$rJ9$$$?$3$H$,$"$kJ}(B*$B!!%5%$%I%S%8%M%9$r9M$($i$l$F$$$kJ}(B 


$B6qBNE*$KMxMQ$5$l$k$3$H$G%a%j%C%H$,$"$kJ}(B$B:#$^$G$*5R$5$s$,Mh$k;~$H$=$&$G$J$$>l9g$N;~$H$N:9$,7c$7$$E9$NJ}(B 
$B9-9p$K$*6b$,$+$+$j$9$.$k$H;W$C$F$*$i$l$kJ}(B $B<+K}$N>$r$b$C$HCN$C$F$b$i$$$?$$$H;W$C$F$*$i$l$kJ}(B 
$B:#F|Cf$KGd$j@Z$j$?$$>$,=P$k$3$H$,NI$/$"$kJ}(B $B:#$*5R$5$s$KCN$i$;$?$$$3$H$,$"$k$N$KJ}K!$,$J$$$H;W$C$?$3$H$N$"$kJ}(B 
$B%[!<%`%Z!<%8$r=P$7$?$1$I:#0lH?1~$,$J$$$H$$$}(B $B85R2p(BHP$B%"%I%l%9!!(Bhttp://ittoku.net/hp/$B".".".".".".".".".".(B///ittoku.net 
$B?d?J;v6HIt!!C4Ev!!>.@>(B $BBg:e;TCf1{6h?4:X666Z(B2-7-2 TEL 06-6211-4726 FAX06-6211-6049 
$BD>DL(BTEL 06-6211-4733 [EMAIL PROTECTED]//$B".".".".".".".".".".(B

IP wierdness...

[Justin T. Gibbs]

After the recent introduction of cardbus support into -current, I
decided to upgrade my laptop.  At first glance, the system seemed
to support a Xircom "Real Port" 10/100/56K modem card with the
dc driver.  The funny thing though is that, although I can initiate
IP or TCP connections to remote hosts, the system seems to drop
all incoming connections.  This even applies to ICMP traffic.
For instance, a 4.1-stable machine can not ping my laptop, but
the laptop can ping/telnet/ftp to the 4.1-stable machine.  Looking
at tcpdump traces on the laptop, it appears that the ICMP echo
request is received correctly, but the system never responds.
I'm not running IPSEC or ipfw, and all of the sysctls that seem
to be related to filtering or rate limiting incoming packets look
normal.  I'm running -current as of a few hours ago, but this
has been broken for me for at least a week in -current.

--
Justin


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

ad1 is not detected.

[Szilveszter Adam]

Hi!

I have just completed a new kernel build (to test the sound:-) but now I
have a similar problem to that reported on -stable wrt 4.2-BETA. Upon boot,
ad1 (sitting on ata0 as slave) is not recognized and therefore the boot
cannot complete. I have even remade the devices because MAKEDEV was changed,
but it was not the solution. I have completed a buildworld too so sources
userland and kernel are definitely in sync.

Of course, I can reconfigure ad1 to become seconadry master (and probably
that is what I will try next) but this problem seems to be serious and 
related to
the one on -STABLE so I thought I would report it. Of course, IDE slave
disks always worked on this system before. In my kernel config I only have 

device ata
device atadisk
device atapicd

The disks are Quantum FireBall lct15 on ad0 and Q. Fireball SE 4.3A as
ad1 but I do not think this should matter. FYI, the ATAPI CD-ROM sitting on
ata1 master was detected without probs.

Any ideas?

-- 
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: ad1 is not detected.

[Soren Schmidt]

It seems Szilveszter Adam wrote:
 Hi!
 
 I have just completed a new kernel build (to test the sound:-) but now I
 have a similar problem to that reported on -stable wrt 4.2-BETA. Upon boot,
 ad1 (sitting on ata0 as slave) is not recognized and therefore the boot
 cannot complete. I have even remade the devices because MAKEDEV was changed,
 but it was not the solution. I have completed a buildworld too so sources
 userland and kernel are definitely in sync.
 
 Of course, I can reconfigure ad1 to become seconadry master (and probably
 that is what I will try next) but this problem seems to be serious and 
 related to
 the one on -STABLE so I thought I would report it. Of course, IDE slave
 disks always worked on this system before. In my kernel config I only have 
 
 device ata
 device atadisk
 device atapicd
 
 The disks are Quantum FireBall lct15 on ad0 and Q. Fireball SE 4.3A as
 ad1 but I do not think this should matter. FYI, the ATAPI CD-ROM sitting on
 ata1 master was detected without probs.
 
 Any ideas?

Damn, why cant I reproduce this misbehavior, please feel free to investigate
why the probe code fails, and then please tell me...

-Søren


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

Re: Problem with dlopen()/dlsym() after recent crt* changes

[John Polstra]

In article [EMAIL PROTECTED],
Maxim Sobolev  [EMAIL PROTECTED] wrote:
 After the crt changes the following piece of code, which worked previously,
 gives a 'host: dlopen() failed: ./module.so: Undefined symbol
 "__register_frame_info' error message (yeah, I know that it's better to check
 handle == NULL first, but it's the way some apps work).
 
  handle = dlopen("./module.so", RTLD_LAZY);
  if ((error = dlerror()) != NULL)
  {
   errx(1, "dlopen() failed: %s", error);
   /* Not reached */
  }

I personally think this code is broken.  It's analogous to checking
errno without first testing a system call's return value.

 The full sources of this testcase can be found at:
 http://people.freebsd.org/~sobomax/dlbug.tar.gz .

OK, thanks.  I'll take a look at it as soon as I can -- hopefully
tonight.  If I can come up with a reasonable work-around, I'll do so.

John
-- 
  John Polstra   [EMAIL PROTECTED]
  John D. Polstra  Co., Inc.Seattle, Washington USA
  "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa



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

Re: ad1 is not detected.

[Szilveszter Adam]

On Mon, Nov 06, 2000 at 04:27:32PM +0100, Soren Schmidt wrote:
 
 Damn, why cant I reproduce this misbehavior, please feel free to investigate
 why the probe code fails, and then please tell me...
 
 -Søren

:-) Relax. We will sort this out somehow.

I will try what I can. For now, further hardware details:

Machine is on a Spacewalker mobo with Intel LX 440 chipset. (so no VIA @
work this time) and a PII233. The probe code worked correctly on a world 
kernel from 3rd November. No Promise etc or similar cards in the system just
the on-board controller.

This narrows down the window to the last couple of days, there were not many
files changed there wrt to ata. I will try things and will get back to you
immediately. (unfortunately machine cannot send mail directly because of
stupid university firewall.)

The only interesting thing is: Why were there no reports from -CURRENT users
this far when this thing bit at least one person on -STABLE already? Is this
such a rare occurence?
 
-- 
Regards:

Szilveszter ADAM
Szeged University
Szeged Hungary


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

tar : needs some attention?

[John W. De Boskey]

Hi,

   Each night I run a 'make release' and then tar it off to
a public storage area...

   For some time now, tar has been complaining...

tar: cdrom/disc2/dev/acd0t32: minor number too large; not dumped
tar: cdrom/disc2/dev/acd0t33: minor number too large; not dumped
tar: cdrom/disc2/dev/acd0t34: minor number too large; not dumped
tar: cdrom/disc2/dev/acd0t35: minor number too large; not dumped
tar: cdrom/disc2/dev/acd0t36: minor number too large; not dumped
tar: cdrom/disc2/dev/acd0t37: minor number too large; not dumped
tar: cdrom/disc2/dev/acd0t38: minor number too large; not dumped
tar: cdrom/disc2/dev/acd0t39: minor number too large; not dumped

   Is this the expected behaviour, or is it worth digging into
tar and making some fixes?

-John

ps: This is on a current machine :-)



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

Cardbus 3Com Megahertz Model 3CXFEM656C

[Jan Knepper]

Hi,

Does anyone know anything about the patch Jon made for this
cardbus card during the BSD Con 2000?

Thanks!
Jan





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

Re: ad1 is not detected.

[Soren Schmidt]

It seems Szilveszter Adam wrote:
 On Mon, Nov 06, 2000 at 04:27:32PM +0100, Soren Schmidt wrote:
  
  Damn, why cant I reproduce this misbehavior, please feel free to investigate
  why the probe code fails, and then please tell me...
  
  -Søren

 Machine is on a Spacewalker mobo with Intel LX 440 chipset. (so no VIA @
 work this time) and a PII233. The probe code worked correctly on a world 
 kernel from 3rd November. No Promise etc or similar cards in the system just
 the on-board controller.
 
 This narrows down the window to the last couple of days, there were not many
 files changed there wrt to ata. I will try things and will get back to you
 immediately. (unfortunately machine cannot send mail directly because of
 stupid university firewall.)
 
 The only interesting thing is: Why were there no reports from -CURRENT users
 this far when this thing bit at least one person on -STABLE already? Is this
 such a rare occurence?

The problem has been around for at least a couble of month both in
current and stable, but only a select few has seen it, I've chased
it with any drive/controller I have access to, but hasn't been able
to reproduce it..
If you can find a way that I can reproduce it, I'm sure I can
fix the problem in a few minutes.. ssh access to a box that has
this problem could also help, but "hands on" are often much better
for this kind of problems...

-Søren


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

Re: tar : needs some attention?

[Matthew Jacob]

On Mon, 6 Nov 2000, John W. De Boskey wrote:

 Hi,
 
Each night I run a 'make release' and then tar it off to
 a public storage area...
 
For some time now, tar has been complaining...
 
 tar: cdrom/disc2/dev/acd0t32: minor number too large; not dumped
 tar: cdrom/disc2/dev/acd0t33: minor number too large; not dumped
 tar: cdrom/disc2/dev/acd0t34: minor number too large; not dumped
 tar: cdrom/disc2/dev/acd0t35: minor number too large; not dumped
 tar: cdrom/disc2/dev/acd0t36: minor number too large; not dumped
 tar: cdrom/disc2/dev/acd0t37: minor number too large; not dumped
 tar: cdrom/disc2/dev/acd0t38: minor number too large; not dumped
 tar: cdrom/disc2/dev/acd0t39: minor number too large; not dumped
 
Is this the expected behaviour, or is it worth digging into
 tar and making some fixes?

Nope. Expected behaviour for interoperability with other unix systems.





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

Re: tar : needs some attention?

[Jeroen Ruigrok van der Werven]

-On [20001106 17:10], John W. De Boskey ([EMAIL PROTECTED]) wrote:
tar: cdrom/disc2/dev/acd0t39: minor number too large; not dumped

   Is this the expected behaviour, or is it worth digging into
tar and making some fixes?

I am hoping to update tar soon these weeks.

Don't know yet if that's expected behaviour.

-- 
Jeroen Ruigrok van der Werven  Network- and systemadministrator
[EMAIL PROTECTED]VIA Net.Works The Netherlands
BSD: Technical excellence at its best  http://www.via-net-works.nl
In my mind nothing makes sense...


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

Weird errors during kernel build

[drwilco]

=== rp
@ - /usr/src/sys
machine - /usr/src/sys/i386/include
perl @/kern/makeobjops.pl -h @/kern/device_if.m
perl @/kern/makeobjops.pl -h @/kern/bus_if.m
perl @/kern/makeobjops.pl -h @/pci/pci_if.m
mv /tmp/htmp.87764 ./pci_if.h failed, 27 at @/kern/makeobjops.pl line 424.

This is one example. It fails a bit further down because the header file
is missing.

This is during "make depend" using fresh world. Both "make
buildkernel" and installing world and using regular kernel building
procedures give me this.

I have enough memory free and enough diskspace.

When I run the make depend again it succeeds to fail on a different module
after that

DocWilco

P.S.: rl was the 3rd to fail, it failed on sound/driver/emu10k1 during the
retry.



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

Re: Weird errors during kernel build

[Clive Lin]

Hi, 

   I'm just curious, did you use threaded perl on a quite rescent -current
system ? If so, don't use threaded perl. I got the same situation several
days ago, and on each trial it missed *different* header files :-( After
re-buildworld without PERL_THREADED= true in /etc/make.conf, everyting goes
just fine.

On Mon, Nov 06, 2000 at 01:22:13PM -0500, drwilco wrote:
 === rp
 @ - /usr/src/sys
 machine - /usr/src/sys/i386/include
 perl @/kern/makeobjops.pl -h @/kern/device_if.m
 perl @/kern/makeobjops.pl -h @/kern/bus_if.m
 perl @/kern/makeobjops.pl -h @/pci/pci_if.m
 mv /tmp/htmp.87764 ./pci_if.h failed, 27 at @/kern/makeobjops.pl line 424.
 
 This is one example. It fails a bit further down because the header file
 is missing.

-- 
CirX - This site doesnt' exist.
9c  k9o h9 s1bg s1f, 7v  .y xqx a  sj m8r ffg1 vg5 a6 asox tmul h38 .
ant sj m8r ob ? 1fj mwby a1 tao vg5. soq df v ' .a. CirX.


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

Re: Weird errors during kernel build

[drwilco]

Yes I do have PERL_THREADED=true. Or rather I did have it until a minute
ago =)

DocWilco

On Tue, 7 Nov 2000, Clive Lin wrote:

 Hi, 
 
I'm just curious, did you use threaded perl on a quite rescent -current
 system ? If so, don't use threaded perl. I got the same situation several
 days ago, and on each trial it missed *different* header files :-( After
 re-buildworld without PERL_THREADED= true in /etc/make.conf, everyting goes
 just fine.
 
 On Mon, Nov 06, 2000 at 01:22:13PM -0500, drwilco wrote:
  === rp
  @ - /usr/src/sys
  machine - /usr/src/sys/i386/include
  perl @/kern/makeobjops.pl -h @/kern/device_if.m
  perl @/kern/makeobjops.pl -h @/kern/bus_if.m
  perl @/kern/makeobjops.pl -h @/pci/pci_if.m
  mv /tmp/htmp.87764 ./pci_if.h failed, 27 at @/kern/makeobjops.pl line 424.
  
  This is one example. It fails a bit further down because the header file
  is missing.
 
 -- 
 CirX - This site doesnt' exist.
 9c  k9o h9 s1bg s1f, 7v  .y xqx a  sj m8r ffg1 vg5 a6 asox tmul h38 .
 ant sj m8r ob ? 1fj mwby a1 tao vg5. soq df v ' .a. CirX.
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message
 



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

Re: -current hangs during boot

[Thomas D. Dean]

I cannot make mergemaster work.  Tried twice earlier in the year and
took several hours to recover...  Don't know what my problem is.

However, I have a script that compares and lists diffs in /etc/rc* and
/etc/defaults/* to those in src/etc.  Normally, I manually copy those
files to /etc.

# grep '$FreeBSD' /etc/rc /etc/rc.shutdown /etc/defaults/rc.conf 
/etc/rc:# $FreeBSD: src/etc/rc,v 1.239 2000/10/22 19:10:13 phk Exp $
/etc/rc.shutdown:# $FreeBSD: src/etc/rc.shutdown,v 1.15 2000/10/20 20:26:05 ache Exp$
/etc/defaults/rc.conf:# $FreeBSD: src/etc/defaults/rc.conf,v 1.83 2000/10/29 19:59:04 
ume Exp $

These are the proper versions.

After looking through rc.shutdown, 'Writing entropy file.' is not
displayed.  In /etc/defaults/rc.conf and /usr/src/etc/defaults/rc.conf,
I have

...
entrop^%]0y_file="/entropy" # Set to NO to disable caching entropy through reboots.
...

Garble?

Fixing this fixes the problem.

Thanks Mark.

tomdean


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

[PATCH] Re: if_tap and devfs

[Maksim Yevmenkin]

Hello,

 I recently moved to using devfs and now if_tap seems unusable. Although
 the module is loaded, it doesn't show up in /dev or as an interface.
 From a quick comparison with if_tun it seems that this is 'expected'
 behaviour although I'm not a specialist with devfs. Is this so? If yes,
 is there somebody working to make if_tap devfs-ready? Or I'm doing
 something wrong?

please try the following patch. it is not tested, sorry i dont have 
FreeBSD box available right now :( please let me know the results.

thanks,
emax



*** if_tap.c.orig   Mon Nov  6 09:24:08 2000
--- if_tap.cMon Nov  6 10:26:35 2000
***
*** 79,84 
--- 79,85 
  static inttapmodevent __P((module_t, int, void *));
  
  /* device */
+ static void   tapclone__P((void *, char *, int, dev_t
*));
  static void   tapcreate   __P((dev_t));
  
  /* network interface */
***
*** 131,157 
int  type;
void*data;
  {
!   static int   attached = 0;
!   struct ifnet*ifp = NULL;
!   int  unit, s;
  
switch (type) {
case MOD_LOAD:
if (attached)
return (EEXIST);
  
cdevsw_add(tap_cdevsw);
attached = 1;
break;
  
!   case MOD_UNLOAD:
if (taprefcnt  0)
return (EBUSY);
  
cdevsw_remove(tap_cdevsw);
  
unit = 0;
while (unit = taplastunit) {
s = splimp();
TAILQ_FOREACH(ifp, ifnet, if_link)
if ((strcmp(ifp-if_name, TAP) == 0) ||
--- 132,164 
int  type;
void*data;
  {
!   static int  attached = 0;
!   static eventhandler_tag eh_tag = NULL;
  
switch (type) {
case MOD_LOAD:
if (attached)
return (EEXIST);
  
+   eh_tag = EVENTHANDLER_REGISTER(dev_clone, tapclone, 0,
1000);
cdevsw_add(tap_cdevsw);
attached = 1;
break;
  
!   case MOD_UNLOAD: {
!   int unit;
! 
if (taprefcnt  0)
return (EBUSY);
  
+   EVENTHANDLER_DEREGISTER(dev_clone, eh_tag);
cdevsw_remove(tap_cdevsw);
  
unit = 0;
while (unit = taplastunit) {
+   int  s;
+   struct ifnet*ifp = NULL;
+ 
s = splimp();
TAILQ_FOREACH(ifp, ifnet, if_link)
if ((strcmp(ifp-if_name, TAP) == 0) ||
***
*** 179,185 
}
  
attached = 0;
!   break;
  
default:
return (EOPNOTSUPP);
--- 186,192 
}
  
attached = 0;
!   } break;
  
default:
return (EOPNOTSUPP);
***
*** 187,192 
--- 194,234 
  
return (0);
  } /* tapmodevent */
+ 
+ 
+ /*
+  * DEVFS handler
+  *
+  * We need to support two kind of devices - tap and vmnet
+  */
+ static void
+ tapclone(arg, name, namlen, dev)
+   void*arg;
+   char*name;
+   int  namelen;
+   dev_t   *dev;
+ {
+   int  unit, minor;
+   char*device_name = NULL;
+ 
+   if (*dev != NODEV)
+   return;
+ 
+   device_name = TAP;
+   if (dev_stdclone(name, NULL, device_name, unit) != 1) {
+   device_name = VMNET;
+ 
+   if (dev_stdclone(name, NULL, device_name, unit) != 1)
+   return;
+ 
+   minor = (unit |  VMNET_DEV_MASK);
+   }
+   else
+   minor = unit;
+ 
+   *dev = make_dev(tap_cdevsw, minor, UID_ROOT, GID_WHEEL, 0600,
"%s%d",
+   device_name, unit);
+ } /* tapclone */
  
  
  /*


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

Re: tar : needs some attention?

[Wilko Bulte]

On Mon, Nov 06, 2000 at 08:09:53AM -0800, Matthew Jacob wrote:
 On Mon, 6 Nov 2000, John W. De Boskey wrote:
 
  Hi,
  
 Each night I run a 'make release' and then tar it off to
  a public storage area...
  
 For some time now, tar has been complaining...
  
  tar: cdrom/disc2/dev/acd0t32: minor number too large; not dumped
  tar: cdrom/disc2/dev/acd0t33: minor number too large; not dumped
  tar: cdrom/disc2/dev/acd0t34: minor number too large; not dumped
  tar: cdrom/disc2/dev/acd0t35: minor number too large; not dumped
  tar: cdrom/disc2/dev/acd0t36: minor number too large; not dumped
  tar: cdrom/disc2/dev/acd0t37: minor number too large; not dumped
  tar: cdrom/disc2/dev/acd0t38: minor number too large; not dumped
  tar: cdrom/disc2/dev/acd0t39: minor number too large; not dumped
  
 Is this the expected behaviour, or is it worth digging into
  tar and making some fixes?
 
 Nope. Expected behaviour for interoperability with other unix systems.

FWIW I think I also have seen this on Tru64 (at least once)

-- 
Wilko Bulte Arnhem, the Netherlands
[EMAIL PROTECTED]   http://www.freebsd.org  http://www.nlfug.nl



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

Re: IP wierdness...

[Warner Losh]

In message [EMAIL PROTECTED] "Justin T. Gibbs" writes:
: After the recent introduction of cardbus support into -current, I
: decided to upgrade my laptop.  At first glance, the system seemed
: to support a Xircom "Real Port" 10/100/56K modem card with the
: dc driver.  The funny thing though is that, although I can initiate
: IP or TCP connections to remote hosts, the system seems to drop
: all incoming connections.  This even applies to ICMP traffic.
: For instance, a 4.1-stable machine can not ping my laptop, but
: the laptop can ping/telnet/ftp to the 4.1-stable machine.  Looking
: at tcpdump traces on the laptop, it appears that the ICMP echo
: request is received correctly, but the system never responds.
: I'm not running IPSEC or ipfw, and all of the sysctls that seem
: to be related to filtering or rate limiting incoming packets look
: normal.  I'm running -current as of a few hours ago, but this
: has been broken for me for at least a week in -current.

tcpdump on the laptop sees the packet?  That's very odd.  I was using
this same card, sans the modem on my laptop for a while earlier in the
week and it was fine.  I didn't try the ping it from a remote
location, however.  I'll have to try that tonight.

Warner


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

Re: Cardbus 3Com Megahertz Model 3CXFEM656C

[Warner Losh]

In message [EMAIL PROTECTED] Jan Knepper writes:
: Does anyone know anything about the patch Jon made for this
: cardbus card during the BSD Con 2000?

Should be in the tree right now.  Modem won't work, however.  It is a
winmodem type thing.  The good news about this winmodem is that there
appears to be a relatively simple linux driver for it (I say appears
because I've seen references to it, but haven't seen the actual
driver).

Warner


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

Re: Cardbus 3Com Megahertz Model 3CXFEM656C

[Jan Knepper]

Hmm,

Well in that case I must be doing something wrong.
I am pretty sure I've got the last current, but the card still does not
come up as it does with the kernel Jon compiled at the Con...

The modem would be great too, but that the Ethernet works is really
number one for me right now.

Thanks!
Jan



Warner Losh wrote:

 In message [EMAIL PROTECTED] Jan Knepper writes:
 : Does anyone know anything about the patch Jon made for this
 : cardbus card during the BSD Con 2000?

 Should be in the tree right now.  Modem won't work, however.  It is a
 winmodem type thing.  The good news about this winmodem is that there
 appears to be a relatively simple linux driver for it (I say appears
 because I've seen references to it, but haven't seen the actual
 driver).

 Warner



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

RE: Problem with dlopen()/dlsym() after recent crt* changes

[Alexander N. Kabaev]

  I've spent couple hours already trying to reproduce the error and so far
failed miserably. Am I the only one who does not see this problem at all?

On 06-Nov-00 Maxim Sobolev wrote:
 After the crt changes the following piece of code, which worked previously,
 gives a 'host: dlopen() failed: ./module.so: Undefined symbol
 "__register_frame_info' error message (yeah, I know that it's better to check


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

Re: Cardbus 3Com Megahertz Model 3CXFEM656C

[Warner Losh]

In message [EMAIL PROTECTED] Jan Knepper writes:
: Well in that case I must be doing something wrong.
: I am pretty sure I've got the last current, but the card still does not
: come up as it does with the kernel Jon compiled at the Con...

OK.  I'll ping him privately.  Maybe he got busy with school :-)

Warner


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

Re: ad1 is not detected.

[Szilveszter Adam]

On Mon, Nov 06, 2000 at 05:08:04PM +0100, Soren Schmidt wrote:

 
 The problem has been around for at least a couble of month both in
 current and stable, but only a select few has seen it, I've chased
 it with any drive/controller I have access to, but hasn't been able
 to reproduce it..
 If you can find a way that I can reproduce it, I'm sure I can
 fix the problem in a few minutes.. ssh access to a box that has
 this problem could also help, but "hands on" are often much better
 for this kind of problems...

Hmmm... I have been trying to get things sorted out but have not been able
to do much. Upon fitting ata-all.c with some printf()-s, itt seems that the
probe in ata_probe(device_t dev) seems to do DTRT. (ie it evaluates the if
statements in lines 838 and 844 respectively and sets the mask for each
device that exists on the controller. The only case where the if statement
gave "false" was on ata1-slave but I *really* do not have anything on there.
In other words, ata0-slave was found it seems.)

But this is appearently not enough and I do not know why. (It shows that I
am not an experienced hacker... sigh)

So, what information would be helpful in getting this problem solved? As for
reproducing it, well, just grab a Spacewalker HOT 637/P mobo with Intel
LX440 AGP chipset, fit two Quantum hdd-s on ata0 and a Sony CDU-621 on
ata1-master, boot a kernel with the most recent ata stuff and there you
go:-) Seriously, I have nothing special on this machine, it has always been
very friendly to FreeBSD; when many other hw configs had problems, this one
seemd to be immune (although earlier I did not have the hdd on ata0-slave,
sooo...) but now, I am stuck. 

Any and all information or help I can provide, or things I should try, just
tell me. 

Sorry for not being able to track this thing down.
-- 
Regards:

Szilveszter ADAM
Szeged University
Szeged Hungary


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

skipping mouse pointer

[Bakul Shah]

I upgraded my system from the -current sources as of Aug-1 to
Nov-4 and find that now the mouse pointer skips while
dragging -- the pointer tracks mouse motion fine for a while,
then freezes and then jumps to a new location quite a few
pixels away.  The same thing happens under X as well as on a
virtual console.  Though the effect is not as pronounced on
a virtual console.  The new things I added were

device  random
options NETGRAPH
options COMPAT_LINUX
options FFS_EXTATTR
options NOBLOCKRANDOM

Also, rc.conf is considerably different since I hadn't upgraded
it in quite a while.  Has anyone else run into this?  Of course
I will remove the new options and see if the symptom goes away
but I thought I'd ask here as well...

Thanks,

-- bakul


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

Re: tar : needs some attention?

[Christian Weisgerber]

John W. De Boskey [EMAIL PROTECTED] wrote:

 tar: cdrom/disc2/dev/acd0t39: minor number too large; not dumped
 
Is this the expected behaviour,

Expected behavior; you can't store 32-bit minor numbers in tar's
archive format.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



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

Re: Problem with dlopen()/dlsym() after recent crt* changes

[Alexander N. Kabaev]

  Why FreeBSD does not link libgcc into shared libraries by default? Everyone
else is doing that. Linking shared libraries with libgcc seems to be the
ultimate work-around. Are there any compatibility problems which are keeping
FreeBSD from doing that?

 OK, thanks.  I'll take a look at it as soon as I can -- hopefully
 tonight.  If I can come up with a reasonable work-around, I'll do so.
 
 John
 -- 


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

Re: Cardbus 3Com Megahertz Model 3CXFEM656C

[Jan Knepper]

Warner Losh wrote:

 In message [EMAIL PROTECTED] Jan Knepper writes:
 : Well in that case I must be doing something wrong.
 : I am pretty sure I've got the last current, but the card still does not
 : come up as it does with the kernel Jon compiled at the Con...

 OK.  I'll ping him privately.  Maybe he got busy with school :-)

Thanks 1E6!

Jan




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

Re: skipping mouse pointer

[Michael C . Wu]

On Mon, Nov 06, 2000 at 04:18:17PM -0500, Bakul Shah scribbled:
| I upgraded my system from the -current sources as of Aug-1 to
| Nov-4 and find that now the mouse pointer skips while
| dragging -- the pointer tracks mouse motion fine for a while,
| then freezes and then jumps to a new location quite a few
| pixels away.  The same thing happens under X as well as on a
| virtual console.  Though the effect is not as pronounced on
| a virtual console.  The new things I added were

The lag is device random harvesting entropy from mouse, and
has been fixed in the latest current builds.

| Also, rc.conf is considerably different since I hadn't upgraded
| it in quite a while.  Has anyone else run into this?  Of course
| I will remove the new options and see if the symptom goes away
| but I thought I'd ask here as well...

mergemaster please.

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

Re: /etc/defaults/rc.conf

[Chris Faulhaber]

On Tue, Nov 07, 2000 at 01:02:03AM +0200, Giorgos Keramidas wrote:
 On Mon, Nov 06, 2000 at 03:37:01PM -0500, Forrest Aldrich wrote:
  It would be useful to have back the program specification variable for 
  inetd.  Currently we have:
  
  inetd_enable="YES"  # Run the network daemon dispatcher (or NO).
  inetd_flags="-wW"   # Optional flags to inetd
  
  and the /etc/rc.* files assume the use of the stock inetd.  Where some 
  people choose to use alternative inetd-like programs such as xinetd.
 [...]
 
 Nice idea!  And the fix is simple.  The included patch will correct it :-)
 

You forgot the patch(es) to the port(s) this would affect (e.g. xinetd).
The affected ports would need their ${PREFIX}/etc/rc.d files removed
(otherwise you would start them twice) along with a message letting the
installer know how to start it properly.

 [ do we really need to cross-post this? ]
 

No, -stable removed.

-- 
Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED]

FreeBSD: 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: PPP over ATM

[Brian Somers]

Sorry to chime in so late, but ppp(8) already has ATM support...  I 
must confess that I haven't tested it and don't know how it works, 
but it may be worth looking at.  A netgraph node would definitely be 
preferable.

 On Sun, 22 Oct 2000 03:41:27 +0200, Poul-Henning Kamp wrote:
 
 Who knows about the ATM stuff in the kernel?
 
 We have two ATM stacks:
* The minimalist "chuck" stack.
* The full-blown HARP stack.
 
 Neither support netgraph.
 
 Are you aware of any efforts to add PPP over ATM or Netgraph 
 support to the current ATM code?
 
 I'm not aware of any activity in the ATM code at all...
 
 Ok, well if I were to netgraphify the ATM code, would mpd be sufficient
 to get PPP over ATM working?  (I have a lot of reading up to do, but
 if I can decide on the correct direction to start off in I could save myself
 alot of time ;)).  And for the record I have done ethernet drivers in Linux
 and OS/2.   But I am quite unfamiliar with the FreeBSD networking code.
 I have only submitted patches to the kernel for cyrix code optimizations. :)
 
 I looked into netgraph and it seems to be a very modular and a wise
 approach to take if it sufficient for this purpose.
 
 Brian Smith

-- 
Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org
  http://www.Awfulhak.org   brian@[uk.]OpenBSD.org
Don't _EVER_ lose your sense of humour !




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

Re: vx driver patch

[Bill Paul]

 Someone (I can't find who in my records, please let me know if it was
 you so I can credit you in the commit message) sent out patches to
 make the vx driver not use the pci compat shims.  I just found it in
 my home directory, applied it, tweaked things very minorly and it
 builds and boots.  Trouble is, I don't have a vortex to test with.  It
 also appears that there is no driver maintainer at this time, so I
 thought I'd send it here.

Unfortunately, there are a couple of problems with this patch. Somebody
tried copying the EISA attachment code too closely: there's only one
I/O space that needs to be allocated (the pci_io allocation is bogus).
The IRQ allocation needs the RF_SHAREABLE flag or it will blow up in
the case where the IRQ is shared with another device. Also, the vx
driver still uses the ugly hack of statically allocated softc structs.

I was working on this in the office the other day and just got done
testing it. I have patches to fix all of this, plus make it use the
bus_space_*() stuff instead of inb/outb/etc, plus allow it to be compiled
as a KLD. The only thing I didn't do was implement detach routines,
which means the driver can be loaded as a KLD, but not unloaded.
The driver should also build in the alpha.

I'll commit the changes to -current shortly.

-Bill


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

Re: ad1 is not detected.

[Michael Harnois]

I think I may be having the same problem you are seeing. My ATAPI
CD-ROM, an HP 8200, which is at ata1-slave, is not being detected. I
can't say reliably when the problem started, but at one time it
worked. (I have been running current almost continuously since I built
this machine in early August, and everything worked then.) If there's
some date in the recent past you'd like me to backtest to I can (I'm
on cable modem so download time is not a big problem.)

-- 
Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA 
[EMAIL PROTECTED]  [EMAIL PROTECTED] 
 "Waiter, there's no fly in my soup!" - Kermit the Frog


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

Re: tar : needs some attention?

[Bruce Evans]

On Mon, 6 Nov 2000, Jeroen Ruigrok van der Werven wrote:

 -On [20001106 17:10], John W. De Boskey ([EMAIL PROTECTED]) wrote:
 tar: cdrom/disc2/dev/acd0t39: minor number too large; not dumped
 
Is this the expected behaviour, or is it worth digging into
 tar and making some fixes?
 
 I am hoping to update tar soon these weeks.

Don't forget to merge all the FreeBSD changes including the ones that
print this message.  For the file:

crw-rw  1 root  operator9, 0x08010002 Feb 12  1995 fd0.1200

gnu tar (v.1.13) prints the user-unfriendly message:

tar: minor_t value 134283266 too large (max=16777215)

while FreeBSD tar prints:

tar: fd0.1200: minor number too large; not dumped

It is not easy to see that 134283266 is 0x08010002 or that the file is
fd0.1200 (the limit 16777215 is 0xFF -- 24 bits).

gnu tar 1.13 actually dumps acd0t39, and FreeBSD tar reads back the
result correctly.  This is because gnu tar 1.13 permits 24-bit minor
numbers, while the FreeBSD version only permits 21-bit ones since it
requires a byte of null padding in the minor number field.  I seem to
have misread the gnu tar 1.13 sources in the following commit:

RCS file: /home/ncvs/src/gnu/usr.bin/tar/create.c,v
Working file: create.c
head: 1.7
...

revision 1.7
date: 1999/08/11 08:03:39;  author: bde;  state: Exp;  lines: +15 -2
Support 21-bit minor numbers.  Avoid wasting a byte in their octal
representation by generating the same format as tar-1.13 (use a single
space as the terminator for 7-digit octal numbers).  This is POSIX.1
conformant (2-byte terminators are just a bug or historical wart in
old versions of gnu tar).  All devices created by `MAKEDEV all' except
rsa0.ctl can now be handled by tar(1).


Previous versions of FreeBSD wasted 2 bytes for null padding.  The
current version still wastes (?) 1 byte relative to gnu tar 1.13.

Bruce



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

Re: IP wierdness...

[Andy Farkas]

 tcpdump on the laptop sees the packet?  That's very odd.
 
 Ceratinly is.  I don't think this particular problem has anything
 to do with the cardbus adapter.  I run tcpdump with "-v -v -v" and
 it never reported a bad checksum either.

For curiosity's sake, I'd try a different cable to the hub...

 
 --
 Justin
 

--
 
 :{ [EMAIL PROTECTED]
  
Andy Farkas
System Administrator
   Speednet Communications
 http://www.speednet.com.au/
  




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

ATA RAID - sysinstall solution

[Ivan Debnr]

I'm using HTP 370 ATA RAID controller, which should have been supported in
stable and current according to CVS messages from Soren.

But as few of us found, it is not, in fact.

KERNEL recognises device ar0.

4.2 sysinstall does not offer ar0 as disk drive
5.0-current sysinstall offers it, but is not able to create slices on it.
(DEBUG: MakeDev unknown major/minor).

So I looked through sysinstall source and libdisk source and guess what ! -
libdisk doesn't know about ar? devices yet.

Could someone update the libdisk source in stable and current to include the
device?
The files affected are:

/src/lib/libdisk/create_chunk.c
/src/lib/libdisk/disk.c

--- disk.c.orig Thu Sep 14 14:10:45 2000
+++ disk.c  Mon Nov  6 23:41:45 2000
@@ -461,7 +461,7 @@
 }
 #endif

-static char * device_list[] = {"wd", "ad", "da", "wfd", "fla", "idad",
"mlxd", "amrd", "twed", 0};
+static char * device_list[] = {"wd", "ad", "da", "wfd", "fla", "idad",
"mlxd", "amrd", "twed", "ar", 0};

 char **
 Disk_Names()


--- create_chunk.c.orig Fri Jul 14 08:30:59 2000
+++ create_chunk.c  Mon Nov  6 23:46:59 2000
@@ -300,6 +300,8 @@
cmaj = 147, p += 4;
 else if (!strncmp(p, "da", 2)) /* CAM support */
cmaj = 13, p += 2;
+else if (!strncmp(p, "ar", 2)) /* ATA RAID */
+   cmaj = 157, p += 2;
 else {
msgDebug("MakeDev: Unknown major/minor for devtype %s\n", p);
return 0;

Unfortunately I am not able to compile and try this, but if someone can
create a set of 4-STABLE or 5-CURRENT installation disks and e-mail them,
I'm willing to try.

Those diffs are against 2000-10-30 stable, so they are just to show changes
what I thing should be done to actual current files. This should make
Current install on ATA RAID hopefully. I don't know, if it will make STABLE
sysinstall recognize the ar device. I hope so.


Ivan Debnr
Online Consulting, s.r.o.

tel.://+421 88 4146721
fax://+421 88 4142231
http://www.o-c.sk


BEGIN:VCARD
VERSION:2.1
N:Debnár;Ivan
FN:Ivan Debnár
ORG:Online Consulting, s.r.o.
TEL;WORK;VOICE:+421 (88) 4146721
TEL;HOME;VOICE:+421 (88) 4171223
TEL;CELL;VOICE:+421 (903) 506197
TEL;WORK;FAX:+421 (88) 4142231
ADR;WORK:;;Rudlovská cesta 53;Banská Bystrica;;974 01;Slovak Republic
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Rudlovsk=E1 cesta 53=0D=0ABansk=E1 Bystrica 974 01=0D=0ASlovak Republic
BDAY:19770829
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:2922T091913Z
END:VCARD

Re: ATA RAID - sysinstall solution

[Jordan Hubbard]

 So I looked through sysinstall source and libdisk source and guess what ! -
 libdisk doesn't know about ar? devices yet.

Committed, thanks!

- Jordan


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

Re: /etc/defaults/rc.conf

[Giorgos Keramidas]

On Mon, Nov 06, 2000 at 03:37:01PM -0500, Forrest Aldrich wrote:
 It would be useful to have back the program specification variable for 
 inetd.  Currently we have:
 
 inetd_enable="YES"  # Run the network daemon dispatcher (or NO).
 inetd_flags="-wW"   # Optional flags to inetd
 
 and the /etc/rc.* files assume the use of the stock inetd.  Where some 
 people choose to use alternative inetd-like programs such as xinetd.
[...]

Nice idea!  And the fix is simple.  The included patch will correct it :-)

[ do we really need to cross-post this? ]

- giorgos


diff -r -u etc.orig/defaults/rc.conf etc/defaults/rc.conf
--- etc.orig/defaults/rc.conf   Tue Nov  7 00:59:39 2000
+++ etc/defaults/rc.confTue Nov  7 00:58:40 2000
@@ -89,6 +89,7 @@
 syslogd_enable="YES"   # Run syslog daemon (or NO).
 syslogd_flags="-s" # Flags to syslogd (if enabled).
 inetd_enable="YES" # Run the network daemon dispatcher (or NO).
+inetd_program="inetd"  # path to inetd, if you don't want stock inetd
 inetd_flags="-wW"  # Optional flags to inetd
 #
 # named.  It may be possible to run named in a sandbox, man security for
diff -r -u etc.orig/rc etc/rc
--- etc.orig/rc Tue Nov  7 00:59:29 2000
+++ etc/rc  Tue Nov  7 00:55:27 2000
@@ -395,7 +395,10 @@
 [Nn][Oo])
;;
 *)
-   echo -n ' inetd';   inetd ${inetd_flags}
+   if [ -x ${inetd_program:-/usr/sbin/inetd} ]; then
+   echo -n ' inetd';
+   ${inetd_program:-/usr/sbin/inetd} ${inetd_flags}
+   fi
;;
 esac
 

/etc/defaults/rc.conf

[Forrest Aldrich]

It would be useful to have back the program specification variable for 
inetd.  Currently we have:

inetd_enable="YES"  # Run the network daemon dispatcher (or NO).
inetd_flags="-wW"   # Optional flags to inetd

and the /etc/rc.* files assume the use of the stock inetd.  Where some 
people choose to use alternative inetd-like programs such as xinetd.  We'd 
do better to have in /etc/defaults/rc.conf:

inetd_enable="YES"  # Run the network daemon dispatcher (or NO).
inetd_program=-"/usr/local/sbin/xinetd"   # Location of inetd/service daemon
inetd_flags="-wW"   # Optional flags to inetd

.. or something similar, rather than manually editing the core rc.* scripts.


_F



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