Re: two soundcards and realplayer
Martin Ván(a wrote: Hi, I use two soundcards on my Freebsd5.1 box - Sb Live and SB AWE64, FreeBSD somehow figured out that Live is better than Awe and made it primary soundcard. The reason I have AWE still in computer, is it's amplyfing skills /2x4W/ so I don't need aditional amplyfier. With Xmms it's fine, I just changed confile and enjoy music. But I can't figure out how to swap soundcards in RealPlayer and Mplayer. Is there a way how to change it system wide? Thank you Martin Well, I suppose you could do something like mv /dev/dsp0 /dev/dsp.tmp mv /dev/dsp1 /dev/dsp0 mv /dev/dsp.tmp /dev/dsp1 Not sure how terribly well that'd work (and it's a horrendous hack), though you can select the output device in mplayer with the ao: option. I don't know anything about RealPlayer, so I wouldn't be able to help you there. --Devon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: two soundcards and realplayer
Martin V?n(a wrote: I use two soundcards on my Freebsd5.1 box - Sb Live and SB AWE64, FreeBSD somehow figured out that Live is better than Awe and made it primary soundcard. ... But I can't figure out how to swap soundcards in The cards are numbered in the order in which they're detected. Assuming both are physical cards, try swapping their slots. Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Boot Problem
This may be a complete newbie question, or it may have been answered before but I would appreciate any help or input that can be provided. I have a Sony VAIO PCG-GRZ615M laptop which I'm trying to install FreeBSD on. I boot from the CD and then try selecting each one of the 7 boot options however each option I pick returns the below and then the system reboots, as such I can not start the installation. -- fwohci0: Link S100, max_rec 2 bytes fwohci0: max_rec2 - 512 fwohci0: bus_OPT 0x0 - 0xf8008000 fwohci0: fwohci_set_intr: 1 firewire :IEEE1394(firewire)Bus on fwohci0 fatal trap 12: page fault while in Kernel mode fault virtual address = 0x2c fault code = supervisor read, page not present instruction pointer = 0x8 :0xc02e5a50 Stack pointer = 0x10 :0xc0b2e8c4 frame pointer = 0x10 :0xc0b2e8c8 code segment = base 0x0, limit 0xf, type 0x1b = DPL0, pres 1, def32 1, gran 1 processor eflags = interrupte enabled, resume, IOPL=0 current process = 0 (swapper) trap number = 12 Panic: Page fault -- I would appreciate it if anyone could help me with this or provide advice. Cheers. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Boot Problem
Which version of FreeBSD are you trying to install? /\ Hidetoshi Shimokawa \/ [EMAIL PROTECTED] PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html At Sat, 25 Oct 2003 15:19:56 +0100, Kris Davidson wrote: This may be a complete newbie question, or it may have been answered before but I would appreciate any help or input that can be provided. I have a Sony VAIO PCG-GRZ615M laptop which I'm trying to install FreeBSD on. I boot from the CD and then try selecting each one of the 7 boot options however each option I pick returns the below and then the system reboots, as such I can not start the installation. -- fwohci0: Link S100, max_rec 2 bytes fwohci0: max_rec2 - 512 fwohci0: bus_OPT 0x0 - 0xf8008000 fwohci0: fwohci_set_intr: 1 firewire :IEEE1394(firewire)Bus on fwohci0 fatal trap 12: page fault while in Kernel mode fault virtual address = 0x2c fault code = supervisor read, page not present instruction pointer = 0x8 :0xc02e5a50 Stack pointer = 0x10 :0xc0b2e8c4 frame pointer = 0x10 :0xc0b2e8c8 code segment = base 0x0, limit 0xf, type 0x1b = DPL0, pres 1, def32 1, gran 1 processor eflags = interrupte enabled, resume, IOPL=0 current process = 0 (swapper) trap number = 12 Panic: Page fault -- I would appreciate it if anyone could help me with this or provide advice. Cheers. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-firewire To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Boot Problem
I'm trying to install 5.1 release and am in the process of downloading version 4.8 Hidetoshi Shimokawa wrote: Which version of FreeBSD are you trying to install? /\ Hidetoshi Shimokawa \/ [EMAIL PROTECTED] PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html At Sat, 25 Oct 2003 15:19:56 +0100, Kris Davidson wrote: This may be a complete newbie question, or it may have been answered before but I would appreciate any help or input that can be provided. I have a Sony VAIO PCG-GRZ615M laptop which I'm trying to install FreeBSD on. I boot from the CD and then try selecting each one of the 7 boot options however each option I pick returns the below and then the system reboots, as such I can not start the installation. -- fwohci0: Link S100, max_rec 2 bytes fwohci0: max_rec2 - 512 fwohci0: bus_OPT 0x0 - 0xf8008000 fwohci0: fwohci_set_intr: 1 firewire :IEEE1394(firewire)Bus on fwohci0 fatal trap 12: page fault while in Kernel mode fault virtual address = 0x2c fault code = supervisor read, page not present instruction pointer = 0x8 :0xc02e5a50 Stack pointer = 0x10 :0xc0b2e8c4 frame pointer = 0x10 :0xc0b2e8c8 code segment = base 0x0, limit 0xf, type 0x1b = DPL0, pres 1, def32 1, gran 1 processor eflags = interrupte enabled, resume, IOPL=0 current process = 0 (swapper) trap number = 12 Panic: Page fault -- I would appreciate it if anyone could help me with this or provide advice. Cheers. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-firewire To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
PCAP Open BPF R/W?
Could someone consider applying the following to the in tree pcap? It
makes it possible to write to the pcap fd to send packets out the
interface. Some simulators expect this ability to properly do
networking..
Jason
--- pcap-bpf.c.old Sat Oct 25 11:56:32 2003
+++ pcap-bpf.c Sat Oct 25 11:49:10 2003
@@ -185,7 +185,7 @@
*/
do {
(void)snprintf(device, sizeof(device), /dev/bpf%d, n++);
- fd = open(device, O_RDONLY);
+ fd = open(device, O_RDWR);
} while (fd 0 errno == EBUSY);
/*
--
Jason Slagle - CCNP - CCDP
/\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
\ / ASCII Ribbon Campaign .
X - NO HTML/RTF in e-mail .
/ \ - NO Word docs in e-mail .
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: two soundcards and realplayer
On Oct 25, Martin V??a wrote: Hi, I use two soundcards on my Freebsd5.1 box - Sb Live and SB AWE64, FreeBSD somehow figured out that Live is better than Awe and made it primary soundcard. The reason I have AWE still in computer, is it's amplyfing skills /2x4W/ so I don't need aditional amplyfier. With Xmms it's fine, I just changed confile and enjoy music. But I can't figure out how to swap soundcards in RealPlayer and Mplayer. Is there a way how to change it system wide? FreeBSD current, sysctl hw.snd.unit, the default unit used by /dev/dsp. Realplayer also checks an enviroment variable AUDIO (which defaults to /dev/dsp), so in bach you could, export AUDIO=/dev/dsp1.0 --Mat -- (on the United States) Living next to you is in some ways like sleeping with an elephant. No matter how friendly and eventempered the beast, one is affected by every twitch and grunt. - Pierre Elliott Trudeau ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
Wes Peters wrote this message on Thu, Oct 23, 2003 at 01:43 -0700: Kip Macy, other DragonFlyBSD developers, and anyone else wishing to contribute are invited to join and participate in the open FreeBSD mail lists, sharing code, design information, research and test results, etc. according to their own will. We welcome input from everyone, including constructive criticism of weaknesses or flaws in FreeBSD. And patches (against FreeBSD) are highly encouraged. It rarely helps to simply point out flaws (or showing how X OS runs soo much better than FreeBSD, why are you guys even running FreeBSD?) w/o showing code to fix it. Note: I am not speaking as an offical representive of FreeBSD, just as a developer who has too few time to try to code up a patch for code I haven't seen. And considering that DragonFlyBSD is based upon FreeBSD coming up with said patches should be trivial. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
On Sat, 25 Oct 2003, John-Mark Gurney wrote: And patches (against FreeBSD) are highly encouraged. It rarely helps to simply point out flaws (or showing how X OS runs soo much better than FreeBSD, why are you guys even running FreeBSD?) w/o showing code to fix it. -- John-Mark GurneyVoice: +1 415 225 5579 Heck, I'd be happy if working benchmark programs were provided. A big chunk of figuring out bugs / performance problems always seems to be setting up the right conditions for the problem to be recreated. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some mmap observations compared to Linux 2.6/OpenBSD
Ted Unangst wrote: On Fri, 24 Oct 2003, Michel TALON wrote: What is more interesting is to look at the actual benchmark results in http://bulk.fefe.de/scalability/ in particular the section about mmap benchmarks, the only one where OpenBSD shines. However as soon as touching pages is benchmarked OpenBSD fails very much. look closer. openbsd's touch page times are identical to what you'd expect a disk access to be. the pages aren't cached, they're read from disk. so compared to systems that don't read from disk, it looks pretty bad. a 5 line patch to fix the benchmark so that the file actually is cached on openbsd results in performance much in line with freebsd/linux. Why does the benchmark need to be fixed for OpenBSD and not for any other platform? My point here is that a benchmark measures what it measures, and if you don't like what it measures, making it measure something else is not a fix for the problem that it was originally intended to show. Microbenchmarks are pretty dumb, in general, because they are not representative of real world performance on a given fixed load, and are totally useless for predicting performance under a mixed load. That said, if this microbenchmark bothers you, fix OpenBSD. I know that Linux has some very good scores on LMBench, and that optimiziing the code to produce good numbers on that test set has pessimized performance in a number of areas under real world conditions. Unless there's an obvious win to be had without additional cost, it's best to take the numbers with a grain of salt. THAT said, it's probably a good idea for the other BSD's to use the read/black code from OpenBSD as a guid for their own code. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
John-Mark Gurney wrote: Wes Peters wrote this message on Thu, Oct 23, 2003 at 01:43 -0700: Kip Macy, other DragonFlyBSD developers, and anyone else wishing to contribute are invited to join and participate in the open FreeBSD mail lists, sharing code, design information, research and test results, etc. according to their own will. We welcome input from everyone, including constructive criticism of weaknesses or flaws in FreeBSD. And patches (against FreeBSD) are highly encouraged. It rarely helps to simply point out flaws (or showing how X OS runs soo much better than FreeBSD, why are you guys even running FreeBSD?) w/o showing code to fix it. Note: I am not speaking as an offical representive of FreeBSD, just as a developer who has too few time to try to code up a patch for code I haven't seen. And considering that DragonFlyBSD is based upon FreeBSD coming up with said patches should be trivial. First off, I really appreciate the mmap() discussion which has taken place. Someone has done a lot of work to create benchmarks, which, while being microbenchmarks, are a hell of a lot more useful than most of their kind. Further, they've pointed out where to get code to get comparable results in FreeBSD, licensed under a two clause BSD license, which means the only issue facing anyone is one of trivial integration. Second, Kip Macy and Matt Dillon have done some excellent work on the checkpointing code. It's basically ELF-based, and requires only small changes to the exec to set up the process for being able to be checkpointed and restarted. Again, the license is a two clause BSD license, and again, the only work necessary to get this over to FreeBSD is integration. When someone offers you a gift, you don't jump down their throat with jack-boots on, complaining about how the gift is wrapped or what color it is; you shut the hell up about any complaints and say Thank you. If the wrapping bothers you, well, you're going to remove it anyway. If the color bothers you, wait until they leave and paint the damn thing. If they come for a visit, they will be much more likely to be happy that you put it on display on the mantle than unhappy that you changed its color. Frankly, FreeBSD has too many cooks, and not enough bottle washers; this is a euphimism for saying that all anyone with a commit bit seems to want to do any more is write new code, and no one is willing to take on the integration and maintenance tasks. In Linux, this work is done by Linus, Alan Cox, and a couple of other people. People get commit bits so that they can do integration, and so that patches don't sit in bug databases for 6 years unintegrated. The problem with this imbalance, is that you seem to be unwilling to hire bottle washers, and people willing to wash bottles when there are no clean bottles left are never given any respect, and certainly not the level of respect accorded to cooks. You guys need to get your heads out, and give out some commit bits to some people willing to do the dirty work of integration of the code people are donating, and of closing out bug database entries where code is provided, and writing code that demonstrates the bug database problem and coming up with a fix and integrating *that*, where patches aren't provided. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some mmap observations compared to Linux 2.6/OpenBSD
On Wed, Oct 22, 2003, Q wrote: As an effort to get more acquainted with the FreeBSD kernel, I have been looking through how mmap works. I don't yet understand how it all fits together, or of the exact implications things may have in the wild, but I have noticed under some synthetic conditions, ie. mmaping small non-contiguous pages of a file, mmap allocation scales much more poorly on FreeBSD than on OpenBSD and Linux 2.6. After investigating this further I have observed that vm_map_findspace() traverses a linked list to find the next region (O(n) cost), whereas OpenBSD and Linux 2.6 both use Red-Black trees for the same purpose (O(log n) cost). Profiling the FreeBSD kernel appears to confirm this. Can someone comment on whether this is something that has been done intentionally, or avoided in favour of some other yet to be implemented solution? Or is it still on someones todo list. This is not, to my knowledge, on anyone's todo list. Using red-black trees for VM space allocation is likely to be slower for the common case where there aren't very many mappings in the first place, so it's not clear that this ``optimization'' should be a priority. I have never seen any real applications that are mmap-bound as a result of mmapping thousands of tiny regions. However, if some exist, I'm sure there would be interest in patches to improve scalability in this area. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
On Sat, Oct 25, 2003 at 11:54:59AM -0700, Terry Lambert wrote: Frankly, FreeBSD has too many cooks, and not enough bottle washers; this is a euphimism for saying that all anyone with a commit bit seems to want to do any more is write new code, and no one is willing to take on the integration and maintenance tasks. The euphemism sucks, but the point is there. The problem here has nothing to do with commit bits. People who do the dirty work and do it in a way that demonstrates that they can do it unattended are given commit bits. The problem is that after a certain amount of dirty work someone either goes away or, if given a commit bit, moves on to more interesting things to waste time on. There is also a problem in that the dirty work, even if done in a way that demonstrates that the person has skills, is not always recognised as important. The recognition has to come from within that part of the developer community that has commit bits, because you need someone with a commit bit to actually commit the stuff. If noone with a commit bit recorgnises the dirty work as important, it's not going to be committed and the person who has done the dirty work is not recognised as someone who is worthy of a commit bit because none of his work has been committed. You don't solve the problems by giving out commit bits. That will only accomplish that effort moves from prior to the commit to after the commit, adding repository pollution to the mix. It therefore makes the problem larger, not smaller. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some mmap observations compared to Linux 2.6/OpenBSD
On Sat, 25 Oct 2003, Terry Lambert wrote: Why does the benchmark need to be fixed for OpenBSD and not for any other platform? openbsd does not have a unified cache between file system (pread) and vm (mmap) interfaces. in the real world, it's unusual to find an application that uses both interfaces for its data files. a good benchmark at least attempts to model real world application behavior. My point here is that a benchmark measures what it measures, and if you don't like what it measures, making it measure something else is not a fix for the problem that it was originally intended to show. then the benchmark author should explain what's going on. touching a cached page and touching a page and reading it from disk are different events. if the name of the graph were reading an mmaped page after priming the disk cache with pread, then fine. but it's not. i'd like a benchmark to either attempt to accurately model (some slice of) real life or accurately explain what it is measuring. -- I am clearly more popular than Reagan. I am in my third term. Where's Reagan? Gone after two! Defeated by George Bush and Michael Dukakis no less. - M. Barry, Mayor of Washington, DC ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Passthrough block device
On Wed, Oct 22, 2003, Sean Hamilton wrote: Does FreeBSD support a device that will allow for the passing of all reads and writes on it to a userland application? I wish to handle swapping myself, preferably without any kernel hacking. What would happen if the kernel decided to swap out such a process? As far as I know, the only way to do that in FreeBSD is to implement a userland NFS server (e.g. amd(8)) on the local machine, have the kernel connect to localhost, and have your applications mmap() storage from that volume. (You probably won't be able to swap to the local NFS server without deadlocking.) People have implemented better solutions than that with some degree of OS support, however. Take a look at Mach's external pagers [1] and LRVM[2]. [1] http://citeseer.nj.nec.com/rashid87machineindependent.html [2] http://citeseer.nj.nec.com/satyanarayanan94lightweight.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
There is also a problem in that the dirty work, even if done in a way that demonstrates that the person has skills, is not always recognised as important. The recognition has to come from within that part of the developer community that has commit bits, because you need someone with a commit bit to actually commit the stuff. If noone with a commit bit recorgnises the dirty work as important, it's not going to be committed and the person who has done the dirty work is not recognised as someone who is worthy of a commit bit because none of his work has been committed. I think this perfectly underscores, if not restates, Terry's point. He doesn't believe sufficient value is placed on the dirty work. The following will sound as if it were intended to be ironic, but it isn't. Those working in the DragonFly tree, all appreciate Hiten's hard work as a bottle-washer. We've benefited from the fact that members of the FreeBSD community, through racist remarks and endless flames, and a key member of core, through the indefinite postponement of a commit-bit, have alienated him. Thus providing us with a, perhaps small, but nonetheless, valuable resource. -Kip ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
On Sat, Oct 25, 2003 at 12:55:26PM -0700, Kip Macy wrote: Those working in the DragonFly tree, all appreciate Hiten's hard work as a bottle-washer. We've benefited from the fact that members of the FreeBSD community, through racist remarks and endless flames, and a key member of core, through the indefinite postponement of a commit-bit, have alienated him. Thus providing us with a, perhaps small, but nonetheless, valuable resource. Those allegations against the core member were withdrawn, and I think it is despicable of you to use slurs of racism to attempt to promote your project. Hiten shouldn't be used as a pawn in your game. No-one has a problem with DragonFly having forked over technical differences. Don't polarise it into active hate between the two projects, you'll only end up damaging both. Kris pgp0.pgp Description: PGP signature
Re: FreeBSD mail list etiquette
On Sat, Oct 25, 2003 at 12:41:35PM -0700, Marcel Moolenaar wrote: On Sat, Oct 25, 2003 at 11:54:59AM -0700, Terry Lambert wrote: Frankly, FreeBSD has too many cooks, and not enough bottle washers; this is a euphimism for saying that all anyone with a commit bit seems to want to do any more is write new code, and no one is willing to take on the integration and maintenance tasks. The euphemism sucks, but the point is there. The problem here has nothing to do with commit bits. People who do the dirty work and do it in a way that demonstrates that they can do it unattended are given commit bits. The problem is that after a certain amount of dirty work someone either goes away or, if given a commit bit, moves on to more interesting things to waste time on. There is also a problem in that the dirty work, even if done in a way that demonstrates that the person has skills, is not always recognised as important. The recognition has to come from within that part of the developer community that has commit bits, because you need someone with a commit bit to actually commit the stuff. If noone with a commit bit recorgnises the dirty work as important, it's not going to be committed and the person who has done the dirty work is not recognised as someone who is worthy of a commit bit because none of his work has been committed. And to add to the complexity the non-committer providing patches has a much better chance of obtaining his/her own commit bit if the patches are committed to the repo. That is the (in?)famous track-record that has been discussed before that is one of the gating factors for a commit bit. Puzzling.. to say the least.. Wilko -- | / o / /_ _ FreeBSD core team secretary |/|/ / / /( (_) Bulte [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
On Sat, Oct 25, 2003 at 12:55:26PM -0700, Kip Macy wrote: There is also a problem in that the dirty work, even if done in a way that demonstrates that the person has skills, is not always recognised as important. The recognition has to come from within that part of the developer community that has commit bits, because you need someone with a commit bit to actually commit the stuff. If noone with a commit bit recorgnises the dirty work as important, it's not going to be committed and the person who has done the dirty work is not recognised as someone who is worthy of a commit bit because none of his work has been committed. I think this perfectly underscores, if not restates, Terry's point. He doesn't believe sufficient value is placed on the dirty work. The following will sound as if it were intended to be ironic, but it isn't. Those working in the DragonFly tree, all appreciate Hiten's hard work as a bottle-washer. We've benefited from the fact that members of the FreeBSD community, through racist remarks and endless flames, and a key member of core, through the indefinite postponement of a commit-bit, have alienated And that is certifiable BS.. I suggest you talk to Hiten first before you further spread fud like this W/ -- | / o / /_ _ FreeBSD core team secretary |/|/ / / /( (_) Bulte [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
In message [EMAIL PROTECTED], Kip Macy writes: We've benefited from the fact that members of the FreeBSD community, through racist remarks and endless flames, and a key member of core, through the indefinite postponement of a commit-bit, have alienated him. Thus providing us with a, perhaps small, but nonetheless, valuable resource. IRONY I suggest we donate a big statue to DragonFlyBSD. We could for instance inscribe it with Give me your tired, your poor, your huddled masses yearning to breathe free. /IRONY Kip, If you had managed to delude anybody to think you wanted peaceful cooperation between the projects, this email from you probably dispelled that notion pretty fast. For the last ten years, the NetBSD, OpenBSD and FreeBSD projects have had a tacit agreement not to post propaganda and inflamatory accusations to each others email lists (what project members do in their own projects is of course a different matter). I, and I think other members of FreeBSD, would appreciate it if the members of DragonflyBSD would adhere to this peace-keeping rule as well. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
This isn't a game Kris. I'm sorry if it hurts your feelings. Core always supports its own. Take a look at the history of SMP locking, the sudden change of ownership when the foundation came into money, the ensuing letter to core, and then the complete inaction. Those allegations against the core member were withdrawn, and I think it is despicable of you to use slurs of racism to attempt to promote your project. Hiten shouldn't be used as a pawn. Hiten is not a pawn. He is my friend. He has been endlessly hurt by numerous *private* e-mails to him from people on the FreeBSD lists. Please re-read my original e-mail I did not claim anything on the part of core. I'm not slurring the community as a whole. Please note that DragonFly is not my project any more than FreeBSD is, I happened to do some work in it. No-one has a problem with DragonFly having forked over technical differences. Don't polarise it into active hate between the two projects, you'll only end up damaging both. Thank you for the advice. If you'll notice I'm not on any of the lists any more. As soon is thread is permitted to die you will likely never hear from me again. Please don't expect me to be silent on the e-mails that I do receive, taking some sort of moral high-ground. -Kip ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
I, and I think other members of FreeBSD, would appreciate it if the members of DragonflyBSD would adhere to this peace-keeping rule as well. Thank you for providing sound advice Poul in a public forum. -Kip ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
Puzzling.. to say the least.. I'm sorry if I hurt your feelings. Please allow this thread to die, and me to move on to other things. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
On Sat, Oct 25, 2003 at 12:55:26PM -0700, Kip Macy wrote: There is also a problem in that the dirty work, even if done in a way that demonstrates that the person has skills, is not always recognised as important. The recognition has to come from within that part of the developer community that has commit bits, because you need someone with a commit bit to actually commit the stuff. If noone with a commit bit recorgnises the dirty work as important, it's not going to be committed and the person who has done the dirty work is not recognised as someone who is worthy of a commit bit because none of his work has been committed. I think this perfectly underscores, if not restates, Terry's point. He doesn't believe sufficient value is placed on the dirty work. There's a fundamental difference between recognition of important work and valuing important work. If you don't recognise it, you cannot value it. Undervaluing important work therefore implies that you at least recognise it. There probably is some undervaluing in the FreeBSD project. However, one must not forget that there's always a bigger fish (one of the more lame lines from The Phantom Menace, btw). There's such a thing as bad timing for dirty work. This does not render the dirty work unimportant per se, but it does make it irrelevent for the moment. This is where I think a lot of the friction originates. Those working in the DragonFly tree, all appreciate Hiten's hard work as a bottle-washer. I don't understand why Hiten has to be insulted all of a sudden. Then again, it does make a weird kind of sense considering the following: We've benefited from the fact that members of the FreeBSD community, through racist remarks and endless flames, and a key member of core, through the indefinite postponement of a commit-bit, have alienated him. I for one am very glad you're not a member of the FreeBSD community. And given that you've found a place with DragonFly, there's little chance that you become part of FreeBSD community in the future. For that I'm also very glad. So, all in all, I'm very glad DragonFly exists. Now even more than before. Because besides the technical divergence it also seems to have the effect of purifying the FreeBSD community from those who are dumb enough to make a fool of themselves, and indirectly the project, race and species they're associated with or otherwise belong to. Unfortunately, that's still 2 out of 3 for me, but then again life wouldn't be so much fun for me if it wasn't for guys like you Kip. I can handle the embarrassment, so do stick around... -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
I for one am very glad you're not a member of the FreeBSD community. And given that you've found a place with DragonFly, there's little chance that you become part of FreeBSD community in the future. For As stated previously, I'm not, nor have I ever been, a member of DragonFly BSD, FreeBSD, NetBSD, OpenBSD, or Linux. I've just done work in the first two and the last. So don't slur those who choose to define themselves as members with all the various evils that you appear to want to attribute to me. that I'm also very glad. So, all in all, I'm very glad DragonFly exists. Now even more than before. Because besides the technical divergence it also seems to have the effect of purifying the FreeBSD community from those who are dumb enough to make a fool of themselves, FreeBSD is not yet pure, but people like you and phk are helping to ensure that every day it becomes more pure. And once again, I thank you both for your efforts. and indirectly the project, race and species they're associated with or otherwise belong to. Unfortunately, that's still 2 out of 3 for me, but then again life wouldn't be so much fun for me if it wasn't for guys like you Kip. I can handle the embarrassment, so do stick around... Ouch. That truly is all encompassing. It is unfortunate that there isn't a competitive demand for people who are talented at making snide remarks. You and a couple of other notables would be very well off. It is also unfortunate that people like you and phk are the most vocal members of the FreeBSD community. There are so many good, kind, and talented people out there. -Kip ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
I think it needs to be recognized that *no* submission or suggestion, whether by core, a committer, or an outside member, will ever survive its original maintainership 'forever'. This is true for everything that was ever put into the kernel throughout its entire history: VFS, VM, BIO, KLD, ELF, Makefiles, the Scheduler, and it is true of all new contemporary work as well (Geom, Slab Allocator, Mutexes, Thread scheduler rules, Security work, etc..). For any outside submission, it is up to the inside project members to take up the ball and do the final step if they want the work in the project. Heaping conformistic requirements on an outside originator will simply result in the work not ever getting into your tree. It's really that simple. After all, FreeBSD is not going to be the focus for any outside submission (KAME's history in the tree being a really good example of this). Regardless of their intent, the lack of involvement by the general FreeBSD developer community has led to some severe issues over the years, yet it is equally obvious that there is great demand for the work. The outsider is not going to be tracking FreeBSD development anywhere near as tightly as FreeBSD insiders do, which makes the idea of requiring a FreeBSD-specific patch set in the first place rather silly. So it simply becomes a matter of whether there is a developer within the project who feels that a piece of work is interesting enough to do the last bit required to integrate, document, and bring it into your project in a fashion that can be maintained generally according to the rules of that project... and then move on. The work is certainly germane. Really, any open-source work is germane, especially on the a list like freebsd-hackers :-). The FreeBSD project is an open-source project, after all, even if some of its developers treat it as their own personal fiefdoms and people are afraid to cross maintainership boundaries because they get their heads bitten off every time they do. The whole maintainership and stewardship concept has seriously stratified FreeBSD development, to the point where some very bad technical decisions have been made over the last few years (Hence DragonFly's existence). -Matt Matthew Dillon [EMAIL PROTECTED] :On Sat, Oct 25, 2003 at 12:41:35PM -0700, Marcel Moolenaar wrote: : On Sat, Oct 25, 2003 at 11:54:59AM -0700, Terry Lambert wrote: : : Frankly, FreeBSD has too many cooks, and not enough bottle washers; : this is a euphimism for saying that all anyone with a commit bit : seems to want to do any more is write new code, and no one is : willing to take on the integration and maintenance tasks. : : The euphemism sucks, but the point is there. The problem here has : nothing to do with commit bits. People who do the dirty work and : do it in a way that demonstrates that they can do it unattended : are given commit bits. The problem is that after a certain amount : of dirty work someone either goes away or, if given a commit bit, : moves on to more interesting things to waste time on. : : There is also a problem in that the dirty work, even if done in a : way that demonstrates that the person has skills, is not always : recognised as important. The recognition has to come from within : that part of the developer community that has commit bits, because : you need someone with a commit bit to actually commit the stuff. If : noone with a commit bit recorgnises the dirty work as important, : it's not going to be committed and the person who has done the dirty : work is not recognised as someone who is worthy of a commit bit : because none of his work has been committed. : :And to add to the complexity the non-committer providing patches :has a much better chance of obtaining his/her own commit bit if the :patches are committed to the repo. : :That is the (in?)famous track-record that has been discussed before :that is one of the gating factors for a commit bit. : :Puzzling.. to say the least.. : :Wilko ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
Sheesh, you think you guys (*ALL* you guys) have enough time on your hands? There are better places to direct all that brainpower. I don't really need to defend DragonFly... I believe it stands on its own very well not only with what we have already accomplished but with what we are about to accomplish. Jeffrey is very close to decoupling the NETIF and network protocol drivers from Giant and Hiten has been playing with the APICs in regards to distributing interrupts to particular CPUs (something which DragonFly is particularly good at due to the way the light weight kernel threading system works). As soon as I get this namecache mess rewritten (and assuming David Rhodus doesn't keep pulling obscure panics out of his hat :-), but to be fair our NFS is already gobs faster then 4.x)... I am going to start cleaning up loose ends in the networking code and we will have the critical path entirely decoupled and mostly (or completely) mutexless. We are taking a somewhat different approach to BGL removal then 5.x. Instead of halfhazardly locking up subsystems with mutexes we are instead locking up subsystems by moving them into their own threads, then scaling through the use of multiple threads, and leaving everything that hasn't been locked up under the BGL. That way we are able to skip the intermediate step of determining where all the contention is, because the only contention will be the BGL'd areas which haven't been converted yet and we will simply assume contention. This way we can focus on optimizing the critical path, which will get us 80% of the scaleability we need, and tackle the other things like, say, the route table, after we have the topology in place and can see clearly what needs to be done for it (e.g. like using RCU and passive IPI messaging instead of mutexes for updates). So, for example, take the TCP stack. It's already mostly in its own thread simply by virtue of being a software interrupt. Softints, like interrupts, are threads in DragonFly. After the first lockup phase external APIs such as mbuf allocation and freeing, and route table lookups, will still be under the BGL, but PCBs and packet manipulation will be serialized in the protocol thread(s) and require no mutexes or locks whatsoever. Then we will move most of the mbuf API out of the BGL simply by adding a per-cpu layer (and since there is no cpu-hopping preemption we can depend on the per-cpu globaldata area without wasting cycles getting and releasing mutexes that just waste cycles since the whole idea is for there to be no contention in the first place). But just like our current slab allocator, things that miss the per-cpu globaldata cache will either use the BGL to access the kernel_map or will queue the operation (if it does not need to be synchronous) for later execution. After all, who cares if free() can't release a chunk of memory to the kernel_map instantly for reuse? It's a lot easier lockup path then the direction 5.x is going, and a whole lot more maintainable IMHO because most of the coding doesn't have to worry about mutexes or LORs or anything like that. If I were to recommend anything to the folks working on FreeBSD-current, it would be: * get rid of priority borrowing, and stop depending on it to fix all your woes with interrupt threads accessing mutexes that non-interrupt threads might also be accessing in the critical path. Fix the interrupt code instead. * get rid of *NON*-interrupt thread preemption while in the kernel. * get rid of preemptive cpu migration, even across normal blocks inside the kernel unless you tell the API otherwise with a flag that it is ok. * formalize critical sections to use just the counter mechanism (similar to spls in 4.x), which it almost does now, and require that hardware interrupts conform to the mechanism on all architectures. * Port our IPI messaging code (which isn't optimized yet, but works and can theoretically be very nicely optimized). * separate the userland scheduler from the kernel thread scheduler using a designated P_CURPROC approach, which completely fixes the priority inversion issues I might add that ULE only 'fake fixes' right now. Make the kernel thread scheduler a fixed priority scheduler (e.g. highest priority being interrupts, then softints, then threads operating in the kernel, then user associated threads operating in the kernel, then user associated threads operating in userland). Fix the userland scheduler API to conform to the designated P_CURPROC approach, where the userland scheduler is responsible for
Bye hackers@...
Sorry, I'm reducing my email load by dropping off [EMAIL PROTECTED] If you want my attention on a problem, send me private email, Cc' me or send it to another list were I'm subscribed. Sorry... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Boot Problem
It seems that fwohci registers are not mapped correctly. If your BIOS has a option for `PnP OS', try to set it to 'no'. /\ Hidetoshi Shimokawa \/ [EMAIL PROTECTED] PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html At Sat, 25 Oct 2003 16:32:30 +0100, Kris Davidson wrote: I'm trying to install 5.1 release and am in the process of downloading version 4.8 Hidetoshi Shimokawa wrote: Which version of FreeBSD are you trying to install? /\ Hidetoshi Shimokawa \/ [EMAIL PROTECTED] PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html At Sat, 25 Oct 2003 15:19:56 +0100, Kris Davidson wrote: This may be a complete newbie question, or it may have been answered before but I would appreciate any help or input that can be provided. I have a Sony VAIO PCG-GRZ615M laptop which I'm trying to install FreeBSD on. I boot from the CD and then try selecting each one of the 7 boot options however each option I pick returns the below and then the system reboots, as such I can not start the installation. -- fwohci0: Link S100, max_rec 2 bytes fwohci0: max_rec2 - 512 fwohci0: bus_OPT 0x0 - 0xf8008000 fwohci0: fwohci_set_intr: 1 firewire :IEEE1394(firewire)Bus on fwohci0 fatal trap 12: page fault while in Kernel mode fault virtual address = 0x2c fault code = supervisor read, page not present instruction pointer = 0x8 :0xc02e5a50 Stack pointer = 0x10 :0xc0b2e8c4 frame pointer = 0x10 :0xc0b2e8c8 code segment = base 0x0, limit 0xf, type 0x1b = DPL0, pres 1, def32 1, gran 1 processor eflags = interrupte enabled, resume, IOPL=0 current process = 0 (swapper) trap number = 12 Panic: Page fault -- I would appreciate it if anyone could help me with this or provide advice. Cheers. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-firewire To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Boot Problem
Okay I've checked my BIOS. I'm using Phoenix BIOS Setup version 4.0 with the bwlo versions BIOS Version: R216B1 EC BIOS Version: R216B1 Video BIOS Version: BOAM7_12 I can't seem to find the option specified below or something similar. Hidetoshi Shimokawa wrote: It seems that fwohci registers are not mapped correctly. If your BIOS has a option for `PnP OS', try to set it to 'no'. /\ Hidetoshi Shimokawa \/ [EMAIL PROTECTED] PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html At Sat, 25 Oct 2003 16:32:30 +0100, Kris Davidson wrote: I'm trying to install 5.1 release and am in the process of downloading version 4.8 Hidetoshi Shimokawa wrote: Which version of FreeBSD are you trying to install? /\ Hidetoshi Shimokawa \/ [EMAIL PROTECTED] PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html At Sat, 25 Oct 2003 15:19:56 +0100, Kris Davidson wrote: This may be a complete newbie question, or it may have been answered before but I would appreciate any help or input that can be provided. I have a Sony VAIO PCG-GRZ615M laptop which I'm trying to install FreeBSD on. I boot from the CD and then try selecting each one of the 7 boot options however each option I pick returns the below and then the system reboots, as such I can not start the installation. -- fwohci0: Link S100, max_rec 2 bytes fwohci0: max_rec2 - 512 fwohci0: bus_OPT 0x0 - 0xf8008000 fwohci0: fwohci_set_intr: 1 firewire :IEEE1394(firewire)Bus on fwohci0 fatal trap 12: page fault while in Kernel mode fault virtual address = 0x2c fault code = supervisor read, page not present instruction pointer = 0x8 :0xc02e5a50 Stack pointer = 0x10 :0xc0b2e8c4 frame pointer = 0x10 :0xc0b2e8c8 code segment = base 0x0, limit 0xf, type 0x1b = DPL0, pres 1, def32 1, gran 1 processor eflags = interrupte enabled, resume, IOPL=0 current process = 0 (swapper) trap number = 12 Panic: Page fault -- I would appreciate it if anyone could help me with this or provide advice. Cheers. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some mmap observations compared to Linux 2.6/OpenBSD
Q [EMAIL PROTECTED] writes: Yes, it would appear this is a legacy thing that existed in the original 1994 import of the BSD 4.4 Lite source. Both FreeBSD and NetBSD still use this technique, but OpenBSD changed to using Red-Black trees back in Feb 2002. [...] I am wondering if there is a compelling reason why the technique used by OpenBSD could not be adapted to FreeBSD's VM system. Adapting OpenBSD's red-balck patches would require quite a bit of work as FreeBSD and OpenBSD have diverged quite a bit in this area. Though it is a good idea to change the list into a tree, I think you'd get more mileage by addressing the fundamental problem, which is the lack of a free list. The current code (in both FreeBSD and OpenBSD) searches a list or tree of allocated extents, sorted by location, looking for a pair that have sufficient space between them for the extent you want to create. We should instead keep track of free extents in a structure that makes it easy to locate one of the correct size. We probably need a dual structure, though, because we need to keep the free extents sorted both by size (to quickly find what we need) and by location (to facilitate aggregation of adjacent extents, without which we'd suffer horribly from address space fragmentation). I have no idea how much this means for real-life workloads though. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
On Sat, Oct 25, 2003 at 02:42:52PM -0700, Matthew Dillon wrote: So it simply becomes a matter of whether there is a developer within the project who feels that a piece of work is interesting enough to do the last bit required to integrate, document, and bring it into your project in a fashion that can be maintained generally according to the rules of that project... and then move on. Yes. Note that the developer doesn't even have to think the work is interesting. Just that it's valuable and worth doing. The work is certainly germane. Really, any open-source work is germane, especially on the a list like freebsd-hackers :-) Agreed, to some extend. Not all open source projects have sufficient relation or impact on FreeBSD that discussing them here has an impact on FreeBSD. I certainly agree that work done in DragonFly can be discussed here. For the sake of DragonFly and FreeBSD I would expect that none of the FreeBSD lists are used as substitutes for DragonFly mailinglists and vice versa. The FreeBSD project is an open-source project, after all, even if some of its developers treat it as their own personal fiefdoms and people are afraid to cross maintainership boundaries because they get their heads bitten off every time they do. Fiefdoms are natural. We humans have a long history of people trying to grab power at various levels of scope, with various levels of force or terror and for reasons of insecurity or insanity at various levels of mental abnormality. This does not mean that fiefdoms are good. It simply means that you're kicking-in open doors. The problem is how to create an environment where the creation of fiefdoms can be stopped before it becomes a problem. Also, I think that most fiefdoms are in fact protectorates. When some- one has put in a lot of thought and work to make some component as perfect as is reasonably possible, you're likely going to step on his or her (we don't want to be labeled as sexists here :-) toes if you make changes that do not appear to have been thought-out as much as the original code. The appearance may not match reality of course, but still the author is likely to resist as a first reaction. Better yet, and I think this applies to you, when changes go against the direction the author was going into, you have a far more political struggle than we'd probably all like. You suddenly have to deal with personalities, egos and other non-technical subjects. It can reach a point where the technical content is totally irrelevant, because the battle is really mostly personal and the code is just an excuse. This may look like fiefdoms, but it's really just psychology and human imperfection. We all suck that way :-) The whole maintainership and stewardship concept has seriously stratified FreeBSD development, to the point where some very bad technical decisions have been made over the last few years (Hence DragonFly's existence). I don't think it's that bad or that it can be generalized this way, but there are some examples that seem to support what you say. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
On Sat, 25 Oct 2003, Matthew Dillon wrote: It's a lot easier lockup path then the direction 5.x is going, and a whole lot more maintainable IMHO because most of the coding doesn't have to worry about mutexes or LORs or anything like that. You still have to be pretty careful, though, with relying on implicit synchronization, because while it works well deep in a subsystem, it can break down on subsystem boundaries. One of the challenges I've been bumping into recently when working with Darwin has been the split between their Giant kernel lock, and their network lock. To give a high level summary of the architecture, basically they have two Funnels, which behave similarly to the Giant lock in -STABLE/-CURRENT: when you block, the lock is released, allowing other threads to enter the kernel, and regained when the thread starts to execute again. They then have fine-grained locking for the Mach-derived components, such as memory allocation, VM, et al. Deep in a particular subsystem -- say, the network stack, all works fine. The problem is at the boundaries, where structures are shared between multiple compartments. I.e., process credentials are referenced by both halves of the Darwin BSD kernel code, and are insufficiently protected in the current implementation (they have a write lock, but no read lock, so it looks like it should be possible to get stale references with pointers accessed in a read form under two different locks). Similarly, there's the potential for serious problems at the surprisingly frequently occuring boundaries between the network subsystem and remainder of the kernel: file descriptor related code, fifos, BPF, et al. By making use of two large subsystem locks, they do simplify locking inside the subsystem, but it's based on a web of implicit assumptions and boundary synchronization that carries most of the risks of explicit locking. It's also worth noting that there have been some serious bugs associated with a lack of explicit synchronization in the non-concurrent kernel model used in RELENG_4 (and a host of other early UNIX systems relying on a single kernel lock). These have to do with unexpected blocking deep in a function call stack, where it's not anticipated by a developer writing source code higher in the stack, resulting in race conditions. In the past, there have been a number of exploitable security vulnerabilities due to races opened up in low memory conditions, during paging, etc. One solution I was exploring was using the compiler to help track the potential for functions to block, similar to the const qualifier, combined with blocking/non-blocking assertions evaluated at compile-time. However, some of our current APIs (M_NOWAIT, M_WAITOK, et al) make that approach somewhat difficult to apply, and would have to be revised to use a compiler solution. These potential weaknesses very much exist in an explicit model, but with explicit locking, we have a clearer notion of how to express assertions. In -CURRENT, we make use of thread-based serialization in a number of places to avoid explicit synchronization costs (such as in GEOM for processing work queues), and we should make more use of this practice. I'm particularly interested in the use of interface interrupt threads performing direct dispatch as a means to maintain interface ordering of packets coming in network interfaces while allowing parallelism in network processing (you'll find this in use in Sam's netperf branch currently). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
: It's a lot easier lockup path then the direction 5.x is going, and : a whole lot more maintainable IMHO because most of the coding doesn't : have to worry about mutexes or LORs or anything like that. : :You still have to be pretty careful, though, with relying on implicit :synchronization, because while it works well deep in a subsystem, it can :break down on subsystem boundaries. One of the challenges I've been :bumping into recently when working with Darwin has been the split between :their Giant kernel lock, and their network lock. To give a high level :summary of the architecture, basically they have two Funnels, which behave :similarly to the Giant lock in -STABLE/-CURRENT: when you block, the lock :is released, allowing other threads to enter the kernel, and regained when :the thread starts to execute again. They then have fine-grained locking :for the Mach-derived components, such as memory allocation, VM, et al. I recall a presentation at BSDCon that mentioned that... yours I think. The interfaces we are contemplating for the NETIF (at the bottom) and UIPC (at the top) are different. We probably won't need to use any mutexes to queue incoming packets to the protocol thread, we will almost certainly use an async IPI message to queue a message holding the packet if the protocol thread is on a different cpu. On the same cpu it's just a critical section to interlock the queueing operation against the protocol thread. Protocol packet output to NETIF would use the same methodology... asynch IPI message if the NETIF is on another cpu, critical section if it is on the current cpu. The protocol itself will change from a softint to a normal thread, or perhaps a thread at softint priority. The softint is already a thread but we would separate each protocol into its own thread and have an ability to create several threads for a single protocol (like TCP) when necessary to take advantage of multiple cpus. On the UIPC side we have a choice of using a mutex to lock the socket buffer, or passing a message to the protocol thread responsible for the socket buffer (aka PCB). There are tradeoffs for both situations since if this is related to a write() it winds up being a synchronous message. Another option is to COW the memory but that might be too complex. Smaller writes could simply copyin() the data as an option, or we could treat the socket buffer as a FIFO which would allow the system call UIPC interface to append to it without holding any locks (other then a memory barrier after the copy and before updating the index), then simply send a kick-off message to the protocol thread telling it that more data is present. :Deep in a particular subsystem -- say, the network stack, all works fine. :The problem is at the boundaries, where structures are shared between :multiple compartments. I.e., process credentials are referenced by both :halves of the Darwin BSD kernel code, and are insufficiently protected :in the current implementation (they have a write lock, but no read lock, :so it looks like it should be possible to get stale references with :pointers accessed in a read form under two different locks). Similarly, :there's the potential for serious problems at the surprisingly frequently :occuring boundaries between the network subsystem and remainder of the :kernel: file descriptor related code, fifos, BPF, et al. By making use of :two large subsystem locks, they do simplify locking inside the subsystem, :but it's based on a web of implicit assumptions and boundary :synchronization that carries most of the risks of explicit locking. Yes. I'm not worried about BPF, and ucred is easy since it is already 95% of the way there, though messing with ucred's ref count will require a mutex or an atomic bus-locked instruction even in DragonFly! The route table is our big issue. TCP caches routes so we can still BGL the route table and achieve 85% of the scaleable performance so I am not going to worry about the route table initially. An example with ucred would be to passively queue it to a particular cpu for action. Lets say instead of using an atomic bus-locked instruction to manipulate ucred's ref count, we instead send a passive IPI to the cpu 'owning' the ucred, and that ucred is otherwise read-only. A passive IPI, which I haven't implemented yet, is simply queueing an IPI message but not actually generating an interrupt on the target cpu unless the CPU-CPU software IPI message FIFO is full, so it doesn't actually waste any cpu cycles and multiple operations can be executed in-batch by the target. Passive IPIs can be used for things that do not require instantanious action and both bumping and releasing ref counts can take advantage of it. I'm not saying that is how we will deal with ucred, but it
Synchronization philosophy (was: Re: FreeBSD mail list etiquette)
(Subject changed to reflect the fact that it contains useful technical content and banter, resulting in a hijacking of the thread; hope no one minds) On Sat, 25 Oct 2003, Matthew Dillon wrote: Yes. I'm not worried about BPF, and ucred is easy since it is already 95% of the way there, though messing with ucred's ref count will require a mutex or an atomic bus-locked instruction even in DragonFly! The route table is our big issue. TCP caches routes so we can still BGL the route table and achieve 85% of the scaleable performance so I am not going to worry about the route table initially. An example with ucred would be to passively queue it to a particular cpu for action. Lets say instead of using an atomic bus-locked instruction to manipulate ucred's ref count, we instead send a passive IPI to the cpu 'owning' the ucred, and that ucred is otherwise read-only. A passive IPI, which I haven't implemented yet, is simply queueing an IPI message but not actually generating an interrupt on the target cpu unless the CPU-CPU software IPI message FIFO is full, so it doesn't actually waste any cpu cycles and multiple operations can be executed in-batch by the target. Passive IPIs can be used for things that do not require instantanious action and both bumping and releasing ref counts can take advantage of it. I'm not saying that is how we will deal with ucred, but it is a definite option. Actually, the problem isn't so much the data referenced by ucred, but the references themselves. Part of the issue in Darwin is that ucred references are always gained using the p_ucred pointer in the proc structure. The proc structure is read and dereferenced fairly deep in the network code (network funnel), and also in the remainder of the kernel (kernel funnel). In addition, there's a lock used to serialize writes to p-p_ucred, but not to protect against reads of stale data. Shared structures, such as these, occur in pretty large quantity in BSD code, and will be a problem no matter what approach to synchronization is taken. Moving towards message passing helps to structure the code to avoid sharing of this sort, although it's not the only way to motivate that sort of change. I'm a big fan of the change in -CURRENT to use td-td_cred as a read-only thread-local credential reference and avoid synchronization on the credential reference--it nicely addresses the requirements for consistency in the referenced data for the read-only cases (which are the vast majority of uses of a credential). There are a number of cases where moving towards a message passing philosophy would really clean up the synchronization and parallelism issues in FreeBSD: for example, even the relatively simple accounting file rotation would benefit from queue-like operation to serialize the accounting data/event stream and rotation events. Using locks and condition variables to perform serialization as is currently done in the accounting code is unwieldy and bug-prone. However, when moving to event/message queuing, you also have to be very careful with data ownership and referencing, as well as proper error-handling. With accounting, most scheduled vnode operations are asynchronous and have no need for substantial error handling (when a process performs execve(), regardless of whether accounting of that operation succeeds or fails, execve() continues). The start/stop operation, however, is intended to be synchronous. Happily, in the accounting case, all necessary error checking can be performed in advance of the handoff to the accounting thread from the user thread, but that won't always be the case... One of the other risks that has worried me about this approach is that explicit locking has some nice benefits from the perspective of deadlocking and lock order management: monitoring for deadlocks and lock orders is a well-understood topic, and the tools for tracking deadlocks and wait conditions, as well as for performing locking and waiting safely, are mature. As with with the older BSD sleeping interfaces, such as tsleep(), synchronous waits on messages are harder to mechanically track, and resulting deadlocks resemble resource deadlocks more than lock deadlocks... On the other hand, some forms of tracing may be made easier. I've had some pretty nasty experiences trying to track deadlocks between cooperating threads due to message waits, and found tools such as WITNESS much easier to work with. In some work we're doing for one of our customers, we make extensive use of handoff between various submitting threads and a serializing kernel thread making use of thread-local storage to avoid explicit synchronization. Having dealt both with lower level lock/cv primitives for event passing, and message passing, I have to say I'm leaning far more towards the message passing. However, it benefits particularly from the approach due to its
Re: Some mmap observations compared to Linux 2.6/OpenBSD
On Sun, Oct 26, 2003, Dag-Erling Smrgrav wrote: Q [EMAIL PROTECTED] writes: Yes, it would appear this is a legacy thing that existed in the original 1994 import of the BSD 4.4 Lite source. Both FreeBSD and NetBSD still use this technique, but OpenBSD changed to using Red-Black trees back in Feb 2002. [...] I am wondering if there is a compelling reason why the technique used by OpenBSD could not be adapted to FreeBSD's VM system. Adapting OpenBSD's red-balck patches would require quite a bit of work as FreeBSD and OpenBSD have diverged quite a bit in this area. Though it is a good idea to change the list into a tree, I think you'd get more mileage by addressing the fundamental problem, which is the lack of a free list. The current code (in both FreeBSD and OpenBSD) searches a list or tree of allocated extents, sorted by location, looking for a pair that have sufficient space between them for the extent you want to create. We should instead keep track of free extents in a structure that makes it easy to locate one of the correct size. We probably need a dual structure, though, because we need to keep the free extents sorted both by size (to quickly find what we need) and by location (to facilitate aggregation of adjacent extents, without which we'd suffer horribly from address space fragmentation). I have no idea how much this means for real-life workloads though. Your idea of using a size-hashed freelist as well as a location-sorted list is appealing in its simplicity. Though it can cause a bit of fragmentation, it gives you constant time lookup. Bonwick's vmem allocator ([1], section 4.4.2 and following), apparently works quite well using this principle. But regardless of the approach, someone has yet to demonstrate that this is actually a performance problem in the real world. ;-) [1] http://www.usenix.org/event/usenix01/full_papers/bonwick/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
