Re: 4.10-RELEASE and -STABLE crashing regularly under load
On Tue, Jun 15, 2004 at 10:34:57PM +0200, Tamas TEVESZ wrote: > > hi folks, > > [i've posted the following message to -bugs@ a while ago, but > then was directed here by a friend freebsder. while reposting, i > also corrected some minor facts i missed in the previous post] > > i have a dell poweredge 2600 (4G ram, 2x2.8ghz xeon cpus, some disk, > full dmesg below), running a heavily loaded website (apache13, php, cgi, > pure-ftpd). this is a brand new 4.10-release install, brought to sync > with -stable, both exhibit the exact same problem), which every once > in a while crashes badly. 4.10-R did that every ~2.5 days, 4.10-S did > it for the first time after one day. (before that, system was running > 4.9-stable on a poweredge 4600 with one xeon cpu, no ht, no smp, > no nothing like that, and was very stable). > > i cannot entirely rule out bad hardware as this is a brand new system, > but we haven't had many problems with dell stuff before. > > everything i think to be related is included below; if anything else > is needed just please tell so. Isn't this the board that apparently can't do HTT without crashing? Try disabling HTT completely instead, as I don't think the sysctl does that. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ <> [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: memory mapped packet capturing - bpf replacement ?
On Mon, Jun 14, 2004 at 06:47:49PM +0100, Bruce M Simpson wrote: > On Mon, Jun 14, 2004 at 08:38:57AM -0400, Ed Maste wrote: > > Hello Sergey. I haven't looked at your code, but I'll provide > > some comments, having implemented a mmaped ringbuffer BPF > > replacement myself. > > We've had some prior interest in this. Do you have patches? If so, I'd be > more than happy to look at them. > > Linux has something similar, but when I looked at the mechanism involved, > I was loathe to adopt the same logic because the buffer(s) involved were > allocated from userland and then mapped accordingly; we generally can't > afford to take a page fault in that path, for mutex related reasons. If I finally get to finish fixing wiring, you should simply be able to call vslock(9) in your kernel module and get that functionality. As it is, vslock(9) is broken -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ <> [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Orinoco Gold and Linksys AP
On Sat, Jun 05, 2004 at 12:37:28PM -0600, M. Warner Losh wrote: > What firmware level do you have? Both wi and owi works for all my > lucent/wavelan/orinoco cards. :-( Try changing the WEP information many times. Eventually, the card just goes away and never returns to initialized state, and the interface is still up but it's dead to the world. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ <> [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: machine is unusable with panic: vrele: negative ref cnt
On Sat, Jun 05, 2004 at 06:08:31PM -0700, Alan Evans wrote: > On boot I see the following on an IBM T30 laptop: > > Mounting root from ufs:/dev/ad0s1a > WARNING: / was not properly dismounted > ad0: FAILURE - READ_MUL status=59 > error=40 LBA=376639 I would stick that drive in another machine and try to get SMART status information from it. There is a port for smartmontools that can be very informative about the health of the drive. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ <> [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.2.1: Mutex/Spinlock starvation?
On Sat, Jun 05, 2004 at 10:55:31PM +0200, Ali Niknam wrote: > I tried this; this helps performance a lot, here are the findings: > - under all conditions turning on HTT helps a *lot* (which is logical i > think) > - under non killing load (killing load = load where server would have > crashed without this option) it performs much much better > - under killing load it performs a lot better, up until a certain level: > - a new killing level: from this point onward basically the same thing > happens as before.. Something is happening which should not be at a much more fundamental level. Something is going on to cause everything to block in Giant. That could be some exceptionally-long operation that executes, holding Giant, without andy context switches. In general, this is really what you would call a "deadlock," but at least you can recover from it. If the system is totally unresponsive to your input, is it still working from the standpoint of the users on it? Are there strange syslog messages? Can you watch the history of sysctl vm.vmtotal, sysctl vm.zone, and vmstat -m to see if it's a memory starvation issue? -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ <> [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: KVA space problems?
On Wed, May 26, 2004 at 03:15:44PM -0400, lost inferno wrote: > I posted something to stable about this, but Im wondering if anyone has > seen this... I saw something over here ( http://gobsd.com/node/view/39 ) > that made me really consider my options as the 4.x series comes to an > end... is anyone else looking into this? Perhaps i would be best off to > move over to this DragonFly thing and see what it's about. > > Interested to see what everyone thinks. Please refrain from making a huge thread out of this. The author of that page knows nothing about FreeBSD, obviously, or he'd realize that a branch called "-CURRENT" exists and has very little in common with much of either FreeBSD 4.x or DragonFlyBSD. Consider gobsd.com as having about the same level of integrity as slashdot.org. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ <> [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Memory Leak
On Sat, May 22, 2004 at 10:30:42PM -0600, M. Warner Losh wrote: > Any suggestions for leak detectors that work in real-time or in > response to some external signal? In a threaded application would be > ideal. > > I've hacked malloc to add the stack traceback to the utrace info > that's output by malloc. However, for applications that run for days, > and tend to allocate and free a lot of memory, you gotta have lots of > local storage. The restrictions in the kernel that requires this to > be a real file makes it harder. > > Also, there's a difference between what's in use and what is leaking.. Try boehm-gc; I run the following local patch to the ports to fix a few things and let me enable compile options from the ports infrastructure. You can call the detector at any time to see if any leaks have occurred made. http://green.homeunix.org/~green/boehm-gc.diffs> -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ <> [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vn swapfiles deleted while in use
On 13 Jun 1999, Joel Ray Holveck wrote: > What, to the reckoning of the resident populace, would happen if > somebody were to rm a vnconfig'd swapfile while it was in use? My reckoning is that the dirent would be deleted, and that's it. It would most likely go away when the system is restarted. Does it continue to work for you? > > Thanks, > joelh > > -- > Joel Ray Holveck - jo...@gnu.org >Fourth law of programming: >Anything that can go wrong wi > sendmail: segmentation violation - core dumped > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.freebsd.org _ |___/___/___/ " THAT'S WRONG WRONG WRONG!" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: High syscall overhead?
On Sun, 13 Jun 1999 sth...@nethelp.no wrote: > > Linux is a Unix clone, while FreeBSD is Unix. Don't confuse people with > > this. > > I'm afraid that attitude isn't going to help Unix agains Windows... > > I use FreeBSD for all my systems. I still go around and tell people that > Linux is one several Unix variants, and I intend to continue doing this. > For an end user, the differences between for instance FreeBSD and Linux > are in most cases small and rather uninteresting - and it's much more > useful to point out the differences between Unix and Windows. > And the differences between a BSD system and Linux aren't huge? Nay, sir, surely you jest. I, personally, dislike people using the wrong terminology. Linux is a relatively Unix-like and relatively POSIX-compliant system, but it's not Unix. What's wrong with calling a system by its true name? > Steinar Haug, Nethelp consulting, sth...@nethelp.no > > Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.freebsd.org _ |___/___/___/ " THAT'S WRONG WRONG WRONG!" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: UDP sockets
On Sun, 13 Jun 1999, Southern Branch of the P.P.Shirshov Institute of Oceanology wrote: > Hi ! > I have a problem. > My program creates UDP-socket and after that it tries to create UDP or > TCP-socket. But last one doesn't work. > TCP doesn't execute "accept" > UDP doesn't execute "recvfrom" > What can I do ? This is almost CERTAINLY programmer error. Have someone experienced look at your source. > > Answer me via e-mail:pa...@sdios.sea.ru > > Thank you > Pavel > > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.freebsd.org _ |___/___/___/ " THAT'S WRONG WRONG WRONG!" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: High syscall overhead?
On Sun, 13 Jun 1999, Chuck Robey wrote: > On Sat, 12 Jun 1999, Bill Huey wrote: > > > Well, so far I've heard alot of BS about Linux that isn't exactly true > > and much of it seems like a bunch of artificial problems that hold > > against the Linux folks. Most of it is just intentionally misrepresented > > bullshit. > > That is totally wrong, Bill. We have a public mail archive, so if you > don't like to believe me, go check our archive. YOU have been the only > source of either Linux or FreeBSD bashing. We have a pretty pleasing > assortment of grownups here, who have gone past the point of needing to > claim "my ball is better than your ball". Exactly. Do you have references? > > One of my own personal complaints about the Linux groups is that they > seem to grow the kind of people who need to disparage in order to feel > good. This might be because my only exposure to Linux persons is via > Usenet, which is immersed in that teenage-type philosophy. I don't know > of any Linux mailing lists of the order of the FreeBSD lists. The Linux-kernel mailing list seems to be closer to -hackers. > > We don't need that approach here, it doesn't increase knowledge, > and only hurts feelings. If you follow up on this thread, please DROP > all Linux/FreeBSD comparisons of that order. We all know that both > Linux AND FreeBSD are fine unixes, and we don't need bashing here. Linux is a Unix clone, while FreeBSD is Unix. Don't confuse people with this. > > This list does occaisonally have some comparisons, Linux vs. FreeBSD, > but if it isn't kept strictly technical, and non-accusatory, we don't > want it or need it. > > I have seen people in the past that were honestly surprised at the huge > difference between Usenet newsgroup rules, and our FreeBSD list rules. > If you actually fit in that category, maybe you should "lurk" these > lists for a while, so you can see the difference, and not find yourself > outside of our lists normal behaviour. The noise to content ratio is MUCH higher on Usenet, and probably will always be. > > > > > I came on this list initially to just check was the FreeBSD community > > was like, but what I've gotten since is alot of ego and hostility > > toward things that aren't completely FreeBSD. That's something that > > I didn't expect and reading this list has given me a particular > > negative view of FreeBSD that wasn't present before. > > People don't like your need to compare, in order to make one group seem > better or worse than another. You need to find some other way to get > your point across. > > > > > In-fighting with the current NFS maintainer and general rudeness to other > > potential devs make FreeBSD's kernel people look like bunch of dorks whether > > you like it or not. Don't confuse fighting with "not sweeping issues under the carpet." > > > > I'm also not big enough asshole ot put someone on a "kill-list" and is just > > a reflection of a kind of conservative need to dehumanize other folks > > so that your selfish comfort is "preserved". > > Profanity is also one of the things not accepted here. Damn straight! Sorry, couldn't resist. Profanity isn't that unacceptable, if appropriate (sometimes it is..), but personal attacks ARE. > > > > > > Wes Peters Softweyr LLC > > > > bill > > > > > > > > To Unsubscribe: send mail to majord...@freebsd.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > +--- > Chuck Robey | Interests include any kind of voice or data > chu...@picnic.mat.net | communications topic, C programming, and Unix. > 213 Lakeside Drive Apt T-1 | > Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. > (301) 220-2114 | > +--- > > > > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.freebsd.org _ |___/___/___/ " THAT'S WRONG WRONG WRONG!" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: select(2) breakage
On 13 Jun 1999, Dag-Erling Smorgrav wrote: > Brian Feldman writes: > > On 13 Jun 1999, Dag-Erling Smorgrav wrote: > > > connect() normally uses the 1024-5000 range. Try the following: > > > > > > # sysctl -w net.inet.ip.portrange.last=4 > > > > > > and see if it solves the EAGAIN problem. > > > > Actually, this is the perfect explanation. I think that this should go in > > the FAQ. Why in the world are we limiting the ports we can use other than > > from 1-1023? > > I have no idea. The only use I've ever had for this is the > predictability of FTP data port numbers, since ftpd will normally use > the high range (49152-65535). Useful for designing firewalls, and if > you don't like opening such a wide port range, you can whittle it down > to a handful (say, one thousand) of ports with judicious use of sysctl. > > I couldn't find any reference to this in RFC 793, 1122, 1123, 1700 or > 2577. Remind me to build a glimpse index of my RFC collection... > > This still doesn't explain select()'s failure to time out, although I > should point out that you forgot to increase FD_SETSIZE before > including , and I'm not sure your computation of > highestsock is correct, since there's no guarantee that fdvec is > sorted. I haven't tested your code though, I just looked over it > quickly. I have two copies. One has FD_SETSIZE increased to 30004 and a vector size of 3. The other has FD_SETSIZE default (1024) and a vector of 512. The guarantee of fdvec is sorted is that Unix behavior is to allocate the next available fd, so highestsock is correct. The program is correct, except I didn't have a linefeed in the select() status printing, so it DID time out successfully, but you didn't see the status report. > > BTW, you should check for errno == EINTR when select() returns -1. The perror() is the status report for select() when -1. > > DES > -- > Dag-Erling Smorgrav - d...@flood.ping.uio.no > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.freebsd.org _ |___/___/___/ " THAT'S WRONG WRONG WRONG!" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: select(2) breakage
On 13 Jun 1999, Dag-Erling Smorgrav wrote: > Brian Feldman writes: > > Another problem that came up with this: I originally started at port 1024. > > I monopolized 3 ports (almost all consecutive, of course). When I try to > > connect() a TCP socket as non-root, it fails with EAGAIN (I only tracked it > > far enough down as in_pcbbind().) It seems that eventually it gives up > > trying > > to find a port... :-/ > > What kind of connects are you doing? If you try to connect all your > sockets to the same destination,port tuple you'll quickly run out of > source ports, since there are only a little less than 4,000 ports > available: > > d...@des ~% sysctl -A | grep portrange > net.inet.ip.portrange.lowfirst: 1023 > net.inet.ip.portrange.lowlast: 600 > net.inet.ip.portrange.first: 1024 > net.inet.ip.portrange.last: 5000 > net.inet.ip.portrange.hifirst: 49152 > net.inet.ip.portrange.hilast: 65535 > > connect() normally uses the 1024-5000 range. Try the following: > > # sysctl -w net.inet.ip.portrange.last=4 > > and see if it solves the EAGAIN problem. Actually, this is the perfect explanation. I think that this should go in the FAQ. Why in the world are we limiting the ports we can use other than from 1-1023? > > DES > -- > Dag-Erling Smorgrav - d...@flood.ping.uio.no > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.freebsd.org _ |___/___/___/ " THAT'S WRONG WRONG WRONG!" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Just connect(2) breakage (Was Re: select(2) breakage)
On Sun, 13 Jun 1999, Brian Feldman wrote:
> I'm using the attached program which I wrote today (don't ask why, I think
> I just wanted to beat the heck out of FreeBSD!) I have maxusers 200, a
> MAXFILES=65536, and the limits set to allow me to use the program
> fully (all 3 ports; I don't want to monopolize EVERY port...) When
> run, select doesn't time out after 60 seconds like it should.
Disregard this part! User error (not making sure stdio is flushed).
> Another problem that came up with this: I originally started at port 1024.
> I monopolized 3 ports (almost all consecutive, of course). When I try to
> connect() a TCP socket as non-root, it fails with EAGAIN (I only tracked it
> far enough down as in_pcbbind().) It seems that eventually it gives up trying
> to find a port... :-/
This problem is quite real.
>
> Brian Feldman_ __ ___ ___ ___ ___
> gr...@unixhelp.org_ __ ___ | _ ) __| \
> FreeBSD: The Power to Serve! _ __ | _ \._ \ |) |
> http://www.freebsd.org _ |___/___/___/
> " THAT'S WRONG WRONG WRONG!"
>
> /*-
> * Copyright (c) 1999 Brian Fundakowski Feldman
> * All rights reserved.
> *
> * Redistribution and use in source and binary forms, with or without
> * modification, are permitted provided that the following conditions
> * are met:
> * 1. Redistributions of source code must retain the above copyright
> *notice, this list of conditions and the following disclaimer.
> * 2. Redistributions in binary form must reproduce the above copyright
> *notice, this list of conditions and the following disclaimer in the
> *documentation and/or other materials provided with the distribution.
> *
> * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
> * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
> * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> * SUCH DAMAGE.
> *
> * $Id$
> *
> */
>
> #include
> #include
> #include
> #include
>
> #include
>
> #include
> #include
> #include
> #include
> #include
> #include
>
> int
> anothersocket(u_short port) {
> struct sockaddr_in sin;
> int fd, serrno;
>
> if ((fd = socket(PF_INET, SOCK_STREAM, 0)) == -1)
> return fd;
>
> sin.sin_family = AF_INET;
> sin.sin_port = htons(port);
> sin.sin_addr.s_addr = htonl(INADDR_ANY);
> if (bind(fd, (struct sockaddr *)&sin, sizeof(sin)) == -1) {
> serrno = errno;
> close(fd);
> errno = serrno;
> return -1;
> }
>
> listen(fd, 1);
>
> return fd;
> }
>
> int
> allocatesockets(int *fdvec, u_short *portvec, int nsockets) {
> int fd, ncreated = 0, serrno;
> u_short port = 32768;
>
> while (nsockets) {
> if (++port == 65535)
> break;
> if ((fd = anothersocket(port)) == -1)
> if (errno == ENFILE || errno == EMFILE) {
> serrno = errno;
> close(fdvec[--ncreated]);
> errno = serrno;
> break;
> } else
> continue;
> portvec[ncreated] = port;
> fdvec[ncreated++] = fd;
> nsockets--;
> }
>
> return ncreated;
> }
>
> int
> main(int argc, char **argv) {
> int fdvec[3];
> u_short portvec[3];
> int nsockets, tmp, highestsock;
> fd_set odescriptors, ndescriptors;
> struct timeval timeout;
>
> nsockets = allocatesockets(fdvec, portvec,
> sizeof(fdvec) / sizeof(fdvec[0]));
> printf("%s started: %d PF_INET SOCK_STREAM sockets ready\n",
> strrchr(argv[0], '/') + 1, nsockets);
> highestsock = fdvec[nsockets - 1] + 1;
> FD_ZERO(&
select(2) breakage
I'm using the attached program which I wrote today (don't ask why, I think
I just wanted to beat the heck out of FreeBSD!) I have maxusers 200, a
MAXFILES=65536, and the limits set to allow me to use the program
fully (all 3 ports; I don't want to monopolize EVERY port...) When
run, select doesn't time out after 60 seconds like it should.
Another problem that came up with this: I originally started at port 1024.
I monopolized 3 ports (almost all consecutive, of course). When I try to
connect() a TCP socket as non-root, it fails with EAGAIN (I only tracked it
far enough down as in_pcbbind().) It seems that eventually it gives up trying
to find a port... :-/
Brian Feldman_ __ ___ ___ ___ ___
gr...@unixhelp.org_ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \._ \ |) |
http://www.freebsd.org _ |___/___/___/
" THAT'S WRONG WRONG WRONG!"
/*-
* Copyright (c) 1999 Brian Fundakowski Feldman
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $Id$
*
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int
anothersocket(u_short port) {
struct sockaddr_in sin;
int fd, serrno;
if ((fd = socket(PF_INET, SOCK_STREAM, 0)) == -1)
return fd;
sin.sin_family = AF_INET;
sin.sin_port = htons(port);
sin.sin_addr.s_addr = htonl(INADDR_ANY);
if (bind(fd, (struct sockaddr *)&sin, sizeof(sin)) == -1) {
serrno = errno;
close(fd);
errno = serrno;
return -1;
}
listen(fd, 1);
return fd;
}
int
allocatesockets(int *fdvec, u_short *portvec, int nsockets) {
int fd, ncreated = 0, serrno;
u_short port = 32768;
while (nsockets) {
if (++port == 65535)
break;
if ((fd = anothersocket(port)) == -1)
if (errno == ENFILE || errno == EMFILE) {
serrno = errno;
close(fdvec[--ncreated]);
errno = serrno;
break;
} else
continue;
portvec[ncreated] = port;
fdvec[ncreated++] = fd;
nsockets--;
}
return ncreated;
}
int
main(int argc, char **argv) {
int fdvec[3];
u_short portvec[3];
int nsockets, tmp, highestsock;
fd_set odescriptors, ndescriptors;
struct timeval timeout;
nsockets = allocatesockets(fdvec, portvec,
sizeof(fdvec) / sizeof(fdvec[0]));
printf("%s started: %d PF_INET SOCK_STREAM sockets ready\n",
strrchr(argv[0], '/') + 1, nsockets);
highestsock = fdvec[nsockets - 1] + 1;
FD_ZERO(&odescriptors);
for (tmp = 0; tmp < nsockets; tmp++)
FD_SET(fdvec[tmp], &odescriptors);
for (;;) {
int nfound, curnum, nset;
int *selected;
u_short *selectedports;
const struct timespec sleeper = { 0, 1 };
timeout.tv_sec = 60;
timeout.tv_usec = 0;
ndescriptors = odescriptors;
if ((nfound = select(highestsock, &ndescriptors, NULL, NULL,
&timeout)) < 1) {
if (nfound == -1)
perror(
Re: High syscall overhead?
On 12 Jun 1999, Arun Sharma wrote: > "John S. Dyson" writes: > > > Finegrained locking either requires developers with IQ's of 200 or higher, > > or a different kernel structure. I suggest that finegrained locking is > > cool, > > and can be intelligently used to mitigate (but not solve) the effects of > > lots of problems > > Fine grained locking is hard - but it isn't exactly rocket > science. It's been tackled in a number of OSes, papers have been > written about it. That's untrue if you're using asynchronous I/O. > > > -- however, it would be unwise to embark on an effort to make > > the FreeBSD kernel into an efficent 16way SMP kernel by using finegrained > > locking all over the place. > > Sure. But 2 and 4-way boxes are becoming more and more mainstream. And > any IO bound job is not going to perform well on FreeBSD because of > giant locking. Not quite as well, but it will still be much faster. Besides, FreeBSD would perform better under load than nearly any other OS, so it's not as if it would be slower than something else. > > One way of tackling the problem is - to implement per lock profiling > and detect which locks are being contested heavily and try breaking > them down. That would be a practical way of doing things. But you can't generalize FreeBSD's usage, can you? > > An alternative way, which requires a good understanding of both the > theory and implementation of the kernel is - > > (a) Implement per subsystem locking That seems to be the most winning solution. > (b) Figure out in a "typical" workload, how much time is being spent > in which subsystem and try increasing parallelism (i.e. finer > grained locking) in subsystems where more time is being spent. Once again, there is no "typical" unless you try to overgeneralize and say "FreeBSD is used mostly for XXX." This would be just an extension of a. But this is much less of a gain (from what I conjecture). It would make sense to have separate locks for, say, at least the I/O subsystems (all in total, not for each one. Why do you want to parallel something that's doing DMA?), FS interfaces, VM/trapping, and networking. > > The result of this approach should be more logical, cleaner and > possibly better performing than the previous one. > > -Arun > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.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: High syscall overhead?
On Sat, 12 Jun 1999, John S. Dyson wrote: > Soren Schmidt said: > [Charset ISO-8859-1 unsupported, filtering to ASCII...] > > It seems Christopher R. Bowman wrote: > > [exelent explanation snipped] > > > The alternative to the Giant Kernel Lock(tm) is so called fine grained > > > locking > > > wherein locking is pushed down closer to the data structures. In fine > > > grained > > > locking two processors might be executing in the kernel at the same time, > > > but > > > only if they didn't need the same resources. On might be doing a disk > > > read > > > while the other queues up a character for the serial port. The fine > > > grained > > > lock has the potential for higher parallelism and thus better throughput > > > since > > > process may not have to wait as long, but the larger number of locks with > > > their > > > many required lock and unlock operations add overhead and further the > > > design is > > > more difficult and error prone since the interaction of the numerous > > > locks may > > > result in deadlock or livelock situations every bit as problematical as > > > the > > > problem they try to solve. > > > > There are also those of us that dont belive in finegrained locking, exactly > > because of all the small locks you have to check/lock/open, the overhead is > > not worth it. > > > Finegrained locking either requires developers with IQ's of 200 or higher, > or a different kernel structure. I suggest that finegrained locking is cool, > and can be intelligently used to mitigate (but not solve) the effects of > lots of problems -- however, it would be unwise to embark on an effort to make > the FreeBSD kernel into an efficent 16way SMP kernel by using finegrained > locking all over the place. But your microkernel-hybrid BSD will do 16way SMP with a fully-parallelized kernel? > > -- > John | Never try to teach a pig to sing, > dy...@iquest.net | it makes one look stupid > jdy...@nc.com | and it irritates the pig. > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.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: Supprting twist for inetd with libwrap
One of the nice things about Unix has always been low process-spawning overhead. FreeBSD should do quite well, especially, since it is demand-paged and a fork doesn't actually copy much, just the vm map and makes everything COW. Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.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: problem for the VM gurus
On Wed, 9 Jun 1999, John S. Dyson wrote: > Howard Goldstein said: > > On Mon, 7 Jun 1999 18:38:51 -0400 (EDT), Brian Feldman > > wrote: > > : On Mon, 7 Jun 1999, Matthew Dillon wrote: > > : > ... what version of the operating system? > > : 4.0-CURRENT > > > > 3.2R too... > > > I just checked the source (CVS) tree, and something bad happend > between 1.27 and 1.29 on ufs_readwrite.c. Unless other things > had been changed to make the problem go away, the recursive vnode > thing was broken then. I am surprised that was changed that long > ago. (The breakage is an example of someone making a change, and > not either understanding why the code was there, or forgetting to > put the alternative into the code.) Is that the limit to Bruce's fu*kup, or did he break it elsewhere, too? It'd be nice to get this reversed since it's been found. And FWIW, semenu seems to be the only one to have anything to handle IN_RECURSE, probably because his NTFS code was recently committed and not mangled. > > -- > John | Never try to teach a pig to sing, > dy...@iquest.net | it makes one look stupid > jdy...@nc.com | and it irritates the pig. > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.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: Strange kernel messages
I don't know why it's there, but that seems to be the sysctl tree. Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.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: problem for the VM gurus
On Mon, 7 Jun 1999, Matthew Dillon wrote: > ... what version of the operating system? > > -Matt 4.0-CURRENT > > : In the long-standing tradition of deadlocks, I present to you all a new > one. > :This one locks in getblk, and causes other processes to lock in inode. It's > :easy to induce, but I have no idea how I'd go about fixing it myself > :(being very new to that part of the kernel.) > : Here's the program which induces the deadlock: > : > :#include > :#include > :... > Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.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: problem for the VM gurus
One of the problems that would make it sensible to do a complete rewrite of vfs_bio.c is this? Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.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
problem for the VM gurus
In the long-standing tradition of deadlocks, I present to you all a new one.
This one locks in getblk, and causes other processes to lock in inode. It's
easy to induce, but I have no idea how I'd go about fixing it myself
(being very new to that part of the kernel.)
Here's the program which induces the deadlock:
#include
#include
#include
#include
#include
int
main(int argc, char **argv) {
int psize = getpagesize() * 2;
void *tmp;
char name[] = "m.XX";
int fd = mkstemp(name);
if (fd == -1) {
perror("open");
exit(1);
}
tmp = mmap(NULL, psize, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
if (tmp == MAP_FAILED) {
perror("mmap");
exit(1);
}
printf("write retval == %lld", write(fd, tmp, psize));
unlink(name);
exit(0);
}
Brian Feldman_ __ ___ ___ ___ ___
gr...@unixhelp.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: so_cred changes
On Mon, 31 May 1999, Chris Costello wrote: > On Sun, May 30, 1999, Nik Clayton wrote: > > Cheers, committed. > >Already? As the CVS tree (at least the one on > anoncvs.freebsd.org) has it, the so_cred changes haven't been > committed yet. *Laugh* I think that the doc was the only thing that was committed. > > -- > Chris Costello > Exclusive: We're the only ones who have the documentation. > Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.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
so_cred changes
Here they all are! I bumped __FreeBSD_version so this can be detected outside
of the kernel (*cough* pidentd *cough*); this makes pidentd a lot simpler; I
am also going to write a sysctl interface for getting credential info soon,
so I'll reimplement identd then. Anyone for /usr/libexec/identd? :)
IPFW UID/GID support still works, but I'm cleaning up (Since I just broke it out
of so_cred changes, and it can USE the cleanup.)
Anyone for committing the so_cred changes? I've got the the pidentd changes
here, too.
Brian Feldman_ __ ___ ___ ___ ___
gr...@unixhelp.org_ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \ _ \ |) |
http://www.freebsd.org _ |___)___/___/
--- src/sys/sys/socketvar.h.origSat May 29 17:26:53 1999
+++ src/sys/sys/socketvar.h Sun May 30 11:07:07 1999
@@ -105,7 +105,7 @@
void(*so_upcall) __P((struct socket *, void *, int));
void*so_upcallarg;
- uid_t so_uid; /* who opened the socket */
+ struct pcred *so_cred; /* user credentials */
/* NB: generation count must not be first; easiest to make it last. */
so_gen_t so_gencnt; /* generation count */
void*so_emuldata; /* private data for emulators */
--- src/sys/kern/uipc_socket.c.orig Sat May 29 17:26:59 1999
+++ src/sys/kern/uipc_socket.c Sun May 30 10:52:32 1999
@@ -36,13 +36,14 @@
#include
#include
-#include
#include
#include
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -124,8 +125,10 @@
TAILQ_INIT(&so->so_incomp);
TAILQ_INIT(&so->so_comp);
so->so_type = type;
- if (p != 0)
- so->so_uid = p->p_ucred->cr_uid;
+ if (p) {
+ so->so_cred = p->p_cred;
+ so->so_cred->p_refcnt++;
+ } else so->so_cred = NULL;
so->so_proto = prp;
error = (*prp->pr_usrreqs->pru_attach)(so, proto, p);
if (error) {
@@ -156,6 +159,10 @@
struct socket *so;
{
so->so_gencnt = ++so_gencnt;
+ if (so->so_cred && --so->so_cred->p_refcnt == 0) {
+ crfree(so->so_cred->pc_ucred);
+ FREE(so->so_cred, M_SUBPROC);
+ }
zfreei(so->so_zone, so);
}
--- src/sys/kern/uipc_socket2.c.origSat May 29 17:27:05 1999
+++ src/sys/kern/uipc_socket2.c Sun May 30 10:53:53 1999
@@ -213,7 +213,9 @@
so->so_state = head->so_state | SS_NOFDREF;
so->so_proto = head->so_proto;
so->so_timeo = head->so_timeo;
- so->so_uid = head->so_uid;
+ so->so_cred = head->so_cred;
+ if (so->so_cred)
+ so->so_cred->p_refcnt++;
(void) soreserve(so, head->so_snd.sb_hiwat, head->so_rcv.sb_hiwat);
if ((*so->so_proto->pr_usrreqs->pru_attach)(so, 0, NULL)) {
@@ -915,7 +917,7 @@
xso->so_oobmark = so->so_oobmark;
sbtoxsockbuf(&so->so_snd, &xso->so_snd);
sbtoxsockbuf(&so->so_rcv, &xso->so_rcv);
- xso->so_uid = so->so_uid;
+ xso->so_uid = so->so_cred ? so->so_cred->pc_ucred->cr_uid : -1;
}
/*
--- src/sys/netinet/in_pcb.c.orig Sun May 30 10:54:09 1999
+++ src/sys/netinet/in_pcb.cSun May 30 11:03:19 1999
@@ -202,7 +202,7 @@
return (EACCES);
if (p && p->p_prison)
prison = 1;
- if (so->so_uid &&
+ if (so->so_cred &&
!IN_MULTICAST(ntohl(sin->sin_addr.s_addr))) {
t = in_pcblookup_local(inp->inp_pcbinfo,
sin->sin_addr, lport,
@@ -212,7 +212,9 @@
ntohl(t->inp_laddr.s_addr) != INADDR_ANY ||
(t->inp_socket->so_options &
SO_REUSEPORT) == 0) &&
- (so->so_uid != t->inp_socket->so_uid))
+ (t->inp_socket->so_cred) &&
+ (so->so_cred->p_ruid !=
+ t->inp_socket->so_cred->p_ruid))
return (EADDRINUSE);
}
t = in_pcblookup_local(pcbinfo, sin->sin_addr,
--- src/sys/sys/param.h.origSun May 30 11:31:18 1999
+++ src/sys/sys/param.h Sun May 30 11:31:30 1999
@@ -46,7 +46,7 @@
#define BSD4_3 1
#define BSD4_4 1
#undef __FreeBSD_version
-#define __FreeBSD_version 45 /* Master, propagated to newvers */
+#define __FreeBSD_version 46 /* Master, propagated to newvers */
#ifndef NULL
#defineNULL0
Re: proposed socket change (IPFW too? :)
On Sat, 29 May 1999, Luigi Rizzo wrote: > > It's only truly associative with the socket itself, if you think about it. > > I'd like to see > > what David thinks about this change, since networking is seemingly 'his' > > where IPFW is > > 'yours'. > > nothing is mine, and certainly not IPFW -- i merely added the dummynet > hooks! Your sound drivers (and PnP too, right?) are both yours; and you seem to be the big IPFW maintainer right about now. > > > > On the ipfw side, yes i think the switch to locate & check credential > > > can be simplified by merging the final part (and perhaps even the > > > in_pcblookup() calls). > > > > Yes, I think I'll clean up ipfw :) Parts of it are due for a rewrite, as > > the code has grown > > unwieldly. > > correct. however, with rules being so "complex" (lots of things you can > specify in a rule) the kernel part cannot be simplified a lot. The > userland code, on the other hand, would really deserve some cleanup! It cannot be simplified a lot, but it can definitely be cleaned up, reorganized, and optimized. ipfw.c itself is REALLY gross to try to use, and maybe it's due for a rewrite too. > > cheers > luigi > > ---+- > Luigi RIZZO, lu...@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) > > http://www.iet.unipi.it/~luigi/ngc99/ > First International Workshop on Networked Group Communication > -------+- > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.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: proposed socket change (IPFW too? :)
On Sat, 29 May 1999, Luigi Rizzo wrote: > > I'd like to propose a change in struct socket, which should increase its > > functionality. It should first be noted that, along with my IPFW UID/GID > > code (which would be nice to have merged into HEAD too, and if I must, I'll > > clean up the ugly switch part), I included this change. Implementation time > > would be nil, as would testing. > > no objection on the struct socket change (but i just wonder, if there > are side effects in changing the struct socket, perhaps one might put > the same parameter in the struct tcpcb/udpcb/inpcb ? after all it is > being used by ipfw only). It's only truly associative with the socket itself, if you think about it. I'd like to see what David thinks about this change, since networking is seemingly 'his' where IPFW is 'yours'. > > On the ipfw side, yes i think the switch to locate & check credential > can be simplified by merging the final part (and perhaps even the > in_pcblookup() calls). Yes, I think I'll clean up ipfw :) Parts of it are due for a rewrite, as the code has grown unwieldly. > > cheers > luigi > ---+- > Luigi RIZZO, lu...@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) > > http://www.iet.unipi.it/~luigi/ngc99/ > First International Workshop on Networked Group Communication > ---+--------- > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.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: FS tuning (Was: File system gets too fragmented ???)
On 29 May 1999, Joel Ray Holveck wrote: > > You might try unmounting the filesystem and doing > > tunefs -o space /dev/rawdevice > > (which can also be done at newfs time). You may find that the > > performance, especially write performance, isn't too good. > > I've been looking over FS performance tuning, trying to get my > compiles to go a bit quicker, and started wondering a few things. > > As we all know, tunefs -o space will hurt write performance. Will it > hurt read performance? If I don't care about install-time speed, but > do care about run-time speed and free space, should I populate my > filesystems at install time with space tuning? It /might/ even make it faster to read. Don't shoot me if this isn't the case! > > Is it possible to, on a restore, place down the directory tree with > dummy entries for regular files, so you don't get a split-up directory > when you populate it? I know that mtree'ing the fs ahead of time > helps (and assume that mtree is breadth-first), but I don't recall any > of our utilities that do a breadth-first restore by default. I don't > even see a utility to prepare a file list for tar in a breadth-first > manner; thoughts? > > About a year ago, I heard discussions about the usefulness of tunefs. > Our OS has undergone lots and lots o' changes since then (unified > VM/buffer cache, CAM, etc). newfs documents that rotdelay is useless, > but what about maxcontig? > > About five minutes ago, I realized that one problem is that I recently > installed a new disk, and forgot to enable softupdates on it (doh!). > From the little I know, I don't quite understand why softupdates is a > tunefs parameter, instead of a mount flag. Can a fs with softupdates > turned on in the superblock work on a non-softupdates kernel without > trouble? If so, would it be a good idea to have newfs turn it on by > default? I don't think it should be turned on by default, since legacy fsck code cannot handle SoftUpdates inconsistencies anywhere nearly as well as Kirk's rewrite does it all. It's a mount flag (as I understand it) so that utilities can find out if the FS was running SoftUpdates in the case of a crash. The flag is harmless to an old kernel, which would just ignore it. > > Does bad144 have any space or time overhead? Can it be disabled? I'm pretty sure bad144 doesn't even apply to current disks. > > How do people like to set up their filesystems these days? I've heard > of people who like one big fs (not generally usable anymore because of > the 1024 cyl limit), others who like the small root fs and one big fs > for everything else, and some who like separate fs's for different > things. All other things (disk speed, etc) being equal, what's this > groups' opinion? My opinion (for a simple user box) is to separate into smaller, maintainable / /tmp /var, and large /usr and /home (etc etc). > > Huzzah! to Dyson et al for making our VM system self-tuning. Any > thoughts about hints to give it? > > Thanks, > joelh > > -- > Joel Ray Holveck - jo...@gnu.org >Fourth law of programming: >Anything that can go wrong wi > sendmail: segmentation violation - core dumped > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.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
proposed socket change (IPFW too? :)
I'd like to propose a change in struct socket, which should increase its
functionality. It should first be noted that, along with my IPFW UID/GID
code (which would be nice to have merged into HEAD too, and if I must, I'll
clean up the ugly switch part), I included this change. Implementation time
would be nil, as would testing.
The change itself would be to store a pointer to struct pcred in each
struct socket. The changes are already done, but I'd like to get rid of the
so_uid too (if possible). Following the cred changes, I'd like to make
a sysctl to find out a socket's credentials. After that, a decent identd to
be shipped with FreeBSD (under the FreeBSD license, of course).
How does all of this sound? I'm including the latest IPFW UID/GID patches,
which have the so_cred functionality.
Brian Feldman_ __ ___ ___ ___ ___
gr...@unixhelp.org_ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \ _ \ |) |
http://www.freebsd.org _ |___)___/___/
--- src/sbin/ipfw/ipfw.c.orig Thu Jan 21 20:46:32 1999
+++ src/sbin/ipfw/ipfw.cWed Apr 21 07:41:03 1999
@@ -30,8 +30,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -333,6 +335,24 @@
}
}
+ if (chain->fw_flg & IP_FW_F_UID) {
+ struct passwd *pwd = getpwuid(chain->fw_uid);
+
+ if (pwd)
+ printf(" uid %s", pwd->pw_name);
+ else
+ printf(" uid %u", chain->fw_uid);
+ }
+
+ if (chain->fw_flg & IP_FW_F_GID) {
+ struct group *grp = getgrgid(chain->fw_gid);
+
+ if (grp)
+ printf(" gid %s", grp->gr_name);
+ else
+ printf(" gid %u", chain->fw_gid);
+ }
+
/* Direction */
if ((chain->fw_flg & IP_FW_F_IN) && !(chain->fw_flg & IP_FW_F_OUT))
printf(" in");
@@ -586,6 +606,8 @@
"src: from [not] {any|ip[{/bits|:mask}]} [{port|port-port},[port],...]\n"
"dst: to [not] {any|ip[{/bits|:mask}]} [{port|port-port},[port],...]\n"
" extras:\n"
+"uid {user id}\n"
+"gid {group id}\n"
"fragment (may not be used with ports or tcpflags)\n"
"in\n"
"out\n"
@@ -1185,6 +1207,32 @@
}
while (ac) {
+ if (!strncmp(*av,"uid",strlen(*av))) {
+ struct passwd *pwd;
+
+ rule.fw_flg |= IP_FW_F_UID;
+ ac--; av++;
+ if (!ac)
+ show_usage("``uid'' requires argument");
+
+ rule.fw_uid = (pwd = getpwnam(*av)) ? pwd->pw_uid
+ : strtoul(*av, NULL, 0);
+ ac--; av++;
+ continue;
+ }
+ if (!strncmp(*av,"gid",strlen(*av))) {
+ struct group *grp;
+
+ rule.fw_flg |= IP_FW_F_GID;
+ ac--; av++;
+ if (!ac)
+ show_usage("``gid'' requires argument");
+
+ rule.fw_gid = (grp = getgrnam(*av)) ? (gid_t)grp->gr_gid
+ : strtoul(*av, NULL, 0);
+ ac--; av++;
+ continue;
+ }
if (!strncmp(*av,"in",strlen(*av))) {
rule.fw_flg |= IP_FW_F_IN;
av++; ac--; continue;
--- src/sys/sys/socketvar.h.origTue Apr 20 23:27:58 1999
+++ src/sys/sys/socketvar.h Tue Apr 20 23:27:15 1999
@@ -109,6 +109,7 @@
/* NB: generation count must not be first; easiest to make it last. */
so_gen_t so_gencnt; /* generation count */
void*so_emuldata; /* private data for emulators */
+ struct pcred *so_cred; /* user credentials */
};
/*
--- uipc_socket.c.orig Fri May 28 17:19:58 1999
+++ uipc_socket.c Sat May 29 01:12:43 1999
@@ -36,13 +36,14 @@
#include
#include
-#include
#include
#include
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -124,8 +125,11 @@
TAILQ_INIT(&so->so_incomp);
TAILQ_INIT(&so->so_comp);
so->so_type = type;
- if (p != 0)
- so->so_uid = p->p_ucred->cr_uid;
+ if (p) {
+ so->so_cred = p->p_cred;
+ so->so_cred->p_refcnt++;
+
K6-2 MTRR support done (^_^)
Well, it took me one more day to get it working (I had a bogus bit-shift in
there), and I did some cleaning (also made probing work). The K6-2 MTRR code
works fine.
It should be ready to be committed now, so I'll attach
it to this message. (it is a required by files.i386, BTW)
I'd like a way to test that this works for certain, but I don't have one :/
Brian Feldman_ __ ___ ___ ___ ___
gr...@unixhelp.org_ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \ _ \ |) |
http://www.freebsd.org _ |___)___/___/
/*-
* Copyright (c) 1999 Brian Fundakowski Feldman
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $Id$
*
*/
#include
#include
#include
#include
#include
#include
#include
#include
/*
* A K6-2 MTRR is defined as the highest 15 bits having the address, the next
* 15 having the mask, the 1st bit being "write-combining" and the 0th bit
* being "uncacheable".
*
* Address MaskWC UC
* | XXX | XXX | X | X |
*
* There are two of these in the 64-bit UWCCR.
*/
/*
* NOTE: I do _not_ comment my code unless it's truly necessary. Don't
* expect anything frivolous here, and do NOT touch my bit-shifts
* unless you want to break this.
*/
#define UWCCR 0xc085
#define k6_reg_get(reg, addr, mask, wc, uc) do {\
addr = (reg) & 0xfffe; \
mask = ((reg) & 0x1fffc) >> 2; \
wc = ((reg) & 0x2) >> 1;\
uc = (reg) & 0x1; \
} while (0)
#define k6_reg_make(addr, mask, wc, uc) \
((addr) | ((mask) << 2) | ((wc) << 1) | uc)
static void k6_mrinit(struct mem_range_softc *sc);
static int k6_mrset(struct mem_range_softc *, struct mem_range_desc *, int *);
static __inline int k6_mrmake(struct mem_range_desc *, u_int32_t *);
static void k6_mem_drvinit(void *);
static struct mem_range_ops k6_mrops = {
k6_mrinit,
k6_mrset,
NULL
};
static __inline int
k6_mrmake(struct mem_range_desc *desc, u_int32_t *mtrr) {
u_int32_t len = 0, wc, uc;
register int bit;
if (desc->mr_base &~ 0xfffe)
return EINVAL;
if (desc->mr_len < 131072 || !powerof2(desc->mr_len))
return EINVAL;
if (desc->mr_flags &~ 0x3)
return EOPNOTSUPP;
for (bit = ffs(desc->mr_len >> 17) - 1; bit < 15; bit++)
len |= 1 << (14 - bit);
wc = (desc->mr_flags & MDF_WRITECOMBINE) ? 1 : 0;
uc = (desc->mr_flags & MDF_UNCACHEABLE) ? 1 : 0;
*mtrr = k6_reg_make(desc->mr_base, len, wc, uc);
return 0;
}
static void
k6_mrinit(struct mem_range_softc *sc) {
u_int64_t reg;
u_int32_t addr, mask, wc, uc;
int d;
sc->mr_cap = 0;
sc->mr_ndesc = 2; /* XXX (BFF) For now, we only have one msr for this */
sc->mr_desc = malloc(sc->mr_ndesc * sizeof(struct mem_range_desc),
M_MEMDESC, M_WAITOK);
bzero(sc->mr_desc, sc->mr_ndesc * sizeof(struct mem_range_desc));
reg = rdmsr(UWCCR);
for (d = 0; d < sc->mr_ndesc; d++) {
u_int32_t one = (reg & (0x << (32 * d))) >> (32 * d);
k6_reg_get(one, addr, mask, wc, uc);
sc->
K6-2 MTRR support testing
I suppose that this is nearly done. It works, it seems, but I have no idea what
I can do to truly test it. I need to implement probing/matching so that it only
works on the CPUs that support it, I suppose. I'd like people to check it out
for now. I make no guarantees, but it seems to work here.
Brian Feldman_ __ ___ ___ ___ ___
gr...@unixhelp.org_ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \ _ \ |) |
http://www.freebsd.org _ |___)___/___/
/*-
* Copyright (c) 1999 Brian Fundakowski Feldman
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $Id$
*
*/
#include
#include
#include
#include
#include
#include
#include
#include
/*
* A K6 MTRR is defined as the highest 15 bits having the address, the next
* 15 having the mask, the 1st bit being "write-combining" and the 0th bit
* being "uncacheable".
*
* Address MaskWC UC
* | XXX | XXX | X | X |
*
* There are two of these in the 64-bit UWCCR.
*/
#define UWCCR 0xc085
#define k6_reg_get(reg, addr, mask, wc, uc) \
addr = ((reg) & 0xfffe) >> 17; \
mask = ((reg) & 0x1fffc) >> 2; \
wc = ((reg) & 0x2) >> 1;\
uc = (reg) & 0x1;
#define k6_reg_make(addr, mask, wc, uc) \
(((addr) << 17) | ((mask) << 2) | ((wc) << 1) | uc)
static void k6_mrinit(struct mem_range_softc *sc);
static int k6_mrset(struct mem_range_softc *, struct mem_range_desc *, int *);
static __inline int k6_mrmake(struct mem_range_desc *, u_int32_t *);
static void k6_mem_drvinit(void *);
static struct mem_range_ops k6_mrops = {
k6_mrinit,
k6_mrset,
NULL
};
static __inline int
k6_mrmake(struct mem_range_desc *desc, u_int32_t *mtrr) {
u_int base, len = 0, wc, uc;
register int bit;
if (desc->mr_base &~ 0xfffe)
return EINVAL;
if (desc->mr_len < 131072 || !powerof2(desc->mr_len))
return EINVAL;
if (desc->mr_flags &~ 0x3)
return EOPNOTSUPP;
base = desc->mr_base & 0xfffe;
for (bit = ffs(desc->mr_len >> 17) - 1; bit < 15; bit++)
len |= 1 << (14 - bit);
wc = (desc->mr_flags & MDF_WRITECOMBINE) ? 1 : 0;
uc = (desc->mr_flags & MDF_UNCACHEABLE) ? 1 : 0;
*mtrr = k6_reg_make(base, len, wc, uc);
return 0;
}
static void
k6_mrinit(struct mem_range_softc *sc) {
u_int64_t reg;
u_int32_t addr, mask, wc, uc;
int d;
sc->mr_cap = 0;
bzero(sc->mr_desc =
malloc((sc->mr_ndesc = 2) * sizeof(struct mem_range_desc),
M_MEMDESC, M_WAITOK), 2 * sizeof(struct mem_range_desc));
reg = rdmsr(UWCCR);
for (d = 0; d < sc->mr_ndesc; d++) {
u_int32_t one = (reg & (0x << (32 * d))) >> (32 * d);
k6_reg_get(one, addr, mask, wc, uc);
sc->mr_desc[d].mr_base = addr << 17;
sc->mr_desc[d].mr_len = ffs(mask) << 17;
if (wc)
sc->mr_desc[d].mr_flags |= MDF_WRITECOMBINE;
if (uc)
sc->mr_desc[d].mr_flags |= MDF_UNCACHEABLE;
}
printf("K6 MTRR support enabled\n");
}
s
freebsd-hackers@freebsd.org
On Mon, 24 May 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > > Since this is right now a glide specific project perhaps a piecemeal > > approach to implementing this shim is appropriate. The little I've looked > > at the glide libs shows; freebsd's nm can show all the important > > symbol info (externs) and our ldd can show the share object dependencies. > > That's exactly what I'm doing. Unfortunately, ldd spits the dummy. I think > I'll be using code based on objcopy for modification of symbol names and > dependent libraries. > > > > How goes it with a native /dev/3dfx? > > > Not as well as I'd like. It follows the structure of Daryll Strauss'es code > OK, but when glide is initialising, after getting the number of cards, it > tries to pass a structure for some I/O which has some garbage values in it. I > don't know if the structure is packed differently or what. Most frustrating. > If I can beat this shim into shape, then we can have hardware accelerated > OpenGL while I tinker with the device driver. Grrr. Have a Voodoo 1 myself. > Am > also waiting for someone else to do the mtrr code for AMD K6-2s. Why do you REALLY need this so badly? If you make me a good case, I'll stay up REALLY late and do it tonight. Deal? > > > > Stephen > > > > -- > The views expressed above are not those of PGS Tensor. > > "We've heard that a million monkeys at a million keyboards could produce > the Complete Works of Shakespeare; now, thanks to the Internet, we know > this is not true." Robert Wilensky, University of California > > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.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: modex support (again)
On 14 May 1999, Dag-Erling Smorgrav wrote: > Kelly Yancey writes: > > What I don't get is how the memory is presented to apps using the > > driver. The best I could think of would be to present it a 256k linear > > frame buffer with the pixels in order (ie writes to consecutive pixels > > would result in the driver switching planes), and while that would present > > a consistent interface, it would be *really* slow (if it is even > > possible). > > Yes, it's possible, but it requires a page fault on *every* write to > video memory. YA case of 'possible, but not practical'. > > (this technique has been used to simulate a linear frame buffer when > using paged modes, but I haven't yet succeeded in convincing Kazu to > implement it in the VESA driver and I don't have the time or know-how > to do it myself) > > >The next best thing would be to present it a 256k linear frame > > buffer but with each plane 64k after the previous. Applications would > > have to be aware of the layout (ie. know that modex modes aren't linear) > > because writes to consecutive memory addresses would result in changing > > every 4th pixel. This is the method I would assume must already be in > > place for the existing 320x240 mode, but I can't find it. Which means that > > at the moment 320x240 is useless? > > Yes, if it's there at all you have to switch banks "manually". > > > Really, I was thinking that this would be a "neat" thing to add. I could > > have some higher resolution video modes without needing VESA (and VM86). > > The VESA code is very small, and you want VM86 anyway (amongst other > things, for reliable memory detection) > > > But you make a good point in that anyone who wants graphics uses X. I > > guess I was thinking that maybe the additional modes would be of use > > should FreeBSD ever really get an equivalent to libsvga. > > We already have that (libvgl), though it's in deperate need of > maintenance. > > > Anyway, as you point out, then the modes are really only of use to > > splash screens (which is a minor feature in and of itself). So the > > question becomes, is there any interest in adding 6 mode "tweaked" modes > > (in addition to the existing 320x240) or should we reduce complexity and > > remove the 320x240 mode because surely nothing can be using it (you can > > only write to every 4th pixel right now). > > I vote for the latter. > > > > OBTW, Mode Q has square pixels and linear addressing. I won't mind > > > adding support for Mode Q :) > > Mode Q? I'm not familiar with that one. Presumably a less-than-320x200 > > resolution? > > No, actually it has 1536 more pixels :) Mode Q is so named because the > frame buffer is a cube of sorts (i.e. 256x256 pixels in 256 colors) > > If you have time and talent to spare and want to work on the console > code, I have two suggestions for useful additions: > > - modify syscons so userland software can mmap the frame buffer, and >whatever other modifications are necessary to make it possible for >userland software to use graphics without needing write access to >/dev/kmem (currently, the only way to mmap the frame buffer is to >map in the correct address range from /dev/kmem) > Kazu finishing his fb(4) would be quite nice, if he has the time. > - port GGI to FreeBSD. Huh? It works for me... GGI is just the API/wrapper, and it allows output to (most useful now) X and XF86DGA (many, many more of course,, and a FreeBSD fb(4) would be cool.). > > DES > -- > Dag-Erling Smorgrav - d...@flood.ping.uio.no > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.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
