Re: qestion about vm page coloring
:Dear all, : : I study FreeBSD vm managememnt recently, however, I am a little confused :with vm_page's page color. when you call vm_add_new_page() in vm_startup(), :you will set each map entry's page color according to its physical addr. : : m-pc = (pa PAGE_SHIFT)PQ_L2_MASK; : :However, I found that almost each map entry's page color is zero, that means :PQ_L2_SIZE is 1, and disable page coloring option. Maybe I can do some :modification to dump PQ_L2_SIZE's value, but I think my guess is right. :Can someone please tell me the principle of page coloring, and why it's disabled :now? : :Thanks, : :Rex Luo I'm not sure what you mean by 'map entry'... vm_page_t's have color, and vm_object's have a base color to randomly offset the color of the vm_page_t's associated with the object, but vm_map_entry's do not have a page color associated with them. The page coloring works fine on my box, you may be looking at the wrong thing. PQ_L2_SIZE is definitely not 1 unless you've specified some weird kernel options in the kernel config. - Page coloring basically ensures that pages which are adjacent in virtual memory also wind up being adjacent in the L1 and L2 cpu caches in order to get more consistent cpu cache behavior. Without page coloring it is quite possible to have several adjacent pages in virtual memory wind up utilizing the same cpu cache page, which can effect performance with certain types of applications or certain cpu cache topologies. On IA32 pentium architectures the effect would probably not be all that noticeable, but getting consistent behavior is still a good thing. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: qestion about vm page coloring
yes, I mean vm_page_t, and understand what you said. I will try to print the value of PQ_L2_SIZE in my kernel. Do you know what kernel options influence this value? I saw it is decided by PQ_CACHESIZE which is decided by different PQ_HUGE[LARGE/MEDIUM/...]CACHEsetting. Default setting PQ_CACHESIZE is 128, and corresponding PQ_L2_SIZE is 32. Am I right until now or something wrong? I use FreeBSD 4.1 release kernel to build my kernel. Anyway, thanks for your explaination. Rex Luo Matt Dillon [EMAIL PROTECTED] said: :Dear all, : : I study FreeBSD vm managememnt recently, however, I am a little confused :with vm_page's page color. when you call vm_add_new_page() in vm_startup(), :you will set each map entry's page color according to its physical addr. : : m-pc = (pa PAGE_SHIFT)PQ_L2_MASK; : :However, I found that almost each map entry's page color is zero, that means :PQ_L2_SIZE is 1, and disable page coloring option. Maybe I can do some :modification to dump PQ_L2_SIZE's value, but I think my guess is right. :Can someone please tell me the principle of page coloring, and why it's disabled :now? : :Thanks, : :Rex Luo I'm not sure what you mean by 'map entry'... vm_page_t's have color, and vm_object's have a base color to randomly offset the color of the vm_page_t's associated with the object, but vm_map_entry's do not have a page color associated with them. The page coloring works fine on my box, you may be looking at the wrong thing. PQ_L2_SIZE is definitely not 1 unless you've specified some weird kernel options in the kernel config. - Page coloring basically ensures that pages which are adjacent in virtual memory also wind up being adjacent in the L1 and L2 cpu caches in order to get more consistent cpu cache behavior. Without page coloring it is quite possible to have several adjacent pages in virtual memory wind up utilizing the same cpu cache page, which can effect performance with certain types of applications or certain cpu cache topologies. On IA32 pentium architectures the effect would probably not be all that noticeable, but getting consistent behavior is still a good thing. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cluster size
Hi, lets come to my question please. tell me can i change mbuf cluster size from 2048 to 4096?? how shd i do it if i can do it? --- Julian Elischer [EMAIL PROTECTED] wrote: no.. it has to do with the fact that it would be unwise to make a cluster 1 page size since we have no guarantee that all drivers could handle breaking up a DMA if a cluster spanned 2 physical address ranges. (they can handle a chain of discontinuous mbufs but may assume that a single mbuf will have physically contiguous data. Now since we cannot span a page boundary, we should fit in exacly to get as much room as possible and since (pagesize/3) is too small, the next possibility is (pagesize/2). If pagesize/3 was big enough, we might have used that.. On Wed, 25 Jul 2001, Zhihui Zhang wrote: I see. It has something to do with the power-of-two allocator we are using inside the kernel. -Zhihui On Wed, 25 Jul 2001, Bosko Milekic wrote: On Wed, Jul 25, 2001 at 01:51:51PM -0400, Zhihui Zhang wrote: On Tue, 24 Jul 2001, Terry Lambert wrote: Zhihui Zhang wrote: Hi, in freebsd can we change the cluster size from 2048 bytes.If yes how can we do that? do we have to configure in some file? You must be asking why the mbuf cluster size is chosen as 2048, right? It is probably a tradeoff between memory efficient and speed. Ask yourselves: What is the minimum cluster size I would have to have to be able to contain the maximum MTU worth of data, yet remain an even multiple of sizeof(mbuf) -- 256 bytes? A dumb question: why even not odd multiple? -Zhihui It actually has to do with the fact that 2K is the only size equal to or greater than the maximum MTU worth of data that can be multiplied to a page size without any leftover (in other words, page size modulo 2K is zero). -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ARP cache problems....
On Wed, Jul 25, 2001 at 08:13:34PM -0700, Soren Kristensen wrote: Hi, I'm trying to do some testing on my boxes with 3 ethernet interface. But it seems like that FreeBSD gets very confused. Can somebody please tell me what's going and, and preferable, help me out ? I basically want to connect those 3 interface to the same hub, and then use them all from one win98 computer. I have tried before to give them IP's on the same subnet, and then move the cable around, but that gives me the same arp error message as below. The funny thing about that is that arp seems to ssave it on the disk somewhere, as it remember where it saw the MAC address even after reboots Anybody know where ?? FreeBSD only saves them in memory. But there is no reason to put more than one interface on the same hub. Simply configure one interface with alias entries. So I figured I could give put them on different subnet, like this: ifconfig_sis0=inet 192.168.1.60 netmask 255.255.255.0 ifconfig_sis1=inet 192.168.2.60 netmask 255.255.255.0 ifconfig_sis2=inet 192.168.3.60 netmask 255.255.255.0 And then I configure my win98 testing machine with the same subnet, using aliases on one ethernet interface. (seems to work fine) When I ping from the win98 machine, the ping seems to work fine, but I get these messages on the FreeBSD box: Jul 25 19:56:40 test256m /kernel: arp: 192.168.1.4 is on sis0 but got reply from 00:a0:cc:a0:d4:07 on sis1 That's quite normal in your configuration as all interfaces accepts broadcasted packets. When I then try to do a arp -a, the arp program seems to hang for a very long time, until it finally show: Try arp -an as arp -a tries DNS lookups for the IPs. ? (192.168.1.1) at 0:80:ad:81:fc:d4 [ethernet] ? (192.168.1.4) at 0:a0:cc:a0:d4:7 [ethernet] ? (192.168.2.1) at 0:a0:cc:a0:d4:7 [ethernet] Are you shure the Winows Bos answers the wuery as it should? tcpdump output would help. The FreeBSD box also hangs for a long time if I try to use the network interface, t.ex telnet to it. Is DNS working? Is what I'm trying to do possible at all ? What's the magic trick ? It is possible but uselless as you never get any improvement from using serveral interfaces to the same hub. If you use a switch with Fast Etherchannel capability FreeBSD can get use of it. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ARP cache problems....
Hi, Thanks for the responses, the long delay was because that I didn't have reverse lookup for the 192.168.x.x private IP's in my DNS setup, I just thought it was related with the arp problem Things seem to work fine now, but I still get a lot of those: Jul 26 00:43:48 test256m /kernel: arp: 192.168.1.4 is on sis0 but got reply from 00:a0:cc:a0:d4:07 on sis1 Anybody know how to turn them off ? Btw, the reason that I want to use multiple interface on the same net, is so I can do manufacturing test on my net4501 boxes from a win98 computer with just one network interface Regards, Soren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ARP cache problems....
Things seem to work fine now, but I still get a lot of those:
Jul 26 00:43:48 test256m /kernel: arp: 192.168.1.4 is on sis0 but got
reply from 00:a0:cc:a0:d4:07 on sis1
Anybody know how to turn them off ?
Yes, I have this problem too. We use several interfaces with totally
different addresses connected to the same hub for testing purposes,
on a testing stand. It's more cheap than bulding truly different
networks. I think it isn't possible to just turn those log messages
off without kernel hacking, which is sad. Probably some sysctl var
would be good ...
Currently, the solution is to take /sys/netinet/if_ether.c, find this:
#ifndef BRIDGE /* the following is not an error when doing bridging */
if (rt-rt_ifp != ac-ac_if) {
log(LOG_ERR, arp: %s is on %s%d but got reply from %6D on
%s%d\n,
inet_ntoa(isaddr),
rt-rt_ifp-if_name, rt-rt_ifp-if_unit,
ea-arp_sha, :,
ac-ac_if.if_name, ac-ac_if.if_unit);
goto reply;
}
#endif
and just hack off this message.
Regards,
Eugene
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: ARP cache problems....
On Thu, 26 Jul 2001, Soren Kristensen wrote: Hi, Thanks for the responses, the long delay was because that I didn't have reverse lookup for the 192.168.x.x private IP's in my DNS setup, I just thought it was related with the arp problem Things seem to work fine now, but I still get a lot of those: Jul 26 00:43:48 test256m /kernel: arp: 192.168.1.4 is on sis0 but got reply from 00:a0:cc:a0:d4:07 on sis1 Anybody know how to turn them off ? sysctl net.link.ether.inet.log_arp_wrong_iface ? Btw, the reason that I want to use multiple interface on the same net, is so I can do manufacturing test on my net4501 boxes from a win98 computer with just one network interface Regards, Soren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ARP cache problems....
Anybody know how to turn them off ? sysctl net.link.ether.inet.log_arp_wrong_iface ? vel@bugz:/home/vel # sysctl net.link.ether.inet.log_arp_wrong_iface sysctl: unknown oid 'net.link.ether.inet.log_arp_wrong_iface' Huh ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ARP cache problems....
"Eugene L. Vorokov" wrote:
Things seem to work fine now, but I still get a lot of those:
"Jul 26 00:43:48 test256m /kernel: arp: 192.168.1.4 is on sis0 but got
reply from 00:a0:cc:a0:d4:07 on sis1"
Anybody know how to turn them off ?
Yes, I have this problem too. We use several interfaces with totally
different addresses connected to the same hub for testing purposes,
on a testing stand. It's more cheap than bulding truly different
networks. I think it isn't possible to just turn those log messages
off without kernel hacking, which is sad. Probably some sysctl var
would be good ...
why not use several addresses on one card?
Currently, the solution is to take /sys/netinet/if_ether.c, find this:
#ifndef BRIDGE /* the following is not an error when doing bridging */
if (rt-rt_ifp != ac-ac_if) {
log(LOG_ERR, "arp: %s is on %s%d but got reply from %6D on
%s%d\n",
inet_ntoa(isaddr),
rt-rt_ifp-if_name, rt-rt_ifp-if_unit,
ea-arp_sha, ":",
ac-ac_if.if_name, ac-ac_if.if_unit);
goto reply;
}
#endif
and just hack off this message.
Regards,
Eugene
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
--
++ __ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ [EMAIL PROTECTED] +--x USA\ a very strange
| ( OZ)\___ ___ | country !
+- X_.---._/presently in San Francisco \_/ \\
v
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: crunched binary oddity
On Tue, Jul 24, 2001 at 10:14:09AM -0700, Etienne de Bruin wrote: Greetings. I crunchgen'd newfs and linked mount_mfs to it (among many other progs), compiled it with success. And yet when I boot my MFS kernel and try to mount /tmp to mfs, boot_crunch complains that 'mfs' is not compiled into it? My /etc/fstab: /dev/zero /tmpmfs rw,nosuid,-s=262144,-m=0,-T=minimum 0 0 /dev/zero /varmfs rw,-s=262144,-m=0,-T=minimum 0 0 /dev/cd0c /cdrom cd9660 ro,user 0 0 proc/proc procfs rw 0 0 Go on, give it to me. Could it be that it's not boot_crunch, but the kernel complaining? What is the exact error message? G'luck, Peter -- If I were you, who would be reading this sentence? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: review request: ng_split cleanup
This hunk is needed for lint(1) to recognize special comments. Don't remove it. The '/*-' part? What does lint do special with those? It's actually a signal to indent(1) to leave the comment's formatting alone. See the manpage. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: btx building error
I cvs'ed the current version of btx by cvs co btx and tried to build it on my FBSD-4.0 box and here is what I got: ... bash-2.04$ as --version GNU assembler 2.11 ... What should I do? Uninstall your custom binutils: ziplok:~uname -r 4.3-STABLE ziplok:~as --version GNU assembler 2.10.1 You might want to build the -stable version of BTX. Note also that BTX is not meant to be built/used standalone; you should look at the higher-level makefiles to see how it's integrated. Note, also that BTX in -current is built with: mass:~as --version GNU assembler 2.11.2 [FreeBSD] -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ARP cache problems....
On Thu, 26 Jul 2001, Eugene L. Vorokov wrote: Anybody know how to turn them off ? sysctl net.link.ether.inet.log_arp_wrong_iface ? vel@bugz:/home/vel # sysctl net.link.ether.inet.log_arp_wrong_iface sysctl: unknown oid 'net.link.ether.inet.log_arp_wrong_iface' Huh ? $ rlog -r1.74 if_ether.c ... description: revision 1.74 date: 2001/01/06 00:45:08; author: alfred; state: Exp; lines: +8 -1 provide a sysctl 'net.link.ether.inet.log_arp_wrong_iface' to allow one to supress logging when ARP replies arrive on the wrong interface: /kernel: arp: 1.2.3.4 is on dc0 but got reply from 00:00:c5:79:d0:0c on dc1 the default is to log just to give notice about possibly incorrectly configured networks. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: exec() doesn't update access time
On Wed, Jul 25, 2001 at 02:25:19PM -0700, David Greenman wrote: Guessing, I think the correct fix is probably to set the IN_ACCESS flag in ufs_open() [and similarly with other filesystems where this makes sense] if the filesystem is not mounted with the noatime flag. However, I'm not sure of the symantics of the access time in the relavent standards, and I seem to recall Bruce saying that it was incorrect to indicate an access on just an open(), but I may be mistaken. Wouldn't setting the access time on open mess up the last read time for people's mail boxes when mail was delivered? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ARP cache problems....
On Thu, Jul 26, 2001 at 02:11:21PM +0400, Maxim Konovalov wrote: On Thu, 26 Jul 2001, Eugene L. Vorokov wrote: Anybody know how to turn them off ? sysctl net.link.ether.inet.log_arp_wrong_iface ? vel@bugz:/home/vel # sysctl net.link.ether.inet.log_arp_wrong_iface sysctl: unknown oid 'net.link.ether.inet.log_arp_wrong_iface' Huh ? $ rlog -r1.74 if_ether.c ... description: revision 1.74 date: 2001/01/06 00:45:08; author: alfred; state: Exp; lines: +8 -1 provide a sysctl 'net.link.ether.inet.log_arp_wrong_iface' to allow one to supress logging when ARP replies arrive on the wrong interface: /kernel: arp: 1.2.3.4 is on dc0 but got reply from 00:00:c5:79:d0:0c on dc1 the default is to log just to give notice about possibly incorrectly configured networks. This exists in -current and has been MFC'd before 4.3-RELEASE. FreeBSD installations older than 4.3-RELEASE, or -STABLE installations older than January 6, 2001, would not have this sysctl knob. G'luck, Peter -- The rest of this sentence is written in Thailand, on To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Starting natd
It seems that rc.network requires an interface to be specified for natd for it to be started. Alas, I do not and cannot specify an interface for natd, using alias_address instead (and disliking even that, since what I really want is static nat). -- Daniel C. Sobral (8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Common sense and a sense of humor are the same thing, moving at different speeds. A sense of humor is just common sense, dancing. -- Clive James To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: exec() doesn't update access time
On Thu, Jul 26, 2001 at 12:09:17PM +0100, David Malone wrote: On Wed, Jul 25, 2001 at 02:25:19PM -0700, David Greenman wrote: Guessing, I think the correct fix is probably to set the IN_ACCESS flag ufs_open() [and similarly with other filesystems where this makes sense] i the filesystem is not mounted with the noatime flag. However, I'm not sure of the symantics of the access time in the relavent standards, and I seem to recall Bruce saying that it was incorrect to indicate an access on just an open(), but I may be mistaken. Wouldn't setting the access time on open mess up the last read time for people's mail boxes when mail was delivered? I think people are only discussing updating atime on exec(), not on all open()'s. I do not really believe you are trying to execute your mailboxes :) Surely if you mark the file for update in ufs_open then it doesn't matter if you're opening of execing? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: qestion about vm page coloring
: : : : yes, I mean vm_page_t, and understand what you said. I will try to print the :value of PQ_L2_SIZE in my kernel. Do you know what kernel options influence :this value? I saw it is decided by PQ_CACHESIZE which is decided by different :PQ_HUGE[LARGE/MEDIUM/...]CACHEsetting. Default setting PQ_CACHESIZE is 128, :and corresponding PQ_L2_SIZE is 32. Am I right until now or something wrong? :I use FreeBSD 4.1 release kernel to build my kernel. : :Anyway, thanks for your explaination. : :Rex Luo Yes, 32 is what you should see with the defaults. I would also upgrade to the latest -stable, 4.1 was a fairly good release but a lot of bugs have still been fixed between it and 4.3 including a couple of root exploits. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ARP cache problems....
On Thu, Jul 26, 2001 at 10:01:05AM +0200, Bernd Walter wrote: But there is no reason to put more than one interface on the same hub. Simply configure one interface with alias entries. s/hub/switch/ and there is, and the system should make this not too painful to configure. -- Leo Bicknell - [EMAIL PROTECTED] Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fwd: Sun Grid Engine 5.2.3 Available. Now Open Source
Paul Marquis wrote: On Wednesday 25 July 2001 03:29, Terry Lambert wrote: Ron Chen wrote: Sun Grid Engine goes opensource. See SGE home page: http://www.sun.com/gridware I see no source code there, only Solaris and Linux binaries. Check out (though the site(s) currently appear down): http://www.gridengine.sunsource.net/ http://www.sunsource.net/ Thanks; it's there. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Downloads appear broked...but work...keep hitting reload...
Jim Bryant wrote: Everybody and their dog must be downloading this. If you keep getting the java.lang.OutOfMemoryError, just keep hitting reload... I was just about to give up when it finally worked for me. Gee, garbage collection is special. I'm going to run right out and use Java in my next embedded system! -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ARP cache problems....
On Thu, Jul 26, 2001 at 11:35:59AM -0400, Leo Bicknell wrote: On Thu, Jul 26, 2001 at 10:01:05AM +0200, Bernd Walter wrote: But there is no reason to put more than one interface on the same hub. Simply configure one interface with alias entries. s/hub/switch/ and there is, and the system should make this not too painful to configure. If you are using a switch you should use FEC or VLANs. Yes I know there switches out there without that features but if you want more performance then use hardware that can do the job you need. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cluster size
Julian Elischer wrote: no.. it has to do with the fact that it would be unwise to make a cluster 1 page size since we have no guarantee that all drivers could handle breaking up a DMA if a cluster spanned 2 physical address ranges. (they can handle a chain of discontinuous mbufs but may assume that a single mbuf will have physically contiguous data. Now since we cannot span a page boundary, we should fit in exacly to get as much room as possible and since (pagesize/3) is too small, the next possibility is (pagesize/2). FWIW: the way clusters work quarantees contiguity, based on the zone allocator being backed by contiguous regions in single pages. This is what Julian said, but it's less verbose... 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cluster size
Bosko Milekic wrote: On Wed, Jul 25, 2001 at 02:17:38PM -0400, Zhihui Zhang wrote: I see. It has something to do with the power-of-two allocator we are using inside the kernel. No, it has nothing to do with the power-of-two allocation strategy used in some cases inside the kernel. 2K is just the most convenient size for a cluster as it fits the maximum MTU size while at the same time fitting nicely into a page, reducing allocation complexity. Specifically, it saves a lot of housekeeping, which isn't really a lot, if it's done correctly. Actually, we would be well serverd by permitting odd-sized mbufs, particularly for use a mbuf cluster containers, since they waste an incredible amount of space. The real reason behind all this is to make the input and output routines symmetric, since mbuf's can be allocated at interrupt, and clusters can't (or couldn't, last time I looked at 4.3). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cluster size
vishwanath pargaonkar wrote: Hi, lets come to my question please. tell me can i change mbuf cluster size from 2048 to 4096?? You can do it, but it's not a really very useful thing to do, since the majority of your cluster will end up being vacant. how shd i do it if i can do it? Look at the header files, and look at uipc_mbuf.c in /sys/kern. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
perhaps one of phk's intern projects?
It'd be nice if one could pass a time specification to at in the form of next reboot. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Backup file formats: tar, cpio, pax, yadda, yadda, yadda
Both tar and cpio seem to have problems doing backups on my server. Looking at the pax manpage, we see this: cpio The extended cpio interchange format specified in the IEEE Std 1003.2 (``POSIX.2'') standard. The default blocksize for this format is 5120 bytes. Inode and device informa- tion about a file (used for detecting file hard links by this format) which may be truncated by this format is detected by pax and is repaired. bcpioThe old binary cpio format. The default blocksize for this format is 5120 bytes. This format is not very portable and should not be used when other formats are available. Inode and device information about a file (used for detecting file hard links by this format) which may be truncated by this format is detected by pax and is repaired. sv4cpio The System V release 4 cpio. The default blocksize for this format is 5120 bytes. Inode and device information about a file (used for detecting file hard links by this format) which may be truncated by this format is detected by pax and is repaired. sv4crc The System V release 4 cpio with file crc checksums. The default blocksize for this format is 5120 bytes. Inode and device information about a file (used for detecting file hard links by this format) which may be truncated by this format is detected by pax and is repaired. tar The old BSD tar format as found in BSD4.3. The default blocksize for this format is 10240 bytes. Pathnames stored by this format must be 100 characters or less in length. Only regular files, hard links, soft links, and directories will be archived (other file system types are not supported). For backwards compatibility with even older tar formats, a -o option can be used when writing an archive to omit the storage of directories. This option takes the form: -o write_opt=nodir ustarThe extended tar interchange format specified in the IEEE Std 1003.2 (``POSIX.2'') standard. The default blocksize for this format is 10240 bytes. Pathnames stored by this format must be 250 characters or less in length. Let's review. All the tar formats will truncate long filenames. All the cpio formats truncate the inode number. Is there a reasonable backup tool which does not do goofy things like that? Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: perhaps one of phk's intern projects?
On Thu, Jul 26, 2001 at 10:20:51AM -0700, Matthew Jacob wrote: It'd be nice if one could pass a time specification to at in the form of next reboot. This could be implemented as a startup script, no? On second thoughts, not quite trivial. It wouldn't be hard to write a separate utility to schedule jobs to be serviced at the next reboot; integrating this functionality into at(1) would be nice, too, though maybe just a little bit harder - it would require the time to parse the at(1) sources ;) Then it would be as simple as making the command-line scheduling utility write the job into the at-next-boot utility spool dir instead of the regular at(1) spool dir; or maybe the at-next-boot utility could just look through the regular at(1) spool dir for some specially-marked files that at(1) would ignore.. I would be willing to do this, if no one else volunteers. G'luck, Peter -- This would easier understand fewer had omitted. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cluster size
On Thu, Jul 26, 2001 at 10:18:09AM -0700, Terry Lambert wrote: The real reason behind all this is to make the input and output routines symmetric, since mbuf's can be allocated at interrupt, and clusters can't (or couldn't, last time I looked at 4.3). They can. Whether they are or not I'm not sure. -- Terry -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cluster size
* Bosko Milekic [EMAIL PROTECTED] [010726 12:32] wrote: On Thu, Jul 26, 2001 at 10:18:09AM -0700, Terry Lambert wrote: The real reason behind all this is to make the input and output routines symmetric, since mbuf's can be allocated at interrupt, and clusters can't (or couldn't, last time I looked at 4.3). They can. Whether they are or not I'm not sure. Er, wouldn't that be the only way for cards to refil thier DMA recieve buffers? -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: crunched binary oddity
When mount(8) invokes a mount_xxx program, it sets argv[0] to the name of the filesystem (ufs, mfs, nfs etc). Crunched binaries use the argv[0] name to determine which code to execute, so you need to add ln mount_mfs mfs to your crunchgen config file to get this to work. Alternatively, just invoke mount_mfs directly instead of using mount(8). Hey this is great, thanks Ian. This explains it all. I went ahead and invoked mount_mfs instead of relying on /etc/fstab. Works perfectly. eT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: perhaps one of phk's intern projects?
at already understands the concept of tomorrow in it's parsing of time. It also understands special terms like teatime. If we simplify this to at reboot then all you'd have to do would be to either squirrel these jobs in another directory and have part of rc check for these or just have a special name so that at's reading of the spool dir won't get upset if they're ther. On Thu, 26 Jul 2001, Peter Pentchev wrote: On Thu, Jul 26, 2001 at 10:20:51AM -0700, Matthew Jacob wrote: It'd be nice if one could pass a time specification to at in the form of next reboot. This could be implemented as a startup script, no? On second thoughts, not quite trivial. It wouldn't be hard to write a separate utility to schedule jobs to be serviced at the next reboot; integrating this functionality into at(1) would be nice, too, though maybe just a little bit harder - it would require the time to parse the at(1) sources ;) Then it would be as simple as making the command-line scheduling utility write the job into the at-next-boot utility spool dir instead of the regular at(1) spool dir; or maybe the at-next-boot utility could just look through the regular at(1) spool dir for some specially-marked files that at(1) would ignore.. I would be willing to do this, if no one else volunteers. G'luck, Peter -- This would easier understand fewer had omitted. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Backup file formats: tar, cpio, pax, yadda, yadda, yadda
Let's review. All the tar formats will truncate long filenames. All the cpio formats truncate the inode number. Is there a reasonable backup tool which does not do goofy things like that? Ive always been partial to dump/ufsdump myself. And gnu tar will handle longfiles names. There was a usenix paper on backup programs, they found dump to be the best at the time. --Larry Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message Lawrence Sica - Systems Administrator - Interactivate, Inc [EMAIL PROTECTED] http://www.interactivate.com - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Backup file formats: tar, cpio, pax, yadda, yadda, yadda
On Thu, Jul 26, 2001 at 01:26:28PM -0400, James Howard wrote: Both tar and cpio seem to have problems doing backups on my server. Looking at the pax manpage, we see this: [snipped] Let's review. All the tar formats will truncate long filenames. All the cpio formats truncate the inode number. Is there a reasonable backup tool which does not do goofy things like that? dump(8) -- Greg LewisEmail : [EMAIL PROTECTED] Eyes Beyond Mobile: 0419 868 494 Information TechnologyWeb : http://www.eyesbeyond.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cluster size
Bosko Milekic wrote: On Thu, Jul 26, 2001 at 10:18:09AM -0700, Terry Lambert wrote: The real reason behind all this is to make the input and output routines symmetric, since mbuf's can be allocated at interrupt, and clusters can't (or couldn't, last time I looked at 4.3). They can. Whether they are or not I'm not sure. FWIW: I meant as in in normal practice, not as in impossible!. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cluster size
Alfred Perlstein wrote: On Thu, Jul 26, 2001 at 10:18:09AM -0700, Terry Lambert wrote: The real reason behind all this is to make the input and output routines symmetric, since mbuf's can be allocated at interrupt, and clusters can't (or couldn't, last time I looked at 4.3). They can. Whether they are or not I'm not sure. Er, wouldn't that be the only way for cards to refil thier DMA recieve buffers? Look at the Tigon II and FXP drivers. The allocations in the macros turn into m_get, not m_clusterget. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cluster size
On Thu, Jul 26, 2001 at 10:51:40AM -0700, Terry Lambert wrote:
Alfred Perlstein wrote:
On Thu, Jul 26, 2001 at 10:18:09AM -0700, Terry Lambert wrote:
The real reason behind all this is to make the input and output
routines symmetric, since mbuf's can be allocated at interrupt,
and clusters can't (or couldn't, last time I looked at 4.3).
They can. Whether they are or not I'm not sure.
Er, wouldn't that be the only way for cards to refil thier DMA
recieve buffers?
Look at the Tigon II and FXP drivers. The allocations in
the macros turn into m_get, not m_clusterget.
From if_fxp.c (fxp_add_rfabuf(), sometimes called from fxp_intr()):
MGETHDR(...); -- get mbuf
if (m != NULL) {
MCLGET(...); -- get cluster
...
}
-- Terry
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Why two cards on the same segment...
Hi, Alfred Perlstein wrote: Things seem to work fine now, but I still get a lot of those: Jul 26 00:43:48 test256m /kernel: arp: 192.168.1.4 is on sis0 but got reply from 00:a0:cc:a0:d4:07 on sis1 Anybody know how to turn them off ? Yes, I have this problem too. We use several interfaces with totally different addresses connected to the same hub for testing purposes, on a testing stand. It's more cheap than bulding truly different networks. I think it isn't possible to just turn those log messages off without kernel hacking, which is sad. Probably some sysctl var would be good ... Without proper attribution I can't make proper fun of you guys for not noticing: net.link.ether.inet.log_arp_wrong_iface set it to zero. Not all of us runs the newest versions Another posting told that the arp sysctl was introduced in 4.3. And the reason why I want 3 ethernet on the same segment is not some fancy reason, I just need to do manufacturing test on a piece of hardware, without a big setup So now I just need to decide if I want to move to 4.3, or kill it in the source. Regards, Soren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Backup file formats: tar, cpio, pax, yadda, yadda, yadda
Let's review. All the tar formats will truncate long filenames. All the cpio formats truncate the inode number. Is there a reasonable backup tool which does not do goofy things like that? Neither tar nor cpio is suitable for backup purposes. Use dump instead. BTW this is a subject for -questions rather than -hackers. Lars To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: exec() doesn't update access time
On Wed, Jul 25, 2001 at 02:25:19PM -0700, David Greenman wrote: Guessing, I think the correct fix is probably to set the IN_ACCESS flag in ufs_open() [and similarly with other filesystems where this makes sense] if the filesystem is not mounted with the noatime flag. However, I'm not sure of the symantics of the access time in the relavent standards, and I seem to recall Bruce saying that it was incorrect to indicate an access on just an open(), but I may be mistaken. Wouldn't setting the access time on open mess up the last read time for people's mail boxes when mail was delivered? Probably. Now that you mention it, it seems kind of bogus for a file write to not be considered an access. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Backup file formats: tar, cpio, pax, yadda, yadda, yadda
On Thu, 26 Jul 2001, [iso-8859-1] Lars Kühl wrote: Neither tar nor cpio is suitable for backup purposes. Use dump instead. A lot of people said this. Why? As near as I can tell, dump isn't that great either. There is no way to exlude specific directories with dump and it appears to be quite painful to restore a specific directory (though I could be wrong about this. BTW this is a subject for -questions rather than -hackers. I sent this to hackers hoping someone would say suitable modifications to tar/cpio/pax could be made :) Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Backup file formats: tar, cpio, pax, yadda, yadda, yadda
On Thu, 26 Jul 2001, James Howard wrote: :On Thu, 26 Jul 2001, [iso-8859-1] Lars Kühl wrote: : : Neither tar nor cpio is suitable for backup purposes. : Use dump instead. : :A lot of people said this. Why? As near as I can tell, dump isn't that :great either. There is no way to exlude specific directories with dump From the dump(8) manpage: Dump honors the user ``nodump'' flag (UF_NODUMP) on regular files and directories. If a directory is marked ``nodump'', the latter and all files and directories under it will not be backed up. That is, dump propagates the ``nodump'' flag on directories. :and it appears to be quite painful to restore a specific directory (though :I could be wrong about this. Interactive restore isn't that painful, and -x is useful as well. -- [EMAIL PROTECTED] Bipedalism is only a fad. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Backup file formats: tar, cpio, pax, yadda, yadda, yadda
On Thu, Jul 26, 2001 at 02:54:52PM -0400, James Howard wrote: On Thu, 26 Jul 2001, [iso-8859-1] Lars Kühl wrote: Neither tar nor cpio is suitable for backup purposes. Use dump instead. A lot of people said this. Why? As near as I can tell, dump isn't that great either. There is no way to exlude specific directories with dump and it appears to be quite painful to restore a specific directory (though I could be wrong about this. From dump(8): Dump honors the user ``nodump'' flag (UF_NODUMP) on regular files and di- rectories. If a directory is marked ``nodump'', the latter and all files and directories under it will not be backed up. That is, dump propagates the ``nodump'' flag on directories. (Note that the recursive nature of the flag only became available in a release starting with FreeBSD 4.3). Restoring a particular directory is quite easy. Interactive mode is my favourite way of doing that. See restore(8). -- Greg LewisEmail : [EMAIL PROTECTED] Eyes Beyond Mobile: 0419 868 494 Information TechnologyWeb : http://www.eyesbeyond.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MPP and new processor designs.
On Wed, 25 Jul 2001, Christopher R. Bowman wrote: Leo Bicknell [EMAIL PROTECTED] wrote: A number of new chips have been released lately, along with some enhancements to existing processors that all fall into the same logic of parallelizing some operations. Why, just today I ran across an article about http://www.theregister.co.uk/content/3/20576.html, which bosts 128 ALU's on a single chip. This got me to thinking about an interesting way of using these chips. Rather than letting the hardware parallelize instructions from a single stream, what about feeding it multiple streams of instructions. That is, treat it like multiple CPU's running two (or more) processes at once. I'm sure the hardware isn't quite designed for this at the moment and so it couldn't just be done, but if you had say 128 ALU's most single user systems could dedicate one ALU to a process and never context switch, in the traditional sense. For systems that run lots of processors the rate limiting on a single process wouldn't be a big issue, and you could gain lots of effiencies in the global aspect by not context-switching in the traditional sense. Does anyone know of something like this being tried? Traditional 2-8 way SMP systems probably don't have enough processors (I'm thinking 64 is a minimum to make this interesting) and require other glue to make multiple independant processors work together. Has anyone tried this with them all in one package, all clocked together, etc? To answer the question, Does anyone know of something like this being tried? the answer is yes, all this has been done before. There were actually some data flow features in one of the IBM supercomputers from the 1960's, and the Denelcor HEP from the 1980's was similar to what the above description sounds like, although I don't see a lot of details so I can't be sure. If anyone is interested in parallel architectures, they might want to read archives of the Usenet newsgroup comp.arch, which carried news of, and debates about, these and many more architectural ideas. IEEE Micro during the 1990's carried many good articles on architectural issues. To summarize 40 years of debate about these issues [ ;-) ;-) ;-) ] a few widely accepted comp.arch principles would be: - Other technologies will play minor roles until CMOS runs out of gas, which should happen any day now ;-) (this prediction has been continous for the last decade). - Since the mid-70's (that is 25 years now), logic/gates/real-estate are no longer (economically) scarce - Therefore, the key to the value/efficiency of any computer architecture is how well it uses memory - There are two key components to memory hierarchy performance- latency and bandwidth - Different applications have different requirements wrt latency and B/W - some require fastest possible effective latency (traditional jobs); some can benefit from greatly increased B/W at the expense of increased latency (traditional supercomputer jobs, including large numerical simulations, image processing, and some other vectorizable jobs); some jobs are amenable to the availability of large numbers of process threads working on the parts of a decomposed problem (parallelizable jobs) The short answer is that a tremendous amount of time and energy has gone to working on various approaches to these problems; many books have been written, papers published, and there has been a large knowledge base built up over the years. As I work for the above mentioned processor company, I though I might jump in here rather quickly and dispel an notion that you will be running any type of Linux or Unix on these processors any time soon. This chip is a reconfigurable data flow architecture with support for control flow. You really need to think about this chip in the dataflow paradigm. In addition you have to examine what the reporter said. While it is true that there are 128 ALUs on the chip and that it can perform in the neighborhood of 15BOPs these are only ALUs, they are not full processors. They don't run a program as you would on a typical von Neumann processor. The ALUs don't even have a program counter (not to mention MMUs). Instead, to program one of these chips you tell each ALU what function to perform and tell the ALUs how their input and output ports are connected. Then you sit back and watch as the data streams through in a pipelined fashion. Because all ALUs operate in parallel you can get some spectacular operations/second counts even at low frequencies. Think of it, even at only 100Mhz 100 ALUs operating in parallel give you 10 Billion operations per second. : finally, I do think that perhaps we have hit the point of diminishing returns with the current complexity of processors. Part of the Hennesy/Patterson approach to architecture that led to RISC was not reduction of instructions sets because that is good as a
RE: Compaq DL380
Hi all, I finally got some time to do the simple MFC for ida driver. It enables the automatic drive rebuild on Integrated SmartArray controllers. I tested enclosed patch on DL380 (controller firmware 1.42) and it works fine. Could someone please have a look and commit this simple MFC into -stable ? Enjoy! ... and thanks in advance for occasinal commit ;-) Milon -- [EMAIL PROTECTED] ida.patch
Re: Backup file formats: tar, cpio, pax, yadda, yadda, yadda
Neither tar nor cpio is suitable for backup purposes. Well, my answer wasn't sufficiently exact. The question behind is whether you want to back up a number of files or a file system. For the latter case you need a tool that has sufficient knowledge of the file system. Therefore Use dump instead. ...for saving file systems. ~ ~ BTW this is a subject for -questions rather than -hackers. I sent this to hackers hoping someone would say suitable modifications to tar/cpio/pax could be made :) Eventually that would lead to another dump(8-) Lars To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cluster size
* Terry Lambert [EMAIL PROTECTED] [010726 12:51] wrote: Alfred Perlstein wrote: On Thu, Jul 26, 2001 at 10:18:09AM -0700, Terry Lambert wrote: The real reason behind all this is to make the input and output routines symmetric, since mbuf's can be allocated at interrupt, and clusters can't (or couldn't, last time I looked at 4.3). They can. Whether they are or not I'm not sure. Er, wouldn't that be the only way for cards to refil thier DMA recieve buffers? Look at the Tigon II and FXP drivers. The allocations in the macros turn into m_get, not m_clusterget. It looks like (at least in -current) that fxp_intr() calls fxp_add_rfabuf() which calls MGETHDR() followed by MCLGET(). -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Why two cards on the same segment...
-- Jonathan M. Slivko [EMAIL PROTECTED] Blinx Networks http://www.blinx.net/ - Original Message - From: Chris Dillon [EMAIL PROTECTED] To: Terry Lambert [EMAIL PROTECTED] Cc: Julian Elischer [EMAIL PROTECTED]; Eugene L. Vorokov [EMAIL PROTECTED]; Soren Kristensen [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, July 26, 2001 4:45 PM Subject: Re: Why two cards on the same segment... On Thu, 26 Jul 2001, Terry Lambert wrote: [...other stuff I've not personally encountered snipped...] ...or the mess the FreeBSD alias code is in, with it demanding netmasks of 255.255.255.255 on aliases, so that aliases and the primary IP _MUST_ have the same netmask instead of different ones (hell, he may just be trying to have two IP's with different netmasks, and the only way he can do it in FreeBSD is to have two cards!). Why would you want multiple IP addresses that belong to the same IP network to have different subnet masks? You'll break the network. If you're saying that you can't put two or more different IP addresses on one NIC that belong to different IP networks, then don't tell my router that, it might decide to stop working. :-) fxp7: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 inet 207.160.214.253 netmask 0xff00 broadcast 207.160.214.255 inet 207.160.214.252 netmask 0x broadcast 207.160.214.252 inet 192.168.254.254 netmask 0xff00 broadcast 192.168.254.255 ether 00:08:c7:07:b2:96 media: Ethernet autoselect (100baseTX full-duplex) status: active Yes, but, I think the issue with the 2 IP classes working is because one is not routable, and therefore it's not a real IP address, and the router knows this, hence it's not reacting to it by stopping to work. As long as you use virtual ip's (192.168.*.*) then there should be no reason why it wouldn't work. However, if your talking about a routable IP address, then you might have a problem, as there is a difference between a virtual IP address and a real (routable) IP address. Just my 0.02 cents. -- Jonathan So, the major reasons for two cards on one segment: to work around bugs in FreeBSD's networking code. The best reason I can think of to put two cards on one segment is for performance reasons. You'll only get a performance benefit if you're attached to a switch, of course. I'm not talking about Fast EtherChannel or other channel bonding or anything like that, just two or more NICs with two or more different IP addresses. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64 (Itanium), PowerPC, and ARM architectures under development - http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: perhaps one of phk's intern projects?
On Thu, 26 Jul 2001, Matthew Jacob wrote: It'd be nice if one could pass a time specification to at in the form of next reboot. -matt Why not just write a script for the command and stick it in /usr/local/etc/rc.d? -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Need a clean room implementation of this function
I'm porting a BSD licensed Java VM from Linux to FreeBSD and ran into the following Linux function which is not implemented in BSDs. To avoid GPL contamination issues, can someone complete[1] the following method in inlined IA-32 assembly ? Intel instruction reference documents an instruction called BTS, which does just this. Thanks! -Arun [1] I've already looked at the Linux implementation - does that disqualify me ? Has anyone dealt with such issues in the past ? /** * test_and_set_bit - Set a bit and return its old value * @nr: Bit to set * @addr: Address to count from * * This operation is atomic and cannot be reordered. * It also implies a memory barrier. */ static __inline__ int test_and_set_bit(int nr, volatile void * addr); To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Why two cards on the same segment...
Yes, but, I think the issue with the 2 IP classes working is because one is not routable, and therefore it's not a real IP address, and the router knows this, hence it's not reacting to it by stopping to work. As long as you use virtual ip's (192.168.*.*) then there should be no reason why it wouldn't work. However, if your talking about a routable IP address, then you might have a problem, as there is a difference between a virtual IP address and a real (routable) IP address. Just my 0.02 cents. -- Jonathan I don't think the networking code knows/cares if something is private or public IP space. I might be off here but I think the real problem with two seperate networks on one card (or even on two cards) would be the default route (can't have two right?) and which IP address gets used as the 'source IP' on packets leaving the system. -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Why two cards on the same segment...
Yes, but what that snippet showed from ifconfig showed 2 networks, 2 from public IP space and 1 from private IP space, and since it's working the networking code must know/care about something that it's being fed. -- Jonathan -- Jonathan M. Slivko [EMAIL PROTECTED] Blinx Networks http://www.blinx.net/ - Original Message - From: Steven Ames [EMAIL PROTECTED] To: Jonathan M. Slivko [EMAIL PROTECTED]; Chris Dillon [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, July 26, 2001 4:56 PM Subject: Re: Why two cards on the same segment... Yes, but, I think the issue with the 2 IP classes working is because one is not routable, and therefore it's not a real IP address, and the router knows this, hence it's not reacting to it by stopping to work. As long as you use virtual ip's (192.168.*.*) then there should be no reason why it wouldn't work. However, if your talking about a routable IP address, then you might have a problem, as there is a difference between a virtual IP address and a real (routable) IP address. Just my 0.02 cents. -- Jonathan I don't think the networking code knows/cares if something is private or public IP space. I might be off here but I think the real problem with two seperate networks on one card (or even on two cards) would be the default route (can't have two right?) and which IP address gets used as the 'source IP' on packets leaving the system. -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Have a good laugh!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Wind-up A Friend, Colleague, Relative Or Even An Enemy -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Call Windupline and you'll be in stitches! With our new service you're able to wind-up, confuse and bemuse people with a choice of bogus callers that you can transfer to your victim on any UK landline or mobile and then listen in to the call and hear their reaction Don't worry though, they won't be able to hear you, nor tell that you made the call - try it on a speaker phone and a group can hear -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Just use the easy to follow recipe: -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- (i) choose one ripe victim (ii) add Windupline by dialling 0906 736 9265 and select 1 - Wind-up samples 2 - Mr Angry 3 - The Irate Delivery Driver 4 - An Invite To No 10 5 - There's A Bomb In Your Street 6 - You're Wanted At The Police Station 7 - The Tax Inspector 8 - You've Got My Daughter Pregnant (iii) enter your victims number and wait for the transfer (iv) when they answer, prepare yourself and ...enjoy! -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This has got to be the funniest way to wind-up anyone -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- http://www.windupline.co.uk Windupline BCM 1543 London WC1N 3XX United Kingdom Tel: +44 (0)8707 469024 -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Calls to 0906 numbers are charged at £1/min at all times Maximum call duration 5 mins, average 2 mins Please ensure you have the permission of the bill payer before calling -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- You've received this email as you're on our mailing list If however, you do not wish to receive any further emails simply mailto:[EMAIL PROTECTED] with the email address(es) to be removed inserted in the subject line Windupline is a trading name of Portmead UK Ltd who are registered and operate under UK data protection legislation We will honour all remove requests -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Portmead UK Ltd 27 Old Gloucester Street London WC1N 3AF United Kingdom Registered in England Wales 3798100 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Why two cards on the same segment...
Not really. The private IP space probably never leaves that LAN segment so the source IP would get set properly and the default route is irrelevent. Whenever he communicated with a block that is not diretly attached then the code has to choose a source address and then send the packet to the next hop (usually the default route unless you have a dynamic protocol daemon (routed/gated/etc) running. As long as your just communicating to directly attached subnets everything will work peachy regardless of public/private/quantity/netmask. -Steve Yes, but what that snippet showed from ifconfig showed 2 networks, 2 from public IP space and 1 from private IP space, and since it's working the networking code must know/care about something that it's being fed. -- Jonathan -- Jonathan M. Slivko [EMAIL PROTECTED] Blinx Networks http://www.blinx.net/ - Original Message - From: Steven Ames [EMAIL PROTECTED] To: Jonathan M. Slivko [EMAIL PROTECTED]; Chris Dillon [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, July 26, 2001 4:56 PM Subject: Re: Why two cards on the same segment... Yes, but, I think the issue with the 2 IP classes working is because one is not routable, and therefore it's not a real IP address, and the router knows this, hence it's not reacting to it by stopping to work. As long as you use virtual ip's (192.168.*.*) then there should be no reason why it wouldn't work. However, if your talking about a routable IP address, then you might have a problem, as there is a difference between a virtual IP address and a real (routable) IP address. Just my 0.02 cents. -- Jonathan I don't think the networking code knows/cares if something is private or public IP space. I might be off here but I think the real problem with two seperate networks on one card (or even on two cards) would be the default route (can't have two right?) and which IP address gets used as the 'source IP' on packets leaving the system. -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Have a good laugh!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Wind-up A Friend, Colleague, Relative Or Even An Enemy -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Call Windupline and you'll be in stitches! With our new service you're able to wind-up, confuse and bemuse people with a choice of bogus callers that you can transfer to your victim on any UK landline or mobile and then listen in to the call and hear their reaction Don't worry though, they won't be able to hear you, nor tell that you made the call - try it on a speaker phone and a group can hear -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Just use the easy to follow recipe: -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- (i) choose one ripe victim (ii) add Windupline by dialling 0906 736 9265 and select 1 - Wind-up samples 2 - Mr Angry 3 - The Irate Delivery Driver 4 - An Invite To No 10 5 - There's A Bomb In Your Street 6 - You're Wanted At The Police Station 7 - The Tax Inspector 8 - You've Got My Daughter Pregnant (iii) enter your victims number and wait for the transfer (iv) when they answer, prepare yourself and ...enjoy! -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This has got to be the funniest way to wind-up anyone -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- http://www.windupline.co.uk Windupline BCM 1543 London WC1N 3XX United Kingdom Tel: +44 (0)8707 469024 -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Calls to 0906 numbers are charged at £1/min at all times Maximum call duration 5 mins, average 2 mins Please ensure you have the permission of the bill payer before calling -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- You've received this email as you're on our mailing list If however, you do not wish to receive any further emails simply mailto:[EMAIL PROTECTED] with the email address(es) to be removed inserted in the subject line Windupline is a trading name of Portmead UK Ltd who are registered and operate under UK data protection legislation We will honour all remove requests -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Portmead UK Ltd 27 Old Gloucester Street London WC1N 3AF United Kingdom Registered in England Wales 3798100 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Starting natd
On Thu, 26 Jul 2001, Daniel C. Sobral wrote: It seems that rc.network requires an interface to be specified for natd for it to be started. Alas, I do not and cannot specify an interface for natd, using alias_address instead (and disliking even that, since what I really want is static nat). You can specify an IP and rc.network autodetects to use -n or -a. natd_interface=a.b.c.d is ok (at least on 4.2) Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Why two cards on the same segment...
Then whats the alternative, it just works out of thin air? Now i'm really curious to find out how this is being done, although I have seen it done on my own systems in the past, just not by me, so i'm intrigued to find out how this is being accomplished. -- Jonathan -- Jonathan M. Slivko [EMAIL PROTECTED] Blinx Networks http://www.blinx.net/ - Original Message - From: Steven Ames [EMAIL PROTECTED] To: Jonathan M. Slivko [EMAIL PROTECTED]; Chris Dillon [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, July 26, 2001 5:07 PM Subject: Re: Why two cards on the same segment... Not really. The private IP space probably never leaves that LAN segment so the source IP would get set properly and the default route is irrelevent. Whenever he communicated with a block that is not diretly attached then the code has to choose a source address and then send the packet to the next hop (usually the default route unless you have a dynamic protocol daemon (routed/gated/etc) running. As long as your just communicating to directly attached subnets everything will work peachy regardless of public/private/quantity/netmask. -Steve Yes, but what that snippet showed from ifconfig showed 2 networks, 2 from public IP space and 1 from private IP space, and since it's working the networking code must know/care about something that it's being fed. -- Jonathan -- Jonathan M. Slivko [EMAIL PROTECTED] Blinx Networks http://www.blinx.net/ - Original Message - From: Steven Ames [EMAIL PROTECTED] To: Jonathan M. Slivko [EMAIL PROTECTED]; Chris Dillon [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, July 26, 2001 4:56 PM Subject: Re: Why two cards on the same segment... Yes, but, I think the issue with the 2 IP classes working is because one is not routable, and therefore it's not a real IP address, and the router knows this, hence it's not reacting to it by stopping to work. As long as you use virtual ip's (192.168.*.*) then there should be no reason why it wouldn't work. However, if your talking about a routable IP address, then you might have a problem, as there is a difference between a virtual IP address and a real (routable) IP address. Just my 0.02 cents. -- Jonathan I don't think the networking code knows/cares if something is private or public IP space. I might be off here but I think the real problem with two seperate networks on one card (or even on two cards) would be the default route (can't have two right?) and which IP address gets used as the 'source IP' on packets leaving the system. -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Need a clean room implementation of this function
On Thu, Jul 26, 2001 at 01:59:13PM -0700, Arun Sharma wrote: /** * test_and_set_bit - Set a bit and return its old value * @nr: Bit to set * @addr: Address to count from * * This operation is atomic and cannot be reordered. * It also implies a memory barrier. */ static __inline__ int test_and_set_bit(int nr, volatile void * addr); -current has a lot of atomic functions in src/sys/i386/include/atomic.h. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Why two cards on the same segment...
You lost me. How what is being done? You can use ifconfig to assign as many blocks/netmasks as you feel the urge to. It'll do it. How does it determine what source address to use? I'd be guessing on this one but here's my guess: 1. If your communicating with a directly connected subnet then the OS will use the IP address that's bound to the ethernet card that is within that subnet; 2. If your communicating to a network that is not directly connected then the OS will use (here's where I get guesswork though I plan to test this when I leave work) either the main IP address (i.e. the one that wasn't created as an 'alias') or the ip address bound to the ethernet card that is in the same subnet as the next hop. -Steve Then whats the alternative, it just works out of thin air? Now i'm really curious to find out how this is being done, although I have seen it done on my own systems in the past, just not by me, so i'm intrigued to find out how this is being accomplished. -- Jonathan -- Jonathan M. Slivko [EMAIL PROTECTED] Blinx Networks http://www.blinx.net/ - Original Message - From: Steven Ames [EMAIL PROTECTED] To: Jonathan M. Slivko [EMAIL PROTECTED]; Chris Dillon [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, July 26, 2001 5:07 PM Subject: Re: Why two cards on the same segment... Not really. The private IP space probably never leaves that LAN segment so the source IP would get set properly and the default route is irrelevent. Whenever he communicated with a block that is not diretly attached then the code has to choose a source address and then send the packet to the next hop (usually the default route unless you have a dynamic protocol daemon (routed/gated/etc) running. As long as your just communicating to directly attached subnets everything will work peachy regardless of public/private/quantity/netmask. -Steve Yes, but what that snippet showed from ifconfig showed 2 networks, 2 from public IP space and 1 from private IP space, and since it's working the networking code must know/care about something that it's being fed. -- Jonathan -- Jonathan M. Slivko [EMAIL PROTECTED] Blinx Networks http://www.blinx.net/ - Original Message - From: Steven Ames [EMAIL PROTECTED] To: Jonathan M. Slivko [EMAIL PROTECTED]; Chris Dillon [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, July 26, 2001 4:56 PM Subject: Re: Why two cards on the same segment... Yes, but, I think the issue with the 2 IP classes working is because one is not routable, and therefore it's not a real IP address, and the router knows this, hence it's not reacting to it by stopping to work. As long as you use virtual ip's (192.168.*.*) then there should be no reason why it wouldn't work. However, if your talking about a routable IP address, then you might have a problem, as there is a difference between a virtual IP address and a real (routable) IP address. Just my 0.02 cents. -- Jonathan I don't think the networking code knows/cares if something is private or public IP space. I might be off here but I think the real problem with two seperate networks on one card (or even on two cards) would be the default route (can't have two right?) and which IP address gets used as the 'source IP' on packets leaving the system. -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Why two cards on the same segment...
:Not really. The private IP space probably never leaves that LAN segment so :the source IP would get set properly and the default route is irrelevent. :Whenever :he communicated with a block that is not diretly attached then the code has :to :choose a source address and then send the packet to the next hop (usually :the :default route unless you have a dynamic protocol daemon (routed/gated/etc) :running. As long as your just communicating to directly attached subnets :everything :will work peachy regardless of public/private/quantity/netmask. : :-Steve I wish it were that easy. If you have two interfaces on the same LAN segment, but one is configured with an internal IP and one is configured with an external IP, and the default route points out the interface configured with the external IP, then you are ok. If you have one interface with *two* ip addresses. For example (taking a real life example): ash:/home/dillon ifconfig fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 208.161.114.66 netmask 0xffc0 broadcast 208.161.114.127 inet 10.0.0.3 netmask 0xff00 broadcast 10.0.0.255 ether 00:b0:d0:49:3b:fd media: Ethernet autoselect (100baseTX full-duplex) status: active Then the 'source IP' address the machine uses is completely up in the air. It could be the external IP, or the internal IP, and it could change out from under you if you manipulate the interface with ifconfig. You have to explicitly bind to the correct source IP if you care. For our machines I bind our external services specifically to the external IP. Beyond that I usually don't care because I NAT-out our internal IP space anyway, so any packets sent 'from' an internal IP to the internet wind up going through the NAT, which hides the fact that the source machine chose the wrong IP. -Matt : Yes, but what that snippet showed from ifconfig showed 2 networks, 2 from : public IP space and 1 from private IP space, and since it's working the : networking code must know/care about something that it's being fed. -- : Jonathan : : -- : Jonathan M. Slivko [EMAIL PROTECTED] : Blinx Networks : http://www.blinx.net/ : : - Original Message - : From: Steven Ames [EMAIL PROTECTED] : To: Jonathan M. Slivko [EMAIL PROTECTED]; Chris Dillon : [EMAIL PROTECTED]; [EMAIL PROTECTED] : Sent: Thursday, July 26, 2001 4:56 PM : Subject: Re: Why two cards on the same segment... : : : Yes, but, I think the issue with the 2 IP classes working is because :one : is : not routable, and therefore it's not a real :IP address, and the router knows this, hence it's not reacting to it :by : stopping to work. As long as you use virtual : ip's (192.168.*.*) then there should be no reason why it wouldn't :work. : However, if your talking about a routable : IP address, then you might have a problem, as there is a difference : between : a virtual IP address and a real (routable) : IP address. Just my 0.02 cents. -- Jonathan : : I don't think the networking code knows/cares if something is private or : public IP space. I might be off here but I think the real problem with : two seperate networks on one card (or even on two cards) would be : the default route (can't have two right?) and which IP address gets : used as the 'source IP' on packets leaving the system. : : -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: Need a clean room implementation of this function
On 26-Jul-01 Arun Sharma wrote:
I'm porting a BSD licensed Java VM from Linux to FreeBSD and ran into
the following Linux function which is not implemented in BSDs.
To avoid GPL contamination issues, can someone complete[1] the following
method in inlined IA-32 assembly ? Intel instruction reference documents
an instruction called BTS, which does just this.
You might be able to rewrite the code to use atomic_cmpset() instead of
test_and_set_bit() (which you can steal from machine/atomic.h in -current).
You can emulate this exact operation with a loop using atomic_cmpset* if
needed:
{
int val;
do {
val = *(int *)addr;
} while (atomic_cmpset_int(addr, val, val | (1 nr) == 0);
return (val (1 nr));
}
If the code in question is just using a single bit in a word as a spinlock like
so:
while (test_and_set_bit(0, lock_var))
;
then you can replace that with an atomic_cmpset loop:
while (atomic_cmpset_int(lock_var, 0, 1) == 0)
;
However, you will want to use appropriate memory barriers for this to work well
on SMP systems (and if you want this portable to other archs at all). In that
case you should use an 'acquire' barrier to acquire the lock, and a 'release'
barrier to release the lock. Thus:
/* lock critical region */
while (atomic_cmpset_acq_int(lock_var, 0, 1) == 0)
; /* spin */
...
/* release lock */
atomic_store_rel_int(lock_var, 0);
--
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-hackers in the body of the message
Re: Why two cards on the same segment...
On Thu, 26 Jul 2001, Jonathan M. Slivko wrote: Yes, but, I think the issue with the 2 IP classes working is because one is not routable, and therefore it's not a real IP address, and the router knows this, hence it's not reacting to it by stopping to work. As long as you use virtual ip's (192.168.*.*) then there should be no reason why it wouldn't work. However, if your talking about a routable IP address, then you might have a problem, as there is a difference between a virtual IP address and a real (routable) IP address. Just my 0.02 cents. -- Jonathan There is no difference. An RFC1918 address is just as real as any other IP address as far as any IP stack or network is concerned. The difference is that we, as humans, have decided those addresses are not to cross certain boundaries, and it is up to us to make sure they don't. Except for my edge router, my other routers could care less that I'm using RFC1918 addresses and in fact they don't know any better. I could just as easily stick my 207.160.213 network, another real network, on there right alongside the 207.160.214 network (and I did, at one time) with no problems. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64 (Itanium), PowerPC, and ARM architectures under development - http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Need a clean room implementation of this function
On Thu, Jul 26, 2001 at 11:15:40PM +0200, Bernd Walter wrote: static __inline__ int test_and_set_bit(int nr, volatile void * addr); -current has a lot of atomic functions in src/sys/i386/include/atomic.h. It has byte, word, int, long level operations - what I want is bit level. -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Need a clean room implementation of this function
On Thu, Jul 26, 2001 at 02:21:06PM -0700, Arun Sharma wrote: On Thu, Jul 26, 2001 at 11:15:40PM +0200, Bernd Walter wrote: static __inline__ int test_and_set_bit(int nr, volatile void * addr); -current has a lot of atomic functions in src/sys/i386/include/atomic.h. It has byte, word, int, long level operations - what I want is bit level. You must have missing something. My version reads the following: [...] ATOMIC_ASM(set, char, orb %b2,%0, v) ATOMIC_ASM(clear,char, andb %b2,%0, ~v) [...] -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Invoking a userland function from kernel
On Wed, 25 Jul 2001 Terry Lambert wrote:
[EMAIL PROTECTED] wrote:
I need pass asynchronously data from kernel
to a userland process, include a quantity variable of
data (void *opaque).
The easiest way to do this is to have the user space process
register a kevent, and then KNOTE() in the kernel when the
event takes place.
Please, look the question at the bottom of this message.
You can't; at least, you can't do exactly that. As others
have pointed out, you would have better luck telling us what
problem it is you are trying to solve, and then letting
people suggest solutions, instead of picking the one true
solution, and then asking us how to implement it.
OK, I'm incorporating the Real Time Protocol RTP into the
FreeBSD Kernel.
I took the RTP Lucent Technologies Library that
provides a high level interface for
developing applications that make use of the
Real Time Transport Protocol (RTP) and I changed
many of the original API library functions
to kernel systems calls, and it works fine.
Here you look about the original library:
http://www-out.bell-labs.com/project/RTPlib/DOCS/rtp_api.hrml
Now, I need manage Timed Events:
Two RTP related events must occur which are timed. They are:
1.RTCP (control RTP packages) reports must be sent periodically.
2.BYE (a control RTP package) packets may be reconsidered for transmission.
To support scheduling, timed events are handled by two functions,
RTPSchedule() and RTPExecute().
The first of these functions is written by the user(user process).
It is called by the RTP kernel module (originally the library)
to request scheduling of events at some predetermined time.
The user is responsible for writing the function to schedule
the event with whatever mechanism is appropriate for the application.
The second function is part of the RTP kernel module (originally the
library),
and is to be called upon execution of the timed event.
The specific formats of the functions are:
void RTPSchedule(int id, void* opaque, struct timeval *tp);
rtperror RTPExecute(int id, void* opaque);
The RTP kernel module will call RTPSchedule, and pass it the context cid
and an opaque piece of data, opaque. It will also pass the time for
which the scheduled event is to occur, tp. At the appropriate time,
tp, the application should call RTPExecute, and pass it the opaque
token provided in the call to RTPSchedule, in addition to the identifier
id.
This general mechanism allows for the RTP kernel module to schedule
arbitrary
timed events. All information about the nature of the events is kept
internal. The opaque data is used internally to identify particular events.
For example the following simple code would implement
the RTP Scheduler in the userland process:
/* Maintain a simple queue of events. */
/* An element queue */
struct evt_queue_elt {
int id;
void* event_opaque;
double event_time;
struct evt_queue_elt *next;
};
/* A queue */
static struct evt_queue_elt* evt_queue = NULL;
/* An the kernel would call this RTPSchedule
function when it needs to schedule an event.
*/
void RTPSchedule(int id, void* opaque, struct timeval *tp)
{
struct evt_queue_elt *elt;
elt = (struct evt_queue_elt *) malloc(sizeof(struct evt_queue_elt));
if (elt == NULL)
return;
elt-id = id;
elt-event_opaque = opaque;
elt-event_time = tv2dbl(*tp);
insert_in_evt_queue(elt); /* Here insert element in queue */
return;
}
/* In other place of the user program ... */
struct evt_queue_elt *next;
gettimeofday(now_tv, NULL);
now = tv2dbl(now_tv);
while (evt_queue != NULL evt_queue-event_time = now) {
/* There is a pending RTP event (currently this means there's
* an RTCP packet to send), so run it. */
RTPExecute(evt_queue-id, evt_queue-event_opaque);
/* Advance the queue */
next = evt_queue-next;
free(evt_queue);
evt_queue = next;
}
/* - RTP systemcall RTPExecute() BEGIN - */
#ifndef _SYS_SYSPROTO_H_
struct RTPExecute_args {
int id ;
void* opaque ;
};
#endif
rtperror RTPExecute (p,uap)
struct proc *p;
register struct RTPExecute_args *uap;
{
int id ;
void* opaque ;
int rtp_error;
int rtp_retorno;
cid = uap-cid ;
rtp_error = copyin( uap-opaque , opaque, sizeof( opaque ));
if (rtp_error != RTP_OK )
goto copyin_out;
/* internal kernel work */
rtp_retorno = the_RTPExecute_rtp_internal(id, opaque);
rtp_error = copyout( opaque , uap-opaque , sizeof( opaque ));
if (rtp_error != RTP_OK )
goto copyout_out;
printf(RTPExecute-- Return: %d \n, rtp_retorno );
p-p_retval[0] = rtp_retorno;
return rtp_retorno;
copyin_out:
printf(RTPExecute-- Error at copyin()\n);
goto bailout;
copyout_out:
printf(RTPExecute-- Error at copyout()\n);
bailout:
p-p_retval[0] = rtp_error;
return rtp_error;
}
/* - RTP systemcall RTPExecute() END - */
Other internal functions into the kernel like to
the_RTPExecute_rtp_internal() needs to call
to RTPSchedule() userland function.
So, my original question was:
Into my kernel code, How I can
Re: Need a clean room implementation of this function
On Thu, Jul 26, 2001 at 02:43:24PM -0700, John Baldwin wrote:
{
int val;
do {
val = *(int *)addr;
} while (atomic_cmpset_int(addr, val, val | (1 nr) == 0);
return (val (1 nr));
}
Thanks! I think that'd work. But code using BTS would be
more efficient (fewer cycles).
Many people asked me this question: the code I'm porting is:
http://www.intel.com/research/mrl/orp/
Please see my messages to [EMAIL PROTECTED] about the port.
-Arun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Why two cards on the same segment...
If you have one interface with *two* ip addresses. For example (taking a real life example): ash:/home/dillon ifconfig fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 208.161.114.66 netmask 0xffc0 broadcast 208.161.114.127 inet 10.0.0.3 netmask 0xff00 broadcast 10.0.0.255 ether 00:b0:d0:49:3b:fd media: Ethernet autoselect (100baseTX full-duplex) status: active Then the 'source IP' address the machine uses is completely up in the air. It could be the external IP, or the internal IP, and it could change out from under you if you manipulate the interface with ifconfig. ? For real? If you telnet from your machine to some other machine in the world (mine for instance) your source address could either be 208.161.114.66 (which would work) or 10.0.0.3 (which wouldn't work because my server would have no clue how to send packets back)? traceroutes from your machine fail half the time because your next hop (the external default gateway) doesn't know how to respond to packets with a source address of 10.0.0.3 either? To test that theory I just bound 10.0.0.3/24 to my external interface and initiated some ssh from my server to my office server. In every case it used the public address (not sure why, either because its the 'real' (i.e. non-alias interface) or because that's the IP in the subnet as the gateway). ifconfig ed0 inet 10.0.0.3 netmask 0xff00 alias ed0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 204.120.165.254 netmask 0xfffc broadcast 204.120.165.255 inet 10.0.0.3 netmask 0xff00 broadcast 10.0.0.255 ether 52:54:00:dc:08:ca And it works just fine. The source address is always the public IP. The gateway is 204.120.165.253. I cannot believe its random. On the other hand (haven't tried this in FBSD, but in Solaris it works), if you assign an interface like this: ifconfig ed0 inet 204.120.165.1 netmask 0xff00 ifconfig ed0 inet 204.120.165.2 netmask 0xff00 It will randomly choose one of those addresses (assuming a gateway within that subnet). -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Need a clean room implementation of this function
On Thu, Jul 26, 2001 at 11:59:27PM +0200, Bernd Walter wrote: [...] ATOMIC_ASM(set, char, orb %b2,%0, v) ATOMIC_ASM(clear,char, andb %b2,%0, ~v) [...] That does set, not test-and-set. What I want is exactly what the Intel BTS instruction does: atomically test and set a bit. -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Why two cards on the same segment...
I cannot believe its random. On the other hand (haven't tried this in FBSD, but in Solaris it works), if you assign an interface like this: ifconfig ed0 inet 204.120.165.1 netmask 0xff00 ifconfig ed0 inet 204.120.165.2 netmask 0xff00 Second line should read: ifconfig ed0 inet 204.120.165.2 netmask 0xff00 alias sorry for any confusion. It will randomly choose one of those addresses (assuming a gateway within that subnet). -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Missing incoming data using select()
I have a server that uses non-blocking I/O, and consists of a process which listens and calls accept(), and passes the accepted file descriptors down to child processes for handling the client connection. Currently, it uses select(), though I plan to rewrite it using kqueue. The problem I have is that when I connect from the client, if the client immediately writes to the socket after connect() (blocking), the server's select() does not report the descriptor as being ready for reading, (although tcpdump seems to indicate otherwise). If, however, the client does a sleep(1) after connect() and before write(), it always works. It looks like the data is being sent from the client to the server in all cases, but for some reason, the server looses track of the data if the client sends it right away. Does this have anything to do with passing the file descriptor between processes? Perhaps the postmaster receives the data just before the socket descriptor is passed down to the child server (and before postmaster closes it)? But wouldn't select() also reveal the data queued to the child server if the postmaster did not read it? I am having difficulty figuring out how to track it. Here is the tcpdump output for a successful connection (when the client calls sleep(1) after connect() and before write()) sending 34 bytes, which the server sends right back: 14:43:21.332838 mike.1654 mike.postmaster: S 1995467003:1995467003(0) win 16384 mss 16344 (DF) 14:43:21.332907 mike.postmaster mike.1654: S 2036815264:2036815264(0) ack 1995467004 win 17520 mss 16344 (DF) 14:43:21.332930 mike.1654 mike.postmaster: . ack 1 win 17520 (DF) 14:43:22.358304 mike.1654 mike.postmaster: P 1:35(34) ack 1 win 17520 (DF) 14:43:22.418249 mike.postmaster mike.1654: P 1:69(68) ack 35 win 17520 (DF) 14:43:22.498603 mike.1654 mike.postmaster: F 35:35(0) ack 69 win 17520 (DF) 14:43:22.498663 mike.postmaster mike.1654: . ack 36 win 17520 (DF) 14:43:22.508506 mike.postmaster mike.1654: F 69:69(0) ack 36 win 17520 (DF) 14:43:22.508566 mike.1654 mike.postmaster: . ack 70 win 17520 (DF) Here are the results for an unsuccessful exchange (when the client immediately writes after connect()) 14:40:38.942493 localhost.xnmp localhost.postmaster: S 3152358295:3152358295(0) win 16384 mss 16344 (DF) 14:40:38.942559 localhost.postmaster localhost.xnmp: S 3060360366:3060360366(0) ack 3152358296 win 57344 mss 16344 (DF) 14:40:38.942583 localhost.xnmp localhost.postmaster: . ack 1 win 57344 (DF) 14:40:38.957527 localhost.xnmp localhost.postmaster: P 1:35(34) ack 1 win 57344 (DF) 14:40:39.054852 localhost.postmaster localhost.xnmp: . ack 35 win 57344 (DF) In this case, it appears as if the server does receive the data, (but select() does not report it). Also, netstat does not show any data pending on either the client's or server's queue. This may or may not help, but here is the debug output for an unsuccessful transfer between client and server (with comments). Server Log -- mike@mike ./postmaster /tmp/server # Postmaster listening 16:44:43.192909 PID 3646 : server_chassis : listen() # Postmaster accepts 16:44:44.616683 PID 3646 : mplxr 0x806b000 : accept(): Starting. 16:44:43.193343 PID 3647 : mplxr 0x806a000 : add_descriptor() : connections=1 # Postmaster sends sockfd to child (PID 3646) 16:44:44.622460 PID 3646 : srvr 0x806b000 : assign_socket(): No current child. Selecting first in list. 16:44:44.623868 PID 3646 : srvr 0x806b000 : assign_socket(): Using child 3647 # Server receives sockfd, sets readable adjusts maxfd for select() 16:44:44.667682 PID 3647 : srvr 0x806a000 : process_packet() : Received socket descriptor: sockfd = 5 16:44:44.667872 PID 3647 : mplxr 0x806a000 : add_descriptor() : descriptor=5. maxfd=5 16:44:44.668082 PID 3647 : mplxr 0x806a000 : add_descriptor() : connections=2 # Many select cycles (100), client has already written data, yet select does not show it 16:44:45.147314 PID 3647 : mplxr 0x806a000 : loop(): Zero ready descriptors. 2 connections. maxfd = 5. 16:44:45.207246 PID 3646 : mplxr 0x806b000 : loop(): Zero ready descriptors. 1 connections. maxfd = 4. 16:44:46.326954 PID 3647 : mplxr 0x806a000 : loop() : Socket 5 set to read. # Client terminates, sockfd set readable for close() 16:44:46.335515 PID 3647 : conn 0x8078000 : close() : Closing descriptor 5 16:44:46.335836 PID 3647 : mplxr 0x806a000 : close() : Closed descriptor. New maxfd=4. Now have 1 clients. Client Log -- # Client connects 16:44:44.621727 PID 3653 : mplxr 0xbfbfee08 : add_descriptor() : descriptor=3. maxfd=3 16:44:44.622171 PID 3653 : mplxr 0xbfbfee08 : add_descriptor() : connections=1 # Writes data 16:44:44.622266 PID 3653 : client : test_server() : Loading packet # Enters select() loop 16:44:44.622347 PID 3653 : client 0xbfbfee08 : test_server() : Looping: 10 times. 16:44:44.637189 PID 3653 : mplxr 0xbfbfee08 : loop(): Zero ready descriptors. 1 connections. maxfd = 3. # Data
Re: Why two cards on the same segment...
On Thu, 26 Jul 2001, Matt Dillon wrote: I wish it were that easy. If you have two interfaces on the same LAN segment, but one is configured with an internal IP and one is configured with an external IP, and the default route points out the interface configured with the external IP, then you are ok. If you have one interface with *two* ip addresses. For example (taking a real life example): ash:/home/dillon ifconfig fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 208.161.114.66 netmask 0xffc0 broadcast 208.161.114.127 inet 10.0.0.3 netmask 0xff00 broadcast 10.0.0.255 ether 00:b0:d0:49:3b:fd media: Ethernet autoselect (100baseTX full-duplex) status: active Then the 'source IP' address the machine uses is completely up in the air. It could be the external IP, or the internal IP, and it could change out from under you if you manipulate the interface with ifconfig. You have to explicitly bind to the correct source IP if you care. For our machines I bind our external services specifically to the external IP. Beyond that I usually don't care because I NAT-out our internal IP space anyway, so any packets sent 'from' an internal IP to the internet wind up going through the NAT, which hides the fact that the source machine chose the wrong IP. Hmm.. That hasn't been my experience at all. I have _always_ seen outgoing connections use a source address of the closest interface address that exists on the same IP network as the destination, OR, if it is a non-local destination, then the source is whatever IP address is on the same IP network as the next-hop gateway. If your next-hop gateway is an RFC1918 address, then your source address will be your RFC1918 address on the same subnet, unless you specify otherwise of course. Maybe if you set net.inet.ip.subnets_are_local to 1, then maybe the system will use the primary non-alias address of the closest physical interface, be it a public address or whatever, but I've not tried that. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64 (Itanium), PowerPC, and ARM architectures under development - http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Need a clean room implementation of this function
On Thu, Jul 26, 2001 at 03:11:00PM -0700, Arun Sharma wrote: On Thu, Jul 26, 2001 at 11:59:27PM +0200, Bernd Walter wrote: [...] ATOMIC_ASM(set, char, orb %b2,%0, v) ATOMIC_ASM(clear,char, andb %b2,%0, ~v) [...] That does set, not test-and-set. What I want is exactly what the Intel BTS instruction does: atomically test and set a bit. Ops - but as John Baldwin already showed that cmpset/cmpclear are also part of atomic.h Using the atomic.h functions gives you the ability to port it to alpha and other FreeBSD architectures. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Why two cards on the same segment...
On Thu, Jul 26, 2001 at 05:24:43PM -0500, Chris Dillon wrote: Hmm.. That hasn't been my experience at all. I have _always_ seen outgoing connections use a source address of the closest interface address that exists on the same IP network as the destination, OR, if it is a non-local destination, then the source is whatever IP address is on the same IP network as the next-hop gateway. If your next-hop gateway is an RFC1918 address, then your source address will be your RFC1918 address on the same subnet, unless you specify otherwise of course. Agreed. And, really, isn't that the behavior you _expect_? Any other behavior could be considered a non-POLA. In most situations the source-IP can be determined logically. There are some situations where it can't be determined and that's where random comes in (at least on the Solaris stack, I hate to use that as an example but I have yet to test it under FBSD or look up the code). A good example is when you have multipe IPs on one card from the same subnet and netmask. The only way to determine what _should_ be used as the IP is to maybe use the one that isn't an alias. But what if they are all aliases and the non-alias is RFC1918 but the gateway is out of that public subnet? Under Solaris its potluck. Took me a bit to figure that out. That's why under FBSD when we want multiple IPs from the same subnet (virtual hosting and such) we encourage the use of the 0x netmask. Then that IP cannot be part of the gateway subnet so won't be used as the source IP. It is however reachable from the outside world thanks to ARP. A tricker question is with two NIC each with a public IP (from different subnets). You can't have a seperate gateway for each NIC so most outgoing traffic is really going to go out one interface even if its coming in both interfaces right? If the NICs have IPs from the same subnet then I'm not sure how the outgoing interface (and source IP) is chosen but logically both get used (round robin?). That question will actually take some source delving to figure out as I don't have the tools to just hook up a machine and watch. -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: perhaps one of phk's intern projects?
Because I thought this might be of general utility. On Thu, 26 Jul 2001, Matthew Emmerton wrote: On Thu, 26 Jul 2001, Matthew Jacob wrote: It'd be nice if one could pass a time specification to at in the form of next reboot. -matt Why not just write a script for the command and stick it in /usr/local/etc/rc.d? -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Need a clean room implementation of this function
On 26-Jul-01 Arun Sharma wrote: On Thu, Jul 26, 2001 at 11:59:27PM +0200, Bernd Walter wrote: [...] ATOMIC_ASM(set, char, orb %b2,%0, v) ATOMIC_ASM(clear,char, andb %b2,%0, ~v) [...] That does set, not test-and-set. What I want is exactly what the Intel BTS instruction does: atomically test and set a bit. Unfortunately that is very ia32 specific. The code would be more friendly on alpha and ia64 at least if the algo was changed to use cmpset on a word instead of test-and-set of a bit. If you want, I can look at the code to see where it uses test_and_set() to determine how hard that would be. (It might be very easy to do.) -- 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-hackers in the body of the message
Re: crunched binary oddity
On Thu, Jul 26, 2001 at 12:09:46PM +0100, Ian Dowse wrote: When mount(8) invokes a mount_xxx program, it sets argv[0] to the name of the filesystem (ufs, mfs, nfs etc). Why? -- Ben An art scene of delight I created this to be ... -- Sun Ra To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Need a clean room implementation of this function
On Thu, Jul 26, 2001 at 03:49:58PM -0700, John Baldwin wrote:
That does set, not test-and-set. What I want is exactly what the Intel
BTS instruction does: atomically test and set a bit.
Unfortunately that is very ia32 specific. The code would be more
friendly on alpha and ia64 at least if the algo was changed to use
cmpset on a word instead of test-and-set of a bit.
Another way to look at it is as an IA-32 specific optimization. For
other architectures, we could just use the code you posted earlier.
If you want, I can look at the code to see where it uses test_and_set()
to determine how hard that would be. (It might be very easy to do.)
The piece of code which uses it is attached.
-Arun
inline
void acquire_header_lock (volatile POINTER_SIZE_INT *p_header)
{
while (true) {
// Try to grab the lock.
volatile PVOID free_header =(PVOID)(*p_header BUSY_FORWARDING_BIT_MASK);
volatile PVOID locked_header =(PVOID)((POINTER_SIZE_INT)free_header |
BUSY_FORWARDING_BIT);
assert (locked_header != free_header);
// IA64 - What are the semantics of test_and_set_bit with regards to acq and
rel?
// Hopefully, test_and_set_bit will have acquire semantics and
// test_and_clear_bit will have release semantics.
if ( test_and_set_bit (BUSY_FORWARDING_BIT_OFFSET, (PVOID *)p_header) == 0)
{
assert ((*p_header BUSY_FORWARDING_BIT) == BUSY_FORWARDING_BIT);
return; // got it this is the only way out.
}
// Try until you get the lock.
while ((*p_header BUSY_FORWARDING_BIT) == BUSY_FORWARDING_BIT) {
Sleep (0); // Sleep until it might be free.
}
}
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Why two cards on the same segment...
:.. : You have to explicitly bind to the correct source IP if you care. : : For our machines I bind our external services specifically to the : external IP. Beyond that I usually don't care because I NAT-out our : internal IP space anyway, so any packets sent 'from' an internal IP : to the internet wind up going through the NAT, which hides the fact : that the source machine chose the wrong IP. : : :Hmm.. That hasn't been my experience at all. I have _always_ seen :outgoing connections use a source address of the closest interface :address that exists on the same IP network as the destination, OR, if :it is a non-local destination, then the source is whatever IP address :is on the same IP network as the next-hop gateway. If your next-hop :gateway is an RFC1918 address, then your source address will be your :RFC1918 address on the same subnet, unless you specify otherwise of :course. Maybe if you set net.inet.ip.subnets_are_local to 1, then :maybe the system will use the primary non-alias address of the closest :physical interface, be it a public address or whatever, but I've not :tried that. : :-- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] Huh... your right! How odd. I think someone may have fixed something since I last played with this. I swear it wasn't going that before! I would set up a bunch of ip aliases and it was pot-luck. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Need a clean room implementation of this function
On Thu, Jul 26, 2001 at 03:49:58PM -0700, John Baldwin wrote:
That does set, not test-and-set. What I want is exactly what the Intel
BTS instruction does: atomically test and set a bit.
Unfortunately that is very ia32 specific. The code would be more
friendly on alpha and ia64 at least if the algo was changed to use
cmpset on a word instead of test-and-set of a bit.
Another way to look at it is as an IA-32 specific optimization. For
other architectures, we could just use the code you posted earlier.
If I wasn't going to use a non-blocking synchronization loop, this
is how I'd do it.
static __inline int
test_and_set_bit(int nr, volatile void *addr)
{
char c;
__asm __volatile(lock ; bts %2, %1 ; setc %0
: =br (c) : m (*(volatile int *)addr), r (nr));
return (c != 0);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Network performance tuning.
On Mon, 16 Jul 2001, Terry Lambert wrote: Matt Dillon wrote: Also, the algorithm is less helpful when it has to figure out the optimal transmit buffer size for every new connection (consider a web server). I am considering ripping out the ssthresh junk from the stack, which does not work virtually at all, and using the route table's ssthresh field to set the initial buffer size for the algorithm. The state of the art for initial window size is flow monitoring at the next hop router, with feedback to the host system. A gross approximation is called fast start. ClickArray has a patch for this, which could potentially be released back to FreeBSD; I will check with TPTB... it's a pretty trivial version of the RFC'ed initial window scaling. Two threads here, the first dealing with MBUFs, buffer allocation, etc., which I'm not mentioning (though clearly there is useful work to do). The other thread is SACK, other TCP performance improvements. The state of the art in this case may be TCP Westwood: http://www.cs.ucla.edu/NRL/hpi/papers.html http://www.cs.ucla.edu/NRL/hpi/papers/2001-mobicom-0.ps.gz http://www-dee.poliba.it/dee-web/Personale/mascolo.html (articles on Smith Principle, control theory applied to TCP) The mobicom paper faster recovery algorithm is, AFAIK, the state of the art, providing somewhat improved throughput on congested links, and, significantly improved throughput on lossy wireless links that many of us use as the last hop. -- Hugh LaMaster, M/S 233-21,Email: [EMAIL PROTECTED] NASA Ames Research Center Or:[EMAIL PROTECTED] Moffett Field, CA 94035-1000 Or:[EMAIL PROTECTED] Phone: 650/604-1056 Disc: Unofficial, personal *opinion*. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: perhaps one of phk's intern projects?
On Thu, 26 Jul 2001, Matthew Jacob wrote:
It'd be nice if one could pass a time specification to at in the form
of next reboot.
-matt
On Thu, 26 Jul 2001, Matthew Emmerton replied:
Why not just write a script for the command and stick it in
/usr/local/etc/rc.d?
-- Matt Emmerton
On Thu, Jul 26, 2001 at 03:45:58PM -0700, Matthew Jacob replied:
Because I thought this might be of general utility.
Okay, try the attached patch. If this is really something that might be
generally usefully I can submit the patch as a PR.
It allows at reboot and at reboot + 1 hour, etc.
It does it by sticking the job in the queue with the filename prefixed
with _ (yeah, a bit ugly, it was the first thing that came to me) and
with the runtime based on the epoch instead of the current time.
Adding:
@reboot root /usr/libexec/atrun -b
to /etc/crontab causes atrun(8) to rename all of these jobs adding the
current time to the jobs runtime.
% echo echo test | at reboot
Job 19 will be executed using /bin/sh
% echo echo test | at reboot + 90 minutes
Job 20 will be executed using /bin/sh
% atq
DateOwner Queue Job#
REBOOT dchapes c 19
REBOOT+01:30:00 dchapes c 20
$ date; /usr/libexec/atrun -b
% atq -v
DateOwner Queue Job#
22:34:00 07/26/01 dchapes c 20
21:04:00 07/26/01 dchapes c(done) 19
--
Dave Chapeskie [EMAIL PROTECTED]
OpenPGP Key KeyId: 3D2B6B34
Index: usr.bin/at/at.h
===
RCS file: /cvs/FreeBSD/src/usr.bin/at/at.h,v
retrieving revision 1.5
diff -u -r1.5 at.h
--- usr.bin/at/at.h 2001/07/24 14:15:51 1.5
+++ usr.bin/at/at.h 2001/07/26 22:38:53
@@ -29,3 +29,4 @@
extern char *namep;
extern char atfile[];
extern char atverify;
+extern int reboot_time;
Index: usr.bin/at/parsetime.c
===
RCS file: /cvs/FreeBSD/src/usr.bin/at/parsetime.c,v
retrieving revision 1.21
diff -u -r1.21 parsetime.c
--- usr.bin/at/parsetime.c 2001/07/24 14:15:51 1.21
+++ usr.bin/at/parsetime.c 2001/07/26 23:28:28
@@ -25,7 +25,7 @@
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
- * at [NOW] PLUS NUMBER MINUTES|HOURS|DAYS|WEEKS
+ * at [NOW|REBOOT] PLUS NUMBER MINUTES|HOURS|DAYS|WEEKS
* /NUMBER [DOT NUMBER] [AM|PM]\ /[MONTH NUMBER [NUMBER]] \
* |NOON | |[TOMORROW] |
* |MIDNIGHT | |[DAY OF WEEK] |
@@ -63,7 +63,7 @@
enum { /* symbols */
MIDNIGHT, NOON, TEATIME,
-PM, AM, TOMORROW, TODAY, NOW,
+PM, AM, TOMORROW, TODAY, NOW, REBOOT,
MINUTES, HOURS, DAYS, WEEKS, MONTHS, YEARS,
NUMBER, PLUS, DOT, SLASH, ID, JUNK,
JAN, FEB, MAR, APR, MAY, JUN,
@@ -86,6 +86,7 @@
{ tomorrow, TOMORROW,0 },/* execute 24 hours from time */
{ today, TODAY, 0 }, /* execute today - don't advance time */
{ now, NOW,0 }, /* opt prefix for PLUS */
+{ reboot, REBOOT, 0 }, /* execute on next reboot */
{ minute, MINUTES,0 }, /* minutes multiplier */
{ minutes, MINUTES,1 }, /* (pluralized) */
@@ -280,7 +281,7 @@
/*
* plus() parses a now + time
*
- * at [NOW] PLUS NUMBER [MINUTES|HOURS|DAYS|WEEKS|MONTHS|YEARS]
+ * at [NOW|REBOOT] PLUS NUMBER [MINUTES|HOURS|DAYS|WEEKS|MONTHS|YEARS]
*
*/
@@ -563,6 +564,7 @@
*/
time_t nowtimer, runtimer;
struct tm nowtime, runtime;
+int t;
int hr = 0;
/* this MUST be initialized to zero for midnight/noon/teatime */
@@ -579,6 +581,22 @@
init_scanner(argc-optind, argv+optind);
switch (token()) {
+case REBOOT:
+ reboot_time = 1;
+ /* Reset now to be the epoch */
+ nowtimer = 0;
+ nowtime = *localtime(nowtimer);
+ runtime = nowtime;
+ runtime.tm_sec = 0;
+ runtime.tm_isdst = 0;
+
+ t = token();
+ if (t == PLUS)
+ plus(runtime);
+ else if (t != EOF)
+ plonk(sc_tokid);
+ break;
+
case NOW: /* now is optional prefix for PLUS tree */
expect(PLUS);
case PLUS:
Index: usr.bin/at/at.c
===
RCS file: /cvs/FreeBSD/src/usr.bin/at/at.c,v
retrieving revision 1.19
diff -u -r1.19 at.c
--- usr.bin/at/at.c 2001/07/24 14:15:51 1.19
+++ usr.bin/at/at.c 2001/07/26 23:53:47
@@ -108,7 +108,8 @@
extern char **environ;
int fcreated;
-char atfile[] = ATJOB_DIR 12345678901234;
+char atfile[] = ATJOB_DIR _Q1234512345678;
+int reboot_time = 0; /* if 'reboot' was specified */
char *atinput = (char*)0; /* where to get input from */
char atqueue = 0; /* which queue to examine for jobs (atq)
Re: Starting natd
Doug White wrote: On Thu, 26 Jul 2001, Daniel C. Sobral wrote: It seems that rc.network requires an interface to be specified for natd for it to be started. Alas, I do not and cannot specify an interface for natd, using alias_address instead (and disliking even that, since what I really want is static nat). You can specify an IP and rc.network autodetects to use -n or -a. natd_interface=a.b.c.d is ok (at least on 4.2) Oh! For lack of reading docs... I thought it selected the interface by IP instead of using alias_address... -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] wow regex humor... I'm a geek To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Backup file formats: tar, cpio, pax, yadda, yadda, yadda
In message [EMAIL PROTECTED] James Howard writes: : Both tar and cpio seem to have problems doing backups on my : server. Looking at the pax manpage, we see this: Use dump. Otherwise, you will lose. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: perhaps one of phk's intern projects?
Matthew Jacob wrote: On Thu, 26 Jul 2001, Matthew Emmerton wrote: On Thu, 26 Jul 2001, Matthew Jacob wrote: It'd be nice if one could pass a time specification to at in the form of next reboot. -matt Why not just write a script for the command and stick it in /usr/local/etc/rc.d? Because I thought this might be of general utility. 'at next reboot' would only be run once, on the NEXT reboot, right? rc.d is for things you want run on EVERY reboot. This does almost smack of Microsoft, though. ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Re[2]: perhaps one of phk's intern projects?
Hmm. 'at teatime' seems the same as 'at reboot' On Fri, 27 Jul 2001, Igor Podlesny wrote: On Thu, 26 Jul 2001, Matthew Jacob wrote: It'd be nice if one could pass a time specification to at in the form of next reboot. look... there is a big difference between time specification in at-program and suggested reboot keyword... I'd say it is like incompatible types... messing up time values and conditions like reboot which are certainly kept within time but AREN'T time values by itself. from man: ... At allows some moderately complex time specifications. ... but it's always foreseen when precisely the action will have it place if the power is on and everything in system works ok. In case of reboot, this statement fails. So, I deem, it's not worth implementation within 'at' syntax. If somebody want such thing as 'do something on the next reboot', let's write another program (call it onreboot for e.g.) and try to use it. Although I bet, it isn't so necessary as it could seemed at first glance. -matt On Thu, 26 Jul 2001, Matthew Emmerton replied: Why not just write a script for the command and stick it in /usr/local/etc/rc.d? -- Matt Emmerton On Thu, Jul 26, 2001 at 03:45:58PM -0700, Matthew Jacob replied: Because I thought this might be of general utility. Okay, try the attached patch. If this is really something that might be generally usefully I can submit the patch as a PR. It allows at reboot and at reboot + 1 hour, etc. It does it by sticking the job in the queue with the filename prefixed with _ (yeah, a bit ugly, it was the first thing that came to me) and with the runtime based on the epoch instead of the current time. Adding: @reboot root /usr/libexec/atrun -b to /etc/crontab causes atrun(8) to rename all of these jobs adding the current time to the jobs runtime. % echo echo test | at reboot Job 19 will be executed using /bin/sh % echo echo test | at reboot + 90 minutes Job 20 will be executed using /bin/sh % atq DateOwner Queue Job# REBOOT dchapes c 19 REBOOT+01:30:00 dchapes c 20 what if a user rebooted the box, before this REBOOT+1:30:00 has been occured? will it be discarded or what? $ date; /usr/libexec/atrun -b % atq -v DateOwner Queue Job# 22:34:00 07/26/01 dchapes c 20 21:04:00 07/26/01 dchapes c(done) 19 -- Igormailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Re[4]: perhaps one of phk's intern projects?
You're being somewhat obtuse. Complicated times such as 'teatime' and 'reboot' are explicitly allowed. On Fri, 27 Jul 2001, Igor Podlesny wrote: Hmm. 'at teatime' seems the same as 'at reboot' excerpt from man 1 at which can be seen at http://www.freebsd.org/cgi/man.cgi?query=atapropos=0sektion=0manpath=FreeBSD+4.3-RELEASEformat=html ...You may also specify midnight, noon, or teatime (4pm) and you can have... So you mean you always reboot your system at 4pm? ;) On Fri, 27 Jul 2001, Igor Podlesny wrote: On Thu, 26 Jul 2001, Matthew Jacob wrote: It'd be nice if one could pass a time specification to at in the form of next reboot. look... there is a big difference between time specification in at-program and suggested reboot keyword... I'd say it is like incompatible types... messing up time values and conditions like reboot which are certainly kept within time but AREN'T time values by itself. from man: ... At allows some moderately complex time specifications. ... but it's always foreseen when precisely the action will have it place if the power is on and everything in system works ok. In case of reboot, this statement fails. So, I deem, it's not worth implementation within 'at' syntax. If somebody want such thing as 'do something on the next reboot', let's write another program (call it onreboot for e.g.) and try to use it. Although I bet, it isn't so necessary as it could seemed at first glance. -matt On Thu, 26 Jul 2001, Matthew Emmerton replied: Why not just write a script for the command and stick it in /usr/local/etc/rc.d? -- Matt Emmerton On Thu, Jul 26, 2001 at 03:45:58PM -0700, Matthew Jacob replied: Because I thought this might be of general utility. Okay, try the attached patch. If this is really something that might be generally usefully I can submit the patch as a PR. It allows at reboot and at reboot + 1 hour, etc. It does it by sticking the job in the queue with the filename prefixed with _ (yeah, a bit ugly, it was the first thing that came to me) and with the runtime based on the epoch instead of the current time. Adding: @reboot root /usr/libexec/atrun -b to /etc/crontab causes atrun(8) to rename all of these jobs adding the current time to the jobs runtime. % echo echo test | at reboot Job 19 will be executed using /bin/sh % echo echo test | at reboot + 90 minutes Job 20 will be executed using /bin/sh % atq DateOwner Queue Job# REBOOT dchapes c 19 REBOOT+01:30:00 dchapes c 20 what if a user rebooted the box, before this REBOOT+1:30:00 has been occured? will it be discarded or what? $ date; /usr/libexec/atrun -b % atq -v DateOwner Queue Job# 22:34:00 07/26/01 dchapes c 20 21:04:00 07/26/01 dchapes c(done) 19 -- Igormailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Igormailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cluster size
Bosko Milekic wrote:
Er, wouldn't that be the only way for cards to refil thier DMA
recieve buffers?
Look at the Tigon II and FXP drivers. The allocations in
the macros turn into m_get, not m_clusterget.
From if_fxp.c (fxp_add_rfabuf(), sometimes called from fxp_intr()):
MGETHDR(...); -- get mbuf
if (m != NULL) {
MCLGET(...); -- get cluster
...
}
Yes, I had misread things. Alfred pointed this out to me in
person, earlier. I had been reading the jumbogram code,
which uses a seperate buffer space, and then just incorrectly
assumed.
Thanks for getting thecorrection into the list archives, so
that future readers will be less confused: you spared me
having to do the same.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
