Re: pppd not working on latest current 2002-10-20
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
On Fri, Oct 25, 2002 at 02:16:32PM -0700, Bakul Shah wrote: Until pppd is taught to create the interface if one doesn't exist, this information needs to be in /usr/src/UPDATING. pppd doesn't need to be taught to create the interface. Rather it needed to learn to check for ppp support in a non-stupid way. The following patch should do it as well as making pppd do the right thing when support isn't compiled in, but a module is available. It should make things work with a GENERIC kernel. `device ppp' was already defined in my kernel config file so there was no need to kldload if_ppp. But I had to run `ifconfig create ppp' to make things work. RTF modfind. The modfind check verifies that ppp is in your kernel one way or another. It IS unnecessicary to create the ppp0 interface because adding a ppp line discipline does that for you. The check for ppp0 was always wrong because you might not get that interface. I don't much like auto kldloading modules from suid programs. I'm waiting on more opinions on this. It's easy enough to remove if that's the concensous. FWIW, ifconfig does exacly this before trying to do anything with any interface. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg45344/pgp0.pgp Description: PGP signature
alpha tinderbox failure
-- 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
On Fri, Oct 25, 2002 at 01:43:57PM -0700, Terry Lambert wrote: It's a moderately common case in -CURRENT, when kernel structure sizes change, and you build a new kernel without new modules, and a module refuses to load. It's not technically correct. The old message might not be either, but at least it had you looking in the right place. Current users are supposed to have enough of a clue to figure this out. Other users are supposed to follow the instructions in UPDATING which preclude this problem. The version of pppd built with my patch basicly keeps the only part of the old message was correct (telling you that you don't have kernel support). The second sentence of the description is entierly unhelpful since README.bsd isn't anywhere in our source tree. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg45346/pgp0.pgp Description: PGP signature
Re: alpha tinderbox failure
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 wrote: On Fri, Oct 25, 2002 at 01:43:57PM -0700, Terry Lambert wrote: It's a moderately common case in -CURRENT, when kernel structure sizes change, and you build a new kernel without new modules, and a module refuses to load. It's not technically correct. The old message might not be either, but at least it had you looking in the right place. Current users are supposed to have enough of a clue to figure this out. Other users are supposed to follow the instructions in UPDATING which preclude this problem. The version of pppd built with my patch basicly keeps the only part of the old message was correct (telling you that you don't have kernel support). The second sentence of the description is entierly unhelpful since README.bsd isn't anywhere in our source tree. Heh. You might as well just exit, and assume that whoever sees it not running should have enough of a clue to know why it exited. 8-). The only failure mode that gets to the end there is the module not loading, and the error is not indicative of the load failure, was all I was saying. Like I said, it's an OK change (at least if it's OK for ifconfig and mount to load modules, instead of the demand causing the kernel to load them), it's just a bit light on the error message. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pppd not working on latest current 2002-10-20
On Fri, Oct 25, 2002 at 12:35:22PM -0700, Brooks Davis wrote:
If someone who actually uses pppd could test it, perferably in both
sceneios, I'll see about getting it commited.
Here's a new patch that gives the user more of a hint at how to add PPP
support and only loads the module if they are actully root. How's this
look?
-- Brooks
Index: sys-bsd.c
===
RCS file: /usr/cvs/src/usr.sbin/pppd/sys-bsd.c,v
retrieving revision 1.18
diff -u -p -r1.18 sys-bsd.c
--- sys-bsd.c 17 Sep 2002 15:52:35 - 1.18
+++ sys-bsd.c 25 Oct 2002 22:21:47 -
-44,6 +44,7 static char rcsid[] = $FreeBSD: src/usr
#include sys/time.h
#include sys/stat.h
#include sys/param.h
+#include sys/module.h
#ifdef NetBSD1_2
#include util.h
#endif
-169,28 +170,29 sys_check_options()
}
/*
- * ppp_available - check whether the system has any ppp interfaces
- * (in fact we check whether we can do an ioctl on ppp0).
+ * ppp_available - check whether the system has the ppp module loaded
+ * or compiled in. If it doesn't, and we're actually root (not just SUID
+ * root) try loading it before giving up.
*/
int
ppp_available()
{
-int s, ok;
-struct ifreq ifr;
+const char *modname = if_ppp;
extern char *no_ppp_msg;
-if ((s = socket(AF_INET, SOCK_DGRAM, 0)) 0)
- return 1; /* can't tell */
+if (modfind(modname) != -1) {
+ return 1;
+}
-strncpy(ifr.ifr_name, ppp0, sizeof (ifr.ifr_name));
-ok = ioctl(s, SIOCGIFFLAGS, (caddr_t) ifr) = 0;
-close(s);
+if (getuid() == 0 kldload(modname) != -1)
+ return 1;
no_ppp_msg = \
This system lacks kernel support for PPP. To include PPP support\n\
-in the kernel, please follow the steps detailed in the README.bsd\n\
-file in the ppp-2.2 distribution.\n;
-return ok;
+in the kernel, please add \device ppp\ to your kernel config or \n\
+load the if_ppp module.\n;
+
+return 0;
}
/*
--
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
msg45349/pgp0.pgp
Description: PGP signature
Re: pppd not working on latest current 2002-10-20
Brooks Davis wrote: On Fri, Oct 25, 2002 at 12:35:22PM -0700, Brooks Davis wrote: If someone who actually uses pppd could test it, perferably in both sceneios, I'll see about getting it commited. Here's a new patch that gives the user more of a hint at how to add PPP support and only loads the module if they are actully root. How's this look? Totally cool. The other one was good enough, too (but you foolishly asked for comments... 8-) 8-)). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Installing from CD and MAKEDEV
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
Here's a new patch that gives the user more of a hint at how to add PPP support and only loads the module if they are actully root. How's this look? I still don't like it. How to explain I don't think it is pppd's responsibility to muck with modules. It is like mount kldloading a disk driver module. Neither program has any business guessing which module name goes with which device/feature. What if I want to run ppp over ethernet over atm? I know you can't do this today but in general the trend should be to make protocol modules more flexible not less. Hardwiring module names is analogous to making a function non-reentrant. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pppd not working on latest current 2002-10-20
On Fri, Oct 25, 2002 at 05:34:15PM -0700, Bakul Shah wrote: Here's a new patch that gives the user more of a hint at how to add PPP support and only loads the module if they are actully root. How's this look? I still don't like it. How to explain I don't think it is pppd's responsibility to muck with modules. It is like mount kldloading a disk driver module. Neither program has any business guessing which module name goes with which device/feature. What if I want to run ppp over ethernet over atm? I know you can't do this today but in general the trend should be to make protocol modules more flexible not less. Hardwiring module names is analogous to making a function non-reentrant. This isn't going to have an effect on the ability to use kernel ppp for other things. The tty orientation of pppd and the outdated, unmodular design on ppp(4) have taken care of that. This patch gives people the functionality they want (pppd just working) without any major entanglements (the whole function is 20 lines). If someone wants to make pppd work on arbitrary devices we can deal with that when it happens and I frankly doubt it's ever going to since we've got netgraph to do that with. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg45353/pgp0.pgp Description: PGP signature
sparc64 tinderbox failure
-- 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 wrote: This isn't going to have an effect on the ability to use kernel ppp for other things. The tty orientation of pppd and the outdated, unmodular design on ppp(4) have taken care of that. This patch gives people the functionality they want (pppd just working) without any major entanglements (the whole function is 20 lines). If someone wants to make pppd work on arbitrary devices we can deal with that when it happens and I frankly doubt it's ever going to since we've got netgraph to do that with. Depending on the value of sysctl kern.module_path, if the if_ppp module does not exist, and one of the path components is writeable, then this would permit you to abuse the pppd to load arbitrary modules into the kernel. So I understand Bakul's complaint. But by the same token, mount and ifconfig have the same problems; on the other hand, unlike pppd, they are not suid root. On general principles, loading modules with commands, rather than the kernel doing it automatically, is a bad idea. But FreeBSD already does this in a number of commands, because it lacks a certralized feature demand support facility. You could also make security arguments on the basis of what if the administrator didn't want the machine to be able to be configured for PPP -- on purpose? As long as you control the module path, I don't think this is a real risk. There is such a thing as being too paranoid. As it is, this patch does nothing worse than add to an existing mess brought about by not having an integrated demand-load facility; I don't see this as a problem... if there;s a problem, fix it first in mount and ifconfig, before you complain about this patch. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pppd not working on latest current 2002-10-20
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
On Fri, Oct 25, 2002 at 07:20:33PM -0700, Brooks Davis wrote: On Fri, Oct 25, 2002 at 07:05:57PM -0700, Terry Lambert wrote: Depending on the value of sysctl kern.module_path, if the if_ppp module does not exist, and one of the path components is writeable, then this would permit you to abuse the pppd to load arbitrary modules into the kernel. So I understand Bakul's complaint. But by the same token, mount and ifconfig have the same problems; on the other hand, unlike pppd, they are not suid root. Note the getuid() check to prevent exactly this problem. If you want to keep root from loading modules, that's a kernel problem. Oops, wrong problem. If this one exists, it's a bug in kldload. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg45357/pgp0.pgp Description: PGP signature
Local DNS lookup by sshd?
Hi, When logging into a current 5.0 system via ssh, I see the following written to the system console (the 'xxx's are my whiteout): ... kernel: Connection attempt to UDP xxx.58.184.35:53 from xxx.58.184.35:49253 ... kernel: Connection attempt to UDP xxx.58.184.35:53 from xxx.58.184.35:49254 ... kernel: Connection attempt to UDP xxx.58.184.35:53 from xxx.58.184.35:49255 ... kernel: Connection attempt to UDP xxx.58.184.35:53 from xxx.58.184.35:49256 Basically, it looks like it is trying to talk to a DNS on the localhost. However, I do not have DNS running. I do not have localhost listed in /etc/resolv.conf. /etc/nsswitch.conf lists 'hosts: files dns' and putting my ssh origination id in /etc/hosts has no effect. It appears to be related to code in canohost.c. Before I start debugging, I thought I'd ask if anyone knew if there is a reason for this behaviour, or where it might be coming from (specifically). Comments Welcome. -John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Local DNS lookup by sshd?
John De Boskey wrote: Hi, When logging into a current 5.0 system via ssh, I see the following written to the system console (the 'xxx's are my whiteout): ... kernel: Connection attempt to UDP xxx.58.184.35:53 from xxx.58.184.35:492 53 ... kernel: Connection attempt to UDP xxx.58.184.35:53 from xxx.58.184.35:492 54 ... kernel: Connection attempt to UDP xxx.58.184.35:53 from xxx.58.184.35:492 55 ... kernel: Connection attempt to UDP xxx.58.184.35:53 from xxx.58.184.35:492 56 Basically, it looks like it is trying to talk to a DNS on the localhost. However, I do not have DNS running. I do not have localhost listed in /etc/resolv.conf. /etc/nsswitch.conf lists 'hosts: files dns' and putting my ssh origination id in /etc/hosts has no effect. It appears to be related to code in canohost.c. Before I start debugging, I thought I'd ask if anyone knew if there is a reason for this behaviour, or where it might be coming from (specifically). Are you using privsep? If so, I think this is expected. The unpriviliged side runs in a chroot under /var/empty. This means, that it cannot see any /etc/nsswitch.conf and cannot see any /etc/resolv.conf or /etc/hosts. And the resolver client library defaults querying on the first interface, and in your case it used localhost. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: pppd not working on latest current 2002-10-20
From: Terry Lambert [mailto:tlambert2;mindspring.com] Brooks Davis wrote: This isn't going to have an effect on the ability to use kernel ppp for other things. The tty orientation of pppd and the outdated, unmodular design on ppp(4) have taken care of that. This patch gives people the functionality they want (pppd just working) without any major entanglements (the whole function is 20 lines). If someone wants to make pppd work on arbitrary devices we can deal with that when it happens and I frankly doubt it's ever going to since we've got netgraph to do that with. Depending on the value of sysctl kern.module_path, if the if_ppp module does not exist, and one of the path components is writeable, then this would permit you to abuse the pppd to load arbitrary modules into the kernel. So I understand Bakul's complaint. But by the same token, mount and ifconfig have the same problems; on the other hand, unlike pppd, they are not suid root. On general principles, loading modules with commands, rather than the kernel doing it automatically, is a bad idea. But FreeBSD already does this in a number of commands, because it lacks a certralized feature demand support facility. i'm sorry for jumping in the middle of the thread, but long time ago i wrote something called kerneld. it is still available on SourceForge (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/kerneld/) the idea was very simple: 1) create a char device kd 2) add hooks inside kernel, so whenever filesystem, interface or char device is requested but not present send message to the kd device. 3) user space daemon that listens on /dev/kd for the events and loads appropriate module (as configured) i send RFC email to -hackers, but i got so many negative replies so i dropped the whole idea :) You could also make security arguments on the basis of what if the administrator didn't want the machine to be able to be configured for PPP -- on purpose? yes. i got the similar arguments: i do not want any smart-ass daemon load and unload modules. i want to do it myself As long as you control the module path, I don't think this is a real risk. There is such a thing as being too paranoid. As it is, this patch does nothing worse than add to an existing mess brought about by not having an integrated demand-load facility; I don't see this as a problem... if there;s a problem, fix it first in mount and ifconfig, before you complain about this patch. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
For the painfully shy 13729
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
Brooks Davis wrote: This isn't going to have an effect on the ability to use kernel ppp for other things. The tty orientation of pppd and the outdated, unmodular design on ppp(4) have taken care of that. This patch gives people the functionality they want (pppd just working) without any major entanglements (the whole function is 20 lines). I meant reuse of pppd. From what I remember, pppd does a lot of the control plane stuff (IPCP, CHAP...) which is useful for other ppp-over-foo combinations. In general a different module or set of modules may implement ppp-over-foo so hardwiring the module name in pppd is not a good idea. Now you are probably thinking: In that case why not just default to if_ppp and otherwise use an environment variable?. This would add complexity and another potential security hole. If someone wants to make pppd work on arbitrary devices we can deal with that when it happens and I frankly doubt it's ever going to since we've got netgraph to do that with. Existance of an alternative is not an argument in favor of allowing something to rot since doing so limits your flexibility. Terry writes: Depending on the value of sysctl kern.module_path, if the if_ppp module does not exist, and one of the path components is writeable, then this would permit you to abuse the pppd to load arbitrary modules into the kernel. Thank you for explicating the security argument! I'll also point out that hardwiring module names makes it harder to experiment with replacement modules (i.e. I may want to develop if_super_duper_ppp). But by the same token, mount and ifconfig have the same problems; on the other hand, unlike pppd, they are not suid root. AFAIK mount does no autoloading (i was using it as another place where one might be tempted to use autoloading). In general any tool (command) that relies on a resource or feature can have the same problem of the resource not existing. Just how far does one go to discover/autoload resources? Should we try to fetch it from a trusted repository? Should we try to compile it if we have the sources? It is a slipper slope. A new programmer next year will assume all the old programmers were fools and to him it will be obvious the module sources fetched afresh and compiled. Okay, I am exaggerating. On general principles, loading modules with commands, rather than the kernel doing it automatically, is a bad idea. But FreeBSD already does this in a number of commands, because it lacks a certralized feature demand support facility. Another area for endless debating:-) But don't worry, I'll stop soon! If only the kernel is allowed to load them on demand, there needs to be a way for modules to declare the feature-set they provide and for the kernel to follow administrative policies while autoloading them. You could also make security arguments on the basis of what if the administrator didn't want the machine to be able to be configured for PPP -- on purpose? This is a policy argument. Thanks for bringing that up! As it is, this patch does nothing worse than add to an existing mess brought about by not having an integrated demand-load facility; I don't see this as a problem... if there;s a problem, fix it first in mount and ifconfig, before you complain about this patch. It adds needless complexity. In any case, complain is too strong a word! I just pointed out something that I didn't like based on the principles I try to follow when writing software. Consider it in the leading a horse to water category:-) If the horse thinks it is just a mirage, that too is fine with me! We can argue about that too. ducks I have used up my 2 cents many times over, so over and out! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5.0 disklabel warnings against 4.7 disk
Hi, I've (re)scanned my -current folder for issues related to the following but didn't see a good match. Pointing out my blindness is allowed if this was discussed... I have a system onto which I installed a 4.7-RC a couple of weeks ago. I then upgraded that newly installed system to -current. After the upgrade, disklabel now complains about every disk in the system, for example: # disklabel -r ad6s1 # /dev/ad6s1c: type: unknown disk: amnesiac label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 193820 sectors/unit: 195371505 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 195371505 634.2BSD 2048 16384 28512 # (Cyl.0*- 193820*) c: 195371505 63unused0 0# (Cyl.0*- 193820*) partition a: partition extends past end of unit partition c: partition extends past end of unit Warning, partition c doesn't start at 0! Warning, An incorrect partition c may cause problems for standard system utilities # This is an fdisk'd drive, with the entire disk allocated to the 1st slice. An identical disk (ad4): ad4: 95396MB WDC WD1000JB-32CWE0 [193821/16/63] at ata2-master UDMA100 ad6: 95396MB WDC WD1000JB-32CWE0 [193821/16/63] at ata3-master UDMA100 which I then fdisk and disklabel under -current shows up as: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 1953715050unused0 0# (Cyl.0 - 193820*) The only difference being the offset of 0 (and lack of warning msgs). Both systems come up with the same disk size, but the offsets not matching seems to be a problem. An older 4.7 pre-release system from Sep 16 creates the 'c' slice with an offset of 0. I don't think this is something I did wrong. Any thoughts, comments, or pointy hats are welcome. Thanks, John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ia64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Fri Oct 25 22:01:25 PDT 2002 -- === xe ./aicasm: 877 instructions used /home/tinderbox/ia64/src/sys/kern/kern_sig.c:77:2: #error You *really* want COMPAT_FREEBSD4 on -current for a while mkdep: compile failed *** Error code 1 Stop in /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/sys/GENERIC. *** Error code 1 Stop in /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/sys/GENERIC. *** Error code 1 Stop in /home/tinderbox/ia64/src. *** Error code 1 Stop in /home/tinderbox/ia64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
/usr/src/sys/netinet/udp_usrreq.c:290
When booting my system, I get the following after samba-2.2.6 starts: acquiring duplicate lock of same type: inp 1st inp @ /usr/src/sys/netinet/udp_usrreq.c:290 2nd inp @ /usr/src/sys/netinet/udp_usrreq.c:290 This is with a kernel from Fri Oct 25 23:27:50 CDT 2002 (about an hour ago). it looks to me that under some conditions, inp isn't being unlocked in the LIST_FOREACH(inp, udb, inp_list) loop. It is possible I am wrong, though... -- Sean Kelly | PGP KeyID: 77042C7B [EMAIL PROTECTED] | http://www.zombie.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libgtop port and v_tag changes
On Fri, 2002-10-25 at 14:15, John Baldwin wrote:
Well, here's the thing. If libgtop is intended to be used only with live
kernels then it might be a better idea to use xvnode's that you get with
from the kernel. Alternatively, you could grab the inode and dev number
the same way the sysctl handler does:
switch (vp-v_type) {
case VREG:
case VDIR:
case VLNK:
xvn[n].xv_dev = vp-v_cachedfs;
xvn[n].xv_ino = vp-v_cachedid;
i.e., you could look at those members of struct vnode instead of trying
to dig into the details of a UFS inode structure in v_data. This
would remove the need to look at v_tag at all.
I can certainly do it this way, but would it be equivalent to the
existing code? It doesn't seem like it would be. At least using the
kvm_read method, we get similar behavior for both -stable and -CURRENT.
Correct me if I'm wrong, but the current code is looking at UFS inodes,
where as you're suggesting to look at generic vnodes.
Joe
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
--
PGP Key : http://www.marcuscom.com/pgp.asc
signature.asc
Description: This is a digitally signed message part
Re: /usr/src/sys/netinet/udp_usrreq.c:290
* De: Sean Kelly [EMAIL PROTECTED] [ Data: 2002-10-25 ] [ Subjecte: /usr/src/sys/netinet/udp_usrreq.c:290 ] When booting my system, I get the following after samba-2.2.6 starts: acquiring duplicate lock of same type: inp 1st inp @ /usr/src/sys/netinet/udp_usrreq.c:290 2nd inp @ /usr/src/sys/netinet/udp_usrreq.c:290 This is with a kernel from Fri Oct 25 23:27:50 CDT 2002 (about an hour ago). I've been seeing this for about two months, but the box I'd been seeing it on (the Samba box) was too unreliable to ever get logged in and get the info, once it was updated to -current, and I didn't get it transcribed as I remember telling someone how to reproduce it, but I don't know if they ever looked into it. Thanks, juli. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: is src/UPDATING up to date
On 2002-10-25 07:28 +, Mathieu Arnold wrote: Hi I was twiddling with my yesterday's current, I was trying to make release to see how things were going, and I saw at the top of UPDATING that : In addition, IDE write caching is currently disabled by default due to on-going concerns about disk write order and file system integrity. Re-enabling write caching can substantially improve performance. This part of the performance disclaimer has been untrue for a while now. It is once again enabled by default. I looked at ata(4), told me about hw.ata.wc, which was supposed to be enabled by default, and it was, so, my question is, is the comment above still true, and how do I enable write cache if it is, if it's not true any more, maybe it should be removed. As stated, it's untrue. You can check the status of write caching by using the sysctl(8) facility. You're looking for hw.ata.wc. It'd probably be a good idea for someone to nuke that paragraph... -- Munish Chopra To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lack of real long double support
In message: [EMAIL PROTECTED] Loren James Rittle [EMAIL PROTECTED] writes: : Yet, the FP hardware is actually configured by default to provide : `long double' as: : : #define LDBL_MANT_DIG 53 : #define LDBL_MIN_EXP(-16381) : #define LDBL_MAX_EXP16384 : : Indeed, FP code using long double generated by gcc 2.95.X, installed : as the FreeBSD 4 system compiler, uses the full exponent range of : -16381 to 16384. However, printf(), etc loses on that exponent range : and reports Inf. I suspect this is why the system header misreports : the FP hardware, thus the header describes the largest printable long : double value, not the largest that could be held in a calculation. I have patches to fix these constants, but not to fix printf, and co, to really support the full precision of long double. Even NetBSD doesn't do that. : Anyways, two questions for FreeBSD maintainers. How should gcc, as : provided from the FSF, describe the long double FP format for : FreeBSD/i386 4.x? Shall we assume that no changes for FreeBSD 5.x : will occur? No. You should assume that for i386, at least, that long double will have the right LDBL_ constants. I've had them in my local tree for about 3 months now and just haven't found the time to commit to -current. I'll find the time right now. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libgtop port and v_tag changes
On 24 Oct 2002, Joe Marcus Clarke wrote: I committed my patch to libgtop and libgtop2 a while ago. It should work on both -CURRENT, not so -CURRENT, and -stable. Checkout patch-ah in libgtop/files. Works like a champ on -CURRENT from Monday. Thanks for taking care of that. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Building -CURRENT with 4.5-RELEASE
In message: [EMAIL PROTECTED] Tim Kientzle [EMAIL PROTECTED] writes: : On Tue, Oct 22, 2002 at 11:52:11PM +0200, Gerhard H=E4ring wrote: : : make installworld dumps core at installing passwd (4.5-RELEASE). : : : Brooks Davis: : : Are you running a current kernel at this point? If you aren't it's safe : to say it won't work. : : The directions in UPDATING leave you running : an OLD kernel after rebooting into single-user. : (Installkernel puts the kernel in the new location, : but the old boot loader is still on disk, so it : loads the kernel from the old location.) If : a new kernel is required at this point, then : UPDATING is wrong or installkernel is wrong. You are correct about this. I'll update it to include installing the new bootblocks as well, if that isn't already in there for the 4.x - 5.0 upgrade path. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Re: kernel broken? (devfs maybe?)
yep that fixes it.. On Thu, 24 Oct 2002, Andrew Gallatin wrote: Try backing out phk's src/sys/kern/vfs_subr.c 1.416 Does that help? Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lack of real long double support
In message: [EMAIL PROTECTED] M. Warner Losh [EMAIL PROTECTED] writes: : : Anyways, two questions for FreeBSD maintainers. How should gcc, as : : provided from the FSF, describe the long double FP format for : : FreeBSD/i386 4.x? Shall we assume that no changes for FreeBSD 5.x : : will occur? : : No. You should assume that for i386, at least, that long double will : have the right LDBL_ constants. I've had them in my local tree for : about 3 months now and just haven't found the time to commit to : -current. I'll find the time right now. I've committed the fix to the tree. NetBSD uses these numbers, and I've been using these numbers on a large number of systems that we maintain at timing solutions (they were added to our local tree prior to the 4.5 release, and we've built hundreds of ports since then w/o any issues). I've had them in my own personal p4 tree for 3 months with similar results. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
gcc 3.2.1 optimization bug with BitchX
I know I should be posting this to the gcc people or ports list, but so far all I and
the current BitchX coder (nuke) have seen this on is -CURRENT.
quoted from an e-mail with nuke:
Program received signal SIGSEGV, Segmentation fault.
0x0804b0f1 in aliascmd (command=0x813ebc8 0,
args=0xbfbf735e ;@ plistf = 5;^on ^cdcc_prepack * {fix.cdcc $0 $1
\037[\037cdcc\037]\037 \002$[-2]3\002 file(s) offered\037-\037 /ctcp \002$N\002 cdcc
send #x for pack #x};^on ^cdcc_note { ;fix.cdcc $0 $1 $2-};^on ^cdcc_postpack *
{@ lsize = ..., subargs=0x0, helparg=0x8136e7b - Scripting command)
at alias.c:329
329 args++;
Seems to be a optimization bug with gcc 3.2.1.
Edit the Makefile to have -O in the CFLAGS instead of -O2 and
it works fine. We should probably report this to the FreeBSD
or gcc teams.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
On Thu, 24 Oct 2002, Andrew Gallatin wrote: Mike Barcroft writes: stage 4: building everything.. -- === usr.sbin/pkg_install/info cc1: warnings being treated as errors /tinderbox/sparc64/src/usr.sbin/pkg_install/info/show.c: In function `show_size': /tinderbox/sparc64/src/usr.sbin/pkg_install/info/show.c:239: warning: passing arg 1 of `getbsize' from incompatible pointer type *** Error code 1 I fixed this an hour or 2 ago when I hit it on my alpha. How long does a sparc64 buildworld take on reasonably priced hardware? Where resonable means = $1000 USD, used OK. I pointed out this breakage a day or two ago. The breakage has since been expanded by breaking most of the messengers, but but pkg_install until you hit it. The complete list of messages in usr/src is easy to find using grep. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
how2 enable pppd support on current
at title: best regards To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === usr.sbin/sysinstall /tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c: In function `dmenuOpen': /tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c:291: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c:295: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c:299: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/usr.sbin/sysinstall/menus.c:1370: warning: initialization makes integer from pointer without a cast disks.o: In function `diskPartitionWrite': disks.o(.text+0x14b8): undefined reference to `Write_Disk' wizard.o: In function `slice_wizard': wizard.o(.text+0x5e4): undefined reference to `Write_Disk' *** Error code 1 Stop in /tinderbox/sparc64/src/usr.sbin/sysinstall. *** Error code 1 Stop in /tinderbox/sparc64/src/usr.sbin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Installing from CD and MAKEDEV
At Thu, 24 Oct 2002 12:10:53 + (UTC), kuriyama wrote: I've created install CD with make iso.1 (with sources few hours before). I'm trying to install fresh current box with this CD. But I got MAKEDEV returned non-zero status dialog after extracting dists. It seems cd /dev; sh MAKEDEV all is failed at devfs environment. I found it. Phk changes in 1.297 of src/etc/Makefile not to install MAKEDEV by default. Options may be: (1) Back out 1.297. (2) Set MAKEDEV_INSTALL for install-media environment. (3) Drop non-devfs code from sysinstall (really???). -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel broken? (devfs maybe?)
Please try the rev 1.418 of vfs_subr.c db tr v_incr_usecount(c1d76cb8,,c037b472,863,cc34a92c) at v_incr_usecount+0x48vrele(c1d76cb8,c1c90a00,c036cc7a,6,100) at vrele+0xb0 addaliasu(c1d76cb8,402,c1cb6200,cc34a9c0,c1d73b00) at addaliasu+0x1ad devfs_allocv(c1d8f880,c1c90a00,cc34ac38,c0f26340,c01e6fe0) at devfs_allocv+0xee devfs_lookupx(cc34ab50,1,0,c0f26340,6) at devfs_lookupx+0x58f devfs_lookup(cc34ab50,c0f26340,0,c0f26340,c037b472) at devfs_lookup+0x4b lookup(cc34ac24,0,c037ad9a,a4,cc34abb8) at lookup+0x302 namei(cc34ac24,c01bb4bd,c03fbac0,1,c037264a) at namei+0x24e stat(c0f26340,cc34ad10,c039bed6,409,2) at stat+0x52 syscall(2f,2f,2f,8057e86,805b52f) at syscall+0x28e Xint0x80_syscall() at Xint0x80_syscall+0x1d -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mi_switch deadlock?
okay, any idea what i'm looking for then? something is locking the whole system up... On Thu, 24 Oct 2002, Julian Elischer wrote: On Thu, 24 Oct 2002, Lamont Granquist wrote: my -current box keeps freezing about every 24h. i broke into the kernel and forced a panic and found lots of processes stuck in mi_switch(). Most processes are actually in mi_switch that's the last think a process does before it is switched away from.. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Installing from CD and MAKEDEV
In message [EMAIL PROTECTED], Jun Kuriyama writes: At Thu, 24 Oct 2002 12:10:53 + (UTC), kuriyama wrote: I've created install CD with make iso.1 (with sources few hours before). I'm trying to install fresh current box with this CD. But I got MAKEDEV returned non-zero status dialog after extracting dists. It seems cd /dev; sh MAKEDEV all is failed at devfs environment. I found it. Phk changes in 1.297 of src/etc/Makefile not to install MAKEDEV by default. Options may be: (3) Drop non-devfs code from sysinstall (really???). This is the way we're going. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: how2 enable pppd support on current
÷ Fri, 25.10.2002, × 11:32, suken woo ÎÁÐÉÓÁÌ: at title: best regards assuming you have /boot/kernel/if_ppp.ko or compiled in ppp interface. # ifconfig ppp0 create To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Vladimir B. Grebenschikov [EMAIL PROTECTED] SWsoft Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lack of real long double support (was Re: libstdc++ does notcontain fabsl symbol)
On Thu, 24 Oct 2002, Loren James Rittle wrote:
... Anyways, that work exposed some issues.
...
It is easy to generate, with arithmetic, a long double value outside
the *exponent* range above no matter how the precision is set; it is
not truncated to Inf until it is actually cast to a double (as is
currently done just before a long double is printed with stdio). See
below for a program that demonstrates this behavior.
Yet, the FP hardware is actually configured by default to provide
`long double' as:
#define LDBL_MANT_DIG 53
I think you mean 64 (the hardware default).
No sir, I did mean as configured in the system startup code, it is
forced to 53-bits (that choice affects long double as well as double).
But there are no IEEE control bits to limit the size of the exponent
field, are there? Thus, the following describes the exact size of the
HW's exponent field of a long double as configured by default:
#define LDBL_MIN_EXP(-16381)
#define LDBL_MAX_EXP16384
gcc can't actually support the full range, since it doesn't control
the runtime environement (it could issue a fninit before main() to
change the default, but it shouldn't and doesn't). The exponent
range is lost long before printf() is reached. E.g.,
long double x= DBL_MAX;
long double y = 2 * x;
gives +Inf for y since the result is doesn't fit in 53-bit precision.
As you know, the selection of maximum precision is orthogonal to the
number of bits used for the exponent.
I do wish you were correct. Have you looked at the raw memory of y?
It is *not* the bit pattern for +Inf. If y were +Inf, then based on
the properties of IEEE math, the following would report Inf not
DBL_MAX/2:
Oops. I did look at the bits, but I looked more closely at gdb's display
of the value which is broken (it says +inf). Apparently gdb uses the
host's FP too much.
#include float.h
int main (void)
{
long double x= LDBL_MAX; // Same as DBL_MAX in current float.h
long double y = 2e100 * x; // If LDBL_MAX was correct, we should latch Inf.
long double z = y / 4e100;
printf (%Lg\n, z);
}
It does, in fact, report DBL_MAX/2 with the system compiler on FreeBSD
4. FYI, I reviewed the generated code to ensure it was using run-time
calculations not compile-time calculations. I'd call that a rather
easy time getting a normalized long double much larger than
LDBL_MAX/DBL_MAX. This test alone proves in my mind that the
float.h system header for i386 is itself wrong.
Yes, this example is as convincing as examining the (right :) bits.
The system header correctly reports this default precision. Any header
genrated by the gcc build should be no different, since the build should
run in the target environment.
I agree that the precision setting in the system header is fine. The
size of the exponent field is buggy. I held the opinion you have but
while trying to convince RTH (the guy that rewrote gcc FP support), I
did enough research that also leads me to think that it is the header
itself which is buggy.
If you really want, I can tell RTH that FreeBSD/i386 absolutely wants
`long double' to be:
53 mantissa bits
1024 max exponent
No need. I prefer to keep the 53-bit precision for now, but fix the
exponents. Hopefully the precision won't be hard-coded into gcc in such
a way as to completely break changing the precision at runtime. I think
it should affect (only) constant folding. The issues are very similar
to the ones with changing the rounding mode at runtime (C99 compilers
shouldn't do constant folding in #pragma STDC FENV_ACCESS ON sections
if the correct result might depend on the FP environment).
It should use whatever is the default format for the host environment,
It still has enquire.c for doing this automatically. [...]
I fear I didn't explain clearly enough. enquire.c is completely
*gone* in gcc 3.3. This is why gcc needs to fully understand the
exact FP default configuration. As you noted, enquire.c was buggy.
Ah. I was a little surprised to find it still in 3.2. It is not so
much buggy as dysfunctional in a cross compiler. It has to run on the
target somehow to work.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: mozilla-devel problems
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
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
According to Terry Lambert: This looks similar to a well known problem that could occur with nominally proportional spacing fonts in X programs that incorrectly assumed monospacing for characters, and also on nominally fixed I just made an experience. I logged in on my STABLE machine coming from the CURRENT machine (so any X app will use the fonts on the CURRENT machine) and ran mozilla. The display is *fine*. So a STABLE mozilla displaying on a CURRENT machine is fine. I don't understand. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla-devel problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It was brought to my attention today by erk! that the way to solve the problem is to remove the mozilla-fonts package. It worked for me... I'm investigating why this is so. - -Adam - -- Adam Weinberger [EMAIL PROTECTED] [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQE9uQ+qo8KM2ULHQ/0RAjvqAKDLH1FozZMnKzkLHDTm4f6+Bhez0QCfSjlC CrftWKiNQkD4uZv04zUBhHc= =MSR7 -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
could sleep with pcm0:play:1 locked
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
Ollivier Robert wrote: According to Terry Lambert: This looks similar to a well known problem that could occur with nominally proportional spacing fonts in X programs that incorrectly assumed monospacing for characters, and also on nominally fixed I just made an experience. I logged in on my STABLE machine coming from the CURRENT machine (so any X app will use the fonts on the CURRENT machine) and ran mozilla. The display is *fine*. So a STABLE mozilla displaying on a CURRENT machine is fine. I don't understand. So the X server was running on your -CURRENT machine, but the application was running on your -STABLE machine? I think this is because on -STABLE, Mozilla compiles without the extra font stuff by default, doesn't it? THat was mentioned in an earlier message by someone else. Can you copy over the code as configured on -CURRENT to the -STABLE machine, so it compiles and links everything as if it were running on a -CURRENT machine? E.g. verify your implication that it's the compiler or the libraries specific to the -CURRENT machine, rather than a diffirence in the environment sensed by configure, etc.? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- 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
According to Adam Weinberger: It was brought to my attention today by erk! that the way to solve the problem is to remove the mozilla-fonts package. It worked for me... I'm investigating why this is so. Works for me too. Thanks a lot ! -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
On Tue, Oct 22, 2002 at 07:53:38PM -0700, Juli Mallett wrote: peter@ has been working busily in a Perforce branch to fix a lot of crap and it's by no means a small amount of work that he's done so far, especially taking into account the amount of testing and debugging he seems to be doing. It's the 'peter_sigfix' branch, I think. Great. Now where's the docu on this whole Perforce repository that everyone's so hot about? And what parts of what do I need? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Floating point problems
* De: Bruce Evans [EMAIL PROTECTED] [ Data: 2002-10-24 ] [ Subjecte: Re: Floating point problems ] Thanks. This makes the main bug clear. The PCB_NPXINITDONE bit in the state was not being restored. This was confusing to debug because gdb doesn't understand this bug so it shows the state that should have been restored until npxdna() unrestores it consistently. Try this fix. FWIW, this fixes every reproducable hang I've had with X and related. Thanks! juli. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ia64 tinderbox failure
-- 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
I can also confirm that my X server has been rock solid since applying the patch. I think Bruce deserves a lollipop. Juli Mallett [EMAIL PROTECTED] wrote: * De: Bruce Evans [EMAIL PROTECTED] [ Data: 2002-10-24 ] [ Subjecte: Re: Floating point problems ] Thanks. This makes the main bug clear. The PCB_NPXINITDONE bit in the state was not being restored. This was confusing to debug because gdb doesn't understand this bug so it shows the state that should have been restored until npxdna() unrestores it consistently. Try this fix. FWIW, this fixes every reproducable hang I've had with X and related. Thanks! juli. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! -- Peter Edwards. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5.0-20021025-CURRENT snapshot
This will be the last post on this topic. A new 5.0-20021025-CURRENT snapshot is available via anonymous ftp at usw2.freebsd.org: /pub/FreeBSD/snapshots/i386/5.0-20021025-CURRENT New snaps will appear each day if the build completes without errors. Enjoy! John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Dag-Erling Smorgrav writes: === share/doc/usd/13.viref out of memory *** Error code 255 Can you update the kernel and rtld on this machine as indicated in UPDATING? Otherwise, we'll see this same failure forever. Also, is there any way I can talk you out of building LINT on alpha in your tinderbox, or at least talk you into building it without WARNS? (there are several hundred pointer/integer with different size casts in various ILP32-centric drivers, and several hundred printf format warnings, so LINT will always fail and the alpha tinderbox will just by crying wolf and annoying people). Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Installing from CD and MAKEDEV
In message [EMAIL PROTECTED], Jun Kuriyama writes: At Thu, 24 Oct 2002 12:10:53 + (UTC), kuriyama wrote: I've created install CD with make iso.1 (with sources few hours before). I'm trying to install fresh current box with this CD. But I got MAKEDEV returned non-zero status dialog after extracting dists. It seems cd /dev; sh MAKEDEV all is failed at devfs environment. I found it. Phk changes in 1.297 of src/etc/Makefile not to install MAKEDEV by default. Options may be: This should be fixed now I hope. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libgtop port and v_tag changes
On 25-Oct-2002 Joe Marcus Clarke wrote: On Thu, 2002-10-24 at 19:13, Nate Lawson wrote: On Thu, 24 Oct 2002, John Baldwin wrote: Speaking of v_tag, can you fix the devel/libgtop port on current? This is the patch I used to get it building the other day: cat patch-sysdeps_freebsd_procmap.c --- sysdeps/freebsd/procmap.c.orig Tue Oct 15 20:00:35 2002 +++ sysdeps/freebsd/procmap.c Tue Oct 15 20:05:54 2002 @@ -251,6 +251,7 @@ vnode, sizeof (vnode)) != sizeof (vnode)) glibtop_error_io_r (server, kvm_read (vnode)); +#if __FreeBSD_version 50 if ((vnode.v_type != VREG) || (vnode.v_tag != VT_UFS) || !vnode.v_data) continue; @@ -261,6 +262,7 @@ maps [i-1].inode = inode.i_number; maps [i-1].device = inode.i_dev; +#endif #endif } while (entry.next != first); -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ I assume Joe has a better version he planned to commit as referenced by this email: [EMAIL PROTECTED] I like his patch better because it still handles the non CURRENT case. Joe? I committed my patch to libgtop and libgtop2 a while ago. It should work on both -CURRENT, not so -CURRENT, and -stable. Checkout patch-ah in libgtop/files. Works like a champ on -CURRENT from Monday. It does?! v_tag is a pointer to kernel memory, you can't read that from userland! You would get a SIGSEGV and die as soon as you do the 'strcmp()'. That's why I #ifdef'd the whole chunk out. Also, just for the record, my code didn't break the non CURRENT case. :) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Floating point problems
On Fri, 25 Oct 2002 03:43:03 -0700 Juli Mallett [EMAIL PROTECTED] wrote: FWIW, this fixes every reproducable hang I've had with X and related. AOL Bye, Alexander. -- The dark ages were caused by the Y1K problem. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla-devel problems
On Fri, 25 Oct 2002, Ollivier Robert wrote: According to Adam Weinberger: It was brought to my attention today by erk! that the way to solve the problem is to remove the mozilla-fonts package. It worked for me... I'm investigating why this is so. Works for me too. Thanks a lot ! -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] Me too. Thanks! - Matt -- Matt Loschert - Software Engineer | email: [EMAIL PROTECTED]| ServInt Internet Services | web: http://www.servint.net/ | McLean, Virginia USA| phone: (703) 847-1381 | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla-devel problems
According to Matt Loschert: Me too. Thanks! The CURRENT machine I've tested is rather old, world/kernel is from Sep. 18th. On an October, 20th CURRENT machine, mozilla just segfaults. During its reading of all fonts available, it get a segv... Any idea ? ... e3affe4fa68dd8cab058ebb21962d72dcfeaaa47e541a2ff3e6ecdacf0484ec3 7151b6b1fa6109a0113e3bef3145b53d05c62e0391e266393ba1a4b39a806a12 f2fe6562dff2fc97eff531ded8dc6e0ed359b2bf16d00031e9e0753bb32c156e ea81b7db813752506558d39f967450fa05390368950c456f106211dfc0621e52 66c14e1ebc6a9f3de3165500218fd683fa0dd2b4fcb937f14f7d3fb85faf556e 3f53ad74a4bcd96872b46716e0bd737dbf5d3115ce382ffb8243c499503283c4 274a0e51c9d41b302fd57c648a4e1769dcab4668ee624f3b9c84f296ba9ca925 056358d1e7f5a56ce1e53b5676d5e9ccfa4cf68f18f28aee890b1bfad737 03b64dcd7c5f34387f4522f421045adb7cb8b552d5145b83e24667d4f80cf636 45f80b863f0293b1d494ed65532c3963b69fe1a858850799155ed2450d836d30 d28dbfc50c7a58fd713346961d7f0e5513394b29c06c52b786b48a2f13b95b9d 56d6aca8250f3b716f055275af003304d36713f14228b5ec40de7c3ba9ae32cd eb91f8110bafcf7c92ea383bd9ca4d4fd0f6ccb0902b07841a4cbee2cbe21c4a 8124a11ef70c32d89e4b86d0e84294412f305ec186afd600ef7d72634e931f60 a75a22b03abbb87b4a163044b96d43cb1a8eac9484df8955edd18bb298612 52448 mozilla-bin RET read 6818/0x1aa2 52448 mozilla-bin PSIG SIGPROF caught handler=0x2856bb70 mask=0x0 code=0x0 52448 mozilla-bin CALL gettimeofday(0x28578158,0) 52448 mozilla-bin RET gettimeofday 0 52448 mozilla-bin CALL sigprocmask(0x3,0x285781dc,0) 52448 mozilla-bin RET sigprocmask 0 52448 mozilla-bin CALL poll(0x8092000,0x1,0) 52448 mozilla-bin RET poll 0 52448 mozilla-bin CALL sigreturn(0xbfbfcb3c) 52448 mozilla-bin RET sigreturn JUSTRETURN 52448 mozilla-bin PSIG SIGSEGV caught handler=0x2856bb70 mask=0x0 code=0xc 52448 mozilla-bin CALL sigprocmask(0x3,0x285781dc,0) 52448 mozilla-bin RET sigprocmask 0 52448 mozilla-bin CALL unlink(0x81430c0) 52448 mozilla-bin NAMI /home/staff/roberto/.mozilla/roberto/lxaarw4c.slt/lock 52448 mozilla-bin RET unlink 0 52448 mozilla-bin CALL setitimer(0x2,0xbfbfcd84,0) 52448 mozilla-bin RET setitimer 0 52448 mozilla-bin CALL close(0x3) 52448 mozilla-bin RET close 0 52448 mozilla-bin CALL close(0x4) 52448 mozilla-bin RET close 0 ... 52448 mozilla-bin CALL exit(0xb) 52443 sh RET wait4 52448/0xcce0 52443 sh CALL exit(0xb) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ia64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === usr.sbin/sysinstall /home/tinderbox/ia64/src/usr.sbin/sysinstall/dmenu.c: In function `dmenuOpen': /home/tinderbox/ia64/src/usr.sbin/sysinstall/dmenu.c:291: warning: cast to pointer from integer of different size /home/tinderbox/ia64/src/usr.sbin/sysinstall/dmenu.c:295: warning: cast to pointer from integer of different size /home/tinderbox/ia64/src/usr.sbin/sysinstall/dmenu.c:299: warning: cast to pointer from integer of different size /home/tinderbox/ia64/src/usr.sbin/sysinstall/menus.c:1370: warning: initialization makes integer from pointer without a cast disks.o: In function `diskPartitionWrite': disks.o(.text+0x2f72): undefined reference to `Write_Disk' *** Error code 1 Stop in /home/tinderbox/ia64/src/usr.sbin/sysinstall. *** Error code 1 Stop in /home/tinderbox/ia64/src/usr.sbin. *** Error code 1 Stop in /home/tinderbox/ia64/src. *** Error code 1 Stop in /home/tinderbox/ia64/src. *** Error code 1 Stop in /home/tinderbox/ia64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libgtop port and v_tag changes
On Fri, 25 Oct 2002, Joe Marcus Clarke wrote: On Fri, 25 Oct 2002, John Baldwin wrote: It does?! v_tag is a pointer to kernel memory, you can't read that from userland! You would get a SIGSEGV and die as soon as you do the 'strcmp()'. That's why I #ifdef'd the whole chunk out. Also, just for the record, my code didn't break the non CURRENT case. :) Sorry, mispoke. Your code didn't fix the CURRENT case. :) Gak! If Julian didn't pound kvm_read into my head before, I've got it now. Sure, it compiles, buth then what :-}. Thanks for the pointer. Attached is a patch to libgtop2, but should be similar if not identical to what's needed for libgtop. Let me know if this looks a little better. Thanks. Joe For another working and tested example, see rev 1.45 of fstat.c (usr.bin/fstat). -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libgtop port and v_tag changes
On 25-Oct-2002 Joe Marcus Clarke wrote:
On Fri, 25 Oct 2002, John Baldwin wrote:
On 25-Oct-2002 Joe Marcus Clarke wrote:
On Thu, 2002-10-24 at 19:13, Nate Lawson wrote:
On Thu, 24 Oct 2002, John Baldwin wrote:
Speaking of v_tag, can you fix the devel/libgtop port on current?
This is the patch I used to get it building the other day:
cat patch-sysdeps_freebsd_procmap.c
--- sysdeps/freebsd/procmap.c.orig Tue Oct 15 20:00:35 2002
+++ sysdeps/freebsd/procmap.c Tue Oct 15 20:05:54 2002
@@ -251,6 +251,7 @@
vnode, sizeof (vnode)) != sizeof (vnode))
glibtop_error_io_r (server, kvm_read (vnode));
+#if __FreeBSD_version 50
if ((vnode.v_type != VREG) || (vnode.v_tag != VT_UFS) ||
!vnode.v_data) continue;
@@ -261,6 +262,7 @@
maps [i-1].inode = inode.i_number;
maps [i-1].device = inode.i_dev;
+#endif
#endif
} while (entry.next != first);
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
I assume Joe has a better version he planned to commit as referenced by
this email:
[EMAIL PROTECTED]
I like his patch better because it still handles the non CURRENT case.
Joe?
I committed my patch to libgtop and libgtop2 a while ago. It should
work on both -CURRENT, not so -CURRENT, and -stable. Checkout patch-ah
in libgtop/files. Works like a champ on -CURRENT from Monday.
It does?! v_tag is a pointer to kernel memory, you can't read that
from userland! You would get a SIGSEGV and die as soon as you do the
'strcmp()'. That's why I #ifdef'd the whole chunk out. Also, just for
the record, my code didn't break the non CURRENT case. :)
Gak! If Julian didn't pound kvm_read into my head before, I've got it
now. Sure, it compiles, buth then what :-}. Thanks for the pointer.
Attached is a patch to libgtop2, but should be similar if not identical to
what's needed for libgtop. Let me know if this looks a little better.
Thanks.
Well, here's the thing. If libgtop is intended to be used only with live
kernels then it might be a better idea to use xvnode's that you get with
from the kernel. Alternatively, you could grab the inode and dev number
the same way the sysctl handler does:
switch (vp-v_type) {
case VREG:
case VDIR:
case VLNK:
xvn[n].xv_dev = vp-v_cachedfs;
xvn[n].xv_ino = vp-v_cachedid;
i.e., you could look at those members of struct vnode instead of trying
to dig into the details of a UFS inode structure in v_data. This
would remove the need to look at v_tag at all.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
pppd not working on latest current 2002-10-20
Is anyone using pppd on CURRENT. somewhere between may and October it seems to have broken. My KERNEL is GENERIC, my sources are dated cvs -D2002-10-20, but I now get a message about needing facilities in the kernel. However, the kernel has many ppp entry points, I haven't modified GENERIC which loads the ppp device, I've tried loading modules with ppp in their name all to no avail. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df problems ?
In article [EMAIL PROTECTED] you write: Alexey Zelkin wrote: Folks, I have dual boot machine with -STABLE and -CURRENT (both have own boot slices and few slices are shared between them.) I don't know all the details, but -CURRENT recently changed the way information is recorded in the superblock. The first copy of the superblock will be different between -CURRENT and -STABLE. Any partitions that are shared between -STABLE and -CURRENT must be fsck'd before use on the opposite system. The fsck was changed in -STABLE to look for the difference and correct it without getting confused. This is all very true for 4.7, but what about earlier versions. I compiled fsck using 4.7 srcs, includes and hierarchy with 4.0 libraries and tools, so that I could have an fsck I could use with my 4.0 CDROM (the latest one I have, unfortunately) to repair any changes made by my CURRENT system. It does compile with the same errors you get on a true 4.7 system about unsigned/signed comparisons. It even works as a program, but it does not repair the filesystem properly to be compatible with 4.0. You get an instant panic when going multi-user. This is a real nuisance as it blows my recovery strategy should I ever need it. If someone could figure out how to fix this I would be grateful until the time I get my hands on a 5.0 CDROM The tape format for dump/restore has been changed as well between CURRENT-Jan 2001 and CURRENT-October 2002. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pppd not working on latest current 2002-10-20
On Fri, Oct 25, 2002 at 06:15:55PM +, Dave Evans wrote: Is anyone using pppd on CURRENT. somewhere between may and October it seems to have broken. My KERNEL is GENERIC, my sources are dated cvs -D2002-10-20, but I now get a message about needing facilities in the kernel. However, the kernel has many ppp entry points, I haven't modified GENERIC which loads the ppp device, I've tried loading modules with ppp in their name all to no avail. You need to create an interface first. Run ifconfig ppp create. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg45217/pgp0.pgp Description: PGP signature
Re: kernel broken? (devfs maybe?)
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
On Fri, Oct 25, 2002 at 06:15:55PM +, Dave Evans wrote: Is anyone using pppd on CURRENT. somewhere between may and October it seems to have broken. My KERNEL is GENERIC, my sources are dated cvs -D2002-10-20, but I now get a message about needing facilities in the kernel. However, the kernel has many ppp entry points, I haven't modified GENERIC which loads the ppp device, I've tried loading modules with ppp in their name all to no avail. You need to create an interface first. Run ifconfig ppp create. Until pppd is taught to create the interface if one doesn't exist, this information needs to be in /usr/src/UPDATING. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI errors and then panic
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
On Fri, Oct 25, 2002 at 11:41:33AM -0700, Bakul Shah wrote:
Until pppd is taught to create the interface if one doesn't
exist, this information needs to be in /usr/src/UPDATING.
pppd doesn't need to be taught to create the interface. Rather it needed
to learn to check for ppp support in a non-stupid way. The following
patch should do it as well as making pppd do the right thing when
support isn't compiled in, but a module is available. It should make
things work with a GENERIC kernel.
If someone who actually uses pppd could test it, perferably in both
sceneios, I'll see about getting it commited.
-- Brooks
Index: sys-bsd.c
===
RCS file: /usr/cvs/src/usr.sbin/pppd/sys-bsd.c,v
retrieving revision 1.18
diff -u -p -r1.18 sys-bsd.c
--- sys-bsd.c 17 Sep 2002 15:52:35 - 1.18
+++ sys-bsd.c 25 Oct 2002 19:30:20 -
-44,6 +44,7 static char rcsid[] = $FreeBSD: src/usr
#include sys/time.h
#include sys/stat.h
#include sys/param.h
+#include sys/module.h
#ifdef NetBSD1_2
#include util.h
#endif
-169,28 +170,24 sys_check_options()
}
/*
- * ppp_available - check whether the system has any ppp interfaces
- * (in fact we check whether we can do an ioctl on ppp0).
+ * ppp_available - check whether the system has the ppp module loaded
+ * or compiled in. If it doesn't try loading it before giving up.
*/
int
ppp_available()
{
-int s, ok;
-struct ifreq ifr;
-extern char *no_ppp_msg;
+const char *modname = if_ppp;
+
+if (modfind(modname) != -1) {
+ printf(module is loaded\n);
+ return 1;
+}
-if ((s = socket(AF_INET, SOCK_DGRAM, 0)) 0)
- return 1; /* can't tell */
+printf(trying to load ppp mode\n);
+if (kldload(modname) != -1)
+ return 1;
-strncpy(ifr.ifr_name, ppp0, sizeof (ifr.ifr_name));
-ok = ioctl(s, SIOCGIFFLAGS, (caddr_t) ifr) = 0;
-close(s);
-
-no_ppp_msg = \
-This system lacks kernel support for PPP. To include PPP support\n\
-in the kernel, please follow the steps detailed in the README.bsd\n\
-file in the ppp-2.2 distribution.\n;
-return ok;
+return 0;
}
/*
--
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
msg45221/pgp0.pgp
Description: PGP signature
Re: pppd not working on latest current 2002-10-20
On Fri, 25 Oct 2002, Bakul Shah wrote:
On Fri, Oct 25, 2002 at 06:15:55PM +, Dave Evans wrote:
Is anyone using pppd on CURRENT. somewhere between may and October it
seems to have broken. My KERNEL is GENERIC, my sources are dated cvs
-D2002-10-20, but I now get a message about needing facilities in the
kernel. However, the kernel has many ppp entry points, I haven't
modified GENERIC which loads the ppp device, I've tried loading modules
with ppp in their name all to no avail.
You need to create an interface first. Run ifconfig ppp create.
Until pppd is taught to create the interface if one doesn't
exist, this information needs to be in /usr/src/UPDATING.
The kernel side of ppp was changed to create 0 ppp interfaces by default.
This is incompatible with the user side of ppp, which determines if ppp
is in the kernel by checking if there is a ppp interface. I use the
following low-quality work around:
%%%
Index: sys-bsd.c
===
RCS file: /home/ncvs/src/usr.sbin/pppd/sys-bsd.c,v
retrieving revision 1.18
diff -u -2 -r1.18 sys-bsd.c
--- sys-bsd.c 17 Sep 2002 15:52:35 - 1.18
+++ sys-bsd.c 17 Sep 2002 19:16:58 -
@@ -183,4 +183,19 @@
return 1; /* can't tell */
+/*
+ * XXX interface doesn't exist until you look at it right.
+ * devfs me harder.
+ */
+{
+int fd, newdisc, olddisc;
+
+fd = open(/dev/cuaa1, O_RDWR); /* XXX my tty hard-coded. */
+ioctl(fd, TIOCGETD, olddisc); /* XXX no error handling. */
+newdisc = PPPDISC;
+ioctl(fd, TIOCSETD, newdisc); /* XXX no error handling. */
+ioctl(fd, TIOCSETD, olddisc); /* XXX no error handling. */
+close(fd);
+}
+
strncpy(ifr.ifr_name, ppp0, sizeof (ifr.ifr_name));
ok = ioctl(s, SIOCGIFFLAGS, (caddr_t) ifr) = 0;
%%%
devfs is not really involved here. The bug just belongs to the same
class of complications given by devfs.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === usr.sbin/sysinstall /tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c: In function `dmenuOpen': /tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c:291: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c:295: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/usr.sbin/sysinstall/dmenu.c:299: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/usr.sbin/sysinstall/menus.c:1370: warning: initialization makes integer from pointer without a cast disks.o: In function `diskPartitionWrite': disks.o(.text+0x14b8): undefined reference to `Write_Disk' wizard.o: In function `slice_wizard': wizard.o(.text+0x5e4): undefined reference to `Write_Disk' *** Error code 1 Stop in /tinderbox/sparc64/src/usr.sbin/sysinstall. *** Error code 1 Stop in /tinderbox/sparc64/src/usr.sbin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: you need to install a new kernel before an installworld.
Due to sigaction(2) syscall number changes, doing a 'make installworld' without having booted a new kernel would be rather messy. For example, if you tried to reboot with the old kernel, /sbin/init and /bin/sh would get a signal and abort. That would be bad. I've added an anti-foot-shooting device to Makefile.inc1 to try and prevent disasters like this. For folks using the *world/*kernel procedure, a reminder of the sequence is probably in order: buildworld buildkernel installkernel reboot installworld reboot You may prefer to avoid building world for a few days and use the newer kernel on its own. Once you've done an installworld, you cannot go back to any previous kernel.old that you may have laying around. For this reason, you probably want to delay an installworld until you are comfortable that your newer kernel builds are satisfactory. options COMPAT_FREEBSD4 is necessary for running older 5.x binaries. For now (an additional anti-foot-shooting measure), I've made it yell loudly if you leave it out. If you try hard enough (read the code), you can turn it off if you really want and if you are really sure that you have no more 4.x or old 5.x binaries around in /usr/local etc. options COMPAT_43 is checked at compile time on the alpha now. It is still compulsory until somebody fixes longjmp in libc to use ucontext_t instead of struct osigcontext. This really needs to be done before 5.0 is released. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Coredump from pkg_add + analysis
On Tue, 24 Sep 2002, Nate Lawson wrote: There's a bit of a layering problem with the ftp/fetch semantics. _fetch_close() is used to shutdown the connection (and handles reference counting but the connection caching is done at the ftp layer. Either the connection cache should be moved to the fetch layer so open/close can deal with it properly (better) or the ftp layer needs to check for a ref count of 1 and invalidate the cache before closing it (worse). A lot of people would really really appreciate it if someone would choose an approach and fix this. -Nate I committed the second approach in rev 1.83 of ftp.c. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pppd not working on latest current 2002-10-20
Brooks Davis wrote: pppd doesn't need to be taught to create the interface. Rather it needed to learn to check for ppp support in a non-stupid way. The following patch should do it as well as making pppd do the right thing when support isn't compiled in, but a module is available. It should make things work with a GENERIC kernel. If someone who actually uses pppd could test it, perferably in both sceneios, I'll see about getting it commited. Try running you program when the module is there, but fails to load. You got rid of the failure message that it used to print. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pppd not working on latest current 2002-10-20
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
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 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 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
