Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Bakul Shah
  Until pppd is taught to create the interface if one doesn't
  exist, this information needs to be in /usr/src/UPDATING.
 
 pppd doesn't need to be taught to create the interface.  Rather it needed
 to learn to check for ppp support in a non-stupid way.  The following
 patch should do it as well as making pppd do the right thing when
 support isn't compiled in, but a module is available.  It should make
 things work with a GENERIC kernel.

`device ppp' was already defined in my kernel config file so
there was no need to kldload if_ppp.  But I had to run
`ifconfig create ppp' to make things work.

I don't much like auto kldloading modules from suid programs.
A simple hack is to just add ifconfig create ppp in rc.local.
Also kldload if_ppp if needed.

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



Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Brooks Davis
On Fri, Oct 25, 2002 at 02:16:32PM -0700, Bakul Shah wrote:
   Until pppd is taught to create the interface if one doesn't
   exist, this information needs to be in /usr/src/UPDATING.
  
  pppd doesn't need to be taught to create the interface.  Rather it needed
  to learn to check for ppp support in a non-stupid way.  The following
  patch should do it as well as making pppd do the right thing when
  support isn't compiled in, but a module is available.  It should make
  things work with a GENERIC kernel.
 
 `device ppp' was already defined in my kernel config file so
 there was no need to kldload if_ppp.  But I had to run
 `ifconfig create ppp' to make things work.

RTF modfind.  The modfind check verifies that ppp is in your kernel one 
way or another.  It IS unnecessicary to create the ppp0 interface 
because adding a ppp line discipline does that for you.  The check for 
ppp0 was always wrong because you might not get that interface.

 I don't much like auto kldloading modules from suid programs.

I'm waiting on more opinions on this.  It's easy enough to remove if
that's the concensous.  FWIW, ifconfig does exacly this before trying to
do anything with any interface.

-- Brooks

-- 
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4



msg45344/pgp0.pgp
Description: PGP signature


alpha tinderbox failure

2002-10-25 Thread Dag-Erling Smorgrav
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== share/doc/usd/13.viref
out of memory
*** Error code 255

Stop in /h/des/src/share/doc/usd/13.viref.
*** Error code 1

Stop in /h/des/src/share/doc/usd.
*** Error code 1

Stop in /h/des/src/share/doc.
*** Error code 1

Stop in /h/des/src/share.
*** Error code 1

Stop in /h/des/src.
*** Error code 1

Stop in /h/des/src.
*** Error code 1

Stop in /h/des/src.

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



Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Brooks Davis
On Fri, Oct 25, 2002 at 01:43:57PM -0700, Terry Lambert wrote:
 It's a moderately common case in -CURRENT, when kernel structure
 sizes change, and you build a new kernel without new modules, and
 a module refuses to load.  It's not technically correct.  The old
 message might not be either, but at least it had you looking in
 the right place.

Current users are supposed to have enough of a clue to figure this out.
Other users are supposed to follow the instructions in UPDATING which
preclude this problem.  The version of pppd built with my patch basicly
keeps the only part of the old message was correct (telling you that you
don't have kernel support).  The second sentence of the description is
entierly unhelpful since README.bsd isn't anywhere in our source tree.

-- Brooks

-- 
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4



msg45346/pgp0.pgp
Description: PGP signature


Re: alpha tinderbox failure

2002-10-25 Thread Peter Wemm
Dag-Erling Smorgrav wrote:

 --
  stage 4: building everything..
 --
 === share/doc/usd/13.viref
 out of memory
 *** Error code 255

This is because the kernel was old on beast (fixing now), but thats not the
point.  We're always going to get this, so the -static workaround probably
needs to remain, or we are using the wrong groff binary or something.


Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5


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



Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Terry Lambert
Brooks Davis wrote:
 On Fri, Oct 25, 2002 at 01:43:57PM -0700, Terry Lambert wrote:
  It's a moderately common case in -CURRENT, when kernel structure
  sizes change, and you build a new kernel without new modules, and
  a module refuses to load.  It's not technically correct.  The old
  message might not be either, but at least it had you looking in
  the right place.
 
 Current users are supposed to have enough of a clue to figure this out.
 Other users are supposed to follow the instructions in UPDATING which
 preclude this problem.  The version of pppd built with my patch basicly
 keeps the only part of the old message was correct (telling you that you
 don't have kernel support).  The second sentence of the description is
 entierly unhelpful since README.bsd isn't anywhere in our source tree.

Heh.

You might as well just exit, and assume that whoever sees it not
running should have enough of a clue to know why it exited.  8-).

The only failure mode that gets to the end there is the module not
loading, and the error is not indicative of the load failure, was
all I was saying.

Like I said, it's an OK change (at least if it's OK for ifconfig
and mount to load modules, instead of the demand causing the kernel
to load them), it's just a bit light on the error message.

-- Terry

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



Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Brooks Davis
On Fri, Oct 25, 2002 at 12:35:22PM -0700, Brooks Davis wrote:
 If someone who actually uses pppd could test it, perferably in both
 sceneios, I'll see about getting it commited.

Here's a new patch that gives the user more of a hint at how to add PPP
support and only loads the module if they are actully root.  How's this
look?

-- Brooks

Index: sys-bsd.c
===
RCS file: /usr/cvs/src/usr.sbin/pppd/sys-bsd.c,v
retrieving revision 1.18
diff -u -p -r1.18 sys-bsd.c
--- sys-bsd.c   17 Sep 2002 15:52:35 -  1.18
+++ sys-bsd.c   25 Oct 2002 22:21:47 -
 -44,6 +44,7  static char rcsid[] = $FreeBSD: src/usr
 #include sys/time.h
 #include sys/stat.h
 #include sys/param.h
+#include sys/module.h
 #ifdef NetBSD1_2
 #include util.h
 #endif
 -169,28 +170,29  sys_check_options()
 }
 
 /*
- * ppp_available - check whether the system has any ppp interfaces
- * (in fact we check whether we can do an ioctl on ppp0).
+ * ppp_available - check whether the system has the ppp module loaded
+ * or compiled in. If it doesn't, and we're actually root (not just SUID
+ * root) try loading it before giving up.
  */
 int
 ppp_available()
 {
-int s, ok;
-struct ifreq ifr;
+const char *modname = if_ppp;
 extern char *no_ppp_msg;
 
-if ((s = socket(AF_INET, SOCK_DGRAM, 0))  0)
-   return 1;   /* can't tell */
+if (modfind(modname) != -1) {
+   return 1;
+}
 
-strncpy(ifr.ifr_name, ppp0, sizeof (ifr.ifr_name));
-ok = ioctl(s, SIOCGIFFLAGS, (caddr_t) ifr) = 0;
-close(s);
+if (getuid() == 0  kldload(modname) != -1)
+   return 1;
 
 no_ppp_msg = \
 This system lacks kernel support for PPP.  To include PPP support\n\
-in the kernel, please follow the steps detailed in the README.bsd\n\
-file in the ppp-2.2 distribution.\n;
-return ok;
+in the kernel, please add \device ppp\ to your kernel config or \n\
+load the if_ppp module.\n;
+
+return 0;
 }
 
 /*

-- 
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4



msg45349/pgp0.pgp
Description: PGP signature


Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Terry Lambert
Brooks Davis wrote:
 On Fri, Oct 25, 2002 at 12:35:22PM -0700, Brooks Davis wrote:
  If someone who actually uses pppd could test it, perferably in both
  sceneios, I'll see about getting it commited.
 
 Here's a new patch that gives the user more of a hint at how to add PPP
 support and only loads the module if they are actully root.  How's this
 look?

Totally cool.  The other one was good enough, too (but you foolishly
asked for comments... 8-) 8-)).

-- Terry

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



Re: Installing from CD and MAKEDEV

2002-10-25 Thread Bruce A. Mah
If memory serves me right, Poul-Henning Kamp wrote:
 In message [EMAIL PROTECTED], Jun Kuriyama writes:
 At Thu, 24 Oct 2002 12:10:53 + (UTC),
 kuriyama wrote:
  I've created install CD with make iso.1 (with sources few hours
  before).
  
  I'm trying to install fresh current box with this CD.  But I got
  MAKEDEV returned non-zero status dialog after extracting dists.
  
  It seems cd /dev; sh MAKEDEV all is failed at devfs environment.
 
 I found it.
 
 Phk changes in 1.297 of src/etc/Makefile not to install MAKEDEV by
 default.  Options may be:
 
 This should be fixed now I hope.

It works here.  I just did a successful i386 install from CDROM.

Thanks!

Bruce.






msg45351/pgp0.pgp
Description: PGP signature


Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Bakul Shah
 Here's a new patch that gives the user more of a hint at how to add PPP
 support and only loads the module if they are actully root.  How's this
 look?

I still don't like it.  How to explain

I don't think it is pppd's responsibility to muck with
modules.  It is like mount kldloading a disk driver module.
Neither program has any business guessing which module name
goes with which device/feature.

What if I want to run ppp over ethernet over atm?  I know you
can't do this today but in general the trend should be to
make protocol modules more flexible not less.  Hardwiring
module names is analogous to making a function non-reentrant.

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



Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Brooks Davis
On Fri, Oct 25, 2002 at 05:34:15PM -0700, Bakul Shah wrote:
  Here's a new patch that gives the user more of a hint at how to add PPP
  support and only loads the module if they are actully root.  How's this
  look?
 
 I still don't like it.  How to explain
 
 I don't think it is pppd's responsibility to muck with
 modules.  It is like mount kldloading a disk driver module.
 Neither program has any business guessing which module name
 goes with which device/feature.
 
 What if I want to run ppp over ethernet over atm?  I know you
 can't do this today but in general the trend should be to
 make protocol modules more flexible not less.  Hardwiring
 module names is analogous to making a function non-reentrant.

This isn't going to have an effect on the ability to use kernel ppp for
other things.  The tty orientation of pppd and the outdated, unmodular
design on ppp(4) have taken care of that.  This patch gives people
the functionality they want (pppd just working) without any major
entanglements (the whole function is 20 lines).  If someone
wants to make pppd work on arbitrary devices we can deal with that when
it happens and I frankly doubt it's ever going to since we've got
netgraph to do that with.

-- Brooks

-- 
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4



msg45353/pgp0.pgp
Description: PGP signature


sparc64 tinderbox failure

2002-10-25 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Sat Oct 26 02:02:12 GMT 2002
--
=== ipfilter
./aicasm: 877 instructions used
/tinderbox/sparc64/src/sys/kern/kern_sig.c:77:2: #error You *really* want 
COMPAT_FREEBSD4 on -current for a while
mkdep: compile failed
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

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



Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Terry Lambert
Brooks Davis wrote:
 This isn't going to have an effect on the ability to use kernel ppp for
 other things.  The tty orientation of pppd and the outdated, unmodular
 design on ppp(4) have taken care of that.  This patch gives people
 the functionality they want (pppd just working) without any major
 entanglements (the whole function is 20 lines).  If someone
 wants to make pppd work on arbitrary devices we can deal with that when
 it happens and I frankly doubt it's ever going to since we've got
 netgraph to do that with.

Depending on the value of sysctl kern.module_path, if the if_ppp
module does not exist, and one of the path components is writeable,
then this would permit you to abuse the pppd to load arbitrary modules
into the kernel.

So I understand Bakul's complaint.

But by the same token, mount and ifconfig have the same problems;
on the other hand, unlike pppd, they are not suid root.

On general principles, loading modules with commands, rather than the
kernel doing it automatically, is a bad idea.  But FreeBSD already
does this in a number of commands, because it lacks a certralized
feature demand support facility.

You could also make security arguments on the basis of what if the
administrator didn't want the machine to be able to be configured
for PPP -- on purpose?

As long as you control the module path, I don't think this is a real
risk.  There is such a thing as being too paranoid.

As it is, this patch does nothing worse than add to an existing
mess brought about by not having an integrated demand-load facility;
I don't see this as a problem... if there;s a problem, fix it first
in mount and ifconfig, before you complain about this patch.

-- Terry

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



Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Brooks Davis
On Fri, Oct 25, 2002 at 07:05:57PM -0700, Terry Lambert wrote:
 Brooks Davis wrote:
  This isn't going to have an effect on the ability to use kernel ppp for
  other things.  The tty orientation of pppd and the outdated, unmodular
  design on ppp(4) have taken care of that.  This patch gives people
  the functionality they want (pppd just working) without any major
  entanglements (the whole function is 20 lines).  If someone
  wants to make pppd work on arbitrary devices we can deal with that when
  it happens and I frankly doubt it's ever going to since we've got
  netgraph to do that with.
 
 Depending on the value of sysctl kern.module_path, if the if_ppp
 module does not exist, and one of the path components is writeable,
 then this would permit you to abuse the pppd to load arbitrary modules
 into the kernel.
 
 So I understand Bakul's complaint.
 
 But by the same token, mount and ifconfig have the same problems;
 on the other hand, unlike pppd, they are not suid root.

Note the getuid() check to prevent exactly this problem.  If you want to
keep root from loading modules, that's a kernel problem.

-- Brooks

-- 
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4



msg45356/pgp0.pgp
Description: PGP signature


Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Brooks Davis
On Fri, Oct 25, 2002 at 07:20:33PM -0700, Brooks Davis wrote:
 On Fri, Oct 25, 2002 at 07:05:57PM -0700, Terry Lambert wrote:
  Depending on the value of sysctl kern.module_path, if the if_ppp
  module does not exist, and one of the path components is writeable,
  then this would permit you to abuse the pppd to load arbitrary modules
  into the kernel.
  
  So I understand Bakul's complaint.
  
  But by the same token, mount and ifconfig have the same problems;
  on the other hand, unlike pppd, they are not suid root.
 
 Note the getuid() check to prevent exactly this problem.  If you want to
 keep root from loading modules, that's a kernel problem.

Oops, wrong problem.  If this one exists, it's a bug in kldload.

-- Brooks

-- 
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4



msg45357/pgp0.pgp
Description: PGP signature


Local DNS lookup by sshd?

2002-10-25 Thread John De Boskey
Hi,

   When logging into a current 5.0 system via ssh, I see the following
written to the system console (the 'xxx's are my whiteout):

... kernel: Connection attempt to UDP xxx.58.184.35:53 from xxx.58.184.35:49253
... kernel: Connection attempt to UDP xxx.58.184.35:53 from xxx.58.184.35:49254
... kernel: Connection attempt to UDP xxx.58.184.35:53 from xxx.58.184.35:49255
... kernel: Connection attempt to UDP xxx.58.184.35:53 from xxx.58.184.35:49256

   Basically, it looks like it is trying to talk to a DNS on the
localhost. However, I do not have DNS running. I do not have localhost listed
in /etc/resolv.conf.  /etc/nsswitch.conf lists 'hosts: files dns' and putting
my ssh origination id in /etc/hosts has no effect.

   It appears to be related to code in canohost.c. Before I start debugging,
I thought I'd ask if anyone knew if there is a reason for this behaviour,
or where it might be coming from (specifically).

Comments Welcome.

-John
   


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



Re: Local DNS lookup by sshd?

2002-10-25 Thread Peter Wemm
John De Boskey wrote:
 Hi,
 
When logging into a current 5.0 system via ssh, I see the following
 written to the system console (the 'xxx's are my whiteout):
 
 ... kernel: Connection attempt to UDP xxx.58.184.35:53 from xxx.58.184.35:492
53
 ... kernel: Connection attempt to UDP xxx.58.184.35:53 from xxx.58.184.35:492
54
 ... kernel: Connection attempt to UDP xxx.58.184.35:53 from xxx.58.184.35:492
55
 ... kernel: Connection attempt to UDP xxx.58.184.35:53 from xxx.58.184.35:492
56
 
Basically, it looks like it is trying to talk to a DNS on the
 localhost. However, I do not have DNS running. I do not have localhost listed
 in /etc/resolv.conf.  /etc/nsswitch.conf lists 'hosts: files dns' and putting
 my ssh origination id in /etc/hosts has no effect.
 
It appears to be related to code in canohost.c. Before I start debugging,
 I thought I'd ask if anyone knew if there is a reason for this behaviour,
 or where it might be coming from (specifically).

Are you using privsep?  If so, I think this is expected.  The unpriviliged
side runs in a chroot under /var/empty.  This means, that it cannot see any
/etc/nsswitch.conf and cannot see any /etc/resolv.conf or /etc/hosts.

And the resolver client library defaults querying on the first interface,
and in your case it used localhost.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5


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



RE: pppd not working on latest current 2002-10-20

2002-10-25 Thread Maksim Yevmenkin

 From: Terry Lambert [mailto:tlambert2;mindspring.com]

  Brooks Davis wrote:
  This isn't going to have an effect on the ability to use kernel ppp for
  other things.  The tty orientation of pppd and the outdated, unmodular
  design on ppp(4) have taken care of that.  This patch gives people
  the functionality they want (pppd just working) without any major
  entanglements (the whole function is 20 lines).  If someone
  wants to make pppd work on arbitrary devices we can deal with that when
  it happens and I frankly doubt it's ever going to since we've got
  netgraph to do that with.

 Depending on the value of sysctl kern.module_path, if the if_ppp
 module does not exist, and one of the path components is writeable,
 then this would permit you to abuse the pppd to load arbitrary modules
 into the kernel.
 
 So I understand Bakul's complaint.
 
 But by the same token, mount and ifconfig have the same problems;
 on the other hand, unlike pppd, they are not suid root.
 
 On general principles, loading modules with commands, rather than the
 kernel doing it automatically, is a bad idea.  But FreeBSD already
 does this in a number of commands, because it lacks a certralized
 feature demand support facility.

i'm sorry for jumping in the middle of the thread, but long time
ago i wrote something called kerneld. it is still available on
SourceForge (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/kerneld/)

the idea was very simple:

1) create a char device kd
2) add hooks inside kernel, so whenever filesystem, interface or
   char device is requested but not present send message to the
   kd device.
3) user space daemon that listens on /dev/kd for the events and
   loads appropriate module (as configured)

i send RFC email to -hackers, but i got so many negative replies
so i dropped the whole idea :)

 You could also make security arguments on the basis of what if the
 administrator didn't want the machine to be able to be configured
 for PPP -- on purpose?

yes. i got the similar arguments: i do not want any smart-ass
daemon load and unload modules. i want to do it myself

 As long as you control the module path, I don't think this is a real
 risk.  There is such a thing as being too paranoid.

 As it is, this patch does nothing worse than add to an existing
 mess brought about by not having an integrated demand-load facility;
 I don't see this as a problem... if there;s a problem, fix it first
 in mount and ifconfig, before you complain about this patch.

thanks,
max



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



For the painfully shy 13729

2002-10-25 Thread I like this really ! i265MEJR1gLsABWX
ARE YOU TOO SHY TO PICK UP THE PHONE? 
I was, but the big recruiters were ALWAYS on the phone. NOT FOR ME! 

As a result, big downlines were always out of my reach. 

But I found something FREE where I joined and sat back and watched 26
people 
join my downline before I did ANYTHING-in less than 24 hours! 

Did I mention it's FREE? 

MULTILEVEL MARKETING IS A HUGE MISTAKE FOR MOST PEOPLE -BECAUSE- 
MOST PEOPLE ARE JUST TOO SHY TO RECRUIT! 

MLM has failed to deliver on its promises for the past 50 years. The
pursuit 
of the MLM Dream has cost hundreds of thousands of people their
friends, 
their fortunes and their sacred honor. The fact is that MLM is fatally 
flawed, meaning that it CANNOT work for most average (shy) people. 

The companies and the few who earn the big money in MLM are NOT going to

tell you the real story. FINALLY, there is someone who has the courage
to 
cut through the hype and lies and tell the TRUTH about MLM. 

HERE'S GOOD NEWS 

There IS an alternative to MLM that WORKS, and works BIG! If you haven't
yet 
abandoned your dreams, then you need to see this. Earning the kind of
income 
you've dreamed about is easier than you think! 

With your permission, I'd like to send you a brief letter that will tell
you 
WHY MLM doesn't work for most people and will then introduce you to 
something so new and refreshing that you'll wonder why you haven't heard
of 
this before. 

EVEN IF YOU ARE PAINFULLY SHY! 

I promise that there will be NO unwanted follow up, NO sales pitch,
NOBODY 
WILL CALL YOU, and your email address will only be used to send you the 
information. Period. 

To receive this free, life-changing information, 
http://annak.freestoreclub.com

I'll get the information to you within 24 hours. Just look for the words
MLM 
WALL OF SHAME in your Inbox. 
Cordially, 
Pete P.  

P.S. Someone recently sent the letter to me and it has been the most 
eye-opening, financially beneficial information I have ever received. I 
honestly believe that you will feel the same way once you've read it.
And 
it's FREE!

66422647
08465248780


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



Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Bakul Shah
 Brooks Davis wrote:
  This isn't going to have an effect on the ability to use kernel ppp for
  other things.  The tty orientation of pppd and the outdated, unmodular
  design on ppp(4) have taken care of that.  This patch gives people
  the functionality they want (pppd just working) without any major
  entanglements (the whole function is 20 lines).

I meant reuse of pppd.  From what I remember, pppd does a lot
of the control plane stuff (IPCP, CHAP...) which is useful
for other ppp-over-foo combinations.  In general a different
module or set of modules may implement ppp-over-foo so
hardwiring the module name in pppd is not a good idea.  Now
you are probably thinking: In that case why not just default
to if_ppp and otherwise use an environment variable?.  This
would add complexity and another potential security hole.

If someone
  wants to make pppd work on arbitrary devices we can deal with that when
  it happens and I frankly doubt it's ever going to since we've got
  netgraph to do that with.

Existance of an alternative is not an argument in favor of
allowing something to rot since doing so limits your flexibility.

Terry writes:
 Depending on the value of sysctl kern.module_path, if the if_ppp
 module does not exist, and one of the path components is writeable,
 then this would permit you to abuse the pppd to load arbitrary modules
 into the kernel.

Thank you for explicating the security argument!  I'll also
point out that hardwiring module names makes it harder to
experiment with replacement modules (i.e. I may want to
develop if_super_duper_ppp).

 But by the same token, mount and ifconfig have the same problems;
 on the other hand, unlike pppd, they are not suid root.

AFAIK mount does no autoloading (i was using it as another
place where one might be tempted to use autoloading).  In
general any tool (command) that relies on a resource or
feature can have the same problem of the resource not
existing.  Just how far does one go to discover/autoload
resources?  Should we try to fetch it from a trusted
repository?  Should we try to compile it if we have the
sources?  It is a slipper slope.  A new programmer next year
will assume all the old programmers were fools and to him it
will be obvious the module sources fetched afresh and
compiled.  Okay, I am exaggerating.

 On general principles, loading modules with commands, rather than the
 kernel doing it automatically, is a bad idea.  But FreeBSD already
 does this in a number of commands, because it lacks a certralized
 feature demand support facility.

Another area for endless debating:-)  But don't worry, I'll stop soon!

If only the kernel is allowed to load them on demand, there
needs to be a way for modules to declare the feature-set they
provide and for the kernel to follow administrative policies
while autoloading them.

 You could also make security arguments on the basis of what if the
 administrator didn't want the machine to be able to be configured
 for PPP -- on purpose?

This is a policy argument.  Thanks for bringing that up!

 As it is, this patch does nothing worse than add to an existing
 mess brought about by not having an integrated demand-load facility;
 I don't see this as a problem... if there;s a problem, fix it first
 in mount and ifconfig, before you complain about this patch.

It adds needless complexity.  In any case, complain is too
strong a word!  I just pointed out something that I didn't
like based on the principles I try to follow when writing
software.  Consider it in the leading a horse to water
category:-)  If the horse thinks it is just a mirage, that
too is fine with me!  We can argue about that too. ducks

I have used up my 2 cents many times over, so over and out!

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



5.0 disklabel warnings against 4.7 disk

2002-10-25 Thread John De Boskey
Hi,

   I've (re)scanned my -current folder for issues related
to the following but didn't see a good match. Pointing
out my blindness is allowed if this was discussed...

   I have a system onto which I installed a 4.7-RC a couple
of weeks ago. I then upgraded that newly installed system
to -current.

   After the upgrade, disklabel now complains about
every disk in the system, for example:

# disklabel -r ad6s1
# /dev/ad6s1c:
type: unknown
disk: amnesiac
label: 
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 16
sectors/cylinder: 1008
cylinders: 193820
sectors/unit: 195371505
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0   # milliseconds
track-to-track seek: 0  # milliseconds
drivedata: 0 

8 partitions:
#size   offsetfstype   [fsize bsize bps/cpg]
  a: 195371505   634.2BSD 2048 16384 28512  # (Cyl.0*- 193820*)
  c: 195371505   63unused0 0# (Cyl.0*- 193820*)
partition a: partition extends past end of unit
partition c: partition extends past end of unit
Warning, partition c doesn't start at 0!
Warning, An incorrect partition c may cause problems for standard system utilities
#

This is an fdisk'd drive, with the entire disk allocated to the
1st slice.

An identical disk (ad4):

ad4: 95396MB WDC WD1000JB-32CWE0 [193821/16/63] at ata2-master UDMA100
ad6: 95396MB WDC WD1000JB-32CWE0 [193821/16/63] at ata3-master UDMA100

which I then fdisk and disklabel under -current shows up as:

8 partitions:
#size   offsetfstype   [fsize bsize bps/cpg]
  c: 1953715050unused0 0# (Cyl.0 - 193820*)

The only difference being the offset of 0 (and lack of warning msgs).

Both systems come up with the same disk size, but the offsets not matching
seems to be a problem. An older 4.7 pre-release  system from Sep 16 creates
the 'c' slice with an offset of 0.  I don't think this is something I did
wrong. Any thoughts, comments, or pointy hats are welcome.

Thanks,
John

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



ia64 tinderbox failure

2002-10-25 Thread Peter Wemm
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Fri Oct 25 22:01:25 PDT 2002
--
=== xe
./aicasm: 877 instructions used
/home/tinderbox/ia64/src/sys/kern/kern_sig.c:77:2: #error You *really* want 
COMPAT_FREEBSD4 on -current for a while
mkdep: compile failed
*** Error code 1

Stop in /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/sys/GENERIC.
*** Error code 1

Stop in /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/sys/GENERIC.
*** Error code 1

Stop in /home/tinderbox/ia64/src.
*** Error code 1

Stop in /home/tinderbox/ia64/src.

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



/usr/src/sys/netinet/udp_usrreq.c:290

2002-10-25 Thread Sean Kelly
When booting my system, I get the following after samba-2.2.6 starts:
acquiring duplicate lock of same type: inp
 1st inp @ /usr/src/sys/netinet/udp_usrreq.c:290
 2nd inp @ /usr/src/sys/netinet/udp_usrreq.c:290

This is with a kernel from Fri Oct 25 23:27:50 CDT 2002 (about an hour
ago).

it looks to me that under some conditions, inp isn't being unlocked in the 
LIST_FOREACH(inp, udb, inp_list) loop. It is possible I am wrong,
though...

-- 
Sean Kelly | PGP KeyID: 77042C7B
[EMAIL PROTECTED] | http://www.zombie.org

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



Re: libgtop port and v_tag changes

2002-10-25 Thread Joe Marcus Clarke
On Fri, 2002-10-25 at 14:15, John Baldwin wrote:
 Well, here's the thing.  If libgtop is intended to be used only with live
 kernels then it might be a better idea to use xvnode's that you get with
 from the kernel.  Alternatively, you could grab the inode and dev number
 the same way the sysctl handler does:
 
 switch (vp-v_type) {
 case VREG:
 case VDIR:
 case VLNK:
 xvn[n].xv_dev = vp-v_cachedfs;
 xvn[n].xv_ino = vp-v_cachedid;
 
 i.e., you could look at those members of struct vnode instead of trying
 to dig into the details of a UFS inode structure in v_data.  This
 would remove the need to look at v_tag at all.

I can certainly do it this way, but would it be equivalent to the
existing code?  It doesn't seem like it would be.  At least using the
kvm_read method, we get similar behavior for both -stable and -CURRENT. 
Correct me if I'm wrong, but the current code is looking at UFS inodes,
where as you're suggesting to look at generic vnodes.

Joe

 
 -- 
 
 John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
 Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/
 
-- 
PGP Key : http://www.marcuscom.com/pgp.asc



signature.asc
Description: This is a digitally signed message part


Re: /usr/src/sys/netinet/udp_usrreq.c:290

2002-10-25 Thread Juli Mallett
* De: Sean Kelly [EMAIL PROTECTED] [ Data: 2002-10-25 ]
[ Subjecte: /usr/src/sys/netinet/udp_usrreq.c:290 ]
 When booting my system, I get the following after samba-2.2.6 starts:
 acquiring duplicate lock of same type: inp
  1st inp @ /usr/src/sys/netinet/udp_usrreq.c:290
  2nd inp @ /usr/src/sys/netinet/udp_usrreq.c:290
 
 This is with a kernel from Fri Oct 25 23:27:50 CDT 2002 (about an hour
 ago).

I've been seeing this for about two months, but the box I'd been seeing
it on (the Samba box) was too unreliable to ever get logged in and get
the info, once it was updated to -current, and I didn't get it transcribed
as I remember telling someone how to reproduce it, but I don't know if they
ever looked into it.

Thanks,
juli.
-- 
Juli Mallett [EMAIL PROTECTED]   | FreeBSD: The Power To Serve
Will break world for fulltime employment. | finger [EMAIL PROTECTED]
http://people.FreeBSD.org/~jmallett/  | Support my FreeBSD hacking!

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



Re: is src/UPDATING up to date

2002-10-25 Thread Munish Chopra
On 2002-10-25 07:28 +, Mathieu Arnold wrote:
 Hi
 
 I was twiddling with my yesterday's current, I was trying to make release
 to see how things were going, and I saw at the top of UPDATING that :
 
 In addition, IDE write caching is currently disabled by default
 due to on-going concerns about disk write order and file system
 integrity.  Re-enabling write caching can substantially improve
 performance.
 

This part of the performance disclaimer has been untrue for a while now.
It is once again enabled by default.

 I looked at ata(4), told me about hw.ata.wc, which was supposed to be
 enabled by default, and it was, so, my question is, is the comment above
 still true, and how do I enable write cache if it is, if it's not true any
 more, maybe it should be removed.
 

As stated, it's untrue. You can check the status of write caching by
using the sysctl(8) facility. You're looking for hw.ata.wc.

It'd probably be a good idea for someone to nuke that paragraph...

-- 
Munish Chopra

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



Panic in swapon on 10/24

2002-10-25 Thread Eric Anholt
Finally upgraded from a September 1st kernel after applying the npx
patch from bde.  On boot (new 10/24 kernel, sept 1st world) I got a
panic during swapon.  I've got the core around if I can be more useful
in some way.

root@anholt:/usr/crash# gdb -k kernel.debug.11 vmcore.11
GNU gdb 5.2.0 (FreeBSD) 20020627
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x78
fault code  = supervisor write, page not present
instruction pointer = 0x8:0xc034418d
stack pointer   = 0x10:0xd7aa49b8
frame pointer   = 0x10:0xd7aa49c0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 83 (swapon)
panic: from debugger


Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc04722a5
stack pointer   = 0x10:0xd7aa47a8
frame pointer   = 0x10:0xd7aa47ac
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 83 (swapon)
panic: from debugger
Uptime: 27s
Dumping 511 MB
ata0: resetting devices ..
done
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 
384 400 416 432 448 464 480 496
---
#0  doadump () at /usr/src/current/sys/kern/kern_shutdown.c:223
223 dumping++;
(kgdb) bt
#0  doadump () at /usr/src/current/sys/kern/kern_shutdown.c:223
#1  0xc02fa327 in boot (howto=260)
at /usr/src/current/sys/kern/kern_shutdown.c:355
#2  0xc02fa528 in panic () at /usr/src/current/sys/kern/kern_shutdown.c:508
#3  0xc0165a2d in db_panic () at /usr/src/current/sys/ddb/db_command.c:450
#4  0xc01659d2 in db_command (last_cmdp=0xc05248c0, cmd_table=0x0, 
aux_cmd_tablep=0xc051874c, aux_cmd_tablep_end=0xc0518764)
at /usr/src/current/sys/ddb/db_command.c:346
#5  0xc0165a9b in db_command_loop ()
at /usr/src/current/sys/ddb/db_command.c:472
#6  0xc01681bb in db_trap (type=12, code=0)
at /usr/src/current/sys/ddb/db_trap.c:72
#7  0xc0472024 in kdb_trap (type=12, code=0, regs=0xd7aa4978)
at /usr/src/current/sys/i386/i386/db_interface.c:166
#8  0xc0481b1d in trap_fatal (frame=0xd7aa4978, eva=120)
at /usr/src/current/sys/i386/i386/trap.c:841
#9  0xc048187b in trap_pfault (frame=0xd7aa4978, usermode=0, eva=120)
at /usr/src/current/sys/i386/i386/trap.c:760
#10 0xc0481396 in trap (frame=
  {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = -1, tf_ebp = 
-676705856, tf_isp = -676705884, tf_ebx = -1003001832, tf_edx = -1005136048, tf_ecx = 
4, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -1070317171, tf_cs = 8, tf_eflags 
= 66050, tf_esp = -1003001832, tf_ss = -1005136048})
at /usr/src/current/sys/i386/i386/trap.c:446
#11 0xc0473518 in calltrap () at {standard input}:98
#12 0xc0344729 in vrele (vp=0xc4376818)
at /usr/src/current/sys/kern/vfs_subr.c:2162
#13 0xc034433b in addaliasu (nvp=0xc4376818, nvp_rdev=1033)
at /usr/src/current/sys/kern/vfs_subr.c:2021
#14 0xc02a5bd2 in devfs_allocv (de=0xc4339980, mp=0xc41e3a00, vpp=0xd7aa4c44, 
td=0xc416d750) at /usr/src/current/sys/fs/devfs/devfs_vnops.c:157
#15 0xc02a63f5 in devfs_lookupx (ap=0x0)
at /usr/src/current/sys/fs/devfs/devfs_vnops.c:422
#16 0xc02a6491 in devfs_lookup (ap=0xd7aa4b8c)
at /usr/src/current/sys/fs/devfs/devfs_vnops.c:440
#17 0xc033dd03 in lookup (ndp=0xd7aa4c30) at vnode_if.h:52
#18 0xc033d799 in namei (ndp=0xd7aa4c30)
at /usr/src/current/sys/kern/vfs_lookup.c:181
#19 0xc0349c4a in stat (td=0xc416d750, uap=0xd7aa4d14)
at /usr/src/current/sys/kern/vfs_syscalls.c:1648
#20 0xc0481deb in syscall (frame=
  {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134562594, tf_esi = 134575950, 
tf_ebp = -1077937864, tf_isp = -676704908, tf_ebx = 134575948, tf_edx = -1077938050, 
tf_ecx = 134575848, tf_eax = 188, tf_trapno = 12, tf_err = 2, tf_eip = 134516703, 
tf_cs = 31, tf_eflags = 642, tf_esp = -1077938244, tf_ss = 47})
at /usr/src/current/sys/i386/i386/trap.c:1035
#21 0xc047356d in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---

(kgdb) frame 12
#12 0xc0344729 in vrele (vp=0xc4376818)
at /usr/src/current/sys/kern/vfs_subr.c:2162
2162v_incr_usecount(vp, -1);
(kgdb) list
2157
2158return;
2159}
2160
2161if (vp-v_usecount == 1) {
2162v_incr_usecount(vp, 

Re: Lack of real long double support

2002-10-25 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
Loren James Rittle [EMAIL PROTECTED] writes:
: Yet, the FP hardware is actually configured by default to provide
: `long double' as:
: 
: #define LDBL_MANT_DIG   53
: #define LDBL_MIN_EXP(-16381)
: #define LDBL_MAX_EXP16384
: 
: Indeed, FP code using long double generated by gcc 2.95.X, installed
: as the FreeBSD 4 system compiler, uses the full exponent range of
: -16381 to 16384.  However, printf(), etc loses on that exponent range
: and reports Inf.  I suspect this is why the system header misreports
: the FP hardware, thus the header describes the largest printable long
: double value, not the largest that could be held in a calculation.

I have patches to fix these constants, but not to fix printf, and co,
to really support the full precision of long double.  Even NetBSD
doesn't do that.

: Anyways, two questions for FreeBSD maintainers.  How should gcc, as
: provided from the FSF, describe the long double FP format for
: FreeBSD/i386 4.x?  Shall we assume that no changes for FreeBSD 5.x
: will occur?

No.  You should assume that for i386, at least, that long double will
have the right LDBL_ constants.  I've had them in my local tree for
about 3 months now and just haven't found the time to commit to
-current.  I'll find the time right now.

Warner

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



Re: libgtop port and v_tag changes

2002-10-25 Thread Nate Lawson
On 24 Oct 2002, Joe Marcus Clarke wrote:
 I committed my patch to libgtop and libgtop2 a while ago.  It should
 work on both -CURRENT, not so -CURRENT, and -stable.  Checkout patch-ah
 in libgtop/files.  Works like a champ on -CURRENT from Monday.

Thanks for taking care of that.

-Nate


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



Re: Lack of real long double support

2002-10-25 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
Bruce Evans [EMAIL PROTECTED] writes:
: On Thu, 24 Oct 2002, Loren James Rittle wrote:
: 
:  ...  Anyways, that work exposed some issues.
: 
:  We have this in the system header:
: 
:  #define LDBL_MANT_DIG   DBL_MANT_DIG
:  #define LDBL_MIN_EXPDBL_MIN_EXP
:  #define LDBL_MAX_EXPDBL_MAX_EXP
:  [...]
: 
: This seems to be correct.  Long double precision is not really supported
: either at complie time or runtime.  The default precision (on i386's)
: is 53 bits, so (normalized) long doubles have a hard time getting any
: larger than DBL_MAX or any smaller than DBL_MIN (you can create them
: as bits or using a hardware transcendental function, but any arithmetic
: on them will convert them to double precision).

That is incorrect.  long double are supported at runtime.  We use them
all the time and do get numbers outside the range of normal doubles.
There are some minor rounding issues with them, but those issues
result in a 1-2 bit rounding error in most of the cases I've looked at
in extreme detail.  Such rounding errors do limit the effective range
to about 62 bits, but that's still a lot better than 53 bits you get
with doubles.

: gcc can't actually support the full range, since it doesn't control
: the runtime environement (it could issue a fninit before main() to
: change the default, but it shouldn't and doesn't).  The exponent
: range is lost long before printf() is reached.  E.g.,
: 
:   long double x= DBL_MAX;
:   long double y = 2 * x;
: 
: gives +Inf for y since the result is doesn't fit in 53-bit precision.
: The system header correctly reports this default precision.  Any header
: genrated by the gcc build should be no different, since the build should
: run in the target environment.

that's not true.  y is not +Inf, but prints as +Inf because printf and
friends do not support outside the range of a double.

If you were correct, the following program would say so:
#include stdio.h
#include float.h

int main(int argc, char **argv)
{
long double x = DBL_MAX;
long double y = x * 2;
long double z = x * 3;

if (y == z)
printf(bde is right\n);
else
printf(bde is not right\n);
}

but it prints that you are not correct.  If you were correct, both y
and z would be the same (+Inf), but they are not (they both print as
+Inf, but that's a bug in our printf code).  A version of the above
with doubles does show they are both the same (+Inf).

: Not really.  Assembly is still required to get full control over precision.
: I'm still waiting for (C) language support to catch up.  Been waiting for
: about 14 years so far.  C99 clarified the semantics of floating point
: precision but is not supported by gcc (yet?).

This is not true.

:  Also, as an aside, having just learned everything there is to know
:  about IEEE FP from a witty 80-slide presentation on the WWW by one of
:  the original designers of the spec@Berkeley, I'd say that he would be
:  sad that we default to use 53-bit precision mode.  I'd say that it is
:  dumb to claim we even support long double unless we change that to
:  64-bit precision mode...
: 
: I think he would be even unhappier with gcc's support for it.  We default
: to 53-bit precision partly because Kahan's (his?) paranioa(1) is unhappy
: with 64-bit precision.

Kahan's paranoia is unhappy with 64-bit precision, but the unhappiness
is on the order of 1-2 bits of rounding error in the wrong direction.

Warner

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



Re: Building -CURRENT with 4.5-RELEASE

2002-10-25 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
Tim Kientzle [EMAIL PROTECTED] writes:
:   On Tue, Oct 22, 2002 at 11:52:11PM +0200, Gerhard H=E4ring wrote:
: 
: make installworld dumps core at installing passwd (4.5-RELEASE).
: 
: 
: Brooks Davis:
: 
:  Are you running a current kernel at this point?  If you aren't it's safe
:  to say it won't work.
: 
: The directions in UPDATING leave you running
: an OLD kernel after rebooting into single-user.
: (Installkernel puts the kernel in the new location,
: but the old boot loader is still on disk, so it
: loads the kernel from the old location.)  If
: a new kernel is required at this point, then
: UPDATING is wrong or installkernel is wrong.

You are correct about this.  I'll update it to include installing the
new bootblocks as well, if that isn't already in there for the 4.x -
5.0 upgrade path.

Warner

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



Re: Installworld fails building Current from 4.7-R

2002-10-25 Thread M. Warner Losh
What does uname -a say in single user.  It should say 5.0, but I'd
guess it is saying 4.x.

Warner



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



Re: Re: kernel broken? (devfs maybe?)

2002-10-25 Thread Julian Elischer
yep that fixes it.. 


On Thu, 24 Oct 2002, Andrew Gallatin wrote:

 
 Try backing out phk's src/sys/kern/vfs_subr.c 1.416
 Does that help?
 
 Drew
 


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



Re: Lack of real long double support

2002-10-25 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
M. Warner Losh [EMAIL PROTECTED] writes:
: : Anyways, two questions for FreeBSD maintainers.  How should gcc, as
: : provided from the FSF, describe the long double FP format for
: : FreeBSD/i386 4.x?  Shall we assume that no changes for FreeBSD 5.x
: : will occur?
: 
: No.  You should assume that for i386, at least, that long double will
: have the right LDBL_ constants.  I've had them in my local tree for
: about 3 months now and just haven't found the time to commit to
: -current.  I'll find the time right now.

I've committed the fix to the tree.  NetBSD uses these numbers, and
I've been using these numbers on a large number of systems that we
maintain at timing solutions (they were added to our local tree prior
to the 4.5 release, and we've built hundreds of ports since then w/o
any issues).  I've had them in my own personal p4 tree for 3 months
with similar results.

Warner

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



gcc 3.2.1 optimization bug with BitchX

2002-10-25 Thread drogoh
I know I should be posting this to the gcc people or ports list, but so far all I and 
the current BitchX coder (nuke) have seen this on is -CURRENT.

quoted from an e-mail with nuke:
Program received signal SIGSEGV, Segmentation fault.
0x0804b0f1 in aliascmd (command=0x813ebc8 0, 
args=0xbfbf735e ;@ plistf = 5;^on ^cdcc_prepack * {fix.cdcc $0 $1  
\037[\037cdcc\037]\037 \002$[-2]3\002 file(s) offered\037-\037 /ctcp \002$N\002 cdcc

 send #x for pack #x};^on ^cdcc_note { ;fix.cdcc $0 $1 $2-};^on ^cdcc_postpack * 
 {@ lsize = ..., subargs=0x0, helparg=0x8136e7b - Scripting command)
at alias.c:329
329 args++;

 Seems to be a optimization bug with gcc 3.2.1.

 Edit the Makefile to have -O in the CFLAGS instead of -O2 and
 it works fine.  We should probably report this to the FreeBSD
 or gcc teams.

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



Re: sparc64 tinderbox failure

2002-10-25 Thread Bruce Evans
On Thu, 24 Oct 2002, Andrew Gallatin wrote:

 Mike Barcroft writes:
stage 4: building everything..
   --
   === usr.sbin/pkg_install/info
   cc1: warnings being treated as errors
   /tinderbox/sparc64/src/usr.sbin/pkg_install/info/show.c: In function `show_size':
   /tinderbox/sparc64/src/usr.sbin/pkg_install/info/show.c:239: warning: passing arg 
1 of `getbsize' from incompatible pointer type
   *** Error code 1

 I fixed this an hour or 2 ago when I hit it on my alpha.

 How long does a sparc64 buildworld take on reasonably priced hardware?
 Where resonable means = $1000 USD, used OK.

I pointed out this breakage a day or two ago.  The breakage has since been
expanded by breaking most of the messengers, but but pkg_install until you
hit it.  The complete list of messages in usr/src is easy to find using
grep.

Bruce


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



how2 enable pppd support on current

2002-10-25 Thread suken woo
at title:
best regards


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



sparc64 tinderbox failure

2002-10-25 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== usr.sbin/sysinstall
/tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c: In function `dmenuOpen':
/tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c:291: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c:295: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c:299: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/usr.sbin/sysinstall/menus.c:1370: warning: initialization makes 
integer from pointer without a cast
disks.o: In function `diskPartitionWrite':
disks.o(.text+0x14b8): undefined reference to `Write_Disk'
wizard.o: In function `slice_wizard':
wizard.o(.text+0x5e4): undefined reference to `Write_Disk'
*** Error code 1

Stop in /tinderbox/sparc64/src/usr.sbin/sysinstall.
*** Error code 1

Stop in /tinderbox/sparc64/src/usr.sbin.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

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



Re: Installing from CD and MAKEDEV

2002-10-25 Thread Jun Kuriyama
At Thu, 24 Oct 2002 12:10:53 + (UTC),
kuriyama wrote:
 I've created install CD with make iso.1 (with sources few hours
 before).
 
 I'm trying to install fresh current box with this CD.  But I got
 MAKEDEV returned non-zero status dialog after extracting dists.
 
 It seems cd /dev; sh MAKEDEV all is failed at devfs environment.

I found it.

Phk changes in 1.297 of src/etc/Makefile not to install MAKEDEV by
default.  Options may be:

(1) Back out 1.297.
(2) Set MAKEDEV_INSTALL for install-media environment.
(3) Drop non-devfs code from sysinstall (really???).


-- 
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.
 [EMAIL PROTECTED] // FreeBSD Project

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



Re: kernel broken? (devfs maybe?)

2002-10-25 Thread Poul-Henning Kamp

Please try the rev 1.418 of vfs_subr.c

 db tr
 v_incr_usecount(c1d76cb8,,c037b472,863,cc34a92c) at
 v_incr_usecount+0x48vrele(c1d76cb8,c1c90a00,c036cc7a,6,100) at
 vrele+0xb0
 addaliasu(c1d76cb8,402,c1cb6200,cc34a9c0,c1d73b00) at addaliasu+0x1ad
 devfs_allocv(c1d8f880,c1c90a00,cc34ac38,c0f26340,c01e6fe0) at
 devfs_allocv+0xee
 devfs_lookupx(cc34ab50,1,0,c0f26340,6) at devfs_lookupx+0x58f
 devfs_lookup(cc34ab50,c0f26340,0,c0f26340,c037b472) at devfs_lookup+0x4b
 lookup(cc34ac24,0,c037ad9a,a4,cc34abb8) at lookup+0x302
 namei(cc34ac24,c01bb4bd,c03fbac0,1,c037264a) at namei+0x24e
 stat(c0f26340,cc34ad10,c039bed6,409,2) at stat+0x52
 syscall(2f,2f,2f,8057e86,805b52f) at syscall+0x28e
 Xint0x80_syscall() at Xint0x80_syscall+0x1d

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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



Re: mi_switch deadlock?

2002-10-25 Thread Lamont Granquist

okay, any idea what i'm looking for then?  something is locking the whole
system up...

On Thu, 24 Oct 2002, Julian Elischer wrote:
 On Thu, 24 Oct 2002, Lamont Granquist wrote:
  my -current box keeps freezing about every 24h.  i broke into the kernel
  and forced a panic and found lots of processes stuck in mi_switch().

 Most processes are actually in mi_switch
 that's the last think a process does before it is switched away from..





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



Re: Installing from CD and MAKEDEV

2002-10-25 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Jun Kuriyama writes:
At Thu, 24 Oct 2002 12:10:53 + (UTC),
kuriyama wrote:
 I've created install CD with make iso.1 (with sources few hours
 before).
 
 I'm trying to install fresh current box with this CD.  But I got
 MAKEDEV returned non-zero status dialog after extracting dists.
 
 It seems cd /dev; sh MAKEDEV all is failed at devfs environment.

I found it.

Phk changes in 1.297 of src/etc/Makefile not to install MAKEDEV by
default.  Options may be:

(3) Drop non-devfs code from sysinstall (really???).

This is the way we're going.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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



Re: how2 enable pppd support on current

2002-10-25 Thread Vladimir B.
÷ Fri, 25.10.2002, × 11:32, suken woo ÎÁÐÉÓÁÌ:
 at title:
 best regards

assuming you have /boot/kernel/if_ppp.ko or compiled in ppp interface.

# ifconfig ppp0 create


 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
-- 
Vladimir B. Grebenschikov [EMAIL PROTECTED]
SWsoft Inc.

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



Re: Lack of real long double support (was Re: libstdc++ does notcontain fabsl symbol)

2002-10-25 Thread Bruce Evans
On Thu, 24 Oct 2002, Loren James Rittle wrote:

  ...  Anyways, that work exposed some issues.
 ...
 It is easy to generate, with arithmetic, a long double value outside
 the *exponent* range above no matter how the precision is set; it is
 not truncated to Inf until it is actually cast to a double (as is
 currently done just before a long double is printed with stdio).  See
 below for a program that demonstrates this behavior.

  Yet, the FP hardware is actually configured by default to provide
  `long double' as:

  #define LDBL_MANT_DIG   53

  I think you mean 64 (the hardware default).

 No sir, I did mean as configured in the system startup code, it is
 forced to 53-bits (that choice affects long double as well as double).
 But there are no IEEE control bits to limit the size of the exponent
 field, are there?  Thus, the following describes the exact size of the
 HW's exponent field of a long double as configured by default:

  #define LDBL_MIN_EXP(-16381)
  #define LDBL_MAX_EXP16384

  gcc can't actually support the full range, since it doesn't control
  the runtime environement (it could issue a fninit before main() to
  change the default, but it shouldn't and doesn't).  The exponent
  range is lost long before printf() is reached.  E.g.,

  long double x= DBL_MAX;
  long double y = 2 * x;

  gives +Inf for y since the result is doesn't fit in 53-bit precision.

 As you know, the selection of maximum precision is orthogonal to the
 number of bits used for the exponent.

 I do wish you were correct.  Have you looked at the raw memory of y?
 It is *not* the bit pattern for +Inf.  If y were +Inf, then based on
 the properties of IEEE math, the following would report Inf not
 DBL_MAX/2:

Oops.  I did look at the bits, but I looked more closely at gdb's display
of the value which is broken (it says +inf).  Apparently gdb uses the
host's FP too much.

 #include float.h
 int main (void)
 {
   long double x= LDBL_MAX; // Same as DBL_MAX in current float.h
   long double y = 2e100 * x; // If LDBL_MAX was correct, we should latch Inf.
   long double z = y / 4e100;
   printf (%Lg\n, z);
 }

 It does, in fact, report DBL_MAX/2 with the system compiler on FreeBSD
 4.  FYI, I reviewed the generated code to ensure it was using run-time
 calculations not compile-time calculations.  I'd call that a rather
 easy time getting a normalized long double much larger than
 LDBL_MAX/DBL_MAX.  This test alone proves in my mind that the
 float.h system header for i386 is itself wrong.

Yes, this example is as convincing as examining the (right :) bits.

  The system header correctly reports this default precision.  Any header
  genrated by the gcc build should be no different, since the build should
  run in the target environment.

 I agree that the precision setting in the system header is fine.  The
 size of the exponent field is buggy.  I held the opinion you have but
 while trying to convince RTH (the guy that rewrote gcc FP support), I
 did enough research that also leads me to think that it is the header
 itself which is buggy.

 If you really want, I can tell RTH that FreeBSD/i386 absolutely wants
 `long double' to be:

 53 mantissa bits
 1024 max exponent

No need.  I prefer to keep the 53-bit precision for now, but fix the
exponents.  Hopefully the precision won't be hard-coded into gcc in such
a way as to completely break changing the precision at runtime.  I think
it should affect (only) constant folding.  The issues are very similar
to the ones with changing the rounding mode at runtime (C99 compilers
shouldn't do constant folding in #pragma STDC FENV_ACCESS ON sections
if the correct result might depend on the FP environment).

  It should use whatever is the default format for the host environment,
  It still has enquire.c for doing this automatically.  [...]

 I fear I didn't explain clearly enough.  enquire.c is completely
 *gone* in gcc 3.3.  This is why gcc needs to fully understand the
 exact FP default configuration.  As you noted, enquire.c was buggy.

Ah.  I was a little surprised to find it still in 3.2.  It is not so
much buggy as dysfunctional in a cross compiler.  It has to run on the
target somehow to work.

Bruce


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



Re: mozilla-devel problems

2002-10-25 Thread Ollivier Robert
According to Wesley Morgan:
 I just finished a build of mozilla-devel, and the fonts look just as
 gorgeous as they do in Konqueror. If anyone is having problems with these

What's in your font path ?
-- 
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: Lack of real long double support

2002-10-25 Thread Bruce Evans
On Fri, 25 Oct 2002, M. Warner Losh wrote:

 In message: [EMAIL PROTECTED]
 Bruce Evans [EMAIL PROTECTED] writes:
 : On Thu, 24 Oct 2002, Loren James Rittle wrote:
 :
 :  ...  Anyways, that work exposed some issues.
 : 
 :  We have this in the system header:
 : 
 :  #define LDBL_MANT_DIG   DBL_MANT_DIG
 :  #define LDBL_MIN_EXPDBL_MIN_EXP
 :  #define LDBL_MAX_EXPDBL_MAX_EXP
 :  [...]
 :
 : This seems to be correct.  Long double precision is not really supported
 : either at complie time or runtime.  The default precision (on i386's)
 : is 53 bits, so (normalized) long doubles have a hard time getting any
 : larger than DBL_MAX or any smaller than DBL_MIN (you can create them
 : as bits or using a hardware transcendental function, but any arithmetic
 : on them will convert them to double precision).

 That is incorrect.  long double are supported at runtime.  We use them
 all the time and do get numbers outside the range of normal doubles.
 There are some minor rounding issues with them, but those issues
 result in a 1-2 bit rounding error in most of the cases I've looked at
 in extreme detail.  Such rounding errors do limit the effective range
 to about 62 bits, but that's still a lot better than 53 bits you get
 with doubles.

Um, you get the FreeBSD default of 53 bits on i386's unless you change
the FP environment using fesetprec(3) or equivalent.  This thread
highlighted the point that you get a larger exponent range even with
53-bit precision.

 : gcc can't actually support the full range, since it doesn't control
 : the runtime environement (it could issue a fninit before main() to
 : change the default, but it shouldn't and doesn't).  The exponent
 : range is lost long before printf() is reached.  E.g.,
 :
 : long double x= DBL_MAX;
 : long double y = 2 * x;
 :
 : gives +Inf for y since the result is doesn't fit in 53-bit precision.
 : The system header correctly reports this default precision.  Any header
 : genrated by the gcc build should be no different, since the build should
 : run in the target environment.

 that's not true.  y is not +Inf, but prints as +Inf because printf and
 friends do not support outside the range of a double.

Oops (see another reply).

 : Not really.  Assembly is still required to get full control over precision.
 : I'm still waiting for (C) language support to catch up.  Been waiting for
 : about 14 years so far.  C99 clarified the semantics of floating point
 : precision but is not supported by gcc (yet?).

 This is not true.

No oops.   gcc has no support for the C99 FENV_ACCESS stuff and still
doesn't clip excess precision on assignment.  These are easy to implement
... provided efficiency is not required.

Bruce


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



Re: mozilla-devel problems

2002-10-25 Thread Ollivier Robert
According to Terry Lambert:
 This looks similar to a well known problem that could occur with
 nominally proportional spacing fonts in X programs that incorrectly
 assumed monospacing for characters, and also on nominally fixed

I just made an experience. I logged in on my STABLE machine coming from the
CURRENT machine (so any X app will use the fonts on the CURRENT machine)
and ran mozilla.

The display is *fine*.

So a STABLE mozilla displaying on a CURRENT machine is fine.

I don't understand.
-- 
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: mozilla-devel problems

2002-10-25 Thread Adam Weinberger
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It was brought to my attention today by erk! that the way to solve the
problem is to remove the mozilla-fonts package. It worked for me... I'm
investigating why this is so.

- -Adam


- --
Adam Weinberger
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.0 (FreeBSD)

iD8DBQE9uQ+qo8KM2ULHQ/0RAjvqAKDLH1FozZMnKzkLHDTm4f6+Bhez0QCfSjlC
CrftWKiNQkD4uZv04zUBhHc=
=MSR7
-END PGP SIGNATURE-

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



could sleep with pcm0:play:1 locked

2002-10-25 Thread Sean Kelly
I'm running 5.0-CURRENT from about 15 minutes ago. I'm running with
snd_emu10k1.ko and snd_pcm.ko loaded from loader.conf. When I attempt to do
anything with audio, I get counld sleep messages.

edgemaster# head -1 /dev/audio
^C
edgemaster# dmesg|tail -1
/usr/src/sys/vm/uma_core.c:1311: could sleep with pcm0:record:0 locked from 
/usr/src/sys/dev/sound/pcm/sound.c:191

edgemaster# echo hello /dev/audio
edgemaster# dmesg | tail -1
/usr/src/sys/vm/uma_core.c:1311: could sleep with pcm0:play:1 locked from 
/usr/src/sys/dev/sound/pcm/sound.c:191


sys/dev/sound/pcm/sound.c:
188:/* scan for a free channel */
189:SLIST_FOREACH(sce, d-channels, link) {
190:c = sce-channel;
191:CHN_LOCK(c);

sys/dev/sound/pcm/channel.h:
#ifdef  USING_MUTEX
...
#define CHN_LOCK(c) mtx_lock((struct mtx *)((c)-lock))
...
#else
#define CHN_LOCK(c)
...
#endif

I'd suggest a fix, but I'm only pretending to know what I'm doing so far.

-- 
Sean Kelly | PGP KeyID: 77042C7B
[EMAIL PROTECTED] | http://www.zombie.org

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



Re: mozilla-devel problems

2002-10-25 Thread Terry Lambert
Ollivier Robert wrote:
 According to Terry Lambert:
  This looks similar to a well known problem that could occur with
  nominally proportional spacing fonts in X programs that incorrectly
  assumed monospacing for characters, and also on nominally fixed
 
 I just made an experience. I logged in on my STABLE machine coming from the
 CURRENT machine (so any X app will use the fonts on the CURRENT machine)
 and ran mozilla.
 
 The display is *fine*.
 
 So a STABLE mozilla displaying on a CURRENT machine is fine.
 
 I don't understand.

So the X server was running on your -CURRENT machine, but the
application was running on your -STABLE machine?

I think this is because on -STABLE, Mozilla compiles without the
extra font stuff by default, doesn't it?  THat was mentioned in
an earlier message by someone else.

Can you copy over the code as configured on -CURRENT to the -STABLE
machine, so it compiles and links everything as if it were running
on a -CURRENT machine?  E.g. verify your implication that it's the
compiler or the libraries specific to the -CURRENT machine, rather
than a diffirence in the environment sensed by configure, etc.?

-- Terry

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



alpha tinderbox failure

2002-10-25 Thread Dag-Erling Smorgrav
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== share/doc/usd/13.viref
out of memory
*** Error code 255

Stop in /h/des/src/share/doc/usd/13.viref.
*** Error code 1

Stop in /h/des/src/share/doc/usd.
*** Error code 1

Stop in /h/des/src/share/doc.
*** Error code 1

Stop in /h/des/src/share.
*** Error code 1

Stop in /h/des/src.
*** Error code 1

Stop in /h/des/src.
*** Error code 1

Stop in /h/des/src.

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



Re: mozilla-devel problems

2002-10-25 Thread Ollivier Robert
According to Adam Weinberger:
 It was brought to my attention today by erk! that the way to solve the
 problem is to remove the mozilla-fonts package. It worked for me... I'm
 investigating why this is so.

Works for me too. Thanks a lot !
-- 
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: 5.0-RUSH: -current install testers wanted!

2002-10-25 Thread Alex Zepeda
On Tue, Oct 22, 2002 at 07:53:38PM -0700, Juli Mallett wrote:

 peter@ has been working busily in a Perforce branch to fix a lot of crap
 and it's by no means a small amount of work that he's done so far,
 especially taking into account the amount of testing and debugging he
 seems to be doing.
 
 It's the 'peter_sigfix' branch, I think.

Great.  Now where's the docu on this whole Perforce repository that
everyone's so hot about?  And what parts of what do I need?

- alex

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



Re: Floating point problems

2002-10-25 Thread Juli Mallett
* De: Bruce Evans [EMAIL PROTECTED] [ Data: 2002-10-24 ]
[ Subjecte: Re: Floating point problems ]
 Thanks.  This makes the main bug clear.  The PCB_NPXINITDONE bit in the
 state was not being restored.  This was confusing to debug because gdb
 doesn't understand this bug so it shows the state that should have been
 restored until npxdna() unrestores it consistently.  Try this fix.

FWIW, this fixes every reproducable hang I've had with X and related.

Thanks!
juli.
-- 
Juli Mallett [EMAIL PROTECTED]   | FreeBSD: The Power To Serve
Will break world for fulltime employment. | finger [EMAIL PROTECTED]
http://people.FreeBSD.org/~jmallett/  | Support my FreeBSD hacking!

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



ia64 tinderbox failure

2002-10-25 Thread Peter Wemm
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== usr.sbin/sysinstall
/home/tinderbox/ia64/src/usr.sbin/sysinstall/dmenu.c: In function `dmenuOpen':
/home/tinderbox/ia64/src/usr.sbin/sysinstall/dmenu.c:291: warning: cast to pointer 
from integer of different size
/home/tinderbox/ia64/src/usr.sbin/sysinstall/dmenu.c:295: warning: cast to pointer 
from integer of different size
/home/tinderbox/ia64/src/usr.sbin/sysinstall/dmenu.c:299: warning: cast to pointer 
from integer of different size
/home/tinderbox/ia64/src/usr.sbin/sysinstall/menus.c:1370: warning: initialization 
makes integer from pointer without a cast
disks.o: In function `diskPartitionWrite':
disks.o(.text+0x2f72): undefined reference to `Write_Disk'
*** Error code 1

Stop in /home/tinderbox/ia64/src/usr.sbin/sysinstall.
*** Error code 1

Stop in /home/tinderbox/ia64/src/usr.sbin.
*** Error code 1

Stop in /home/tinderbox/ia64/src.
*** Error code 1

Stop in /home/tinderbox/ia64/src.
*** Error code 1

Stop in /home/tinderbox/ia64/src.

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



Re: Floating point problems

2002-10-25 Thread Peter Edwards
I can also confirm that my X server has been rock solid since applying the
patch.
I think Bruce deserves a lollipop.

Juli Mallett [EMAIL PROTECTED] wrote:

 
 * De: Bruce Evans [EMAIL PROTECTED] [ Data: 2002-10-24 ]
   [ Subjecte: Re: Floating point problems ]
  Thanks.  This makes the main bug clear.  The PCB_NPXINITDONE bit in the
  state was not being restored.  This was confusing to debug because gdb
  doesn't understand this bug so it shows the state that should have been
  restored until npxdna() unrestores it consistently.  Try this fix.
 
 FWIW, this fixes every reproducable hang I've had with X and related.
 
 Thanks!
 juli.
 -- 
 Juli Mallett [EMAIL PROTECTED]   | FreeBSD: The Power To Serve
 Will break world for fulltime employment. | finger [EMAIL PROTECTED]
 http://people.FreeBSD.org/~jmallett/  | Support my FreeBSD hacking!
 

-- 
Peter Edwards.


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



5.0-20021025-CURRENT snapshot

2002-10-25 Thread John De Boskey

This will be the last post on this topic.

A new 5.0-20021025-CURRENT snapshot is available
via anonymous ftp at usw2.freebsd.org:

/pub/FreeBSD/snapshots/i386/5.0-20021025-CURRENT

New snaps will appear each day if the build completes
without errors.

Enjoy!
John


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



Re: alpha tinderbox failure

2002-10-25 Thread Andrew Gallatin

Dag-Erling Smorgrav writes:
  === share/doc/usd/13.viref
  out of memory
  *** Error code 255
  

Can you update the kernel and rtld on this machine as indicated in
UPDATING?   Otherwise, we'll see this same failure forever.

Also, is there any way I can talk you out of building LINT on alpha in
your tinderbox, or at least talk you into building it without WARNS?
(there are several hundred pointer/integer with different size casts
in various ILP32-centric drivers, and several hundred printf format
warnings, so LINT will always fail and the alpha tinderbox will just
by crying wolf and annoying people).

Thanks,

Drew

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



Re: Installing from CD and MAKEDEV

2002-10-25 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Jun Kuriyama writes:
At Thu, 24 Oct 2002 12:10:53 + (UTC),
kuriyama wrote:
 I've created install CD with make iso.1 (with sources few hours
 before).
 
 I'm trying to install fresh current box with this CD.  But I got
 MAKEDEV returned non-zero status dialog after extracting dists.
 
 It seems cd /dev; sh MAKEDEV all is failed at devfs environment.

I found it.

Phk changes in 1.297 of src/etc/Makefile not to install MAKEDEV by
default.  Options may be:

This should be fixed now I hope.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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



Re: libgtop port and v_tag changes

2002-10-25 Thread John Baldwin

On 25-Oct-2002 Joe Marcus Clarke wrote:
 On Thu, 2002-10-24 at 19:13, Nate Lawson wrote:
 On Thu, 24 Oct 2002, John Baldwin wrote:
  Speaking of v_tag, can you fix the devel/libgtop port on current?
  This is the patch I used to get it building the other day:
  
   cat patch-sysdeps_freebsd_procmap.c 
  --- sysdeps/freebsd/procmap.c.orig  Tue Oct 15 20:00:35 2002
  +++ sysdeps/freebsd/procmap.c   Tue Oct 15 20:05:54 2002
  @@ -251,6 +251,7 @@
vnode, sizeof (vnode)) != sizeof (vnode))
  glibtop_error_io_r (server, kvm_read (vnode));
   
  +#if __FreeBSD_version  50
  if ((vnode.v_type != VREG) || (vnode.v_tag != VT_UFS) ||
  !vnode.v_data) continue;
   
  @@ -261,6 +262,7 @@
   
  maps [i-1].inode  = inode.i_number;
  maps [i-1].device = inode.i_dev;
  +#endif
   #endif
  } while (entry.next != first);
  
  -- 
  
  John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
  Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/
 
 I assume Joe has a better version he planned to commit as referenced by
 this email:
 
   [EMAIL PROTECTED]
 
 I like his patch better because it still handles the non CURRENT case.  
 Joe?
 
 I committed my patch to libgtop and libgtop2 a while ago.  It should
 work on both -CURRENT, not so -CURRENT, and -stable.  Checkout patch-ah
 in libgtop/files.  Works like a champ on -CURRENT from Monday.

It does?!  v_tag is a pointer to kernel memory, you can't read that
from userland!  You would get a SIGSEGV and die as soon as you do the
'strcmp()'.  That's why I #ifdef'd the whole chunk out.  Also, just for
the record, my code didn't break the non CURRENT case. :)

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
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: Floating point problems

2002-10-25 Thread Alexander Leidinger
On Fri, 25 Oct 2002 03:43:03 -0700
Juli Mallett [EMAIL PROTECTED] wrote:

 FWIW, this fixes every reproducable hang I've had with X and related.

AOL

Bye,
Alexander.

-- 
The dark ages were caused by the Y1K problem.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7

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



Re: mozilla-devel problems

2002-10-25 Thread Matt Loschert
On Fri, 25 Oct 2002, Ollivier Robert wrote:

 According to Adam Weinberger:
  It was brought to my attention today by erk! that the way to solve the
  problem is to remove the mozilla-fonts package. It worked for me... I'm
  investigating why this is so.

 Works for me too. Thanks a lot !
 --
 Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]

Me too.  Thanks!

- Matt

--
Matt Loschert - Software Engineer   | email: [EMAIL PROTECTED]|
ServInt Internet Services   | web:   http://www.servint.net/ |
McLean, Virginia USA| phone: (703) 847-1381  |


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



Re: mozilla-devel problems

2002-10-25 Thread Ollivier Robert
According to Matt Loschert:
 Me too.  Thanks!

The CURRENT machine I've tested is rather old, world/kernel is from Sep.
18th. On an October, 20th CURRENT machine, mozilla just segfaults.

During its reading of all fonts available, it get a segv...
Any idea ?

...
e3affe4fa68dd8cab058ebb21962d72dcfeaaa47e541a2ff3e6ecdacf0484ec3
7151b6b1fa6109a0113e3bef3145b53d05c62e0391e266393ba1a4b39a806a12
f2fe6562dff2fc97eff531ded8dc6e0ed359b2bf16d00031e9e0753bb32c156e
ea81b7db813752506558d39f967450fa05390368950c456f106211dfc0621e52
66c14e1ebc6a9f3de3165500218fd683fa0dd2b4fcb937f14f7d3fb85faf556e
3f53ad74a4bcd96872b46716e0bd737dbf5d3115ce382ffb8243c499503283c4
274a0e51c9d41b302fd57c648a4e1769dcab4668ee624f3b9c84f296ba9ca925
056358d1e7f5a56ce1e53b5676d5e9ccfa4cf68f18f28aee890b1bfad737
03b64dcd7c5f34387f4522f421045adb7cb8b552d5145b83e24667d4f80cf636
45f80b863f0293b1d494ed65532c3963b69fe1a858850799155ed2450d836d30
d28dbfc50c7a58fd713346961d7f0e5513394b29c06c52b786b48a2f13b95b9d
56d6aca8250f3b716f055275af003304d36713f14228b5ec40de7c3ba9ae32cd
eb91f8110bafcf7c92ea383bd9ca4d4fd0f6ccb0902b07841a4cbee2cbe21c4a
8124a11ef70c32d89e4b86d0e84294412f305ec186afd600ef7d72634e931f60
a75a22b03abbb87b4a163044b96d43cb1a8eac9484df8955edd18bb298612
 52448 mozilla-bin RET   read 6818/0x1aa2
 52448 mozilla-bin PSIG  SIGPROF caught handler=0x2856bb70 mask=0x0 code=0x0
 52448 mozilla-bin CALL  gettimeofday(0x28578158,0)
 52448 mozilla-bin RET   gettimeofday 0
 52448 mozilla-bin CALL  sigprocmask(0x3,0x285781dc,0)
 52448 mozilla-bin RET   sigprocmask 0
 52448 mozilla-bin CALL  poll(0x8092000,0x1,0)
 52448 mozilla-bin RET   poll 0
 52448 mozilla-bin CALL  sigreturn(0xbfbfcb3c)
 52448 mozilla-bin RET   sigreturn JUSTRETURN
 52448 mozilla-bin PSIG  SIGSEGV caught handler=0x2856bb70 mask=0x0 code=0xc
 52448 mozilla-bin CALL  sigprocmask(0x3,0x285781dc,0)
 52448 mozilla-bin RET   sigprocmask 0
 52448 mozilla-bin CALL  unlink(0x81430c0)
 52448 mozilla-bin NAMI  /home/staff/roberto/.mozilla/roberto/lxaarw4c.slt/lock
 52448 mozilla-bin RET   unlink 0
 52448 mozilla-bin CALL  setitimer(0x2,0xbfbfcd84,0)
 52448 mozilla-bin RET   setitimer 0
 52448 mozilla-bin CALL  close(0x3)
 52448 mozilla-bin RET   close 0
 52448 mozilla-bin CALL  close(0x4)
 52448 mozilla-bin RET   close 0
...
 52448 mozilla-bin CALL  exit(0xb)
 52443 sh   RET   wait4 52448/0xcce0
 52443 sh   CALL  exit(0xb)
-- 
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



ia64 tinderbox failure

2002-10-25 Thread Peter Wemm
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== usr.sbin/sysinstall
/home/tinderbox/ia64/src/usr.sbin/sysinstall/dmenu.c: In function `dmenuOpen':
/home/tinderbox/ia64/src/usr.sbin/sysinstall/dmenu.c:291: warning: cast to pointer 
from integer of different size
/home/tinderbox/ia64/src/usr.sbin/sysinstall/dmenu.c:295: warning: cast to pointer 
from integer of different size
/home/tinderbox/ia64/src/usr.sbin/sysinstall/dmenu.c:299: warning: cast to pointer 
from integer of different size
/home/tinderbox/ia64/src/usr.sbin/sysinstall/menus.c:1370: warning: initialization 
makes integer from pointer without a cast
disks.o: In function `diskPartitionWrite':
disks.o(.text+0x2f72): undefined reference to `Write_Disk'
*** Error code 1

Stop in /home/tinderbox/ia64/src/usr.sbin/sysinstall.
*** Error code 1

Stop in /home/tinderbox/ia64/src/usr.sbin.
*** Error code 1

Stop in /home/tinderbox/ia64/src.
*** Error code 1

Stop in /home/tinderbox/ia64/src.
*** Error code 1

Stop in /home/tinderbox/ia64/src.

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



Re: libgtop port and v_tag changes

2002-10-25 Thread Nate Lawson
On Fri, 25 Oct 2002, Joe Marcus Clarke wrote:
 On Fri, 25 Oct 2002, John Baldwin wrote:
  It does?!  v_tag is a pointer to kernel memory, you can't read that
  from userland!  You would get a SIGSEGV and die as soon as you do the
  'strcmp()'.  That's why I #ifdef'd the whole chunk out.  Also, just for
  the record, my code didn't break the non CURRENT case. :)

Sorry, mispoke.  Your code didn't fix the CURRENT case.  :)
 
 Gak!  If Julian didn't pound kvm_read into my head before, I've got it
 now.  Sure, it compiles, buth then what :-}.  Thanks for the pointer.
 Attached is a patch to libgtop2, but should be similar if not identical to
 what's needed for libgtop.  Let me know if this looks a little better.
 Thanks.
 
 Joe

For another working and tested example, see rev 1.45 of fstat.c
(usr.bin/fstat).

-Nate


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



Re: libgtop port and v_tag changes

2002-10-25 Thread John Baldwin

On 25-Oct-2002 Joe Marcus Clarke wrote:
 On Fri, 25 Oct 2002, John Baldwin wrote:
 

 On 25-Oct-2002 Joe Marcus Clarke wrote:
  On Thu, 2002-10-24 at 19:13, Nate Lawson wrote:
  On Thu, 24 Oct 2002, John Baldwin wrote:
   Speaking of v_tag, can you fix the devel/libgtop port on current?
   This is the patch I used to get it building the other day:
  
cat patch-sysdeps_freebsd_procmap.c
   --- sysdeps/freebsd/procmap.c.orig  Tue Oct 15 20:00:35 2002
   +++ sysdeps/freebsd/procmap.c   Tue Oct 15 20:05:54 2002
   @@ -251,6 +251,7 @@
 vnode, sizeof (vnode)) != sizeof (vnode))
   glibtop_error_io_r (server, kvm_read (vnode));
  
   +#if __FreeBSD_version  50
   if ((vnode.v_type != VREG) || (vnode.v_tag != VT_UFS) ||
   !vnode.v_data) continue;
  
   @@ -261,6 +262,7 @@
  
   maps [i-1].inode  = inode.i_number;
   maps [i-1].device = inode.i_dev;
   +#endif
#endif
   } while (entry.next != first);
  
   --
  
   John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
   Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/
 
  I assume Joe has a better version he planned to commit as referenced by
  this email:
 
[EMAIL PROTECTED]
 
  I like his patch better because it still handles the non CURRENT case.
  Joe?
 
  I committed my patch to libgtop and libgtop2 a while ago.  It should
  work on both -CURRENT, not so -CURRENT, and -stable.  Checkout patch-ah
  in libgtop/files.  Works like a champ on -CURRENT from Monday.

 It does?!  v_tag is a pointer to kernel memory, you can't read that
 from userland!  You would get a SIGSEGV and die as soon as you do the
 'strcmp()'.  That's why I #ifdef'd the whole chunk out.  Also, just for
 the record, my code didn't break the non CURRENT case. :)
 
 Gak!  If Julian didn't pound kvm_read into my head before, I've got it
 now.  Sure, it compiles, buth then what :-}.  Thanks for the pointer.
 Attached is a patch to libgtop2, but should be similar if not identical to
 what's needed for libgtop.  Let me know if this looks a little better.
 Thanks.

Well, here's the thing.  If libgtop is intended to be used only with live
kernels then it might be a better idea to use xvnode's that you get with
from the kernel.  Alternatively, you could grab the inode and dev number
the same way the sysctl handler does:

switch (vp-v_type) {
case VREG:
case VDIR:
case VLNK:
xvn[n].xv_dev = vp-v_cachedfs;
xvn[n].xv_ino = vp-v_cachedid;

i.e., you could look at those members of struct vnode instead of trying
to dig into the details of a UFS inode structure in v_data.  This
would remove the need to look at v_tag at all.

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
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



pppd not working on latest current 2002-10-20

2002-10-25 Thread Dave Evans
Is anyone using pppd on CURRENT.  somewhere between may and October it
seems to have broken.  My KERNEL is GENERIC, my sources are dated cvs
-D2002-10-20, but I now get a message about needing facilities in the
kernel. However, the kernel has many ppp entry points, I haven't
modified GENERIC which loads the ppp device, I've tried loading modules
with ppp in their name all to no avail.


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



Re: df problems ?

2002-10-25 Thread Dave Evans
In article [EMAIL PROTECTED] you write:
 Alexey Zelkin wrote:
  Folks,
 
  I have dual boot machine with -STABLE and -CURRENT (both have own
  boot slices and few slices are shared between them.)
 
 I don't know all the details, but -CURRENT recently changed the way
 information is recorded in the superblock.  The first copy of the
 superblock will be different between -CURRENT and -STABLE.
 
 Any partitions that are shared between -STABLE and -CURRENT
 must be fsck'd before use on the opposite system.  The fsck was
 changed in -STABLE to look for the difference and correct it
 without getting confused.
 

This is all very true for 4.7, but what about earlier versions.

I compiled fsck using 4.7 srcs, includes and hierarchy with 4.0
libraries and tools, so that I could have an fsck I could use with my
4.0 CDROM (the latest one I have, unfortunately) to repair any changes
made by my CURRENT system. It does compile with the same errors you get
on a true 4.7 system about unsigned/signed comparisons. It even works as
a program, but it does not repair the filesystem properly to be
compatible with 4.0. You get an instant panic when going multi-user.
This is a real nuisance as it blows my recovery strategy should I ever
need it. If someone could figure out how to fix this I would be grateful
until the time I get my hands on a 5.0 CDROM


The tape format for dump/restore has been changed as well between
CURRENT-Jan 2001 and CURRENT-October 2002. 


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



Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Brooks Davis
On Fri, Oct 25, 2002 at 06:15:55PM +, Dave Evans wrote:
 Is anyone using pppd on CURRENT.  somewhere between may and October it
 seems to have broken.  My KERNEL is GENERIC, my sources are dated cvs
 -D2002-10-20, but I now get a message about needing facilities in the
 kernel. However, the kernel has many ppp entry points, I haven't
 modified GENERIC which loads the ppp device, I've tried loading modules
 with ppp in their name all to no avail.

You need to create an interface first. Run ifconfig ppp create.

-- Brooks

-- 
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4



msg45217/pgp0.pgp
Description: PGP signature


Re: kernel broken? (devfs maybe?)

2002-10-25 Thread Julian Elischer
that fixes it.. thanks


On Fri, 25 Oct 2002, Poul-Henning Kamp wrote:

 
 Please try the rev 1.418 of vfs_subr.c
 
  db tr
  v_incr_usecount(c1d76cb8,,c037b472,863,cc34a92c) at
  v_incr_usecount+0x48vrele(c1d76cb8,c1c90a00,c036cc7a,6,100) at
  vrele+0xb0
  addaliasu(c1d76cb8,402,c1cb6200,cc34a9c0,c1d73b00) at addaliasu+0x1ad
  devfs_allocv(c1d8f880,c1c90a00,cc34ac38,c0f26340,c01e6fe0) at
  devfs_allocv+0xee
  devfs_lookupx(cc34ab50,1,0,c0f26340,6) at devfs_lookupx+0x58f
  devfs_lookup(cc34ab50,c0f26340,0,c0f26340,c037b472) at devfs_lookup+0x4b
  lookup(cc34ac24,0,c037ad9a,a4,cc34abb8) at lookup+0x302
  namei(cc34ac24,c01bb4bd,c03fbac0,1,c037264a) at namei+0x24e
  stat(c0f26340,cc34ad10,c039bed6,409,2) at stat+0x52
  syscall(2f,2f,2f,8057e86,805b52f) at syscall+0x28e
  Xint0x80_syscall() at Xint0x80_syscall+0x1d
 
 -- 
 Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
 [EMAIL PROTECTED] | TCP/IP since RFC 956
 FreeBSD committer   | BSD since 4.3-tahoe
 Never attribute to malice what can adequately be explained by incompetence.
 


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



Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Bakul Shah
 On Fri, Oct 25, 2002 at 06:15:55PM +, Dave Evans wrote:
  Is anyone using pppd on CURRENT.  somewhere between may and October it
  seems to have broken.  My KERNEL is GENERIC, my sources are dated cvs
  -D2002-10-20, but I now get a message about needing facilities in the
  kernel. However, the kernel has many ppp entry points, I haven't
  modified GENERIC which loads the ppp device, I've tried loading modules
  with ppp in their name all to no avail.
 
 You need to create an interface first. Run ifconfig ppp create.

Until pppd is taught to create the interface if one doesn't
exist, this information needs to be in /usr/src/UPDATING.

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



Re: ACPI errors and then panic

2002-10-25 Thread Nate Lawson
Thank you for the reply.

On Sat, 5 Oct 2002, Mitsuru IWASAKI wrote:
 Hi,
 # ACPI CA related problem should be sent to [EMAIL PROTECTED]
 # so that Intel folks can be aware of the problem.

Ok, I didn't know that.
 
 From: Nate Lawson [EMAIL PROTECTED]
 Subject: ACPI errors and then panic
 Date: Fri, 4 Oct 2002 17:14:31 -0700 (PDT)
 Message-ID: [EMAIL PROTECTED]
 
  My laptop appears to work ok without ACPI but of course I don't get
  suspend, resume, etc.  I have never been able to get ACPI to work with it,
  including with a -current as of 2 hours ago.  If ACPI is enabled, I get a
  spew of:
  
  ACPI-0412 *** Error: NsSearchAndEnter: Bad character in ACPI name
  
  and then a panic from acpi_attach.
 
 First several lines of DDB backtrace would be very helpful
 to track the problem down.
 Also having following lines in your loader.conf would be
 helpful to determine which object causes the ACPI CA Eroor.
 
 debug.acpi.layer=ACPI_ALL_COMPONENTS ACPI_BUS
 debug.acpi.level=ACPI_LV_WARN ACPI_LV_ERROR ACPI_LV_OBJECTS

I have placed a ddb session with tracebacks for two panics at:
  http://www.root.org/~nate/acpi/ddb1
  http://www.root.org/~nate/acpi/ddb2

I set your debug options in device.hints.
 
One interesting thing is that the oem sysctl node seems bogus:
   hint.acpi.0.oem=IBM   ??
where the ?'s are invalid characters like the happy face.

 BTW, what's model name?  Some ThinkPad's are blacklisted such as
 IBM 600E.  And may I add your ACPI data to our repo. (in Japan) ?

IBM T23.  Feel free to use the dsdt and/or asl however you wish.

  Here are the appropriate files...
http://www.root.org/~nate/acpi/ibm.asl
http://www.root.org/~nate/acpi/ibm.dsdt
http://www.root.org/~nate/acpi/ibm.dmesg  (from a working boot)

(Note that I renamed the .aml file to asl as shown above)

-Nate




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



Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Brooks Davis
On Fri, Oct 25, 2002 at 11:41:33AM -0700, Bakul Shah wrote:
 Until pppd is taught to create the interface if one doesn't
 exist, this information needs to be in /usr/src/UPDATING.

pppd doesn't need to be taught to create the interface.  Rather it needed
to learn to check for ppp support in a non-stupid way.  The following
patch should do it as well as making pppd do the right thing when
support isn't compiled in, but a module is available.  It should make
things work with a GENERIC kernel.

If someone who actually uses pppd could test it, perferably in both
sceneios, I'll see about getting it commited.

-- Brooks

Index: sys-bsd.c
===
RCS file: /usr/cvs/src/usr.sbin/pppd/sys-bsd.c,v
retrieving revision 1.18
diff -u -p -r1.18 sys-bsd.c
--- sys-bsd.c   17 Sep 2002 15:52:35 -  1.18
+++ sys-bsd.c   25 Oct 2002 19:30:20 -
 -44,6 +44,7  static char rcsid[] = $FreeBSD: src/usr
 #include sys/time.h
 #include sys/stat.h
 #include sys/param.h
+#include sys/module.h
 #ifdef NetBSD1_2
 #include util.h
 #endif
 -169,28 +170,24  sys_check_options()
 }
 
 /*
- * ppp_available - check whether the system has any ppp interfaces
- * (in fact we check whether we can do an ioctl on ppp0).
+ * ppp_available - check whether the system has the ppp module loaded
+ * or compiled in. If it doesn't try loading it before giving up.
  */
 int
 ppp_available()
 {
-int s, ok;
-struct ifreq ifr;
-extern char *no_ppp_msg;
+const char *modname = if_ppp;
+
+if (modfind(modname) != -1) {
+   printf(module is loaded\n);
+   return 1;
+}
 
-if ((s = socket(AF_INET, SOCK_DGRAM, 0))  0)
-   return 1;   /* can't tell */
+printf(trying to load ppp mode\n);
+if (kldload(modname) != -1)
+   return 1;
 
-strncpy(ifr.ifr_name, ppp0, sizeof (ifr.ifr_name));
-ok = ioctl(s, SIOCGIFFLAGS, (caddr_t) ifr) = 0;
-close(s);
-
-no_ppp_msg = \
-This system lacks kernel support for PPP.  To include PPP support\n\
-in the kernel, please follow the steps detailed in the README.bsd\n\
-file in the ppp-2.2 distribution.\n;
-return ok;
+return 0;
 }
 
 /*

-- 
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4



msg45221/pgp0.pgp
Description: PGP signature


Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Bruce Evans
On Fri, 25 Oct 2002, Bakul Shah wrote:

  On Fri, Oct 25, 2002 at 06:15:55PM +, Dave Evans wrote:
   Is anyone using pppd on CURRENT.  somewhere between may and October it
   seems to have broken.  My KERNEL is GENERIC, my sources are dated cvs
   -D2002-10-20, but I now get a message about needing facilities in the
   kernel. However, the kernel has many ppp entry points, I haven't
   modified GENERIC which loads the ppp device, I've tried loading modules
   with ppp in their name all to no avail.
 
  You need to create an interface first. Run ifconfig ppp create.

 Until pppd is taught to create the interface if one doesn't
 exist, this information needs to be in /usr/src/UPDATING.

The kernel side of ppp was changed to create 0 ppp interfaces by default.
This is incompatible with the user side of ppp, which determines if ppp
is in the kernel by checking if there is a ppp interface.  I use the
following low-quality work around:

%%%
Index: sys-bsd.c
===
RCS file: /home/ncvs/src/usr.sbin/pppd/sys-bsd.c,v
retrieving revision 1.18
diff -u -2 -r1.18 sys-bsd.c
--- sys-bsd.c   17 Sep 2002 15:52:35 -  1.18
+++ sys-bsd.c   17 Sep 2002 19:16:58 -
@@ -183,4 +183,19 @@
return 1;   /* can't tell */

+/*
+ * XXX interface doesn't exist until you look at it right.
+ * devfs me harder.
+ */
+{
+int fd, newdisc, olddisc;
+
+fd = open(/dev/cuaa1, O_RDWR);   /* XXX my tty hard-coded. */
+ioctl(fd, TIOCGETD, olddisc); /* XXX no error handling. */
+newdisc = PPPDISC;
+ioctl(fd, TIOCSETD, newdisc); /* XXX no error handling. */
+ioctl(fd, TIOCSETD, olddisc); /* XXX no error handling. */
+close(fd);
+}
+
 strncpy(ifr.ifr_name, ppp0, sizeof (ifr.ifr_name));
 ok = ioctl(s, SIOCGIFFLAGS, (caddr_t) ifr) = 0;
%%%

devfs is not really involved here.  The bug just belongs to the same
class of complications given by devfs.

Bruce


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



sparc64 tinderbox failure

2002-10-25 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== usr.sbin/sysinstall
/tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c: In function `dmenuOpen':
/tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c:291: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c:295: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c:299: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/usr.sbin/sysinstall/menus.c:1370: warning: initialization makes 
integer from pointer without a cast
disks.o: In function `diskPartitionWrite':
disks.o(.text+0x14b8): undefined reference to `Write_Disk'
wizard.o: In function `slice_wizard':
wizard.o(.text+0x5e4): undefined reference to `Write_Disk'
*** Error code 1

Stop in /tinderbox/sparc64/src/usr.sbin/sysinstall.
*** Error code 1

Stop in /tinderbox/sparc64/src/usr.sbin.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

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



HEADS UP: you need to install a new kernel before an installworld.

2002-10-25 Thread Peter Wemm
Due to sigaction(2) syscall number changes, doing a 'make installworld'
without having booted a new kernel would be rather messy.  For example, if
you tried to reboot with the old kernel, /sbin/init and /bin/sh would get a
signal and abort. That would be bad.

I've added an anti-foot-shooting device to Makefile.inc1 to try and prevent
disasters like this.

For folks using the *world/*kernel procedure, a reminder of the sequence
is probably in order:
 buildworld
 buildkernel
 installkernel
 reboot
 installworld
 reboot

You may prefer to avoid building world for a few days and use the newer
kernel on its own.  Once you've done an installworld, you cannot go back
to any previous kernel.old that you may have laying around.  For this
reason, you probably want to delay an installworld until you are comfortable
that your newer kernel builds are satisfactory.

options COMPAT_FREEBSD4 is necessary for running older 5.x binaries.
For now (an additional anti-foot-shooting measure), I've made it yell
loudly if you leave it out.  If you try hard enough (read the code), you
can turn it off if you really want and if you are really sure that you have
no more 4.x or old 5.x binaries around in /usr/local etc.

options COMPAT_43 is checked at compile time on the alpha now.  It is still
compulsory until somebody fixes longjmp in libc to use ucontext_t instead
of struct osigcontext.  This really needs to be done before 5.0 is
released.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5


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



Re: Coredump from pkg_add + analysis

2002-10-25 Thread Nate Lawson
On Tue, 24 Sep 2002, Nate Lawson wrote:
 There's a bit of a layering problem with the ftp/fetch semantics.  
 _fetch_close() is used to shutdown the connection (and handles reference
 counting but the connection caching is done at the ftp layer.  Either the
 connection cache should be moved to the fetch layer so open/close can deal
 with it properly (better) or the ftp layer needs to check for a ref count
 of 1 and invalidate the cache before closing it (worse).
 
 A lot of people would really really appreciate it if someone would choose
 an approach and fix this.
 
 -Nate

I committed the second approach in rev 1.83 of ftp.c.

-Nate


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



Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Terry Lambert
Brooks Davis wrote:
 pppd doesn't need to be taught to create the interface.  Rather it needed
 to learn to check for ppp support in a non-stupid way.  The following
 patch should do it as well as making pppd do the right thing when
 support isn't compiled in, but a module is available.  It should make
 things work with a GENERIC kernel.
 
 If someone who actually uses pppd could test it, perferably in both
 sceneios, I'll see about getting it commited.

Try running you program when the module is there, but fails to load.
You got rid of the failure message that it used to print.

-- Terry

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



Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Brooks Davis
On Fri, Oct 25, 2002 at 12:58:57PM -0700, Terry Lambert wrote:
 Brooks Davis wrote:
  pppd doesn't need to be taught to create the interface.  Rather it needed
  to learn to check for ppp support in a non-stupid way.  The following
  patch should do it as well as making pppd do the right thing when
  support isn't compiled in, but a module is available.  It should make
  things work with a GENERIC kernel.
  
  If someone who actually uses pppd could test it, perferably in both
  sceneios, I'll see about getting it commited.
 
 Try running you program when the module is there, but fails to load.
 You got rid of the failure message that it used to print.

No, it just let the default one be printed instead.  The one in the
function was just plain wrong and the default one is reasonable:

Sorry - this system lacks PPP kernel support

You either had to know what you were doing or cluelessly fail to follow
the exceptionaly simple instructions to build and install a
kernel+modules to get to that point, so a long winded message explaning
how to correct the problem isn't likely to be useful.  I suppose a
better message could be written, but I didn't see a point.

-- Brooks

-- 
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4



msg45227/pgp0.pgp
Description: PGP signature


Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Bruce Evans
On Fri, 25 Oct 2002, Brooks Davis wrote:

 On Fri, Oct 25, 2002 at 11:41:33AM -0700, Bakul Shah wrote:
  Until pppd is taught to create the interface if one doesn't
  exist, this information needs to be in /usr/src/UPDATING.

 pppd doesn't need to be taught to create the interface.  Rather it needed
 to learn to check for ppp support in a non-stupid way.  The following

Right.

 patch should do it as well as making pppd do the right thing when
 support isn't compiled in, but a module is available.  It should make
 things work with a GENERIC kernel.

I disagree with auto-loading of modules for anything, but especially in
setuid programs like pppd.

Bruce


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



Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Terry Lambert
Brooks Davis wrote:
   If someone who actually uses pppd could test it, perferably in both
   sceneios, I'll see about getting it commited.
 
  Try running you program when the module is there, but fails to load.
  You got rid of the failure message that it used to print.
 
 No, it just let the default one be printed instead.  The one in the
 function was just plain wrong and the default one is reasonable:
 
 Sorry - this system lacks PPP kernel support
 
 You either had to know what you were doing or cluelessly fail to follow
 the exceptionaly simple instructions to build and install a
 kernel+modules to get to that point, so a long winded message explaning
 how to correct the problem isn't likely to be useful.  I suppose a
 better message could be written, but I didn't see a point.

It's a moderately common case in -CURRENT, when kernel structure
sizes change, and you build a new kernel without new modules, and
a module refuses to load.  It's not technically correct.  The old
message might not be either, but at least it had you looking in
the right place.

The whole area is pretty messy, unfortunately.  8-(.  Your patch
is a definite improvement, though the lack of a message makes the
failure case harder to diagnose, unless you happen to know that
it only happens when the module fails to load.

Anyway, it's at least improvement enough to stop people who have
a matching ppp module, but forgot to load it, from complaining.

-- Terry

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



Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Terry Lambert
Bruce Evans wrote:
  patch should do it as well as making pppd do the right thing when
  support isn't compiled in, but a module is available.  It should make
  things work with a GENERIC kernel.
 
 I disagree with auto-loading of modules for anything, but especially in
 setuid programs like pppd.

It's really tempting to say that modules should be classified by the
services they can provide, and, barring them being disallowed, have
the kernel automatically load them when the services they export are
referenced, if they are not already loaded.

Module code is trusted code, even if the people who might want to
load modules into the kernel are not.

Really, the security association that establishes the trust needs
to trust the module code, not trust (or not trust) the user (IMO).

The bset way to do this, I think, is to add a seperate section to
the module image that can be used to provide this information to
the kernel.

A recent example in this regard was the aio routines, where if you
call the system call, the default for the system call not being
implemented is to signal (and, by the default behaviour, kill) the
process.  Only if you trapped the signal did the call return -1
with errno set to ENOSYS.  Arguably, it should have loaded the AIO
module, and just worked.

NB: The security issues that led to it being a module in the first
place are unlikely to be addressed at all, if they are not a threat
because they are in a module which is not loaded by default, which
is bad.

-- Terry

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