Re: why FFS is THAT slower than EXT2 ?
I've never had a crashed file system with Freebsd (I started with FreeBSD 1.1) On Wed, 27 Oct 1999, Ilia Chipitsine wrote: -BEGIN PGP SIGNED MESSAGE- Well, guys, listen :-) I and my friends mentioned that "FreeBSD + ffs" is often slower (THAT slower) than "Linux + ext2" for number of tasks: rm, find, tar ... for IDE SCSI disks. I didn't try things like "FreeBSD + ext2" or "Linux + ffs". I attached here results of the test I performed. For test I "gunzip"ped FreeBSD ports collection, in attachment You can find "scripted" output of "# time sh install.sh" for both systems. Also there are "dmesg" outputs. machine was THE SAME: read "dmesg", FreeBSD-3.3 + softupdates + "# tunefs -o time" + "flags 0xb0ffb0ff" (kernel was compiled with "-O2") Linux - RedHat-6.0 with out_of_box_kernel, just "# hdparm -d 1 -c 3 -m 16 /dev/hda", read "hdparm" output... even as non-native English speaker I know few other other words which begin with "f" :-) is "fast" the propriate one for "ffs" ? Regards, (îÁÉÌÕÞÛÉÅ ÐÏÖÅÌÁÎÉÑ) Ilia Chipitsine (éÌØÑ ûÉÐÉÃÉÎ) -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQB1AwUBOBcbQuRxlWKN2EXhAQHHqgL+K+2O8gkv1kYs8AhsqbMsIFTG5u7gfzcT oqqhKlTUlTtaKtAl6g/CnKsPpxfh0CaMEmQC+5bzqSa4MnZcyHwiAWlrNLRlU08A DfYJQRGa/6S5OiaJVYnsAuKnbr6tLZGZ =YWer -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Weird /tmp behaviour
Hi all We've just noticed something strange here, that probably has a mundane explanation but we can't figure it out. On a 2.2.8 FreeBSD system, if anyone creates a file in /tmp, the group gets set to `bin'. The SGID bit is not set, so that doesn't explain it. Does anyone know why this happens? Unfortunately I don't have immediate access to any other releases to see if it is release-specific. -- Dr Graham WheelerE-mail: [EMAIL PROTECTED] Cequrux Technologies Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax:+27(21)24-3656 Data/Network Security SpecialistsWWW:http://www.cequrux.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Weird /tmp behaviour
On Thu, Oct 28, 1999 at 11:06:14AM +0200, Graham Wheeler wrote: Hi all We've just noticed something strange here, that probably has a mundane explanation but we can't figure it out. On a 2.2.8 FreeBSD system, if anyone creates a file in /tmp, the group gets set to `bin'. The SGID bit is not set, so that doesn't explain it. Does anyone know why this happens? Unfortunately I don't have immediate access to any other releases to see if it is release-specific. That's what BSD just does - see open(2): When a new file is created it is given the group of the directory which contains it. The sticky bit on /tmp ensures that only the owner can delete and rename his files in this directory. bye, Harold -- Shabby Sleep is an abstinence syndrome wich occurs due to lack of caffein. Wed Mar 4 04:53:33 CET 1998 #unix, ircnet To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Weird /tmp behaviour
On Thu, 28 Oct 1999, you wrote: On Thu, Oct 28, 1999 at 11:06:14AM +0200, Graham Wheeler wrote: Hi all We've just noticed something strange here, that probably has a mundane explanation but we can't figure it out. On a 2.2.8 FreeBSD system, if anyone creates a file in /tmp, the group gets set to `bin'. The SGID bit is not set, so that doesn't explain it. Does anyone know why this happens? Unfortunately I don't have immediate access to any other releases to see if it is release-specific. That's what BSD just does - see open(2): When a new file is created it is given the group of the directory which contains it. That's pretty weird (but quite correct). Just checked on NetBSD and found the same. I would have expected this behaviour only if the SGID bit was set, not by default. Ah, well, live and learn (and use chown()); -- Dr Graham WheelerE-mail: [EMAIL PROTECTED] Cequrux Technologies Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax:+27(21)24-3656 Data/Network Security SpecialistsWWW:http://www.cequrux.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Weird /tmp behaviour
That's what BSD just does - see open(2): When a new file is created it is given the group of the directory which contains it. That's pretty weird (but quite correct). Just checked on NetBSD and found the same. I would have expected this behaviour only if the SGID bit was set, not by default. It's always been the BSD behavior. Solaris and and some other SVR4 systems do the sgid thing in order to make the BSD behavior possible. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
2 problems with the linksys mx driver
Hi Bill, I'm having quite a few problems with my linksys cards. I think most are caused because I'm connected to a switch rather than a simple hub. The cards are the new Version 2 cards (with Wake On Lan) and use the MX driver. 1) On 3.3-stable, the linksys mx driver detects my network connection to a 3COM switch as 100BaseT4. However, the kernel then panics because if_media cannot support media type 0x28. My workarond was to hack the kernel source for if_mx.c and stop it detecting 100BaseT4. It now detects 100Base Full duplex and works ok. 2) On 4.x-current, the linksys mx driver is connected to a Kingston 10/100 Switch. It does not detect a carrier on the network. If I do ifconfig mx0 media auto I see the 'link in use' and '100 Megs in use' LED on my switch go on for 2 seconds, then go off for 2 seconds, then go on for 2 seconds, then go off for 2 seconds. When the link is up, I can ping and use the network etc. When the link is down, I have no network connection. If I type in ifconfig mx0 media 100basetx it all works OK. Do you have any ideas on these. I'm willing to test patches on both -stable and -current and can swap switches too (swap the 3COM and the Kingston) Thanks Roger -- Roger Hardiman| Telepresence Research Group [EMAIL PROTECTED] | DMEM, University of Strathclyde tel: 0141 548 2897| Glasgow, Scotland, G1 1XJ, UK fax: 0141 552 0557| http://www.telepresence.strath.ac.uk To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Weird /tmp behaviour
On Thu, 28 Oct 1999 [EMAIL PROTECTED] wrote: That's what BSD just does - see open(2): When a new file is created it is given the group of the directory which contains it. That's pretty weird (but quite correct). Just checked on NetBSD and found the same. I would have expected this behaviour only if the SGID bit was set, not by default. It's always been the BSD behavior. Solaris and and some other SVR4 systems do the sgid thing in order to make the BSD behavior possible. There is US government regulation requiring this behavior in certain government systems. The Missed 'em V behavior was created for this. David Scheidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: POSIX threads
I have an application that uses SIGUSR1, but also POSIX threads. It appears (?) that the user-level POSIX threads now incorporated into FreeBSD 3.x use SIGUSR1 and SIGUSR2. Is this correct? If so, and I have a threaded application, what signals are still available for use? No, the threads library that comes with 3.x/4.x does not use SIGUSR1 or SIGUSR2 for anything. It does use SIGPROF via setitimer for its internal scheduling mechanism, and SIGINFO to dump thread information (to aid debugging), but the other signals are available. Perhaps you're confusing libc_r with LinuxThreads which also runs under FreeBSD. I believe LinuxThreads uses SIGUSR1 and/or SIGUSR2. Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: POSIX threads
I'm familiar with LinuxThreads libc_r that uses BOTH SIGUSR1 and SIGUSR2. I recently took code that used to work with FSU's implementation of threads under FreeBSD; and instead recompiled with the new FreeBSD 3.x threads; however, it crashes now when creating threads. The FSU threads (that used to work with FreeBSD 2.x no longer compile under 3.x); so I'm not sure if there's another implementation I can try. Thanks, -david Envelope-to: [EMAIL PROTECTED] Delivery-date: Thu, 28 Oct 1999 09:32:28 -0600 Date: Thu, 28 Oct 1999 11:31:07 -0400 (EDT) From: Daniel Eischen [EMAIL PROTECTED] I have an application that uses SIGUSR1, but also POSIX threads. It appears (?) that the user-level POSIX threads now incorporated into FreeBSD 3.x use SIGUSR1 and SIGUSR2. Is this correct? If so, and I have a threaded application, what signals are still available for use? No, the threads library that comes with 3.x/4.x does not use SIGUSR1 or SIGUSR2 for anything. It does use SIGPROF via setitimer for its internal scheduling mechanism, and SIGINFO to dump thread information (to aid debugging), but the other signals are available. Perhaps you're confusing libc_r with LinuxThreads which also runs under FreeBSD. I believe LinuxThreads uses SIGUSR1 and/or SIGUSR2. Dan Eischen [EMAIL PROTECTED] -- David A. Bader, Ph.D. Office: 505-277-6724 Dept of Electrical and Computer Engineering FAX:505-277-1439 EECE Building University of New Mexico [EMAIL PROTECTED] Albuquerque, NM 87131 http://www.eece.unm.edu/~dbader To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: POSIX threads
I'm familiar with LinuxThreads libc_r that uses BOTH SIGUSR1 and SIGUSR2. I recently took code that used to work with FSU's implementation of threads under FreeBSD; and instead recompiled with the new FreeBSD 3.x threads; however, it crashes now when creating threads. When you say the "new FreeBSD 3.x threads", you mean FreeBSDs default libc_r library, not the LinuxThreads library, right? In what way does your program crash? Have you debugged it? And what version of FreeBSD 3.x are you talking about? Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
I don't like to be the shoot the messenger type - but I have several FreeBSD systems and several Linux systems. Twice I have had my Linux filesystem corrupted beyond recovery - I have never had that problem on FreeBSD. The file system may be marginally slower for certain activities, however, I doubt that the time you save will make up for the time spent reinstalling. -Kip On Wed, 27 Oct 1999, Ilia Chipitsine wrote: -BEGIN PGP SIGNED MESSAGE- Well, guys, listen :-) I and my friends mentioned that "FreeBSD + ffs" is often slower (THAT slower) than "Linux + ext2" for number of tasks: rm, find, tar ... for IDE SCSI disks. I didn't try things like "FreeBSD + ext2" or "Linux + ffs". I attached here results of the test I performed. For test I "gunzip"ped FreeBSD ports collection, in attachment You can find "scripted" output of "# time sh install.sh" for both systems. Also there are "dmesg" outputs. machine was THE SAME: read "dmesg", FreeBSD-3.3 + softupdates + "# tunefs -o time" + "flags 0xb0ffb0ff" (kernel was compiled with "-O2") Linux - RedHat-6.0 with out_of_box_kernel, just "# hdparm -d 1 -c 3 -m 16 /dev/hda", read "hdparm" output... even as non-native English speaker I know few other other words which begin with "f" :-) is "fast" the propriate one for "ffs" ? Regards, (îÁÉÌÕÞÛÉÅ ÐÏÖÅÌÁÎÉÑ) Ilia Chipitsine (éÌØÑ ûÉÐÉÃÉÎ) -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQB1AwUBOBcbQuRxlWKN2EXhAQHHqgL+K+2O8gkv1kYs8AhsqbMsIFTG5u7gfzcT oqqhKlTUlTtaKtAl6g/CnKsPpxfh0CaMEmQC+5bzqSa4MnZcyHwiAWlrNLRlU08A DfYJQRGa/6S5OiaJVYnsAuKnbr6tLZGZ =YWer -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: POSIX threads
On Thu, 28 Oct 1999, David A. Bader wrote: I'm familiar with LinuxThreads libc_r that uses BOTH SIGUSR1 and SIGUSR2. I recently took code that used to work with FSU's implementation of threads under FreeBSD; and instead recompiled with the new FreeBSD 3.x threads; however, it crashes now when creating threads. A traceback would be much more useful, can you possibly provide one? Even better a specific set of code that causes the crash would be even better. thanks, -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: POSIX threads
When you say the "new FreeBSD 3.x threads", you mean FreeBSDs default libc_r library, not the LinuxThreads library, right? Correct. In what way does your program crash? Have you debugged it? And what version of FreeBSD 3.x are you talking about? I'm running FreeBSD-3.3R, and I'll try to provide more debugging information ASAP. Thanks, -david -- David A. Bader, Ph.D. Office: 505-277-6724 Dept of Electrical and Computer Engineering FAX:505-277-1439 EECE Building University of New Mexico [EMAIL PROTECTED] Albuquerque, NM 87131 http://www.eece.unm.edu/~dbader To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ip forwarding broken on alpha
In article [EMAIL PROTECTED], Andrew Gallatin [EMAIL PROTECTED] wrote: I have an older AlphaStation 600 5/266 running -current (cvsupped last week) which is setup as a router between 2 100mb networks. When the machine is pushed fairly hard (like running a netperf -tUDP_STREAM -- -m 100 across the router, eg about 10-20k 100byte packets/sec ) the alpha falls over almost instantly. I have not enabled any NAT or firewall functionality, just ip forwarding. It generally crashes in MCLGET down in the ethernet driver's receiver interrupt handler. I'm probably way off the mark, but I have to ask. Are you sure you're not simply running out of mbufs? I noticed your maxusers is only 32 and I didn't see an options line to raise NMBCLUSTERS. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: xntpd xcdplayer
On Wed, 27 Oct 1999, Mike Pritchard wrote: I've noticed something peculiar over the past week or so with xntpd and I think xcdplayer (from ports). I am running xntpd to keep my clock right. I have an always on DSL connection, so I almost never see any output from xntpd. However, I've noticed that the past few times I've started playing a CD with xcdplayer, I get the following out of xntpd: Oct 27 04:10:44 mpp xntpd[153]: Previous time adjustment didn't complete These are pretty normal on busy systems o rsystems with seriously screwed clocks. Which is somewhat odd, because the last message from xntpd about adjusting the time was over 13 hours ago (and it was a 0.129016 s adjustment). xntpd only logs time steps, not the fractional clock slewing it does constantly. The full steps shouldn't really happen once you're synched, but we all know that PC clocks leave something to be desired. Normally I ignore whatever xntpd tells me, unless it reports a large time difference. But, tonight when I was checking my mail and decided to listen to a CD while doing so, I got the "Previous time adjustment..." message right away after starting to play the CD. And after thinking back, it seems to me that I see more of around the time when I'm playing CDs, so it seems like the two might be related. (IDE) CD activity tends to suspend interrupts for an excessive amount of time. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf problem (panic) SOLVED --possibly related to Berkeley DB 2.7.7
I've increased maxusers to 512, and NMBCLUSTERS to 16384, and I haven't been able to reproduce the kernel panic problem anymore. So, my conclusion is that increasing maxusers solved the problem. I don't believe that raising NMBCLUSTERS by itself, or it indirectly being raised by maxusers, fixed the problem. The reason I think this is because I raised NMBCLUSTERS to 8192 before, and it had no effect whatsover in delaying or preventing the kernel panics I was experiencing. As I described before, right before the panic occurred, the OS began to exponentially use up all of the mbufs, and even if I had set NBMCLUSTERS to 3 it would have used them up in short order. The typical mbuf usage for this system while running all of its software (scripts) is about 100 mbufs, and it has been running over a day now, and not exceeded 962. I've not seen anywhere near the kind of mbuf usage, that occurred when the machine panicked before. This leads me to the conclusion that maxusers, affects many other kernel parameters (which of course it does), and indirectly eliminated the mbuf problem by providing enough resources for the database in all situations, and most especially in cases when Berkeley DB wasn't shut down clean, or in its proper fashion. Although I don't know all of the kernel parameters affected by increasing maxusers, it seems to have solved my problem, and in a roundabout way prevented the machine going into its "spiral-of-death" mbuf problem. -Steve Developer Verio, Inc. verio.com -- the new world of business To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Some modifications to natd. proposal
On Wed, 27 Oct 1999, Damian Kuczynski wrote: Hello I use natd + libalias in my test network connected to internet. From my point of view main disadvantage of this program is, that i can't see what' s going on in packet alias engine, I'm not sure what you're looknig for here... do you want more than what 'natd -l' or strategically located ipfw log rules provide? Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 2 problems with the linksys mx driver
Hi, Problems with linksys (mx driver) cards in -stable and - current If I type in ifconfig mx0 media 100basetx it all works OK. Do you have any ideas on these. Autonegotiation is failing. That happens in the Fast Ethernet world. Buying better quality switches *may* help. ;^) Can you get any better than 3COM's top of the range stacks? Seriously though, in -stable there are 2 bugs with the linksys (mx driver) cards. 1) In if_mx, (and a few other drivers too for that mater) the driver probes the link and then selects the most suitable speed and mode (half or full duplex) The code picks 100BaseT4 as its first chose, then 100 Meg Full Duplex second, then 100 Meg Half duplex, then 10 Full Duplex, then 10 Half duplex. The Ethernet specs I have read say the official order should be 100 Meg Full Duplex FIRST, then 100base T4, then 100 Meg Half duplex, then 10 Full D then 10 Half D. 2) Even if my line was 100BaseT4, the if_mx driver should not be passing an invalid paremter to if_media, causeing if_media to panic with something along the lines of "invalid media type 0x28/0xff" if_mx should not select 100BaseT4 if the rest of the kernel cannot handle it. _OR_ it should be passing the right parameter to if_media. Then there are issues in -current, but lets fix -stable first. This is all a bit different to the Bt848 driver, so I could do with some help kernel hacking. Cheers Roger To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: The sppp driver
(It would be nice if you formatted your message with line breaks.)
"Daniel Hilevich" [EMAIL PROTECTED] wrote:
But, in the later case, the control messages are = queued to the
control queue=20 (sp-pp_cpq) which the if_start functions doesn't
have access to. Should = I implement the access?
Nothing you gotta worry about. The control queue is only there in
order to get higher priority for control packets than for data
packets, in an attempt to speedup control negotiations for interfaces
that are `dial on demand' (i. e., have LINK1 set). This is opaque to
the `customer' of sppp.
- How do you recommend connecting my ioctrl functions to the sppp ioctrl =
function
Have a look at the current `customers' for sppp, which are
sys/i4b/driver/i4b_sppp.c (for a driver that uses dialup connections),
and sys/i386/isa/if_{ar,cx,sr}.c for drivers that use hardware links
(like HDLC lines) without dialling.
- Is there any resource about using the sppp driver. The sppp man page =
isn't satisfying at all.
See above.
--=_NextPart_000_01C7_01BF09C7.C5ECB6F0
Content-Type: text/html;
charset="windows-1255"
Content-Transfer-Encoding: quoted-printable
Please don't do this.
--
cheers, J"org
[EMAIL PROTECTED] -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: 2.88Mb floppies
Wilko Bulte [EMAIL PROTECTED] wrote: Just having installed a 2.88Mb floppy drive in one of my axp boxes I wonder if FreeBSD can do 2.88Mb floppy disks. From the looks of the contents of /sys/i386/isa/fd.c: it appears it cannot. It cannot. I once tried to hack support for 2.88 MB into the existing driver, but eventually gave up. The driver needs a complete rewrite in order to do this (or some royally painful hackups in order to accomodate for the differing FDC clock frequencies, wrt. seek timing etc.). Once i'm retired, i promise to rewrite that driver. :-) -- cheers, J"org [EMAIL PROTECTED] -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A bug in the sppp driver?
"Daniel Hilevich" [EMAIL PROTECTED] wrote: In my case, although, I want to use the IFF_AUTO (dial on demand) option and this is where ifconfig can not help me. In the auto mode, the sppp driver should initialize the lcp machine when it gets a new message to send. Did you ever look how the ISDN `customer' driver handles it? At least for me, it used to work for something like two years now there (and i'm using it daily). Without a massive code review, i can't however tell you the exact chain of events that happens once the callout is triggered, that's nothing one can remember for more than a week. :-) I could however offer you a log from "ifconfig ... debug" for a callout dial-on-demand connection, that should demonstrate the state transitions for normal (i. e. no packet loss) negotiations. -- cheers, J"org [EMAIL PROTECTED] -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Limitations in FreeBSD
Hi ! 1. What is the maximum size of a file on a filesystem ? 2. What is the maximum size of a filesystem ? 3. What is the maximum amount of RAM that FreeBSD can handle ? 4. What is the maximum size of a file that can be mmap´ed ? Furthermore, I understand that FreeBSD can´t mmap a block device. Is it planned to change that ? Thanks ! :-) Michael To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limitations in FreeBSD
On Thu, 28 Oct 1999, Michael Beckmann wrote: Hi ! 1. What is the maximum size of a file on a filesystem ? 2. What is the maximum size of a filesystem ? http://www.freebsd.org/FAQ/install.html#AEN704 - Chris D. Faulhaber [EMAIL PROTECTED] | All the true gurus I've met never System/Network Administrator,| claimed they were one, and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limitations in FreeBSD
:On Thu, 28 Oct 1999, Michael Beckmann wrote: : : Hi ! : : 1. What is the maximum size of a file on a filesystem ? : 2. What is the maximum size of a filesystem ? : :http://www.freebsd.org/FAQ/install.html#AEN704 : :- :Chris D. Faulhaber [EMAIL PROTECTED] | All the true gurus I've met never :System/Network Administrator,| claimed they were one, and always The document is not quite right. The maximum size is limited to 8 Terrabytes due to block-size conversions done in the kernel which are independant of the filesystem block size. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: The sppp driver
of course if you want to be really generic,
we've just added the netgraph code to -current which implements a lot more
than the rather specialised sppp code.
On Thu, 28 Oct 1999, J Wunsch wrote:
(It would be nice if you formatted your message with line breaks.)
"Daniel Hilevich" [EMAIL PROTECTED] wrote:
But, in the later case, the control messages are = queued to the
control queue=20 (sp-pp_cpq) which the if_start functions doesn't
have access to. Should = I implement the access?
Nothing you gotta worry about. The control queue is only there in
order to get higher priority for control packets than for data
packets, in an attempt to speedup control negotiations for interfaces
that are `dial on demand' (i. e., have LINK1 set). This is opaque to
the `customer' of sppp.
- How do you recommend connecting my ioctrl functions to the sppp ioctrl =
function
Have a look at the current `customers' for sppp, which are
sys/i4b/driver/i4b_sppp.c (for a driver that uses dialup connections),
and sys/i386/isa/if_{ar,cx,sr}.c for drivers that use hardware links
(like HDLC lines) without dialling.
- Is there any resource about using the sppp driver. The sppp man page =
isn't satisfying at all.
See above.
--=_NextPart_000_01C7_01BF09C7.C5ECB6F0
Content-Type: text/html;
charset="windows-1255"
Content-Transfer-Encoding: quoted-printable
Please don't do this.
--
cheers, J"org
[EMAIL PROTECTED] -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
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: Limitations in FreeBSD
The document is not quite right. The maximum size is limited to 8 Terrabytes due to block-size conversions done in the kernel which are independant of the filesystem block size. The table in it is also completely hosed. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limitations in FreeBSD
On Thu, 28 Oct 1999, Matthew Dillon wrote: :Hi ! : :1. What is the maximum size of a file on a filesystem ? :2. What is the maximum size of a filesystem ? :3. What is the maximum amount of RAM that FreeBSD can handle ? :4. What is the maximum size of a file that can be mmap´ed ? : :Furthermore, I understand that FreeBSD can´t mmap a block device. :Is it planned to change that ? : :Thanks ! :-) : :Michael The maximum size of a standard filesystem is 8 Terrabytes. The maximum size of a file depends on the filesystem. It is 8 Terrabytes on the standard UFS filesystem. FreeBSD boxes can handle up to 4 Gigabytes of main memory. Block devices are being removed from the system so the answer is no at the moment. If people have a need, we will probably introduce a block device overlay of some sort that would theoretically be mmapable. I think he means block device as in 'disk' not as in 'brwxrwxrwx" -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: Limitations in FreeBSD
According to Michael Beckmann: Furthermore, I understand that FreeBSD can´t mmap a block device. Is it planned to change that ? What is a block device ? /me hides and runs :-) for the humour impaired... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #74: Thu Sep 9 00:20:51 CEST 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limitations in FreeBSD
:On Thu, Oct 28, 1999 at 02:56:00PM -0700, Julian Elischer wrote: : Block devices are being removed from the system so the answer is : no at the moment. If people have a need, we will probably introduce : a block device overlay of some sort that would theoretically be mmapable. : : I think he means block device as in 'disk' not as in 'brwxrwxrwx" : :I was thinking of using a disk without a filesystem, for example for the CNFS :storage method in INN. This requires that the device is mmapable. : :OK, so I know now that I can have pretty large files in the Terabyte range. :Very nice. But I assume I cannot mmap anything like a 100 GB file ? : :Michael Intel cpu's only have a 4G address space. Your are limited to around a 2G mmap()ing. You can mmap() any portion of a larger file but you cannot mmap() the whole file at once. The easiest thing to do is to simply create a number of fixed-sized files and tell CNFS to use them. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limitations in FreeBSD
On Thu, Oct 28, 1999 at 03:53:20PM -0700, Mike Smith wrote: How many fd's do you plan to have open? This would be 2^17 to 2^19. Would that be advisable ? I have never seen anything like that. How severe is the performance penalty (have you actually measured it yet, or are you just going on word of mouth)? The latter. Measuring would be difficult due to lack of tools, and I´d rather not make life tests in production machines. Michael To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limitations in FreeBSD
On Thu, Oct 28, 1999 at 03:53:20PM -0700, Mike Smith wrote: How many fd's do you plan to have open? This would be 2^17 to 2^19. Would that be advisable ? I have never seen anything like that. That would be difficult. How severe is the performance penalty (have you actually measured it yet, or are you just going on word of mouth)? The latter. Measuring would be difficult due to lack of tools, and I´d rather not make life tests in production machines. This is a failure of your approach, I think. You are trying to make a decision without adequate information, which is never a good idea. Craft the tools and make an informed choice. TBH, it sounds like you need to look at a different reader architecture. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limitations in FreeBSD
Michael Beckmann [EMAIL PROTECTED] wrote: On Thu, Oct 28, 1999 at 03:53:20PM -0700, Mike Smith wrote: How severe is the performance penalty (have you actually measured it yet, or are you just going on word of mouth)? The latter. Measuring would be difficult due to lack of tools, and I´d rather not make life tests in production machines. Urk! I don't mean to be insulting, but the notion that you would roll _any_ solution out for a problem of this size based on word of mouth freaks the crap out of me. If you have a genuine need for 500Gig of news spool, and enough users that mmap'ed I/O in nntp is needed and the number of file descriptors is going to be a problem, and you're willing to change architectures if need be, then if you don't have tools - I'd suggest you write some! [And better to start early, because once you roll into production it's too late to write the tools :-),] scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limitations in FreeBSD
On Thu, Oct 28, 1999 at 04:42:42PM -0700, Scott Hess wrote: Urk! I don't mean to be insulting, but the notion that you would roll _any_ solution out for a problem of this size based on word of mouth freaks the crap out of me. Hey ! You guys seem to have pretty strict opinions about how to solve problems. Right now I am just investigating the options and asking for the properties of this FreeBSD OS (where news is not the only reason for finding out about them). If you have a genuine need for 500Gig of news spool, This is roughly 10 days of newsfeed, btw. and enough users that mmap'ed I/O in nntp is needed and the number of file descriptors is going to be a problem, and you're willing to change I would like to know if that number of file descriptors is going to be a problem, could someone tell me please ? It appears that 2^17 are settable through sysctl, but will I actually be able to use that many ? (Yes, I could write a tool to find it out, but I am willing to rely on word of mouth here). Thanks, Michael To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limitations in FreeBSD
Michael Beckmann wrote: On Thu, Oct 28, 1999 at 03:34:53PM -0700, Matthew Dillon wrote: :OK, so I know now that I can have pretty large files in the Terabyte range. :Very nice. But I assume I cannot mmap anything like a 100 GB file ? : :Michael Intel cpu's only have a 4G address space. Your are limited to around a 2G mmap()ing. You can mmap() any portion of a larger file but you cannot mmap() the whole file at once. The easiest thing to do is to simply create a number of fixed-sized files and tell CNFS to use them. Here is the problem: When you want to have 500 GB of storage, you will need 250 files. In the current implementation of nnrpd, this will need 250 file descriptors per nnrpd. This will I think this situation will bring you where you started: you will be able to map a whole one file, but only one file at a time, not 250 files at once. So it would be simpler and more efficient to have only one big file and map the pieces of it as needed. I would also suggest to make these pieces much smaller than 2G: then you will be able to map a number of them at once and when you decide to substitute one mapped piece for another you won't have to re-create the page tables for the whole 2G of the address space. I guess the best size of these pieces depends on the typical request size of your application. limit the number of readers that can be supported on a system, because a nnrpd is spawned for each reader. I was told that nnrpd can be hacked to only consume file descriptors when really needed, but it´s supposed to have a performance penalty. Mapping and unmapping frequently the whole 2G files would impose much higher performance penalty. Also if you plan to have many processes doing mmaps don't forget that each of them would consume some kernel address space for its page tables. With big mmaps you would exhaust your kernel address space very quickly (an example of this is that Oracle on UnixWare uses special calls using 4MB physical pages to map its SGA, otherwise the kernel virtual memory on a large-physical-memory machine gets exhausted very quickly and with terrible consequences). The page tables for such amounts of memory would consume the kernel virtual memory much faster than 250 file descriptors per process. That´s why I´m looking for a way of having large mmap´able files. Are you saying that ALL Intel CPUs, including PIII, can only address 4 GB? I probably need to look at other architectures or solve this fd problem. Pentiums can address more physical memory (again, UnixWare supports up to 16GB of physical memory) - at the price of some performance penalty, but not virtual memory. A 64-bit architecture such as Alpha, UltraSPARC or HP PA-8000 may help you. But I guess what you really need is to split your very big file into a number of pages of some reasonable size and map/unmap them as needed. Although the RISC architectures (at least PA-RISC and RS/6000 but I think the others too) use different organisation of the page tables and for them mapping the big memory areas in many processes should not be a big problem. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limitations in FreeBSD
: Urk! I don't mean to be insulting, but the notion that you would roll : _any_ solution out for a problem of this size based on word of mouth freaks : the crap out of me. : :Hey ! You guys seem to have pretty strict opinions about how to solve problems. :Right now I am just investigating the options and asking for the properties of :this FreeBSD OS (where news is not the only reason for finding out about them). : : If you have a genuine need for 500Gig of news spool, : :This is roughly 10 days of newsfeed, btw. This is roughly 20 days of newsfeed if one take the porn, warez, and binaries groups, which contain mostly junk, and try to hold onto them for the full expiration time. If the person setting up the system were to spend a little time filtering out the junk and/or adjusting the expiration it is fairly easy to get away with much smaller spools and an order of magnitude cheaper system. At BEST I wound up using around a 40G spool. If the person isn't willing to filter he pretty much deserves all the pain he creates for himself :-(. Roughly speaking, less then 1% of a typical userbase even bothers to read usenet news. In anycase... I don't know what INN is doing these days, but I do know that lots of people run large spools with it on 32 bit machines just fine. Most of the assumptions I've heard so far are absurd for *any* UNIX box, not just an intel box. INN is a heavy-weight system but it doesn't eat hundreds of file descriptors per nnrpd process. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ip forwarding broken on alpha
Andrew Gallatin writes:
I have an older AlphaStation 600 5/266 running -current (cvsupped
last week) which is setup as a router between 2 100mb networks. When
the machine is pushed fairly hard (like running a netperf -tUDP_STREAM
-- -m 100 across the router, eg about 10-20k 100byte packets/sec ) the
alpha falls over almost instantly. I have not enabled any NAT or
firewall functionality, just ip forwarding.
...
This might be a red herring, but I've found that if I run the entire
ip_input path under splnet() (added splnet() around the call to
ip_input() in ipintr().), things get a hell of a lot more stable.
Rather than crashing in a few seconds, it sometimes takes minutes.
And rather than an illegal access, I tend to run out of kernel stack
space ( either a panic("possible stack overflow\n"); in
alpha/alpha/interrupt.c, or I end up in the SRM console after calling
halt from a PC which isn't in the kernel, which smells like an overrun
stack to me). I'm not sure if this is related, or if it is a separate
problem entirely.
That was it.
The problem is that the interrupt handler returns through
exception_return, like the trap handler does. Exception_return checks
to see if the last ipl the system was at was 0. If it was, it
eventually lowers the ipl to zero and checks for a pending ast. This
was the problem. If you're getting interrupts quickly enough, there's
large window when you're still running on the interrupt stack where
you're sitting at ipl0 and you can get another interrupt build onto
that stack. If you're getting 40,000 interrupts per second
(forwarding 20,000 packets/sec), this can build up rapidly run you
out of stack space.
I've found the system can forward 70,000 packets per second remain
perfectly stable with the appended patch. I'm not terribly good at
assembler, so rather than try to be tricky check to see if the
current ipl is = 4 (handling a device interrupt), I simply copied
exception_return skipped the ipl lowering the check for an ast
since I don't think you're ever going to need to check for an ast
after an interrupt.
I have NFC why mclfree was getting trashed, but it must have been
caused by running out of stack space as the appended patch seems to
take care of everything.
Doug -- should I commit this as-is, or do you want to take a more
refined approach?
Drew
--
Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin
Duke University Email: [EMAIL PROTECTED]
Department of Computer Science Phone: (919) 660-6590
Index: exception.s
===
RCS file: /home/ncvs/src/sys/alpha/alpha/exception.s,v
retrieving revision 1.3
diff -u -r1.3 exception.s
--- exception.s 1999/08/28 00:38:26 1.3
+++ exception.s 1999/10/28 19:17:26
@@ -76,7 +76,7 @@
/* a0, a1, a2 already set up */
mov sp, a3 ; .loc 1 __LINE__
CALL(interrupt)
- jmp zero, exception_return
+ jmp zero, interrupt_return
END(XentInt)
/**/
Index: swtch.s
===
RCS file: /home/ncvs/src/sys/alpha/alpha/swtch.s,v
retrieving revision 1.11
diff -u -r1.11 swtch.s
--- swtch.s 1999/08/28 00:38:32 1.11
+++ swtch.s 1999/10/28 20:08:24
@@ -308,6 +308,61 @@
.set at
END(exception_return)
+
+
+LEAF(interrupt_return, 1) /* XXX should be NESTED */
+ br pv, Lintr_er1
+Lintr_er1: LDGP(pv)
+
+ ldq s1, (FRAME_PS * 8)(sp) /* get the saved PS */
+ and s1, ALPHA_PSL_IPL_MASK, t0 /* look at the saved IPL */
+ bne t0, Lintr_restoreregs /* != 0: can't do AST or SIR */
+
+ /* see if we can do an SIR */
+ ldl t1, ipending/* SIR pending? */
+ beq t1, Lintr_chkast/* no, try an AST*/
+
+ /* We've got a SIR. */
+ CALL(do_sir)/* do the SIR; lowers IPL */
+
+Lintr_chkast:
+
+ and s1, ALPHA_PSL_USERMODE, t0 /* are we returning to user? */
+ beq t0, Lintr_restoreregs /* no: just return */
+
+Lintr_setfpenable:
+ /* enable FPU based on whether the current proc is fpcurproc */
+ ldq t0, curproc
+ ldq t1, fpcurproc
+ cmpeq t0, t1, t0
+ mov zero, a0
+ cmovne t0, 1, a0
+ call_pal PAL_OSF1_wrfen
+
+Lintr_restoreregs:
+ /* set the hae register if this process has specified a value */
+ ldq t0, curproc
+ beq t0, Lintr_nohae
+ ldq t1, P_MD_FLAGS(t0)
+ and t1, MDP_HAEUSED
+ beq t1, Lintr_nohae
+ ldq a0, P_MD_HAE(t0)
+ ldq pv, chipset
Re: Limitations in FreeBSD
: : The document is not quite right. The maximum size is limited to : 8 Terrabytes due to block-size conversions done in the kernel which are : independant of the filesystem block size. : :Can you tell me how to get the 8TB value? I know all the things about :indirect blocks and I know that we use negative numbers for those indirect :blocks. Thanks. : :-Zhihui The kernel uses 512 byte blocks internally. 32 bit block number quantities are used. To avoid sign problems we only allow 31 bits to be used within the kernel (negative block number quantities are also used within the kernel to identify meta-data). So: 2^31 = 2 billion x 512 = 1 TB. Hmm. That isn't 8 TB. I think we might have a problem over 1 TB with mmap() and the VM system. Grr. Maybe the I/O subsystem too. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limitations in FreeBSD
Here is the problem: When you want to have 500 GB of storage, you will need 250 files. In the current implementation of nnrpd, this will need 250 file descriptors per nnrpd. This will limit the number of readers that can be supported on a system, because a nnrpd is spawned for each reader. I was told that nnrpd can be hacked to only consume file descriptors when really needed, but it´s supposed to have a performance penalty. That´s why I´m looking for a way of having large mmap´able files. Are you saying that ALL Intel CPUs, including PIII, can only address 4 GB? I probably need to look at other architectures or solve this fd problem. Michael Is FreeBSD available for Alpha's 64 bit arch (1.8e19)? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limitations in FreeBSD
Matthew Dillon wrote: : If you have a genuine need for 500Gig of news spool, : :This is roughly 10 days of newsfeed, btw. This is roughly 20 days of newsfeed if one take the porn, warez, and binaries groups, which contain mostly junk, and try to hold onto them for the full expiration time. If the person setting up the system were to spend a little time filtering out the junk and/or adjusting the expiration it is fairly easy to get away with much smaller spools and an order of magnitude cheaper system. At BEST I wound up using around a 40G spool. If the person isn't willing to filter he pretty much deserves all the pain he creates for himself :-(. Roughly speaking, less then 1% of a typical userbase even bothers to read usenet news. I think if such a high amount of space with such a high number of parallel users is a must then a lot simpler approach would be to divide the news spool (say, by newsgroups) among multiple machines and set up one machine as a kind of proxy, to accept requests from the users and forward them to a machine which really has this particular newsgroup on it. That would also solve the problem with the CPU load and memory size. For further scalability there may be multiple proxy machines and a load balancing appliance of the same kind as the ones used for the web servers. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limitations in FreeBSD
That´s why I´m looking for a way of having large mmap´able files. Are you saying that ALL Intel CPUs, including PIII, can only address 4 GB? That's correct; it's why the ia32 architecture has a '32' in its name. I don't believe that's true. I don't have any hard evidence within easy reach, but with the introduction of the Pentium, the address space was increased. A user process, of course, can only have 4G of addressible space (32-bit addresses) but the OS can map pages of the 4G space into a larger area. Something to do with 4MB pages instead of 4K pages. Again, I could be wrong on this one. Chuck Youse To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limitations in FreeBSD
On 28-Oct-99 Mike Smith wrote: That´s why I´m looking for a way of having large mmap´able files. Are you saying that ALL Intel CPUs, including PIII, can only address 4 GB? That's correct; it's why the ia32 architecture has a '32' in its name. Note quite. With PAE (Page Address Extensions available on PPro's and some later chips) you can get an extra 4 bits, for a total of 36 bits of addressable space, or 64 Gig. That still won't help out very much, however, for this problem. --- John Baldwin [EMAIL PROTECTED] -- http://www.cslab.vt.edu/~jobaldwi/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limitations in FreeBSD
On 29-Oct-99 Chuck Youse wrote: That´s why I´m looking for a way of having large mmap´able files. Are you saying that ALL Intel CPUs, including PIII, can only address 4 GB? That's correct; it's why the ia32 architecture has a '32' in its name. I don't believe that's true. I don't have any hard evidence within easy reach, but with the introduction of the Pentium, the address space was increased. A user process, of course, can only have 4G of addressible space (32-bit addresses) but the OS can map pages of the 4G space into a larger area. It was the PPro, not the Pentium, and it is called Page Address Extensions.. it does some funky stuff with the page tables to gain an extra 4 bits for a total of 64 gig of addressable space. It ends up using 4k and 2mb pages. Something to do with 4MB pages instead of 4K pages. This is a seperate issue known as Page Size Extensions and actually was present in some i486dx4/100's. Basically, it allows you to directly map 4mb with a single page entry by leaving out the bottommost layer of the page tables. Again, I could be wrong on this one. Chuck Youse --- John Baldwin [EMAIL PROTECTED] -- http://www.cslab.vt.edu/~jobaldwi/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limitations in FreeBSD
On Fri, 29 Oct 1999, Michael Beckmann wrote: Here is the problem: When you want to have 500 GB of storage, you will need 250 files. In the current implementation of nnrpd, this will need 250 file descriptors per nnrpd. This will limit the number of readers that can be supported on a system, because a nnrpd is spawned for each reader. I was told that nnrpd can be hacked to only consume file descriptors when really needed, but it´s supposed to have a performance penalty. That´s why I´m looking for a way of having large mmap´able files. Are you saying that ALL Intel CPUs, including PIII, can only address 4 GB? I probably need to look at other architectures or solve this fd problem. Michael Have a look in news.software.nntp. Some of the folks there have built some monster news systems on intel boxes (including FreeBSD). They surely have encountered some of the hurdles you forsee. There was an excellent thread last summer about building a distributed scalable news system that would scale to a million users with a FreeBSD/Diablo combination. A search for Joe Greco and Diablo at deja should turn up some gems. - Barrett To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limitations in FreeBSD
Yuch. The page address extension junk is just that... junk. Besides, as was mentioned it wouldn't help mmap() at all. Registers are 32 bits and nobody is going to revisit the segmentation (retch) stuff. Ugh, two icky things in one paragraph, excuse me please while I take a trip to the bathroom! -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ip forwarding broken on alpha
On Thu, 28 Oct 1999 21:32:51 -0400 (EDT) Andrew Gallatin [EMAIL PROTECTED] wrote: exception_return skipped the ipl lowering the check for an ast since I don't think you're ever going to need to check for an ast after an interrupt. Nonsense. ASTs are a key part of process scheduling, and I'd bet that you run into strange scheduling behaviour if you don't deal with ASTs after e.g. clock interrupts. -- Jason R. Thorpe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limitations in FreeBSD
That's correct; it's why the ia32 architecture has a '32' in its name. I don't believe that's true. I don't have any hard evidence within easy reach, but with the introduction of the Pentium, the address space was increased. A user process, of course, can only have 4G of addressible space (32-bit addresses) but the OS can map pages of the 4G space into a larger area. Something to do with 4MB pages instead of 4K pages. Again, I could be wrong on this one. Think about it for a second. How big is a pointer? -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CCD questions
"Stephen J. Roznowski" wrote: I'm looking at the tutorial on building CCDs at Why? Do you have a compelling reason not to use Vinum volume manager? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RTLD_GLOBAL/RTLD_LOCAL dlopen mode flags
hi, there! Are there any plans to implement RTLD_GLOBAL/RTLD_LOCAL mode flags for dlopen? /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 2 problems with the linksys mx driver
Autonegotiation is failing. That happens in the Fast Ethernet world. Buying better quality switches *may* help. ;^) Can you get any better than 3COM's top of the range stacks? I ran into a similar problem with a couple Linksys cards under both FBSD (ugh) Win95 -- telling the HP ProCurve 2424M to force 100BTX half-duplex (didn't try full) fixed the problem Still seeing this autoneg problem with my cheapy Linksys 100-only hub and my wife's Linksys card on '95... You'd figure that autoneg would work when everything's by the same manufacturer :) mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: The sppp driver
As Julian Elischer wrote: of course if you want to be really generic, we've just added the netgraph code to -current which implements a lot more than the rather specialised sppp code. Sure, i was only answering a question. -- cheers, J"org [EMAIL PROTECTED] -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
