From owner-freebsd-hackers Sun Feb 25 0:29:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id BDE8837B491 for ; Sun, 25 Feb 2001 00:29:46 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1P8Thd03268; Sun, 25 Feb 2001 01:29:43 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102250829.f1P8Thd03268@harmony.village.org> To: seebs@plethora.net (Peter Seebach) Subject: Re: Setting memory allocators for library functions. Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Sun, 25 Feb 2001 01:57:27 CST." <200102250757.f1P7vR625246@guild.plethora.net> References: <200102250757.f1P7vR625246@guild.plethora.net> Date: Sun, 25 Feb 2001 01:29:43 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102250757.f1P7vR625246@guild.plethora.net> Peter Seebach writes: : >I searched through the standard extensively to see if "allocates : >space" is defined and couldn't find anything other than 'the poitner : >can be used to access the space allocated.' : : EXACTLY! : : If it can't actually be used, then something has gone horribly wrong. It says can, not must. I disagree with you that you can't overcommit. Also, access is ill defined. Does that mean read access? write access? How about execute access? It just says access and leaves the meaning up to the implementor. You fail to draw a distinction between "reading" the allocated area, and "writing" to the allocated area. The standard makes no promises that you can do both, and only has the vaguely defined access as to what you can do with it. Reasonable people can differ as to what this means. : >There appear to be no : >guarantees that you can always use all of the memory that you've : >allocated, the performance characterstics of accessing said memory or : >anything else. : : Performance characteristics are not at issue; I don't think anyone on the : committee would complain about an implementation which provided "committed" : space by backing it all to disk, all the time. No one would. However, the standard does not preclude the ability to overcommit. Many different systems do this already. : >Do not read too much into the above words. They mean exactly what : >they say. FreeBSD is in compliance. : : Assuming I make the Copenhagen meeting, I'll bring this up again as a DR : or something. This gets debated every few years, and the consensus seems : to be that malloc *MUST* return a valid pointer to space which can actually : be used. Really, I guess I missed those debates. I've not seen it in the literature. I've not seen this addressed in the last 20 years that systems have been overcomitting in any meaningful way. : >The space is indeed allocated to : >the process address space. System resource issues might get in the : >way of being able to use that, but that's true of anything you : >allocate. : : That's not what "allocate" means. A resource which is *allocated* is one : you actually have access to. Not necessarily. Allocate means, in the absense of resource shortages, you get the memory. You might get the memory, you might not. Consider a system that has a quota on dirty pages. If I malloc a huge array, and then only use part of it, I can stay under my quota. But if I use most of it by dirtying it, then the system can kill the process. : Basically, if your interpretation had been intended, the committee would have : put in words to the effect of "access to an allocated object invokes undefined : behavior". : : It doesn't. Yes it does. You do not understand. If there's an ECC error, then you do not have access to the memory without errors. This is no different, just a different class of error. : Therefore, the following code: : #include : int main(void) { : unsigned char *p; : if (200000000 < SIZE_MAX) { : p = malloc(200000000) : if (p) { : size_t i; : for (i = 0; i < 200000000; ++i) { : p[i] = i % 5; : } : } : } : return 0; : } : *MUST* succeed and return 0. The program does not invoke undefined behavior; : therefore, the compiler is obliged to ensure that it succeeds. It's fine for : malloc to fail; it's not fine for the loop to segfault. That's not necessarily true. There's nothing in the standard that states that you have to be able to write to all parts of an allocated region. It is a perfectly reasonable implementation to return the memory from malloc. The system might enforce an upper bound on the number of dirty pages a process has. malloc would not necessarily have any way of knowing what those limits are, and those limits and quotas might be dynamic or shared amoung classes of users. The limit might be 100 right now, but 10 later. This is a host environment issue. The malloc call gets a resource, but in the future you might not be able to access that resource due to circumstances beyond the control of the program. Also, the program does not *HAVE* to succeed. If you have a low CPU quota, for example, and the program exceeds it, the host environment will signal SIGXCPU to the process. Another process might send this one a SIGKILL. The system may crash in the middle of its execution. There might be an unrecoverable memory parity error. There might be an unrecoverable disk error on the swap partition. There might be any number of things that preclude it from reaching completion, beyond your control. I don't see how this is significantly different than a dirty page quota or a dirty page limit. That's what we're talking about here. There's nothing in the standard that precludes host limits that do not fit into the standard well. : This is probably one of the single most-unimplemented features in the spec, : but it really wouldn't be that hard to provide as an option. It would be extremely difficult to provide as an option. The over commit stuff is down in the kernel's vm system. There's no real way to have a single process get "guaranteed" access to anything. It is way ugly to change. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 0:40:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id B0EF837B401 for ; Sun, 25 Feb 2001 00:40:16 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1P8eG625861 for ; Sun, 25 Feb 2001 02:40:16 -0600 (CST) Message-Id: <200102250840.f1P8eG625861@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Sun, 25 Feb 2001 01:29:43 MST." <200102250829.f1P8Thd03268@harmony.village.org> Date: Sun, 25 Feb 2001 02:40:16 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102250829.f1P8Thd03268@harmony.village.org>, Warner Losh writes: >It says can, not must. But if it "can be used", and no one says "undefined behavior", then we're done; no undefined behavior is allowed. >I disagree with you that you can't overcommit. >Also, access is ill defined. It's defined better in C99 than it was in C89. >Does that mean read access? write >access? How about execute access? Within "defined behavior", read and write; all jumps to data are undefined behavior. >The standard makes no promises >that you can do both, and only has the vaguely defined access as to >what you can do with it. Once again, if it had been intended to allow only limited access, it would say so. >Reasonable people can differ as to what this means. Yes. >: Performance characteristics are not at issue; I don't think anyone on the >: committee would complain about an implementation which provided "committed" >: space by backing it all to disk, all the time. >No one would. However, the standard does not preclude the ability to >overcommit. It is certainly read that way by a number of people, and I think we're currently a majority on the committee. No one cares; it's not as though an implementation is required to be in the maximally conforming mode at all times. >Many different systems do this already. Yes, they do. That doesn't mean it's correct. I don't believe there's a single completely correct implementation of the fully ammended C89 standard, let alone C99. >Really, I guess I missed those debates. I've not seen it in the >literature. I've not seen this addressed in the last 20 years that >systems have been overcomitting in any meaningful way. It's an old flamewar on comp.std.c. :) >: That's not what "allocate" means. A resource which is *allocated* is one >: you actually have access to. >Not necessarily. Allocate means, in the absense of resource >shortages, you get the memory. No. To allocate is to get. Allocation *fails* in the case of a resource shortage. >You might get the memory, you might >not. Consider a system that has a quota on dirty pages. If I malloc >a huge array, and then only use part of it, I can stay under my >quota. But if I use most of it by dirtying it, then the system can >kill the process. Sure. Now imagine a quota on file I/O. If I start writing to a file, I'm under my quota, but if I exceed it, then the system can kill the process. If the standard had meant to say "access to allocated space invokes undefined behavior", it would have done so. Would you argue that the system which simply *kills* a process that tries to write to a full disk is correct? If not, can you show how that's any different? >Yes it does. You do not understand. If there's an ECC error, then >you do not have access to the memory without errors. This is no >different, just a different class of error. Hardware errors do, indeed, produce a non-conforming implementation. However, on a system where the hardware works, overcommit-and-kill is *STILL* a conformance problem; killing on ECC errors isn't a conformance problem unless there are some. >That's not necessarily true. There's nothing in the standard that >states that you have to be able to write to all parts of an allocated >region. Sure, and there's nothing in the standard that explicitly says "a call to frwrite with valid arguments should not raise SIGKILL", but everyone knows that would be a mistake. >It is a perfectly reasonable implementation to return the >memory from malloc. It's very reasonable, but it does not provide the environment described in the standard, which is an environment in which the memory returned by malloc is all available for use. >might be 100 right now, but 10 later. This is a host environment >issue. The malloc call gets a resource, but in the future you might >not be able to access that resource due to circumstances beyond the >control of the program. The same argument applies to killing programs when they write to a full disk. >Also, the program does not *HAVE* to succeed. If you have a low CPU >quota, for example, and the program exceeds it, the host environment >will signal SIGXCPU to the process. Another process might send this >one a SIGKILL. The system may crash in the middle of its execution. >There might be an unrecoverable memory parity error. There might be >an unrecoverable disk error on the swap partition. There might be any >number of things that preclude it from reaching completion, beyond >your control. Yes, and *EVERY ONE OF THOSE* is a conformance failure. I'm not saying we can produce an environment which is guaranteed to conform in all cases; it's obviously impossible. We *could* avoid breaking things. >I don't see how this is significantly different than a dirty page >quota or a dirty page limit. Very simple: We don't have control over hardware, and the Unix environment says you're allowed to do all sorts of things which, from the point of view of the spec, magically render the execution environment non-conforming. But that doesn't mean we need to *add* one. >That's what we're talking about here. >There's nothing in the standard that precludes host limits that do not >fit into the standard well. There's nothing that *allows* for them, though. Once again, by the same reasoning, we could defer fopen() until we actually start writing to the file, and *THEN* kill the process if fopen()'s path was invalid. It's just as good an idea, and it's just as correct. >It would be extremely difficult to provide as an option. The >over commit stuff is down in the kernel's vm system. There's no real >way to have a single process get "guaranteed" access to anything. It >is way ugly to change. Okay, so it's hard. I still say that guaranteed memory is a legitimate request for a process to make, which the OS should be able to satisfy in at least some cases. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 3:10:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id CC98B37B503 for ; Sun, 25 Feb 2001 03:10:45 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id MAA59550; Sun, 25 Feb 2001 12:10:42 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Kenneth Wayne Culver Cc: simond@irrelevant.org, Justin McKnight , FreeBSD-newbies Subject: Re: Compaq e500, 3com cardbus card help References: From: Dag-Erling Smorgrav Date: 25 Feb 2001 12:10:41 +0100 In-Reply-To: Kenneth Wayne Culver's message of "Sun, 25 Feb 2001 01:30:45 -0500 (EST)" Message-ID: Lines: 20 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kenneth Wayne Culver writes: > On 24 Feb 2001, Dag-Erling Smorgrav wrote: > > Kenneth Wayne Culver writes: > > > FreeBSD supports cardbus in -CURRENT, but I wouldn't expect it to ever > > > support cardbus in 4.x. If you are daring you can get -CURRENT, but from > > > what I hear right now, it's not working very well. > > It works just fine, thank you very much, but it takes some > > hand-holding. > Must not be cardbus then. I beg your pardon? Were you trying to say that -CURRENT does not work very well, or that Cardbus does not work very well? I assumed the former, which is partly true (-CURRENT works fine if you keep close enough track of things to know when it's safe to upgrade and how to fix or work around whatever bugs you hit). If you meant the latter, I beg to differ - Cardbus itself works fine and dandy for me. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 3:19:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.10]) by hub.freebsd.org (Postfix) with ESMTP id 0C23D37B491; Sun, 25 Feb 2001 03:19:41 -0800 (PST) (envelope-from danny@cs.huji.ac.il) Received: from sexta.cs.huji.ac.il ([132.65.16.13] ident=danny) by cs.huji.ac.il with esmtp (Exim 3.20 #1) id 14WzD5-0002Pb-00; Sun, 25 Feb 2001 13:19:27 +0200 X-Mailer: exmh version 2.2 06/23/2000 with nmh-0.24 To: freebsd-hackers@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: diskless-boot/PXE/dhcp Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 25 Feb 2001 13:19:27 +0200 From: Danny Braniss Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi all, I've made some changes to libstand/bootp.c and they are available for evaluation/comments/critics at: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/diskless-boot short desc.: o the bootp request now does a vendor-specific-request FreeBSDc instead of PXEClient. o dhcp options are placed in the env. as dhcp.option-name o FBSD options are placed in the env as is. long description: see README :-) danny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 3:39:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 4BDB737B401 for ; Sun, 25 Feb 2001 03:39:29 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p36-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.37]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id UAA08841; Sun, 25 Feb 2001 20:39:13 +0900 (JST) Message-ID: <3A98EE37.7B0B6CE0@newsguy.com> Date: Sun, 25 Feb 2001 20:36:23 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: Peter Seebach , freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102241643.f1OGhw616627@guild.plethora.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > > seebs@plethora.net (Peter Seebach) writes: > > Is there any hope that, some day, a setting could be provided where a program > > could request that malloc *NOT* overcommit? There are programs which would > > rather know in advance, and clean up, than be killed abruptly. > > Malloc() does not overcommit - the kernel does. Malloc() doesn't know > and doesn't care. > > I imagine you could add a compile-time option that forces obreak() > (why do we still use brk()/sbrk()?) to prefault the newly allocated > address space. Or you could write a malloc() implementation that only > uses mmap(), and add a flag value that makes mmap() prefault pages, > and fail if there isn't enough memory available. > > None of these solutions are portable, however; the portable way around > memory overcommit is to write a malloc() wrapper that installs a > SIGSEGV handler, then tries to dirty the newly allocated memory, and > fails gracefully if this causes a segfault. Untested code: None of these solutions will work. In all of the above cases, it is still possible for an application to be killed due to out of memory conditions caused by other applications. The main point of non-overcommitting applications is to avoid that. Personally, I like AIX solution of a SIGDANGER signal, and having applications that do not have a handler installed be killed first. But that isn't what is being asked for. OTOH, the *only* way to get non-overcommit to FreeBSD is for someone who *wants* that feature to sit down and code it. It won't happen otherwise. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@kzinti.bsdconspiracy.net Acabou o hipismo-arte. Mas a desculpa brasileira mais ouvida em Sydney e' que nao tem mais cavalo bobo por ai'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 4: 5:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 03B3637B491 for ; Sun, 25 Feb 2001 04:05:04 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p36-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.37]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id VAA15192; Sun, 25 Feb 2001 21:04:56 +0900 (JST) Message-ID: <3A98F43E.FFC99867@newsguy.com> Date: Sun, 25 Feb 2001 21:02:06 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: Peter Seebach , freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102242037.f1OKbd618343@guild.plethora.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > > > > None of these solutions are portable, however; > > Well, no, but the sole available definition of "portable" says that it is > > "portable" to assume that all the memory malloc can return is really > > available. > > Show me a modern OS (excluding real-time and/or embedded OSes) that > makes this guarantee. Solaris and AIX (on AIX this is optional on a global or per-application level). -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@kzinti.bsdconspiracy.net Acabou o hipismo-arte. Mas a desculpa brasileira mais ouvida em Sydney e' que nao tem mais cavalo bobo por ai'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 4:17:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id AA98D37B401 for ; Sun, 25 Feb 2001 04:17:08 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p36-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.37]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id VAA18444; Sun, 25 Feb 2001 21:17:01 +0900 (JST) Message-ID: <3A98F713.393532F7@newsguy.com> Date: Sun, 25 Feb 2001 21:14:11 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Julian Elischer Cc: Peter Seebach , freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102241643.f1OGhw616627@guild.plethora.net> <3A988312.2E238F48@elischer.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > to not be caught by surprise, > simply touch every page after you allocate it. It doesn't work. The application killed by reason of insufficient resources is not (necessarily) the one that causes the page fault leading to that. Id est, if my application allocates all available memory, touching every page, and then some other application touches a pre-allocated page not backed by memory or swap, it is quite likely mine which will get killed. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@kzinti.bsdconspiracy.net Acabou o hipismo-arte. Mas a desculpa brasileira mais ouvida em Sydney e' que nao tem mais cavalo bobo por ai'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 5:16:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 9088537B491; Sun, 25 Feb 2001 05:16:25 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f1PDGaM13718; Sun, 25 Feb 2001 14:16:37 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Dima Dorfman Cc: Robert Watson , freebsd-hackers@FreeBSD.ORG Subject: Re: Listing configured md(4) devices In-Reply-To: Your message of "Sat, 24 Feb 2001 16:42:58 PST." <20010225004258.0F01E3E09@bazooka.unixfreak.org> Date: Sun, 25 Feb 2001 14:16:36 +0100 Message-ID: <13716.983106996@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think my commit to md yesterday torpedoed your patch, because one part of it rej'ected. I applied the .rej by hand and found a few nits here and there. I change the list function extensively, because the "512" size of the array were not picked from where it should come, , because it is under #ifdef _KERNEL there, so instead I did a list based sorting instead. Thanks! In message <20010225004258.0F01E3E09@bazooka.unixfreak.org>, Dima Dorfman write s: >> The "md" problem should really be solved by adding >> #define MD_NAME "md" >> to and using this in both the driver and the mdconfig >> program. >> >> Can I get you to incorporate that in your patch ? > >Certainly! The updated patch is at >http://www.unixfreak.org/~dima/home/md-list4.diff (it's getting a >little big, so I thought I'd not attach it here). The changes include, > > - "md" (and variants thereof) -> MD_NAME, > - "mdctl" (and variants thereof) -> MDCTL_NAME (for consistency), and > - update the mdconfig(8) manual page to mention the -l option. > >Thanks > > Dima Dorfman > dima@unixfreak.org > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 7:38:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 3120D37B491 for ; Sun, 25 Feb 2001 07:38:13 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id QAA60479; Sun, 25 Feb 2001 16:37:57 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Daniel C. Sobral" Cc: Julian Elischer , Peter Seebach , freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102241643.f1OGhw616627@guild.plethora.net> <3A988312.2E238F48@elischer.org> <3A98F713.393532F7@newsguy.com> From: Dag-Erling Smorgrav Date: 25 Feb 2001 16:37:56 +0100 In-Reply-To: "Daniel C. Sobral"'s message of "Sun, 25 Feb 2001 21:14:11 +0900" Message-ID: Lines: 10 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" writes: > It doesn't work. The application killed by reason of insufficient > resources is not (necessarily) the one that causes the page fault > leading to that. This is arguably a bug which needs to be fixed. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 7:58:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.30.2]) by hub.freebsd.org (Postfix) with ESMTP id B360B37B4EC for ; Sun, 25 Feb 2001 07:58:51 -0800 (PST) (envelope-from kuku@gilberto.physik.rwth-aachen.de) Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.9.3/8.9.3) id QAA57232 for hackers@freebsd.org; Sun, 25 Feb 2001 16:58:50 +0100 (CET) (envelope-from kuku) Date: Sun, 25 Feb 2001 16:58:50 +0100 (CET) From: Christoph Kukulies Message-Id: <200102251558.QAA57232@gilberto.physik.rwth-aachen.de> To: hackers@freebsd.org Subject: NFS behaviour Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG NFS experts out there, I have a question about synchronisation: Imagine two hosts A (NFS server), host B (NFS client). Process on A modifies a file. When does process on B get notification about the change? Does it depend on the time set on the different hosts? Is it a caching issue or what? With two Linux systems we are seeing all sorts of strange effects with such a setup. Just curious if FreeBSD behaves better here. Well, I could try it out, but if it is a general problem anyway with NFS I'd prefer to discuss it theoretically :-) -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 7:59: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id C9BF837B4EC for ; Sun, 25 Feb 2001 07:59:02 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1PFx2627103 for ; Sun, 25 Feb 2001 09:59:02 -0600 (CST) Message-Id: <200102251559.f1PFx2627103@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Sun, 25 Feb 2001 20:36:23 +0900." <3A98EE37.7B0B6CE0@newsguy.com> Date: Sun, 25 Feb 2001 09:59:02 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3A98EE37.7B0B6CE0@newsguy.com>, "Daniel C. Sobral" writes: >OTOH, the *only* way to get non-overcommit to FreeBSD is for someone who >*wants* that feature to sit down and code it. It won't happen otherwise. So, out of idle curiousity: If, somewhere down the road, I know the kernel well enough to attempt such a thing, what would the interest level be in merging such a feature? -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 8:43:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from po4.wam.umd.edu (po4.wam.umd.edu [128.8.10.166]) by hub.freebsd.org (Postfix) with ESMTP id 88E4437B4EC for ; Sun, 25 Feb 2001 08:43:43 -0800 (PST) (envelope-from culverk@wam.umd.edu) Received: from rac2.wam.umd.edu (IDENT:root@rac2.wam.umd.edu [128.8.10.142]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id LAA04460; Sun, 25 Feb 2001 11:43:38 -0500 (EST) Received: from rac2.wam.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by rac2.wam.umd.edu (8.9.3/8.9.3) with SMTP id LAA03022; Sun, 25 Feb 2001 11:43:38 -0500 (EST) Received: from localhost (culverk@localhost) by rac2.wam.umd.edu (8.9.3/8.9.3) with ESMTP id LAA03018; Sun, 25 Feb 2001 11:43:38 -0500 (EST) X-Authentication-Warning: rac2.wam.umd.edu: culverk owned process doing -bs Date: Sun, 25 Feb 2001 11:43:38 -0500 (EST) From: Kenneth Wayne Culver To: Dag-Erling Smorgrav Cc: simond@irrelevant.org, Justin McKnight , FreeBSD-newbies Subject: Re: Compaq e500, 3com cardbus card help In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What I was saying is that cardbus only works on current. ================================================================= | Kenneth Culver | FreeBSD: The best NT upgrade | | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| ================================================================= On 25 Feb 2001, Dag-Erling Smorgrav wrote: > Kenneth Wayne Culver writes: > > On 24 Feb 2001, Dag-Erling Smorgrav wrote: > > > Kenneth Wayne Culver writes: > > > > FreeBSD supports cardbus in -CURRENT, but I wouldn't expect it to ever > > > > support cardbus in 4.x. If you are daring you can get -CURRENT, but from > > > > what I hear right now, it's not working very well. > > > It works just fine, thank you very much, but it takes some > > > hand-holding. > > Must not be cardbus then. > > I beg your pardon? Were you trying to say that -CURRENT does not work > very well, or that Cardbus does not work very well? I assumed the > former, which is partly true (-CURRENT works fine if you keep close > enough track of things to know when it's safe to upgrade and how to > fix or work around whatever bugs you hit). If you meant the latter, I > beg to differ - Cardbus itself works fine and dandy for me. > > DES > -- > Dag-Erling Smorgrav - des@ofug.org > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 9:17:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from kuku.excite.com (kuku-rwcmta.excite.com [198.3.99.63]) by hub.freebsd.org (Postfix) with ESMTP id BC44D37B401 for ; Sun, 25 Feb 2001 09:17:39 -0800 (PST) (envelope-from john_wilson100@excite.com) Received: from bernie.excite.com ([199.172.148.157]) by kuku.excite.com (InterMail vM.4.01.02.39 201-229-119-122) with ESMTP id <20010225171739.WZKX460.kuku.excite.com@bernie.excite.com>; Sun, 25 Feb 2001 09:17:39 -0800 Message-ID: <18242322.983121459104.JavaMail.imail@bernie.excite.com> Date: Sun, 25 Feb 2001 09:17:38 -0800 (PST) From: John Wilson To: Anton Berezin Subject: Re: Converting Perforce to CVS Cc: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Excite Inbox X-Sender-Ip: 192.116.157.232 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear Anton, If you still have the Perforce->CVS conversion script, I would be very grateful if you could e-mail it to me. Thanks in advance John Wilson On Tue, 9 Jan 2001 09:13:39 +0100, Anton Berezin wrote: > On Sat, Jan 06, 2001 at 03:06:20PM -0800, John Wilson wrote: > > I apologize in advance, as this is not strictly a FreeBSD-related question, > > but I know that a lot of FreeBSD'ers use CVS as well as Perforce, so here > > goes... > > > > What is the easiest way to convert a P4 source repository to CVS, while > > preserving revisions, history, log messages, etc? Both systems seem to use > > RCS, but is it as simple as copying the files? Are there any caveats? > > I have one script, but it does not handle branches (the project I was > converting did not have any). I can mail it to you if you want. The > branch handling should be rather similar to binary files handling, which > the script already performs. > > Cheers, > ^Anton. > -- > May the tuna salad be with you. _______________________________________________________ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 10:44:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sabre.velocet.net (sabre.velocet.net [198.96.118.66]) by hub.freebsd.org (Postfix) with ESMTP id B1F1D37B401 for ; Sun, 25 Feb 2001 10:44:27 -0800 (PST) (envelope-from dgilbert@office.tor.velocet.net) Received: from office.tor.velocet.net (trooper.velocet.net [204.138.45.2]) by sabre.velocet.net (Postfix) with ESMTP id 5D6E5137F12; Sun, 25 Feb 2001 13:44:26 -0500 (EST) Received: (from dgilbert@localhost) by office.tor.velocet.net (8.11.2/8.9.3) id f1PIiPR65915; Sun, 25 Feb 2001 13:44:25 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15001.21129.307283.198917@trooper.velocet.net> Date: Sun, 25 Feb 2001 13:44:25 -0500 (EST) To: Matt Dillon Cc: Bernd Walter , David Gilbert , freebsd-hackers@FreeBSD.ORG Subject: [hackers] Re: Large MFS on NFS-swap? In-Reply-To: <200102250644.f1P6iuL12016@earth.backplane.com> References: <15000.8884.6165.759008@trooper.velocet.net> <20010225042933.A508@cicely5.cicely.de> <200102250644.f1P6iuL12016@earth.backplane.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Matt" == Matt Dillon writes: Matt> Use the vn device to create a swap-backed filesystem. 'man Matt> vnconfig'. (In current VN functionality has been merged into MD Matt> and MD in swap-backed mode should be used instead ). If you Matt> turn softupdates on on the VN based filesystem, it should work Matt> quite nicely for small files and yet still be able to handle the Matt> very large files (assuming you have sufficient swap). Hmmm... I was just having a little fun, and I think that someone's using the wrong type of integer somewhere: [1:23:323]root@news:~> vnconfig -e -s labels -S 1t vn0 [1:24:324]root@news:~> disklabel -r -w vn0 auto [1:25:325]root@news:~> newfs /dev/vn0c preposterous size -2147483648 Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 11:13:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 487AA37B4EC for ; Sun, 25 Feb 2001 11:13:12 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1PJDAc15495; Sun, 25 Feb 2001 11:13:10 -0800 (PST) (envelope-from dillon) Date: Sun, 25 Feb 2001 11:13:10 -0800 (PST) From: Matt Dillon Message-Id: <200102251913.f1PJDAc15495@earth.backplane.com> To: David Gilbert Cc: Bernd Walter , David Gilbert , freebsd-hackers@FreeBSD.ORG Subject: Re: [hackers] Re: Large MFS on NFS-swap? References: <15000.8884.6165.759008@trooper.velocet.net> <20010225042933.A508@cicely5.cicely.de> <200102250644.f1P6iuL12016@earth.backplane.com> <15001.21129.307283.198917@trooper.velocet.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Hmmm... I was just having a little fun, and I think that someone's :using the wrong type of integer somewhere: : :[1:23:323]root@news:~> vnconfig -e -s labels -S 1t vn0 :[1:24:324]root@news:~> disklabel -r -w vn0 auto :[1:25:325]root@news:~> newfs /dev/vn0c :preposterous size -2147483648 : :Dave. Heh heh. Yes, newfs has some overflows inside it when you get that big. Also, you'll probably run out of swap just newfs'ing the metadata, you need to use a larger block size, large -c value, and a large bytes/inode (-i) value. But then, of course, you are likely to run out of swap trying to write out a large file even if you do manage to newfs it. I had a set of patches for newfs a year or two ago but never incorporated them. We'd have to do a run-through on newfs to get it to newfs a swap-backed (i.e. 4K/sector) 1TB filesystem. Actually, this brings up a good point. Drive storage is beginning to reach the limitations of FFS and our internal (512 byte/block) block numbering scheme. IBM is almost certain to come out with their 500GB hard drive sometime this year. We should probably do a bit of cleanup work to make sure that we can at least handle FFS's theoretical limitations for real. vnconfig -e -s labels -S 900g vn0 newfs -i 1048576 -f 8192 -b 65536 -c 100 /dev/vn0c mobile:/home/dillon> pstat -s Device 1K-blocks Used Avail Capacity Type /dev/ad0s1b 524160 188976 335184 36% Interleaved -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 14: 4:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 5E5F837B65D for ; Sun, 25 Feb 2001 14:04:39 -0800 (PST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f1PM4bh84859; Sun, 25 Feb 2001 15:04:38 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.2/8.8.3) with ESMTP id f1PM1fY00967; Sun, 25 Feb 2001 15:01:42 -0700 (MST) Message-Id: <200102252201.f1PM1fY00967@billy-club.village.org> To: seebs@plethora.net (Peter Seebach) Subject: Re: Setting memory allocators for library functions. Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Sun, 25 Feb 2001 09:59:02 CST." <200102251559.f1PFx2627103@guild.plethora.net> References: <200102251559.f1PFx2627103@guild.plethora.net> Date: Sun, 25 Feb 2001 15:01:41 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102251559.f1PFx2627103@guild.plethora.net> Peter Seebach writes: : In message <3A98EE37.7B0B6CE0@newsguy.com>, "Daniel C. Sobral" writes: : >OTOH, the *only* way to get non-overcommit to FreeBSD is for someone who : >*wants* that feature to sit down and code it. It won't happen otherwise. : : So, out of idle curiousity: If, somewhere down the road, I know the kernel : well enough to attempt such a thing, what would the interest level be in : merging such a feature? Assuming that it doesn't break anything, that it doesn't introduce a severe performance penalty and works, there would be interest. There are times that this is a desirable feature. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 15:14:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id 9887F37B491 for ; Sun, 25 Feb 2001 15:14:38 -0800 (PST) (envelope-from ticso@cicely8.cicely.de) Received: from cicely7.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id f1PNEPT12348 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Mon, 26 Feb 2001 00:14:26 +0100 (MET) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by cicely7.cicely.de (8.11.2/8.11.2) with ESMTP id f1PNEh905682; Mon, 26 Feb 2001 00:14:43 +0100 (CET) (envelope-from ticso@cicely8.cicely.de) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.2/8.11.2) id f1PNEcv01029; Mon, 26 Feb 2001 00:14:38 +0100 (CET) (envelope-from ticso) Date: Mon, 26 Feb 2001 00:14:36 +0100 From: Bernd Walter To: David Gilbert Cc: Matt Dillon , Bernd Walter , freebsd-hackers@FreeBSD.ORG Subject: Re: [hackers] Re: Large MFS on NFS-swap? Message-ID: <20010226001436.A728@cicely8.cicely.de> References: <15000.8884.6165.759008@trooper.velocet.net> <20010225042933.A508@cicely5.cicely.de> <200102250644.f1P6iuL12016@earth.backplane.com> <15001.21129.307283.198917@trooper.velocet.net> <200102251913.f1PJDAc15495@earth.backplane.com> <15001.35517.468307.915125@trooper.velocet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <15001.35517.468307.915125@trooper.velocet.net>; from dgilbert@velocet.ca on Sun, Feb 25, 2001 at 05:44:13PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Feb 25, 2001 at 05:44:13PM -0500, David Gilbert wrote: > >>>>> "Matt" == Matt Dillon writes: > > [... my newfw bomb deleted ...] > > Matt> I had a set of patches for newfs a year or two ago but never > Matt> incorporated them. We'd have to do a run-through on newfs to > Matt> get it to newfs a swap-backed (i.e. 4K/sector) 1TB filesystem. > > Matt> Actually, this brings up a good point. Drive storage is > Matt> beginning to reach the limitations of FFS and our internal (512 > Matt> byte/block) block numbering scheme. IBM is almost certain to > Matt> come out with their 500GB hard drive sometime this year. We > Matt> should probably do a bit of cleanup work to make sure that we > Matt> can at least handle FFS's theoretical limitations for real. > > That and the availability of vinum and other raid solutions. You can > always make multiple partitions for no good reason (other than > filesystem limitations), but we were planning to put together a 1TB > filesystem next month. From what you're telling me, I'd need larger > block sizes to make this work? With 512 Byte blocksizes you are limited to 1T because the physical block number is a signed 32bit. FFS uses 32bit (I wouldn't count on the high bit) frag numbers. A fragment defaults to 1k so even with 1k fragments the limit is at least 2T. It is possible to reformat most SCSI disks to 1k or 2k block sizes, but I'm not shure if vinum handles non 512 byte blocks correctly and I don't know if the buffer code always uses 512 or physical sizes. Maybe ccd is an option. AFAIK the same limit is there for SCSI as SCSI uses 32bit block numbers. Using a RAID controller will show the same limits and it's usually untested with block sizes != 512. > IMHO, we might reconsider that. With SAN-type designs, you're > probably going to find the distribution of filesizes on > multi-terrabyte filesystems that are shared by 100's of computers to > be roughly the same as the filesize distributions on today's > filesystems. > > Making the run for larger block sizes puts us in the same league as > DOS. While it will stave off the wolves, it will only work for so > long give Moore's law. Noone is telling that that's the way the world will go. But is a goable workaround until the world is more perfect. The base design should allow using 64bit values some day without the scaling problem and consistency risks as DOS. The steps have to go increasing the limits of the buffer system and the filesystem after that. I'm shure the persons with knowledge about that will do what is possible after -current stabilizes a bit. Changing everything at the same time is not a good way to go. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 15:34:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 4C17A37B401 for ; Sun, 25 Feb 2001 15:34:23 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1PNYIf18842; Sun, 25 Feb 2001 15:34:18 -0800 (PST) (envelope-from dillon) Date: Sun, 25 Feb 2001 15:34:18 -0800 (PST) From: Matt Dillon Message-Id: <200102252334.f1PNYIf18842@earth.backplane.com> To: David Gilbert Cc: Bernd Walter , freebsd-hackers@FreeBSD.ORG Subject: Re: [hackers] Re: Large MFS on NFS-swap? References: <15000.8884.6165.759008@trooper.velocet.net> <20010225042933.A508@cicely5.cicely.de> <200102250644.f1P6iuL12016@earth.backplane.com> <15001.21129.307283.198917@trooper.velocet.net> <200102251913.f1PJDAc15495@earth.backplane.com> <15001.35517.468307.915125@trooper.velocet.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Making the run for larger block sizes puts us in the same league as :DOS. While it will stave off the wolves, it will only work for so :long give Moore's law. : :Dave. : :-- :============================================================================ :|David Gilbert, Velocet Communications. | Two things can only be | Ultimately the limit we face is the fact that we use 32 bit quantities to store block numbers. At 512 bytes per block, and assuming only 31 bits of useful space, we are limited to 2G x 512 = 1TB. (filesystems such as FFS use 'negative' block numbers for special purposes). Within the kernel we have already moved to 64 bit offsets for everything that is offset-based. Block numbers however are still 32 bits. There have been a number of proposals on how to solve the problem and the one that will probably win in the end will be to pass 64 bit offsets all the way through to the low level disk I/O. e.g. we would still guarentee appropriate block boundries for the offsets when passing them through to the device level, but we would not do the divide that we currently do. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 15:37:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 6DBAA37B4EC for ; Sun, 25 Feb 2001 15:37:49 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1PNbeS18875; Sun, 25 Feb 2001 15:37:40 -0800 (PST) (envelope-from dillon) Date: Sun, 25 Feb 2001 15:37:40 -0800 (PST) From: Matt Dillon Message-Id: <200102252337.f1PNbeS18875@earth.backplane.com> To: Bernd Walter Cc: David Gilbert , Bernd Walter , freebsd-hackers@FreeBSD.ORG Subject: Re: [hackers] Re: Large MFS on NFS-swap? References: <15000.8884.6165.759008@trooper.velocet.net> <20010225042933.A508@cicely5.cicely.de> <200102250644.f1P6iuL12016@earth.backplane.com> <15001.21129.307283.198917@trooper.velocet.net> <200102251913.f1PJDAc15495@earth.backplane.com> <15001.35517.468307.915125@trooper.velocet.net> <20010226001436.A728@cicely8.cicely.de> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :With 512 Byte blocksizes you are limited to 1T because the physical :block number is a signed 32bit. :FFS uses 32bit (I wouldn't count on the high bit) frag numbers. :A fragment defaults to 1k so even with 1k fragments the limit is :at least 2T. Yes, the FFS limit is essentially the frag size limitation. However, internally our device I/O path normalizes blocks to 512 byte quantities. I've heard of people running larger filesystems (16TB) with larger fragment sizes, but I'm not exactly sure how it can work under FreeBSD due to the normalization that the FreeBSD device layer makes. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 19:42:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from proxy4.ba.best.com (proxy4.ba.best.com [206.184.139.15]) by hub.freebsd.org (Postfix) with ESMTP id 2227A37B491 for ; Sun, 25 Feb 2001 19:42:42 -0800 (PST) (envelope-from scott@renfro.org) Received: from renfro.org (dynamic30.pm01.san-jose.best.com [209.24.164.30]) by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id TAA17818; Sun, 25 Feb 2001 19:40:31 -0800 (PST) Received: (from scott@localhost) by renfro.org (8.11.2/8.11.2) id f1Q3fKE64126; Sun, 25 Feb 2001 19:41:20 -0800 (PST) (envelope-from scott) Date: Sun, 25 Feb 2001 19:41:20 -0800 From: Scott Renfro To: Soren Schmidt Cc: freebsd-hackers@freebsd.org, Richard Johnson Subject: ata-disk ioctl and atactl patch Message-ID: <20010225194120.A64003@bonsai.home.renfro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As I promised on -mobile earlier this week, I've cleaned up my patches to port the {Net,Open}BSD atactl utility, including a simplistic ata-disk ioctl. They apply cleanly against this afternoon's -stable (including Soren's latest commit bringing -stable up to date with -current). I've been running them for some time and they ''work great here''. Before announcing this in a broader context, I wanted to get a bit of feedback on the ioctl implementation. In particular, is it safe to just do an ata_command inside adioctl() without any further checking? (e.g., can this cause bad things to happen under heavy i/o load?) Here's a snippet from the newly added adioctl() in ata-disk.c: switch (cmd) { case ATAIOCCOMMAND: { struct atareq *req = (struct atareq *)addr; if (!req) return EINVAL; /* request not valid */ /* issue an ata command */ switch (req->command) { case ATAPI_STANDBY_IMMEDIATE: case ATAPI_IDLE_IMMEDIATE: /* no count argument */ error = ata_command(adp->controller, adp->unit, req->command, 0, 0, 0, 0, 0, ATA_WAIT_INTR); The full diffs are at http://www.renfro.org/scott (at the bottom of the page). These patches only implement the idle, setidle, standby, and setstandby commands. I haven't tackled sleep, identify, or checkpower commands. (Sleep isn't hard to implement, but I haven't tested whether the driver would actually reset all state properly when coming out of sleep or whether more code is required to do this). For those that question the usefulness of atactl: I do find this extremely useful. On a laptop with noatime mounts, softupdates, and syslog, cron, and atrun disabled, I can go a long time (an hour or more) without the drive spinning up. It also cuts the noise level of my Z505L in half. (Now if I can just get the fan to shut up ;-) Thanks, -scott -- Scott Renfro +1 650 906 9618 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 20: 0:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peorth.iteration.net (peorth.iteration.net [208.190.180.178]) by hub.freebsd.org (Postfix) with ESMTP id C28AC37B65D for ; Sun, 25 Feb 2001 20:00:10 -0800 (PST) (envelope-from keichii@peorth.iteration.net) Received: by peorth.iteration.net (Postfix, from userid 1001) id 541FD5953A; Sun, 25 Feb 2001 22:00:31 -0600 (CST) Date: Sun, 25 Feb 2001 22:00:31 -0600 From: "Michael C . Wu" To: John Wilson Cc: freebsd-hackers@freebsd.org Subject: Re: Converting Perforce to CVS Message-ID: <20010225220031.A64617@peorth.iteration.net> Reply-To: "Michael C . Wu" Mail-Followup-To: "Michael C . Wu" , John Wilson , freebsd-hackers@freebsd.org References: <18242322.983121459104.JavaMail.imail@bernie.excite.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <18242322.983121459104.JavaMail.imail@bernie.excite.com>; from john_wilson100@excite.com on Sun, Feb 25, 2001 at 09:17:38AM -0800 X-PGP-Fingerprint: 5025 F691 F943 8128 48A8 5025 77CE 29C5 8FA1 2E20 X-PGP-Key-ID: 0x8FA12E20 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Feb 25, 2001 at 09:17:38AM -0800, John Wilson scribbled: | If you still have the Perforce->CVS conversion script, I would be very | grateful if you could e-mail it to me. Such a script is available for download on www.perforce.com. | On Tue, 9 Jan 2001 09:13:39 +0100, Anton Berezin wrote: | > On Sat, Jan 06, 2001 at 03:06:20PM -0800, John Wilson wrote: | > > I apologize in advance, as this is not strictly a FreeBSD-related | question, | > > but I know that a lot of FreeBSD'ers use CVS as well as Perforce, so | here | > > goes... | > > | > > What is the easiest way to convert a P4 source repository to CVS, while | > > preserving revisions, history, log messages, etc? Both systems seem | to use | > > RCS, but is it as simple as copying the files? Are there any caveats? | | > | > I have one script, but it does not handle branches (the project I was | > converting did not have any). I can mail it to you if you want. The | > branch handling should be rather similar to binary files handling, which | > the script already performs. -- +------------------------------------------------------------------+ | keichii@peorth.iteration.net | keichii@bsdconspiracy.net | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +------------------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 20:55:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id 5640837B69F for ; Sun, 25 Feb 2001 20:55:28 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1Q4tQ606269 for ; Sun, 25 Feb 2001 22:55:27 -0600 (CST) Message-Id: <200102260455.f1Q4tQ606269@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: [hackers] Re: Setting memory allocators for library functions. In-reply-to: Your message of "Sun, 25 Feb 2001 23:47:29 EST." <15001.57313.163670.146752@trooper.velocet.net> Date: Sun, 25 Feb 2001 22:55:26 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <15001.57313.163670.146752@trooper.velocet.net>, David Gilbert write s: >IIRC, Digital-UNIX or OSF-1 ... or whatever it's called now. I seem >to remember the first Alphas that arrived to a company I worked for >had this set globally in the OS by default. Due to the bloat of the >OS and Motif and other such things, they required simply amazing >amounts of swap just to run. Well, to some extent, I have to wonder why all these pages are being requested if they aren't being used... Still, all we "really" need to do is make sure that we flag the space as definitely for sure already taken up; it doesn't need to be backed to swap unless it's been dirtied, because untouched allocated memory is allowed to contain random garbage. You don't need to actually store all the pages right away - just make sure that you have a place to put them, say, some swap space or something. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 21:29:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id B1B5037B503 for ; Sun, 25 Feb 2001 21:29:08 -0800 (PST) (envelope-from archie@dellroad.org) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA93254; Sun, 25 Feb 2001 21:29:08 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.11.2/8.11.2) id f1Q5T8413011; Sun, 25 Feb 2001 21:29:08 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200102260529.f1Q5T8413011@curve.dellroad.org> Subject: Re: Setting memory allocators for library functions. In-Reply-To: <200102252201.f1PM1fY00967@billy-club.village.org> "from Warner Losh at Feb 25, 2001 03:01:41 pm" To: Warner Losh Date: Sun, 25 Feb 2001 21:29:08 -0800 (PST) Cc: Peter Seebach , freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh writes: > : >OTOH, the *only* way to get non-overcommit to FreeBSD is for someone who > : >*wants* that feature to sit down and code it. It won't happen otherwise. > : > : So, out of idle curiousity: If, somewhere down the road, I know the kernel > : well enough to attempt such a thing, what would the interest level be in > : merging such a feature? > > Assuming that it doesn't break anything, that it doesn't introduce a > severe performance penalty and works, there would be interest. There > are times that this is a desirable feature. This thread reminds me of what happened when I brought up the same issue a few years ago, arguing that the kernel shouldn't overcommit memory (i.e., the same thing, everybody though I was nuts :) For me it helps to understand people's underlying motivation. Here's mine... my perspective probably comes from using FreeBSD in the embedded world, which is very different from using FreeBSD in the rack-mounted server world. One important way to gain confidence that you're little box won't silently crash at the worst possible time for the customer is to be able to *prove* to yourself that it can't happen, given certain assumptions. Those assumptions usually include things like "the hardware is working properly" (e.g., no ECC errors) and "the compiler compiled my C code correctly". Given these basic assumptions, you go through and check that you've properly handled every possible case of input (malicious or otherwise) from the outside world. Part of the "proof" is verifying that you've checked all of your malloc(3) return values for NULL.. and assuming that if malloc(3) returns != NULL, then the memory is really there. Now, if malloc can return NULL and the memory *not* really be there, there is simply no way to prove that your code is not going to crash. This memory overcommit thing is the only case that I can think of where this happens, given the basic assumptions of correctly functioning hardware, etc. That is why it's especially annoying to (some) people. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 22: 7: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from syncopation-03.iinet.net.au (syncopation-03.iinet.net.au [203.59.24.49]) by hub.freebsd.org (Postfix) with SMTP id 2825837B401 for ; Sun, 25 Feb 2001 22:06:58 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 16600 invoked by uid 666); 26 Feb 2001 06:19:02 -0000 Received: from i091-108.nv.iinet.net.au (HELO elischer.org) (203.59.91.108) by mail.m.iinet.net.au with SMTP; 26 Feb 2001 06:19:02 -0000 Message-ID: <3A99F25A.B940BEE0@elischer.org> Date: Sun, 25 Feb 2001 22:06:18 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Archie Cobbs Cc: Warner Losh , Peter Seebach , freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102260529.f1Q5T8413011@curve.dellroad.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Archie Cobbs wrote: > > Warner Losh writes: > > : >OTOH, the *only* way to get non-overcommit to FreeBSD is for someone who > > : >*wants* that feature to sit down and code it. It won't happen otherwise. > > : > > : So, out of idle curiousity: If, somewhere down the road, I know the kernel > > : well enough to attempt such a thing, what would the interest level be in > > : merging such a feature? > > > > Assuming that it doesn't break anything, that it doesn't introduce a > > severe performance penalty and works, there would be interest. There > > are times that this is a desirable feature. > > This thread reminds me of what happened when I brought up the same > issue a few years ago, arguing that the kernel shouldn't overcommit > memory (i.e., the same thing, everybody though I was nuts :) > > For me it helps to understand people's underlying motivation. Here's > mine... my perspective probably comes from using FreeBSD in the > embedded world, which is very different from using FreeBSD in the > rack-mounted server world. > > One important way to gain confidence that you're little box won't > silently crash at the worst possible time for the customer is to > be able to *prove* to yourself that it can't happen, given certain > assumptions. Those assumptions usually include things like "the > hardware is working properly" (e.g., no ECC errors) and "the compiler > compiled my C code correctly". > > Given these basic assumptions, you go through and check that you've > properly handled every possible case of input (malicious or otherwise) > from the outside world. Part of the "proof" is verifying that you've > checked all of your malloc(3) return values for NULL.. and assuming > that if malloc(3) returns != NULL, then the memory is really there. > > Now, if malloc can return NULL and the memory *not* really be there, > there is simply no way to prove that your code is not going to crash. > > This memory overcommit thing is the only case that I can think of > where this happens, given the basic assumptions of correctly > functioning hardware, etc. That is why it's especially annoying to > (some) people. I still think that in such a case it should be possible to 'test the commitment' by touching all the allocated memory while trapping page faults. and fault all your memory from 'potential' to 'allocated'. As someone said. it is not sure which program when you run out of swap, but I think you might be able to somehow change this behaviour to "the program making the request" fails (or gets a fault). You could allocate your memory. trap faults. touch all of the allocated memory. if it faults, you can remap some file to that location to allow the instruction to continue.. continue and abort the check.. exit as needed, OR continue with secure knowledge that all your memory is there. Alternatively you could allocate your own on-disk swapspace for a program by telling malloc to use a file for all your memory needs. > > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 22:29:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 64DD637B491 for ; Sun, 25 Feb 2001 22:29:14 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1Q6SYX29811; Sun, 25 Feb 2001 22:28:34 -0800 (PST) (envelope-from dillon) Date: Sun, 25 Feb 2001 22:28:34 -0800 (PST) From: Matt Dillon Message-Id: <200102260628.f1Q6SYX29811@earth.backplane.com> To: Archie Cobbs Cc: Warner Losh , Peter Seebach , freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102260529.f1Q5T8413011@curve.dellroad.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :... :> : merging such a feature? :> :> Assuming that it doesn't break anything, that it doesn't introduce a :> severe performance penalty and works, there would be interest. There :> are times that this is a desirable feature. : :This thread reminds me of what happened when I brought up the same :issue a few years ago, arguing that the kernel shouldn't overcommit :memory (i.e., the same thing, everybody though I was nuts :) : :For me it helps to understand people's underlying motivation. Here's The memory overcommit thread comes up once or twice a year. So this time around I am going to try to take a different tact in trying to explain the issue. One could argue about making the OS not overcommit until one is blue in the face. One could argue that every single routine that allocates memory must be prepared to handle a memory failure in a graceful manner. One could argue all sorts of high-and-mighty value things. But its all a crock. It simply isn't possible to gracefully handle an out of memory condition. All sorts of side effects occur when the system runs out of memory, even *with* overcommit protection. In fact, all sorts of side effects occur even when the system *doesn't* run out of memory, but instead just starts to thrash swap. All sorts of side effects occur if the system starts to get cornered memory-wise even if you don't *have* any swap. The number of possible combinations of effects is near infinite and nearly impossible to program against. Simply put, the 'overcommit' argument doesn't actually solve the problem in any meaningful way. Any significantly sized program that actually handled every possible combination and side effect of an out-of-memory condition gracefully would have so much conditional garbage cluttering it up that the rest of the code would be obscured in a haze of if()'s. There ain't no magic bullet here, folks. By the time you get a memory failure, even with no overcommit, it is far too late to save the day. There is only one correct way to handle an out of memory condition and that is to make sure it doesn't happen... so when it does happen you can treat it as a fatal error and scream bloody murder. It's a whole lot easier to design a program with bounded, deterministic memory use (e.g. database X requires Y kilobytes of memory per client instance) and control that use at the edges rather then to try to deal with memory failures gracefully in the deepest darkest corners of the program. And it's a whole lot more reliable, too. When I write such a program, if I care about bounding memory use I do it at the edges. I don't pollute low level allocation routines (like strdup(), small structural allocations, etc...) with all sorts of conditionals to gracefully back out of a memory failure. It's a huge waste of time. I just wrap the routines... safe_strdup(), safe_malloc(), safe_asprintf()... and the wrappers scream bloody murder and exit if they get a failure. It's that simple... and far more reliable. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 23:10:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 9FB8D37B491 for ; Sun, 25 Feb 2001 23:10:14 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1Q79fq30005; Sun, 25 Feb 2001 23:09:41 -0800 (PST) (envelope-from dillon) Date: Sun, 25 Feb 2001 23:09:41 -0800 (PST) From: Matt Dillon Message-Id: <200102260709.f1Q79fq30005@earth.backplane.com> To: seebs@plethora.net (Peter Seebach) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102251559.f1PFx2627103@guild.plethora.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :In message <3A98EE37.7B0B6CE0@newsguy.com>, "Daniel C. Sobral" writes: :>OTOH, the *only* way to get non-overcommit to FreeBSD is for someone who :>*wants* that feature to sit down and code it. It won't happen otherwise. : :So, out of idle curiousity: If, somewhere down the road, I know the kernel :well enough to attempt such a thing, what would the interest level be in :merging such a feature? : :-s The problem is a whole lot more complex then you think. Dealing with overcommit is not simply counting mapped pages, there are all sorts of issues involved. But the biggest gotcha is that putting in overcommit protection will not actually save your system from dying a terrible death. It in fact makes it *more* likely that the system will die a horrible death, because with overcommit protection you wind up pre-reserving resources that would otherwise be reserved on demand (and often might not ever be used by the programs mapping those resources). Not only that, but overcommit protection does not protect you from thrashing, and quite often the system will become unusable long before it actually runs out of memory+swap. This is true whether you have configured swap or not... it is perfectly easy to thrash a swapless system if the vast majority of pages are clean (e.g. you mmap() a lot of files read-only). A simple example of this is mmap(... PROT_READ|PROT_WRITE, MAP_PRIVATE), or even simply the static data and bss space associated with a program binary. Such memory only takes up physical space if you dirty it...you can *read* the memory all you want without having to reserve any resources, the OS can throw the physical page away at any time and reload it form the backing file. But the moment you dirty the memory the OS must allocate real resources to it ... either a physical page, or swap (and it can flip between the two). Many such mappings never actually require dirtying the underlying page and thus never actually take any resources. But with overcommit protection you have to reserve the resources immediately, even if the program will never use them. The result is that your system is likely to run out of memory long before it would without the overcommit protection. There are many other issues involved as well that are more complex, such as what you have to do when a program fork()s. So before you get into tring to 'protect' yourself by implementing overcommit protection, you need to think long and hard on what you are actually protecting yourself from... and what you aren't. People seem to believe that edge cases such as allocating memory and then the system faulting the process later because it couldn't allocate the actual backing store later is of paramount importance but they seem to forget that by the time you reach that situation, you are generally already past the point of no return. Overcommit protection doesn't even come close to being able to prevent your system from getting into an unrecoverable situation and it certainly is no substitute for writing the software correctly (such that the memory failure can't occur in the first place). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 23:29: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id E961D37B503 for ; Sun, 25 Feb 2001 23:28:59 -0800 (PST) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.9.3/8.9.1) id IAA43029; Mon, 26 Feb 2001 08:28:56 +0100 (CET) (envelope-from sos) From: Soren Schmidt Message-Id: <200102260728.IAA43029@freebsd.dk> Subject: Re: ata-disk ioctl and atactl patch In-Reply-To: <20010225194120.A64003@bonsai.home.renfro.org> from Scott Renfro at "Feb 25, 2001 07:41:20 pm" To: scott@renfro.org (Scott Renfro) Date: Mon, 26 Feb 2001 08:28:56 +0100 (CET) Cc: freebsd-hackers@freebsd.org, raj@cisco.com (Richard Johnson) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Scott Renfro wrote: > As I promised on -mobile earlier this week, I've cleaned up my patches > to port the {Net,Open}BSD atactl utility, including a simplistic > ata-disk ioctl. They apply cleanly against this afternoon's -stable > (including Soren's latest commit bringing -stable up to date with > -current). I've been running them for some time and they ''work great > here''. > > Before announcing this in a broader context, I wanted to get a bit of > feedback on the ioctl implementation. In particular, is it safe to > just do an ata_command inside adioctl() without any further checking? > (e.g., can this cause bad things to happen under heavy i/o load?) No its not safe at all, you risk trashing an already running command... Anyhow, I have an atacontrol thingy in the works for attach/detach, raid control etc, etc, I'll try to merge this functionality into that (the ioctl's will change etc, but the functionality is nice)... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 25 23:53: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 3B86537B401 for ; Sun, 25 Feb 2001 23:52:56 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p47-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.112]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id QAA22812; Mon, 26 Feb 2001 16:52:37 +0900 (JST) Message-ID: <3A9A0A9A.E4D31F97@newsguy.com> Date: Mon, 26 Feb 2001 16:49:46 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Matt Dillon Cc: Archie Cobbs , Warner Losh , Peter Seebach , freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102260529.f1Q5T8413011@curve.dellroad.org> <200102260628.f1Q6SYX29811@earth.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote: > > But its all a crock. It simply isn't possible to gracefully handle > an out of memory condition. All sorts of side effects occur when > the system runs out of memory, even *with* overcommit protection. > In fact, all sorts of side effects occur even when the system > *doesn't* run out of memory, but instead just starts to thrash swap. > All sorts of side effects occur if the system starts to get cornered > memory-wise even if you don't *have* any swap. The number of possible > combinations of effects is near infinite and nearly impossible to > program against. Simply put, the 'overcommit' argument doesn't > actually solve the problem in any meaningful way. Any significantly > sized program that actually handled every possible combination and > side effect of an out-of-memory condition gracefully would have so much > conditional garbage cluttering it up that the rest of the code would > be obscured in a haze of if()'s. That's an assumption. > There ain't no magic bullet here, folks. By the time you get a memory > failure, even with no overcommit, it is far too late to save the day. Scientific computation. If, at one point, no more memory can be allocated, you back off, save the present results, and try again later. > There is only one correct way to handle an out of memory condition and > that is to make sure it doesn't happen... so when it does happen you > can treat it as a fatal error and scream bloody murder. It's a whole lot > easier to design a program with bounded, deterministic memory use (e.g. > database X requires Y kilobytes of memory per client instance) and > control that use at the edges rather then to try to deal with memory > failures gracefully in the deepest darkest corners of the program. > And it's a whole lot more reliable, too. > > When I write such a program, if I care about bounding memory use > I do it at the edges. I don't pollute low level allocation routines > (like strdup(), small structural allocations, etc...) with all sorts > of conditionals to gracefully back out of a memory failure. It's a huge > waste of time. I just wrap the routines... safe_strdup(), safe_malloc(), > safe_asprintf()... and the wrappers scream bloody murder and exit if > they get a failure. It's that simple... and far more reliable. You assume too much. Quite a few of the more efficient garbage collection algorithms depend on knowing when the memory has become full. You keep allocating, and when malloc() returns NULL, *then* you run the garbage collector, free some space, and try again. If malloc() doesn't work, quite a few very efficient garbage collection algorithms become impossible to implement. Just because *you* don't see how one thing can work, it doesn't mean it can't work. As I have trivially shown above. Honestly, I think non-overcommit is a mistake and your approach is much better, but it's not the only approach and there _are_ valid approaches that depend on not overcommitting, and I really hate having to defend non-overcommit against such bogus arguments. You don't implement it because you don't think it's worth your time and you are not being paid to do so. That's a perfectly good reason, and if people would just stick with it the threads about this would die much sooner. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@kzinti.bsdconspiracy.net Acabou o hipismo-arte. Mas a desculpa brasileira mais ouvida em Sydney e' que nao tem mais cavalo bobo por ai'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 1:14:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 39EE837B6BA for ; Mon, 26 Feb 2001 01:13:48 -0800 (PST) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id CD0073E02 for ; Mon, 26 Feb 2001 01:13:47 -0800 (PST) To: hackers@freebsd.org Subject: Inheriting the nodump flag Date: Mon, 26 Feb 2001 01:13:47 -0800 From: Dima Dorfman Message-Id: <20010226091347.CD0073E02@bazooka.unixfreak.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello -hackers Some time ago, on -arch, phk proposed that the nodump flag should be inherited (see 'inheriting the "nodump" flag ?' around Dec. 2000). This was generally considered a good idea, however, the patch to the kernel he proposed was thought an ugly hack. In addition, jeroen pointed out that NetBSD had implemented this functionality the Right Way(tm), in dump(8). Attached below is a port of NetBSD's patch to FreeBSD's dump(8). dump's tree walker is a little weird, so the patch is a little more complicated than calling fts_set with FTS_SKIP. For the technical details of what it does, see: http://lists.openresources.com/NetBSD/tech-kern/msg00453.html. I've been using this on two of my hosts for a while, and it works as expected. Given the additional fact that NetBSD has had this for almost two years, and that the patch below looks very similar to the one they applied, I doubt it significantly breaks anything. Comments? Thanks in advance Dima Dorfman dima@unixfreak.org Index: traverse.c =================================================================== RCS file: /st/src/FreeBSD/src/sbin/dump/traverse.c,v retrieving revision 1.11 diff -u -r1.11 traverse.c --- traverse.c 2000/04/14 06:14:59 1.11 +++ traverse.c 2001/02/20 01:39:06 @@ -74,9 +74,11 @@ typedef long fsizeT; #endif -static int dirindir __P((ino_t ino, daddr_t blkno, int level, long *size)); +static int dirindir __P((ino_t ino, daddr_t blkno, int level, long *size, + long *tapesize, int nodump)); static void dmpindir __P((ino_t ino, daddr_t blk, int level, fsizeT *size)); -static int searchdir __P((ino_t ino, daddr_t blkno, long size, long filesize)); +static int searchdir __P((ino_t ino, daddr_t blkno, long size, long filesize, + long *tapesize, int nodump)); /* * This is an estimation of the number of TP_BSIZE blocks in the file. @@ -152,10 +154,14 @@ dp = getino(ino); if ((mode = (dp->di_mode & IFMT)) == 0) continue; - SETINO(ino, usedinomap); + /* + * All dirs go in dumpdirmap; only inodes that are to + * be dumped go in usedinomap and dumpinomap, however. + */ if (mode == IFDIR) SETINO(ino, dumpdirmap); if (WANTTODUMP(dp)) { + SETINO(ino, usedinomap); SETINO(ino, dumpinomap); if (mode != IFREG && mode != IFDIR && mode != IFLNK) *tapesize += 1; @@ -192,9 +198,10 @@ long *tapesize; { register struct dinode *dp; - register int i, isdir; + register int i, isdir, nodump; register char *map; register ino_t ino; + struct dinode di; long filesize; int ret, change = 0; @@ -204,24 +211,34 @@ isdir = *map++; else isdir >>= 1; - if ((isdir & 1) == 0 || TSTINO(ino, dumpinomap)) + /* + * If a directory has been removed from usedinomap, it + * either has the nodump flag set, or has inherited + * it. Although a directory can't be in dumpinomap if + * it isn't in usedinomap, we have to go through it to + * propogate the nodump flag. + */ + nodump = (TSTINO(ino, usedinomap) == 0); + if ((isdir & 1) == 0 || (TSTINO(ino, dumpinomap) && !nodump)) continue; dp = getino(ino); - filesize = dp->di_size; + di = *dp; /* inode buf may change in searchdir(). */ + filesize = di.di_size; for (ret = 0, i = 0; filesize > 0 && i < NDADDR; i++) { - if (dp->di_db[i] != 0) - ret |= searchdir(ino, dp->di_db[i], + if (di.di_db[i] != 0) + ret |= searchdir(ino, di.di_db[i], (long)dblksize(sblock, dp, i), - filesize); + filesize, tapesize, nodump); if (ret & HASDUMPEDFILE) filesize = 0; else filesize -= sblock->fs_bsize; } for (i = 0; filesize > 0 && i < NIADDR; i++) { - if (dp->di_ib[i] == 0) + if (di.di_ib[i] == 0) continue; - ret |= dirindir(ino, dp->di_ib[i], i, &filesize); + ret |= dirindir(ino, di.di_ib[i], i, &filesize, + tapesize, nodump); } if (ret & HASDUMPEDFILE) { SETINO(ino, dumpinomap); @@ -229,12 +246,15 @@ change = 1; continue; } - if ((ret & HASSUBDIRS) == 0) { + if (nodump) { + if (ret & HASSUBDIRS) + change = 1; /* subdirs inherit nodump */ + CLRINO(ino, dumpdirmap); + } else if ((ret & HASSUBDIRS) == 0) if (!TSTINO(ino, dumpinomap)) { CLRINO(ino, dumpdirmap); change = 1; } - } } return (change); } @@ -245,11 +265,13 @@ * require the directory to be dumped. */ static int -dirindir(ino, blkno, ind_level, filesize) +dirindir(ino, blkno, ind_level, filesize, tapesize, nodump) ino_t ino; daddr_t blkno; int ind_level; long *filesize; + long *tapesize; + int nodump; { int ret = 0; register int i; @@ -261,7 +283,7 @@ blkno = idblk[i]; if (blkno != 0) ret |= searchdir(ino, blkno, sblock->fs_bsize, - *filesize); + *filesize, tapesize, nodump); if (ret & HASDUMPEDFILE) *filesize = 0; else @@ -273,7 +295,8 @@ for (i = 0; *filesize > 0 && i < NINDIR(sblock); i++) { blkno = idblk[i]; if (blkno != 0) - ret |= dirindir(ino, blkno, ind_level, filesize); + ret |= dirindir(ino, blkno, ind_level, filesize, + tapesize, nodump); } return (ret); } @@ -284,13 +307,16 @@ * contains any subdirectories. */ static int -searchdir(ino, blkno, size, filesize) +searchdir(ino, blkno, size, filesize, tapesize, nodump) ino_t ino; daddr_t blkno; register long size; long filesize; + long *tapesize; + int nodump; { register struct direct *dp; + register struct dinode *ip; register long loc, ret = 0; char dblk[MAXBSIZE]; @@ -311,16 +337,30 @@ continue; if (dp->d_name[1] == '.' && dp->d_name[2] == '\0') continue; - } - if (TSTINO(dp->d_ino, dumpinomap)) { - ret |= HASDUMPEDFILE; - if (ret & HASSUBDIRS) - break; } - if (TSTINO(dp->d_ino, dumpdirmap)) { - ret |= HASSUBDIRS; - if (ret & HASDUMPEDFILE) - break; + if (nodump) { + ip = getino(dp->d_ino); + if (TSTINO(dp->d_ino, dumpinomap)) { + CLRINO(dp->d_ino, dumpinomap); + CLRINO(dp->d_ino, usedinomap); + *tapesize -= blockest(ip); + } + /* Add back to dumpdirmap to propogate nodump. */ + if ((ip->di_mode & IFMT) == IFDIR) { + SETINO(dp->d_ino, dumpdirmap); + ret |= HASSUBDIRS; + } + } else { + if (TSTINO(dp->d_ino, dumpinomap)) { + ret |= HASDUMPEDFILE; + if (ret & HASSUBDIRS) + break; + } + if (TSTINO(dp->d_ino, dumpdirmap)) { + ret |= HASSUBDIRS; + if (ret & HASDUMPEDFILE) + break; + } } } return (ret); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 6:57:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id EFCD237B491 for ; Mon, 26 Feb 2001 06:57:38 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1QEva607692 for ; Mon, 26 Feb 2001 08:57:36 -0600 (CST) Message-Id: <200102261457.f1QEva607692@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Sun, 25 Feb 2001 22:06:18 PST." <3A99F25A.B940BEE0@elischer.org> Date: Mon, 26 Feb 2001 08:57:35 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3A99F25A.B940BEE0@elischer.org>, Julian Elischer writes: >I still think that in such a case it should be possible to >'test the commitment' by touching all the allocated memory >while trapping page faults. And what do you do if you get one? There's no undo button for SIGSEGV. Traditionally, you return from the signal handler right where you were. Can you get out of this with longjmp()? Probably. It's not exactly supported or guaranteed. In any event: 1. The C language spec doesn't require you to do this. 2. Other implementations have provided this guarantee, at least as an option. It's odd that I see lots of people arguing for segfaults killing the process accessing memory that has been "successfully" allocated, but no one arguing for the process getting killed when it exceeds a disk quota. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 7: 6:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id 32B2437B503 for ; Mon, 26 Feb 2001 07:06:35 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1QF6Y607763 for ; Mon, 26 Feb 2001 09:06:34 -0600 (CST) Message-Id: <200102261506.f1QF6Y607763@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Sun, 25 Feb 2001 23:09:41 PST." <200102260709.f1Q79fq30005@earth.backplane.com> Date: Mon, 26 Feb 2001 09:06:34 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102260709.f1Q79fq30005@earth.backplane.com>, Matt Dillon writes: > The problem is a whole lot more complex then you think. Dealing with > overcommit is not simply counting mapped pages, there are all sorts > of issues involved. But the biggest gotcha is that putting in > overcommit protection will not actually save your system from > dying a terrible death. No, but it may allow me to stop and save some work and then gracefully suicide, rather than being segfaulted. I have seen plenty of designs which are able to say "give me another 32MB of memory. Oh, you can't? Okay, I'll do this the other way." Most importantly, though, I would rather be able to save my work and *THEN* abort because there's insufficient memory. Let's compare FreeBSD's handling of this situation to the handling we get under one of the most unstable pieces of crap imaginable: MacOS. When I run out of memory on my Mac, you know what happens? I get little warning boxes saying there isn't enough memory to complete a given operation. Almost all the time, I am then allowed to continue *using* the applications I have open. Indeed, the application which *gave* me the error message is still able to run... long enough for me to save my work and close a few windows. Apparently, the "desirable" behavior under FreeBSD would be for the application to believe it had memory, then suddenly abort without warning, and with no chance to save my work. >It in fact makes it *more* likely that the > system will die a horrible death, because with overcommit protection > you wind up pre-reserving resources that would otherwise be reserved on > demand (and often might not ever be used by the programs mapping > those resources). Sure. But I want to know *UP FRONT* when I have problems. If I am trying to allocate too much memory, for God's sake, *TELL ME*. Give me warnings and errors. Make my program thrash, so I start wondering where the swap space went, and I can try to fix the problem, but don't just randomly kill processes that may or may not have done anything "wrong". >Not only that, but overcommit protection does not > protect you from thrashing, and quite often the system will become > unusable long before it actually runs out of memory+swap. I am okay with saving my work slowly. I am not okay with not saving my work. > A simple example of this is mmap(... PROT_READ|PROT_WRITE, MAP_PRIVATE), I am not sure that any promises have ever been made about the stability of mmap()'d memory. :) > So before you get into tring to 'protect' yourself by implementing > overcommit protection, you need to think long and hard on what you > are actually protecting yourself from... and what you aren't. People > seem to believe that edge cases such as allocating memory and then > the system faulting the process later because it couldn't allocate the > actual backing store later is of paramount importance but they seem > to forget that by the time you reach that situation, you are generally > already past the point of no return. This is quite possibly the case. On the other hand, in theory, the system could limit the total number of dirtyable pages such that it has a guarantee of enough space to swap... or at least promise to only kill programs that haven't had the "don't kill me" flag set. There are real applications, if only a few, where this would make a substantial difference. There are lots where it would at least provide warm fuzzies, and a checkbox conformance item that some one may have specified. >Overcommit protection doesn't > even come close to being able to prevent your system from getting > into an unrecoverable situation and it certainly is no substitute for > writing the software correctly (such that the memory failure can't > occur in the first place). Unfortunately, as has been made abundantly clear, you can't write software such that a memory failure can't occur in the first place. If someone else writes a program that allocates a giant chunk of memory, then slowly goes through dirtying pages, it is quite likely that a correctly written program will eventually be killed. If, indeed, FreeBSD might also kill a program for dirtying bss space, you can't write *ANY* program "correctly"; you can always get a SIGSEGV for accessing an object that was in no way distinguishable from an object you have permission to access. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 7:17: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from num1sun.intercore.com (num1sun.intercore.com [199.181.243.1]) by hub.freebsd.org (Postfix) with ESMTP id 9C25037B4EC for ; Mon, 26 Feb 2001 07:16:43 -0800 (PST) (envelope-from robin@num1sun.intercore.com) Received: (from robin@localhost) by num1sun.intercore.com (8.11.2/8.11.2) id f1QFAa718770; Mon, 26 Feb 2001 10:10:36 -0500 (EST) Date: Mon, 26 Feb 2001 10:10:35 -0500 From: Robin Cutshaw To: Peter Wemm Cc: Robin Cutshaw , freebsd-hackers@FreeBSD.ORG Subject: Re: Build timings - FreeBSD 4.2 vs. Linux Message-ID: <20010226101035.A18698@intercore.com> References: <20010221090207.A11473@intercore.com> <200102211844.f1LIigf26743@mobile.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102211844.f1LIigf26743@mobile.wemm.org>; from peter@netplex.com.au on Wed, Feb 21, 2001 at 10:44:42AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Feb 21, 2001 at 10:44:42AM -0800, Peter Wemm wrote: > > > > There's a problem here. I tried to configure an SMP kernel but when it > > booted the fxp0 (Compaq dual eepro100 adapter) got timeout errors and > > wouldn't work. I went back and did the config/make on the GENERIC > > kernel and booted it. Same thing. The stock GENERIC kernel that came > > with the dist works just fine. Any ideas? > > > > One other problem I've seen with the Compaq 8500 system. FreeBSD doesn't > > see the pci adapter on the secondary bus. I had to move the ethernet > > adapter to the primary bus for it to work. > > Perhaps the output of 'pciconf -l' and mptable(8) would be useful. > dmesg also, after a verbose boot (boot -v at the loader). > I did a little more research. The GENERIC kernel works fine, even when rebuilt. If I uncomment SMP/APIC, the kernel doesn't work with the ethernet card. It looks like interrupts aren't being processed. Also, it looks like 4.2 is not scanning the complete PCI bus. Here's the output from pciconf: pcib3@pci0:1:0: class=0x060400 card=0x000000dc chip=0x00261011 rev=0x05 hdr=0x01 none0@pci0:11:0: class=0x080400 card=0xa2f80e11 chip=0xa0f70e11 rev=0x11 hdr=0x00 none1@pci0:12:0: class=0x088000 card=0xb0f30e11 chip=0xa0f00e11 rev=0x00 hdr=0x00 none2@pci0:13:0: class=0x030000 card=0x47561002 chip=0x47561002 rev=0x7a hdr=0x00 ida0@pci0:14:0: class=0x010400 card=0x40400e11 chip=0x00101000 rev=0x02 hdr=0x00 isab0@pci0:15:0: class=0x060100 card=0x02001166 chip=0x02001166 rev=0x4d hdr=0x00 none3@pci0:20:0: class=0x050000 card=0x00000000 chip=0x1117118c rev=0x05 hdr=0x00 none4@pci0:20:1: class=0x050000 card=0x00000000 chip=0x1117118c rev=0x05 hdr=0x00 chip0@pci0:25:0: class=0x060000 card=0x00000000 chip=0x60100e11 rev=0x01 hdr=0x00 chip1@pci0:26:0: class=0x060000 card=0x00000000 chip=0x60100e11 rev=0x01 hdr=0x00 chip2@pci0:27:0: class=0x060000 card=0x00000000 chip=0x60100e11 rev=0x01 hdr=0x00 fxp0@pci1:4:0: class=0x020000 card=0xb0dd0e11 chip=0x12298086 rev=0x05 hdr=0x00 fxp1@pci1:5:0: class=0x020000 card=0xb0dd0e11 chip=0x12298086 rev=0x05 hdr=0x00 Here's the output from scanpci (a little program that I wrote for XFree86): pci bus 0x0 cardnum 0x01 function 0x0000: vendor 0x1011 device 0x0026 Digital Device unknown pci bus 0x0 cardnum 0x0b function 0x0000: vendor 0x0e11 device 0xa0f7 Compaq Device unknown pci bus 0x0 cardnum 0x0c function 0x0000: vendor 0x0e11 device 0xa0f0 Compaq Device unknown pci bus 0x0 cardnum 0x0d function 0x0000: vendor 0x1002 device 0x4756 ATI Mach64 GV pci bus 0x0 cardnum 0x0e function 0x0000: vendor 0x1000 device 0x0010 NCR Device unknown pci bus 0x0 cardnum 0x0f function 0x0000: vendor 0x1166 device 0x0200 Device unknown pci bus 0x0 cardnum 0x14 function 0x0000: vendor 0x118c device 0x1117 Device unknown pci bus 0x0 cardnum 0x14 function 0x0001: vendor 0x118c device 0x1117 Device unknown pci bus 0x0 cardnum 0x19 function 0x0000: vendor 0x0e11 device 0x6010 Compaq Device unknown pci bus 0x0 cardnum 0x1a function 0x0000: vendor 0x0e11 device 0x6010 Compaq Device unknown pci bus 0x0 cardnum 0x1b function 0x0000: vendor 0x0e11 device 0x6010 Compaq Device unknown pci bus 0x1 cardnum 0x04 function 0x0000: vendor 0x8086 device 0x1229 Intel 82557/8/9 10/100MBit network controller pci bus 0x1 cardnum 0x05 function 0x0000: vendor 0x8086 device 0x1229 Intel 82557/8/9 10/100MBit network controller pci bus 0x5 cardnum 0x01 function 0x0000: vendor 0x1011 device 0x0026 Digital Device unknown pci bus 0x5 cardnum 0x0b function 0x0000: vendor 0x0e11 device 0xa0f7 Compaq Device unknown pci bus 0x6 cardnum 0x04 function 0x0000: vendor 0x8086 device 0x1229 Intel 82557/8/9 10/100MBit network controller pci bus 0x6 cardnum 0x05 function 0x0000: vendor 0x8086 device 0x1229 Intel 82557/8/9 10/100MBit network controller pci bus 0xd cardnum 0x0b function 0x0000: vendor 0x0e11 device 0xa0f7 Compaq Device unknown Note that the XFree86 3.3.6 version of scanpci stopped at bus 3 but this new version scans the complete bus. Here's the output from mptable (while running GENERIC): =============================================================================== MPTable, version 2.0.15 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f4fd0 signature: '_MP_' length: 16 bytes version: 1.4 checksum: 0x18 mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000ff485 signature: 'PCMP' base table length: 668 version: 1.4 checksum: 0x28 OEM ID: 'COMPAQ ' Product ID: 'PROLIANT ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 72 local APIC address: 0xfee00000 extended table length: 172 extended table checksum: 148 ------------------------------------------------------------------------------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 7 0x10 BSP, usable 6 10 1 0x387fbff 4 0x10 AP, usable 6 10 1 0x387fbff 5 0x10 AP, usable 6 10 1 0x387fbff 6 0x10 AP, usable 6 10 1 0x387fbff -- Bus: Bus ID Type 0 PCI 5 PCI 13 PCI 17 ISA -- I/O APICs: APIC ID Version State Address 8 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# INT active-lo level 0 14:A 8 24 INT active-lo level 0 14:B 8 24 INT active-lo level 5 1:A 8 20 INT active-lo level 5 1:C 8 20 INT active-lo level 5 1:B 8 20 INT active-lo level 5 1:D 8 20 INT active-lo level 5 2:A 8 19 INT active-lo level 5 2:B 8 19 INT active-lo level 5 2:C 8 19 INT active-lo level 5 2:D 8 19 INT active-lo level 5 3:A 8 18 INT active-lo level 5 3:C 8 18 INT active-lo level 5 3:B 8 18 INT active-lo level 5 3:D 8 18 INT active-lo level 5 4:A 8 17 INT active-lo level 5 4:C 8 17 INT active-lo level 5 4:B 8 17 INT active-lo level 5 4:D 8 17 INT active-lo level 5 5:A 8 16 INT active-lo level 5 5:C 8 16 INT active-lo level 5 5:B 8 16 INT active-lo level 5 5:D 8 16 INT active-lo level 5 6:A 8 31 INT active-lo level 5 6:C 8 31 INT active-lo level 5 6:B 8 31 INT active-lo level 5 6:D 8 31 INT active-lo level 0 1:A 8 23 INT active-lo level 0 1:C 8 23 INT active-lo level 0 1:B 8 23 INT active-lo level 0 1:D 8 23 INT active-lo level 0 2:A 8 22 INT active-lo level 0 2:C 8 22 INT active-lo level 0 2:B 8 22 INT active-lo level 0 2:D 8 22 INT active-lo level 0 3:A 8 21 INT active-lo level 0 3:C 8 21 INT active-lo level 0 3:B 8 21 INT active-lo level 0 3:D 8 21 INT active-lo level 13 1:A 8 30 INT active-lo level 13 1:C 8 30 INT active-lo level 13 1:B 8 29 INT active-lo level 13 1:D 8 29 INT active-lo level 13 2:A 8 28 INT active-lo level 13 2:C 8 28 INT active-lo level 13 2:B 8 28 INT active-lo level 13 2:D 8 28 INT active-lo level 0 11:A 8 26 INT active-lo level 5 11:A 8 26 INT active-lo level 13 11:A 8 26 INT active-hi edge 17 1 8 1 INT active-hi edge 17 0 8 2 INT active-hi edge 17 3 8 3 INT active-hi edge 17 4 8 4 INT active-hi edge 17 6 8 6 INT active-hi edge 17 7 8 7 INT active-hi edge 17 8 8 8 INT active-hi edge 17 12 8 12 INT active-lo level 17 13 8 13 INT active-hi edge 17 14 8 14 INT active-hi edge 17 15 8 15 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT conforms conforms 17 0 255 0 NMI conforms conforms 17 0 255 1 ------------------------------------------------------------------------------- MP Config Extended Table Entries: Extended Table HOSED! Robin -- ---- Robin Cutshaw internet: robin@interlabs.com robin@intercore.com Internet Labs, Inc. BellNet: 404-713-4000 robin@XFree86.Org XFree86 coreteam/board member "Time is just one damn thing after another" -- PBS/Nova ---- -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 7:36: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by hub.freebsd.org (Postfix) with ESMTP id 0976537B401 for ; Mon, 26 Feb 2001 07:36:01 -0800 (PST) (envelope-from scott@renfro.org) Received: from renfro.org (dynamic30.pm01.san-jose.best.com [209.24.164.30]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id HAA06628; Mon, 26 Feb 2001 07:33:57 -0800 (PST) Received: (from scott@localhost) by renfro.org (8.11.2/8.11.2) id f1QFY0604541; Mon, 26 Feb 2001 07:34:00 -0800 (PST) (envelope-from scott) Date: Mon, 26 Feb 2001 07:34:00 -0800 From: Scott Renfro To: Soren Schmidt Cc: Scott Renfro , freebsd-hackers@freebsd.org, Richard Johnson Subject: Re: ata-disk ioctl and atactl patch Message-ID: <20010226073400.A4517@bonsai.home.renfro.org> References: <20010225194120.A64003@bonsai.home.renfro.org> <200102260728.IAA43029@freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102260728.IAA43029@freebsd.dk>; from sos@freebsd.dk on Mon, Feb 26, 2001 at 08:28:56AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 26, 2001 at 08:28:56AM +0100, Soren Schmidt wrote: > > No its not safe at all, you risk trashing an already running command... Thanks for the feedback; that's exactly what I was concerned about. > Anyhow, I have an atacontrol thingy in the works for attach/detach, > raid control etc, etc, I'll try to merge this functionality into that > (the ioctl's will change etc, but the functionality is nice)... Great. thanks again, -scott -- Scott Renfro +1 650 906 9618 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 8: 0:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id EEED137B401 for ; Mon, 26 Feb 2001 08:00:49 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1QG0kh13031; Mon, 26 Feb 2001 11:00:47 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 26 Feb 2001 11:00:46 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Dima Dorfman Cc: hackers@freebsd.org Subject: Re: Inheriting the nodump flag In-Reply-To: <20010226091347.CD0073E02@bazooka.unixfreak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I won't have a chance to look at the patch below until later this week, but had two comments-- 1) This method of handling recursive nodump is far superior to any actual inheritence of the flag as part of file system operations, as currently no other file flags are inherited from the parent directory -- the only property that is inherited is the group. With ACLs, the parent's default ACL will also play a role in the new access ACL. In any case, there is no precedent for file flag inheritence. 2) Please run the patch by freebsd-audit -- there have been a fair number of vulnerabilities in the fts code in the past due to race conditions of various sorts, and it's important that any modifications be carefully scrutinized to prevent the reintroduction of vulnerabilites. However, the general idea sounds very useful, and something that I'd find applicable on a daily basis :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Mon, 26 Feb 2001, Dima Dorfman wrote: > Hello -hackers > > Some time ago, on -arch, phk proposed that the nodump flag should be > inherited (see 'inheriting the "nodump" flag ?' around Dec. 2000). > This was generally considered a good idea, however, the patch to the > kernel he proposed was thought an ugly hack. In addition, jeroen > pointed out that NetBSD had implemented this functionality the Right > Way(tm), in dump(8). > > Attached below is a port of NetBSD's patch to FreeBSD's dump(8). > dump's tree walker is a little weird, so the patch is a little more > complicated than calling fts_set with FTS_SKIP. For the technical > details of what it does, see: > http://lists.openresources.com/NetBSD/tech-kern/msg00453.html. > > I've been using this on two of my hosts for a while, and it works as > expected. Given the additional fact that NetBSD has had this for > almost two years, and that the patch below looks very similar to the > one they applied, I doubt it significantly breaks anything. > > Comments? > > Thanks in advance > > Dima Dorfman > dima@unixfreak.org > > > Index: traverse.c > =================================================================== > RCS file: /st/src/FreeBSD/src/sbin/dump/traverse.c,v > retrieving revision 1.11 > diff -u -r1.11 traverse.c > --- traverse.c 2000/04/14 06:14:59 1.11 > +++ traverse.c 2001/02/20 01:39:06 > @@ -74,9 +74,11 @@ > typedef long fsizeT; > #endif > > -static int dirindir __P((ino_t ino, daddr_t blkno, int level, long *size)); > +static int dirindir __P((ino_t ino, daddr_t blkno, int level, long *size, > + long *tapesize, int nodump)); > static void dmpindir __P((ino_t ino, daddr_t blk, int level, fsizeT *size)); > -static int searchdir __P((ino_t ino, daddr_t blkno, long size, long filesize)); > +static int searchdir __P((ino_t ino, daddr_t blkno, long size, long filesize, > + long *tapesize, int nodump)); > > /* > * This is an estimation of the number of TP_BSIZE blocks in the file. > @@ -152,10 +154,14 @@ > dp = getino(ino); > if ((mode = (dp->di_mode & IFMT)) == 0) > continue; > - SETINO(ino, usedinomap); > + /* > + * All dirs go in dumpdirmap; only inodes that are to > + * be dumped go in usedinomap and dumpinomap, however. > + */ > if (mode == IFDIR) > SETINO(ino, dumpdirmap); > if (WANTTODUMP(dp)) { > + SETINO(ino, usedinomap); > SETINO(ino, dumpinomap); > if (mode != IFREG && mode != IFDIR && mode != IFLNK) > *tapesize += 1; > @@ -192,9 +198,10 @@ > long *tapesize; > { > register struct dinode *dp; > - register int i, isdir; > + register int i, isdir, nodump; > register char *map; > register ino_t ino; > + struct dinode di; > long filesize; > int ret, change = 0; > > @@ -204,24 +211,34 @@ > isdir = *map++; > else > isdir >>= 1; > - if ((isdir & 1) == 0 || TSTINO(ino, dumpinomap)) > + /* > + * If a directory has been removed from usedinomap, it > + * either has the nodump flag set, or has inherited > + * it. Although a directory can't be in dumpinomap if > + * it isn't in usedinomap, we have to go through it to > + * propogate the nodump flag. > + */ > + nodump = (TSTINO(ino, usedinomap) == 0); > + if ((isdir & 1) == 0 || (TSTINO(ino, dumpinomap) && !nodump)) > continue; > dp = getino(ino); > - filesize = dp->di_size; > + di = *dp; /* inode buf may change in searchdir(). */ > + filesize = di.di_size; > for (ret = 0, i = 0; filesize > 0 && i < NDADDR; i++) { > - if (dp->di_db[i] != 0) > - ret |= searchdir(ino, dp->di_db[i], > + if (di.di_db[i] != 0) > + ret |= searchdir(ino, di.di_db[i], > (long)dblksize(sblock, dp, i), > - filesize); > + filesize, tapesize, nodump); > if (ret & HASDUMPEDFILE) > filesize = 0; > else > filesize -= sblock->fs_bsize; > } > for (i = 0; filesize > 0 && i < NIADDR; i++) { > - if (dp->di_ib[i] == 0) > + if (di.di_ib[i] == 0) > continue; > - ret |= dirindir(ino, dp->di_ib[i], i, &filesize); > + ret |= dirindir(ino, di.di_ib[i], i, &filesize, > + tapesize, nodump); > } > if (ret & HASDUMPEDFILE) { > SETINO(ino, dumpinomap); > @@ -229,12 +246,15 @@ > change = 1; > continue; > } > - if ((ret & HASSUBDIRS) == 0) { > + if (nodump) { > + if (ret & HASSUBDIRS) > + change = 1; /* subdirs inherit nodump */ > + CLRINO(ino, dumpdirmap); > + } else if ((ret & HASSUBDIRS) == 0) > if (!TSTINO(ino, dumpinomap)) { > CLRINO(ino, dumpdirmap); > change = 1; > } > - } > } > return (change); > } > @@ -245,11 +265,13 @@ > * require the directory to be dumped. > */ > static int > -dirindir(ino, blkno, ind_level, filesize) > +dirindir(ino, blkno, ind_level, filesize, tapesize, nodump) > ino_t ino; > daddr_t blkno; > int ind_level; > long *filesize; > + long *tapesize; > + int nodump; > { > int ret = 0; > register int i; > @@ -261,7 +283,7 @@ > blkno = idblk[i]; > if (blkno != 0) > ret |= searchdir(ino, blkno, sblock->fs_bsize, > - *filesize); > + *filesize, tapesize, nodump); > if (ret & HASDUMPEDFILE) > *filesize = 0; > else > @@ -273,7 +295,8 @@ > for (i = 0; *filesize > 0 && i < NINDIR(sblock); i++) { > blkno = idblk[i]; > if (blkno != 0) > - ret |= dirindir(ino, blkno, ind_level, filesize); > + ret |= dirindir(ino, blkno, ind_level, filesize, > + tapesize, nodump); > } > return (ret); > } > @@ -284,13 +307,16 @@ > * contains any subdirectories. > */ > static int > -searchdir(ino, blkno, size, filesize) > +searchdir(ino, blkno, size, filesize, tapesize, nodump) > ino_t ino; > daddr_t blkno; > register long size; > long filesize; > + long *tapesize; > + int nodump; > { > register struct direct *dp; > + register struct dinode *ip; > register long loc, ret = 0; > char dblk[MAXBSIZE]; > > @@ -311,16 +337,30 @@ > continue; > if (dp->d_name[1] == '.' && dp->d_name[2] == '\0') > continue; > - } > - if (TSTINO(dp->d_ino, dumpinomap)) { > - ret |= HASDUMPEDFILE; > - if (ret & HASSUBDIRS) > - break; > } > - if (TSTINO(dp->d_ino, dumpdirmap)) { > - ret |= HASSUBDIRS; > - if (ret & HASDUMPEDFILE) > - break; > + if (nodump) { > + ip = getino(dp->d_ino); > + if (TSTINO(dp->d_ino, dumpinomap)) { > + CLRINO(dp->d_ino, dumpinomap); > + CLRINO(dp->d_ino, usedinomap); > + *tapesize -= blockest(ip); > + } > + /* Add back to dumpdirmap to propogate nodump. */ > + if ((ip->di_mode & IFMT) == IFDIR) { > + SETINO(dp->d_ino, dumpdirmap); > + ret |= HASSUBDIRS; > + } > + } else { > + if (TSTINO(dp->d_ino, dumpinomap)) { > + ret |= HASDUMPEDFILE; > + if (ret & HASSUBDIRS) > + break; > + } > + if (TSTINO(dp->d_ino, dumpdirmap)) { > + ret |= HASSUBDIRS; > + if (ret & HASDUMPEDFILE) > + break; > + } > } > } > return (ret); > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 8:26:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from brutus.conectiva.com.br (brutus.conectiva.com.br [200.250.58.146]) by hub.freebsd.org (Postfix) with ESMTP id 319D537B503 for ; Mon, 26 Feb 2001 08:26:48 -0800 (PST) (envelope-from riel@conectiva.com.br) Received: from localhost (riel@localhost) by brutus.conectiva.com.br (8.11.2/8.11.2) with ESMTP id f1QGQQt15969; Mon, 26 Feb 2001 13:26:28 -0300 X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs Date: Mon, 26 Feb 2001 13:26:26 -0300 (BRST) From: Rik van Riel X-X-Sender: To: Peter Seebach Cc: Subject: Re: Setting memory allocators for library functions. In-Reply-To: <200102242128.f1OLS2619633@guild.plethora.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 24 Feb 2001, Peter Seebach wrote: > In message <9820.983050024@critter>, Poul-Henning Kamp writes: > >I think there is a language thing you don't understand here. > > No, I just disagree. It is useful for the OS to provide a hook for > memory which is *known to work* - and that is the environment C specifies. Send patches. Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 8:27:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id A9E0C37B401 for ; Mon, 26 Feb 2001 08:27:31 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1QGRU610388 for ; Mon, 26 Feb 2001 10:27:30 -0600 (CST) Message-Id: <200102261627.f1QGRU610388@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Mon, 26 Feb 2001 13:26:26 -0300." Date: Mon, 26 Feb 2001 10:27:30 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Rik van Riel writes: >> No, I just disagree. It is useful for the OS to provide a hook for >> memory which is *known to work* - and that is the environment C specifies. >Send patches. I may some day. It's not very high on my priority list; I'd probably try to fix UVM first. :) -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 8:51:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from k9.rose.nu (adsl-63-196-10-163.dsl.snfc21.pacbell.net [63.196.10.163]) by hub.freebsd.org (Postfix) with ESMTP id E514137B503 for ; Mon, 26 Feb 2001 08:51:18 -0800 (PST) (envelope-from rose@rose.nu) Received: from localhost (rose@localhost) by k9.rose.nu (8.9.2/8.9.2) with ESMTP id IAA64603; Mon, 26 Feb 2001 08:50:08 -0800 (PST) (envelope-from rose@k9.rose.nu) Date: Mon, 26 Feb 2001 08:50:08 -0800 (PST) From: Stephen Rose To: Soren Schmidt Cc: freebsd-hackers@FreeBSD.ORG, Joe Gleason Subject: Re: ata-disk ioctl and atactl patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A couple of us on the questions list have asked for a way to spin down ide disks when idle. Is there any chance that this utility could lead to something useful there? Steve Rose It seems Scott Renfro wrote: > As I promised on -mobile earlier this week, I've cleaned up my patches > to port the {Net,Open}BSD atactl utility, including a simplistic > ata-disk ioctl. They apply cleanly against this afternoon's -stable > (including Soren's latest commit bringing -stable up to date with > -current). I've been running them for some time and they ''work great > here''. > > Before announcing this in a broader context, I wanted to get a bit of > feedback on the ioctl implementation. In particular, is it safe to > just do an ata_command inside adioctl() without any further checking? > (e.g., can this cause bad things to happen under heavy i/o load?) No its not safe at all, you risk trashing an already running command... Anyhow, I have an atacontrol thingy in the works for attach/detach, raid control etc, etc, I'll try to merge this functionality into that (the ioctl's will change etc, but the functionality is nice)... -S?ren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message --- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 9:19:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id EB25437B4EC for ; Mon, 26 Feb 2001 09:19:20 -0800 (PST) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id KAA29895; Mon, 26 Feb 2001 10:19:03 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id KAA20617; Mon, 26 Feb 2001 10:19:02 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15002.36869.925599.285850@nomad.yogotech.com> Date: Mon, 26 Feb 2001 10:19:01 -0700 (MST) To: Archie Cobbs Cc: Warner Losh , Peter Seebach , freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. In-Reply-To: <200102260529.f1Q5T8413011@curve.dellroad.org> References: <200102252201.f1PM1fY00967@billy-club.village.org> <200102260529.f1Q5T8413011@curve.dellroad.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ Memory overcommit ] > One important way to gain confidence that you're little box won't > silently crash at the worst possible time for the customer is to > be able to *prove* to yourself that it can't happen, given certain > assumptions. Those assumptions usually include things like "the > hardware is working properly" (e.g., no ECC errors) and "the compiler > compiled my C code correctly". > > Given these basic assumptions, you go through and check that you've > properly handled every possible case of input (malicious or otherwise) > from the outside world. Part of the "proof" is verifying that you've > checked all of your malloc(3) return values for NULL.. and assuming > that if malloc(3) returns != NULL, then the memory is really there. > > Now, if malloc can return NULL and the memory *not* really be there, ^^^ I assume you meant 'can't' here, right? > there is simply no way to prove that your code is not going to crash. Even in this case, there's no way to prove your code is not going to crash. The kernel has bugs, your software will have bugs (unless you've proved that it doesn't, and doing so on any significant piece of software will probably take longer to do than the amount of time you've spent writing and debugging it). And, what's to say that your correctly working software won't go bad right in the middle of your program running. There is no such thing as 100% fool-proof. > This memory overcommit thing is the only case that I can think of > where this happens, given the basic assumptions of correctly > functioning hardware, etc. That is why it's especially annoying to > (some) people. If you need 99.9999999% fool-proof, memory-overcommit can be one of the many classes of problems that bite you. However, in embededed systems, most folks design the system with particular software in mind. Therefore, you know ahead of time how much memory should be used, and can plan for how much memory is needed (overcommit or not) in your hardware design. (We're doing this right now in our 3rd generation product at work.) If the amount of memory is unknown (because of changing load conditions, and/or lack-of-experience with newer hardware), then overcommit *can* allow you to actually run 'better' than a non-overcommit system, though it doesn't necessarily give you the same kind of predictability when you 'hit the wall' like a non-overcommit system will do. Our embedded OS doesn't do memory-overcommit, but sometimes I wish it did, because it would give us some things for free. However, *IF* it did, we'd need some sort of mechanism (ie; AIX's SIGDANGER) that memory was getting tight, so the application could start dumping unused memory, or at least have an idea that something bad was happening so it could attempt to cleanup before it got whacked. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 9:23:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id 29C9C37B4EC for ; Mon, 26 Feb 2001 09:23:08 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1QHN6613015 for ; Mon, 26 Feb 2001 11:23:07 -0600 (CST) Message-Id: <200102261723.f1QHN6613015@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Mon, 26 Feb 2001 10:19:01 MST." <15002.36869.925599.285850@nomad.yogotech.com> Date: Mon, 26 Feb 2001 11:23:06 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <15002.36869.925599.285850@nomad.yogotech.com>, Nate Williams writes : >Even in this case, there's no way to prove your code is not going to >crash. Sure. But you can at least prove that all crashes are the result of bugs, not merely design "features". From the point of view of proving that a system is designed correctly, memory overcommit is a "bug". ;) -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 9:29:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from Samizdat.uucom.com (samizdat.uucom.com [198.202.217.54]) by hub.freebsd.org (Postfix) with ESMTP id DA94037B491 for ; Mon, 26 Feb 2001 09:29:15 -0800 (PST) (envelope-from cshenton@OutBounderInc.com) Received: (from cshenton@localhost) by Samizdat.uucom.com (8.9.3/8.9.3) id MAA14996; Mon, 26 Feb 2001 12:29:08 -0500 (EST) To: wes peters Cc: hackers@freebsd.org Subject: ThinkNIC booting FreeBSD? [WAS: Re: Silent FreeBSD] Message-ID: <3A4CC308.9A3F092C@softweyr.com> References: <3A4B7498.267D52E8@softweyr.com> <005801c07037$47ae6ea0$0402010a@biohz.net> <200012281812.LAA95895@harmony.village.org> From: Chris Shenton Date: 26 Feb 2001 12:29:08 -0500 Lines: 25 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3A4B7498.267D52E8@softweyr.com> Wes Peters writes: > We have several NIC's around here (the New Internet Computer, see > http://www.thinknic.com/ for details) and will be adding a couple of these > so we can boot FreeBSD or NetBSD on them in the next little while. A NIC > running FreeBSD on a silent CF disk strikes me as an ideal bedroom computer; > you can leave it on all the time and just let the screen sleep when you're > not using it. Been thinking seriously about buying a couple of these; hard to beat the $200 price point. Chat on one of the NIC lists indicates they had two fans and will now ship with three fans; this seems like it will make it rather noisey -- especially since they're diskless and should be quiet. Since I prefer FreeBSD to Linux, I'd rather run BSD than the Linux on the CD it runs from. Is it possible to create an ISO of a bootable and runnable FreeBSD? What happens with stuff like /tmp and /var/log? Failing this, I'd probably net-boot the NICs off a bigger FreeBSD machine, and NFS mount /home dirs and /usr/local type of software. That way when I built a tool or package it would be available to any of the FreeBSD boxes in the house. Seems like a great bang/buck ratio. Any comments on this approach? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 9:37:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id E580637B503 for ; Mon, 26 Feb 2001 09:37:46 -0800 (PST) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id KAA00301; Mon, 26 Feb 2001 10:37:44 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id KAA20690; Mon, 26 Feb 2001 10:37:43 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15002.37991.500583.137739@nomad.yogotech.com> Date: Mon, 26 Feb 2001 10:37:43 -0700 (MST) To: seebs@plethora.net (Peter Seebach) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. In-Reply-To: <200102261723.f1QHN6613015@guild.plethora.net> References: <15002.36869.925599.285850@nomad.yogotech.com> <200102261723.f1QHN6613015@guild.plethora.net> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >Even in this case, there's no way to prove your code is not going to > >crash. > > Sure. But you can at least prove that all crashes are the result of bugs, > not merely design "features". 'Proving' something is correct is left as an excercise for the folks who have way too much time on their hand. At my previous job (SRI), we have folks who work full-time trying to prove algorithms. In general, proving out simple algorithms takes months, when the algorithm itself took 1-2 hours to design and write. Another thing is that crashes may have occurred because of invalid input, invalid output, valid but not expected input, etc... Again, memory overcommit is only *one* class of bugs that is avoided. The phrase "can't see the forest for the trees" jumps to mind. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 9:41: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id CC90A37B503 for ; Mon, 26 Feb 2001 09:41:05 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1QHf4619958 for ; Mon, 26 Feb 2001 11:41:04 -0600 (CST) Message-Id: <200102261741.f1QHf4619958@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Mon, 26 Feb 2001 10:37:43 MST." <15002.37991.500583.137739@nomad.yogotech.com> Date: Mon, 26 Feb 2001 11:41:04 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <15002.37991.500583.137739@nomad.yogotech.com>, Nate Williams writes : >Again, memory overcommit is only *one* class of bugs that is avoided. >The phrase "can't see the forest for the trees" jumps to mind. :) Sure, and likewise, bugs in libc are only one *class* of bugs we can avoid, but that doesn't mean we don't fix them. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 9:56:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id AD17F37B491 for ; Mon, 26 Feb 2001 09:56:07 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1QHtvr34064; Mon, 26 Feb 2001 09:55:57 -0800 (PST) (envelope-from dillon) Date: Mon, 26 Feb 2001 09:55:57 -0800 (PST) From: Matt Dillon Message-Id: <200102261755.f1QHtvr34064@earth.backplane.com> To: "Daniel C. Sobral" Cc: Archie Cobbs , Warner Losh , Peter Seebach , freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102260529.f1Q5T8413011@curve.dellroad.org> <200102260628.f1Q6SYX29811@earth.backplane.com> <3A9A0A9A.E4D31F97@newsguy.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Matt Dillon wrote: :> :.. :> the system runs out of memory, even *with* overcommit protection. :> In fact, all sorts of side effects occur even when the system :... : :That's an assumption. Ha. Right. Go through any piece of significant code and just see how much goes flying out the window because the code wants to simply assume things work. Then try coding conditionals all the way through to fix it... and don't forget you need to propogate the error condition back up the procedure chain too so the original caller knows why it failed. : :> There ain't no magic bullet here, folks. By the time you get a memory :> failure, even with no overcommit, it is far too late to save the day. : :Scientific computation. If, at one point, no more memory can be :allocated, you back off, save the present results, and try again later. This is irrelevant to the conversation. It has nothing to do with overcommit in the context it is being discussed. : :You assume too much. Quite a few of the more efficient garbage :collection algorithms depend on knowing when the memory has become full. This has nothing to do with overcommit in the context it is being discussed. In fact, this has nothing to do with OS memory management at all -- all garbage collected languages have their own infrastructure to determine when memory pressure requires collecting. :You keep allocating, and when malloc() returns NULL, *then* you run the :garbage collector, free some space, and try again. If malloc() doesn't :work, quite a few very efficient garbage collection algorithms become :impossible to implement. First, that's bullshit. Most garbage collection implementations require the memory 'size' to be hardwired. Second, that's bullshit because any program relying on that sort of operation had damn well better have its datasize limit set to something reasonable, or the garbage collector is going to run the system out of swap before it decides it needs to do a run through. :Just because *you* don't see how one thing can work, it doesn't mean it :can't work. As I have trivially shown above. You haven't shown anything above. Garbage collectors do not work that way and you really should know it. :Honestly, I think non-overcommit is a mistake and your approach is much :better, but it's not the only approach and there _are_ valid approaches :that depend on not overcommitting, and I really hate having to defend :non-overcommit against such bogus arguments. You've completely ignored the point that overcommit has nothing whatsoever to do with memory pressure. You are assuming that overcommit is some sort of magic bullet that will solve the memory pressure handling problem, and it is nothing of the sort. -Matt :Daniel C. Sobral (8-DCS) :dcs@newsguy.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 9:57: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id 10E5A37B401 for ; Mon, 26 Feb 2001 09:57:01 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.11.1/8.11.1) id f1QHsma18433; Mon, 26 Feb 2001 12:54:48 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200102261754.f1QHsma18433@hda.hda.com> Subject: Re: Setting memory allocators for library functions. In-Reply-To: <3A99F25A.B940BEE0@elischer.org> from Julian Elischer at "Feb 25, 2001 10:06:18 pm" To: Julian Elischer Date: Mon, 26 Feb 2001 12:54:44 -0500 (EST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I still think that in such a case it should be possible to > 'test the commitment' by touching all the allocated memory > while trapping page faults. and fault all your memory from > 'potential' to 'allocated'. As someone said. it is not sure which program > when you run out of swap, but I think you might be able to somehow > change this behaviour to "the program making the request" fails > (or gets a fault). > > You could allocate your memory. > trap faults. > touch all of the allocated memory. > if it faults, you can remap some file to that location to allow the > instruction to continue.. continue and abort the check.. > exit as needed, OR continue with secure knowledge that > all your memory is there. > Alternatively you could allocate your own on-disk swapspace for > a program by telling malloc to use a file for all your memory needs. I think the right way to implement this would be define a POSIX P1003.1 "mlockall(MCL_CURRENT|MCL_FUTURE)" along with a physical memory limit resource. I think this could be defined to give the requested malloc performance. This is defined to be not inherited so you'd still need to modify your program. I absolutely agree this is a can of worms, but this would be a way to proceed. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 9:59:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id BCC0F37B503 for ; Mon, 26 Feb 2001 09:59:45 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1QHxj606269 for ; Mon, 26 Feb 2001 11:59:45 -0600 (CST) Message-Id: <200102261759.f1QHxj606269@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Mon, 26 Feb 2001 09:55:57 PST." <200102261755.f1QHtvr34064@earth.backplane.com> Date: Mon, 26 Feb 2001 11:59:44 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102261755.f1QHtvr34064@earth.backplane.com>, Matt Dillon writes: > This has nothing to do with overcommit in the context it is being > discussed. In fact, this has nothing to do with OS memory management > at all -- all garbage collected languages have their own infrastructure > to determine when memory pressure requires collecting. I think we were talking about C, and there are reasonable GC implementations for C... that assume that they can detect an out-of-memory condition because malloc returns a null pointer. > First, that's bullshit. Most garbage collection implementations > require the memory 'size' to be hardwired. Second, that's bullshit > because any program relying on that sort of operation had damn well > better have its datasize limit set to something reasonable, or the > garbage collector is going to run the system out of swap before it > decides it needs to do a run through. Fair enough, other circumstances might *also* cause a scan... but the fact remains that a GC system will want to know when it's out of memory, and will want some kind of warning other than a segfault. > You've completely ignored the point that overcommit has nothing whatsoever > to do with memory pressure. You are assuming that overcommit is some > sort of magic bullet that will solve the memory pressure handling problem, > and it is nothing of the sort. No one has said it solves all the problems. It solves *one specific* problem; the problem that you don't get *ANY* warning, or *ANY* chance to do anything, if you actually run out of available memory. Even if it's a transient failure that will go away in five minutes. Even if all you need to do is an fwrite and an fclose. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 10: 6: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17]) by hub.freebsd.org (Postfix) with ESMTP id B85A437B503 for ; Mon, 26 Feb 2001 10:05:59 -0800 (PST) (envelope-from nsayer@quack.kfu.com) Received: from quack.kfu.com (beast.talarian.com [10.4.10.6] (may be forged)) by phobos.talarian.com (8.9.0/8.9.0) with ESMTP id KAA29913 for ; Mon, 26 Feb 2001 10:06:08 -0800 (PST) Message-ID: <3A9A9AFE.1080504@quack.kfu.com> Date: Mon, 26 Feb 2001 10:05:50 -0800 From: Nick Sayer User-Agent: Mozilla/5.0 (X11; U; FreeBSD 4.2-RELEASE i386; en-US; 0.8) Gecko/20010216 X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: 802.1q vlan patches for if_fxp Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A colleague of mine has reported the necessity of adding this patch to if_fxp.c to support 802.1q vlans. I must admit that I am not familiar enough with the vlan code to understand what good this does. This patch is against 4.1-RELEASE. If it is a good thing, I would like to add it to -current and MFC it back in time for 4.3. If it isn't, I'd like to tell my friend why. Thanks in advance. ------------------------------------------------------------------------ *** pci/if_fxp.c.orig Wed Jul 19 09:36:36 2000 --- pci/if_fxp.c Tue Aug 8 23:18:37 2000 *************** *** 52,57 **** --- 52,65 ---- #include + #include "vlan.h" + #if NVLAN > 0 + #include + #include + #include + #include + #endif + #if defined(__NetBSD__) #include *************** *** 417,422 **** --- 425,433 ---- ether_ifattach(ifp, enaddr); bpfattach(&sc->sc_ethercom.ec_if.if_bpf, ifp, DLT_EN10MB, sizeof(struct ether_header)); + #if NVLAN > 0 + ifp->if_data.ifi_hdrlen = sizeof(struct ether_vlan_header); + #endif /* * Add shutdown hook so that DMA is disabled prior to reboot. Not *************** *** 599,604 **** --- 610,618 ---- * Attach the interface. */ ether_ifattach(ifp, ETHER_BPF_SUPPORTED); + #if NVLAN > 0 + ifp->if_data.ifi_hdrlen = sizeof(struct ether_vlan_header); + #endif /* * Let the system queue as many packets as we have available * TX descriptors. *** modules/fxp/Makefile.orig Fri Jan 28 05:26:29 2000 --- modules/fxp/Makefile Tue Aug 8 23:28:25 2000 *************** *** 2,7 **** .PATH: ${.CURDIR}/../../pci KMOD = if_fxp ! SRCS = if_fxp.c opt_bdg.h device_if.h bus_if.h pci_if.h .include --- 2,11 ---- .PATH: ${.CURDIR}/../../pci KMOD = if_fxp ! SRCS = if_fxp.c opt_bdg.h vlan.h device_if.h bus_if.h pci_if.h ! CLEANFILES = vlan.h ! ! vlan.h: ! touch vlan.h .include To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 10:35:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 650FF37B65D for ; Mon, 26 Feb 2001 10:35:52 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p13-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.14]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id DAA07247; Tue, 27 Feb 2001 03:35:47 +0900 (JST) Message-ID: <3A9AA158.61669F11@newsguy.com> Date: Tue, 27 Feb 2001 03:32:56 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Peter Seebach Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102261457.f1QEva607692@guild.plethora.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Seebach wrote: > > It's odd that I see lots of people arguing for segfaults killing the process > accessing memory that has been "successfully" allocated, but no one arguing > for the process getting killed when it exceeds a disk quota. Disk quote is an artificial limit. If you remind each and every other time this discussion came up, you *can* set artificial memory limits, and that won't cause applications to be killed. But, of course, this particular solution you do not accept. Anyway, these are two very different situations, and comparing them is silly. If you want non-overcommit, code it and send the patches. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@kzinti.bsdconspiracy.net Acabou o hipismo-arte. Mas a desculpa brasileira mais ouvida em Sydney e' que nao tem mais cavalo bobo por ai'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 11:17:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 64EAA37B491 for ; Mon, 26 Feb 2001 11:17:17 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p13-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.14]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id EAA26049; Tue, 27 Feb 2001 04:17:00 +0900 (JST) Message-ID: <3A9AAB02.793A197A@newsguy.com> Date: Tue, 27 Feb 2001 04:14:10 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Matt Dillon Cc: Archie Cobbs , Warner Losh , Peter Seebach , freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102260529.f1Q5T8413011@curve.dellroad.org> <200102260628.f1Q6SYX29811@earth.backplane.com> <3A9A0A9A.E4D31F97@newsguy.com> <200102261755.f1QHtvr34064@earth.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote: > > :Matt Dillon wrote: > :> > :.. > :> the system runs out of memory, even *with* overcommit protection. > :> In fact, all sorts of side effects occur even when the system > :... > : > :That's an assumption. > > Ha. Right. Go through any piece of significant code and just see how > much goes flying out the window because the code wants to simply assume > things work. Then try coding conditionals all the way through to fix > it... and don't forget you need to propogate the error condition back > up the procedure chain too so the original caller knows why it failed. Perhaps you should re-acquaint yourself with exception handlers, as you seem to have forgotten them since you last worked with your C compiler. You know, the kind of thing where you can put a longjmp() in a proxy malloc(), and keep a setjmp() at the appropriate functional level so that if _any_ allocation fails down that path the whole function is cancelled? > : > :> There ain't no magic bullet here, folks. By the time you get a memory > :> failure, even with no overcommit, it is far too late to save the day. > : > :Scientific computation. If, at one point, no more memory can be > :allocated, you back off, save the present results, and try again later. > > This is irrelevant to the conversation. It has nothing to do with > overcommit in the context it is being discussed. It has everything to do with overcommit in the context it is being discussed. I might be mistaken on exactly who, but I think it was Peter Seebach himself who once complained about his scientific application dieing suddenly under out of memory conditions on FreeBSD, though working perfectly on Solaris. Said application allocated memory if possible, and, if not, saved temporary results and went do something else until more memory became available. Now, you say "By the time you get a memory failure, even with no overcommit, it is far too late to save the day". This example shows that, no, you are wrong, it is not far too late. It is possible, at this point, to deal with the lack of more memory. I'll give you one more example. Protocol validation. It is often impossible to test all possible permutations of a protocol's dialog, but being able to go as deep as possible on execution tree and then, when you go out of memory, giving up on that path, backing down and continuing elsewhere let you get a partial validation, which is not enough to prove a protocol is correct but might well be enough to prove it is incorrect. This is a real application, and one in which an out of memory condition is not only handled but even expected. > :You assume too much. Quite a few of the more efficient garbage > :collection algorithms depend on knowing when the memory has become full. > > This has nothing to do with overcommit in the context it is being > discussed. In fact, this has nothing to do with OS memory management > at all -- all garbage collected languages have their own infrastructure > to determine when memory pressure requires collecting. And, of course, those whose infrastructure depends on a malloc() returning NULL indicating the heap is full will not work on FreeBSD. (You do recall that many of these languages are written in C, don't you?) It has everything to do with overcommit. In this particular case, not only there _is_ something to do when the out of memory condition arise, but the very algorithm depends on it arising. And this is for some algorithms. Other algorithms require unbounded space for the collection but can handle out of memory conditions if they arise. > :You keep allocating, and when malloc() returns NULL, *then* you run the > :garbage collector, free some space, and try again. If malloc() doesn't > :work, quite a few very efficient garbage collection algorithms become > :impossible to implement. > > First, that's bullshit. Most garbage collection implementations > require the memory 'size' to be hardwired. Second, that's bullshit Garbage Collection: Algorithms for Automatic Memory Management, Richard Jones and Rafael Lins. Bullshit is what you just said. > because any program relying on that sort of operation had damn well > better have its datasize limit set to something reasonable, or the > garbage collector is going to run the system out of swap before it > decides it needs to do a run through. Yes, indeed that happens, and dealing with swapped out objects is one topic of study in gc algorithms. For some applications, it would result in trashing. For others, most of the swapped out pages consist entirely of garbage. > :Just because *you* don't see how one thing can work, it doesn't mean it > :can't work. As I have trivially shown above. > > You haven't shown anything above. Garbage collectors do not work that > way and you really should know it. You are obviously acquainted with an all too small subset of garbage collection algorithms. > :Honestly, I think non-overcommit is a mistake and your approach is much > :better, but it's not the only approach and there _are_ valid approaches > :that depend on not overcommitting, and I really hate having to defend > :non-overcommit against such bogus arguments. > > You've completely ignored the point that overcommit has nothing whatsoever > to do with memory pressure. You are assuming that overcommit is some > sort of magic bullet that will solve the memory pressure handling problem, > and it is nothing of the sort. Some applications *do* handle memory pressure, but they depend on being _told_ one is out of memory. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@kzinti.bsdconspiracy.net Acabou o hipismo-arte. Mas a desculpa brasileira mais ouvida em Sydney e' que nao tem mais cavalo bobo por ai'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 11:40:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id ED43937B401 for ; Mon, 26 Feb 2001 11:40:30 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1QJeJi38115; Mon, 26 Feb 2001 11:40:19 -0800 (PST) (envelope-from dillon) Date: Mon, 26 Feb 2001 11:40:19 -0800 (PST) From: Matt Dillon Message-Id: <200102261940.f1QJeJi38115@earth.backplane.com> To: "Daniel C. Sobral" Cc: Archie Cobbs , Warner Losh , Peter Seebach , freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102260529.f1Q5T8413011@curve.dellroad.org> <200102260628.f1Q6SYX29811@earth.backplane.com> <3A9A0A9A.E4D31F97@newsguy.com> <200102261755.f1QHtvr34064@earth.backplane.com> <3A9AAB02.793A197A@newsguy.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :... :> : :> :That's an assumption. :> :> Ha. Right. Go through any piece of significant code and just see how :> much goes flying out the window because the code wants to simply assume :> things work. Then try coding conditionals all the way through to fix :> it... and don't forget you need to propogate the error condition back :> up the procedure chain too so the original caller knows why it failed. : :Perhaps you should re-acquaint yourself with exception :handlers, as you seem to have forgotten them since you last worked with :your C compiler. You know, the kind of thing where you can put a :longjmp() in a proxy malloc(), and keep a setjmp() at the appropriate :functional level so that if _any_ allocation fails down that path the :whole function is cancelled? ... just try *proving* that sort of code. Good luck! I'm trying to imagine how to QA code that tries to deal with memory failures at any point and uses longjump, and I'm failing. :It has everything to do with overcommit in the context it is being :discussed. I might be mistaken on exactly who, but I think it was Peter :Seebach himself who once complained about his scientific application :dieing suddenly under out of memory conditions on FreeBSD, though :working perfectly on Solaris. Said application allocated memory if :possible, and, if not, saved temporary results and went do something :else until more memory became available. Said application was poorly written, then. Even on solaris if you actually run the system out of memory you can blow up other unrelated processes. To depend on that sort of operation is just plain dumb. At *best*, even on solaris, you can set the datasize limit for the process and try to manage memory that way. It is still a bad idea though because there's a chance that any libc call you make inside your core code, even something is innocuous as a printf(), may fail. The proper way to manage memory with this sort of application is to specify a hard limit in the program itself, and have the program keep track of its own useage and save itself off if it hits the hard limit. Alternatively you can monitor system load and install a signal handler to cause the program to save itself off and exit if the load gets too high... something that will occur long before the system actually runs out of memory. :I'll give you one more example. Protocol validation. It is often :impossible to test all possible permutations of a protocol's dialog, but :being able to go as deep as possible on execution tree and then, when :you go out of memory, giving up on that path, backing down and :continuing elsewhere let you get a partial validation, which is not :enough to prove a protocol is correct but might well be enough to prove :it is incorrect. This is a real application, and one in which an out of :memory condition is not only handled but even expected. This has nothing to do with memory overcommit. Nothing at all. What is your definition of out-of-memory? When swap runs out, or when the system starts to thrash? What is the point of running a scientific calculation if the machine turns into a sludge pile and would otherwise cause the calculation to take years to complete instead of days? You've got a whole lot more issues to deal with then simple memory overcommit, and you are ignoring them completely. :And, of course, those whose infrastructure depends on a malloc() :returning NULL indicating the heap is full will not work on FreeBSD. :(You do recall that many of these languages are written in C, :don't you?) Bullshit. If you care, a simple wrapper will do what you want. Modern systems tend to have huge amounts of swap. Depending on malloc to fail with unbounded resources in an overcommit OR a non-overcommit case is stupid, because the system will be thrashing heavily long before it even gets to that point. Depending on malloc() to fail by setting an appropriate datasize limit resource is more reasonable, and malloc() does work as expected if you do that. :It has everything to do with overcommit. In this particular case, not :only there _is_ something to do when the out of memory condition arise, :but the very algorithm depends on it arising. It has nothing to do with overcommit. You are confusing overcommit with hard-datasize limits, which can be set with a simple 'limit' command. : :Garbage Collection: Algorithms for Automatic Memory Management, Richard :Jones and Rafael Lins. Bullshit is what you just said. None of which requires overcommit. None of which would actually work in a real-world situation with or without overcommit if you do not hard-limit the memory resource for the program in the first place. You are again making the mistake of assuming that not having overcommit will magically solve all your problems. It doesn't even come close. You think these garbage collection algorithms work by running the system out of VM and then backing off? That's pure nonsense. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 11:50:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id 1A4D937B491 for ; Mon, 26 Feb 2001 11:50:16 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1QJoE612168 for ; Mon, 26 Feb 2001 13:50:15 -0600 (CST) Message-Id: <200102261950.f1QJoE612168@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Tue, 27 Feb 2001 03:32:56 +0900." <3A9AA158.61669F11@newsguy.com> Date: Mon, 26 Feb 2001 13:50:14 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3A9AA158.61669F11@newsguy.com>, "Daniel C. Sobral" writes: >Anyway, these are two very different situations, and comparing them is >silly. They are situations in which an application can be killed and has no way to detect that it is about to do something wrong, and in which there *was* a correct way to notify the application of impending doom. Once we accept the argument "the C standard doesn't say this doesn't cause a segmentation fault", we can apply it to everything. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 11:53:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from brutus.conectiva.com.br (brutus.conectiva.com.br [200.250.58.146]) by hub.freebsd.org (Postfix) with ESMTP id D328A37B491 for ; Mon, 26 Feb 2001 11:53:44 -0800 (PST) (envelope-from riel@conectiva.com.br) Received: from localhost (riel@localhost) by brutus.conectiva.com.br (8.11.2/8.11.2) with ESMTP id f1QJrN619146; Mon, 26 Feb 2001 16:53:24 -0300 X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs Date: Mon, 26 Feb 2001 16:53:23 -0300 (BRST) From: Rik van Riel X-X-Sender: To: Matt Dillon Cc: Peter Seebach , Subject: Re: Setting memory allocators for library functions. In-Reply-To: <200102260709.f1Q79fq30005@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 25 Feb 2001, Matt Dillon wrote: > The problem is a whole lot more complex then you think. Dealing with > overcommit is not simply counting mapped pages, there are all sorts > of issues involved. But the biggest gotcha is that putting in > overcommit protection will not actually save your system from > dying a terrible death. It in fact makes it *more* likely that the > system will die a horrible death, Indeed, but since a lot of the non-overcommit fans will not believe this, why not let them find out by themselves when they write a patch for it? And maybe, just maybe, they'll succeed in getting their idea of non-overcommit working with a patch which doesn't change dozens of places in the kernel and doesn't add any measurable overhead. (a while ago we had our yearly discussion on linux-kernel about this, after some time somebody showed up with code to do overcommit ... and, of course, the conclusion that it wouldn't work since he got to understand the problem better while writing the code ;)) regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 11:54:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from a.mx.everquick.net (a.mx.everquick.net [216.89.137.3]) by hub.freebsd.org (Postfix) with ESMTP id 3B3EC37B4EC for ; Mon, 26 Feb 2001 11:54:43 -0800 (PST) (envelope-from eddy+public+spam@noc.everquick.net) Received: from localhost (eddy@localhost) by a.mx.everquick.net (8.9.0/8.8.7) with ESMTP id TAA02189 for ; Mon, 26 Feb 2001 19:54:39 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Date: Mon, 26 Feb 2001 19:54:39 +0000 (GMT) From: "E.B. Dreger" To: freebsd-hackers@freebsd.org Subject: mmap() w/ MAP_STACK question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greetings, I'm interested in using mmap() with MAP_STACK. After writing a couple of test programs and looking at vm_map_insert() and vm_map_stack(), it appears that vm_map_stack() behaves as if MAP_FIXED were set. Why is this? I would like to allocate stack space without having to search for available blocks. Is there any harm in modifying vm_map_stack() to search for a free block, a la vm_map_insert()? I've not delved extensively into the kernel, and am asking before I tinker in new territory. :-) TIA, Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet / EternalCommerce Division E-Mail: eddy@everquick.net Phone: (316) 794-8922 --------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 11:56:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from brutus.conectiva.com.br (brutus.conectiva.com.br [200.250.58.146]) by hub.freebsd.org (Postfix) with ESMTP id 451AD37B4EC for ; Mon, 26 Feb 2001 11:56:52 -0800 (PST) (envelope-from riel@conectiva.com.br) Received: from localhost (riel@localhost) by brutus.conectiva.com.br (8.11.2/8.11.2) with ESMTP id f1QJt4219167; Mon, 26 Feb 2001 16:55:04 -0300 X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs Date: Mon, 26 Feb 2001 16:55:04 -0300 (BRST) From: Rik van Riel X-X-Sender: To: "Daniel C. Sobral" Cc: Matt Dillon , Archie Cobbs , Warner Losh , Peter Seebach , Subject: Re: Setting memory allocators for library functions. In-Reply-To: <3A9AAB02.793A197A@newsguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 27 Feb 2001, Daniel C. Sobral wrote: > Matt Dillon wrote: > > :Matt Dillon wrote: > > :> > > :.. > > :> the system runs out of memory, even *with* overcommit protection. > > :> In fact, all sorts of side effects occur even when the system > > :... > > : > > :That's an assumption. > > > > Ha. Right. Go through any piece of significant code and just see how > > much goes flying out the window because the code wants to simply assume > > things work. Then try coding conditionals all the way through to fix > > it... and don't forget you need to propogate the error condition back > > up the procedure chain too so the original caller knows why it failed. > > Perhaps you should re-acquaint yourself with exception > handlers, And just where are you going to grow the cache when the exception handler runs off the edge of the current stack page ? Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 12: 2:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id E1CF037B491 for ; Mon, 26 Feb 2001 12:02:27 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1QK2N612484 for ; Mon, 26 Feb 2001 14:02:25 -0600 (CST) Message-Id: <200102262002.f1QK2N612484@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Mon, 26 Feb 2001 16:53:23 -0300." Date: Mon, 26 Feb 2001 14:02:23 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , >And maybe, just maybe, they'll succeed in getting their >idea of non-overcommit working with a patch which doesn't >change dozens of places in the kernel and doesn't add >any measurable overhead. If it adds overhead, fine, make it a kernel option. :) Anyway, no, I'm not going to contribute code right now. If I get time to do this at all, I'll probably do it to UVM first. My main objection was to the claim that the C standard allows random segfaults. It doesn't. And yes, bad hardware is a conformance violation. :) -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 12:10:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 5142C37B491 for ; Mon, 26 Feb 2001 12:10:48 -0800 (PST) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.9.3/8.9.1) id VAA29823; Mon, 26 Feb 2001 21:10:43 +0100 (CET) (envelope-from sos) From: Soren Schmidt Message-Id: <200102262010.VAA29823@freebsd.dk> Subject: Re: ata-disk ioctl and atactl patch In-Reply-To: from Stephen Rose at "Feb 26, 2001 08:50:08 am" To: rose@rose.nu (Stephen Rose) Date: Mon, 26 Feb 2001 21:10:43 +0100 (CET) Cc: freebsd-hackers@FreeBSD.ORG, clash@tasam.com (Joe Gleason) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Stephen Rose wrote: > A couple of us on the questions list have asked for a way to spin down ide > disks when idle. Is there any chance that this utility could lead to > something useful there? Well, of cause it could, but I'm not sure I see the usefullness of the spindown at all, a spinup costs several units of idleness power, so you have to keep it spun down for long periods to make it worth the effort, and you wear significantly more on the mechanics this way too... > It seems Scott Renfro wrote: > > As I promised on -mobile earlier this week, I've cleaned up my patches > > to port the {Net,Open}BSD atactl utility, including a simplistic > > ata-disk ioctl. They apply cleanly against this afternoon's -stable > > (including Soren's latest commit bringing -stable up to date with > > -current). I've been running them for some time and they ''work great > > here''. > > > > Before announcing this in a broader context, I wanted to get a bit of > > feedback on the ioctl implementation. In particular, is it safe to > > just do an ata_command inside adioctl() without any further checking? > > (e.g., can this cause bad things to happen under heavy i/o load?) > > No its not safe at all, you risk trashing an already running command... > > Anyhow, I have an atacontrol thingy in the works for attach/detach, > raid control etc, etc, I'll try to merge this functionality into that > (the ioctl's will change etc, but the functionality is nice)... > > -S?ren > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > --- > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 12:39:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from search.sparks.net (search.sparks.net [208.5.188.60]) by hub.freebsd.org (Postfix) with ESMTP id E7FD937B491 for ; Mon, 26 Feb 2001 12:39:12 -0800 (PST) (envelope-from dmiller@sparks.net) Received: by search.sparks.net (Postfix, from userid 100) id 0E1EEDB2A; Mon, 26 Feb 2001 15:38:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by search.sparks.net (Postfix) with ESMTP id DDED3DB29 for ; Mon, 26 Feb 2001 15:38:35 -0500 (EST) Date: Mon, 26 Feb 2001 15:38:35 -0500 (EST) From: David Miller To: hackers@freebsd.org Subject: fast PCI + quad port ethernet? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does anyone have any real world experience with the upper performance end of freebsd based routers? Specifically, I'm wondering if the Znyx ZX374 card with its 66MHz bus is really worth twice the money of the adaptec Quartet64 board with a 33 MHz 64 bit bus. The intended mobo for it would be a tyan thunder/tiger LE with the ServerSet chipset. This mobo has dual independent fast 64 PCI busses. Any other advice for putting 16 fast ethernet ports on a FreeBSD box? Thanks, --- David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 12:58:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from akira.lanfear.com (akira.lanfear.com [208.12.11.174]) by hub.freebsd.org (Postfix) with ESMTP id F37AC37B401 for ; Mon, 26 Feb 2001 12:58:36 -0800 (PST) (envelope-from mwlist@lanfear.com) Received: from sapporo.lanfear.com (h-64-105-36-216.snvacaid.covad.net [64.105.36.216]) by akira.lanfear.com (8.9.3/8.9.3) with SMTP id MAA39009 for freebsd-hackers@freebsd.org; Mon, 26 Feb 2001 12:58:36 -0800 (PST) (envelope-from mwlist@lanfear.com) Date: Mon, 26 Feb 2001 12:58:36 -0800 (PST) From: Marc W Message-Id: <200102262058.MAA39009@akira.lanfear.com> To: freebsd-hackers@freebsd.org Subject: Is mkdir guaranteed to be 'atomic' ?? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Kiltdown 0.7 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi! i can never really tell if this alias is for discussions concerning development OF the FreeBSD OS or development ON the FreeBSD OS (or both), but I figure i'll risk the wrath of the anti-social and ask a coupla programming questions :-) is mkdir(3) guaranteed to be atomic? Thus, if I have two processes with a possible race condition, is mkdir(3) guaranteed to only work on one of them and return EEXIST on the other??? Are there filesystem type cases where this might not be the case (NFS being my main concern ....) thanks! marc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 12:58:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from akira.lanfear.com (akira.lanfear.com [208.12.11.174]) by hub.freebsd.org (Postfix) with ESMTP id 5854737B491 for ; Mon, 26 Feb 2001 12:58:37 -0800 (PST) (envelope-from mwlist@lanfear.com) Received: from sapporo.lanfear.com (h-64-105-36-216.snvacaid.covad.net [64.105.36.216]) by akira.lanfear.com (8.9.3/8.9.3) with SMTP id MAA39013 for freebsd-hackers@freebsd.org; Mon, 26 Feb 2001 12:58:36 -0800 (PST) (envelope-from mwlist@lanfear.com) Date: Mon, 26 Feb 2001 12:58:36 -0800 (PST) From: Marc W Message-Id: <200102262058.MAA39013@akira.lanfear.com> To: freebsd-hackers@freebsd.org Subject: Why does a named pipe (FIFO) give me my data twice ??? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Kiltdown 0.7 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hello! I've got a program that creates a named pipe, and then spawns a thread which sits in a loop: // error checking snipped. // while (1) { int fifo = open(fifoPath, O_RDONLY); // this blocks fprintf(stderr, "somebody opened the other end!\n"); read(fifo, buf, sizeof(buf)); fprintf(stderr, "got the following data: %s\n", buf); close(fifo); } i then have another instance of the same program do the following: fifo = open(fifoPath, O_WRONLY); write(fifo, buf, strlen(buf); now, the problem is that the first process succeeds suddenly for the open, reads the data, closes the fifo, and IMMEDIATELY SUCCEEDS THE open(2) again, reading in the same data. After that, all is as expected. Note that this doesn't happen ALL the time -- only about 80% of the time. Any idea why this would happen? Thanks! marc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 13: 8:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.vi.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with SMTP id 23CE137B491 for ; Mon, 26 Feb 2001 13:08:22 -0800 (PST) (envelope-from dphoenix@bravenet.com) Received: (qmail 31783 invoked by uid 1000); 26 Feb 2001 21:07:40 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 26 Feb 2001 21:07:40 -0000 Date: Mon, 26 Feb 2001 13:07:40 -0800 (PST) From: Dan Phoenix To: freebsd-hackers@FreeBSD.ORG Subject: apache In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Mon Feb 26 13:04:34 2001] [error] (54)Connection reset by peer: getsockname [Mon Feb 26 13:04:39 2001] [emerg] (9)Bad file descriptor: flock: LOCK_EX: Error getting accept lock. Exiting! [Mon Feb 26 13:04:39 2001] [alert] Child 777 returned a Fatal error... Apache is exiting! httpd in free(): warning: page is already free. anyone seen this before? i do have some things on nfs apache accesses.. Dan +------------------------------------------------------+ | BRAVENET WEB SERVICES | | dan@bravenet.com | | make installworld | | ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail | | ln -s /var/qmail/bin/newaliases /usr/sbin/newaliases | +______________________________________________________+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 13:15:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.vi.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with SMTP id D682537B401 for ; Mon, 26 Feb 2001 13:15:32 -0800 (PST) (envelope-from dphoenix@bravenet.com) Received: (qmail 23477 invoked by uid 1000); 26 Feb 2001 21:14:52 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 26 Feb 2001 21:14:52 -0000 Date: Mon, 26 Feb 2001 13:14:52 -0800 (PST) From: Dan Phoenix To: freebsd-hackers@FreeBSD.ORG Subject: Re: apache In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG httpd in free(): warning: recursive call. httpd in free(): warning: recursive call. httpd in free(): warning: recursive call. httpd in free(): warning: recursive call. httpd in free(): warning: recursive call. httpd in free(): warning: recursive call. httpd in free(): warning: recursive call. seeing that on 2 webservers that have highest cpu yet others are exactly the same with really low cpu's On Mon, 26 Feb 2001, Dan Phoenix wrote: > Date: Mon, 26 Feb 2001 13:07:40 -0800 (PST) > From: Dan Phoenix > To: freebsd-hackers@FreeBSD.ORG > Subject: apache > > > > > [Mon Feb 26 13:04:34 2001] [error] (54)Connection reset by > peer: getsockname > [Mon Feb 26 13:04:39 2001] [emerg] (9)Bad file > descriptor: flock: LOCK_EX: Error getting accept lock. Exiting! > [Mon Feb 26 13:04:39 2001] [alert] Child 777 returned a Fatal error... > Apache is exiting! > httpd in free(): warning: page is already free. > > > anyone seen this before? > i do have some things on nfs apache accesses.. > > > Dan > > +------------------------------------------------------+ > | BRAVENET WEB SERVICES | > | dan@bravenet.com | > | make installworld | > | ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail | > | ln -s /var/qmail/bin/newaliases /usr/sbin/newaliases | > +______________________________________________________+ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 13:36:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sabre.velocet.net (sabre.velocet.net [198.96.118.66]) by hub.freebsd.org (Postfix) with ESMTP id 105D337B4EC for ; Mon, 26 Feb 2001 13:36:07 -0800 (PST) (envelope-from dgilbert@office.tor.velocet.net) Received: from office.tor.velocet.net (trooper.velocet.net [204.138.45.2]) by sabre.velocet.net (Postfix) with ESMTP id C604E137F07; Sun, 25 Feb 2001 17:44:14 -0500 (EST) Received: (from dgilbert@localhost) by office.tor.velocet.net (8.11.2/8.9.3) id f1PMiDQ95320; Sun, 25 Feb 2001 17:44:13 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15001.35517.468307.915125@trooper.velocet.net> Date: Sun, 25 Feb 2001 17:44:13 -0500 (EST) To: Matt Dillon Cc: David Gilbert , Bernd Walter , freebsd-hackers@FreeBSD.ORG Subject: Re: [hackers] Re: Large MFS on NFS-swap? In-Reply-To: <200102251913.f1PJDAc15495@earth.backplane.com> References: <15000.8884.6165.759008@trooper.velocet.net> <20010225042933.A508@cicely5.cicely.de> <200102250644.f1P6iuL12016@earth.backplane.com> <15001.21129.307283.198917@trooper.velocet.net> <200102251913.f1PJDAc15495@earth.backplane.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Matt" == Matt Dillon writes: [... my newfw bomb deleted ...] Matt> Heh heh. Yes, newfs has some overflows inside it when you Matt> get that big. Also, you'll probably run out of swap just Matt> newfs'ing the metadata, you need to use a larger block size, Matt> large -c value, and a large bytes/inode (-i) value. But then, Matt> of course, you are likely to run out of swap trying to write out Matt> a large file even if you do manage to newfs it. Matt> I had a set of patches for newfs a year or two ago but never Matt> incorporated them. We'd have to do a run-through on newfs to Matt> get it to newfs a swap-backed (i.e. 4K/sector) 1TB filesystem. Matt> Actually, this brings up a good point. Drive storage is Matt> beginning to reach the limitations of FFS and our internal (512 Matt> byte/block) block numbering scheme. IBM is almost certain to Matt> come out with their 500GB hard drive sometime this year. We Matt> should probably do a bit of cleanup work to make sure that we Matt> can at least handle FFS's theoretical limitations for real. That and the availability of vinum and other raid solutions. You can always make multiple partitions for no good reason (other than filesystem limitations), but we were planning to put together a 1TB filesystem next month. From what you're telling me, I'd need larger block sizes to make this work? IMHO, we might reconsider that. With SAN-type designs, you're probably going to find the distribution of filesizes on multi-terrabyte filesystems that are shared by 100's of computers to be roughly the same as the filesize distributions on today's filesystems. Making the run for larger block sizes puts us in the same league as DOS. While it will stave off the wolves, it will only work for so long give Moore's law. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 13:48: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from chopper.Poohsticks.ORG (chopper.poohsticks.org [63.227.60.73]) by hub.freebsd.org (Postfix) with ESMTP id BC0C237B4EC for ; Mon, 26 Feb 2001 13:48:01 -0800 (PST) (envelope-from drew@chopper.Poohsticks.ORG) Received: from chopper.Poohsticks.ORG (drew@localhost.poohsticks.org [127.0.0.1]) by chopper.Poohsticks.ORG (8.10.1/8.10.1) with ESMTP id f1QLlon10675; Mon, 26 Feb 2001 14:47:50 -0700 Message-Id: <200102262147.f1QLlon10675@chopper.Poohsticks.ORG> To: Marc W Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Is mkdir guaranteed to be 'atomic' ?? In-reply-to: Your message of "Mon, 26 Feb 2001 12:58:36 PST." <200102262058.MAA39009@akira.lanfear.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10671.983224070.1@chopper.Poohsticks.ORG> Date: Mon, 26 Feb 2001 14:47:50 -0700 From: Drew Eckhardt Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102262058.MAA39009@akira.lanfear.com>, mwlist@lanfear.com writes : > is mkdir(3) guaranteed to be atomic? Yes. >Are there filesystem type cases where this might not be the case >(NFS being my main concern ....) No. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 13:55:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 915E537B503 for ; Mon, 26 Feb 2001 13:55:05 -0800 (PST) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id OAA04618; Mon, 26 Feb 2001 14:54:49 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id OAA27150; Mon, 26 Feb 2001 14:54:49 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15002.53416.901436.285883@nomad.yogotech.com> Date: Mon, 26 Feb 2001 14:54:48 -0700 (MST) To: Drew Eckhardt Cc: Marc W , freebsd-hackers@FreeBSD.ORG Subject: Re: Is mkdir guaranteed to be 'atomic' ?? In-Reply-To: <200102262147.f1QLlon10675@chopper.Poohsticks.ORG> References: <200102262058.MAA39009@akira.lanfear.com> <200102262147.f1QLlon10675@chopper.Poohsticks.ORG> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > is mkdir(3) guaranteed to be atomic? > > Yes. > > >Are there filesystem type cases where this might not be the case > >(NFS being my main concern ....) > > No. Yes. NFS doesn't guarantee atomicity, because it can't. If the mkdir call returns, you have no guarantee that the remote directory has been created (caching, errors, etc...) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 13:56:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from akira.lanfear.com (akira.lanfear.com [208.12.11.174]) by hub.freebsd.org (Postfix) with ESMTP id 6D53837B491 for ; Mon, 26 Feb 2001 13:56:50 -0800 (PST) (envelope-from mwlist@lanfear.com) Received: from sapporo.lanfear.com (h-64-105-36-216.snvacaid.covad.net [64.105.36.216]) by akira.lanfear.com (8.9.3/8.9.3) with SMTP id NAA39209; Mon, 26 Feb 2001 13:56:33 -0800 (PST) (envelope-from mwlist@lanfear.com) Date: Mon, 26 Feb 2001 13:56:33 -0800 (PST) From: Marc W Message-Id: <200102262156.NAA39209@akira.lanfear.com> To: , Drew Eckhardt Cc: Marc W , freebsd-hackers@FreeBSD.ORG Subject: Re: Is mkdir guaranteed to be 'atomic' ?? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Kiltdown 0.7 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ----------------------------- > From: Nate Williams > > >Are there filesystem type cases where this might not be the case > > >(NFS being my main concern ....) > > > > No. > > Yes. NFS doesn't guarantee atomicity, because it can't. If the mkdir > call returns, you have no guarantee that the remote directory has been > created (caching, errors, etc...) I can handle it if there is a case where both fail, but is there a case where both can SUCCEED ?? marc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 13:58: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id C567437B401 for ; Mon, 26 Feb 2001 13:57:57 -0800 (PST) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id OAA04689; Mon, 26 Feb 2001 14:57:54 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id OAA27201; Mon, 26 Feb 2001 14:57:53 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15002.53601.427628.963431@nomad.yogotech.com> Date: Mon, 26 Feb 2001 14:57:53 -0700 (MST) To: Marc W Cc: , Drew Eckhardt , freebsd-hackers@FreeBSD.ORG Subject: Re: Is mkdir guaranteed to be 'atomic' ?? In-Reply-To: <200102262156.NAA39209@akira.lanfear.com> References: <200102262156.NAA39209@akira.lanfear.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > >Are there filesystem type cases where this might not be the case > > > >(NFS being my main concern ....) > > > > > > No. > > > > Yes. NFS doesn't guarantee atomicity, because it can't. If the > mkdir > > call returns, you have no guarantee that the remote directory has > been > > created (caching, errors, etc...) > > I can handle it if there is a case where both fail, but is there a > case where both can SUCCEED ?? What do you mean 'both succeed'? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 14: 0: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (user-uinjtfm.biz.mindspring.com [165.121.245.246]) by hub.freebsd.org (Postfix) with ESMTP id A74FF37B401 for ; Mon, 26 Feb 2001 14:00:02 -0800 (PST) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.2/8.11.2) with ESMTP id f1QLxES01872; Mon, 26 Feb 2001 13:59:18 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200102262159.f1QLxES01872@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Drew Eckhardt Cc: Marc W , freebsd-hackers@FreeBSD.ORG Subject: Re: Is mkdir guaranteed to be 'atomic' ?? In-reply-to: Your message of "Mon, 26 Feb 2001 14:47:50 MST." <200102262147.f1QLlon10675@chopper.Poohsticks.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Feb 2001 13:59:14 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <200102262058.MAA39009@akira.lanfear.com>, mwlist@lanfear.com writes > : > > is mkdir(3) guaranteed to be atomic? > > Yes. Um. mkdir(2) is atomic. Note that mkdir(1) with the -p argument is *not* atomic. > >Are there filesystem type cases where this might not be the case > >(NFS being my main concern ....) > > No. How would it *not* be atomic? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 14: 1:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id 5104837B401 for ; Mon, 26 Feb 2001 14:01:31 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1QM1S620699 for ; Mon, 26 Feb 2001 16:01:28 -0600 (CST) Message-Id: <200102262201.f1QM1S620699@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Is mkdir guaranteed to be 'atomic' ?? In-reply-to: Your message of "Mon, 26 Feb 2001 13:59:14 PST." <200102262159.f1QLxES01872@mass.dis.org> Date: Mon, 26 Feb 2001 16:01:28 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102262159.f1QLxES01872@mass.dis.org>, Mike Smith writes: >How would it *not* be atomic? Well, imagine a hypothetical broken system in which two simultaneous calls to mkdir, on some hypothetical broken filesystem, can each think that it "succeeded". After all, at the end of the operation, the directory has been created, so who's to say they're wrong? ;) -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 14: 2:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from akira.lanfear.com (akira.lanfear.com [208.12.11.174]) by hub.freebsd.org (Postfix) with ESMTP id 0E42D37B4EC; Mon, 26 Feb 2001 14:02:13 -0800 (PST) (envelope-from mwlist@lanfear.com) Received: from sapporo.lanfear.com (h-64-105-36-216.snvacaid.covad.net [64.105.36.216]) by akira.lanfear.com (8.9.3/8.9.3) with SMTP id OAA39275; Mon, 26 Feb 2001 14:02:09 -0800 (PST) (envelope-from mwlist@lanfear.com) Date: Mon, 26 Feb 2001 14:02:09 -0800 (PST) From: Marc W Message-Id: <200102262202.OAA39275@akira.lanfear.com> To: , Marc W Cc: , Drew Eckhardt , freebsd-hackers@FreeBSD.ORG Subject: Re: Is mkdir guaranteed to be 'atomic' ?? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Kiltdown 0.7 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > I can handle it if there is a case where both fail, but is there a > > case where both can SUCCEED ?? > > What do you mean 'both succeed'? My understanding is that, on non-broken filesystems, calls to mkdir(2) either succeed by creating a new directory, or fail and return EEXIST (note: excluding all other types of errors :-)) However, NFS seems to have issues, so the question is: could both mkdir(2) calls actually succeed and claim to have created the same directory (even if it is?), or is one ALWAYS guaranteed to fail, as on a normal fs. marc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 14: 6: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id A17F237B491; Mon, 26 Feb 2001 14:05:57 -0800 (PST) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id PAA04856; Mon, 26 Feb 2001 15:05:46 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id PAA27291; Mon, 26 Feb 2001 15:05:45 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15002.54073.668155.728179@nomad.yogotech.com> Date: Mon, 26 Feb 2001 15:05:45 -0700 (MST) To: Marc W Cc: , , Drew Eckhardt , freebsd-hackers@FreeBSD.ORG Subject: Re: Is mkdir guaranteed to be 'atomic' ?? In-Reply-To: <200102262202.OAA39275@akira.lanfear.com> References: <200102262202.OAA39275@akira.lanfear.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > I can handle it if there is a case where both fail, but is > there a > > > case where both can SUCCEED ?? > > > > What do you mean 'both succeed'? > > My understanding is that, on non-broken filesystems, calls to > mkdir(2) either succeed by creating a new directory, or fail and return > EEXIST (note: excluding all other types of errors :-)) > > However, NFS seems to have issues, so the question is: could both > mkdir(2) calls actually succeed and claim to have created the same > directory (even if it is?), or is one ALWAYS guaranteed to fail, as on > a normal fs. You're implying that you are making two calls to create the same directory. Am I correct? The answer is 'maybe'? Depends on the remote NFS server. Matt or one of the other NFS gurus may know more, but I wouldn't count on *anything* over NFS. If you need atomicity, you need lockd, which isn't implemented on FreeBSD. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 14: 8:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from k9.rose.nu (adsl-63-196-10-163.dsl.snfc21.pacbell.net [63.196.10.163]) by hub.freebsd.org (Postfix) with ESMTP id A5D9C37B4EC for ; Mon, 26 Feb 2001 14:08:10 -0800 (PST) (envelope-from rose@rose.nu) Received: from localhost (rose@localhost) by k9.rose.nu (8.9.2/8.9.2) with ESMTP id OAA73917; Mon, 26 Feb 2001 14:06:43 -0800 (PST) (envelope-from rose@k9.rose.nu) Date: Mon, 26 Feb 2001 14:06:43 -0800 (PST) From: Stephen Rose To: Soren Schmidt Cc: freebsd-hackers@FreeBSD.ORG, Joe Gleason Subject: Re: ata-disk ioctl and atactl patch In-Reply-To: <200102262010.VAA29823@freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, for me it's the noise and heat that I'm trying to minimize. That and we're out of power here in California. :-) Steve Rose On Mon, 26 Feb 2001, Soren Schmidt wrote: > It seems Stephen Rose wrote: > > A couple of us on the questions list have asked for a way to spin down = ide > > disks when idle. Is there any chance that this utility could lead to > > something useful there? >=20 > Well, of cause it could, but I'm not sure I see the usefullness of > the spindown at all, a spinup costs several units of idleness power, > so you have to keep it spun down for long periods to make it worth > the effort, and you wear significantly more on the mechanics this > way too... >=20 > > It seems Scott Renfro wrote: > > > As I promised on -mobile earlier this week, I've cleaned up my patche= s > > > to port the {Net,Open}BSD atactl utility, including a simplistic > > > ata-disk ioctl. They apply cleanly against this afternoon's -stable > > > (including Soren's latest commit bringing -stable up to date with > > > -current). I've been running them for some time and they ''work grea= t > > > here''. > > > > > > Before announcing this in a broader context, I wanted to get a bit of > > > feedback on the ioctl implementation. In particular, is it safe to > > > just do an ata_command inside adioctl() without any further checking? > > > (e.g., can this cause bad things to happen under heavy i/o load?) > >=20 > > No its not safe at all, you risk trashing an already running command... > >=20 > > Anyhow, I have an atacontrol thingy in the works for attach/detach, > > raid control etc, etc, I'll try to merge this functionality into that > > (the ioctl's will change etc, but the functionality is nice)... > >=20 > > -S?ren > >=20 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > >=20 > > --- > >=20 > >=20 > >=20 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > >=20 >=20 >=20 > -S=F8ren >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 14: 8:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sabre.velocet.net (sabre.velocet.net [198.96.118.66]) by hub.freebsd.org (Postfix) with ESMTP id 9310837B401 for ; Mon, 26 Feb 2001 14:08:23 -0800 (PST) (envelope-from dgilbert@office.tor.velocet.net) Received: from office.tor.velocet.net (trooper.velocet.net [204.138.45.2]) by sabre.velocet.net (Postfix) with ESMTP id 291E1137F10; Sun, 25 Feb 2001 23:47:38 -0500 (EST) Received: (from dgilbert@localhost) by office.tor.velocet.net (8.11.2/8.9.3) id f1Q4lTB39909; Sun, 25 Feb 2001 23:47:29 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15001.57313.163670.146752@trooper.velocet.net> Date: Sun, 25 Feb 2001 23:47:29 -0500 (EST) To: "Daniel C. Sobral" Cc: Dag-Erling Smorgrav , Peter Seebach , freebsd-hackers@FreeBSD.ORG Subject: [hackers] Re: Setting memory allocators for library functions. In-Reply-To: <3A98F43E.FFC99867@newsguy.com> References: <200102242037.f1OKbd618343@guild.plethora.net> <3A98F43E.FFC99867@newsguy.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Daniel" == Daniel C Sobral writes: Daniel> Dag-Erling Smorgrav wrote: >> > > None of these solutions are portable, however; > Well, no, but >> the sole available definition of "portable" says that it is > >> "portable" to assume that all the memory malloc can return is >> really > available. >> >> Show me a modern OS (excluding real-time and/or embedded OSes) that >> makes this guarantee. Daniel> Solaris and AIX (on AIX this is optional on a global or Daniel> per-application level). IIRC, Digital-UNIX or OSF-1 ... or whatever it's called now. I seem to remember the first Alphas that arrived to a company I worked for had this set globally in the OS by default. Due to the bloat of the OS and Motif and other such things, they required simply amazing amounts of swap just to run. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 14:10:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (user-uinjtfm.biz.mindspring.com [165.121.245.246]) by hub.freebsd.org (Postfix) with ESMTP id B531837B491 for ; Mon, 26 Feb 2001 14:10:08 -0800 (PST) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.2/8.11.2) with ESMTP id f1QMAlS01993; Mon, 26 Feb 2001 14:10:51 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200102262210.f1QMAlS01993@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: seebs@plethora.net (Peter Seebach) Cc: freebsd-hackers@freebsd.org Subject: Re: Is mkdir guaranteed to be 'atomic' ?? In-reply-to: Your message of "Mon, 26 Feb 2001 16:01:28 CST." <200102262201.f1QM1S620699@guild.plethora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Feb 2001 14:10:47 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <200102262159.f1QLxES01872@mass.dis.org>, Mike Smith writes: > >How would it *not* be atomic? > > Well, imagine a hypothetical broken system in which two simultaneous calls > to mkdir, on some hypothetical broken filesystem, can each think that it > "succeeded". After all, at the end of the operation, the directory has > been created, so who's to say they're wrong? ;) Is this somehow related to memory overcommit? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 14:18:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from orthanc.ab.ca (207-167-15-66.dsl.worldgate.ca [207.167.15.66]) by hub.freebsd.org (Postfix) with ESMTP id A325037B4EC for ; Mon, 26 Feb 2001 14:18:51 -0800 (PST) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost [127.0.0.1]) by orthanc.ab.ca (8.11.2/8.11.2) with ESMTP id f1QMITq95167; Mon, 26 Feb 2001 15:18:29 -0700 (MST) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <200102262218.f1QMITq95167@orthanc.ab.ca> From: Lyndon Nerenberg Organization: The Frobozz Magic Homing Pigeon Company To: seebs@plethora.net (Peter Seebach) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Is mkdir guaranteed to be 'atomic' ?? In-reply-to: Your message of "Mon, 26 Feb 2001 16:01:28 CST." <200102262201.f1QM1S620699@guild.plethora.net> Date: Mon, 26 Feb 2001 15:18:29 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Peter" == Peter Seebach writes: Peter> Well, imagine a hypothetical broken system in which two Peter> simultaneous calls to mkdir, on some hypothetical broken Peter> filesystem, can each think that it "succeeded". After all, Peter> at the end of the operation, the directory has been Peter> created, so who's to say they're wrong? ;) "They" are :-) What if the two processes issuing mkdir() have a different effective [ug]id or umask? I.e. if I get success back I'm going to assume I own the directory, which has a 1/n chance of being wrong for for n processes with unique uids racing a non-atomic mkdir() call over (say) NFS. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 14:19: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from brutus.conectiva.com.br (brutus.conectiva.com.br [200.250.58.146]) by hub.freebsd.org (Postfix) with ESMTP id 6333837B401 for ; Mon, 26 Feb 2001 14:18:58 -0800 (PST) (envelope-from riel@conectiva.com.br) Received: from localhost (riel@localhost) by brutus.conectiva.com.br (8.11.2/8.11.2) with ESMTP id f1QMIwC21282; Mon, 26 Feb 2001 19:18:58 -0300 X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs Date: Mon, 26 Feb 2001 19:18:57 -0300 (BRST) From: Rik van Riel X-X-Sender: To: Peter Seebach Cc: Subject: Re: Setting memory allocators for library functions. In-Reply-To: <200102262002.f1QK2N612484@guild.plethora.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 26 Feb 2001, Peter Seebach wrote: > In message , > >And maybe, just maybe, they'll succeed in getting their > >idea of non-overcommit working with a patch which doesn't > >change dozens of places in the kernel and doesn't add > >any measurable overhead. > > If it adds overhead, fine, make it a kernel option. :) > > Anyway, no, I'm not going to contribute code right now. If I get time > to do this at all, I'll probably do it to UVM first. > > My main objection was to the claim that the C standard allows > random segfaults. It doesn't. And yes, bad hardware is a > conformance violation. :) I don't think a failed kernel-level allocation after overcommit should generate a segfault. IMHO it should send a bus error (or a sigkill if the process doesn't exit after the SIGBUS). Rationale: SIGSEGV for _user_ mistakes (process accesses wrong stuff) SIGBUS for _system_ errors (ECC error, kernel messes up, ...) cheers, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 14:21:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id 43C7137B401 for ; Mon, 26 Feb 2001 14:21:10 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1QML9621604 for ; Mon, 26 Feb 2001 16:21:09 -0600 (CST) Message-Id: <200102262221.f1QML9621604@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Mon, 26 Feb 2001 19:18:57 -0300." Date: Mon, 26 Feb 2001 16:21:09 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Rik van Riel writes: >I don't think a failed kernel-level allocation after overcommit >should generate a segfault. >IMHO it should send a bus error (or a sigkill if the process >doesn't exit after the SIGBUS). Same difference, so far as the language is concerned. >Rationale: >SIGSEGV for _user_ mistakes (process accesses wrong stuff) >SIGBUS for _system_ errors (ECC error, kernel messes up, ...) As long as we grant that it's the kernel *messing up*, I won't complain; no one said an implementation could be perfect, and known bugs go with the territory. I only object to attempts to portray it as a legitimate and correct implementation of the C spec. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 14:23:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id E027037B65D for ; Mon, 26 Feb 2001 14:23:42 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1QMNg621729 for ; Mon, 26 Feb 2001 16:23:42 -0600 (CST) Message-Id: <200102262223.f1QMNg621729@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Mon, 26 Feb 2001 19:18:57 -0300." Date: Mon, 26 Feb 2001 16:23:42 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Rik van Riel writes: >Rationale: >SIGSEGV for _user_ mistakes (process accesses wrong stuff) >SIGBUS for _system_ errors (ECC error, kernel messes up, ...) Actually, this is not canonically the distinction made. On a Unix PC, { int *a, c[2]; char *b; a = c; b = a; ++b; a = b; *a = 0; } would get SIGBUS, because it was a bus error. The error is not a segmentation fault; the memory written to is all legitimately available to the process. It is a bus error, because the data access is not possible on the bus. :) I think "the memory you thought you had actually doesn't exist anywhere" is more like a segmentation fault than a bus error. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 14:26:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id B6C9E37B491 for ; Mon, 26 Feb 2001 14:26:45 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1QMQBJ44997; Mon, 26 Feb 2001 14:26:11 -0800 (PST) (envelope-from dillon) Date: Mon, 26 Feb 2001 14:26:11 -0800 (PST) From: Matt Dillon Message-Id: <200102262226.f1QMQBJ44997@earth.backplane.com> To: Nate Williams Cc: Marc W , , Drew Eckhardt , freebsd-hackers@FreeBSD.ORG Subject: Re: Is mkdir guaranteed to be 'atomic' ?? References: <200102262202.OAA39275@akira.lanfear.com> <15002.54073.668155.728179@nomad.yogotech.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG (owner-freebsd-hackers removed from list) :You're implying that you are making two calls to create the same :directory. Am I correct? : :The answer is 'maybe'? Depends on the remote NFS server. Matt or one :of the other NFS gurus may know more, but I wouldn't count on *anything* :over NFS. If you need atomicity, you need lockd, which isn't :implemented on FreeBSD. : :Nate There are a couple of issues here. First, I'm fairly sure that the NFS server side implementation of mkdir() does *not* guarentee that the operation will be synced to permanent storage on the server side before returning. So if the NFS server crashes and reboots, the just-created directory could disappear. Second, in regards to several clients trying to mkdir() at the same time: mkdir() does not use the same semantics as an O_EXCL file create. This means that *normally* only one of the two clients will succeed in the mkdir() call. However, under certain circumstances (e.g. a server reboot or possibly packet loss / NFS retry) it is possible for the directory to be created yet for *both* client's mkdir() calls to *FAIL* (server reboot), or for *both* client's mkdir() calls to succeed (if one or both clients had packet loss and had to retry the request). Under NFSv3, the only thing that truely guarentees proper operation in regards to competing clients is an O_EXCL file open(). An O_EXCL file open() is guarenteed to succeed on precisely one client when multiple clients are trying to create the same file, and NFSv3 O_EXCL semantics guarentees that NFS retries and server reboots will still result in proper operation (the client doing the retry or the client that succeeded in the open() call will still see a 'success' even if the server reboots or if an NFS retry occurs). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 14:31:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gigi.excite.com (gigi.excite.com [199.172.152.110]) by hub.freebsd.org (Postfix) with ESMTP id 7492E37B491 for ; Mon, 26 Feb 2001 14:31:34 -0800 (PST) (envelope-from john_wilson100@excite.com) Received: from blizzard.excite.com ([199.172.148.158]) by gigi.excite.com (InterMail vM.4.01.02.39 201-229-119-122) with ESMTP id <20010226223134.BQJQ2736.gigi.excite.com@blizzard.excite.com>; Mon, 26 Feb 2001 14:31:34 -0800 Message-ID: <5173449.983226694087.JavaMail.imail@blizzard.excite.com> Date: Mon, 26 Feb 2001 14:31:33 -0800 (PST) From: John Wilson To: "Michael C . Wu" , John Wilson , "Michael C . Wu" , John Wilson , freebsd-hackers@freebsd.org Subject: Re: Converting Perforce to CVS Cc: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Excite Inbox X-Sender-Ip: 192.116.157.233 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG No, there isn't. They have a CVS to Perforce script, not Perforce to CVS (please don't ask who in their right mind would want to go from Perforce to CVS :) Well, if Anton doesn't respond, I guess I'll just have to write one myself... John On Sun, 25 Feb 2001 22:00:31 -0600, Michael C . Wu wrote: > On Sun, Feb 25, 2001 at 09:17:38AM -0800, John Wilson scribbled: > | If you still have the Perforce->CVS conversion script, I would be very > | grateful if you could e-mail it to me. > > Such a script is available for download on www.perforce.com. > > | On Tue, 9 Jan 2001 09:13:39 +0100, Anton Berezin wrote: > | > On Sat, Jan 06, 2001 at 03:06:20PM -0800, John Wilson wrote: > | > > I apologize in advance, as this is not strictly a FreeBSD-related > | question, > | > > but I know that a lot of FreeBSD'ers use CVS as well as Perforce, so > | here > | > > goes... > | > > > | > > What is the easiest way to convert a P4 source repository to CVS, while > | > > preserving revisions, history, log messages, etc? Both systems seem > | to use > | > > RCS, but is it as simple as copying the files? Are there any caveats? > | > | > > | > I have one script, but it does not handle branches (the project I was > | > converting did not have any). I can mail it to you if you want. The > | > branch handling should be rather similar to binary files handling, which > | > the script already performs. > > -- > +------------------------------------------------------------------+ > | keichii@peorth.iteration.net | keichii@bsdconspiracy.net | > | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | > +------------------------------------------------------------------+ _______________________________________________________ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 15: 2:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 0777337B401 for ; Mon, 26 Feb 2001 15:02:35 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1QN2Yt46234; Mon, 26 Feb 2001 15:02:34 -0800 (PST) (envelope-from dillon) Date: Mon, 26 Feb 2001 15:02:34 -0800 (PST) From: Matt Dillon Message-Id: <200102262302.f1QN2Yt46234@earth.backplane.com> To: Dan Phoenix Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: apache References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :httpd in free(): warning: recursive call. :httpd in free(): warning: recursive call. :httpd in free(): warning: recursive call. :httpd in free(): warning: recursive call. :httpd in free(): warning: recursive call. :httpd in free(): warning: recursive call. :httpd in free(): warning: recursive call. : :seeing that on 2 webservers that have highest cpu :yet others are exactly the same with really low cpu's This occurs if a signal occurs in the middle of a free() and the signal handler itself tries to do a free(). It is extremely illegal to do this... apache needs to be fixed. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 15: 3:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail3.wi.rr.com (fe3.rdc-kc.rr.com [24.94.163.50]) by hub.freebsd.org (Postfix) with ESMTP id E87A137B401 for ; Mon, 26 Feb 2001 15:03:31 -0800 (PST) (envelope-from hamilton@pobox.com) Received: from woodstock.monkey.net ([24.167.246.123]) by mail3.wi.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Mon, 26 Feb 2001 16:59:49 -0600 Received: by woodstock.monkey.net (Postfix, from userid 500) id B743928; Mon, 26 Feb 2001 17:02:20 -0600 (CST) Date: Mon, 26 Feb 2001 17:02:20 -0600 From: Jon Hamilton To: Soren Schmidt Cc: Stephen Rose , freebsd-hackers@FreeBSD.ORG, Joe Gleason Subject: Re: ata-disk ioctl and atactl patch Message-ID: <20010226170220.A67952@woodstock.monkey.net> References: <200102262010.VAA29823@freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200102262010.VAA29823@freebsd.dk>; from sos@freebsd.dk on Mon, Feb 26, 2001 at 09:10:43PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Soren Schmidt , said on Mon Feb 26, 2001 [09:10:43 PM]: } It seems Stephen Rose wrote: } > A couple of us on the questions list have asked for a way to spin down ide } > disks when idle. Is there any chance that this utility could lead to } > something useful there? } } Well, of cause it could, but I'm not sure I see the usefullness of } the spindown at all, a spinup costs several units of idleness power, } so you have to keep it spun down for long periods to make it worth } the effort, and you wear significantly more on the mechanics this } way too... Others have posted from their experiments that they were able to maintain a spun down state for upwards of an hour (admittedly, with some care and planning). There are also lots of odd uses where one might have long periods of inactivity, such as a laptop on which you log in to a "real machine" to do some kind of work, and want to leave the display going without having to listen to the disk (for whatever reason). I often leave mine listening for incoming messages for hours at a time, and appreciate being able to shut up the disk. I'm using a different method to accomplish the goal, but the desire that led me there is what's important for purposes of this discussion. Are there other ways to accomplish the same thing? Sure. But this desire isn't per se unreasonable on its face. It's not a good fit for lots of systems, but there are cases where it's desirable. -- Jon Hamilton hamilton@pobox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 15:24: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.vi.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with SMTP id DB35A37B4EC for ; Mon, 26 Feb 2001 15:24:01 -0800 (PST) (envelope-from dphoenix@bravenet.com) Received: (qmail 8527 invoked by uid 1000); 26 Feb 2001 23:23:21 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 26 Feb 2001 23:23:21 -0000 Date: Mon, 26 Feb 2001 15:23:21 -0800 (PST) From: Dan Phoenix To: Matt Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: apache In-Reply-To: <200102262302.f1QN2Yt46234@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Exact same config on other webservers wtih really low cpu. Memory checks out fine. Mysql connection to db checks out fine. IO is fine.......running out of ideas. tcpdump returns alot of these.... 15:19:53.383597 elrond.sf.bravenet.com.shivahose > drago.sf.bravenet.com.telnet: . ack 6212 win 17520 (DF) [tos 0x10] 15:19:53.914743 0:30:80:28:dd:c7 > 1:80:c2:0:0:0 802.1d ui/C >>> Unknown IPX Data: (43 bytes) [000] 00 00 00 00 00 80 00 00 02 16 7A 67 80 00 00 00 ........ ..zg.... [010] 13 80 00 00 30 80 28 DD C0 80 13 01 00 14 00 02 ....0.(. ........ [020] 00 0F 00 00 00 00 00 00 00 00 00 ........ ... len=43 0000 0000 0080 0000 0216 7a67 8000 0000 1380 0000 3080 28dd c080 1301 0014 0002 000f 0000 0000 0000 0000 00 what is shivahose? dmesg returns icmp-response bandwidth limit 228/200 pps icmp-response bandwidth limit 230/200 pps pid 1146 (httpd), uid 506: exited on signal 10 pid 1207 (httpd), uid 506: exited on signal 10 icmp-response bandwidth limit 219/200 pps icmp-response bandwidth limit 204/200 pps icmp-response bandwidth limit 217/200 pps icmp-response bandwidth limit 219/200 pps icmp-response bandwidth limit 219/200 pps icmp-response bandwidth limit 221/200 pps I even recompiled his kernel optimized with 256 maxusers. That did not help either. looking at apache error log i see alot of [Mon Feb 26 15:12:50 2001] [error] (54)Connection reset by peer: getsockname so i guess i will ask about getsockname......i have experience this before when maxclients was set to low. That is not the case here....running out of ideas. On Mon, 26 Feb 2001, Matt Dillon wrote: > Date: Mon, 26 Feb 2001 15:02:34 -0800 (PST) > From: Matt Dillon > To: Dan Phoenix > Cc: freebsd-hackers@FreeBSD.ORG > Subject: Re: apache > > : > :httpd in free(): warning: recursive call. > :httpd in free(): warning: recursive call. > :httpd in free(): warning: recursive call. > :httpd in free(): warning: recursive call. > :httpd in free(): warning: recursive call. > :httpd in free(): warning: recursive call. > :httpd in free(): warning: recursive call. > : > :seeing that on 2 webservers that have highest cpu > :yet others are exactly the same with really low cpu's > > This occurs if a signal occurs in the middle of a free() and > the signal handler itself tries to do a free(). It is extremely > illegal to do this... apache needs to be fixed. > > -Matt > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 17:21:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from akira.lanfear.com (akira.lanfear.com [208.12.11.174]) by hub.freebsd.org (Postfix) with ESMTP id 309AB37B491 for ; Mon, 26 Feb 2001 17:21:39 -0800 (PST) (envelope-from mwlist@lanfear.com) Received: from sapporo.lanfear.com (h-64-105-36-216.snvacaid.covad.net [64.105.36.216]) by akira.lanfear.com (8.9.3/8.9.3) with SMTP id RAA39980 for freebsd-hackers@freebsd.org; Mon, 26 Feb 2001 17:21:37 -0800 (PST) (envelope-from mwlist@lanfear.com) Date: Mon, 26 Feb 2001 17:21:37 -0800 (PST) From: Marc W Message-Id: <200102270121.RAA39980@akira.lanfear.com> To: freebsd-hackers@freebsd.org Subject: Where can I find out rules on blocking in threads? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Kiltdown 0.7 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hello! I'm running into a problem with some threading using pthreads in an application i'm writing for FreeBSD. The application basically 1. initializes some UI goo (but doesn't start any of it UP) using a GUI framework (Qt) 2. creates a FIFO, and then spawns a thread 3. this new thread then does: fifo = open(fifoPath, O_RDONLY); 4. after the new thread is spawned, the application is supposed to then continue initialization, showing the main window and continuing on happily. Now, the problem is that when step 3 above blocks on the open(2) call (as it should, since the other end of the pipe isn't opened yet), the whole application is frozen, and the main thread can't continue with GUI processing, and the app appears to die. What is goofy is that this works just fine under Linux. So, FreeBSD has slightly different blocking rules or something -- but I don't understand them. It also hangs under Solaris 8/Intel. So, the question is: how can I find out what these differences are and try to get around them. I'm using this to limit instances of my program to one, and need a named pipe instead of just a lock file so that new instances can communicate any arguments they might have been given, etc ... any suggestions? thanks! marc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 17:57: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.122.47]) by hub.freebsd.org (Postfix) with ESMTP id 3E2A537B401 for ; Mon, 26 Feb 2001 17:57:05 -0800 (PST) (envelope-from dwhite@resnet.uoregon.edu) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.10.1/8.10.1) with ESMTP id f1R1v3q26034; Mon, 26 Feb 2001 17:57:03 -0800 (PST) Date: Mon, 26 Feb 2001 17:57:03 -0800 (PST) From: Doug White To: Dan Phoenix Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: apache In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 26 Feb 2001, Dan Phoenix wrote: > > > > [Mon Feb 26 13:04:34 2001] [error] (54)Connection reset by > peer: getsockname > [Mon Feb 26 13:04:39 2001] [emerg] (9)Bad file > descriptor: flock: LOCK_EX: Error getting accept lock. Exiting! > [Mon Feb 26 13:04:39 2001] [alert] Child 777 returned a Fatal error... > Apache is exiting! > httpd in free(): warning: page is already free. > > > anyone seen this before? > i do have some things on nfs apache accesses.. Don't put the scoreboard & lock file on NFS. The Apache docs say this is a No-No unless you change the locking type. Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 17:57:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id 56CFA37B401 for ; Mon, 26 Feb 2001 17:57:15 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1R1vE627084 for ; Mon, 26 Feb 2001 19:57:14 -0600 (CST) Message-Id: <200102270157.f1R1vE627084@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: [hackers] Re: Setting memory allocators for library functions. In-reply-to: Your message of "Tue, 27 Feb 2001 01:37:43 GMT." <20010227013743.H609@hand.dotat.at> Date: Mon, 26 Feb 2001 19:57:13 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010227013743.H609@hand.dotat.at>, Tony Finch writes: >fork() with big data segments that cause swap to be reserved in case >of a copy-on-write. The 2GB of swap is never actually used, but you >still have to have it. That's a good point. So, we should warn people that asking for memory committments, having huge data spaces, and forking, is dangerous or stupid. :) -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 18: 3:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.vi.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with SMTP id D981C37B401 for ; Mon, 26 Feb 2001 18:03:09 -0800 (PST) (envelope-from dphoenix@bravenet.com) Received: (qmail 25358 invoked by uid 1000); 27 Feb 2001 02:02:29 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 27 Feb 2001 02:02:29 -0000 Date: Mon, 26 Feb 2001 18:02:29 -0800 (PST) From: Dan Phoenix To: Doug White Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: apache In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I did not specify a lock directive in httpd.conf. Default my httpd is in /usr/local/apache i would assume lock file is going there which is an ide drive. > Date: Mon, 26 Feb 2001 17:57:03 -0800 (PST) > From: Doug White > To: Dan Phoenix > Cc: freebsd-hackers@FreeBSD.ORG > Subject: Re: apache > > On Mon, 26 Feb 2001, Dan Phoenix wrote: > > > > > > > > > [Mon Feb 26 13:04:34 2001] [error] (54)Connection reset by > > peer: getsockname > > [Mon Feb 26 13:04:39 2001] [emerg] (9)Bad file > > descriptor: flock: LOCK_EX: Error getting accept lock. Exiting! > > [Mon Feb 26 13:04:39 2001] [alert] Child 777 returned a Fatal error... > > Apache is exiting! > > httpd in free(): warning: page is already free. > > > > > > anyone seen this before? > > i do have some things on nfs apache accesses.. > > Don't put the scoreboard & lock file on NFS. The Apache docs say this is a > No-No unless you change the locking type. > > Doug White | FreeBSD: The Power to Serve > dwhite@resnet.uoregon.edu | www.FreeBSD.org > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 18:40:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 21FD037B401 for ; Mon, 26 Feb 2001 18:40:37 -0800 (PST) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id 46EB03E09; Mon, 26 Feb 2001 18:40:36 -0800 (PST) To: Marc W Cc: freebsd-hackers@freebsd.org Subject: Re: Why does a named pipe (FIFO) give me my data twice ??? In-Reply-To: Message from Marc W of "Mon, 26 Feb 2001 12:58:36 PST." <200102262058.MAA39013@akira.lanfear.com> Date: Mon, 26 Feb 2001 18:40:36 -0800 From: Dima Dorfman Message-Id: <20010227024036.46EB03E09@bazooka.unixfreak.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If the first program calls open(2) before the second one calls close(2) the former will not block because there's already a writer on the pipe. A possible workaround would be to unlink and recreate the fifo in program one, like so: for (;;) { int fifo; mkfifo(fifo_path, fifo_mode); fifo = open(fifo_path, O_RDONLY); read(fifo, ...); printf(...); close(fifo); unlink(fifo_path); } As for why this actually happens, I don't know. None of my Stevens books explain this. Hope this helps Dima Dorfman dima@unixfreak.org > > hello! > > I've got a program that creates a named pipe, and then spawns a > thread > which sits in a loop: > > // error checking snipped. > // > while (1) { > int fifo = open(fifoPath, O_RDONLY); // this blocks > fprintf(stderr, "somebody opened the other end!\n"); > read(fifo, buf, sizeof(buf)); > fprintf(stderr, "got the following data: %s\n", buf); > close(fifo); > } > > i then have another instance of the same program do the following: > > fifo = open(fifoPath, O_WRONLY); > write(fifo, buf, strlen(buf); > > > now, the problem is that the first process succeeds suddenly for > the > open, reads the data, closes the fifo, and IMMEDIATELY SUCCEEDS THE > open(2) > again, reading in the same data. > After that, all is as expected. > > Note that this doesn't happen ALL the time -- only about 80% of the > time. > > Any idea why this would happen? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 19: 5:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 345C837B491 for ; Mon, 26 Feb 2001 19:05:29 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from isi.edu (hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f1R35SH21686; Mon, 26 Feb 2001 19:05:28 -0800 (PST) Message-ID: <3A9B1977.3CDE0435@isi.edu> Date: Mon, 26 Feb 2001 19:05:27 -0800 From: Lars Eggert Organization: USC Information Sciences Institute X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en, de MIME-Version: 1.0 To: Dan Phoenix Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: apache References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms66ABCEED951304EBB06700BD" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a cryptographically signed message in MIME format. --------------ms66ABCEED951304EBB06700BD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dan Phoenix wrote: > > httpd in free(): warning: recursive call. What FreeBSD/apache versions is this with? I've seen the same on FreeBSD-3.4 and an older apache build from ports. Haven't (yet) seen it under 4.2 and the latest apache from ports. -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms66ABCEED951304EBB06700BD Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIIwYJKoZIhvcNAQcCoIIIFDCCCBACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BfQwggLYMIICQaADAgECAgMDIwUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDgyNDIwMzAwOFoXDTAxMDgyNDIwMzAw OFowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAz1yfcNs53rvhuw8gSDvr2+/snP8GduYY7x7WkJdyvcwb4oipNpWYIkMGP214 Zv1KrgvntGaG+jeugAGQt0n64VusgcIzQ6QDRtnMgdQDTAkVSQ2eLRSQka+nAPx6SFKJg79W EEHmgKQBMtZdMBYtYv/mTOcpm7jTJVg+7W6n04UCAwEAAaN3MHUwKgYFK2UBBAEEITAfAgEA MBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1 MAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiKvxYINmVfTkWMdGHcBhvSPXw4wwDQYJKoZI hvcNAQEEBQADgYEAi65fM/jSCaPhRoA9JW5X2FktSFhE5zkIpFVPpv33GWPPNrncsK13HfZm s0B1rNy2vU7UhFI/vsJQgBJyffkLFgMCjp3uRZvBBjGD1q4yjDO5yfMMjquqBpZtRp5op3lT d01faA58ZCB5sxCb0ORSxvXR8tc9DJO0JIpQILa6vIAwggMUMIICfaADAgECAgELMA0GCSqG SIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTkwOTE2MTQwMTQwWhcNMDEwOTE1MTQwMTQwWjCBlDELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoT BlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNv bmFsIEZyZWVtYWlsIFJTQSAxOTk5LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALNpWpfU0BYLerXFXekhnCNyzRJMS/d+z8f7ynIk9EJSrFeV43theheE5/1yOTiUtOrtZaeS Bl694GX2GbuUeXZMPrlocHWEHPQRdAC8BSxPCQMXMcz0QdRyxqZd4ohEsIsuxE3x8NaFPmzz lZR4kX5A6ZzRjRVXjsJz5TDeRvVPAgMBAAGjNzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYD VR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEAa8ZZ6TH6 6bbssQPY33Jy/pFgSOrGVd178GeOxmFw523CpTfYnbcXKFYFi91cdW/GkZDGbGZxE9AQfGuR b4bgITYtwdfqsgmtzy1txoNSm/u7/pyHnfy36XSS5FyXrvx+rMoNb3J6Zyxrc/WG+Z31AG70 HQfOnZ6CYynvkwl+Vd4xggH3MIIB8wIBATCBnDCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEd MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt YWlsIFJTQSAxOTk5LjkuMTYCAwMjBTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDIyNzAzMDUyN1owIwYJKoZIhvcNAQkEMRYE FC8/qAWCLliBDgjG1bcoxGjEq0XPMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G CSqGSIb3DQEBAQUABIGAJmm6LfAMkw1qZQF++wwrQRrlcA7JgQd7KnwHw/rB/37pAM+7xVOi Mc9LzyP4+/a99j99+fEE3tr1hAL9jLuaXc8vmNZWrNFDNYzp4g4ozc9eue/2xsn2Cgr0TkW3 GIK7q23i2UEtqWT9AzPrssRgCUkk49fT9aLYZWuMrwz04NA= --------------ms66ABCEED951304EBB06700BD-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 22:27:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from c62443-a.frmt1.sfba.home.com (c62443-a.frmt1.sfba.home.com [24.0.69.165]) by hub.freebsd.org (Postfix) with ESMTP id B8E9E37B684 for ; Mon, 26 Feb 2001 22:27:52 -0800 (PST) (envelope-from adsharma@c62443-a.frmt1.sfba.home.com) Received: (from adsharma@localhost) by c62443-a.frmt1.sfba.home.com (8.9.3/8.9.3) id WAA17949; Mon, 26 Feb 2001 22:24:19 -0800 Date: Mon, 26 Feb 2001 22:24:19 -0800 From: Arun Sharma Message-Id: <200102270624.WAA17949@c62443-a.frmt1.sfba.home.com> To: dillon@earth.backplane.com Cc: hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-Reply-To: <200102261755.f1QHtvr34064@earth.backplane.com> References: <200102260529.f1Q5T8413011@curve.dellroad.org> <200102261755.f1QHtvr34064@earth.backplane.com> Reply-To: adsharma@sharmas.dhs.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 26 Feb 2001 18:56:18 +0100, Matt Dillon wrote: > Ha. Right. Go through any piece of significant code and just see how > much goes flying out the window because the code wants to simply assume > things work. Then try coding conditionals all the way through to fix > it... and don't forget you need to propogate the error condition back > up the procedure chain too so the original caller knows why it failed. So, it all comes down to reimplementing the UNIX kernel in a language that supports exceptions, just like Linus suggested :) -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 23:33:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id D3F4137B719 for ; Mon, 26 Feb 2001 23:33:24 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14Xeo5-0000No-00; Tue, 27 Feb 2001 00:44:25 -0700 Message-ID: <3A9B5AD8.10EB0A1D@softweyr.com> Date: Tue, 27 Feb 2001 00:44:24 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Chris Shenton Cc: hackers@freebsd.org Subject: Re: ThinkNIC booting FreeBSD? [WAS: Re: Silent FreeBSD] References: <3A4B7498.267D52E8@softweyr.com> <005801c07037$47ae6ea0$0402010a@biohz.net> <200012281812.LAA95895@harmony.village.org> <3A4CC308.9A3F092C@softweyr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chris Shenton wrote: > > In message <3A4B7498.267D52E8@softweyr.com> Wes Peters writes: > > > We have several NIC's around here (the New Internet Computer, see > > http://www.thinknic.com/ for details) and will be adding a couple of these > > so we can boot FreeBSD or NetBSD on them in the next little while. A NIC > > running FreeBSD on a silent CF disk strikes me as an ideal bedroom computer; > > you can leave it on all the time and just let the screen sleep when you're > > not using it. > > Been thinking seriously about buying a couple of these; hard to beat > the $200 price point. Chat on one of the NIC lists indicates they had > two fans and will now ship with three fans; this seems like it will > make it rather noisey -- especially since they're diskless and should > be quiet. They are quiet. I didn't notice any fans in the ones we disassembled at work. The Geode processor runs QUITE hot, though. They make good hand- warmers when it's snowing outside. > Since I prefer FreeBSD to Linux, I'd rather run BSD than the Linux on > the CD it runs from. Is it possible to create an ISO of a bootable > and runnable FreeBSD? What happens with stuff like /tmp and /var/log? You wouldn't want it; performance running off the CD-ROM is terrible. Get a 2.5" hard drive and stick it to the case top with double-sticky tape. > Failing this, I'd probably net-boot the NICs off a bigger FreeBSD > machine, and NFS mount /home dirs and /usr/local type of software. That would probably give you better performance than the CD-ROM. The NIC has a small flash disk in it as well; you could probably put the boot loader and enough /boot filesystem on that to autoboot. > That way when I built a tool or package it would be available to any > of the FreeBSD boxes in the house. Seems like a great bang/buck > ratio. Any comments on this approach? Sounds good to me. Maybe I should setup a netboot server at work and have a hack at it. We've got a couple of IDE->CompactFlash adapters I could play with without scrogging the NIC-standard flash device. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 26 23:44: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id A231037B718; Mon, 26 Feb 2001 23:44:01 -0800 (PST) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id 4E1483E02; Mon, 26 Feb 2001 23:44:01 -0800 (PST) To: Robert Watson Cc: hackers@freebsd.org Subject: Re: Inheriting the nodump flag In-Reply-To: Message from Robert Watson of "Mon, 26 Feb 2001 11:00:46 EST." Date: Mon, 26 Feb 2001 23:44:00 -0800 From: Dima Dorfman Message-Id: <20010227074401.4E1483E02@bazooka.unixfreak.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 1) This method of handling recursive nodump is far superior to any actual > inheritence of the flag as part of file system operations, as currently > no other file flags are inherited from the parent directory -- the only > property that is inherited is the group. With ACLs, the parent's > default ACL will also play a role in the new access ACL. In any case, > there is no precedent for file flag inheritence. I'm not sure if this is supposed to be a confirmation, but, just to clear things up, the patch doesn't cause the nodump flag to be inherited in the filesystem per se. I.e., you won't see entire trees of files marked nodump that weren't marked before after running dump with this patch applied. It is inherited in terms of dump's internal maps; perhaps propagated would be a better word to describe its behavior. > > 2) Please run the patch by freebsd-audit -- there have been a fair number > of vulnerabilities in the fts code in the past due to race conditions > of various sorts, and it's important that any modifications be > carefully scrutinized to prevent the reintroduction of vulnerabilites. dump doesn't use fts; I used calling fts_set as an example because in a program that uses fts, pruning a directory and everything under it is a matter of one library call. In dump's case, it's not that simple. Nevertheless (or should that be consequently?), your point is well taken. I will send this to -audit in a few days barring any objections here. Thanks again Dima Dorfman dima@unixfreak.org > > However, the general idea sounds very useful, and something that I'd find > applicable on a daily basis :-). > > Robert N M Watson FreeBSD Core Team, TrustedBSD Project > robert@fledge.watson.org NAI Labs, Safeport Network Services > > On Mon, 26 Feb 2001, Dima Dorfman wrote: > > > Hello -hackers > > > > Some time ago, on -arch, phk proposed that the nodump flag should be > > inherited (see 'inheriting the "nodump" flag ?' around Dec. 2000). > > This was generally considered a good idea, however, the patch to the > > kernel he proposed was thought an ugly hack. In addition, jeroen > > pointed out that NetBSD had implemented this functionality the Right > > Way(tm), in dump(8). > > > > Attached below is a port of NetBSD's patch to FreeBSD's dump(8). > > dump's tree walker is a little weird, so the patch is a little more > > complicated than calling fts_set with FTS_SKIP. For the technical > > details of what it does, see: > > http://lists.openresources.com/NetBSD/tech-kern/msg00453.html. > > > > I've been using this on two of my hosts for a while, and it works as > > expected. Given the additional fact that NetBSD has had this for > > almost two years, and that the patch below looks very similar to the > > one they applied, I doubt it significantly breaks anything. > > > > Comments? > > > > Thanks in advance > > > > Dima Dorfman > > dima@unixfreak.org > > > > > > [ Patch snipped to conserve bandwidth of those who have to pay for > > it; it's available at > > http://www.unixfreak.org/~dima/home/nodump.diff or the mailing > > list archives if you're interested. ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 0:22:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id C4CD937B718 for ; Tue, 27 Feb 2001 00:22:51 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1R8Mkw54670; Tue, 27 Feb 2001 00:22:46 -0800 (PST) (envelope-from dillon) Date: Tue, 27 Feb 2001 00:22:46 -0800 (PST) From: Matt Dillon Message-Id: <200102270822.f1R8Mkw54670@earth.backplane.com> To: Arun Sharma Cc: hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. References: <200102260529.f1Q5T8413011@curve.dellroad.org> <200102261755.f1QHtvr34064@earth.backplane.com> <200102270624.WAA17949@c62443-a.frmt1.sfba.home.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> things work. Then try coding conditionals all the way through to fix :> it... and don't forget you need to propogate the error condition back :> up the procedure chain too so the original caller knows why it failed. : :So, it all comes down to reimplementing the UNIX kernel in a language :that supports exceptions, just like Linus suggested :) : : -Arun Not really. UNIX works just fine, it gives you plenty sufficient control over your environment and you can write your programs pretty much in whatever language you like. But no amount of OS control will magically save a badly written program from itself. The best you can hope for is to reduce the collateral damage by setting appropriate resource limits. Allowing a program to run the OS itself out of VM, with or without overcommit, is (being generous) just plain dumb. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 0:32:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 1118737B71A for ; Tue, 27 Feb 2001 00:32:09 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p22-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.87]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id RAA29411; Tue, 27 Feb 2001 17:31:47 +0900 (JST) Message-ID: <3A9B6548.E298F857@newsguy.com> Date: Tue, 27 Feb 2001 17:28:56 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Matt Dillon Cc: Archie Cobbs , Warner Losh , Peter Seebach , freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102260529.f1Q5T8413011@curve.dellroad.org> <200102260628.f1Q6SYX29811@earth.backplane.com> <3A9A0A9A.E4D31F97@newsguy.com> <200102261755.f1QHtvr34064@earth.backplane.com> <3A9AAB02.793A197A@newsguy.com> <200102261940.f1QJeJi38115@earth.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote: > > Said application was poorly written, then. Even on solaris if you The only reason the application was "poorly written" is the overcommit architecture. > actually run the system out of memory you can blow up other unrelated > processes. To depend on that sort of operation is just plain dumb. Not at all. You can fill all memory on Solaris and it will work just fine. Go ahead and try it, if you doubt me. > :I'll give you one more example. Protocol validation. It is often > :impossible to test all possible permutations of a protocol's dialog, but > :being able to go as deep as possible on execution tree and then, when > :you go out of memory, giving up on that path, backing down and > :continuing elsewhere let you get a partial validation, which is not > :enough to prove a protocol is correct but might well be enough to prove > :it is incorrect. This is a real application, and one in which an out of > :memory condition is not only handled but even expected. > > This has nothing to do with memory overcommit. Nothing at all. What > is your definition of out-of-memory? When swap runs out, or when the > system starts to thrash? What is the point of running a scientific When a memory request cannot be satisfied. Swap runs out, it would seem. > calculation if the machine turns into a sludge pile and would otherwise > cause the calculation to take years to complete instead of days? It doesn't trash. The memory is filled with backtracking information. Memory in active use at any time is rather small. > You've got a whole lot more issues to deal with then simple memory > overcommit, and you are ignoring them completely. Not at all. I'm giving you an example of an application which depends on non overcommitting and _works_ on such architectures. > :And, of course, those whose infrastructure depends on a malloc() > :returning NULL indicating the heap is full will not work on FreeBSD. > :(You do recall that many of these languages are written in C, > :don't you?) > > Bullshit. If you care, a simple wrapper will do what you want. Modern > systems tend to have huge amounts of swap. Depending on malloc to Huge amounts of swaps is not a given. You are assuming a hardware setup to fit your theory. > fail with unbounded resources in an overcommit OR a non-overcommit case > is stupid, because the system will be thrashing heavily long before it > even gets to that point. Allocating memory does not trash the system. A rather large number of pages in active use does, and this is not necessarily the case at all. > Depending on malloc() to fail by setting an appropriate datasize limit > resource is more reasonable, and malloc() does work as expected if you > do that. I completely agree that setting datasize limit is more reasonable, but that does not prevent an application from being killed if the system does run out of memory. I think that if the system runs out of memory, you don't have enough memory. That datasize limits must be used to ensure desired behavior. But this is a _preference_. On Solaris, depending on non overcommitting of memory is possible, and some do prefer it that way. > :It has everything to do with overcommit. In this particular case, not > :only there _is_ something to do when the out of memory condition arise, > :but the very algorithm depends on it arising. > > It has nothing to do with overcommit. You are confusing overcommit > with hard-datasize limits, which can be set with a simple 'limit' > command. Unless I want it to grab all available memory. > : > :Garbage Collection: Algorithms for Automatic Memory Management, Richard > :Jones and Rafael Lins. Bullshit is what you just said. > > None of which requires overcommit. None of which would actually > work in a real-world situation with or without overcommit if you do > not hard-limit the memory resource for the program in the first place. If you ever bother to check the reference, you'll see that many of these algorithms were implemented and used in real world systems. > You are again making the mistake of assuming that not having overcommit > will magically solve all your problems. It doesn't even come close. No, *YOU* keep insisting that we assume that. The assumption is rather different: *with* overcommit the problems *cannot* be solved (except by using datasize limit, which I think it's entirely reasonable, but some don't). > You think these garbage collection algorithms work by running the > system out of VM and then backing off? That's pure nonsense. I don't "think" anything. I'm reporting facts. Many algorithms do work that way, whether you think they are non-sense or not. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@kzinti.bsdconspiracy.net Acabou o hipismo-arte. Mas a desculpa brasileira mais ouvida em Sydney e' que nao tem mais cavalo bobo por ai'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 4:47:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id E3B0937B71A for ; Tue, 27 Feb 2001 04:47:16 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.11.1/8.11.1) id f1RCj5T21997; Tue, 27 Feb 2001 07:45:05 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200102271245.f1RCj5T21997@hda.hda.com> Subject: Re: Where can I find out rules on blocking in threads? In-Reply-To: <200102270121.RAA39980@akira.lanfear.com> from Marc W at "Feb 26, 2001 05:21:37 pm" To: Marc W Date: Tue, 27 Feb 2001 07:43:49 -0500 (EST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 1. initializes some UI goo (but doesn't start any of it UP) using a > GUI framework (Qt) > 2. creates a FIFO, and then spawns a thread > 3. this new thread then does: > > fifo = open(fifoPath, O_RDONLY); ... > > Now, the problem is that when step 3 above blocks on the open(2) > call (as it should, since the other end of the pipe isn't opened yet), > the whole application is frozen, and the main thread can't continue > with GUI processing, and the app appears to die. > > What is goofy is that this works just fine under Linux. So, > FreeBSD has slightly different blocking rules or something -- but I > don't understand them. It also hangs under Solaris 8/Intel. > > So, the question is: how can I find out what these differences are > and try to get around them. I'm using this to limit instances of my > program to one, and need a named pipe instead of just a lock file so > that new instances can communicate any arguments they might have been > given, etc ... I think the FreeBSD behavior is wrong, the spec says that when opening a FIFO with O_NONBLOCK clear that: > An open() for reading-only shall block the calling thread until a > thread opens the file for writing. An open() for writing-only > shall block the calling thread until a thread opens the file for > reading. The FBSD man pages will let you know if something will block or not, for example, look at the "implementation notes" section for open. You can open the fifo non-blocking and then clear O_NONBLOCK using fcntl, hopefully that will work in all environments. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 5: 6:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mip.co.za (puck.mip.co.za [209.212.106.44]) by hub.freebsd.org (Postfix) with ESMTP id A09E637B71B for ; Tue, 27 Feb 2001 05:06:19 -0800 (PST) (envelope-from patrick@mip.co.za) Received: from patrick (patrick.mip.co.za [10.3.13.181]) by puck.mip.co.za (8.9.3/8.9.3) with SMTP id HAA19908; Mon, 26 Feb 2001 07:52:17 +0200 (SAST) (envelope-from patrick@mip.co.za) From: "Patrick O'Reilly" To: "Michael Solan" , Subject: RE: dummynet as modules Date: Mon, 26 Feb 2001 07:52:17 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3A9722A5.D305A67@ffnet.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Michael, I hope I am not barking up the wrong tree here, but my understanding is that ipfw selects packets to forward to dummynet. This would make it illogical (and hence probably impossible) to run dummynet without having ipfw running correctly. The man page for 'dummynet' says: In its current implementation, packet selection is done with the ipfw program, by means of ``pipe'' rules. I think you will have to go about this the hard way..... Regards, Patrick O'Reilly --- "I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forego their use." -- Galileo Galilei -----Original Message----- From: owner-freebsd-hackers@FreeBSD.ORG [mailto:owner-freebsd-hackers@FreeBSD.ORG]On Behalf Of Michael Solan Sent: 24 February 2001 04:56 To: hackers@FreeBSD.ORG Subject: dummynet as modules Hi there, How do I compile a a kernel without ipfw, and a ipfw.ko module with dummynet support? I have to add some features to the dummynet code, so instead of rebooting every 5 mins I figured kldloading it would save me some time. I tried several combinations like 'options DUMMYNET' but no 'options IPFIREWALL', even defined DUMMYNET in the modules/ipfw/Makefile but it all resulted in undefined symbols when either building or kldloading... Any ideas? Michael Solan -- New to FreeBSD and less confused than a hamster on FreeBase -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 5:24:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail2.wmptl.com (mail2.wmptl.com [216.94.6.26]) by hub.freebsd.org (Postfix) with ESMTP id 3521337B719; Tue, 27 Feb 2001 05:24:23 -0800 (PST) (envelope-from webmaster@wmptl.com) Received: from wmptl.com ([10.0.0.168]) by mail2.wmptl.com (8.9.3/8.9.3) with ESMTP id JAA78592; Tue, 27 Feb 2001 09:30:46 -0500 (EST) (envelope-from webmaster@wmptl.com) Message-ID: <3A9BAA26.E9851690@wmptl.com> Date: Tue, 27 Feb 2001 08:22:46 -0500 From: Nathan Vidican X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: questions@freebsd.org, hackers@freebsd.org Subject: unexplained strangness with cucipop pop3 daemon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG For some (yet to be unexplained reason), cucipop has (twice now), somehow locked the /var/mail/ files, and is apparently not erasing the message and exiting. Therefore the next time a user checks email (every two minutes from Outlook) they get another copy of the same message(s). The problem does not stop, (while making some users download the same message >200 times), until cucipop is restarted manually. For obvious reasons, this is becoming a big problem. This is the second time this has happened in two weeks now, and luckily while the majority of the office was not in. What I need to do is find out what's causing it, and/or why. Someone earlier had replied explaining that maybe the system was running out of file-lock resources. So I re-compiled a new kernel with maxusers set to 256, started the system back up, and it ran since Monday morning to Saturday morning and started with the problem again. I've since then re-started cucipop, and things seem fine for now. The strange part is that we've changed nothing for months now, (cept the username of one particular UID), and it had been working fine for > 70 days prior to this. (Would be like >150days, cept that we took it down to upgrade server hardware/install freebsd 4.2-stable) The machine is running an old(er) snapshot of 4.2-STABLE, and I wonder if FreeBSD, or cucipop has a problem in it? I figure maybe cucipop (like some radius daemons) has some memory leakage or something and must be restarted cylically? Any ideas, comments, suggestions, or otherwise would be highly appreciated at this point. Nathan Vidican webmaster@wmptl.com Windsor Match Plate & Tool Ltd. http://home.wmptl.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 5:58:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from syncopation-03.iinet.net.au (syncopation-03.iinet.net.au [203.59.24.49]) by hub.freebsd.org (Postfix) with SMTP id 43FD637B718 for ; Tue, 27 Feb 2001 05:58:13 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 19132 invoked by uid 666); 27 Feb 2001 14:10:09 -0000 Received: from i079-084.nv.iinet.net.au (HELO elischer.org) (203.59.79.84) by mail.m.iinet.net.au with SMTP; 27 Feb 2001 14:10:09 -0000 Message-ID: <3A9BAAF9.C75B39BF@elischer.org> Date: Tue, 27 Feb 2001 05:26:17 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: adsharma@sharmas.dhs.org Cc: dillon@earth.backplane.com, hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. References: <200102260529.f1Q5T8413011@curve.dellroad.org> <200102261755.f1QHtvr34064@earth.backplane.com> <200102270624.WAA17949@c62443-a.frmt1.sfba.home.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Arun Sharma wrote: > > On 26 Feb 2001 18:56:18 +0100, Matt Dillon wrote: > > Ha. Right. Go through any piece of significant code and just see how > > much goes flying out the window because the code wants to simply assume > > things work. Then try coding conditionals all the way through to fix > > it... and don't forget you need to propogate the error condition back > > up the procedure chain too so the original caller knows why it failed. > > So, it all comes down to reimplementing the UNIX kernel in a language > that supports exceptions, just like Linus suggested :) I've often considered writing a language SPECIFICALLY for writing the kernel. (no other uses) I mean it basically uses the same mechaninsims over and over and over again... linked lists, hash tables, nested loops, etc.etc. I'd like a language that lets me define the module I'm writing, define the way it should behave, and let the boring code be taken care of by itelf :-) > > -Arun > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 6:33:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id D8AD637B718 for ; Tue, 27 Feb 2001 06:33:42 -0800 (PST) (envelope-from usebsd@free.fr) Received: by smtp.nettoll.com; Tue, 27 Feb 2001 15:31:49 +0100 (MET) Message-Id: <4.3.0.20010227153039.00dd4f00@pop.free.fr> X-Sender: usebsd@pop.free.fr X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 27 Feb 2001 15:34:51 +0100 To: Marc W , freebsd-hackers@freebsd.org From: mouss Subject: Re: Where can I find out rules on blocking in threads? In-Reply-To: <200102270121.RAA39980@akira.lanfear.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 17:21 26/02/01 -0800, Marc W wrote: >hello! > > I'm running into a problem with some threading using pthreads in an >application i'm writing for FreeBSD. > > The application basically > > 1. initializes some UI goo (but doesn't start any of it UP) using a >GUI framework (Qt) > 2. creates a FIFO, and then spawns a thread > 3. this new thread then does: > > fifo = open(fifoPath, O_RDONLY); > > 4. after the new thread is spawned, the application is supposed to >then continue initialization, showing the main window and continuing on >happily. > > > Now, the problem is that when step 3 above blocks on the open(2) >call (as it should, since the other end of the pipe isn't opened yet), >the whole application is frozen, and the main thread can't continue >with GUI processing, and the app appears to die. > > What is goofy is that this works just fine under Linux. So, >FreeBSD has slightly different blocking rules or something -- but I >don't understand them. It also hangs under Solaris 8/Intel. > > So, the question is: how can I find out what these differences are >and try to get around them. I'm using this to limit instances of my >program to one, and need a named pipe instead of just a lock file so >that new instances can communicate any arguments they might have been >given, etc ... > > > any suggestions? depens on how long it blocks? is it indefinitely blocking or for some time? in the latter, you might use a sleep() in the child before the open(). Does the parent wait for its child (the thread that does the open fifo thing)? can you provided a small piece of code that shows this behaviour? cheers, mouss To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 7: 1:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id 8751C37B71D for ; Tue, 27 Feb 2001 07:01:17 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.11.1/8.11.1) id f1REs5j22343; Tue, 27 Feb 2001 09:54:05 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200102271454.f1REs5j22343@hda.hda.com> Subject: Re: Where can I find out rules on blocking in threads? In-Reply-To: <4.3.0.20010227153039.00dd4f00@pop.free.fr> from mouss at "Feb 27, 2001 03:34:51 pm" To: mouss Date: Tue, 27 Feb 2001 09:54:05 -0500 (EST) Cc: Marc W , freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > can you provided a small piece of code that shows this behaviour? Here's one without error checking. Be sure to use -pthread. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval #include #include #include #include #include #include struct threadstuff { int rfid, wfid; const char *name; }; static void * reader(void *arg) { struct threadstuff *pts = (struct threadstuff *)arg; fprintf(stderr, "Opening %s for read...", pts->name); pts->rfid = open(pts->name, O_RDONLY); fprintf(stderr, " reader got fid %d.\n", pts->rfid); return 0; } static void * writer(void *arg) { struct threadstuff *pts = (struct threadstuff *)arg; fprintf(stderr, "Opening %s for write...", pts->name); pts->wfid = open(pts->name, O_WRONLY); fprintf(stderr, " writer got fid %d.\n", pts->wfid); return 0; } int main(int ac, char *av[]) { pthread_t r, w; void *value; struct threadstuff ts; ts.name = "./my_fifo"; ts.rfid = ts.wfid = -1; (void)unlink(ts.name); (void)mkfifo(ts.name, 0666); pthread_create(&r, 0, reader, (void *)&ts); pthread_create(&w, 0, writer, (void *)&ts); pthread_join(r, &value); pthread_join(w, &value); if (ts.rfid != -1) (void)close(ts.rfid); if (ts.wfid != -1) (void)close(ts.wfid); return 0; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 7:13: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from syncopation-01.iinet.net.au (syncopation-01.iinet.net.au [203.59.24.37]) by hub.freebsd.org (Postfix) with SMTP id 9DA1037B71D for ; Tue, 27 Feb 2001 07:12:57 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 13119 invoked by uid 666); 27 Feb 2001 15:24:06 -0000 Received: from i079-084.nv.iinet.net.au (HELO elischer.org) (203.59.79.84) by mail.m.iinet.net.au with SMTP; 27 Feb 2001 15:24:06 -0000 Message-ID: <3A9BC3CF.4A911C0D@elischer.org> Date: Tue, 27 Feb 2001 07:12:15 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Patrick O'Reilly Cc: Michael Solan , hackers@freebsd.org Subject: Re: dummynet as modules References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Patrick O'Reilly wrote: > > Michael, > > I hope I am not barking up the wrong tree here, but my understanding is that > ipfw selects packets to forward to dummynet. This would make it illogical > (and hence probably impossible) to run dummynet without having ipfw running > correctly. > > The man page for 'dummynet' says: > In its current implementation, packet selection is done with the ipfw > program, by means of ``pipe'' rules. > > I think you will have to go about this the hard way..... > > Regards, > Patrick O'Reilly > --- > "I do not feel obliged to believe that the same God who has endowed us with > sense, reason, and intellect has intended us to forego their use." -- > Galileo Galilei > > -----Original Message----- > From: owner-freebsd-hackers@FreeBSD.ORG > [mailto:owner-freebsd-hackers@FreeBSD.ORG]On Behalf Of Michael Solan > Sent: 24 February 2001 04:56 > To: hackers@FreeBSD.ORG > Subject: dummynet as modules > > Hi there, > > How do I compile a a kernel without ipfw, and a ipfw.ko module with > dummynet support? > I have to add some features to the dummynet code, so instead of > rebooting every 5 mins I figured kldloading it would save me some time. > > I tried several combinations like 'options DUMMYNET' but no 'options > IPFIREWALL', even defined DUMMYNET in the modules/ipfw/Makefile but it > all resulted in undefined symbols when either building or kldloading... > > Any ideas? make a combined ipfw+dummynet module (include both sets of files in the same module > > Michael Solan > > -- New to FreeBSD and less confused than a hamster on FreeBase -- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 7:15:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from a.mx.everquick.net (a.mx.everquick.net [216.89.137.3]) by hub.freebsd.org (Postfix) with ESMTP id 30D0037B71A for ; Tue, 27 Feb 2001 07:15:35 -0800 (PST) (envelope-from eddy+public+spam@noc.everquick.net) Received: from localhost (eddy@localhost) by a.mx.everquick.net (8.9.0/8.8.7) with ESMTP id PAA16252 for ; Tue, 27 Feb 2001 15:15:33 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Date: Tue, 27 Feb 2001 15:15:33 +0000 (GMT) From: "E.B. Dreger" To: freebsd-hackers@FreeBSD.ORG Subject: Re: Where can I find out rules on blocking in threads? In-Reply-To: <200102270121.RAA39980@akira.lanfear.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is this a library issue in libc_r? I just wrote a quick test program using rfork(RFMEM|RFPROC) to create a child thread. I then had both the parent and the child attempt to open the pre-existing file /tmp/blah with O_EXLOCK set. When I specify O_NONBLOCK, the child open() fails immediately. When I do not specify O_NONBLOCK, the child blocks indefinitely: #if TRY_NONBLOCKING # define O_XXXX (O_NONBLOCK) #else # define O_XXXX (0) #endif int main(int argc, char* *argv) { thread_creation_using_rfork(RFPROC|RFTHREAD) ; /* parent continues here */ printf("main: %d\n", open("/tmp/blah", O_RDWR|O_EXLOCK|O_XXXX)) ; for( ; ; ) ; } void childthreadproc(void *) { /* child begins here */ /* fails for O_NONBLOCK, otherwise blocks indefinitely */ printf("child: %d\n", open("/tmp/blah", O_RDWR|O_EXLOCK|O_XXXX)) ; for( ; ; ) ; } Note that I've omitted the guts of rfork(). Therefore, it seems to me that the blocking is at the library level, not the kernel level. Have I missed something? Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet / EternalCommerce Division E-Mail: eddy@everquick.net Phone: (316) 794-8922 --------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 9:24:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from a.mx.everquick.net (a.mx.everquick.net [216.89.137.3]) by hub.freebsd.org (Postfix) with ESMTP id A1A9E37B718 for ; Tue, 27 Feb 2001 09:24:09 -0800 (PST) (envelope-from eddy+public+spam@noc.everquick.net) Received: from localhost (eddy@localhost) by a.mx.everquick.net (8.9.0/8.8.7) with ESMTP id RAA19274 for ; Tue, 27 Feb 2001 17:24:09 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Date: Tue, 27 Feb 2001 17:24:09 +0000 (GMT) From: "E.B. Dreger" To: freebsd-hackers@freebsd.org Subject: Re: Where can I find out rules on blocking in threads? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Date: Tue, 27 Feb 2001 15:15:33 +0000 (GMT) > From: E.B. Dreger > > Is this a library issue in libc_r? > > I just wrote a quick test program using rfork(RFMEM|RFPROC) to > create a child thread. Correction: RFTHREAD|RFPROC Sorry... I have RFMEM on the brain. The pseudocode gave the correct RFXXX flags. (I also typed "#if" instead of "#ifdef". FreeBSD multitasks better than I do this morning.) FWIW, does anyone know what Linuxthread's blocking behavior is? The original poster mentioned that Linux gave the desired behavior... what about the Linuxthreads library? Although I have written pthread applications, I prefer to do my thread programming at a lower level; hence my use of rfork(). Hopefully the info will be useful, though. Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet / EternalCommerce Division E-Mail: eddy@everquick.net Phone: (316) 794-8922 --------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 10: 3:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id B2B3B37B719 for ; Tue, 27 Feb 2001 10:03:51 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1RI2N058049; Tue, 27 Feb 2001 10:02:23 -0800 (PST) (envelope-from dillon) Date: Tue, 27 Feb 2001 10:02:23 -0800 (PST) From: Matt Dillon Message-Id: <200102271802.f1RI2N058049@earth.backplane.com> To: "Daniel C. Sobral" Cc: Archie Cobbs , Warner Losh , Peter Seebach , freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102260529.f1Q5T8413011@curve.dellroad.org> <200102260628.f1Q6SYX29811@earth.backplane.com> <3A9A0A9A.E4D31F97@newsguy.com> <200102261755.f1QHtvr34064@earth.backplane.com> <3A9AAB02.793A197A@newsguy.com> <200102261940.f1QJeJi38115@earth.backplane.com> <3A9B6548.E298F857@newsguy.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel, you don't have to believe me, I really don't care. I hear this argument once or twice a year and those of who actually have experience (except for Terry, who always likes to argue theory) already know what the reality is. Come back in a year or two after you've wasted a thousand man hours trying to implement your little beast, tried to use it for something non trivial, and found that it doesn't work the way you expect. I've heard the solaris argument before two, though until you came along I didn't actually hear someone try to propound that running a machine out of memory on purpose wouldn't have any unwanted side effects. That's a new one.. and a good laugh. But it isn't reality. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 10:15:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from oden.exmandato.se (exmandato.se [192.71.33.1]) by hub.freebsd.org (Postfix) with ESMTP id 2ECDD37B719 for ; Tue, 27 Feb 2001 10:15:30 -0800 (PST) (envelope-from jonas.bulow@servicefactory.se) Received: from servicefactory.se (root@oden.exmandato.se [192.71.33.1]) by oden.exmandato.se (8.8.8/8.8.5) with ESMTP id TAA13404 for ; Tue, 27 Feb 2001 19:15:26 +0100 (MET) Message-ID: <3A9BEEBB.1D7489D8@servicefactory.se> Date: Tue, 27 Feb 2001 19:15:23 +0100 From: Jonas Bulow Organization: Service Factory X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102230728.f1N7SW619041@guild.plethora.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Seebach wrote: ... > Imagine a word processor with this behavior. No attempt to save your > file, no nothing, it just suddenly closes all windows and dies. I think most people can think of at least one widely used commerical word processor with exactly this behaviour. :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 10:53:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ffnet.com (w200.z208176006.sjc-ca.dsl.cnc.net [208.176.6.200]) by hub.freebsd.org (Postfix) with ESMTP id 2079F37B719 for ; Tue, 27 Feb 2001 10:53:16 -0800 (PST) (envelope-from solan@ffnet.com) Received: from ffnet.com (noriega.ffnet.com [172.16.248.252]) by ffnet.com (8.8.8/8.8.8) with ESMTP id KAA10234 for ; Tue, 27 Feb 2001 10:53:15 -0800 (PST) (envelope-from solan@ffnet.com) Message-ID: <3A9BF79A.4939E44C@ffnet.com> Date: Tue, 27 Feb 2001 10:53:14 -0800 From: Michael Solan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: Re: dummynet as modules References: <3A9BC3CF.4A911C0D@elischer.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > Patrick O'Reilly wrote: > > > > Michael, > > > > I hope I am not barking up the wrong tree here, but my understanding is that > > ipfw selects packets to forward to dummynet. This would make it illogical > > (and hence probably impossible) to run dummynet without having ipfw running > > correctly. > > > > The man page for 'dummynet' says: > > In its current implementation, packet selection is done with the ipfw > > program, by means of ``pipe'' rules. > > > > I think you will have to go about this the hard way..... > > > > Regards, > > Patrick O'Reilly > > --- > > "I do not feel obliged to believe that the same God who has endowed us with > > sense, reason, and intellect has intended us to forego their use." -- > > Galileo Galilei > > > > -----Original Message----- > > From: owner-freebsd-hackers@FreeBSD.ORG > > [mailto:owner-freebsd-hackers@FreeBSD.ORG]On Behalf Of Michael Solan > > Sent: 24 February 2001 04:56 > > To: hackers@FreeBSD.ORG > > Subject: dummynet as modules > > > > Hi there, > > > > How do I compile a a kernel without ipfw, and a ipfw.ko module with > > dummynet support? > > I have to add some features to the dummynet code, so instead of > > rebooting every 5 mins I figured kldloading it would save me some time. > > > > I tried several combinations like 'options DUMMYNET' but no 'options > > IPFIREWALL', even defined DUMMYNET in the modules/ipfw/Makefile but it > > all resulted in undefined symbols when either building or kldloading... > > > > Any ideas? > > make a combined ipfw+dummynet module (include both sets of files in the same > module > That's what I tried, the problem though is that there's a couple of #ifdef DUMMYNET in ip_input.c which gets statically linked to the kernel and is not part of the ipfw module. > > > > Michael Solan > > > > -- New to FreeBSD and less confused than a hamster on FreeBase -- > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > -- > __--_|\ Julian Elischer > / \ julian@elischer.org > ( OZ ) World tour 2000-2001 > ---> X_.---._/ > v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 11:21:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 7332E37B718 for ; Tue, 27 Feb 2001 11:21:22 -0800 (PST) (envelope-from fanf@dotat.at) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14XYr7-0002st-00; Tue, 27 Feb 2001 01:23:09 +0000 Date: Tue, 27 Feb 2001 01:23:09 +0000 From: Tony Finch To: Dag-Erling Smorgrav Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. Message-ID: <20010227012309.G609@hand.dotat.at> References: <200102230627.f1N6Rk618467@guild.plethora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: Organization: Covalent Technologies, Inc Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > >This is all academic since FreeBSD does memory overcommit, so unless >you run out of address space for your process before you run out of >actual memory and/or swap (not likely, but quite possible) malloc() >will never return NULL and you won't know a thing until you dirty one >page too many and segfault. What about setrlimit(RLIMIMT_DATA)? Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 11:21:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 1C8F137B719 for ; Tue, 27 Feb 2001 11:21:25 -0800 (PST) (envelope-from fanf@dotat.at) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14XZ5D-0002xN-00; Tue, 27 Feb 2001 01:37:43 +0000 Date: Tue, 27 Feb 2001 01:37:43 +0000 From: Tony Finch To: Peter Seebach Cc: freebsd-hackers@freebsd.org Subject: Re: [hackers] Re: Setting memory allocators for library functions. Message-ID: <20010227013743.H609@hand.dotat.at> References: <15001.57313.163670.146752@trooper.velocet.net> <200102260455.f1Q4tQ606269@guild.plethora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102260455.f1Q4tQ606269@guild.plethora.net> Organization: Covalent Technologies, Inc Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Seebach wrote: >David Gilbert writes: >> >>Due to the bloat of the OS and Motif and other such things, they >>required simply amazing amounts of swap just to run. > >Well, to some extent, I have to wonder why all these pages are being >requested if they aren't being used... fork() with big data segments that cause swap to be reserved in case of a copy-on-write. The 2GB of swap is never actually used, but you still have to have it. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 11:36:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from orthanc.ab.ca (207-167-15-66.dsl.worldgate.ca [207.167.15.66]) by hub.freebsd.org (Postfix) with ESMTP id 9900D37B718 for ; Tue, 27 Feb 2001 11:36:41 -0800 (PST) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost [127.0.0.1]) by orthanc.ab.ca (8.11.2/8.11.2) with ESMTP id f1RJaFq98998; Tue, 27 Feb 2001 12:36:15 -0700 (MST) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <200102271936.f1RJaFq98998@orthanc.ab.ca> From: Lyndon Nerenberg Organization: The Frobozz Magic Homing Pigeon Company To: Tony Finch Cc: Peter Seebach , freebsd-hackers@FreeBSD.ORG Subject: Re: [hackers] Re: Setting memory allocators for library functions. In-reply-to: Your message of "Tue, 27 Feb 2001 01:37:43 GMT." <20010227013743.H609@hand.dotat.at> Date: Tue, 27 Feb 2001 12:36:15 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Tony" == Tony Finch writes: >> Well, to some extent, I have to wonder why all these pages are >> being requested if they aren't being used... Tony> fork() with big data segments that cause swap to be reserved Tony> in case of a copy-on-write. The 2GB of swap is never Tony> actually used, but you still have to have it. If the information in the data segment is going to be updated then you have to have writable backing store. If, however, that data is never going to be changed, it should be declared in the program as read-only data. The kernel VM system should not be working around applications that don't declare their data arena correctly. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 11:43:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 4679A37B719 for ; Tue, 27 Feb 2001 11:43:42 -0800 (PST) (envelope-from fanf@dotat.at) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14Xq13-0003xx-00; Tue, 27 Feb 2001 19:42:33 +0000 Date: Tue, 27 Feb 2001 19:42:33 +0000 From: Tony Finch To: "Daniel C. Sobral" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. Message-ID: <20010227194233.J609@hand.dotat.at> References: <200102260529.f1Q5T8413011@curve.dellroad.org> <200102260628.f1Q6SYX29811@earth.backplane.com> <3A9A0A9A.E4D31F97@newsguy.com> <200102261755.f1QHtvr34064@earth.backplane.com> <3A9AAB02.793A197A@newsguy.com> <200102261940.f1QJeJi38115@earth.backplane.com> <3A9B6548.E298F857@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A9B6548.E298F857@newsguy.com> Organization: Covalent Technologies, Inc Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" wrote: >Matt Dillon wrote: >> >> What is the point of running a scientific calculation if the >> machine turns into a sludge pile and would otherwise cause the >> calculation to take years to complete instead of days? > >It doesn't trash. The memory is filled with backtracking information. >Memory in active use at any time is rather small. I've read articles about programs which use GC which have a small working set, although it is constantly changing (I've heard of programs allocating megabytes a second). The OS would have to swap out the stale pages if the program's total memory use exceeds RAM, and when the GC finally runs it will take forever and thrash swap like there's no tomorrow. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at THAMES: EAST OR SOUTHEAST 3 OR 4. RAIN. MODERATE OR GOOD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 11:53:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from nebula.cybercable.fr (d217.dhcp212-126.cybercable.fr [212.198.126.217]) by hub.freebsd.org (Postfix) with ESMTP id C982137B719 for ; Tue, 27 Feb 2001 11:53:24 -0800 (PST) (envelope-from mux@qualys.com) Received: (from mux@localhost) by nebula.cybercable.fr (8.11.2/8.11.2) id f1RJrAQ02032 for hackers@freebsd.org; Tue, 27 Feb 2001 20:53:10 +0100 (CET) (envelope-from mux) Date: Tue, 27 Feb 2001 20:53:09 +0100 From: Maxime Henrion To: hackers@freebsd.org Subject: talk(1) patch to allow 8bits characters Message-ID: <20010227205309.D345@nebula.cybercable.fr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, talk(1) uses the isprint() function to determine if a character is printable. If it's not, it outputs '^' followed by the character without his 8th bit. However, isprint() and friends are broken currently on FreeBSD (at least on -STABLE), so it will never recognize an accentued character as printable. The attached patch remove the isprint() test so that it's possible to write special characters. It also removes the now useless setlocale() call and headers. When locale support will be complete, I'm volunteer to re-introduce this check if someone thinks it's really worth it. Could someone review this ? Thanks, Maxime -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code Key fingerprint = F9B6 1D5A 4963 331C 88FC CA6A AB50 1EF2 8CBE 99D6 Public Key : http://www.epita.fr/~henrio_m/ --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="talk.diff" diff -cr talk/display.c /usr/src/usr.bin/talk/display.c *** talk/display.c Tue Feb 27 20:35:30 2001 --- /usr/src/usr.bin/talk/display.c Tue Feb 27 20:39:02 2001 *************** *** 44,50 **** * displaying of text */ #include "talk.h" - #include xwin_t my_win; xwin_t his_win; --- 44,49 ---- *************** *** 150,162 **** text++; continue; } ! if (!isprint((unsigned char)*text) && *text != '\t') { ! waddch(win->x_win, '^'); ! getyx(win->x_win, win->x_line, win->x_col); ! cch = (*text & 63) + 64; ! waddch(win->x_win, cch); ! } else ! waddch(win->x_win, (unsigned char)*text); getyx(win->x_win, win->x_line, win->x_col); text++; } --- 149,155 ---- text++; continue; } ! waddch(win->x_win, (unsigned char)*text); getyx(win->x_win, win->x_line, win->x_col); text++; } diff -cr talk/talk.c /usr/src/usr.bin/talk/talk.c *** talk/talk.c Tue Feb 27 20:35:30 2001 --- /usr/src/usr.bin/talk/talk.c Tue Feb 27 20:37:22 2001 *************** *** 46,52 **** #endif /* not lint */ #include "talk.h" - #include /* * talk: A visual form of write. Using sockets, a two way --- 46,51 ---- *************** *** 70,77 **** int argc; char *argv[]; { - (void) setlocale(LC_CTYPE, ""); - get_names(argc, argv); check_writeable(); init_display(); --- 69,74 ---- --2oS5YaxWCcQjTEyO-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 12: 1:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id BEB1737B71B for ; Tue, 27 Feb 2001 12:01:11 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p14-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.15]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id EAA19511; Wed, 28 Feb 2001 04:59:46 +0900 (JST) Message-ID: <3A9C0686.E4C80775@newsguy.com> Date: Wed, 28 Feb 2001 04:56:54 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Tony Finch Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102260529.f1Q5T8413011@curve.dellroad.org> <200102260628.f1Q6SYX29811@earth.backplane.com> <3A9A0A9A.E4D31F97@newsguy.com> <200102261755.f1QHtvr34064@earth.backplane.com> <3A9AAB02.793A197A@newsguy.com> <200102261940.f1QJeJi38115@earth.backplane.com> <3A9B6548.E298F857@newsguy.com> <20010227194233.J609@hand.dotat.at> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tony Finch wrote: > > >It doesn't trash. The memory is filled with backtracking information. > >Memory in active use at any time is rather small. > > I've read articles about programs which use GC which have a small > working set, although it is constantly changing (I've heard of > programs allocating megabytes a second). The OS would have to swap out > the stale pages if the program's total memory use exceeds RAM, and > when the GC finally runs it will take forever and thrash swap like > there's no tomorrow. It depends a lot on how allocation is made and the characteristics of the reachable objects graph. If the likeness of a reachable object existing in each page isn't small, it will trash indeed. On the other hand, if most objects created have very short lifetimes and a generational technique is used to move objects in the working set, then few pages of the swap will need to be swapped in for tracing, and the rest can be outright discarded without ever swaping them in. On the gripping hand, FreeBSD on configurations without swap is not unheard of by any means either, and overcommitting is still a problem in these configurations. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.obscure.bsdconspiracy.net I think you are delusional, but that is OK. Its part of your natural charm! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 12:23:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 4F73A37B71B for ; Tue, 27 Feb 2001 12:23:43 -0800 (PST) (envelope-from fanf@dotat.at) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14Xqdm-00045h-00; Tue, 27 Feb 2001 20:22:34 +0000 Date: Tue, 27 Feb 2001 20:22:34 +0000 From: Tony Finch To: Lyndon Nerenberg Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: [hackers] Re: Setting memory allocators for library functions. Message-ID: <20010227202234.K609@hand.dotat.at> References: <20010227013743.H609@hand.dotat.at> <200102271936.f1RJaFq98998@orthanc.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102271936.f1RJaFq98998@orthanc.ab.ca> Organization: Covalent Technologies, Inc Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Lyndon Nerenberg wrote: > >If the information in the data segment is going to be updated then >you have to have writable backing store. If, however, that data >is never going to be changed, it should be declared in the program >as read-only data. The kernel VM system should not be working around >applications that don't declare their data arena correctly. In most cases it is impossible to declare the data read-only because it originally had to be read-write and you can't change its attributes later. This is always the case for malloc(). Many applications do a load of initialization that requires read-write memory then never write to that memory again; when they fork the OS still has to account for that memory twice even if it is going to be immediately discarded by an exec(). An even more exaggerated example is Apache which forks a load of times then hangs around for ages. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at MALIN: NORTHEAST 7 TO SEVERE GALE 9, OCCASIONALLY STORM 10 IN SOUTHEAST AT FIRST, DECREASING 5. SNOW SHOWERS. GOOD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 12:46:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from chopper.Poohsticks.ORG (chopper.poohsticks.org [63.227.60.73]) by hub.freebsd.org (Postfix) with ESMTP id 78B0237B718 for ; Tue, 27 Feb 2001 12:46:43 -0800 (PST) (envelope-from drew@chopper.Poohsticks.ORG) Received: from chopper.Poohsticks.ORG (drew@localhost.poohsticks.org [127.0.0.1]) by chopper.Poohsticks.ORG (8.10.1/8.10.1) with ESMTP id f1RKi0n13690; Tue, 27 Feb 2001 13:44:00 -0700 Message-Id: <200102272044.f1RKi0n13690@chopper.Poohsticks.ORG> To: Tony Finch Cc: Lyndon Nerenberg , freebsd-hackers@FreeBSD.ORG Subject: Re: [hackers] Re: Setting memory allocators for library functions. In-reply-to: Your message of "Tue, 27 Feb 2001 20:22:34 GMT." <20010227202234.K609@hand.dotat.at> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13686.983306640.1@chopper.Poohsticks.ORG> Date: Tue, 27 Feb 2001 13:44:00 -0700 From: Drew Eckhardt Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010227202234.K609@hand.dotat.at>, dot@dotat.at writes: >In most cases it is impossible to declare the data read-only because >it originally had to be read-write and you can't change its attributes >later. mprotect(2). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 12:51:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from akira.lanfear.com (akira.lanfear.com [208.12.11.174]) by hub.freebsd.org (Postfix) with ESMTP id 4212D37B719 for ; Tue, 27 Feb 2001 12:51:17 -0800 (PST) (envelope-from mwlist@lanfear.com) Received: from sapporo.lanfear.com (h-64-105-36-216.snvacaid.covad.net [64.105.36.216]) by akira.lanfear.com (8.9.3/8.9.3) with SMTP id MAA42206; Tue, 27 Feb 2001 12:51:11 -0800 (PST) (envelope-from mwlist@lanfear.com) Date: Tue, 27 Feb 2001 12:51:11 -0800 (PST) From: Marc W Message-Id: <200102272051.MAA42206@akira.lanfear.com> To: Peter Dufault , Marc W Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Where can I find out rules on blocking in threads? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Kiltdown 0.7 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I think the FreeBSD behavior is wrong, the spec says that when > opening a FIFO with O_NONBLOCK clear that: > > > An open() for reading-only shall block the calling thread until a > > thread opens the file for writing. An open() for writing-only > > shall block the calling thread until a thread opens the file for > > reading. > > The FBSD man pages will let you know if something will block or > not, for example, look at the "implementation notes" section for > open. > You can open the fifo non-blocking and then clear O_NONBLOCK using > fcntl, hopefully that will work in all environments. I have tried this, but it gets even weirder then: - the call to open always succeeds right away (even when there are no threads on the write end of the fifo) - the immediately following call to read() also succeeds, returning 0 bytes as the number of bytes read. it gets worse -- when i change my loop to be: while (1) { fifo = open(fifoPath, O_RDONLY | O_NONBLOCK); cread = read(fifo, buf, sizeof(buf)); if (cread > 0) do_something(); close(fifo); usleep(100000); } anybody who tries to open the write end of the fifo ends up hanging .. argh! i'll keep investigating... my poor "2 hour solution to single instancing" is going into day 3 :-) marc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 13: 4:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id B946637B71B for ; Tue, 27 Feb 2001 13:04:23 -0800 (PST) (envelope-from usebsd@free.fr) Received: by smtp.nettoll.com; Tue, 27 Feb 2001 22:01:08 +0100 (MET) Message-Id: <4.3.0.20010227220128.0400f540@pop.free.fr> X-Sender: usebsd@pop.free.fr X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 27 Feb 2001 22:04:10 +0100 To: Peter Dufault From: mouss Subject: Re: Where can I find out rules on blocking in threads? Cc: Marc W , freebsd-hackers@FreeBSD.ORG In-Reply-To: <200102271454.f1REs5j22343@hda.hda.com> References: <4.3.0.20010227153039.00dd4f00@pop.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems ther's a problem here:) the manpage of open states ".... disables thread rescheduling...". Is this the explanation? As far as I can tell, Posix requires that some function should not block the process, and lists open(), fcntl(), ... Are there any pthread gurus who could give us the real truth here? cheers, mouss To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 13: 4:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id 84BEA37B71D for ; Tue, 27 Feb 2001 13:04:36 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.11.1/8.11.1) id f1RL2Sr24485; Tue, 27 Feb 2001 16:02:28 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200102272102.f1RL2Sr24485@hda.hda.com> Subject: Re: Where can I find out rules on blocking in threads? In-Reply-To: <200102272051.MAA42206@akira.lanfear.com> from Marc W at "Feb 27, 2001 12:51:11 pm" To: Marc W Date: Tue, 27 Feb 2001 16:02:28 -0500 (EST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I have tried this, but it gets even weirder then: > > - the call to open always succeeds right away (even when there are > no threads on the write end of the fifo) > - the immediately following call to read() also succeeds, returning > 0 bytes as the number of bytes read. > > > it gets worse -- when i change my loop to be: > > while (1) { > > fifo = open(fifoPath, O_RDONLY | O_NONBLOCK); > cread = read(fifo, buf, sizeof(buf)); > if (cread > 0) do_something(); > close(fifo); > usleep(100000); > } > > anybody who tries to open the write end of the fifo ends up hanging Set the FIFO blocking with fcntl(2) after you open it. I'll hack up my test program to be sure that works. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 13:13:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id A048E37B718 for ; Tue, 27 Feb 2001 13:13:35 -0800 (PST) (envelope-from fanf@dotat.at) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14XrPr-0004DP-00; Tue, 27 Feb 2001 21:12:15 +0000 Date: Tue, 27 Feb 2001 21:12:15 +0000 From: Tony Finch To: Drew Eckhardt Cc: Lyndon Nerenberg , freebsd-hackers@FreeBSD.ORG Subject: Re: [hackers] Re: Setting memory allocators for library functions. Message-ID: <20010227211215.M609@hand.dotat.at> References: <20010227202234.K609@hand.dotat.at> <200102272044.f1RKi0n13690@chopper.Poohsticks.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102272044.f1RKi0n13690@chopper.Poohsticks.ORG> Organization: Covalent Technologies, Inc Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Drew Eckhardt wrote: >In message <20010227202234.K609@hand.dotat.at>, dot@dotat.at writes: >>In most cases it is impossible to declare the data read-only because >>it originally had to be read-write and you can't change its attributes >>later. > >mprotect(2). If it's available at all, mprotect() is often limited to memory obtained with mmap(), i.e. not malloc(). Not great for portability. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at FORTH: NORTHEAST 6 TO GALE 8 DECREASING 5 OR 6. SLEET. MAINLY MODERATE. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 13:18:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from digital.csudsu.com (digital.csudsu.com [209.249.57.102]) by hub.freebsd.org (Postfix) with ESMTP id 0596C37B719 for ; Tue, 27 Feb 2001 13:18:47 -0800 (PST) (envelope-from stefan@csudsu.com) Received: by digital.csudsu.com (Postfix, from userid 1000) id 4E26A22E01; Tue, 27 Feb 2001 13:21:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by digital.csudsu.com (Postfix) with ESMTP id 436481F001; Tue, 27 Feb 2001 13:21:04 -0800 (PST) Date: Tue, 27 Feb 2001 13:21:04 -0800 (PST) From: Stefan Molnar To: Wes Peters Cc: Chris Shenton , Subject: Re: ThinkNIC booting FreeBSD? [WAS: Re: Silent FreeBSD] In-Reply-To: <3A9B5AD8.10EB0A1D@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes, you do not even need the flash to netboot, since it supports PXE. And it boots very nicely On Tue, 27 Feb 2001, Wes Peters wrote: > Chris Shenton wrote: > > > > In message <3A4B7498.267D52E8@softweyr.com> Wes Peters writes: > > > > > We have several NIC's around here (the New Internet Computer, see > > > http://www.thinknic.com/ for details) and will be adding a couple of these > > > so we can boot FreeBSD or NetBSD on them in the next little while. A NIC > > > running FreeBSD on a silent CF disk strikes me as an ideal bedroom computer; > > > you can leave it on all the time and just let the screen sleep when you're > > > not using it. > > > > Been thinking seriously about buying a couple of these; hard to beat > > the $200 price point. Chat on one of the NIC lists indicates they had > > two fans and will now ship with three fans; this seems like it will > > make it rather noisey -- especially since they're diskless and should > > be quiet. > > They are quiet. I didn't notice any fans in the ones we disassembled at > work. The Geode processor runs QUITE hot, though. They make good hand- > warmers when it's snowing outside. > > > Since I prefer FreeBSD to Linux, I'd rather run BSD than the Linux on > > the CD it runs from. Is it possible to create an ISO of a bootable > > and runnable FreeBSD? What happens with stuff like /tmp and /var/log? > > You wouldn't want it; performance running off the CD-ROM is terrible. > Get a 2.5" hard drive and stick it to the case top with double-sticky > tape. > > > Failing this, I'd probably net-boot the NICs off a bigger FreeBSD > > machine, and NFS mount /home dirs and /usr/local type of software. > > That would probably give you better performance than the CD-ROM. The > NIC has a small flash disk in it as well; you could probably put the > boot loader and enough /boot filesystem on that to autoboot. > > > That way when I built a tool or package it would be available to any > > of the FreeBSD boxes in the house. Seems like a great bang/buck > > ratio. Any comments on this approach? > > Sounds good to me. Maybe I should setup a netboot server at work and > have a hack at it. We've got a couple of IDE->CompactFlash adapters > I could play with without scrogging the NIC-standard flash device. > > -- > "Where am I, and what am I doing in this handbasket?" > > Wes Peters Softweyr LLC > wes@softweyr.com http://softweyr.com/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 13:25:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from nebula.cybercable.fr (d217.dhcp212-126.cybercable.fr [212.198.126.217]) by hub.freebsd.org (Postfix) with ESMTP id D5D6537B718 for ; Tue, 27 Feb 2001 13:25:10 -0800 (PST) (envelope-from mux@qualys.com) Received: (from mux@localhost) by nebula.cybercable.fr (8.11.2/8.11.2) id f1RLOsd02437; Tue, 27 Feb 2001 22:24:54 +0100 (CET) (envelope-from mux) Date: Tue, 27 Feb 2001 22:24:54 +0100 From: Maxime Henrion To: hackers@freebsd.org Cc: Tony Finch Subject: Re: [hackers] Re: Setting memory allocators for library functions. Message-ID: <20010227222454.G345@nebula.cybercable.fr> References: <20010227202234.K609@hand.dotat.at> <200102272044.f1RKi0n13690@chopper.Poohsticks.ORG> <20010227211215.M609@hand.dotat.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010227211215.M609@hand.dotat.at>; from dot@dotat.at on Tue, Feb 27, 2001 at 09:12:15PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tony Finch wrote: > Drew Eckhardt wrote: > >In message <20010227202234.K609@hand.dotat.at>, dot@dotat.at writes: > >>In most cases it is impossible to declare the data read-only because > >>it originally had to be read-write and you can't change its attributes > >>later. > > > >mprotect(2). > > If it's available at all, mprotect() is often limited to memory > obtained with mmap(), i.e. not malloc(). Not great for portability. FreeBSD malloc() calls mmap() as AFAIK many (if not all) malloc() implementations. Maxime -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code Key fingerprint = F9B6 1D5A 4963 331C 88FC CA6A AB50 1EF2 8CBE 99D6 Public Key : http://www.epita.fr/~henrio_m/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 13:28:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id 141AE37B719 for ; Tue, 27 Feb 2001 13:28:31 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.11.1/8.11.1) id f1RLQNH24622; Tue, 27 Feb 2001 16:26:23 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200102272126.f1RLQNH24622@hda.hda.com> Subject: Re: Where can I find out rules on blocking in threads? In-Reply-To: <200102272051.MAA42206@akira.lanfear.com> from Marc W at "Feb 27, 2001 12:51:11 pm" To: Marc W Date: Tue, 27 Feb 2001 16:26:23 -0500 (EST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > it gets worse -- when i change my loop to be: > > while (1) { > > fifo = open(fifoPath, O_RDONLY | O_NONBLOCK); > cread = read(fifo, buf, sizeof(buf)); > if (cread > 0) do_something(); > close(fifo); > usleep(100000); > } > > anybody who tries to open the write end of the fifo ends up hanging > .. It's a little messier than I hoped. As long as no one has opened the FIFO for write read returns a zero with errno clear. If you don't have time slicing turned on for the threads you'll hang forever. You'll have to do something like this: #include #include #include #include #include #include #include struct threadstuff { int rfid, wfid; const char *name; }; static void * reader(void *arg) { int flags; ssize_t r; char buff[32]; int cr; struct threadstuff *pts = (struct threadstuff *)arg; fprintf(stderr, "Opening %s for read, non-blocking...\n", pts->name); pts->rfid = open(pts->name, O_RDONLY | O_NONBLOCK); fprintf(stderr, "reader got fid %d, setting to blocking...\n", pts->rfid); (void)fcntl(pts->rfid, F_GETFL, &flags); flags &= ~O_NONBLOCK; (void)fcntl(pts->rfid, F_SETFL, &flags); fprintf(stderr, "Trying to read something from the FIFO...\n"); cr = 0; /* * You better have round robin turned on here or be sure * the writer is of higher priority or you'll just buzz * away the CPU. */ do { errno = 0; r = read(pts->rfid, buff, sizeof(buff) - 1); if (errno == 0 && r == 0) { /* No one has the FIFO open for write. * You should delay here (or preferably synchronize) * to avoid busy waiting. */ cr++; fprintf(stderr, "%s(%3d) No writer yet.\r", ((cr % 5) == 1) ? "\n" : "", cr); } } while (r == 0); if (r < 0) { perror("Read of FIFO"); } else { buff[r] = 0; fprintf(stderr, "Read \"%s\".\n", buff); } return 0; } static void * writer(void *arg) { char something[] = "Something"; struct threadstuff *pts = (struct threadstuff *)arg; fprintf(stderr, "Opening %s for write\n", pts->name); pts->wfid = open(pts->name, O_WRONLY); fprintf(stderr, "writer got fid %d.\n", pts->wfid); write(pts->wfid, something, sizeof(something)); return 0; } int main(int ac, char *av[]) { pthread_t r, w; void *value; struct threadstuff ts; ts.name = "./my_fifo"; ts.rfid = ts.wfid = -1; (void)unlink(ts.name); (void)mkfifo(ts.name, 0666); pthread_create(&r, 0, reader, (void *)&ts); pthread_create(&w, 0, writer, (void *)&ts); pthread_join(r, &value); pthread_join(w, &value); if (ts.rfid != -1) (void)close(ts.rfid); if (ts.wfid != -1) (void)close(ts.wfid); return 0; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 13:43:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from akira.lanfear.com (akira.lanfear.com [208.12.11.174]) by hub.freebsd.org (Postfix) with ESMTP id 5900237B719 for ; Tue, 27 Feb 2001 13:43:45 -0800 (PST) (envelope-from mwlist@lanfear.com) Received: from sapporo.lanfear.com (h-64-105-36-216.snvacaid.covad.net [64.105.36.216]) by akira.lanfear.com (8.9.3/8.9.3) with SMTP id NAA42419 for freebsd-hackers@FreeBSD.ORG; Tue, 27 Feb 2001 13:43:41 -0800 (PST) (envelope-from mwlist@lanfear.com) Date: Tue, 27 Feb 2001 13:43:41 -0800 (PST) From: Marc W Message-Id: <200102272143.NAA42419@akira.lanfear.com> To: freebsd-hackers@FreeBSD.ORG Subject: Re: Where can I find out rules on blocking in threads? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Kiltdown 0.7 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG just did some more testing -- the problem does appear to be FreeBSD specific. Solaris 8 and all the Linuxes I've got handy run this no probs. Don't have any openbsd or netbsd to test those out ... I'll just #ifdef in some code for FreeBSD. anybody know what #ifdef I should use before I start digging through headers? thanks :-) marc. > ----------------------------- > From: mouss > To: Peter Dufault > Cc: Marc W , freebsd-hackers@FreeBSD.ORG > Subject: Re: Where can I find out rules on blocking in threads? > Sent: 02/27/01 22:04> > > > It seems ther's a problem here:) > > the manpage of open states ".... disables thread rescheduling...". > Is this the explanation? > > As far as I can tell, Posix requires that some function should not > block the process, and lists open(), fcntl(), ... > > > Are there any pthread gurus who could give us the real truth here? > > cheers, > mouss > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 13:45:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from kiop.wiredmedia.co.uk (wiredmedia-2.dsl.easynet.co.uk [212.135.181.114]) by hub.freebsd.org (Postfix) with ESMTP id 2B57E37B71F for ; Tue, 27 Feb 2001 13:45:30 -0800 (PST) (envelope-from joe@tao.org.uk) Received: from tao.org.uk (postfix@genius.tao.org.uk [212.135.162.50] (may be forged)) by kiop.wiredmedia.co.uk (8.11.2/8.11.2) with ESMTP id f1RLpJ348693 for ; Tue, 27 Feb 2001 21:51:20 GMT (envelope-from joe@tao.org.uk) Received: by tao.org.uk (Postfix, from userid 100) id CFB50311D; Tue, 27 Feb 2001 21:41:00 +0000 (GMT) Date: Tue, 27 Feb 2001 21:41:00 +0000 From: Josef Karthauser To: hackers@freebsd.org Subject: rootdev problems with /boot/loader. Message-ID: <20010227214100.A850@tao.org.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I've got a bootable filesystem that although it's installed in the first slice on a disk the kernel/bootloader tries to mount /dev/ad0s2a as the root filesystem. I'm scratching my head as to why. Any ideas? It should be mounting /dev/ad0s1a automatically. The following are set by /boot/loader: rootdev=disk1s1a currdev=disk1s1a: Joe. p.s. This image is being booted via /dev/md0 in vmware. What I'm trying to work out is whether it's a bug in either of these parts. --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjqcHuwACgkQXVIcjOaxUBalVACeO1wWhv7s/FPY7cOo/7UUYALd 6s4AniPn++hkIwQszfYHTKtiWcbzlZgg =b9DY -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 13:49:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from faithful.dizzyd.com (c396142-a.lakwod2.co.home.com [24.183.233.142]) by hub.freebsd.org (Postfix) with ESMTP id 785F937B71A for ; Tue, 27 Feb 2001 13:49:18 -0800 (PST) (envelope-from dizzyd@dizzyd.com) Received: by faithful.dizzyd.com (Postfix, from userid 1000) id 05A58105F; Tue, 27 Feb 2001 14:49:16 -0700 (MST) Date: Tue, 27 Feb 2001 14:49:16 -0700 To: Marc W Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Where can I find out rules on blocking in threads? Message-ID: <20010227144916.A9254@dizzyd.com> Mail-Followup-To: Marc W , freebsd-hackers@FreeBSD.ORG References: <200102272143.NAA42419@akira.lanfear.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <200102272143.NAA42419@akira.lanfear.com>; from mwlist@lanfear.com on Tue, Feb 27, 2001 at 01:43:41PM -0800 From: dizzyd@dizzyd.com (Dave Smith) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, my understand (limited) of *BSD's threading systems is that they are not truly pre-emptive -- they use a scheme similar to PTH for forcing a single process to jump around its process space. Given this, it doesn't suprise me that a few system calls don't yield; possibly because they aren't wrapped properly; or maybe can't be wrapped. Of course, this is based on my _very_ limited knowledge... :) D. On Tue, Feb 27, 2001 at 01:43:41PM -0800, Marc W wrote: > > just did some more testing -- the problem does appear to be FreeBSD > specific. Solaris 8 and all the Linuxes I've got handy run this no > probs. Don't have any openbsd or netbsd to test those out ... > > I'll just #ifdef in some code for FreeBSD. anybody know what > #ifdef I should use before I start digging through headers? > > thanks :-) > > marc. > > > > > ----------------------------- > > From: mouss > > To: Peter Dufault > > Cc: Marc W , freebsd-hackers@FreeBSD.ORG > > > Subject: Re: Where can I find out rules on blocking in threads? > > Sent: 02/27/01 22:04> > > > > > > It seems ther's a problem here:) > > > > the manpage of open states ".... disables thread rescheduling...". > > Is this the explanation? > > > > As far as I can tell, Posix requires that some function should not > > block the process, and lists open(), fcntl(), ... > > > > > > Are there any pthread gurus who could give us the real truth here? > > > > cheers, > > mouss > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 14:16: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id BA00B37B719 for ; Tue, 27 Feb 2001 14:16:06 -0800 (PST) (envelope-from fanf@dotat.at) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14XsOW-0004MP-00; Tue, 27 Feb 2001 22:14:56 +0000 Date: Tue, 27 Feb 2001 22:14:56 +0000 From: Tony Finch To: Maxime Henrion Cc: hackers@freebsd.org Subject: Re: [hackers] Re: Setting memory allocators for library functions. Message-ID: <20010227221456.O609@hand.dotat.at> References: <20010227202234.K609@hand.dotat.at> <200102272044.f1RKi0n13690@chopper.Poohsticks.ORG> <20010227211215.M609@hand.dotat.at> <20010227211215.M609@hand.dotat.at>; <20010227222454.G345@nebula.cybercable.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010227222454.G345@nebula.cybercable.fr> Organization: Covalent Technologies, Inc Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Maxime Henrion wrote: >Tony Finch wrote: >> >> If it's available at all, mprotect() is often limited to memory >> obtained with mmap(), i.e. not malloc(). Not great for portability. > >FreeBSD malloc() calls mmap() as AFAIK many (if not all) malloc() >implementations. FreeBSD malloc() uses sbrk() for memory that it returns to the application and mmap() for book-keeping memory (the page index). Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at GERMAN BIGHT: SOUTHEAST 4 OR 5 BACKING NORTHEAST 5 OR 6. SLEET. MODERATE OR POOR. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 14:23:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peorth.iteration.net (peorth.iteration.net [208.190.180.178]) by hub.freebsd.org (Postfix) with ESMTP id BEC8137B71D for ; Tue, 27 Feb 2001 14:23:55 -0800 (PST) (envelope-from keichii@peorth.iteration.net) Received: by peorth.iteration.net (Postfix, from userid 1001) id 22FDF5954B; Tue, 27 Feb 2001 16:23:57 -0600 (CST) Date: Tue, 27 Feb 2001 16:23:57 -0600 From: "Michael C . Wu" To: Maxime Henrion Cc: hackers@freebsd.org Subject: Re: talk(1) patch to allow 8bits characters Message-ID: <20010227162357.A89484@peorth.iteration.net> Reply-To: "Michael C . Wu" References: <20010227205309.D345@nebula.cybercable.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010227205309.D345@nebula.cybercable.fr>; from mux@qualys.com on Tue, Feb 27, 2001 at 08:53:09PM +0100 X-PGP-Fingerprint: 5025 F691 F943 8128 48A8 5025 77CE 29C5 8FA1 2E20 X-PGP-Key-ID: 0x8FA12E20 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 27, 2001 at 08:53:09PM +0100, Maxime Henrion scribbled: | talk(1) uses the isprint() function to determine if a character is | printable. If it's not, it outputs '^' followed by the character without | his 8th bit. However, isprint() and friends are broken currently on | FreeBSD (at least on -STABLE), so it will never recognize an accentued | character as printable. isprint() has been broken for a long long time. Clive Lin was about to fix it. I know that we have been slacking, but please give us some time. | The attached patch remove the isprint() test so that it's possible to | write special characters. It also removes the now useless setlocale() | call and headers. Have you tried setenv LC_CTYPE=en_US.ISO-8859-1 before starting talk(1) and typing 8-bit chars? For most cases, this will work for 8-bit chars. (Yes, it is _*BADLY*_ broken.) | When locale support will be complete, I'm volunteer to re-introduce | this check if someone thinks it's really worth it. | | Could someone review this ? Sorry, the fact that you remove #include and the check for LC_CTYPE makes this patch somewhat hard to accept. However, I can accept a "talk-i18n" port that will go into the ports temporarily until we fix isprint(). Would this be acceptable for you? We can arrange to commit it as a port with you or I as the maintainer. -- +------------------------------------------------------------------+ | keichii@peorth.iteration.net | keichii@bsdconspiracy.net | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +------------------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 14:44:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id D341737B718 for ; Tue, 27 Feb 2001 14:44:22 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f1RMekl87450; Tue, 27 Feb 2001 14:40:46 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010227214100.A850@tao.org.uk> Date: Tue, 27 Feb 2001 14:44:04 -0800 (PST) From: John Baldwin To: Josef Karthauser Subject: RE: rootdev problems with /boot/loader. Cc: hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 27-Feb-01 Josef Karthauser wrote: > I've got a bootable filesystem that although it's installed in the first > slice on a disk the kernel/bootloader tries to mount /dev/ad0s2a as the > root filesystem. I'm scratching my head as to why. Any ideas? > It should be mounting /dev/ad0s1a automatically. > > The following are set by /boot/loader: > rootdev=disk1s1a > currdev=disk1s1a: > > Joe. > > p.s. This image is being booted via /dev/md0 in vmware. What I'm > trying to work out is whether it's a bug in either of these parts. What does 'lsdev' show. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 14:54:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from nebula.cybercable.fr (d217.dhcp212-126.cybercable.fr [212.198.126.217]) by hub.freebsd.org (Postfix) with ESMTP id 5730E37B71A for ; Tue, 27 Feb 2001 14:54:06 -0800 (PST) (envelope-from mux@qualys.com) Received: (from mux@localhost) by nebula.cybercable.fr (8.11.2/8.11.2) id f1RMrhb03155; Tue, 27 Feb 2001 23:53:43 +0100 (CET) (envelope-from mux) Date: Tue, 27 Feb 2001 23:53:42 +0100 From: Maxime Henrion To: hackers@freebsd.org Cc: "Michael C . Wu" Subject: Re: talk(1) patch to allow 8bits characters Message-ID: <20010227235342.H345@nebula.cybercable.fr> References: <20010227205309.D345@nebula.cybercable.fr> <20010227162357.A89484@peorth.iteration.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010227162357.A89484@peorth.iteration.net>; from keichii@iteration.net on Tue, Feb 27, 2001 at 04:23:57PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Michael C . Wu wrote: > On Tue, Feb 27, 2001 at 08:53:09PM +0100, Maxime Henrion scribbled: > isprint() has been broken for a long long time. Clive Lin > was about to fix it. I know that > we have been slacking, but please give us some time. Of course, this was only meant as a temporary solution, if isprint() is going to be fixed soon then it's probably useless. I would like to see this working for 4.3-RELEASE though, that's why I posted this patch. > Have you tried setenv LC_CTYPE=en_US.ISO-8859-1 before starting > talk(1) and typing 8-bit chars? For most cases, this will work > for 8-bit chars. (Yes, it is _*BADLY*_ broken.) It unfortunately doesn't help here. > Sorry, the fact that you remove #include and the > check for LC_CTYPE makes this patch somewhat hard to accept. I can understand this. > However, I can accept a "talk-i18n" port that will go into the > ports temporarily until we fix isprint(). Would this be acceptable > for you? We can arrange to commit it as a port with you or I as > the maintainer. If you think it makes sense, I'd be glad to maintain such a port. Thanks, Maxime -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code Key fingerprint = F9B6 1D5A 4963 331C 88FC CA6A AB50 1EF2 8CBE 99D6 Public Key : http://www.epita.fr/~henrio_m/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 14:59: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id D200937B71A for ; Tue, 27 Feb 2001 14:59:00 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1RMwmF67311; Tue, 27 Feb 2001 14:58:48 -0800 (PST) (envelope-from dillon) Date: Tue, 27 Feb 2001 14:58:48 -0800 (PST) From: Matt Dillon Message-Id: <200102272258.f1RMwmF67311@earth.backplane.com> To: Maxime Henrion Cc: hackers@FreeBSD.ORG Subject: Re: talk(1) patch to allow 8bits characters References: <20010227205309.D345@nebula.cybercable.fr> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is an extremely dangerous patch. A number of terminal protocols have a 'talkback' escape sequence that allow you to write data that the terminal then copies back as if someone typed it. I remember using this feature quite a lot while at Berkeley to, ah, break into people's accounts :-) isprintf() is in there to prevent extranious escape sequences from blowing up the other guy's window. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 15:12: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from nebula.cybercable.fr (d217.dhcp212-126.cybercable.fr [212.198.126.217]) by hub.freebsd.org (Postfix) with ESMTP id 2C48A37B71B for ; Tue, 27 Feb 2001 15:11:53 -0800 (PST) (envelope-from mux@qualys.com) Received: (from mux@localhost) by nebula.cybercable.fr (8.11.2/8.11.2) id f1RNBco03327; Wed, 28 Feb 2001 00:11:38 +0100 (CET) (envelope-from mux) Date: Wed, 28 Feb 2001 00:11:37 +0100 From: Maxime Henrion To: hackers@freebsd.org Cc: Matt Dillon Subject: Re: talk(1) patch to allow 8bits characters Message-ID: <20010228001137.I345@nebula.cybercable.fr> References: <20010227205309.D345@nebula.cybercable.fr> <200102272258.f1RMwmF67311@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102272258.f1RMwmF67311@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Feb 27, 2001 at 02:58:48PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote: > This is an extremely dangerous patch. A number of terminal protocols > have a 'talkback' escape sequence that allow you to write data > that the terminal then copies back as if someone typed it. I remember > using this feature quite a lot while at Berkeley to, ah, break into > people's accounts :-) > > isprintf() is in there to prevent extranious escape sequences from > blowing up the other guy's window. > -Matt I wasn't aware of this at all. I will know now, thanks :-) Maxime -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code Key fingerprint = F9B6 1D5A 4963 331C 88FC CA6A AB50 1EF2 8CBE 99D6 Public Key : http://www.epita.fr/~henrio_m/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 15:22:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from kiop.wiredmedia.co.uk (wiredmedia-2.dsl.easynet.co.uk [212.135.181.114]) by hub.freebsd.org (Postfix) with ESMTP id 6D3B037B71C; Tue, 27 Feb 2001 15:22:54 -0800 (PST) (envelope-from joe@tao.org.uk) Received: from tao.org.uk (postfix@genius.tao.org.uk [212.135.162.50] (may be forged)) by kiop.wiredmedia.co.uk (8.11.2/8.11.2) with ESMTP id f1RNSl348771; Tue, 27 Feb 2001 23:28:49 GMT (envelope-from joe@tao.org.uk) Received: by tao.org.uk (Postfix, from userid 100) id 4C9EA311D; Tue, 27 Feb 2001 23:22:50 +0000 (GMT) Date: Tue, 27 Feb 2001 23:22:49 +0000 From: Josef Karthauser To: John Baldwin Cc: hackers@FreeBSD.org Subject: Re: rootdev problems with /boot/loader. Message-ID: <20010227232249.A86753@tao.org.uk> References: <20010227214100.A850@tao.org.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Tue, Feb 27, 2001 at 02:44:04PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 27, 2001 at 02:44:04PM -0800, John Baldwin wrote: >=20 > On 27-Feb-01 Josef Karthauser wrote: > >=20 > > p.s. This image is being booted via /dev/md0 in vmware. What I'm > > trying to work out is whether it's a bug in either of these parts. >=20 > What does 'lsdev' show. That's probably it. I'm using devfs on the kernel, and I'll bet it hasn't created ad0s1a at mount time. It works if I specify it ufs:/dev/ad0s1a, but not automatically. I rebuilt another image on s2 instead of s1 and that booted fine. I'll take a look at lsdev tomorrow when I do the next build, but I'm betting that this is what it is. Joe --jRHKVT23PllUwdXP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjqcNsgACgkQXVIcjOaxUBbfEQCg7ewKOJhSp9EvACCrkyUqhUFz FckAn0PCHgun0toLWUMES8JzYccjby72 =DlJc -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 15:49:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id 0CB4937B719; Tue, 27 Feb 2001 15:49:27 -0800 (PST) (envelope-from ps@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1000) id 2A1CB81D02; Tue, 27 Feb 2001 17:49:26 -0600 (CST) Date: Tue, 27 Feb 2001 15:49:26 -0800 From: Paul Saab To: Josef Karthauser Cc: John Baldwin , hackers@FreeBSD.org Subject: Re: rootdev problems with /boot/loader. Message-ID: <20010227154926.A28148@elvis.mu.org> References: <20010227214100.A850@tao.org.uk> <20010227232249.A86753@tao.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010227232249.A86753@tao.org.uk>; from joe@tao.org.uk on Tue, Feb 27, 2001 at 11:22:49PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG root.vfs.mountrootfrom="ufs:/dev/ad0s1a" paul Josef Karthauser (joe@tao.org.uk) wrote: > On Tue, Feb 27, 2001 at 02:44:04PM -0800, John Baldwin wrote: > > > > On 27-Feb-01 Josef Karthauser wrote: > > > > > > p.s. This image is being booted via /dev/md0 in vmware. What I'm > > > trying to work out is whether it's a bug in either of these parts. > > > > What does 'lsdev' show. > > That's probably it. I'm using devfs on the kernel, and I'll bet > it hasn't created ad0s1a at mount time. It works if I specify it > ufs:/dev/ad0s1a, but not automatically. > > I rebuilt another image on s2 instead of s1 and that booted fine. > > I'll take a look at lsdev tomorrow when I do the next build, but > I'm betting that this is what it is. > > Joe -- Paul Saab Technical Yahoo paul@mu.org - ps@yahoo-inc.com - ps@freebsd.org Do You .. uhh .. Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 15:51: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id 5ED3737B71B; Tue, 27 Feb 2001 15:51:03 -0800 (PST) (envelope-from ps@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1000) id 30AB881D02; Tue, 27 Feb 2001 17:51:03 -0600 (CST) Date: Tue, 27 Feb 2001 15:51:03 -0800 From: Paul Saab To: Josef Karthauser Cc: John Baldwin , hackers@FreeBSD.org Subject: Re: rootdev problems with /boot/loader. Message-ID: <20010227155103.A28359@elvis.mu.org> References: <20010227214100.A850@tao.org.uk> <20010227232249.A86753@tao.org.uk> <20010227154926.A28148@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010227154926.A28148@elvis.mu.org>; from ps@mu.org on Tue, Feb 27, 2001 at 03:49:26PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Oops. make that vfs.root.mountrootfrom="ufs:/dev/ad0s1a" Paul Saab (ps@mu.org) wrote: > root.vfs.mountrootfrom="ufs:/dev/ad0s1a" > > paul > > Josef Karthauser (joe@tao.org.uk) wrote: > > On Tue, Feb 27, 2001 at 02:44:04PM -0800, John Baldwin wrote: > > > > > > On 27-Feb-01 Josef Karthauser wrote: > > > > > > > > p.s. This image is being booted via /dev/md0 in vmware. What I'm > > > > trying to work out is whether it's a bug in either of these parts. > > > > > > What does 'lsdev' show. > > > > That's probably it. I'm using devfs on the kernel, and I'll bet > > it hasn't created ad0s1a at mount time. It works if I specify it > > ufs:/dev/ad0s1a, but not automatically. > > > > I rebuilt another image on s2 instead of s1 and that booted fine. > > > > I'll take a look at lsdev tomorrow when I do the next build, but > > I'm betting that this is what it is. > > > > Joe > > > > -- > Paul Saab > Technical Yahoo > paul@mu.org - ps@yahoo-inc.com - ps@freebsd.org > Do You .. uhh .. Yahoo!? > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- Paul Saab Technical Yahoo paul@mu.org - ps@yahoo-inc.com - ps@freebsd.org Do You .. uhh .. Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 18:11:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 92F0937B718; Tue, 27 Feb 2001 18:11:46 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.2/8.11.2) with ESMTP id f1S1xX455382; Wed, 28 Feb 2001 02:00:48 GMT (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.2/8.11.2) with ESMTP id f1S21Fn01559; Wed, 28 Feb 2001 02:01:15 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200102280201.f1S21Fn01559@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Robert Watson Cc: Drew Eckhardt , David Rufino , hackers@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: character device driver In-Reply-To: Message from Robert Watson of "Mon, 19 Feb 2001 00:22:57 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Feb 2001 02:01:15 +0000 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [.....] > In my mind, it is important that (in the general case) we provide a struct > file state hook rather than having per-process state, to allow things like > threads, process teams, aio, file descriptor passing, etc, to work > properly. One advantage to tying VFS statefulness to device statefulness > is you get some nice benefits like guarantees about open/close pairs on > devices. I think there aren't too many VFS complications -- the only > complications might be if vnodes are ever used for relevant calls > (ioctl, read, write, ...) without a VOP_OPEN first -- a few used to exist > but I think those have been cleaned up. IMHO phk's recent suggestion on -arch was excellent. The idea is that a driver calls make_dev() with some sort of CLONE flag. When a lookup() happens and devfs sees that the path points to such a device, it asks the driver for a udev_t. The driver may (if it wants to) call make_dev(), and then returns the udev_t. devfs creates the vnode and returns it to the caller. The VOP_OPEN then happens as usual. (I'm not sure what magic devfs needs to do with the nameidata at this point). The good thing about this is that the driver gets to declare a minor as being a CLONE device and gets to choose whether it'll return a new minor or not for the imminent open(). fork(), exec() and dup*() will make new references to the same vnode, as will open()s of the device if the driver did a make_dev(). Some sort of locking will be required so that the driver can handle udev_t requests while others are outstanding... I'd like to implement something (if I ever get the time) and post patches to -arch & phk, as this seems to solve all the problems I know of :-) > Robert N M Watson FreeBSD Core Team, TrustedBSD Project > robert@fledge.watson.org NAI Labs, Safeport Network Services -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 19:14:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from akira.lanfear.com (akira.lanfear.com [208.12.11.174]) by hub.freebsd.org (Postfix) with ESMTP id 14C1237B719 for ; Tue, 27 Feb 2001 19:14:40 -0800 (PST) (envelope-from mwlist@lanfear.com) Received: from sapporo.lanfear.com (h-64-105-36-216.snvacaid.covad.net [64.105.36.216]) by akira.lanfear.com (8.9.3/8.9.3) with SMTP id TAA43386 for freebsd-hackers@freebsd.org; Tue, 27 Feb 2001 19:14:39 -0800 (PST) (envelope-from mwlist@lanfear.com) Date: Tue, 27 Feb 2001 19:14:39 -0800 (PST) From: Marc W Message-Id: <200102280314.TAA43386@akira.lanfear.com> To: freebsd-hackers@freebsd.org Subject: Generating Core Dump Programmatically MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Kiltdown 0.7 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm trying to ensure robust shutdown on my machine. Thus, I've installed signal handlers for a bunch of nasty looking signals. In my new handler, after all critical state is saved, I then call abort(3), and all seems to work well. EXCEPT -- some signals generate core files when left with the default behaviour. Is there some straightforward way to do this? thanks. marc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 22: 7:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id B497337B718 for ; Tue, 27 Feb 2001 22:07:39 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14XzwS-0000Fo-00; Tue, 27 Feb 2001 23:18:28 -0700 Message-ID: <3A9C9834.6D95C4C2@softweyr.com> Date: Tue, 27 Feb 2001 23:18:28 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Stefan Molnar Cc: Chris Shenton , hackers@FreeBSD.ORG Subject: Re: ThinkNIC booting FreeBSD? [WAS: Re: Silent FreeBSD] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Stefan Molnar wrote: > > Wes, you do not even need the flash to netboot, since it supports > PXE. And it boots very nicely Oh, cool. Is the boot rom on the machine, or is there a socket there somewhere? Where can I get a ROM image? Netbooting FreeBSD on our several NICs at work would probably make them much faster than running leeenoooks off the CD-ROM. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 22:11:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from digital.csudsu.com (digital.csudsu.com [209.249.57.102]) by hub.freebsd.org (Postfix) with ESMTP id 3B43637B71B for ; Tue, 27 Feb 2001 22:11:29 -0800 (PST) (envelope-from stefan@csudsu.com) Received: by digital.csudsu.com (Postfix, from userid 1000) id 8961122E01; Tue, 27 Feb 2001 22:13:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by digital.csudsu.com (Postfix) with ESMTP id 7A4D11F001; Tue, 27 Feb 2001 22:13:46 -0800 (PST) Date: Tue, 27 Feb 2001 22:13:46 -0800 (PST) From: Stefan Molnar To: Wes Peters Cc: Chris Shenton , Subject: Re: ThinkNIC booting FreeBSD? [WAS: Re: Silent FreeBSD] In-Reply-To: <3A9C9834.6D95C4C2@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Just turn on network boot in the bios, and setup the server for a PXE Client. No hardware to add. On Tue, 27 Feb 2001, Wes Peters wrote: > Stefan Molnar wrote: > > > > Wes, you do not even need the flash to netboot, since it supports > > PXE. And it boots very nicely > > Oh, cool. Is the boot rom on the machine, or is there a socket there > somewhere? Where can I get a ROM image? Netbooting FreeBSD on our > several NICs at work would probably make them much faster than running > leeenoooks off the CD-ROM. > > -- > "Where am I, and what am I doing in this handbasket?" > > Wes Peters Softweyr LLC > wes@softweyr.com http://softweyr.com/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 22:27:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id E289637B71A for ; Tue, 27 Feb 2001 22:27:16 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14Y0FQ-0000GO-00; Tue, 27 Feb 2001 23:38:04 -0700 Message-ID: <3A9C9CCC.4F9B521D@softweyr.com> Date: Tue, 27 Feb 2001 23:38:04 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: adsharma@sharmas.dhs.org, dillon@earth.backplane.com, hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. References: <200102260529.f1Q5T8413011@curve.dellroad.org> <200102261755.f1QHtvr34064@earth.backplane.com> <200102270624.WAA17949@c62443-a.frmt1.sfba.home.com> <3A9BAAF9.C75B39BF@elischer.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > Arun Sharma wrote: > > > > On 26 Feb 2001 18:56:18 +0100, Matt Dillon wrote: > > > Ha. Right. Go through any piece of significant code and just see how > > > much goes flying out the window because the code wants to simply assume > > > things work. Then try coding conditionals all the way through to fix > > > it... and don't forget you need to propogate the error condition back > > > up the procedure chain too so the original caller knows why it failed. > > > > So, it all comes down to reimplementing the UNIX kernel in a language > > that supports exceptions, just like Linus suggested :) > > I've often considered writing a language SPECIFICALLY for writing the kernel. > (no other uses) > > I mean it basically uses the same mechaninsims over and over and over again... > > linked lists, hash tables, nested loops, etc.etc. > > I'd like a language that lets me define the module I'm writing, > define the way it should behave, and let the boring code be taken care of > by itelf :-) Oh, like C++ & STL? /me ducks and runs, trying not to gag. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 27 22:39:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from syncopation-03.iinet.net.au (syncopation-03.iinet.net.au [203.59.24.49]) by hub.freebsd.org (Postfix) with SMTP id B7E4637B71A for ; Tue, 27 Feb 2001 22:39:17 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 16267 invoked by uid 666); 28 Feb 2001 06:51:10 -0000 Received: from i003-146.nv.iinet.net.au (HELO elischer.org) (203.59.3.146) by mail.m.iinet.net.au with SMTP; 28 Feb 2001 06:51:10 -0000 Message-ID: <3A9C9D11.854BCD5@elischer.org> Date: Tue, 27 Feb 2001 22:39:13 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Wes Peters Cc: adsharma@sharmas.dhs.org, dillon@earth.backplane.com, hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. References: <200102260529.f1Q5T8413011@curve.dellroad.org> <200102261755.f1QHtvr34064@earth.backplane.com> <200102270624.WAA17949@c62443-a.frmt1.sfba.home.com> <3A9BAAF9.C75B39BF@elischer.org> <3A9C9CCC.4F9B521D@softweyr.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters wrote: > > Julian Elischer wrote: > > > > Arun Sharma wrote: > > > > > > On 26 Feb 2001 18:56:18 +0100, Matt Dillon wrote: > > > > Ha. Right. Go through any piece of significant code and just see how > > > > much goes flying out the window because the code wants to simply assume > > > > things work. Then try coding conditionals all the way through to fix > > > > it... and don't forget you need to propogate the error condition back > > > > up the procedure chain too so the original caller knows why it failed. > > > > > > So, it all comes down to reimplementing the UNIX kernel in a language > > > that supports exceptions, just like Linus suggested :) > > > > I've often considered writing a language SPECIFICALLY for writing the kernel. > > (no other uses) > > > > I mean it basically uses the same mechaninsims over and over and over again... > > > > linked lists, hash tables, nested loops, etc.etc. > > > > I'd like a language that lets me define the module I'm writing, > > define the way it should behave, and let the boring code be taken care of > > by itelf :-) > > Oh, like C++ & STL? > > /me ducks and runs, trying not to gag. no, something specifically designed around kernel type of actions. declarations of "physical pointer", "kvm pointer" "User Pointer" for example, and being able to declare a structure (not 'struct') and say "this list is 'per process'" and have the list head automatically in the proc struct without haviong to add it there.. i.e backwards from today.. > > -- > "Where am I, and what am I doing in this handbasket?" > > Wes Peters Softweyr LLC > wes@softweyr.com http://softweyr.com/ -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 1:20:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from kiop.wiredmedia.co.uk (wiredmedia-2.dsl.easynet.co.uk [212.135.181.114]) by hub.freebsd.org (Postfix) with ESMTP id 5952137B718; Wed, 28 Feb 2001 01:20:40 -0800 (PST) (envelope-from joe@tao.org.uk) Received: from tao.org.uk (postfix@genius.tao.org.uk [212.135.162.50] (may be forged)) by kiop.wiredmedia.co.uk (8.11.2/8.11.2) with ESMTP id f1S9QV349656; Wed, 28 Feb 2001 09:26:33 GMT (envelope-from joe@tao.org.uk) Received: by tao.org.uk (Postfix, from userid 100) id E357B311D; Wed, 28 Feb 2001 09:20:33 +0000 (GMT) Date: Wed, 28 Feb 2001 09:20:33 +0000 From: Josef Karthauser To: Paul Saab Cc: John Baldwin , hackers@FreeBSD.org Subject: Re: rootdev problems with /boot/loader. Message-ID: <20010228092033.B86753@tao.org.uk> References: <20010227214100.A850@tao.org.uk> <20010227232249.A86753@tao.org.uk> <20010227154926.A28148@elvis.mu.org> <20010227155103.A28359@elvis.mu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="4SFOXa2GPu3tIq4H" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010227155103.A28359@elvis.mu.org>; from ps@mu.org on Tue, Feb 27, 2001 at 03:51:03PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --4SFOXa2GPu3tIq4H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Feb 27, 2001 at 03:51:03PM -0800, Paul Saab wrote: > Oops. > make that > vfs.root.mountrootfrom="ufs:/dev/ad0s1a" Thanks Paul Joe --4SFOXa2GPu3tIq4H Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjqcwt8ACgkQXVIcjOaxUBb+dACgvDjTgCzCwFNGBaTFdGf5fW7N 6+gAoM/MiPfEnED8EOSWDW3mLGng6vts =G6Jp -----END PGP SIGNATURE----- --4SFOXa2GPu3tIq4H-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 2:47:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (Postfix) with ESMTP id 640D337B718 for ; Wed, 28 Feb 2001 02:47:29 -0800 (PST) (envelope-from michael.schuster@Sun.COM) Received: from ms-emuc07-01.Germany.Sun.COM ([129.157.128.14]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA00395 for ; Wed, 28 Feb 2001 02:47:26 -0800 (PST) Received: from Sun.COM (hacker [129.157.133.195]) by ms-emuc07-01.Germany.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07636 for ; Wed, 28 Feb 2001 11:47:39 +0100 (MET) Message-ID: <3A9CD73D.655A4A53@Sun.COM> Date: Wed, 28 Feb 2001 11:47:25 +0100 From: michael schuster Organization: Sun Microsystems X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote: > Allowing a program to run the OS itself out of VM, with or without > overcommit, is (being generous) just plain dumb. I'm not a fan of either (overcommit or non-), I can see advantages with both (seeing that Solaris, which I happen to work with, has one and FreeBSD the other), but your last remark does beg an answer: In a non-dedicated environment (ie a general-purpose Unix machine), it's the mix of applications that brings down your memory, not a single one. In such a situation I can imagine synchronous information to the effect "you're out of swapable memory" to be practical (that's the way Solaris implements it). I haven't thought this out in detail, but I also imagine it easier to handle ENOMEM than SIGDANGER, because of the synchronous nature of the first versus the asynchronous nature of the second. just my 2 euro cents Michael -- Michael Schuster / Michael.Schuster@sun.com Sun Microsystems GmbH / (+49 89) 46008-2974 | x62974 Sonnenallee 1, D-85551 Kirchheim-Heimstetten Recursion, n.: see 'Recursion' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 3:32:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from kiop.wiredmedia.co.uk (wiredmedia-2.dsl.easynet.co.uk [212.135.181.114]) by hub.freebsd.org (Postfix) with ESMTP id D4BC237B719; Wed, 28 Feb 2001 03:32:18 -0800 (PST) (envelope-from joe@tao.org.uk) Received: from tao.org.uk (postfix@genius.tao.org.uk [212.135.162.50] (may be forged)) by kiop.wiredmedia.co.uk (8.11.2/8.11.2) with ESMTP id f1SBc9372082; Wed, 28 Feb 2001 11:38:11 GMT (envelope-from joe@tao.org.uk) Received: by tao.org.uk (Postfix, from userid 100) id 0AC3B313C; Wed, 28 Feb 2001 11:32:03 +0000 (GMT) Date: Wed, 28 Feb 2001 11:32:02 +0000 From: Josef Karthauser To: John Baldwin Cc: hackers@FreeBSD.org Subject: Re: rootdev problems with /boot/loader. Message-ID: <20010228113202.A32458@tao.org.uk> References: <20010227214100.A850@tao.org.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Tue, Feb 27, 2001 at 02:44:04PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 27, 2001 at 02:44:04PM -0800, John Baldwin wrote: >=20 > On 27-Feb-01 Josef Karthauser wrote: > > I've got a bootable filesystem that although it's installed in the first > > slice on a disk the kernel/bootloader tries to mount /dev/ad0s2a as the > > root filesystem. I'm scratching my head as to why. Any ideas? > > It should be mounting /dev/ad0s1a automatically. > >=20 > > The following are set by /boot/loader: > > rootdev=3Ddisk1s1a > > currdev=3Ddisk1s1a: > >=20 > > Joe. > >=20 > > p.s. This image is being booted via /dev/md0 in vmware. What I'm > > trying to work out is whether it's a bug in either of these parts. >=20 > What does 'lsdev' show. Here's what lsdev shows: disk @ 0xf3e4 disk0: BIOS drive A: disk1: BIOS drive C: disk1s1a: FFS So why is it trying to book disk1s2a at mount time. /me's confused. Joe p.s. It's not devfs. It does the same thing with static dev nodes in /dev. --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjqc4bEACgkQXVIcjOaxUBZkPwCgxSDp2q7BJ0x934DCqfa4/GAg dcUAn0GUp/o3ICCNL8rKLy8wmI/zyxX7 =gTkO -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 3:46:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from kiop.wiredmedia.co.uk (wiredmedia-2.dsl.easynet.co.uk [212.135.181.114]) by hub.freebsd.org (Postfix) with ESMTP id 5BC1637B718; Wed, 28 Feb 2001 03:46:29 -0800 (PST) (envelope-from joe@tao.org.uk) Received: from tao.org.uk (postfix@genius.tao.org.uk [212.135.162.50] (may be forged)) by kiop.wiredmedia.co.uk (8.11.2/8.11.2) with ESMTP id f1SBqM372103; Wed, 28 Feb 2001 11:52:23 GMT (envelope-from joe@tao.org.uk) Received: by tao.org.uk (Postfix, from userid 100) id BF9903141; Wed, 28 Feb 2001 11:46:25 +0000 (GMT) Date: Wed, 28 Feb 2001 11:46:25 +0000 From: Josef Karthauser To: John Baldwin Cc: hackers@FreeBSD.org Subject: Re: rootdev problems with /boot/loader. Message-ID: <20010228114625.D32458@tao.org.uk> References: <20010227214100.A850@tao.org.uk> <20010228113202.A32458@tao.org.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="F8dlzb82+Fcn6AgP" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010228113202.A32458@tao.org.uk>; from joe@tao.org.uk on Wed, Feb 28, 2001 at 11:32:02AM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --F8dlzb82+Fcn6AgP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 28, 2001 at 11:32:02AM +0000, Josef Karthauser wrote: > > What does 'lsdev' show. >=20 > Here's what lsdev shows: >=20 > disk @ 0xf3e4 > disk0: BIOS drive A: > disk1: BIOS drive C: > disk1s1a: FFS >=20 > So why is it trying to book disk1s2a at mount time. /me's confused. Ahha! It looks like /boot/loader or the kernel sneaks a look at /etc/fstab to try and work out what to mount. :) I had /dev/ad0s2a in there for /. Changing it to /dev/ad0s1a fixed the boot. Joe --F8dlzb82+Fcn6AgP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjqc5REACgkQXVIcjOaxUBaQWACdEYyb0yV7KgEDMQ5qk/O0rxZ0 pYIAn1inOEWSh6cKECpSUR9lm30nCxjZ =2N1x -----END PGP SIGNATURE----- --F8dlzb82+Fcn6AgP-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 3:49:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id B63BE37B718 for ; Wed, 28 Feb 2001 03:49:26 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id MAA74956; Wed, 28 Feb 2001 12:49:17 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Tony Finch Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102230627.f1N6Rk618467@guild.plethora.net> <20010227012309.G609@hand.dotat.at> From: Dag-Erling Smorgrav Date: 28 Feb 2001 12:49:16 +0100 In-Reply-To: Tony Finch's message of "Tue, 27 Feb 2001 01:23:09 +0000" Message-ID: Lines: 9 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tony Finch writes: > What about setrlimit(RLIMIMT_DATA)? Yep, I'd forgotten about that. Malloc() will return NULL if you hit your data size limit. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 5: 7:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from heechee.tobez.org (254.adsl0.ryv.worldonline.dk [213.237.10.254]) by hub.freebsd.org (Postfix) with ESMTP id 2BFBA37B718 for ; Wed, 28 Feb 2001 05:07:52 -0800 (PST) (envelope-from tobez@tobez.org) Received: by heechee.tobez.org (Postfix, from userid 1001) id A7EDE54F4; Wed, 28 Feb 2001 14:07:49 +0100 (CET) Date: Wed, 28 Feb 2001 14:07:49 +0100 From: Anton Berezin To: hackers@freebsd.org Subject: how to actually find out whether data hit the disk? Message-ID: <20010228140749.B29400@heechee.tobez.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I am doing the following, on the partition with softupdates turned on: 1. fd = open("a file", O_CREAT) 2. mmap(fd) 3. sequencial write to mmapped region 4. some other processing 5. munmap 6. unlink 7. close Since this is a supposedly high-perfomance application, I am interested that data do NOT hit the disk. I understand that softupdates do a good job at that. The time taken by step 4 is usually sub-second, but sometimes it can take longer (network delays etc.). The question is - is it possible to actually find out whether data hit the disk or not for a particular run of 1-7? &Anton. -- May the tuna salad be with you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 5:33:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id C76B737B719 for ; Wed, 28 Feb 2001 05:33:06 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.11.1/8.11.1) id f1SDWPD27689 for hackers@freebsd.org; Wed, 28 Feb 2001 08:32:25 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200102281332.f1SDWPD27689@hda.hda.com> Subject: memorylocked resource (was "Setting memory allocators...") To: hackers@freebsd.org Date: Wed, 28 Feb 2001 08:31:49 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Why is the mlock(2) call restricted to the super user instead of enforcing it through per-user or per-login class limits? I was checking to see if most of the pieces were in place for "mlockall(MCL_FUTURE)" and noticed the "memorylocked infinity" setting in limits (I didn't know about memorylocked). Setting "memorylocked 0" for normal users is a flexible way to address this, then create a special class of programs that are permitted to do some locking. Along the same lines (matt probably knows the answer) is it easy to force paging in and locking down of any memory associated with a process so that mlockall(MCL_FUTURE) together with an appropriate memorylocked limit gives the requested memory semantics? I'd have to check through the specs to see how mmap() is supposed to play with mlockall(). Please leave aside most resource management issues for now, I'm assuming the main use for this is debugged small closed embedded systems, only bring up kickers. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 5:59:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id 0BEB737B718 for ; Wed, 28 Feb 2001 05:59:35 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.11.1/8.11.1) id f1SDvVW27830; Wed, 28 Feb 2001 08:57:31 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200102281357.f1SDvVW27830@hda.hda.com> Subject: Re: how to actually find out whether data hit the disk? In-Reply-To: <20010228140749.B29400@heechee.tobez.org> from Anton Berezin at "Feb 28, 2001 02:07:49 pm" To: Anton Berezin Date: Wed, 28 Feb 2001 08:57:31 -0500 (EST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I am doing the following, on the partition with softupdates turned on: > > 1. fd = open("a file", O_CREAT) > 2. mmap(fd) > 3. sequencial write to mmapped region > 4. some other processing > 5. munmap > 6. unlink > 7. close > > Since this is a supposedly high-perfomance application, I am interested > that data do NOT hit the disk. I understand that softupdates do a good > job at that. The time taken by step 4 is usually sub-second, but > sometimes it can take longer (network delays etc.). The question is - > is it possible to actually find out whether data hit the disk or not for > a particular run of 1-7? Answer to your question: Do an msync with MS_SYNC someplace. Also, use MAP_NOSYNC in mmap until 4.3 when Matt Dillon plans to make that the default behavior. But: When does the data need to "hit the disk", given that you're unlinking the file in step 6? If I read the posix spec correctly it may never need to hit the disk. Consider a set of unrelated processes whacking a shared memory file. Set it up so the first one creates it, a bunch attach, and a final one attaches and unlinks it: process 1: fd = open("foo", O_CREAT|O_RDWR); mmap(fd, MAP_NOSYNC|MAP_SHARED); Write to mapped region process 2: fd = open("foo", O_RDWR); mmap(fd, MAP_NOSYNC|MAP_SHARED); process 3: fd = open("foo", O_RDWR); mmap(fd, MAP_NOSYNC|MAP_SHARED); ... process N: fd = open("foo", O_RDWR) mmap(fd, MAP_NOSYNC|MAP_SHARED); unlink("foo"); Everyone now happily does what they want and then all exit and no one ever does an msync(). Then you never need to actually transfer any data to disk. I'm not sure what actually happens now. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 6:11: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from heechee.tobez.org (254.adsl0.ryv.worldonline.dk [213.237.10.254]) by hub.freebsd.org (Postfix) with ESMTP id 190C837B71B for ; Wed, 28 Feb 2001 06:11:04 -0800 (PST) (envelope-from tobez@tobez.org) Received: by heechee.tobez.org (Postfix, from userid 1001) id B0BB154F4; Wed, 28 Feb 2001 15:11:02 +0100 (CET) Date: Wed, 28 Feb 2001 15:11:02 +0100 From: Anton Berezin To: Peter Dufault Cc: hackers@FreeBSD.ORG Subject: Re: how to actually find out whether data hit the disk? Message-ID: <20010228151102.C29400@heechee.tobez.org> References: <20010228140749.B29400@heechee.tobez.org> <200102281357.f1SDvVW27830@hda.hda.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102281357.f1SDvVW27830@hda.hda.com>; from dufault@hda.hda.com on Wed, Feb 28, 2001 at 08:57:31AM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Feb 28, 2001 at 08:57:31AM -0500, Peter Dufault wrote: > > I am doing the following, on the partition with softupdates turned on: > > > > 1. fd = open("a file", O_CREAT) > > 2. mmap(fd) > > 3. sequencial write to mmapped region > > 4. some other processing > > 5. munmap > > 6. unlink > > 7. close > > > > Since this is a supposedly high-perfomance application, I am interested > > that data do NOT hit the disk. I understand that softupdates do a good > > job at that. The time taken by step 4 is usually sub-second, but > > sometimes it can take longer (network delays etc.). The question is - > > is it possible to actually find out whether data hit the disk or not for > > a particular run of 1-7? > > Answer to your question: > > Do an msync with MS_SYNC someplace. Also, use MAP_NOSYNC in > mmap until 4.3 when Matt Dillon plans to make that the default behavior. Ahh, no. That's the other way around - I do not *want* it to hit the disk, but would like to *know* when it nevertheless does. =Anton. -- May the tuna salad be with you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 6:18:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from heechee.tobez.org (254.adsl0.ryv.worldonline.dk [213.237.10.254]) by hub.freebsd.org (Postfix) with ESMTP id 2040437B719; Wed, 28 Feb 2001 06:18:24 -0800 (PST) (envelope-from tobez@tobez.org) Received: by heechee.tobez.org (Postfix, from userid 1001) id 4AC4F54F4; Wed, 28 Feb 2001 15:18:23 +0100 (CET) Date: Wed, 28 Feb 2001 15:18:23 +0100 From: Anton Berezin To: Mike Smith Cc: Peter Dufault , hackers@freebsd.org Subject: Re: how to actually find out whether data hit the disk? Message-ID: <20010228151823.D29400@heechee.tobez.org> References: <200102281357.f1SDvVW27830@hda.hda.com> <200102281407.f1SE7oi01870@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102281407.f1SE7oi01870@mass.dis.org>; from msmith@freebsd.org on Wed, Feb 28, 2001 at 06:07:50AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ putting hackers- back here] On Wed, Feb 28, 2001 at 06:07:50AM -0800, Mike Smith wrote: > > > I am doing the following, on the partition with softupdates turned on: > > > > > > 1. fd = open("a file", O_CREAT) > > > 2. mmap(fd) > > > 3. sequencial write to mmapped region > > > 4. some other processing > > > 5. munmap > > > 6. unlink > > > 7. close > > > > > > Since this is a supposedly high-perfomance application, I am interested > > > that data do NOT hit the disk. I understand that softupdates do a good > > > job at that. The time taken by step 4 is usually sub-second, but > > > sometimes it can take longer (network delays etc.). The question is - > > > is it possible to actually find out whether data hit the disk or not for > > > a particular run of 1-7? > > The *real* question here is - why are you using a file at all? > > You could trivially replace open/mmap with malloc, and munmap/unlink/ > close with free. If you don't want the operation to go to disk, don't > apply disk-file semantics to it at all. That's a sort of memory overcommit protection. The files/buffers are potentially large (say, ~20MB-100MB), there can be several of those in a process, and there are going to be several copies of a process. So neither malloc() nor anonymous mmap() do the job. In most cases they would work just fine (i.e, the typical buffer size is 2K-500K), but so will do the file-backed mmap(). In the bad case, however, the file-backed mmap() will have an advantage of not coredumping. ;-) %Anton. -- May the tuna salad be with you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 6:20:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id 8A62037B729 for ; Wed, 28 Feb 2001 06:20:19 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.11.1/8.11.1) id f1SEILG28001; Wed, 28 Feb 2001 09:18:21 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200102281418.f1SEILG28001@hda.hda.com> Subject: Re: how to actually find out whether data hit the disk? In-Reply-To: <20010228151102.C29400@heechee.tobez.org> from Anton Berezin at "Feb 28, 2001 03:11:02 pm" To: Anton Berezin Date: Wed, 28 Feb 2001 09:18:21 -0500 (EST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Do an msync with MS_SYNC someplace. Also, use MAP_NOSYNC in > > mmap until 4.3 when Matt Dillon plans to make that the default behavior. > > Ahh, no. That's the other way around - I do not *want* it to hit the > disk, but would like to *know* when it nevertheless does. OK, doing a stat and checking the mtime should give you the info at the expense of polling, I can't think of another way. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 6:37: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from heechee.tobez.org (254.adsl0.ryv.worldonline.dk [213.237.10.254]) by hub.freebsd.org (Postfix) with ESMTP id C563437B719 for ; Wed, 28 Feb 2001 06:37:01 -0800 (PST) (envelope-from tobez@tobez.org) Received: by heechee.tobez.org (Postfix, from userid 1001) id A015E54F5; Wed, 28 Feb 2001 15:37:00 +0100 (CET) Date: Wed, 28 Feb 2001 15:37:00 +0100 From: Anton Berezin To: John Wilson Cc: "Michael C . Wu" , freebsd-hackers@freebsd.org Subject: Re: Converting Perforce to CVS Message-ID: <20010228153700.A30828@heechee.tobez.org> References: <5173449.983226694087.JavaMail.imail@blizzard.excite.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5173449.983226694087.JavaMail.imail@blizzard.excite.com>; from john_wilson100@excite.com on Mon, Feb 26, 2001 at 02:31:33PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 26, 2001 at 02:31:33PM -0800, John Wilson wrote: > On Sun, 25 Feb 2001 22:00:31 -0600, Michael C . Wu wrote: >> On Sun, Feb 25, 2001 at 09:17:38AM -0800, John Wilson scribbled: >>> If you still have the Perforce->CVS conversion script, I would be >>> very grateful if you could e-mail it to me. >> Such a script is available for download on www.perforce.com. > No, there isn't. They have a CVS to Perforce script, not Perforce to > CVS (please don't ask who in their right mind would want to go from > Perforce to CVS :) > Well, if Anton doesn't respond, I guess I'll just have to write one > myself... Well, it took a month for you request it... Not that I was deliberately waiting the same period before sending it, but.. ;-) http://www.tobez.org/download/p42cvs Beware it is very unpolished and probably requires your inspection before using it. I used it once, and it worked for me. Cheers, +Anton. -- May the tuna salad be with you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 8:52:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sharmasnew.dhs.org (c239143-a.frmt1.sfba.home.com [24.19.220.119]) by hub.freebsd.org (Postfix) with ESMTP id 48FB037B719 for ; Wed, 28 Feb 2001 08:52:46 -0800 (PST) (envelope-from adsharma@sharmasnew.dhs.org) Received: (from adsharma@localhost) by sharmasnew.dhs.org (8.11.1/8.11.1) id f1SGl0r26924; Wed, 28 Feb 2001 08:47:00 -0800 (PST) (envelope-from adsharma) Date: Wed, 28 Feb 2001 08:46:59 -0800 From: Arun Sharma To: Julian Elischer Cc: hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. Message-ID: <20010228084659.A26909@sharmas.dhs.org> References: <200102260529.f1Q5T8413011@curve.dellroad.org> <200102261755.f1QHtvr34064@earth.backplane.com> <200102270624.WAA17949@c62443-a.frmt1.sfba.home.com> <3A9BAAF9.C75B39BF@elischer.org> <3A9C9CCC.4F9B521D@softweyr.com> <3A9C9D11.854BCD5@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A9C9D11.854BCD5@elischer.org>; from julian@elischer.org on Tue, Feb 27, 2001 at 10:39:13PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 27, 2001 at 10:39:13PM -0800, Julian Elischer wrote: > no, something specifically designed around kernel type of actions. > declarations of "physical pointer", "kvm pointer" "User Pointer" > for example, and being able to declare a structure (not 'struct') > and say "this list is 'per process'" and have the list head > automatically in the proc struct > without haviong to add it there.. i.e backwards from today.. Rumor has it that MS has several compiler extensions, just for supporting their kernel. Some of what you say above could be built on top of the compiler, declaratively. Language support works well in cases where writing the same code by hand is tedious and error prone or down right ugly - like several hundred if (foo = null) return blah checks. -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 10:45: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from toppur.simi.is (toppur.simi.is [194.105.227.1]) by hub.freebsd.org (Postfix) with ESMTP id BFDE837B771 for ; Wed, 28 Feb 2001 10:44:56 -0800 (PST) (envelope-from khb@simi.is) Received: (from root@localhost) by toppur.simi.is (8.9.3/8.9.3) id SAA28273 for freebsd-hackers@freebsd.org; Wed, 28 Feb 2001 18:44:49 GMT From: khb@simi.is Received: from mail01.simi.is (mail01.simi.is [157.157.254.24]) by toppur.simi.is (8.9.3/8.9.3) with ESMTP id SAA27011 for ; Wed, 28 Feb 2001 18:44:33 GMT Subject: subscribe To: freebsd-hackers@freebsd.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 28 Feb 2001 17:39:42 +0000 X-MIMETrack: Serialize by Router on mail01/ =?iso-8859-1?q?S=EDminn=28Release_5=2E0=2E5_|September_22=2C_2000=29_at?= 28.02.2001 18:41:21 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Antivirus: scanned by McAfee Antivirus (www.simi.is) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG subscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 12:18: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id CE25937B71B for ; Wed, 28 Feb 2001 12:18:02 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f1SKDhl23051; Wed, 28 Feb 2001 12:13:43 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200102280314.TAA43386@akira.lanfear.com> Date: Wed, 28 Feb 2001 12:17:15 -0800 (PST) From: John Baldwin To: Marc W Subject: RE: Generating Core Dump Programmatically Cc: freebsd-hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 28-Feb-01 Marc W wrote: > > > I'm trying to ensure robust shutdown on my machine. Thus, I've > installed signal handlers for a bunch of nasty looking signals. In my > new handler, after all critical state is saved, I then call abort(3), > and all seems to work well. > > EXCEPT -- some signals generate core files when left with the > default behaviour. Is there some straightforward way to do this? Hmm, perhaps make sure you have the default SIGSEGV handler installed after your cleanup and do: *(int *)NULL = 1; or some such? Then again, the core dump you get may not be all that useful... > thanks. > > marc. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 13:37:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id BC54837B719 for ; Wed, 28 Feb 2001 13:37:36 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1SLbMs91698; Wed, 28 Feb 2001 13:37:22 -0800 (PST) (envelope-from dillon) Date: Wed, 28 Feb 2001 13:37:22 -0800 (PST) From: Matt Dillon Message-Id: <200102282137.f1SLbMs91698@earth.backplane.com> To: Peter Dufault Cc: Anton Berezin , hackers@FreeBSD.ORG Subject: Re: how to actually find out whether data hit the disk? References: <200102281357.f1SDvVW27830@hda.hda.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> is it possible to actually find out whether data hit the disk or not for :> a particular run of 1-7? : :Answer to your question: : :Do an msync with MS_SYNC someplace. Also, use MAP_NOSYNC in :mmap until 4.3 when Matt Dillon plans to make that the default behavior. I plan on making it the default behavior only for Linux emulation, to emulate what Linux does. For FreeBSD native you still need to specify MAP_NOSYNC. Eventually I hope to make it the default behavior for FreeBSD native but some work needs to be done on the VM heuristics first (or on an incremental system sync) to avoid collecting too many dirty pages. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 14: 3:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns1.net.com (ns1.net.com [134.56.3.101]) by hub.freebsd.org (Postfix) with ESMTP id 31E9537B719 for ; Wed, 28 Feb 2001 14:03:09 -0800 (PST) (envelope-from shankar_agarwal@net.com) Received: from isis.net.com (isis.net.com [134.56.112.20]) by ns1.net.com (8.9.3/8.9.3) with ESMTP id OAA15874 for ; Wed, 28 Feb 2001 14:03:05 -0800 (PST) Received: from west-mail.net.com by isis.net.com (8.9.3/SMI-SVR4) id OAA16509; Wed, 28 Feb 2001 14:03:05 -0800 (PST) Received: from net.com ([134.56.103.239]) by west-mail.net.com (Netscape Messaging Server 3.6) with ESMTP id AAA21B6 for ; Wed, 28 Feb 2001 14:04:16 -0800 Message-ID: <3A9D7669.C567448E@net.com> Date: Wed, 28 Feb 2001 14:06:33 -0800 From: Shankar Agarwal Organization: N.E.T. http://www.net.com X-Mailer: Mozilla 4.61C-NETv45 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en, en-GB, fr, de MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: questions regarding the MGET function. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Can you please tell me when did the MGET function change it implementation from using MALLOC to using pool_get to allocate a mbuf. I am having a trouble finding out how does the memstats keep track of the mbufs allocated through pool_get. Thanks Regards Shankar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 14:49:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 69B3B37B71F for ; Wed, 28 Feb 2001 14:49:18 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1SMn6N93107; Wed, 28 Feb 2001 14:49:06 -0800 (PST) (envelope-from dillon) Date: Wed, 28 Feb 2001 14:49:06 -0800 (PST) From: Matt Dillon Message-Id: <200102282249.f1SMn6N93107@earth.backplane.com> To: Peter Dufault Cc: hackers@FreeBSD.ORG Subject: Re: memorylocked resource (was "Setting memory allocators...") References: <200102281332.f1SDWPD27689@hda.hda.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hmm. Well, mlock() is one of those system calls that virtually nobody has worked on since inception. The most I've done with it has been to fix bugs. The resource issues for mlock() aren't really good enough to prevent misuse in a general multiuser system. The resource is per-process rather then per-user, and in fact not even implemented. And the locked memory is not advisory so there is no way for the kernel to recover it under heavy load conditions until the process releases it or exits. If you grep for RLIMIT_MEMLOCK you find a minimal implementation of the resource limit in vm/vm_mmap.c. 'pmap_wired_count' is not defined, so the implementation is to be root-only and to ignore the resource limit. Even with pmap_wired_count implemented the implementation is per-process, which is not sufficient protection. -Matt :Why is the mlock(2) call restricted to the super user instead :of enforcing it through per-user or per-login class limits? :I was checking to see if most of the pieces were in place for :"mlockall(MCL_FUTURE)" and noticed the "memorylocked infinity" :setting in limits (I didn't know about memorylocked). Setting :"memorylocked 0" for normal users is a flexible way to address :this, then create a special class of programs that are permitted :to do some locking. : :Along the same lines (matt probably knows the answer) is it :easy to force paging in and locking down of any memory associated :with a process so that mlockall(MCL_FUTURE) together with :an appropriate memorylocked limit gives the requested :memory semantics? I'd have to check through the specs to see :how mmap() is supposed to play with mlockall(). : :Please leave aside most resource management issues :for now, I'm assuming the main use for this is debugged :small closed embedded systems, only bring up kickers. : :Peter : :-- :Peter Dufault (dufault@hda.com) Realtime development, Machine control, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 15: 8:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 4700437B718 for ; Wed, 28 Feb 2001 15:08:43 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1SN8hC93566; Wed, 28 Feb 2001 15:08:43 -0800 (PST) (envelope-from dillon) Date: Wed, 28 Feb 2001 15:08:43 -0800 (PST) From: Matt Dillon Message-Id: <200102282308.f1SN8hC93566@earth.backplane.com> To: Peter Dufault , hackers@FreeBSD.ORG Subject: Re: memorylocked resource (was "Setting memory allocators...") References: <200102281332.f1SDWPD27689@hda.hda.com> <200102282249.f1SMn6N93107@earth.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ::Along the same lines (matt probably knows the answer) is it ::easy to force paging in and locking down of any memory associated ::with a process so that mlockall(MCL_FUTURE) together with ::an appropriate memorylocked limit gives the requested ::memory semantics? I'd have to check through the specs to see ::how mmap() is supposed to play with mlockall(). :: ::Please leave aside most resource management issues ::for now, I'm assuming the main use for this is debugged ::small closed embedded systems, only bring up kickers. :: ::Peter ::Peter Dufault (dufault@hda.com) Realtime development, Machine control, Heh heh. I didn't answer that very well the first time eh? In regards to mlockall(MCL_FUTURE). Hmm. Well, you could certainly implement it inside vm_fault but there are a couple of other cases where the system manually enters a page into the user's page table. I haven't researched it but I would not expect it to be difficult. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 16:50:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from VL-MS-MR002.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id 66EE237B71A for ; Wed, 28 Feb 2001 16:50:53 -0800 (PST) (envelope-from bmilekic@technokratis.com) Received: from jehovah ([24.202.203.190]) by VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G9HU1102.JKY; Wed, 28 Feb 2001 19:43:49 -0500 Message-ID: <007201c0a1e9$07620490$becbca18@jehovah> From: "Bosko Milekic" To: "Shankar Agarwal" , References: <3A9D7669.C567448E@net.com> Subject: Re: questions regarding the MGET function. Date: Wed, 28 Feb 2001 19:46:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Shankar Agarwal wrote: > Hi, > Can you please tell me when did the MGET function change it > implementation from using MALLOC to using pool_get to allocate a mbuf. I Never. We don't use pool_get(). That's a NetBSD-ism. :-) The mbuf subsystem uses its own allocator and stats are kept in mbstat which is exported via sysctl. Things like netstat(1) can fetch this information for you. > am having a trouble finding out how does the memstats keep track of the > mbufs allocated through pool_get. > Thanks > Regards > Shankar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 17: 4:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 519AD37B718 for ; Wed, 28 Feb 2001 17:04:13 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.2/8.11.2) with ESMTP id f2114f466878; Thu, 1 Mar 2001 01:04:41 GMT (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.2/8.11.2) with ESMTP id f2116JS54201; Thu, 1 Mar 2001 01:06:19 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200103010106.f2116JS54201@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Dima Dorfman Cc: hackers@freebsd.org, brian@Awfulhak.org Subject: Re: Inheriting the nodump flag In-Reply-To: Message from Dima Dorfman of "Mon, 26 Feb 2001 01:13:47 PST." <20010226091347.CD0073E02@bazooka.unixfreak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Mar 2001 01:06:19 +0000 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Attached below is a port of NetBSD's patch to FreeBSD's dump(8). > dump's tree walker is a little weird, so the patch is a little more > complicated than calling fts_set with FTS_SKIP. For the technical > details of what it does, see: > http://lists.openresources.com/NetBSD/tech-kern/msg00453.html. [.....] > Comments? Just that I noticed a typo in a comment where ``inherited'' is misspelt ``herited'' going via your URL.... but it's fixed in the attached patch :-) It's probably worth updating the web page. I'd certainly like to see this committed - I'm sick of backing up release directories, cvs repositories and /usr/obj :-) > Thanks in advance > > Dima Dorfman > dima@unixfreak.org Cheers. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 17:11:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from w250.z064001178.sjc-ca.dsl.cnc.net (w250.z064001178.sjc-ca.dsl.cnc.net [64.1.178.250]) by hub.freebsd.org (Postfix) with SMTP id 4C9D137B718 for ; Wed, 28 Feb 2001 17:11:38 -0800 (PST) (envelope-from josb@cncdsl.com) Received: (qmail 67820 invoked by uid 1000); 1 Mar 2001 01:11:57 -0000 Date: Wed, 28 Feb 2001 17:11:35 -0800 From: Jos Backus To: Peter Seebach Cc: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. Message-ID: <20010228171135.E66723@lizzy.bugworks.com> Reply-To: Jos Backus Mail-Followup-To: Peter Seebach , freebsd-hackers@freebsd.org References: <200102250745.f1P7jPd02969@harmony.village.org> <200102250757.f1P7vR625246@guild.plethora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102250757.f1P7vR625246@guild.plethora.net>; from seebs@plethora.net on Sun, Feb 25, 2001 at 01:57:05AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG For your collective amusement, here's a post that talks about how OS/2 handles memory allocation. DosAllocMem() has a flags argument, and one of the flags requests the OS to actually commit the memory. http://w3.hethmon.com/os2isp/1998/Apr/Msgs/l2w96957.html http://www.stidolph.com/os2api/Dos/DosAllocMem.html So even IBM must have thought it not to be such a bad idea. -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 19: 0:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fremont.bolingbroke.com (adsl-216-102-90-210.dsl.snfc21.pacbell.net [216.102.90.210]) by hub.freebsd.org (Postfix) with ESMTP id 9C01037B71A; Wed, 28 Feb 2001 19:00:23 -0800 (PST) (envelope-from hacker@bolingbroke.com) Received: from fremont.bolingbroke.com (fremont.bolingbroke.com [216.102.90.210]) by fremont.bolingbroke.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2130Mu75911; Wed, 28 Feb 2001 19:00:22 -0800 (PST) Date: Wed, 28 Feb 2001 19:00:22 -0800 (PST) From: Ken Bolingbroke To: freebsd-hackers@FreeBSD.ORG Cc: freebsd-platforms@FreeBSD.ORG Subject: FreeBSD on S/390? In-Reply-To: <7c.12440815.27cf08e0@aol.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Long shot, probably, but I've got a bunch of virtual machines on an IBM S/390 mainframe, and while we're running SuSE Linux on most of them, on a whim I tossed out the idea of running FreeBSD on one of them, and to my surprise, it was taken seriously. So, has anyone done any work with getting FreeBSD running on a S/390? What can I do to make it happen if there's interest? Ken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 19:16:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from batangas.i-next.net (batangas.i-next.net [202.61.64.22]) by hub.freebsd.org (Postfix) with ESMTP id A3EDA37B718 for ; Wed, 28 Feb 2001 19:16:30 -0800 (PST) (envelope-from tayerv@ph.inter.net) Received: from x4o7r5 (bsd.i-next.net [202.61.68.75]) by batangas.i-next.net (8.11.1/8.11.2) with SMTP id f1SHA3o02880 for ; Thu, 1 Mar 2001 01:10:04 +0800 (PHT) Message-ID: <000701c0a1a6$539fd280$4b443dca@x4o7r5> From: "jett tayer" To: Subject: ipchains ported to FreeBSD Date: Thu, 1 Mar 2001 00:48:46 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C0A1E9.5FA25560" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C0A1E9.5FA25560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello, can ipchains / iptables be ported to FreeBSD... this is a suggestion if u dont mind. jett ------=_NextPart_000_0004_01C0A1E9.5FA25560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello,
 
can ipchains / iptables be ported to = FreeBSD...
this is a suggestion if u dont=20 mind.
 
jett
------=_NextPart_000_0004_01C0A1E9.5FA25560-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 20:19:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 4B8BF37B719 for ; Wed, 28 Feb 2001 20:19:56 -0800 (PST) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id 224DD3E09; Wed, 28 Feb 2001 20:19:56 -0800 (PST) To: Brian Somers Cc: hackers@freebsd.org Subject: Re: Inheriting the nodump flag In-Reply-To: Message from Brian Somers of "Thu, 01 Mar 2001 01:06:19 GMT." <200103010106.f2116JS54201@hak.lan.Awfulhak.org> Date: Wed, 28 Feb 2001 20:19:55 -0800 From: Dima Dorfman Message-Id: <20010301041956.224DD3E09@bazooka.unixfreak.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Attached below is a port of NetBSD's patch to FreeBSD's dump(8). > > dump's tree walker is a little weird, so the patch is a little more > > complicated than calling fts_set with FTS_SKIP. For the technical > > details of what it does, see: > > http://lists.openresources.com/NetBSD/tech-kern/msg00453.html. > [.....] > > Comments? > > Just that I noticed a typo in a comment where ``inherited'' is misspelt > ``herited'' going via your URL.... but it's fixed in the attached > patch :-) It's probably worth updating the web page. That page is the archive of the tech-kern@netbsd.org mailing list, and as such can't be changed (much less by me). I provided it because it offers a very good technical explanation of the patch, which I didn't want to repeat. I took the patch there almost verbatim, except for, obviously, the exact placement of the code, and the comments; I didn't take the latter because the person who wrote it isn't a natural English speaker (as far as I can tell, anyway), and as such didn't write such great comments ("such great" being a reference to the English grammar and spelling, not their technical accuracy). > > I'd certainly like to see this committed - I'm sick of backing up > release directories, cvs repositories and /usr/obj :-) Yes, this was my motivation for porting this, too. :-) Thanks Dima Dorfman dima@unixfreak.org P.S. I just sent this patch to -audit per request of rwatson. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 20:20:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 7788837B719 for ; Wed, 28 Feb 2001 20:20:21 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.11.1/8.11.1) id f214KFR17040; Wed, 28 Feb 2001 22:20:15 -0600 (CST) (envelope-from dan) Date: Wed, 28 Feb 2001 22:20:14 -0600 From: Dan Nelson To: jett tayer Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ipchains ported to FreeBSD Message-ID: <20010228222014.A22763@dan.emsphone.com> References: <000701c0a1a6$539fd280$4b443dca@x4o7r5> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.14i In-Reply-To: <000701c0a1a6$539fd280$4b443dca@x4o7r5>; from "jett tayer" on Thu Mar 1 00:48:46 GMT 2001 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Mar 01), jett tayer said: > can ipchains / iptables be ported to FreeBSD... this is a suggestion > if u dont mind. We've already got ipfw and ipfilter; why in the world would we need a third packet-filtering systam? :) -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 21:35:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (ns.aub.dk [195.24.1.195]) by hub.freebsd.org (Postfix) with ESMTP id 2CF7637B719; Wed, 28 Feb 2001 21:35:34 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f215ZYM38952; Thu, 1 Mar 2001 06:35:34 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Ken Bolingbroke Cc: freebsd-hackers@FreeBSD.ORG, freebsd-platforms@FreeBSD.ORG Subject: Re: FreeBSD on S/390? In-Reply-To: Your message of "Wed, 28 Feb 2001 19:00:22 PST." Date: Thu, 01 Mar 2001 06:35:34 +0100 Message-ID: <38950.983424934@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Ken Bolingbroke writes: > >Long shot, probably, but I've got a bunch of virtual machines on an IBM >S/390 mainframe, and while we're running SuSE Linux on most of them, on a >whim I tossed out the idea of running FreeBSD on one of them, and to my >surprise, it was taken seriously. > >So, has anyone done any work with getting FreeBSD running on a S/390? >What can I do to make it happen if there's interest? I certainly think it is a worthwhile task. I have long been advocating it publically. I can't promise that I have much time for it but I'll do what I can to help. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 28 22:13:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fjord.dignus.com (sdsl-64-244-29-38.dsl.rdu.megapath.net [64.244.29.38]) by hub.freebsd.org (Postfix) with ESMTP id 78B6837B718; Wed, 28 Feb 2001 22:13:45 -0800 (PST) (envelope-from rivers@dignus.com) Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3]) by fjord.dignus.com (8.11.1/8.11.1) with ESMTP id f216Dpk11105; Thu, 1 Mar 2001 01:13:51 -0500 (EST) (envelope-from rivers@dignus.com) Received: (from rivers@localhost) by lakes.dignus.com (8.9.3/8.6.9) id BAA35918; Thu, 1 Mar 2001 01:15:23 -0500 (EST) Date: Thu, 1 Mar 2001 01:15:23 -0500 (EST) From: Thomas David Rivers Message-Id: <200103010615.BAA35918@lakes.dignus.com> To: freebsd-hackers@FreeBSD.ORG, hacker@bolingbroke.com Subject: Re: FreeBSD on S/390? Cc: freebsd-platforms@FreeBSD.ORG In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Long shot, probably, but I've got a bunch of virtual machines on an IBM > S/390 mainframe, and while we're running SuSE Linux on most of them, on a > whim I tossed out the idea of running FreeBSD on one of them, and to my > surprise, it was taken seriously. > > So, has anyone done any work with getting FreeBSD running on a S/390? > What can I do to make it happen if there's interest? > > Ken > I'd like to see it as well.... I beleive we'd be willing to help with it too.. as resources permit. - Dave Rivers - -- rivers@dignus.com Work: (919) 676-0847 Get your mainframe (370) `C' compiler at http://www.dignus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 1:32:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id 07ACC37B718 for ; Thu, 1 Mar 2001 01:32:11 -0800 (PST) (envelope-from usebsd@free.fr) Received: by smtp.nettoll.com; Thu, 1 Mar 2001 10:30:07 +0100 (MET) Message-Id: <4.3.0.20010301103255.06184220@pop.free.fr> X-Sender: usebsd@pop.free.fr X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 01 Mar 2001 10:33:19 +0100 To: Dan Nelson , jett tayer From: mouss Subject: Re: ipchains ported to FreeBSD Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <20010228222014.A22763@dan.emsphone.com> References: <000701c0a1a6$539fd280$4b443dca@x4o7r5> <000701c0a1a6$539fd280$4b443dca@x4o7r5> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 22:20 28/02/01 -0600, Dan Nelson wrote: >In the last episode (Mar 01), jett tayer said: > > can ipchains / iptables be ported to FreeBSD... this is a suggestion > > if u dont mind. > >We've already got ipfw and ipfilter; why in the world would we need a >third packet-filtering systam? :) add to this that ipchains will certainly be replaced by iptables! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 3:29:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.prod.itd.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 5235137B71A for ; Thu, 1 Mar 2001 03:29:51 -0800 (PST) (envelope-from derick@xenocex.com) Received: from xenocex.com (pool0257.cvx27-bradley.dialup.earthlink.net [209.179.57.2]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id DAA02515 for ; Thu, 1 Mar 2001 03:29:46 -0800 (PST) Message-ID: <3A9E32C5.90603@xenocex.com> Date: Thu, 01 Mar 2001 03:30:13 -0800 From: "Derick J. Fernando" User-Agent: Mozilla/5.0 (X11; U; FreeBSD 4.2-RELEASE i386; en-US; 0.8) Gecko/20010227 X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Subject: RE: Dropping RTS in FreeBSD 4.2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello all, This is an example of how I would try to drop RTS, I am porting a win32 seismometer program to FreeBSD / X11. However this does not seem to work on FreeBSD, my cheap breakout box reports no change. #include #include int fd; int status; ioctl(fd, TIOCMGET, &status); status &= ~TIOCM_RTS; ioctl(fd, TIOCMSET, status); Any ideas, more reliable way to do this? Any docs? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 6: 1:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 448DE37B71B; Thu, 1 Mar 2001 06:01:17 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f21E1Ah65677; Thu, 1 Mar 2001 09:01:10 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 1 Mar 2001 09:01:09 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Ken Bolingbroke Cc: freebsd-hackers@FreeBSD.ORG, freebsd-platforms@FreeBSD.ORG Subject: Re: FreeBSD on S/390? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 28 Feb 2001, Ken Bolingbroke wrote: > Long shot, probably, but I've got a bunch of virtual machines on an IBM > S/390 mainframe, and while we're running SuSE Linux on most of them, on > a whim I tossed out the idea of running FreeBSD on one of them, and to > my surprise, it was taken seriously. > > So, has anyone done any work with getting FreeBSD running on a S/390? > What can I do to make it happen if there's interest? Well, as you've seen from the two responses already, the implicit answer to your question of "has anyone done any work" appears to be "no" :-). However, I think a number of us in the developer community see this as a fairly serious gap, and would like to remedy this. However, IBM hasn't been dropping S/390 machines and documentation in anyone's laps (at least, not mine, and no one else has mentioned it), so the primary facilitators would be, as with any new hardware port: 1) Access to necessary technical documentation and expertise 2) Access to hardware 3) Someone with appropriate expertise willing the guide ("own", if you will) the port to the platform through to completion, and continue to provide on-going maintainership in the face of adversity (someone adds fine-grained SMP support and it falls on the maintainer to figure out how that works on their platform, if no one has hardware). Part of the "real answer" is probably that IBM or a large consumer of S/390 machines has to shepherd the whole process to make it happen, and that probably involves a moderate amount of money, and moderate levels of frustration. If you can provide access to the first and survive the second, then you can certainly make this a reality. If not, well, it would be nice to see it happen but the task is to identify someone who can provide these. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 6:47:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from silby.com (adam042-060.resnet.wisc.edu [146.151.42.60]) by hub.freebsd.org (Postfix) with ESMTP id AB31537B719 for ; Thu, 1 Mar 2001 06:47:47 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 3547 invoked by uid 1000); 1 Mar 2001 14:47:46 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 1 Mar 2001 14:47:46 -0000 Date: Thu, 1 Mar 2001 08:47:46 -0600 (CST) From: Mike Silbersack To: Robert Watson Cc: Ken Bolingbroke , , Subject: Re: FreeBSD on S/390? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 1 Mar 2001, Robert Watson wrote: > Part of the "real answer" is probably that IBM or a large consumer of > S/390 machines has to shepherd the whole process to make it happen, and > that probably involves a moderate amount of money, and moderate levels of > frustration. If you can provide access to the first and survive the > second, then you can certainly make this a reality. If not, well, it > would be nice to see it happen but the task is to identify someone who can > provide these. > > Robert N M Watson FreeBSD Core Team, TrustedBSD Project > robert@fledge.watson.org NAI Labs, Safeport Network Services If memory serves me right, the way Linux S/390 support came about was that a team of S/390 enthusiasts start working on an S/390 port. After a year or so, they were almost done. At this point an internal IBM team submitted a set of patches that they had been working on, supplanting the efforts of the enthusiast team. Hence, perhaps the best approach is just to do a really good job of making it look like a FreeBSD S/390 port is being done. If this is successfully pulled off, IBM will actually end up doing the real work. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 7: 5:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mip.co.za (puck.mip.co.za [209.212.106.44]) by hub.freebsd.org (Postfix) with ESMTP id 014FE37B719 for ; Thu, 1 Mar 2001 07:05:32 -0800 (PST) (envelope-from patrick@mip.co.za) Received: from patrick (patrick.mip.co.za [10.3.13.181]) by mip.co.za (8.9.3/8.9.3) with SMTP id RAA80332 for ; Thu, 1 Mar 2001 17:05:29 +0200 (SAST) (envelope-from patrick@mip.co.za) From: "Patrick O'Reilly" To: Subject: Hardware question - WAN port for FreeBSD router! Date: Thu, 1 Mar 2001 17:05:29 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all. Please forgive me if this post is altogether in the wrong place, but I need help finding a certain piece of hardware. I have a number of firewalls running (very happily) on FreeBSD. Each one is connected on the outside NIC to a Cisco 1601 Router, which is connected in turn to an NTU etc.... I am sure I could save a lot by installing a WAN card directly into the BSD firewall, thereby doing without the Router altogether - FreeBSD can do all the routing I need after all! So - is there such a WAN serial card available? And (most important) one which is supported by the necessary BSD drivers? Any pointers would be MUCH appreciated. Regards, Patrick O'Reilly --- "I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forego their use." -- Galileo Galilei To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 7:18:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns3.safety.net (ns3.safety.net [216.200.162.38]) by hub.freebsd.org (Postfix) with ESMTP id 149B237B718 for ; Thu, 1 Mar 2001 07:18:48 -0800 (PST) (envelope-from les@ns3.safety.net) Received: (from les@localhost) by ns3.safety.net (8.9.3/8.9.3) id IAA85552; Thu, 1 Mar 2001 08:18:38 -0700 (MST) (envelope-from les) From: Les Biffle Message-Id: <200103011518.IAA85552@ns3.safety.net> Subject: Re: Hardware question - WAN port for FreeBSD router! In-Reply-To: from "Patrick O'Reilly" at "Mar 1, 2001 05:05:29 pm" To: patrick@mip.co.za (Patrick O'Reilly) Date: Thu, 1 Mar 2001 08:18:38 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG Reply-To: les@safety.net X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > So - is there such a WAN serial card available? And (most important) one > which is supported by the necessary BSD drivers? I've been very pleased with the Sangoma WanPipe card. http://www.sangoma.com/ The people are nice, the product works (although not with netgraph at the moment). It does Cisco HDLC, Frame Relay (100 PVCs) and Sync PPP. Good luck, -Les -- Les Biffle Community Service... Just Say NO! (480) 778-0177 les@safety.net http://www.networksafety.com/ Network Safety, 7802 E Gray Rd Ste 500, Scottsdale, AZ 85260 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 7:52:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from et-gw.etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 19B9E37B719 for ; Thu, 1 Mar 2001 07:52:26 -0800 (PST) (envelope-from dennis@etinc.com) Received: from dbsys.etinc.com (dbsys.etinc.com [207.252.1.18]) by et-gw.etinc.com (8.9.3/8.9.3) with ESMTP id LAA42715; Thu, 1 Mar 2001 11:02:19 GMT (envelope-from dennis@etinc.com) Message-Id: <5.0.0.25.0.20010301110131.0248e290@mail.etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 01 Mar 2001 11:06:58 -0500 To: "Patrick O'Reilly" From: Dennis Subject: Re: Hardware question - WAN port for FreeBSD router! Cc: hackers@freebsd.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 10:05 AM 03/01/2001, you wrote: >Hi all. > >Please forgive me if this post is altogether in the wrong place, but I need >help finding a certain piece of hardware. > >I have a number of firewalls running (very happily) on FreeBSD. Each one is >connected on the outside NIC to a Cisco 1601 Router, which is connected in >turn to an NTU etc.... > >I am sure I could save a lot by installing a WAN card directly into the BSD >firewall, thereby doing without the Router altogether - FreeBSD can do all >the routing I need after all! > >So - is there such a WAN serial card available? And (most important) one >which is supported by the necessary BSD drivers? www.etinc.com V.35, EIA-530, X.21, RS-232, HSSI. Support for FreeBSD v3.4, v4.1 and v4.2. PPP, Frame Relay (1024 DLCIs per line), densities to 4 ports per line, 16 ports per system. All cards include integrated Bandwidth Management software. We also sell complete prebuilt !U routers with up to 4 ports with complete GUI management. Dennis Emerging Technologies, Inc. ------------------------------------------------------------------------------------- http://www.etinc.com ISA and PCI T1/T3/V35/HSSI Cards for FreeBSD and LINUX Multiport T1 and HSSI/T3 UNIX-based Routers Bandwidth Management Standalone Systems Bandwidth Management software for LINUX and FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 8:20:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from xena.gsicomp.on.ca (cr677933-a.ktchnr1.on.wave.home.com [24.43.230.149]) by hub.freebsd.org (Postfix) with ESMTP id 1B4C337B71A; Thu, 1 Mar 2001 08:20:17 -0800 (PST) (envelope-from matt@xena.gsicomp.on.ca) Received: from localhost (matt@localhost) by xena.gsicomp.on.ca (8.11.1/8.9.3) with ESMTP id f21GIVl22243; Thu, 1 Mar 2001 11:18:31 -0500 (EST) (envelope-from matt@xena.gsicomp.on.ca) Date: Thu, 1 Mar 2001 11:18:31 -0500 (EST) From: Matthew Emmerton To: Robert Watson Cc: Ken Bolingbroke , freebsd-hackers@FreeBSD.ORG, freebsd-platforms@FreeBSD.ORG Subject: Re: FreeBSD on S/390? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 1 Mar 2001, Robert Watson wrote: > On Wed, 28 Feb 2001, Ken Bolingbroke wrote: > > > Long shot, probably, but I've got a bunch of virtual machines on an IBM > > S/390 mainframe, and while we're running SuSE Linux on most of them, on > > a whim I tossed out the idea of running FreeBSD on one of them, and to > > my surprise, it was taken seriously. > > > > So, has anyone done any work with getting FreeBSD running on a S/390? > > What can I do to make it happen if there's interest? > > Well, as you've seen from the two responses already, the implicit answer > to your question of "has anyone done any work" appears to be "no" :-). > However, I think a number of us in the developer community see this as a > fairly serious gap, and would like to remedy this. However, IBM hasn't > been dropping S/390 machines and documentation in anyone's laps (at least, > not mine, and no one else has mentioned it), so the primary facilitators > would be, as with any new hardware port: > > 1) Access to necessary technical documentation and expertise > 2) Access to hardware > 3) Someone with appropriate expertise willing the guide ("own", if you > will) the port to the platform through to completion, and continue to > provide on-going maintainership in the face of adversity (someone adds > fine-grained SMP support and it falls on the maintainer to figure out > how that works on their platform, if no one has hardware). > > Part of the "real answer" is probably that IBM or a large consumer of > S/390 machines has to shepherd the whole process to make it happen, and > that probably involves a moderate amount of money, and moderate levels of > frustration. If you can provide access to the first and survive the > second, then you can certainly make this a reality. If not, well, it > would be nice to see it happen but the task is to identify someone who can > provide these. Well, I'm starting with IBM in May at their Toronto Labs. All of my managers were particularly interested in my non-Linux open source activity (what is this FreeBSd thing that you talk about?) I'm not promising anything, but I too would *love* to get IBM supporting FreeBSD in some way. Perhaps a version of JFS released under the BSD licence would be a start, and then hardware support for RS/6k and S/390. I will keep my eyes and ears open for anything useful that falls my way. -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 9:46:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id BDE8A37B719 for ; Thu, 1 Mar 2001 09:46:28 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.11.1/8.11.1) id f21Hjts33386 for hackers@freebsd.org; Thu, 1 Mar 2001 12:45:55 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200103011745.f21Hjts33386@hda.hda.com> Subject: Stupid debugging pthread question To: hackers@freebsd.org Date: Thu, 1 Mar 2001 12:44:39 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a stupid question, basically it's how to debug something. I have four cooperating p-threaded processes. One of them keeps getting a SIGSEGV with the address 0x752f422f. I'm not sure if that address is always the same, but with a given compile it is. The thing that's a pain is it is random. The four processes can run for a long time, or through several tests to completion, and then the nasty process gets that SIGSEGV. The thread that receives the SIGSEGV is random, the stack of the SEGV'd thread is trash, the rest of the threads in the offending process still have intact stacks. Arg! Because this is intermittent my temptation is to ignore it and proceed and eventually something will happen to let me figure it out. But it's been going on for a while, and it just happened twice in a row so... Anybody seen anything remotely similar and have a suggestion? How does one dump the stack brute force on an x86? Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 9:57:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id 71D7B37B718 for ; Thu, 1 Mar 2001 09:57:42 -0800 (PST) (envelope-from sthaug@nethelp.no) Received: (qmail 42536 invoked by uid 1001); 1 Mar 2001 17:57:40 +0000 (GMT) To: hackers@freebsd.org Subject: FreeBSD on IBM's radar screen? From: sthaug@nethelp.no X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 01 Mar 2001 18:57:40 +0100 Message-ID: <42534.983469460@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I work mainly for Enitel, a medium sized ISP in Norway. We use FreeBSD a lot (eivind and des can tell you more about this). Today I got an interesting question from IBM Norway: What would be needed for IBM to support FreeBSD for Enitel? Basically: What FreeBSD version, what kind of hardware do we need supported, etc. (Based on IBM's Netfinity servers, of course.) I told them a bit about 4.2-STABLE, which is our platform of choice, and also mentioned that we'd be interested in the Qlogic fibre channel cards for the higher end platforms. Anyway, I just wanted to mention on -hackers that it's possible FreeBSD is starting to show up on IBM's radar screen. I think it's way too early to conclude anything yet, but it's interesting nevertheless. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 9:58:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 45B2837B719 for ; Thu, 1 Mar 2001 09:58:43 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 76362 invoked by uid 1000); 1 Mar 2001 17:58:17 -0000 Date: Thu, 1 Mar 2001 19:58:17 +0200 From: Peter Pentchev To: Peter Dufault Cc: hackers@freebsd.org Subject: Re: Stupid debugging pthread question Message-ID: <20010301195817.G55211@ringworld.oblivion.bg> Mail-Followup-To: Peter Dufault , hackers@freebsd.org References: <200103011745.f21Hjts33386@hda.hda.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103011745.f21Hjts33386@hda.hda.com>; from dufault@hda.hda.com on Thu, Mar 01, 2001 at 12:44:39PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Mar 01, 2001 at 12:44:39PM -0500, Peter Dufault wrote: > This is a stupid question, basically it's how to debug something. > > I have four cooperating p-threaded processes. One of them keeps getting > a SIGSEGV with the address 0x752f422f. I'm not sure if that address is > always the same, but with a given compile it is. The thing that's a pain > is it is random. The four processes can run for a long time, or through > several tests to completion, and then the > nasty process gets that SIGSEGV. The thread that receives the SIGSEGV > is random, the stack of the SEGV'd thread is trash, the rest of the > threads in the offending process still have intact stacks. Arg! > > Because this is intermittent my temptation is to ignore it and proceed > and eventually something will happen to let me figure it out. But > it's been going on for a while, and it just happened twice in a row so... > Anybody seen anything remotely similar and have a suggestion? How > does one dump the stack brute force on an x86? Not too much help, but.. 0x752f422f sure looks like a hex representation of 4 ASCII chars, and in the alnum range to boot; it's '/B/u', if I'm not too sleepy, and considering the little-endian Intel architecture. It sure looks like you have a (self-inflicted? :) buffer overflow somewhere in your code. G'luck, Peter -- This sentence claims to be an Epimenides paradox, but it is lying. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 10:41:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from a.mx.everquick.net (a.mx.everquick.net [216.89.137.3]) by hub.freebsd.org (Postfix) with ESMTP id CC4C537B71C for ; Thu, 1 Mar 2001 10:41:38 -0800 (PST) (envelope-from eddy+public+spam@noc.everquick.net) Received: from localhost (eddy@localhost) by a.mx.everquick.net (8.9.0/8.8.7) with ESMTP id SAA29817; Thu, 1 Mar 2001 18:41:25 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Date: Thu, 1 Mar 2001 18:41:25 +0000 (GMT) From: "E.B. Dreger" To: Peter Dufault Cc: hackers@FreeBSD.ORG Subject: Re: Stupid debugging pthread question In-Reply-To: <200103011745.f21Hjts33386@hda.hda.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Date: Thu, 1 Mar 2001 12:44:39 -0500 (EST) > From: Peter Dufault > > This is a stupid question, basically it's how to debug something. > > I have four cooperating p-threaded processes. One of them keeps getting > a SIGSEGV with the address 0x752f422f. I'm not sure if that address is > always the same, but with a given compile it is. The thing that's a pain > is it is random. The four processes can run for a long time, or through > several tests to completion, and then the > nasty process gets that SIGSEGV. The thread that receives the SIGSEGV > is random, the stack of the SEGV'd thread is trash, the rest of the > threads in the offending process still have intact stacks. Arg! Sounds like maybe a buffer overrun or something might be trashing a return pointer. Not sure what the exact cause is, but if that address is not an actual address, I'd suspect that a return pointer is getting trashed. Any strings "/B/u" in your program? That would be stored as 0x752f422f. If you're using assembly with using %ebp for stack frame (yay!), then make certain %esp isn't getting corrupted. Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet / EternalCommerce Division E-Mail: eddy@everquick.net Phone: (316) 794-8922 --------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 11:13: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 71A7037B718 for ; Thu, 1 Mar 2001 11:12:58 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id OAA20716; Thu, 1 Mar 2001 14:12:45 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <42534.983469460@verdi.nethelp.no> References: <42534.983469460@verdi.nethelp.no> Date: Thu, 1 Mar 2001 14:12:43 -0500 To: sthaug@nethelp.no, hackers@FreeBSD.ORG From: Garance A Drosihn Subject: Re: FreeBSD on IBM's radar screen? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 6:57 PM +0100 3/1/01, sthaug@nethelp.no wrote: >Anyway, I just wanted to mention on -hackers that it's >possible FreeBSD is starting to show up on IBM's radar >screen. I think it's way too early to conclude anything >yet, but it's interesting nevertheless. I think the recent debacle with the T20 and A20 laptops actually helped to get us noticed. Here someone in IBM probably made a dumb programming mistake which happened to make freebsd unusable on their hardware, and they got a whole bunch of their *customers* (owners of one of these laptops) beating them up for the problem. Not freebsd.org making vague promises of sales based on freebsd, but actual customers using freebsd on IBM hardware. IBM wants to sell as much hardware as they can, and so they are bound to be interested when they notice that some of their customers are using freebsd. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 14:11:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ambrisko.com (adsl-216-103-208-74.dsl.snfc21.pacbell.net [216.103.208.74]) by hub.freebsd.org (Postfix) with ESMTP id 146DE37B7A1; Thu, 1 Mar 2001 14:11:08 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.11.2/8.11.1) id f21MB5Y29968; Thu, 1 Mar 2001 14:11:05 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200103012211.f21MB5Y29968@ambrisko.com> Subject: Re: FreeBSD on S/390? In-Reply-To: "from Robert Watson at Mar 1, 2001 09:01:09 am" To: Robert Watson Date: Thu, 1 Mar 2001 14:11:05 -0800 (PST) Cc: Ken Bolingbroke , freebsd-hackers@FreeBSD.ORG, freebsd-platforms@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robert Watson writes: | On Wed, 28 Feb 2001, Ken Bolingbroke wrote: | > Long shot, probably, but I've got a bunch of virtual machines on an IBM | > S/390 mainframe, and while we're running SuSE Linux on most of them, on | > a whim I tossed out the idea of running FreeBSD on one of them, and to | > my surprise, it was taken seriously. | > | > So, has anyone done any work with getting FreeBSD running on a S/390? | > What can I do to make it happen if there's interest? | | fairly serious gap, and would like to remedy this. However, IBM hasn't | been dropping S/390 machines and documentation in anyone's laps (at least, | not mine, and no one else has mentioned it), so the primary facilitators | would be, as with any new hardware port: | | 1) Access to necessary technical documentation and expertise | 2) Access to hardware I would suggest people look at http://www.conmicro.cx/hercules/ It is "an open source software implementation of the mainframe System/370 and ESA/390". So the first step would be to port that to FreeBSD and then you sort of have the hardware. It is supposed to run the Linux 390 port. I would think this would be a good starting point and since the emulator is open source it should be easier to figure out how the machine works. Doug A. Standard disclaimer applies To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 16:12: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by hub.freebsd.org (Postfix) with ESMTP id EEC1737B718; Thu, 1 Mar 2001 16:11:54 -0800 (PST) (envelope-from reel@sympatico.ca) Received: from HSE-QCity-ppp95564.qc.sympatico.ca ([64.230.230.5]) by tomts5-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010302001154.YFBY2129.tomts5-srv.bellnexxia.net@HSE-QCity-ppp95564.qc.sympatico.ca>; Thu, 1 Mar 2001 19:11:54 -0500 Date: Thu, 1 Mar 2001 19:11:52 -0500 (EST) From: Felix-Antoine Paradis X-X-Sender: To: Cc: FreeBSD Questions Subject: Kernel compilation failed. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi. I am running FreeBSD 3.5-STABLE on a i386 arch. When I boot, it tells me that: --- sb0 at 0x220 on isa NOTE! SB Pro support required with your soundcard! snd0: --- So I added: --- device sbxvi0 at isa? drq ? --- to my kernel. Then, I recompiled and I got an error: --- su-2.04# make loading kernel dev_table.o(.data+0xc4): undefined reference to `attach_sb16midi' dev_table.o(.data+0xc8): undefined reference to `probe_sb16midi' sb_dsp.o: In function `sbintr': sb_dsp.o(.text+0xa9): undefined reference to `sb16midiintr' *** Error code 1 Stop. --- I did a: make depend; make; make install It fails in the "make". Any idea? ______________________ Felix-Antoine Paradis reel@sympatico.ca PGP Key ID: 0x7B3AD2C5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 17:25:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from kuku.excite.com (kuku-rwcmta.excite.com [198.3.99.63]) by hub.freebsd.org (Postfix) with ESMTP id 5621937B719 for ; Thu, 1 Mar 2001 17:25:14 -0800 (PST) (envelope-from john_wilson100@excite.com) Received: from prance.excite.com ([199.172.153.84]) by kuku.excite.com (InterMail vM.4.01.02.39 201-229-119-122) with ESMTP id <20010302012514.CHTG23026.kuku.excite.com@prance.excite.com> for ; Thu, 1 Mar 2001 17:25:14 -0800 Message-ID: <26889712.983496314142.JavaMail.imail@prance.excite.com> Date: Thu, 1 Mar 2001 17:25:13 -0800 (PST) From: John Wilson To: freebsd-hackers@freebsd.org Subject: Compiling FreeBSD kernel with Sun's cc Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Excite Inbox X-Sender-Ip: 192.116.157.236 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Has anyone tried using Sun's optimizing cc compiler (for Solaris x86) to compile the kernel to x86 assembly, assemble it with gas, and link with GNU ld? It seems possible for a user-level application that is source-compatible with Solaris (because cc will output assembly with system call names rather than numbers, and gas/ld fill in the system-specific blanks), but compiling the kernel seems more complicated. Is it very difficult to do / a stupid idea? John _______________________________________________________ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 18: 9:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from akira.lanfear.com (akira.lanfear.com [208.12.11.174]) by hub.freebsd.org (Postfix) with ESMTP id 7A74937B719 for ; Thu, 1 Mar 2001 18:09:27 -0800 (PST) (envelope-from mwlist@lanfear.com) Received: from sapporo.lanfear.com (h-64-105-36-216.snvacaid.covad.net [64.105.36.216]) by akira.lanfear.com (8.9.3/8.9.3) with SMTP id SAA49235 for freebsd-hackers@FreeBSD.ORG; Thu, 1 Mar 2001 18:09:26 -0800 (PST) (envelope-from mwlist@lanfear.com) Date: Thu, 1 Mar 2001 18:09:26 -0800 (PST) From: Marc W Message-Id: <200103020209.SAA49235@akira.lanfear.com> To: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Subject: Re:Compiling FreeBSD kernel with Sun's cc MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Kiltdown 0.7 i may be wrong on this, but i believe that the reason that freebsd has its 'own' version of gcc is to support some things in the kernel. thus, in addition to being mildly psychotic (;-)), it seems unlikely that this would work ... marc. > ----------------------------- > From: John Wilson > To: freebsd-hackers@FreeBSD.ORG > Subject: Compiling FreeBSD kernel with Sun's cc > Sent: 03/01/01 17:25> > > > Has anyone tried using Sun's optimizing cc compiler (for Solaris x86) to > compile the kernel to x86 assembly, assemble it with gas, and link with GNU > ld? > > It seems possible for a user-level application that is source-compatible > with Solaris (because cc will output assembly with system call names rather > than numbers, and gas/ld fill in the system-specific blanks), but compiling > the kernel seems more complicated. > > Is it very difficult to do / a stupid idea? > > John > > > > > > _______________________________________________________ > Send a cool gift with your E-Card > http://www.bluemountain.com/giftcenter/ > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 18:43:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 3BCAE37B71A for ; Thu, 1 Mar 2001 18:43:37 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id VAA12597; Thu, 1 Mar 2001 21:43:35 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.2/8.9.1) id f222h5605022; Thu, 1 Mar 2001 21:43:05 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15007.2233.875119.730345@grasshopper.cs.duke.edu> Date: Thu, 1 Mar 2001 21:43:05 -0500 (EST) To: John Wilson Cc: freebsd-hackers@freebsd.org Subject: Re: Compiling FreeBSD kernel with Sun's cc In-Reply-To: <26889712.983496314142.JavaMail.imail@prance.excite.com> References: <26889712.983496314142.JavaMail.imail@prance.excite.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Wilson writes: > Has anyone tried using Sun's optimizing cc compiler (for Solaris x86) to > compile the kernel to x86 assembly, assemble it with gas, and link with GNU > ld? > > It seems possible for a user-level application that is source-compatible > with Solaris (because cc will output assembly with system call names rather > than numbers, and gas/ld fill in the system-specific blanks), but compiling > the kernel seems more complicated. > > Is it very difficult to do / a stupid idea? > > John It sounds like a reasonable idea, if the compiler is much better than gcc and its syntax is reasonably compatable. Is their compiler much better than gcc? On the alpha, Compaq's compiler is substantially better than gcc, so I spent some time trying to get the FreeBSD/alpha kernel to compile using Compaq's C compiler. The main barrier is that gcc and ccc have different inline asm syntax. I spent most of an afternoon translating our inline asms to ccc syntax, then got distracted and never got back to it... Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 19: 4:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dayspring.firedrake.org (dayspring.firedrake.org [195.82.105.251]) by hub.freebsd.org (Postfix) with ESMTP id 7F00B37B71A; Thu, 1 Mar 2001 19:04:49 -0800 (PST) (envelope-from float@firedrake.org) Received: from float by dayspring.firedrake.org with local (Exim 3.12 #1 (Debian)) id 14Yfs7-0004ME-00; Fri, 02 Mar 2001 03:04:47 +0000 Date: Fri, 2 Mar 2001 03:04:47 +0000 To: Mike Smith Cc: Peter Seebach , freebsd-hackers@freebsd.org Subject: Re: Is mkdir guaranteed to be 'atomic' ?? Message-ID: <20010302030447.A10757@firedrake.org> References: <200102262201.f1QM1S620699@guild.plethora.net> <200102262210.f1QMAlS01993@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102262210.f1QMAlS01993@mass.dis.org>; from msmith@freebsd.org on Mon, Feb 26, 2001 at 02:10:47PM -0800 From: void Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 26, 2001 at 02:10:47PM -0800, Mike Smith wrote: > > > > Well, imagine a hypothetical broken system in which two simultaneous calls > > to mkdir, on some hypothetical broken filesystem, can each think that it > > "succeeded". After all, at the end of the operation, the directory has > > been created, so who's to say they're wrong? ;) > > Is this somehow related to memory overcommit? It's actually an interaction between that, the fxp driver, and non-reflexive stackable VFS layers. HTH, HAND. -- Ben "I told Paddy no, I told Steve no, I told Paul no, and Ben fell asleep." --Kate C. (no, different Ben, I would have stayed up) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 19:16: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id AB70E37B718 for ; Thu, 1 Mar 2001 19:16:01 -0800 (PST) (envelope-from julian@elischer.org) Received: from muzak.iinet.net.au (muzak.iinet.net.au [203.59.24.237]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id LAA18529; Fri, 2 Mar 2001 11:15:58 +0800 Received: from elischer.org (i087-112.nv.iinet.net.au [203.59.87.112]) by muzak.iinet.net.au (8.8.5/8.8.5) with ESMTP id LAA00397; Fri, 2 Mar 2001 11:12:57 +0800 Message-ID: <3A9F1065.8F738700@elischer.org> Date: Thu, 01 Mar 2001 19:15:49 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: sthaug@nethelp.no Cc: hackers@freebsd.org Subject: Re: FreeBSD on IBM's radar screen? References: <42534.983469460@verdi.nethelp.no> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG sthaug@nethelp.no wrote: > > I work mainly for Enitel, a medium sized ISP in Norway. We use FreeBSD > a lot (eivind and des can tell you more about this). Today I got an > interesting question from IBM Norway: What would be needed for IBM to > support FreeBSD for Enitel? Basically: What FreeBSD version, what kind > of hardware do we need supported, etc. (Based on IBM's Netfinity servers, > of course.) > > I told them a bit about 4.2-STABLE, which is our platform of choice, and > also mentioned that we'd be interested in the Qlogic fibre channel cards > for the higher end platforms. > > Anyway, I just wanted to mention on -hackers that it's possible FreeBSD > is starting to show up on IBM's radar screen. I think it's way too early > to conclude anything yet, but it's interesting nevertheless. remember that IBM owns whistle (until they finish integrating it into different parts of IBM and it dissappears) (burp) and have some FreeBSD experience there. > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 20:25:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from stox.sa.enteract.com (stox.sa.enteract.com [207.229.132.161]) by hub.freebsd.org (Postfix) with ESMTP id 54C4937B719 for ; Thu, 1 Mar 2001 20:25:34 -0800 (PST) (envelope-from stox@stox.sa.enteract.com) Received: (from stox@localhost) by stox.sa.enteract.com (8.11.2/8.11.2) id f224PHS01805; Thu, 1 Mar 2001 22:25:17 -0600 (CST) (envelope-from stox) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3A9F1065.8F738700@elischer.org> Date: Thu, 01 Mar 2001 22:25:17 -0600 (CST) Organization: Imaginary Landscape, LLC. From: "Kenneth P. Stox" To: Julian Elischer Subject: Re: FreeBSD on IBM's radar screen? Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 02-Mar-01 Julian Elischer wrote: > remember that IBM owns whistle (until they finish > integrating it into different parts of IBM > and it dissappears) (burp) > and have some FreeBSD experience there. The problem is that 93.7% of IBM probably has no idea that IBM owns whistle. I remember a discussion I had with an IBM sales rep working at the NCC conference in the early 1980's. He had no idea that IBM was selling systems that ran UNIX. At the time they were selling a 68K based lab system ( the 9000 ?? ) and I think were still selling the Series 1. I'm sure that things haven't changed much since. ---------------------------------- E-Mail: Kenneth P. Stox Date: 01-Mar-01 Time: 22:18:47 ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 20:44:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id A7A5A37B71B; Thu, 1 Mar 2001 20:44:22 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@dhcp152.geekhouse.net [192.168.1.152]) by moby.geekhouse.net (8.11.0/8.9.3) with ESMTP id f224iu154624; Thu, 1 Mar 2001 20:44:57 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 01 Mar 2001 20:44:04 -0800 (PST) From: John Baldwin To: Felix-Antoine Paradis Subject: RE: Kernel compilation failed. Cc: FreeBSD Questions , hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 02-Mar-01 Felix-Antoine Paradis wrote: > Hi. > > I am running FreeBSD 3.5-STABLE on a i386 arch. When I boot, it tells > me that: > > --- > sb0 at 0x220 on isa > > NOTE! SB Pro support required with your soundcard! > snd0: > --- > > So I added: > > --- > device sbxvi0 at isa? drq ? > --- > > to my kernel. Then, I recompiled and I got an error: > > --- > su-2.04# make > loading kernel > dev_table.o(.data+0xc4): undefined reference to `attach_sb16midi' > dev_table.o(.data+0xc8): undefined reference to `probe_sb16midi' > sb_dsp.o: In function `sbintr': > sb_dsp.o(.text+0xa9): undefined reference to `sb16midiintr' > *** Error code 1 > > Stop. > --- > > I did a: make depend; make; make install > > It fails in the "make". > > Any idea? Look in /sys/i386/conf/LINT. You need to add some more lines to your config file for the midi driver. I think it is called olpm0 or some such. Just look for the example snd0 in LINT. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 20:44:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id E83DF37B71D for ; Thu, 1 Mar 2001 20:44:22 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@dhcp152.geekhouse.net [192.168.1.152]) by moby.geekhouse.net (8.11.0/8.9.3) with ESMTP id f224iv154628; Thu, 1 Mar 2001 20:44:58 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200103020209.SAA49235@akira.lanfear.com> Date: Thu, 01 Mar 2001 20:44:05 -0800 (PST) From: John Baldwin To: Marc W Subject: RE: Cc: freebsd-hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 02-Mar-01 Marc W wrote: > Subject: Re:Compiling FreeBSD kernel with Sun's cc > MIME-Version: 1.0 > Content-Type: text/plain; > charset="iso-8859-1" > X-Mailer: Kiltdown 0.7 > > > i may be wrong on this, but i believe that the reason that freebsd > has its 'own' version of gcc is to support some things in the kernel. > > thus, in addition to being mildly psychotic (;-)), it seems > unlikely that this would work ... Actually, the only customizations I'm aware of are -fformat-extensions which teaches gcc about the extended printf syntax in the kernel so it can give more intelligent printf argument warnings. It's not needed and is only there to shut up annoying warnings and get a little extra sanity checking from the compiler. > marc. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 21: 4:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mgw1.MEIway.com (mgw1.meiway.com [212.73.210.75]) by hub.freebsd.org (Postfix) with ESMTP id 2BC9F37B719 for ; Thu, 1 Mar 2001 21:04:44 -0800 (PST) (envelope-from LConrad@Go2France.com) Received: from sv.Go2France.com (sv.meiway.com [212.73.210.79]) by mgw1.MEIway.com (Postfix Relay Hub) with ESMTP id 13F4A16B13 for ; Fri, 2 Mar 2001 06:16:07 +0100 (CET) Message-Id: <5.0.0.25.0.20010302055922.058e8440@mail.Go2France.com> X-Sender: lconrad%Go2France.com@mail.Go2France.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 02 Mar 2001 06:02:27 +0100 To: freebsd-hackers@freebsd.org From: Len Conrad Subject: Re: FreeBSD on IBM's radar screen? In-Reply-To: References: <3A9F1065.8F738700@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >The problem is that 93.7% of IBM probably has no idea that IBM owns whistle. > >I remember a discussion I had with an IBM sales rep working at the NCC >conference in the early 1980's. He had no idea that IBM was selling systems >that ran UNIX. At the time they were selling a 68K based lab system ( >the 9000 ?? ) and I think were still selling the Series 1. I'm sure >that things >haven't changed much since. IBM is financing postfix and Wietse Venema, but recently they felt it necessary to make a press announcement that they were standardizing on senmdmail of some Linux platform. When I asked Wietse about the sendmail announcement, he told me: "It's a big company" Len http://BIND8NT.MEIway.com : Binary for ISC BIND 8.2.3 for NT4 & W2K http://IMGate.MEIway.com : Build free, hi-perf, anti-spam mail gateways To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 21:47:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from web801.mail.yahoo.com (web801.mail.yahoo.com [128.11.23.61]) by hub.freebsd.org (Postfix) with SMTP id CD8D437B71E for ; Thu, 1 Mar 2001 21:47:46 -0800 (PST) (envelope-from jafour2@yahoo.com) Received: (qmail 14057 invoked by uid 60001); 2 Mar 2001 05:47:46 -0000 Message-ID: <20010302054746.14056.qmail@web801.mail.yahoo.com> Received: from [24.28.94.107] by web801.mail.yahoo.com; Thu, 01 Mar 2001 21:47:46 PST Date: Thu, 1 Mar 2001 21:47:46 -0800 (PST) From: Jaime Fournier Subject: Re: FreeBSD on S/390? To: Matthew Emmerton , Robert Watson Cc: Ken Bolingbroke , freebsd-hackers@FreeBSD.ORG, freebsd-platforms@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --- Matthew Emmerton wrote: > On Thu, 1 Mar 2001, Robert Watson wrote: > > > On Wed, 28 Feb 2001, Ken Bolingbroke wrote: > > > > > Long shot, probably, but I've got a bunch of > virtual machines on an IBM > > > S/390 mainframe, and while we're running SuSE > Linux on most of them, on > > > a whim I tossed out the idea of running FreeBSD > on one of them, and to > > > my surprise, it was taken seriously. > > > > > > So, has anyone done any work with getting > FreeBSD running on a S/390? > > > What can I do to make it happen if there's > interest? > > > > Well, as you've seen from the two responses > already, the implicit answer > > to your question of "has anyone done any work" > appears to be "no" :-). > > However, I think a number of us in the developer > community see this as a > > fairly serious gap, and would like to remedy this. > However, IBM hasn't > > been dropping S/390 machines and documentation in > anyone's laps (at least, > > not mine, and no one else has mentioned it), so > the primary facilitators > > would be, as with any new hardware port: > > > > 1) Access to necessary technical documentation and > expertise > > 2) Access to hardware > > 3) Someone with appropriate expertise willing the > guide ("own", if you > > will) the port to the platform through to > completion, and continue to > > provide on-going maintainership in the face of > adversity (someone adds > > fine-grained SMP support and it falls on the > maintainer to figure out > > how that works on their platform, if no one has > hardware). > > > > Part of the "real answer" is probably that IBM or > a large consumer of > > S/390 machines has to shepherd the whole process > to make it happen, and > > that probably involves a moderate amount of money, > and moderate levels of > > frustration. If you can provide access to the > first and survive the > > second, then you can certainly make this a > reality. If not, well, it > > would be nice to see it happen but the task is to > identify someone who can > > provide these. > > Well, I'm starting with IBM in May at their Toronto > Labs. All of my > managers were particularly interested in my > non-Linux open source activity > (what is this FreeBSd thing that you talk about?) > > I'm not promising anything, but I too would *love* > to get IBM supporting > FreeBSD in some way. Perhaps a version of JFS > released under the BSD > licence would be a start, and then hardware support > for RS/6k and S/390. > > I will keep my eyes and ears open for anything > useful that falls my way. > > -- > Matt Emmerton > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of > the message Well, I work for IBM for 4 years, and at one time they did not know what Linux was. I run freebsd at work on my workstation, and have to pass it off as a "linux distribution" in order for people to understand what it is. Some interesting news is that in front of the IBM building here in austin they raised a flag that said "Peace, Love, and linux". So go figure. Linux seems to have more talk internally than actual use. But given how big IBM is it is hard to say what any other part of it is doing. __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 22:26:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peorth.iteration.net (peorth.iteration.net [208.190.180.178]) by hub.freebsd.org (Postfix) with ESMTP id C556B37B718 for ; Thu, 1 Mar 2001 22:26:34 -0800 (PST) (envelope-from keichii@peorth.iteration.net) Received: by peorth.iteration.net (Postfix, from userid 1001) id CE92359563; Fri, 2 Mar 2001 00:26:35 -0600 (CST) Date: Fri, 2 Mar 2001 00:26:35 -0600 From: "Michael C . Wu" To: Jaime Fournier Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD on S/390? Message-ID: <20010302002635.C18255@peorth.iteration.net> Reply-To: "Michael C . Wu" Mail-Followup-To: "Michael C . Wu" , Jaime Fournier , freebsd-hackers@freebsd.org References: <20010302054746.14056.qmail@web801.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010302054746.14056.qmail@web801.mail.yahoo.com>; from jafour2@yahoo.com on Thu, Mar 01, 2001 at 09:47:46PM -0800 X-PGP-Fingerprint: 5025 F691 F943 8128 48A8 5025 77CE 29C5 8FA1 2E20 X-PGP-Key-ID: 0x8FA12E20 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Mar 01, 2001 at 09:47:46PM -0800, Jaime Fournier scribbled: | Well, I work for IBM for 4 years, and at one time they | did not know what Linux was. I run freebsd at work on | my workstation, and have to pass it off as a "linux | distribution" in order for people to understand what | it is. Some interesting news is that in front of the | IBM building here in austin they raised a flag that | said "Peace, Love, and linux". | So go figure. Linux seems to have more talk internally | than actual use. But given how big IBM is it is hard | to say what any other part of it is doing. Why, this calls for a prank. Let's go there and make the changes more to our liking :) -- +------------------------------------------------------------------+ | keichii@peorth.iteration.net | keichii@bsdconspiracy.net | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +------------------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 22:48:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (fw2.aub.dk [195.24.1.195]) by hub.freebsd.org (Postfix) with ESMTP id 60F1137B71B for ; Thu, 1 Mar 2001 22:48:04 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f21I61M41896; Thu, 1 Mar 2001 19:06:01 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Patrick O'Reilly" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Hardware question - WAN port for FreeBSD router! In-Reply-To: Your message of "Thu, 01 Mar 2001 17:05:29 +0200." Date: Thu, 01 Mar 2001 19:06:01 +0100 Message-ID: <41894.983469961@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , "Patrick O'Reilly" writes: >Hi all. > >Please forgive me if this post is altogether in the wrong place, but I need >help finding a certain piece of hardware. > >I have a number of firewalls running (very happily) on FreeBSD. Each one is >connected on the outside NIC to a Cisco 1601 Router, which is connected in >turn to an NTU etc.... > >I am sure I could save a lot by installing a WAN card directly into the BSD >firewall, thereby doing without the Router altogether - FreeBSD can do all >the routing I need after all! > >So - is there such a WAN serial card available? And (most important) one >which is supported by the necessary BSD drivers? www.lanmedia.com, they have a T1/E1 card... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 22:57: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 61B6137B718 for ; Thu, 1 Mar 2001 22:57:04 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14YjfU-0000JD-00; Fri, 02 Mar 2001 00:08:00 -0700 Message-ID: <3A9F46D0.B74159DA@softweyr.com> Date: Fri, 02 Mar 2001 00:08:00 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Kenneth P. Stox" Cc: Julian Elischer , hackers@FreeBSD.ORG Subject: Re: FreeBSD on IBM's radar screen? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Kenneth P. Stox" wrote: > > On 02-Mar-01 Julian Elischer wrote: > > remember that IBM owns whistle (until they finish > > integrating it into different parts of IBM > > and it dissappears) (burp) > > and have some FreeBSD experience there. > > The problem is that 93.7% of IBM probably has no idea that IBM owns whistle. Make that 99.99937% of IBM, it's a BIG company. > I remember a discussion I had with an IBM sales rep working at the NCC > conference in the early 1980's. He had no idea that IBM was selling systems > that ran UNIX. At the time they were selling a 68K based lab system ( > the 9000 ?? ) The CS-9000, M68K + some weird limited operating system. It was developed and sold by the IBM Instrumentation division, and had an IEEE-488 port. Remember those? > and I think were still selling the Series 1. I'm sure that things > haven't changed much since. Or System/36, or one of those blecherous little monstrosities. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 1 23:31:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mip.co.za (puck.mip.co.za [209.212.106.44]) by hub.freebsd.org (Postfix) with ESMTP id 3129937B71A for ; Thu, 1 Mar 2001 23:30:58 -0800 (PST) (envelope-from patrick@mip.co.za) Received: from patrick (patrick.mip.co.za [10.3.13.181]) by mip.co.za (8.9.3/8.9.3) with SMTP id JAA87192 for ; Fri, 2 Mar 2001 09:30:55 +0200 (SAST) (envelope-from patrick@mip.co.za) From: "Patrick O'Reilly" To: Subject: RE: Hardware question - WAN port for FreeBSD router! Date: Fri, 2 Mar 2001 09:30:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi again. Thanks to all for your responses to my question, I will investigate the options. Patrick. -----Original Message----- From: owner-freebsd-hackers@FreeBSD.ORG [mailto:owner-freebsd-hackers@FreeBSD.ORG]On Behalf Of Patrick O'Reilly Sent: 01 March 2001 17:05 To: freebsd-hackers@FreeBSD.ORG Subject: Hardware question - WAN port for FreeBSD router! Hi all. Please forgive me if this post is altogether in the wrong place, but I need help finding a certain piece of hardware. I have a number of firewalls running (very happily) on FreeBSD. Each one is connected on the outside NIC to a Cisco 1601 Router, which is connected in turn to an NTU etc.... I am sure I could save a lot by installing a WAN card directly into the BSD firewall, thereby doing without the Router altogether - FreeBSD can do all the routing I need after all! So - is there such a WAN serial card available? And (most important) one which is supported by the necessary BSD drivers? Any pointers would be MUCH appreciated. Regards, Patrick O'Reilly --- "I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forego their use." -- Galileo Galilei To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 4:16:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from primo.verat.net (primo.verat.net [217.26.64.130]) by hub.freebsd.org (Postfix) with ESMTP id 35C9F37B718 for ; Fri, 2 Mar 2001 04:16:13 -0800 (PST) (envelope-from milunovic@sendmail.ru) Received: from scorpion.cosmos.all.net (ppp-87.verat.net [217.26.65.87]) by primo.verat.net (8.9.3/8.9.3) with ESMTP id NAA29974 for ; Fri, 2 Mar 2001 13:16:08 +0100 Received: from scorpion.cosmos.all.net (scorpion.cosmos.all.net [127.0.0.1]) by scorpion.cosmos.all.net (8.11.2/8.11.2) with ESMTP id f22CN4005093 for ; Fri, 2 Mar 2001 13:23:06 +0100 (CET) Date: Fri, 2 Mar 2001 13:23:01 +0100 (CET) From: milunovic X-Sender: milunovic@scorpion.cosmos.all.net To: hackers@freebsd.org Subject: blow fish Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- Does anybody have blow fish for FreeBSD or know wehere to find it? I just want to change password encription from MD5 to blow fish:o) Vojislav Milunovic milunovic@sendmail.ru -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQEVAwUBOp+QqC3gPLld8IkLAQEYoAf7B03lKgYhL1ClCKPIJphHqYrIjfs+SYpJ 0FJxkVK23azHyioDVXwSUH5i6C7GMkmFsiuW+xcNNrwY91IRBmJr7iwfJgdZovT2 8GJxxb0z9ByV5CtWGSYdoFF91grgsduaBFMXGOmFTjL5BDD9sA19SP5cppqB0i1k 7d0/fDrg8Pja7DBFYMOoZ51POBn9upvp0XecIoMkxk13axRE/JU/2Ugi/eEPvkoF jdaEqrPzjfjjC1qENhzSk2An6SIY640njyj0iJocgOj/Qa1fMvpPH72quw8vQkw2 icAasJU82JhiAUNHdKe87KnDUM/3vpyJfzG6cMBFhT3AqMWzzDUy5Q== =aNKQ -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 4:26:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id C4AA037B718 for ; Fri, 2 Mar 2001 04:26:27 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 2768 invoked by uid 1000); 2 Mar 2001 12:26:03 -0000 Date: Fri, 2 Mar 2001 14:26:03 +0200 From: Peter Pentchev To: milunovic Cc: hackers@freebsd.org Subject: Re: blow fish Message-ID: <20010302142603.A2609@ringworld.oblivion.bg> Mail-Followup-To: milunovic , hackers@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from milunovic@sendmail.ru on Fri, Mar 02, 2001 at 01:23:01PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Mar 02, 2001 at 01:23:01PM +0100, milunovic wrote: > > Does anybody have blow fish for FreeBSD or know wehere to find it? > I just want to change password encription from MD5 to blow fish:o) A little question: why? MD5 seems to be secure enough. Other than that, look at the security/libmcrypt port, it has Blowfish as an available encryption algorithm. It's not in a usable form for password encryption, though; you need to pull out the guts of the encryption function and build your own crypt() function. G'luck, Peter -- If wishes were fishes, the antecedent of this conditional would be true. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 4:32: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id DAEB037B719 for ; Fri, 2 Mar 2001 04:32:01 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 2814 invoked by uid 1000); 2 Mar 2001 12:31:41 -0000 Date: Fri, 2 Mar 2001 14:31:41 +0200 From: Peter Pentchev To: milunovic Cc: hackers@freebsd.org Subject: Re: blow fish Message-ID: <20010302143141.B2609@ringworld.oblivion.bg> Mail-Followup-To: milunovic , hackers@freebsd.org References: <20010302142603.A2609@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010302142603.A2609@ringworld.oblivion.bg>; from roam@orbitel.bg on Fri, Mar 02, 2001 at 02:26:03PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Mar 02, 2001 at 02:26:03PM +0200, Peter Pentchev wrote: > On Fri, Mar 02, 2001 at 01:23:01PM +0100, milunovic wrote: > > > > Does anybody have blow fish for FreeBSD or know wehere to find it? > > I just want to change password encription from MD5 to blow fish:o) > > A little question: why? MD5 seems to be secure enough. > > Other than that, look at the security/libmcrypt port, it has Blowfish > as an available encryption algorithm. It's not in a usable form for > password encryption, though; you need to pull out the guts of the > encryption function and build your own crypt() function. Come to think of it, there's nothing that would prevent security/libmcrypt to be part of the authentication process (not crypt(), though). Is there something inherently flawed in the idea of a PAM module using libs which do not live in /usr, but in /usr/local? G'luck, Peter -- If I had finished this sentence, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 4:48:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from primo.verat.net (primo.verat.net [217.26.64.130]) by hub.freebsd.org (Postfix) with ESMTP id 543E437B71A for ; Fri, 2 Mar 2001 04:48:27 -0800 (PST) (envelope-from milunovic@sendmail.ru) Received: from scorpion.cosmos.all.net (ppp-87.verat.net [217.26.65.87]) by primo.verat.net (8.9.3/8.9.3) with ESMTP id NAA01013; Fri, 2 Mar 2001 13:47:23 +0100 Received: from scorpion.cosmos.all.net (scorpion.cosmos.all.net [127.0.0.1]) by scorpion.cosmos.all.net (8.11.2/8.11.2) with ESMTP id f22Cp0011500; Fri, 2 Mar 2001 13:51:56 +0100 (CET) Date: Fri, 2 Mar 2001 13:50:53 +0100 (CET) From: milunovic X-Sender: milunovic@scorpion.cosmos.all.net To: Peter Pentchev Cc: hackers@freebsd.org Subject: Re: blow fish In-Reply-To: <20010302142603.A2609@ringworld.oblivion.bg> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- On Fri, 2 Mar 2001, Peter Pentchev wrote: > A little question: why? MD5 seems to be secure enough. Just to try it:o) Vojislav Milunovic milunovic@sendmail.ru -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQEVAwUBOp+XMy3gPLld8IkLAQGGwgf6A3vwNZt14RitgklZG6GCCZCVoO18PZbX TRzwnOf25wD0noHcoSknwbVJ8T+A0/DMMUoMhIMjJ9vElXDXVIML92N46WICbYBj tZX1Ofb34jg/f5mK+eXqKagjqFUge8FVTzqfOeqp7Kkh40IwRGG96eWgJdzvI3e8 Ablcyr8hFC1ouXDLBfu3/hj5zBWx38VsabBgrMvMTwyPkGqsID5IBWH6X4k6odO5 sp1nCfOjZA8d4/yl1gofSSKmX2sAdUGE//RJJlAVBhDrCYR6AGHdlwF6Sn5fywdt NFgISDlJiCMRBjHXoIqRhdEIgkQudgyxUYCvWXA/JeU2a0u3sL1t5g== =DELV -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 4:59:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 651D037B719 for ; Fri, 2 Mar 2001 04:59:41 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id NAA84915; Fri, 2 Mar 2001 13:59:35 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Peter Dufault Cc: Anton Berezin , hackers@FreeBSD.ORG Subject: Re: how to actually find out whether data hit the disk? References: <200102281418.f1SEILG28001@hda.hda.com> From: Dag-Erling Smorgrav Date: 02 Mar 2001 13:59:34 +0100 In-Reply-To: Peter Dufault's message of "Wed, 28 Feb 2001 09:18:21 -0500 (EST)" Message-ID: Lines: 14 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Dufault writes: > > > Do an msync with MS_SYNC someplace. Also, use MAP_NOSYNC in > > > mmap until 4.3 when Matt Dillon plans to make that the default behavior. > > Ahh, no. That's the other way around - I do not *want* it to hit the > > disk, but would like to *know* when it nevertheless does. > OK, doing a stat and checking the mtime should give you > the info at the expense of polling, I can't think of another way. Won't help. You'll get the same mtime no matter whether the file is actually written to disk or not. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 5: 7: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id C510B37B71C for ; Fri, 2 Mar 2001 05:06:54 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.11.1/8.11.1) id f22D52P36608; Fri, 2 Mar 2001 08:05:02 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200103021305.f22D52P36608@hda.hda.com> Subject: Re: Stupid debugging pthread question In-Reply-To: from "E.B. Dreger" at "Mar 1, 2001 06:41:25 pm" To: "E.B. Dreger" Date: Fri, 2 Mar 2001 08:04:52 -0500 (EST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Date: Thu, 1 Mar 2001 12:44:39 -0500 (EST) > > From: Peter Dufault > > > > This is a stupid question, basically it's how to debug something. > > > > I have four cooperating p-threaded processes. One of them keeps getting > > a SIGSEGV with the address 0x752f422f. I'm not sure if that address is > > always the same, but with a given compile it is. The thing that's a pain > > is it is random. The four processes can run for a long time, or through > > several tests to completion, and then the > > nasty process gets that SIGSEGV. The thread that receives the SIGSEGV > > is random, the stack of the SEGV'd thread is trash, the rest of the > > threads in the offending process still have intact stacks. Arg! > > Sounds like maybe a buffer overrun or something might be trashing a return > pointer. Not sure what the exact cause is, but if that address is not an > actual address, I'd suspect that a return pointer is getting trashed. > > Any strings "/B/u" in your program? That would be stored as 0x752f422f. > > If you're using assembly with using %ebp for stack frame (yay!), then make > certain %esp isn't getting corrupted. Very good, I read those high bits off-by-one and stupidly didn't recognize the ascii: > (gdb) x/s $esp-8 > 0x826b400 : "/wd0/B/usr-src/lib/libc_r/uthread/uthread_dup2.c" > (gdb) I guess it is the "thread_fd_lock_debug/_thread_fd_unlock_debug" calls with __FILE__ that push this on the stack. I'll build a debuggable libc_r and see I see. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 5:31:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from heechee.tobez.org (254.adsl0.ryv.worldonline.dk [213.237.10.254]) by hub.freebsd.org (Postfix) with ESMTP id A715037B71C for ; Fri, 2 Mar 2001 05:31:50 -0800 (PST) (envelope-from tobez@tobez.org) Received: by heechee.tobez.org (Postfix, from userid 1001) id 3391754F8; Fri, 2 Mar 2001 14:31:49 +0100 (CET) Date: Fri, 2 Mar 2001 14:31:49 +0100 From: Anton Berezin To: Dag-Erling Smorgrav Cc: Peter Dufault , hackers@FreeBSD.ORG Subject: Re: how to actually find out whether data hit the disk? Message-ID: <20010302143149.D55912@heechee.tobez.org> References: <200102281418.f1SEILG28001@hda.hda.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Fri, Mar 02, 2001 at 01:59:34PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Mar 02, 2001 at 01:59:34PM +0100, Dag-Erling Smorgrav wrote: > Peter Dufault writes: > > > > Do an msync with MS_SYNC someplace. Also, use MAP_NOSYNC in > > > > mmap until 4.3 when Matt Dillon plans to make that the default behavior. > > > Ahh, no. That's the other way around - I do not *want* it to hit the > > > disk, but would like to *know* when it nevertheless does. > > OK, doing a stat and checking the mtime should give you > > the info at the expense of polling, I can't think of another way. > > Won't help. You'll get the same mtime no matter whether the file is > actually written to disk or not. That's what I suspected. :-( So is there a way, or is not? Thanks, -- May the tuna salad be with you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 5:33:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 6236A37B71E for ; Fri, 2 Mar 2001 05:33:17 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id OAA85056; Fri, 2 Mar 2001 14:33:15 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Anton Berezin Cc: Peter Dufault , hackers@FreeBSD.ORG Subject: Re: how to actually find out whether data hit the disk? References: <200102281418.f1SEILG28001@hda.hda.com> <20010302143149.D55912@heechee.tobez.org> From: Dag-Erling Smorgrav Date: 02 Mar 2001 14:33:14 +0100 In-Reply-To: Anton Berezin's message of "Fri, 2 Mar 2001 14:31:49 +0100" Message-ID: Lines: 8 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Anton Berezin writes: > So is there a way, or is not? No. If there was a way to tell it'd be a bug. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 5:43:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from a.mx.everquick.net (a.mx.everquick.net [216.89.137.3]) by hub.freebsd.org (Postfix) with ESMTP id 365A037B718 for ; Fri, 2 Mar 2001 05:43:42 -0800 (PST) (envelope-from eddy+public+spam@noc.everquick.net) Received: from localhost (eddy@localhost) by a.mx.everquick.net (8.9.0/8.8.7) with ESMTP id NAA11990; Fri, 2 Mar 2001 13:43:35 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Date: Fri, 2 Mar 2001 13:43:35 +0000 (GMT) From: "E.B. Dreger" To: Peter Dufault Cc: hackers@FreeBSD.ORG Subject: Re: Stupid debugging pthread question In-Reply-To: <200103021305.f22D52P36608@hda.hda.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Date: Fri, 2 Mar 2001 08:04:52 -0500 (EST) > From: Peter Dufault > > Any strings "/B/u" in your program? That would be stored as 0x752f422f. > > > > If you're using assembly with using %ebp for stack frame (yay!), then make > > certain %esp isn't getting corrupted. (I meant _without_ %ebp, but I didn't want to repost.) > Very good, I read those high bits off-by-one and stupidly didn't recognize > the ascii: > > > (gdb) x/s $esp-8 > > 0x826b400 : "/wd0/B/usr-src/lib/libc_r/uthread/uthread_dup2.c" > > (gdb) > > I guess it is the "thread_fd_lock_debug/_thread_fd_unlock_debug" > calls with __FILE__ that push this on the stack. I'll build a > debuggable libc_r and see I see. Hmmmm. That "/B/u" portion is toward the beginning of the string, not the end as one would expect from an overrun. It looks like the string is getting written to -4(%esp,1), where %esp is the initial stack pointer. Note that the return address is at 0(%esp,1). What is the first variable that you declare in the function? /* Note use of "&trashme" instead of "trashme" */ void foo (void) { char *trashme; strcpy((char*)&trashme, "/wd0/B/usr-src/libc/libc_r..."); } If you compile using -fomit-frame-pointer, I _think_ that "trashme" would be at -4(%esp,1). (Otherwise, %ebp would be saved at that address.) It looks like you might be passing the address of a 32-bit variable to a string function when you should be passing the contents. Anyone have any other ideas off the top of their head? Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet / EternalCommerce Division E-Mail: eddy@everquick.net Phone: (316) 794-8922 --------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 5:46:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.10]) by hub.freebsd.org (Postfix) with ESMTP id 8BAEE37B719; Fri, 2 Mar 2001 05:46:12 -0800 (PST) (envelope-from danny@cs.huji.ac.il) Received: from sexta.cs.huji.ac.il ([132.65.16.13] ident=danny) by cs.huji.ac.il with esmtp (Exim 3.20 #1) id 14Ypso-0006hc-00; Fri, 02 Mar 2001 15:46:10 +0200 X-Mailer: exmh version 2.2 06/23/2000 with nmh-0.24 To: FreeBSD-stable Cc: hackers@FreeBSD.ORG Subject: wchan kqread Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 Mar 2001 15:46:10 +0200 From: Danny Braniss Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG with the latest kernel (4.2, cvsuped today), some processes get stuck for a long time with WCHAN kqread - mainly login, top, netstart -r, with an old kernel (about Feb 11 all is ok). what did i screw up? danny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 5:48:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id 5891B37B718 for ; Fri, 2 Mar 2001 05:48:05 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.11.1/8.11.1) id f22Diw636709; Fri, 2 Mar 2001 08:44:58 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200103021344.f22Diw636709@hda.hda.com> Subject: Re: how to actually find out whether data hit the disk? In-Reply-To: from Dag-Erling Smorgrav at "Mar 2, 2001 01:59:34 pm" To: Dag-Erling Smorgrav Date: Fri, 2 Mar 2001 08:44:58 -0500 (EST) Cc: Anton Berezin , hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM983540698-36466-0_ Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --ELM983540698-36466-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Peter Dufault writes: > > > > Do an msync with MS_SYNC someplace. Also, use MAP_NOSYNC in > > > > mmap until 4.3 when Matt Dillon plans to make that the default behavior. > > > Ahh, no. That's the other way around - I do not *want* it to hit the > > > disk, but would like to *know* when it nevertheless does. > > OK, doing a stat and checking the mtime should give you > > the info at the expense of polling, I can't think of another way. > > Won't help. You'll get the same mtime no matter whether the file is > actually written to disk or not. No, the spec says: If there was no such call [to msync] these fields [st_ctime and st_mtime] may be marked for update at any time after a write reference if the underlying file is modified as a result. I wrote a program (attached) to verify it. Here's the output: > mapped at 08:34:04.206204 modification time 08:34:04.000000000 > modified at 08:34:05.210740 modification time 08:34:04.000000000 > unmapped at 08:34:06.220744 modification time 08:34:04.000000000 > remapped at 08:34:07.230750 modification time 08:34:04.000000000 > msync at 08:34:08.247007 modification time 08:34:08.000000000 Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval --ELM983540698-36466-0_ Content-Type: text/plain; charset=US-ASCII Content-Disposition: attachment; filename=main.c Content-Description: /tmp/main.c Content-Transfer-Encoding: 7bit #include #include #include #include #include #include #include #include #include #ifndef MAP_NOSYNC #define MAP_NOSYNC 0 #endif static const char *name = "mapped_file"; static void put_tv(FILE *f, struct timeval *pTv) { struct tm tm; struct timeval tv; if (pTv == 0) { gettimeofday(&tv, 0); pTv = &tv; } localtime_r(&pTv->tv_sec, &tm); fprintf(f, "%02d:%02d:%02d.%06ld", tm.tm_hour, tm.tm_min, tm.tm_sec, pTv->tv_usec); } static void put_ts(FILE *f, struct timespec *pTs) { struct tm tm; localtime_r(&pTs->tv_sec, &tm); fprintf(f, "%02d:%02d:%02d.%09ld", tm.tm_hour, tm.tm_min, tm.tm_sec, pTs->tv_nsec); } static void quit_if(long code, long value, const char *s) { if (code == value) { perror(s); exit(1); } } static void status(FILE *f, const char *p, const int fd) { struct stat st; fstat(fd, &st); fprintf(f, "%12s ", p); put_tv(f, 0); fprintf(f, " modification time "); put_ts(f, &st.st_mtimespec); putchar('\n'); } int main(int ac, char *av[]) { void *p; long pagesize; int i, fd; void *buff; pagesize = sysconf(_SC_PAGESIZE); (void)unlink(name); errno = 0; quit_if((fd = open(name, O_RDWR|O_CREAT, 0666)), -1, "open"); buff = calloc(1, pagesize); quit_if((long)(p = mmap(0, 10*pagesize, PROT_READ|PROT_WRITE, MAP_NOSYNC|MAP_SHARED, fd, (off_t)0)), (long)MAP_FAILED, "mmap"); for (i = 0; i < 10; i++) { write(fd, buff, pagesize); } status(stdout, "mapped at", fd); sleep(1); *(long *)p = -1; status(stdout, "modified at", fd); sleep(1); munmap(p, 10*pagesize); status(stdout, "unmapped at", fd); sleep(1); quit_if((long)(p = mmap(0, 10*pagesize, PROT_READ|PROT_WRITE, MAP_NOSYNC|MAP_SHARED, fd, (off_t)0)), (long)MAP_FAILED, "mmap"); status(stdout, "remapped at", fd); sleep(1); quit_if(msync(p, 10*pagesize, MS_SYNC), -1, "msync"); status(stdout, "msync at", fd); close(fd); return 0; } --ELM983540698-36466-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 5:49:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 3F8B937B71A for ; Fri, 2 Mar 2001 05:49:44 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id OAA85138; Fri, 2 Mar 2001 14:49:39 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Peter Dufault Cc: Anton Berezin , hackers@FreeBSD.ORG Subject: Re: how to actually find out whether data hit the disk? References: <200103021344.f22Diw636709@hda.hda.com> From: Dag-Erling Smorgrav Date: 02 Mar 2001 14:49:39 +0100 In-Reply-To: Peter Dufault's message of "Fri, 2 Mar 2001 08:44:58 -0500 (EST)" Message-ID: Lines: 11 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Dufault writes: > > Won't help. You'll get the same mtime no matter whether the file is > > actually written to disk or not. > No, the spec says: [...] Oops, I was thinking "regular file with softupdates", not "mmapped file" (note to self: get more sleep) DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 6:27:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from a.mx.everquick.net (a.mx.everquick.net [216.89.137.3]) by hub.freebsd.org (Postfix) with ESMTP id 78C5D37B718 for ; Fri, 2 Mar 2001 06:27:40 -0800 (PST) (envelope-from eddy+public+spam@noc.everquick.net) Received: from localhost (eddy@localhost) by a.mx.everquick.net (8.9.0/8.8.7) with ESMTP id OAA12456 for ; Fri, 2 Mar 2001 14:27:40 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Date: Fri, 2 Mar 2001 14:27:40 +0000 (GMT) From: "E.B. Dreger" To: freebsd-hackers@freebsd.org Subject: need help: mmap() / vm_map_stack() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greetings, This is something of a repost of an earlier question, but in a different vein. I should mention that I'm using 4.2-R. Has anyone modified vm_map_stack(), in /usr/src/sys/vm/vm_map.c, to search for the first suitable open block? I tried modifying vm_map_stack() based on vm_map_find(), but get: * kernel panic upon boot ("Bad entry start/end for new stack entry") * kernel panic when attempting to search for a block using mmap(MAP_STACK) * _duplicate_ values returned when searching using mmap(MAP_STACK) depending upon the exact code that I tried. I know that the first two symptoms are when I made a fubar vm_map_stack(). I'm rather new to the kernel code, so I'm sure that I'm doing something wrong... For the last problem, I made certain that I had vm_map_lock()'ed, ran at splvm()... same thing. I then sleep()'ed between mmap() calls... same thing. I've concluded that I need to learn more about vm_map_entry_t and friends, but wanted to see if anyone had any suggestions before I went chasing the wrong thing... I'm almost tempted to try having vm_map_stack() call vm_map_find() with size SGROWSIZ, shrink it to the initial size, then alter vm_map_entry_t entries as needed based upon current vm_map_stack() code. Advice? Just keep digging? :-) Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet / EternalCommerce Division E-Mail: eddy@everquick.net Phone: (316) 794-8922 --------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 7: 6:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id 4BE0A37B71B for ; Fri, 2 Mar 2001 07:06:40 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.11.1/8.11.1) id f22F6AL37014; Fri, 2 Mar 2001 10:06:10 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200103021506.f22F6AL37014@hda.hda.com> Subject: Re: Stupid debugging pthread question In-Reply-To: <200103021305.f22D52P36608@hda.hda.com> from Peter Dufault at "Mar 2, 2001 08:04:52 am" To: hackers@freebsd.org Date: Fri, 2 Mar 2001 10:06:10 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > (gdb) x/s $esp-8 > > 0x826b400 : "/wd0/B/usr-src/lib/libc_r/uthread/uthread_dup2.c" > > (gdb) > > I guess it is the "thread_fd_lock_debug/_thread_fd_unlock_debug" > calls with __FILE__ that push this on the stack. I'll build a > debuggable libc_r and see I see. Well, of course with the library compiled with -g and without -O the problem went away. However, I do have a call to "dup2" for some threads in a function installed with "pthread_switch_add_np" > #ifdef HAVE_PTHREAD_NP > pthread_switch_add_np(px_switch); > #endif in order to mimic the vxWorks behavior of having a different file 0, 1, and 2 per thread. By disabling this the behavior goes away, apparently what I'm doing is illegal. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 7: 6:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cyclone.eis.ru (for.spb.ru [195.201.69.16]) by hub.freebsd.org (Postfix) with SMTP id 82C1537B71A for ; Fri, 2 Mar 2001 07:06:29 -0800 (PST) (envelope-from diwil@eis.ru) Received: (qmail 90525 invoked from network); 2 Mar 2001 15:15:16 -0000 Received: from good.for.spb.ru (HELO runnet-gw.marketsite.ru) (195.201.69.80) by for.spb.ru with SMTP; 2 Mar 2001 15:15:16 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Fri, 02 Mar 2001 18:02:56 +0300 (MSK) Reply-To: diwil@eis.ru From: Dmitry Dicky To: freebsd-hackers@freebsd.org Subject: stupid device driver question Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi fellows, I'm writing some device driver which should pass some data to the user space. The part of the device read routine looks as follows: ---------------------------------- int dev_read(dev_t dev, struct uio *uio, int ioflag) { int err = 0; /* ... */ amnt = MIN(uio->uio_resid, cntw); /* Wait here until data available .... how? */ err = uiomove(buf2, amnt, uio); if (err != 0) { return(err); } memset(buf2, 0, amnt); cntw -= amnt; return 0; } ------------------------------------- User application hands on read(2). But buf2 being filled upon some event and 'dev_read' should wait until data in buf2 available. So, the question is: How can I hang dev_read, issue some signal and then continue uiomove(9) data to the user space? Thanks in advance, D. -- ********************************************************************* ("`-''-/").___..--''"`-._ (\ Dimmy the Wild UA1ACZ `6_ 6 ) `-. ( ).`-.__.`) Enterprise Information Sys (_Y_.)' ._ ) `._ `. ``-..-' Nevsky prospekt, 20 / 44 _..`--'_..-_/ /--'_.' ,' Saint Petersburg, Russia (il),-'' (li),' ((!.-' +7 (812) 3148860, 5585314 ********************************************************************* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 8:40:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from server1.manmail.norlight.net (server1.manmail.norlight.net [207.170.4.2]) by hub.freebsd.org (Postfix) with SMTP id 66B2B37B718 for ; Fri, 2 Mar 2001 08:40:27 -0800 (PST) (envelope-from hyun@staff.norlight.net) Received: (qmail 31786 invoked from network); 2 Mar 2001 16:40:18 -0000 Received: from gw-app-eng.norlight.net (HELO staff.norlight.net) (207.170.1.30) by server1.manmail.norlight.net with SMTP; 2 Mar 2001 16:40:18 -0000 Message-ID: <3A9FCCF8.F05F4C3E@staff.norlight.net> Date: Fri, 02 Mar 2001 10:40:24 -0600 From: Hyunseog Ryu Organization: Norlight Telecommunications X-Mailer: Mozilla 4.72 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: BIND 9.1.1 and FBSD 4.2-stable Content-Type: multipart/mixed; boundary="------------271251D22325AA635DDF2B01" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------271251D22325AA635DDF2B01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, folks I have questions for BIND version 9.1.1rc2. I submitted original question to freebsd-isp@freebsd.org, but couldn't get an answer for this. Recently I installed BIND 9.1.1rc2 into one of FreeBSD 4.2-stable version. After installation of BIND, it works fine for a while. But when I look at the "top" command output, it says that memory consumption of named is increasing continuously. Yesterday I saw that named consumed more than 67MB memory. And today named suddenly stopped to respond. Do you guys have similar problem? > uname -a FreeBSD weiss.norlight.net 4.2-STABLE FreeBSD 4.2-STABLE #0: Mon Feb 19 18:35:06 CST 2001 root@test.norlight.net:/usr/src/sys/compile/weiss i386 > > top last pid: 43099; load averages: 0.22, 0.21, 0.17 up 9+05:05:33 18:10:51 26 processes: 1 running, 25 sleeping CPU states: 8.6% user, 0.0% nice, 2.7% system, 0.0% interrupt, 88.7% idle Mem: 35M Active, 22M Inact, 25M Wired, 5424K Cache, 22M Buf, 35M Free Swap: 256M Total, 1612K Used, 254M Free PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 42818 dns 2 0 29472K 28528K poll 18:02 10.79% 10.79% named 43099 admin 28 0 1872K 1020K RUN 0:00 1.21% 0.44% top 81 root 2 0 916K 268K select 6:36 0.00% 0.00% syslogd 36216 admin 2 0 1884K 604K select 4:51 0.00% 0.00% top 114 root 2 0 2404K 588K select 3:20 0.00% 0.00% sshd 110 root 2 0 2496K 728K select 0:21 0.00% 0.00% sendmail 107 root 10 0 960K 236K nanslp 0:07 0.00% 0.00% cron 42846 root 2 0 2344K 1500K select 0:03 0.00% 0.00% ssh 42997 root 2 0 2436K 1532K select 0:01 0.00% 0.00% sshd I don't know what caused this problem. Please give me some idea to resolve this. Second, when named leaves syslog, timestamp looks like GMT. Not CST that we configured. Is there any way I can change this? Thanks for your help in advance. Best regards, Hyun --------------271251D22325AA635DDF2B01 Content-Type: text/x-vcard; charset=us-ascii; name="hyun.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Hyunseog Ryu Content-Disposition: attachment; filename="hyun.vcf" begin:vcard n:Ryu;Hyunseig tel;fax:262-792-7655 tel;work:262-792-7965 x-mozilla-html:FALSE org:Norlight Telecommunications;Applications Engineering adr:;;275 North Corporate Drive;Brookfield;WI;53045;USA version:2.1 email;internet:hyun@staff.norlight.net title:Network Engineer note:MCSE, CCDA fn:Hyunseig Ryu end:vcard --------------271251D22325AA635DDF2B01-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 8:57: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id B281D37B71B for ; Fri, 2 Mar 2001 08:57:04 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14Yt21-0000AK-00; Fri, 02 Mar 2001 10:07:53 -0700 Message-ID: <3A9FD369.D6A84FC8@softweyr.com> Date: Fri, 02 Mar 2001 10:07:53 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Anton Berezin Cc: Dag-Erling Smorgrav , Peter Dufault , hackers@FreeBSD.ORG Subject: Re: how to actually find out whether data hit the disk? References: <200102281418.f1SEILG28001@hda.hda.com> <20010302143149.D55912@heechee.tobez.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Anton Berezin wrote: > > On Fri, Mar 02, 2001 at 01:59:34PM +0100, Dag-Erling Smorgrav wrote: > > Peter Dufault writes: > > > > > Do an msync with MS_SYNC someplace. Also, use MAP_NOSYNC in > > > > > mmap until 4.3 when Matt Dillon plans to make that the default behavior. > > > > Ahh, no. That's the other way around - I do not *want* it to hit the > > > > disk, but would like to *know* when it nevertheless does. > > > OK, doing a stat and checking the mtime should give you > > > the info at the expense of polling, I can't think of another way. > > > > Won't help. You'll get the same mtime no matter whether the file is > > actually written to disk or not. > > That's what I suspected. :-( > > So is there a way, or is not? Even if the system tells you the data has been flushed to the drive, you don't know that the data has been flushed from the buffers on the drive to the platters unless you specifically tell the drive to sync the buffers. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 9:50:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mr200.netcologne.de (mr200.netcologne.de [194.8.194.109]) by hub.freebsd.org (Postfix) with ESMTP id C999237B71A for ; Fri, 2 Mar 2001 09:50:17 -0800 (PST) (envelope-from pherman@frenchfries.net) Received: from husten.security.at12.de (dial-213-168-73-58.netcologne.de [213.168.73.58]) by mr200.netcologne.de (Mirapoint) with ESMTP id ACA22821; Fri, 2 Mar 2001 18:50:14 +0100 (CET) Received: from localhost (localhost.security.at12.de [127.0.0.1]) by husten.security.at12.de (8.11.2/8.11.2) with ESMTP id f22HnxE65557; Fri, 2 Mar 2001 18:49:59 +0100 (CET) (envelope-from pherman@frenchfries.net) Date: Fri, 2 Mar 2001 18:49:59 +0100 (CET) From: Paul Herman To: milunovic Cc: Peter Pentchev , Subject: Re: blow fish In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 2 Mar 2001, milunovic wrote: > Does anybody have blow fish for FreeBSD or know wehere to find it? > I just want to change password encription from MD5 to blow fish:o) I think Mark Murray is still sitting on the patch I did for this very thing. Check the -hackers mail archives. It was about 2-3 Months ago, so it may not even patch cleanly anymore against -CURRENT. As for why, I can only think of two reasons. One, the geek factor (it has an iteration parameter built into the hash to "increase" security on the fly, it's pretty trick), but mostly two, for people using NIS between OpenBSD and FreeBSD boxen. I don't use it (it was just a fun little hacking project), so I personally don't care if it gets worked into the tree, but this has got to be the 3rd or 4th time somebody has asked for it. -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 10: 3:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.matriplex.com (ns1.matriplex.com [208.131.42.8]) by hub.freebsd.org (Postfix) with ESMTP id 87BBE37B718 for ; Fri, 2 Mar 2001 10:03:07 -0800 (PST) (envelope-from rh@matriplex.com) Received: from mail.matriplex.com (mail.matriplex.com [208.131.42.9]) by mail.matriplex.com (8.9.2/8.9.2) with ESMTP id KAA48413; Fri, 2 Mar 2001 10:02:47 -0800 (PST) (envelope-from rh@matriplex.com) Date: Fri, 2 Mar 2001 10:02:47 -0800 (PST) From: Richard Hodges To: Dmitry Dicky Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: stupid device driver question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 2 Mar 2001, Dmitry Dicky wrote: > Hi fellows, > > I'm writing some device driver which should pass some data to the user > space. > > The part of the device read routine looks as follows: > > ---------------------------------- > int > dev_read(dev_t dev, struct uio *uio, int ioflag) > { > int err = 0; > /* ... */ > amnt = MIN(uio->uio_resid, cntw); > /* Wait here until data available .... how? */ > err = uiomove(buf2, amnt, uio); > if (err != 0) { > return(err); > } > > memset(buf2, 0, amnt); > cntw -= amnt; > return 0; > } > ------------------------------------- > User application hands on read(2). > > But buf2 being filled upon some event and 'dev_read' should > wait until data in buf2 available. > > So, the question is: > How can I hang dev_read, issue some signal and then continue uiomove(9) > data to the user space? How about something like: int timeout; timeout = hz; /* fail if nothing in one second */ while(timeout && (NOTREADY)) if(tsleep(softc, PRIBIO, "mydev", 1)) timeout--; if(NOTREADY) return(EIO); /* or whatever... */ uiomove(...) Then in your interrupt service routine: wakeup(softc); Hope this helps! -Richard ------------------------------------------- Richard Hodges | Matriplex, inc. Product Manager | 769 Basque Way rh@matriplex.com | Carson City, NV 89706 775-886-6477 | www.matriplex.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 10:44: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from security.za.net (security.za.net [196.2.146.22]) by hub.freebsd.org (Postfix) with ESMTP id F07E037B719 for ; Fri, 2 Mar 2001 10:43:55 -0800 (PST) (envelope-from lists@security.za.net) Received: from localhost (lists@localhost) by security.za.net (8.9.3/8.9.3) with ESMTP id UAA68224 for ; Fri, 2 Mar 2001 20:43:48 +0200 (SAST) (envelope-from lists@security.za.net) Date: Fri, 2 Mar 2001 20:43:48 +0200 (SAST) From: Lists Account To: hackers@freebsd.org Subject: gcc -pthread / segfault problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all, I was coding some stuff under a 4.2 box of mine here earlier today and I seem to have hit a very strange bug, I was wondering if anyone could help me out here. I wrote a bunch of pthread enabled code, when I tried to run the program, after I compiled it with -pthread (I had to with the threading code in there), it segfaulted, so I ran it through gdb, and it was segfaulting on malloc(). So I dug around some more, and eventually I tried changing that single line to a c++ new() call, no more problems... So for the sake of testing, I commented out all the code that needed pthreads, and compiled it again, without the -pthread flag, unchanged except for a function that I commented out, with the original malloc() call, no problems again. Then, with that function commented out, exactly was I had compiled it a few seconds earlier where it worked, I recompiled it, using the -pthread flag again, ran it, and sure enough it segfaults on the first malloc() it reaches. Is there a bug in the pthreads, or have I possibly missed something in the code that I need in there to make it work with -pthread? Any help or suggestions would be MUCH appreciated Thanks Andrew Alston To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 14: 5:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 8667B37B718; Fri, 2 Mar 2001 14:05:32 -0800 (PST) (envelope-from DougB@gorean.org) Received: from slave (Studded@slave [10.0.0.1]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id OAA30555; Fri, 2 Mar 2001 14:05:29 -0800 (PST) (envelope-from DougB@gorean.org) Date: Fri, 2 Mar 2001 14:05:28 -0800 (PST) From: Doug Barton X-X-Sender: To: Hyunseog Ryu Cc: , Subject: Re: BIND 9.1.1 and FBSD 4.2-stable In-Reply-To: <3A9FCCF8.F05F4C3E@staff.norlight.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 2 Mar 2001, Hyunseog Ryu wrote: > > Hi, folks > > I have questions for BIND version 9.1.1rc2. > I submitted original question to freebsd-isp@freebsd.org, > but couldn't get an answer for this. You're not getting answers because you are sending to the wrong lists. Your question belongs on freebsd-questions only. > Recently I installed BIND 9.1.1rc2 into one of FreeBSD 4.2-stable > version. Please update to rc3. It fixes several bugs, and may help your situation. > After installation of BIND, it works fine for a while. > But when I look at the "top" command output, > it says that memory consumption of named is increasing continuously. What are you doing with this named? Are you using it as a resolver? If so, it's normal for the size of the cache to grow. How much ram is it adding per day? You might also consider using/installing 8.2.3 and see if you get the same results. In any case, please respond to freebsd-questions@freebsd.org with your answer. Doug -- "Pain heals. Chicks dig scars. Glory . . . lasts forever." -- Keanu Reeves as Shane Falco in "The Replacements" Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 15: 4:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.matriplex.com (ns1.matriplex.com [208.131.42.8]) by hub.freebsd.org (Postfix) with ESMTP id 8466137B71A for ; Fri, 2 Mar 2001 15:04:30 -0800 (PST) (envelope-from rh@matriplex.com) Received: from mail.matriplex.com (mail.matriplex.com [208.131.42.9]) by mail.matriplex.com (8.9.2/8.9.2) with ESMTP id PAA49072 for ; Fri, 2 Mar 2001 15:04:28 -0800 (PST) (envelope-from rh@matriplex.com) Date: Fri, 2 Mar 2001 15:04:27 -0800 (PST) From: Richard Hodges To: freebsd-hackers@FreeBSD.ORG Subject: kern/23620: Fore PCA200E driver Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, all! A couple months ago, I submitted PR kern/23620 describing a problem with the Fore PCA200E driver for HARP. It includes a description of the problems and a patch. Could someone commit this to STABLE so that it has a chance of making it into 4.3 RELEASE? Thanks, -Richard ------------------------------------------- Richard Hodges | Matriplex, inc. Product Manager | 769 Basque Way rh@matriplex.com | Carson City, NV 89706 775-886-6477 | www.matriplex.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 15:16:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.vi.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with SMTP id 9297337B719 for ; Fri, 2 Mar 2001 15:16:19 -0800 (PST) (envelope-from dphoenix@bravenet.com) Received: (qmail 29384 invoked by uid 1000); 2 Mar 2001 23:15:36 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Mar 2001 23:15:36 -0000 Date: Fri, 2 Mar 2001 15:15:36 -0800 (PST) From: Dan Phoenix To: freebsd-hackers@FreeBSD.ORG Subject: easy way to crash freebsd In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG symbolic link /etc/resolv.conf to a non-existant file....throw a bunch of connections at it and watch it reboot. -- Dan +------------------------------------------------------+ | BRAVENET WEB SERVICES | | dan@bravenet.com | | make installworld | | ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail | | ln -s /var/qmail/bin/newaliases /usr/sbin/newaliases | +______________________________________________________+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 15:24: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.vi.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with SMTP id 51B0537B719 for ; Fri, 2 Mar 2001 15:23:58 -0800 (PST) (envelope-from dphoenix@bravenet.com) Received: (qmail 11252 invoked by uid 1000); 2 Mar 2001 23:23:15 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Mar 2001 23:23:15 -0000 Date: Fri, 2 Mar 2001 15:23:15 -0800 (PST) From: Dan Phoenix To: freebsd-hackers@FreeBSD.ORG Subject: Re: easy way to crash freebsd In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG People asking me how this could be used as a local user. Well i guess if you wanted to you could find something root runs that writes to /tmp then umask resolv.conf and echo "" > resolv.conf I am in no way supporting that...just answering a question. On Fri, 2 Mar 2001, Dan Phoenix wrote: > Date: Fri, 2 Mar 2001 15:15:36 -0800 (PST) > From: Dan Phoenix > To: freebsd-hackers@FreeBSD.ORG > Subject: easy way to crash freebsd > > > > symbolic link /etc/resolv.conf > to a non-existant file....throw a bunch of connections at it > and watch it reboot. > > > -- > Dan > > +------------------------------------------------------+ > | BRAVENET WEB SERVICES | > | dan@bravenet.com | > | make installworld | > | ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail | > | ln -s /var/qmail/bin/newaliases /usr/sbin/newaliases | > +______________________________________________________+ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 15:24:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from barabas.bitstream.net (barabas.bitstream.net [216.243.128.159]) by hub.freebsd.org (Postfix) with SMTP id 9909337B71A for ; Fri, 2 Mar 2001 15:24:28 -0800 (PST) (envelope-from airboss@bitstream.net) Received: (qmail 40326 invoked from network); 2 Mar 2001 23:24:24 -0000 Received: from unknown (HELO dmitri.bitstream.net) (216.243.132.33) by barabas with SMTP; 2 Mar 2001 23:24:24 -0000 Date: Fri, 2 Mar 2001 17:15:02 -0600 (CST) From: Dan Debertin To: Dan Phoenix Cc: "freebsd-hackers@FreeBSD.ORG" Subject: Re: easy way to crash freebsd In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Unable to replicate. Opened up 1,000 connections to port 22 with /etc/resolv.conf symlinked to /etc/foo. FreeBSD-4.1.1-RELEASE. Have fun, Dan Debertin -- ++ Unix is the worst operating system, except for all others. ++ Dan Debertin ++ Senior Systems Administrator ++ Bitstream Underground, LLC ++ airboss@bitstream.net ++ (612)321-9290 x108 ++ GPG Fingerprint: 0BC5 F4D6 649F D0C8 D1A7 CAE4 BEF4 0A5C 300D 2387 On Fri, 2 Mar 2001, Dan Phoenix wrote: > > > symbolic link /etc/resolv.conf > to a non-existant file....throw a bunch of connections at it > and watch it reboot. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 15:25:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 0606E37B718 for ; Fri, 2 Mar 2001 15:25:54 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f22NPrk21590; Fri, 2 Mar 2001 15:25:53 -0800 (PST) Date: Fri, 2 Mar 2001 15:25:53 -0800 From: Alfred Perlstein To: Dan Phoenix Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: easy way to crash freebsd Message-ID: <20010302152553.H8663@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dphoenix@bravenet.com on Fri, Mar 02, 2001 at 03:23:15PM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Fri, 2 Mar 2001, Dan Phoenix wrote: > > > symbolic link /etc/resolv.conf > > to a non-existant file....throw a bunch of connections at it > > and watch it reboot. * Dan Phoenix [010302 15:24] wrote: > > People asking me how this could be used as a local user. > Well i guess if you wanted to you could find something root runs > that writes to /tmp then umask resolv.conf > and echo "" > resolv.conf > > I am in no way supporting that...just answering a question. Try overwriting /dev/mem, it's much more interesting. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 15:27:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.vi.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with SMTP id 2239B37B718 for ; Fri, 2 Mar 2001 15:27:25 -0800 (PST) (envelope-from dphoenix@bravenet.com) Received: (qmail 23102 invoked by uid 1000); 2 Mar 2001 23:26:41 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Mar 2001 23:26:41 -0000 Date: Fri, 2 Mar 2001 15:26:41 -0800 (PST) From: Dan Phoenix To: Dan Debertin Cc: "freebsd-hackers@FreeBSD.ORG" Subject: Re: easy way to crash freebsd In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [root@lotho dphoenix]# uname -a FreeBSD lotho.sf.bravenet.com 4.2-STABLE FreeBSD 4.2-STABLE #0: Thu Mar 1 17:07:55 PST 2001 droot@lotho.sf.bravenet.com:/usr/src/sys/compile/MYKERNEL i386 [root@lotho dphoenix]# Here is the machine i was able to do it on. Btw it won't happen instantly Give it a few hours to run out of mbufs etc :) name lookups shouldn't be happening in kernel space. was somethign suggested. On Fri, 2 Mar 2001, Dan Debertin wrote: > Date: Fri, 2 Mar 2001 17:15:02 -0600 (CST) > From: Dan Debertin > To: Dan Phoenix > Cc: "freebsd-hackers@FreeBSD.ORG" > Subject: Re: easy way to crash freebsd > > Unable to replicate. Opened up 1,000 connections to port 22 with > /etc/resolv.conf symlinked to /etc/foo. FreeBSD-4.1.1-RELEASE. > > Have fun, > > Dan Debertin > -- > ++ Unix is the worst operating system, except for all others. > > ++ Dan Debertin > ++ Senior Systems Administrator > ++ Bitstream Underground, LLC > ++ airboss@bitstream.net > ++ (612)321-9290 x108 > ++ GPG Fingerprint: 0BC5 F4D6 649F D0C8 D1A7 CAE4 BEF4 0A5C 300D 2387 > > > On Fri, 2 Mar 2001, Dan Phoenix wrote: > > > > > > > symbolic link /etc/resolv.conf > > to a non-existant file....throw a bunch of connections at it > > and watch it reboot. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 15:28:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.vi.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with SMTP id 40F4E37B718 for ; Fri, 2 Mar 2001 15:28:25 -0800 (PST) (envelope-from dphoenix@bravenet.com) Received: (qmail 15906 invoked by uid 1000); 2 Mar 2001 23:27:42 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Mar 2001 23:27:42 -0000 Date: Fri, 2 Mar 2001 15:27:42 -0800 (PST) From: Dan Phoenix To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: easy way to crash freebsd In-Reply-To: <20010302152553.H8663@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG lol....ya that would definately be a killer :) On Fri, 2 Mar 2001, Alfred Perlstein wrote: > Date: Fri, 2 Mar 2001 15:25:53 -0800 > From: Alfred Perlstein > To: Dan Phoenix > Cc: freebsd-hackers@FreeBSD.ORG > Subject: Re: easy way to crash freebsd > > > On Fri, 2 Mar 2001, Dan Phoenix wrote: > > > > > symbolic link /etc/resolv.conf > > > to a non-existant file....throw a bunch of connections at it > > > and watch it reboot. > > * Dan Phoenix [010302 15:24] wrote: > > > > People asking me how this could be used as a local user. > > Well i guess if you wanted to you could find something root runs > > that writes to /tmp then umask resolv.conf > > and echo "" > resolv.conf > > > > I am in no way supporting that...just answering a question. > > Try overwriting /dev/mem, it's much more interesting. > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 2 16: 4:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-158.dsl.lsan03.pacbell.net [63.207.60.158]) by hub.freebsd.org (Postfix) with ESMTP id A0F1037B718 for ; Fri, 2 Mar 2001 16:04:35 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 3D65366F09; Fri, 2 Mar 2001 16:04:35 -0800 (PST) Date: Fri, 2 Mar 2001 16:04:35 -0800 From: Kris Kennaway To: Peter Pentchev Cc: milunovic , hackers@freebsd.org Subject: Re: blow fish Message-ID: <20010302160435.B49111@mollari.cthul.hu> References: <20010302142603.A2609@ringworld.oblivion.bg> <20010302143141.B2609@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="qlTNgmc+xy1dBmNv" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010302143141.B2609@ringworld.oblivion.bg>; from roam@orbitel.bg on Fri, Mar 02, 2001 at 02:31:41PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --qlTNgmc+xy1dBmNv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 02, 2001 at 02:31:41PM +0200, Peter Pentchev wrote: > On Fri, Mar 02, 2001 at 02:26:03PM +0200, Peter Pentchev wrote: > > On Fri, Mar 02, 2001 at 01:23:01PM +0100, milunovic wrote: > > >=20 > > > Does anybody have blow fish for FreeBSD or know wehere to find it? > > > I just want to change password encription from MD5 to blow fish:o) > >=20 > > A little question: why? MD5 seems to be secure enough. > >=20 > > Other than that, look at the security/libmcrypt port, it has Blowfish > > as an available encryption algorithm. It's not in a usable form for > > password encryption, though; you need to pull out the guts of the > > encryption function and build your own crypt() function. >=20 > Come to think of it, there's nothing that would prevent security/libmcrypt > to be part of the authentication process (not crypt(), though). Is there > something inherently flawed in the idea of a PAM module using libs which > do not live in /usr, but in /usr/local? Why not just use OpenSSL which also includes this algorithm? You'd still need to build it into a crypt() function, and the correct location and layering for that to take place is in libcrypt, not PAM. Kris --qlTNgmc+xy1dBmNv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6oDUSWry0BWjoQKURAnm7AJwMf4LnhKJ5jcLs1/1OMJXRXYTkRgCeIIdS P9Scu1wXET9UogTFP9TmIrE= =U5KE -----END PGP SIGNATURE----- --qlTNgmc+xy1dBmNv-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 3 1: 8:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from primo.verat.net (primo.verat.net [217.26.64.130]) by hub.freebsd.org (Postfix) with ESMTP id 5772D37B71A for ; Sat, 3 Mar 2001 00:47:11 -0800 (PST) (envelope-from milunovic@sendmail.ru) Received: from scorpion.cosmos.all.net (ppp-28.verat.net [217.26.65.28]) by primo.verat.net (8.9.3/8.9.3) with ESMTP id JAA13796 for ; Sat, 3 Mar 2001 09:47:09 +0100 Received: from scorpion.cosmos.all.net (scorpion.cosmos.all.net [127.0.0.1]) by scorpion.cosmos.all.net (8.11.2/8.11.2) with ESMTP id f238s6X10588 for ; Sat, 3 Mar 2001 09:54:07 +0100 (CET) Date: Sat, 3 Mar 2001 09:54:02 +0100 (CET) From: milunovic X-Sender: milunovic@scorpion.cosmos.all.net To: hackers@FreeBSD.org Subject: Re: blow fish In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- On Fri, 2 Mar 2001, Paul Herman wrote: > but this has got to be the 3rd or 4th time somebody has asked for it. sorry I didn't know :o( Vojislav Milunovic milunovic@sendmail.ru -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQEVAwUBOqCxLi3gPLld8IkLAQE+3QgAhGJdUuPROmUgrS8cHA2WieQlq/RYzYlV t9nqMFNPT/V5xC8jKhjLgDTnCoQSJyVhKGtZbx/eiMEniykMXT7Ct2oqTwuW+62M rO4Vgc7IQq4UFhGtZBhUtUd6lpuk9w9FByo/Toc+phzMNyw8K4yMnK4+612harbN dPjiZtTrtR8v8liKQIxBNJhC/FyoYTMPgbAAK8igWuZFeLmFEnetalckbEq3qVvQ 4S7ahMTvt4FRoGtJto8Zsld+KdIirW41kJVRP8JV2oVjqAS9onVfEaquqyOoRW5R Xc9ZXRafFviioQdmWARBoj4yGKjrp+aXrGF0U2jGLSo+/vuHdyPvCg== =qheC -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 3 1:25:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 2A2C037B71F for ; Sat, 3 Mar 2001 00:29:58 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14Z7b6-0000Cu-00; Sat, 03 Mar 2001 01:41:04 -0700 Message-ID: <3AA0AE20.653196F8@softweyr.com> Date: Sat, 03 Mar 2001 01:41:04 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: Dan Phoenix , freebsd-hackers@FreeBSD.ORG Subject: Re: easy way to crash freebsd References: <20010302152553.H8663@fw.wintelcom.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > > > On Fri, 2 Mar 2001, Dan Phoenix wrote: > > > > > symbolic link /etc/resolv.conf > > > to a non-existant file....throw a bunch of connections at it > > > and watch it reboot. > > * Dan Phoenix [010302 15:24] wrote: > > > > People asking me how this could be used as a local user. > > Well i guess if you wanted to you could find something root runs > > that writes to /tmp then umask resolv.conf > > and echo "" > resolv.conf > > > > I am in no way supporting that...just answering a question. > > Try overwriting /dev/mem, it's much more interesting. You don't even have to overwrite it some times. Accessing word-size-only registers in memory a byte at a time can cause a bus error and panic... -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 3 7:16:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from quack.kfu.com (quack.kfu.com [205.178.90.194]) by hub.freebsd.org (Postfix) with ESMTP id 1F42A37B718 for ; Sat, 3 Mar 2001 07:16:28 -0800 (PST) (envelope-from nsayer@quack.kfu.com) Received: from medusa.kfu.com (medusa.kfu.com [205.178.90.222]) by quack.kfu.com (8.11.1/8.11.1) with ESMTP id f23FGRj38803; Sat, 3 Mar 2001 07:16:27 -0800 (PST) (envelope-from nsayer@quack.kfu.com) Received: from quack.kfu.com (icarus.kfu.com [205.178.90.254]) by medusa.kfu.com (8.11.1/8.11.0) with ESMTP id f23FGRY16698; Sat, 3 Mar 2001 07:16:27 -0800 (PST) (envelope-from nsayer@quack.kfu.com) Message-ID: <3AA10ACA.7080104@quack.kfu.com> Date: Sat, 03 Mar 2001 07:16:26 -0800 From: Nick Sayer User-Agent: Mozilla/5.0 (X11; U; FreeBSD 4.2-STABLE i386; en-US; 0.8) Gecko/20010216 X-Accept-Language: en MIME-Version: 1.0 To: Garance A Drosihn , freebsd-hackers@freebsd.org Subject: Re: FreeBSD on IBM's radar screen? References: <42534.983469460@verdi.nethelp.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > I think the recent debacle with the T20 and A20 laptops > actually helped to get us noticed. Here someone in IBM > probably made a dumb programming mistake which happened > to make freebsd unusable on their hardware, and they got > a whole bunch of their *customers* (owners of one of > these laptops) beating them up for the problem. Not > freebsd.org making vague promises of sales based on > freebsd, but actual customers using freebsd on IBM > hardware. IBM wants to sell as much hardware as they > can, and so they are bound to be interested when they > notice that some of their customers are using freebsd. I was particularly gratified that when the story got slashdotted, a lot of support came from people who didn't run FreeBSD, but did feel our pain - Linux folks are in this sense part of the same community used to the same shoddy treatment by hardware vendors (if you're not running Winblows, it's unsupported, so go away). They helped make the response larger and noisier. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 3 8:28:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 13DA737B71C; Sat, 3 Mar 2001 08:28:45 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14ZF4I-0000Kw-00; Sat, 03 Mar 2001 09:39:42 -0700 Message-ID: <3AA11E4E.A3356338@softweyr.com> Date: Sat, 03 Mar 2001 09:39:42 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Nick Sayer Cc: Garance A Drosihn , freebsd-hackers@freebsd.org, freebsd-advocacy@freebsd.org Subject: Re: FreeBSD on IBM's radar screen? References: <42534.983469460@verdi.nethelp.no> <3AA10ACA.7080104@quack.kfu.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nick Sayer wrote: > > I was particularly gratified that when the story got slashdotted, a lot > of support came from people who didn't run FreeBSD, but did feel our > pain - Linux folks are in this sense part of the same community used to > the same shoddy treatment by hardware vendors (if you're not running > Winblows, it's unsupported, so go away). They helped make the response > larger and noisier. They may be our banjo-playing cousins, but they ARE our cousins. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 3 10: 5:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from po4.glue.umd.edu (po4.glue.umd.edu [128.8.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 0D2FD37B718 for ; Sat, 3 Mar 2001 10:05:42 -0800 (PST) (envelope-from howardjp@well.com) Received: from z.glue.umd.edu (IDENT:root@z.glue.umd.edu [128.8.10.71]) by po4.glue.umd.edu (8.10.1/8.10.1) with ESMTP id f23I5Ps04363; Sat, 3 Mar 2001 13:05:25 -0500 (EST) Received: from z.glue.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by z.glue.umd.edu (8.9.3/8.9.3) with SMTP id NAA11908; Sat, 3 Mar 2001 13:05:24 -0500 (EST) Received: from localhost (howardjp@localhost) by z.glue.umd.edu (8.9.3/8.9.3) with ESMTP id NAA11904; Sat, 3 Mar 2001 13:05:24 -0500 (EST) X-Authentication-Warning: z.glue.umd.edu: howardjp owned process doing -bs Date: Sat, 3 Mar 2001 13:05:24 -0500 (EST) From: James Howard X-Sender: howardjp@z.glue.umd.edu To: Wes Peters Cc: Alfred Perlstein , Dan Phoenix , freebsd-hackers@FreeBSD.ORG Subject: Re: easy way to crash freebsd In-Reply-To: <3AA0AE20.653196F8@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 3 Mar 2001, Wes Peters wrote: > You don't even have to overwrite it some times. Accessing word-size-only > registers in memory a byte at a time can cause a bus error and panic... I have never worked with FreeBSD at this low a level. How does one do this and why? :) Jamie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 3 10:24:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by hub.freebsd.org (Postfix) with ESMTP id 4013337B718 for ; Sat, 3 Mar 2001 10:24:28 -0800 (PST) (envelope-from chris@holly.calldei.com) Received: from holly.calldei.com ([208.191.149.190]) by mta4.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G9M000FTWF26Y@mta4.rcsntx.swbell.net> for freebsd-hackers@FreeBSD.ORG; Sat, 3 Mar 2001 12:23:26 -0600 (CST) Received: (from chris@localhost) by holly.calldei.com (8.11.1/8.9.3) id f23IOOl25329; Sat, 03 Mar 2001 12:24:24 -0600 (CST envelope-from chris) Date: Sat, 03 Mar 2001 12:24:19 -0600 From: Chris Costello Subject: Re: easy way to crash freebsd In-reply-to: ; from dphoenix@bravenet.com on Fri, Mar 02, 2001 at 03:23:15PM -0800 To: Dan Phoenix Cc: freebsd-hackers@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <20010303122419.L2028@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Friday, March 02, 2001, Dan Phoenix wrote: > People asking me how this could be used as a local user. > Well i guess if you wanted to you could find something root runs > that writes to /tmp then umask resolv.conf > and echo "" > resolv.conf Could you expand on this, please? What does finding a root utility that writes to /tmp have to do with umasking a file? (I've found it rather difficult to umask files in the past.) -- +-------------------+----------------------------+ | Chris Costello | I just found the last bug. | | chris@calldei.com | | +-------------------+----------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 3 10:29:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peorth.iteration.net (peorth.iteration.net [208.190.180.178]) by hub.freebsd.org (Postfix) with ESMTP id D66B737B720 for ; Sat, 3 Mar 2001 10:29:45 -0800 (PST) (envelope-from keichii@peorth.iteration.net) Received: by peorth.iteration.net (Postfix, from userid 1001) id 6E97359570; Sat, 3 Mar 2001 12:29:38 -0600 (CST) Date: Sat, 3 Mar 2001 12:29:38 -0600 From: "Michael C . Wu" To: James Howard Cc: Wes Peters , Alfred Perlstein , Dan Phoenix , freebsd-hackers@FreeBSD.ORG Subject: Re: easy way to crash freebsd Message-ID: <20010303122938.A31278@peorth.iteration.net> Reply-To: "Michael C . Wu" Mail-Followup-To: "Michael C . Wu" , James Howard , Wes Peters , Alfred Perlstein , Dan Phoenix , freebsd-hackers@FreeBSD.ORG References: <3AA0AE20.653196F8@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from howardjp@well.com on Sat, Mar 03, 2001 at 01:05:24PM -0500 X-PGP-Fingerprint: 5025 F691 F943 8128 48A8 5025 77CE 29C5 8FA1 2E20 X-PGP-Key-ID: 0x8FA12E20 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Mar 03, 2001 at 01:05:24PM -0500, James Howard scribbled: | On Sat, 3 Mar 2001, Wes Peters wrote: | | > You don't even have to overwrite it some times. Accessing word-size-only | > registers in memory a byte at a time can cause a bus error and panic... | | I have never worked with FreeBSD at this low a level. How does one do | this and why? :) 1. You never do this. 2. Wes and Alfred were pointing out the logical errors made by a certain user. When you can modify /etc/resolv.conf at will, you are root. What point is there when the "malicious" "user" (if we can call him just a user at this point)? :) 3. Like Wes and Alfred said, accessing /dev/mem could be fun. -- +------------------------------------------------------------------+ | keichii@peorth.iteration.net | keichii@bsdconspiracy.net | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +------------------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 3 10:57: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.newst.irs.ru (newst.irs.ru [212.164.94.1]) by hub.freebsd.org (Postfix) with ESMTP id C0F1F37B720 for ; Sat, 3 Mar 2001 10:56:57 -0800 (PST) (envelope-from fjoe@newst.net) Received: from lark.nsk.bsgdesign.com (lark.nsk.bsgdesign.com [192.168.3.21]) by mail.newst.irs.ru (8.11.1/8.11.0) with ESMTP id f23IuUZ73539; Sun, 4 Mar 2001 00:56:40 +0600 (NOVT) (envelope-from fjoe@newst.net) Date: Sun, 4 Mar 2001 00:56:30 +0600 (NOVT) From: Max Khon X-Sender: fjoe@localhost To: Lists Account Cc: hackers@FreeBSD.ORG Subject: Re: gcc -pthread / segfault problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi, there! On Fri, 2 Mar 2001, Lists Account wrote: > I was coding some stuff under a 4.2 box of mine here earlier today and I > seem to have hit a very strange bug, I was wondering if anyone could help > me out here. > > I wrote a bunch of pthread enabled code, when I tried to run the program, > after I compiled it with -pthread (I had to with the threading code in > there), it segfaulted, so I ran it through gdb, and it was segfaulting on > malloc(). So I dug around some more, and eventually I tried changing that > single line to a c++ new() call, no more problems... 4.2-RELEASE has known problems with C++ and pthreads please upgrade to latest -STABLE /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 3 11:25:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 2589F37B71D for ; Sat, 3 Mar 2001 10:28:11 -0800 (PST) (envelope-from zzhang@cs.binghamton.edu) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.2/8.11.2) with ESMTP id f23ISAJ26376 for ; Sat, 3 Mar 2001 13:28:10 -0500 (EST) Date: Sat, 3 Mar 2001 13:28:08 -0500 (EST) From: Zhiui Zhang X-Sender: zzhang@onyx To: freebsd-hackers@freebsd.org Subject: Linux kiobuf stuff... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG While looking at Linux 2.4 code, I see the kiobuf stuff. They implement it because Linux 2.2 lacks raw device support. I am wondering whether FreeBSD has a similar mechanism already in place. My reasonings: (1) FreeBSD's buffer is variable sized while Linux's buffer is fixed sized. So in the case of FreeBSD, a buffer can easily be associated with many pages. The kiobuf in Linux seems to limit the max I/O to 64KB. (2) We have physical buffers, they can be used separately (like in physio() and swapping) or they can be built on top of regular buffers (like in clustering I/O). Thanks for any enlightment. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 3 11:42: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hotmail.com (f146.law8.hotmail.com [216.33.241.146]) by hub.freebsd.org (Postfix) with ESMTP id B418B37B718 for ; Sat, 3 Mar 2001 11:21:09 -0800 (PST) (envelope-from dominic_marks@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 3 Mar 2001 11:21:09 -0800 Received: from 194.72.9.37 by lw8fd.law8.hotmail.msn.com with HTTP; Sat, 03 Mar 2001 19:21:09 GMT X-Originating-IP: [194.72.9.37] From: "Dominic Marks" To: freebsd-hackers@FreeBSD.ORG Subject: C / C++, Networking, Tutorials, Links... Date: Sat, 03 Mar 2001 19:21:09 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Mar 2001 19:21:09.0551 (UTC) FILETIME=[1A1A53F0:01C0A417] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, Im fairly new to using FreeBSD but I'm a fairly experienced programmer and I'd like to start writing some programs. Im competant in doing fairly simple things in C and C++ and I can read most code and understand it with any problems. Does anyone know of any good books, tutorials, sites I could check out that would show a clear way of writing network code, and in particular network servers? Ive read through large parts of Postfix and INN but they are rather large programs and Im having trouble pinpointing the actual information im hunting after. I really appreciate any good tips Dominic _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 3 12:17:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sigtrap.com (ip212-226-143-10.adsl.kpnqwest.fi [212.226.143.10]) by hub.freebsd.org (Postfix) with SMTP id 32B5F37B718 for ; Sat, 3 Mar 2001 12:17:26 -0800 (PST) (envelope-from desti@sigtrap.com) Received: (qmail 24900 invoked from network); 3 Mar 2001 20:15:52 -0000 Received: from ip212-226-143-11.adsl.kpnqwest.fi (HELO sigtrap.com) (desti@212.226.143.11) by ip212-226-143-9.adsl.kpnqwest.fi with SMTP; 3 Mar 2001 20:15:52 -0000 Message-ID: <3AA16DF6.D0FA92E1@sigtrap.com> Date: Sat, 03 Mar 2001 22:19:34 +0000 From: Edvard Fagerholm X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dominic Marks , freebsd-hackers@freebsd.org Subject: Re: C / C++, Networking, Tutorials, Links... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, here are some starters (and actually a bit more than that too): TCP/IP Illustrated Vol 1: The Protocols W. Richard Stevens ISBN: 0201633469 TCP/IP Illustrated Vol 2: The Implementation Gary A. Wright, W. Richard Stevens ISBN: 020163354X UNIX Network Programming Vol 1: Networking APIs - Sockets and XT1 W. Richard Stevens ISBN: 013490012X Advanced Programming in the UNIX Environment W. Richard Stevens ISBN: 0201563177 The C++ Programming Language Bjarne Stroustrup ISBN: 0201700735 The C Programming Language Brian W. Kernighan, Dennis M. Ritchie ISBN: 0131103628 The Design and Implementation of the 4.4BSD Operating System (Unix and Open Systems Series.) Marshall Kirk McKusick (Editor), Keith Bostic, Michael J. Karels (Editor) ISBN: 0201549794 Programming with POSIX Threads David R. Butenhof ISBN: 0201633922 You should atleast get Unix Network Programming Vol 1, Advanced Programming in the UNIX Environment and TCP/IP Illustrated Vol 1 and preferably Vol 2 too. Cheers, Edvard Fagerholm Dominic Marks wrote: > > Hello, > > Im fairly new to using FreeBSD but I'm a fairly experienced programmer and > I'd like to start writing some programs. Im competant in doing fairly simple > things in C and C++ and I can read most code and understand it with any > problems. Does anyone know of any good books, tutorials, sites I could check > out that would show a clear way of writing network code, and in particular > network servers? > > Ive read through large parts of Postfix and INN but they are rather large > programs and Im having trouble pinpointing the actual information im hunting > after. > > I really appreciate any good tips > Dominic > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 3 14:59: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 8EB2037B719 for ; Sat, 3 Mar 2001 14:59:03 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14ZLAL-0005Yc-00; Sat, 03 Mar 2001 16:10:21 -0700 Message-ID: <3AA179DC.131B8112@softweyr.com> Date: Sat, 03 Mar 2001 16:10:20 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: James Howard Cc: Alfred Perlstein , Dan Phoenix , freebsd-hackers@FreeBSD.ORG Subject: Re: easy way to crash freebsd References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG James Howard wrote: > > On Sat, 3 Mar 2001, Wes Peters wrote: > > > You don't even have to overwrite it some times. Accessing word-size-only > > registers in memory a byte at a time can cause a bus error and panic... > > I have never worked with FreeBSD at this low a level. How does one do > this and why? :) Some memory locations are memory-mapped I/O registers, rather than "just RAM", and have to be read at the correct width for the register. Reading a 32-bit register with an 8-bit read can cause a bus error; since you're poking around in kernel memory (/dev/*k*mem) a panic ensues. This was a sure-fire way to crash RISC Ultrix, and I think SunOS M68K too. I don't know that this will work on x86, with it's separate I/O address space, and it doesn't work on SPARC because you can't get to the right Address Space Identifier (ASI) for anything other than RAM (and maybe some ROM). -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 3 15:21:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dove.angel.org (dsl-64-194-138-85.telocity.com [64.194.138.85]) by hub.freebsd.org (Postfix) with ESMTP id 7D7D137B72A for ; Sat, 3 Mar 2001 15:21:17 -0800 (PST) (envelope-from dp@penix.org) Received: from penix.org (Toronto-ppp221194.sympatico.ca [64.228.106.11]) by dove.angel.org (8.11.1/8.11.1) with ESMTP id f23NKXG14898 for ; Sat, 3 Mar 2001 18:20:33 -0500 (EST) (envelope-from dp@penix.org) Message-ID: <3AA17EFF.6A4F3B81@penix.org> Date: Sat, 03 Mar 2001 18:32:15 -0500 From: Paul Halliday X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: freezing freebsd. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG While on the topic of crashing FreeBSD I would like to post this and see if I can get any input on it. Let's assume that someones configuration happens to contain something like this: sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 This is easily achieved if you have eliminated some ports via your bios to juggle some irqs or, in the case that I first noticed it a bad serial port on my gateway. Anyway, [dp]-useless% cu -l cuaa0 Connected. ... and your system will be pretty much toast. I am not really sure what is happening here. There is no reboot, no crash, the system just hangs. SSH connection from another machine locks up and the machine seems to dissapear from the network. Power cycling seems the only recourse. I have tried this on two x86 machines runnning 4.2-stable and two alpha's running 4.2-stable. I know this is probably something stupid but, if someone could tell me why it does this, I would greatly appreciate it. thanks. -- Paul H. ============================================================================ Don't underestimate the power of stupid people in large groups. Brute force is the last resort of the incompetent. GPG Key fingerprint: 2D7C A7E2 DB1F EA5F 8C6F D5EC 3D39 F274 4AA3 E8B9 Web: http://www3.sympatico.ca/transmogrify Public Key available here: http://www3.sympatico.ca/transmogrify/dp.txt ============================================================================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 3 16:50: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.vi.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with SMTP id 4278D37B718 for ; Sat, 3 Mar 2001 16:50:03 -0800 (PST) (envelope-from dphoenix@bravenet.com) Received: (qmail 1624 invoked by uid 1000); 4 Mar 2001 00:47:21 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 4 Mar 2001 00:47:21 -0000 Date: Sat, 3 Mar 2001 16:47:21 -0800 (PST) From: Dan Phoenix To: Chris Costello Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: easy way to crash freebsd In-Reply-To: <20010303122419.L2028@holly.calldei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 3 Mar 2001, Chris Costello wrote: > Date: Sat, 03 Mar 2001 12:24:19 -0600 > From: Chris Costello > To: Dan Phoenix > Cc: freebsd-hackers@FreeBSD.ORG > Subject: Re: easy way to crash freebsd > > On Friday, March 02, 2001, Dan Phoenix wrote: > > People asking me how this could be used as a local user. > > Well i guess if you wanted to you could find something root runs > > that writes to /tmp then umask resolv.conf > > and echo "" > resolv.conf > > Could you expand on this, please? What does finding a root > utility that writes to /tmp have to do with umasking a file? > (I've found it rather difficult to umask files in the past.) > > -- > +-------------------+----------------------------+ > | Chris Costello | I just found the last bug. | > | chris@calldei.com | | > +-------------------+----------------------------+ > Well one one the concepts is to umask 4777 then write as many tmp files to the tmp dir as you can symlinking to say /etc/master.passwd....which would really do nothing i would imagine...symlinking to spwd.db would prob be better. Afterwards you have write perms to the file with whatever root wrote to it. I beleive that is the basic concept....many of these have been fixed. BTW in no way do I promote this....just explaining the concept. [root@elrond dphoenix]# ls /tmp commitlog* elist.log fcsignup.log mysql.sock= screens/ [root@elrond dphoenix]# for me shows this.....I guess in this case you could wait for root to shutdown mysql and link that mysql.sock= to some database you want overwritten. I am not sure if it works the same for socket files. Best to ask one the unix gurus :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 3 20:41:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail4.bigmailbox.com (mail4.bigmailbox.com [209.132.220.35]) by hub.freebsd.org (Postfix) with ESMTP id 7422537B718 for ; Sat, 3 Mar 2001 20:41:41 -0800 (PST) (envelope-from bsd_appliance@bemail.org) Received: œby mail4.bigmailbox.com (8.8.7/8.8.7) id UAA04438; Sat, 3 Mar 2001 20:41:41 -0800 Date: Sat, 3 Mar 2001 20:41:41 -0800 Message-Id: <200103040441.UAA04438@mail4.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [216.249.90.37] From: "Nathaniel G H" To: freebsd-hackers@freebsd.org Subject: Re: ipchains ported to FreeBSD Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> In the last episode (Mar 01), jett tayer said: >> > can ipchains / iptables be ported to FreeBSD... this is a >> > suggestion if u dont mind. To answer your suggestion... I wouldn't waste time porting ipchains or iptables. If I wanted to use existing Linux (?) firewall scripts, I would most likely write a program to convert them over to ipfw and/or ipfilter. That would be much easier. -NGH ------------------------------------------------------------ Free, BeOS-friendly email accounts: http://BeMail.org/ Peep! .:. http://twinfusion.com/comic/peep/ .:. An Epic Webcomic To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 3 23:25:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.viasoft.com.cn (unknown [61.153.1.177]) by hub.freebsd.org (Postfix) with ESMTP id 0F6CA37B718; Sat, 3 Mar 2001 23:25:39 -0800 (PST) (envelope-from bsddiy@163.net) Received: from William ([192.168.1.98]) by mail.viasoft.com.cn (8.9.3/8.9.3) with ESMTP id MAA23161; Fri, 2 Mar 2001 12:19:58 +0800 Date: Fri, 2 Mar 2001 12:31:33 +0800 From: David Xu X-Mailer: The Bat! (v1.48f) Personal Reply-To: bsddiy X-Priority: 3 (Normal) Message-ID: <13013690696.20010302123133@163.net> To: freebsd-hackers@FreeBSD.org Cc: freebsd-questions@FreeBSD.org Subject: today cvsup and netstat broken Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have cvsuped 4.2-STABLE today, make buildword and mergemaster, after reboot, netstat no longer show TCP connections: %netstat -n -a -finet Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) udp4 0 0 *.3130 *.* udp4 0 0 *.* *.* udp4 0 0 192.168.1.97.138 *.* udp4 0 0 192.168.1.97.137 *.* udp4 0 0 *.138 *.* udp4 0 0 *.137 *.* udp4 0 0 *.518 *.* udp4 0 0 *.512 *.* udp4 0 0 *.111 *.* udp4 0 0 *.514 *.* % note that I telneted to the FreeBSD machine, the command did not show my telnet connection. -- David Xu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 3 23:40:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from silby.com (adam042-060.resnet.wisc.edu [146.151.42.60]) by hub.freebsd.org (Postfix) with ESMTP id 068B637B721 for ; Sat, 3 Mar 2001 23:40:09 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 6731 invoked by uid 1000); 4 Mar 2001 07:40:08 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 4 Mar 2001 07:40:08 -0000 Date: Sun, 4 Mar 2001 01:40:08 -0600 (CST) From: Mike Silbersack To: David Xu Cc: , Subject: Re: today cvsup and netstat broken In-Reply-To: <13013690696.20010302123133@163.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 2 Mar 2001, David Xu wrote: > note that I telneted to the FreeBSD machine, the command did not show > my telnet connection. > > -- > David Xu I'm seeing your telnet session fine in my packet sniffer. What's the problem? Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message