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

[Terry Lambert]

Bakul Shah wrote:
> 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).

Actually, this isn't an issue (I'm assuming that you want it to
be named "ppp").  What won't work is autoloading -- you'll get the
old module.  But if you preload, you can experiment with it fine;
it's a different issue if it's not an experiment, though...

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

Actually, it does.  The standard mount doesn't, but several of the
per-FS versions do this.

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

"All the way"?

In the limit, you want things to work without intervention.


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

Yes.  You are.  8-) 8-).


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

I already talked about this.  It's very easy to support.  You define
an elf section to use for attributes, and the kernel can examine it
and know ahead of time.  With devfs, you could even register a
device for it (in this case, registering an interface is even easier),
and then when it's referenced, effectively thunk the real one in place
of a loading stub that only knows the name.


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

The opposite one is "what it the administrator doesn't want calls
at 3 A.M. from idiot users?".  8-).


> > 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. 
> 
> I have used up my 2 cents many times over, so over and out!

It's a good point; the way you will win the argument is by providing
kernel autoloading code that makes the autoloading code in user apps
no longer necessary...

-- Terry

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

Re: 5.0 disklabel warnings against 4.7 disk

[Bruce Evans]

On Sat, 26 Oct 2002, John De Boskey wrote:

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

It's just another intentional incompatibility in GEOM.

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

Actually, only everything except the first 63 sectors is allocated to
the first slice.  This is shown by the offset of 63 for the partitions.
In 4.7 and other non-broken systems (e.g., -current without GEOM),
slice offsets are absolute (63 here) on the disk but the ioctl used
by disklabel(8) subtracts the offset of the 'c' partition for the slice
being looked at so that the offsets seen by disklabel(8) are slice-relative.
The corresponding ioctl implemented by GEOM doesn't subtract the offset
and disklabel(8) complains.  disklabel(8)'s error checking may have
been weakened a bit so that this is a warning and not an error.  You
would have to be careful writing back a label either way.

> An identical disk (ad4):
>
> ad4: 95396MB  [193821/16/63] at ata2-master UDMA100
> ad6: 95396MB  [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).

Labels created under -current with GEOM have slice-relative offsets and there
is no conversion by the ioctl, so disklabel(8) is happy.  The labels are
just incompatible, so they don't work under 4.7 or -current without GEOM.

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

The end result of the incompatibilities is that you can't share labeled
slices between 4.7, etc. and -current if the labels were created under
-current.  To share them, label them on a non-broken system and put up
with the warnings from the New World Order.

Bruce


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

-current buildworld breakage

[Yamada Ken Takeshi]

  I have an error for a week and cannot make buildworld.
Where can I find "panic" other than real panic?

===> sbin/gbde
 :  :  :  :
cc -O -pipe -mcpu=pentiumpro -I/usr/src/sbin/gbde/../../sys   -Werror -Wall 
-Wno-format-y2k -Wno-uninitialized  -c template.c
cc1: warnings being treated as errors
/usr/src/sys/crypto/rijndael/rijndael-api-fst.c: In function `rijndael_padEncrypt':
/usr/src/sys/crypto/rijndael/rijndael-api-fst.c:222: warning: implicit declaration of 
function `panic'
*** Error code 1



msg45368/pgp0.pgp
Description: PGP signature

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

[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: libgtop port and v_tag changes

[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

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

[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

ia64 tinderbox failure

[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

5.0 disklabel warnings against 4.7 disk

[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  [193821/16/63] at ata2-master UDMA100
ad6: 95396MB  [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

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

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

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

For the painfully shy 13729

[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

[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

Re: Local DNS lookup by sshd?

[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

Local DNS lookup by sshd?

[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: pppd not working on latest current 2002-10-20

[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

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

[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

[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

sparc64 tinderbox failure

[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

[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

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

[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: Installing from CD and MAKEDEV

[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

[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: pppd not working on latest current 2002-10-20

[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 
 #include 
 #include 
+#include 
 #ifdef NetBSD1_2
 #include 
 #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

[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: alpha tinderbox failure

[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

[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

alpha tinderbox failure

[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

[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

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

[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

[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

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

[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

[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

[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

[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: Coredump from pkg_add + analysis

[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

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

[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

sparc64 tinderbox failure

[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: pppd not working on latest current 2002-10-20

[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

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

[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 
 #include 
 #include 
+#include 
 #ifdef NetBSD1_2
 #include 
 #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: ACPI errors and then panic

[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

[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: kernel broken? (devfs maybe?)

[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

[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: df problems ?

[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

pppd not working on latest current 2002-10-20

[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: libgtop port and v_tag changes

[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

Re: libgtop port and v_tag changes

[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

ia64 tinderbox failure

[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: mozilla-devel problems

[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

Re: mozilla-devel problems

[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: Floating point problems

[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: libgtop port and v_tag changes

[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: Installing from CD and MAKEDEV

[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: alpha tinderbox failure

[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

5.0-20021025-CURRENT snapshot

[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: Floating point problems

[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

ia64 tinderbox failure

[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

[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

Re: 5.0-RUSH: -current install testers wanted!

[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: mozilla-devel problems

[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

alpha tinderbox failure

[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

[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

could sleep with "pcm0:play:1" locked

[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

[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

Re: mozilla-devel problems

[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: Lack of real long double support

[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

[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 (was Re: libstdc++ does notcontain fabsl symbol)

[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 
> 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
>  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: how2 enable pppd support on current

[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: Installing from CD and MAKEDEV

[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: mi_switch deadlock?

[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: kernel broken? (devfs maybe?)

[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: Installing from CD and MAKEDEV

[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

sparc64 tinderbox failure

[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

how2 enable pppd support on current

[suken woo]

at title:
best regards


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

Re: sparc64 tinderbox failure

[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

gcc 3.2.1 optimization bug with BitchX

[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: Lack of real long double support

[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

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

[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: Installworld fails building Current from 4.7-R

[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: Building -CURRENT with 4.5-RELEASE

[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