No Subject
subscribe freebsd-current subscribe cvs-all To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Head's up: Yarrow-style periodic entropy saving
For the sake of those who don't follow commit messages (shame on you!), here's your fair warning regarding this change. This is the promised update that periodically (every 3 minutes by default) saves 2k of randomness to a set of rotating files stored by default in /.entropy. That location was chosen so that it could be loaded as early as possible in the boot process. As mentioned in the commit message, Mark suggested the defaults for size, period, and number of files based on the requirements of the Yarrow algorithm. System load for this should be negligible. All the parameters are tunable if load becomes a problem. I chose the operator user as the custodian of the entropy files since that both isolates them from unprivileged users to a certain extent, and minimizes the possibility of damaged caused by file based exploits that could be caused if the files were owned by root. This is bike shed material. For now my opinion is that the best option is to leave the single file written out at shutdown intact. First, I'd rather make one change at a time. Second, having both systems in place gives users with special needs (like diskless boots) more options in terms of saving entropy. I've no objection to ripping this out down the road if circumstances warrant. Enjoy, Doug Original Message Subject: cvs commit: src/etc crontab rc src/etc/defaults rc.confsrc/etc/mtree BSD.root.dist src/libexec Makefilesrc/libexec/save-entropy Makefile save-entropy.sh Date: Thu, 11 Jan 2001 05:01:20 -0800 (PST) From: Doug Barton [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] dougb 2001/01/11 05:01:20 PST Modified files: etc crontab rc etc/defaults rc.conf etc/mtreeBSD.root.dist libexec Makefile Added files: libexec/save-entropy Makefile save-entropy.sh Log: Add a system to save entropy from /dev/random periodically so that it can be used to reseed at boot time. This will greatly increase the chances that there will be sufficient entropy available at boot time to prevent long delays. For /etc/rc, remove the vmstat and iostat runs from the attempt to provide some cheesy randomness if the files fail, since those programs are dynamically linked, and ldd seems to want some randomness to do its magic. Guidance and parameters for this project were provided by Mark Murray, based on the requirements of the Yarrow algorithm. Some helpful suggestions for implementation (including the tip about iostat and vmstat) were provided by Sheldon Hearn. All blame for problems or mistakes is mine of course. Revision ChangesPath 1.28 +4 -1 src/etc/crontab 1.247 +27 -11src/etc/rc 1.84 +4 -1 src/etc/defaults/rc.conf 1.48 +5 -1 src/etc/mtree/BSD.root.dist 1.44 +2 -1 src/libexec/Makefile http://www.FreeBSD.org/cgi/cvsweb.cgi/src/etc/crontab.diff?r1=1.27r2=1.28f=h http://www.FreeBSD.org/cgi/cvsweb.cgi/src/etc/rc.diff?r1=1.246r2=1.247f=h http://www.FreeBSD.org/cgi/cvsweb.cgi/src/etc/defaults/rc.conf.diff?r1=1.83r2=1.84f=h http://www.FreeBSD.org/cgi/cvsweb.cgi/src/etc/mtree/BSD.root.dist.diff?r1=1.47r2=1.48f=h http://www.FreeBSD.org/cgi/cvsweb.cgi/src/libexec/Makefile.diff?r1=1.43r2=1.44f=h To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fan speed control sony vaio lx800 slimtop
It's possible that the EC is solely responsible for the fan, or that Sony decided in their infinite wisdom to do it all in a driver somewhere. "acpiconf -s 1" switches the fan to its low setting, so we do know how to do it. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /boot/kernel/kernel: swap_pager_getswapspace: failed
Edwin Culp wrote: I am starting to get the following error. I've never seen it before and don't really understand why it should fail. Where should I start looking for the problem? /boot/kernel/kernel: swap_pager_getswapspace: failed This seems to have started in the last week. I saw the same problem until I stopped using mfs on /tmp. Stop using mfs for /tmp. P.S. you might want to add the following to /etc/rc.conf: clear_tmp_enable="YES" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /boot/kernel/kernel: swap_pager_getswapspace: failed
On Fri, 12 Jan 2001 00:54:40 +1030, Matthew Thyer wrote: /boot/kernel/kernel: swap_pager_getswapspace: failed This seems to have started in the last week. I saw the same problem until I stopped using mfs on /tmp. Stop using mfs for /tmp. Are you sure it's not just /tmp "filling up" swap? If it's just that, all Edwin needs to do is limit the size of his MFS /tmp. I do this in /etc/fstab: /dev/ad0s1b /tmp mfs rw,-s=245760 0 0 See the description of the -s option in mount_mfs(8). Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Heads Up Re: cvs commit: src/sys/alpha/include globals.h src/sys/conf files.i386 src/sys/i386/i386 locore.s globals.s src/sys/i386/include asnames.h globals.h src/sys/ia64/include globals.h
jake2001/01/11 06:46:26 PST Modified files: sys/alpha/includeglobals.h sys/conf files.i386 sys/i386/i386locore.s sys/i386/include asnames.h globals.h sys/ia64/include globals.h Removed files: sys/i386/i386globals.s Log: - Remove compatibility macros for accessing per-cpu variables. __FreeBSD_version 500015 can be used to detect their disappearance. - Move the symbols for SMP_prvspace and lapic from globals.s to locore.s. - Remove globals.s with extreme prejudice. Revision ChangesPath 1.6 +1 -14 src/sys/alpha/include/globals.h 1.345 +1 -2 src/sys/conf/files.i386 1.140 +12 -1 src/sys/i386/i386/locore.s 1.50 +1 -44 src/sys/i386/include/asnames.h 1.16 +1 -25 src/sys/i386/include/globals.h 1.5 +1 -13 src/sys/ia64/include/globals.h If you have not rebuilt your modules in the past few days you must do so now. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ppp/samba (configuration?) question
If this isn't the right place for this, I apologize. Feel free to set followups appropriately. I'm running ppp on a -current system (12/7/2000 vintage) named `moran'. I'm using it as a gateway for small in-home network (a couple of windoze boxes and a laptop running -stable), and I have NAT enabled. ppp is started automatically at boot as follows: /usr/sbin/ppp -quiet -auto -nat mintel Here's the appropriate part of ppp.conf: mintel: allow users rjk set openmode active 5 set phone 1234567 set timeout 2700 set socket /var/tmp/internet "" set authname a set authkey b deny lqr disable lqr set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0 delete all add default HISADDR enable dns In ppp.linkdown, I have: mintel: iface clear I'm using 10.1.0.0/24 internally, and moran is also running dhcpd and samba. Everything is working fine, except (you knew there'd be an except, right?:) the windoze boxes on my local network can't find the samba server on moran immediately after moran reboots. After some experimenting with config files and playing with ethereal, I think I know what's going on but I don't know what to do about it. If I don't put "10.0.0.1 localhost" in /etc/hosts, rebooting is very slow; I have to wait for ppp to make a connection before sendmail gets going. If I add it to /etc/hosts I don't have to wait on sendmail but I have problems with nmbd. With the above configuration for ppp, ifconfig always shows 2 IP addresses associated with tun0. Immediately after boot, it looks like (for example): tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1514 inet 10.0.0.1 -- 255.255.255.255 netmask 0x inet 63.xx.xx.13 -- 63.xx.xx.2 netmask 0xff00 Opened by PID 115 After I lose my connection for whatever reason (which normally happens at least 3 or 4 times a day with our local telephone service :() ppp automatically redials and reconnects. After this happens, ifconfig would show: tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1514 inet 63.xx.xx.13 -- 255.255.255.255 netmask 0x inet 63.xx.xx.47 -- 63.xx.xx.2 netmask 0xff00 Opened by PID 115 The 10. address is gone, my last address is still there but points to 255.255.255.255, and my new address is fine. ethereal shows that nmbd is saying it lives at 10.0.0.1. If I kill nmbd and restart it after having lost and remade my ppp connection, everything is fine. Note that this only affects nmbd. Browsers and ssh work just fine. Have I got something misconfigured? Should ppp be keeping my last IP address around like that? Sorry for the length of this message. Any comments and/or suggestions? Thanks. -- Richard Kuhns [EMAIL PROTECTED] PO Box 6249 Tel: (765)477-6000 \ 100 Sawmill Roadx319 Lafayette, IN 47903 (800)489-4891 / To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
If memory serves me right, "Crist J. Clark" wrote: I had some buildworld failures earlier this week. In src/share/man/man8 the Makefile includes code to get the sysinstall.8 manpage. Since the manpage lives in src/release, this requires that you CVSup src-release. I had not been. This broke buildworld which had worked in the past. sysinstall.8 is the only file in src-release that is required for a buildworld. It seems somewhat silly to me that you are required to grab the whole thing for that one file. OK...I was one of the people who (indirectly) pushed for this. In a nutshell, I (and, independently, several other people) noticed that the sysinstall(8) manpage never gets installed as a part of the binary distributions or by an installworld. (I got highly confused by this while rewriting some other parts of the documentation.) The solution was to make sure that an installworld installs this manpage. I made the change to the Makefile which makes sysinstall.8 and src-release optional. I included it in a reply to the PR that precipitated the change, http://www.FreeBSD.org/cgi/query-pr.cgi?pr=19818 My personal opinion is that sysinstall.8 is a part of the base system and shouldn't be optional. If we take your suggestion, it means that installworld will sometimes install this manpage and sometimes it won't. A good counter-argument is that installworld doesn't touch /stand/sysinstall, and therefore shouldn't touch the manpage either. Idea: Maybe we need the release building process to do this instead? On all of my systems, the sysinstall binary came from a CD, and never got touched by any subsequent installworlds. Anyone have a good reason why everyone _must_ have src-release to buildworld? I never thought of trying to do a buildworld with anything less than src-all. I guess my counter question is: Anyone have a good reason to do buildworlds *without* /usr/src/release/? Bruce. PGP signature
Re: sysinstall.8 Breaking buildworld
My personal opinion is that sysinstall.8 is a part of the base system and shouldn't be optional. If we take your suggestion, it means that installworld will sometimes install this manpage and sometimes it won't. I think we should simply move the stupid man page into man8. It's a bit weird to have a man page and its utility live in seperate places, but the release/ directory in the hierarchy has always been a red-headed stepchild in any case. If I had it to do over, it would have all gone into /usr/src/sbin somewhere. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
Crist J. Clark wrote: Anyone have a good reason why everyone _must_ have src-release to buildworld? No. Sorry. I kind of assumed people doing buildworlds would just get src-all. Pointy hat this way please... As I said in a reply to a private mail to Crist, I'll commit a fix for this tonight and MFC it soon. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
On 11-Jan-01 Bruce A. Mah wrote: If memory serves me right, "Crist J. Clark" wrote: I had some buildworld failures earlier this week. In src/share/man/man8 the Makefile includes code to get the sysinstall.8 manpage. Since the manpage lives in src/release, this requires that you CVSup src-release. I had not been. This broke buildworld which had worked in the past. sysinstall.8 is the only file in src-release that is required for a buildworld. It seems somewhat silly to me that you are required to grab the whole thing for that one file. OK...I was one of the people who (indirectly) pushed for this. In a nutshell, I (and, independently, several other people) noticed that the sysinstall(8) manpage never gets installed as a part of the binary distributions or by an installworld. (I got highly confused by this while rewriting some other parts of the documentation.) The solution was to make sure that an installworld installs this manpage. I made the change to the Makefile which makes sysinstall.8 and src-release optional. I included it in a reply to the PR that precipitated the change, http://www.FreeBSD.org/cgi/query-pr.cgi?pr=19818 My personal opinion is that sysinstall.8 is a part of the base system and shouldn't be optional. If we take your suggestion, it means that installworld will sometimes install this manpage and sometimes it won't. A good counter-argument is that installworld doesn't touch /stand/sysinstall, and therefore shouldn't touch the manpage either. Idea: Maybe we need the release building process to do this instead? On all of my systems, the sysinstall binary came from a CD, and never got touched by any subsequent installworlds. Anyone have a good reason why everyone _must_ have src-release to buildworld? I never thought of trying to do a buildworld with anything less than src-all. I guess my counter question is: Anyone have a good reason to do buildworlds *without* /usr/src/release/? The real fix is that sysinstall does not belong in /usr/src/release, it needs to move back into /sbin or /usr/sbin and be a part of the regular world build. Jordan, is there any reason why we keep sysinstall out of sync with world? We can still leave /stand on teh system, but having a 3.x sysinstall in /stand on a -current system is less than useless. Whereas having an up-to-date sysinstall in /sbin or /usr/sbin as well as an up-to-date sysinstall.8 manpage that doesn't require weird hacks to be installed would be useful. The new sysinstall isn't coming anytime soon and we both know that, so that is not a valid argument for not moving it. It used to live in /sbin, so my only question is which directory should it move to: /sbin or /usr/sbin? I will do all the legwork on this.. Bruce. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ PGP signature
Re: sysinstall.8 Breaking buildworld
On Thu, Jan 11, 2001 at 09:29:45AM -0800, Bruce A. Mah wrote: [snip] My personal opinion is that sysinstall.8 is a part of the base system and shouldn't be optional. If we take your suggestion, it means that installworld will sometimes install this manpage and sometimes it won't. Bu-ut, as you point out... A good counter-argument is that installworld doesn't touch /stand/sysinstall, and therefore shouldn't touch the manpage either. I think getting the sysinstall binary and manpages out of sync, which is what the current configuration promises to do, is in itself a bug. Idea: Maybe we need the release building process to do this instead? On all of my systems, the sysinstall binary came from a CD, and never got touched by any subsequent installworlds. I had assumed that the 'release' target would do something like this which explains why I was so puzzled by this change. I now understand why some people wanted it. Anyone have a good reason why everyone _must_ have src-release to buildworld? I never thought of trying to do a buildworld with anything less than src-all. I guess my counter question is: Anyone have a good reason to do buildworlds *without* /usr/src/release/? When I was CVSup'ing over a phone line to a notebook PC with a 750MB HDD, I trimmed my supfile to only what I needed, no src-games, no src-kerberosIV, no src-kerberos5, no src-release, etc. But to reiterate, I think the best reason not to do this is the potential for getting /stand/sysinstall and sysinstall(8) out of sync on your system. That is Just Wrong. The manpage should only be installed when /stand/sysinstall changes. The fact that src-release is now required was just an annoyance since I lost a build before I tracked it down. I woulda got over it. ;) I had not even noticed the change on some builds over the weekend since I do ususally grab src-release. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
On Thu, Jan 11, 2001 at 10:53:43AM -0800, John Baldwin wrote: On 11-Jan-01 Jordan Hubbard wrote: My personal opinion is that sysinstall.8 is a part of the base system and shouldn't be optional. If we take your suggestion, it means that installworld will sometimes install this manpage and sometimes it won't. I think we should simply move the stupid man page into man8. It's a bit weird to have a man page and its utility live in seperate places, but the release/ directory in the hierarchy has always been a red-headed stepchild in any case. If I had it to do over, it would have all gone into /usr/src/sbin somewhere. Let's put sysinstall back in sbin/ then. It _used_ to live there until someone moved it. :) -r--r--r-- 1 root src 62356 Dec 30 1995 /usr/cvs/src/sbin/sysinstall/Attic/sysinstall.c,v I had assumed that sysinstall was not part of the standard installworld for recovery purposes. That is, if a buildworld-installworld were to totally hose your system (but of course that _never_ happens), you would still have a reliable /stand/sysinstall uncorrupted by the errant installworld to aid in fixing things. Again, this is just what I assumed the reason for the design to be. And I have never actually used sysinstall to recover a hosed upgrade, I like the fixit.flp. But IMHO, either both /stand/sysinstall and sysinstall.8 get installed when building world or neither do. To me, that seems clear cut. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
Let's put sysinstall back in sbin/ then. It _used_ to live there until someo ne moved it. :) I won't argue - move away! Just have one of the CVSmeisters do it as a repo-copy, of course. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
On 11-Jan-01 Jordan Hubbard wrote: Let's put sysinstall back in sbin/ then. It _used_ to live there until someo ne moved it. :) I won't argue - move away! Just have one of the CVSmeisters do it as a repo-copy, of course. Yay! Thanks. Will do. :) - Jordan -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
On 11-Jan-01 Crist J. Clark wrote: On Thu, Jan 11, 2001 at 10:53:43AM -0800, John Baldwin wrote: On 11-Jan-01 Jordan Hubbard wrote: My personal opinion is that sysinstall.8 is a part of the base system and shouldn't be optional. If we take your suggestion, it means that installworld will sometimes install this manpage and sometimes it won't. I think we should simply move the stupid man page into man8. It's a bit weird to have a man page and its utility live in seperate places, but the release/ directory in the hierarchy has always been a red-headed stepchild in any case. If I had it to do over, it would have all gone into /usr/src/sbin somewhere. Let's put sysinstall back in sbin/ then. It _used_ to live there until someone moved it. :) -r--r--r-- 1 root src 62356 Dec 30 1995 /usr/cvs/src/sbin/sysinstall/Attic/sysinstall.c,v I had assumed that sysinstall was not part of the standard installworld for recovery purposes. That is, if a buildworld-installworld were to totally hose your system (but of course that _never_ happens), you would still have a reliable /stand/sysinstall uncorrupted by the errant installworld to aid in fixing things. Erm, many things live in both /stand and other places: ll /stand/ | wc -l 35 ll /stand/rm /bin/rm -r-xr-xr-x 2 root wheel 255736 Jan 9 08:17 /bin/rm -r-xr-xr-x 31 root wheel 1729520 Jul 28 07:32 /stand/rm Putting it in world wouldn't touch /stand, it would just add it to either /usr/sbin or /sbin and keep that copy updated. Again, this is just what I assumed the reason for the design to be. And I have never actually used sysinstall to recover a hosed upgrade, I like the fixit.flp. But IMHO, either both /stand/sysinstall and sysinstall.8 get installed when building world or neither do. To me, that seems clear cut. I vote for both, but not to touch /stand. We don't keep rm.1 in sync with /stand/rm, we keep it in sync with /bin/rm, so this seems to be the most consistent.. -- Crist J. Clark [EMAIL PROTECTED] -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Head's up: Yarrow-style periodic entropy saving
According to Matt Dillon: Please make the default something more reasonable, like every 30 minutes. It is simply not necessary to save entropy every 3 minutes. It's massive overkill. Agreed. This is broken. The files should be in /var somewhere... for example, /var/db/entropy/ Agreed too, this is the standard location for such things. I know we need entropy at boot time (hopefully after mounting /var) but that's not a good reason to put them in / IMHO. -- 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: sio serial console in -current?
Matthew Jacob wrote:
Yeah, weird. I'm at 9600... What's wierd is that it's got to be some userland
induced thing because printouts from the kernel are fine until init is
invoked...
This is an ongoing "Hmm, that is strange!" type problem. There are several
symptoms that I see at times:
1: console turns to garbage part way through /etc/rc and comes back to life
when /etc/rc exits and getty starts
2: console *disappears* part way through /etc/rc and comes back to life
when /etc/rc exits and getty starts
3: there is a burst of garbage after /etc/rc and before getty
4: the problem you describe I think I have seen a long time ago, once.
5: ^T and ^C and ^\ do not work ("not a controlling terminal") during
the execution of /etc/rc. There are several different ways this happens
depending on whether you go via the single user shell or not.
This happens on some machines semi regularly and occasionally on others and
"never" (yet) on some others. These are all serial consoles, and all
machines are different. SMP machines are far worse than UP, but my UP
machines have this sort of thing occasionally too.
sio for alpha seems fine. wahhh.
I am sure we can break it for compatability :-)
No doubt.
What I'm really curious about is whether I'm the only one seeing this
consistently- not the 1-3,5 above, but #4- where as soon as /sbin/init is
invoked, the serial console has this repeated output that makes it unusable,
period. I really don't want to debug this myself- I am *sooo* behind on
other FreeBSD issues that I need to spend what few FreeBSD cycles I have on
those.
-matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Head's up: Yarrow-style periodic entropy saving
On Thu, 11 Jan 2001 21:20:44 +0100, Ollivier Robert wrote: This is broken. The files should be in /var somewhere... for example, /var/db/entropy/ Agreed too, this is the standard location for such things. I know we need entropy at boot time (hopefully after mounting /var) but that's not a good reason to put them in / IMHO. Hop off the bandwagon. The system didn't use /var/db/ before Doug's commit either. See my _long_ explanation (before/after/future) on the cvs-all mailing list. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current-ISO
If memory serves me right, "Sidwell, Josh" wrote: I have been unsucessfully trying to build an ISO image of the 5.0-CURRENT branch for the past several weeks. Is anyone aware of a tool to pull the latest tree and turn it into an ISO image? http://www.freebsd.org/FAQ/hackers.html#CUSTREL Bruce. PGP signature
Re: sysinstall.8 Breaking buildworld
On Thu, Jan 11, 2001 at 11:52:43AM -0800, John Baldwin wrote: [snip] Erm, many things live in both /stand and other places: ll /stand/ | wc -l 35 ll /stand/rm /bin/rm -r-xr-xr-x 2 root wheel 255736 Jan 9 08:17 /bin/rm -r-xr-xr-x 31 root wheel 1729520 Jul 28 07:32 /stand/rm I am not clear what you are saying here. Only sysinstall lives in /stand, [592:~] ls -li /stand total 45250 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 -sh 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 [ 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 arp 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 boot_crunch 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 cpio 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 dhclient 3 drwx-- 3 root wheel 512 Jun 19 2000 etc 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 find 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 fsck 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 gunzip 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 gzip 29952 drwxr-xr-x 2 root wheel 1024 Jun 19 2000 help 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 hostname 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 ifconfig 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 minigzip 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 mount_mfs 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 mount_nfs 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 newfs 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 pccardc 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 pccardd 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 ppp 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 pwd 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 rm 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 route 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 sed 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 sh 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 slattach 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 sysinstall 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 test 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 zcat But it lives by many names. (Ignoring the directories.) Putting it in world wouldn't touch /stand, it would just add it to either /usr/sbin or /sbin and keep that copy updated. [snip] I vote for both, but not to touch /stand. We don't keep rm.1 in sync with /stand/rm, we keep it in sync with /bin/rm, so this seems to be the most consistent.. Well, /stand/rm is not _really_ rm at all, but I get the point. I guess the only question is whether to put it in /sbin or /usr/sbin. I think /sbin makes sense (so it is bootable), but it is 1.6MB of /-bloat... But from another thread about making 250MB the default / size, I guess few care too much about that anymore. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
Crist J. Clark wrote: On Thu, Jan 11, 2001 at 11:52:43AM -0800, John Baldwin wrote: Erm, many things live in both /stand and other places: ll /stand/ | wc -l 35 ll /stand/rm /bin/rm -r-xr-xr-x 2 root wheel 255736 Jan 9 08:17 /bin/rm -r-xr-xr-x 31 root wheel 1729520 Jul 28 07:32 /stand/rm I am not clear what you are saying here. Only sysinstall lives in /stand, yeah, but it can be used as many things. If invoked as "rm" sysinstall behaves just like the real rm, it happens to be one big binary. Well, /stand/rm is not _really_ rm at all, but I get the point. I guess the only question is whether to put it in /sbin or /usr/sbin. I think /sbin makes sense (so it is bootable), but it is 1.6MB of /-bloat... But from another thread about making 250MB the default / size, I guess few care too much about that anymore. I'd prefer it in /usr/sbin, some of my root partitions are only 32MB, and that's not big enough at the moment. If your /usr is hosed to the extent you can't mount it you've probably got more problems than sysinstall will help you with. But that's just my opinion. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
If memory serves me right, Ben Smithurst wrote: yeah, but it can be used as many things. If invoked as "rm" sysinstall behaves just like the real rm, it happens to be one big binary. The thing in /stand is a crunchgen(8) binary. sysinstall itself is (chug, chug) 850K. After being stripped, it's 798K: 1616 -rwxr-xr-x 1 root wheel 817416 Jan 11 14:14 sysinstall Bruce. PGP signature
Re: sysinstall.8 Breaking buildworld
Jordan Hubbard wrote: Let's put sysinstall back in sbin/ then. It _used_ to live there until som eo ne moved it. :) I won't argue - move away! Just have one of the CVSmeisters do it as a repo-copy, of course. We cannot repo-copy it to src/sbin - there is a copy there already. We could blow the old one away and lose the history (RELEASE_2_0 and earlier) but I guess that is no big deal these days. Personally I would prefer it in src/usr.sbin/sysinstall and have it dynamically linked. The release crunchgen can still take the .o's and make the giant /stand version.. dynamic: 390769 shared: 892921 On the other hand, if we had the static version in src/sbin, we could have a "LINKS+= /sbin/sysinstall /stand/sysinstall" and blow away the old installed version with each make world. This would avoid POLA with people following old instructions to run /stand/sysinstall. 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: sysinstall.8 Breaking buildworld
yeah, but it can be used as many things. If invoked as "rm" sysinstall behaves just like the real rm, it happens to be one big binary. This, however, is merely "post-installation behavior" - if you rebuild and reinstall sysinstall in order to catch up with a bug fix to it, however, then this behavior goes away. - Jordan Well, /stand/rm is not _really_ rm at all, but I get the point. I guess the only question is whether to put it in /sbin or /usr/sbin. I think /sbin makes sense (so it is bootable), but it is 1.6MB of /-bloat... But from another thread about making 250MB the default / size, I guess few care too much about that anymore. I'd prefer it in /usr/sbin, some of my root partitions are only 32MB, and that's not big enough at the moment. If your /usr is hosed to the extent you can't mount it you've probably got more problems than sysinstall will help you with. But that's just my opinion. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Head's up: Yarrow-style periodic entropy saving
According to Sheldon Hearn: Hop off the bandwagon. The system didn't use /var/db/ before Doug's commit either. See my _long_ explanation (before/after/future) on the cvs-all mailing list. I know the system used now stores it in /entropy. I was too busy to react at that time but I still dislike using / for that. I read your message as well but I'm still behind Matt Jordan on that one. -- 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: sysinstall.8 Breaking buildworld
On 11-Jan-01 Ben Smithurst wrote: Crist J. Clark wrote: On Thu, Jan 11, 2001 at 11:52:43AM -0800, John Baldwin wrote: Erm, many things live in both /stand and other places: ll /stand/ | wc -l 35 ll /stand/rm /bin/rm -r-xr-xr-x 2 root wheel 255736 Jan 9 08:17 /bin/rm -r-xr-xr-x 31 root wheel 1729520 Jul 28 07:32 /stand/rm I am not clear what you are saying here. Only sysinstall lives in /stand, yeah, but it can be used as many things. If invoked as "rm" sysinstall behaves just like the real rm, it happens to be one big binary. Well, /stand/rm is not _really_ rm at all, but I get the point. I guess the only question is whether to put it in /sbin or /usr/sbin. I think /sbin makes sense (so it is bootable), but it is 1.6MB of /-bloat... But from another thread about making 250MB the default / size, I guess few care too much about that anymore. I'd prefer it in /usr/sbin, some of my root partitions are only 32MB, and that's not big enough at the moment. If your /usr is hosed to the extent you can't mount it you've probably got more problems than sysinstall will help you with. But that's just my opinion. Erm, sysinstall can be used as a replacement for fdisk and disklabel, both of which are in /sbin. In fact, in 4.2 the only tool you can realistically use to splat a virgin disklabel onto a slice w/o weird hoop jumping that isn't documented _is_ sysinstall. disklabel should have that fixed by 4.3, however. However, 800k is big for /sbin: ll /sbin/ | sort -n -k 5 ... -r-xr-sr-x 2 root tty 299956 Jan 9 08:25 restore -r-xr-sr-x 2 root tty 299956 Jan 9 08:25 rrestore -r-xr-xr-x 1 root wheel 424448 Jan 9 08:24 ipfstat -r-xr-xr-x 1 root wheel 484912 Jan 9 08:24 fsdb -r-xr-xr-x 1 root wheel 513748 Jan 9 08:25 vinum -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
On 11-Jan-01 Crist J. Clark wrote: On Thu, Jan 11, 2001 at 11:52:43AM -0800, John Baldwin wrote: [snip] Erm, many things live in both /stand and other places: ll /stand/ | wc -l 35 ll /stand/rm /bin/rm -r-xr-xr-x 2 root wheel 255736 Jan 9 08:17 /bin/rm -r-xr-xr-x 31 root wheel 1729520 Jul 28 07:32 /stand/rm I am not clear what you are saying here. Only sysinstall lives in /stand, Heh, no. That is a crunch. It has the object code for _all_ of those binaries in it. So /stand/rm will remove a file just like the normal rm: /stand/rm usage: rm [-f | -i] [-dPRrvW] file ... unlink file Putting it in world wouldn't touch /stand, it would just add it to either /usr/sbin or /sbin and keep that copy updated. [snip] I vote for both, but not to touch /stand. We don't keep rm.1 in sync with /stand/rm, we keep it in sync with /bin/rm, so this seems to be the most consistent.. Well, /stand/rm is not _really_ rm at all, but I get the point. I guess the only question is whether to put it in /sbin or /usr/sbin. I think /sbin makes sense (so it is bootable), but it is 1.6MB of /-bloat... But from another thread about making 250MB the default / size, I guess few care too much about that anymore. It isn't that big: file $owd/sysinstall /usr/obj/usr/src/sbin/sysinstall/sysinstall: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, not stripped ll !:1 ll /usr/obj/usr/src/sbin/sysinstall/sysinstall -rwxrwxr-x 1 john src 899374 Jan 11 14:06 /usr/obj/usr/src/sbin/sysinstall/sysinstall The stripped version is about 840k, which isn't but so bad. That is if it lives in /sbin (which I vote for). The dynamic version if it goes in /usr/sbin would be smaller again. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
entropy bikesheds
Since this post actually has some content I'm moving it to -current. On Thu, 11 Jan 2001, Warner Losh wrote: I agree. RO / is absoultely *REQUIRED* for our application. As stated, all concerned are sympathetic to that. This is why it's configurable. we have a small, writable partition that we can use to store the random entropy files. Any attempts to force / to be writable will be met with extreme resistance. The good thing about this ridiculous thread is that the next time someone asks me if I've read the code, I can simply respond with, "No one reads the code for my projects, even when I include the cvsweb links in my head's up mail, so why should I be bothered?" Our /var isn't persistant accross boots, btw. It is a mfs file system. Having a requirement that /var contain persistant data would likely lead to problems. It's precisely for these, and other hairy examples that I haven't put the thing in /var yet. Even a diskless workstation can read files from a RO root that the host writes out periodically, but there is no guarantee that there will be a /var filesystem that we can read from at boot time. I actually started to write some code to handle some obvious cases and got a major headache just thinking about it. I'm still not sure why we can't do something like: date /dev/random cat /bin/ls /dev/random fsck mount the file systems read in the entropy file Eg, toss some bone to the random pool. Sure, it will be highly preditable, but for the mount commands it doesn't matter. We fix before anything interesting happens. I have a lot of sympathy for this idea, but I don't know if it would work for yarrow. Mark will have to weigh in on it first. FYI, the things rc does first (as needed) are below. / is already mounted RO at this point. 1. rc.diskless 2. source the *rc.conf* files 3. try seeding from /entropy 4. ccdconfig 5. vinum start 6. fsck 7. mount root RW (exit if this fails) 8. umount -a 9. mount -a -t nonfs For my money that's a fairly large number of things that could potentially break if I fooled around with the mount'ing order, so I felt that putting the default in /.entropy was a good way to get started with the minimum amount of real pain. Bikeshed pain I can deal with. One way to deal with this is to introduce a new variable that specifies the filesystem mount point that needs to be mounted to read the seed files. That way we could mount that fs RO, do the seeding, then unmount it and proceed with the rest of the steps from 4. on. I would need some advice on potential pitfalls here though, which is why I haven't acted on it yet. The one that leaps immediately to mind is am I getting myself into trouble by mounting a potentially dirty filesystem, even though it's RO? I know this is done with /, but I'd like someone with more fs experience to confirm that I won't be digging a hole for someone if they have some sort of funky /var/foo fs that I haven't heard of. Doug -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ppp/samba (configuration?) question
You should get away with adding your ``set ifaddr'' line to ppp.linkdown (you can remove the ``iface clear'' too). If this isn't the right place for this, I apologize. Feel free to set followups appropriately. I'm running ppp on a -current system (12/7/2000 vintage) named `moran'. I'm using it as a gateway for small in-home network (a couple of windoze boxes and a laptop running -stable), and I have NAT enabled. ppp is started automatically at boot as follows: /usr/sbin/ppp -quiet -auto -nat mintel Here's the appropriate part of ppp.conf: mintel: allow users rjk set openmode active 5 set phone 1234567 set timeout 2700 set socket /var/tmp/internet "" set authname a set authkey b deny lqr disable lqr set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0 delete all add default HISADDR enable dns In ppp.linkdown, I have: mintel: iface clear I'm using 10.1.0.0/24 internally, and moran is also running dhcpd and samba. Everything is working fine, except (you knew there'd be an except, right?:) the windoze boxes on my local network can't find the samba server on moran immediately after moran reboots. After some experimenting with config files and playing with ethereal, I think I know what's going on but I don't know what to do about it. If I don't put "10.0.0.1 localhost" in /etc/hosts, rebooting is very slow; I have to wait for ppp to make a connection before sendmail gets going. If I add it to /etc/hosts I don't have to wait on sendmail but I have problems with nmbd. With the above configuration for ppp, ifconfig always shows 2 IP addresses associated with tun0. Immediately after boot, it looks like (for example): tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1514 inet 10.0.0.1 -- 255.255.255.255 netmask 0x inet 63.xx.xx.13 -- 63.xx.xx.2 netmask 0xff00 Opened by PID 115 After I lose my connection for whatever reason (which normally happens at least 3 or 4 times a day with our local telephone service :() ppp automatically redials and reconnects. After this happens, ifconfig would show: tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1514 inet 63.xx.xx.13 -- 255.255.255.255 netmask 0x inet 63.xx.xx.47 -- 63.xx.xx.2 netmask 0xff00 Opened by PID 115 The 10. address is gone, my last address is still there but points to 255.255.255.255, and my new address is fine. ethereal shows that nmbd is saying it lives at 10.0.0.1. If I kill nmbd and restart it after having lost and remade my ppp connection, everything is fine. Note that this only affects nmbd. Browsers and ssh work just fine. Have I got something misconfigured? Should ppp be keeping my last IP address around like that? Sorry for the length of this message. Any comments and/or suggestions? Thanks. -- Richard Kuhns [EMAIL PROTECTED] PO Box 6249 Tel: (765)477-6000 \ 100 Sawmill Road x319 Lafayette, IN 47903 (800)489-4891 / -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Running Linux kernel modules.
Is there a possibility of a generalized interface where any linux kernel module could be loaded, in the event that the linux emulator were loaded? Or would this require running the linux kernel in RAM, and therefore running two virtual machines? On Thursday, January 11, 2001 3:12 PM, Alfred Perlstein [SMTP:[EMAIL PROTECTED]] wrote: * Carl Makin [EMAIL PROTECTED] [010111 14:52] wrote: There are a couple of linux kernel modules that I'd love to run under FreeBSD. I've always assumed that I'd have to rewrite them substantially to make that happen. Can anyone give me some pointers on how hard it could be to port a linux kernel module to FreeBSD? Depends on how familiar you are with kernel internals, for instance after taking a quick look at the kernel module needed to run vmware it was pretty clear that someone with the experience and time could have it done in under a week, about 2 weeks later some maniac ( :) ) surfaced who had done just that. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message Glen M. Gross Unix Technical Support Specialist Symark Software 5716 Corsa Avenue, Suite 200 Westlake Village, CA 91362 http://www.symark.com [EMAIL PROTECTED] [EMAIL PROTECTED] Main: 800-234-9072 or 818-865-6100 Main fax: 818-889-1894 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Broken mmap in current?
Title: Broken mmap in current? I have written a character device driver for a proprietary PCI device that has a large sum of mapable memory. The character device supports mmap() which I use to export the memory into a user process. I have no problems accessing the memory on this device, but I notice that my mmap routine is called for every access! Is this a problem with current, or a problem with my mmap? I use bus_alloc_resource and then rman_get_start to get the physical address in my attach, and then the mmap just returns atop(physical address). I assumed this is correct since I have verified with a logical analyzer that I am indeed writing to the memory on the device. Also, I noticed that the device's mmap interface does not provide any way to limit the size of the block being mapped? Can I specify the length of the region? Thanks, Jeff
Re: sysinstall.8 Breaking buildworld
On Thu, Jan 11, 2001 at 02:38:55PM -0800, John Baldwin wrote: Erm, sysinstall can be used as a replacement for fdisk and disklabel, both of which are in /sbin. In fact, in 4.2 the only tool you can realistically use to splat a virgin disklabel onto a slice w/o weird hoop jumping that isn't documented _is_ sysinstall. disklabel should have that fixed by 4.3, however. But disklabel/fdisk can't even accept MB's as a unit. Until they grow the functionality of the NetBSD and OpenBSD versions of them, sysinstall is really the only tolerable disk label manipulation tool our users have. This includes those with a bummed /usr that needs to install a new disk to get it back. On Thu, Jan 11, 2001 at 02:22:23PM -0800, Peter Wemm wrote: Personally I would prefer it in src/usr.sbin/sysinstall and have it dynamically linked. That would be OK, *once* our fdisk/disklable grows some modern [heck even late 1990's] user interface. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
On Thu, Jan 11, 2001 at 02:22:23PM -0800, Peter Wemm wrote: I won't argue - move away! Just have one of the CVSmeisters do it as a repo-copy, of course. We cannot repo-copy it to src/sbin - there is a copy there already. We could blow the old one away and lose the history (RELEASE_2_0 and earlier) but I guess that is no big deal these days. It wouldn't be that much history (how about moving /home/ncvs/src/sbin/sysinstall/Attic to /home/ncvs/src/sbin/sysinstall/Old to preserve it??) Unfortuneatly in those days repo copies weren't done as well as now. :-(( To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy bikesheds
On Thu, Jan 11, 2001 at 03:00:35PM -0800, Doug Barton wrote: Since this post actually has some content I'm moving it to -current. On Thu, 11 Jan 2001, Warner Losh wrote: I agree. RO / is absoultely *REQUIRED* for our application. As stated, all concerned are sympathetic to that. This is why it's configurable. Not really -- specifying /var as the home of these files will not work very well (as you even show why below). So things *appear* to be configurable, but aren't. The good thing about this ridiculous thread is that the next time someone asks me if I've read the code, I can simply respond with, "No one reads the code for my projects, even when I include the cvsweb links in my head's up mail, so why should I be bothered?" I *did* read the diff you committed. So don't use that on me. ;-) Do YOU Yahoo!? Yep! -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy bikesheds
On Thu, 11 Jan 2001, David O'Brien wrote: On Thu, Jan 11, 2001 at 03:00:35PM -0800, Doug Barton wrote: Since this post actually has some content I'm moving it to -current. On Thu, 11 Jan 2001, Warner Losh wrote: I agree. RO / is absoultely *REQUIRED* for our application. As stated, all concerned are sympathetic to that. This is why it's configurable. Not really -- specifying /var as the home of these files will not work very well (as you even show why below). So things *appear* to be configurable, but aren't. We're talking about the defaults only. There is nothing to prevent you from putting the entropy files in /my/blue/pony if that's where you really want them. I still need to splatter test the really obscure cases in /etc/rc, but our ultimate goal is for total configurability. Doug -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Running Linux kernel modules.
On Thursday, January 11, 2001 3:12 PM, Alfred Perlstein
[SMTP:[EMAIL PROTECTED]] wrote:
* Carl Makin [EMAIL PROTECTED] [010111 14:52] wrote:
There are a couple of linux kernel modules that I'd love to run under
FreeBSD. I've always assumed that I'd have to rewrite them substantially
to make that happen.
Can anyone give me some pointers on how hard it could be to port a linux
kernel module to FreeBSD?
Depends on how familiar you are with kernel internals, for instance
after taking a quick look at the kernel module needed to run vmware
it was pretty clear that someone with the experience and time could
have it done in under a week, about 2 weeks later some maniac ( :) )
surfaced who had done just that.
The biggest problem I've had porting linux drivers is that linux
exports enough internals to allow drivers to distinguish between
multiple opens of the same device. Eg:
int
foo_ioctl(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg)
{
foo_per_open_data *priv = filp-private_data;
foo_softc *sc = priv-dev;
..
}
AFAIK, there's no clean way to do this with FreeBSD. I think this is
why VMware is limited to running one virtual machine.
This can be somewhat overcome in a very ugly way -- At my day job, I'm
porting a driver for Giganet cLAN1000 VIA adapters. This has much
the same problem as VMware. They've got an open-source linux kernel
module and a closed source userland binary.
To handle the multiple open problem, I'm overloading the open and
close system calls. Upon open, I call the native open, then I grovel
around in the process' open file table looking for my special file.
When I find it, I mark fp-f_nextread with a magic number, then store
a pointer to the per-open private data in fp-f_offset. On close, I
go grovelling again. I deallocate the private data, clear the magic
number, and call the system close function. I've also got an
at_exit() hook that does much the same thing.
Obtaining the file descripter at ioctl() and mmap() time is much more
interesting. When I'm called from a syscall, I pull the args out of
the process and grab the fd, index the process' file table and bingo.
The real problem is when mmap is called out of a fault (and not
dev_pager_alloc, which is what gets called when the mmap syscall is
issued). Right now I throw up my hands and return the private data
from the first instance I find when walking the process' open file
table. If this becomes a problem, I'm planning on prefaulting the
pages at dev_pager_alloc() time (when I can get an fd from the
process) and wiring them -- its only 20k per process..
Isn't this gross? Is there a better way?
Drew
--
Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin
Duke University Email: [EMAIL PROTECTED]
Department of Computer Science Phone: (919) 660-6590
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Broken mmap in current?
On Thu, 11 Jan 2001, Jeff Roberson wrote: I have written a character device driver for a proprietary PCI device that has a large sum of mapable memory. The character device supports mmap() which I use to export the memory into a user process. I have no problems accessing the memory on this device, but I notice that my mmap routine is called for every access! Is this a problem with current, or a problem with my mmap? Maybe both. The device mmap routine is called mainly by the mmap syscall for every page to be mmapped. It is also called by dev_pager_getpages() for some pagefaults, but I think this rarely happens. I use bus_alloc_resource and then rman_get_start to get the physical address in my attach, and then the mmap just returns atop(physical address). I assumed this is correct since I have verified with a logical analyzer that I am indeed writing to the memory on the device. This is correct. I looked at some examples. Many drivers get this wrong by using i386_btop(), alpha_btop(), etc. (AFAIK, atop() is for addresses which are what we are converting here, btop() is for (byte) offsets, and the machine-dependent prefixes are a vestige of page clustering code that mostly went away 7 years ago. Also, I noticed that the device's mmap interface does not provide any way to limit the size of the block being mapped? Can I specify the length of the region? The length is implicitly PAGE_SIZE. The device mmap function is called for each page to be mapped. It must verify that the memory from offset to (offset + PAGE_SIZE - 1) belongs to the device and can be accessed with the given protection, and do any device-specific things necessary to enable this memory. This scheme can't support bank-switched device memory very well, if at all. pcvvt_mmap() in the pcvt driver is the simplest example of this. agp_mmap() is a more up to date example with the same old bug that the vga drivers used to have (off by 1 (page) error checking the offset). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy bikesheds
Doug Barton said:
Since this post actually has some content I'm moving it to
-current.
Cool!
Our /var isn't persistant accross boots, btw. It is a mfs file
system. Having a requirement that /var contain persistant data would
likely lead to problems.
It's precisely for these, and other hairy examples that I haven't
put the thing in /var yet. Even a diskless workstation can read files from
a RO root that the host writes out periodically, but there is no guarantee
that there will be a /var filesystem that we can read from at boot time. I
actually started to write some code to handle some obvious cases and got a
major headache just thinking about it.
What is needed is some form of persistant storage to stash the Yarrow
state over a reboot or a crash.
There are a number of people saying "Over my dead body can you put it
${HERE}!!", without coming up with alternatives that are useful. At
BSDCon, the concept of using the first swap partition was discussed,
and I think it is a great idea, but the volunteer has yet to offer
any code.
I'm still not sure why we can't do something like:
date /dev/random
cat /bin/ls /dev/random
fsck
mount the file systems
read in the entropy file
Eg, toss some bone to the random pool. Sure, it will be highly
preditable, but for the mount commands it doesn't matter. We fix
before anything interesting happens.
Just as usable is "echo 'sekrit password' /dev/random".
Might as well not bother. There is no usable randomness here, so rather
than pretending, it is better to simply admit to ourselves that the
entropy generator is giving crap numbers at this point.
I originally put a block-at-startup in precicesly because of this
complaint. Remember that on a brand-new system, at first boot, the
sshd is going to use /dev/random to make keys. How insecure do you
want that?
Can we decide this, please - do we want secure startup (which will
take some effort to achieve), or can we say "screw it" and start
insecure like the old system?
I'm happy to accomodate folks, but the constant lack of concensus
combined with extreme positions is wearing a bit thin.
M
--
Mark Murray
Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: bogus microuptime() warnings?
In message [EMAIL PROTECTED] John Baldwin writes: : Going off on a tangent, I'm getting a lot fewer "hwptr went backwards" : with the latest -CURRENT than I used to... : : Which soundcard? I get them on sbc0: ESS ES1879 at port 0x220-0x22f,0x388-0x38b,0x320-0x321 irq 5 drq 1,5 on isa0 pcm0: ESS 18xx DSP on sbc0 on m VAIO. I see them more when there's lots of traffic on my zoomair awi card. But I also see them when playing mp3s off my hard disk. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: YES! laptop installing
In message [EMAIL PROTECTED] Mark Murray writes: : My Netgear FA510 (dc0) probes (sorta) but comes up with a crazy : MAC address, and then doesn't work. It doesn't even go UP. : : MAC=00:00:80:00:00:80, FWIW. There's about 4 different dc based cards that don't work because they don't get the nic address right. Well, that's what I think. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy bikesheds
Mark Murray [EMAIL PROTECTED] wrote: Can we decide this, please - do we want secure startup (which will take some effort to achieve), or can we say "screw it" and start insecure like the old system? I'm happy to accomodate folks, but the constant lack of concensus combined with extreme positions is wearing a bit thin. Although I'm not a coder on this platform, I do have an idea that we sometimes use on my hobby platform, maybe this might help... Start some kind of hardware-managed timer at the earliest possible opportunity (perhaps start it in the boot loader!), then when you need to pick up your first seed, read the timer's value and seed your random generator from that. The idea is to catch that timer at an unknown condition, and certainly the computer is not going to boot in the exact same amount of time, every time it's restarted. This would be especially true if the boot sequence gets interrupted (to load another kernel perhaps) or the user forces the machine into single-user mode while it's booting. In my hobby platform, it's common to start the timer, then grab a value from it after the user hits a key after viewing some introduction screen. The value grabbed is often used as the actual random number, but it could be just as useful if used to seed a random generator. If you're particularly paranoid, you set both timers for 32-bit mode, start one first thing at startup, and the other when the user hits the key, then read both of them the first time a random number is needed. Seed your random generator from that, along with any other sources you can (such as the video raster counter and the sound device's readable oscillator, set to generate a noise waveform). Just my two cents. -- ___ _ _ | _///@@@| | | [EMAIL PROTECTED] /'//ZZ@@| | | |'''/|'/@7 | | http://home.kscable.com/natedac |`'| `~~' | | | `| .--. | | C64/C128 - What's *YOUR* hobby? | `\|___\ | | \_ | | |___ \_| _| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bogus microuptime() warnings?
On Thu, 11 Jan 2001, Warner Losh wrote:
In message [EMAIL PROTECTED] John Baldwin writes:
: Going off on a tangent, I'm getting a lot fewer "hwptr went backwards"
: with the latest -CURRENT than I used to...
:
: Which soundcard?
sbc0: ESS ES1879 at port 0x220-0x22f,0x388-0x38b,0x320-0x321 irq 5 drq 1,5 on isa0
pcm0: ESS 18xx DSP on sbc0
I have also been experiencing this problem ("hwptr went backwards") with
my ESS Audiodrive (integrated on the motherboard), which uses the same
chip of course. Also, mine shows up as pcm1, rather than pcm0 as it did
in 4.1-Release, and I am forced to use a bridge driver. What am I doing
wrong?
Do you get stereo playback from yours? Mine's only mono in anything
over 4.1-Release. Of course I'm tracking 5.0-current.
But I also see them when playing mp3s off my hard disk.
Ditto.
--
___ _ _
| _///@@@| |
| [EMAIL PROTECTED] /'//ZZ@@| |
| |'''/|'/@7 |
| http://home.kscable.com/natedac |`'| `~~' |
| | `| .--. |
| C64/C128 - What's *YOUR* hobby? | `\|___\ |
| \_ | |
|___ \_| _|
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Bug in src tree?
hi!I try to compile a new kernel with the latest source and I always end upwith this (in the end). Any suggestions?I mean the error message is fun...dont match any know i386 instructioncc -c -xassembler-with-cpp -DLOCORE -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../dev -I../../../include -I../../contrib/dev/acpica/Subsystem/Include -D_KERNEL -includeopt_global.h -elf -mpreferred-stack-boundary=2 ../../i386/i386/bioscall.s/tmp/ccmJEqq7.s: Assembler messages:/tmp/ccmJEqq7.s:758: Error: operands given don't match any known 386instruction/tmp/ccmJEqq7.s:822: Error: operands given don't match any known 386instruction*** Error code 1Stop in /usr/src/sys/compile/PROFESSOR.010110.
Still... hwptr went backwards...
Dear all... Just a few days ago, I thought I saw a few posts that state the latest -CURRENT emits less hwptr went backwards messages. Apparently this doesn't happen on my system :( Currently running KDE 2.0.0 with XFree86 4.0.1 and when I play MP3, and want to lock my screen, MP3 playing choked heavily. If disk is heavily access, MP3 playing choke more worse. $ cat /dev/sndstat FreeBSD Audio Driver (newpcm) Jan 10 2001 18:06:06 Installed devices: pcm0: AudioPCI ES1371 at io 0xd400 irq 9 (1p/1r channels duplex) $ dmesg Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Wed Jan 10 18:07:41 JAVT 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DANTE Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 737023115 Hz CPU: Pentium III/Pentium III Xeon/Celeron (737.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 133083136 (129964K bytes) avail memory = 125952000 (123000K bytes) Preloaded elf kernel "kernel" at 0xc0312000. Pentium Pro MTRR support enabled Using $PIR table, 10 entries at 0xc00f0ed0 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82815 (i815 GMCH) Host To Hub bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 agp0: Intel 82815 (i815 GMCH) SVGA controller mem 0xf700-0xf707,0xf800-0xfbff irq 11 at device 2.0 on pci0 pcib1: PCI-PCI bridge at device 30.0 on pci0 pci1: PCI bus on pcib1 xl0: 3Com 3c905C-TX Fast Etherlink XL port 0xd800-0xd87f mem 0xf680-0xf680007f irq 9 at device 10.0 on pci1 xl0: Ethernet address: 00:50:da:95:85:dc miibus0: MII bus on xl0 xlphy0: 3c905C 10/100 internal PHY on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcm0: AudioPCI ES1371 port 0xd400-0xd43f irq 9 at device 11.0 on pci1 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH2 ATA100 controller port 0xb800-0xb80f at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: serial bus, SMBus at 31.3 (no driver attached) atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0401 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0f13 can't assign resources unknown: PNP0303 can't assign resources unknown: PNP0c02 can't assign resources ata0-master: DMA limited to UDMA33, non-ATA66 compliant cable ad0: 14324MB QUANTUM FIREBALLlct15 15 [29104/16/63] at ata0-master UDMA33 acd0: CDROM SONY CDU4811 at ata0-slave using PIO4 Mounting root from ufs:/dev/ad0s2a pcm0: hwptr went backwards 64 - 32 pcm0: hwptr went backwards 192 - 4032 pcm0: hwptr went backwards 384 - 192 pcm0: hwptr went backwards 2752 - 2720 pcm0: hwptr went backwards 192 - 32 pcm0: hwptr went backwards 2304 - 2048 pcm0: hwptr went backwards 2176 - 2080 pcm0: hwptr went backwards 2112 - 2048 pcm0: hwptr went backwards 2112 - 1856 pcm0: hwptr went backwards 64 - 4064 Sound card is Creative SoundBlaster Vibra 128. Motherboard ASUS CUSL2. /john To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP! New netgraph code coming
Hi Julian, I tried netgraph for the first time to work with latest vmware2 port. When I try to load netgraph kernel module, it failed with: # kldload ng_bridge kldload: can't load ng_bridge: Exec format error And /var/log/messages says: Jan 12 16:27:07 waterblue /boot/kernel/kernel: KLD ng_bridge.ko: depends on ng_ether - not available But ng_ether.ko is already loaded automatically (checked by kldstat). Is this known problem, or my local configuration mistake? # My environment is "make world"ed yesterday and kernel is latest. -- 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
