Re: Bursting at the seams (was: Heh heh, humorous lockup)
> jul...@whistle.com (Julian Elischer) writes: > > > we already use the gs register for SMP now.. > > what about the fs register? > > I vaguely remember that the different segments could be used to achieve > > this (%fs points to user space or something) > > You can't extend the address space that way, segments are all parts of > the single 4GB address space described by the page mapping. True, but you can reserve a part of the 4GB address space (say 128MB of it) for partitioning into tiny (say 8MB) address spaces (which are still flat, just small), for use by small processes, the idea being that all those small processes will than share a single page table without compromising on memory protection (the GDT is under full OS's control anyway), or the simplicity of a flat address space (virtual addresses still start at 0 and continue till the top of address space; the scheme is totally transparent.) patryk. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
yeah I remembered how it all worked after I wrote that.. You'd think they'd eventually get the idea of letting the kernel have it's own 'cr3' and some TLBs eh? listenning intel? On 8 Jul 1999, Ville-Pertti Keinonen wrote: > > jul...@whistle.com (Julian Elischer) writes: > > > we already use the gs register for SMP now.. > > what about the fs register? > > I vaguely remember that the different segments could be used to achieve > > this (%fs points to user space or something) > > You can't extend the address space that way, segments are all parts of > the single 4GB address space described by the page mapping. > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
jul...@whistle.com (Julian Elischer) writes: > we already use the gs register for SMP now.. > what about the fs register? > I vaguely remember that the different segments could be used to achieve > this (%fs points to user space or something) You can't extend the address space that way, segments are all parts of the single 4GB address space described by the page mapping. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
[EMAIL PROTECTED] (Patryk Zadarnowski) writes: > > You can't extend the address space that way, segments are all parts of > > the single 4GB address space described by the page mapping. > True, but you can reserve a part of the 4GB address space (say 128MB of it) > for partitioning into tiny (say 8MB) address spaces (which are still flat, > just small), for use by small processes, the idea being that all those small > processes will than share a single page table without compromising on memory > protection (the GDT is under full OS's control anyway), or the simplicity of > a flat address space (virtual addresses still start at 0 and continue till > the top of address space; the scheme is totally transparent.) Yeah, I know, I've read Liedtke's original paper where he described the optimization in L3, that's fine for that specific purpose, but that wasn't what the thread was about. Unless I totally missed the point. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer)
On Wed, 7 Jul 1999 19:46:38 -0700 (PDT), Julian Elischer said: julian> With your scheme the clock needs to be always running at elevated speed. julian> Possibly you might have a startup routine that turns on the elevated julian> frequency, (basically does an 'aquire_timer0()' ) I would say that you julian> would have more success in implementing your finetimer() by using julian> "aquiretimer0" than the other way around. I agree that acquire_timer0() would give more freedom to the ticks to callout. Then I tried figuring out how to manage multiple callouts using acquire_timer0(), which is something like below. Let C the callout queue, and c_i a callout. (0 <= i < I) Next define f(c_i) as the callout function of c_i, and dt_rem(c_i) the time span between c_(i-1) and c_i. (dt_rem(c_-1) is defined as zero) We use the time span to avoid traversing though the queue to update the time tags on the callouts. (footnote: I'd better write in TeX :-<) Queueing a new callout c' to be made in t' involves a problem to find the maximum j (which is an integer, j >= 0) satisfying a constraint t' > \sum_(k=0)^(j) dt_rem(c_k) where the right hand side of the inequality is the time span after which the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). In clkintr(), we dequeue c_0 from C, and make a callout to f(c_0). Then acquire_timer0() is called once more with the new dt_rem(c_0). dt_rem(c_i) is the difference of callout times, so they need not be updated on every clkintr(). Although the computational cost in clkintr() is generaly O(1), the queueing cost is O(I). Not sure whether we can reduce it or not (will it really make a trouble?) How does it sound? Seigo Tanimura To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Heh heh, humorous lockup
[EMAIL PROTECTED] (Matthew Dillon) writes: > pair-down the fields in both structures. For example, the vnode structure > contains a lot of temporary clustering fields that could be removed > entirely if clustering operations are done at the time of the actual I/O > rather then before hand ( which leads to other problems related to > low-memory deadlocks :-(... but assuming that could be fixed... ). Actually the vnode structure can be reduced in size quite a bit without affecting behavior. I analyzed this in a private mail to phk a few months ago, I can get the list of necessary changes out again if anyone is actually interested. The idea was to reduce the size to 128 bytes (on i386) so that the kernel malloc would do a reasonable job allocating the vnodes without too much overhead. IIRC it was very close. I had written code that allocated and deallocated vnodes dynamically (see http://www.hut.fi/~will/freebsd_vnfree0.diff for a non-malloc version with parameters adjusted to exercise the behavior quite heavily). It didn't seem like a very useful feature, though, because of fragmentation (even with the 'optimizing' zone allocator in the patch). Even if the kernel malloc would be usable, the only other common object that would typically use that memory would be ffs inodes, which are allocated and deallocated along with vnodes... This reminds me - the small patch I submitted to fix the v_id references still hasn't been commited (phk, if you're reading this, is there any specific reason for this?). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
> [EMAIL PROTECTED] (Julian Elischer) writes: > > > we already use the gs register for SMP now.. > > what about the fs register? > > I vaguely remember that the different segments could be used to achieve > > this (%fs points to user space or something) > > You can't extend the address space that way, segments are all parts of > the single 4GB address space described by the page mapping. True, but you can reserve a part of the 4GB address space (say 128MB of it) for partitioning into tiny (say 8MB) address spaces (which are still flat, just small), for use by small processes, the idea being that all those small processes will than share a single page table without compromising on memory protection (the GDT is under full OS's control anyway), or the simplicity of a flat address space (virtual addresses still start at 0 and continue till the top of address space; the scheme is totally transparent.) patryk. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Problem with fxp driver and 82559 cards
>> >Large data transfers seem to cause the lockup. I know at least 1 netbsd >> >person has reported similar problems with these new cards, (kern/7216). >> > >> >Has anyone seen problems like these? Any ideas? >> >>Hmmm...I've been using them in some machines here and haven't seen any >> problems. Strange. Do all of your systems have similar motherboards and CPU? > > The only thing that I can identify as a common factor, is that the >PCI slots are on a riser card. One type is an NLX-form factor >motherboard. The other is an industrial system with a Single Board >Computer (SBC) and a passive backplain. Aside from the riser card, these >machines are completely different. (IDE vs. SCSI, no other PCI devices, >SCSI pci device, pentium vs pentium-II... onboard video/ethernet(in >addition to the intel cards) vs nothing onboard...) > > However, we have at least one industrial-type system (with a >different board/config) that works fine with these cards, though we didn't >do the install with one. I'll try that tomorrow and report my findings. > >I doubt this is the case, but is the fxp driver different on the install >floppy than on the post-install kernel / kernel-source? Same driver on floppy and installed kernel. >Any suggestions as to what I should look into? It sounds like a motherboard chipset problem. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
yeah I remembered how it all worked after I wrote that.. You'd think they'd eventually get the idea of letting the kernel have it's own 'cr3' and some TLBs eh? listenning intel? On 8 Jul 1999, Ville-Pertti Keinonen wrote: > > [EMAIL PROTECTED] (Julian Elischer) writes: > > > we already use the gs register for SMP now.. > > what about the fs register? > > I vaguely remember that the different segments could be used to achieve > > this (%fs points to user space or something) > > You can't extend the address space that way, segments are all parts of > the single 4GB address space described by the page mapping. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
[EMAIL PROTECTED] (Julian Elischer) writes: > we already use the gs register for SMP now.. > what about the fs register? > I vaguely remember that the different segments could be used to achieve > this (%fs points to user space or something) You can't extend the address space that way, segments are all parts of the single 4GB address space described by the page mapping. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer)
On Wed, 7 Jul 1999 19:46:38 -0700 (PDT), Julian Elischer <[EMAIL PROTECTED]> said: julian> With your scheme the clock needs to be always running at elevated speed. julian> Possibly you might have a startup routine that turns on the elevated julian> frequency, (basically does an 'aquire_timer0()' ) I would say that you julian> would have more success in implementing your finetimer() by using julian> "aquiretimer0" than the other way around. I agree that acquire_timer0() would give more freedom to the ticks to callout. Then I tried figuring out how to manage multiple callouts using acquire_timer0(), which is something like below. Let C the callout queue, and c_i a callout. (0 <= i < I) Next define f(c_i) as the callout function of c_i, and dt_rem(c_i) the time span between c_(i-1) and c_i. (dt_rem(c_-1) is defined as zero) We use the time span to avoid traversing though the queue to update the time tags on the callouts. (footnote: I'd better write in TeX :-<) Queueing a new callout c' to be made in t' involves a problem to find the maximum j (which is an integer, j >= 0) satisfying a constraint t' > \sum_(k=0)^(j) dt_rem(c_k) where the right hand side of the inequality is the time span after which the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). In clkintr(), we dequeue c_0 from C, and make a callout to f(c_0). Then acquire_timer0() is called once more with the new dt_rem(c_0). dt_rem(c_i) is the difference of callout times, so they need not be updated on every clkintr(). Although the computational cost in clkintr() is generaly O(1), the queueing cost is O(I). Not sure whether we can reduce it or not (will it really make a trouble?) How does it sound? Seigo Tanimura <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
On Jul 4, 5:35pm, "Jonathan M. Bresler" wrote: } Subject: Re: Pictures from USENIX } beards are great...women love them, getting fluffed is much } better than getting scratchedkids love them. brush the beard } whenever you brush your hair. dont hae to deal with a buzzing razor, } very unkind to newly awoken folk. dont ahve to wield a blade across } you neck in a fogged monring stupor. } } jmb--i aint shaved in 18 years. I've got you beat by 4.5 years ;-) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Problem with fxp driver and 82559 cards
>> >Large data transfers seem to cause the lockup. I know at least 1 netbsd >> >person has reported similar problems with these new cards, (kern/7216). >> > >> >Has anyone seen problems like these? Any ideas? >> >>Hmmm...I've been using them in some machines here and haven't seen any >> problems. Strange. Do all of your systems have similar motherboards and CPU? > > The only thing that I can identify as a common factor, is that the >PCI slots are on a riser card. One type is an NLX-form factor >motherboard. The other is an industrial system with a Single Board >Computer (SBC) and a passive backplain. Aside from the riser card, these >machines are completely different. (IDE vs. SCSI, no other PCI devices, >SCSI pci device, pentium vs pentium-II... onboard video/ethernet(in >addition to the intel cards) vs nothing onboard...) > > However, we have at least one industrial-type system (with a >different board/config) that works fine with these cards, though we didn't >do the install with one. I'll try that tomorrow and report my findings. > >I doubt this is the case, but is the fxp driver different on the install >floppy than on the post-install kernel / kernel-source? Same driver on floppy and installed kernel. >Any suggestions as to what I should look into? It sounds like a motherboard chipset problem. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Berkeley DB question
User Joe wrote: > >Is the berkeley db (or any other small db) multi user safe? Are there >locks to maintain coherency of multiple processes access the same database >files? The web pages for Berkeley DB 2 claim that it does (note version 2, not 1.85 as shipped with FreeBSD). http://www.sleepycat.com/. Tony. -- f.a.n.finch d...@dotat.at f...@demon.net Winner, International Obfuscated C Code Competition 1998 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Someone want to add support for computer radio scaners?
In reply: > Hello All, > > I was just looking at http://www.winradio.com/ and was thinking > that it would be a nice addition to FreeBSD. I don't own one of the > cards, otherwise I would have started to see what I could do. But if > anyone out there has one/has access to one, it would be interesting > to add into FreeBSD. They also supply information for programming > use of the device (http://www.winradio.com/home/developer.htm). > > Well thats all for now, > Mike what they supply is a dog/winblowz sdk. the api is documented, but the libraries are provided in binary form, and there is no register level documentation. it might be a fair assumption that these "radios" are dumber than people think from the dynamic range and other crucial numbers, these radios pretty much suck. you would get better performance out of a direct conversion or trf receiver, honestly. jim -- All opinions expressed are mine, if you| "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" -- Inet: jbry...@tfs.netAX.25: kc5...@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant -- HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rtfm' script
Put it in the ".login" or /etc/csh.login (etc.) file. They'll see it every time they log in. -Mark Taylor NetMAX Developer mtay...@cybernet.com http://www.netmax.com/ Wes Peters wrote: > > Bill Fumerola wrote: > > > > On Tue, 6 Jul 1999, Brian F. Feldman wrote: > > > > > Thanks! But still, I don't think rtfm is very appropriate... Can we look > > > for something better, more obvious? Or perhaps it would be in the motd > > > like /stand/sysinstall is people would need to be aware of this. > > > > it can be called anything. the new user isn't going to know it unless > > refered to it. (or unless there is a question mark to click) > > Now there's an idea! Someone wanna code up wmrtfm real quick? It should > start an rxvt (if available) or xterm running rtfm on strings that are > dropped onto or pasted into the dock icon. > > You know, being a program designer is a WHOLE lot easier than being a > programmer. ;^) > > -- > "Where am I, and what am I doing in this handbasket?" > > Wes Peters Softweyr > LLC > http://softweyr.com/ > w...@softweyr.com > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
Dag-Erling Smorgrav wrote: > >Don't use err() indiscriminately after a malloc() failure; malloc() >doesn't set errno. When I looked at malloc(3) I decided that it relied on sbrk(2) to set errno if it returned 0. Is this wrong? i.e. can it return 0 without a failed syscall? Tony. -- f.a.n.finch d...@dotat.at f...@demon.net Winner, International Obfuscated C Code Competition 1998 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
On Jul 4, 5:35pm, "Jonathan M. Bresler" wrote: } Subject: Re: Pictures from USENIX } beards are great...women love them, getting fluffed is much } better than getting scratchedkids love them. brush the beard } whenever you brush your hair. dont hae to deal with a buzzing razor, } very unkind to newly awoken folk. dont ahve to wield a blade across } you neck in a fogged monring stupor. } } jmb--i aint shaved in 18 years. I've got you beat by 4.5 years ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Berkeley DB question
User Joe <[EMAIL PROTECTED]> wrote: > >Is the berkeley db (or any other small db) multi user safe? Are there >locks to maintain coherency of multiple processes access the same database files? The web pages for Berkeley DB 2 claim that it does (note version 2, not 1.85 as shipped with FreeBSD). http://www.sleepycat.com/. Tony. -- f.a.n.finch [EMAIL PROTECTED] [EMAIL PROTECTED] Winner, International Obfuscated C Code Competition 1998 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Clipboard Daemon - thinking of writing one :)
The hard part is going to be the applications to co-operate. good luck. it's be nice. especially if it worked with the syscons cut-n-paste. julian On Thu, 8 Jul 1999, Mikhail Ramendik wrote: > Hello! > > I am new to FreeBSD and Unix, but not new to programming and TCP/IP. > > I have noticed that there is no good clipboard system in FreeBSD. X has only > a rudimentary clipboard, and outside X there is no clipboard that would be > shared between programs... All this while Windows has a very interesting > clipboard system that allows to paste as different types. > > I am thinking of writing a Clipboard Demon (of course, free and documented > and source and all) to try and tackle this problem. It's going to be a > daemon working over IP, it will allow "named clipboards" so that by default > each user has one clipboard, but a user can start several clipboards and/or > share one over a network (ok, insecure, at least in first releases - but > then, it can be nonsensitive info over a LAN). It will allow a program to > export data into the clipboard in one or _several_ formats (MIME, of > course), and then it will allow the importing program to choose the format > it wants (a la Windows, but no OLE stuff here) and get the data in it. > > For example, a GUI text editor can export the text as native format, text, > formatted text (RTF?), vector graphics (unsure what format would replace WMF > here), bitmap. This same editor will paste the native by default, another > editor will use the formatted text by default, etc. > > Note that it will work independently of X. So I can copy in Joe then paste > to GIMP (as text), if both support the clipboard. > > I will probably have time for actual coding in August or September. But I > want to work out the specs first, and to make sure it's needed at all ;) So, > my questions are: > > - Whether this thing is, in your opinion, needed > > - Whether a similar solution already exists in the freenix world (perhaps in > Linux?) > > - How to handle "big" data? If a program exports a big graphic in several > formats, that's a lot of data... Well, it can not actually send the data but > only indicate it's available - but then we'd have to "call back" to receive > the data, so the program would need to have a permanent connection with the > daemon and "listen" to it, and the availability of data would cease when the > program quits. Should I nevertheless include this behaviour as an option, to > be decided by the exporting program? > > Now the newbie questions: > > - Where can I read a good text on writing FreeBSD daemons? > > - How can I choose a guaranteed free TCP port? > > Yours in Christ, Mikhail Ramendik > Moscow, Russia > > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Someone want to add support for computer radio scaners?
In reply: > Hello All, > > I was just looking at http://www.winradio.com/ and was thinking > that it would be a nice addition to FreeBSD. I don't own one of the > cards, otherwise I would have started to see what I could do. But if > anyone out there has one/has access to one, it would be interesting > to add into FreeBSD. They also supply information for programming > use of the device (http://www.winradio.com/home/developer.htm). > > Well thats all for now, > Mike what they supply is a dog/winblowz sdk. the api is documented, but the libraries are provided in binary form, and there is no register level documentation. it might be a fair assumption that these "radios" are dumber than people think from the dynamic range and other crucial numbers, these radios pretty much suck. you would get better performance out of a direct conversion or trf receiver, honestly. jim -- All opinions expressed are mine, if you| "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" -- Inet: [EMAIL PROTECTED]AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant -- HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rtfm' script
Put it in the ".login" or /etc/csh.login (etc.) file. They'll see it every time they log in. -Mark Taylor NetMAX Developer [EMAIL PROTECTED] http://www.netmax.com/ Wes Peters wrote: > > Bill Fumerola wrote: > > > > On Tue, 6 Jul 1999, Brian F. Feldman wrote: > > > > > Thanks! But still, I don't think rtfm is very appropriate... Can we look > > > for something better, more obvious? Or perhaps it would be in the motd > > > like /stand/sysinstall is people would need to be aware of this. > > > > it can be called anything. the new user isn't going to know it unless > > refered to it. (or unless there is a question mark to click) > > Now there's an idea! Someone wanna code up wmrtfm real quick? It should > start an rxvt (if available) or xterm running rtfm on strings that are > dropped onto or pasted into the dock icon. > > You know, being a program designer is a WHOLE lot easier than being a > programmer. ;^) > > -- > "Where am I, and what am I doing in this handbasket?" > > Wes Peters Softweyr LLC > http://softweyr.com/ [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
Re: Replacement for grep(1) (part 2)
Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote: > >Don't use err() indiscriminately after a malloc() failure; malloc() >doesn't set errno. When I looked at malloc(3) I decided that it relied on sbrk(2) to set errno if it returned 0. Is this wrong? i.e. can it return 0 without a failed syscall? Tony. -- f.a.n.finch [EMAIL PROTECTED] [EMAIL PROTECTED] Winner, International Obfuscated C Code Competition 1998 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Clipboard Daemon - thinking of writing one :)
Hello! I am new to FreeBSD and Unix, but not new to programming and TCP/IP. I have noticed that there is no good clipboard system in FreeBSD. X has only a rudimentary clipboard, and outside X there is no clipboard that would be shared between programs... All this while Windows has a very interesting clipboard system that allows to paste as different types. I am thinking of writing a Clipboard Demon (of course, free and documented and source and all) to try and tackle this problem. It's going to be a daemon working over IP, it will allow "named clipboards" so that by default each user has one clipboard, but a user can start several clipboards and/or share one over a network (ok, insecure, at least in first releases - but then, it can be nonsensitive info over a LAN). It will allow a program to export data into the clipboard in one or _several_ formats (MIME, of course), and then it will allow the importing program to choose the format it wants (a la Windows, but no OLE stuff here) and get the data in it. For example, a GUI text editor can export the text as native format, text, formatted text (RTF?), vector graphics (unsure what format would replace WMF here), bitmap. This same editor will paste the native by default, another editor will use the formatted text by default, etc. Note that it will work independently of X. So I can copy in Joe then paste to GIMP (as text), if both support the clipboard. I will probably have time for actual coding in August or September. But I want to work out the specs first, and to make sure it's needed at all ;) So, my questions are: - Whether this thing is, in your opinion, needed - Whether a similar solution already exists in the freenix world (perhaps in Linux?) - How to handle "big" data? If a program exports a big graphic in several formats, that's a lot of data... Well, it can not actually send the data but only indicate it's available - but then we'd have to "call back" to receive the data, so the program would need to have a permanent connection with the daemon and "listen" to it, and the availability of data would cease when the program quits. Should I nevertheless include this behaviour as an option, to be decided by the exporting program? Now the newbie questions: - Where can I read a good text on writing FreeBSD daemons? - How can I choose a guaranteed free TCP port? Yours in Christ, Mikhail Ramendik Moscow, Russia To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
On Thu, 8 Jul 1999, Patryk Zadarnowski wrote: > > > Why not put the kernel in a different address space? IIRC there's no > > absolute requirement for the kernel and userland to be in the same > > address space, and that way we would have 4 GB for each. > > Wouldn't that make system calls that need to share data between kernel > and user spaces hopelessly inefficient? Things like sysctl() would > need to introduce (temporary) memory mappings, and someone would have > to keep track of these mappings and remove them as required, or the > kernel would probably run out of address space in no time, given even > with 4GB to spare. On top of that, every mapping established requires > some messing arround with the TLB, which, at least on pentium, is > rather expensive. All user data is imported and exported to the kernel using special calls anyhow, as we've always thought that we may want to go back to the separate address spaces that we asarted out with on the 11-40 and 11-45 (etc.) so technically it wouldn't make too much work as far as altering the kernel. I guess however, having thought about it, that we'd have to reload CR3 on a syscall and that'd flush the TLBs which would be a pain.. > > Incidentally, someone already experimented with such "dual" address > spaces on Linux, and the result was a 30% or so slow down. If you're > interested, I can give you the relevant references (the scenario was > somewhat different, but the source of the performance hit was the > "dual" address space.) > > patryk. > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Heh heh, humorous lockup
On Wed, 7 Jul 1999 18:21:03 -0700 (PDT) Matthew Dillon wrote: > Now, I also believe that when UVM maps those pages, it makes them > copy-on-write so I/O can be initiated on the data without having to > stall anyone attempting to make further modifications to the VM object. > Is this correct? This is something I would like to throw into FreeBSD > at some point. It would get rid of all the freeze/bogus-page hacks > already in there and avoid a number of I/O blocking conditions that we > currently face. Um... In UVM+UBC, VOP_GETPAGES() and VOP_PUTPAGES() operate on pages marked w/ PG_BUSY. In the case of faulting a page in, the mapping isn't yet entered into the VA at which it will be accessed, and in the case of a page being paged out, the page has been deactivated (and thus has had all mappings removed) and marked PG_BUSY. Thus, if a fault which would reactivate the page occurs, the fault handler waits for PG_BUSY to clear before reentering the mapping at the VA where the page will be accessed. Now, while the fault handler is waiting for PG_BUSY to clear, something else can certainly modify the object... But in the case of faulting on the same page, the second thread will wait for PG_BUSY to clear, too, since the page has already been inserted into the object. The pager's KVA for the page is read/write, for obvious reasons[*]. [*] Mapping a faulting page *at all* is suboptimal, of course. You'd prefer to see if the device can handle a physical address (or a uio with physical addresses), and if so, use that. This is faster, and eliminates bad cache interactions on VAC systems. You really only want to map the page if you have to do PIO to/from it. This is all handled via the ubc_pager (which has a special fault routine, part of UVM's basic infrastructure). VOP_GETPAGES() and VOP_PUTPAGES() are basically helper routines for the ubc_pager (effectively turning the file systems themselves into "pagers"). > However, I do not like the idea of taking page faults in kernel mode, > which I believe UVM also does -- but I think the above could be > implemented in FreeBSD without taking page faults. Taking page faults in kernel mode is a perfectly reasonable thing to do, if you don't need to access those addresses in interrupt context. What is the reason for your aversion to pageable mappings in the kernel? > Well, I do not like the "nuke the object chains" part of UVM. From what > I can tell UVM is doing a considerable amount of extra work to avoid the > object chain stuff, but only saving a small amount of overhead on > vm_fault's ( though, compared to the original Mach stuff the UVM stuff is > much, much better ). We've made a considerable number of improvements > to our vm_object's in the last few months. But I do like the idea > of a VM-specific substructure for vnodes and I do agree that embedding > the master VM object in the vnode is a good idea. Nuking object chains actually made things *simpler*. The locking protocol, in the face of object chains, is nighmareish. With amap-on-top-object-on- bottom, it's simple, makes fault handling quite fast, and eliminates all the complexity otherwise necessary in collasping those nasty object chains (where the various objects in the chain may be referenced by more than one map entry). ...and, in some cases, it's NOT a "small amount of overhead". Whereas the Mach object chains may be of arbitrary length (think about a program which forks often), involving a potentially hash computation for each object in the chain, the UVM case is always, at the most, two layers (in the current amap implementation, the lookup is always a direct index into an array, and the object underneath is a hash lookup). -- Jason R. Thorpe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
Dag-Erling Smorgrav writes: > > And besides, I really don't think this is a grep function but actually > > is useful for programs that don't have any strategy for handling out > > of memory errors and might as well die (with a descriptive error > > message, of course). Let's call it emalloc and let's put in somewhere > > where it can be used. > > Too simple to warrant that, and other programs will likely want to > handle the error differently. I don't agree. 1. this is a small function, but it's useful in lots of programs 2. that helps lazy programmers write code that actually checks for error returns instead of just ignoring them 3. it helps lots of programs that don't do anything intelligent (or for which there isn't much bright things to do) when allocating memory fails 4. having it in a library means it's more likely to be correct (i.e. sz == 0) but then again, I don't get to decide what goes in *BSD libc/libutil. In my library there's already a emalloc, ecalloc, and erealloc. /assar To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Problem with fxp driver and 82559 cards
> >Large data transfers seem to cause the lockup. I know at least 1 netbsd > >person has reported similar problems with these new cards, (kern/7216). > > > >Has anyone seen problems like these? Any ideas? > >Hmmm...I've been using them in some machines here and haven't seen any > problems. Strange. Do all of your systems have similar motherboards and CPU? The only thing that I can identify as a common factor, is that the PCI slots are on a riser card. One type is an NLX-form factor motherboard. The other is an industrial system with a Single Board Computer (SBC) and a passive backplain. Aside from the riser card, these machines are completely different. (IDE vs. SCSI, no other PCI devices, SCSI pci device, pentium vs pentium-II... onboard video/ethernet(in addition to the intel cards) vs nothing onboard...) However, we have at least one industrial-type system (with a different board/config) that works fine with these cards, though we didn't do the install with one. I'll try that tomorrow and report my findings. I doubt this is the case, but is the fxp driver different on the install floppy than on the post-install kernel / kernel-source? Any suggestions as to what I should look into? Thanks, Jay To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Clipboard Daemon - thinking of writing one :)
The hard part is going to be the applications to co-operate. good luck. it's be nice. especially if it worked with the syscons cut-n-paste. julian On Thu, 8 Jul 1999, Mikhail Ramendik wrote: > Hello! > > I am new to FreeBSD and Unix, but not new to programming and TCP/IP. > > I have noticed that there is no good clipboard system in FreeBSD. X has only > a rudimentary clipboard, and outside X there is no clipboard that would be > shared between programs... All this while Windows has a very interesting > clipboard system that allows to paste as different types. > > I am thinking of writing a Clipboard Demon (of course, free and documented > and source and all) to try and tackle this problem. It's going to be a > daemon working over IP, it will allow "named clipboards" so that by default > each user has one clipboard, but a user can start several clipboards and/or > share one over a network (ok, insecure, at least in first releases - but > then, it can be nonsensitive info over a LAN). It will allow a program to > export data into the clipboard in one or _several_ formats (MIME, of > course), and then it will allow the importing program to choose the format > it wants (a la Windows, but no OLE stuff here) and get the data in it. > > For example, a GUI text editor can export the text as native format, text, > formatted text (RTF?), vector graphics (unsure what format would replace WMF > here), bitmap. This same editor will paste the native by default, another > editor will use the formatted text by default, etc. > > Note that it will work independently of X. So I can copy in Joe then paste > to GIMP (as text), if both support the clipboard. > > I will probably have time for actual coding in August or September. But I > want to work out the specs first, and to make sure it's needed at all ;) So, > my questions are: > > - Whether this thing is, in your opinion, needed > > - Whether a similar solution already exists in the freenix world (perhaps in > Linux?) > > - How to handle "big" data? If a program exports a big graphic in several > formats, that's a lot of data... Well, it can not actually send the data but > only indicate it's available - but then we'd have to "call back" to receive > the data, so the program would need to have a permanent connection with the > daemon and "listen" to it, and the availability of data would cease when the > program quits. Should I nevertheless include this behaviour as an option, to > be decided by the exporting program? > > Now the newbie questions: > > - Where can I read a good text on writing FreeBSD daemons? > > - How can I choose a guaranteed free TCP port? > > Yours in Christ, Mikhail Ramendik > Moscow, Russia > > > > > 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: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer)
On Thu, 8 Jul 1999, Seigo Tanimura wrote: > > Ow, I thought it was in the mailing list archive, turned out not. > I will attach the paper below. Sorry for a long mail. > > > --- v --- cut here --- v --- > Unlike 16550, MPU401 does not generate an interrupt on TX-ready. > So we have to choose one of the following two options to drive [...] > alpha and PC98, and tuning hzmul. > --- ^ --- cut here --- ^ --- > > > Seigo Tanimura This is both more general and less general than aquire_timer0() aquiretimer0 assumes that there will only be one user of an elevated clock speed and produces a clock multiple of exactly the period that user requires. This allows us to generate a frequency of (for example) 16KHz. (not a power of 2) When it is not used it is turned off and there is no overhead. With your scheme the clock needs to be always running at elevated speed. Possibly you might have a startup routine that turns on the elevated frequency, (basically does an 'aquire_timer0()' ) I would say that you would have more success in implementing your finetimer() by using "aquiretimer0" than the other way around. a finetimer running at 16KHz (using aquire_timer0()) could allow the use of pca as well. (assuming we allowed 'reference counts on the timer to allow multiple clients that can use the same frequency.) Many people have thought about this. there are people who have run the system with Hz set to 1000 or more without great problems. We have always assumed in writing the code that hz may change so the code should be insulated from that change. The scheduling quantum is even done in uSecs and calculated against Hz. julian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
> we already use the gs register for SMP now.. > what about the fs register? > I vaguely remember that the different segments could be used to achieve > this (%fs points to user space or something) ... as I've suggested a few days ago, and was told to shut up with a (rather irrelevant) reference to SASOS's. It can be done, in fact, it's already been done, with 50%+ performance improvement for tasks that rely heavily on IPC. (think client/server; email me for references.) However, it would involve a rather major redesign of the MMU and some redesign of the syscall stack. Further, one ends up restricting the size of the address space, which is fine until you start loading dynamic libraries. With something like libc, the working set may be small if all you need is a few system call stubs, but you end up with an extremely sparse address space which cannot be handled well with segmentation. Incidentally, you don't need to use FS to implement a tagged TLB using Liedtke's small address spaces. All you need is to modify CS, DS and SS; noone in the unix world relies on the values of ES and FS anyway; if they do, a quick-and-easy segmentation fault will teach them a lesson preaty fast. ;) patryk. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
> Why not put the kernel in a different address space? IIRC there's no > absolute requirement for the kernel and userland to be in the same > address space, and that way we would have 4 GB for each. Wouldn't that make system calls that need to share data between kernel and user spaces hopelessly inefficient? Things like sysctl() would need to introduce (temporary) memory mappings, and someone would have to keep track of these mappings and remove them as required, or the kernel would probably run out of address space in no time, given even with 4GB to spare. On top of that, every mapping established requires some messing arround with the TLB, which, at least on pentium, is rather expensive. Incidentally, someone already experimented with such "dual" address spaces on Linux, and the result was a 30% or so slow down. If you're interested, I can give you the relevant references (the scenario was somewhat different, but the source of the performance hit was the "dual" address space.) patryk. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rtfm' script
On Wed, Jul 7, 1999, Wes Peters wrote: > Now there's an idea! Someone wanna code up wmrtfm real quick? It should > start an rxvt (if available) or xterm running rtfm on strings that are > dropped onto or pasted into the dock icon. Wait until someone writes grtfm! GNOME support, panel applet, comes with Perl, C, C++, and Pascal bindings... > You know, being a program designer is a WHOLE lot easier than being a > programmer. ;^) Most consumers are program designers. "I want it to control my printer and my modem and I want it done NOW." -- Chris Costello There are always at least two ways to program the same thing. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Clipboard Daemon - thinking of writing one :)
Hello! I am new to FreeBSD and Unix, but not new to programming and TCP/IP. I have noticed that there is no good clipboard system in FreeBSD. X has only a rudimentary clipboard, and outside X there is no clipboard that would be shared between programs... All this while Windows has a very interesting clipboard system that allows to paste as different types. I am thinking of writing a Clipboard Demon (of course, free and documented and source and all) to try and tackle this problem. It's going to be a daemon working over IP, it will allow "named clipboards" so that by default each user has one clipboard, but a user can start several clipboards and/or share one over a network (ok, insecure, at least in first releases - but then, it can be nonsensitive info over a LAN). It will allow a program to export data into the clipboard in one or _several_ formats (MIME, of course), and then it will allow the importing program to choose the format it wants (a la Windows, but no OLE stuff here) and get the data in it. For example, a GUI text editor can export the text as native format, text, formatted text (RTF?), vector graphics (unsure what format would replace WMF here), bitmap. This same editor will paste the native by default, another editor will use the formatted text by default, etc. Note that it will work independently of X. So I can copy in Joe then paste to GIMP (as text), if both support the clipboard. I will probably have time for actual coding in August or September. But I want to work out the specs first, and to make sure it's needed at all ;) So, my questions are: - Whether this thing is, in your opinion, needed - Whether a similar solution already exists in the freenix world (perhaps in Linux?) - How to handle "big" data? If a program exports a big graphic in several formats, that's a lot of data... Well, it can not actually send the data but only indicate it's available - but then we'd have to "call back" to receive the data, so the program would need to have a permanent connection with the daemon and "listen" to it, and the availability of data would cease when the program quits. Should I nevertheless include this behaviour as an option, to be decided by the exporting program? Now the newbie questions: - Where can I read a good text on writing FreeBSD daemons? - How can I choose a guaranteed free TCP port? Yours in Christ, Mikhail Ramendik Moscow, Russia To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer)
On Wed, 7 Jul 1999 19:18:57 -0700 (PDT), Julian Elischer said: >> Sorry, finetimer(9) is the new timer implemented in my latest midi driver. >> You can read the short paper describing the feature and principle in: >> >> Message-Id: <199907060959.saa05...@rina.naklab.dnj.ynu.ac.jp> julian> how do I read that? Ow, I thought it was in the mailing list archive, turned out not. I will attach the paper below. Sorry for a long mail. --- v --- cut here --- v --- Unlike 16550, MPU401 does not generate an interrupt on TX-ready. So we have to choose one of the following two options to drive MPU401: A. polling the status to wait until TX-ready, B. emulating a TX-ready interrupt by a timer. The option A, used by VoxWare(sys/i386/isa/sound/sb16_midi.c:sb16midi_out()), consumes most of syscall time to wait for MPU401 to come TX-ready. One byte of midi message takes 0.32ms to transmit. Some certain midi sequences contain continuous long sysexes summed up to 200 bytes or more, leaving a latency of 0.32 * 200 = 60ms or something like that. This latency results in an unstable tempo. I have chosen the option B to eliminate the latency on message transmission. In this case, the timer needs to be capable of a period less than 0.32ms. The conventional timeout(9) has a period of 1/hz[s], which is generally 10ms. (hz = 100) While raising hz to, eg 3000 seems to shorten the period of timeout(9) enough, many parts of the kernel would be affected by this change, likely to end up with poor stability. To solve this problem, I propose a new *fine* callout mechanism. The realtime clock interrupt is at (hz * (1 << hzmul))[Hz], where (1 << hzmul) is the mutiplication ratio of hz. Although the ratio can be any natural number in theory, I have chosen the power of two to reduce the computational cost of the clock divider. (discussed later) As desceribed above, (for i386) clkintr() is called at (hz * (1 << hzmul))[Hz], calling hardclock() at the same frequency. hardclock() has two elements in it: a callout detector and a clock divider. A callout detector traverses the callout list and makes a callout, as in softclock(), except that the IPL stays at splclock. A clock divider reduces the frequency to hz[Hz], to process the conventional hardclock(), which is now renamed to hardclock1(), and softclock(). Although dividing a clock tick generally involves a costing division operation of the dividor counter by (1 << hzmul), a ratio of 2^n allows us to replace the operation with a simple shift of (clkdiv >> hzmul), where clkdiv is the dividor counter incremented one by one on a hardclock(). Fig 1 shows the frequency and the IPL of the new timer handlers. FrequencyIPL Timer ^ ^ Generator | | | | | v(hz * (1 << hzmul))[Hz] splclock clkintr() | | | | | v v v hardclock() -> Fine | Callouts ^ ^ v | | hardclock1() | | | hz[Hz] splsoftclock v | | softclock() -> Conventional | | Callouts v v Fig 1: Call Frequency and IPL under New Timer Handling I have implemented the new fine callout system discussed above in the latest patch of my midi driver. hzmul is 6, to multiply the timer frequency to 6400Hz. The usage of the fine callout is the same as timeout(9), except for the prefix of fine-, and that the granularity of the ticks is (1/(hz * (1 << hzmul)))[s]. Although I have not done any quantitative evaluation yet, I played some midi sequences with sysex messages to show a picture on the LCD of my SC-88, recognizing no latency like VoxWare. This result states the effectiveness of my proposing fine callout system. The future works include porting to alpha and PC98, and tuning hzmul. --- ^ --- cut here --- ^ --- Seigo Tanimura To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
implementing a fs on a raw partition
As I reading on filesystem algorithms and principles [bach 86 and mckusick 96], I am tempted to try my hand on a free partition. From my understanding, I should be using the partition as a character device for raw i/o in order to avoid the current filesystem overhead (/dev/rwd0s3). From that point, I've been using the code from /usr/src/sys/msdosfs in order to get something going at first... but this has shown to be an exhausting task. I keep running into dependencies and such which make it seem impossible to implement. Perhaps I have taken a wrong turn at Albuquerque, so I'd appreciate if anyone could give a hint to get me up and running. Thanks in advance, Marc [bach 86] The Design of the UNIX Operating System, Maurice J. Bach [mckusick 96] The Design and Implementation of the 4.4BSD Operating System, Marshall McKusick, Keith Bostic, Michael J. Karels, John S. Quarterman To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer)
On Thu, 8 Jul 1999, Seigo Tanimura wrote: > On Wed, 7 Jul 1999 19:06:48 -0700 (PDT), > Julian Elischer said: > > julian> uh... > julian> [phaser.whistle.com] 536 man 9 finetimer > julian> No entry for finetimer in section 9 of the manual > > > Sorry, finetimer(9) is the new timer implemented in my latest midi driver. > You can read the short paper describing the feature and principle in: > > Message-Id: <199907060959.saa05...@rina.naklab.dnj.ynu.ac.jp> how do I read that? > > finetimer(9) has the same interface functions as timeout(9), so it should > be easy to use it. > > > Seigo Tanimura > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer)
On Wed, 7 Jul 1999 19:06:48 -0700 (PDT), Julian Elischer said: julian> uh... julian> [phaser.whistle.com] 536 man 9 finetimer julian> No entry for finetimer in section 9 of the manual Sorry, finetimer(9) is the new timer implemented in my latest midi driver. You can read the short paper describing the feature and principle in: Message-Id: <199907060959.saa05...@rina.naklab.dnj.ynu.ac.jp> finetimer(9) has the same interface functions as timeout(9), so it should be easy to use it. Seigo Tanimura To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes: > > And besides, I really don't think this is a grep function but actually > > is useful for programs that don't have any strategy for handling out > > of memory errors and might as well die (with a descriptive error > > message, of course). Let's call it emalloc and let's put in somewhere > > where it can be used. > > Too simple to warrant that, and other programs will likely want to > handle the error differently. I don't agree. 1. this is a small function, but it's useful in lots of programs 2. that helps lazy programmers write code that actually checks for error returns instead of just ignoring them 3. it helps lots of programs that don't do anything intelligent (or for which there isn't much bright things to do) when allocating memory fails 4. having it in a library means it's more likely to be correct (i.e. sz == 0) but then again, I don't get to decide what goes in *BSD libc/libutil. In my library there's already a emalloc, ecalloc, and erealloc. /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Problem with fxp driver and 82559 cards
> >Large data transfers seem to cause the lockup. I know at least 1 netbsd > >person has reported similar problems with these new cards, (kern/7216). > > > >Has anyone seen problems like these? Any ideas? > >Hmmm...I've been using them in some machines here and haven't seen any > problems. Strange. Do all of your systems have similar motherboards and CPU? The only thing that I can identify as a common factor, is that the PCI slots are on a riser card. One type is an NLX-form factor motherboard. The other is an industrial system with a Single Board Computer (SBC) and a passive backplain. Aside from the riser card, these machines are completely different. (IDE vs. SCSI, no other PCI devices, SCSI pci device, pentium vs pentium-II... onboard video/ethernet(in addition to the intel cards) vs nothing onboard...) However, we have at least one industrial-type system (with a different board/config) that works fine with these cards, though we didn't do the install with one. I'll try that tomorrow and report my findings. I doubt this is the case, but is the fxp driver different on the install floppy than on the post-install kernel / kernel-source? Any suggestions as to what I should look into? Thanks, Jay To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer)
uh... [phaser.whistle.com] 536 man 9 finetimer No entry for finetimer in section 9 of the manual On Thu, 8 Jul 1999, Seigo Tanimura wrote: > Another idea has come to my mind... > > > pca(4) currently uses acquire_timer0(), which changes the timer > frequency directly, breaking finetimer(9). I am considering to > move acquire_timer0()s in pca(4) to finetimer(9), so that pca(4) > comes to work again. Furthermore, we can get rid of acquire_timer0() > and the related stuff in clkintr() to be much more simple than now. > > > Any comments? > > > Seigo Tanimura > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
we already use the gs register for SMP now.. what about the fs register? I vaguely remember that the different segments could be used to achieve this (%fs points to user space or something) julian On Wed, 7 Jul 1999, Matthew Dillon wrote: > :Why not put the kernel in a different address space? IIRC there's no > :absolute requirement for the kernel and userland to be in the same > :address space, and that way we would have 4 GB for each. > : > :Greg > > No, the syscall overhead is way too high if we have to mess with MMU > context. This would work fine on certain cpus with hardware PID support, > such as the MIPS, but the entire TLB is wiped when you change the mmu > context on an Intel cpu. > > -Matt > Matthew Dillon > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: The busspace modernization initiative.
In message <19990707230648.d771...@overcee.netplex.com.au> Peter Wemm writes: : At the very least it must use the real resource lists, not a second copy. : That probably means that nexus.c itself would have to export these functions. Yes. Or that bus_space_*map would live in nexus.c. : At the moment, the probe/attach routines use ia_iot from the aux arg: ... : .. using the isa stuff for an example. (tough if they want multiple : IO ports per device, eh? like the keyboard controller at 0x60 and 0x64 with : another device in between...) ok. : It uses the tag to get a handle: : And uses the tag and handle in the bus_space_read/write_xxx() macros. Hmmm. That may mean we'd have to make both bus_space_tag_t and bus_space_handle_t be structs. The bus_space_tag_t so that we know which device it is, and bus_space_handle_t to record the rid. Must ponder. : I don't see why we couldn't add a device_t pointer in there as well, and the : newconfig shim could use it to store the device_t of the wrapper device. Yes. Right now on NetBSD there is only one instance per bus type of the bus_space_tag structure, however. We'd have to have one per device_t that is wrapped. : The bus_space_map() etc macros could then do the proper uplink calls to the : parent bus since it now has access to the device pointer. Yes. That's true. Suddenly, a light has gone on in my head, so I'll try to code this up later this evening and see if the light was a good light, or a wil-o-the-wisp.[*] Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer)
Another idea has come to my mind... pca(4) currently uses acquire_timer0(), which changes the timer frequency directly, breaking finetimer(9). I am considering to move acquire_timer0()s in pca(4) to finetimer(9), so that pca(4) comes to work again. Furthermore, we can get rid of acquire_timer0() and the related stuff in clkintr() to be much more simple than now. Any comments? Seigo Tanimura To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ARP breakage
On Wed, 7 Jul 1999, Justin C. Walker wrote:
> Out of curiosity, what does 'arp -a' show after the 'arp -s'
> command?
Same thing it shows before the "arp -s" attempt, as does "netstat -nr" :(
For the record, regular "arp -s" commands without the "pub" parameter
(i.e. static ARP cache entries, no proxying) work fine.
I have a couple of other related questions for anyone who knows the
answer, too:
1) Can anyone explain the difference between "permanent published" ARP
table entries, and "permanent published (proxy only)" ARP table
entries?
2) What purpose does the RTF_ANNOUNCE (aka RTF_PROTO2) routing message
flag serve? How about the sin_other parameter of the sockaddr_inarp
structure (defined in /usr/include/netinet/if_ether.h)? How do they
relate?
3) How about the significance of the RTF_HOST routing message flag (i.e.
how does an IP "host" route functionally differ from a "net" route with
a /32 netmask)? Or does this only have significance for non-IP routes?
4) What's the purpose of this snippet of code from rtmsg() in
usr.sbin/arp/arp.c?
if (doing_proxy) {
if (export_only)
sin_m.sin_other = SIN_PROXY;
else {
rtm->rtm_addrs |= RTA_NETMASK;
rtm->rtm_flags &= ~RTF_HOST;
}
}
If I remove the last line of code (rtm->rtm_flags &= ~RTF_HOST;) and
recompile the arp command, it seems to insert the correct entry
according to netstat -nr, but arp -a doesn't recognize it as
"published":
# newarp -s 192.168.54.5 auto pub
using interface ed1 for proxy with address 0:e0:29:32:21:ee
# newarp -a
? (192.168.54.5) at 0:e0:29:32:21:ee permanent [ethernet]
? (192.168.54.133) at 0:a0:c9:70:4c:1c [ethernet]
? (192.168.54.254) at 0:e0:1e:b9:7d:c1 [ethernet]
# netstat -nr
Routing tables
Internet:
DestinationGatewayFlags Refs Use Netif Expire
default192.168.54.254 UGSc20 ed1
127.0.0.1 127.0.0.1 UH 04 lo0
192.168.27 link#1 UC 00 fxp0
192.168.54 link#2 UC 00 ed1
192.168.54.5 0:e0:29:32:21:ee UHLS2 00 ed1
192.168.54.133 0:a0:c9:70:4c:1c UHLW1 322 ed1509
192.168.54.254 0:e0:1e:b9:7d:c1 UHLW10 ed1509
Note, however, that the code *with* the rtm->rtm_flags &= ~RTF_HOST;
worked in earlier incarnations of 3.2-STABLE (it's in 3.2-RELEASE).
Cheers,
Mick
The Reverend Jasper P. O'Malley dotdot:jo...@webnology.com
Systems Administrator ringring:asktheadmiral
Webnology, LLC woowoo:http://www.webnology.com/~jooji
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
:Why not put the kernel in a different address space? IIRC there's no :absolute requirement for the kernel and userland to be in the same :address space, and that way we would have 4 GB for each. : :Greg No, the syscall overhead is way too high if we have to mess with MMU context. This would work fine on certain cpus with hardware PID support, such as the MIPS, but the entire TLB is wiped when you change the mmu context on an Intel cpu. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Bursting at the seams (was: Heh heh, humorous lockup)
On Thursday, 8 July 1999 at 9:26:09 +1000, Peter Jeremy wrote: > David Greenman wrote: >> Yes, I do - at least with the 512MB figure. That would be half of the 1GB >> KVA space and large systems really need that space for things like network >> buffers and other map regions. > > Matthew Dillon wrote: >>What would be an acceptable upper limit? 256MB? 128MB? The test >>I ran (Kirk's news test) ate around 60MB for the "FFS Node" memory area >>before the number of vnodes stabilized, on a 1GB machine. I would say >>that a 128MB upper limit would be too small for a 4G machine. A 256MB >>limit ought to work for a 4G machine > > It appears we're rapidly approaching the point where 32-bits isn't > enough. We could increase KVA - but that cuts into process VM space > (and a large machine is likely to have large processes). > > The other option is moving away from a flat memory model: How about > putting some of the larger kernel-only data-structures into another > segment? The downside is that unless we want to start passing `far' > pointers around (which is both ugly and inefficient), we need to > make the pointer address space transparent to the compiler. Why not put the kernel in a different address space? IIRC there's no absolute requirement for the kernel and userland to be in the same address space, and that way we would have 4 GB for each. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rtfm' script
On Wed, Jul 7, 1999, Wes Peters wrote: > Now there's an idea! Someone wanna code up wmrtfm real quick? It should > start an rxvt (if available) or xterm running rtfm on strings that are > dropped onto or pasted into the dock icon. Wait until someone writes grtfm! GNOME support, panel applet, comes with Perl, C, C++, and Pascal bindings... > You know, being a program designer is a WHOLE lot easier than being a > programmer. ;^) Most consumers are program designers. "I want it to control my printer and my modem and I want it done NOW." -- Chris Costello<[EMAIL PROTECTED]> There are always at least two ways to program the same thing. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
implementing a fs on a raw partition
As I reading on filesystem algorithms and principles [bach 86 and mckusick 96], I am tempted to try my hand on a free partition. From my understanding, I should be using the partition as a character device for raw i/o in order to avoid the current filesystem overhead (/dev/rwd0s3). >From that point, I've been using the code from /usr/src/sys/msdosfs in order to get something going at first... but this has shown to be an exhausting task. I keep running into dependencies and such which make it seem impossible to implement. Perhaps I have taken a wrong turn at Albuquerque, so I'd appreciate if anyone could give a hint to get me up and running. Thanks in advance, Marc [bach 86] The Design of the UNIX Operating System, Maurice J. Bach [mckusick 96] The Design and Implementation of the 4.4BSD Operating System, Marshall McKusick, Keith Bostic, Michael J. Karels, John S. Quarterman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Heh heh, humorous lockup
:On Thu, 08 Jul 1999 08:36:19 +0800 : Peter Wemm wrote: : : > Out of curiosity, how does it handle the problem of small 512 byte : > directories? Does it consume a whole page or does it do something smarter? : > Or does the ubc work apply to read/write only and the filesystem itself : > continues to use the buffer cache interfaces for metadata and directories : > still? Does the caching part of the bio system still exist? : :At the moment, only VREG is handled w/ UBC. We plan on addressing that :in the future. : :In the case of file system blocks smaller than a page size, multiple :blocks are read into the page. In the case of small directories, :"we'll burn that bridge when we come to it" (i.e. when we attempt to :deal with non-VREG). : :So, the caching part of the bio interface still exists for now (in part, :this helps us to use file systems which haven't yet been converted to :the UBC interface). : :-- Jason R. Thorpe I would also like to add that FreeBSD's current method of handling small directories does not work very well. It saves memory, sure, but it is based on specialized B_MALLOC buffers in the buffer cache and is unable to use the wider-ranging VM page cache. Since we do not keep buffers around for very long and non-VMIO-backed memory goes away with the buffer, the result is that FreeBSD does a terrible job caching directories. DG and I have experimented with turning on VMIO backing for directories. It works except for a bug in softupdates which I am going to get Kirk interested in (so hopefully it will get fixed). John Dyson is against it due to the waste in memory but I am of the opinion that the waste will not be that bad - and, in anycase, the worst that can happen is that we will throw pages containing directory data away that would have long since been thrown away with the old buffer cache mechanism anyway. For FreeBSD, the changes are so simple that we can add a sysctl to turn the capability on and off. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
sysctl question
How do I set up a sysctl so that I may pass in a two pointers: one to pass in some data another to receive some data ? Is it possible? Otherwise, I think I should just do something with passing in an arbitrary data buffer (pointer to, rather) which contains the data necessary on entrance on exit will receive the (other type) of data as output. Right now, I have myself confused with the sysctl interface and I'm attempting to use oldptr, oldlen, newptr, and newlen all at the same time which is definitely wrong. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer)
On Wed, 7 Jul 1999 19:06:48 -0700 (PDT), Julian Elischer <[EMAIL PROTECTED]> said: julian> uh... julian> [phaser.whistle.com] 536 man 9 finetimer julian> No entry for finetimer in section 9 of the manual Sorry, finetimer(9) is the new timer implemented in my latest midi driver. You can read the short paper describing the feature and principle in: Message-Id: <[EMAIL PROTECTED]> finetimer(9) has the same interface functions as timeout(9), so it should be easy to use it. Seigo Tanimura <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Heh heh, humorous lockup
:The way this is done in the still-in-development branch of NetBSD's :unified buffer cache is to basically elimiate the old buffer cache :interface for vnode read/write completely. When you want to do that :sort of I/O to a vnode, you simply map a window of the object into :KVA space (via ubc_alloc()), do the uiomove (lettings the pages fault :in as necessary, getting added to the vnode's memq), and release the :window (via ubc_release()). The actual window mappings themselves can :persist, as well (although those mappings are nuked immediately if the :vnode is marked VTEXT on VAC machines, to eliminate bad cache interactions). Effectively this is what a piece of our buffer cache code does now. The problem is the other 60% of the buffer cache code that does the more complex stuff. I'd like to see our buffer cache devolve into just the I/O and mapping piece. Now, I also believe that when UVM maps those pages, it makes them copy-on-write so I/O can be initiated on the data without having to stall anyone attempting to make further modifications to the VM object. Is this correct? This is something I would like to throw into FreeBSD at some point. It would get rid of all the freeze/bogus-page hacks already in there and avoid a number of I/O blocking conditions that we currently face. However, I do not like the idea of taking page faults in kernel mode, which I believe UVM also does -- but I think the above could be implemented in FreeBSD without taking page faults. :In addition, as described in the UVM paper at USENIX, placing the :object directly in the vnode (which requires a somewhat fundamental :change in the objects, at least nuking the concept of object chains) Well, I do not like the "nuke the object chains" part of UVM. From what I can tell UVM is doing a considerable amount of extra work to avoid the object chain stuff, but only saving a small amount of overhead on vm_fault's ( though, compared to the original Mach stuff the UVM stuff is much, much better ). We've made a considerable number of improvements to our vm_object's in the last few months. But I do like the idea of a VM-specific substructure for vnodes and I do agree that embedding the master VM object in the vnode is a good idea. -Matt Matthew Dillon :allows a mapped file's pages to persist in the page cache as long as :the vnode itself is not recycled, as opposed to they annoying limit :on persisting vnode objects that used to exist in NetBSD's Mach VM. : :-- Jason R. Thorpe : : To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Someone want to add support for computer radio scaners?
Hello All, I was just looking at http://www.winradio.com/ and was thinking that it would be a nice addition to FreeBSD. I don't own one of the cards, otherwise I would have started to see what I could do. But if anyone out there has one/has access to one, it would be interesting to add into FreeBSD. They also supply information for programming use of the device (http://www.winradio.com/home/developer.htm). Well thats all for now, Mike ___ Get Free Email and Do More On The Web. Visit http://www.msn.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer)
uh... [phaser.whistle.com] 536 man 9 finetimer No entry for finetimer in section 9 of the manual On Thu, 8 Jul 1999, Seigo Tanimura wrote: > Another idea has come to my mind... > > > pca(4) currently uses acquire_timer0(), which changes the timer > frequency directly, breaking finetimer(9). I am considering to > move acquire_timer0()s in pca(4) to finetimer(9), so that pca(4) > comes to work again. Furthermore, we can get rid of acquire_timer0() > and the related stuff in clkintr() to be much more simple than now. > > > Any comments? > > > Seigo Tanimura <[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
Re: Bursting at the seams (was: Heh heh, humorous lockup)
we already use the gs register for SMP now.. what about the fs register? I vaguely remember that the different segments could be used to achieve this (%fs points to user space or something) julian On Wed, 7 Jul 1999, Matthew Dillon wrote: > :Why not put the kernel in a different address space? IIRC there's no > :absolute requirement for the kernel and userland to be in the same > :address space, and that way we would have 4 GB for each. > : > :Greg > > No, the syscall overhead is way too high if we have to mess with MMU > context. This would work fine on certain cpus with hardware PID support, > such as the MIPS, but the entire TLB is wiped when you change the mmu > context on an Intel cpu. > > -Matt > Matthew Dillon > <[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
Re: The busspace modernization initiative.
In message <[EMAIL PROTECTED]> Peter Wemm writes: : At the very least it must use the real resource lists, not a second copy. : That probably means that nexus.c itself would have to export these functions. Yes. Or that bus_space_*map would live in nexus.c. : At the moment, the probe/attach routines use ia_iot from the aux arg: ... : .. using the isa stuff for an example. (tough if they want multiple : IO ports per device, eh? like the keyboard controller at 0x60 and 0x64 with : another device in between...) ok. : It uses the tag to get a handle: : And uses the tag and handle in the bus_space_read/write_xxx() macros. Hmmm. That may mean we'd have to make both bus_space_tag_t and bus_space_handle_t be structs. The bus_space_tag_t so that we know which device it is, and bus_space_handle_t to record the rid. Must ponder. : I don't see why we couldn't add a device_t pointer in there as well, and the : newconfig shim could use it to store the device_t of the wrapper device. Yes. Right now on NetBSD there is only one instance per bus type of the bus_space_tag structure, however. We'd have to have one per device_t that is wrapped. : The bus_space_map() etc macros could then do the proper uplink calls to the : parent bus since it now has access to the device pointer. Yes. That's true. Suddenly, a light has gone on in my head, so I'll try to code this up later this evening and see if the light was a good light, or a wil-o-the-wisp.[*] Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ARP breakage
> From: Jasper O'Malley > Date: 1999-07-07 17:49:24 -0700 > To: hack...@freebsd.org > Subject: ARP breakage > Delivered-to: freebsd-hackers@freebsd.org > X-Loop: FreeBSD.ORG > > > I haven't gotten much of a response in -stable, so I'll ask here. Any one > know what happened to proxy ARP in recent incarnations of 3.2-STABLE? See > problem report bin/12448, but in a nutshell: > [snip] > > # arp -s 192.168.54.5 auto pub > using interface ed1 for proxy with address 0:e0:29:32:21:ee > arp: writing to routing socket: File exists > ^^^ > > What broke? Out of curiosity, what does 'arp -a' show after the 'arp -s' command? Could be something like the "alias" response of 'ifconfig'... Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer)
Another idea has come to my mind... pca(4) currently uses acquire_timer0(), which changes the timer frequency directly, breaking finetimer(9). I am considering to move acquire_timer0()s in pca(4) to finetimer(9), so that pca(4) comes to work again. Furthermore, we can get rid of acquire_timer0() and the related stuff in clkintr() to be much more simple than now. Any comments? Seigo Tanimura <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ARP breakage
On Wed, 7 Jul 1999, Justin C. Walker wrote:
> Out of curiosity, what does 'arp -a' show after the 'arp -s'
> command?
Same thing it shows before the "arp -s" attempt, as does "netstat -nr" :(
For the record, regular "arp -s" commands without the "pub" parameter
(i.e. static ARP cache entries, no proxying) work fine.
I have a couple of other related questions for anyone who knows the
answer, too:
1) Can anyone explain the difference between "permanent published" ARP
table entries, and "permanent published (proxy only)" ARP table
entries?
2) What purpose does the RTF_ANNOUNCE (aka RTF_PROTO2) routing message
flag serve? How about the sin_other parameter of the sockaddr_inarp
structure (defined in /usr/include/netinet/if_ether.h)? How do they
relate?
3) How about the significance of the RTF_HOST routing message flag (i.e.
how does an IP "host" route functionally differ from a "net" route with
a /32 netmask)? Or does this only have significance for non-IP routes?
4) What's the purpose of this snippet of code from rtmsg() in
usr.sbin/arp/arp.c?
if (doing_proxy) {
if (export_only)
sin_m.sin_other = SIN_PROXY;
else {
rtm->rtm_addrs |= RTA_NETMASK;
rtm->rtm_flags &= ~RTF_HOST;
}
}
If I remove the last line of code (rtm->rtm_flags &= ~RTF_HOST;) and
recompile the arp command, it seems to insert the correct entry
according to netstat -nr, but arp -a doesn't recognize it as
"published":
# newarp -s 192.168.54.5 auto pub
using interface ed1 for proxy with address 0:e0:29:32:21:ee
# newarp -a
? (192.168.54.5) at 0:e0:29:32:21:ee permanent [ethernet]
? (192.168.54.133) at 0:a0:c9:70:4c:1c [ethernet]
? (192.168.54.254) at 0:e0:1e:b9:7d:c1 [ethernet]
# netstat -nr
Routing tables
Internet:
DestinationGatewayFlags Refs Use Netif Expire
default192.168.54.254 UGSc20 ed1
127.0.0.1 127.0.0.1 UH 04 lo0
192.168.27 link#1 UC 00 fxp0
192.168.54 link#2 UC 00 ed1
192.168.54.5 0:e0:29:32:21:ee UHLS2 00 ed1
192.168.54.133 0:a0:c9:70:4c:1c UHLW1 322 ed1509
192.168.54.254 0:e0:1e:b9:7d:c1 UHLW10 ed1509
Note, however, that the code *with* the rtm->rtm_flags &= ~RTF_HOST;
worked in earlier incarnations of 3.2-STABLE (it's in 3.2-RELEASE).
Cheers,
Mick
The Reverend Jasper P. O'Malley dotdot:[EMAIL PROTECTED]
Systems Administrator ringring:asktheadmiral
Webnology, LLC woowoo:http://www.webnology.com/~jooji
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Problem with fxp driver and 82559 cards
> I have been using the Intel EtherExpress Pro 10/100B cards for > some time. I just recieved a batch of the Intel Pro/100+ management > adapters. In most of my machines, they don't work. > > Everything I can find says they should be compatible, but there are very > clearly some problems. > > Doing FTP installs is impossible, on 3.2, if I can get it to start at all, > it gets 60% through bin and hangs. 2.2.8 gets 30% through and hangs. > > Large data transfers seem to cause the lockup. I know at least 1 netbsd > person has reported similar problems with these new cards, (kern/7216). I use the new Intel Pro/100+ Management adapters in several FreeBSD servers with no problems. I have also have done a FTP install using these adapters without a problem. You probably want to look elsewhere for the cause of the lockup. Cheers, -- Oliver To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
ARP breakage
I haven't gotten much of a response in -stable, so I'll ask here. Any one know what happened to proxy ARP in recent incarnations of 3.2-STABLE? See problem report bin/12448, but in a nutshell: # ifconfig ed1 ed1: flags=8843 mtu 1500 inet 192.168.54.1 netmask 0xff00 broadcast 192.168.54.255 ether 00:e0:29:32:21:ee # arp -a ? (192.168.54.133) at 0:a0:c9:70:4c:1c [ethernet] ? (192.168.54.254) at 0:e0:1e:b9:7d:c1 [ethernet] # netstat -nr Routing tables Internet: DestinationGatewayFlags Refs Use Netif Expire default192.168.54.254 UGSc20 ed1 127.0.0.1 127.0.0.1 UH 04 lo0 192.168.27 link#1 UC 00 fxp0 192.168.54 link#2 UC 00 ed1 192.168.54.133 0:a0:c9:70:4c:1c UHLW1 128 ed1818 192.168.54.254 0:e0:1e:b9:7d:c1 UHLW10 ed1818 # arp -s 192.168.54.5 auto pub using interface ed1 for proxy with address 0:e0:29:32:21:ee arp: writing to routing socket: File exists ^^^ What broke? Cheers, Mick The Reverend Jasper P. O'Malley dotdot:jo...@webnology.com Systems Administrator ringring:asktheadmiral Webnology, LLC woowoo:http://www.webnology.com/~jooji To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Heh heh, humorous lockup
On Thu, 08 Jul 1999 08:36:19 +0800 Peter Wemm wrote: > Out of curiosity, how does it handle the problem of small 512 byte > directories? Does it consume a whole page or does it do something smarter? > Or does the ubc work apply to read/write only and the filesystem itself > continues to use the buffer cache interfaces for metadata and directories > still? Does the caching part of the bio system still exist? At the moment, only VREG is handled w/ UBC. We plan on addressing that in the future. In the case of file system blocks smaller than a page size, multiple blocks are read into the page. In the case of small directories, "we'll burn that bridge when we come to it" (i.e. when we attempt to deal with non-VREG). So, the caching part of the bio interface still exists for now (in part, this helps us to use file systems which haven't yet been converted to the UBC interface). -- Jason R. Thorpe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Sony Z505S [was: USB floppy & booting]
Ollivier Robert writes: > Do we support booting from USB floppies ? I plan to buy one of the new VAIOs > (probably the Z505S with Celeron/333 + 64 MB + 12.1" screen) and it seems to > come with an USB floppy (as opposed to the probably-IDE of former models). > > They've apparently ditched both the PS/2 mouse and the IDE floppy and moved > to > 2x USB ports... I also have my eye on one of these (or possibly the Z505SX: P-II/366 + 128M). Anyone know what kind of ethernet card is built in? What about the modem? These are new enough that a web search did not reveal much about what is inside. andrew To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Heh heh, humorous lockup
Jason Thorpe wrote: > On Wed, 7 Jul 1999 17:03:16 -0700 (PDT) > Matthew Dillon wrote: > > > If this could result in a smaller overall structure, it may be worth i t. > > To really make the combined structure smaller we would also have to > > pair-down the fields in both structures. For example, the vnode struc ture > > contains a lot of temporary clustering fields that could be removed > > entirely if clustering operations are done at the time of the actual I /O > > rather then before hand ( which leads to other problems related to > > low-memory deadlocks :-(... but assuming that could be fixed... ). > > The way this is done in the still-in-development branch of NetBSD's > unified buffer cache is to basically elimiate the old buffer cache > interface for vnode read/write completely. When you want to do that > sort of I/O to a vnode, you simply map a window of the object into > KVA space (via ubc_alloc()), do the uiomove (lettings the pages fault > in as necessary, getting added to the vnode's memq), and release the > window (via ubc_release()). The actual window mappings themselves can > persist, as well (although those mappings are nuked immediately if the > vnode is marked VTEXT on VAC machines, to eliminate bad cache interactions). Out of curiosity, how does it handle the problem of small 512 byte directories? Does it consume a whole page or does it do something smarter? Or does the ubc work apply to read/write only and the filesystem itself continues to use the buffer cache interfaces for metadata and directories still? Does the caching part of the bio system still exist? Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
sysctl question
How do I set up a sysctl so that I may pass in a two pointers: one to pass in some data another to receive some data ? Is it possible? Otherwise, I think I should just do something with passing in an arbitrary data buffer (pointer to, rather) which contains the data necessary on entrance on exit will receive the (other type) of data as output. Right now, I have myself confused with the sysctl interface and I'm attempting to use oldptr, oldlen, newptr, and newlen all at the same time which is definitely wrong. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: 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: Heh heh, humorous lockup
On Wed, 7 Jul 1999 17:03:16 -0700 (PDT) Matthew Dillon wrote: > If this could result in a smaller overall structure, it may be worth it. > To really make the combined structure smaller we would also have to > pair-down the fields in both structures. For example, the vnode > structure > contains a lot of temporary clustering fields that could be removed > entirely if clustering operations are done at the time of the actual I/O > rather then before hand ( which leads to other problems related to > low-memory deadlocks :-(... but assuming that could be fixed... ). The way this is done in the still-in-development branch of NetBSD's unified buffer cache is to basically elimiate the old buffer cache interface for vnode read/write completely. When you want to do that sort of I/O to a vnode, you simply map a window of the object into KVA space (via ubc_alloc()), do the uiomove (lettings the pages fault in as necessary, getting added to the vnode's memq), and release the window (via ubc_release()). The actual window mappings themselves can persist, as well (although those mappings are nuked immediately if the vnode is marked VTEXT on VAC machines, to eliminate bad cache interactions). Clustering is done by the same clustered pagein/pageout that already exists in UVM. In addition, as described in the UVM paper at USENIX, placing the object directly in the vnode (which requires a somewhat fundamental change in the objects, at least nuking the concept of object chains) allows a mapped file's pages to persist in the page cache as long as the vnode itself is not recycled, as opposed to they annoying limit on persisting vnode objects that used to exist in NetBSD's Mach VM. -- Jason R. Thorpe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Someone want to add support for computer radio scaners?
Hello All, I was just looking at http://www.winradio.com/ and was thinking that it would be a nice addition to FreeBSD. I don't own one of the cards, otherwise I would have started to see what I could do. But if anyone out there has one/has access to one, it would be interesting to add into FreeBSD. They also supply information for programming use of the device (http://www.winradio.com/home/developer.htm). Well thats all for now, Mike ___ Get Free Email and Do More On The Web. Visit http://www.msn.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Heh heh, humorous lockup
On Wed, 7 Jul 1999, Jason Thorpe wrote: > On Wed, 7 Jul 1999 16:55:28 -0700 (PDT) > Julian Elischer wrote: > > > or do what Kirk wants to do and merge the VM and Vnode structures > > I belive the UVM does a bit in this direction due to kirk's influence. > > A uvm_object is not a standalone thing in UVM. Every thing that's > mappable in UVM has a uvm_object embedded in it. > > In the case of vnodes, a vnode contains a uvm_vnode, which in turn contains > a uvm_object. This has direct performance benefits as described in both > Chuck's thesis and in his USENIX paper. > > Now, in the case of the chs-ubc2 branch of the NetBSD source tree, which is > where the unified buffer cache work is happening, there is almost no > distinction between a vnode and an object. Yes, I understand... I was simplifying :-) > > -- Jason R. Thorpe > > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ARP breakage
> From: Jasper O'Malley <[EMAIL PROTECTED]> > Date: 1999-07-07 17:49:24 -0700 > To: [EMAIL PROTECTED] > Subject: ARP breakage > Delivered-to: [EMAIL PROTECTED] > X-Loop: FreeBSD.ORG > > > I haven't gotten much of a response in -stable, so I'll ask here. Any one > know what happened to proxy ARP in recent incarnations of 3.2-STABLE? See > problem report bin/12448, but in a nutshell: > [snip] > > # arp -s 192.168.54.5 auto pub > using interface ed1 for proxy with address 0:e0:29:32:21:ee > arp: writing to routing socket: File exists > ^^^ > > What broke? Out of curiosity, what does 'arp -a' show after the 'arp -s' command? Could be something like the "alias" response of 'ifconfig'... Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Heh heh, humorous lockup
On Wed, 7 Jul 1999 16:55:28 -0700 (PDT) Julian Elischer wrote: > or do what Kirk wants to do and merge the VM and Vnode structures > I belive the UVM does a bit in this direction due to kirk's influence. A uvm_object is not a standalone thing in UVM. Every thing that's mappable in UVM has a uvm_object embedded in it. In the case of vnodes, a vnode contains a uvm_vnode, which in turn contains a uvm_object. This has direct performance benefits as described in both Chuck's thesis and in his USENIX paper. Now, in the case of the chs-ubc2 branch of the NetBSD source tree, which is where the unified buffer cache work is happening, there is almost no distinction between a vnode and an object. -- Jason R. Thorpe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Heh heh, humorous lockup
:or do what Kirk wants to do and merge the VM and Vnode structures :I belive the UVM does a bit in this direction due to kirk's influence. : :julian If this could result in a smaller overall structure, it may be worth it. To really make the combined structure smaller we would also have to pair-down the fields in both structures. For example, the vnode structure contains a lot of temporary clustering fields that could be removed entirely if clustering operations are done at the time of the actual I/O rather then before hand ( which leads to other problems related to low-memory deadlocks :-(... but assuming that could be fixed... ). -Matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Heh heh, humorous lockup
: We've been here before, a couple of times. This started to become an issue :when the limits were removed and has gotten worse as the vnode and fsnode :structs have grown over time. We're running into some limits on how much :space we can give to the kernel since there are a number of folks which :think that 3GB of process VA space is a minimum. I tend to think that the :2GB/2GB split that I use on wcarchive is probably more appropriate as a :default, but like I say, others disagree. : :-DG : :David Greenman If we added the capability to the buffer cache to delete B_DELWRI B_VMIO buffers (leaving dirty VM pages behind), we could reduce the size of the filesystem buffer cache considerably while at the same time improve our ability to cache dirty data - assuming all the other problems related to doing that sort of thing get fixed, that is. I am heading this way already as are others -- the filesystem buffer cache really needs to be relegated to handling active I/O and filesystem mappings, not holding onto dirty data for dear life. This would require keeping track of most dirty pages, which isn't too hard to do - we split the vm_object page list into a clean and a dirty list, and we keep the notion of clean and dirty vnodes so the update daemon doesn't change. If we can reduce the size of the filesystem buffer cache to something reasonable, more KVA space will be available for other kernel things. -- The biggest stumbling block to doing this is the reconstitution overhead of the buffer cache, as demonstrated by this simple test. As you can see by this test, the cost of reconstituting a filesystem buffer on a pentium-Pro 200 is roughly equivalent to 27 MBytes/sec worth of bandwidth. Create a big file: dd if=/dev/zero of=test bs=32k count=4096 DD back in (several times) a block big enough to fit in the VM page cache but not big enough to fit into the filesystem buffer cache. No actual disk I/O occurs: dd if=test of=/dev/null bs=32k count=256 8388608 bytes transferred in 0.146539 secs (57244848 bytes/sec) DD back in (several times) a block big enough to fit in the VM page cache *AND* the filesystem buffer cache. No actual disk I/O occurs: apollo:/usr/obj# dd if=test of=/dev/null bs=32k count=64 2097152 bytes transferred in 0.024780 secs (84630712 bytes/sec) -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Heh heh, humorous lockup
On Wed, 7 Jul 1999, Matthew Dillon wrote: > :>limit ought to work for a 4G machine > :> > :>Since most of those news files were small, I think Kirk's news test code > :>is pretty much the worse case scenario as far as vnode allocation goes. > : > : Well, I could possibly live with 256MB, but the vnode/fsnode consumption > :seems to be getting a bit silly in the memory overhead department, even for > :machines with 4GB of RAM. It seems like there needs to be fewer of them > :and/or they need to go on a diet. > : > :-DG > : > :David Greenman > > Well, the problem occurs because the system has sufficient memory to keep > the underlying VM object around. The current vnode code will not place > a vnode on the free list until the underlying VM object goes away. The > 60MB worth of KVM being used to hold vnodes is supporting 1GB worth > of cached VM pages ( associated with small files, that is ). So even > though the numbers look strange, it does seem to scale. > > In order to turn the maxvnodes sysctl into a harder limit, the vnode > allocation & freeing code would have to be reworked some. Right now > vnodes are not placed back onto the free list until their underlying > VM objects go away. We would need to make the vnode lists (which are > headed by mount table entries) LRU and then attempt to reuse the vnodes > that way, destroying the underlying VM object when necessary. > > Alternatively we can try to make the vnode structure smaller, or we > could try to decouple the vnode from the VM object and instead reference > the VM object by inode. All I can say to that: Yuch. I'd rather just > bump up the KVM. or do what Kirk wants to do and merge the VM and Vnode structures I belive the UVM does a bit in this direction due to kirk's influence. julian > > -Matt > Matthew Dillon > > > > > To Unsubscribe: send mail to majord...@freebsd..org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Problem with fxp driver and 82559 cards
> I have been using the Intel EtherExpress Pro 10/100B cards for > some time. I just recieved a batch of the Intel Pro/100+ management > adapters. In most of my machines, they don't work. > > Everything I can find says they should be compatible, but there are very > clearly some problems. > > Doing FTP installs is impossible, on 3.2, if I can get it to start at all, > it gets 60% through bin and hangs. 2.2.8 gets 30% through and hangs. > > Large data transfers seem to cause the lockup. I know at least 1 netbsd > person has reported similar problems with these new cards, (kern/7216). I use the new Intel Pro/100+ Management adapters in several FreeBSD servers with no problems. I have also have done a FTP install using these adapters without a problem. You probably want to look elsewhere for the cause of the lockup. Cheers, -- Oliver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ARP breakage
I haven't gotten much of a response in -stable, so I'll ask here. Any one know what happened to proxy ARP in recent incarnations of 3.2-STABLE? See problem report bin/12448, but in a nutshell: # ifconfig ed1 ed1: flags=8843 mtu 1500 inet 192.168.54.1 netmask 0xff00 broadcast 192.168.54.255 ether 00:e0:29:32:21:ee # arp -a ? (192.168.54.133) at 0:a0:c9:70:4c:1c [ethernet] ? (192.168.54.254) at 0:e0:1e:b9:7d:c1 [ethernet] # netstat -nr Routing tables Internet: DestinationGatewayFlags Refs Use Netif Expire default192.168.54.254 UGSc20 ed1 127.0.0.1 127.0.0.1 UH 04 lo0 192.168.27 link#1 UC 00 fxp0 192.168.54 link#2 UC 00 ed1 192.168.54.133 0:a0:c9:70:4c:1c UHLW1 128 ed1818 192.168.54.254 0:e0:1e:b9:7d:c1 UHLW10 ed1818 # arp -s 192.168.54.5 auto pub using interface ed1 for proxy with address 0:e0:29:32:21:ee arp: writing to routing socket: File exists ^^^ What broke? Cheers, Mick The Reverend Jasper P. O'Malley dotdot:[EMAIL PROTECTED] Systems Administrator ringring:asktheadmiral Webnology, LLC woowoo:http://www.webnology.com/~jooji To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Berkeley DB question
User Joe wrote: > > Is the berkeley db (or any other small db) multi user safe? Are there > locks to maintain coherency of multiple processes access the same database > files? No. I've heard that Cygnus newlib has a thread-safe version of db or dbm, but haven't checked it out myself. It may bear looking into. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rtfm' script
Bill Fumerola wrote: > > On Tue, 6 Jul 1999, Brian F. Feldman wrote: > > > Thanks! But still, I don't think rtfm is very appropriate... Can we look > > for something better, more obvious? Or perhaps it would be in the motd > > like /stand/sysinstall is people would need to be aware of this. > > it can be called anything. the new user isn't going to know it unless > refered to it. (or unless there is a question mark to click) Now there's an idea! Someone wanna code up wmrtfm real quick? It should start an rxvt (if available) or xterm running rtfm on strings that are dropped onto or pasted into the dock icon. You know, being a program designer is a WHOLE lot easier than being a programmer. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Sony Z505S [was: USB floppy & booting]
Ollivier Robert <[EMAIL PROTECTED]> writes: > Do we support booting from USB floppies ? I plan to buy one of the new VAIOs > (probably the Z505S with Celeron/333 + 64 MB + 12.1" screen) and it seems to > come with an USB floppy (as opposed to the probably-IDE of former models). > > They've apparently ditched both the PS/2 mouse and the IDE floppy and moved to > 2x USB ports... I also have my eye on one of these (or possibly the Z505SX: P-II/366 + 128M). Anyone know what kind of ethernet card is built in? What about the modem? These are new enough that a web search did not reveal much about what is inside. andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Heh heh, humorous lockup
>:>limit ought to work for a 4G machine >:> >:>Since most of those news files were small, I think Kirk's news test code >:>is pretty much the worse case scenario as far as vnode allocation goes. >: >: Well, I could possibly live with 256MB, but the vnode/fsnode consumption >:seems to be getting a bit silly in the memory overhead department, even for >:machines with 4GB of RAM. It seems like there needs to be fewer of them >:and/or they need to go on a diet. > >Well, the problem occurs because the system has sufficient memory to keep >the underlying VM object around. The current vnode code will not place >a vnode on the free list until the underlying VM object goes away. The >60MB worth of KVM being used to hold vnodes is supporting 1GB worth >of cached VM pages ( associated with small files, that is ). So even >though the numbers look strange, it does seem to scale. > >In order to turn the maxvnodes sysctl into a harder limit, the vnode >allocation & freeing code would have to be reworked some. Right now >vnodes are not placed back onto the free list until their underlying >VM objects go away. We would need to make the vnode lists (which are >headed by mount table entries) LRU and then attempt to reuse the vnodes >that way, destroying the underlying VM object when necessary. > >Alternatively we can try to make the vnode structure smaller, or we >could try to decouple the vnode from the VM object and instead reference >the VM object by inode. All I can say to that: Yuch. I'd rather just >bump up the KVM. We've been here before, a couple of times. This started to become an issue when the limits were removed and has gotten worse as the vnode and fsnode structs have grown over time. We're running into some limits on how much space we can give to the kernel since there are a number of folks which think that 3GB of process VA space is a minimum. I tend to think that the 2GB/2GB split that I use on wcarchive is probably more appropriate as a default, but like I say, others disagree. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: docs/12377: doc patch for login_cap.
On Tue, Jul 06, 1999 at 08:06:26AM +0200, Sheldon Hearn wrote: > On Mon, 05 Jul 1999 23:56:17 +0100, Nik Clayton wrote: > > I'm unfamiliar with the ins and outs of the login_cap system. Could > > someone who is versed in it please take a look at this PR (text included) > > and let me know whether or not the suggested patch is correct. > > Quite often, we receive requests to improve documentation that are born > out of a failure to read that documentation correctly. I think this PR > might be one of those cases. Have a look at the login_cap(3) manpage, > into which I suspect the submitter may not have dug deeply enough: I have done. As far as I can tell, the submitter is saying "Yes, the information I was looking for was in the manual page, but it (specifically, that the "root" account doesn't use the "default" entry) is buried as a throw away comment at the end of a long paragraph." The patch in the PR just rewords the paragraph slightly to make this a little more obvious for the next person to come along. I've got no objection to the patch itself, as (IMHO) it does make the para read a little more clearly. If no one objects that it's actually changing the intent of the paragraph then I'll commit it soonish. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <37514...@cs.colorado.edu> To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Heh heh, humorous lockup
:It appears we're rapidly approaching the point where 32-bits isn't :enough. We could increase KVA - but that cuts into process VM space :(and a large machine is likely to have large processes). True, though what we are talking about here is scaling issue with main memory. We should be able to fit everything necessary to support 4GB of ram into a 1GB of KVM. That we aren't means we are doing something wrong somewhere. :The other option is moving away from a flat memory model: How about :putting some of the larger kernel-only data-structures into another :segment? The downside is that unless we want to start passing `far' :pointers around (which is both ugly and inefficient), we need to :make the pointer address space transparent to the compiler. I don't think it is worth it. We would then have to switch the MMU context just going from user to supervisor mode. It would not be too hard to do that since all data movement from the user address space is encapsulated, but it just wouldn't be worth the overhead. The biggest thorn in our side is the filesystem buffer cache. If we could somehow make the KVA mappings apply only to I/O in progress and actively retrieved buffers (getblk()), we would have plenty of KVA space left over for other things. Right now it is fairly expensive to KVA map and unmap the filesystem buffer's b_data pointer. I'm not sure why. :Of course, with proper data-hiding, this exercise is fairly trivial - :only the functions that physically reference the object need to know :where it is. But I don't think the kernel is structured in this way :(for good and valid reasons - CS theoreticians notwithstanding). And :any bugs (like `cheating' by not accessing data through the approved :mechanisms) will lead to fairly obscure panics (the address is :perfectly valid - it's just the wrong segment). : :Peter -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Heh heh, humorous lockup
On Wed, 7 Jul 1999 17:03:16 -0700 (PDT) Matthew Dillon <[EMAIL PROTECTED]> wrote: > If this could result in a smaller overall structure, it may be worth it. > To really make the combined structure smaller we would also have to > pair-down the fields in both structures. For example, the vnode structure > contains a lot of temporary clustering fields that could be removed > entirely if clustering operations are done at the time of the actual I/O > rather then before hand ( which leads to other problems related to > low-memory deadlocks :-(... but assuming that could be fixed... ). The way this is done in the still-in-development branch of NetBSD's unified buffer cache is to basically elimiate the old buffer cache interface for vnode read/write completely. When you want to do that sort of I/O to a vnode, you simply map a window of the object into KVA space (via ubc_alloc()), do the uiomove (lettings the pages fault in as necessary, getting added to the vnode's memq), and release the window (via ubc_release()). The actual window mappings themselves can persist, as well (although those mappings are nuked immediately if the vnode is marked VTEXT on VAC machines, to eliminate bad cache interactions). Clustering is done by the same clustered pagein/pageout that already exists in UVM. In addition, as described in the UVM paper at USENIX, placing the object directly in the vnode (which requires a somewhat fundamental change in the objects, at least nuking the concept of object chains) allows a mapped file's pages to persist in the page cache as long as the vnode itself is not recycled, as opposed to they annoying limit on persisting vnode objects that used to exist in NetBSD's Mach VM. -- Jason R. Thorpe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Heh heh, humorous lockup
On Wed, 7 Jul 1999, Jason Thorpe wrote: > On Wed, 7 Jul 1999 16:55:28 -0700 (PDT) > Julian Elischer <[EMAIL PROTECTED]> wrote: > > > or do what Kirk wants to do and merge the VM and Vnode structures > > I belive the UVM does a bit in this direction due to kirk's influence. > > A uvm_object is not a standalone thing in UVM. Every thing that's > mappable in UVM has a uvm_object embedded in it. > > In the case of vnodes, a vnode contains a uvm_vnode, which in turn contains > a uvm_object. This has direct performance benefits as described in both > Chuck's thesis and in his USENIX paper. > > Now, in the case of the chs-ubc2 branch of the NetBSD source tree, which is > where the unified buffer cache work is happening, there is almost no > distinction between a vnode and an object. Yes, I understand... I was simplifying :-) > > -- Jason R. Thorpe <[EMAIL PROTECTED]> > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Heh heh, humorous lockup
David Greenman wrote: > Yes, I do - at least with the 512MB figure. That would be half of the 1GB >KVA space and large systems really need that space for things like network >buffers and other map regions. Matthew Dillon wrote: >What would be an acceptable upper limit? 256MB? 128MB? The test >I ran (Kirk's news test) ate around 60MB for the "FFS Node" memory area >before the number of vnodes stabilized, on a 1GB machine. I would say >that a 128MB upper limit would be too small for a 4G machine. A 256MB >limit ought to work for a 4G machine It appears we're rapidly approaching the point where 32-bits isn't enough. We could increase KVA - but that cuts into process VM space (and a large machine is likely to have large processes). The other option is moving away from a flat memory model: How about putting some of the larger kernel-only data-structures into another segment? The downside is that unless we want to start passing `far' pointers around (which is both ugly and inefficient), we need to make the pointer address space transparent to the compiler. Of course, with proper data-hiding, this exercise is fairly trivial - only the functions that physically reference the object need to know where it is. But I don't think the kernel is structured in this way (for good and valid reasons - CS theoreticians notwithstanding). And any bugs (like `cheating' by not accessing data through the approved mechanisms) will lead to fairly obscure panics (the address is perfectly valid - it's just the wrong segment). Peter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Heh heh, humorous lockup
:>limit ought to work for a 4G machine :> :>Since most of those news files were small, I think Kirk's news test code :>is pretty much the worse case scenario as far as vnode allocation goes. : : Well, I could possibly live with 256MB, but the vnode/fsnode consumption :seems to be getting a bit silly in the memory overhead department, even for :machines with 4GB of RAM. It seems like there needs to be fewer of them :and/or they need to go on a diet. : :-DG : :David Greenman Well, the problem occurs because the system has sufficient memory to keep the underlying VM object around. The current vnode code will not place a vnode on the free list until the underlying VM object goes away. The 60MB worth of KVM being used to hold vnodes is supporting 1GB worth of cached VM pages ( associated with small files, that is ). So even though the numbers look strange, it does seem to scale. In order to turn the maxvnodes sysctl into a harder limit, the vnode allocation & freeing code would have to be reworked some. Right now vnodes are not placed back onto the free list until their underlying VM objects go away. We would need to make the vnode lists (which are headed by mount table entries) LRU and then attempt to reuse the vnodes that way, destroying the underlying VM object when necessary. Alternatively we can try to make the vnode structure smaller, or we could try to decouple the vnode from the VM object and instead reference the VM object by inode. All I can say to that: Yuch. I'd rather just bump up the KVM. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Heh heh, humorous lockup
On Wed, 7 Jul 1999 16:55:28 -0700 (PDT) Julian Elischer <[EMAIL PROTECTED]> wrote: > or do what Kirk wants to do and merge the VM and Vnode structures > I belive the UVM does a bit in this direction due to kirk's influence. A uvm_object is not a standalone thing in UVM. Every thing that's mappable in UVM has a uvm_object embedded in it. In the case of vnodes, a vnode contains a uvm_vnode, which in turn contains a uvm_object. This has direct performance benefits as described in both Chuck's thesis and in his USENIX paper. Now, in the case of the chs-ubc2 branch of the NetBSD source tree, which is where the unified buffer cache work is happening, there is almost no distinction between a vnode and an object. -- Jason R. Thorpe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Heh heh, humorous lockup
:or do what Kirk wants to do and merge the VM and Vnode structures :I belive the UVM does a bit in this direction due to kirk's influence. : :julian If this could result in a smaller overall structure, it may be worth it. To really make the combined structure smaller we would also have to pair-down the fields in both structures. For example, the vnode structure contains a lot of temporary clustering fields that could be removed entirely if clustering operations are done at the time of the actual I/O rather then before hand ( which leads to other problems related to low-memory deadlocks :-(... but assuming that could be fixed... ). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Heh heh, humorous lockup
>: Yes, I do - at least with the 512MB figure. That would be half of the 1GB >:KVA space and large systems really need that space for things like network >:buffers and other map regions. >: >:-DG >: >:David Greenman >:Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org >:Creator of high-performance Internet servers - http://www.terasolutions.com > >What would be an acceptable upper limit? 256MB? 128MB? The test >I ran (Kirk's news test) ate around 60MB for the "FFS Node" memory area >before the number of vnodes stabilized, on a 1GB machine. I would say >that a 128MB upper limit would be too small for a 4G machine. A 256MB >limit ought to work for a 4G machine > >Since most of those news files were small, I think Kirk's news test code >is pretty much the worse case scenario as far as vnode allocation goes. Well, I could possibly live with 256MB, but the vnode/fsnode consumption seems to be getting a bit silly in the memory overhead department, even for machines with 4GB of RAM. It seems like there needs to be fewer of them and/or they need to go on a diet. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: The busspace modernization initiative.
Warner Losh wrote:
> In message Do
ug Rabson writes:
> : This seems to bypass the nexus completely which isn't right. It wouldn't
> : detect conflicts between bus_space_alloc and the new-bus resource apis
> : since it has its own instances of struct rman.
>
> This is true. However, that's just because that was what the code
> that I acquired from the newconfig people did. I don't think that it
> must be this way.
At the very least it must use the real resource lists, not a second copy.
That probably means that nexus.c itself would have to export these functions.
> : Do we really need to
> : support this api for common newconfig style drivers?
>
> Yes. I believe that we do. One thing that this is used for is to map
> things, even if they conflict. I'm sure I understand why it does that
> beyond checks for conflicts/valid I/O addresses in some drivers
> (mostly the scsi drivers).
>
> I'll have to look into what this API is supposed to do It is
> definitely heavily used (or at least used in almost all) in the few
> drivers that I've tried to port over
At the moment, the probe/attach routines use ia_iot from the aux arg:
struct isa_attach_args {
bus_space_tag_t ia_iot; /* isa i/o space tag */
bus_space_tag_t ia_memt;/* isa mem space tag */
bus_dma_tag_t ia_dmat; /* DMA tag */
isa_chipset_tag_t ia_ic;
int ia_iobase; /* base i/o address */
int ia_iosize; /* span of ports used */
int ia_irq; /* interrupt request */
int ia_drq; /* DMA request */
int ia_drq2;/* second DMA request */
int ia_maddr; /* physical i/o mem addr */
u_int ia_msize; /* size of i/o memory */
void*ia_aux;/* driver specific */
};
.. using the isa stuff for an example. (tough if they want multiple
IO ports per device, eh? like the keyboard controller at 0x60 and 0x64 with
another device in between...)
It uses the tag to get a handle:
if (bus_space_map(iot, ia->ia_iobase, SATLINK_IOSIZE, 0, &ioh))
return (0);
rv = 1;
ia->ia_iosize = SATLINK_IOSIZE;
ia->ia_msize = 0;
bus_space_unmap(iot, ioh, SATLINK_IOSIZE);
return (rv);
And uses the tag and handle in the bus_space_read/write_xxx() macros.
Under NetBSD/i386:
typedef int bus_space_tag_t;
typedef u_long bus_space_handle_t;
But NetBSD/Alpha:
typedef struct alpha_bus_space *bus_space_tag_t;
typedef u_long bus_space_handle_t;
struct alpha_bus_space {
/* cookie */
void*abs_cookie;
/* mapping/unmapping */
int (*abs_map) __P((void *, bus_addr_t, bus_size_t,
int, bus_space_handle_t *, int));
[..]
I don't see why we couldn't add a device_t pointer in there as well, and the
newconfig shim could use it to store the device_t of the wrapper device.
The bus_space_map() etc macros could then do the proper uplink calls to the
parent bus since it now has access to the device pointer.
> It doesn't change the fact that bus_space_hanle_t is supposed to be an
> opaque type and many places in the three don't treat it as such
Yes, agreed there.
> Warner
Cheers,
-Peter
--
Peter Wemm - pe...@freebsd.org; pe...@yahoo-inc.com; pe...@netplex.com.au
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: Heh heh, humorous lockup
: We've been here before, a couple of times. This started to become an issue :when the limits were removed and has gotten worse as the vnode and fsnode :structs have grown over time. We're running into some limits on how much :space we can give to the kernel since there are a number of folks which :think that 3GB of process VA space is a minimum. I tend to think that the :2GB/2GB split that I use on wcarchive is probably more appropriate as a :default, but like I say, others disagree. : :-DG : :David Greenman If we added the capability to the buffer cache to delete B_DELWRI B_VMIO buffers (leaving dirty VM pages behind), we could reduce the size of the filesystem buffer cache considerably while at the same time improve our ability to cache dirty data - assuming all the other problems related to doing that sort of thing get fixed, that is. I am heading this way already as are others -- the filesystem buffer cache really needs to be relegated to handling active I/O and filesystem mappings, not holding onto dirty data for dear life. This would require keeping track of most dirty pages, which isn't too hard to do - we split the vm_object page list into a clean and a dirty list, and we keep the notion of clean and dirty vnodes so the update daemon doesn't change. If we can reduce the size of the filesystem buffer cache to something reasonable, more KVA space will be available for other kernel things. -- The biggest stumbling block to doing this is the reconstitution overhead of the buffer cache, as demonstrated by this simple test. As you can see by this test, the cost of reconstituting a filesystem buffer on a pentium-Pro 200 is roughly equivalent to 27 MBytes/sec worth of bandwidth. Create a big file: dd if=/dev/zero of=test bs=32k count=4096 DD back in (several times) a block big enough to fit in the VM page cache but not big enough to fit into the filesystem buffer cache. No actual disk I/O occurs: dd if=test of=/dev/null bs=32k count=256 8388608 bytes transferred in 0.146539 secs (57244848 bytes/sec) DD back in (several times) a block big enough to fit in the VM page cache *AND* the filesystem buffer cache. No actual disk I/O occurs: apollo:/usr/obj# dd if=test of=/dev/null bs=32k count=64 2097152 bytes transferred in 0.024780 secs (84630712 bytes/sec) -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Problem with fxp driver and 82559 cards
> >Good Afternoon, > > I have been using the Intel EtherExpress Pro 10/100B cards for >some time. I just recieved a batch of the Intel Pro/100+ management >adapters. In most of my machines, they don't work. > >Everything I can find says they should be compatible, but there are very >clearly some problems. > >Doing FTP installs is impossible, on 3.2, if I can get it to start at all, >it gets 60% through bin and hangs. 2.2.8 gets 30% through and hangs. > >Large data transfers seem to cause the lockup. I know at least 1 netbsd >person has reported similar problems with these new cards, (kern/7216). > >Has anyone seen problems like these? Any ideas? Hmmm...I've been using them in some machines here and haven't seen any problems. Strange. Do all of your systems have similar motherboards and CPU? -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Heh heh, humorous lockup
On Wed, 7 Jul 1999, Matthew Dillon wrote: > :>limit ought to work for a 4G machine > :> > :>Since most of those news files were small, I think Kirk's news test code > :>is pretty much the worse case scenario as far as vnode allocation goes. > : > : Well, I could possibly live with 256MB, but the vnode/fsnode consumption > :seems to be getting a bit silly in the memory overhead department, even for > :machines with 4GB of RAM. It seems like there needs to be fewer of them > :and/or they need to go on a diet. > : > :-DG > : > :David Greenman > > Well, the problem occurs because the system has sufficient memory to keep > the underlying VM object around. The current vnode code will not place > a vnode on the free list until the underlying VM object goes away. The > 60MB worth of KVM being used to hold vnodes is supporting 1GB worth > of cached VM pages ( associated with small files, that is ). So even > though the numbers look strange, it does seem to scale. > > In order to turn the maxvnodes sysctl into a harder limit, the vnode > allocation & freeing code would have to be reworked some. Right now > vnodes are not placed back onto the free list until their underlying > VM objects go away. We would need to make the vnode lists (which are > headed by mount table entries) LRU and then attempt to reuse the vnodes > that way, destroying the underlying VM object when necessary. > > Alternatively we can try to make the vnode structure smaller, or we > could try to decouple the vnode from the VM object and instead reference > the VM object by inode. All I can say to that: Yuch. I'd rather just > bump up the KVM. or do what Kirk wants to do and merge the VM and Vnode structures I belive the UVM does a bit in this direction due to kirk's influence. julian > > -Matt > Matthew Dillon > <[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-current" in the body of the message
Re: Heh heh, humorous lockup
: : Yes, I do - at least with the 512MB figure. That would be half of the 1GB :KVA space and large systems really need that space for things like network :buffers and other map regions. : :-DG : :David Greenman :Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org :Creator of high-performance Internet servers - http://www.terasolutions.com What would be an acceptable upper limit? 256MB? 128MB? The test I ran (Kirk's news test) ate around 60MB for the "FFS Node" memory area before the number of vnodes stabilized, on a 1GB machine. I would say that a 128MB upper limit would be too small for a 4G machine. A 256MB limit ought to work for a 4G machine Since most of those news files were small, I think Kirk's news test code is pretty much the worse case scenario as far as vnode allocation goes. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Terminal CTRL-C processing...
This is a dumb question, but I've been trying to hack on it all day, and I'm getting frustrated, so I want throw this in the air for comment... I'm putting the finishing touches on a second revision of the Cyclades Z driver. Its pretty much there, except for when you hit CTRL-C with a shell I suspect the problem has to do with an ioctl() call that isn't completing properly, but I might be terribly wrong. In my first test scenario, when I hit CTRL-C, the application continues to write to the port (ie - the device driver write() routine continues to get called), but the data is basically garbage - rewrites of old data, command history - basically just junk output. I'm 99.9% sure its not the write half of the device drive, as I mentioned the write routine is actually being called repeatedly. On one run, I happened to catch some output (on screen, there doesn't appear to be anything in the logs) that a tiocsettr failed, so I suspected that maybe an IOCTL was getting called at too low of a priority, and the interrupt handler was just hosing it. So, I moved the spltty() call to the top of the routine, so baically the whole routine will run at the tty spl level. Then, on rerunning the test, the machine just hung. Any thoughts on what might be causing this when CTRL-C is hit? I'm expecting that SIGKILL is being sent to the ls command thats running, but I don't understand how that could hose the system so badly that everything else fails -Brian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Berkeley DB question
User Joe wrote: > > Is the berkeley db (or any other small db) multi user safe? Are there > locks to maintain coherency of multiple processes access the same database files? No. I've heard that Cygnus newlib has a thread-safe version of db or dbm, but haven't checked it out myself. It may bear looking into. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rtfm' script
Bill Fumerola wrote: > > On Tue, 6 Jul 1999, Brian F. Feldman wrote: > > > Thanks! But still, I don't think rtfm is very appropriate... Can we look > > for something better, more obvious? Or perhaps it would be in the motd > > like /stand/sysinstall is people would need to be aware of this. > > it can be called anything. the new user isn't going to know it unless > refered to it. (or unless there is a question mark to click) Now there's an idea! Someone wanna code up wmrtfm real quick? It should start an rxvt (if available) or xterm running rtfm on strings that are dropped onto or pasted into the dock icon. You know, being a program designer is a WHOLE lot easier than being a programmer. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Heh heh, humorous lockup
>Since we have increased the hard page table allocation for the kernel to >1G (?) we should be able to safely increase VM_KMEM_SIZE_MAX. I was >thinking of increasing it to 512MB. This increase only effects >large-memory systems. It keeps them from locking up :-) > >Anyone have any objections? Yes, I do - at least with the 512MB figure. That would be half of the 1GB KVA space and large systems really need that space for things like network buffers and other map regions. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Heh heh, humorous lockup
>:>limit ought to work for a 4G machine >:> >:>Since most of those news files were small, I think Kirk's news test code >:>is pretty much the worse case scenario as far as vnode allocation goes. >: >: Well, I could possibly live with 256MB, but the vnode/fsnode consumption >:seems to be getting a bit silly in the memory overhead department, even for >:machines with 4GB of RAM. It seems like there needs to be fewer of them >:and/or they need to go on a diet. > >Well, the problem occurs because the system has sufficient memory to keep >the underlying VM object around. The current vnode code will not place >a vnode on the free list until the underlying VM object goes away. The >60MB worth of KVM being used to hold vnodes is supporting 1GB worth >of cached VM pages ( associated with small files, that is ). So even >though the numbers look strange, it does seem to scale. > >In order to turn the maxvnodes sysctl into a harder limit, the vnode >allocation & freeing code would have to be reworked some. Right now >vnodes are not placed back onto the free list until their underlying >VM objects go away. We would need to make the vnode lists (which are >headed by mount table entries) LRU and then attempt to reuse the vnodes >that way, destroying the underlying VM object when necessary. > >Alternatively we can try to make the vnode structure smaller, or we >could try to decouple the vnode from the VM object and instead reference >the VM object by inode. All I can say to that: Yuch. I'd rather just >bump up the KVM. We've been here before, a couple of times. This started to become an issue when the limits were removed and has gotten worse as the vnode and fsnode structs have grown over time. We're running into some limits on how much space we can give to the kernel since there are a number of folks which think that 3GB of process VA space is a minimum. I tend to think that the 2GB/2GB split that I use on wcarchive is probably more appropriate as a default, but like I say, others disagree. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: docs/12377: doc patch for login_cap.
On Tue, Jul 06, 1999 at 08:06:26AM +0200, Sheldon Hearn wrote: > On Mon, 05 Jul 1999 23:56:17 +0100, Nik Clayton wrote: > > I'm unfamiliar with the ins and outs of the login_cap system. Could > > someone who is versed in it please take a look at this PR (text included) > > and let me know whether or not the suggested patch is correct. > > Quite often, we receive requests to improve documentation that are born > out of a failure to read that documentation correctly. I think this PR > might be one of those cases. Have a look at the login_cap(3) manpage, > into which I suspect the submitter may not have dug deeply enough: I have done. As far as I can tell, the submitter is saying "Yes, the information I was looking for was in the manual page, but it (specifically, that the "root" account doesn't use the "default" entry) is buried as a throw away comment at the end of a long paragraph." The patch in the PR just rewords the paragraph slightly to make this a little more obvious for the next person to come along. I've got no objection to the patch itself, as (IMHO) it does make the para read a little more clearly. If no one objects that it's actually changing the intent of the paragraph then I'll commit it soonish. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
