From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 00:04:33 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AEC516A4CE; Sun, 11 Jan 2004 00:04:33 -0800 (PST) Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E59143D54; Sun, 11 Jan 2004 00:04:32 -0800 (PST) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=danny) by cs.huji.ac.il with esmtp id 1AfaaC-0003ql-OJ; Sun, 11 Jan 2004 10:04:28 +0200 X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Robert Watson In-reply-to: Your message of Sat, 10 Jan 2004 17:48:20 -0500 (EST) . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Jan 2004 10:04:28 +0200 From: Danny Braniss Message-Id: cc: hackers@freebsd.org Subject: Re: diskless problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 08:04:33 -0000 while the subject is being revived, there are some changes/additions I made to libstand/bootp.c, it exports all the dhcp tags so that they are available to rc.diskless? or rc.d/initdiskless via kenv check out ftp://ftp.cs.huji.ac.il/users/danny/freebsd/diskless-boot/ these are a bit date, but the uptodated stuff is actively being used here, so if there is some interest i could update it. danny From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 00:29:11 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C21CC16A4D0 for ; Sun, 11 Jan 2004 00:29:11 -0800 (PST) Received: from hannibal.servitor.co.uk (hannibal.servitor.co.uk [195.188.15.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57B3543D31 for ; Sun, 11 Jan 2004 00:29:08 -0800 (PST) (envelope-from paul@iconoplex.co.uk) Received: from hannibal.servitor.co.uk ([195.188.15.48] helo=iconoplex.co.uk) by hannibal.servitor.co.uk with esmtp (Exim 4.14) id 1Afawj-0004fd-Jk; Sun, 11 Jan 2004 08:27:45 +0000 Message-ID: <400108FC.9010008@iconoplex.co.uk> Date: Sun, 11 Jan 2004 08:27:40 +0000 From: Paul Robinson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wes Peters References: <20040108163724.GA26745@lpthe.jussieu.fr> <20040110013313.Q51801@ganymede.hub.org> <200401101945.27234.wes@softweyr.com> In-Reply-To: <200401101945.27234.wes@softweyr.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: Discussion on the future of floppies in 5.x and 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 08:29:12 -0000 Wes Peters wrote: >Faster than loading a single ISO image with only the boot information and >sysinstall and booting from that, rather than 3 (or 4 or 5) floppies? A >CD-R is cheaper, faster, more reliable, and you don't have to keep >feeding them into the machine. > I think you're missing the point, which I'll come onto, but first, the points you raise. It's not cheaper than a floppy - I have stacks of old floppies here that are re-usable, unlike CD-Rs where I have to shell out for a new one every time. It isn't faster than a floppy, because I'm still doing an FTP install (because I've taken your advice and only downloaded a 3Mb file to "save time"). If you assume that burning the CD takes no longer than doing a dd (finding the machine would take me longer), it takes the same amount of time. Oh, you mean the extra 30 seconds to read the disk? Yeah, my life would be *much* improved if I could save that. (I'm trying to be ironic... :-) ). It isn't "more reliable", as I do a diff on /dev/fd0 and the img file to make sure everything is OK after the dd, and therefore it's just as reliable. In fact, with cheap CD-Rs, I get a coaster-to-usable ratio of about 1:2 which is nowhere near as good as 3.5" floppy. As for "Keep feeding them into the machine"? It's two disks. Let me write that again. 2. Two. One + one. This "constant feeding" is hardly likely to give me serious RSI. :-) Perhaps I'm missing something, and I can see why abondoning the current method in 5-6 years would be reasonable, but I don't see the immediate advantage of making the change right now. I also don't think it's the issue that needs to be dealt with - distribution is much, much, MUCH bigger an issue than "shall we get rid of floppies"? I sent this to the list before, but it got ignored, so I'll send it again, where Jordan points out we have bigger issues to deal with when discussing the "floppy disk problem" whilst discussing libh:- (http://rtp1.slowblink.com/~libh/sysinstall2/improvements.html): "As I mentioned in Section 2.3, one of the more annoying problems with FreeBSD's current distribution format is the dividing line between distributions and packages. There should really only be one type of "distribution format" and, of course, it should be the package (There Can Be Only One). Achieving this means we're first going to have to grapple with several problems, however: First, eliminating the distribution format means either teaching the package tools how to deal with a split archive format (they currently do not) or divorcing ourselves forever from floppies as a distribution medium. This is an issue which would seem an easy one to decide but invariably becomes Highly Religious(tm) every time it's brought up. In some dark corner of the world, there always seems to be somebody still installing FreeBSD via floppies and even some of the fortune 500 folks can cite FreeBSD success stories where they resurrected some old 386 box (with only a floppy drive and no networking/CD/...) and turned it into the star of the office/saved the company/etc etc. That's not to say we can't still bite that particular bullet, just that it's not a decision which will go down easily with everyone and should be well thought-out." And I have to say, I agree. If abondoning floppies is part of some well-thought-out and well-planned package management strategy, I'm all for it. Otherwise, let sleeping dogs lie? -- Paul Robinson From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 00:48:54 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D88B16A4CE for ; Sun, 11 Jan 2004 00:48:54 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71BD843D31 for ; Sun, 11 Jan 2004 00:48:53 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 3FE0C1880C1A; Sun, 11 Jan 2004 00:48:52 -0800 (PST) From: Wes Peters Organization: Softweyr To: Paul Robinson Date: Sun, 11 Jan 2004 00:48:52 -0800 User-Agent: KMail/1.5.4 References: <20040108163724.GA26745@lpthe.jussieu.fr> <200401101945.27234.wes@softweyr.com> <400108FC.9010008@iconoplex.co.uk> In-Reply-To: <400108FC.9010008@iconoplex.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401110048.52747.wes@softweyr.com> cc: freebsd-hackers@freebsd.org Subject: Re: Discussion on the future of floppies in 5.x and 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 08:48:54 -0000 On Sunday 11 January 2004 12:27 am, Paul Robinson wrote: > > Perhaps I'm missing something, and I can see why abondoning the current > method in 5-6 years would be reasonable, but I don't see the immediate > advantage of making the change right now. So you'll be signing up to do the floppy release engineering, and to modify the kernel so it can load the boot-device modules dynamically. That's great news! > And I have to say, I agree. If abondoning floppies is part of some > well-thought-out and well-planned package management strategy, I'm all > for it. Otherwise, let sleeping dogs lie? The dog isn't sleeping, it's dead. Like everything else in FreeBSD, it takes time. If someone wants to donate that time, it'll continue getting done, otherwise it'll fall by the wayside. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 01:01:22 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F14C116A4CE; Sun, 11 Jan 2004 01:01:22 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2220443D45; Sun, 11 Jan 2004 01:01:20 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id F03F15323; Sun, 11 Jan 2004 10:01:18 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id BD1A75308; Sun, 11 Jan 2004 10:01:11 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 509E633C6A; Sun, 11 Jan 2004 10:01:11 +0100 (CET) To: Scott Long References: <40007D14.6090205@freebsd.org> <40008E4A.3060604@freebsd.org> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Sun, 11 Jan 2004 10:01:11 +0100 In-Reply-To: <40008E4A.3060604@freebsd.org> (Scott Long's message of "Sat, 10 Jan 2004 16:44:10 -0700") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=RCVD_IN_SORBS autolearn=no version=2.60 cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: Future of RAIDFrame X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 09:01:23 -0000 Scott Long writes: > Dag-Erling Sm=F8rgrav wrote: > > I'm having trouble seeing what RF does that Vinum (or at least a > > properly GEOMified Vinum) can't do... > Please read the RAIDframe documents at http://www.pdl.cmu.edu/RAIDframe > before you ask again. I have, long ago, and frankly it sounds like GEOM with a bunch of RAID classes. We already have GEOM, and the RAID classes are practically trivial to implement once you have GEOM. Considering that RF is unusable in -CURRENT (any attempt to use it causes a panic) and nobody is working on it or has been in a long time, the least you could do is disconnect it from the build. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 01:03:18 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F91116A4CE for ; Sun, 11 Jan 2004 01:03:18 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DEB743D45 for ; Sun, 11 Jan 2004 01:03:17 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 3499D5323; Sun, 11 Jan 2004 10:03:16 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 6DB4E5308; Sun, 11 Jan 2004 10:03:08 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 4010533C6A; Sun, 11 Jan 2004 10:03:08 +0100 (CET) To: Peter Jeremy References: <20040109193551.GD39751@moo.sysabend.org> <20040110225509.GA60996@server.vk2pj.dyndns.org> <20040111005308.GD60996@server.vk2pj.dyndns.org> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Sun, 11 Jan 2004 10:03:08 +0100 In-Reply-To: <20040111005308.GD60996@server.vk2pj.dyndns.org> (Peter Jeremy's message of "Sun, 11 Jan 2004 11:53:08 +1100") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=RCVD_IN_SORBS autolearn=no version=2.60 cc: freebsd-hackers@freebsd.org Subject: Re: Large Filesystem Woes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 09:03:18 -0000 Peter Jeremy writes: > - A statement "these options are no longer necessary and will be > be removed in a future release" in the newfs(8)-equivalent man > page should read more like "these options are essential" (this > relates to dimensioning metadata allocation based on the expected > total number of files). The default values hit undocumented > metadata extent count limits at about 500,000 files. The table > showing suggested dimensioning guidelines only goes to 800,000 files. Ugh. That's practically useless. And they actually charge money for this product? DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 01:08:30 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C5A716A4CE for ; Sun, 11 Jan 2004 01:08:30 -0800 (PST) Received: from hannibal.servitor.co.uk (hannibal.servitor.co.uk [195.188.15.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id B93C643D45 for ; Sun, 11 Jan 2004 01:08:28 -0800 (PST) (envelope-from paul@iconoplex.co.uk) Received: from hannibal.servitor.co.uk ([195.188.15.48] helo=iconoplex.co.uk) by hannibal.servitor.co.uk with esmtp (Exim 4.14) id 1AfbYq-0004mm-Rs; Sun, 11 Jan 2004 09:07:08 +0000 Message-ID: <40011237.3000409@iconoplex.co.uk> Date: Sun, 11 Jan 2004 09:07:03 +0000 From: Paul Robinson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wes Peters References: <20040108163724.GA26745@lpthe.jussieu.fr> <200401101945.27234.wes@softweyr.com> <400108FC.9010008@iconoplex.co.uk> <200401110048.52747.wes@softweyr.com> In-Reply-To: <200401110048.52747.wes@softweyr.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: Discussion on the future of floppies in 5.x and 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 09:08:30 -0000 Wes Peters wrote: >So you'll be signing up to do the floppy release engineering, and to >modify the kernel so it can load the boot-device modules dynamically. >That's great news! > If the kernel changes don't support the established distribution format, the kernel changes are broken, not the distribution format. If the kernel changes must happen at some point and the distribution format must therefore become "the package", then that's fine, but that change (including being able to split packages over several physical distribution "units") has to happen first, surely? I'm happy to get involved in any team looking at that as it falls under something I've been looking at for the last year or so in my spare time - package management and installers. >The dog isn't sleeping, it's dead. Like everything else in FreeBSD, it >takes time. If someone wants to donate that time, it'll continue getting >done, otherwise it'll fall by the wayside. > Understood. I just think saying "let's get rid of floppies" is shooting a dog that happens to be near to hand because you don't like that dog, to stretch the analogy. Personally, I think getting the package management issues sorted so that distribution becomes independent of physical medium (so floppies, CDs, etc. can be used or abondoned at will, along with future formats) is an admirable goal, but one that should be on the 6- roadmap. In other words, getting rid of floppies is not the discussion we should be having, if that makes sense? -- Paul Robinson From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 01:20:07 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3680D16A4CE for ; Sun, 11 Jan 2004 01:20:07 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBF9E43D3F for ; Sun, 11 Jan 2004 01:20:04 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id C84905327; Sun, 11 Jan 2004 10:20:03 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 301D9530E; Sun, 11 Jan 2004 10:19:54 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id B8FA233C6A; Sun, 11 Jan 2004 10:19:53 +0100 (CET) To: Paul Robinson References: <20040108163724.GA26745@lpthe.jussieu.fr> <200401101945.27234.wes@softweyr.com> <400108FC.9010008@iconoplex.co.uk> <200401110048.52747.wes@softweyr.com> <40011237.3000409@iconoplex.co.uk> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Sun, 11 Jan 2004 10:19:53 +0100 In-Reply-To: <40011237.3000409@iconoplex.co.uk> (Paul Robinson's message of "Sun, 11 Jan 2004 09:07:03 +0000") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=RCVD_IN_SORBS autolearn=no version=2.60 cc: freebsd-hackers@freebsd.org Subject: Re: Discussion on the future of floppies in 5.x and 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 09:20:07 -0000 Paul Robinson writes: > Understood. I just think saying "let's get rid of floppies" is > shooting a dog that happens to be near to hand because you don't like > that dog, to stretch the analogy. I don't think you have any idea how difficult it is (and has been for a couple of years now) just to keep the install floppies alive. The kernel keeps growing, and the amount of "must-have" features (such as acpi) keeps growing, and every time the boot floppies overflow we have to toss out yet another driver that about a dozen people vehemently tell us they can't live without. To rephrase this in terms of your analogy, the dog was hit by a bus two years ago and has been on artificial life support ever since, and it's starting to dawn on us that we can no longer afford the hospital bill. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 01:27:52 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7C4E16A4CE for ; Sun, 11 Jan 2004 01:27:52 -0800 (PST) Received: from pc5.i.0x5.de (reverse-213-146-113-119.dialin.kamp-dsl.de [213.146.113.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DE6943D46 for ; Sun, 11 Jan 2004 01:27:48 -0800 (PST) (envelope-from nicolas@dauerreden.de) Received: from pc5.i.0x5.de (nicolas@localhost [127.0.0.1]) by pc5.i.0x5.de (8.12.9p2/8.12.9) with ESMTP id i0B9RkR7002866 for ; Sun, 11 Jan 2004 10:27:46 +0100 (CET) (envelope-from nicolas@pc5.i.0x5.de) Received: (from nicolas@localhost) by pc5.i.0x5.de (8.12.9p2/8.12.9/Submit) id i0B9RkEh002865 for freebsd-hackers@freebsd.org; Sun, 11 Jan 2004 10:27:46 +0100 (CET) (envelope-from nicolas) Date: Sun, 11 Jan 2004 10:27:46 +0100 From: Nicolas Rachinsky To: freebsd-hackers@freebsd.org Message-ID: <20040111092746.GA836@pc5.i.0x5.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20040108163724.GA26745@lpthe.jussieu.fr> <200401101945.27234.wes@softweyr.com> <400108FC.9010008@iconoplex.co.uk> <200401110048.52747.wes@softweyr.com> <40011237.3000409@iconoplex.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Powered-by: FreeBSD X-Homepage: http://www.rachinsky.de X-PGP-Keyid: C11ABC0E X-PGP-Fingerprint: 19DB 8392 8FE0 814A 7362 EEBD A53B 526A C11A BC0E X-PGP-Key: http://www.rachinsky.de/nicolas/nicolas_rachinsky.asc X-SECURITY: Never trust a running system User-Agent: Mutt/1.5.5.1i Subject: Re: Discussion on the future of floppies in 5.x and 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 09:27:52 -0000 * Dag-Erling Smørgrav [2004-01-11 10:19 +0100]: > Paul Robinson writes: > > Understood. I just think saying "let's get rid of floppies" is > > shooting a dog that happens to be near to hand because you don't like > > that dog, to stretch the analogy. > > I don't think you have any idea how difficult it is (and has been for > a couple of years now) just to keep the install floppies alive. The > kernel keeps growing, and the amount of "must-have" features (such as > acpi) keeps growing, and every time the boot floppies overflow we have > to toss out yet another driver that about a dozen people vehemently > tell us they can't live without. Why not split the kernel onto 2 disks? The code to do this is already there and seems to work. And the people who think they absolutly need disks would have to deal with 4 disks, but that would be better than no disks. Look at the commit history of /usr/src/lib/libstand/splitfs.c. Is there a reason not to use it? Nicolas From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 02:01:04 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4251416A4CE for ; Sun, 11 Jan 2004 02:01:04 -0800 (PST) Received: from herring.nlsystems.com (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC7CA43D39 for ; Sun, 11 Jan 2004 02:01:01 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from [10.0.0.2] (herring.nlsystems.com [10.0.0.2]) i0BA0n3I044931; Sun, 11 Jan 2004 10:00:49 GMT (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Peter Jeremy In-Reply-To: <20040111000551.GC60996@server.vk2pj.dyndns.org> References: <20040110032731.18864.qmail@web13422.mail.yahoo.com> <40003F4C.2000107@gamersimpact.com><4000701B.40102@cream.org> <20040111000551.GC60996@server.vk2pj.dyndns.org> Content-Type: text/plain Message-Id: <1073815249.5250.2.camel@herring.nlsystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 11 Jan 2004 10:00:49 +0000 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on herring.nlsystems.com cc: freebsd-hackers@freebsd.org Subject: Re: SCM options (was Re: Where is FreeBSD going?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 10:01:04 -0000 On Sun, 2004-01-11 at 00:05, Peter Jeremy wrote: > On Sat, Jan 10, 2004 at 05:01:13PM -0500, Garance A Drosihn wrote: > >At 9:35 PM +0000 1/10/04, Andrew Boothman wrote: > >>Peter Schuller wrote: > >> > >>>Most of the noteworthy features of subversion are listed > >>>on the project front page: > >>> > >>> http://subversion.tigris.org/ > >> > >>A significant one of which is the fact that it's available > >>under a BSD-style license. Meaning that the project wouldn't > >>have to rely on more GPLed code. > >> > >>I wonder if our SCM would be brought into the base system or > >>whether it would just be left in ports? > > > >We haven't even started to *test* subversion yet, so I think > >it's a bit early to worry about this question! > > I disagree. Andrew raised two issues (type of license and port vs > base location). The type of license is an input to the decision as > to which SCM to choose - BSD would be preferable but GPL is probably > acceptable (given two potential SCMs with similar features, the BSD > licensed one would be selected in preference to the GPL one). Subversion has a friendly BSD-ish license but it depends heavily on Sleepycat DB which doesn't. I imagine that if we do end up using it one day, it would be best managed as a port rather than part of the base system. I just don't see many people agreeing on importing subversion+db-4.2+apache2 into src/contrib... From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 02:29:41 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB3AE16A4CE for ; Sun, 11 Jan 2004 02:29:41 -0800 (PST) Received: from web12706.mail.yahoo.com (web12706.mail.yahoo.com [216.136.173.243]) by mx1.FreeBSD.org (Postfix) with SMTP id 07B5A43D4C for ; Sun, 11 Jan 2004 02:29:41 -0800 (PST) (envelope-from topa_007@yahoo.com) Message-ID: <20040111102937.89684.qmail@web12706.mail.yahoo.com> Received: from [219.65.96.135] by web12706.mail.yahoo.com via HTTP; Sun, 11 Jan 2004 02:29:37 PST Date: Sun, 11 Jan 2004 02:29:37 -0800 (PST) From: 70uf33q Hu5541n To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: FreeBSD 5.1 Installation probelms X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 10:29:41 -0000 hey guys, Just got my copy of FreeBSD 5.1. Spent about an hour going through the BSD Handbook and preparing a Installation checklist. ok here's my problem. I have a WD 40 GB HDD the primary partition is 10 GB, with the extended partition 28 GB.(the rest 2 GB is in WD's bank). OK , the extended partition has 3 logical drives. To create a slice for BSD, I resized one of the logical drives to free up some space. About 1.2 GB,cause that's all I can spare. When I run the installation through CDROM, and the point where I'm to creat the Freebsd slice,the new partition is not displayed in the "FDISK" utility. All I get is the primary (10GB) and the whole Extended (28 GB). The freespace I guess is "locked into" the Extended Partiton. Not sure though. Any workaround for this, or should I start with a new HDD. cheers, TH ===== "Love is control,I'll die if I let go I will only let you breathe My air that you receive Then we'll see if I let you love me." -James Hetfield All Within My Hands,St.Anger Metallica __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 03:13:55 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A5B216A4CE; Sun, 11 Jan 2004 03:13:55 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F2C943D1D; Sun, 11 Jan 2004 03:13:54 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i0BBDaOl009730; Sun, 11 Jan 2004 12:13:52 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Alexander Leidinger From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 11 Jan 2004 12:08:24 +0100." <20040111120824.00cb6314@Magellan.Leidinger.net> Date: Sun, 11 Jan 2004 12:13:36 +0100 Message-ID: <9729.1073819616@critter.freebsd.dk> cc: Greg 'groggy' Lehey cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 11:13:55 -0000 In message <20040111120824.00cb6314@Magellan.Leidinger.net>, Alexander Leidinge r writes: >I'm a little bit confused. I've read Pouls mail as an suggestion to >remove vinum from -current and let people modify it in the perforce >repository. If I got this wrong, please tell me and everything is fine, >but if I got it right, do you (Greg) agree to remove it from -current? My proposal is to do just that with both vinum and raidframe until one or possibly both are up to full strength again. -- 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. From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 03:27:23 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9214016A4CE; Sun, 11 Jan 2004 03:27:23 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6C2F43D45; Sun, 11 Jan 2004 03:27:21 -0800 (PST) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (blackwater.lemis.com [192.109.197.80]) by ozlabs.org (Postfix) with ESMTP id BC83C2BD5A; Sun, 11 Jan 2004 22:27:18 +1100 (EST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 3E35851211; Sun, 11 Jan 2004 21:57:16 +1030 (CST) Date: Sun, 11 Jan 2004 21:57:16 +1030 From: Greg 'groggy' Lehey To: Alexander Leidinger Message-ID: <20040111112716.GO7617@wantadilla.lemis.com> References: <40007D14.6090205@freebsd.org> <3180.1073776377@critter.freebsd.dk> <20040111051649.GK7617@wantadilla.lemis.com> <20040111120824.00cb6314@Magellan.Leidinger.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrLUmiMCPBhU8YVX" Content-Disposition: inline In-Reply-To: <20040111120824.00cb6314@Magellan.Leidinger.net> User-Agent: Mutt/1.4.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: Poul-Henning Kamp cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 11:27:23 -0000 --lrLUmiMCPBhU8YVX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sunday, 11 January 2004 at 12:08:24 +0100, Alexander Leidinger wrote: > On Sun, 11 Jan 2004 15:46:49 +1030 > "Greg 'groggy' Lehey" wrote: >> [missing attribution to phk] >>> I'd say lets kick them both into perforce and let whoever wants >>> their hands have a go at them. >> >> For some definition of perforce, I'm all for it. Note that there's >> also an OS-independent mailing list (see >> http://www.auug.org.au/mailman/listinfo/vinum-devel for joining >> instructions). > > I'm a little bit confused. I've read Pouls mail as an suggestion to > remove vinum from -current and let people modify it in the perforce > repository. If I got this wrong, please tell me and everything is fine, > but if I got it right, do you (Greg) agree to remove it from -current? No. As others have said, if phk and I agree, the world will come to an end. I'm saying: 1. Yes, let people hack at it and improve on it outside the source tree. 2. If it works, don't fix it. At the moment, Vinum works, for some definition of "works". These two aren't incompatible. Removing existing functionality for the sake of purity, on the other hand, is unnecessary. Sadly, much as I love the discussion, I have this conference next week, starting in less than 12 hours, and I need to sleep first. Unless the shit hits the fan, don't expect to hear from me for a week. Greg -- See complete headers for address and phone numbers. --lrLUmiMCPBhU8YVX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQFAATMUIubykFB6QiMRAqHlAJ0Wd3uFQUikBonRkn8SxW/xNt0FpACbBOlF qLLwJ8v+RHyUdYcWZVL4Jn4= =EvJq -----END PGP SIGNATURE----- --lrLUmiMCPBhU8YVX-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 03:39:17 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC7CB16A4CE; Sun, 11 Jan 2004 03:39:17 -0800 (PST) Received: from mindfields.energyhq.es.eu.org (73.Red-213-97-200.pooles.rima-tde.net [213.97.200.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89BAD43D2F; Sun, 11 Jan 2004 03:39:15 -0800 (PST) (envelope-from flynn@energyhq.es.eu.org) Received: from energyhq.es.eu.org (scienide.energyhq.es.eu.org [192.168.100.1]) by mindfields.energyhq.es.eu.org (Postfix) with ESMTP id B6BCF356F0; Sun, 11 Jan 2004 12:39:13 +0100 (CET) Message-ID: <400135EA.8050603@energyhq.es.eu.org> Date: Sun, 11 Jan 2004 12:39:22 +0100 From: Miguel Mendez User-Agent: Mozilla/5.0 (X11; U; DragonFly i386; en-US; rv:1.6b) Gecko/20040110 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <40007D14.6090205@freebsd.org> In-Reply-To: <40007D14.6090205@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: Future of RAIDFrame X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 11:39:18 -0000 Scott Long wrote: > I started RAIDframe three years ago with the hope of bringing a proven > and extensible RAID stack to FreeBSD. Unfortunately, while it was made > to work pretty well on 4.x, it has never been viable on 5.x; it never > survived the introduction of GEOM and removal of the old disk layer. > I'm coming to the conclusion that I really don't have the time to work > on it in my spare time. Also, I've seen next to zero interest in it > from others, except for the occasional reminder that it doesn't work. William Carrel used to maintain a set of patches for RAIDframe on 4.x, were they ever committed? No? Why not? WRT lack of interest in RF. First, the 5.0 patches were horrible. That code was a mess to work with. Second, inertia. Most people with simple needs like mirroring and/or simple stripes were happy with good old ccd(4). Those who needed a full volume manager (which neither ccd nor RF claim to be) used vinum. People with VxVM experience feel at home with it. Unfortunately, vinum has its own set of issues as well. It's probably easier to write a set of GEOM classes from scratch than trying to shoehorn RF into GEOM. Cheers, Miguel Mendez http://www.energyhq.es.eu.org From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 03:45:47 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD8B816A4CE for ; Sun, 11 Jan 2004 03:45:46 -0800 (PST) Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 259C543D5A for ; Sun, 11 Jan 2004 03:45:42 -0800 (PST) (envelope-from alsbergt@cs.huji.ac.il) Received: from serin.cs.huji.ac.il ([132.65.80.149] ident=exim) by cs.huji.ac.il with esmtp id 1Afe2G-000Ihr-5h for freebsd-hackers@freebsd.org; Sun, 11 Jan 2004 13:45:40 +0200 Received: from alsbergt by serin.cs.huji.ac.il with local (Exim 4.12) id 1Afe2G-000Dyh-00 for freebsd-hackers@freebsd.org; Sun, 11 Jan 2004 13:45:40 +0200 Date: Sun, 11 Jan 2004 13:45:39 +0200 From: Tom Alsberg To: FreeBSD Hackers List Message-ID: <20040111114539.GA53691@cs.huji.ac.il> Mail-Followup-To: Tom Alsberg , FreeBSD Hackers List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Face: "5"j@Y1Peoz1; ftTv>\|['ox-csmV+:_RDNdi/2lSe2x?0:HVAeVW~ajwQ7RfDlcb^18eJ; t,O,s5-aNdU/DJ2E8h1s,..4}N9$27u`pWmH|; s!zlqqVwr9R^_ji=1\3}Z6gQBYyQ]{gd5-V8s^fYf{$V2*_&S>eA|SH@Y\hOVUjd[5eah{EO@gCr.ydSpJHJIU[QsH~bC?$C@O:SzF=CaUxp80-iknM(]q(W List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 11:45:47 -0000 Hi there. I sent the following question to the list a while ago, and got no answer yet. The problem looks weird to me, but I have the feeling that I'm missing something very simple (I did RTFM, though) - so if anyone can provide any guidance - cannot be that complicated of a question... I didn't look much into the sources of the kernel GDB (db_interface.c, etc. etc.), but from what I saw I wasn't sure what's going on. I'm asking again because it would really ease one of the things I have on my "to do" queue (which I haven't touched recently because of that problem): I'm fooling around a bit with kernel hacking recently, and got a bit to work with online kernel debugging with GDB (over a serial port). I built the kernel (FreeBSD-4.9) with DDB and -g compile option, and set the flag on sio0, as described in section 10.6 of the FreeBSD Developer's Handbook at: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-gdb.html Using gdb -k I can open the kernel image, and doing 'target remote /dev/cuaa0' I can attach to the debugged host (having switched to gdb mode from DDB on it, and entered 's' to generate a trap). Trying to figure out some stuff I can do with it, I noticed that for some reason I cannot call any kernel functions from kgdb... When entering, e.g. the command: (kgdb) call print_uptime() gdb points it caught of a SIGSEGV, which actually is a panic on the host - I see a fatal trap 12 (page fault while in kernel mode), with fault code 'supervisor read, page not present'... Am I in some special context when inside the kernel debugger, from which other kernel functions cannot be called? (no access to their page?) What needs to be done to setup the paging and memory protection to be able to do so? The even more weird thing yet is that from the information in the panic, during the panic the instruction pointer, frame pointer (but not the stack pointer), and panic virtual address are zero: fault virtual address = 0x0 instruction pointer = 0x8:0x0 frame pointer = 0x10:0x0 I thought maybe there is some zero at the time of return from the function when ret is executed (so the CPU tries to jump to address 0), but having put some breakpoints inside the function, I see that the panic is even before the first instruction of it executes... I found very little documentation on kernel debugging, except on how to get into DDB and use it a bit, how to debug offline with gdb with crash dumps, and how to start a remote online GDB session through the serial port on a running kernel... In the Developer's Handbook there are examples on usage of DDB online, and GDB offline on a crash dump, but no examples of online remote GDB usage. I am not sure how exactly the contexts of the kernel should affect debugging which (as far as I understand) is done completely within the kernel, and how the kernel debugger/GDB interferes... I'll try to learn more and perhaps understand it... But can someone provide some ideas as to what is the cause of the problem, what is exactly happening and why, and how to overcome it? Thanks, any help appreciated, -- Tom -- Tom Alsberg - hacker (being the best description fitting this space) Web page: http://www.cs.huji.ac.il/~alsbergt/ DISCLAIMER: The above message does not even necessarily represent what my fingers have typed on the keyboard, save anything further. From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 05:06:39 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B34E216A4CE for ; Sun, 11 Jan 2004 05:06:39 -0800 (PST) Received: from Vitsch.net (b74143.upc-b.chello.nl [212.83.74.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5917743D45 for ; Sun, 11 Jan 2004 05:06:37 -0800 (PST) (envelope-from Danovitsch@Vitsch.net) Received: from FreeBSD.Danovitsch.LAN (b83007.upc-b.chello.nl [212.83.83.7]) by Vitsch.net (8.12.3p2/8.11.3) with ESMTP id i0BD6GXe046745; Sun, 11 Jan 2004 14:06:17 +0100 (CET) (envelope-from Danovitsch@Vitsch.net) Content-Type: text/plain; charset="iso-8859-1" From: "Daan Vreeken [PA4DAN]" To: 70uf33q Hu5541n Date: Sun, 11 Jan 2004 14:06:41 +0100 User-Agent: KMail/1.4.3 References: <20040111102937.89684.qmail@web12706.mail.yahoo.com> In-Reply-To: <20040111102937.89684.qmail@web12706.mail.yahoo.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200401111406.41156.Danovitsch@Vitsch.net> cc: FreeBSD-hackers@FreeBSD.org Subject: Re: FreeBSD 5.1 Installation probelms X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 13:06:39 -0000 On Sunday 11 January 2004 11:29, 70uf33q Hu5541n wrote: > hey guys, > > Just got my copy of FreeBSD 5.1. > Spent about an hour going through the BSD Handbook and > preparing a Installation checklist. > > ok here's my problem. > > I have a WD 40 GB HDD > the primary partition is 10 GB, with the extended > partition 28 GB.(the rest 2 GB is in WD's bank). > > OK , the extended partition has 3 logical drives. > To create a slice for BSD, I resized one of the > logical drives to free up some space. About 1.2 > GB,cause that's all I can spare. > > When I run the installation through CDROM, and the > point where I'm to creat the Freebsd slice,the new > partition is not displayed in the "FDISK" utility. > > All I get is the primary (10GB) and the whole Extended > (28 GB). > The freespace I guess is "locked into" the Extended > Partiton. Not sure though. Indeed you first have to resize the extended partition before you can use= the=20 space to create slices. The "fdisk" program that comes with Windows has n= o=20 way to do this (except deleting all logicle drives in the extended partit= ion=20 and re-creating them). Have a look at the program "Partition Magic". It c= an=20 resize partitions and it has a nice user interface. grtz, Daan From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 10 09:05:51 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8955316A4CE for ; Sat, 10 Jan 2004 09:05:51 -0800 (PST) Received: from web13425.mail.yahoo.com (web13425.mail.yahoo.com [216.136.175.156]) by mx1.FreeBSD.org (Postfix) with SMTP id 9BF3E43D1F for ; Sat, 10 Jan 2004 09:05:50 -0800 (PST) (envelope-from giffunip@yahoo.com) Message-ID: <20040110170550.34302.qmail@web13425.mail.yahoo.com> Received: from [200.93.154.235] by web13425.mail.yahoo.com via HTTP; Sat, 10 Jan 2004 09:05:50 PST Date: Sat, 10 Jan 2004 09:05:50 -0800 (PST) From: "Pedro F. Giffuni" To: Garance A Drosihn In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Sun, 11 Jan 2004 05:21:34 -0800 cc: freebsd-hackers@freebsd.org Subject: Re: SCM options (was Re: Where is FreeBSD going?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: giffunip@asme.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 17:05:51 -0000 --- Garance A Drosihn wrote: > At 7:27 PM -0800 1/9/04, Pedro F. Giffuni wrote: > >Hi; > > > >There is a comparison here: > >http://better-scm.berlios.de/comparison/comparison.html > > > >I think there are compelling reasons to try subversion, > >but we have to wait for a 1.0 Release, and this would be > >something that should be done gradually.. for example > >moving the ports tree first. > > That's a pretty major test! Could we perhaps pick off > something smaller? The "projects" repository, for > instance? (or is that still tied to the base-system?) > > (I am very interested in subversion, but it is still > something I need to learn more about...) > I think we must wait until a 1.0 version is available. SVN is meant to be a replacement to CVS. The projects repository is using perforce which happens to be a good tool, so moving it to svn is probably not a step forward IMHO ;-). cheers, Pedro. > -- > Garance Alistair Drosehn = gad@gilead.netel.rpi.edu > Senior Systems Programmer or gad@freebsd.org > Rensselaer Polytechnic Institute or drosih@rpi.edu __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 10 15:13:00 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 583DF16A4CE; Sat, 10 Jan 2004 15:13:00 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9213D43D4C; Sat, 10 Jan 2004 15:12:58 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i0ANCvOl003181; Sun, 11 Jan 2004 00:12:57 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Scott Long From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 10 Jan 2004 15:30:44 MST." <40007D14.6090205@freebsd.org> Date: Sun, 11 Jan 2004 00:12:57 +0100 Message-ID: <3180.1073776377@critter.freebsd.dk> X-Mailman-Approved-At: Sun, 11 Jan 2004 05:21:34 -0800 cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: Future of RAIDFrame X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 23:13:00 -0000 In message <40007D14.6090205@freebsd.org>, Scott Long writes: >All, > >I started RAIDframe three years ago with the hope of bringing a proven >and extensible RAID stack to FreeBSD. Unfortunately, while it was made >to work pretty well on 4.x, it has never been viable on 5.x; it never >survived the introduction of GEOM and removal of the old disk layer. >[...] >I have a Work-In-Progress for converting and integrating it into GEOM >on my home Perforce server. It hasn't been touched in several months >and I really don't see myself being able to finish alone it in the near >future. Since it's been hanging over my head for so long, I'm very, >very close to just removing it and moving on. I can't help thinking about how small the central group of developers in FreeBSD is, and considering that you also carry the armoured release-engineer hat, I am fully able to understand why you have not been able to pull RF along in addition to all the other stuff. As much as I would hate to see RF and Vinum disappar from our source tree, maybe what we need to do is to kick them both into "training-camp" in p4 while you and Greg look the other way. In the p4 tree, we can easier add new talent to our developer force and I am pretty sure that some sort of merry band of developers would form around both RF and vinum there. I am not convinced that they may be able to pull off the task, but the fact that somebody at least tries should give us better chances than having RF stuck in your TODO queue, and vinum stuck in Gregs, while everybody else waits more or less paitiently. If they manage to make it work in p4, pulling it back into CVS is a small matter of repo work (AFAIK). Because we might as well be honest and face it: Neither you nor Greg has much chance of finding the significant amount of time that you need. I know this can be seen as you and Greg throwing in the towel, but I urge you to try to see it like saw my Junior Kernel Hacker list: Throwing a good meaty bone to pick which I myself couldn't eat anyway. I'd say lets kick them both into perforce and let whoever wants their hands have a go at them. Poul-Henning -- 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. From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 10 16:52:18 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A232516A4CE; Sat, 10 Jan 2004 16:52:18 -0800 (PST) Received: from gallantin.skynet.be (gallantin.skynet.be [195.238.2.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A22843D4C; Sat, 10 Jan 2004 16:52:16 -0800 (PST) (envelope-from brad.knowles@skynet.be) Received: from [10.0.1.4] (16.139-200-80.adsl.skynet.be [80.200.139.16]) ESMTP id i0B0qAPq003811; Sun, 11 Jan 2004 01:52:10 +0100 (envelope-from ) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: References: <40007D14.6090205@freebsd.org> Date: Sun, 11 Jan 2004 01:52:15 +0100 To: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= ) From: Brad Knowles Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-RAVMilter-Version: 8.4.3(snapshot 20030212) (gallantin.skynet.be) X-Mailman-Approved-At: Sun, 11 Jan 2004 05:21:34 -0800 cc: hackers@freebsd.org cc: Scott Long Subject: Re: Future of RAIDFrame X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 00:52:18 -0000 At 12:28 AM +0100 2004/01/11, Dag-Erling Smørgrav wrote: > I'm having trouble seeing what RF does that Vinum (or at least a > properly GEOMified Vinum) can't do... I think Scott is right, in that we should probably have separate RAID vs. LVM systems. It seems to me that vinum naturally fills the LVM role, while RAIDframe handles the RAID side well. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 10 17:05:00 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3A6116A4CE; Sat, 10 Jan 2004 17:05:00 -0800 (PST) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFC6A43D3F; Sat, 10 Jan 2004 17:04:58 -0800 (PST) (envelope-from Alexander@Leidinger.net) Received: from fwd03.aul.t-online.de by mailout02.sul.t-online.com with smtp id 1AfU26-0001H5-01; Sun, 11 Jan 2004 02:04:50 +0100 Received: from Andro-Beta.Leidinger.net (VUkzL8ZlgeBnTfXkjgnHJbvDsTRpRMkXagMdLxr2jw5A2X2zZVNN0U@[217.83.16.40]) by fmrl03.sul.t-online.com with esmtp id 1AfU24-1krANk0; Sun, 11 Jan 2004 02:04:48 +0100 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) i0B14iJb036510; Sun, 11 Jan 2004 02:04:44 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Magellan.Leidinger.net (netchild@localhost [127.0.0.1]) i0B150O2077496; Sun, 11 Jan 2004 02:05:00 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Sun, 11 Jan 2004 02:04:59 +0100 From: Alexander Leidinger To: "Poul-Henning Kamp" Message-Id: <20040111020459.5bbba56a@Magellan.Leidinger.net> In-Reply-To: <3180.1073776377@critter.freebsd.dk> References: <40007D14.6090205@freebsd.org> <3180.1073776377@critter.freebsd.dk> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: VUkzL8ZlgeBnTfXkjgnHJbvDsTRpRMkXagMdLxr2jw5A2X2zZVNN0U@t-dialin.net X-Mailman-Approved-At: Sun, 11 Jan 2004 05:21:34 -0800 cc: hackers@freebsd.org cc: Scott Long cc: current@freebsd.org Subject: Re: Future of RAIDFrame X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 01:05:00 -0000 On Sun, 11 Jan 2004 00:12:57 +0100 "Poul-Henning Kamp" wrote: > As much as I would hate to see RF and Vinum disappar from our > source tree, maybe what we need to do is to kick them both into > "training-camp" in p4 while you and Greg look the other way. [...] > I'd say lets kick them both into perforce and let whoever wants > their hands have a go at them. RF isn't working today on -current, vinum is (please don't tell me something else, I don't want the system under my desk stop running on a vinum volume just because you say it has to :-)). Do you really want to throw your axe at vinum while it's still alive? Bye, Alexander. -- I will be available to get hired in April 2004. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 10 17:35:42 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E17D716A4CE; Sat, 10 Jan 2004 17:35:42 -0800 (PST) Received: from nebula.skynet.be (nebula.skynet.be [195.238.2.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7347543D49; Sat, 10 Jan 2004 17:35:39 -0800 (PST) (envelope-from brad.knowles@skynet.be) Received: from [10.0.1.4] (16.139-200-80.adsl.skynet.be [80.200.139.16]) id i0B1ZTGC020361; Sun, 11 Jan 2004 02:35:30 +0100 (envelope-from ) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: <40007D14.6090205@freebsd.org> References: <40007D14.6090205@freebsd.org> Date: Sun, 11 Jan 2004 02:35:38 +0100 To: Scott Long From: Brad Knowles Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-RAVMilter-Version: 8.4.3(snapshot 20030212) (nebula.skynet.be) X-Mailman-Approved-At: Sun, 11 Jan 2004 05:21:34 -0800 cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: Future of RAIDFrame X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 01:35:43 -0000 At 3:30 PM -0700 2004/01/10, Scott Long wrote: > It will probably never be an LVM stack, but I've also always > believed that LVM and RAID are related but separate layers. Having looked at the RAIDframe documentation you referenced, it strikes me that it cannot really move towards LVM and still be RAIDframe. It is a framework for doing rapid prototyping of RAID systems (and presumably their operation), and is available on a wide variety of platforms. To do anything else would be to change the fundamental nature of the beast. > It can > certainly build upon whatever LVM layer appears in GEOM. My experience has been that a good RAID/LVM system also needs a lot of support from the filesystem, and skimming through the RAIDframe documentation, it seems that I am not alone in this opinion. What work has been done (or identified) to make the filesystem more suitable for use with RAID/LVM systems? At the most basic, do we have things like "growfs" and "shrinkfs"? -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 01:32:08 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A27616A4CE; Sun, 11 Jan 2004 01:32:08 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00BA343D54; Sun, 11 Jan 2004 01:32:02 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i0B9VxOl006553; Sun, 11 Jan 2004 10:31:59 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: "Greg 'groggy' Lehey" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 11 Jan 2004 15:46:49 +1030." <20040111051649.GK7617@wantadilla.lemis.com> Date: Sun, 11 Jan 2004 10:31:59 +0100 Message-ID: <6552.1073813519@critter.freebsd.dk> X-Mailman-Approved-At: Sun, 11 Jan 2004 05:21:34 -0800 cc: hackers@FreeBSD.org cc: Scott Long cc: current@FreeBSD.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 09:32:08 -0000 In message <20040111051649.GK7617@wantadilla.lemis.com>, "Greg 'groggy' Lehey" writes: >> As much as I would hate to see RF and Vinum disappar from our >> source tree, maybe what we need to do is to kick them both into >> "training-camp" in p4 while you and Greg look the other way. > >Hmm. I can't see why they have to disappear from the source tree, and >I don't see why Scott or I should have to look the other way. The reason I say this is that neither of you have the time needed, and whoever picks up may have ideas, even necesarry ideas, which would grind your spine seriously. By letting go, I think you would give vinum a better chance. >> In the p4 tree, we can easier add new talent to our developer force >> and I am pretty sure that some sort of merry band of developers >> would form around both RF and vinum there. > >OK, I'm not a fan of p4, but I suspect that's not the issue. This >sounds like a way of suggesting "Let's do VinumNG and RFNG and get a >whole lot of people involved". I couldn't agree more. Well, I soft of think the entire "NG" thing is sooooo dotcomish, so I particularly tried to avoid it :-) But otherwise: yes, exactly. I just want you and Scott to realize that if you don't have the time to run with whatever crowd forms, your participation might be a hindrance more than a help. For it to work, you need to truly let go of control. >I've been trying to encourage people to look at Vinum for some time. >It's a relatively complicated piece of code, and something about it >seems to scare people away. The proximity of a Well.Known@FreeBSD.org person can be quite a damper on enthusiasm by way of intimidation: "Gee, I'm nowhere near as good as him, I'd better not even try", and getting a lukewarm "Yeah, well, maybe" from such a person is a very cold shower for a young rising star. We are an intimidating bunch of old farts, and that's all well and fine, but we need to remember to pull in young farts and let them grow older, at least if we want the project to stay long term. Every so often I have to remind myself that when I was at their age, I was allowed to mess around with some complicated and important stuff so I shouldn't be in the way of them getting the same experience. >> but I urge you to try to see it like saw my Junior Kernel Hacker >> list: Throwing a good meaty bone to pick which I myself couldn't eat >> anyway. > >Yes, that's the way I've seen it for some time. Any ideas how to >excite people? Do you want to say something? Something like "If phk >and grog agree, it must be right"? :-) A lot of people out there will start looking out for black helicopters if they see the two of us agree, so I would like to state for the record that while you words _seem_ to say the same as my words, you have got it all _TOTALLY_ wrong! :-) Poul-Henning -- 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. From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 03:08:46 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88D7C16A4CE; Sun, 11 Jan 2004 03:08:46 -0800 (PST) Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 832B143D46; Sun, 11 Jan 2004 03:08:44 -0800 (PST) (envelope-from Alexander@Leidinger.net) Received: from fwd01.aul.t-online.de by mailout08.sul.t-online.com with smtp id 1AfdSV-0000J3-02; Sun, 11 Jan 2004 12:08:43 +0100 Received: from Andro-Beta.Leidinger.net (Gib5+4ZpYefNid2RHt0M4Eddr0rQhRFC6FkWxtgXGbclkR56HZ4900@[217.83.16.40]) by fmrl01.sul.t-online.com with esmtp id 1AfdS2-1a4gUK0; Sun, 11 Jan 2004 12:08:14 +0100 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) i0BB87Jb020539; Sun, 11 Jan 2004 12:08:08 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Magellan.Leidinger.net (netchild@localhost [127.0.0.1]) i0BB8P51006557; Sun, 11 Jan 2004 12:08:25 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Sun, 11 Jan 2004 12:08:24 +0100 From: Alexander Leidinger To: "Greg 'groggy' Lehey" Message-Id: <20040111120824.00cb6314@Magellan.Leidinger.net> In-Reply-To: <20040111051649.GK7617@wantadilla.lemis.com> References: <40007D14.6090205@freebsd.org> <3180.1073776377@critter.freebsd.dk> <20040111051649.GK7617@wantadilla.lemis.com> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: Gib5+4ZpYefNid2RHt0M4Eddr0rQhRFC6FkWxtgXGbclkR56HZ4900@t-dialin.net X-Mailman-Approved-At: Sun, 11 Jan 2004 05:21:34 -0800 cc: Poul-Henning Kamp cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 11:08:46 -0000 On Sun, 11 Jan 2004 15:46:49 +1030 "Greg 'groggy' Lehey" wrote: > Hmm. I can't see why they have to disappear from the source tree, and > I don't see why Scott or I should have to look the other way. I don't > know about RAIDFrame, but Vinum still works for the most part: [...] > > In the p4 tree, we can easier add new talent to our developer force > > and I am pretty sure that some sort of merry band of developers > > would form around both RF and vinum there. > > OK, I'm not a fan of p4, but I suspect that's not the issue. This > sounds like a way of suggesting "Let's do VinumNG and RFNG and get a > whole lot of people involved". I couldn't agree more. [...] > > I'd say lets kick them both into perforce and let whoever wants > > their hands have a go at them. > > For some definition of perforce, I'm all for it. Note that there's > also an OS-independent mailing list (see > http://www.auug.org.au/mailman/listinfo/vinum-devel for joining > instructions). I'm a little bit confused. I've read Pouls mail as an suggestion to remove vinum from -current and let people modify it in the perforce repository. If I got this wrong, please tell me and everything is fine, but if I got it right, do you (Greg) agree to remove it from -current? Bye, Alexander. -- I will be available to get hired in April 2004. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 05:52:41 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AF4A16A4CE for ; Sun, 11 Jan 2004 05:52:41 -0800 (PST) Received: from as6-1-5.kr.m.bonet.se (as6-1-5.kr.m.bonet.se [217.215.84.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FFCC43D45 for ; Sun, 11 Jan 2004 05:52:39 -0800 (PST) (envelope-from martin@gneto.com) Received: from gneto.com (euklides.gneto.com [192.168.10.11]) by as6-1-5.kr.m.bonet.se (Postfix) with ESMTP id 5B89C743AC for ; Sun, 11 Jan 2004 14:52:37 +0100 (CET) Message-ID: <4001552B.5060108@gneto.com> Date: Sun, 11 Jan 2004 14:52:43 +0100 From: Martin Nilsson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6b) Gecko/20031212 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Assembler coding help needed. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 13:52:41 -0000 I'm trying to find out why I can't boot 5.2 from USB CDROM on Supermicro motherboards. (I have an old Gateway P3 that can!). I've found out that that only 0x20 of 0x4c sectors of the loader are read in and it therfor traps when executed. (read is only called once). My last attempt at programming x86 assembler was ~15years ago so I'm a bit rusty :-) The below loop from cdboot.s is what I'm having problem understanding, how can this fail on one box but not on another? # # Load the binary into the buffer. Due to real mode addressing limitations # we have to read it in in 64k chunks. # mov DIR_SIZE(%bx),%eax # Read file length add $SECTOR_SIZE-1,%eax # Convert length to sectors shr $11,%eax %eax is 0x4c here on both machines! cmp $BUFFER_LEN,%eax jbe load_sizeok mov $msg_load2big,%si # Error message call error load_sizeok: movzbw %al,%cx # Num sectors to read mov DIR_EXTENT(%bx),%eax # Load extent xor %edx,%edx mov DIR_EA_LEN(%bx),%dl add %edx,%eax # Skip extended mov $MEM_READ_BUFFER,%ebx # Read into the buffer load_loop: mov %cl,%dh cmp $MAX_READ_SEC,%cl # Truncate to max read size jbe load_notrunc mov $MAX_READ_SEC,%dh load_notrunc: sub %dh,%cl # Update count push %eax # Save call read # Read it in pop %eax # Restore add $MAX_READ_SEC,%eax # Update LBA add $MAX_READ,%ebx # Update dest addr jcxz load_done # Done? jmp load_loop # Keep going load_done: From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 07:35:42 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D958416A4D0 for ; Sun, 11 Jan 2004 07:35:42 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2A1F43D5C for ; Sun, 11 Jan 2004 07:35:36 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 6A88565213; Sun, 11 Jan 2004 15:35:35 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 49447-08; Sun, 11 Jan 2004 15:35:34 +0000 (GMT) Received: from saboteur.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id CDFEC6520C; Sun, 11 Jan 2004 15:35:34 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id E0F952E; Sun, 11 Jan 2004 15:35:33 +0000 (GMT) Date: Sun, 11 Jan 2004 15:35:33 +0000 From: Bruce M Simpson To: YACINE GHANJAOUI <001VA36979@stud.alakhawayn.ma> Message-ID: <20040111153533.GH17555@saboteur.dek.spc.org> Mail-Followup-To: YACINE GHANJAOUI <001VA36979@stud.alakhawayn.ma>, freebsd-hackers@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: freebsd-hackers@freebsd.org Subject: Re: freebsd-hackers Digest, Vol 42, Issue 6 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 15:35:43 -0000 On Fri, Jan 09, 2004 at 03:57:07PM +0000, YACINE GHANJAOUI wrote: > when trying to intercept UDP packet after changing the protocol number > from 17 to a user one (99) in the ip_input.c file. when trying to > regenrate the packet after inserting some bit errors an error message > appears in the reciever telling that The udp checksum is incorrect even if > i just change the ip Header. > What do you think the problem is? You didn't read how UDP checksums were calculated, did you? Here is one free clue: Look at the definition of in_pseudo() and where it is used. Use the source. look! BMS From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 07:58:09 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 484DE16A4CE; Sun, 11 Jan 2004 07:58:09 -0800 (PST) Received: from milla.ask33.net (milla.ask33.net [217.197.166.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id C642343D48; Sun, 11 Jan 2004 07:58:04 -0800 (PST) (envelope-from nick@milla.ask33.net) Received: by milla.ask33.net (Postfix, from userid 1001) id A816B3ABB53; Sun, 11 Jan 2004 16:58:42 +0100 (CET) Date: Sun, 11 Jan 2004 16:58:42 +0100 From: Pawel Jakub Dawidek To: freebsd-hackers@freebsd.org Message-ID: <20040111155842.GB74246@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="veXX9dWIonWZEC6h" Content-Disposition: inline X-PGP-Key-URL: http://garage.freebsd.pl/jules.asc X-OS: FreeBSD 4.8-RELEASE-p13 i386 X-URL: http://garage.freebsd.pl User-Agent: Mutt/1.5.1i cc: phk@freebsd.org Subject: MD(4) cleanups and unload lesson. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 15:58:09 -0000 --veXX9dWIonWZEC6h Content-Type: multipart/mixed; boundary="w7PDEPdKQumQfZlR" Content-Disposition: inline --w7PDEPdKQumQfZlR Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello hackers... With attached patch unloading md(4) module is possible. It also cleans up big part of code according to style(9). Patch is also avaliable at: http://garage.freebsd.pl/patches/md.c.patch --=20 Pawel Jakub Dawidek pawel@dawidek.net UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net --w7PDEPdKQumQfZlR Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: attachment; filename="md.c.patch" Content-Transfer-Encoding: quoted-printable With this patch it is possible to unload md.ko module and it contains a lot of cleanups (style(9)) and simplifies. --- md.c.orig Sun Dec 28 11:12:22 2003 +++ md.c Sun Jan 11 16:41:23 2004 @@ -98,7 +98,7 @@ static MALLOC_DEFINE(M_MD, "MD disk", "Memory Disk"); static MALLOC_DEFINE(M_MDSECT, "MD sectors", "Memory Disk Sectors"); =20 -static int md_debug; +static int md_debug =3D 0; SYSCTL_INT(_debug, OID_AUTO, mddebug, CTLFLAG_RW, &md_debug, 0, ""); =20 #if defined(MD_ROOT) && defined(MD_ROOT_SIZE) @@ -107,13 +107,16 @@ static u_char end_mfs_root[] __unused =3D "MFS Filesystem had better STOP = here"; #endif =20 -static g_init_t md_drvinit; =20 static int mdrootready; static int mdunits; static dev_t status_dev =3D 0; =20 + static d_ioctl_t mdctlioctl; +static g_init_t md_drvinit; +static g_fini_t md_drvfini; +static g_ctl_destroy_geom_t md_destroy_geom; =20 static struct cdevsw mdctl_cdevsw =3D { .d_ioctl =3D mdctlioctl, @@ -121,6 +124,14 @@ }; =20 =20 +struct g_class g_md_class =3D { + .name =3D "MD", + .init =3D md_drvinit, + .fini =3D md_drvfini, + .destroy_geom =3D md_destroy_geom, +}; + + static LIST_HEAD(, md_s) md_softc_list =3D LIST_HEAD_INITIALIZER(&md_softc= _list); =20 #define NINDIR (PAGE_SIZE / sizeof(uintptr_t)) @@ -168,7 +179,14 @@ vm_object_t object; }; =20 -static int mddestroy(struct md_s *sc, struct thread *td); +struct md_tmp { + int unit; + int error; +}; + + +static void mddestroy(struct md_s *sc); + =20 static struct indir * new_indir(u_int shift) @@ -178,8 +196,8 @@ ip =3D malloc(sizeof *ip, M_MD, M_NOWAIT | M_ZERO); if (ip =3D=3D NULL) return (NULL); - ip->array =3D malloc(sizeof(uintptr_t) * NINDIR, - M_MDSECT, M_NOWAIT | M_ZERO); + ip->array =3D malloc(sizeof(uintptr_t) * NINDIR, M_MDSECT, + M_NOWAIT | M_ZERO); if (ip->array =3D=3D NULL) { free(ip, M_MD); return (NULL); @@ -240,8 +258,8 @@ * too much space for ip->array in here. */ ip =3D malloc(sizeof *ip, M_MD, M_WAITOK | M_ZERO); - ip->array =3D malloc(sizeof(uintptr_t) * NINDIR, - M_MDSECT, M_WAITOK | M_ZERO); + ip->array =3D malloc(sizeof(uintptr_t) * NINDIR, M_MDSECT, + M_WAITOK | M_ZERO); ip->total =3D NINDIR; ip->shift =3D layer * nshift; return (ip); @@ -292,7 +310,7 @@ cip =3D ip; for (;;) { lip[li++] =3D cip; - if (cip->shift) { + if (cip->shift > 0) { idx =3D (offset >> cip->shift) & NMASK; up =3D cip->array[idx]; if (up !=3D 0) { @@ -335,12 +353,6 @@ return (0); } =20 - -struct g_class g_md_class =3D { - .name =3D "MD", - .init =3D md_drvinit, -}; - static int g_md_access(struct g_provider *pp, int r, int w, int e) { @@ -352,11 +364,10 @@ r +=3D pp->acr; w +=3D pp->acw; e +=3D pp->ace; - if ((pp->acr + pp->acw + pp->ace) =3D=3D 0 && (r + w + e) > 0) { + if ((pp->acr + pp->acw + pp->ace) =3D=3D 0 && (r + w + e) > 0) sc->opencount =3D 1; - } else if ((pp->acr + pp->acw + pp->ace) > 0 && (r + w + e) =3D=3D 0) { + else if ((pp->acr + pp->acw + pp->ace) > 0 && (r + w + e) =3D=3D 0) sc->opencount =3D 0; - } return (0); } =20 @@ -376,9 +387,6 @@ wakeup(sc); } =20 -DECLARE_GEOM_CLASS(g_md_class, g_md); - - static int mdstart_malloc(struct md_s *sc, struct bio *bp) { @@ -391,7 +399,7 @@ secno =3D bp->bio_pblkno; dst =3D bp->bio_data; error =3D 0; - while (nsec--) { + while (nsec-- > 0) { osp =3D s_read(sc->indir, secno); if (bp->bio_cmd =3D=3D BIO_DELETE) { if (osp !=3D 0) @@ -406,7 +414,7 @@ bcopy((void *)osp, dst, sc->secsize); osp =3D 0; } else if (bp->bio_cmd =3D=3D BIO_WRITE) { - if (sc->flags & MD_COMPRESS) { + if ((sc->flags & MD_COMPRESS) !=3D 0) { uc =3D dst[0]; for (i =3D 1; i < sc->secsize; i++) if (dst[i] !=3D uc) @@ -420,8 +428,8 @@ error =3D s_write(sc->indir, secno, uc); } else { if (osp <=3D 255) { - sp =3D (uintptr_t) uma_zalloc( - sc->uma, M_NOWAIT); + sp =3D (uintptr_t)uma_zalloc(sc->uma, + M_NOWAIT); if (sp =3D=3D 0) { error =3D ENOSPC; break; @@ -438,7 +446,7 @@ } if (osp > 255) uma_zfree(sc->uma, (void*)osp); - if (error) + if (error !=3D 0) break; secno++; dst +=3D sc->secsize; @@ -452,10 +460,13 @@ { =20 if (bp->bio_cmd =3D=3D BIO_DELETE) { + /* Nothing here. */ } else if (bp->bio_cmd =3D=3D BIO_READ) { - bcopy(sc->pl_ptr + (bp->bio_pblkno << DEV_BSHIFT), bp->bio_data, bp->bio= _bcount); + bcopy(sc->pl_ptr + (bp->bio_pblkno << DEV_BSHIFT), bp->bio_data, + bp->bio_bcount); } else { - bcopy(bp->bio_data, sc->pl_ptr + (bp->bio_pblkno << DEV_BSHIFT), bp->bio= _bcount); + bcopy(bp->bio_data, sc->pl_ptr + (bp->bio_pblkno << DEV_BSHIFT), + bp->bio_bcount); } bp->bio_resid =3D 0; return (0); @@ -485,9 +496,9 @@ auio.uio_iovcnt =3D 1; auio.uio_offset =3D (vm_ooffset_t)bp->bio_pblkno * sc->secsize; auio.uio_segflg =3D UIO_SYSSPACE; - if(bp->bio_cmd =3D=3D BIO_READ) + if (bp->bio_cmd =3D=3D BIO_READ) auio.uio_rw =3D UIO_READ; - else if(bp->bio_cmd =3D=3D BIO_WRITE) + else if (bp->bio_cmd =3D=3D BIO_WRITE) auio.uio_rw =3D UIO_WRITE; else panic("wrong BIO_OP in mdstart_vnode"); @@ -517,62 +528,57 @@ static int mdstart_swap(struct md_s *sc, struct bio *bp) { - { - int i, o, rv; - vm_page_t m; - u_char *p; - vm_offset_t kva; - - p =3D bp->bio_data; - o =3D bp->bio_offset / sc->secsize; - mtx_lock(&Giant); - kva =3D kmem_alloc_nofault(kernel_map, sc->secsize); - =09 - VM_OBJECT_LOCK(sc->object); - vm_object_pip_add(sc->object, 1); - for (i =3D 0; i < bp->bio_length / sc->secsize; i++) { - m =3D vm_page_grab(sc->object, i + o, - VM_ALLOC_NORMAL|VM_ALLOC_RETRY); - pmap_qenter(kva, &m, 1); - if (bp->bio_cmd =3D=3D BIO_READ) { - if (m->valid !=3D VM_PAGE_BITS_ALL) { - rv =3D vm_pager_get_pages(sc->object, - &m, 1, 0); - } - bcopy((void *)kva, p, sc->secsize); - } else if (bp->bio_cmd =3D=3D BIO_WRITE) { - bcopy(p, (void *)kva, sc->secsize); - m->valid =3D VM_PAGE_BITS_ALL; + int i, o, rv; + vm_page_t m; + u_char *p; + vm_offset_t kva; + + p =3D bp->bio_data; + o =3D bp->bio_offset / sc->secsize; + mtx_lock(&Giant); + kva =3D kmem_alloc_nofault(kernel_map, sc->secsize); + + VM_OBJECT_LOCK(sc->object); + vm_object_pip_add(sc->object, 1); + for (i =3D 0; i < bp->bio_length / sc->secsize; i++) { + m =3D vm_page_grab(sc->object, i + o, + VM_ALLOC_NORMAL | VM_ALLOC_RETRY); + pmap_qenter(kva, &m, 1); + if (bp->bio_cmd =3D=3D BIO_READ) { + if (m->valid !=3D VM_PAGE_BITS_ALL) + rv =3D vm_pager_get_pages(sc->object, &m, 1, 0); + bcopy((void *)kva, p, sc->secsize); + } else if (bp->bio_cmd =3D=3D BIO_WRITE) { + bcopy(p, (void *)kva, sc->secsize); + m->valid =3D VM_PAGE_BITS_ALL; #if 0 - } else if (bp->bio_cmd =3D=3D BIO_DELETE) { - bzero((void *)kva, sc->secsize); - vm_page_dirty(m); - m->valid =3D VM_PAGE_BITS_ALL; + } else if (bp->bio_cmd =3D=3D BIO_DELETE) { + bzero((void *)kva, sc->secsize); + vm_page_dirty(m); + m->valid =3D VM_PAGE_BITS_ALL; #endif - }=20 - pmap_qremove(kva, 1); - vm_page_lock_queues(); - vm_page_wakeup(m); - vm_page_activate(m); - if (bp->bio_cmd =3D=3D BIO_WRITE) { - vm_page_dirty(m); - } - vm_page_unlock_queues(); - p +=3D sc->secsize; + }=20 + pmap_qremove(kva, 1); + vm_page_lock_queues(); + vm_page_wakeup(m); + vm_page_activate(m); + if (bp->bio_cmd =3D=3D BIO_WRITE) + vm_page_dirty(m); + vm_page_unlock_queues(); + p +=3D sc->secsize; #if 0 if (bootverbose || o < 17) printf("wire_count %d busy %d flags %x hold_count %d act_count %d queue %d= valid %d dirty %d @ %d\n", m->wire_count, m->busy,=20 m->flags, m->hold_count, m->act_count, m->queue, m->valid, m->dirty, o= + i); #endif - } - vm_object_pip_subtract(sc->object, 1); - vm_object_set_writeable_dirty(sc->object); - VM_OBJECT_UNLOCK(sc->object); - kmem_free(kernel_map, kva, sc->secsize); - mtx_unlock(&Giant); - return (0); } + vm_object_pip_subtract(sc->object, 1); + vm_object_set_writeable_dirty(sc->object); + VM_OBJECT_UNLOCK(sc->object); + kmem_free(kernel_map, kva, sc->secsize); + mtx_unlock(&Giant); + return (0); } =20 static void @@ -601,10 +607,10 @@ for (;;) { mtx_lock(&sc->queue_mtx); bp =3D bioq_first(&sc->bio_queue); - if (bp) + if (bp !=3D NULL) bioq_remove(&sc->bio_queue, bp); - if (!bp) { - if (sc->flags & MD_SHUTDOWN) { + else { + if ((sc->flags & MD_SHUTDOWN) !=3D 0) { mtx_unlock(&sc->queue_mtx); sc->procp =3D NULL; wakeup(&sc->procp); @@ -617,14 +623,17 @@ } mtx_unlock(&sc->queue_mtx); if (bp->bio_cmd =3D=3D BIO_GETATTR) { - if (sc->fwsectors && sc->fwheads && - (g_handleattr_int(bp, "GEOM::fwsectors", - sc->fwsectors) || - g_handleattr_int(bp, "GEOM::fwheads", - sc->fwheads))) - error =3D -1; - else - error =3D EOPNOTSUPP; + if (sc->fwsectors > 0 && sc->fwheads > 0) { + if (g_handleattr_int(bp, "GEOM::fwsectors", + sc->fwsectors)) { + continue; + } + if (g_handleattr_int(bp, "GEOM::fwheads", + sc->fwheads)) { + continue; + } + } + error =3D EOPNOTSUPP; } else { switch (sc->type) { case MD_MALLOC: @@ -640,15 +649,12 @@ error =3D mdstart_swap(sc, bp); break; default: - panic("Impossible md(type)"); + panic("impossible md type (%d)", sc->type); break; } } - - if (error !=3D -1) { - bp->bio_completed =3D bp->bio_length; - g_io_deliver(bp, error); - } + bp->bio_completed =3D bp->bio_length; + g_io_deliver(bp, error); } } =20 @@ -689,7 +695,7 @@ mtx_init(&sc->queue_mtx, "md bio queue", NULL, MTX_DEF); sprintf(sc->name, "md%d", unit); error =3D kthread_create(md_kthread, sc, &sc->procp, 0, 0,"%s", sc->name); - if (error) { + if (error !=3D 0) { free(sc, M_MD); return (NULL); } @@ -701,7 +707,6 @@ static void mdinit(struct md_s *sc) { - struct g_geom *gp; struct g_provider *pp; =20 @@ -768,14 +773,14 @@ error =3D 0; if (mdio->md_size =3D=3D 0) return (EINVAL); - if (mdio->md_options & ~(MD_AUTOUNIT | MD_COMPRESS | MD_RESERVE)) + if ((mdio->md_options & ~(MD_AUTOUNIT | MD_COMPRESS | MD_RESERVE)) !=3D 0) return (EINVAL); if (mdio->md_secsize !=3D 0 && !powerof2(mdio->md_secsize)) return (EINVAL); /* Compression doesn't make sense if we have reserved space */ - if (mdio->md_options & MD_RESERVE) + if ((mdio->md_options & MD_RESERVE) !=3D 0) mdio->md_options &=3D ~MD_COMPRESS; - if (mdio->md_options & MD_AUTOUNIT) { + if ((mdio->md_options & MD_AUTOUNIT) !=3D 0) { sc =3D mdnew(-1); if (sc =3D=3D NULL) return (ENOMEM); @@ -800,23 +805,23 @@ sc->indir =3D dimension(sc->nsect); sc->uma =3D uma_zcreate(sc->name, sc->secsize, NULL, NULL, NULL, NULL, 0x1ff, 0); - if (mdio->md_options & MD_RESERVE) { + if ((mdio->md_options & MD_RESERVE) !=3D 0) { for (u =3D 0; u < sc->nsect; u++) { - sp =3D (uintptr_t) uma_zalloc(sc->uma, M_NOWAIT | M_ZERO); + sp =3D (uintptr_t)uma_zalloc(sc->uma, M_NOWAIT | M_ZERO); if (sp !=3D 0) error =3D s_write(sc->indir, u, sp); else error =3D ENOMEM; - if (error) + if (error !=3D 0) break; } } - if (error) { - mddestroy(sc, NULL); + if (error !=3D 0) { + mddestroy(sc); return (error); } mdinit(sc); - if (!(mdio->md_options & MD_RESERVE)) + if ((mdio->md_options & MD_RESERVE) =3D=3D 0) sc->pp->flags |=3D G_PF_CANDELETE; return (0); } @@ -840,7 +845,7 @@ * Horrible kludge to establish credentials for NFS XXX. */ =20 - if (sc->vnode) { + if (sc->vnode !=3D NULL) { struct uio auio; struct iovec aiov; =20 @@ -874,23 +879,26 @@ flags =3D FREAD|FWRITE; NDINIT(&nd, LOOKUP, FOLLOW, UIO_USERSPACE, mdio->md_file, td); error =3D vn_open(&nd, &flags, 0, -1); - if (error) { + if (error !=3D 0) { if (error !=3D EACCES && error !=3D EPERM && error !=3D EROFS) return (error); flags &=3D ~FWRITE; NDINIT(&nd, LOOKUP, FOLLOW, UIO_USERSPACE, mdio->md_file, td); error =3D vn_open(&nd, &flags, 0, -1); - if (error) + if (error !=3D 0) return (error); } NDFREE(&nd, NDF_ONLY_PNBUF); - if (nd.ni_vp->v_type !=3D VREG || - (error =3D VOP_GETATTR(nd.ni_vp, &vattr, td->td_ucred, td))) { - VOP_UNLOCK(nd.ni_vp, 0, td); - (void) vn_close(nd.ni_vp, flags, td->td_ucred, td); - return (error ? error : EINVAL); - } VOP_UNLOCK(nd.ni_vp, 0, td); + if (nd.ni_vp->v_type !=3D VREG) { + vn_close(nd.ni_vp, flags, td->td_ucred, td); + return (EINVAL); + } + error =3D VOP_GETATTR(nd.ni_vp, &vattr, td->td_ucred, td); + if (error !=3D 0) { + vn_close(nd.ni_vp, flags, td->td_ucred, td); + return (error); + } =20 if (mdio->md_options & MD_AUTOUNIT) { sc =3D mdnew(-1); @@ -899,13 +907,13 @@ sc =3D mdnew(mdio->md_unit); } if (sc =3D=3D NULL) { - (void) vn_close(nd.ni_vp, flags, td->td_ucred, td); + vn_close(nd.ni_vp, flags, td->td_ucred, td); return (EBUSY); } =20 sc->type =3D MD_VNODE; sc->flags =3D mdio->md_options & MD_FORCE; - if (!(flags & FWRITE)) + if ((flags & FWRITE) =3D=3D 0) sc->flags |=3D MD_READONLY; sc->secsize =3D DEV_BSIZE; sc->vnode =3D nd.ni_vp; @@ -913,17 +921,17 @@ /* * If the size is specified, override the file attributes. */ - if (mdio->md_size) + if (mdio->md_size > 0) sc->nsect =3D mdio->md_size; else sc->nsect =3D vattr.va_size / sc->secsize; /* XXX: round up ? */ if (sc->nsect =3D=3D 0) { - mddestroy(sc, td); + mddestroy(sc); return (EINVAL); } error =3D mdsetcred(sc, td->td_ucred); - if (error) { - mddestroy(sc, td); + if (error !=3D 0) { + mddestroy(sc); return (error); } mdinit(sc); @@ -931,23 +939,15 @@ } =20 static void -md_zapit(void *p, int cancel) -{ - if (cancel) - return; - g_wither_geom(p, ENXIO); -} - -static int -mddestroy(struct md_s *sc, struct thread *td) +mddestroy(struct md_s *sc) { =20 GIANT_REQUIRED; =20 mtx_destroy(&sc->queue_mtx); - if (sc->gp) { + if (sc->gp !=3D NULL) { sc->gp->softc =3D NULL; - g_waitfor_event(md_zapit, sc->gp, M_WAITOK, sc->gp, NULL); + g_wither_geom(sc->gp, ENXIO); sc->gp =3D NULL; sc->pp =3D NULL; } @@ -955,24 +955,27 @@ wakeup(sc); while (sc->procp !=3D NULL) tsleep(&sc->procp, PRIBIO, "mddestroy", hz / 10); - if (sc->vnode !=3D NULL) - (void)vn_close(sc->vnode, sc->flags & MD_READONLY ? - FREAD : (FREAD|FWRITE), sc->cred, td); + if (sc->vnode !=3D NULL) { + int flags; + + flags =3D FREAD; + if ((sc->flags & MD_READONLY) =3D=3D 0) + flags |=3D FWRITE; + vn_close(sc->vnode, flags, sc->cred, curthread); + } if (sc->cred !=3D NULL) crfree(sc->cred); - if (sc->object !=3D NULL) { + if (sc->object !=3D NULL) vm_object_deallocate(sc->object); - } - if (sc->indir) + if (sc->indir !=3D NULL) destroy_indir(sc, sc->indir); - if (sc->uma) + if (sc->uma !=3D NULL) uma_zdestroy(sc->uma); =20 /* XXX: LOCK(unique unit numbers) */ LIST_REMOVE(sc, list); /* XXX: UNLOCK(unique unit numbers) */ free(sc, M_MD); - return (0); } =20 static int @@ -1000,7 +1003,7 @@ */ =20 if (mdio->md_size =3D=3D 0) { - mddestroy(sc, td); + mddestroy(sc); return (EDOM); } =20 @@ -1015,45 +1018,58 @@ =20 sc->secsize =3D PAGE_SIZE; sc->nsect =3D mdio->md_size / (PAGE_SIZE / DEV_BSIZE); - sc->object =3D vm_pager_allocate(OBJT_SWAP, NULL, sc->secsize * (vm_offse= t_t)sc->nsect, VM_PROT_DEFAULT, 0); + sc->object =3D vm_pager_allocate(OBJT_SWAP, NULL, + sc->secsize * (vm_offset_t)sc->nsect, VM_PROT_DEFAULT, 0); sc->flags =3D mdio->md_options & MD_FORCE; - if (mdio->md_options & MD_RESERVE) { + if ((mdio->md_options & MD_RESERVE) !=3D 0) { if (swap_pager_reserve(sc->object, 0, sc->nsect) < 0) { vm_object_deallocate(sc->object); sc->object =3D NULL; - mddestroy(sc, td); + mddestroy(sc); return (EDOM); } } error =3D mdsetcred(sc, td->td_ucred); - if (error) { - mddestroy(sc, td); + if (error !=3D 0) { + mddestroy(sc); return (error); } mdinit(sc); - if (!(mdio->md_options & MD_RESERVE)) + if ((mdio->md_options & MD_RESERVE) =3D=3D 0) sc->pp->flags |=3D G_PF_CANDELETE; return (0); } =20 -static int -mddetach(int unit, struct thread *td) +static void +mddetach(void *p, int cancel) { struct md_s *sc; + struct md_tmp *tmp; =20 - sc =3D mdfind(unit); - if (sc =3D=3D NULL) - return (ENOENT); - if (sc->opencount !=3D 0 && !(sc->flags & MD_FORCE)) - return (EBUSY); + if (cancel !=3D 0) + return; + tmp =3D p; + + sc =3D mdfind(tmp->unit); + if (sc =3D=3D NULL) { + tmp->error =3D ENOENT; + return; + } + if (sc->opencount !=3D 0 && (sc->flags & MD_FORCE) =3D=3D 0) { + tmp->error =3D EBUSY; + return; + } switch(sc->type) { case MD_VNODE: case MD_SWAP: case MD_MALLOC: case MD_PRELOAD: - return (mddestroy(sc, td)); + tmp->error =3D 0; + mddestroy(sc); + return; default: - return (EOPNOTSUPP); + tmp->error =3D EOPNOTSUPP; + return; } } =20 @@ -1064,9 +1080,10 @@ struct md_s *sc; int i; =20 - if (md_debug) - printf("mdctlioctl(%s %lx %p %x %p)\n", - devtoname(dev), cmd, addr, flags, td); + if (md_debug > 0) { + printf("mdctlioctl(%s %lx %p %x %p)\n", devtoname(dev), cmd, + addr, flags, td); + } =20 /* * We assert the version number in the individual ioctl @@ -1092,13 +1109,25 @@ default: return (EINVAL); } - case MDIOCDETACH: + case MDIOCDETACH: { + struct md_tmp *tmp; + int error; + if (mdio->md_version !=3D MDIOVERSION) return (EINVAL); if (mdio->md_file !=3D NULL || mdio->md_size !=3D 0 || - mdio->md_options !=3D 0) + mdio->md_options !=3D 0) { return (EINVAL); - return (mddetach(mdio->md_unit, td)); + } + + tmp =3D malloc(sizeof(*tmp), M_TEMP, M_WAITOK | M_ZERO); + tmp->unit =3D mdio->md_unit; + g_waitfor_event(mddetach, tmp, M_WAITOK, tmp, NULL); + error =3D tmp->error; + free(tmp, M_TEMP); + + return (error); + } case MDIOCQUERY: if (mdio->md_version !=3D MDIOVERSION) return (EINVAL); @@ -1162,7 +1191,6 @@ static void md_drvinit(struct g_class *mp __unused) { - caddr_t mod; caddr_t c; u_char *ptr, *name, *type; @@ -1180,8 +1208,10 @@ continue; if (type =3D=3D NULL) continue; - if (strcmp(type, "md_image") && strcmp(type, "mfs_root")) + if (strcmp(type, "md_image") !=3D 0 && + strcmp(type, "mfs_root") !=3D 0) { continue; + } c =3D preload_search_info(mod, MODINFO_ADDR); ptr =3D *(u_char **)c; c =3D preload_search_info(mod, MODINFO_SIZE); @@ -1195,39 +1225,37 @@ g_topology_lock(); } =20 +static void +md_drvfini(struct g_class *mp __unused) +{ + + KASSERT(LIST_EMPTY(&md_softc_list), ("device list isn't empty")); + + if (status_dev) + destroy_dev(status_dev); + status_dev =3D 0; +} + static int -md_modevent(module_t mod, int type, void *data) +md_destroy_geom(struct gctl_req *req, struct g_class *mp, struct g_geom *g= p) { - int error; struct md_s *sc; + struct md_tmp tmp; =20 - switch (type) { - case MOD_LOAD: - break; - case MOD_UNLOAD: - LIST_FOREACH(sc, &md_softc_list, list) { - error =3D mddetach(sc->unit, curthread); - if (error !=3D 0) - return (error); - } - if (status_dev) - destroy_dev(status_dev); - status_dev =3D 0; - break; - default: - break; - } - return (0); + g_topology_assert(); + sc =3D gp->softc; + + tmp.unit =3D sc->unit; + tmp.error =3D 0; + mtx_lock(&Giant); + mddetach(&tmp, 0); + mtx_unlock(&Giant); + + return (tmp.error); } =20 -static moduledata_t md_mod =3D { - MD_NAME, - md_modevent, - NULL -}; -DECLARE_MODULE(md, md_mod, SI_SUB_DRIVERS, SI_ORDER_MIDDLE); +DECLARE_GEOM_CLASS(g_md_class, md); MODULE_VERSION(md, MD_MODVER); - =20 #ifdef MD_ROOT static void --w7PDEPdKQumQfZlR-- --veXX9dWIonWZEC6h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iQCVAwUBQAFysj/PhmMH/Mf1AQGh/gQAgWKQEfDuK4RVR9SQ8MIO9LMFYrkh98AO 0FXT31bkjmbVxQdo/aPBP+pnCeWZCgx9G+n1hKObFm1vFzWIrY9HiblcMkZd7BKs sGn9y82uEEmZF6BS+npLCxzLOfkvsA3MluNnuyRmQEKYgxv2OovHBp92u+x3KDQL W/dQ1ld/yw0= =Kha9 -----END PGP SIGNATURE----- --veXX9dWIonWZEC6h-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 08:18:42 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C34316A4CE for ; Sun, 11 Jan 2004 08:18:42 -0800 (PST) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FC8143D45 for ; Sun, 11 Jan 2004 08:18:40 -0800 (PST) (envelope-from marcov@stack.nl) Received: from toad.stack.nl (zen.stack.nl [2001:610:1108:5010::130]) by mailhost.stack.nl (Postfix) with ESMTP id 4001775F#7DAE81F00D for ; Sun, 11 Jan 2004 17:18:39 +0100 (CET) Received: by toad.stack.nl (Postfix, from userid 816) id 53EC788; Sun, 11 Jan 2004 17:18:39 +0100 (CET) In-Reply-To: <400108FC.9010008@iconoplex.co.uk> "from Paul Robinson at Jan 11, 2004 08:27:40 am" To: freebsd-hackers@freebsd.org Date: Sun, 11 Jan 2004 17:18:39 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20040111161839.53EC788@toad.stack.nl> From: marcov@stack.nl (Marco van de Voort) Subject: Re: Discussion on the future of floppies in 5.x and 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 16:18:42 -0000 > I also don't think it's the issue that needs to be dealt with - > distribution is much, much, MUCH bigger an issue than "shall we get rid > of floppies"? I sent this to the list before, but it got ignored, so > I'll send it again, where Jordan points out we have bigger issues to > deal with when discussing the "floppy disk problem" whilst discussing > libh:- (http://rtp1.slowblink.com/~libh/sysinstall2/improvements.html): > > "As I mentioned in Section 2.3, one of the more annoying problems with > FreeBSD's current distribution format is the dividing line between > distributions and packages. There should really only be one type of > "distribution format" and, of course, it should be the package (There Can > Be Only One). Achieving this means we're first going to have to grapple > with several problems, however: > > First, eliminating the distribution format means either teaching the > package tools how to deal with a split archive format (they currently do > not) or divorcing ourselves forever from floppies as a distribution > medium. This is an issue which would seem an easy one to decide but > invariably becomes Highly Religious(tm) every time it's brought up. In > some dark corner of the world, there always seems to be somebody still > installing FreeBSD via floppies and even some of the fortune 500 folks can > cite FreeBSD success stories where they resurrected some old 386 box (with > only a floppy drive and no networking/CD/...) and turned it into the star > of the office/saved the company/etc etc. That's not to say we can't still > bite that particular bullet, just that it's not a decision which will go > down easily with everyone and should be well thought-out." > > And I have to say, I agree. If abondoning floppies is part of some > well-thought-out and well-planned package management strategy, I'm all for > it. Otherwise, let sleeping dogs lie? It isn't as far as I can understand from that link. JKH is talking about doing floppy only install (....some old 386 box (with only a floppy drive and no networking/CD/...) and turned it into the star of the office/saved the company/etc etc...) not loading an installation kernel and /stand from floppy and then transfer to network/cd later. This because when then base/packages need to fit on floppy. This isn't necessary for the current two-flop, then CD install which is discussed now. P.s. for the record, I prefer Slackware's approach to floppy booting. Multiple cut down bootsets (SCSI, NET etc) with the ability to simply extract extra kernel modules from CD to a floppy (on a separate machine) and load them from floppy while still in the initial system ramdisk (before mounting CD). The loading/mounting etc must be done by hand, no extra new functionality required. Maybe the basic idea should be to forget the equivalence of floppy and cd boot, and deliver a set of kernel modules on CD, and a few basic boot/root floppies, and for the rest let users create their own custom driver discs, and do some extra work to keep their floppy boot running. That ends the one boot/root for all idea, but is maybe more flexible, ( didn't have to make something with custom kernel to install my Proliant 1500, but only select the right kernel disc and copy some extra kernel moduless to an empty flop) and at the same time decrease release engineering on the floppies. I think this is a good compromise: Keep floppy option open, but shift some burden to the users. From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 08:43:05 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16FA616A4CE for ; Sun, 11 Jan 2004 08:43:05 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A736A43D5E for ; Sun, 11 Jan 2004 08:43:02 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i0BGfIUd090101; Sun, 11 Jan 2004 11:41:18 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i0BGfHMM090098; Sun, 11 Jan 2004 11:41:18 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 11 Jan 2004 11:41:17 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Danny Braniss In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org Subject: Re: diskless problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 16:43:05 -0000 On Sun, 11 Jan 2004, Danny Braniss wrote: > while the subject is being revived, there are some changes/additions I > made to libstand/bootp.c, it exports all the dhcp tags so that they are > available to rc.diskless? or rc.d/initdiskless via kenv check out > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/diskless-boot/ > > these are a bit date, but the uptodated stuff is actively being used > here, so if there is some interest i could update it. Sounds very interesting indeed. Could you: (1) Update it to bootp.c:1.5; this just removed 'register', and it looks like you've already done that. (2) Restore the original file style -- right now, it's a very hard to read diff because you use different tabbing, function prototypes, etc, so it's hard to isolate and read the changes. There's probably some room for style convergence (new function prototypes), but we have a long-standing tradition of committing style and functional chaanges separately so cvs diff is maximally useful between revisions. It looks like the main difference is that you use four space tabs, and the original file uses real tab characters. Then if you could file a PR and drop me the PR number by e-mail, that would be great. I can do the style stuff if necessary, but I figured since you're much more familiar with the changes, it might not be a bad idea if you did it :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 09:42:03 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D13C16A4CE for ; Sun, 11 Jan 2004 09:42:03 -0800 (PST) Received: from crf-consulting.co.uk (82-44-220-218.cable.ubr10.haye.blueyonder.co.uk [82.44.220.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12F8B43D39 for ; Sun, 11 Jan 2004 09:41:59 -0800 (PST) (envelope-from nik@freebsd.org) Received: from [192.168.1.112] ([192.168.1.112])i0BHfuaY050443; Sun, 11 Jan 2004 17:41:56 GMT (envelope-from nik@freebsd.org) In-Reply-To: <20040108143934.GA51446@ussenterprise.ufp.org> References: <20040107235737.I32227@pooker.samsco.home> <20040108143934.GA51446@ussenterprise.ufp.org> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2-1046429501" Message-Id: <6F6FD8C6-445D-11D8-BAA5-000393863D48@freebsd.org> Content-Transfer-Encoding: 7bit From: Nik Clayton Date: Sun, 11 Jan 2004 17:41:49 +0000 To: Leo Bicknell X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.609) cc: hackers@freebsd.org Subject: Re: Discussion on the future of floppies in 5.x and 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 17:42:03 -0000 --Apple-Mail-2-1046429501 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 8 Jan 2004, at 14:39, Leo Bicknell wrote: > Then, to replace the current floppy process, a new floppy installer > is created. It may or may not be based on FreeBSD, but what it > needs to be able to do is boot, load a network driver, configure > the network, and ftp the above mentioned iso into ram, and then > jump into the kernel from the iso as if it had been loaded from a > CD. Or mount the ISO image from a FAT, NTFS, UFS, or EXT2FS filesystem on a disk that's already in the machine... N --Apple-Mail-2-1046429501 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAAYrek6gHZCw343URAv9fAJ93ajL8wRG2JwVpZxkBLpVF+RRw1QCeO43R BpwtgFYCAg4X3iM4l5XsruA= =pkdR -----END PGP SIGNATURE----- --Apple-Mail-2-1046429501-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 09:48:27 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E2F516A4CE for ; Sun, 11 Jan 2004 09:48:27 -0800 (PST) Received: from tx3.oucs.ox.ac.uk (tx3.oucs.ox.ac.uk [163.1.2.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90EBD43D41 for ; Sun, 11 Jan 2004 09:48:25 -0800 (PST) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from scan3.oucs.ox.ac.uk ([163.1.2.166] helo=localhost) by tx3.oucs.ox.ac.uk with esmtp (Exim 4.20) id 1AfjhI-00060g-OW for hackers@freebsd.org; Sun, 11 Jan 2004 17:48:24 +0000 Received: from rx3.oucs.ox.ac.uk ([163.1.2.165]) by localhost (scan3.oucs.ox.ac.uk [163.1.2.166]) (amavisd-new, port 25) with ESMTP id 22635-08 for ; Sun, 11 Jan 2004 17:48:24 +0000 (GMT) Received: from gateway.wadham.ox.ac.uk ([163.1.161.253]) by rx3.oucs.ox.ac.uk with smtp (Exim 4.20) id 1AfjhI-00060c-B7 for hackers@freebsd.org; Sun, 11 Jan 2004 17:48:24 +0000 Received: (qmail 1492 invoked by uid 0); 11 Jan 2004 17:48:24 -0000 Received: from colin.percival@wadham.ox.ac.uk by gateway by uid 71 with qmail-scanner-1.16 (sweep: 2.14/3.71. spamassassin: 2.53. Clear:. Processed in 1.937797 secs); 11 Jan 2004 17:48:24 -0000 X-Qmail-Scanner-Mail-From: colin.percival@wadham.ox.ac.uk via gateway X-Qmail-Scanner: 1.16 (Clear:. Processed in 1.937797 secs) Received: from dhcp1131.wadham.ox.ac.uk (HELO piii600.wadham.ox.ac.uk) (163.1.161.131) by gateway.wadham.ox.ac.uk with SMTP; 11 Jan 2004 17:48:22 -0000 Message-Id: <6.0.1.1.1.20040111174309.04327900@imap.sfu.ca> X-Sender: cperciva@imap.sfu.ca (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sun, 11 Jan 2004 17:48:19 +0000 To: hackers@freebsd.org From: Colin Percival Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: binary files in src tree X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 17:48:27 -0000 While browsing the FreeBSD src tree, I came across a number of binary files (listed below); the regression tests are perhaps understandable, but shouldn't the rest of these files be uuencoded? contrib/groff/doc/gnu.png contrib/ipfilter/samples/ipfilter-pb.gif contrib/sendmail/libmilter/docs/figure1.jpg contrib/sendmail/libmilter/docs/figure2.jpg crypto/openssh/regress/copy.1 crypto/openssh/regress/copy.2 crypto/openssh/scard/Ssh.bin crypto/openssl/crypto/pkcs7/p7/a1 crypto/openssl/crypto/pkcs7/p7/a2 crypto/openssl/crypto/pkcs7/p7/cert.p7c crypto/openssl/crypto/pkcs7/p7/smime.p7m crypto/openssl/crypto/pkcs7/p7/smime.p7s crypto/openssl/doc/openssl_button.gif release/picobsd/tinyware/view/fbsd.png tools/regression/usr.bin/file2c/regress.in tools/regression/usr.bin/uudecode/regress.out tools/regression/usr.bin/uuencode/regress.in tools/tools/tinderbox/www/daemon.png tools/tools/tinderbox/www/valid-css.png tools/tools/tinderbox/www/valid-xhtml10.png Colin Percival From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 09:50:32 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 019E816A4CE; Sun, 11 Jan 2004 09:50:32 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AE0443D3F; Sun, 11 Jan 2004 09:50:30 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i0BHmuUd001696; Sun, 11 Jan 2004 12:48:56 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i0BHmuNI001693; Sun, 11 Jan 2004 12:48:56 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 11 Jan 2004 12:48:56 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Pawel Jakub Dawidek In-Reply-To: <20040111155842.GB74246@garage.freebsd.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: phk@freebsd.org Subject: Re: MD(4) cleanups and unload lesson. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 17:50:32 -0000 On Sun, 11 Jan 2004, Pawel Jakub Dawidek wrote: > With attached patch unloading md(4) module is possible. It also cleans > up big part of code according to style(9). Could you separate this into a functional diff and a style diff? There's a general preference to not combine them, as it means cvs diff between revisions isn't useful for identifying functional changes (i.e., reviewing for bugs when back-tracking, etc). Thanks, Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 10:20:58 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BAEF16A4CE; Sun, 11 Jan 2004 10:20:58 -0800 (PST) Received: from sizone.org (mortar.sizone.org [65.126.154.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD72E43D48; Sun, 11 Jan 2004 10:20:56 -0800 (PST) (envelope-from dgilbert@daveg.ca) Received: by sizone.org (Postfix, from userid 66) id E7D9030743; Sun, 11 Jan 2004 13:20:55 -0500 (EST) Received: by canoe.dclg.ca (Postfix, from userid 101) id C741C1D1E67; Sun, 11 Jan 2004 13:20:53 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <16385.37893.652979.822920@canoe.dclg.ca> Date: Sun, 11 Jan 2004 13:20:53 -0500 To: Scott Long In-Reply-To: <40008E4A.3060604@freebsd.org> References: <40007D14.6090205@freebsd.org> <40008E4A.3060604@freebsd.org> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: Future of RAIDFrame X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 18:20:58 -0000 >>>>> "Scott" =3D=3D Scott Long writes: Scott> Dag-Erling Sm=F8rgrav wrote: >> Scott Long writes: >>=20 >>> I started RAIDframe three years ago with the hope of bringing a >>> proven and extensible RAID stack to FreeBSD. >>=20 >>=20 >> I'm having trouble seeing what RF does that Vinum (or at least a >> properly GEOMified Vinum) can't do... >>=20 >> DES Scott> Please read the RAIDframe documents at Scott> http://www.pdl.cmu.edu/RAIDframe before you ask again. Having used Vinum is production and on home boxes for some time, and having come in contact with Raidframe on NetBSD several times, I would distill this to several points. - Vinum is fairly fragile and a number of operations have vastly non-obvious steps. - Vinum's support for different types of RAID is limited. - Vinum's abstractions don't work for more complex cases. That said, we need a strong and robust software raid. Dave. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D |David Gilbert, Independent Contractor. | Two things can only be = | |Mail: dave@daveg.ca | equal if and only if t= hey | |http://daveg.ca | are precisely opposit= e. | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3DGLO=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 10:24:18 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A134E16A4CE; Sun, 11 Jan 2004 10:24:18 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A6E843D31; Sun, 11 Jan 2004 10:24:16 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i0BIO6Ol014093; Sun, 11 Jan 2004 19:24:11 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: David Gilbert From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 11 Jan 2004 13:20:53 EST." <16385.37893.652979.822920@canoe.dclg.ca> Date: Sun, 11 Jan 2004 19:24:06 +0100 Message-ID: <14092.1073845446@critter.freebsd.dk> cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= cc: hackers@freebsd.org cc: Scott Long cc: current@freebsd.org Subject: Re: Future of RAIDFrame X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 18:24:18 -0000 In message <16385.37893.652979.822920@canoe.dclg.ca>, David Gilbert writes: >That said, we need a strong and robust software raid. And as long as we have something which "mostly work" there seems to be insufficient motivation to make that happen. Therefore my proposal to send both RF and Vinum in training camp in p4. -- 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. From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 11:02:44 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF4FD16A4CE for ; Sun, 11 Jan 2004 11:02:44 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60A6D43D45 for ; Sun, 11 Jan 2004 11:02:43 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.3) with ESMTP id i0BJ2eA7030220 for ; Sun, 11 Jan 2004 11:02:40 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i0BJ2eBv030219 for freebsd-hackers@freebsd.org; Sun, 11 Jan 2004 11:02:40 -0800 Date: Sun, 11 Jan 2004 11:02:40 -0800 From: Brooks Davis To: freebsd-hackers@freebsd.org Message-ID: <20040111190240.GA28161@Odin.AC.HMC.Edu> References: <20040108163724.GA26745@lpthe.jussieu.fr> <200401101945.27234.wes@softweyr.com> <400108FC.9010008@iconoplex.co.uk> <200401110048.52747.wes@softweyr.com> <40011237.3000409@iconoplex.co.uk> <20040111092746.GA836@pc5.i.0x5.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <20040111092746.GA836@pc5.i.0x5.de> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Subject: Re: Discussion on the future of floppies in 5.x and 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 19:02:45 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 11, 2004 at 10:27:46AM +0100, Nicolas Rachinsky wrote: > * Dag-Erling Sm=F8rgrav [2004-01-11 10:19 +0100]: > > Paul Robinson writes: > > > Understood. I just think saying "let's get rid of floppies" is > > > shooting a dog that happens to be near to hand because you don't like > > > that dog, to stretch the analogy. > >=20 > > I don't think you have any idea how difficult it is (and has been for > > a couple of years now) just to keep the install floppies alive. The > > kernel keeps growing, and the amount of "must-have" features (such as > > acpi) keeps growing, and every time the boot floppies overflow we have > > to toss out yet another driver that about a dozen people vehemently > > tell us they can't live without. >=20 > Why not split the kernel onto 2 disks? The code to do this is already > there and seems to work. And the people who think they absolutly need > disks would have to deal with 4 disks, but that would be better than > no disks. >=20 > Look at the commit history of /usr/src/lib/libstand/splitfs.c. Is > there a reason not to use it? If you could make this work such that you just stuffed GENERIC and the mfsroot onto however many floppies it takes, I think that would almost certaintly solve re's problems with floppies (i.e. if all they had to do when the kernel/mfsroot got too big was to bump a NUMFLOPPIES variable.) Sure that would suck for the floppy users, but that would put the pain in the place where it's most likely to cause someone to come up with some better. Now, who wants to give this a try? -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAAZ3PXY6L6fI4GtQRAk3qAKDJ472s6C0H/cWy+8BGaeUfsjLw1ACdHs3v wnxIAkCuRHz9an+OHcRZlJU= =Qr2l -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 11:13:11 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CECF16A4CE for ; Sun, 11 Jan 2004 11:13:11 -0800 (PST) Received: from smtp02.glenview.famvid.com (smtp02.glenview.famvid.com [66.94.212.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 358A943D64 for ; Sun, 11 Jan 2004 11:12:49 -0800 (PST) (envelope-from wgrim@siue.edu) Received: from smtp02.glenview.famvid.com ([127.0.0.1] helo=localhost) by smtp02.glenview.famvid.com with esmtp (Exim 4.20) id 1Afkyd-0007pI-Gh for freebsd-hackers@freebsd.org; Sun, 11 Jan 2004 13:10:23 -0600 Received: from smtp02.glenview.famvid.com ([127.0.0.1])port 10024) with ESMTP id 26990-06 for ; Sun, 11 Jan 2004 13:10:11 -0600 (CST) Received: from smtptemp.glenview.famvid.com ([10.253.4.20] helo=mail.famvid.com) by smtp02.glenview.famvid.com with esmtp (Exim 4.20) id 1AfkyO-0007n0-2B for freebsd-hackers@freebsd.org; Sun, 11 Jan 2004 13:10:08 -0600 Received: from 13spidialup24.famvid.com ([66.94.203.24] helo=siue.edu) by mail.famvid.com with esmtp (Exim 4.20) id 1Afl1X-00005S-CF for freebsd-hackers@freebsd.org; Sun, 11 Jan 2004 13:13:23 -0600 Message-ID: <4001A019.2030604@siue.edu> Date: Sun, 11 Jan 2004 13:12:25 -0600 From: William Grim Organization: SIUE User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <20040111161839.53EC788@toad.stack.nl> In-Reply-To: <20040111161839.53EC788@toad.stack.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at famvid.com Subject: Re: Discussion on the future of floppies in 5.x and 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: wgrim@siue.edu List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 19:13:11 -0000 Marco van de Voort wrote: >>I also don't think it's the issue that needs to be dealt with - >>distribution is much, much, MUCH bigger an issue than "shall we get rid >>of floppies"? I sent this to the list before, but it got ignored, so >>I'll send it again, where Jordan points out we have bigger issues to >>deal with when discussing the "floppy disk problem" whilst discussing >>libh:- (http://rtp1.slowblink.com/~libh/sysinstall2/improvements.html): >> >>"As I mentioned in Section 2.3, one of the more annoying problems with >>FreeBSD's current distribution format is the dividing line between >>distributions and packages. There should really only be one type of >>"distribution format" and, of course, it should be the package (There Can >>Be Only One). Achieving this means we're first going to have to grapple >>with several problems, however: >> >>First, eliminating the distribution format means either teaching the >>package tools how to deal with a split archive format (they currently do >>not) or divorcing ourselves forever from floppies as a distribution >>medium. This is an issue which would seem an easy one to decide but >>invariably becomes Highly Religious(tm) every time it's brought up. In >>some dark corner of the world, there always seems to be somebody still >>installing FreeBSD via floppies and even some of the fortune 500 folks can >>cite FreeBSD success stories where they resurrected some old 386 box (with >>only a floppy drive and no networking/CD/...) and turned it into the star >>of the office/saved the company/etc etc. That's not to say we can't still >>bite that particular bullet, just that it's not a decision which will go >>down easily with everyone and should be well thought-out." >> >>And I have to say, I agree. If abondoning floppies is part of some >>well-thought-out and well-planned package management strategy, I'm all for >>it. Otherwise, let sleeping dogs lie? >> >> > >It isn't as far as I can understand from that link. JKH is talking about >doing floppy only install > >(....some old 386 box (with only a floppy drive and no networking/CD/...) and >turned it into the star of the office/saved the company/etc etc...) > >not loading an installation kernel and /stand from floppy and then transfer to >network/cd later. > >This because when then base/packages need to fit on floppy. This isn't necessary >for the current two-flop, then CD install which is discussed now. > >P.s. for the record, I prefer Slackware's approach to floppy booting. >Multiple cut down bootsets (SCSI, NET etc) with the ability to simply >extract extra kernel modules from CD to a floppy (on a separate machine) and >load them from floppy while still in the initial system ramdisk (before >mounting CD). The loading/mounting etc must be done by hand, no extra >new functionality required. > >Maybe the basic idea should be to forget the equivalence of floppy and cd >boot, and deliver a set of kernel modules on CD, and a few basic boot/root >floppies, and for the rest let users create their own custom driver discs, >and do some extra work to keep their floppy boot running. > >That ends the one boot/root for all idea, but is maybe more flexible, ( didn't >have to make something with custom kernel to install my Proliant 1500, but >only select the right kernel disc and copy some extra kernel moduless to an empty >flop) and at the same time decrease release engineering on the floppies. > >I think this is a good compromise: Keep floppy option open, but shift some >burden to the users. > >_______________________________________________ >freebsd-hackers@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > This idea dawned on me a few moments ago: If it's really such a big deal to get rid of floppy support, how about we get rid of it and make sure an older version of FreeBSD 4.x/5.x is always available for download? This way, floppy users could install an older version of the OS and cvsup to the latest version they want. I see the above as a decent compromise. This way, we no longer have to support newer floppy editions, but we leave people with floppy drives an option to perform the installation. What do you think? -- William Michael Grim Student, Southern Illinois University at Edwardsville Unix Network Administrator, SIUE, Computer Science dept. Phone: (217) 341-6552 Email: wgrim@siue.edu From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 11:18:35 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1EB216A4CE for ; Sun, 11 Jan 2004 11:18:35 -0800 (PST) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id A78FD43D45 for ; Sun, 11 Jan 2004 11:18:33 -0800 (PST) (envelope-from mdcki@gmx.net) Received: (qmail 1874 invoked by uid 65534); 11 Jan 2004 19:18:32 -0000 Received: from Bc20a.b.pppool.de (EHLO gmx.net) (213.7.194.10) by mail.gmx.net (mp016) with SMTP; 11 Jan 2004 20:18:32 +0100 X-Authenticated: #17236065 Message-ID: <4001A184.5060301@gmx.net> Date: Sun, 11 Jan 2004 20:18:28 +0100 From: Marcin Dalecki User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031224 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Nilsson References: <4001552B.5060108@gneto.com> In-Reply-To: <4001552B.5060108@gneto.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: Assembler coding help needed. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 19:18:35 -0000 Martin Nilsson wrote: > I'm trying to find out why I can't boot 5.2 from USB CDROM on Supermicro > motherboards. (I have an old Gateway P3 that can!). > > I've found out that that only 0x20 of 0x4c sectors of the loader are > read in and it therfor traps when executed. (read is only called once). > > My last attempt at programming x86 assembler was ~15years ago so I'm a > bit rusty :-) > > The below loop from cdboot.s is what I'm having problem understanding, > how can this fail on one box but not on another? > > # > # Load the binary into the buffer. Due to real mode addressing limitations > # we have to read it in in 64k chunks. > # > mov DIR_SIZE(%bx),%eax # Read file length > add $SECTOR_SIZE-1,%eax # Convert length to sectors > shr $11,%eax > > %eax is 0x4c here on both machines! > > cmp $BUFFER_LEN,%eax > jbe load_sizeok > mov $msg_load2big,%si # Error message > call error > load_sizeok: movzbw %al,%cx # Num sectors to read > mov DIR_EXTENT(%bx),%eax # Load extent > xor %edx,%edx > mov DIR_EA_LEN(%bx),%dl > add %edx,%eax # Skip extended > mov $MEM_READ_BUFFER,%ebx # Read into the buffer > load_loop: mov %cl,%dh > cmp $MAX_READ_SEC,%cl # Truncate to max read size > jbe load_notrunc > mov $MAX_READ_SEC,%dh > load_notrunc: sub %dh,%cl # Update count > push %eax # Save > call read # Read it in The fun will be ^^^^ here. The rest is self contained and doesn't depend on CPU variant or periphery. > pop %eax # Restore > add $MAX_READ_SEC,%eax # Update LBA > add $MAX_READ,%ebx # Update dest addr > jcxz load_done # Done? > jmp load_loop # Keep going > load_done: > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 12:13:29 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1EBE16A4CE; Sun, 11 Jan 2004 12:13:29 -0800 (PST) Received: from sizone.org (mortar.sizone.org [65.126.154.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id D211743D3F; Sun, 11 Jan 2004 12:13:28 -0800 (PST) (envelope-from dgilbert@daveg.ca) Received: by sizone.org (Postfix, from userid 66) id 329B9307C6; Sun, 11 Jan 2004 15:13:28 -0500 (EST) Received: by canoe.dclg.ca (Postfix, from userid 101) id 23FBD1D1FB8; Sun, 11 Jan 2004 15:13:26 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16385.44645.936069.15441@canoe.dclg.ca> Date: Sun, 11 Jan 2004 15:13:25 -0500 To: "Poul-Henning Kamp" In-Reply-To: <6552.1073813519@critter.freebsd.dk> References: <20040111051649.GK7617@wantadilla.lemis.com> <6552.1073813519@critter.freebsd.dk> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid cc: Greg 'groggy' Lehey cc: hackers@FreeBSD.org cc: Scott Long cc: current@FreeBSD.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 20:13:30 -0000 >>>>> "Poul-Henning" == Poul-Henning Kamp writes: Poul-Henning> In message <20040111051649.GK7617@wantadilla.lemis.com>, Poul-Henning> "Greg 'groggy' Lehey" writes: Poul-Henning> The reason I say this is that neither of you have the Poul-Henning> time needed, and whoever picks up may have ideas, even Poul-Henning> necesarry ideas, which would grind your spine seriously. Poul-Henning> By letting go, I think you would give vinum a better Poul-Henning> chance. >>> In the p4 tree, we can easier add new talent to our developer >>> force and I am pretty sure that some sort of merry band of >>> developers would form around both RF and vinum there. ... now I thought I followed this list relatively well, but can someone point me at what 'p4' is? Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 12:24:43 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EA2216A4CE for ; Sun, 11 Jan 2004 12:24:43 -0800 (PST) Received: from pc5.i.0x5.de (reverse-213-146-113-119.dialin.kamp-dsl.de [213.146.113.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29E3743D58 for ; Sun, 11 Jan 2004 12:24:40 -0800 (PST) (envelope-from nicolas@dauerreden.de) Received: from pc5.i.0x5.de (nicolas@localhost [127.0.0.1]) by pc5.i.0x5.de (8.12.9p2/8.12.9) with ESMTP id i0BKOcR7056793 for ; Sun, 11 Jan 2004 21:24:38 +0100 (CET) (envelope-from nicolas@pc5.i.0x5.de) Received: (from nicolas@localhost) by pc5.i.0x5.de (8.12.9p2/8.12.9/Submit) id i0BKOc43056792 for freebsd-hackers@freebsd.org; Sun, 11 Jan 2004 21:24:38 +0100 (CET) (envelope-from nicolas) Date: Sun, 11 Jan 2004 21:24:38 +0100 From: Nicolas Rachinsky To: freebsd-hackers@freebsd.org Message-ID: <20040111202438.GA55331@pc5.i.0x5.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20040108163724.GA26745@lpthe.jussieu.fr> <200401101945.27234.wes@softweyr.com> <400108FC.9010008@iconoplex.co.uk> <200401110048.52747.wes@softweyr.com> <40011237.3000409@iconoplex.co.uk> <20040111092746.GA836@pc5.i.0x5.de> <20040111190240.GA28161@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040111190240.GA28161@Odin.AC.HMC.Edu> X-Powered-by: FreeBSD X-Homepage: http://www.rachinsky.de X-PGP-Keyid: C11ABC0E X-PGP-Fingerprint: 19DB 8392 8FE0 814A 7362 EEBD A53B 526A C11A BC0E X-PGP-Key: http://www.rachinsky.de/nicolas/nicolas_rachinsky.asc X-SECURITY: Never trust a running system User-Agent: Mutt/1.5.5.1i Subject: Re: Discussion on the future of floppies in 5.x and 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 20:24:43 -0000 * Brooks Davis [2004-01-11 11:02 -0800]: > If you could make this work such that you just stuffed GENERIC and the > mfsroot onto however many floppies it takes, I think that would almost > certaintly solve re's problems with floppies (i.e. if all they had to do > when the kernel/mfsroot got too big was to bump a NUMFLOPPIES > variable.) Sure that would suck for the floppy users, but that would > put the pain in the place where it's most likely to cause someone to > come up with some better. > > Now, who wants to give this a try? OK, I tried now the following: I made copies of the 4.9 RELEASE Floppies, split the half of the kernel and mfsroot to another floppy and added two appropriate splitfiles. Afterwards booting from these four disks worked fine. disk1: /boot /kernel.gz.split /kernel.gzaa "Message from libstand" disk2: /kernel.gzab "Message from loader.rc" disk3: /mfsroot.gz.split /mfsroot.gzaa "Message from libstand" disk4: /mfsroot.gzab I don't know the release build process, so I don't know how much effort is neccessary to create such floppies, but the loader seems to have all features needed to use such disks. Nicolas From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 12:31:42 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A39ED16A4CE; Sun, 11 Jan 2004 12:31:42 -0800 (PST) Received: from mindfields.energyhq.es.eu.org (73.Red-213-97-200.pooles.rima-tde.net [213.97.200.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6259743D45; Sun, 11 Jan 2004 12:31:24 -0800 (PST) (envelope-from flynn@energyhq.es.eu.org) Received: from energyhq.es.eu.org (scienide.energyhq.es.eu.org [192.168.100.1]) by mindfields.energyhq.es.eu.org (Postfix) with ESMTP id 3697035819; Sun, 11 Jan 2004 21:31:06 +0100 (CET) Message-ID: <4001B292.6010405@energyhq.es.eu.org> Date: Sun, 11 Jan 2004 21:31:14 +0100 From: Miguel Mendez User-Agent: Mozilla/5.0 (X11; U; DragonFly i386; en-US; rv:1.6b) Gecko/20040110 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Gilbert References: <20040111051649.GK7617@wantadilla.lemis.com> <6552.1073813519@critter.freebsd.dk> <16385.44645.936069.15441@canoe.dclg.ca> In-Reply-To: <16385.44645.936069.15441@canoe.dclg.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: hackers@FreeBSD.org cc: current@FreeBSD.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 20:31:42 -0000 David Gilbert wrote: >>>>In the p4 tree, we can easier add new talent to our developer >>>>force and I am pretty sure that some sort of merry band of >>>>developers would form around both RF and vinum there. > > ... now I thought I followed this list relatively well, but can > someone point me at what 'p4' is? p4 is an SCM, some will say the best money can buy :) http://www.perforce.com Some of the FreeBSD development takes place in a perforce repo, perforce.freebsd.org iirc. Cheers, -- Miguel Mendez http://www.energyhq.es.eu.org PGP Key: 0xDC8514F1 From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 12:35:37 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 574BC16A4CE for ; Sun, 11 Jan 2004 12:35:37 -0800 (PST) Received: from natrium.plan-ix.de (natrium.plan-ix.de [212.37.39.36]) by mx1.FreeBSD.org (Postfix) with SMTP id A197143D55 for ; Sun, 11 Jan 2004 12:35:31 -0800 (PST) (envelope-from braukmann@tse-online.de) Received: (qmail 23638 invoked from network); 11 Jan 2004 20:34:23 -0000 Received: from p50824d55.dip0.t-ipconnect.de (HELO ?192.168.225.100?) (braukmann%tse-online.de@80.130.77.85) by natrium.plan-ix.de with SMTP; 11 Jan 2004 20:34:23 -0000 Date: Sun, 11 Jan 2004 21:29:38 +0100 From: Andreas Braukmann To: Poul-Henning Kamp Message-ID: <35520000.1073852978@cage.int.unixxinu.de> In-Reply-To: <9729.1073819616@critter.freebsd.dk> References: <9729.1073819616@critter.freebsd.dk> X-Mailer: Mulberry/3.1.0 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: Greg 'groggy' Lehey cc: Alexander Leidinger cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 20:35:37 -0000 On 01/11/04 12:13:36 +0100 Poul-Henning Kamp wrote: > In message <20040111120824.00cb6314@Magellan.Leidinger.net>, > Alexander Leidinger writes: > >> fine, but if I got it right, do you (Greg) agree to remove it from >> -current? > > My proposal is to do just that with both vinum and raidframe until > one or possibly both are up to full strength again. and I'm pretty sure, that you'll provide means to migrate the vinum volumes on -current systems transparently and in-place to regular partitions? vinum (IMHO) is a quite valuable piece of software. I'm using it quite intensively; *especially* on -current-boxes I'm in need of most flexible storage management. -Andreas From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 12:47:25 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6A9C16A4CE for ; Sun, 11 Jan 2004 12:47:25 -0800 (PST) Received: from redqueen.elvandar.org (cust.94.120.adsl.cistron.nl [195.64.94.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id B04ED43D48 for ; Sun, 11 Jan 2004 12:47:21 -0800 (PST) (envelope-from remko@elvandar.org) From: "Remko Lodder" To: "Daan Vreeken [PA4DAN]" , "70uf33q Hu5541n" Date: Sun, 11 Jan 2004 21:48:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) In-Reply-To: <20040111130736.6962338F@mail.elvandar.org> Importance: Normal X-Virus-Scanned: by amavisd 0.1 Message-Id: <20040111204714.CE9F52B4D47@redqueen.elvandar.org> cc: FreeBSD-hackers@FreeBSD.org cc: Avinash Piare Subject: RE: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 20:47:25 -0000 Sorry to interupt, but i think that person x, since he has a weird name ;-) , means that the partitioning device of freebsd cannot access the extended partition at all. I had this with a friend of mine, and we could not access the devices anymore since it was packed inside another partition (we migrated from linux to freebsd) We needed to use a bit of software that could re-enable our partition. Perhaps Avinash can reply with the software name/ Also it is possible that your partition is held inside another one, how to resolve? No idea, i always started with a clean hdd, or a new one when the current on needed to be saved. Hope it helped a little. Cheers -- Kind regards, Remko Lodder Elvandar.org/DSINet.org www.mostly-harmless.nl Dutch community for helping newcomers on the hackerscene -----Oorspronkelijk bericht----- Van: freebsd-hackers-bounces@lists.elvandar.org [mailto:freebsd-hackers-bounces@lists.elvandar.org]Namens Daan Vreeken [PA4DAN] Verzonden: zondag 11 januari 2004 14:07 Aan: 70uf33q Hu5541n CC: FreeBSD-hackers@FreeBSD.org Onderwerp: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms On Sunday 11 January 2004 11:29, 70uf33q Hu5541n wrote: > hey guys, > > Just got my copy of FreeBSD 5.1. > Spent about an hour going through the BSD Handbook and > preparing a Installation checklist. > > ok here's my problem. > > I have a WD 40 GB HDD > the primary partition is 10 GB, with the extended > partition 28 GB.(the rest 2 GB is in WD's bank). > > OK , the extended partition has 3 logical drives. > To create a slice for BSD, I resized one of the > logical drives to free up some space. About 1.2 > GB,cause that's all I can spare. > > When I run the installation through CDROM, and the > point where I'm to creat the Freebsd slice,the new > partition is not displayed in the "FDISK" utility. > > All I get is the primary (10GB) and the whole Extended > (28 GB). > The freespace I guess is "locked into" the Extended > Partiton. Not sure though. Indeed you first have to resize the extended partition before you can use the space to create slices. The "fdisk" program that comes with Windows has no way to do this (except deleting all logicle drives in the extended partition and re-creating them). Have a look at the program "Partition Magic". It can resize partitions and it has a nice user interface. grtz, Daan _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" _______________________________________________ Freebsd-hackers mailing list Freebsd-hackers@lists.elvandar.org http://lists.elvandar.org/mailman/listinfo/freebsd-hackers From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 13:15:54 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 262C116A4CE; Sun, 11 Jan 2004 13:15:54 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6724F43D3F; Sun, 11 Jan 2004 13:15:52 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i0BLFfET042294; Sun, 11 Jan 2004 14:15:42 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 11 Jan 2004 14:15:05 -0700 (MST) Message-Id: <20040111.141505.108953149.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <14092.1073845446@critter.freebsd.dk> References: <16385.37893.652979.822920@canoe.dclg.ca> <14092.1073845446@critter.freebsd.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: des@des.no cc: hackers@freebsd.org cc: current@freebsd.org cc: dgilbert@dclg.ca Subject: Re: Future of RAIDFrame X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 21:15:54 -0000 In message: <14092.1073845446@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <16385.37893.652979.822920@canoe.dclg.ca>, David Gilbert writes: : >That said, we need a strong and robust software raid. : : And as long as we have something which "mostly work" there seems to : be insufficient motivation to make that happen. : : Therefore my proposal to send both RF and Vinum in training camp in p4. This has been a fundamental disagreement in the development model for a long time. Some people think this is a great idea, others hate it. The pros are that open source tends to be written best when there's pain and suffering to overcome. The cons are that sometimes things that are shot in the head never come back to life, leaving our users in the lurch. Maybe this would be a good test-case for seeing how well it works? Maybe not. We do need to run a few more test-cases for things through this scenario... I'm not sure this one is well suited to it. Warner From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 13:34:37 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A91216A4D0 for ; Sun, 11 Jan 2004 13:34:37 -0800 (PST) Received: from pear.silverwraith.com (66-214-182-79.la-cbi.charterpipeline.net [66.214.182.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id B942343D3F for ; Sun, 11 Jan 2004 13:34:33 -0800 (PST) (envelope-from lists-freebsd@silverwraith.com) Received: from avleen by pear.silverwraith.com with local (Exim 4.30; FreeBSD) id 1AfnE9-000KPk-1b for freebsd-hackers@freebsd.org; Sun, 11 Jan 2004 13:34:33 -0800 Date: Sun, 11 Jan 2004 13:34:32 -0800 From: Avleen Vig To: freebsd-hackers@freebsd.org Message-ID: <20040111213432.GK53429@silverwraith.com> References: <20040108163724.GA26745@lpthe.jussieu.fr> <200401101945.27234.wes@softweyr.com> <400108FC.9010008@iconoplex.co.uk> <200401110048.52747.wes@softweyr.com> <40011237.3000409@iconoplex.co.uk> <20040111092746.GA836@pc5.i.0x5.de> <20040111190240.GA28161@Odin.AC.HMC.Edu> <20040111202438.GA55331@pc5.i.0x5.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040111202438.GA55331@pc5.i.0x5.de> User-Agent: Mutt/1.5.5.1i Subject: Re: Discussion on the future of floppies in 5.x and 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 21:34:37 -0000 On Sun, Jan 11, 2004 at 09:24:38PM +0100, Nicolas Rachinsky wrote: > > Now, who wants to give this a try? > > OK, I tried now the following: > > I made copies of the 4.9 RELEASE Floppies, split the half of the > kernel and mfsroot to another floppy and added two appropriate > splitfiles. > > Afterwards booting from these four disks worked fine. OK, someone help me out here :) I was going to try this with a range of floppies (4.8, 4.9, 5.1, 5.2, etc), but I can't figure out what to do with splitfs.c gcc -o splitfs /usr/src/lib/libstand/splitfs.c /usr/lib/crt1.o: In function `_start': /usr/lib/crt1.o(.text+0x85): undefined reference to `main' /tmp/cc1Xbt2V.o: In function `splitfs_open': /tmp/cc1Xbt2V.o(.text+0x239): undefined reference to `fgetstr' /tmp/cc1Xbt2V.o: In function `splitfs_seek': /tmp/cc1Xbt2V.o(.text+0x695): undefined reference to `panic' /tmp/cc1Xbt2V.o(.text+0x801): undefined reference to `panic' /tmp/cc1Xbt2V.o(.data+0x10): undefined reference to `null_write' /tmp/cc1Xbt2V.o(.data+0x1c): undefined reference to `null_readdir' I'm guessing that's not the right thing to do. From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 13:39:14 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7343616A4CE; Sun, 11 Jan 2004 13:39:14 -0800 (PST) Received: from as6-1-5.kr.m.bonet.se (as6-1-5.kr.m.bonet.se [217.215.84.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4950143D46; Sun, 11 Jan 2004 13:39:08 -0800 (PST) (envelope-from martin@gneto.com) Received: from gneto.com (euklides.gneto.com [192.168.10.11]) by as6-1-5.kr.m.bonet.se (Postfix) with ESMTP id E7A67743AC; Sun, 11 Jan 2004 22:39:06 +0100 (CET) Message-ID: <4001C283.5080106@gneto.com> Date: Sun, 11 Jan 2004 22:39:15 +0100 From: Martin Nilsson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6b) Gecko/20031212 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcin Dalecki References: <4001552B.5060108@gneto.com> <4001A184.5060301@gmx.net> In-Reply-To: <4001A184.5060301@gmx.net> Content-Type: multipart/mixed; boundary="------------060902090801080906010005" cc: freebsd-hackers@freebsd.org Subject: Re: Assembler coding help needed. [solved, patch enclosed] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 21:39:14 -0000 This is a multi-part message in MIME format. --------------060902090801080906010005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Marcin Dalecki wrote: > Martin Nilsson wrote: > >> I'm trying to find out why I can't boot 5.2 from USB CDROM on >> Supermicro motherboards. (I have an old Gateway P3 that can!). >> >> I've found out that that only 0x20 of 0x4c sectors of the loader are >> read in and it therfor traps when executed. (read is only called once). >> >> load_notrunc: sub %dh,%cl # Update count >> push %eax # Save >> call read # Read it in > > > The fun will be ^^^^ here. The rest is self contained and > doesn't depend on CPU variant or periphery. > I found the problem! The bios trashes %cx when reading from USB CD but not when reading from ATAPI CD. The attached patch fixes this and two other small nits in sys/boot/i386/cdboot/cdboot.s Can somebody (jhb) commit this? This probably affects all Phoenix-Award bios equipped boxes. My old Gateway with AMI BIOS works as it should. /Martin --------------060902090801080906010005 Content-Type: text/plain; name="cdboot.s.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cdboot.s.diff" *** cdboot.s-original Sun Jan 11 22:16:45 2004 --- cdboot.s Sun Jan 11 22:16:13 2004 *************** *** 165,171 **** # mov DIR_SIZE(%bx),%eax # Read file length add $SECTOR_SIZE-1,%eax # Convert length to sectors ! shr $11,%eax cmp $BUFFER_LEN,%eax jbe load_sizeok mov $msg_load2big,%si # Error message --- 165,171 ---- # mov DIR_SIZE(%bx),%eax # Read file length add $SECTOR_SIZE-1,%eax # Convert length to sectors ! shr $SECTOR_SHIFT,%eax cmp $BUFFER_LEN,%eax jbe load_sizeok mov $msg_load2big,%si # Error message *************** *** 182,189 **** mov $MAX_READ_SEC,%dh load_notrunc: sub %dh,%cl # Update count push %eax # Save call read # Read it in ! pop %eax # Restore add $MAX_READ_SEC,%eax # Update LBA add $MAX_READ,%ebx # Update dest addr jcxz load_done # Done? --- 182,191 ---- mov $MAX_READ_SEC,%dh load_notrunc: sub %dh,%cl # Update count push %eax # Save + push %cx # Supermicro BIOS trashes cx when booting USB CD call read # Read it in ! pop %cx # Restore ! pop %eax add $MAX_READ_SEC,%eax # Update LBA add $MAX_READ,%ebx # Update dest addr jcxz load_done # Done? *************** *** 460,465 **** --- 462,468 ---- mov twiddle_chars,%bx # Address table inc %al # Next and $3,%al # char + mov %al,twiddle_index # Save index xlat # Get char call putc # Output it mov $8,%al # Backspace --------------060902090801080906010005-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 14:19:57 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5416216A4CE for ; Sun, 11 Jan 2004 14:19:57 -0800 (PST) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E139E43D4C for ; Sun, 11 Jan 2004 14:19:55 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i0BMJrKx004416; Sun, 11 Jan 2004 17:19:54 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <1073815249.5250.2.camel@herring.nlsystems.com> References: <20040110032731.18864.qmail@web13422.mail.yahoo.com> <40003F4C.2000107@gamersimpact.com> <200401102020.17108.peter.schuller@infidyne.com> <4000701B.40102@cream.org> <20040111000551.GC60996@server.vk2pj.dyndns.org> <1073815249.5250.2.camel@herring.nlsystems.com> Date: Sun, 11 Jan 2004 17:19:53 -0500 To: Doug Rabson , Peter Jeremy From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: freebsd-hackers@freebsd.org Subject: Re: SCM options (was Re: Where is FreeBSD going?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 22:19:57 -0000 At 10:00 AM +0000 1/11/04, Doug Rabson wrote: >On Sun, 2004-01-11 at 00:05, Peter Jeremy wrote: > > > > I disagree. Andrew raised two issues (type of license and > > port vs base location). The type of license is an input to > > the decision as to which SCM to choose - BSD preferable ... > >Subversion has a friendly BSD-ish license but it depends heavily >on Sleepycat DB which doesn't. I imagine that if we do end up >using it one day, it would be best managed as a port rather than >part of the base system. I just don't see many people agreeing >on importing subversion+db-4.2+apache2 into src/contrib... Another way of approaching that is to say subversion is not-likely to be imported *unless* we can find an acceptable BSD-licensed database mgr to go along with it. (I do not know how much of Apache is needed. Would svn *clients* need to have apache installed, or is that only needed for machines that hold a public repository?) -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 14:25:58 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4017C16A4CE for ; Sun, 11 Jan 2004 14:25:58 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 4949143D2F for ; Sun, 11 Jan 2004 14:25:55 -0800 (PST) (envelope-from rooneg@electricjellyfish.net) Received: (qmail 31078 invoked from network); 11 Jan 2004 22:25:54 -0000 Received: from ool-435713c1.dyn.optonline.net (HELO ?192.168.0.2?) (67.87.19.193) by relay.pair.com with SMTP; 11 Jan 2004 22:25:54 -0000 X-pair-Authenticated: 67.87.19.193 In-Reply-To: References: <20040110032731.18864.qmail@web13422.mail.yahoo.com> <40003F4C.2000107@gamersimpact.com> <200401102020.17108.peter.schuller@infidyne.com> <4000701B.40102@cream.org> <20040111000551.GC60996@server.vk2pj.dyndns.org> <1073815249.5250.2.camel@herring.nlsystems.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1E090F46-4485-11D8-9AE9-000393CE23F4@electricjellyfish.net> Content-Transfer-Encoding: 7bit From: Garrett Rooney Date: Sun, 11 Jan 2004 17:25:53 -0500 To: Garance A Drosihn X-Mailer: Apple Mail (2.609) cc: freebsd-hackers@freebsd.org Subject: Re: SCM options (was Re: Where is FreeBSD going?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 22:25:58 -0000 On Jan 11, 2004, at 5:19 PM, Garance A Drosihn wrote: > At 10:00 AM +0000 1/11/04, Doug Rabson wrote: >> On Sun, 2004-01-11 at 00:05, Peter Jeremy wrote: >> > >> > I disagree. Andrew raised two issues (type of license and >> > port vs base location). The type of license is an input to >> > the decision as to which SCM to choose - BSD preferable ... >> >> Subversion has a friendly BSD-ish license but it depends heavily >> on Sleepycat DB which doesn't. I imagine that if we do end up >> using it one day, it would be best managed as a port rather than >> part of the base system. I just don't see many people agreeing >> on importing subversion+db-4.2+apache2 into src/contrib... > > Another way of approaching that is to say subversion is not-likely > to be imported *unless* we can find an acceptable BSD-licensed > database mgr to go along with it. (I do not know how much of > Apache is needed. Would svn *clients* need to have apache > installed, or is that only needed for machines that hold a > public repository?) Subversion servers require Berkeley DB and potentially Apache if you want to use mod_dav_svn as your server. If you don't want to use mod_dav_svn you can avoid the dependency on Apache. Subversion clients require APR (the Apache Portable Runtime) and potentially Neon (a webdav client library) if you want to use mod_dav_svn as your server. In any event, I'm not convinced that importing Subversion into the tree is necessary even if you do want to use it. There's no real reason it can't just live in the ports tree as it does now. -garrett From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 14:35:25 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7452C16A4CE for ; Sun, 11 Jan 2004 14:35:25 -0800 (PST) Received: from web12707.mail.yahoo.com (web12707.mail.yahoo.com [216.136.173.244]) by mx1.FreeBSD.org (Postfix) with SMTP id 5748C43D2D for ; Sun, 11 Jan 2004 14:35:23 -0800 (PST) (envelope-from topa_007@yahoo.com) Message-ID: <20040111223523.83697.qmail@web12707.mail.yahoo.com> Received: from [219.65.96.122] by web12707.mail.yahoo.com via HTTP; Sun, 11 Jan 2004 14:35:23 PST Date: Sun, 11 Jan 2004 14:35:23 -0800 (PST) From: 70uf33q Hu5541n To: Remko Lodder In-Reply-To: <20040111204714.CE9F52B4D47@redqueen.elvandar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-hackers@freebsd.org Subject: RE: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 22:35:25 -0000 hey Remko, the FreeBSD sysinstall (i think) program does identify the extended partitions but not the logical drives contained in it. and yes, I've not introduced myself yet. :D btw, I'm Toufeeq from Chennai,India. 20 yrs old doing my Engineering final year. Been a linux user for 4 years now. FreeBSD , well I was interested more in the way the history/development of the OS took place and that got me hooked on and so I wanted to give it a try. Sadly though, my hard disk is causing problems.Though that wont stop me ;) btw, name uses wat some people call 'lewt' speak its just replacing alphabets with numbers, like 3 = e and a = 4. so 70uf33q is actually Toufeeq. love to explain more but its 4 am and I got a test on Monday. cheers, toufeeq --- Remko Lodder wrote: > Sorry to interupt, > > but i think that person x, since he has a weird name > ;-) , > means that the partitioning device of freebsd cannot > access the extended > partition > at all. > > I had this with a friend of mine, and we could not > access the devices > anymore since it was > packed inside another partition (we migrated from > linux to freebsd) > We needed to use a bit of software that could > re-enable our partition. > Perhaps Avinash can reply with the software name/ > > Also it is possible that your partition is held > inside another one, > > how to resolve? No idea, i always started with a > clean hdd, or a new one > when the current on needed to be saved. > > Hope it helped a little. > Cheers > > > -- > > Kind regards, > > Remko Lodder > Elvandar.org/DSINet.org > www.mostly-harmless.nl Dutch community for helping > newcomers on the > hackerscene > > -----Oorspronkelijk bericht----- > Van: freebsd-hackers-bounces@lists.elvandar.org > [mailto:freebsd-hackers-bounces@lists.elvandar.org]Namens > Daan Vreeken > [PA4DAN] > Verzonden: zondag 11 januari 2004 14:07 > Aan: 70uf33q Hu5541n > CC: FreeBSD-hackers@FreeBSD.org > Onderwerp: [Freebsd-hackers] Re: FreeBSD 5.1 > Installation probelms > > > On Sunday 11 January 2004 11:29, 70uf33q Hu5541n > wrote: > > hey guys, > > > > Just got my copy of FreeBSD 5.1. > > Spent about an hour going through the BSD Handbook > and > > preparing a Installation checklist. > > > > ok here's my problem. > > > > I have a WD 40 GB HDD > > the primary partition is 10 GB, with the extended > > partition 28 GB.(the rest 2 GB is in WD's bank). > > > > OK , the extended partition has 3 logical drives. > > To create a slice for BSD, I resized one of the > > logical drives to free up some space. About 1.2 > > GB,cause that's all I can spare. > > > > When I run the installation through CDROM, and the > > point where I'm to creat the Freebsd slice,the new > > partition is not displayed in the "FDISK" utility. > > > > All I get is the primary (10GB) and the whole > Extended > > (28 GB). > > The freespace I guess is "locked into" the > Extended > > Partiton. Not sure though. > Indeed you first have to resize the extended > partition before you can use > the > space to create slices. The "fdisk" program that > comes with Windows has no > way to do this (except deleting all logicle drives > in the extended partition > and re-creating them). Have a look at the program > "Partition Magic". It can > resize partitions and it has a nice user interface. > > grtz, > Daan > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > _______________________________________________ > Freebsd-hackers mailing list > Freebsd-hackers@lists.elvandar.org > http://lists.elvandar.org/mailman/listinfo/freebsd-hackers > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" ===== "Love is control,I'll die if I let go I will only let you breathe My air that you receive Then we'll see if I let you love me." -James Hetfield All Within My Hands,St.Anger Metallica __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 14:40:36 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F12416A4D0 for ; Sun, 11 Jan 2004 14:40:36 -0800 (PST) Received: from redqueen.elvandar.org (cust.94.120.adsl.cistron.nl [195.64.94.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DA6643D2F for ; Sun, 11 Jan 2004 14:40:32 -0800 (PST) (envelope-from remko@elvandar.org) From: "Remko Lodder" To: "70uf33q Hu5541n" Date: Sun, 11 Jan 2004 23:41:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) In-Reply-To: <20040111223540.3EAC034A@mail.elvandar.org> Importance: Normal X-Virus-Scanned: by amavisd 0.1 Message-Id: <20040111224031.488072B4D47@redqueen.elvandar.org> cc: freebsd-hackers@freebsd.org cc: Avinash Piare Subject: RE: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 22:40:36 -0000 Excuse me, that is what i ment, (the logical drives) As said with Avinash, we could not access that as well, and he used to program he replied with (will be posted to this list when the admin approves :) ) to restore it's data. But perhaps that makes it also able to modify it a little to make it accessible by freebsd fdisk/disklabel (not sysinstall i think, since i think it calles fdisk or disklabel). Anyway i am not sure this will work and does the job, but perhaps you can have a look at it, Though i never had your problem, as said i just plugged in a little extra harddrive (450mb was my first and it worked perfect :) ) and i do know the l33t language, but i prefer the 'normal' language :) please to meet you toufeeq and success with your harddrive/freebsd and your test. -- Kind regards, Remko Lodder Elvandar.org/DSINet.org www.mostly-harmless.nl Dutch community for helping newcomers on the hackerscene -----Oorspronkelijk bericht----- Van: 70uf33q Hu5541n [mailto:topa_007@yahoo.com] Verzonden: zondag 11 januari 2004 23:35 Aan: Remko Lodder CC: freebsd-hackers@freebsd.org Onderwerp: RE: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms hey Remko, the FreeBSD sysinstall (i think) program does identify the extended partitions but not the logical drives contained in it. and yes, I've not introduced myself yet. :D btw, I'm Toufeeq from Chennai,India. 20 yrs old doing my Engineering final year. Been a linux user for 4 years now. FreeBSD , well I was interested more in the way the history/development of the OS took place and that got me hooked on and so I wanted to give it a try. Sadly though, my hard disk is causing problems.Though that wont stop me ;) btw, name uses wat some people call 'lewt' speak its just replacing alphabets with numbers, like 3 = e and a = 4. so 70uf33q is actually Toufeeq. love to explain more but its 4 am and I got a test on Monday. cheers, toufeeq --- Remko Lodder wrote: > Sorry to interupt, > > but i think that person x, since he has a weird name > ;-) , > means that the partitioning device of freebsd cannot > access the extended > partition > at all. > > I had this with a friend of mine, and we could not > access the devices > anymore since it was > packed inside another partition (we migrated from > linux to freebsd) > We needed to use a bit of software that could > re-enable our partition. > Perhaps Avinash can reply with the software name/ > > Also it is possible that your partition is held > inside another one, > > how to resolve? No idea, i always started with a > clean hdd, or a new one > when the current on needed to be saved. > > Hope it helped a little. > Cheers > > > -- > > Kind regards, > > Remko Lodder > Elvandar.org/DSINet.org > www.mostly-harmless.nl Dutch community for helping > newcomers on the > hackerscene > > -----Oorspronkelijk bericht----- > Van: freebsd-hackers-bounces@lists.elvandar.org > [mailto:freebsd-hackers-bounces@lists.elvandar.org]Namens > Daan Vreeken > [PA4DAN] > Verzonden: zondag 11 januari 2004 14:07 > Aan: 70uf33q Hu5541n > CC: FreeBSD-hackers@FreeBSD.org > Onderwerp: [Freebsd-hackers] Re: FreeBSD 5.1 > Installation probelms > > > On Sunday 11 January 2004 11:29, 70uf33q Hu5541n > wrote: > > hey guys, > > > > Just got my copy of FreeBSD 5.1. > > Spent about an hour going through the BSD Handbook > and > > preparing a Installation checklist. > > > > ok here's my problem. > > > > I have a WD 40 GB HDD > > the primary partition is 10 GB, with the extended > > partition 28 GB.(the rest 2 GB is in WD's bank). > > > > OK , the extended partition has 3 logical drives. > > To create a slice for BSD, I resized one of the > > logical drives to free up some space. About 1.2 > > GB,cause that's all I can spare. > > > > When I run the installation through CDROM, and the > > point where I'm to creat the Freebsd slice,the new > > partition is not displayed in the "FDISK" utility. > > > > All I get is the primary (10GB) and the whole > Extended > > (28 GB). > > The freespace I guess is "locked into" the > Extended > > Partiton. Not sure though. > Indeed you first have to resize the extended > partition before you can use > the > space to create slices. The "fdisk" program that > comes with Windows has no > way to do this (except deleting all logicle drives > in the extended partition > and re-creating them). Have a look at the program > "Partition Magic". It can > resize partitions and it has a nice user interface. > > grtz, > Daan > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > _______________________________________________ > Freebsd-hackers mailing list > Freebsd-hackers@lists.elvandar.org > http://lists.elvandar.org/mailman/listinfo/freebsd-hackers > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" ===== "Love is control,I'll die if I let go I will only let you breathe My air that you receive Then we'll see if I let you love me." -James Hetfield All Within My Hands,St.Anger Metallica __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 14:49:59 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B30F216A4D2 for ; Sun, 11 Jan 2004 14:49:59 -0800 (PST) Received: from web12703.mail.yahoo.com (web12703.mail.yahoo.com [216.136.173.240]) by mx1.FreeBSD.org (Postfix) with SMTP id 9EFB543D41 for ; Sun, 11 Jan 2004 14:49:57 -0800 (PST) (envelope-from topa_007@yahoo.com) Message-ID: <20040111224957.64241.qmail@web12703.mail.yahoo.com> Received: from [219.65.96.122] by web12703.mail.yahoo.com via HTTP; Sun, 11 Jan 2004 14:49:57 PST Date: Sun, 11 Jan 2004 14:49:57 -0800 (PST) From: 70uf33q Hu5541n To: Remko Lodder In-Reply-To: <20040111224031.488072B4D47@redqueen.elvandar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-hackers@freebsd.org Subject: RE: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 22:49:59 -0000 hey, ok noted. will wait for Avinash's software.will also check out if its possible under PartitionMagic 8 and let you know if that works out. great to be among this community. bye, Toufeeq --- Remko Lodder wrote: > Excuse me, that is what i ment, (the logical drives) > As said with Avinash, we could not access that as > well, > and he used to program he replied with (will be > posted to this list > when the admin approves :) ) to restore it's data. > But perhaps that makes it > also able to modify it a little to make it > accessible by freebsd > fdisk/disklabel (not sysinstall > i think, since i think it calles fdisk or > disklabel). > > Anyway i am not sure this will work and does the > job, but perhaps you can > have a look at it, > Though i never had your problem, as said i just > plugged in a little extra > harddrive (450mb was > my first and it worked perfect :) ) > > and i do know the l33t language, but i prefer the > 'normal' language :) > > please to meet you toufeeq > and success with your harddrive/freebsd and your > test. > > > -- > > Kind regards, > > Remko Lodder > Elvandar.org/DSINet.org > www.mostly-harmless.nl Dutch community for helping > newcomers on the > hackerscene > > -----Oorspronkelijk bericht----- > Van: 70uf33q Hu5541n [mailto:topa_007@yahoo.com] > Verzonden: zondag 11 januari 2004 23:35 > Aan: Remko Lodder > CC: freebsd-hackers@freebsd.org > Onderwerp: RE: [Freebsd-hackers] Re: FreeBSD 5.1 > Installation probelms > > > hey Remko, > > the FreeBSD sysinstall (i think) program does > identify > the extended partitions but not the logical drives > contained in it. > > and yes, I've not introduced myself yet. :D > btw, > I'm Toufeeq from Chennai,India. > 20 yrs old doing my Engineering final year. > > Been a linux user for 4 years now. FreeBSD , well I > was interested more in the way the > history/development > of the OS took place and that got me hooked on and > so > I wanted to give it a try. > > Sadly though, my hard disk is causing > problems.Though > that wont stop me ;) > > btw, name uses wat some people call 'lewt' speak > its just replacing alphabets with numbers, like 3 = > e > and a = 4. > so 70uf33q is actually Toufeeq. > > love to explain more but its 4 am and I got a test > on > Monday. > > cheers, > toufeeq > --- Remko Lodder wrote: > > Sorry to interupt, > > > > but i think that person x, since he has a weird > name > > ;-) , > > means that the partitioning device of freebsd > cannot > > access the extended > > partition > > at all. > > > > I had this with a friend of mine, and we could not > > access the devices > > anymore since it was > > packed inside another partition (we migrated from > > linux to freebsd) > > We needed to use a bit of software that could > > re-enable our partition. > > Perhaps Avinash can reply with the software name/ > > > > Also it is possible that your partition is held > > inside another one, > > > > how to resolve? No idea, i always started with a > > clean hdd, or a new one > > when the current on needed to be saved. > > > > Hope it helped a little. > > Cheers > > > > > > -- > > > > Kind regards, > > > > Remko Lodder > > Elvandar.org/DSINet.org > > www.mostly-harmless.nl Dutch community for helping > > newcomers on the > > hackerscene > > > > -----Oorspronkelijk bericht----- > > Van: freebsd-hackers-bounces@lists.elvandar.org > > > [mailto:freebsd-hackers-bounces@lists.elvandar.org]Namens > > Daan Vreeken > > [PA4DAN] > > Verzonden: zondag 11 januari 2004 14:07 > > Aan: 70uf33q Hu5541n > > CC: FreeBSD-hackers@FreeBSD.org > > Onderwerp: [Freebsd-hackers] Re: FreeBSD 5.1 > > Installation probelms > > > > > > On Sunday 11 January 2004 11:29, 70uf33q Hu5541n > > wrote: > > > hey guys, > > > > > > Just got my copy of FreeBSD 5.1. > > > Spent about an hour going through the BSD > Handbook > > and > > > preparing a Installation checklist. > > > > > > ok here's my problem. > > > > > > I have a WD 40 GB HDD > > > the primary partition is 10 GB, with the > extended > > > partition 28 GB.(the rest 2 GB is in WD's bank). > > > > > > OK , the extended partition has 3 logical > drives. > > > To create a slice for BSD, I resized one of the > > > logical drives to free up some space. About 1.2 > > > GB,cause that's all I can spare. > > > > > > When I run the installation through CDROM, and > the > > > point where I'm to creat the Freebsd slice,the > new > > > partition is not displayed in the "FDISK" > utility. > > > > > > All I get is the primary (10GB) and the whole > > Extended > > > (28 GB). > > > The freespace I guess is "locked into" the > > Extended > > > Partiton. Not sure though. > > Indeed you first have to resize the extended > > partition before you can use > > the > > space to create slices. The "fdisk" program that > > comes with Windows has no > > way to do this (except deleting all logicle drives > > in the extended partition > > and re-creating them). Have a look at the program > > "Partition Magic". It can > > resize partitions and it has a nice user > interface. > > > > grtz, > > Daan > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to > > "freebsd-hackers-unsubscribe@freebsd.org" > > _______________________________________________ > > Freebsd-hackers mailing list > > Freebsd-hackers@lists.elvandar.org > > > http://lists.elvandar.org/mailman/listinfo/freebsd-hackers > > > > _______________________________________________ > === message truncated === ===== "Love is control,I'll die if I let go I will only let you breathe My air that you receive Then we'll see if I let you love me." -James Hetfield All Within My Hands,St.Anger Metallica __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 15:14:47 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 432FB16A4CE for ; Sun, 11 Jan 2004 15:14:47 -0800 (PST) Received: from pc5.i.0x5.de (reverse-213-146-113-119.dialin.kamp-dsl.de [213.146.113.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF35D43D46 for ; Sun, 11 Jan 2004 15:14:43 -0800 (PST) (envelope-from nicolas@dauerreden.de) Received: from pc5.i.0x5.de (nicolas@localhost [127.0.0.1]) by pc5.i.0x5.de (8.12.9p2/8.12.9) with ESMTP id i0BNEfR7070675 for ; Mon, 12 Jan 2004 00:14:41 +0100 (CET) (envelope-from nicolas@pc5.i.0x5.de) Received: (from nicolas@localhost) by pc5.i.0x5.de (8.12.9p2/8.12.9/Submit) id i0BNEfPU070674 for freebsd-hackers@freebsd.org; Mon, 12 Jan 2004 00:14:41 +0100 (CET) (envelope-from nicolas) Date: Mon, 12 Jan 2004 00:14:41 +0100 From: Nicolas Rachinsky To: freebsd-hackers@freebsd.org Message-ID: <20040111231441.GA70479@pc5.i.0x5.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20040108163724.GA26745@lpthe.jussieu.fr> <200401101945.27234.wes@softweyr.com> <400108FC.9010008@iconoplex.co.uk> <200401110048.52747.wes@softweyr.com> <40011237.3000409@iconoplex.co.uk> <20040111092746.GA836@pc5.i.0x5.de> <20040111190240.GA28161@Odin.AC.HMC.Edu> <20040111202438.GA55331@pc5.i.0x5.de> <20040111213432.GK53429@silverwraith.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040111213432.GK53429@silverwraith.com> X-Powered-by: FreeBSD X-Homepage: http://www.rachinsky.de X-PGP-Keyid: C11ABC0E X-PGP-Fingerprint: 19DB 8392 8FE0 814A 7362 EEBD A53B 526A C11A BC0E X-PGP-Key: http://www.rachinsky.de/nicolas/nicolas_rachinsky.asc X-SECURITY: Never trust a running system User-Agent: Mutt/1.5.5.1i Subject: Re: Discussion on the future of floppies in 5.x and 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 23:14:47 -0000 * Avleen Vig [2004-01-11 13:34 -0800]: > On Sun, Jan 11, 2004 at 09:24:38PM +0100, Nicolas Rachinsky wrote: > > > Now, who wants to give this a try? > > > > OK, I tried now the following: > > > > I made copies of the 4.9 RELEASE Floppies, split the half of the > > kernel and mfsroot to another floppy and added two appropriate > > splitfiles. > > > > Afterwards booting from these four disks worked fine. > > OK, someone help me out here :) > I was going to try this with a range of floppies (4.8, 4.9, 5.1, 5.2, > etc), but I can't figure out what to do with splitfs.c Do nothing, the loader already contains it. Nicolas From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 15:19:04 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3025216A4D0; Sun, 11 Jan 2004 15:19:04 -0800 (PST) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2DB043D58; Sun, 11 Jan 2004 15:18:46 -0800 (PST) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (localhost [127.0.0.1]) by haldjas.folklore.ee (8.12.3/8.11.3) with ESMTP id i0BNIiHV018282; Mon, 12 Jan 2004 01:18:45 +0200 (EET) (envelope-from narvi@haldjas.folklore.ee) Received: from localhost (narvi@localhost)i0BNIder018279; Mon, 12 Jan 2004 01:18:39 +0200 (EET) Date: Mon, 12 Jan 2004 01:18:39 +0200 (EET) From: Narvi To: Andreas Braukmann In-Reply-To: <35520000.1073852978@cage.int.unixxinu.de> Message-ID: <20040112011539.S32387-100000@haldjas.folklore.ee> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Greg 'groggy' Lehey cc: Alexander Leidinger cc: Poul-Henning Kamp cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 23:19:04 -0000 On Sun, 11 Jan 2004, Andreas Braukmann wrote: > On 01/11/04 12:13:36 +0100 Poul-Henning Kamp wrote: > > > In message <20040111120824.00cb6314@Magellan.Leidinger.net>, > > Alexander Leidinger writes: > > > >> fine, but if I got it right, do you (Greg) agree to remove it from > >> -current? > > > > My proposal is to do just that with both vinum and raidframe until > > one or possibly both are up to full strength again. > > and I'm pretty sure, that you'll provide means to migrate > the vinum volumes on -current systems transparently and > in-place to regular partitions? > > vinum (IMHO) is a quite valuable piece of software. I'm > using it quite intensively; *especially* on -current-boxes > I'm in need of most flexible storage management. > oh yes - and please fix disklabel to support an arbirtary number of file system per a "disk" or "slice" in the process, because otherwise it will not be converting many setups. > > -Andreas > From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 16:42:40 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50B4416A4CE; Sun, 11 Jan 2004 16:42:40 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id C19A443D4C; Sun, 11 Jan 2004 16:42:38 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 70D3B5309; Mon, 12 Jan 2004 01:42:37 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id A04515308; Mon, 12 Jan 2004 01:42:28 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id BE7DC33C6A; Sun, 11 Jan 2004 22:35:28 +0100 (CET) To: "M. Warner Losh" References: <16385.37893.652979.822920@canoe.dclg.ca> <14092.1073845446@critter.freebsd.dk> <20040111.141505.108953149.imp@bsdimp.com> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Sun, 11 Jan 2004 22:35:28 +0100 In-Reply-To: <20040111.141505.108953149.imp@bsdimp.com> (M. Warner Losh's message of "Sun, 11 Jan 2004 14:15:05 -0700 (MST)") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on flood.des.no X-Spam-Level: sss X-Spam-Status: No, hits=3.3 required=5.0 tests=DATE_IN_PAST_03_06, RCVD_IN_DYNABLOCK,RCVD_IN_SORBS autolearn=no version=2.61 cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: current@freebsd.org cc: dgilbert@dclg.ca Subject: Re: Future of RAIDFrame X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 00:42:40 -0000 "M. Warner Losh" writes: > Maybe this would be a good test-case for seeing how well it works? > Maybe not. We do need to run a few more test-cases for things through > this scenario... I'm not sure this one is well suited to it. If we toss out Vinum, there's a significant risk that 5.3 will ship without RAID support at all. I'm pretty certain we don't want that. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 17:26:44 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADF0516A4CE; Sun, 11 Jan 2004 17:26:44 -0800 (PST) Received: from milla.ask33.net (milla.ask33.net [217.197.166.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id C566F43D55; Sun, 11 Jan 2004 17:26:41 -0800 (PST) (envelope-from nick@milla.ask33.net) Received: by milla.ask33.net (Postfix, from userid 1001) id 31C4C3ABB51; Mon, 12 Jan 2004 02:27:12 +0100 (CET) Date: Mon, 12 Jan 2004 02:27:12 +0100 From: Pawel Jakub Dawidek To: Robert Watson Message-ID: <20040112012711.GC74246@garage.freebsd.pl> References: <20040111155842.GB74246@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="+JUInw4efm7IfTNU" Content-Disposition: inline In-Reply-To: X-PGP-Key-URL: http://garage.freebsd.pl/jules.asc X-OS: FreeBSD 4.8-RELEASE-p13 i386 X-URL: http://garage.freebsd.pl User-Agent: Mutt/1.5.1i cc: freebsd-hackers@freebsd.org cc: phk@freebsd.org Subject: Re: MD(4) cleanups and unload lesson. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 01:26:44 -0000 --+JUInw4efm7IfTNU Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 11, 2004 at 12:48:56PM -0500, Robert Watson wrote: +> On Sun, 11 Jan 2004, Pawel Jakub Dawidek wrote: +> > With attached patch unloading md(4) module is possible. It also cleans +> > up big part of code according to style(9).=20 +>=20 +> Could you separate this into a functional diff and a style diff? There's +> a general preference to not combine them, as it means cvs diff between +> revisions isn't useful for identifying functional changes (i.e., reviewi= ng +> for bugs when back-tracking, etc).=20 Sure functional-only change is now here: http://garage.freebsd.pl/patches/md.c.patch and old patch is here: http://garage.freebsd.pl/patches/md.c.2.patch I haven't prepare style patch, because I wasn't sure against which version of md.c it should be (original or with functional change). --=20 Pawel Jakub Dawidek pawel@dawidek.net UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net --+JUInw4efm7IfTNU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iQCVAwUBQAH37z/PhmMH/Mf1AQG/wwQAoLoPtIBY/nD7qWc7HJq3lX2jEK9HsOrK TbjoRQHuNVoDiSUmgQKi0rtrXsUczFax47+A5/yb02cnSHvghRA6TLw6dQ9a200W hat4bvU9GFRIDAO2h1YRxW6sITZR6q8cW0tcKCAYEQXVc+OxXnHct0jpn1DwsBjx OKVlXKLnR3c= =t0wy -----END PGP SIGNATURE----- --+JUInw4efm7IfTNU-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 08:48:04 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3B0116A4D0 for ; Sun, 11 Jan 2004 08:48:04 -0800 (PST) Received: from web12708.mail.yahoo.com (web12708.mail.yahoo.com [216.136.173.245]) by mx1.FreeBSD.org (Postfix) with SMTP id 9429543D39 for ; Sun, 11 Jan 2004 08:48:02 -0800 (PST) (envelope-from topa_007@yahoo.com) Message-ID: <20040111164802.26287.qmail@web12708.mail.yahoo.com> Received: from [219.65.97.87] by web12708.mail.yahoo.com via HTTP; Sun, 11 Jan 2004 08:48:01 PST Date: Sun, 11 Jan 2004 08:48:01 -0800 (PST) From: 70uf33q Hu5541n To: "Daan Vreeken [PA4DAN]" In-Reply-To: <200401111406.41156.Danovitsch@Vitsch.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Sun, 11 Jan 2004 18:28:31 -0800 cc: hackers-freebsd@freebsd.org Subject: Re: FreeBSD 5.1 Installation probelms X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 16:48:05 -0000 hey Daan, :) I did use Partition mAgic 8 to resize the partition. PM8 resized the logical drive.Not the extended partition.SO though I have "unused" space on my HD, its locked away in the Extended Partition and not detected by F-BSD. Is it possible to resize the whole extended partition with PM8? Not a power-windows user, so havent used PM8 much. I hope the people behind FreeBSD could fix this problem. RedHat/other linux distros seem to use the free space perfectly fine. Also, does FreeBSD use FAT or ext2/3 partition? -just a doubt. cheers, TH --- "Daacn Vreeken [PA4DAN]" wrote: > On Sunday 11 January 2004 11:29, 70uf33q Hu5541n > wrote: > > hey guys, > > > > Just got my copy of FreeBSD 5.1. > > Spent about an hour going through the BSD Handbook > and > > preparing a Installation checklist. > > > > ok here's my problem. > > > > I have a WD 40 GB HDD > > the primary partition is 10 GB, with the extended > > partition 28 GB.(the rest 2 GB is in WD's bank). > > > > OK , the extended partition has 3 logical drives. > > To create a slice for BSD, I resized one of the > > logical drives to free up some space. About 1.2 > > GB,cause that's all I can spare. > > > > When I run the installation through CDROM, and the > > point where I'm to creat the Freebsd slice,the new > > partition is not displayed in the "FDISK" utility. > > > > All I get is the primary (10GB) and the whole > Extended > > (28 GB). > > The freespace I guess is "locked into" the > Extended > > Partiton. Not sure though. > Indeed you first have to resize the extended > partition before you can use the > space to create slices. The "fdisk" program that > comes with Windows has no > way to do this (except deleting all logicle drives > in the extended partition > and re-creating them). Have a look at the program > "Partition Magic". It can > resize partitions and it has a nice user interface. > > grtz, > Daan > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" ===== "Love is control,I'll die if I let go I will only let you breathe My air that you receive Then we'll see if I let you love me." -James Hetfield All Within My Hands,St.Anger Metallica __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 10:09:10 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C5FD16A4CE; Sun, 11 Jan 2004 10:09:10 -0800 (PST) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE50043D1D; Sun, 11 Jan 2004 10:09:08 -0800 (PST) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.10/8.12.10) with ESMTP id i0BI97v9064120; Sun, 11 Jan 2004 13:09:07 -0500 (EST) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.10/8.12.10/Submit) id i0BI97tD064119; Sun, 11 Jan 2004 13:09:07 -0500 (EST) (envelope-from barney) Date: Sun, 11 Jan 2004 13:09:07 -0500 From: Barney Wolff To: Poul-Henning Kamp Message-ID: <20040111180907.GA63647@pit.databus.com> References: <20040111120824.00cb6314@Magellan.Leidinger.net> <9729.1073819616@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9729.1073819616@critter.freebsd.dk> User-Agent: Mutt/1.5.5.1i X-Scanned-By: MIMEDefang 2.39 X-Mailman-Approved-At: Sun, 11 Jan 2004 18:28:31 -0800 cc: Greg 'groggy' Lehey cc: Alexander Leidinger cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 18:09:10 -0000 On Sun, Jan 11, 2004 at 12:13:36PM +0100, Poul-Henning Kamp wrote: > In message <20040111120824.00cb6314@Magellan.Leidinger.net>, Alexander Leidinge > r writes: > > >I'm a little bit confused. I've read Pouls mail as an suggestion to > >remove vinum from -current and let people modify it in the perforce > >repository. If I got this wrong, please tell me and everything is fine, > >but if I got it right, do you (Greg) agree to remove it from -current? > > My proposal is to do just that with both vinum and raidframe until > one or possibly both are up to full strength again. On behalf of people like me who are mere users, let me protest that removing vinum would break working systems and create needless hardship. What would be gained? Are there upcoming changes in the rest of the OS that the presence of vinum would make harder? If not, then please branch vinum to perforce if you like, but leave it in -current until it's actually broken for most users, which is not the case now. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 12:36:08 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC8D116A4CE; Sun, 11 Jan 2004 12:36:08 -0800 (PST) Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF99343D55; Sun, 11 Jan 2004 12:36:06 -0800 (PST) (envelope-from wegster@mindcore.net) Received: from mindcore.net (rdu162-234-100.nc.rr.com [24.162.234.100]) i0BKa2KY001104; Sun, 11 Jan 2004 15:36:03 -0500 (EST) Message-ID: <4001B3B2.8080504@mindcore.net> Date: Sun, 11 Jan 2004 15:36:02 -0500 From: Scott W User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20031129 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Gilbert References: <20040111051649.GK7617@wantadilla.lemis.com> <6552.1073813519@critter.freebsd.dk> <16385.44645.936069.15441@canoe.dclg.ca> In-Reply-To: <16385.44645.936069.15441@canoe.dclg.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Mailman-Approved-At: Sun, 11 Jan 2004 18:28:31 -0800 cc: hackers@FreeBSD.org cc: current@FreeBSD.org Subject: Re: Future of RAIDFrame and Vinum X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 20:36:09 -0000 David Gilbert wrote: >>>>>>"Poul-Henning" == Poul-Henning Kamp writes: >>>>>> >>>>>> > >Poul-Henning> In message <20040111051649.GK7617@wantadilla.lemis.com>, >Poul-Henning> "Greg 'groggy' Lehey" writes: > >Poul-Henning> The reason I say this is that neither of you have the >Poul-Henning> time needed, and whoever picks up may have ideas, even >Poul-Henning> necesarry ideas, which would grind your spine seriously. >Poul-Henning> By letting go, I think you would give vinum a better >Poul-Henning> chance. > > > >>>>In the p4 tree, we can easier add new talent to our developer >>>>force and I am pretty sure that some sort of merry band of >>>>developers would form around both RF and vinum there. >>>> >>>> > >... now I thought I followed this list relatively well, but can >someone point me at what 'p4' is? > >Dave. > > > p4 = perforce source control. I'd seen the perforce depot somewhere on freebsd's sites, but didn't previous to this discussion understand it's purpose. Someone with more of a clue than I can fill in the blanks, but it seems that the perforce depot is essentially open-access, (unlike needing the commit bit set in FreeBSDs CVS tree), or at least easier to get commit privs assigned, allowing people that are not currently FreeBSD commiters to contribute changes back to the repository...at some point, presumably, to be rolled back into the main development branch of FreeBSD by integrating back into CVS....if a project at some point becomes 'release-worthy.' More info on perforce is available at www.perforce.com . I saw someone mention in this thread not liking perforce, although I'm not sure why- I used to be pretty heavily involved in SCM/DTS, and perforce IMHO was/is one of the few SCMs that generally 'did the right thing' in a usually unobtrusive way. Scott From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 13:35:41 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB82016A4CE for ; Sun, 11 Jan 2004 13:35:41 -0800 (PST) Received: from redqueen.elvandar.org (cust.94.120.adsl.cistron.nl [195.64.94.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id E40D343D2D for ; Sun, 11 Jan 2004 13:35:11 -0800 (PST) (envelope-from avinash@piare.org) Received: from elvandar.org (elvandar.serverfarm.elvandar.intranet [192.168.180.122]) by redqueen.elvandar.org (Postfix) with SMTP id 3613B2B4D6F for ; Sun, 11 Jan 2004 22:35:07 +0100 (CET) Received: from tomas.elvandar.intranet (tomas.elvandar.intranet [10.0.2.128]) by mail.evilcoder.org (Horde) with HTTP for ; Sun, 11 Jan 2004 22:35:06 +0100 Date: Sun, 11 Jan 2004 22:35:06 +0100 From: Avinash Piare To: Remko Lodder References: <20040111204714.8B5F034A@mail.elvandar.org> In-Reply-To: <20040111204714.8B5F034A@mail.elvandar.org> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit Message-Id: <20040111213507.3613B2B4D6F@redqueen.elvandar.org> X-Mailman-Approved-At: Sun, 11 Jan 2004 18:28:31 -0800 cc: "Daan Vreeken \[PA4DAN\]" cc: FreeBSD-hackers@FreeBSD.org cc: 70uf33q Hu5541n Subject: RE: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 21:35:42 -0000 Hi, I had a similair problem as Remko described. I used R-Linux. U can download it from http://www.r-tt.com Put the hard drive, on which u can't reach the certain partition, in a pc with Windows installed on it, run R-Linux and u should be able to see the drive and partition that u couldn't read. Good luck ! Avinash Piare ----------------------- M avinash@piare.org, piare01@ie.hva.nl Citeren Remko Lodder : > Sorry to interupt, > > but i think that person x, since he has a weird name ;-) , > means that the partitioning device of freebsd cannot access the extended > partition > at all. > > I had this with a friend of mine, and we could not access the devices > anymore since it was > packed inside another partition (we migrated from linux to freebsd) > We needed to use a bit of software that could re-enable our partition. > Perhaps Avinash can reply with the software name/ > > Also it is possible that your partition is held inside another one, > > how to resolve? No idea, i always started with a clean hdd, or a new one > when the current on needed to be saved. > > Hope it helped a little. > Cheers > > > -- > > Kind regards, > > Remko Lodder > Elvandar.org/DSINet.org > www.mostly-harmless.nl Dutch community for helping newcomers on the > hackerscene > > -----Oorspronkelijk bericht----- > Van: freebsd-hackers-bounces@lists.elvandar.org > [mailto:freebsd-hackers-bounces@lists.elvandar.org]Namens Daan Vreeken > [PA4DAN] > Verzonden: zondag 11 januari 2004 14:07 > Aan: 70uf33q Hu5541n > CC: FreeBSD-hackers@FreeBSD.org > Onderwerp: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms > > > On Sunday 11 January 2004 11:29, 70uf33q Hu5541n wrote: > > hey guys, > > > > Just got my copy of FreeBSD 5.1. > > Spent about an hour going through the BSD Handbook and > > preparing a Installation checklist. > > > > ok here's my problem. > > > > I have a WD 40 GB HDD > > the primary partition is 10 GB, with the extended > > partition 28 GB.(the rest 2 GB is in WD's bank). > > > > OK , the extended partition has 3 logical drives. > > To create a slice for BSD, I resized one of the > > logical drives to free up some space. About 1.2 > > GB,cause that's all I can spare. > > > > When I run the installation through CDROM, and the > > point where I'm to creat the Freebsd slice,the new > > partition is not displayed in the "FDISK" utility. > > > > All I get is the primary (10GB) and the whole Extended > > (28 GB). > > The freespace I guess is "locked into" the Extended > > Partiton. Not sure though. > Indeed you first have to resize the extended partition before you can use > the > space to create slices. The "fdisk" program that comes with Windows has no > way to do this (except deleting all logicle drives in the extended partition > and re-creating them). Have a look at the program "Partition Magic". It can > resize partitions and it has a nice user interface. > > grtz, > Daan > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > _______________________________________________ > Freebsd-hackers mailing list > Freebsd-hackers@lists.elvandar.org > http://lists.elvandar.org/mailman/listinfo/freebsd-hackers > > ------------------ Email provided by elvandar.org Email remko@elvandar.org for an address From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 17:19:25 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDA3116A4CE; Sun, 11 Jan 2004 17:19:25 -0800 (PST) Received: from mail.npubs.com (mail.npubs.com [209.66.100.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75DB343D62; Sun, 11 Jan 2004 17:19:24 -0800 (PST) (envelope-from nielsen@memberwebs.com) Resent-Message-Id: From: Nielsen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org;, freebsd-hackers@freebsd.org X-Enigmail-Version: 0.82.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <20040112011942.C78B6840128@mail.npubs.com> Resent-Date: Mon, 12 Jan 2004 01:19:43 +0000 (GMT) Resent-From: nielsen@memberwebs.com (Postfix Filters) X-Mailman-Approved-At: Sun, 11 Jan 2004 18:28:31 -0800 Subject: Gratituous ARP and the em driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Mon, 12 Jan 2004 01:19:25 -0000 X-List-Received-Date: Mon, 12 Jan 2004 01:19:25 -0000 When I change IP addresses on my 'em' gigabit NIC, ARP isn't sent properly. This appears to be the problem in the following bug report, however i'm using the 'fixed' version of the em driver (in FreeBSD 4.9). http://www.freebsd.org/cgi/query-pr.cgi?pr=54488 Does anyone have any tips on how to get around this? I'm building new systems with gigabit ethernet support and this problem keeps cropping up. I have a failover system, and when moving an IP alias between machines, the em NIC driver doesn't properly send out gratituous ARP, resulting in the IP being inaccessible. - The problem does not occur when plugged into a 100BaseTX switch - FreeBSD 4.9p1 / em version 1.7.16 - Tried various gigabit switches. - One other odd thing is that when configuring the NIC (ifconfig) the machine locks up for several seconds. Thanks in advance. Nate From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 17:56:42 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B72116A4CE for ; Sun, 11 Jan 2004 17:56:42 -0800 (PST) Received: from obsecurity.dyndns.org (adsl-67-119-53-122.dsl.lsan03.pacbell.net [67.119.53.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B44443D3F for ; Sun, 11 Jan 2004 17:56:41 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id EC6B966C4F; Sun, 11 Jan 2004 17:56:40 -0800 (PST) Date: Sun, 11 Jan 2004 17:56:40 -0800 From: Kris Kennaway To: giffunip@asme.org Message-ID: <20040112015640.GA4832@xor.obsecurity.org> References: <20040110170550.34302.qmail@web13425.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: <20040110170550.34302.qmail@web13425.mail.yahoo.com> User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Sun, 11 Jan 2004 18:28:31 -0800 cc: freebsd-hackers@freebsd.org Subject: Re: SCM options (was Re: Where is FreeBSD going?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 01:56:42 -0000 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 10, 2004 at 09:05:50AM -0800, Pedro F. Giffuni wrote: > I think we must wait until a 1.0 version is available.=20 >=20 > SVN is meant to be a replacement to CVS. The projects repository is using > perforce which happens to be a good tool, so moving it to svn is probably= not a > step forward IMHO ;-). No, the projects/ repository is in CVS. There's also a perforce repository that people use for development work, but it's not what Garance was talking about. Kris --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAAf7YWry0BWjoQKURAsAAAJ0U3ByIUHngacQqB0qgsEeb5PgMHgCg8dI+ E5EC4sf+DUKb4i4s/2MUf/8= =eh6x -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 20:10:38 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 589C216A4CE for ; Sun, 11 Jan 2004 20:10:38 -0800 (PST) Received: from web12704.mail.yahoo.com (web12704.mail.yahoo.com [216.136.173.241]) by mx1.FreeBSD.org (Postfix) with SMTP id 729FA43D2F for ; Sun, 11 Jan 2004 20:10:36 -0800 (PST) (envelope-from topa_007@yahoo.com) Message-ID: <20040112041036.61633.qmail@web12704.mail.yahoo.com> Received: from [61.2.224.42] by web12704.mail.yahoo.com via HTTP; Sun, 11 Jan 2004 20:10:36 PST Date: Sun, 11 Jan 2004 20:10:36 -0800 (PST) From: 70uf33q Hu5541n To: toufeeq@ee.com In-Reply-To: <20040111213507.3613B2B4D6F@redqueen.elvandar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-hackers@freebsd.org Subject: RE: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms !-==solved==-! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 04:10:38 -0000 whew! Gentlemen, its done, freeBSD 5.1 has been installed.PartitionMagic 8 did the trick though :( sad that I had to use windows. anyway, this is what I did.(Daan deserves credit) 1.free disk space at the last logical drive of the extended partition. 2.resize the last logical drive to create unallocated space. 3.*here's the best part* Resize the Extended partition such that the unallocated part gets left out completely. 4.thats all, apply changes. please excuse me, I havent slept in 2 days and maybe I'm displaying bursts of euphoria. :D was hard though, but enjoyed every bit of it.Had to go through documentation about disk geometry,inodes and what not... anyway I'm thrilled. X config and all the rest was a breeze. setup GNOME , looks good. all set for a great ride. Thanks to Daan, Remko and Avinash couldnt have done it without you guys. ok think I'll stop. ;) cheers, toufeeq Its 9:30 am here, and I think I better go to sleep now cause the monitor seems to be spining around my head.just wanted to tell u guys about it. --- Avinash Piare wrote: > Hi, > > I had a similair problem as Remko described. I used > R-Linux. U can download it > from http://www.r-tt.com > > Put the hard drive, on which u can't reach the > certain partition, in a pc with > Windows installed on it, run R-Linux and u should be > able to see the drive and > partition that u couldn't read. > > Good luck ! > > Avinash Piare > ----------------------- > M avinash@piare.org, piare01@ie.hva.nl > > > Citeren Remko Lodder : > > > Sorry to interupt, > > > > but i think that person x, since he has a weird > name ;-) , > > means that the partitioning device of freebsd > cannot access the extended > > partition > > at all. > > > > I had this with a friend of mine, and we could not > access the devices > > anymore since it was > > packed inside another partition (we migrated from > linux to freebsd) > > We needed to use a bit of software that could > re-enable our partition. > > Perhaps Avinash can reply with the software name/ > > > > Also it is possible that your partition is held > inside another one, > > > > how to resolve? No idea, i always started with a > clean hdd, or a new one > > when the current on needed to be saved. > > > > Hope it helped a little. > > Cheers > > > > > > -- > > > > Kind regards, > > > > Remko Lodder > > Elvandar.org/DSINet.org > > www.mostly-harmless.nl Dutch community for helping > newcomers on the > > hackerscene > > > > -----Oorspronkelijk bericht----- > > Van: freebsd-hackers-bounces@lists.elvandar.org > > > [mailto:freebsd-hackers-bounces@lists.elvandar.org]Namens > Daan Vreeken > > [PA4DAN] > > Verzonden: zondag 11 januari 2004 14:07 > > Aan: 70uf33q Hu5541n > > CC: FreeBSD-hackers@FreeBSD.org > > Onderwerp: [Freebsd-hackers] Re: FreeBSD 5.1 > Installation probelms > > > > > > On Sunday 11 January 2004 11:29, 70uf33q Hu5541n > wrote: > > > hey guys, > > > > > > Just got my copy of FreeBSD 5.1. > > > Spent about an hour going through the BSD > Handbook and > > > preparing a Installation checklist. > > > > > > ok here's my problem. > > > > > > I have a WD 40 GB HDD > > > the primary partition is 10 GB, with the > extended > > > partition 28 GB.(the rest 2 GB is in WD's bank). > > > > > > OK , the extended partition has 3 logical > drives. > > > To create a slice for BSD, I resized one of the > > > logical drives to free up some space. About 1.2 > > > GB,cause that's all I can spare. > > > > > > When I run the installation through CDROM, and > the > > > point where I'm to creat the Freebsd slice,the > new > > > partition is not displayed in the "FDISK" > utility. > > > > > > All I get is the primary (10GB) and the whole > Extended > > > (28 GB). > > > The freespace I guess is "locked into" the > Extended > > > Partiton. Not sure though. > > Indeed you first have to resize the extended > partition before you can use > > the > > space to create slices. The "fdisk" program that > comes with Windows has no > > way to do this (except deleting all logicle drives > in the extended partition > > and re-creating them). Have a look at the program > "Partition Magic". It can > > resize partitions and it has a nice user > interface. > > > > grtz, > > Daan > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > > _______________________________________________ > > Freebsd-hackers mailing list > > Freebsd-hackers@lists.elvandar.org > > > http://lists.elvandar.org/mailman/listinfo/freebsd-hackers > > > > > > ------------------ > Email provided by elvandar.org > Email remko@elvandar.org for an address > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" ===== "Love is control,I'll die if I let go I will only let you breathe My air that you receive Then we'll see if I let you love me." -James Hetfield All Within My Hands,St.Anger Metallica __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 22:32:30 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC2ED16A4CE; Sun, 11 Jan 2004 22:32:30 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB7CD43D41; Sun, 11 Jan 2004 22:32:28 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i0C6WQOl022703; Mon, 12 Jan 2004 07:32:26 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Narvi From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 12 Jan 2004 01:18:39 +0200." <20040112011539.S32387-100000@haldjas.folklore.ee> Date: Mon, 12 Jan 2004 07:32:26 +0100 Message-ID: <22702.1073889146@critter.freebsd.dk> cc: Greg 'groggy' Lehey cc: Alexander Leidinger cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 06:32:31 -0000 In message <20040112011539.S32387-100000@haldjas.folklore.ee>, Narvi writes: >oh yes - and please fix disklabel to support an arbirtary number of file >system per a "disk" or "slice" in the process, because otherwise it will >not be converting many setups. We need to move to a different labeling format because bsdlabel has a number of problems going forward. GPT is our current candidate. -- 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. From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 22:33:37 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04B8A16A4CE; Sun, 11 Jan 2004 22:33:37 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01BD143D55; Sun, 11 Jan 2004 22:33:35 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i0C6XOOl022742; Mon, 12 Jan 2004 07:33:24 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 11 Jan 2004 22:35:28 +0100." Date: Mon, 12 Jan 2004 07:33:24 +0100 Message-ID: <22741.1073889204@critter.freebsd.dk> cc: hackers@freebsd.org cc: current@freebsd.org cc: dgilbert@dclg.ca Subject: Re: Future of RAIDFrame X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 06:33:37 -0000 In message , Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= writes: >"M. Warner Losh" writes: >> Maybe this would be a good test-case for seeing how well it works? >> Maybe not. We do need to run a few more test-cases for things through >> this scenario... I'm not sure this one is well suited to it. > >If we toss out Vinum, there's a significant risk that 5.3 will ship >without RAID support at all. I'm pretty certain we don't want that. If we don't do something drastic, there's a significant risk that 5.3 and all future releases will ship with partially broken RAID support. I'm pretty certain we don't want that either. -- 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. From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 22:40:37 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B65D516A4CE for ; Sun, 11 Jan 2004 22:40:37 -0800 (PST) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 032D543D49 for ; Sun, 11 Jan 2004 22:40:34 -0800 (PST) (envelope-from doconnor@gsoft.com.au) Received: from chowder.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.9/8.12.8) with ESMTP id i0C6eTQ9092538; Mon, 12 Jan 2004 17:10:30 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Vladimir Terziev , hackers@freebsd.org Date: Mon, 12 Jan 2004 17:10:28 +1030 User-Agent: KMail/1.5.4 References: <20040109180305.18c23192.vlady@sun-fish.com> In-Reply-To: <20040109180305.18c23192.vlady@sun-fish.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401121710.28179.doconnor@gsoft.com.au> X-Spam-Score: -3.6 () CARRIAGE_RETURNS,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) Subject: Re: UNIX / BSD parallel port programming documentation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 06:40:37 -0000 On Saturday 10 January 2004 02:33, Vladimir Terziev wrote: > I have to develop small server which has to manage custom microcontroller > via parallel port interface. > > Does anyone know good manual/documentation about UNIX / BSD parallel port > programming ? Someone mentioned the ppi etc pages which is good, there is also this port - /usr/ports/devel/avrprog - which programs an Atmel AVR micro via the parallel port (works quite well in my experience) you should be able to examine the source code for clues. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 23:27:34 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A6A616A4CE for ; Sun, 11 Jan 2004 23:27:34 -0800 (PST) Received: from server.vk2pj.dyndns.org (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id D439343D55 for ; Sun, 11 Jan 2004 23:27:32 -0800 (PST) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1])i0C7RL7B065817; Mon, 12 Jan 2004 18:27:21 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.12.10/8.12.10/Submit) id i0C7RFSF065816; Mon, 12 Jan 2004 18:27:15 +1100 (EST) (envelope-from peter) Date: Mon, 12 Jan 2004 18:27:15 +1100 From: Peter Jeremy To: William Grim Message-ID: <20040112072715.GA65549@server.vk2pj.dyndns.org> References: <20040111161839.53EC788@toad.stack.nl> <4001A019.2030604@siue.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4001A019.2030604@siue.edu> User-Agent: Mutt/1.4.1i cc: freebsd-hackers@freebsd.org Subject: Re: Discussion on the future of floppies in 5.x and 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 07:27:34 -0000 On Sun, Jan 11, 2004 at 01:12:25PM -0600, William Grim wrote: >If it's really such a big deal to get rid of floppy support, how about >we get rid of it and make sure an older version of FreeBSD 4.x/5.x is >always available for download? This way, floppy users could install an >older version of the OS and cvsup to the latest version they want. 1) CVSup isn't an option for someone who wants to install a binary distribution and not have to do a buildworld. 2) Across major releases, "make world" is only defined for an up to date -STABLE to -CURRENT. Crossing multiple major releases isn't supported. 3) It's common for major releases to recommend a reinstall. 5.x is the current case-in-point: a reinstall allows upgrading to UFS2. 4) Bare-metal restores become very painful if you have to do a reversion and upgrade - especially if you want to use features that don't exist in the "older" version. 5) The "older version would need to be continuously upgraded with security fixes. Would you feel safe with instructions that said (in essence) "Install FreeBSD 2.2.8 and then CVSup to 6.x" when 2.2.8 was missing 5 years of security patches. Peter From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 01:13:32 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 719F016A4CE; Mon, 12 Jan 2004 01:13:32 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id C854243D45; Mon, 12 Jan 2004 01:13:29 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i0C9DROl033571; Mon, 12 Jan 2004 10:13:27 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: "Greg 'groggy' Lehey" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 11 Jan 2004 15:46:49 +1030." <20040111051649.GK7617@wantadilla.lemis.com> Date: Mon, 12 Jan 2004 10:13:27 +0100 Message-ID: <33570.1073898807@critter.freebsd.dk> cc: hackers@FreeBSD.org cc: Scott Long cc: current@FreeBSD.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 09:13:32 -0000 In message <20040111051649.GK7617@wantadilla.lemis.com>, "Greg 'groggy' Lehey" >> As much as I would hate to see RF and Vinum disappar from our >> source tree, maybe what we need to do is to kick them both into >> "training-camp" in p4 while you and Greg look the other way. > >Hmm. I can't see why they have to disappear from the source tree, [...] I forgot to mention on rather important factor in this equation: If nothing happens, vinum is going to break even more very soon. The plan for the cleanup of the buffer cache, such as we drew it up at BSDcon, says that filesystems will go directly to GEOM for disk service rather than detour through the vnode layer, SPECFS and then to GEOM. (This is not a matter of our choice of bike-shed color, this is a matter of SMP performance, locking sanity and buf/VM performance.) The first step of this has actually happened with the swap_pager which now goes directly to GEOM, and that is why you cannot put your swapspace on a vinum volume any more. The next target is UFS. The softupdates and snapshot support, because of the way the buffer cache interacts with SPECFS, has callback hooks in SPECFS which do not belong there. The next step is to move UFS to go directly to GEOM and at the same time pull the callbacks out of SPECFS and into UFS (FFS really) where they belong. Once I proceed with that step, you cannot mount UFS on a vinum volume. After that, the rest of the filesystems will follow, one by one. The question in my mind is: What if vinum is not fixed by then ? If it is decided to leave vinum in the CVS tree at this point in time, do we all agree and accept that if not fixed by then, vinum gets disconnected from the build when we proceed with the buffer cache cleanup ? To give an idea about the relative urgency, we are probably talking february or march this year. Poul-Henning -- 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. From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 01:31:06 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 855EC16A4CE for ; Mon, 12 Jan 2004 01:31:06 -0800 (PST) Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84CB843D55 for ; Mon, 12 Jan 2004 01:31:03 -0800 (PST) (envelope-from a.j.dejong-1@student.utwente.nl) Received: from klaptop.student.utwente.nl (allin.adsl.utwente.nl [130.89.226.84])i0C9TdS22908 for ; Mon, 12 Jan 2004 10:29:39 +0100 Message-Id: <5.1.0.14.0.20040112101357.08813748@130.89.1.29> X-Sender: s0027294@130.89.1.29 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 12 Jan 2004 10:29:39 +0100 To: freebsd-hackers@freebsd.org From: Arvid Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean Subject: Wacom Graphire3 USB Tablet and FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 09:31:06 -0000 Hello people, I have a bit of a problem to get my Wacom Graphire3 (USB) to work with FreeBSD. At first I thought I was doing something wrong, but it seems that FreeBSD doesnt understand it. I know it works with OpenBSD and NetBSD, and that it probably is due to uhid.c http://fxr.watson.org/fxr/source/dev/usb/uhid.c?v=RELENG51 I was really surprised that it works on the two other BSDs, if I had known that before I probably would've installed one of them. But now my FreeBSD is pretty much set up(about everything else works now), so I give it another try. It only works since about 1-2 weeks on NetBSD, I found the story behind that, and wrote the guy responsible for that about it. He gave me some hints, you can find what he wrote, and what I tried before in (and it the parent message) Message-ID: or on google: http://groups.google.com/groups?selm=slrnbvrd54.9hq.nospam%40hennep.adsl.utwente.nl What I want to know is, is it possible to just replace the uhid.c from FreeBSD by the one from Net- or OpenBSD? I dont think so, but if so, thats an easy try. Otherwise I'm looking for someone that knows C, and wants to look at uhid.c. I obviously dont know C, nor any other programming language. If its probably a better idea to install OpenBSD, I'd like to hear that too ;-) Regards, Arvid de Jong, Enschede, Netherlands (I am on IRCnet as arvid, and my ICQ is 14006518) From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 02:00:42 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B319016A4CE; Mon, 12 Jan 2004 02:00:42 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1C2443D31; Mon, 12 Jan 2004 02:00:40 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i0CA0YOl078216; Mon, 12 Jan 2004 11:00:39 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Mark Linimon From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 12 Jan 2004 03:41:42 CST." <200401120341.42349.linimon@lonesome.com> Date: Mon, 12 Jan 2004 11:00:34 +0100 Message-ID: <78215.1073901634@critter.freebsd.dk> cc: Greg 'groggy' Lehey cc: hackers@FreeBSD.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 10:00:42 -0000 In message <200401120341.42349.linimon@lonesome.com>, Mark Linimon writes: >But, in the real world of software engineering, He Who Breaketh It, >Must Fixeth It. If we are talking paid jobs, yes, then you can make rules like that because with the salary you control resource allocation and prioritization. My real life experience show that such rules invariably give way to other factors when push comes to shove, but they're nice as a starting point until the real real world rears its ugly head. In a free software project, you can take any rule like that an put it anywhere you like, in any font, size and color of your choice and it still wont work. If there are not enough people willing and able to actively maintain vinum, and in particular to make it keep pace with the kernel infrastructure then we are only talking about _when_, not _if_ it will die. What about vinum and locking ? Is anybody working on getting vinun out from under Giant ? Any piece of software in FreeBSD needs a minimum critical mass of developers, and judging from the probelms, both RF and vinum are below that threshold. If vinum means a lot to you, you should do something to get it above that threshold: start debugging/coding, learn to code if need be, donate money so somebody else can code if you can't do anything else. -- 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. From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 03:23:18 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B460916A4CE; Mon, 12 Jan 2004 03:23:18 -0800 (PST) Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 928B543D64; Mon, 12 Jan 2004 03:23:17 -0800 (PST) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=danny) by cs.huji.ac.il with esmtp id 1Ag0A7-00082f-Cc; Mon, 12 Jan 2004 13:23:15 +0200 X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Robert Watson In-reply-to: Your message of Sun, 11 Jan 2004 11:41:17 -0500 (EST) . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jan 2004 13:23:15 +0200 From: Danny Braniss Message-Id: cc: hackers@freebsd.org Subject: Re: diskless problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 11:23:18 -0000 i re-applied the patches to the latest bootp.c, and took care not to botch up the tabs, but my user friendly emacs was not too helpful :-) (the diff is now about 500 lines) the PR is: http://www.freebsd.org/cgi/query-pr.cgi?pr=61239 thanks, danny > Sounds very interesting indeed. Could you: > > (1) Update it to bootp.c:1.5; this just removed 'register', and it looks > like you've already done that. > > (2) Restore the original file style -- right now, it's a very hard to read > diff because you use different tabbing, function prototypes, etc, so > it's hard to isolate and read the changes. There's probably some room > for style convergence (new function prototypes), but we have a > long-standing tradition of committing style and functional chaanges > separately so cvs diff is maximally useful between revisions. It > looks like the main difference is that you use four space tabs, and > the original file uses real tab characters. > > Then if you could file a PR and drop me the PR number by e-mail, that > would be great. I can do the style stuff if necessary, but I figured > since you're much more familiar with the changes, it might not be a bad > idea if you did it :-). > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Senior Research Scientist, McAfee Research > From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 03:39:20 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C3F2C16A4CE for ; Mon, 12 Jan 2004 03:39:20 -0800 (PST) Received: from ns.mmk.ru (ns1.mmk.ru [195.54.3.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33BC743D39 for ; Mon, 12 Jan 2004 03:39:15 -0800 (PST) (envelope-from freebsd@mmk.ru) Received: from antivirus.mmk.ru (antivirus [161.8.100.3]) by ns.mmk.ru (8.12.9p2/8.12.9) with ESMTP id i0CBbZQE001130 for ; Mon, 12 Jan 2004 16:37:35 +0500 (YEKT) (envelope-from freebsd@mmk.ru) Received: from wall.mmk.ru (localhost [127.0.0.1]) by antivirus.mmk.ru (8.12.9/8.12.9) with ESMTP id i0CBbTGr018368 for ; Mon, 12 Jan 2004 16:37:29 +0500 (YEKT) Received: from wall (localhost [127.0.0.1]) by wall.mmk.ru (8.12.9p2/8.12.9) with SMTP id i0CBYFks063334 for ; Mon, 12 Jan 2004 16:34:15 +0500 (YEKT) (envelope-from freebsd@mmk.ru) Message-ID: <025201c3d911$96325be0$02010101@wall> From: "Dmitry A. Bondareff" To: Date: Mon, 12 Jan 2004 16:39:04 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Upgrade from 4.9 to 5.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 11:39:21 -0000 Hello hackers! Help to understand problem. I have FreeBSD 4.9 on my box. # uname -a FreeBSD wall.ru 4.9-RELEASE-p1 FreeBSD 4.9-RELEASE-p1 #24 I've tried to Upgrade it to 5.1 # cvsup /etc/cvsupfile # cd /usr/src # make buildworld .................... .................... =3D=3D=3D> lib/libpam/modules/pam_krb5 rm -f .depend mkdep -f .depend -a = -I/usr/src/lib/libpam/modules/pam_krb5/../../../../contrib/openpam/i nclude -I/usr/src/lib/libpam/modules/pam_krb5/../../libpam = /usr/src/lib/libpam/modules/pam _krb5/pam_krb5.c *** Error code 1 Stop in /usr/src/lib/libpam/modules/pam_krb5. *** Error code 1 Stop in /usr/src/lib/libpam/modules. *** Error code 1 Stop in /usr/src/lib/libpam. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. How to resolve this problem. Thanks. Dmitry Bondareff. From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 04:44:53 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A87E16A4CE; Mon, 12 Jan 2004 04:44:53 -0800 (PST) Received: from milla.ask33.net (milla.ask33.net [217.197.166.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44EEE43D48; Mon, 12 Jan 2004 04:44:38 -0800 (PST) (envelope-from nick@milla.ask33.net) Received: by milla.ask33.net (Postfix, from userid 1001) id CB6063ABB53; Mon, 12 Jan 2004 13:45:21 +0100 (CET) Date: Mon, 12 Jan 2004 13:45:21 +0100 From: Pawel Jakub Dawidek To: Miguel Mendez Message-ID: <20040112124521.GE74246@garage.freebsd.pl> References: <40007D14.6090205@freebsd.org> <400135EA.8050603@energyhq.es.eu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="kHRd/tpU31Zn62xO" Content-Disposition: inline In-Reply-To: <400135EA.8050603@energyhq.es.eu.org> X-PGP-Key-URL: http://garage.freebsd.pl/jules.asc X-OS: FreeBSD 4.8-RELEASE-p13 i386 X-URL: http://garage.freebsd.pl User-Agent: Mutt/1.5.1i cc: hackers@freebsd.org cc: Scott Long cc: current@freebsd.org Subject: Re: Future of RAIDFrame X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 12:44:53 -0000 --kHRd/tpU31Zn62xO Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 11, 2004 at 12:39:22PM +0100, Miguel Mendez wrote: +> >I started RAIDframe three years ago with the hope of bringing a proven +> >and extensible RAID stack to FreeBSD. Unfortunately, while it was made +> >to work pretty well on 4.x, it has never been viable on 5.x; it never +> >survived the introduction of GEOM and removal of the old disk layer. +> >I'm coming to the conclusion that I really don't have the time to work +> >on it in my spare time. Also, I've seen next to zero interest in it +> >from others, except for the occasional reminder that it doesn't work. +>=20 +> William Carrel used to maintain a set of patches for RAIDframe on 4.x,= =20 +> were they ever committed? No? Why not? +>=20 +> WRT lack of interest in RF. First, the 5.0 patches were horrible. That= =20 +> code was a mess to work with. Second, inertia. Most people with simple= =20 +> needs like mirroring and/or simple stripes were happy with good old=20 +> ccd(4). Those who needed a full volume manager (which neither ccd nor RF= =20 +> claim to be) used vinum. People with VxVM experience feel at home with= =20 +> it. Unfortunately, vinum has its own set of issues as well. +>=20 +> It's probably easier to write a set of GEOM classes from scratch than=20 +> trying to shoehorn RF into GEOM. And that's what I'm doing. I'm working on one geom class (called for now geom_raid) which will support transformations like: concatenation, stripe (raid0), mirror (raid1), raid4 and raid5. The main goal is to prepare driver-independent configuration description that will fit to as many existing ondisk metadata formats as possible. So on one axis we got transformations and on another we got different types of on-disk metadata formats. Work is going forward, but slow, because of leak of time of course. For now I got concatenation and stripe working and I'm sitting on raid5 implementation right now. I know now that after raid5 will be implemented I'll have raid4 working as well (it fits to raid5 description). Last step (in transformations) will be raid1. It will be great if RF could be fixed and I'm still wondering to help with it or just focus on my geom_raid. RF implementation is complex and it will take some time to well understand it in first way. Reverse-engineering is time-consuming. I'm opened for suggestions. If Scott is sure and determined to reanimate RF and help me to understand RF I think I can help. --=20 Pawel Jakub Dawidek pawel@dawidek.net UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net --kHRd/tpU31Zn62xO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iQCVAwUBQAKW4T/PhmMH/Mf1AQFhrgQAmPYmLOwu+daWoZUbhn6+GQAuucy3+0I2 NeC2Diqk3RB5NngNsyTYEYbu/GLp+qJOBY3DpxhQD311XnxdDmBo/tf6pFHs9S5t DwfezHdWSgO+edSpbLt+xx6S4yJxtuY/SDOIIltzrXzioL6kpGy2vJKc6eWq6ni/ BIObyehDzKI= =sxPT -----END PGP SIGNATURE----- --kHRd/tpU31Zn62xO-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 04:48:32 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 676C016A4CE for ; Mon, 12 Jan 2004 04:48:32 -0800 (PST) Received: from mail.svenskabutiker.se (ns.svenskabutiker.se [212.247.101.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id B190D43D1D for ; Mon, 12 Jan 2004 04:48:30 -0800 (PST) (envelope-from martin@gneto.com) Received: from gneto.com (h118n1fls31o985.telia.com [213.65.16.118]) by mail.svenskabutiker.se (Postfix) with ESMTP id 8E8E7377AE; Mon, 12 Jan 2004 13:48:28 +0100 (CET) Message-ID: <4002979B.1070306@gneto.com> Date: Mon, 12 Jan 2004 13:48:27 +0100 From: Martin Nilsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <78215.1073901634@critter.freebsd.dk> In-Reply-To: <78215.1073901634@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: hackers@FreeBSD.org Subject: GEOM programming resources? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 12:48:32 -0000 Poul-Henning, do you have a list of GEOM programming info available so that one have something to start with for example to make Vinum compatible with GEOM. I read the GEOM manpage in 5.2, have looked at your webpage (http://people.freebsd.org/~phk) and have found a paper and some slides. Are there any more material available, I didn't find anything in the arch-handbook which is where I expected to find a detailed overview. The search function at FreeBSD.org comes up with a lot of hits but not many seems useful for programming. A list with links to emails etc about geom would be a nice addition to your freeBSD homepage. /Martin From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 05:07:37 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A674F16A4CE for ; Mon, 12 Jan 2004 05:07:37 -0800 (PST) Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D96543D45 for ; Mon, 12 Jan 2004 05:07:35 -0800 (PST) (envelope-from alsbergt@cs.huji.ac.il) Received: from cerium.cs.huji.ac.il ([132.65.80.122] ident=exim) by cs.huji.ac.il with esmtp id 1Ag1n3-000Ean-AQ; Mon, 12 Jan 2004 15:07:33 +0200 Received: from alsbergt by cerium.cs.huji.ac.il with local (Exim 4.12) id 1Ag1n3-00007q-00; Mon, 12 Jan 2004 15:07:33 +0200 Date: Mon, 12 Jan 2004 15:07:33 +0200 From: Tom Alsberg To: burawa Message-ID: <20040112130732.GB403@cs.huji.ac.il> Mail-Followup-To: Tom Alsberg , burawa , FreeBSD Hackers List References: <20040111114539.GA53691@cs.huji.ac.il> <000d01c3d8ea$aa4dacf0$e014a8c0@unitpnnem56cwm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000d01c3d8ea$aa4dacf0$e014a8c0@unitpnnem56cwm> X-Face: "5"j@Y1Peoz1; ftTv>\|['ox-csmV+:_RDNdi/2lSe2x?0:HVAeVW~ajwQ7RfDlcb^18eJ; t,O,s5-aNdU/DJ2E8h1s,..4}N9$27u`pWmH|; s!zlqqVwr9R^_ji=1\3}Z6gQBYyQ]{gd5-V8s^fYf{$V2*_&S>eA|SH@Y\hOVUjd[5eah{EO@gCr.ydSpJHJIU[QsH~bC?$C@O:SzF=CaUxp80-iknM(]q(W Subject: Re: Remote GDB online and kernel functions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 13:07:37 -0000 Well, I'll look into that in GDB somewhen, when I have time if nobody else has any idea... I tried four functions from three different areas of the kernel, and all crashed, so I didn't bother to try more... But I'll try more somewhen and see if I find functions which don't cause a panic... Thanks, -- Tom On Mon, Jan 12, 2004 at 05:01:28PM +0800, burawa wrote: > I am just suffering from such things in OpenBSD, it seems that it is > a bug of gdb, which has incorrect symbol relocation address when > calling some functions, so it may call an incorrect address of > subroutines, thus ... > I am not sure, but if I adjust link order of some .o when making > kernel, some functions which can not formerly be called from gdb > may now be called and work well -- Tom Alsberg - hacker (being the best description fitting this space) Web page: http://www.cs.huji.ac.il/~alsbergt/ DISCLAIMER: The above message does not even necessarily represent what my fingers have typed on the keyboard, save anything further. From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 01:42:29 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5942E16A4CE; Mon, 12 Jan 2004 01:42:29 -0800 (PST) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18E6B43D39; Mon, 12 Jan 2004 01:42:26 -0800 (PST) (envelope-from linimon@lonesome.com) Received: from lonesome.lonesome.com (cs242719-195.austin.rr.com [24.27.19.195]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.soaustin.net (Postfix) with ESMTP id 8DF661470F; Mon, 12 Jan 2004 03:42:25 -0600 (CST) From: Mark Linimon Organization: Lonesome Dove Computing Services To: "Poul-Henning Kamp" , "Greg 'groggy' Lehey" Date: Mon, 12 Jan 2004 03:41:42 -0600 User-Agent: KMail/1.5.4 References: <33570.1073898807@critter.freebsd.dk> In-Reply-To: <33570.1073898807@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401120341.42349.linimon@lonesome.com> X-Mailman-Approved-At: Mon, 12 Jan 2004 05:18:24 -0800 cc: hackers@FreeBSD.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 09:42:29 -0000 > I forgot to mention on rather important factor in this equation: Er, this is the *only* important factor. IMHO, it made most of the previous conversation be completely off-the-rails. > If nothing happens, vinum is going to break even more very soon. No ... if you do a commit that changes the code assumptions upon which vinum was built, vinum will break. vinum is not going to "magically" break by itself. This gets back to a problem with the FreeBSD development model: people who commit changes that break things in other parts of the system do not automatically get assigned the responsibility to fix them. Now, there's no way to impose something like that requirement on a cooperative anarchy, so I am not playing the "let's reorganize" card -- I think most of us would agree that "that dog won't hunt" as we say down around these parts. But, in the real world of software engineering, He Who Breaketh It, Must Fixeth It. Your mileage may vary. mcl From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 02:05:58 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93A2516A4CE; Mon, 12 Jan 2004 02:05:58 -0800 (PST) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDD3843D4C; Mon, 12 Jan 2004 02:05:57 -0800 (PST) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 9037F146F8; Mon, 12 Jan 2004 04:05:57 -0600 (CST) Date: Mon, 12 Jan 2004 04:05:57 -0600 (CST) From: Mark Linimon X-X-Sender: linimon@pancho To: Poul-Henning Kamp In-Reply-To: <78215.1073901634@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Mon, 12 Jan 2004 05:18:24 -0800 cc: Greg 'groggy' Lehey cc: Mark Linimon cc: hackers@FreeBSD.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 10:05:58 -0000 > If vinum means a lot to you, you should do something to get it above > that threshold: start debugging/coding, learn to code if need be, > donate money so somebody else can code if you can't do anything > else. I don't use vinum so I have no stake in this. OTOH I'm not announcing changes which will affect it, either, so the burden is not on me. I have stated my opinion as well as I can, and will now go back to working on things that I have a reasonable understanding of and chance to fix. mcl From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 05:23:39 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2192816A4CE for ; Mon, 12 Jan 2004 05:23:39 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2504F43D2F for ; Mon, 12 Jan 2004 05:23:34 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i0CDNQ2n002763; Mon, 12 Jan 2004 14:23:31 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Martin Nilsson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 12 Jan 2004 13:48:27 +0100." <4002979B.1070306@gneto.com> Date: Mon, 12 Jan 2004 14:23:26 +0100 Message-ID: <2762.1073913806@critter.freebsd.dk> cc: hackers@FreeBSD.org Subject: Re: GEOM programming resources? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 13:23:39 -0000 In message <4002979B.1070306@gneto.com>, Martin Nilsson writes: >I read the GEOM manpage in 5.2, have looked at your webpage >(http://people.freebsd.org/~phk) and have found a paper and some slides. I'm afraid that you have pretty much discovered what there is at this point in time. Kirk is updating the daemon-book, and the text I've seen about GEOM there is a very good overview. What's missing a this time is the document people like you would sit down and read and that has yet to be even started, and I would seriously doubt that it ever happens. (It's important to understand that writing a class for GEOM is not rocket science. It's new, yes, but not harder than anything else in the kernel.) I've tried to make geom classes of various sorts so there would be plenty for people to look at, depending on their application. In the case of vinum, the most applicable prior art is geom_ccd which does many of the same things. Basically, the way I would advocate you go about this is the following steps: 1. Add a geom_vinum class and get it to hook into GEOM (check the XML from "sysctl -b kern.geom.confxml" to see that it happens.) 2. Add a "taste function", and get it to recognize vinum metadata, and subsequently get autoconfiguration to work. (CCD doesn't have this, look instead in geom_mirror.c). 3. Make vinum use the consumers constructed in #2 to issue down-wards I/O requests. 4. Change the upper side of vinum to publish "providers" and service I/O requests on those instead of the current cdevsw. Don't be mislead by these four easy steps, there is a lot of stuff to do in vinum to get these done, a lot of then undoing things as Greg has already remarked, but if you do it in this order, GEOM will not be your biggest problem in this. -- 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. From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 05:51:37 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0D9216A4CE for ; Mon, 12 Jan 2004 05:51:37 -0800 (PST) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 031FC43D46 for ; Mon, 12 Jan 2004 05:51:25 -0800 (PST) (envelope-from marcolz@stack.nl) Received: from toad.stack.nl (zen.stack.nl [2001:610:1108:5010::130]) by mailhost.stack.nl (Postfix) with ESMTP id 4002A65B#A8ED01F00E; Mon, 12 Jan 2004 14:51:23 +0100 (CET) Received: by toad.stack.nl (Postfix, from userid 333) id 65A7F8E; Mon, 12 Jan 2004 14:51:23 +0100 (CET) Date: Mon, 12 Jan 2004 14:51:23 +0100 From: Marc Olzheim To: Daniel Eischen Message-ID: <20040112135123.GA41657@stack.nl> References: <20031231140533.GA56158@stack.nl> <20031231143015.GA59104@stack.nl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline In-Reply-To: <20031231143015.GA59104@stack.nl> X-Operating-System: FreeBSD toad.stack.nl 4.9-RC FreeBSD 4.9-RC X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.5.1i cc: Marc Olzheim cc: hackers@freebsd.org Subject: Re: libc_r/uthread/uthread_join.c and uthread_create.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 13:51:38 -0000 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Dec 31, 2003 at 03:30:15PM +0100, Marc Olzheim wrote: > So I noticed. But it seems to me as if the undefers could be removed > from within the if-else-blocks and collapsed into a single undefer just > beneath the if-else-blocks, right before the > _thread_leave_cancellation_point(); Hmm, this is just what OpenBSD did... Any way: new problem / idea: uthread_create.c: _pthread_create() doesn't clean ebp, so producing a backtrace, either with gdb, or with gcc's __builtin_frame_address(), results in garbage, cq. segmentation faults, when for instance the spawning thread has already been deleted. The following patch fixes that for i386. I don't have any other systems available, so I don't know what to do on other systems, but this works for us. Zlo --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="uthread_ebp.patch" --- /usr/src/lib/libc_r/uthread/pthread_private.h Tue Oct 22 16:44:02 2002 +++ /usr/src/lib/libc_r/uthread/pthread_private.h Mon Jan 12 14:34:32 2004 @@ -84,7 +84,8 @@ fdata = (char *) (ucp)->uc_mcontext.mc_fpregs; \ __asm__("frstor %0": :"m"(*fdata)); \ } while (0) -#define SET_RETURN_ADDR_JB(jb, ra) (jb)[0]._jb[0] = (int)(ra) +#define SET_RETURN_ADDR_JB(jb, ra) (jb)[0]._jb[0] = (int)(ra) +#define SET_FRAME_PTR_JB(jb, fp) (jb)[0]._jb[3] = (int)(fp) #elif defined(__alpha__) #include #define GET_STACK_JB(jb) ((unsigned long)((jb)[0]._jb[R_SP + 4])) --- /usr/src/lib/libc_r/uthread/uthread_create.c Wed Jan 8 06:04:26 2003 +++ /usr/src/lib/libc_r/uthread/uthread_create.c Mon Jan 12 14:23:56 2004 @@ -195,6 +195,7 @@ * _thread_start(). */ SET_RETURN_ADDR_JB(new_thread->ctx.jb, _thread_start); + SET_FRAME_PTR_JB(new_thread->ctx.jb, NULL); /* The stack starts high and builds down: */ SET_STACK_JB(new_thread->ctx.jb, --Kj7319i9nmIyA2yE-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 05:53:24 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EB4016A4D0 for ; Mon, 12 Jan 2004 05:53:24 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4ECFB43D2D for ; Mon, 12 Jan 2004 05:53:06 -0800 (PST) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id C55865489C; Mon, 12 Jan 2004 07:53:05 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id 52F466D45F; Mon, 12 Jan 2004 07:53:05 -0600 (CST) Date: Mon, 12 Jan 2004 07:53:05 -0600 From: "Jacques A. Vidrine" To: Colin Percival Message-ID: <20040112135305.GB94632@madman.celabo.org> References: <6.0.1.1.1.20040111174309.04327900@imap.sfu.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.1.1.1.20040111174309.04327900@imap.sfu.ca> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.4i-ja.1 cc: hackers@freebsd.org Subject: Re: binary files in src tree X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 13:53:24 -0000 On Sun, Jan 11, 2004 at 05:48:19PM +0000, Colin Percival wrote: > While browsing the FreeBSD src tree, I came across a number of > binary files (listed below); the regression tests are perhaps > understandable, but shouldn't the rest of these files be uuencoded? > > contrib/groff/doc/gnu.png > contrib/ipfilter/samples/ipfilter-pb.gif > contrib/sendmail/libmilter/docs/figure1.jpg > contrib/sendmail/libmilter/docs/figure2.jpg > crypto/openssh/regress/copy.1 > crypto/openssh/regress/copy.2 > crypto/openssh/scard/Ssh.bin > crypto/openssl/crypto/pkcs7/p7/a1 > crypto/openssl/crypto/pkcs7/p7/a2 > crypto/openssl/crypto/pkcs7/p7/cert.p7c > crypto/openssl/crypto/pkcs7/p7/smime.p7m > crypto/openssl/crypto/pkcs7/p7/smime.p7s > crypto/openssl/doc/openssl_button.gif > release/picobsd/tinyware/view/fbsd.png > tools/regression/usr.bin/file2c/regress.in > tools/regression/usr.bin/uudecode/regress.out > tools/regression/usr.bin/uuencode/regress.in > tools/tools/tinderbox/www/daemon.png > tools/tools/tinderbox/www/valid-css.png > tools/tools/tinderbox/www/valid-xhtml10.png > > Colin Percival Those that are found in src/contrib/ and src/crypto/, at least, should not be touched. However, it seems likely that some or all of them in that case are not actually used in FreeBSD. Those that are not used should perhaps be removed. I'll put reviewing the src/crypto/openssl/ cases on my todo list for the next import. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal nectar@celabo.org jvidrine@verio.net nectar@freebsd.org nectar@kth.se From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 06:25:44 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11EED16A4CE; Mon, 12 Jan 2004 06:25:44 -0800 (PST) Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AD6443D60; Mon, 12 Jan 2004 06:25:39 -0800 (PST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: from zibbi.icomtek.csir.co.za (localhost [IPv6:::1]) i0CEPVNJ017750; Mon, 12 Jan 2004 16:25:31 +0200 (SAST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.12.9/8.12.9/Submit) id i0CEPSpQ017749; Mon, 12 Jan 2004 16:25:28 +0200 (SAST) (envelope-from jhay) Date: Mon, 12 Jan 2004 16:25:28 +0200 From: John Hay To: Poul-Henning Kamp Message-ID: <20040112142528.GA15906@zibbi.icomtek.csir.co.za> References: <200401120341.42349.linimon@lonesome.com> <78215.1073901634@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78215.1073901634@critter.freebsd.dk> User-Agent: Mutt/1.4i cc: Greg 'groggy' Lehey cc: hackers@freebsd.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 14:25:44 -0000 On Mon, Jan 12, 2004 at 11:00:34AM +0100, Poul-Henning Kamp wrote: > In message <200401120341.42349.linimon@lonesome.com>, Mark Linimon writes: > > >But, in the real world of software engineering, He Who Breaketh It, > >Must Fixeth It. > > If we are talking paid jobs, yes, then you can make rules like that > because with the salary you control resource allocation and > prioritization. > ... > In a free software project, you can take any rule like that an put > it anywhere you like, in any font, size and color of your choice > and it still wont work. I don't think it is totally true. If a free software project have enough power to give and revoke commit bits and to make rules... They can have a rule like this: No committer may commit an API change in the kernel without also fixing the places that depend on it. The only exception is if he can get a majority vote that a certain section is not being used anymore and may be axed. Then if a developer comes with an API change, he must like it enough to do the work needed for it or motivate to the majority why a certain part have to be axed.... But then it is the group that decide and not him anymore. :-) John -- John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 07:04:12 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F08216A4CE; Mon, 12 Jan 2004 07:04:12 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77C1843D2D; Mon, 12 Jan 2004 07:04:10 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i0CF412n005612; Mon, 12 Jan 2004 16:04:08 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: John Hay From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 12 Jan 2004 16:25:28 +0200." <20040112142528.GA15906@zibbi.icomtek.csir.co.za> Date: Mon, 12 Jan 2004 16:04:01 +0100 Message-ID: <5611.1073919841@critter.freebsd.dk> cc: Greg 'groggy' Lehey cc: hackers@freebsd.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 15:04:12 -0000 In message <20040112142528.GA15906@zibbi.icomtek.csir.co.za>, John Hay writes: >> >But, in the real world of software engineering, He Who Breaketh It, >> >Must Fixeth It. >... >> In a free software project, you can take any rule like that an put >> it anywhere you like, in any font, size and color of your choice >> and it still wont work. > >I don't think it is totally true. If a free software project have >enough power to give and revoke commit bits and to make rules... N% of the work in FreeBSD is done by 100-N% of the committers, for some value of N. This fraction of people and new people inducted into that elite statistic are obviously rather crucial to the future of FreeBSD. If you insist on putting a rule down which make it impossible to work on any sort of infrastructure in the FreeBSD kernel without inheriting every single lump of code anybody ever managed to check into our CVS, then I think most people in this caliber can find better things to use their spare time on. Isolated features with a small user-communities, things like vinum, raidframe, appletalk, bluetooth, MAC and similar, needs to come with developer resources for its own maintenance, and vinum currently comes up short in this respect. _THAT_ is the problem we need solved, we don't need more arm-chair inspired pseudo-management rules for monkey-throwing. As you can hear, I am getting pretty sick and tired of the "Vinum is important to me and/or the project so _you_ have to fix it" refrain. I can tell you with 100% certainty, that no matter what I do, I will not be fixing vinum in my own spare time. If somebody wants to pay me to do it, then it is a different thing, I'll do anything for money (well... almost anything): contact me, my rates are very reasonable. And I will say it one last time: If you want vinum to have a future, you should rally behind whatever Greg organizes for the purpose of getting vinum into shape and contribute to that. That is the only way it will happen. In the mean time, FreeBSD needs to move forward with the SMPng work, even if that means breaking vinum further until Gregs team catches up. Poul-Henning -- 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. From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 07:13:01 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29A4B16A4CE for ; Mon, 12 Jan 2004 07:13:01 -0800 (PST) Received: from Vitsch.net (b74143.upc-b.chello.nl [212.83.74.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 914F243D49 for ; Mon, 12 Jan 2004 07:12:58 -0800 (PST) (envelope-from Danovitsch@Vitsch.net) Received: from FreeBSD.Danovitsch.LAN (b83007.upc-b.chello.nl [212.83.83.7]) by Vitsch.net (8.12.3p2/8.11.3) with ESMTP id i0CFCbXe067435 for ; Mon, 12 Jan 2004 16:12:37 +0100 (CET) (envelope-from Danovitsch@Vitsch.net) Content-Type: text/plain; charset="us-ascii" From: "Daan Vreeken [PA4DAN]" To: FreeBSD-hackers@FreeBSD.org Date: Mon, 12 Jan 2004 16:13:05 +0100 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200401121613.05238.Danovitsch@Vitsch.net> Subject: Release USB WLAN driver version 0.2 - testers wanted X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 15:13:01 -0000 Hi, Some time ago I released the first public version of my "atuwi" driver (f= or=20 Atmel usb wireless adapters). Since then I have made a lot of changes to = the=20 code and today it's time to release the next version... Version 0.2 features : * A nice step-by-step guide to installing and using the driver. * Support for both RFMD and Intersil radio parts.=20 * Support for Ad-hoc networks.=20 * Support for Infrastructure mode (currently in infrastructure mode only = 'open=20 system' authentication is implemented). * Setting the channel / SSID / WEP mode / WEP key / mac-addr via ifconfig= =2E * Automatic scanning and associating with a wireless network.=20 * BPF support for both DLT_EN10MB and DLT_IEEE802_11. * Improving the speed by issuing multiple transfers at the same time. * Decreasing processing overhead with what I would like to call "Lazy tra= nsmit=20 net-isr scheduling". If you happen to have a USB WLAN adapter or if you're just interrested in= my=20 usb-improvements, feel free have a look at the driver : http://vitsch.net/bsd/atuwi/ I'd be happy to hear any possitive / negative feedback. grtz, Daan From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 07:20:38 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A1F016A4CE; Mon, 12 Jan 2004 07:20:38 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 983D143D68; Mon, 12 Jan 2004 07:20:22 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i0CFIkUd065426; Mon, 12 Jan 2004 10:18:46 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i0CFIkqc065423; Mon, 12 Jan 2004 10:18:46 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 12 Jan 2004 10:18:45 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Mark Linimon In-Reply-To: <200401120341.42349.linimon@lonesome.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Greg 'groggy' Lehey cc: Poul-Henning Kamp cc: hackers@FreeBSD.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 15:20:38 -0000 On Mon, 12 Jan 2004, Mark Linimon wrote: > > If nothing happens, vinum is going to break even more very soon. > > No ... if you do a commit that changes the code assumptions upon which > vinum was built, vinum will break. vinum is not going to "magically" > break by itself. > > This gets back to a problem with the FreeBSD development model: people > who commit changes that break things in other parts of the system do not > automatically get assigned the responsibility to fix them. Now, there's > no way to impose something like that requirement on a cooperative > anarchy, so I am not playing the "let's reorganize" card -- I think > most of us would agree that "that dog won't hunt" as we say down around > these parts. > > But, in the real world of software engineering, He Who Breaketh It, Must > Fixeth It. Well, actually, it's not quite that way. The reality is that every major component in a system needs someone with expertise in it, who is willing and available to maintain the system across infrastructural changes. Vinum has made it over smaller API bumps without a maintainer: the move to devfs, etc. However, to make it speak GEOM requires someone highly familiar with Vinum, and with the time available to do it. If we want to enhance the architecture of FreeBSD for improvements in performance, stability, and long-term maintainability, there will necessarily be structural changes that require a distributed update of the system. FreeBSD is of sufficient size that no one person will be able to make this sort of change alone, which is one of the important reasons to have a software maintenance model that reflects that. Our notion of software maintainance could certainly use some further evolution, but I think there are some existing intuitions. Vinum is a highly complex software module, and *must* have an active maintainer in order to survive structural operating system changes. Greg has recently posted to arch@ saying "What's the future of Vinum", indicating an intent to continue to enhance Vinum, and received a number of e-mails regarding how to adapt Vinum for GEOM. I sent him an e-mail in which I laid out a spectrum of possibilities, ranging from the minimalist to a complete transformation of Vinum into a GEOM module. Greg has indicated he plans to work on Vinum further, so I think the best we can do is provide support and encourgement. The minimalist approach appears to be viable (although there are some risks), and someone highly familiar with Vinum (such as Greg) can probably make the changes in short order. He's currently at a conference, but my hope is that when he gets back, he'll evaluate some of the approaches we've described, and pick one. I think the right strategy is to follow the minimalist approach now (adopt the disk(9) API, rather than having Vinum generate character devices) so that swap works on Vinum again, and so that when UFS moves to speaking GEOM there's no loss of functionality. If we want to completely reimplement Vinum, we should do that separately so as to avoid loss of functionality during structural changes. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 07:23:50 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61BE516A4CE for ; Mon, 12 Jan 2004 07:23:50 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2007A43D66 for ; Mon, 12 Jan 2004 07:22:45 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.3) with ESMTP id i0CFMeA7002164 for ; Mon, 12 Jan 2004 07:22:40 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i0CFMdwQ002163 for freebsd-hackers@freebsd.org; Mon, 12 Jan 2004 07:22:39 -0800 Date: Mon, 12 Jan 2004 07:22:39 -0800 From: Brooks Davis To: freebsd-hackers@freebsd.org Message-ID: <20040112152239.GA1762@Odin.AC.HMC.Edu> References: <20040108163724.GA26745@lpthe.jussieu.fr> <200401101945.27234.wes@softweyr.com> <400108FC.9010008@iconoplex.co.uk> <200401110048.52747.wes@softweyr.com> <40011237.3000409@iconoplex.co.uk> <20040111092746.GA836@pc5.i.0x5.de> <20040111190240.GA28161@Odin.AC.HMC.Edu> <20040111202438.GA55331@pc5.i.0x5.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: <20040111202438.GA55331@pc5.i.0x5.de> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Subject: Re: Discussion on the future of floppies in 5.x and 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 15:23:50 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 11, 2004 at 09:24:38PM +0100, Nicolas Rachinsky wrote: > * Brooks Davis [2004-01-11 11:02 -0800]: > > If you could make this work such that you just stuffed GENERIC and the > > mfsroot onto however many floppies it takes, I think that would almost > > certaintly solve re's problems with floppies (i.e. if all they had to do > > when the kernel/mfsroot got too big was to bump a NUMFLOPPIES > > variable.) Sure that would suck for the floppy users, but that would > > put the pain in the place where it's most likely to cause someone to > > come up with some better. > >=20 > > Now, who wants to give this a try? >=20 > OK, I tried now the following: >=20 > I made copies of the 4.9 RELEASE Floppies, split the half of the > kernel and mfsroot to another floppy and added two appropriate > splitfiles. >=20 > Afterwards booting from these four disks worked fine. >=20 > disk1: > /boot > /kernel.gz.split > /kernel.gzaa >=20 > "Message from libstand" >=20 > disk2: > /kernel.gzab >=20 > "Message from loader.rc" >=20 > disk3: > /mfsroot.gz.split > /mfsroot.gzaa >=20 > "Message from libstand" >=20 > disk4: > /mfsroot.gzab >=20 >=20 > I don't know the release build process, so I don't know how much > effort is neccessary to create such floppies, but the loader seems to > have all features needed to use such disks. It sounds like this is definatly a viable option. Now someone needs to see about hacking something like this into the release makefiles. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAAru9XY6L6fI4GtQRAu5ZAKCVVwnDZzYHPG03Ea1e6ivQG+rDqQCcC6iz P8tIQP+NWWzqSHwCeacPRpg= =0MRd -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 08:26:24 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B31F16A4CE for ; Mon, 12 Jan 2004 08:26:24 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id E980543D2F for ; Mon, 12 Jan 2004 08:26:22 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id E7ED972DAE; Mon, 12 Jan 2004 08:26:21 -0800 (PST) From: Wes Peters Organization: Softweyr To: Brooks Davis , freebsd-hackers@freebsd.org Date: Mon, 12 Jan 2004 08:26:22 -0800 User-Agent: KMail/1.5.4 References: <20040108163724.GA26745@lpthe.jussieu.fr> <20040111202438.GA55331@pc5.i.0x5.de> <20040112152239.GA1762@Odin.AC.HMC.Edu> In-Reply-To: <20040112152239.GA1762@Odin.AC.HMC.Edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401120826.22052.wes@softweyr.com> Subject: Re: Discussion on the future of floppies in 5.x and 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 16:26:24 -0000 On Monday 12 January 2004 07:22 am, Brooks Davis wrote: > On Sun, Jan 11, 2004 at 09:24:38PM +0100, Nicolas Rachinsky wrote: > > > > I don't know the release build process, so I don't know how much > > effort is neccessary to create such floppies, but the loader seems to > > have all features needed to use such disks. > > It sounds like this is definatly a viable option. Now someone needs to > see about hacking something like this into the release makefiles. Note that I didn't say it would be a lot of work. ;^) Do we have a volunteer showing up here? -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 08:32:41 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57A6516A4CE for ; Mon, 12 Jan 2004 08:32:41 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1F9943D2F for ; Mon, 12 Jan 2004 08:32:36 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 4E1391880C17; Mon, 12 Jan 2004 08:32:36 -0800 (PST) From: Wes Peters Organization: Softweyr To: Scott W , David Gilbert Date: Mon, 12 Jan 2004 08:32:36 -0800 User-Agent: KMail/1.5.4 References: <20040111051649.GK7617@wantadilla.lemis.com> <16385.44645.936069.15441@canoe.dclg.ca> <4001B3B2.8080504@mindcore.net> In-Reply-To: <4001B3B2.8080504@mindcore.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401120832.36163.wes@softweyr.com> cc: hackers@FreeBSD.org Subject: Re: Future of RAIDFrame and Vinum X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 16:32:41 -0000 On Sunday 11 January 2004 12:36 pm, Scott W wrote: > David Gilbert wrote: > >>>>>>"Poul-Henning" == Poul-Henning Kamp writes: > > > >Poul-Henning> In message <20040111051649.GK7617@wantadilla.lemis.com>, > >Poul-Henning> "Greg 'groggy' Lehey" writes: > > > >Poul-Henning> The reason I say this is that neither of you have the > >Poul-Henning> time needed, and whoever picks up may have ideas, even > >Poul-Henning> necesarry ideas, which would grind your spine seriously. > >Poul-Henning> By letting go, I think you would give vinum a better > >Poul-Henning> chance. > > > >>>>In the p4 tree, we can easier add new talent to our developer > >>>>force and I am pretty sure that some sort of merry band of > >>>>developers would form around both RF and vinum there. > > > >... now I thought I followed this list relatively well, but can > >someone point me at what 'p4' is? > > > >Dave. > > p4 = perforce source control. I'd seen the perforce depot somewhere on > freebsd's sites, but didn't previous to this discussion understand it's > purpose. Someone with more of a clue than I can fill in the blanks, > but it seems that the perforce depot is essentially open-access, > (unlike needing the commit bit set in FreeBSDs CVS tree), or at least > easier to get commit privs assigned, allowing people that are not > currently FreeBSD commiters to contribute changes back to the > repository In particular, Perforce has a very nice lightweight branching model so it is easy to give someone a Perforce account and a private branch they are allowed to commit to. That's a nice feature for an open source project. > ...at some point, presumably, to be rolled back into the main > development branch of FreeBSD by integrating back into CVS....if a > project at some point becomes 'release-worthy.' You do have to be a committer to do this. > More info on perforce is available at www.perforce.com . I saw someone > mention in this thread not liking perforce, although I'm not sure why- For people with less than stellar net connectivity, cvsup and a local CVS repo are much easier to work with. Perforce was built with a LAN in mind and scales reasonably well to the Internet, but can be painful unless you have relatively low latency and relatively high bandwidth to the server. cvsup updates much faster on slow links, too. A few years ago Perforce was working on a write-through cache so you could have a local duplicate of the server environment, but I haven't seen that work come out of the company. That would've rocked for our development model. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 08:45:23 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9034D16A4CE; Mon, 12 Jan 2004 08:45:23 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4C1743D39; Mon, 12 Jan 2004 08:45:22 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 2B82472DE9; Mon, 12 Jan 2004 08:45:21 -0800 (PST) From: Wes Peters Organization: Softweyr To: "Jacques A. Vidrine" , Colin Percival Date: Mon, 12 Jan 2004 08:45:21 -0800 User-Agent: KMail/1.5.4 References: <6.0.1.1.1.20040111174309.04327900@imap.sfu.ca> <20040112135305.GB94632@madman.celabo.org> In-Reply-To: <20040112135305.GB94632@madman.celabo.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401120845.21389.wes@softweyr.com> cc: hackers@freebsd.org Subject: Re: binary files in src tree X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 16:45:23 -0000 On Monday 12 January 2004 05:53 am, Jacques A. Vidrine wrote: > On Sun, Jan 11, 2004 at 05:48:19PM +0000, Colin Percival wrote: > > While browsing the FreeBSD src tree, I came across a number of > > binary files (listed below); the regression tests are perhaps > > understandable, but shouldn't the rest of these files be uuencoded? > > > > tools/regression/usr.bin/uudecode/regress.out > > tools/regression/usr.bin/uuencode/regress.in ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Those that are found in src/contrib/ and src/crypto/, at least, should > not be touched. However, it seems likely that some or all of them in > that case are not actually used in FreeBSD. Those that are not used > should perhaps be removed. I'll put reviewing the src/crypto/openssl/ > cases on my todo list for the next import. The two binary files used to test uuencode/uudecode should NOT be uuencoded, for obvious reasons. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 09:30:03 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E3E716A4CE for ; Mon, 12 Jan 2004 09:30:03 -0800 (PST) Received: from mx2.ngi.de (mx2.ngi.de [213.191.74.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6368643D69 for ; Mon, 12 Jan 2004 09:29:56 -0800 (PST) (envelope-from gerald.heinig@ngi.de) Received: (qmail 18097 invoked from network); 12 Jan 2004 17:11:48 -0000 Received: from unknown (HELO mx2.ngi.de) ([213.191.74.86]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 12 Jan 2004 17:11:48 -0000 From: To: hackers@freebsd.org Date: Mon, 12 Jan 2004 18:10:21 +0100 X-Mailer: NGI Webmail Message-Id: <20040112172956.6368643D69@mx1.FreeBSD.org> Subject: ping duplicates under load X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 17:30:03 -0000 Hi all, I've noticed a very weird phenomenon with ping which I can't explain. I have two machines with 2 NICs. When I started a ping -f with larger packet size (-s 3052) with NIC 1 and simultaneously hammered NIC 2 with UDP using ttcp, I got duplicate ping replies (on NIC 1, of course). Not many: only about 1 in 10000 to 100000, but still, I can't explain it. Since I had a similar problem a while back with another driver I developed (for OS X) and that turned out to be due to lost interrupts and my ISR not terminating quickly enough, I decided to limit the number of iterations of my ISR to 3. That improved the situation somewhat: I now only get 1 duplicate ping in 1E8. The real kicker is: I see this effect when my driver is the one doing the UDP receive. The ping duplicates also happen with other card drivers, so it's not a simple transmit/receive ring problem with my driver. When I use a different card driver to do the UDP receives, the effect goes away. It seems like the receive interrupt activity on my driver affects the ping replies of the _other_ drivers. Does anyone have any idea what could be going on? Cheers, Gerald From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 09:36:06 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8314716A4CE for ; Mon, 12 Jan 2004 09:36:06 -0800 (PST) Received: from grouse.mail.pas.earthlink.net (grouse.mail.pas.earthlink.net [207.217.120.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id C338D43D49 for ; Mon, 12 Jan 2004 09:36:02 -0800 (PST) (envelope-from chris@behanna.org) Received: from user183.net446.oh.sprint-hsd.net ([65.40.131.183] helo=192.168.1.2) by grouse.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Ag5yr-00024F-00 for hackers@freebsd.org; Mon, 12 Jan 2004 09:36:01 -0800 From: Chris BeHanna Organization: Western Pennsylvania Pizza Disposal Unit To: hackers@freebsd.org Date: Mon, 12 Jan 2004 12:35:59 -0500 User-Agent: KMail/1.5.4 References: <1073582974.37229.8.camel@herring.nlsystems.com> <20040108180552.GA17378@opiate.soulwax.net> In-Reply-To: <20040108180552.GA17378@opiate.soulwax.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401121235.59788.chris@behanna.org> Subject: Re: Where is FreeBSD going? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: chris@behanna.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 17:36:06 -0000 On Thursday 08 January 2004 13:05, Munish Chopra wrote: > On 2004-01-08 17:29 +0000, Doug Rabson wrote: > > [...] > > > The three main showstoppers for moving FreeBSD to subversion would be: > > > > 1. A replacement for cvsup. Probably quite doable using svnadmin > > dump and load. > > 2. Support for $FreeBSD$ - user-specified keywords are not supported > > and won't be until after svn-1.0 by the looks of things. > > 3. Converting the repository. This is a tricky one - I tried the > > current version of the migration scripts and they barfed and died > > pretty quickly. Still, I'm pretty sure that the svn developers > > are planning to fix most of those problems. From mailing-list > > archives, it appears that they are using our cvs tree as test > > material for the migration scripts. > > [...cvs2svn.py scheduled for 1.0...] What about "arch"? I have it installed, but $realjob has prevented me from looking at it. And, unless I misunderstand, Perforce is available for free for non-profits, and the client is a free download. Other than a desire to be "pure" and use open source exclusively, what objection is there to Perforce? (And even considering that desire, Perforce is built upon open source: RCS and BDB, if I understand correctly). Speaking as a former CVS repo-meister (for a company that evaporated out from under me), Perforce really is a better mousetrap. No more, "I updated in the middle of a commit" problem, because commits are transactional. No more "Oh, god, this merge sucks", because Perforce keeps track of what was merged when, and where. The latest versions rather painlessly support cross-branch merges, too (i.e., pulling changes from one branch to another without having to first push up to and pull down from a common ancestor). Triggers can be written to prevent inadvertent DoSes (p4 integ -I //depot/branch1/... //depot/branch2/...) and to do submit-time checks. Risks are more easily mitigated with branches, and pulling/pushing of selected changes is MUCH easier (no more need to generate and apply patches by hand). Generating weird-elmo hybrid mappings of the tree is also a snap, and the repo itself doesn't bloat as badly because P4 uses its database to keep track of where histories go, rather than actually physically copy a file to move it in the repo. CVS: cp /CVSROOT/foo/bar /CVSROOT/foo/baz cvs delete foo/bar cvs commit (but bar,v lives forever, if you want to keep the change history and/or if you ever want to check out an old tagged revision of the tree) Perforce: p4 integ -t foo/bar foo/baz p4 delete foo/bar p4 submit (foo/baz doesn't actually physically exist. P4 keeps a DB record that foo/baz points to foo/bar, and this operation is only visible in the branch in which it was done, until that branch is pushed up to its parent) With Perforce, no repo-meister intervention is needed. Add in the ability to use local proxies to cache frequently-fetched files and revisions, and you have a winner, IMHO. I'm starting to sound like a spokesman. I'm not--just a *very* satisfied user. -- Chris BeHanna Software Engineer (Remove "bogus" before responding.) chris@bogus.behanna.org Turning coffee into software since 1990. From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 10:21:27 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37C6E16A4CE for ; Mon, 12 Jan 2004 10:21:27 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED9B143D3F for ; Mon, 12 Jan 2004 10:21:25 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.3) with ESMTP id i0CILMA7020517; Mon, 12 Jan 2004 10:21:22 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i0CILM8e020516; Mon, 12 Jan 2004 10:21:22 -0800 Date: Mon, 12 Jan 2004 10:21:22 -0800 From: Brooks Davis To: Wes Peters Message-ID: <20040112182122.GD1762@Odin.AC.HMC.Edu> References: <20040108163724.GA26745@lpthe.jussieu.fr> <20040111202438.GA55331@pc5.i.0x5.de> <20040112152239.GA1762@Odin.AC.HMC.Edu> <200401120826.22052.wes@softweyr.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UoPmpPX/dBe4BELn" Content-Disposition: inline In-Reply-To: <200401120826.22052.wes@softweyr.com> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: freebsd-hackers@freebsd.org Subject: Re: Discussion on the future of floppies in 5.x and 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 18:21:27 -0000 --UoPmpPX/dBe4BELn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 12, 2004 at 08:26:22AM -0800, Wes Peters wrote: > On Monday 12 January 2004 07:22 am, Brooks Davis wrote: > > On Sun, Jan 11, 2004 at 09:24:38PM +0100, Nicolas Rachinsky wrote: > > > > > > I don't know the release build process, so I don't know how much > > > effort is neccessary to create such floppies, but the loader seems to > > > have all features needed to use such disks. > > > > It sounds like this is definatly a viable option. Now someone needs to > > see about hacking something like this into the release makefiles. >=20 > Note that I didn't say it would be a lot of work. ;^) >=20 > Do we have a volunteer showing up here? Definatly not me. I hate floppies (and they hate me). I was just trying to convince someone to follow what looks like a reasionably promising path to keeping floppy support and moving the pain of dealing with floppies from RE to the floppy users. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --UoPmpPX/dBe4BELn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAAuWhXY6L6fI4GtQRAg96AKDXLkEqqbr2vXmU3sq1Tu8H39vvbQCeNE6e DF4nxCwngKQK3TKKXx5mClY= =yOdX -----END PGP SIGNATURE----- --UoPmpPX/dBe4BELn-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 10:46:04 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20F1A16A4CE for ; Mon, 12 Jan 2004 10:46:04 -0800 (PST) Received: from revelstoke.panasas.com (gw2.panasas.com [65.194.124.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DF0D43D1F for ; Mon, 12 Jan 2004 10:46:01 -0800 (PST) (envelope-from nlanza@premodern.org) Received: from revelstoke.panasas.com (localhost [127.0.0.1]) i0CIjsbl028493; Mon, 12 Jan 2004 13:45:54 -0500 (EST) (envelope-from nlanza@premodern.org) Received: (from nlanza@localhost) by revelstoke.panasas.com (8.12.9p2/8.12.9/Submit) id i0CIjpFO028022; Mon, 12 Jan 2004 13:45:51 -0500 (EST) (envelope-from nlanza@premodern.org) X-Authentication-Warning: revelstoke.panasas.com: nlanza set sender to nlanza@premodern.org using -f From: Nat Lanza To: Wes Peters In-Reply-To: <200401120832.36163.wes@softweyr.com> References: <20040111051649.GK7617@wantadilla.lemis.com> <4001B3B2.8080504@mindcore.net> <200401120832.36163.wes@softweyr.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1073933150.83993.14.camel@revelstoke.panasas.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 12 Jan 2004 13:45:51 -0500 X-Mailman-Approved-At: Mon, 12 Jan 2004 10:54:23 -0800 cc: hackers@FreeBSD.org cc: David Gilbert cc: Scott W Subject: Re: Future of RAIDFrame and Vinum X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 18:46:04 -0000 On Mon, 2004-01-12 at 11:32, Wes Peters wrote: > A few years ago Perforce was working on a write-through cache so you could > have a local duplicate of the server environment, but I haven't seen that > work come out of the company. That would've rocked for our development > model. They released the proxy a while ago, and it works very nicely. We use it at work, where we have three remote development sites connected by a VPN over fairly narrow pipes -- each site runs a local proxy and things are a lot faster than they used to be. p4p is pretty easy to set up and doesn't require any admin privileges -- take a look at the release notes: http://www.perforce.com/perforce/doc.032/user/p4pnotes.txt Assuming the FreeBSD repository is running a reasonably recent server version, people working with it ought to see a pretty decent speedup if they run a local p4p on their development machines. --nat From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 11:07:56 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EEFF16A4CE for ; Mon, 12 Jan 2004 11:07:56 -0800 (PST) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEB8B43D73 for ; Mon, 12 Jan 2004 11:06:39 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 6358 invoked from network); 12 Jan 2004 19:06:10 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 12 Jan 2004 19:06:10 -0000 Received: from 10.50.40.206 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i0CJ65M0064426; Mon, 12 Jan 2004 14:06:06 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Brooks Davis , Wes Peters Date: Mon, 12 Jan 2004 13:46:07 -0500 User-Agent: KMail/1.5.4 References: <20040108163724.GA26745@lpthe.jussieu.fr> <200401120826.22052.wes@softweyr.com> <20040112182122.GD1762@Odin.AC.HMC.Edu> In-Reply-To: <20040112182122.GD1762@Odin.AC.HMC.Edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401121346.07929.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-hackers@freebsd.org Subject: Re: Discussion on the future of floppies in 5.x and 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 19:07:56 -0000 On Monday 12 January 2004 01:21 pm, Brooks Davis wrote: > On Mon, Jan 12, 2004 at 08:26:22AM -0800, Wes Peters wrote: > > On Monday 12 January 2004 07:22 am, Brooks Davis wrote: > > > On Sun, Jan 11, 2004 at 09:24:38PM +0100, Nicolas Rachinsky wrote: > > > > I don't know the release build process, so I don't know how much > > > > effort is neccessary to create such floppies, but the loader seems to > > > > have all features needed to use such disks. > > > > > > It sounds like this is definatly a viable option. Now someone needs to > > > see about hacking something like this into the release makefiles. > > > > Note that I didn't say it would be a lot of work. ;^) > > > > Do we have a volunteer showing up here? > > Definatly not me. I hate floppies (and they hate me). I was just > trying to convince someone to follow what looks like a reasionably > promising path to keeping floppy support and moving the pain of dealing > with floppies from RE to the floppy users. > > -- Brooks I'm going to look at using splitfs for GENERIC kernel and mfsroot that we use on CD installs. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 11:46:57 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D5A416A4CE; Mon, 12 Jan 2004 11:46:57 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B0B943D46; Mon, 12 Jan 2004 11:46:55 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i0CJkrtV054273; Mon, 12 Jan 2004 11:46:53 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i0CJkqOE054272; Mon, 12 Jan 2004 11:46:52 -0800 (PST) (envelope-from dillon) Date: Mon, 12 Jan 2004 11:46:52 -0800 (PST) From: Matthew Dillon Message-Id: <200401121946.i0CJkqOE054272@apollo.backplane.com> To: "" References: <200401062000.i06K0hSI012184@dyson.jdyson.com> <200401072317.i07NHaM9065411@apollo.backplane.com> <3FFD01CE.5070301@energyhq.es.eu.org> <1073680797.3fff119d89733@webmail.iquest.net> cc: freebsd-chat@freebsd.org cc: freebsd-hackers@freebsd.org cc: Munden Randall J cc: Brett Glass cc: jsd@jdyson.com Subject: Re: Where is FreeBSD going? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 19:46:57 -0000 :> Agreed. Like I've said, the main problem I see is complexity. It :> wouldn't matter as much if there were 5-10 people with deep knowledge of :> SMPng, but with 1 or 2 hackers working on it, the chance that everything :> will be ever fixed is quite small. :> :IMO, the easiest way to start the SMP work (from a FreeBSD monolithic :approach), is to flatten as much of the VFS/VM code as possible into :a continuation scheme... That is something that I could have done 5yrs :ago in a few weeks, and then keep the networking system as it is. :There would be shims deployed that would still support the sleep/wakeup :scheme, so that the non-networking could and the new flat interface could :be debugged... (It is NOT a good idea to bug the networking guys until :the new scheme would be debugged.) : :At that point, there would be a code with explicit context carried around, :and no nesting or stack context. This would have a small benefit of avoiding :multiple deeply nested kernel stacks... : :Given the very flat scheme, each subsystem could be recoded into a :message passing or simple continuation scheme (whatever is appropriate.) :The system would be naturally able to be reworked -- without the :hidden dependencies of the stack. VFS/VM layering problems then :become resolvable. : :This is NOT a total solution, but should be the beginning of a thinking :exercise that seems to lead into the correct direction. (Don't :criticize this based upon the completeness of my prescription, but :on what can eventually be developed!!!) I have been trying to figure out how to implement asynch system calls in DFly, which is a very similar problem to the one posed by the VFS stack. I don't think we can use a pure continuation scheme, but I do think the required context can be minimized enough to fit in a structure. In DFly, the natural structure to hold the contextual information is the message structure that was used to initiate the operation in the first place. So, in regards to async system calls, the message structure contains an additional union that lays out contextual storage requirements for each system call. For example, the contextual information required to support nanosleep() would primarily be a timeout structure. (This is in fact the only system call that can be run asynch in DFly at the moment... I am using it as an experimental base to try to refine the code requirements to reduce complexity). The blocking points for both system calls and VFS calls (which are the real problem being solved here) tend to be related to blocking on I/O events, locks, and mutexes. In DFly I primarily have to worry about I/O events and locks and not so much about mutexes. Also, in DFly, We are serializing many major subsystems and segregating high performance structures, such as PCB's, by associating them with a single thread. This fits very well with the continuation scheme idea because we would prefer to have only a few threads which handle multiple data structures (to make best use of available cpus), and this means that we cannot simply 'block' in such threads whenever we feel like it without screwing up parallelism. -Matt Matthew Dillon :Oh well -- I cannot think too much about this stuff, or I'll actually :get emotionally involved again. I need to get a 'normal' job, not :working at home and need to interact with people instead of CRTs. :-). :(I give a sh*t about FreeBSD, and hope that WHATEVER problems that :truly exist are fully resolved.) There is alot of blood sweat and :tears in that codebase, and being involved in the project should be :done with great respect. : :John From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 12:07:50 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE0A216A4CE for ; Mon, 12 Jan 2004 12:07:50 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FF5943D46 for ; Mon, 12 Jan 2004 12:07:49 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i0CK7lET057863; Mon, 12 Jan 2004 13:07:48 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 12 Jan 2004 13:07:44 -0700 (MST) Message-Id: <20040112.130744.103234908.imp@bsdimp.com> To: peterjeremy@optushome.com.au From: "M. Warner Losh" In-Reply-To: <20040112072715.GA65549@server.vk2pj.dyndns.org> References: <20040111161839.53EC788@toad.stack.nl> <4001A019.2030604@siue.edu> <20040112072715.GA65549@server.vk2pj.dyndns.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: wgrim@siue.edu Subject: Re: Discussion on the future of floppies in 5.x and 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 20:07:50 -0000 In message: <20040112072715.GA65549@server.vk2pj.dyndns.org> Peter Jeremy writes: : On Sun, Jan 11, 2004 at 01:12:25PM -0600, William Grim wrote: : >If it's really such a big deal to get rid of floppy support, how about : >we get rid of it and make sure an older version of FreeBSD 4.x/5.x is : >always available for download? This way, floppy users could install an : >older version of the OS and cvsup to the latest version they want. : : 1) CVSup isn't an option for someone who wants to install a binary : distribution and not have to do a buildworld. Actually, one can distribute binaries with cvsup, but it is a bit of a pita... Warner From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 12:19:55 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C27FB16A4CE; Mon, 12 Jan 2004 12:19:55 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB03243D2F; Mon, 12 Jan 2004 12:19:51 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i0CKJjET058050; Mon, 12 Jan 2004 13:19:46 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 12 Jan 2004 13:19:41 -0700 (MST) Message-Id: <20040112.131941.66169325.imp@bsdimp.com> To: linimon@lonesome.com From: "M. Warner Losh" In-Reply-To: <200401120341.42349.linimon@lonesome.com> References: <33570.1073898807@critter.freebsd.dk> <200401120341.42349.linimon@lonesome.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: grog@freebsd.org cc: phk@phk.freebsd.dk cc: hackers@freebsd.org Subject: Re: Future of RAIDFrame and Vinum X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 20:19:56 -0000 In message: <200401120341.42349.linimon@lonesome.com> Mark Linimon writes: : > If nothing happens, vinum is going to break even more very soon. : : No ... if you do a commit that changes the code assumptions upon : which vinum was built, vinum will break. vinum is not going to : "magically" break by itself. Another way of looking at it is that vinum failed to keep up. There are many other examples that this has happened to. FreeBSD is a dynamic system, full of life and vigor. Some parts of it are more vigorous than other parts. There's a boatload of ISA drivers that are about to be desupported because they rely on old interfaces. There's a number of pci devices that have already been removed because they couldn't keep up. And before that, there were a number of pccard drivers that broke when we went to newbus. : But, in the real world of software engineering, He Who Breaketh It, : Must Fixeth It. That's not always a viable option. We've obsoleted a number of drivers over time because the developers that were moving the rest of the system forward just flat didn't have the hardware to properly test changes. Also, there's a fuzzy core of FreeBSD that 'everybody' cares about and makes sure keeps working. The further you get from that core, the harder it is to keep things working. Fewer people deal with the code and changes to the rest of the system may impact that to a larger or smaller degree. It is up to the 'fringe' folks to keep the 'fringe' code in shape. There's simply too much in the tree to expect otherwise. Put another way, would you expect me to order European ISDN service while I live in the US, and find ISDN hardware when I'm doing some wide ranging change that brushes up against i4b? Or should I get an OS/2 system online if I happened to have a change that could impact hpfs? Or should I fix an ISA driver that literally no one is using? The reality of the situation is that there has always been a balance between moving forward and keeping compatibility. We've come out of a period where not too many things have forced a break with compatibility. As a result, we've got a lot of ugly architectural code in the tree. We're now moving into a period where those things will be cleaned up. It will continue to be a balancing act moving forward. It is better to identify the colater damage up front than to be meek about it. That's why phk's saying something about vinum. It is in the uncomfortable middle ground. Clearly it is useful to a lot of people. However, it is equally clear that it hasn't had the care and feeding that other parts of the system have had and this neglect is starting to show. If this were some obscure file system (say amiga DOS file system), then it would be easy to make the tradeoff. If it were used on every box it would also be easy (eg UFS). Since it is in the middle ground, it becomes a painful decision: it is too much for one person to do in addition to the needful cleanups, and it is too important to just ignore. Warner From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 12:56:25 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D61D16A4CE for ; Mon, 12 Jan 2004 12:56:25 -0800 (PST) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF11543D5A for ; Mon, 12 Jan 2004 12:55:41 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 26898 invoked from network); 12 Jan 2004 20:55:41 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 12 Jan 2004 20:55:41 -0000 Received: from 10.50.40.206 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i0CKtOM8065075; Mon, 12 Jan 2004 15:55:37 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Martin Nilsson , Marcin Dalecki Date: Mon, 12 Jan 2004 15:30:20 -0500 User-Agent: KMail/1.5.4 References: <4001552B.5060108@gneto.com> <4001A184.5060301@gmx.net> <4001C283.5080106@gneto.com> In-Reply-To: <4001C283.5080106@gneto.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401121530.20732.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-hackers@freebsd.org Subject: Re: Assembler coding help needed. [solved, patch enclosed] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 20:56:25 -0000 On Sunday 11 January 2004 04:39 pm, Martin Nilsson wrote: > Marcin Dalecki wrote: > > Martin Nilsson wrote: > >> I'm trying to find out why I can't boot 5.2 from USB CDROM on > >> Supermicro motherboards. (I have an old Gateway P3 that can!). > >> > >> I've found out that that only 0x20 of 0x4c sectors of the loader are > >> read in and it therfor traps when executed. (read is only called once). > >> > >> load_notrunc: sub %dh,%cl # Update count > >> push %eax # Save > >> call read # Read it in > > > > The fun will be ^^^^ here. The rest is self contained and > > doesn't depend on CPU variant or periphery. > > I found the problem! > The bios trashes %cx when reading from USB CD but not when reading from > ATAPI CD. > > The attached patch fixes this and two other small nits in > sys/boot/i386/cdboot/cdboot.s Thanks for the nit fixes. > Can somebody (jhb) commit this? > > This probably affects all Phoenix-Award bios equipped boxes. My old > Gateway with AMI BIOS works as it should. I will commit something similar. I will save %cx around the BIOS call itself in the read function. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 13:44:31 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6D3516A4CE; Mon, 12 Jan 2004 13:44:31 -0800 (PST) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 322E143D3F; Mon, 12 Jan 2004 13:43:51 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc12) with ESMTP id <20040112214348012006m0rce>; Mon, 12 Jan 2004 21:43:49 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA86752; Mon, 12 Jan 2004 13:43:47 -0800 (PST) Date: Mon, 12 Jan 2004 13:43:46 -0800 (PST) From: Julian Elischer To: Matthew Dillon In-Reply-To: <200401121946.i0CJkqOE054272@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-chat@freebsd.org cc: freebsd-hackers@freebsd.org cc: Munden Randall J cc: dyson@iquest.net cc: Brett Glass cc: jsd@jdyson.com Subject: Re: Where is FreeBSD going? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 21:44:31 -0000 On Mon, 12 Jan 2004, Matthew Dillon wrote: > > :> Agreed. Like I've said, the main problem I see is complexity. It > :> wouldn't matter as much if there were 5-10 people with deep knowledge of > :> SMPng, but with 1 or 2 hackers working on it, the chance that everything > :> will be ever fixed is quite small. > :> > :IMO, the easiest way to start the SMP work (from a FreeBSD monolithic > :approach), is to flatten as much of the VFS/VM code as possible into > :a continuation scheme... That is something that I could have done 5yrs > :ago in a few weeks, and then keep the networking system as it is. > :There would be shims deployed that would still support the sleep/wakeup > :scheme, so that the non-networking could and the new flat interface could > :be debugged... (It is NOT a good idea to bug the networking guys until > :the new scheme would be debugged.) > : > :At that point, there would be a code with explicit context carried around, > :and no nesting or stack context. This would have a small benefit of avoiding > :multiple deeply nested kernel stacks... > : > :Given the very flat scheme, each subsystem could be recoded into a > :message passing or simple continuation scheme (whatever is appropriate.) > :The system would be naturally able to be reworked -- without the > :hidden dependencies of the stack. VFS/VM layering problems then > :become resolvable. > : > :This is NOT a total solution, but should be the beginning of a thinking > :exercise that seems to lead into the correct direction. (Don't > :criticize this based upon the completeness of my prescription, but > :on what can eventually be developed!!!) > > I have been trying to figure out how to implement asynch system > calls in DFly, which is a very similar problem to the one posed by > the VFS stack. I know that Matt knows all this but.. The thing about async syscalls is that by definition, the context needs to be split.. Something goes back to the caller and something stays behind to compete the operation. The 2nd "something" can be a saved message, or a full saved context. Dfly would use the first methond and FreeBSD uses the 2nd method. (KSE threads are based upon asyncronous system calls). In case 2 you need a way for the program to cope with the fact that syscalls return without having done what they were asked to do.. this is what the kse threading library and API do. > > I don't think we can use a pure continuation scheme, but I do > think the required context can be minimized enough to fit in > a structure. In DFly, the natural structure to hold the > contextual information is the message structure that was used > to initiate the operation in the first place. In order to make the state minimal, you need to know what state is important to keep in every situation. In FreeBSD there is not enough knowledge about this so we keep the entire thread state. If the requests were encapsulated in messages then that would help, but you still need to keep other state available.. for example, if you sleep while doing the 3rd part (out of 4) of a large read (that the kernel has broken up due to allocation discontinuities on the disk for example) then you still need to keep track of that and the original message probabyl doesn't have the storeage context for that. > > So, in regards to async system calls, the message structure > contains an additional union that lays out contextual storage > requirements for each system call. yes but you have to design your system for that from scratch.. (Dfly is doing it with a retroactive "scratch" :-) > > For example, the contextual information required to > support nanosleep() would primarily be a timeout structure. > (This is in fact the only system call that can be run asynch > in DFly at the moment... I am using it as an experimental > base to try to refine the code requirements to reduce > complexity). > > The blocking points for both system calls and VFS calls (which > are the real problem being solved here) tend to be related to > blocking on I/O events, locks, and mutexes. In DFly I > primarily have to worry about I/O events and locks and not so > much about mutexes. Also, in DFly, We are serializing many major > subsystems and segregating high performance structures, such as PCB's, > by associating them with a single thread. This fits very well > with the continuation scheme idea because we would prefer to > have only a few threads which handle multiple data structures > (to make best use of available cpus), and this means that we cannot > simply 'block' in such threads whenever we feel like it without > screwing up parallelism. right.. It depends if yuo thin that doing all that work is worth it.. If you are happy to save the running context and return another that doesn't hold any locks etc. then you can make the existing code work. But it has costs of course. > > -Matt > Matthew Dillon > > > :Oh well -- I cannot think too much about this stuff, or I'll actually > :get emotionally involved again. I need to get a 'normal' job, not > :working at home and need to interact with people instead of CRTs. :-). > :(I give a sh*t about FreeBSD, and hope that WHATEVER problems that > :truly exist are fully resolved.) There is alot of blood sweat and > :tears in that codebase, and being involved in the project should be > :done with great respect. > : > :John > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 16:07:12 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C124216A4CE for ; Mon, 12 Jan 2004 16:07:12 -0800 (PST) Received: from mail-in.m-online.net (svr8.m-online.net [62.245.150.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01E8E43D1F for ; Mon, 12 Jan 2004 16:07:11 -0800 (PST) (envelope-from h@schmalzbauer.de) Received: from mail.m-online.net (svr14.m-online.net [192.168.3.144]) by svr8.m-online.net (Postfix) with ESMTP id C151EAD1E; Tue, 13 Jan 2004 01:07:09 +0100 (CET) Received: from cale.flintsbach.schmalzbauer.de (ppp-82-135-4-225.mnet-online.de [82.135.4.225]) by mail.m-online.net (Postfix) with ESMTP id 84D5434E07; Tue, 13 Jan 2004 01:07:09 +0100 (CET) From: Harald Schmalzbauer To: "Poul-Henning Kamp" , des@des.no (Dag-Erling =?iso-8859-15?q?Sm=F8rgrav?=) Date: Tue, 13 Jan 2004 01:07:02 +0100 User-Agent: KMail/1.5.4 References: <22741.1073889204@critter.freebsd.dk> In-Reply-To: <22741.1073889204@critter.freebsd.dk> X-Birthday: 06 Oktober 1972 X-Name: Harald Schmalzbauer X-Phone1: +49 (0) 163 555 3237 X-Phone2: +49 (0) 89 18947781 X-Address: Munich, 80686 X-Country: Germany MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_sazAAfmPZENjFQB"; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200401130107.08427@harrymail> X-Mailman-Approved-At: Mon, 12 Jan 2004 20:45:04 -0800 cc: hackers@freebsd.org Subject: Re: Future of RAIDFrame X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2004 00:07:12 -0000 --Boundary-02=_sazAAfmPZENjFQB Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Description: signed data Content-Disposition: inline On Monday 12 January 2004 07:33, Poul-Henning Kamp wrote: > In message , Dag-Erling > =?iso-8859-1?q?Sm=F8rgrav?= > > writes: > >"M. Warner Losh" writes: > >> Maybe this would be a good test-case for seeing how well it works? > >> Maybe not. We do need to run a few more test-cases for things through > >> this scenario... I'm not sure this one is well suited to it. > > > >If we toss out Vinum, there's a significant risk that 5.3 will ship > >without RAID support at all. I'm pretty certain we don't want that. Just my opinion: That's way worse than having no software RAID! No qualified explanations, just a opinion. -Harry > > If we don't do something drastic, there's a significant risk that > 5.3 and all future releases will ship with partially broken RAID > support. I'm pretty certain we don't want that either. --Boundary-02=_sazAAfmPZENjFQB Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQBAAzasBylq0S4AzzwRAmaQAJ9Br/6xooc7eXBdbjVQjTZRdb/MigCghE// OC+tyY+cMoHUGH0N4SGnFNg= =G6i+ -----END PGP SIGNATURE----- --Boundary-02=_sazAAfmPZENjFQB-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 13:04:31 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6F7E16A4CE; Mon, 12 Jan 2004 13:04:31 -0800 (PST) Received: from shell.webmaster.com (mail.webmaster.com [216.152.64.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EC8143D6E; Mon, 12 Jan 2004 13:03:55 -0800 (PST) (envelope-from davids@webmaster.com) Received: from however ([206.171.168.138]) by shell.webmaster.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com; Mon, 12 Jan 2004 13:03:45 -0800 From: "David Schwartz" To: "Gary W. Swearingen" , "M. Warner Losh" Date: Mon, 12 Jan 2004 13:03:43 -0800 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.6604 (9.0.2911.0) In-Reply-To: <35u1357fbm.135@mail.comcast.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2055 Importance: Normal X-Mailman-Approved-At: Mon, 12 Jan 2004 20:45:14 -0800 cc: freebsd-hackers@freebsd.org cc: freebsd-chat@freebsd.org Subject: RE: Where is FreeBSD going? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 21:04:32 -0000 > Well, I know that it's legal to omit one's own copyright claim, but > for some organization to lay claim to copyrights owned by you or me > seems very wrong. It's a violation of BSD-type licenses and a > violation of the concept of attribution that is behind the licenses. > A legal entity has made the false claim of copyright ownership, > whether that's an informal organization or the person who wrote the > claim with a pseudonym. I'm not sure how you or I have been damaged, > but I supose that a lawyer could find a way. Anyone who can legally created derived or aggregated works from a work to which you hold copyright may place their own copyright on those derived or aggregated works. This in no way affects your original copyright. DS From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 23:46:25 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE4BC16A4CE for ; Mon, 12 Jan 2004 23:46:25 -0800 (PST) Received: from manor.msen.com (manor.msen.com [148.59.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id D949643D2F for ; Mon, 12 Jan 2004 23:46:23 -0800 (PST) (envelope-from wayne@staff.msen.com) Received: from manor.msen.com (wayne@localhost [127.0.0.1]) by manor.msen.com (8.12.7M/8.12.7) with ESMTP id i0D7kNEk004375 for ; Tue, 13 Jan 2004 02:46:23 -0500 (EST) Message-Id: <200401130746.i0D7kNEk004375@manor.msen.com> To: hackers@freebsd.org Date: Tue, 13 Jan 2004 02:46:23 -0500 From: "Michael R. Wayne" Subject: Mergemaster+RCS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2004 07:46:25 -0000 Although Doug Barton has written a wonderful tool, it has always seemed to have a major deficiency: it completely ignores the existance of RCS files. I've exchanged some email with Doug and he has no interest in adding RCS support to mergemaster. So I did. Doug has mentioned that some people solve this problem by using the precompare script or by checking out all RCS files before running mergemaster then checking them in afterwards. These solutions are highly unattractive to me since they require sysadmins to remember far too much, especially given that systems are often upgraded at off hours to minimize user impact. The attached patch to the mergemaster in 4.9-RELEASE-p1 addresses this issue. Specifically, it does the following, automatically: For every file that mergemaster replaces, check for the existance of an associated RCS log file in the RCS subdirectory. (I do NOT check for the logfile in the current directory). If such a logfile exists If the file is currently checked out, check it in with an automated comment. Check the file out. Apply the upgrade. Check the file in with an automated comment. If the file was originally checked out, check it back out again. If no associated RCS log file exists, there is no change in the operation of mergemaster. I take care to leave the log file in the original checked in/out state: People have tools that "know" the state of logfiles and these tools should not be broken. This seems to work for us. Comments/suggestions welcome. /\/\ \/\/ *** /usr/sbin/mergemaster Thu Jan 8 17:03:30 2004 --- mergemaster+rcs Fri Jan 9 08:45:19 2004 *************** *** 8,20 **** # Copyright 1998-2003 Douglas Barton # DougB@FreeBSD.org # $FreeBSD: src/usr.sbin/mergemaster/mergemaster.sh,v 1.6.2.18 2003/08/25 08:27:41 dougb Exp $ PATH=/bin:/usr/bin:/usr/sbin display_usage () { VERSION_NUMBER=`grep "[$]FreeBSD:" $0 | cut -d ' ' -f 4` ! echo "mergemaster version ${VERSION_NUMBER}" echo 'Usage: mergemaster [-scrvahipCP] [-m /path]' echo ' [-t /path] [-d] [-u N] [-w N] [-D /path]' echo "Options:" --- 8,22 ---- # Copyright 1998-2003 Douglas Barton # DougB@FreeBSD.org + # Automated support for RCS log files added 2004 by wayne@msen.com + # $FreeBSD: src/usr.sbin/mergemaster/mergemaster.sh,v 1.6.2.18 2003/08/25 08:27:41 dougb Exp $ PATH=/bin:/usr/bin:/usr/sbin display_usage () { VERSION_NUMBER=`grep "[$]FreeBSD:" $0 | cut -d ' ' -f 4` ! echo "mergemaster version ${VERSION_NUMBER} with RCS support" echo 'Usage: mergemaster [-scrvahipCP] [-m /path]' echo ' [-t /path] [-d] [-u N] [-w N] [-D /path]' echo "Options:" *************** *** 646,653 **** --- 648,695 ---- ;; esac + # Begin part 1 of 2 support for RCS added by wayne@msen.com + # Deals with RCS log files in the RCS subdirectory, first checking + # in previous changes (if any), checks in the changes made by + # mergemaster and leaves the file in the original checked in/out state. + # + # Assume we will not need to check this file in. + local MM_RCS + MM_RCS=0 + if [ -d ${3}/RCS ]; then + # The RCS directory exists, check it for this logfile + if [ -e ${3}/RCS/${2##*/},v ]; then + # The RCS logfile exists, now we need to know it's existing state + if [ -z `rlog -L -R ${3}/${2##*/}` ]; then + # Target file is unlocked, check it out + co -l ${3}/${2##*/} + # Remember to leave file unlocked after install + MM_RCS=1 + else + # File is already locked, check it in before we mess with it + ci -l -m"Mergemaster auto checkin of locked file." ${3}/${2##*/} + # Remember to leave file locked after install + MM_RCS=2 + fi + fi + fi + # End part 1 of 2 support for RCS added by wayne@msen.com + install -m "${1}" "${2}" "${3}" && rm -f "${2}" + + # Begin part 2 of 2 support for RCS added by wayne@msen.com + if [ $MM_RCS -eq 1 ]; then + # Checkin the file, leaving it unlocked + ci -u -m"Mergemaster auto checkin after updates" ${3}/${2##*/} + elif [ $MM_RCS -eq 2 ]; then + # Checkin the file, leaving it locked + ci -l -m"Mergemaster auto checkin after updates" ${3}/${2##*/} + else + # Do nothing, no RCS log file exists + fi + # End part 2 of 2 support for RCS added by wayne@msen.com + } find_mode () { From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 13 11:25:33 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F8E716A4CE for ; Tue, 13 Jan 2004 11:25:33 -0800 (PST) Received: from mta-b.kjsl.com (mta-b.kjsl.com [69.36.241.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41D9043D58 for ; Tue, 13 Jan 2004 11:25:32 -0800 (PST) (envelope-from fmc@reanimators.org) Received: by mta-b.kjsl.com (Postfix, from userid 66) id 0186B4ADD1; Tue, 13 Jan 2004 11:25:31 -0800 (PST) Received: from daemonweed.reanimators.org (localhost.reanimators.org [127.0.0.1])i0DJEM39087401 for ; Tue, 13 Jan 2004 11:14:22 -0800 (PST) (envelope-from fmc@daemonweed.reanimators.org) Received: (from fmc@localhost)i0DJEMdZ087400; Tue, 13 Jan 2004 11:14:22 -0800 (PST) (envelope-from fmc) Message-Id: <200401131914.i0DJEMdZ087400@daemonweed.reanimators.org> To: freebsd-hackers@freebsd.org References: <20040109193551.GD39751@moo.sysabend.org> <20040110225509.GA60996@server.vk2pj.dyndns.org> From: Frank McConnell Date: Tue, 13 Jan 2004 11:14:22 -0800 In-Reply-To: <20040110225509.GA60996@server.vk2pj.dyndns.org> (Peter Jeremy's message of "Sun, 11 Jan 2004 09:55:09 +1100") MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: Large Filesystem Woes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2004 19:25:33 -0000 Peter Jeremy wrote: > (OTOH, I have no problems with 1.9e6 files in a UFS1 partition > on a FreeBSD box). For your amusement: a box running 4.7-RELEASE with 3.3e6 files in a single directory. It began to exhibit problems but remained usable. ~90MB directory file. Took a while to find a file or create a new one in that directory. The security run reported "find: fts_read: Cannot allocate memory" as its scan for setuid files. It's been rearranged a bit and is happier now. -Frank McConnell From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 13 13:16:45 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CCA916A4CE for ; Tue, 13 Jan 2004 13:16:45 -0800 (PST) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBB3443D58 for ; Tue, 13 Jan 2004 13:16:43 -0800 (PST) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (c-24-6-186-224.client.comcast.net[24.6.186.224]) by comcast.net (rwcrmhc11) with ESMTP id <20040113211643013006trs8e>; Tue, 13 Jan 2004 21:16:43 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id i0DLGg43000664 for ; Tue, 13 Jan 2004 13:16:42 -0800 (PST) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id i0DLGfKG000663 for freebsd-hackers@freebsd.org; Tue, 13 Jan 2004 13:16:41 -0800 (PST) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Tue, 13 Jan 2004 13:16:41 -0800 From: "Crist J. Clark" To: freebsd-hackers@freebsd.org Message-ID: <20040113211641.GA99925@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ Subject: Measuring Time on Serial Port Events X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Crist J. Clark" List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2004 21:16:45 -0000 I'm doing some work involving measuring latencies of communications over serial ports. To avoid clock synchronizations issues if we were running on separate machines, a configuration is a modem hooked into /dev/cuaa0 and another in /dev/cuaa1. We talk to the modem on cuaa0 which calls the modem on cuaa1, we tell it to answer, and then we throw data back and forth and take timestamps. Right now, all of the code is running in userland. I am trying to figure out what tuning we could do to get things as accurate as possible. That is, the information we want is the time that a bunch of bits to leave the COM port versus when they arrive on the other one. Since things look more like, Userland | OS | Comms Hardware | | | | [measuring]<->|<-[ sio ]->|<---- UART ---->|<-------> [ program ] | [driver] | | And this doesn't account for delays between when we get the data in userland and then have to make gettimeofday() calls for timestamps and other potential delays. I'm concerned how far off our measurements in userland will be from when bits actually arrive and leave on the wire. The data we are concerned with has latencies of a few 100 ms, but calibrations on the PSTN are a typically 50-ms-ish. We need to have a few significant digits below that. Any pointers? -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 13 15:26:06 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 185EC16A4CE; Tue, 13 Jan 2004 15:26:06 -0800 (PST) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BFA643D5A; Tue, 13 Jan 2004 15:26:04 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc13) with ESMTP id <2004011323260301500b7qbne>; Tue, 13 Jan 2004 23:26:03 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA01644; Tue, 13 Jan 2004 15:26:02 -0800 (PST) Date: Tue, 13 Jan 2004 15:26:00 -0800 (PST) From: Julian Elischer To: hackers@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: imp@freebsd.org Subject: PCI interrupt allocation question.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2004 23:26:06 -0000 I have a (well, several of them) system with a SuperMicro X5 series Motherboard. It has a Xeon (2.8GHz) and an intel ICH series chipset. The kernel includes teh ichsmb driver to try access the SMBus for temperature reading reasons (yes I know I can do it other ways..) During boot (FreeBSD 4.8) I see: Jan 13 14:25:13 build1 /k2: ichsmb0: port 0x1100-0x111f irq 0 at device 31.3 on pci0 Jan 13 14:25:13 build1 /k2: pci_cfgintr_virgin: using routable interrupt 3 Jan 13 14:25:13 build1 /k2: pci_cfgintr: 0:31 INTB routed to irq 3 Jan 13 14:25:13 build1 /k2: smbus0: on ichsmb0 Jan 13 14:25:13 build1 /k2: smb0: on smbus0 What actually doe sthis mean (it's unusual) The interrupts apparently never get there anyhow.. I assume that the Bios hasn't assigned an interrupt and the kernel is trying to do so by itself. I also assume that it doesn't REALLY know how to do this... at least not with the chipset I'm using.. (82801AC from memory) (ICH3 , MCH etc.) E7501 chipset. Any thoughts that move me towards getting th eichsmb driver working on this machine are welcome. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 13 15:41:02 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58EDB16A4CE; Tue, 13 Jan 2004 15:41:02 -0800 (PST) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12BB443D97; Tue, 13 Jan 2004 15:40:16 -0800 (PST) (envelope-from kientzle@acm.org) Received: from acm.org ([66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id i0DNe8kX070459; Tue, 13 Jan 2004 15:40:09 -0800 (PST) (envelope-from kientzle@acm.org) Message-ID: <400481D8.2030708@acm.org> Date: Tue, 13 Jan 2004 15:40:08 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alfred Perlstein References: <20040110050033.GP9623@elvis.mu.org> <20040110222441.GS9623@elvis.mu.org> In-Reply-To: <20040110222441.GS9623@elvis.mu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Dag-Erling Sm?rgrav cc: hackers@freebsd.org Subject: Re: help with linking please X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2004 23:41:02 -0000 Alfred Perlstein wrote: > It will refuse to strip symbols if: > > foo.o:func1() references bar.o:func2(). > > But I need it to. I suppose there are good reasons why you cannot compile everything into a single .o file for distribution? > cat master.c #include #include > gcc -o master.o master.c Now you have a single .o file with everything in it and there are therefore no cross-module references within your library. Tim From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 13 15:52:41 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26A6516A4CE; Tue, 13 Jan 2004 15:52:41 -0800 (PST) Received: from pcwin002.win.tue.nl (pcwin002.win.tue.nl [131.155.71.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF99243D46; Tue, 13 Jan 2004 15:52:37 -0800 (PST) (envelope-from stijn@pcwin002.win.tue.nl) Received: from pcwin002.win.tue.nl (orb_rules@localhost [127.0.0.1]) by pcwin002.win.tue.nl (8.12.10/8.12.10) with ESMTP id i0DNtB4x040559; Wed, 14 Jan 2004 00:55:11 +0100 (CET) (envelope-from stijn@pcwin002.win.tue.nl) Received: (from stijn@localhost) by pcwin002.win.tue.nl (8.12.10/8.12.10/Submit) id i0DNtB4x040558; Wed, 14 Jan 2004 00:55:11 +0100 (CET) (envelope-from stijn) Date: Wed, 14 Jan 2004 00:55:11 +0100 From: Stijn Hoop To: Julian Elischer Message-ID: <20040113235511.GB39353@pcwin002.win.tue.nl> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Bright-Idea: Let's abolish HTML mail! cc: hackers@freebsd.org cc: imp@freebsd.org Subject: Re: PCI interrupt allocation question.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2004 23:52:41 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 13, 2004 at 03:26:00PM -0800, Julian Elischer wrote: > The kernel includes teh ichsmb driver to try access the SMBus=20 > for temperature reading reasons (yes I know I can do it other ways..) >=20 > Any thoughts that move me towards getting th eichsmb driver working on > this machine are welcome. Make sure that the mainboard really does support SMBus -- it turns out that this is optional. The ICH docs talk about a bit that should be enabled in t= he PCI config when SMB is present. I ran into this once, it should be document= ed in the archives (of -current off the top of my head). OTOH, I didn't even succeed in getting an ichsmb device probed so this might be something total= ly unrelated. FWIW, I had to try other ways to get the temperature (xmbmon & related). I don't have the box anymore or I'd show you the exact config... --Stijn --=20 Beware of he who would deny you access to information. For in his heart he thinks himself your master. -- Sid Meier, "Sid Meier's Alpha Centauri" --/04w6evG8XlLl3ft Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFABIVfY3r/tLQmfWcRAtcoAJ4p5XqsCIr/YqWtTvw1BvBTyaeN6ACeOUUS YeueP5y7deFh4OWPnDVpLrM= =7izD -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 13 16:14:16 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F0A916A4CE; Tue, 13 Jan 2004 16:14:16 -0800 (PST) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6F6C43D1D; Tue, 13 Jan 2004 16:14:14 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc12) with ESMTP id <20040114001413012007t5rce>; Wed, 14 Jan 2004 00:14:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA02200; Tue, 13 Jan 2004 16:14:11 -0800 (PST) Date: Tue, 13 Jan 2004 16:14:10 -0800 (PST) From: Julian Elischer To: Stijn Hoop In-Reply-To: <20040113235511.GB39353@pcwin002.win.tue.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org cc: imp@freebsd.org Subject: Re: PCI interrupt allocation question.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 00:14:16 -0000 On Wed, 14 Jan 2004, Stijn Hoop wrote: > On Tue, Jan 13, 2004 at 03:26:00PM -0800, Julian Elischer wrote: > > The kernel includes teh ichsmb driver to try access the SMBus > > for temperature reading reasons (yes I know I can do it other ways..) > > > > Any thoughts that move me towards getting th eichsmb driver working on > > this machine are welcome. > > Make sure that the mainboard really does support SMBus -- it turns out that > this is optional. The ICH docs talk about a bit that should be enabled in the > PCI config when SMB is present. I ran into this once, it should be documented > in the archives (of -current off the top of my head). OTOH, I didn't even > succeed in getting an ichsmb device probed so this might be something totally > unrelated. > > FWIW, I had to try other ways to get the temperature (xmbmon & related). I > don't have the box anymore or I'd show you the exact config... xmbmon uses the SMBus to read the temperatures but it does it from userland using direct read and write operations and when there are timing glitches caused by the process not getting scheduled quite quick enough you get garbage results.. teh theory is that the kernel driver wouldn't be susceptible to this but it looks like unless I resort to polling I will not be able to use it because it relies on the interrupts and they are not being delivered. ASUS motherboards actually turn off the SMBus. (why?) So you need to turn it back on before you can read the temperatures.. I have a little script that uses pciconf to do it.. > > --Stijn > > -- > Beware of he who would deny you access to information. For in his heart > he thinks himself your master. > -- Sid Meier, "Sid Meier's Alpha Centauri" > From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 13 16:20:32 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EFDC16A4CE; Tue, 13 Jan 2004 16:20:32 -0800 (PST) Received: from pcwin002.win.tue.nl (pcwin002.win.tue.nl [131.155.71.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id F203843D5A; Tue, 13 Jan 2004 16:20:30 -0800 (PST) (envelope-from stijn@pcwin002.win.tue.nl) Received: from pcwin002.win.tue.nl (orb_rules@localhost [127.0.0.1]) by pcwin002.win.tue.nl (8.12.10/8.12.10) with ESMTP id i0E0N44x040710; Wed, 14 Jan 2004 01:23:04 +0100 (CET) (envelope-from stijn@pcwin002.win.tue.nl) Received: (from stijn@localhost) by pcwin002.win.tue.nl (8.12.10/8.12.10/Submit) id i0E0N4cP040709; Wed, 14 Jan 2004 01:23:04 +0100 (CET) (envelope-from stijn) Date: Wed, 14 Jan 2004 01:23:04 +0100 From: Stijn Hoop To: Julian Elischer Message-ID: <20040114002304.GC39353@pcwin002.win.tue.nl> References: <20040113235511.GB39353@pcwin002.win.tue.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1UWUbFP1cBYEclgG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Bright-Idea: Let's abolish HTML mail! cc: hackers@freebsd.org cc: imp@freebsd.org Subject: Re: PCI interrupt allocation question.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 00:20:32 -0000 --1UWUbFP1cBYEclgG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 13, 2004 at 04:14:10PM -0800, Julian Elischer wrote: > xmbmon uses the SMBus to read the temperatures but it does it from > userland using direct read and write operations Oh, I didn't know that. Like I said the box is gone so I can't really verify what I did anymore :( > and when there are timing glitches caused by the process not getting > scheduled quite quick enough you get garbage results.. > teh theory is that the kernel driver wouldn't be susceptible to this > but it looks like unless I resort to polling I will not be able to use > it because it relies on the interrupts and they are not being delivered. :( > ASUS motherboards actually turn off the SMBus. (why?) > So you need to turn it back on before you can read the temperatures.. > I have a little script that uses pciconf to do it.. The machine I tested this on was a Dell GX115 I think, but even when that bit was enabled using pciconf there was no SMBus device/reading possible... Anyway, it seems to be some other problem so I'm off again :) --Stijn --=20 "I used to think I was indecisive, but now I'm not so sure." --1UWUbFP1cBYEclgG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFABIvoY3r/tLQmfWcRAp0BAKCf8BkVCPxotvH0rTQpARjQCnrq2QCgnUD3 ctDrMo/zbX3GhgLOXr8hOaM= =Q+gL -----END PGP SIGNATURE----- --1UWUbFP1cBYEclgG-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 13 17:26:50 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E4D016A4CE for ; Tue, 13 Jan 2004 17:26:50 -0800 (PST) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id E557D43D55 for ; Tue, 13 Jan 2004 17:26:47 -0800 (PST) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=ganbold.micom.mng.net) by publicd.ub.mng.net with asmtp (Exim 4.30; FreeBSD) id 1AgZjx-0009GI-KH for freebsd-hackers@freebsd.org; Wed, 14 Jan 2004 09:22:37 +0800 Message-Id: <6.0.1.1.2.20040114092613.02a65db8@202.179.0.80> X-Sender: ganbold@micom.mng.net@202.179.0.80 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 14 Jan 2004 09:30:34 +0800 To: freebsd-hackers@freebsd.org From: Ganbold Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: FreeBSD 5.x source update and compilation problem in HP Vectra VE18 -- SOLVED X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 01:26:50 -0000 Hi, Thanks for all who tried to help me. I solved my problem replacing hard disk. It was 4GB seagate IDE HDD. Somehow it was causing the problem. I've changed it and compilation went smoothly. Some suggested me changing the RAM, however RAM change didn't solve the problem. Below is my previous post. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- I installed FreeBSD 5.1 in HP Vectra VE18 PIII 450MHz with 128MB RAM and 4GB HDD. However I'm having problem compiling sources. Whenever I try to make buildworld make stops sometime later saying some variable not found etc. When I check that variable from source it is somehow changed strangely something like: addend changed to adddnd, else changed to dlse, INFOPATH changed to INFNPATH etc. I did cvsup several times, also I used rm -rf /usr/obj cd /usr/src && make cleandir command before compiling. I don't know what to do, I really need to install FreeBSD 5.x on this machine. I even tried with FreeBSD 5.2RC2, but same results. Also I first tried to compile kernel , but it is same, no results. Can somebody help me in this regard? What should I do? ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Ganbold From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 13 20:15:47 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D1E416A4CE for ; Tue, 13 Jan 2004 20:15:47 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 601BD43D48 for ; Tue, 13 Jan 2004 20:15:44 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 3DB475C74A; Tue, 13 Jan 2004 20:15:44 -0800 (PST) Date: Tue, 13 Jan 2004 20:15:44 -0800 From: Alfred Perlstein To: Tim Kientzle Message-ID: <20040114041544.GK9623@elvis.mu.org> References: <20040110050033.GP9623@elvis.mu.org> <20040110222441.GS9623@elvis.mu.org> <400481D8.2030708@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <400481D8.2030708@acm.org> User-Agent: Mutt/1.4.1i cc: Dag-Erling Sm?rgrav cc: hackers@freebsd.org Subject: Re: help with linking please X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 04:15:47 -0000 * Tim Kientzle [040113 15:41] wrote: > Alfred Perlstein wrote: > >It will refuse to strip symbols if: > > > >foo.o:func1() references bar.o:func2(). > > > >But I need it to. > > I suppose there are good reasons why you > cannot compile everything into a single > .o file for distribution? > > > cat master.c > #include > #include > > gcc -o master.o master.c > > Now you have a single .o file with everything > in it and there are therefore no cross-module > references within your library. It would be more trouble than it's worth. I use libssl and libcrypto, it would be a nightmare to #include all those .c files as well as compile it... without incemental compilation it would hurt. What I wound up doing was loading the creating a static object to load my module... er yeah.. :) -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684 From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 13 20:38:39 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 222F916A4CE; Tue, 13 Jan 2004 20:38:39 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D47743D39; Tue, 13 Jan 2004 20:38:37 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i0E4avUd039527; Tue, 13 Jan 2004 23:36:57 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i0E4auof039523; Tue, 13 Jan 2004 23:36:57 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 13 Jan 2004 23:36:56 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Nielsen In-Reply-To: <20040112011942.C78B6840128@mail.npubs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Gratituous ARP and the em driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 04:38:39 -0000 On -1 xxx -1, Nielsen wrote: > When I change IP addresses on my 'em' gigabit NIC, ARP isn't sent > properly. This appears to be the problem in the following bug report, > however i'm using the 'fixed' version of the em driver (in FreeBSD 4.9). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=54488 > > Does anyone have any tips on how to get around this? > > I'm building new systems with gigabit ethernet support and this problem > keeps cropping up. I have a failover system, and when moving an IP alias > between machines, the em NIC driver doesn't properly send out gratituous > ARP, resulting in the IP being inaccessible. > > - The problem does not occur when plugged into a 100BaseTX switch - > FreeBSD 4.9p1 / em version 1.7.16 - Tried various gigabit switches. - > One other odd thing is that when configuring the NIC (ifconfig) the > machine locks up for several seconds. If you run tcpdump on the machine to sniff the interface in question looking for arp packets, does tcpdump see the gratuitous arp? I'm guessing that it does, and the lack of sending the arp is a result of delays in negotiating on the wire. Does this problem turn up only the first time you raise the interface, or every time you change the IP address on the interface? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 13 21:33:13 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7425816A4DF; Tue, 13 Jan 2004 21:33:13 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3876F43D46; Tue, 13 Jan 2004 21:33:11 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i0E5X5ET081545; Tue, 13 Jan 2004 22:33:05 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 13 Jan 2004 22:33:03 -0700 (MST) Message-Id: <20040113.223303.111547284.imp@bsdimp.com> To: cjc@freebsd.org, cristjc@comcast.net From: "M. Warner Losh" In-Reply-To: <20040113211641.GA99925@blossom.cjclark.org> References: <20040113211641.GA99925@blossom.cjclark.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: Measuring Time on Serial Port Events X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 05:33:13 -0000 In message: <20040113211641.GA99925@blossom.cjclark.org> "Crist J. Clark" writes: : I'm doing some work involving measuring latencies of communications : over serial ports. To avoid clock synchronizations issues if we were : running on separate machines, a configuration is a modem hooked into : /dev/cuaa0 and another in /dev/cuaa1. We talk to the modem on cuaa0 : which calls the modem on cuaa1, we tell it to answer, and then we : throw data back and forth and take timestamps. : : Right now, all of the code is running in userland. : : I am trying to figure out what tuning we could do to get things as : accurate as possible. That is, the information we want is the time : that a bunch of bits to leave the COM port versus when they arrive on : the other one. Since things look more like, : : Userland | OS | Comms Hardware | : | | | : [measuring]<->|<-[ sio ]->|<---- UART ---->|<-------> : [ program ] | [driver] | | : : And this doesn't account for delays between when we get the data in : userland and then have to make gettimeofday() calls for timestamps and : other potential delays. The sio driver batches characters up. You get new characters only once every HZ. You can reduce the amount of latency by using a higher HZ. You also have a few character times of latency on top of that due to the FIFOs. sio is optimized for data movement and few interrupts, not for low latency between character arrival and userland. : I'm concerned how far off our measurements in userland will be from : when bits actually arrive and leave on the wire. The data we are : concerned with has latencies of a few 100 ms, but calibrations on the : PSTN are a typically 50-ms-ish. We need to have a few significant : digits below that. : : Any pointers? Make HZ 5000 or something like that. If it is critical that you get things down to a few microseconds, chances are you may need to hack your own driver together... Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 13 22:55:02 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C746A16A4CF for ; Tue, 13 Jan 2004 22:55:02 -0800 (PST) Received: from ns1.unixmexico.net (ns1.unixmexico.net [69.10.138.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E08F43D5A for ; Tue, 13 Jan 2004 22:54:58 -0800 (PST) (envelope-from nbari@unixmexico.com) Received: (qmail 41300 invoked by uid 85); 14 Jan 2004 06:59:17 -0000 Received: from nbari@unixmexico.com by ns1.unixmexico.net by uid 82 with qmail-scanner-1.16 (hbedv: 6.22.0.1/6.22.0.6. Clear:. Processed in 0.337516 secs); 14 Jan 2004 06:59:17 -0000 Received: from ns1.unixmexico.net (HELO mail.unixmexico.com) ([69.10.138.161]) (envelope-sender ) by ns1.unixmexico.net (qmail-ldap-1.03) with SMTP for ; 14 Jan 2004 06:59:16 -0000 Received: from 148.243.211.1 (SquirrelMail authenticated user nbari@unixmexico.com) by mail.unixmexico.com with HTTP; Wed, 14 Jan 2004 00:59:16 -0600 (CST) Message-ID: <52975.148.243.211.1.1074063556.squirrel@mail.unixmexico.com> Date: Wed, 14 Jan 2004 00:59:16 -0600 (CST) From: =?iso-8859-1?Q?Nicol=E1s_de_Bari_Embr=EDz_G._R.?= To: freebsd-isp@freebsd.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal cc: freebsd-hackers@freebsd.org Subject: Routing Networks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 06:55:03 -0000 Hi all, I need some help routing or making Nat on a LAN. I have something like this: I N T E R N E T ----------------- ^ ^ | | fxp0 public IP public IP | | FreeBSD server LINUX server | | dc0 192.168.10.1 | dc1 192.168.1.1 ^ 192.168.1.3 ^ | ^ | | | | | | ---------------- | Switch/Hub | ---------------- | | ------------------ ----------------- | LAN A | | LAN B | | 192.168.10.2-254 | | 192.168.1.4-100 | ------------------ ----------------- I have running a FreeBSD server as a gateway and DHCP, the server share the Internet to all the computers on LAN A (192.168.10.0/24). The server have 3 network cards: fxp0 is public IP. dc0 is the gateway for the LAN A "192.168.10.1". dc1 has IP 192.168.1.1 ( need help with this ). Right now i am just using fxp0 and dc0 so any computer on the LAN A "192.168.10.2-254" can have Internet, my ipnat.rules file looks like this: -- map fxp0 192.168.10.1/24 -> 0/32 portmap tcp/udp auto map fxp0 192.168.10.1/24 -> 0/32 -- until that point everything just work OK. There is another network, I will call it LAN B, this LAN make the same thing that i am doing with the FreeBSD Server, but instead it uses LINUX, the m achine have 2 network cars. eth0 has a public IP. eth1 is the gateway for the LAN B "192.168.1.3" Both networks are connected to the same switch/hub, but now i need that the computers of LAN A can see "ping" computers on LAN B. If I configure the third nick "dc1" on the FreeBSD server to have an IP on the range of LAN B for example with ip 192.168.1.1, then I can see all the computers from both LAN's, I can ping, telnet, ssh etc. to both 192.168.10.X and 192.168.1.X. networks "standing on the FreeBSD server." What i want to do is that a computer on LAN A with an IP on the range of 192.168.10.2-254 can ping, telnet, ssh, etc. to a computer on LAN B "192.168.1.X". How can i solve this problem, is this is a route or Nat problem ? There is one more issue, I can't touch the LINUX SERVER I can just be a client or join the LAN by configure a nic with a IP on the range of 192.168.1.0/24. I have been trying to fix this with static routes but i am not having luck. Any help will be apreciated. regards. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 13 23:41:16 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A2AB16A4CE; Tue, 13 Jan 2004 23:41:16 -0800 (PST) Received: from correo.tid.es (tidos.tid.es [193.145.240.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6A0D43D1D; Tue, 13 Jan 2004 23:41:13 -0800 (PST) (envelope-from igf@tid.es) Received: from conversion-daemon.tid.hi.inet by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) id <0HRG00001XQSE4@tid.hi.inet>; Wed, 14 Jan 2004 08:41:12 +0100 (MET) Received: from tid.es (sophia.hi.inet [10.95.43.243]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0HRG003ATYOOKB@tid.hi.inet>; Wed, 14 Jan 2004 08:41:12 +0100 (MET) Date: Wed, 14 Jan 2004 08:43:37 +0100 From: Isaac Gelado To: freebsd-hackers@freebsd.org Message-id: <4004F329.1000902@tid.es> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT X-Accept-Language: es-es, es, en-us User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.0.1) Gecko/20020823 Netscape/7.0 References: <52975.148.243.211.1.1074063556.squirrel@mail.unixmexico.com> cc: freebsd-isp@freebsd.org cc: nbari@unixmexico.com Subject: Re: Routing Networks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 07:41:16 -0000 Nicolás de Bari Embríz G. R. escribió: > Hi all, I need some help routing or making Nat on a LAN. > > I have something like this: > > > I N T E R N E T > ----------------- > ^ ^ > | | > fxp0 public IP public IP > | | > FreeBSD server LINUX server > | | > dc0 192.168.10.1 | > dc1 192.168.1.1 ^ 192.168.1.3 > ^ | ^ > | | | > | | | > ---------------- > | Switch/Hub | > ---------------- > | | > ------------------ ----------------- > | LAN A | | LAN B | > | 192.168.10.2-254 | | 192.168.1.4-100 | > ------------------ ----------------- > > > What i want to do is that a computer on LAN A with an IP on the range of > 192.168.10.2-254 can ping, telnet, ssh, etc. to a computer on LAN B > "192.168.1.X". > > How can i solve this problem, is this is a route or Nat problem ? I think it is a route problem. You must add next static route: - On the linux machine route all incoming packets with dest addr 192.168.10.x to 192.168.1.1 It shouldn't be necesary a static route on the freebsd machine since it has a network device with an addr of LAN B. Of course you must run a route daemon in both machines (I supouse it's running now since they are working as gateways) and the previous route must be added to the route daemon running on the linux machine. You can allways check that packets are going by the correct way with traceroute. Regards, Isaac -- __________________________________________________________ | Isaac Gelado | | | Telefónica I+D | Tlf 983367649 | | Paq. Tec. de Boecillo | | | Valladolid | igf@tid.es | |_______________________________|__________________________| | As gold which he cannot spend will make no man rich | | so knowledge which he cannot apply will make no man wise | |__________________________________________________________| From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 03:02:09 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B5CD16A4CE; Wed, 14 Jan 2004 03:02:09 -0800 (PST) Received: from lilith.bellavista.cz (bellavista.worldonline.cz [212.90.245.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59D7943D5E; Wed, 14 Jan 2004 03:02:07 -0800 (PST) (envelope-from neuhauser@bellavista.cz) Received: from freepuppy.bellavista.cz (freepuppy.bellavista.cz [10.0.0.10]) by lilith.bellavista.cz (Postfix) with ESMTP id 473AA5C; Wed, 14 Jan 2004 12:02:05 +0100 (CET) Received: by freepuppy.bellavista.cz (Postfix, from userid 1001) id 35ECC2FDA03; Wed, 14 Jan 2004 12:02:05 +0100 (CET) Date: Wed, 14 Jan 2004 12:02:05 +0100 From: Roman Neuhauser To: freebsd-current , freebsd-hackers Message-ID: <20040114110205.GC4820@freepuppy.bellavista.cz> Mail-Followup-To: freebsd-current , freebsd-hackers References: <20040109203839.GK5994@freepuppy.bellavista.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040109203839.GK5994@freepuppy.bellavista.cz> User-Agent: Mutt/1.5.4i Subject: Re: beastie boot menu, 4th (forth) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 11:02:09 -0000 I'd like to thank everyone who's replied to my questions regarding the beastie menu and 4th. my mail has attracted far more attention than I expected. -- If you cc me or remove the list(s) completely I'll most likely ignore your message. see http://www.eyrie.org./~eagle/faqs/questions.html From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 13 22:30:50 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A64116A4CE for ; Tue, 13 Jan 2004 22:30:50 -0800 (PST) Received: from alabama.innomedia.soft.net (ns.innomedia.soft.net [164.164.79.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6109A43D5C for ; Tue, 13 Jan 2004 22:30:43 -0800 (PST) (envelope-from soodhakar@innomedia.soft.net) Received: from sudhakar ([192.168.1.43])i0E6Udt00771 for ; Wed, 14 Jan 2004 12:00:41 +0530 Message-ID: <002b01c3da68$3342dde0$2b01a8c0@sudhakar> From: "sudhakar" To: Date: Wed, 14 Jan 2004 12:02:35 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailman-Approved-At: Wed, 14 Jan 2004 05:33:43 -0800 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: TOS bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 06:30:50 -0000 =20 Hi, I want to know the TOS bit at server side which is set at the client = side. i have a TCP connection. I do not want a RAW socket connection. I = require it urgently If anyone can help me reply soon. I have not = subscribed to this mailing list please cc the mail to mail id=20 soodhakar@innomedia.soft.net. see u soon . . . ********************************************* SUDHAKAR MOHARANA Innomedia technologies pvt ltd. #3278,12th main,100ft road,HAL 2nd stage, indiranagar,bangalore-8 ph :-(080)5252807,5278444,ext-144 (O) ********************************************* From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 08:25:28 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7D9B16A4CE for ; Wed, 14 Jan 2004 08:25:28 -0800 (PST) Received: from sizone.org (mortar.sizone.org [65.126.154.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8AFF43D67 for ; Wed, 14 Jan 2004 08:25:25 -0800 (PST) (envelope-from dgilbert@daveg.ca) Received: by sizone.org (Postfix, from userid 66) id EDAC72FE04; Wed, 14 Jan 2004 10:54:31 -0500 (EST) Received: by canoe.dclg.ca (Postfix, from userid 101) id D0DE31D2095; Wed, 14 Jan 2004 10:48:45 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16389.25821.502399.872877@canoe.dclg.ca> Date: Wed, 14 Jan 2004 10:48:45 -0500 To: freebsd-hackers@freebsd.org X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid Subject: Filesystem marker. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 16:25:28 -0000 Is there a set of bytes at some offset in a block that is common to any instance of a BSD ufs filesystem? I ask because recently my home machine erased it's fdisk block _and_ the bsdlabel with it. It certainly didn't have time to erase the whole disk, but I'm having trouble guessing where the partitions are. /usr/ports/sysutils/gpart will look for partitions on a disk ... but it only knows to look for bsd disklabels ... not bsd filesystems. Ideally, I'd like to make a bsd filesystem module for gpart with some pointers from the group. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 08:25:44 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BAEE16A4FB for ; Wed, 14 Jan 2004 08:25:44 -0800 (PST) Received: from bewilderbeast.blackhelicopters.org (bewilderbeast.blackhelicopters.org [198.22.63.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 926F743D1D for ; Wed, 14 Jan 2004 08:25:41 -0800 (PST) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (mwlucas@localhost [127.0.0.1])i0EGPdGP081753; Wed, 14 Jan 2004 11:25:39 -0500 (EST) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: (from mwlucas@localhost)i0EGPdRg081752; Wed, 14 Jan 2004 11:25:39 -0500 (EST) (envelope-from mwlucas) Date: Wed, 14 Jan 2004 11:25:39 -0500 From: "Michael W. Lucas" To: "Michael R. Wayne" Message-ID: <20040114162539.GA81326@bewilderbeast.blackhelicopters.org> References: <200401130746.i0D7kNEk004375@manor.msen.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401130746.i0D7kNEk004375@manor.msen.com> User-Agent: Mutt/1.4.1i X-Spam-Status: No, hits=-5.0 required=4.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: hackers@freebsd.org Subject: Re: Mergemaster+RCS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 16:25:44 -0000 Woo hoo! We'll test this here the next time we upgrade. Could you send-pr this, so it doesn't get lost? Thanks! ==ml On Tue, Jan 13, 2004 at 02:46:23AM -0500, Michael R. Wayne wrote: > > Although Doug Barton has written a wonderful tool, it has always > seemed to have a major deficiency: it completely ignores the > existance of RCS files. I've exchanged some email with Doug and > he has no interest in adding RCS support to mergemaster. So I did. > > Doug has mentioned that some people solve this problem by using > the precompare script or by checking out all RCS files before > running mergemaster then checking them in afterwards. These > solutions are highly unattractive to me since they require sysadmins > to remember far too much, especially given that systems are often > upgraded at off hours to minimize user impact. > > The attached patch to the mergemaster in 4.9-RELEASE-p1 addresses > this issue. Specifically, it does the following, automatically: > > For every file that mergemaster replaces, check for the existance > of an associated RCS log file in the RCS subdirectory. (I do > NOT check for the logfile in the current directory). > If such a logfile exists > If the file is currently checked out, check it in with an automated comment. > Check the file out. > Apply the upgrade. > Check the file in with an automated comment. > If the file was originally checked out, check it back out again. > If no associated RCS log file exists, there is no change in the > operation of mergemaster. > > I take care to leave the log file in the original checked in/out > state: People have tools that "know" the state of logfiles and > these tools should not be broken. > > This seems to work for us. Comments/suggestions welcome. > > /\/\ \/\/ > > > *** /usr/sbin/mergemaster Thu Jan 8 17:03:30 2004 > --- mergemaster+rcs Fri Jan 9 08:45:19 2004 > *************** > *** 8,20 **** > # Copyright 1998-2003 Douglas Barton > # DougB@FreeBSD.org > > # $FreeBSD: src/usr.sbin/mergemaster/mergemaster.sh,v 1.6.2.18 2003/08/25 08:27:41 dougb Exp $ > > PATH=/bin:/usr/bin:/usr/sbin > > display_usage () { > VERSION_NUMBER=`grep "[$]FreeBSD:" $0 | cut -d ' ' -f 4` > ! echo "mergemaster version ${VERSION_NUMBER}" > echo 'Usage: mergemaster [-scrvahipCP] [-m /path]' > echo ' [-t /path] [-d] [-u N] [-w N] [-D /path]' > echo "Options:" > --- 8,22 ---- > # Copyright 1998-2003 Douglas Barton > # DougB@FreeBSD.org > > + # Automated support for RCS log files added 2004 by wayne@msen.com > + > # $FreeBSD: src/usr.sbin/mergemaster/mergemaster.sh,v 1.6.2.18 2003/08/25 08:27:41 dougb Exp $ > > PATH=/bin:/usr/bin:/usr/sbin > > display_usage () { > VERSION_NUMBER=`grep "[$]FreeBSD:" $0 | cut -d ' ' -f 4` > ! echo "mergemaster version ${VERSION_NUMBER} with RCS support" > echo 'Usage: mergemaster [-scrvahipCP] [-m /path]' > echo ' [-t /path] [-d] [-u N] [-w N] [-D /path]' > echo "Options:" > *************** > *** 646,653 **** > --- 648,695 ---- > ;; > esac > > + # Begin part 1 of 2 support for RCS added by wayne@msen.com > + # Deals with RCS log files in the RCS subdirectory, first checking > + # in previous changes (if any), checks in the changes made by > + # mergemaster and leaves the file in the original checked in/out state. > + # > + # Assume we will not need to check this file in. > + local MM_RCS > + MM_RCS=0 > + if [ -d ${3}/RCS ]; then > + # The RCS directory exists, check it for this logfile > + if [ -e ${3}/RCS/${2##*/},v ]; then > + # The RCS logfile exists, now we need to know it's existing state > + if [ -z `rlog -L -R ${3}/${2##*/}` ]; then > + # Target file is unlocked, check it out > + co -l ${3}/${2##*/} > + # Remember to leave file unlocked after install > + MM_RCS=1 > + else > + # File is already locked, check it in before we mess with it > + ci -l -m"Mergemaster auto checkin of locked file." ${3}/${2##*/} > + # Remember to leave file locked after install > + MM_RCS=2 > + fi > + fi > + fi > + # End part 1 of 2 support for RCS added by wayne@msen.com > + > install -m "${1}" "${2}" "${3}" && > rm -f "${2}" > + > + # Begin part 2 of 2 support for RCS added by wayne@msen.com > + if [ $MM_RCS -eq 1 ]; then > + # Checkin the file, leaving it unlocked > + ci -u -m"Mergemaster auto checkin after updates" ${3}/${2##*/} > + elif [ $MM_RCS -eq 2 ]; then > + # Checkin the file, leaving it locked > + ci -l -m"Mergemaster auto checkin after updates" ${3}/${2##*/} > + else > + # Do nothing, no RCS log file exists > + fi > + # End part 2 of 2 support for RCS added by wayne@msen.com > + > } > > find_mode () { > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Michael Lucas mwlucas@FreeBSD.org, mwlucas@BlackHelicopters.org Today's chance of throwing it all away to start a goat farm: 41.8% http://www.BlackHelicopters.org/~mwlucas/ Absolute OpenBSD: http://www.AbsoluteOpenBSD.com/ From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 08:41:53 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3348016A4CE for ; Wed, 14 Jan 2004 08:41:53 -0800 (PST) Received: from newman.gte.com (newman.gte.com [132.197.8.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA52B43D68 for ; Wed, 14 Jan 2004 08:41:44 -0800 (PST) (envelope-from ak03@gte.com) Received: from h132-197-179-27.gte.com (kanpc.gte.com [132.197.179.27]) by newman.gte.com (8.9.1/8.9.1) with ESMTP id LAA21093; Wed, 14 Jan 2004 11:41:44 -0500 (EST) Received: from kanpc.gte.com (localhost [IPv6:::1])i0EGfhiw010978; Wed, 14 Jan 2004 11:41:43 -0500 (EST) (envelope-from ak03@gte.com) Date: Wed, 14 Jan 2004 11:41:43 -0500 From: Alexander Kabaev To: David Gilbert Message-Id: <20040114114143.0d98d930@kanpc.gte.com> In-Reply-To: <16389.25821.502399.872877@canoe.dclg.ca> References: <16389.25821.502399.872877@canoe.dclg.ca> Organization: Verizon Data Services X-Mailer: Sylpheed version 0.9.8claws23 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: Filesystem marker. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 16:41:53 -0000 Look for ffsfind.c elsewhere on Internet. I used one when I incidentally relabeled a device from under a host on our SAN array. Had to modify it slightly to recognize superblocks UFS2 on FreeBSD side, but on a bright side, it worked pretty much unchanged on Solaris box. Just in any case, I saved my copy at http://people.freebsd.org/~kan/ffsfind.c On Wed, 14 Jan 2004 10:48:45 -0500 David Gilbert wrote: > Is there a set of bytes at some offset in a block that is common to > any instance of a BSD ufs filesystem? I ask because recently my home > machine erased it's fdisk block _and_ the bsdlabel with it. It > certainly didn't have time to erase the whole disk, but I'm having > trouble guessing where the partitions are. > > /usr/ports/sysutils/gpart will look for partitions on a disk ... but > it only knows to look for bsd disklabels ... not bsd filesystems. > Ideally, I'd like to make a bsd filesystem module for gpart with some > pointers from the group. > > Dave. > > -- > ===================================================================== > =======|David Gilbert, Independent Contractor. | Two things can > only be ||Mail: dave@daveg.ca | equal if > and only if they ||http://daveg.ca | > are precisely opposite. > |=========================================================GLO======== > ========_______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" -- Alexander Kabaev From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 10:56:39 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 150BA16A4CE for ; Wed, 14 Jan 2004 10:56:39 -0800 (PST) Received: from pds.uberhacker.org (uberhacker.org [198.144.198.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE2A043D67 for ; Wed, 14 Jan 2004 10:56:37 -0800 (PST) (envelope-from ryanb@goddamnbastard.org) Received: from localhost (localhost [127.0.0.1]) by pds.uberhacker.org (Postfix) with ESMTP id 6E65326D for ; Wed, 14 Jan 2004 10:56:37 -0800 (PST) Received: from pds.uberhacker.org ([127.0.0.1]) by localhost (pds.uberhacker.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90597-04 for ; Wed, 14 Jan 2004 10:56:36 -0800 (PST) Received: by pds.uberhacker.org (Postfix, from userid 1003) id 3C9D5229; Wed, 14 Jan 2004 10:56:36 -0800 (PST) Date: Wed, 14 Jan 2004 12:56:36 -0600 From: Ryan Beasley To: freebsd-hackers@freebsd.org Message-ID: <20040114185636.GA60885@uberhacker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new at uberhacker.org Subject: p_[usi]ticks from userland without kvm and procfs? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 18:56:39 -0000 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, -hackers! I'm poring over some code that uses the p_[usi]ticks counters inside of struct proc. This is fine under 4.x where kinfo_proc includes a copy of proc, but is broken under 5.x since a commit 3 years ago that reorganized kinfo_proc. So, outside of kvm and procfs, is there any user<->kernel interface for getting to struct proc or just those counters? (getrusage is kinda close except one can't lookup info about another process. :|. ) Any info is welcome. TIA! --=20 ryan beasley GPG ID: 0x16EFBD48 --opJtzjQTFsWo+cga Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFABZDkskfdOxbvvUgRAgC7AJ4p92rziBLdhCQLsL5ETlHEWCUjYgCfQBJu u+rXWDcki2i2seCTq2q68Mg= =wbfq -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 11:19:57 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6448316A4CE for ; Wed, 14 Jan 2004 11:19:57 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D937C43D68 for ; Wed, 14 Jan 2004 11:19:53 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i0EJICUd050740; Wed, 14 Jan 2004 14:18:12 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i0EJICTh050737; Wed, 14 Jan 2004 14:18:12 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 14 Jan 2004 14:18:12 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Ryan Beasley In-Reply-To: <20040114185636.GA60885@uberhacker.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: p_[usi]ticks from userland without kvm and procfs? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 19:19:57 -0000 On Wed, 14 Jan 2004, Ryan Beasley wrote: > I'm poring over some code that uses the p_[usi]ticks counters inside of > struct proc. This is fine under 4.x where kinfo_proc includes a copy of > proc, but is broken under 5.x since a commit 3 years ago that > reorganized kinfo_proc. > > So, outside of kvm and procfs, is there any user<->kernel interface for > getting to struct proc or just those counters? (getrusage is kinda > close except one can't lookup info about another process. :|. ) libkvm uses two back-ends to retrieve information from the kernel: it can either retrieve it using sysctl() on a live kernel, or using kvm access on /dev/kmem or a core file. Generally, using sysctl() is preferred for a live kernel, as it requires no special privilege, and also lets the kernel decide what data is revealed to the user application (i.e., hide processes owned by other users). The kernel function that generally exports process information userspace access is sysctl_out_proc() in src/sys/kern/kern_proc.c, which calls kill_info_proc() of fill_kinfo_thread(), depending on a flag passed to sysctl. Those fields are now part of the thread definition as opposed to the proc definition, and don't appear in the externalized structure in -current (that I can tell). A lot of process accounting and measurement changed with the introduction of M:N threads (KSE), and some of the details haven't yet been sorted out as part of the dust settling. It could well be that the fields are not currently maintained properly, and that the functionality in the kernel needs to be fixed to measure them again properly. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 11:23:01 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE6B416A4CE for ; Wed, 14 Jan 2004 11:23:01 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83DF743D46 for ; Wed, 14 Jan 2004 11:22:50 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i0EJKtUd050786; Wed, 14 Jan 2004 14:20:55 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i0EJKt9K050783; Wed, 14 Jan 2004 14:20:55 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 14 Jan 2004 14:20:55 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: David Gilbert In-Reply-To: <16389.25821.502399.872877@canoe.dclg.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: Filesystem marker. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 19:23:01 -0000 On Wed, 14 Jan 2004, David Gilbert wrote: > Is there a set of bytes at some offset in a block that is common to any > instance of a BSD ufs filesystem? I ask because recently my home > machine erased it's fdisk block _and_ the bsdlabel with it. It > certainly didn't have time to erase the whole disk, but I'm having > trouble guessing where the partitions are. > > /usr/ports/sysutils/gpart will look for partitions on a disk ... but it > only knows to look for bsd disklabels ... not bsd filesystems. Ideally, > I'd like to make a bsd filesystem module for gpart with some pointers > from the group. I ported the OpenBSD version of their scan_ffs to FreeBSD. However, it only speaks UFS1: http://www.watson.org/~robert/freebsd/scan_ffs_freebsd4/ It might also require tweaking to even build on -CURRENT, as I haven't lost any file systems recently enough to have needed to test. One of the nice things about this tool is that it can generate output that can then be fed into disklabel to write the disklabel you need back to disk. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 06:06:21 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 206D716A4CE; Wed, 14 Jan 2004 06:06:21 -0800 (PST) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FB7F43D64; Wed, 14 Jan 2004 06:06:20 -0800 (PST) (envelope-from fanf@chiark.greenend.org.uk) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local id 1Aglf1-0003pp-00; Wed, 14 Jan 2004 14:06:19 +0000 To: nick@garage.freebsd.pl From: Tony Finch In-Reply-To: <20040112124521.GE74246@garage.freebsd.pl> References: <40007D14.6090205@freebsd.org> <400135EA.8050603@energyhq.es.eu.org> <400135EA.8050603@energyhq.es.eu.org> Message-Id: Sender: Tony Finch Date: Wed, 14 Jan 2004 14:06:19 +0000 X-Mailman-Approved-At: Wed, 14 Jan 2004 11:29:30 -0800 cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: Future of RAIDFrame X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 14:06:21 -0000 Pawel Jakub Dawidek wrote: > >I'm working on one geom class (called for now geom_raid) which will support >transformations like: concatenation, stripe (raid0), mirror (raid1), raid4 >and raid5. Isn't is more GEOMish to have a separate GEOM class for each transformation? Tony. -- f.a.n.finch http://dotat.at/ SHANNON: NORTHWEST BACKING SOUTHWEST 6 TO GALE 8. SHOWERS. MODERATE OR GOOD. From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 11:31:46 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B91716A4CE; Wed, 14 Jan 2004 11:31:46 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58C2643D6A; Wed, 14 Jan 2004 11:31:34 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.3) with ESMTP id i0EJTlaT023805; Wed, 14 Jan 2004 11:29:47 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i0EJTlLV023804; Wed, 14 Jan 2004 11:29:47 -0800 Date: Wed, 14 Jan 2004 11:29:47 -0800 From: Brooks Davis To: Robert Watson Message-ID: <20040114192943.GB20013@Odin.AC.HMC.Edu> References: <16389.25821.502399.872877@canoe.dclg.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aVD9QWMuhilNxW9f" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: freebsd-hackers@freebsd.org cc: David Gilbert Subject: Re: Filesystem marker. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 19:31:46 -0000 --aVD9QWMuhilNxW9f Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 14, 2004 at 02:20:55PM -0500, Robert Watson wrote: >=20 > On Wed, 14 Jan 2004, David Gilbert wrote: >=20 > > Is there a set of bytes at some offset in a block that is common to any > > instance of a BSD ufs filesystem? I ask because recently my home > > machine erased it's fdisk block _and_ the bsdlabel with it. It > > certainly didn't have time to erase the whole disk, but I'm having > > trouble guessing where the partitions are.=20 > >=20 > > /usr/ports/sysutils/gpart will look for partitions on a disk ... but it > > only knows to look for bsd disklabels ... not bsd filesystems. Ideally, > > I'd like to make a bsd filesystem module for gpart with some pointers > > from the group.=20 >=20 > I ported the OpenBSD version of their scan_ffs to FreeBSD. However, it > only speaks UFS1: >=20 > http://www.watson.org/~robert/freebsd/scan_ffs_freebsd4/ >=20 > It might also require tweaking to even build on -CURRENT, as I haven't > lost any file systems recently enough to have needed to test. One of the > nice things about this tool is that it can generate output that can then > be fed into disklabel to write the disklabel you need back to disk. A port of scan_ffs that support UFS1 and UFS2 was committed yesterday as sysutils/scan_ffs: http://www.freshports.org/sysutils/scan_ffs -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --aVD9QWMuhilNxW9f Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFABZimXY6L6fI4GtQRAm9EAJ9zYHMlKbgZbhYnHSbUPl73qWujawCgyajH GS5xseKOJRrPMstbRZuqemg= =jWMr -----END PGP SIGNATURE----- --aVD9QWMuhilNxW9f-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 12:45:46 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E66316A4CE; Wed, 14 Jan 2004 12:45:46 -0800 (PST) Received: from mail.npubs.com (mail.writemehere.com [209.66.100.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A86643D88; Wed, 14 Jan 2004 12:45:11 -0800 (PST) (envelope-from nielsen@memberwebs.com) Resent-Message-Id: Message-ID: <4005AA55.3080202@memberwebs.com> From: Nielsen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Resent-Date: Wed, 14 Jan 2004 20:45:30 +0000 (GMT) Resent-From: nielsen@memberwebs.com (Postfix Filters) cc: freebsd-net@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Gratituous ARP and the em driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 14 Jan 2004 20:45:46 -0000 X-List-Received-Date: Wed, 14 Jan 2004 20:45:46 -0000 Yes, this is the case. I tested it again, and the arp packet in question doesn't get to the other machines. The sending machine does send gratituous arp, however the em NIC is down for 3 or 4 seconds, and the packet isn't sent on the wire. I find it odd that the em driver would need to reinitialize the NIC each time an alias is added. I haven't seen any other network drivers do this. And, yes, it occurs every time an alias is added or removed from the NIC. Not just the first time. Cheers, Nate Robert Watson wrote: >On -1 xxx -1, Nielsen wrote: >If you run tcpdump on the machine to sniff the interface in question >looking for arp packets, does tcpdump see the gratuitous arp? I'm >guessing that it does, and the lack of sending the arp is a result of >delays in negotiating on the wire. Does this problem turn up only the >first time you raise the interface, or every time you change the IP >address on the interface? > >Robert N M Watson FreeBSD Core Team, TrustedBSD Projects >robert@fledge.watson.org Senior Research Scientist, McAfee Research > > From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 12:56:00 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3066316A4CE for ; Wed, 14 Jan 2004 12:56:00 -0800 (PST) Received: from wattres.Watt.COM (wattres.watt.com [66.93.133.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 111D743D9B for ; Wed, 14 Jan 2004 12:55:50 -0800 (PST) (envelope-from steve@Watt.COM) Received: (from steve@localhost) by wattres.Watt.COM (8.12.9/8.12.9) id i0EKtnL6085950 for hackers@freebsd.org; Wed, 14 Jan 2004 12:55:49 -0800 (PST) (envelope-from steve) Message-Id: <200401142055.i0EKtnL6085950@wattres.Watt.COM> From: steve@Watt.COM (Steve Watt) Date: Wed, 14 Jan 2004 12:55:49 -0800 X-Mailer: Mail User's Shell (7.2.6 beta(5) jp(8) 11/23/00) To: hackers@freebsd.org Subject: kernel environment between reboots, diskless X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 20:56:00 -0000 Greetings, I'm working on a dataless system that will be booting and rooting from flash for some environmental chamber (thermal) tests, and logging the results to an NFS server outside the chamber. The problem is that the driver for the card under test only supports one card at a time. That's relatively easy to hack around by passing in a kernel environment varible from loader that indicates which PCI slot is OK. Then the probe routine of the driver looks for that variable and won't accept the device unless it matches. I'm trying to see if there's a way to get that information into the loader (or the driver) in some way that doesn't require rewriting a file in the flash every reboot, to avoid flash write cycles. I know there's some amount of NVRAM in PCs, but didn't spot anything about how to get at it from the driver. It'd be nice, for this sort of application, if there was a way to stash somewhere between 2 and 8 bytes somewhere... Thanks for insights! Pls cc: me directly on replies. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9" Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 13:06:21 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03ABF16A4CE; Wed, 14 Jan 2004 13:06:21 -0800 (PST) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6382743D60; Wed, 14 Jan 2004 13:06:06 -0800 (PST) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (c-24-6-186-224.client.comcast.net[24.6.186.224]) by comcast.net (rwcrmhc13) with ESMTP id <2004011421060501500blcice>; Wed, 14 Jan 2004 21:06:05 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id i0EL6443049194; Wed, 14 Jan 2004 13:06:04 -0800 (PST) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id i0EL63TH049193; Wed, 14 Jan 2004 13:06:03 -0800 (PST) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Wed, 14 Jan 2004 13:06:03 -0800 From: "Crist J. Clark" To: Isaac Gelado Message-ID: <20040114210603.GA49090@blossom.cjclark.org> References: <52975.148.243.211.1.1074063556.squirrel@mail.unixmexico.com> <4004F329.1000902@tid.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4004F329.1000902@tid.es> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ cc: freebsd-isp@freebsd.org cc: freebsd-hackers@freebsd.org cc: nbari@unixmexico.com Subject: Re: Routing Networks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Crist J. Clark" List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 21:06:21 -0000 On Wed, Jan 14, 2004 at 08:43:37AM +0100, Isaac Gelado wrote: > Nicol?s de Bari Embr?z G. R. escribi?: > >Hi all, I need some help routing or making Nat on a LAN. > > > >I have something like this: > > > > > > I N T E R N E T > > ----------------- > > ^ ^ > > | | > >fxp0 public IP public IP > > | | > > FreeBSD server LINUX server > > | | > >dc0 192.168.10.1 | > >dc1 192.168.1.1 ^ 192.168.1.3 > > ^ | ^ > > | | | > > | | | > > ---------------- > > | Switch/Hub | > > ---------------- > > | | > > ------------------ ----------------- > > | LAN A | | LAN B | > > | 192.168.10.2-254 | | 192.168.1.4-100 | > > ------------------ ----------------- > > > > > >What i want to do is that a computer on LAN A with an IP on the range of > >192.168.10.2-254 can ping, telnet, ssh, etc. to a computer on LAN B > >"192.168.1.X". > > > >How can i solve this problem, is this is a route or Nat problem ? > > I think it is a route problem. You must add next static route: > > - On the linux machine route all incoming packets with dest addr > 192.168.10.x to 192.168.1.1 > > It shouldn't be necesary a static route on the freebsd machine since it > has a network device with an addr of LAN B. This is correct. Things can get from LAN A to LAN B just fine in this picture. The problem is that machines on LAN B won't be able to get back to LAN A (i.e. your pings go from A to B, but the pongs never get back from B to A). You'll have to touch that Linux box or touch the routes on everything on LAN B to route 192.168.10.0/24 through 192.168.1.1. > Of course you must run a > route daemon in both machines (I supouse it's running now since they are > working as gateways) and the previous route must be added to the route > daemon running on the linux machine. OK now here is the problem. Why does he need a routing daemon? I saw no mention of RIP, OSPF, or any other dynamic routing protocol. Looks like it's all static routes to me. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 13:11:45 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8AE116A4CE for ; Wed, 14 Jan 2004 13:11:45 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2299C43D95 for ; Wed, 14 Jan 2004 13:11:33 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.3) with ESMTP id i0ELBTaT007014; Wed, 14 Jan 2004 13:11:29 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i0ELBTs4007009; Wed, 14 Jan 2004 13:11:29 -0800 Date: Wed, 14 Jan 2004 13:11:29 -0800 From: Brooks Davis To: Steve Watt Message-ID: <20040114211129.GB4974@Odin.AC.HMC.Edu> References: <200401142055.i0EKtnL6085950@wattres.Watt.COM> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SkvwRMAIpAhPCcCJ" Content-Disposition: inline In-Reply-To: <200401142055.i0EKtnL6085950@wattres.Watt.COM> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: hackers@freebsd.org Subject: Re: kernel environment between reboots, diskless X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 21:11:45 -0000 --SkvwRMAIpAhPCcCJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 14, 2004 at 12:55:49PM -0800, Steve Watt wrote: > Greetings, >=20 > I'm working on a dataless system that will be booting and rooting > from flash for some environmental chamber (thermal) tests, and > logging the results to an NFS server outside the chamber. I've got to ask, if you're in an NFS environment, why boot from flash at all? Why not PXE boot or use etherboot? -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --SkvwRMAIpAhPCcCJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFABbB/XY6L6fI4GtQRAlo8AKDJAzZzI/cO5qgXryYP8MJbL39HawCaAi0V ALIMQ24bmNUQeKSpGYqpZM4= =wY82 -----END PGP SIGNATURE----- --SkvwRMAIpAhPCcCJ-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 13:16:02 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 449B216A4CE for ; Wed, 14 Jan 2004 13:16:02 -0800 (PST) Received: from wattres.Watt.COM (wattres.watt.com [66.93.133.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6562B43D58 for ; Wed, 14 Jan 2004 13:16:01 -0800 (PST) (envelope-from steve@Watt.COM) Received: (from steve@localhost) by wattres.Watt.COM (8.12.9/8.12.9) id i0ELG1RX088594; Wed, 14 Jan 2004 13:16:01 -0800 (PST) (envelope-from steve) Message-Id: <200401142116.i0ELG1RX088594@wattres.Watt.COM> From: steve@Watt.COM (Steve Watt) Date: Wed, 14 Jan 2004 13:16:01 -0800 In-Reply-To: Brooks Davis "Re: kernel environment between reboots, diskless" (Jan 14, 13:11) X-Mailer: Mail User's Shell (7.2.6 beta(5) jp(8) 11/23/00) To: Brooks Davis cc: hackers@freebsd.org Subject: Re: kernel environment between reboots, diskless X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 21:16:02 -0000 On Jan 14, 13:11, Brooks Davis wrote: } On Wed, Jan 14, 2004 at 12:55:49PM -0800, Steve Watt wrote: } > I'm working on a dataless system that will be booting and rooting } > from flash for some environmental chamber (thermal) tests, and } > logging the results to an NFS server outside the chamber. } } I've got to ask, if you're in an NFS environment, why boot from flash at } all? Why not PXE boot or use etherboot? I'm attempting to minimize reboot cycle time, since part of the test suite involves 50 reboots per card, and with 5 cards in the system, a minute extra boot time is suddenly four hours. But I'll admit to not having gathered the data on that one, so I'll give it a closer look. If I PXE or etherboot, how would the kernel environment get populated then? -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9" Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 13:24:11 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C519116A4CF for ; Wed, 14 Jan 2004 13:24:11 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4A8F43D48 for ; Wed, 14 Jan 2004 13:24:09 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.3) with ESMTP id i0ELO6aT009311; Wed, 14 Jan 2004 13:24:06 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i0ELO6X8009310; Wed, 14 Jan 2004 13:24:06 -0800 Date: Wed, 14 Jan 2004 13:24:06 -0800 From: Brooks Davis To: Steve Watt Message-ID: <20040114212405.GD4974@Odin.AC.HMC.Edu> References: <200401142116.i0ELG1RX088594@wattres.Watt.COM> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qGV0fN9tzfkG3CxV" Content-Disposition: inline In-Reply-To: <200401142116.i0ELG1RX088594@wattres.Watt.COM> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: hackers@freebsd.org Subject: Re: kernel environment between reboots, diskless X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 21:24:11 -0000 --qGV0fN9tzfkG3CxV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 14, 2004 at 01:16:01PM -0800, Steve Watt wrote: > On Jan 14, 13:11, Brooks Davis wrote: > } On Wed, Jan 14, 2004 at 12:55:49PM -0800, Steve Watt wrote: > } > I'm working on a dataless system that will be booting and rooting > } > from flash for some environmental chamber (thermal) tests, and > } > logging the results to an NFS server outside the chamber. > }=20 > } I've got to ask, if you're in an NFS environment, why boot from flash at > } all? Why not PXE boot or use etherboot? >=20 > I'm attempting to minimize reboot cycle time, since part of the test > suite involves 50 reboots per card, and with 5 cards in the system, > a minute extra boot time is suddenly four hours. Hmm, that might be an issue. If your network is reliable (and you configure your switches so you don't get screwed by spanning tree), PXE boots are quite fast, probably not more then a few seconds longer then booting from local media (possiably less since you could disabling BIOS probing of the media which takes forever.) > But I'll admit to not having gathered the data on that one, so I'll > give it a closer look. If I PXE or etherboot, how would the kernel > environment get populated then? =46rom the server. The advantage of this is that it would be easy to script changes on the server as opposed to changes on the flash card. You also don't need to worry about wearing out the server's disks. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --qGV0fN9tzfkG3CxV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFABbN0XY6L6fI4GtQRAruvAJ42qzyjYty7jaQt0pNurHr64o8oyQCfW1zi jzJXPkLYyWc+yyYnkV5dA4U= =mMqw -----END PGP SIGNATURE----- --qGV0fN9tzfkG3CxV-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 13:26:33 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02C5B16A4CE for ; Wed, 14 Jan 2004 13:26:33 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FCB243D46 for ; Wed, 14 Jan 2004 13:26:30 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i0ELQLET093337; Wed, 14 Jan 2004 14:26:21 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 14 Jan 2004 14:26:19 -0700 (MST) Message-Id: <20040114.142619.35090817.imp@bsdimp.com> To: dgilbert@dclg.ca From: "M. Warner Losh" In-Reply-To: <16389.25821.502399.872877@canoe.dclg.ca> References: <16389.25821.502399.872877@canoe.dclg.ca> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: Filesystem marker. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 21:26:33 -0000 In message: <16389.25821.502399.872877@canoe.dclg.ca> David Gilbert writes: : Is there a set of bytes at some offset in a block that is common to : any instance of a BSD ufs filesystem? I ask because recently my home : machine erased it's fdisk block _and_ the bsdlabel with it. It : certainly didn't have time to erase the whole disk, but I'm having : trouble guessing where the partitions are. You can look for the UFS magic number. Warner From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 13:27:50 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBD4C16A4CE; Wed, 14 Jan 2004 13:27:50 -0800 (PST) Received: from mailbox.univie.ac.at (mail.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F64D43D8C; Wed, 14 Jan 2004 13:27:39 -0800 (PST) (envelope-from l.ertl@univie.ac.at) Received: from wireless (adslle.cc.univie.ac.at [131.130.102.11]) i0ELRT8U406130; Wed, 14 Jan 2004 22:27:31 +0100 Date: Wed, 14 Jan 2004 22:27:25 +0100 (CET) From: Lukas Ertl To: Robert Watson In-Reply-To: Message-ID: <20040114215347.P608@korben.in.tern> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-DCC-ZID-Univie-Metrics: imap 4244; Body=0 Fuz1=0 Fuz2=0 cc: Greg 'groggy' Lehey cc: Mark Linimon cc: Poul-Henning Kamp cc: hackers@freebsd.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 21:27:51 -0000 On Mon, 12 Jan 2004, Robert Watson wrote: > I think the right strategy is to follow the minimalist approach now > (adopt the disk(9) API, rather than having Vinum generate character > devices) so that swap works on Vinum again, and so that when UFS moves > to speaking GEOM there's no loss of functionality. If we want to > completely reimplement Vinum, we should do that separately so as to > avoid loss of functionality during structural changes. As many ways lead to Rome, how about the following scenario. I don't know if it's a clever way to do things, and I don't know if it's even possible to with GEOM, so some input is appreciated. *) Have separate GEOM classes for each of the different vinum objects (drive, sd, plex, volume). *) Let the drive geom taste the slices configured for vinum, read the on-disk config and then spawn the necessary other geoms (I'm not sure if the latter can be done in GEOM). *) I think this is a clean implementation, since the GEOM framework offers all the "background" needed to transform the IO requests. *) It would also be a good way to clean up the vinum code. regards, le -- Lukas Ertl eMail: l.ertl@univie.ac.at UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 13:32:42 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86E2416A4CE; Wed, 14 Jan 2004 13:32:42 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99F1643D1D; Wed, 14 Jan 2004 13:32:40 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i0ELWWdN029578; Wed, 14 Jan 2004 22:32:32 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Lukas Ertl From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 14 Jan 2004 22:27:25 +0100." <20040114215347.P608@korben.in.tern> Date: Wed, 14 Jan 2004 22:32:32 +0100 Message-ID: <29577.1074115952@critter.freebsd.dk> cc: Greg 'groggy' Lehey cc: Mark Linimon cc: hackers@freebsd.org cc: Robert Watson Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 21:32:42 -0000 In message <20040114215347.P608@korben.in.tern>, Lukas Ertl writes: >On Mon, 12 Jan 2004, Robert Watson wrote: > >> I think the right strategy is to follow the minimalist approach now >> (adopt the disk(9) API, rather than having Vinum generate character >> devices) so that swap works on Vinum again, and so that when UFS moves >> to speaking GEOM there's no loss of functionality. If we want to >> completely reimplement Vinum, we should do that separately so as to >> avoid loss of functionality during structural changes. > >As many ways lead to Rome, how about the following scenario. I don't know >if it's a clever way to do things, and I don't know if it's even possible >to with GEOM, so some input is appreciated. > >*) Have separate GEOM classes for each of the different vinum objects > (drive, sd, plex, volume). >*) Let the drive geom taste the slices configured for vinum, read the > on-disk config and then spawn the necessary other geoms (I'm not sure > if the latter can be done in GEOM). >*) I think this is a clean implementation, since the GEOM framework offers > all the "background" needed to transform the IO requests. >*) It would also be a good way to clean up the vinum code. It is possible in GEOM, but I am not convinced that fragmenting into this many GEOM classes can be classified as an easy path to go. I think for now the important thing is to get the people interested on this collected on a mail-alias, and for them to discuss how the can work together to make something happen. After that, try to define "something" closer. -- 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. From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 13:54:54 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9552A16A4CE for ; Wed, 14 Jan 2004 13:54:54 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 315C143D53 for ; Wed, 14 Jan 2004 13:54:52 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 8E728530A; Wed, 14 Jan 2004 22:54:50 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 78FE65309; Wed, 14 Jan 2004 22:54:41 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 07C6A33C9A; Wed, 14 Jan 2004 22:54:41 +0100 (CET) To: David Gilbert References: <16389.25821.502399.872877@canoe.dclg.ca> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Wed, 14 Jan 2004 22:54:40 +0100 In-Reply-To: <16389.25821.502399.872877@canoe.dclg.ca> (David Gilbert's message of "Wed, 14 Jan 2004 10:48:45 -0500") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on flood.des.no X-Spam-Level: ss X-Spam-Status: No, hits=2.6 required=5.0 tests=RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.61 cc: freebsd-hackers@freebsd.org Subject: Re: Filesystem marker. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 21:54:54 -0000 David Gilbert writes: > Is there a set of bytes at some offset in a block that is common to > any instance of a BSD ufs filesystem? Yes, you should find copies of the superblock for each file system at regular intervals. On a little-endian machine, each superblock will contain, at offset 0x55c, the bytes 0x54 0x19 0x01 0x00 (for UFS1) 0x19 0x01 0x54 0x19 (for UFS2) obviously on a big-endian machine they will be in the reverse order (but at the same offset) Note that you may get false positives from files containing data that happens to match the UFS magic numbers (e.g. dumps). The offset of the first superblock backup relative to the start of the filesystem depends on the newfs parameters. I believe that with default values in 5.x the superblocks will be at sector offsets 160, 376512, 752864 and so on in increments of 376352 sectors. For UFS1, the sector offsets will be 32, 376224, 752416 and so on in increments of 376192 sectors. For older UFS1 filesystems created back when newfs defaulted to 8192-byte blocks and 1024-byte fragments, the offsets will be 32, 92448, 184864 and so on in 92416-sector increments. The layout of the superblock is described in /sys/ufs/ffs/fs.h (see the definition of struct fs) DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 14:06:41 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19A6016A4CE; Wed, 14 Jan 2004 14:06:41 -0800 (PST) Received: from correo.tid.es (tidos.tid.es [193.145.240.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7729E43D45; Wed, 14 Jan 2004 14:06:16 -0800 (PST) (envelope-from igf@tid.es) Received: from conversion-daemon.tid.hi.inet by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) id <0HRI004012G1RD@tid.hi.inet>; Wed, 14 Jan 2004 23:06:15 +0100 (MET) Received: from tid.es (localhost [127.0.0.1]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0HRI00HE42QEVK@tid.hi.inet>; Wed, 14 Jan 2004 23:06:14 +0100 (MET) Received: from [213.9.244.25] by tid.hi.inet (mshttpd); Wed, 14 Jan 2004 23:06:14 +0100 Date: Wed, 14 Jan 2004 23:06:14 +0100 From: ISAAC GELADO FERNANDEZ To: "Crist J. Clark" Message-id: <3354de336433.3364333354de@tid.es> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.18 (built Jul 28 2003) Content-type: text/plain; charset=iso-8859-1 Content-language: es Content-transfer-encoding: QUOTED-PRINTABLE Content-disposition: inline X-Accept-Language: es Priority: normal cc: freebsd-isp@freebsd.org cc: freebsd-hackers@freebsd.org cc: nbari@unixmexico.com Subject: Re: Routing Networks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 22:06:41 -0000 ----- Mensaje original ----- De: "Crist J. Clark" Fecha: Mi=E9rcoles, Enero 14, 2004 10:06 pm Asunto: Re: Routing Networks > On Wed, Jan 14, 2004 at 08:43:37AM +0100, Isaac Gelado wrote: > > Nicol?s de Bari Embr?z G. R. escribi?: > > >Hi all, I need some help routing or making Nat on a LAN. > > > > > >I have something like this: > > > > > > > > > I N T E R N E T > > > ----------------- > > > ^ ^ > > > | | > > >fxp0 public IP public IP > > > | | > > > FreeBSD server LINUX server > > > | | > > >dc0 192.168.10.1 | > > >dc1 192.168.1.1 ^ 192.168.1.3 > > > ^ | ^ > > > | | | > > > | | | > > > ---------------- > > > | Switch/Hub | > > > ---------------- > > > | | > > > ------------------ ----------------- > > > | LAN A | | LAN B | > > > | 192.168.10.2-254 | | 192.168.1.4-100 | > > > ------------------ ----------------- > > > > > > > > >What i want to do is that a computer on LAN A with an IP on the=20 > range of=20 > > >192.168.10.2-254 can ping, telnet, ssh, etc. to a computer on=20 > LAN B > > >"192.168.1.X". > > > > > >How can i solve this problem, is this is a route or Nat problem ? > >=20 > > I think it is a route problem. You must add next static route: > >=20 > > - On the linux machine route all incoming packets with dest=20 > addr=20 > > 192.168.10.x to 192.168.1.1 > >=20 > > It shouldn't be necesary a static route on the freebsd machine=20 > since it=20 > > has a network device with an addr of LAN B. >=20 > This is correct. Things can get from LAN A to LAN B just fine in this > picture. The problem is that machines on LAN B won't be able to get > back to LAN A (i.e. your pings go from A to B, but the pongs never get > back from B to A). You'll have to touch that Linux box or touch the > routes on everything on LAN B to route 192.168.10.0/24 through > 192.168.1.1. >=20 > > Of course you must run a=20 > > route daemon in both machines (I supouse it's running now since=20 > they are=20 > > working as gateways) and the previous route must be added to the=20 > route=20 > > daemon running on the linux machine. >=20 > OK now here is the problem. Why does he need a routing daemon? I saw > no mention of RIP, OSPF, or any other dynamic routing protocol. Looks > like it's all static routes to me. Sorry, I was mistaken. You only need that FreeBSD machines redirects packets from one network interface to the other as Crist says. Regards > --=20 > Crist J. Clark | =20 cjclark@alum.mit.edu > | =20 cjclark@jhu.edu > http://people.freebsd.org/~cjc/ | =20 cjc@freebsd.org > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers- > unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 14:26:22 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADED916A4CE; Wed, 14 Jan 2004 14:26:22 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB69B43D1D; Wed, 14 Jan 2004 14:26:20 -0800 (PST) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (blackwater.lemis.com [192.109.197.80]) by ozlabs.org (Postfix) with ESMTP id 52C902BD75; Thu, 15 Jan 2004 09:26:18 +1100 (EST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 7DDDF51215; Thu, 15 Jan 2004 08:56:16 +1030 (CST) Date: Thu, 15 Jan 2004 08:56:16 +1030 From: Greg 'groggy' Lehey To: Poul-Henning Kamp Message-ID: <20040114222616.GC64370@wantadilla.lemis.com> References: <20040114215347.P608@korben.in.tern> <29577.1074115952@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0vzXIDBeUiKkjNJl" Content-Disposition: inline In-Reply-To: <29577.1074115952@critter.freebsd.dk> User-Agent: Mutt/1.4.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: Mark Linimon cc: hackers@freebsd.org cc: Robert Watson Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 22:26:22 -0000 --0vzXIDBeUiKkjNJl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wednesday, 14 January 2004 at 22:32:32 +0100, Poul-Henning Kamp wrote: > In message <20040114215347.P608@korben.in.tern>, Lukas Ertl writes: >> On Mon, 12 Jan 2004, Robert Watson wrote: >> >>> I think the right strategy is to follow the minimalist approach now >>> (adopt the disk(9) API, rather than having Vinum generate character >>> devices) so that swap works on Vinum again, and so that when UFS moves >>> to speaking GEOM there's no loss of functionality. If we want to >>> completely reimplement Vinum, we should do that separately so as to >>> avoid loss of functionality during structural changes. >> >> As many ways lead to Rome, how about the following scenario. I don't know >> if it's a clever way to do things, and I don't know if it's even possible >> to with GEOM, so some input is appreciated. >> >> *) Have separate GEOM classes for each of the different vinum objects >> (drive, sd, plex, volume). >> *) Let the drive geom taste the slices configured for vinum, read the >> on-disk config and then spawn the necessary other geoms (I'm not sure >> if the latter can be done in GEOM). >> *) I think this is a clean implementation, since the GEOM framework offers >> all the "background" needed to transform the IO requests. >> *) It would also be a good way to clean up the vinum code. > > It is possible in GEOM, but I am not convinced that fragmenting into > this many GEOM classes can be classified as an easy path to go. I think it's probably a good ultimate aim, but I don't think it should be the first step. > I think for now the important thing is to get the people interested > on this collected on a mail-alias, and for them to discuss how the > can work together to make something happen. After that, try to > define "something" closer. A mailing lists exists. vinum-devel@auug.org.au. If somebody wants to put in a FreeBSD version, that wouldn't be a disadvantage. Greg -- See complete headers for address and phone numbers. --0vzXIDBeUiKkjNJl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQFABcIIIubykFB6QiMRAhY5AJ9tk0gu0ZojXiZ1J70cwZ6Tf97u/wCeLl8o ad8KShjoWU9mvAq7Hc7gIpA= =C9hb -----END PGP SIGNATURE----- --0vzXIDBeUiKkjNJl-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 17:31:18 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D357016A4CE for ; Wed, 14 Jan 2004 17:31:18 -0800 (PST) Received: from wattres.Watt.COM (wattres.watt.com [66.93.133.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7234F43D5F for ; Wed, 14 Jan 2004 17:31:17 -0800 (PST) (envelope-from steve@Watt.COM) Received: (from steve@localhost) by wattres.Watt.COM (8.12.9/8.12.9) id i0F1VE54020740; Wed, 14 Jan 2004 17:31:14 -0800 (PST) (envelope-from steve) Message-Id: <200401150131.i0F1VE54020740@wattres.Watt.COM> From: steve@Watt.COM (Steve Watt) Date: Wed, 14 Jan 2004 17:31:14 -0800 In-Reply-To: Brooks Davis "Re: kernel environment between reboots, diskless" (Jan 14, 13:24) X-Mailer: Mail User's Shell (7.2.6 beta(5) jp(8) 11/23/00) To: Brooks Davis , Steve Watt cc: hackers@freebsd.org Subject: Re: kernel environment between reboots, diskless X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 01:31:18 -0000 On Jan 14, 13:24, Brooks Davis wrote: } On Wed, Jan 14, 2004 at 01:16:01PM -0800, Steve Watt wrote: } > On Jan 14, 13:11, Brooks Davis wrote: } > } On Wed, Jan 14, 2004 at 12:55:49PM -0800, Steve Watt wrote: } > } > I'm working on a dataless system that will be booting and rooting } > } > from flash for some environmental chamber (thermal) tests, and } > } > logging the results to an NFS server outside the chamber. } > } } > } I've got to ask, if you're in an NFS environment, why boot from flash at } > } all? Why not PXE boot or use etherboot? } > } > I'm attempting to minimize reboot cycle time, since part of the test } > suite involves 50 reboots per card, and with 5 cards in the system, } > a minute extra boot time is suddenly four hours. } } Hmm, that might be an issue. If your network is reliable (and you } configure your switches so you don't get screwed by spanning tree), PXE } boots are quite fast, probably not more then a few seconds longer then } booting from local media (possiably less since you could disabling BIOS } probing of the media which takes forever.) It's going to be an isolated net, so it shouldn't be a problem on this part. } > But I'll admit to not having gathered the data on that one, so I'll } > give it a closer look. If I PXE or etherboot, how would the kernel } > environment get populated then? } } From the server. The advantage of this is that it would be easy to } script changes on the server as opposed to changes on the flash card. } You also don't need to worry about wearing out the server's disks. Ah! I see how that works. Only catch is, I'm getting a strange result when trying diskless boots. I've got the DHCP server configured as suggested in pxeboot(8), and I see the loader get started. It grabs (over NFS) loader.rc, loader.4th, and support.4th. I see the start word get executed, but adding .( message ) cr in various places, it seems like it's getting to the end of start, but not coming back to the loader.rc code. And most of my Forth knowledge is from working with PostScript 15 years ago, which doesn't help a lot. :P Anyone want to hazard a guess? I feel like I'm falling deeper into that maze of twisty little passages. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9" Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 21:26:46 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A1D116A4CF for ; Wed, 14 Jan 2004 21:26:46 -0800 (PST) Received: from smtp.mho.com (smtp.mho.net [64.58.4.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 58E2343D5C for ; Wed, 14 Jan 2004 21:26:43 -0800 (PST) (envelope-from scottl@freebsd.org) Received: (qmail 8736 invoked by uid 1002); 15 Jan 2004 05:26:43 -0000 Received: from unknown (HELO freebsd.org) (64.58.1.252) by smtp.mho.net with SMTP; 15 Jan 2004 05:26:43 -0000 Message-ID: <40062428.4000904@freebsd.org> Date: Wed, 14 Jan 2004 22:24:56 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031103 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Call for bi-monthly status reports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 05:26:46 -0000 All, It's time for bi-monthly status reports. This one is a little late due to the excitement of releasing 5.2, so please submit reports for Oct-Dec 2003. As always, the template is at http://www.freebsd.org/news/status/report-sample.xml, and submissions go to monthly@freebsd.org. While this report is primarily for projects that are in-progress, we would also encourage submissions for projects that are still in their idea and planning phases. It is open to src, ports, and documentation projects that are related to FreeBSD Submissions are due to monthly@freebsd.org by Jan 24. Thanks! Scott Long From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 23:49:08 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B524816A4CE for ; Wed, 14 Jan 2004 23:49:08 -0800 (PST) Received: from pasmtp.tele.dk (pasmtp.tele.dk [193.162.159.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id A97F743D75 for ; Wed, 14 Jan 2004 23:49:06 -0800 (PST) (envelope-from xride@x12.dk) Received: from x12.dk (xforce.dk [80.164.11.218]) by pasmtp.tele.dk (Postfix) with ESMTP id DAE6C1EC373; Thu, 15 Jan 2004 08:49:04 +0100 (CET) Received: by x12.dk (Postfix, from userid 666) id 2562B38; Thu, 15 Jan 2004 08:49:03 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by x12.dk (Postfix) with ESMTP id D842D26; Thu, 15 Jan 2004 08:49:03 +0100 (CET) Date: Thu, 15 Jan 2004 08:49:03 +0100 (CET) From: Soeren Straarup To: Poul-Henning Kamp In-Reply-To: <29577.1074115952@critter.freebsd.dk> Message-ID: <20040115084359.M20688-100000@x12.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 07:49:08 -0000 On Wed, 14 Jan 2004, Poul-Henning Kamp wrote: > > I think for now the important thing is to get the people interested > on this collected on a mail-alias, and for them to discuss how the > can work together to make something happen. After that, try to define > "something" closer. > What about freebsd-vinum or freebsd-raid ? Looks like something i might follow. I got a disk array with 4 disks to test on btw, but that might not be that needed. Soeren Straarup | aka OZ2DAK aka Xride FreeBSD wannabe | FreeBSD since 2.2.6-R If you see the light at the end of the tunnel, then make sure it is not a train.. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 15 00:48:22 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC15A16A4CE for ; Thu, 15 Jan 2004 00:48:22 -0800 (PST) Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id F35CB43D6A for ; Thu, 15 Jan 2004 00:48:21 -0800 (PST) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=danny) by cs.huji.ac.il with esmtp id 1Ah3Ap-000EZY-Ci; Thu, 15 Jan 2004 10:48:19 +0200 X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Brooks Davis In-reply-to: Your message of Wed, 14 Jan 2004 13:24:06 -0800 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Jan 2004 10:48:19 +0200 From: Danny Braniss Message-Id: cc: hackers@freebsd.org Subject: Re: kernel environment between reboots, diskless X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 08:48:22 -0000 > > But I'll admit to not having gathered the data on that one, so I'll > > give it a closer look. If I PXE or etherboot, how would the kernel > > environment get populated then? i use a modified bootp that palces all the dhcp tags in the kernel environment see ftp://ftp.cs.huji.ac.il/users/danny/freebsd/diskless-boot/ or http://www.freebsd.org/cgi/query-pr.cgi?pr=61239 danny From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 15 03:54:57 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8694016A4CE for ; Thu, 15 Jan 2004 03:54:57 -0800 (PST) Received: from ns.mmk.ru (ns1.mmk.ru [195.54.3.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id D665843D60 for ; Thu, 15 Jan 2004 03:54:50 -0800 (PST) (envelope-from freebsd@mmk.ru) Received: from antivirus.mmk.ru (antivirus [161.8.100.3]) by ns.mmk.ru (8.12.9p1/8.12.9) with ESMTP id i0FBpYVn007443 for ; Thu, 15 Jan 2004 16:51:34 +0500 (YEKT) (envelope-from freebsd@mmk.ru) Received: from wall.mmk.ru (localhost [127.0.0.1]) by antivirus.mmk.ru (8.12.9/8.12.9) with ESMTP id i0FBr2Gr000379 for ; Thu, 15 Jan 2004 16:53:02 +0500 (YEKT) Received: from wall (localhost [127.0.0.1]) by wall.mmk.ru (8.12.9p2/8.12.9) with SMTP id i0FBndHl024688 for ; Thu, 15 Jan 2004 16:49:39 +0500 (YEKT) (envelope-from freebsd@mmk.ru) Message-ID: <01cc01c3db6f$44528f60$02010101@wall> From: "Dmitry A. Bondareff" To: Date: Thu, 15 Jan 2004 16:55:41 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Upgrade from 4.9 to 5.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 11:54:57 -0000 Hello hackers! Help to understand problem. I have FreeBSD 4.9 on my box. # uname -a FreeBSD wall.ru 4.9-RELEASE-p1 FreeBSD 4.9-RELEASE-p1 #24 I've tried to Upgrade it up to 5.1 # cvsup /etc/cvsupfile # cd /usr/src # make buildworld .................... .................... =3D=3D=3D> lib/libpam/modules/pam_krb5 rm -f .depend mkdep -f .depend -a = -I/usr/src/lib/libpam/modules/pam_krb5/../../../../contrib/openpam/i nclude -I/usr/src/lib/libpam/modules/pam_krb5/../../libpam = /usr/src/lib/libpam/modules/pam _krb5/pam_krb5.c *** Error code 1 Stop in /usr/src/lib/libpam/modules/pam_krb5. *** Error code 1 Stop in /usr/src/lib/libpam/modules. *** Error code 1 Stop in /usr/src/lib/libpam. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. How to resolve this problem. Thanks. Dmitry Bondareff. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 15 06:53:07 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A556016A4CE for ; Thu, 15 Jan 2004 06:53:07 -0800 (PST) Received: from phantom.cris.net (phantom.cris.net [212.110.130.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id E071B43D62 for ; Thu, 15 Jan 2004 06:53:01 -0800 (PST) (envelope-from ru@FreeBSD.org.ua) Received: from phantom.cris.net (ru@localhost [127.0.0.1]) by phantom.cris.net (8.12.10/8.12.10) with ESMTP id i0FErYCa083068; Thu, 15 Jan 2004 16:53:34 +0200 (EET) (envelope-from ru@FreeBSD.org.ua) Received: (from ru@localhost) by phantom.cris.net (8.12.10/8.12.10/Submit) id i0FErYkL083063; Thu, 15 Jan 2004 16:53:34 +0200 (EET) (envelope-from ru) Date: Thu, 15 Jan 2004 16:53:34 +0200 From: Ruslan Ermilov To: "Dmitry A. Bondareff" Message-ID: <20040115145334.GD82211@FreeBSD.org.ua> References: <01cc01c3db6f$44528f60$02010101@wall> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cPi+lWm09sJ+d57q" Content-Disposition: inline In-Reply-To: <01cc01c3db6f$44528f60$02010101@wall> User-Agent: Mutt/1.5.5.1i cc: freebsd-hackers@freebsd.org Subject: Re: Upgrade from 4.9 to 5.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 14:53:07 -0000 --cPi+lWm09sJ+d57q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 15, 2004 at 04:55:41PM +0300, Dmitry A. Bondareff wrote: > Hello hackers! > Help to understand problem. > I have FreeBSD 4.9 on my box. > # uname -a > FreeBSD wall.ru 4.9-RELEASE-p1 FreeBSD 4.9-RELEASE-p1 #24 >=20 > I've tried to Upgrade it up to 5.1 > # cvsup /etc/cvsupfile > # cd /usr/src > # make buildworld > .................... > .................... > =3D=3D=3D> lib/libpam/modules/pam_krb5 > rm -f .depend > mkdep -f .depend -a -I/usr/src/lib/libpam/modules/pam_krb5/../../../..= /contrib/openpam/i > nclude -I/usr/src/lib/libpam/modules/pam_krb5/../../libpam /usr/src/lib/= libpam/modules/pam > _krb5/pam_krb5.c > *** Error code 1 >=20 This doesn't inlude the actual error that caused the breakage. Please put the full log (compressed) available somewhere for download, and I will look into it. Cheers, --=20 Ruslan Ermilov FreeBSD committer ru@FreeBSD.org --cPi+lWm09sJ+d57q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFABqluUkv4P6juNwoRAnRpAJ4s0q4Vnz6WNumuDuveZ/CsSx4LjACfUH1L HV+XWiw/F/lJG/ioHlHBj64= =45Ww -----END PGP SIGNATURE----- --cPi+lWm09sJ+d57q-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 15 07:21:19 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6618616A4CF for ; Thu, 15 Jan 2004 07:21:19 -0800 (PST) Received: from obsecurity.dyndns.org (adsl-67-119-53-122.dsl.lsan03.pacbell.net [67.119.53.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2ACB243D55 for ; Thu, 15 Jan 2004 07:21:17 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A426B66CD1; Thu, 15 Jan 2004 07:21:16 -0800 (PST) Date: Thu, 15 Jan 2004 07:21:16 -0800 From: Kris Kennaway To: "Dmitry A. Bondareff" Message-ID: <20040115152116.GA12857@xor.obsecurity.org> References: <01cc01c3db6f$44528f60$02010101@wall> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: <01cc01c3db6f$44528f60$02010101@wall> User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Thu, 15 Jan 2004 11:25:11 -0800 cc: freebsd-hackers@freebsd.org Subject: Re: Upgrade from 4.9 to 5.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 15:21:19 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 15, 2004 at 04:55:41PM +0300, Dmitry A. Bondareff wrote: > Hello hackers! > Help to understand problem. > I have FreeBSD 4.9 on my box. > # uname -a > FreeBSD wall.ru 4.9-RELEASE-p1 FreeBSD 4.9-RELEASE-p1 #24 >=20 > I've tried to Upgrade it up to 5.1 > # cvsup /etc/cvsupfile > # cd /usr/src > # make buildworld > .................... > .................... > =3D=3D=3D> lib/libpam/modules/pam_krb5 > rm -f .depend > mkdep -f .depend -a -I/usr/src/lib/libpam/modules/pam_krb5/../../../..= /contrib/openpam/i > nclude -I/usr/src/lib/libpam/modules/pam_krb5/../../libpam /usr/src/lib/= libpam/modules/pam > _krb5/pam_krb5.c > *** Error code 1 This doesn't show the error. Are you sure you didn't use -j with buildworld? Retry without it, since -j obscures the output of make. Kris --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFABq/sWry0BWjoQKURAvwfAKClDQoKSHPkpaic7HhZLL/nRtzpMQCeOPab F5msH8He19tGfGStJ6zj5TY= =hkTn -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 15 14:01:23 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2738A16A4CE for ; Thu, 15 Jan 2004 14:01:23 -0800 (PST) Received: from mail.gulfgate-inc.com (mail.gulfgate-inc.com [64.1.98.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFF2543D5E for ; Thu, 15 Jan 2004 14:01:04 -0800 (PST) (envelope-from mpf@inodes.us) Received: (qmail 78029 invoked by uid 85); 15 Jan 2004 22:03:47 -0000 Received: from mpf@inodes.us by linkdead.beatlab.org by uid 89 with qmail-scanner-1.15 (uvscan: v4.1.60/v4248. spamassassin: 2.x. Clear:. Processed in 1.002596 secs); 15 Jan 2004 22:03:47 -0000 Received: from unknown (HELO inodes.us) (mfreitag@gulfgateequipment.com@192.168.0.4) by 192.168.0.40 with SMTP; 15 Jan 2004 22:03:46 -0000 Message-ID: <40070D9E.6060407@inodes.us> Date: Thu, 15 Jan 2004 16:01:02 -0600 From: Matt Freitag User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: 5.1->5.2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 22:01:23 -0000 Building 5.2-RELEASE from 5.1-RELEASE-p10 w/ipf+ipfw+ipfw6+dummynet, 5.1 Compiled fine with this setup. I need ipfilter as it's doing my source routing for ipv6 (multiple transits) since ip6fw doesn't support fwd. (I just use ip6fw for filtering, and ipf for forwarding to the correct interface according to source) Am I just being stupid here somehow? cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I../../.. -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd -I../../../contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror ../../../contrib/ipfilter/netinet/ip_fil.c ../../../contrib/ipfilter/netinet/ip_fil.c: In function `fr_check_wrapper': ../../../contrib/ipfilter/netinet/ip_fil.c:319: `PFIL_OUT' undeclared (first use in this function) ../../../contrib/ipfilter/netinet/ip_fil.c:319: (Each undeclared identifier is reported only once ../../../contrib/ipfilter/netinet/ip_fil.c:319: for each function it appears in.) ../../../contrib/ipfilter/netinet/ip_fil.c: In function `fr_check_wrapper6': ../../../contrib/ipfilter/netinet/ip_fil.c:329: `PFIL_OUT' undeclared (first use in this function) cc1: warnings being treated as errors ../../../contrib/ipfilter/netinet/ip_fil.c: In function `iplattach': ../../../contrib/ipfilter/netinet/ip_fil.c:376: warning: unused variable `ph_inet' ../../../contrib/ipfilter/netinet/ip_fil.c:378: warning: unused variable `ph_inet6' machine/in_cksum.h: At top level: ../../../contrib/ipfilter/netinet/ip_fil.c:317: warning: `fr_check_wrapper' defined but not used ../../../contrib/ipfilter/netinet/ip_fil.c:327: warning: `fr_check_wrapper6' defined but not used *** Error code 1 Stop in /usr/src/sys/i386/compile/funk. -mpf From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 15 14:06:48 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A888016A4CE for ; Thu, 15 Jan 2004 14:06:48 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD37C43D2F for ; Thu, 15 Jan 2004 14:06:44 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i0FM4xUd077331; Thu, 15 Jan 2004 17:04:59 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i0FM4xT1077328; Thu, 15 Jan 2004 17:04:59 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 15 Jan 2004 17:04:59 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Matt Freitag In-Reply-To: <40070D9E.6060407@inodes.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: 5.1->5.2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 22:06:48 -0000 On Thu, 15 Jan 2004, Matt Freitag wrote: > Building 5.2-RELEASE from 5.1-RELEASE-p10 w/ipf+ipfw+ipfw6+dummynet, 5.1 > Compiled fine with this setup. I need ipfilter as it's doing my source > routing for ipv6 (multiple transits) since ip6fw doesn't support fwd. (I > just use ip6fw for filtering, and ipf for forwarding to the correct > interface according to source) Am I just being stupid here somehow? IPFILTER now relies on the PFIL_HOOKS kernel option; this is something that is somewhat poorly documented, and we should add it to the errate I suspect. If you add "options PFIL_HOOKS" to your kernel config, it should work. Moving to PFIL_HOOKS for all the "funky IP input/ouput" feature is a goal for 5.3 (in fact, I believe Sam has it almost entirely done in one of his development branches), and should both simplify the input/output paths, and also simplify locking for the IP stack. So the change is for a good cause :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research > > > cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. > -I../../.. -I../../../contrib/dev/acpica -I../../../contrib/ipfilter > -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd > -I../../../contrib/ngatm -D_KERNEL -include opt_global.h -fno-common > -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings > -mpreferred-stack-boundary=2 -ffreestanding -Werror > ../../../contrib/ipfilter/netinet/ip_fil.c > ../../../contrib/ipfilter/netinet/ip_fil.c: In function `fr_check_wrapper': > ../../../contrib/ipfilter/netinet/ip_fil.c:319: `PFIL_OUT' undeclared > (first use in this function) > ../../../contrib/ipfilter/netinet/ip_fil.c:319: (Each undeclared > identifier is reported only once > ../../../contrib/ipfilter/netinet/ip_fil.c:319: for each function it > appears in.) > ../../../contrib/ipfilter/netinet/ip_fil.c: In function `fr_check_wrapper6': > ../../../contrib/ipfilter/netinet/ip_fil.c:329: `PFIL_OUT' undeclared > (first use in this function) > cc1: warnings being treated as errors > ../../../contrib/ipfilter/netinet/ip_fil.c: In function `iplattach': > ../../../contrib/ipfilter/netinet/ip_fil.c:376: warning: unused variable > `ph_inet' > ../../../contrib/ipfilter/netinet/ip_fil.c:378: warning: unused variable > `ph_inet6' > machine/in_cksum.h: At top level: > ../../../contrib/ipfilter/netinet/ip_fil.c:317: warning: > `fr_check_wrapper' defined but not used > ../../../contrib/ipfilter/netinet/ip_fil.c:327: warning: > `fr_check_wrapper6' defined but not used > *** Error code 1 > > Stop in /usr/src/sys/i386/compile/funk. > > > > -mpf > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 15 14:26:47 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 062E216A4CE; Thu, 15 Jan 2004 14:26:47 -0800 (PST) Received: from math.teaser.net (math.teaser.net [213.91.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4926A43D1F; Thu, 15 Jan 2004 14:26:41 -0800 (PST) (envelope-from e-masson@kisoft-services.com) Received: from t39bsdems.interne.kisoft-services.com (nantes.kisoft-services.com [193.56.60.243]) by math.teaser.net (Postfix) with ESMTP id 324B26C80C; Thu, 15 Jan 2004 23:26:40 +0100 (CET) Received: by t39bsdems.interne.kisoft-services.com (Postfix, from userid 1001) id 3972559E9F; Thu, 15 Jan 2004 23:24:46 +0100 (CET) To: Robert Watson From: Eric Masson In-Reply-To: (Robert Watson's message of "Thu, 15 Jan 2004 17:04:59 -0500 (EST)") References: X-Operating-System: FreeBSD 4.9-STABLE i386 Date: Thu, 15 Jan 2004 23:24:45 +0100 Message-ID: <86oet497f6.fsf@t39bsdems.interne.kisoft-services.com> User-Agent: Gnus/5.110002 (No Gnus v0.2) XEmacs/21.4 (Portable Code, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: Matt Freitag cc: freebsd-hackers@freebsd.org Subject: Re: 5.1->5.2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 22:26:47 -0000 >>>>> "Robert" == Robert Watson writes: Hello, Robert> Moving to PFIL_HOOKS for all the "funky IP input/ouput" Will all available packet filters, including ipfw rely on PFIL_HOOKS or not ? Regards Eric Masson -- C'est pas avec la censure que tu vas censurer les censeurs. -+- JL in GNU : Las, censeurs pour l'échafaud -+- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 15 14:41:54 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9DB616A4CE for ; Thu, 15 Jan 2004 14:41:54 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6E7443D62 for ; Thu, 15 Jan 2004 14:41:52 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i0FMe7Ud077733; Thu, 15 Jan 2004 17:40:07 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i0FMe7jK077730; Thu, 15 Jan 2004 17:40:07 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 15 Jan 2004 17:40:06 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Eric Masson In-Reply-To: <86oet497f6.fsf@t39bsdems.interne.kisoft-services.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Matt Freitag cc: freebsd-hackers@freebsd.org Subject: Re: 5.1->5.2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 22:41:54 -0000 On Thu, 15 Jan 2004, Eric Masson wrote: > >>>>> "Robert" == Robert Watson writes: > > Robert> Moving to PFIL_HOOKS for all the "funky IP input/ouput" > > Will all available packet filters, including ipfw rely on PFIL_HOOKS or > not ? Yes; we to make it so that ipfw will also rely on PFIL_HOOKS to integrate with the IP stack, greatly reducing the quantity of #ifdef FOO in ip_input() and ip_output(). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 15 15:07:59 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D669A16A4CE; Thu, 15 Jan 2004 15:07:59 -0800 (PST) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EED143D48; Thu, 15 Jan 2004 15:07:56 -0800 (PST) (envelope-from bmah@intruder.kitchenlab.org) Received: from intruder.kitchenlab.org (adsl-64-142-31-106.sonic.net [64.142.31.106]) by a.mail.sonic.net (8.12.10/8.12.7) with ESMTP id i0FN7tts013477 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 15 Jan 2004 15:07:56 -0800 Received: from intruder.kitchenlab.org (bmah@localhost [127.0.0.1]) i0FN7spW039480; Thu, 15 Jan 2004 15:07:54 -0800 (PST) (envelope-from bmah@intruder.kitchenlab.org) Message-Id: <200401152307.i0FN7spW039480@intruder.kitchenlab.org> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Robert Watson In-Reply-To: References: Comments: In-reply-to Robert Watson message dated "Thu, 15 Jan 2004 17:04:59 -0500." From: "Bruce A. Mah" X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-91939202P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 15 Jan 2004 15:07:54 -0800 Sender: bmah@intruder.kitchenlab.org cc: Matt Freitag cc: freebsd-hackers@freebsd.org Subject: Re: 5.1->5.2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: bmah@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 23:08:00 -0000 --==_Exmh_-91939202P Content-Type: text/plain; charset=us-ascii If memory serves me right, Robert Watson wrote: > > On Thu, 15 Jan 2004, Matt Freitag wrote: > > > Building 5.2-RELEASE from 5.1-RELEASE-p10 w/ipf+ipfw+ipfw6+dummynet, 5.1 > > Compiled fine with this setup. I need ipfilter as it's doing my source > > routing for ipv6 (multiple transits) since ip6fw doesn't support fwd. (I > > just use ip6fw for filtering, and ipf for forwarding to the correct > > interface according to source) Am I just being stupid here somehow? > > IPFILTER now relies on the PFIL_HOOKS kernel option; this is something > that is somewhat poorly documented, and we should add it to the errate I > suspect. It's in the release notes and in UPDATING...I have the feeling that if people won't read it in either of those two places, they won't read it in the errata either. :-p Enabling the options IPFILTER feature also requires enabling options PFIL_HOOKS. Bruce. --==_Exmh_-91939202P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) Comment: Exmh version 2.5+ 20020506 iD8DBQFABx1K2MoxcVugUsMRAtplAKCX6hP1FGEm904kkaXG/7OsPf0tIwCfZEkA xYuPswCGmgdsf13HRXL85Qw= =ani6 -----END PGP SIGNATURE----- --==_Exmh_-91939202P-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 15 15:13:33 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18ACB16A4CE; Thu, 15 Jan 2004 15:13:33 -0800 (PST) Received: from musique.teaser.net (musique.teaser.net [213.91.2.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1274C43D49; Thu, 15 Jan 2004 15:13:31 -0800 (PST) (envelope-from e-masson@kisoft-services.com) Received: from t39bsdems.interne.kisoft-services.com (nantes.kisoft-services.com [193.56.60.243]) by musique.teaser.net (Postfix) with ESMTP id 3164872506; Fri, 16 Jan 2004 00:13:30 +0100 (CET) Received: by t39bsdems.interne.kisoft-services.com (Postfix, from userid 1001) id 4D17559E9F; Fri, 16 Jan 2004 00:11:53 +0100 (CET) To: Robert Watson From: Eric Masson In-Reply-To: (Robert Watson's message of "Thu, 15 Jan 2004 17:40:06 -0500 (EST)") References: X-Operating-System: FreeBSD 4.9-STABLE i386 Date: Fri, 16 Jan 2004 00:11:53 +0100 Message-ID: <86fzeg958m.fsf@t39bsdems.interne.kisoft-services.com> User-Agent: Gnus/5.110002 (No Gnus v0.2) XEmacs/21.4 (Portable Code, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: Matt Freitag cc: freebsd-hackers@freebsd.org Subject: Re: 5.1->5.2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 23:13:33 -0000 >>>>> "Robert" == Robert Watson writes: Robert> Yes; we to make it so that ipfw will also rely on PFIL_HOOKS to Robert> integrate with the IP stack, greatly reducing the quantity of Robert> #ifdef FOO in ip_input() and ip_output(). Ok, thanks for your clear answer. Regards Eric Masson -- >j'ai beau préparé une session express, elle ne se garde pas et qd je >fais ouvrir je reçois toutes les cauchonneries des usa comment faire >pour garder seulement les newgroupes qui m'interressent :-@ -+-TGV in : - Yankee go home -+- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 15 18:31:35 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D7A616A4CE; Thu, 15 Jan 2004 18:31:35 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD3BD43D5C; Thu, 15 Jan 2004 18:31:33 -0800 (PST) (envelope-from ljwu@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72) id ; Thu, 15 Jan 2004 21:31:23 -0500 Message-ID: From: Loh John Wu To: "'freebsd-hackers@freebsd.org'" Date: Thu, 15 Jan 2004 21:31:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" cc: "'freebsd-current@freebsd.org'" Subject: devfs error on RELENG_5_2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 02:31:35 -0000 Hello, I'm running a RELENG_5_2 box and I'm trying to use the devfs to change the file permissions on /dev/ttyd1. After perusing through the man page, I tried to change the permissions by doing this # ls -ol /dev/ttyd1 crw------- 1 root wheel - 28, 1 Jan 15 20:47 /dev/ttyd1 # devfs rule add path ttyd1 mode 666 devfs rule: ioctl DEVFSIO_RADD: Input/output error # ls -ol /dev/ttyd1 crw------- 1 root wheel - 28, 1 Jan 15 20:47 /dev/ttyd1 but it fails and I'm not sure why. I'll have to do devfs rule applyset if the rule add succeeds since the node /dev/ttyd1 has already been created but I haven't got that far yet... I've also tried using the example in the man page with /dev/speaker, but it also fails with the same error. # ls -ol /dev/speaker crw------- 1 root wheel - 26, 0 Jan 15 21:24 /dev/speaker # dmesg | grep speaker speaker0: at port 0x61 on isa0 # devfs rule add path speaker mode 666 devfs rule: ioctl DEVFSIO_RADD: Input/output error # ls -ol /dev/speaker crw------- 1 root wheel - 26, 0 Jan 15 21:24 /dev/speaker Any thoughts on this would be greatly appreciated. Thanks, John From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 15 19:39:38 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB7E916A4CE for ; Thu, 15 Jan 2004 19:39:38 -0800 (PST) Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16A5143D64 for ; Thu, 15 Jan 2004 19:39:38 -0800 (PST) (envelope-from tedu@stanford.edu) Received: from elaine30.Stanford.EDU (elaine30.Stanford.EDU [171.64.15.105]) by smtp3.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i0G3daw6006843; Thu, 15 Jan 2004 19:39:37 -0800 Date: Thu, 15 Jan 2004 19:39:36 -0800 (PST) From: Ted Unangst To: Steve Watt In-Reply-To: <200401142055.i0EKtnL6085950@wattres.Watt.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org Subject: Re: kernel environment between reboots, diskless X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 03:39:39 -0000 On Wed, 14 Jan 2004, Steve Watt wrote: > I'm trying to see if there's a way to get that information into the > loader (or the driver) in some way that doesn't require rewriting a file > in the flash every reboot, to avoid flash write cycles. > > I know there's some amount of NVRAM in PCs, but didn't spot anything > about how to get at it from the driver. It'd be nice, for this > sort of application, if there was a way to stash somewhere between > 2 and 8 bytes somewhere... many (most?) PCs don't clear RAM on soft reboot, so stuff like the message buffer survives. try mapping the same physical address, out of the way of other code, and leaving your data there. -- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 15 20:57:37 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3EF016A4CE for ; Thu, 15 Jan 2004 20:57:37 -0800 (PST) Received: from ngw.bvu.edu (ngw1.bvu.edu [147.92.2.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id B434743D46 for ; Thu, 15 Jan 2004 20:57:36 -0800 (PST) (envelope-from cacemic@bvu.edu) Received: from BVU-Gateways-MTA by ngw.bvu.edu with Novell_GroupWise; Thu, 15 Jan 2004 22:57:17 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Thu, 15 Jan 2004 22:56:36 -0600 From: "Michael Cacek" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Slow Console Input X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 04:57:37 -0000 I recently installed freebsd 5.2 on a local sunblade 100 system. I had several problems with keyboard input throughout the install, but I eventually made it though. The problems that I had were as follows: Slow response time with keypresses. I had to use ctrl + n or ctrl + p to move though menu options(the options never lit up completely, only blinked..enough to show me that they were currently selected). It was a terrible experience, but I made it through, but now I have another problem. Upon rebooting, my console input is incredibly slow. I press a key and it takes around 1/2 a second for the letter to appear. I read that I could use kbdcontrol to change key rates, but whenever I try to issue a command with it, it reports back the following error: "inappropriate ioctl for device". Any help is much appreciated. The slow speed is simply not tolerable. This is my first freebsd install and I hope it won't won't be the last. Thanks ahead of time.. Mike From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 15 22:15:13 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7468416A4CF for ; Thu, 15 Jan 2004 22:15:13 -0800 (PST) Received: from mail.ubergeeks.com (lorax.ubergeeks.com [209.145.65.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43B7743D5E for ; Thu, 15 Jan 2004 22:15:12 -0800 (PST) (envelope-from adrian+freebsd-hackers@ubergeeks.com) Received: from mail.ubergeeks.com (localhost [127.0.0.1]) by mail.ubergeeks.com (8.12.9p2/8.12.9) with ESMTP id i0G6F5qZ047743; Fri, 16 Jan 2004 01:15:05 -0500 (EST) (envelope-from adrian+freebsd-hackers@ubergeeks.com) Received: from localhost (adrian@localhost)i0G6F4Lx047740; Fri, 16 Jan 2004 01:15:05 -0500 (EST) (envelope-from adrian+freebsd-hackers@ubergeeks.com) X-Authentication-Warning: lorax.ubergeeks.com: adrian owned process doing -bs Date: Fri, 16 Jan 2004 01:15:04 -0500 (EST) From: Adrian Filipi Sender: adrian@ubergeeks.com To: "Michael R. Wayne" In-Reply-To: <200401130746.i0D7kNEk004375@manor.msen.com> Message-ID: <20040116011400.V32954@lorax.ubergeeks.com> References: <200401130746.i0D7kNEk004375@manor.msen.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean cc: hackers@freebsd.org Subject: Re: Mergemaster+RCS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 06:15:13 -0000 On Tue, 13 Jan 2004, Michael R. Wayne wrote: > > Although Doug Barton has written a wonderful tool, it has always > seemed to have a major deficiency: it completely ignores the > existance of RCS files. I've exchanged some email with Doug and > he has no interest in adding RCS support to mergemaster. So I did. Most excellent! This will help me very much as I too use RCS to track local config files. I'll let you know how it goes after my ext update. thanks! Adrian -- [ adrian@ubergeeks.com ] From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 01:27:11 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22AE616A4CE; Fri, 16 Jan 2004 01:27:11 -0800 (PST) Received: from gvr.gvr.org (gvr-gw.gvr.org [80.126.103.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E35143D68; Fri, 16 Jan 2004 01:27:09 -0800 (PST) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id ED31E5F; Fri, 16 Jan 2004 10:27:08 +0100 (CET) Date: Fri, 16 Jan 2004 10:27:08 +0100 From: Guido van Rooij To: Robert Watson Message-ID: <20040116092708.GA203@gvr.gvr.org> References: <40070D9E.6060407@inodes.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: Matt Freitag cc: freebsd-hackers@freebsd.org Subject: Re: 5.1->5.2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 09:27:12 -0000 On Thu, Jan 15, 2004 at 05:04:59PM -0500, Robert Watson wrote: > > IPFILTER now relies on the PFIL_HOOKS kernel option; this is something > that is somewhat poorly documented, and we should add it to the errate I > suspect. If you add "options PFIL_HOOKS" to your kernel config, it should > work. Moving to PFIL_HOOKS for all the "funky IP input/ouput" feature is > a goal for 5.3 (in fact, I believe Sam has it almost entirely done in one > of his development branches), and should both simplify the input/output > paths, and also simplify locking for the IP stack. So the change is for a > good cause :-). > That reminds me: is there a way to influence the order in which the various packages are hooked up? E.g. I can imagine a situation where you want IPfilter NATting and ipfw filtering. In such a scenario you want to be able to specify _exactly_ that ipfilter comes before ipfw when packets come in, and vice versa when packets go out. -Guido From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 02:35:04 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D355916A4CE; Fri, 16 Jan 2004 02:35:04 -0800 (PST) Received: from sev.net.ua (sev.net.ua [212.86.233.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B1A443D48; Fri, 16 Jan 2004 02:35:00 -0800 (PST) (envelope-from root@umka.bear.com.ua) Received: from umka.bear.com.ua (st50.sevcity.net [212.86.245.254]) by sev.net.ua (8.12.10/8.12.9) with ESMTP id i0GAWtB9015879; Fri, 16 Jan 2004 12:32:56 +0200 (EET) (envelope-from root@umka.bear.com.ua) Received: from localhost (localhost [[UNIX: localhost]]) by umka.bear.com.ua (8.11.6/8.11.6) id i0GAWxS26170; Fri, 16 Jan 2004 12:32:59 +0200 Content-Type: text/plain; charset="koi8-r" From: Alex Lyashkov Organization: Positive Software Corporation To: hackers@freebsd.org Date: Fri, 16 Jan 2004 12:32:57 +0200 User-Agent: KMail/1.4.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200401161232.59044.shadow@psoft.net> cc: current@freebsd.org Subject: few question about vfs layer X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 10:35:05 -0000 Hi List I explore vfs lookup code. and have few questions about it. what a reasone leave rootvnode as global varables, but not store it in filedesc structrure and adjust it in chroot or jail syscall ? -- With best regards, Alex From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 06:14:24 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5C6916A4CE for ; Fri, 16 Jan 2004 06:14:24 -0800 (PST) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5292743D54 for ; Fri, 16 Jan 2004 06:14:23 -0800 (PST) (envelope-from tillman@seekingfire.com) Received: by mail.seekingfire.com (Postfix, from userid 500) id 5AB19282; Fri, 16 Jan 2004 08:14:22 -0600 (CST) Date: Fri, 16 Jan 2004 08:14:22 -0600 From: Tillman Hodgson To: Michael Cacek Message-ID: <20040116141422.GX468@seekingfire.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-GPG-Key-ID: 828AFC7B X-GPG-Fingerprint: 5584 14BA C9EB 1524 0E68 F543 0F0A 7FBC 828A FC7B X-GPG-Key: http://www.seekingfire.com/gpg_key.asc X-Urban-Legend: There is lots of hidden information in headers User-Agent: Mutt/1.5.5.1i cc: freebsd-hackers@freebsd.org Subject: Re: Slow Console Input X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 14:14:24 -0000 On Thu, Jan 15, 2004 at 10:56:36PM -0600, Michael Cacek wrote: > I recently installed freebsd 5.2 on a local sunblade 100 system. You probably want to try on the sparc64@ list. FWIW, the last time I checked syscons improvements were still on the TO-DO list for the sparc64 port. It's never really affected me though -- my Ultra 5 is a server, so I either serial console to it or ssh/Kerberized telnet to it. -T -- > Life is once again okay, if non-standard. - Takis Skagos, on a LOSURS mailing list From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 06:30:01 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7FDB16A501 for ; Fri, 16 Jan 2004 06:30:00 -0800 (PST) Received: from mail.gulfgate-inc.com (mail.gulfgate-inc.com [64.1.98.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id C765C43D41 for ; Fri, 16 Jan 2004 06:29:54 -0800 (PST) (envelope-from mfreitag@gulfgateequipment.com) Received: (qmail 90766 invoked by uid 85); 16 Jan 2004 14:32:45 -0000 Received: from mfreitag@gulfgateequipment.com by linkdead.beatlab.org by uid 89 with qmail-scanner-1.15 (uvscan: v4.1.60/v4248. spamassassin: 2.x. Clear:. Processed in 1.051341 secs); 16 Jan 2004 14:32:45 -0000 Received: from unknown (HELO gulfgateequipment.com) (mfreitag@gulfgateequipment.com@192.168.0.4) by 192.168.0.40 with SMTP; 16 Jan 2004 14:32:43 -0000 Message-ID: <4007F55E.8010003@gulfgateequipment.com> Date: Fri, 16 Jan 2004 08:29:50 -0600 From: Matt Freitag User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson , freebsd-hackers@freebsd.org References: In-Reply-To: X-Mailman-Approved-At: Fri, 16 Jan 2004 06:31:59 -0800 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Re: 5.1->5.2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 14:30:01 -0000 Now I can play with ULE, Thanks for your quick response. I should've checked release notes before posting my question, my fault. -mpf Robert Watson wrote: >On Thu, 15 Jan 2004, Matt Freitag wrote: > > > >>Building 5.2-RELEASE from 5.1-RELEASE-p10 w/ipf+ipfw+ipfw6+dummynet, 5.1 >>Compiled fine with this setup. I need ipfilter as it's doing my source >>routing for ipv6 (multiple transits) since ip6fw doesn't support fwd. (I >>just use ip6fw for filtering, and ipf for forwarding to the correct >>interface according to source) Am I just being stupid here somehow? >> >> > >IPFILTER now relies on the PFIL_HOOKS kernel option; this is something >that is somewhat poorly documented, and we should add it to the errate I >suspect. If you add "options PFIL_HOOKS" to your kernel config, it should >work. Moving to PFIL_HOOKS for all the "funky IP input/ouput" feature is >a goal for 5.3 (in fact, I believe Sam has it almost entirely done in one >of his development branches), and should both simplify the input/output >paths, and also simplify locking for the IP stack. So the change is for a >good cause :-). > >Robert N M Watson FreeBSD Core Team, TrustedBSD Projects >robert@fledge.watson.org Senior Research Scientist, McAfee Research > > > > > > > From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 08:39:47 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F32516A4CE; Fri, 16 Jan 2004 08:39:47 -0800 (PST) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02E0A43D31; Fri, 16 Jan 2004 08:39:42 -0800 (PST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) i0GGdQN1046543 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 16 Jan 2004 17:39:32 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id i0GGdG4H029312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2004 17:39:17 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.10/8.12.10) with ESMTP id i0GGdGBE042003; Fri, 16 Jan 2004 17:39:16 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.10/8.12.10/Submit) id i0GGdDQm042002; Fri, 16 Jan 2004 17:39:13 +0100 (CET) (envelope-from ticso) Date: Fri, 16 Jan 2004 17:39:13 +0100 From: Bernd Walter To: Julian Elischer Message-ID: <20040116163912.GK24203@cicely12.cicely.de> References: <20040113235511.GB39353@pcwin002.win.tue.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.61 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on cicely5.cicely.de cc: hackers@freebsd.org cc: imp@freebsd.org Subject: Re: PCI interrupt allocation question.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 16:39:47 -0000 On Tue, Jan 13, 2004 at 04:14:10PM -0800, Julian Elischer wrote: > > > On Wed, 14 Jan 2004, Stijn Hoop wrote: > > > On Tue, Jan 13, 2004 at 03:26:00PM -0800, Julian Elischer wrote: > > > The kernel includes teh ichsmb driver to try access the SMBus > > > for temperature reading reasons (yes I know I can do it other ways..) > > > > > > Any thoughts that move me towards getting th eichsmb driver working on > > > this machine are welcome. > > > > Make sure that the mainboard really does support SMBus -- it turns out that > > this is optional. The ICH docs talk about a bit that should be enabled in the > > PCI config when SMB is present. I ran into this once, it should be documented > > in the archives (of -current off the top of my head). OTOH, I didn't even > > succeed in getting an ichsmb device probed so this might be something totally > > unrelated. SMBus is absolutely not optional because it's required for SPD eeproms. > > FWIW, I had to try other ways to get the temperature (xmbmon & related). I > > don't have the box anymore or I'd show you the exact config... > > xmbmon uses the SMBus to read the temperatures but it does it from > userland using direct read and write operations > and when there are timing glitches caused by the process not getting > scheduled quite quick enough you get garbage results.. > teh theory is that the kernel driver wouldn't be susceptible to this > but it looks like unless I resort to polling I will not be able to use > it because it relies on the interrupts and they are not being delivered. ichsmb(4) does a different addressing on smbus as other smbus drivers. I'm about to validate all SMBus drivers to harmonise this point. Also software regulary forgets about different smb.h include path on 5.x > ASUS motherboards actually turn off the SMBus. (why?) A very good question - I'm in tight contact with Asus germany to get that answered, but even they doesn't seem to get a satisfying answer from taiwan. It seems that they don't want customers to tamper with SMBus :( > So you need to turn it back on before you can read the temperatures.. Use ACPI... Well - it's evil after all, because I sell add on products for SMBus for which ACPI is not an option. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 09:42:36 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B8C016A4CE for ; Fri, 16 Jan 2004 09:42:36 -0800 (PST) Received: from smtp.jeans.ocn.ne.jp (jeans.ocn.ne.jp [211.6.83.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 825F243D45 for ; Fri, 16 Jan 2004 09:42:34 -0800 (PST) (envelope-from shirube@jeans.ocn.ne.jp) Received: from localhost (p2222-ipad64marunouchi.tokyo.ocn.ne.jp [219.165.9.222]) by smtp.jeans.ocn.ne.jp (Postfix) with ESMTP id 2C24D4831; Sat, 17 Jan 2004 02:42:33 +0900 (JST) To: adrian+freebsd-hackers@ubergeeks.com In-Reply-To: <20040116011400.V32954@lorax.ubergeeks.com> References: <200401130746.i0D7kNEk004375@manor.msen.com> <20040116011400.V32954@lorax.ubergeeks.com> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Message-Id: <20040117024103F.shirube@jeans.ocn.ne.jp> Date: Sat, 17 Jan 2004 02:41:03 +0900 From: S.Yamagishi X-Dispatcher: imput version 20000228(IM140) Lines: 15 cc: hackers@freebsd.org Subject: Re: Mergemaster+RCS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 17:42:36 -0000 $B1)?6$j$NNI$/$J$C$?$+$D$F$NIt2<$KD$r5-$7$?%O%k$N2s8\O?Iw$K(B $B$O!"(B"$B#1#0!s$N9XF~A}(B"$B!"(B"$BM}2r$r5a$a$k(B"$B$O;~4V2T$.$G!"2?$+$r1#$7$F$$$k>Z5r$H(B $B2rl$ON?$2$k$H;W$C$F$$$k!"A10U$KK~$A$?(B $B$O$$$k$,7hDj8"$NA4$/$J$$7/$_$?$$$J?M$HMh$F$O!"9T$+$J$$J}$,NI$$$K7h$^$C$F$$$k!#(B $BD@L[!"6[D%$KBQ$($k5$35$b$J$/!"7W2h$b$J$$$N$@$+$i!"32$HB;$,A}$($k$@$1!#1Q9qN.(B $B$N(BUnderstatement$B$J$i(B10 %$B$r8@$&$K$O(B100%$BA}$N7W2h$,$J$1$l$P$J$k$^$$!#(B $B$R$I$$8@Ap$H;W$&$@$m$&$,!"@5$7$$H=CG$@$H9M$($k!#5nG/$b:_8K$rA}$d$7$?$N$K!"99$K(B $B#1#0!s$H$OE~Dl?.$8$i$l$J$$OC!#(BRenapur$B$rGd$C$?J}$,3f9%$,IU$/$N$G$O$J$$$+!#(B $BBg$$$KIe$k$,$h$m$7$$!#:#$^$G$r9M$($l$P!"EvA3$J7k2L$K$J$C$?$HG Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8002A16A4CE for ; Fri, 16 Jan 2004 10:54:47 -0800 (PST) Received: from Shenton.org (23.ebbed1.client.atlantech.net [209.190.235.35]) by mx1.FreeBSD.org (Postfix) with SMTP id 083CC43D69 for ; Fri, 16 Jan 2004 10:54:16 -0800 (PST) (envelope-from chris@Shenton.Org) Received: (qmail 35662 invoked by uid 1001); 16 Jan 2004 18:54:13 -0000 To: bmah@freebsd.org References: <200401152307.i0FN7spW039480@intruder.kitchenlab.org> From: Chris Shenton Date: Fri, 16 Jan 2004 13:54:13 -0500 In-Reply-To: <200401152307.i0FN7spW039480@intruder.kitchenlab.org> (Bruce A. Mah's message of "Thu, 15 Jan 2004 15:07:54 -0800") Message-ID: <868yk7ybai.fsf@PECTOPAH.shenton.org> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: Matt Freitag cc: freebsd-hackers@freebsd.org cc: Robert Watson Subject: Re: 5.1->5.2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 18:54:47 -0000 "Bruce A. Mah" writes: > It's in the release notes and in UPDATING...I have the feeling that if > people won't read it in either of those two places, they won't read it > in the errata either. :-p How 'bout putting it some place folks are likely to stumble upon it, like as a comment in the GENERIC kernel file? From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 12:09:50 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60BFB16A4CE for ; Fri, 16 Jan 2004 12:09:50 -0800 (PST) Received: from nalle.netsonic.fi (netsonic.fi [194.29.192.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCEB243D31 for ; Fri, 16 Jan 2004 12:09:47 -0800 (PST) (envelope-from markus.kovero@grafikansi.fi) Received: from shaggy (pilosus.grafikansi.fi [81.17.198.68]) by nalle.netsonic.fi (8.11.6/8.11.6) with ESMTP id i0GK9kY13041 for ; Fri, 16 Jan 2004 22:09:46 +0200 Message-Id: <200401162009.i0GK9kY13041@nalle.netsonic.fi> From: "Markus Kovero" To: Date: Fri, 16 Jan 2004 22:09:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcPcbLImgFYHRocmQQCCRXilQgvliQ== Subject: Bind hack for ipv6 autoconf X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 20:09:50 -0000 I was just wondering, inspired by Saku Ytti's idea of making hack to bind which would allow proper PTR and AAAA records for rtadvd or similar autoconfigured hosts, as you can know hosts that are given are quite random, and far as I know there is no smart logic with them. So, somekinda hack for bind is needed. eg. bind could be modified to do PTR and AAAA with different system than zonefiles has, though zonefiles shouldn't be ignored but if query regarding autoconfigured subnet comes in it should be handled on its own system. For example: Foo asks reverse for address xyz, bind notices that it has subnet xy defined as autoconfig hosts and calculates reverse for it like, xyz IN PTR z-xy.auto.foo.tld. And then, another day, Bar asks AAAA record for z-xy.auto.foo.tld and bind notices that its under auto.foo.tld which was defined for autoconfigured hosts and subnet was xy, answer xyz is given. And if foo asks AAAA for foo.tld bind operates normally and gives possible answer from zonefile. If ISC guys are following these lists I would like to hear their comments. Anybody interested in developing this kind of modification? Ideas? Comments? Anybody? Greets Markus Kovero From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 12:43:25 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49E8E16A4CE for ; Fri, 16 Jan 2004 12:43:25 -0800 (PST) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 3B39343D58 for ; Fri, 16 Jan 2004 12:43:19 -0800 (PST) (envelope-from mdcki@gmx.net) Received: (qmail 18525 invoked by uid 65534); 16 Jan 2004 20:43:17 -0000 Received: from Bc267.b.pppool.de (EHLO gmx.net) (213.7.194.103) by mail.gmx.net (mp025) with SMTP; 16 Jan 2004 21:43:17 +0100 X-Authenticated: #17236065 Message-ID: <40084CE7.5010507@gmx.net> Date: Fri, 16 Jan 2004 21:43:19 +0100 From: Marcin Dalecki User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031224 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Linimon References: <33570.1073898807@critter.freebsd.dk> <200401120341.42349.linimon@lonesome.com> In-Reply-To: <200401120341.42349.linimon@lonesome.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Greg 'groggy' Lehey cc: Poul-Henning Kamp cc: hackers@FreeBSD.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 20:43:25 -0000 Mark Linimon wrote: > > But, in the real world of software engineering, He Who Breaketh It, > Must Fixeth It. > > Your mileage may vary. Yes it vaires. In the real world He Who Reaketh It, will hire someone who known what he is doing to fix the problem... From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 15:50:16 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3140216A4CE; Fri, 16 Jan 2004 15:50:16 -0800 (PST) Received: from exchange.wan.no (exchange.wan.no [80.86.128.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D79143D68; Fri, 16 Jan 2004 15:50:07 -0800 (PST) (envelope-from sten.daniel.sorsdal@wan.no) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Date: Sat, 17 Jan 2004 00:50:04 +0100 Message-ID: <0AF1BBDF1218F14E9B4CCE414744E70F5D97FF@exchange.wanglobal.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ip_input - chksum - why is it done so early in ip_input? Thread-Index: AcPci3XZNAfA0SjOROqn22VbyT2w8A== From: =?iso-8859-1?Q?Sten_Daniel_S=F8rsdal?= To: , Subject: ip_input - chksum - why is it done so early in ip_input? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 23:50:16 -0000 Apologies for the cross-post, i wasnt sure if this was hackers or net = material. I've often wondered why ip checksumming is done on every incoming=20 packet and not only on the packets that need to be delivered locally. It looks like a very expensive way of doing it, especially on high PPS. Basically all hosts do checksumming so why not just pass the bad packet on, making the forward process alot cheaper (cpu wise)? I ran some tests (unable to disclose results) by removing it completely and it seems to make a noticable impact on the performance. Especially on for example gaming services where there is a high PPS = versus actual data. Besides that i'd like to add that FreeBSD has the fastest forwarding = engine i've seen on any free OS. It's in my opinion a very suitable OS for=20 routing/forwarding. _// Sten From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 16:10:13 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B16E616A4CE for ; Fri, 16 Jan 2004 16:10:13 -0800 (PST) Received: from agp.stanford.edu (agp.Stanford.EDU [171.67.73.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A8E943D58 for ; Fri, 16 Jan 2004 16:09:35 -0800 (PST) (envelope-from twohey@CS.Stanford.EDU) Received: from [171.64.66.201] (helo=Xenon.Stanford.EDU) by agp.stanford.edu with esmtp (Exim 4.22) id 1Ahe1v-000346-Jr for freebsd-hackers@freebsd.org; Fri, 16 Jan 2004 16:09:35 -0800 Received: from xenon.stanford.edu ([171.64.66.201]) by Xenon.Stanford.EDU with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.20) id 1Ahe1u-0000lq-Uc for freebsd-hackers@freebsd.org; Fri, 16 Jan 2004 16:09:34 -0800 Date: Fri, 16 Jan 2004 16:09:34 -0800 (PST) From: Paul Twohey To: freebsd-hackers@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scan-Signature: 4ae6892c939336b6dbaef034bca59745 Subject: [CHECKER] bugs in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2004 00:10:13 -0000 Hi, I'm with the Stanford Metacompilation research group. We have a suite of checkers that find bugs at compile time and we've had quite a bit of success checking the Linux kernel code for errors. Since our checkers can emit false alarms we filter the reports before we give them to the kernel developers. While some false alarms slip past us to the developers, our limited knowledge of the kernel allows us to recognize most of them. We are currently trying to extend our checker to automatically find functions which allocate resources and to make sure those resources are properly disposed of. Enclosed is a list of potential bugs in FreeBSD where a value is returned from a function (like malloc) that should be owned by the caller and the caller does not properly dispose of the value with the appropriate disposal routine (like free). Confirmation of these reports would be appreciated. Thanks Paul Twohey --------------------------------------------------------- [BUG] they do error checking at the end, so lose config. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/ata/ata-raid.c:1222:ar_highpoint_write_conf:ERROR:LEAK:1222:1222: pointer=config from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=6] microtime(×tamp); rdp->magic_0 = timestamp.tv_sec + 2; rdp->magic_1 = timestamp.tv_sec; for (disk = 0; disk < rdp->total_disks; disk++) { Error ---> if (!(config = (struct highpoint_raid_conf *) malloc(sizeof(struct highpoint_raid_conf), M_AR, M_NOWAIT | M_ZERO))) { printf("ar%d: Highpoint write conf failed\n", rdp->lun); --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/ppbus/vpo.c:187:vpo_cam_rescan:ERROR:LEAK:187:192: pointer=ccb from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=4] static void vpo_cam_rescan(struct vpo_data *vpo) { struct cam_path *path; Start ---> union ccb *ccb = malloc(sizeof(union ccb), M_TEMP, M_WAITOK | M_ZERO); if (xpt_create_path(&path, xpt_periph, cam_sim_path(vpo->sim), 0, 0) != CAM_REQ_CMP) { /* A failure is benign as the user can do a manual rescan */ Error ---> return; } xpt_setup_ccb(&ccb->ccb_h, path, 5/*priority (low)*/); --------------------------------------------------------- [BUG] though we should demote things that are not locals. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/ips/ips.c:148:ips_add_waiting_command:ERROR:LEAK:148:154: pointer=waiter from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=5] ips_command_t *command; ips_wait_list_t *waiter; unsigned long memflags = 0; if(IPS_NOWAIT_FLAG & flags) memflags = M_NOWAIT; Start ---> waiter = malloc(sizeof(ips_wait_list_t), M_DEVBUF, memflags); if(!waiter) return ENOMEM; mask = splbio(); if(sc->state & IPS_OFFLINE){ splx(mask); Error ---> return EIO; } command = SLIST_FIRST(&sc->free_cmd_list); if(command && !(sc->state & IPS_TIMEOUT)){ --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/sio/sio.c:497:sioprobe:ERROR:LEAK:497:504: pointer=port from RO=bus_alloc_resource(-1) [s=65,pop=65,pr=1.00] [rank=med] leaked! [z=1.0] [success=3] u_int flags = device_get_flags(dev); int rid; struct resource *port; rid = xrid; Start ---> port = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, 0, ~0, IO_COMSIZE, RF_ACTIVE); if (!port) return (ENXIO); com = malloc(sizeof(*com), M_DEVBUF, M_NOWAIT | M_ZERO); if (com == NULL) Error ---> return (ENOMEM); device_set_softc(dev, com); com->bst = rman_get_bustag(port); com->bsh = rman_get_bushandle(port); --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/mly/mly.c:2023:mly_cam_rescan_btl:ERROR:LEAK:2023:2031: pointer=ccb from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=4] { union ccb *ccb; debug_called(1); Start ---> if ((ccb = malloc(sizeof(union ccb), M_TEMP, M_WAITOK | M_ZERO)) == NULL) { mly_printf(sc, "rescan failed (can't allocate CCB)\n"); return; } if (xpt_create_path(&sc->mly_cam_path, xpt_periph, cam_sim_path(sc->mly_cam_sim[bus]), target, 0) != CAM_REQ_CMP) { mly_printf(sc, "rescan failed (can't create path)\n"); Error ---> return; } xpt_setup_ccb(&ccb->ccb_h, sc->mly_cam_path, 5/*priority (low)*/); ccb->ccb_h.func_code = XPT_SCAN_LUN; --------------------------------------------------------- [BUG] inferred bcopy. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../cam/scsi/scsi_low.c:966:scsi_low_rescan_bus_cam:ERROR:LEAK:966:974: pointer=ccb from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=5][passed through 1 nros][NCO=bzero(0), s=85, pop=85, pr=1.00] static void scsi_low_rescan_bus_cam(slp) struct scsi_low_softc *slp; { struct cam_path *path; Start ---> union ccb *ccb = malloc(sizeof(union ccb), M_DEVBUF, M_WAITOK); cam_status status; bzero(ccb, sizeof(union ccb)); status = xpt_create_path(&path, xpt_periph, cam_sim_path(slp->sl_si.sim), -1, 0); if (status != CAM_REQ_CMP) Error ---> return; xpt_setup_ccb(&ccb->ccb_h, path, 5); ccb->ccb_h.func_code = XPT_SCAN_BUS; --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/ciss/ciss.c:2130:ciss_cam_rescan_target:ERROR:LEAK:2130:2138: pointer=ccb from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=4] { union ccb *ccb; debug_called(1); Start ---> if ((ccb = malloc(sizeof(union ccb), M_TEMP, M_WAITOK | M_ZERO)) == NULL) { ciss_printf(sc, "rescan failed (can't allocate CCB)\n"); return; } if (xpt_create_path(&sc->ciss_cam_path, xpt_periph, cam_sim_path(sc->ciss_cam_sim), target, 0) != CAM_REQ_CMP) { ciss_printf(sc, "rescan failed (can't create path)\n"); Error ---> return; } xpt_setup_ccb(&ccb->ccb_h, sc->ciss_cam_path, 5/*priority (low)*/); --------------------------------------------------------- [BUG] i think it got lost. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../kern/uipc_socket.c:1608:soopt_getm:ERROR:LEAK:1608:1617: pointer=m from RO=m_get(-1) [s=46,pop=49,pr=1.00] [rank=med] leaked! [z=1.0] [success=2][passed through 1 nros][NCO=m_clget(0), s=54, pop=54, pr=1.00] sopt_size -= m->m_len; *mp = m; m_prev = m; while (sopt_size) { Start ---> MGET(m, sopt->sopt_td ? M_TRYWAIT : M_DONTWAIT, MT_DATA); if (m == 0) { m_freem(*mp); return ENOBUFS; } if (sopt_size > MLEN) { MCLGET(m, sopt->sopt_td ? M_TRYWAIT : M_DONTWAIT); if ((m->m_flags & M_EXT) == 0) { m_freem(*mp); Error ---> return ENOBUFS; } m->m_len = min(MCLBYTES, sopt_size); } else { --------------------------------------------------------- [BUG] indeed. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../isa/pnp.c:657:pnp_read_bytes:ERROR:LEAK:657:669: pointer=resources from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=7] int space = *spacep; int len = *lenp; if (space == 0) { space = 1024; Start ---> resources = malloc(space, M_TEMP, M_NOWAIT); if (!resources) return ENOMEM; } if (len + amount > space) { int extra = 1024; while (len + amount > space + extra) extra += 1024; newres = malloc(space + extra, M_TEMP, M_NOWAIT); if (!newres) { /* XXX: free resources */ Error ---> return ENOMEM; } bcopy(resources, newres, len); free(resources, M_TEMP); --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/firewire/fwohci.c:1188:fwohci_db_init:ERROR:LEAK:1188:1201: pointer=db_tr from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=5] return; /* allocate DB entries and attach one to each DMA channels */ /* DB entry must start at 16 bytes bounary. */ STAILQ_INIT(&dbch->db_trq); Start ---> db_tr = (struct fwohcidb_tr *) malloc(sizeof(struct fwohcidb_tr) * dbch->ndb, M_FW, M_WAITOK | M_ZERO); if(db_tr == NULL){ printf("fwohci_db_init: malloc(1) failed\n"); return; } #define DB_SIZE(x) (sizeof(struct fwohcidb) * (x)->ndesc) dbch->am = fwdma_malloc_multiseg(&sc->fc, DB_SIZE(dbch), DB_SIZE(dbch), dbch->ndb, BUS_DMA_WAITOK); if (dbch->am == NULL) { printf("fwohci_db_init: fwdma_malloc_multiseg failed\n"); Error ---> return; } /* Attach DB to DMA ch. */ for(idb = 0 ; idb < dbch->ndb ; idb++){ --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/firewire/fwdev.c:579:fw_ioctl:ERROR:LEAK:579:593: pointer=fwb from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=3] } if(bindreq->start.hi > 0xffff ){ err = EINVAL; break; } Start ---> fwb = (struct fw_bind *)malloc(sizeof (struct fw_bind), M_FW, M_NOWAIT); if(fwb == NULL){ err = ENOMEM; break; } fwb->start_hi = bindreq->start.hi; fwb->start_lo = bindreq->start.lo; fwb->addrlen = bindreq->len; fwb->sub = sub; fwb->act_type = FWACT_CH; xfer = fw_xfer_alloc(M_FWXFER); if(xfer == NULL){ err = ENOMEM; Error ---> return err; } xfer->fc = sc->fc; --------------------------------------------------------- [BUG] sure looks like an error, since they free it below. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/an/if_an.c:913:an_rxeof:ERROR:LEAK:913:932: pointer=m from RO=m_gethdr(-1) [s=74,pop=78,pr=1.00] [rank=med] leaked! [z=1.0] [success=2][passed through 1 nros][NCO=m_clget(0), s=54, pop=54, pr=1.00] rx_frame.an_rx_payload_len); } /* dump raw 802.11 packet to bpf and skip ip stack */ BPF_TAP(ifp, bpf_buf, len); } else { Start ---> MGETHDR(m, M_DONTWAIT, MT_DATA); ... DELETED 13 lines ... #ifdef ANCACHE /* Read NIC frame header */ if (an_read_data(sc, id, 0, (caddr_t)&rx_frame, sizeof(rx_frame))) { ifp->if_ierrors++; Error ---> return; } #endif /* Read in the 802_3 frame header */ --------------------------------------------------------- [BUG] actually, i'm not sure if it labelled pnp_get_resource_info correctly. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../isa/pnp.c:657:pnp_read_bytes:ERROR:LEAK:657:678: pointer=resources from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=7] int space = *spacep; int len = *lenp; if (space == 0) { space = 1024; Start ---> resources = malloc(space, M_TEMP, M_NOWAIT); ... DELETED 15 lines ... resources = newres; space += extra; } if (pnp_get_resource_info(resources + len, amount) != amount) Error ---> return EINVAL; len += amount; *resourcesp = resources; --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/dpt/dpt_scsi.c:1542:dpt_attach:ERROR:LEAK:1542:1571: pointer=devq from RO=cam_simq_alloc(-1) [s=21,pop=21,pr=0.99] [rank=med] leaked! [z=1.0] [success=3] int i; /* * Create the device queue for our SIM. */ Start ---> devq = cam_simq_alloc(dpt->max_dccbs); ... DELETED 23 lines ... } if (i > 0) EVENTHANDLER_REGISTER(shutdown_final, dptshutdown, dpt, SHUTDOWN_PRI_DEFAULT); Error ---> return (i); } int --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/iir/iir.c:500:iir_attach:ERROR:LEAK:500:530: pointer=devq from RO=cam_simq_alloc(-1) [s=21,pop=21,pr=0.99] [rank=med] leaked! [z=1.0] [success=3] GDT_DPRINTF(GDT_D_INIT, ("iir_attach()\n")); /* * Create the device queue for our SIM. */ Start ---> devq = cam_simq_alloc(GDT_MAXCMDS); ... DELETED 24 lines ... if (i > 0) EVENTHANDLER_REGISTER(shutdown_final, iir_shutdown, gdt, SHUTDOWN_PRI_DEFAULT); /* iir_watchdog(gdt); */ gdt->sc_state = GDT_NORMAL; Error ---> } static void gdt_eval_mapping(u_int32_t size, int *cyls, int *heads, int *secs) --------------------------------------------------------- [BUG] they lose all sorts of stuff. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/kbd/atkbd.c:361:atkbd_init:ERROR:LEAK:361:392: pointer=fkeymap from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=10] } else if (*kbdp == NULL) { *kbdp = kbd = malloc(sizeof(*kbd), M_DEVBUF, M_NOWAIT | M_ZERO); state = malloc(sizeof(*state), M_DEVBUF, M_NOWAIT | M_ZERO); keymap = malloc(sizeof(key_map), M_DEVBUF, M_NOWAIT); accmap = malloc(sizeof(accent_map), M_DEVBUF, M_NOWAIT); Start ---> fkeymap = malloc(sizeof(fkey_tab), M_DEVBUF, M_NOWAIT); ... DELETED 25 lines ... } if (!KBD_IS_PROBED(kbd)) { state->kbdc = atkbdc_open(data[0]); if (state->kbdc == NULL) Error ---> return ENXIO; kbd_init_struct(kbd, ATKBD_DRIVER_NAME, KB_OTHER, unit, flags, 0, 0); bcopy(&key_map, keymap, sizeof(key_map)); --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/kbd/atkbd.c:360:atkbd_init:ERROR:LEAK:360:392: pointer=accmap from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=10] sizeof(default_fkeytab)/sizeof(default_fkeytab[0]); } else if (*kbdp == NULL) { *kbdp = kbd = malloc(sizeof(*kbd), M_DEVBUF, M_NOWAIT | M_ZERO); state = malloc(sizeof(*state), M_DEVBUF, M_NOWAIT | M_ZERO); keymap = malloc(sizeof(key_map), M_DEVBUF, M_NOWAIT); Start ---> accmap = malloc(sizeof(accent_map), M_DEVBUF, M_NOWAIT); ... DELETED 26 lines ... } if (!KBD_IS_PROBED(kbd)) { state->kbdc = atkbdc_open(data[0]); if (state->kbdc == NULL) Error ---> return ENXIO; kbd_init_struct(kbd, ATKBD_DRIVER_NAME, KB_OTHER, unit, flags, 0, 0); bcopy(&key_map, keymap, sizeof(key_map)); --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/amr/amr_cam.c:143:amr_cam_attach:ERROR:LEAK:143:175: pointer=devq from RO=cam_simq_alloc(-1) [s=21,pop=21,pr=0.99] [rank=med] leaked! [z=1.0] [success=3] /* * Allocate a devq for all our channels combined. This should * allow for the maximum number of SCSI commands we will accept * at one time. */ Start ---> if ((devq = cam_simq_alloc(AMR_MAX_SCSI_CMDS)) == NULL) ... DELETED 26 lines ... } /* * XXX we should scan the config and work out which devices are actually * protected. */ Error ---> return(0); } /******************************************************************************** --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/kbd/atkbd.c:359:atkbd_init:ERROR:LEAK:359:392: pointer=keymap from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=10] fkeymap_size = sizeof(default_fkeytab)/sizeof(default_fkeytab[0]); } else if (*kbdp == NULL) { *kbdp = kbd = malloc(sizeof(*kbd), M_DEVBUF, M_NOWAIT | M_ZERO); state = malloc(sizeof(*state), M_DEVBUF, M_NOWAIT | M_ZERO); Start ---> keymap = malloc(sizeof(key_map), M_DEVBUF, M_NOWAIT); ... DELETED 27 lines ... } if (!KBD_IS_PROBED(kbd)) { state->kbdc = atkbdc_open(data[0]); if (state->kbdc == NULL) Error ---> return ENXIO; kbd_init_struct(kbd, ATKBD_DRIVER_NAME, KB_OTHER, unit, flags, 0, 0); bcopy(&key_map, keymap, sizeof(key_map)); --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/kbd/atkbd.c:358:atkbd_init:ERROR:LEAK:358:392: pointer=state from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=8] fkeymap = default_fkeytab; fkeymap_size = sizeof(default_fkeytab)/sizeof(default_fkeytab[0]); } else if (*kbdp == NULL) { *kbdp = kbd = malloc(sizeof(*kbd), M_DEVBUF, M_NOWAIT | M_ZERO); Start ---> state = malloc(sizeof(*state), M_DEVBUF, M_NOWAIT | M_ZERO); ... DELETED 28 lines ... } if (!KBD_IS_PROBED(kbd)) { state->kbdc = atkbdc_open(data[0]); if (state->kbdc == NULL) Error ---> return ENXIO; kbd_init_struct(kbd, ATKBD_DRIVER_NAME, KB_OTHER, unit, flags, 0, 0); bcopy(&key_map, keymap, sizeof(key_map)); --------------------------------------------------------- [BUG] probably minor: it can happen if uio_resid == 0 (the error checking just flags if its < 0). /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../net/if_tun.c:719:tunwrite:ERROR:LEAK:719:761: pointer=m from RO=m_gethdr(-1) [s=74,pop=78,pr=1.00] [rank=med] leaked! [z=1.0] [success=3] return (EIO); } tlen = uio->uio_resid; /* get a header mbuf */ Start ---> MGETHDR(m, M_DONTWAIT, MT_DATA); ... DELETED 36 lines ... * Conveniently, we already have a 4-byte address * family prepended to our packet ! * Inconveniently, it's in the wrong byte order ! */ if ((top = m_pullup(top, sizeof(family))) == NULL) Error ---> return (ENOBUFS); *mtod(top, u_int32_t *) = ntohl(*mtod(top, u_int32_t *)); BPF_MTAP(ifp, top); --------------------------------------------------------- [BUG] i'm getting less sure about these type of errors, but it sure looks like a bug. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../kern/uipc_mbuf.c:656:m_devget:ERROR:LEAK:656:700: pointer=m from RO=m_gethdr(-1) [s=74,pop=78,pr=1.00] [rank=med] leaked! [z=1.0] [success=6] int len; if (off < 0 || off > MHLEN) return (NULL); Start ---> MGETHDR(m, M_DONTWAIT, MT_DATA); ... DELETED 38 lines ... buf += len; *mp = m; mp = &m->m_next; totlen -= len; } Error ---> return (top); } /* --------------------------------------------------------- [BUG] there are similar errors in dev/kbd/atkbd.c /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/usb/ukbd.c:522:ukbd_init:ERROR:LEAK:522:581: pointer=state from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=8] } else if (*kbdp == NULL) { *kbdp = kbd = malloc(sizeof(*kbd), M_DEVBUF, M_NOWAIT); if (kbd == NULL) return ENOMEM; bzero(kbd, sizeof(*kbd)); Start ---> state = malloc(sizeof(*state), M_DEVBUF, M_NOWAIT); ... DELETED 53 lines ... } if (!KBD_IS_INITIALIZED(kbd) && !(flags & KB_CONF_PROBE_ONLY)) { if (KBD_HAS_DEVICE(kbd) && init_keyboard((ukbd_state_t *)kbd->kb_data, &kbd->kb_type, kbd->kb_flags)) Error ---> return ENXIO; ukbd_ioctl(kbd, KDSETLED, (caddr_t)&(state->ks_state)); KBD_INIT_DONE(kbd); } --------------------------------------------------------- [BUG] does lose on default. "impossible" though. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/ata/ata-raid.c:704:arstrategy:ERROR:LEAK:704:829: pointer=buf1 from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=15] bp->bio_error = EIO; biodone(bp); return; } Start ---> buf1 = malloc(sizeof(struct ar_buf), M_AR, M_NOWAIT | M_ZERO); ... DELETED 119 lines ... default: printf("ar%d: unknown array type in arstrategy\n", rdp->lun); } } Error ---> } static void ar_done(struct bio *bp) --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/pst/pst-iop.c:341:iop_get_util_params:ERROR:LEAK:341:347: pointer=param from RO=contigmalloc(-1) [s=4,pop=4,pr=0.57] [rank=med] leaked! [z=0.6] [success=3] struct i2o_util_get_param_message *msg; struct i2o_get_param_operation *param; struct i2o_get_param_reply *reply; int mfa; Start ---> if (!(param = contigmalloc(PAGE_SIZE, M_PSTIOP, M_NOWAIT | M_ZERO, 0x00010000, 0xFFFFFFFF, PAGE_SIZE, 0))) return NULL; if (!(reply = contigmalloc(PAGE_SIZE, M_PSTIOP, M_NOWAIT | M_ZERO, 0x00010000, 0xFFFFFFFF, PAGE_SIZE, 0))) Error ---> return NULL; mfa = iop_get_mfa(sc); msg = (struct i2o_util_get_param_message *)(sc->ibase + mfa); --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/mlx/mlx.c:1870:mlx_user_command:ERROR:LEAK:1870:1878: pointer=mc from RO=mlx_alloccmd(-1) [s=6,pop=8,pr=0.57] [rank=med] leaked! [z=0.6] [success=2] mc = NULL; dcdb = NULL; error = ENOMEM; /* get ourselves a command and copy in from user space */ Start ---> if ((mc = mlx_alloccmd(sc)) == NULL) goto out; bcopy(mu->mu_command, mc->mc_mailbox, sizeof(mc->mc_mailbox)); debug(0, "got command buffer"); /* if we need a buffer for data transfer, allocate one and copy in its initial contents */ if (mu->mu_datasize > 0) { if (mu->mu_datasize > MAXPHYS) Error ---> return (EINVAL); if (((kbuf = malloc(mu->mu_datasize, M_DEVBUF, M_WAITOK)) == NULL) || (error = copyin(mu->mu_buf, kbuf, mu->mu_datasize))) goto out; --------------------------------------------------------- [BUG] I think this is a bug. if command is null, it still fails out, and there is no other pointer to mc. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/mlx/mlx.c:1467:mlx_enquire:ERROR:LEAK:1467:1512: pointer=mc from RO=mlx_alloccmd(-1) [s=6,pop=8,pr=0.57] [rank=med] leaked! [z=0.6] [success=2] debug_called(1); /* get ourselves a command buffer */ error = 1; result = NULL; Start ---> if ((mc = mlx_alloccmd(sc)) == NULL) ... DELETED 39 lines ... /* we got an error, and we allocated a result */ if ((error != 0) && (result != NULL)) { free(result, M_DEVBUF); result = NULL; } Error ---> return(result); } --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/usb/umass.c:2123:umass_cam_rescan:ERROR:LEAK:2123:2135: pointer=ccb from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=0.4] [success=5][passed through 1 nros][NCO=memset(0), s=3, pop=3, pr=0.43] Static void umass_cam_rescan(void *addr) { struct umass_softc *sc = (struct umass_softc *) addr; struct cam_path *path; Start ---> union ccb *ccb = malloc(sizeof(union ccb), M_USBDEV, M_WAITOK); memset(ccb, 0, sizeof(union ccb)); DPRINTF(UDMASS_SCSI, ("scbus%d: scanning for %s:%d:%d:%d\n", cam_sim_path(sc->umass_sim), USBDEVNAME(sc->sc_dev), cam_sim_path(sc->umass_sim), USBDEVUNIT(sc->sc_dev), CAM_LUN_WILDCARD)); if (xpt_create_path(&path, xpt_periph, cam_sim_path(sc->umass_sim), CAM_TARGET_WILDCARD, CAM_LUN_WILDCARD) != CAM_REQ_CMP) Error ---> return; xpt_setup_ccb(&ccb->ccb_h, path, 5/*priority (low)*/); ccb->ccb_h.func_code = XPT_SCAN_BUS; --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/usb/ukbd.c:525:ukbd_init:ERROR:LEAK:525:562: pointer=fkeymap from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=0.3] [success=9][passed through 2 nros][NCO=bcopy(1), s=61, pop=61, pr=1.00][NCO=kbd_set_maps(3), s=2, pop=2, pr=0.31] return ENOMEM; bzero(kbd, sizeof(*kbd)); state = malloc(sizeof(*state), M_DEVBUF, M_NOWAIT); keymap = malloc(sizeof(key_map), M_DEVBUF, M_NOWAIT); accmap = malloc(sizeof(accent_map), M_DEVBUF, M_NOWAIT); Start ---> fkeymap = malloc(sizeof(fkey_tab), M_DEVBUF, M_NOWAIT); ... DELETED 31 lines ... imin(fkeymap_size*sizeof(fkeymap[0]), sizeof(fkey_tab))); kbd_set_maps(kbd, keymap, accmap, fkeymap, fkeymap_size); kbd->kb_data = (void *)state; if (probe_keyboard(uaa, flags)) Error ---> return ENXIO; else KBD_FOUND_DEVICE(kbd); ukbd_clear_state(kbd); --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/usb/ukbd.c:524:ukbd_init:ERROR:LEAK:524:562: pointer=accmap from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=0.3] [success=9][passed through 2 nros][NCO=bcopy(1), s=61, pop=61, pr=1.00][NCO=kbd_set_maps(2), s=2, pop=2, pr=0.31] if (kbd == NULL) return ENOMEM; bzero(kbd, sizeof(*kbd)); state = malloc(sizeof(*state), M_DEVBUF, M_NOWAIT); keymap = malloc(sizeof(key_map), M_DEVBUF, M_NOWAIT); Start ---> accmap = malloc(sizeof(accent_map), M_DEVBUF, M_NOWAIT); ... DELETED 32 lines ... imin(fkeymap_size*sizeof(fkeymap[0]), sizeof(fkey_tab))); kbd_set_maps(kbd, keymap, accmap, fkeymap, fkeymap_size); kbd->kb_data = (void *)state; if (probe_keyboard(uaa, flags)) Error ---> return ENXIO; else KBD_FOUND_DEVICE(kbd); ukbd_clear_state(kbd); --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/usb/ukbd.c:523:ukbd_init:ERROR:LEAK:523:562: pointer=keymap from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=0.3] [success=9][passed through 2 nros][NCO=bcopy(1), s=61, pop=61, pr=1.00][NCO=kbd_set_maps(1), s=2, pop=2, pr=0.31] *kbdp = kbd = malloc(sizeof(*kbd), M_DEVBUF, M_NOWAIT); if (kbd == NULL) return ENOMEM; bzero(kbd, sizeof(*kbd)); state = malloc(sizeof(*state), M_DEVBUF, M_NOWAIT); Start ---> keymap = malloc(sizeof(key_map), M_DEVBUF, M_NOWAIT); ... DELETED 33 lines ... imin(fkeymap_size*sizeof(fkeymap[0]), sizeof(fkey_tab))); kbd_set_maps(kbd, keymap, accmap, fkeymap, fkeymap_size); kbd->kb_data = (void *)state; if (probe_keyboard(uaa, flags)) Error ---> return ENXIO; else KBD_FOUND_DEVICE(kbd); ukbd_clear_state(kbd); --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/usb/ukbd.c:525:ukbd_init:ERROR:LEAK:525:581: pointer=fkeymap from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=0.3] [success=9][passed through 2 nros][NCO=bcopy(1), s=61, pop=61, pr=1.00][NCO=kbd_set_maps(3), s=2, pop=2, pr=0.31] return ENOMEM; bzero(kbd, sizeof(*kbd)); state = malloc(sizeof(*state), M_DEVBUF, M_NOWAIT); keymap = malloc(sizeof(key_map), M_DEVBUF, M_NOWAIT); accmap = malloc(sizeof(accent_map), M_DEVBUF, M_NOWAIT); Start ---> fkeymap = malloc(sizeof(fkey_tab), M_DEVBUF, M_NOWAIT); ... DELETED 50 lines ... } if (!KBD_IS_INITIALIZED(kbd) && !(flags & KB_CONF_PROBE_ONLY)) { if (KBD_HAS_DEVICE(kbd) && init_keyboard((ukbd_state_t *)kbd->kb_data, &kbd->kb_type, kbd->kb_flags)) Error ---> return ENXIO; ukbd_ioctl(kbd, KDSETLED, (caddr_t)&(state->ks_state)); KBD_INIT_DONE(kbd); } --------------------------------------------------------- [BUG] i'm not really sure --- m is a param, so if m_pullup returns something different, it gets lost. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../netinet/ip_output.c:1286:in_delayed_cksum:ERROR:LEAK:1286:1289: pointer=m from RO=m_pullup(-1) [s=56,pop=57,pr=1.00] [rank=hard] leaked! [z=1.0] [success=0] * XXX * this shouldn't happen, but if it does, the * correct behavior may be to insert the checksum * in the existing chain instead of rearranging it. */ Start ---> m = m_pullup(m, offset + sizeof(u_short)); } *(u_short *)(m->m_data + offset) = csum; Error ---> } /* * Insert IP options into preformed packet. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 16:01:49 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27A4816A4CE for ; Fri, 16 Jan 2004 16:01:49 -0800 (PST) Received: from agp.stanford.edu (agp.Stanford.EDU [171.67.73.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5665E43D3F for ; Fri, 16 Jan 2004 16:01:46 -0800 (PST) (envelope-from twohey@CS.Stanford.EDU) Received: from [171.64.66.201] (helo=Xenon.Stanford.EDU) by agp.stanford.edu with esmtp (Exim 4.22) id 1AhduM-0001V0-GD for freebsd-hackers@freebsd.org; Fri, 16 Jan 2004 16:01:46 -0800 Received: from xenon.stanford.edu ([171.64.66.201]) by Xenon.Stanford.EDU with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.20) id 1AhduL-0000K4-W1 for freebsd-hackers@freebsd.org; Fri, 16 Jan 2004 16:01:46 -0800 Date: Fri, 16 Jan 2004 16:01:31 -0800 (PST) From: Paul Twohey To: freebsd-hackers@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scan-Signature: a0064e702aa09b52bc21b2ed999c3a2c X-Mailman-Approved-At: Fri, 16 Jan 2004 16:42:08 -0800 Subject: [CHECKER] bugs in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2004 00:01:49 -0000 Hi, I'm with the Stanford Metacompilation research group. We have a suite of checkers that find bugs at compile time and we've had quite a bit of success checking the Linux kernel code for errors. Since our checkers can emit false alarms we filter the reports before we give them to the kernel developers. While some false alarms slip past us to the developers, our limited knowledge of the kernel allows us to recognize most of them. We are currently trying to extend our checker to automatically find functions which allocate resources and to make sure those resources are properly disposed of. Enclosed is a list of potential bugs in FreeBSD where a value is returned from a function (like malloc) that should be owned by the caller and the caller does not properly dispose of the value with the appropriate disposal routine (like free). Confirmation of these reports would be appreciated. Thanks Paul Twohey --------------------------------------------------------- [BUG] they do error checking at the end, so lose config. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/ata/ata-raid.c:1222:ar_highpoint_write_conf:ERROR:LEAK:1222:1222: pointer=config from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=6] microtime(×tamp); rdp->magic_0 = timestamp.tv_sec + 2; rdp->magic_1 = timestamp.tv_sec; for (disk = 0; disk < rdp->total_disks; disk++) { Error ---> if (!(config = (struct highpoint_raid_conf *) malloc(sizeof(struct highpoint_raid_conf), M_AR, M_NOWAIT | M_ZERO))) { printf("ar%d: Highpoint write conf failed\n", rdp->lun); --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/ppbus/vpo.c:187:vpo_cam_rescan:ERROR:LEAK:187:192: pointer=ccb from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=4] static void vpo_cam_rescan(struct vpo_data *vpo) { struct cam_path *path; Start ---> union ccb *ccb = malloc(sizeof(union ccb), M_TEMP, M_WAITOK | M_ZERO); if (xpt_create_path(&path, xpt_periph, cam_sim_path(vpo->sim), 0, 0) != CAM_REQ_CMP) { /* A failure is benign as the user can do a manual rescan */ Error ---> return; } xpt_setup_ccb(&ccb->ccb_h, path, 5/*priority (low)*/); --------------------------------------------------------- [BUG] though we should demote things that are not locals. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/ips/ips.c:148:ips_add_waiting_command:ERROR:LEAK:148:154: pointer=waiter from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=5] ips_command_t *command; ips_wait_list_t *waiter; unsigned long memflags = 0; if(IPS_NOWAIT_FLAG & flags) memflags = M_NOWAIT; Start ---> waiter = malloc(sizeof(ips_wait_list_t), M_DEVBUF, memflags); if(!waiter) return ENOMEM; mask = splbio(); if(sc->state & IPS_OFFLINE){ splx(mask); Error ---> return EIO; } command = SLIST_FIRST(&sc->free_cmd_list); if(command && !(sc->state & IPS_TIMEOUT)){ --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/sio/sio.c:497:sioprobe:ERROR:LEAK:497:504: pointer=port from RO=bus_alloc_resource(-1) [s=65,pop=65,pr=1.00] [rank=med] leaked! [z=1.0] [success=3] u_int flags = device_get_flags(dev); int rid; struct resource *port; rid = xrid; Start ---> port = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, 0, ~0, IO_COMSIZE, RF_ACTIVE); if (!port) return (ENXIO); com = malloc(sizeof(*com), M_DEVBUF, M_NOWAIT | M_ZERO); if (com == NULL) Error ---> return (ENOMEM); device_set_softc(dev, com); com->bst = rman_get_bustag(port); com->bsh = rman_get_bushandle(port); --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/mly/mly.c:2023:mly_cam_rescan_btl:ERROR:LEAK:2023:2031: pointer=ccb from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=4] { union ccb *ccb; debug_called(1); Start ---> if ((ccb = malloc(sizeof(union ccb), M_TEMP, M_WAITOK | M_ZERO)) == NULL) { mly_printf(sc, "rescan failed (can't allocate CCB)\n"); return; } if (xpt_create_path(&sc->mly_cam_path, xpt_periph, cam_sim_path(sc->mly_cam_sim[bus]), target, 0) != CAM_REQ_CMP) { mly_printf(sc, "rescan failed (can't create path)\n"); Error ---> return; } xpt_setup_ccb(&ccb->ccb_h, sc->mly_cam_path, 5/*priority (low)*/); ccb->ccb_h.func_code = XPT_SCAN_LUN; --------------------------------------------------------- [BUG] inferred bcopy. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../cam/scsi/scsi_low.c:966:scsi_low_rescan_bus_cam:ERROR:LEAK:966:974: pointer=ccb from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=5][passed through 1 nros][NCO=bzero(0), s=85, pop=85, pr=1.00] static void scsi_low_rescan_bus_cam(slp) struct scsi_low_softc *slp; { struct cam_path *path; Start ---> union ccb *ccb = malloc(sizeof(union ccb), M_DEVBUF, M_WAITOK); cam_status status; bzero(ccb, sizeof(union ccb)); status = xpt_create_path(&path, xpt_periph, cam_sim_path(slp->sl_si.sim), -1, 0); if (status != CAM_REQ_CMP) Error ---> return; xpt_setup_ccb(&ccb->ccb_h, path, 5); ccb->ccb_h.func_code = XPT_SCAN_BUS; --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/ciss/ciss.c:2130:ciss_cam_rescan_target:ERROR:LEAK:2130:2138: pointer=ccb from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=4] { union ccb *ccb; debug_called(1); Start ---> if ((ccb = malloc(sizeof(union ccb), M_TEMP, M_WAITOK | M_ZERO)) == NULL) { ciss_printf(sc, "rescan failed (can't allocate CCB)\n"); return; } if (xpt_create_path(&sc->ciss_cam_path, xpt_periph, cam_sim_path(sc->ciss_cam_sim), target, 0) != CAM_REQ_CMP) { ciss_printf(sc, "rescan failed (can't create path)\n"); Error ---> return; } xpt_setup_ccb(&ccb->ccb_h, sc->ciss_cam_path, 5/*priority (low)*/); --------------------------------------------------------- [BUG] i think it got lost. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../kern/uipc_socket.c:1608:soopt_getm:ERROR:LEAK:1608:1617: pointer=m from RO=m_get(-1) [s=46,pop=49,pr=1.00] [rank=med] leaked! [z=1.0] [success=2][passed through 1 nros][NCO=m_clget(0), s=54, pop=54, pr=1.00] sopt_size -= m->m_len; *mp = m; m_prev = m; while (sopt_size) { Start ---> MGET(m, sopt->sopt_td ? M_TRYWAIT : M_DONTWAIT, MT_DATA); if (m == 0) { m_freem(*mp); return ENOBUFS; } if (sopt_size > MLEN) { MCLGET(m, sopt->sopt_td ? M_TRYWAIT : M_DONTWAIT); if ((m->m_flags & M_EXT) == 0) { m_freem(*mp); Error ---> return ENOBUFS; } m->m_len = min(MCLBYTES, sopt_size); } else { --------------------------------------------------------- [BUG] indeed. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../isa/pnp.c:657:pnp_read_bytes:ERROR:LEAK:657:669: pointer=resources from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=7] int space = *spacep; int len = *lenp; if (space == 0) { space = 1024; Start ---> resources = malloc(space, M_TEMP, M_NOWAIT); if (!resources) return ENOMEM; } if (len + amount > space) { int extra = 1024; while (len + amount > space + extra) extra += 1024; newres = malloc(space + extra, M_TEMP, M_NOWAIT); if (!newres) { /* XXX: free resources */ Error ---> return ENOMEM; } bcopy(resources, newres, len); free(resources, M_TEMP); --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/firewire/fwohci.c:1188:fwohci_db_init:ERROR:LEAK:1188:1201: pointer=db_tr from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=5] return; /* allocate DB entries and attach one to each DMA channels */ /* DB entry must start at 16 bytes bounary. */ STAILQ_INIT(&dbch->db_trq); Start ---> db_tr = (struct fwohcidb_tr *) malloc(sizeof(struct fwohcidb_tr) * dbch->ndb, M_FW, M_WAITOK | M_ZERO); if(db_tr == NULL){ printf("fwohci_db_init: malloc(1) failed\n"); return; } #define DB_SIZE(x) (sizeof(struct fwohcidb) * (x)->ndesc) dbch->am = fwdma_malloc_multiseg(&sc->fc, DB_SIZE(dbch), DB_SIZE(dbch), dbch->ndb, BUS_DMA_WAITOK); if (dbch->am == NULL) { printf("fwohci_db_init: fwdma_malloc_multiseg failed\n"); Error ---> return; } /* Attach DB to DMA ch. */ for(idb = 0 ; idb < dbch->ndb ; idb++){ --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/firewire/fwdev.c:579:fw_ioctl:ERROR:LEAK:579:593: pointer=fwb from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=3] } if(bindreq->start.hi > 0xffff ){ err = EINVAL; break; } Start ---> fwb = (struct fw_bind *)malloc(sizeof (struct fw_bind), M_FW, M_NOWAIT); if(fwb == NULL){ err = ENOMEM; break; } fwb->start_hi = bindreq->start.hi; fwb->start_lo = bindreq->start.lo; fwb->addrlen = bindreq->len; fwb->sub = sub; fwb->act_type = FWACT_CH; xfer = fw_xfer_alloc(M_FWXFER); if(xfer == NULL){ err = ENOMEM; Error ---> return err; } xfer->fc = sc->fc; --------------------------------------------------------- [BUG] sure looks like an error, since they free it below. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/an/if_an.c:913:an_rxeof:ERROR:LEAK:913:932: pointer=m from RO=m_gethdr(-1) [s=74,pop=78,pr=1.00] [rank=med] leaked! [z=1.0] [success=2][passed through 1 nros][NCO=m_clget(0), s=54, pop=54, pr=1.00] rx_frame.an_rx_payload_len); } /* dump raw 802.11 packet to bpf and skip ip stack */ BPF_TAP(ifp, bpf_buf, len); } else { Start ---> MGETHDR(m, M_DONTWAIT, MT_DATA); ... DELETED 13 lines ... #ifdef ANCACHE /* Read NIC frame header */ if (an_read_data(sc, id, 0, (caddr_t)&rx_frame, sizeof(rx_frame))) { ifp->if_ierrors++; Error ---> return; } #endif /* Read in the 802_3 frame header */ --------------------------------------------------------- [BUG] actually, i'm not sure if it labelled pnp_get_resource_info correctly. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../isa/pnp.c:657:pnp_read_bytes:ERROR:LEAK:657:678: pointer=resources from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=7] int space = *spacep; int len = *lenp; if (space == 0) { space = 1024; Start ---> resources = malloc(space, M_TEMP, M_NOWAIT); ... DELETED 15 lines ... resources = newres; space += extra; } if (pnp_get_resource_info(resources + len, amount) != amount) Error ---> return EINVAL; len += amount; *resourcesp = resources; --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/dpt/dpt_scsi.c:1542:dpt_attach:ERROR:LEAK:1542:1571: pointer=devq from RO=cam_simq_alloc(-1) [s=21,pop=21,pr=0.99] [rank=med] leaked! [z=1.0] [success=3] int i; /* * Create the device queue for our SIM. */ Start ---> devq = cam_simq_alloc(dpt->max_dccbs); ... DELETED 23 lines ... } if (i > 0) EVENTHANDLER_REGISTER(shutdown_final, dptshutdown, dpt, SHUTDOWN_PRI_DEFAULT); Error ---> return (i); } int --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/iir/iir.c:500:iir_attach:ERROR:LEAK:500:530: pointer=devq from RO=cam_simq_alloc(-1) [s=21,pop=21,pr=0.99] [rank=med] leaked! [z=1.0] [success=3] GDT_DPRINTF(GDT_D_INIT, ("iir_attach()\n")); /* * Create the device queue for our SIM. */ Start ---> devq = cam_simq_alloc(GDT_MAXCMDS); ... DELETED 24 lines ... if (i > 0) EVENTHANDLER_REGISTER(shutdown_final, iir_shutdown, gdt, SHUTDOWN_PRI_DEFAULT); /* iir_watchdog(gdt); */ gdt->sc_state = GDT_NORMAL; Error ---> } static void gdt_eval_mapping(u_int32_t size, int *cyls, int *heads, int *secs) --------------------------------------------------------- [BUG] they lose all sorts of stuff. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/kbd/atkbd.c:361:atkbd_init:ERROR:LEAK:361:392: pointer=fkeymap from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=10] } else if (*kbdp == NULL) { *kbdp = kbd = malloc(sizeof(*kbd), M_DEVBUF, M_NOWAIT | M_ZERO); state = malloc(sizeof(*state), M_DEVBUF, M_NOWAIT | M_ZERO); keymap = malloc(sizeof(key_map), M_DEVBUF, M_NOWAIT); accmap = malloc(sizeof(accent_map), M_DEVBUF, M_NOWAIT); Start ---> fkeymap = malloc(sizeof(fkey_tab), M_DEVBUF, M_NOWAIT); ... DELETED 25 lines ... } if (!KBD_IS_PROBED(kbd)) { state->kbdc = atkbdc_open(data[0]); if (state->kbdc == NULL) Error ---> return ENXIO; kbd_init_struct(kbd, ATKBD_DRIVER_NAME, KB_OTHER, unit, flags, 0, 0); bcopy(&key_map, keymap, sizeof(key_map)); --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/kbd/atkbd.c:360:atkbd_init:ERROR:LEAK:360:392: pointer=accmap from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=10] sizeof(default_fkeytab)/sizeof(default_fkeytab[0]); } else if (*kbdp == NULL) { *kbdp = kbd = malloc(sizeof(*kbd), M_DEVBUF, M_NOWAIT | M_ZERO); state = malloc(sizeof(*state), M_DEVBUF, M_NOWAIT | M_ZERO); keymap = malloc(sizeof(key_map), M_DEVBUF, M_NOWAIT); Start ---> accmap = malloc(sizeof(accent_map), M_DEVBUF, M_NOWAIT); ... DELETED 26 lines ... } if (!KBD_IS_PROBED(kbd)) { state->kbdc = atkbdc_open(data[0]); if (state->kbdc == NULL) Error ---> return ENXIO; kbd_init_struct(kbd, ATKBD_DRIVER_NAME, KB_OTHER, unit, flags, 0, 0); bcopy(&key_map, keymap, sizeof(key_map)); --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/amr/amr_cam.c:143:amr_cam_attach:ERROR:LEAK:143:175: pointer=devq from RO=cam_simq_alloc(-1) [s=21,pop=21,pr=0.99] [rank=med] leaked! [z=1.0] [success=3] /* * Allocate a devq for all our channels combined. This should * allow for the maximum number of SCSI commands we will accept * at one time. */ Start ---> if ((devq = cam_simq_alloc(AMR_MAX_SCSI_CMDS)) == NULL) ... DELETED 26 lines ... } /* * XXX we should scan the config and work out which devices are actually * protected. */ Error ---> return(0); } /******************************************************************************** --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/kbd/atkbd.c:359:atkbd_init:ERROR:LEAK:359:392: pointer=keymap from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=10] fkeymap_size = sizeof(default_fkeytab)/sizeof(default_fkeytab[0]); } else if (*kbdp == NULL) { *kbdp = kbd = malloc(sizeof(*kbd), M_DEVBUF, M_NOWAIT | M_ZERO); state = malloc(sizeof(*state), M_DEVBUF, M_NOWAIT | M_ZERO); Start ---> keymap = malloc(sizeof(key_map), M_DEVBUF, M_NOWAIT); ... DELETED 27 lines ... } if (!KBD_IS_PROBED(kbd)) { state->kbdc = atkbdc_open(data[0]); if (state->kbdc == NULL) Error ---> return ENXIO; kbd_init_struct(kbd, ATKBD_DRIVER_NAME, KB_OTHER, unit, flags, 0, 0); bcopy(&key_map, keymap, sizeof(key_map)); --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/kbd/atkbd.c:358:atkbd_init:ERROR:LEAK:358:392: pointer=state from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=8] fkeymap = default_fkeytab; fkeymap_size = sizeof(default_fkeytab)/sizeof(default_fkeytab[0]); } else if (*kbdp == NULL) { *kbdp = kbd = malloc(sizeof(*kbd), M_DEVBUF, M_NOWAIT | M_ZERO); Start ---> state = malloc(sizeof(*state), M_DEVBUF, M_NOWAIT | M_ZERO); ... DELETED 28 lines ... } if (!KBD_IS_PROBED(kbd)) { state->kbdc = atkbdc_open(data[0]); if (state->kbdc == NULL) Error ---> return ENXIO; kbd_init_struct(kbd, ATKBD_DRIVER_NAME, KB_OTHER, unit, flags, 0, 0); bcopy(&key_map, keymap, sizeof(key_map)); --------------------------------------------------------- [BUG] probably minor: it can happen if uio_resid == 0 (the error checking just flags if its < 0). /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../net/if_tun.c:719:tunwrite:ERROR:LEAK:719:761: pointer=m from RO=m_gethdr(-1) [s=74,pop=78,pr=1.00] [rank=med] leaked! [z=1.0] [success=3] return (EIO); } tlen = uio->uio_resid; /* get a header mbuf */ Start ---> MGETHDR(m, M_DONTWAIT, MT_DATA); ... DELETED 36 lines ... * Conveniently, we already have a 4-byte address * family prepended to our packet ! * Inconveniently, it's in the wrong byte order ! */ if ((top = m_pullup(top, sizeof(family))) == NULL) Error ---> return (ENOBUFS); *mtod(top, u_int32_t *) = ntohl(*mtod(top, u_int32_t *)); BPF_MTAP(ifp, top); --------------------------------------------------------- [BUG] i'm getting less sure about these type of errors, but it sure looks like a bug. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../kern/uipc_mbuf.c:656:m_devget:ERROR:LEAK:656:700: pointer=m from RO=m_gethdr(-1) [s=74,pop=78,pr=1.00] [rank=med] leaked! [z=1.0] [success=6] int len; if (off < 0 || off > MHLEN) return (NULL); Start ---> MGETHDR(m, M_DONTWAIT, MT_DATA); ... DELETED 38 lines ... buf += len; *mp = m; mp = &m->m_next; totlen -= len; } Error ---> return (top); } /* --------------------------------------------------------- [BUG] there are similar errors in dev/kbd/atkbd.c /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/usb/ukbd.c:522:ukbd_init:ERROR:LEAK:522:581: pointer=state from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=8] } else if (*kbdp == NULL) { *kbdp = kbd = malloc(sizeof(*kbd), M_DEVBUF, M_NOWAIT); if (kbd == NULL) return ENOMEM; bzero(kbd, sizeof(*kbd)); Start ---> state = malloc(sizeof(*state), M_DEVBUF, M_NOWAIT); ... DELETED 53 lines ... } if (!KBD_IS_INITIALIZED(kbd) && !(flags & KB_CONF_PROBE_ONLY)) { if (KBD_HAS_DEVICE(kbd) && init_keyboard((ukbd_state_t *)kbd->kb_data, &kbd->kb_type, kbd->kb_flags)) Error ---> return ENXIO; ukbd_ioctl(kbd, KDSETLED, (caddr_t)&(state->ks_state)); KBD_INIT_DONE(kbd); } --------------------------------------------------------- [BUG] does lose on default. "impossible" though. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/ata/ata-raid.c:704:arstrategy:ERROR:LEAK:704:829: pointer=buf1 from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0] [success=15] bp->bio_error = EIO; biodone(bp); return; } Start ---> buf1 = malloc(sizeof(struct ar_buf), M_AR, M_NOWAIT | M_ZERO); ... DELETED 119 lines ... default: printf("ar%d: unknown array type in arstrategy\n", rdp->lun); } } Error ---> } static void ar_done(struct bio *bp) --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/pst/pst-iop.c:341:iop_get_util_params:ERROR:LEAK:341:347: pointer=param from RO=contigmalloc(-1) [s=4,pop=4,pr=0.57] [rank=med] leaked! [z=0.6] [success=3] struct i2o_util_get_param_message *msg; struct i2o_get_param_operation *param; struct i2o_get_param_reply *reply; int mfa; Start ---> if (!(param = contigmalloc(PAGE_SIZE, M_PSTIOP, M_NOWAIT | M_ZERO, 0x00010000, 0xFFFFFFFF, PAGE_SIZE, 0))) return NULL; if (!(reply = contigmalloc(PAGE_SIZE, M_PSTIOP, M_NOWAIT | M_ZERO, 0x00010000, 0xFFFFFFFF, PAGE_SIZE, 0))) Error ---> return NULL; mfa = iop_get_mfa(sc); msg = (struct i2o_util_get_param_message *)(sc->ibase + mfa); --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/mlx/mlx.c:1870:mlx_user_command:ERROR:LEAK:1870:1878: pointer=mc from RO=mlx_alloccmd(-1) [s=6,pop=8,pr=0.57] [rank=med] leaked! [z=0.6] [success=2] mc = NULL; dcdb = NULL; error = ENOMEM; /* get ourselves a command and copy in from user space */ Start ---> if ((mc = mlx_alloccmd(sc)) == NULL) goto out; bcopy(mu->mu_command, mc->mc_mailbox, sizeof(mc->mc_mailbox)); debug(0, "got command buffer"); /* if we need a buffer for data transfer, allocate one and copy in its initial contents */ if (mu->mu_datasize > 0) { if (mu->mu_datasize > MAXPHYS) Error ---> return (EINVAL); if (((kbuf = malloc(mu->mu_datasize, M_DEVBUF, M_WAITOK)) == NULL) || (error = copyin(mu->mu_buf, kbuf, mu->mu_datasize))) goto out; --------------------------------------------------------- [BUG] I think this is a bug. if command is null, it still fails out, and there is no other pointer to mc. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/mlx/mlx.c:1467:mlx_enquire:ERROR:LEAK:1467:1512: pointer=mc from RO=mlx_alloccmd(-1) [s=6,pop=8,pr=0.57] [rank=med] leaked! [z=0.6] [success=2] debug_called(1); /* get ourselves a command buffer */ error = 1; result = NULL; Start ---> if ((mc = mlx_alloccmd(sc)) == NULL) ... DELETED 39 lines ... /* we got an error, and we allocated a result */ if ((error != 0) && (result != NULL)) { free(result, M_DEVBUF); result = NULL; } Error ---> return(result); } --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/usb/umass.c:2123:umass_cam_rescan:ERROR:LEAK:2123:2135: pointer=ccb from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=0.4] [success=5][passed through 1 nros][NCO=memset(0), s=3, pop=3, pr=0.43] Static void umass_cam_rescan(void *addr) { struct umass_softc *sc = (struct umass_softc *) addr; struct cam_path *path; Start ---> union ccb *ccb = malloc(sizeof(union ccb), M_USBDEV, M_WAITOK); memset(ccb, 0, sizeof(union ccb)); DPRINTF(UDMASS_SCSI, ("scbus%d: scanning for %s:%d:%d:%d\n", cam_sim_path(sc->umass_sim), USBDEVNAME(sc->sc_dev), cam_sim_path(sc->umass_sim), USBDEVUNIT(sc->sc_dev), CAM_LUN_WILDCARD)); if (xpt_create_path(&path, xpt_periph, cam_sim_path(sc->umass_sim), CAM_TARGET_WILDCARD, CAM_LUN_WILDCARD) != CAM_REQ_CMP) Error ---> return; xpt_setup_ccb(&ccb->ccb_h, path, 5/*priority (low)*/); ccb->ccb_h.func_code = XPT_SCAN_BUS; --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/usb/ukbd.c:525:ukbd_init:ERROR:LEAK:525:562: pointer=fkeymap from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=0.3] [success=9][passed through 2 nros][NCO=bcopy(1), s=61, pop=61, pr=1.00][NCO=kbd_set_maps(3), s=2, pop=2, pr=0.31] return ENOMEM; bzero(kbd, sizeof(*kbd)); state = malloc(sizeof(*state), M_DEVBUF, M_NOWAIT); keymap = malloc(sizeof(key_map), M_DEVBUF, M_NOWAIT); accmap = malloc(sizeof(accent_map), M_DEVBUF, M_NOWAIT); Start ---> fkeymap = malloc(sizeof(fkey_tab), M_DEVBUF, M_NOWAIT); ... DELETED 31 lines ... imin(fkeymap_size*sizeof(fkeymap[0]), sizeof(fkey_tab))); kbd_set_maps(kbd, keymap, accmap, fkeymap, fkeymap_size); kbd->kb_data = (void *)state; if (probe_keyboard(uaa, flags)) Error ---> return ENXIO; else KBD_FOUND_DEVICE(kbd); ukbd_clear_state(kbd); --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/usb/ukbd.c:524:ukbd_init:ERROR:LEAK:524:562: pointer=accmap from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=0.3] [success=9][passed through 2 nros][NCO=bcopy(1), s=61, pop=61, pr=1.00][NCO=kbd_set_maps(2), s=2, pop=2, pr=0.31] if (kbd == NULL) return ENOMEM; bzero(kbd, sizeof(*kbd)); state = malloc(sizeof(*state), M_DEVBUF, M_NOWAIT); keymap = malloc(sizeof(key_map), M_DEVBUF, M_NOWAIT); Start ---> accmap = malloc(sizeof(accent_map), M_DEVBUF, M_NOWAIT); ... DELETED 32 lines ... imin(fkeymap_size*sizeof(fkeymap[0]), sizeof(fkey_tab))); kbd_set_maps(kbd, keymap, accmap, fkeymap, fkeymap_size); kbd->kb_data = (void *)state; if (probe_keyboard(uaa, flags)) Error ---> return ENXIO; else KBD_FOUND_DEVICE(kbd); ukbd_clear_state(kbd); --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/usb/ukbd.c:523:ukbd_init:ERROR:LEAK:523:562: pointer=keymap from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=0.3] [success=9][passed through 2 nros][NCO=bcopy(1), s=61, pop=61, pr=1.00][NCO=kbd_set_maps(1), s=2, pop=2, pr=0.31] *kbdp = kbd = malloc(sizeof(*kbd), M_DEVBUF, M_NOWAIT); if (kbd == NULL) return ENOMEM; bzero(kbd, sizeof(*kbd)); state = malloc(sizeof(*state), M_DEVBUF, M_NOWAIT); Start ---> keymap = malloc(sizeof(key_map), M_DEVBUF, M_NOWAIT); ... DELETED 33 lines ... imin(fkeymap_size*sizeof(fkeymap[0]), sizeof(fkey_tab))); kbd_set_maps(kbd, keymap, accmap, fkeymap, fkeymap_size); kbd->kb_data = (void *)state; if (probe_keyboard(uaa, flags)) Error ---> return ENXIO; else KBD_FOUND_DEVICE(kbd); ukbd_clear_state(kbd); --------------------------------------------------------- [BUG] /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/usb/ukbd.c:525:ukbd_init:ERROR:LEAK:525:581: pointer=fkeymap from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=0.3] [success=9][passed through 2 nros][NCO=bcopy(1), s=61, pop=61, pr=1.00][NCO=kbd_set_maps(3), s=2, pop=2, pr=0.31] return ENOMEM; bzero(kbd, sizeof(*kbd)); state = malloc(sizeof(*state), M_DEVBUF, M_NOWAIT); keymap = malloc(sizeof(key_map), M_DEVBUF, M_NOWAIT); accmap = malloc(sizeof(accent_map), M_DEVBUF, M_NOWAIT); Start ---> fkeymap = malloc(sizeof(fkey_tab), M_DEVBUF, M_NOWAIT); ... DELETED 50 lines ... } if (!KBD_IS_INITIALIZED(kbd) && !(flags & KB_CONF_PROBE_ONLY)) { if (KBD_HAS_DEVICE(kbd) && init_keyboard((ukbd_state_t *)kbd->kb_data, &kbd->kb_type, kbd->kb_flags)) Error ---> return ENXIO; ukbd_ioctl(kbd, KDSETLED, (caddr_t)&(state->ks_state)); KBD_INIT_DONE(kbd); } --------------------------------------------------------- [BUG] i'm not really sure --- m is a param, so if m_pullup returns something different, it gets lost. /u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../netinet/ip_output.c:1286:in_delayed_cksum:ERROR:LEAK:1286:1289: pointer=m from RO=m_pullup(-1) [s=56,pop=57,pr=1.00] [rank=hard] leaked! [z=1.0] [success=0] * XXX * this shouldn't happen, but if it does, the * correct behavior may be to insert the checksum * in the existing chain instead of rearranging it. */ Start ---> m = m_pullup(m, offset + sizeof(u_short)); } *(u_short *)(m->m_data + offset) = csum; Error ---> } /* * Insert IP options into preformed packet. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 17:23:04 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EBCA16A4CE for ; Fri, 16 Jan 2004 17:23:04 -0800 (PST) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C169743D5D for ; Fri, 16 Jan 2004 17:23:02 -0800 (PST) (envelope-from kientzle@acm.org) Received: from acm.org ([66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id i0H1N2kX086130 for ; Fri, 16 Jan 2004 17:23:02 -0800 (PST) (envelope-from kientzle@acm.org) Message-ID: <40088E75.5080908@acm.org> Date: Fri, 16 Jan 2004 17:23:01 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'freebsd-hackers@freebsd.org'" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: __restrict__ vs __restrict ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2004 01:23:04 -0000 I've been enabling a LOT of gcc warnings recently in the process of linting some code I'm writing. In the process, I stumbled across the following curiosity: > cat test.c #include > gcc -std=c99 -ansi test.c In file included from test.c:1: /usr/include/stdio.h:220: conflicting types for `restrict' /usr/include/stdio.h:220: previous declaration of `restrict' /usr/include/stdio.h:221: conflicting types for `restrict' /usr/include/stdio.h:221: previous declaration of `restrict' /usr/include/stdio.h:222: redefinition of `restrict' /usr/include/stdio.h:222: `restrict' previously declared here /usr/include/stdio.h:223: conflicting types for `restrict' [ .... many similar lines omitted .... ] If I change all "__restrict" in stdio.h to "__restrict__", these warnings disappear. Question: Does anyone know the difference between __restrict and __restrict__? Should we be using the latter in our system headers? Tim From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 17:57:49 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBD4B16A4CE; Fri, 16 Jan 2004 17:57:48 -0800 (PST) Received: from phantom.cris.net (phantom.cris.net [212.110.130.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id D458F43D1D; Fri, 16 Jan 2004 17:57:42 -0800 (PST) (envelope-from ru@FreeBSD.org.ua) Received: from phantom.cris.net (ru@localhost [127.0.0.1]) by phantom.cris.net (8.12.10/8.12.10) with ESMTP id i0H1wCjm011273; Sat, 17 Jan 2004 03:58:12 +0200 (EET) (envelope-from ru@FreeBSD.org.ua) Received: (from ru@localhost) by phantom.cris.net (8.12.10/8.12.10/Submit) id i0H1wAmg011268; Sat, 17 Jan 2004 03:58:10 +0200 (EET) (envelope-from ru) Date: Sat, 17 Jan 2004 03:58:10 +0200 From: Ruslan Ermilov To: Tim Kientzle Message-ID: <20040117015809.GJ9410@FreeBSD.org.ua> References: <40088E75.5080908@acm.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aznLbwQ42o7LEaqN" Content-Disposition: inline In-Reply-To: <40088E75.5080908@acm.org> User-Agent: Mutt/1.5.5.1i cc: hackers@FreeBSD.org cc: Garrett Wollman cc: David O'Brien cc: Dag-Erling Smorgrav cc: Mike Barcroft Subject: Re: __restrict__ vs __restrict ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2004 01:57:49 -0000 --aznLbwQ42o7LEaqN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 16, 2004 at 05:23:01PM -0800, Tim Kientzle wrote: > I've been enabling a LOT of gcc warnings recently > in the process of linting some code I'm writing. > In the process, I stumbled across the following > curiosity: >=20 > > cat test.c > #include > > gcc -std=3Dc99 -ansi test.c > In file included from test.c:1: > /usr/include/stdio.h:220: conflicting types for `restrict' > /usr/include/stdio.h:220: previous declaration of `restrict' > /usr/include/stdio.h:221: conflicting types for `restrict' > /usr/include/stdio.h:221: previous declaration of `restrict' > /usr/include/stdio.h:222: redefinition of `restrict' > /usr/include/stdio.h:222: `restrict' previously declared here > /usr/include/stdio.h:223: conflicting types for `restrict' > [ .... many similar lines omitted .... ] >=20 > If I change all "__restrict" in stdio.h to "__restrict__", > these warnings disappear. >=20 > Question: Does anyone know the difference between > __restrict and __restrict__? >=20 __restrict__ is the gcc(1)-only feature. From gcc.info: : `-std=3D' : Determine the language standard. This option is currently only : supported when compiling C or C++. A value for this option must be : provided; possible values are : [...] : Even when this option is not specified, you can still use some of : the features of newer standards in so far as they do not conflict : with previous C standards. For example, you may use : `__restrict__' even when `-std=3Dc99' is not specified. : [...] : As with gcc, g++ understands the C99 feature of restricted pointers, : specified with the `__restrict__', or `__restrict' type qualifier. : Because you cannot compile C++ by specifying the `-std=3Dc99' language : flag, `restrict' is not a keyword in C++. __restrict is defined in , it's the FreeBSD feature. > Should we be using the latter in our system headers? >=20 No, we should be using the __restrict as coded. But I wonder why we can't just use "restrict", please see below. Note that __restrict is a no-op these days because we don't compile our C code by default with -std=3Dc99. I'm not sure why we can't replace #if !(__GNUC__ =3D=3D 2 && __GNUC_MINOR__ =3D=3D 95) #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 199901 #define __restrict #else #define __restrict restrict #endif #endif with #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 199901 #define restrict #endif and just use "restrict" everywhere. Also similarly I'm not aware of the status of the CSTD feature for share/mk that was backed out. (8 makefiles in src/ still have CSTD.) Cheers, --=20 Ruslan Ermilov FreeBSD committer ru@FreeBSD.org --aznLbwQ42o7LEaqN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFACJaxUkv4P6juNwoRAs8QAJ4+VXlFcR/iCq0xuCb6dvyABDbLjQCcCP7F IJw2dMYDsvDokd5XAwek8Qw= =/VgN -----END PGP SIGNATURE----- --aznLbwQ42o7LEaqN-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 20:03:08 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AD0116A4CE; Fri, 16 Jan 2004 20:03:08 -0800 (PST) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B49943D69; Fri, 16 Jan 2004 20:03:07 -0800 (PST) (envelope-from kientzle@acm.org) Received: from acm.org ([66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id i0H436kX086811; Fri, 16 Jan 2004 20:03:07 -0800 (PST) (envelope-from kientzle@acm.org) Message-ID: <4008B3F9.6010903@acm.org> Date: Fri, 16 Jan 2004 20:03:05 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <40088E75.5080908@acm.org> <20040117015809.GJ9410@FreeBSD.org.ua> In-Reply-To: <20040117015809.GJ9410@FreeBSD.org.ua> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: hackers@FreeBSD.org cc: Garrett Wollman cc: David O'Brien cc: Dag-Erling Smorgrav cc: Mike Barcroft Subject: Re: __restrict__ vs __restrict ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2004 04:03:08 -0000 Ruslan Ermilov wrote: > On Fri, Jan 16, 2004 at 05:23:01PM -0800, Tim Kientzle wrote: > >>Question: Does anyone know the difference between >>__restrict and __restrict__? > > __restrict__ is the gcc(1)-only feature. > __restrict is defined in , it's the FreeBSD feature. A-ha! That's the part I had missed. After a few experiments with gcc -dM -E, I've convinced myself that this is just another GCC bug. Basically, -std=c99 -ansi seems to be a very bad compination, as -std=c99 defines __STDC_VERSION__ to be 199901L and -ansi then turns off compiler support for c99 features. Ugh. >>Should we be using the latter in our system headers? > > No, we should be using the __restrict as coded. But I wonder why > we can't just use "restrict"... Because that would really mess up any user program that used 'restrict' as a variable or function name. I think the current approach is the best. Thanks for the clarification. I'll go crawl back under my nice, comfortable rock now. Tim From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 20:09:08 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C297F16A4CE for ; Fri, 16 Jan 2004 20:09:08 -0800 (PST) Received: from ftp.bjpu.edu.cn (ftp.bjpu.edu.cn [202.112.78.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1862343D1F for ; Fri, 16 Jan 2004 20:09:07 -0800 (PST) (envelope-from delphij@frontfree.net) Received: by ftp.bjpu.edu.cn (Postfix, from userid 426) id 9BF4152D4; Sat, 17 Jan 2004 12:09:04 +0800 (CST) Received: from beastie.frontfree.net (beastie.frontfree.net [218.107.145.7]) by ftp.bjpu.edu.cn (Postfix) with ESMTP id 636E75299 for ; Sat, 17 Jan 2004 12:09:04 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 426) id 0CE9111675; Sat, 17 Jan 2004 12:09:03 +0800 (CST) Received: from phantasm205 (unknown [61.49.185.93]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by beastie.frontfree.net (Postfix) with ESMTP id 08A3A11421; Sat, 17 Jan 2004 12:09:02 +0800 (CST) Message-ID: <03f801c3dcaf$aa099c90$0401a8c0@phantasm205> From: "Xin LI" To: "Paul Twohey" , References: Date: Sat, 17 Jan 2004 12:09:10 +0800 Organization: Phantasm Studio 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 6.00.3790.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Subject: Re: [CHECKER] bugs in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2004 04:09:08 -0000 Hello, The tool is amazing :) I am very interested in how does it work, is there any paper published on this topic? Thanks in advance! Xin LI, Beijing University of Technology ----- Original Message ----- From: "Paul Twohey" To: Sent: Saturday, January 17, 2004 8:01 AM Subject: [CHECKER] bugs in FreeBSD > Hi, > > I'm with the Stanford Metacompilation research group. We have a suite of > checkers that find bugs at compile time and we've had quite a bit of > success checking the Linux kernel code for errors. Since our checkers can > emit false alarms we filter the reports before we give them to the kernel > developers. While some false alarms slip past us to the developers, our > limited knowledge of the kernel allows us to recognize most of them. > > We are currently trying to extend our checker to automatically find > functions which allocate resources and to make sure those resources are > properly disposed of. > > Enclosed is a list of potential bugs in FreeBSD where a value is returned > from a function (like malloc) that should be owned by the caller and the > caller does not properly dispose of the value with the appropriate > disposal routine (like free). From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 21:00:08 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08BE916A4CF for ; Fri, 16 Jan 2004 21:00:07 -0800 (PST) Received: from mx01.netapp.com (mx01.netapp.com [198.95.226.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAD9443D60 for ; Fri, 16 Jan 2004 20:59:57 -0800 (PST) (envelope-from kmacy@netapp.com) Received: from frejya.corp.netapp.com (frejya [10.57.157.119]) i0H4xuKw021737; Fri, 16 Jan 2004 20:59:56 -0800 (PST) Received: from cranford (cranford-fe.eng.netapp.com [10.56.10.106]) i0H4xups016749; Fri, 16 Jan 2004 20:59:56 -0800 (PST) Date: Fri, 16 Jan 2004 20:59:56 -0800 (PST) From: Kip Macy X-Sender: kmacy@cranford-fe.eng.netapp.com To: Xin LI In-Reply-To: <03f801c3dcaf$aa099c90$0401a8c0@phantasm205> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: [CHECKER] bugs in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2004 05:00:08 -0000 Dawson is the man. http://www.stanford.edu/~engler/ ================================================================ If I have not seen as far as others, it is because I have been standing in the footprints of giants. -- from Usenet On Fri, 16 Jan 2004, Xin LI wrote: > Hello, > > The tool is amazing :) > > I am very interested in how does it work, is there any paper published on > this topic? > Thanks in advance! > > Xin LI, > Beijing University of Technology > > ----- Original Message ----- > From: "Paul Twohey" > To: > Sent: Saturday, January 17, 2004 8:01 AM > Subject: [CHECKER] bugs in FreeBSD > > > > Hi, > > > > I'm with the Stanford Metacompilation research group. We have a suite of > > checkers that find bugs at compile time and we've had quite a bit of > > success checking the Linux kernel code for errors. Since our checkers can > > emit false alarms we filter the reports before we give them to the kernel > > developers. While some false alarms slip past us to the developers, our > > limited knowledge of the kernel allows us to recognize most of them. > > > > We are currently trying to extend our checker to automatically find > > functions which allocate resources and to make sure those resources are > > properly disposed of. > > > > Enclosed is a list of potential bugs in FreeBSD where a value is returned > > from a function (like malloc) that should be owned by the caller and the > > caller does not properly dispose of the value with the appropriate > > disposal routine (like free). > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 17 09:19:39 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3362516A4CE; Sat, 17 Jan 2004 09:19:39 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id E446F43D1F; Sat, 17 Jan 2004 09:19:36 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.9) with ESMTP id i0HHJTip038071; Sat, 17 Jan 2004 09:19:29 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.10/8.12.10/Submit) id i0HHJSgE038070; Sat, 17 Jan 2004 09:19:28 -0800 (PST) (envelope-from obrien) Date: Sat, 17 Jan 2004 09:19:28 -0800 From: "David O'Brien" To: Tim Kientzle Message-ID: <20040117171928.GB38009@dragon.nuxi.com> Mail-Followup-To: David O'Brien , Tim Kientzle , Ruslan Ermilov , Mike Barcroft , Garrett Wollman , Dag-Erling Smorgrav , hackers@FreeBSD.org References: <40088E75.5080908@acm.org> <20040117015809.GJ9410@FreeBSD.org.ua> <4008B3F9.6010903@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4008B3F9.6010903@acm.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: Garrett Wollman cc: hackers@FreeBSD.org cc: Ruslan Ermilov cc: Dag-Erling Smorgrav cc: Mike Barcroft Subject: Re: __restrict__ vs __restrict ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2004 17:19:39 -0000 On Fri, Jan 16, 2004 at 08:03:05PM -0800, Tim Kientzle wrote: > >No, we should be using the __restrict as coded. But I wonder why > >we can't just use "restrict"... > > Because that would really mess up any user program that used > 'restrict' as a variable or function name. I think the > current approach is the best. Such code isn't portable to C99, which is still a goal of ours. I like RU's suggestion, because it is straight C[99] code and not an abstraction. I'll do a 'make world' test and see if we'd have trouble with RU's form. -- -- David (obrien@FreeBSD.org) From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 17 09:32:23 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FCEF16A4CE; Sat, 17 Jan 2004 09:32:23 -0800 (PST) Received: from phantom.cris.net (phantom.cris.net [212.110.130.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C9F943D2D; Sat, 17 Jan 2004 09:32:20 -0800 (PST) (envelope-from ru@FreeBSD.org.ua) Received: from phantom.cris.net (ru@localhost [127.0.0.1]) by phantom.cris.net (8.12.10/8.12.10) with ESMTP id i0HHWujm021909; Sat, 17 Jan 2004 19:32:56 +0200 (EET) (envelope-from ru@FreeBSD.org.ua) Received: (from ru@localhost) by phantom.cris.net (8.12.10/8.12.10/Submit) id i0HHWtJn021904; Sat, 17 Jan 2004 19:32:55 +0200 (EET) (envelope-from ru) Date: Sat, 17 Jan 2004 19:32:55 +0200 From: Ruslan Ermilov To: "David O'Brien" , Tim Kientzle , Mike Barcroft , Garrett Wollman , Dag-Erling Smorgrav , hackers@FreeBSD.org Message-ID: <20040117173255.GB21742@FreeBSD.org.ua> References: <40088E75.5080908@acm.org> <20040117015809.GJ9410@FreeBSD.org.ua> <4008B3F9.6010903@acm.org> <20040117171928.GB38009@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H1spWtNR+x+ondvy" Content-Disposition: inline In-Reply-To: <20040117171928.GB38009@dragon.nuxi.com> User-Agent: Mutt/1.5.5.1i Subject: Re: __restrict__ vs __restrict ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2004 17:32:23 -0000 --H1spWtNR+x+ondvy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 17, 2004 at 09:19:28AM -0800, David O'Brien wrote: > On Fri, Jan 16, 2004 at 08:03:05PM -0800, Tim Kientzle wrote: > > >No, we should be using the __restrict as coded. But I wonder why > > >we can't just use "restrict"... > >=20 > > Because that would really mess up any user program that used > > 'restrict' as a variable or function name. I think the > > current approach is the best. >=20 > Such code isn't portable to C99, which is still a goal of ours. I like > RU's suggestion, because it is straight C[99] code and not an > abstraction. I'll do a 'make world' test and see if we'd have trouble > with RU's form. >=20 The code I've posted has obvious troubles. It would take care of the following fragment for -std=3Dc89 and be pure C99 for -std=3Dc99, void foo(char * restrict fa) { } but will break this for -std=3Dc89: void restrict(void) { } We have a problem if we want to mix old C89 and new C99 code. Cheers, --=20 Ruslan Ermilov FreeBSD committer ru@FreeBSD.org --H1spWtNR+x+ondvy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFACXHHUkv4P6juNwoRAh40AJ91MCs99R3UCpY4vQqW0F5CzsLzwQCfYFrU qMB3pP/ecj1+xejgWyn1dOA= =O5Xy -----END PGP SIGNATURE----- --H1spWtNR+x+ondvy-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 17 09:37:23 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B0E916A4CE for ; Sat, 17 Jan 2004 09:37:23 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id B897D43D49 for ; Sat, 17 Jan 2004 09:37:21 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i0HHbHET036526; Sat, 17 Jan 2004 10:37:17 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 17 Jan 2004 10:37:17 -0700 (MST) Message-Id: <20040117.103717.07694079.imp@bsdimp.com> To: twohey@CS.Stanford.EDU From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: [CHECKER] bugs in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2004 17:37:23 -0000 In message: Paul Twohey writes: : Hi, : : I'm with the Stanford Metacompilation research group. We have a suite of : checkers that find bugs at compile time and we've had quite a bit of : success checking the Linux kernel code for errors. Since our checkers can : emit false alarms we filter the reports before we give them to the kernel : developers. While some false alarms slip past us to the developers, our : limited knowledge of the kernel allows us to recognize most of them. : : We are currently trying to extend our checker to automatically find : functions which allocate resources and to make sure those resources are : properly disposed of. : : Enclosed is a list of potential bugs in FreeBSD where a value is returned : from a function (like malloc) that should be owned by the caller and the : caller does not properly dispose of the value with the appropriate : disposal routine (like free). : : Confirmation of these reports would be appreciated. Wow! That's cool! You've found a number of problems. It will take us a little while to chew through them (although on their face they do seem to be issues). Warner From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 17 09:47:44 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 833D316A4CE for ; Sat, 17 Jan 2004 09:47:44 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FA8943D58 for ; Sat, 17 Jan 2004 09:47:33 -0800 (PST) (envelope-from andre@freebsd.org) Received: (qmail 26283 invoked from network); 17 Jan 2004 17:47:32 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 17 Jan 2004 17:47:32 -0000 Message-ID: <40097534.2913A1D2@freebsd.org> Date: Sat, 17 Jan 2004 18:47:32 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sten Daniel =?iso-8859-1?Q?S=F8rsdal?= References: <0AF1BBDF1218F14E9B4CCE414744E70F5D97FF@exchange.wanglobal.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: freebsd-hackers@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: ip_input - chksum - why is it done so early in ip_input? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2004 17:47:44 -0000 Sten Daniel Sørsdal wrote: > > Apologies for the cross-post, i wasnt sure if this was hackers or net material. > > I've often wondered why ip checksumming is done on every incoming > packet and not only on the packets that need to be delivered locally. Only the IP header checksum is checked. We don't want to forward a packet with a broken header because we can't be sure if it wasn't the destination address that is broken. Be aware that we do not calculate any checksum of the entire IP packet. (This is up to the higher level protocol). > It looks like a very expensive way of doing it, especially on high > PPS. Basically all hosts do checksumming so why not just pass the bad > packet on, making the forward process alot cheaper (cpu wise)? On modern networks card (mostly GigE) you have hardware support for that. So there is no expense anymore. > I ran some tests (unable to disclose results) by removing it completely > and it seems to make a noticable impact on the performance. Can you qualify this more? The checksumming touches only 20 bytes (or a couple more if ip options are present). > Especially on for example gaming services where there is a high PPS versus > actual data. > > Besides that i'd like to add that FreeBSD has the fastest forwarding engine > i've seen on any free OS. It's in my opinion a very suitable OS for > routing/forwarding. We are working on it to make it even faster. If you are using 5.2 or -current you get the first step of it by enabling net.inet.ip.fastfowarding. This is a newly written fast path for packet forwarding. (Do not do this on 4.9 because that is the old ip_flow code). -- Andre From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 17 12:55:09 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35DD316A4CE; Sat, 17 Jan 2004 12:55:09 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8461543D2D; Sat, 17 Jan 2004 12:55:07 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i0HKrHUd021270; Sat, 17 Jan 2004 15:53:17 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i0HKrGaC021267; Sat, 17 Jan 2004 15:53:16 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 17 Jan 2004 15:53:16 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Andre Oppermann In-Reply-To: <40097534.2913A1D2@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: Sten Daniel =?iso-8859-1?Q?S=F8rsdal?= cc: freebsd-net@freebsd.org Subject: Re: ip_input - chksum - why is it done so early in ip_input? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2004 20:55:09 -0000 On Sat, 17 Jan 2004, Andre Oppermann wrote: > > Besides that i'd like to add that FreeBSD has the fastest forwarding engine > > i've seen on any free OS. It's in my opinion a very suitable OS for > > routing/forwarding. > > We are working on it to make it even faster. If you are using 5.2 or > -current you get the first step of it by enabling > net.inet.ip.fastfowarding. This is a newly written fast path for packet > forwarding. (Do not do this on 4.9 because that is the old ip_flow > code). You can also enable debug.mpsafenet, which disables holding the Giant lock over the forwarding path for supported ethernet drivers. Unfortunately, this option can't be used with KAME IPSEC or IPv6 yet, but can be used with FAST_IPSEC. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 17 16:10:04 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96CBF16A4CE for ; Sat, 17 Jan 2004 16:10:04 -0800 (PST) Received: from mailbox.univie.ac.at (mailbox.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50FE443D1F for ; Sat, 17 Jan 2004 16:10:01 -0800 (PST) (envelope-from l.ertl@univie.ac.at) Received: from wireless (adslle.cc.univie.ac.at [131.130.102.11]) by mailbox.univie.ac.at (8.12.10/8.12.10) with ESMTP id i0I09tJh266192 for ; Sun, 18 Jan 2004 01:09:57 +0100 Date: Sun, 18 Jan 2004 01:09:50 +0100 (CET) From: Lukas Ertl To: hackers@freebsd.org Message-ID: <20040118010036.M599@korben.in.tern> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-DCC-ZID-Univie-Metrics: imap 4243; Body=0 Fuz1=0 Fuz2=0 Subject: GEOM + Vinum X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2004 00:10:04 -0000 Hi -hackers, following the recent discussion about GEOM and Vinum I wrote some proof-of-concept code, or rather, I copy'n'pasted the necessary stuff for a prototype. Of course it's ugly, it's buggy, it's by far not complete, but at least it understands the most basic setup: a volume with a single plex and a single subdisk. This is how such a setup looks like: (this is the actual output from sysctl -b kern.geom.confdot | dot -Tps). And here's the code: . You still need vinum(8) to configure the setup; when you're done, unload vinum again and load geom_vinum. Then you can access your volumes in /dev/gvinum/. regards, le -- Lukas Ertl eMail: l.ertl@univie.ac.at UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 17 23:46:37 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6817116A4CE for ; Sat, 17 Jan 2004 23:46:37 -0800 (PST) Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8387E43D4C for ; Sat, 17 Jan 2004 23:46:36 -0800 (PST) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=danny) by cs.huji.ac.il with esmtp id 1Ai7dh-0002r4-SL for hackers@freebsd.org; Sun, 18 Jan 2004 09:46:33 +0200 X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 18 Jan 2004 09:46:33 +0200 From: Danny Braniss Message-Id: Subject: network constipation? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2004 07:46:37 -0000 hi, i have 2 amd64s (one dual opteron, one athlon64), which behave identicaly. Im trying to compile /usr/ports/x11-fonts, ports & obj are nfs mounted (on the the same server). so things go nicely, but after a while gzip hangs, and later i get 'nfs server dev:/r+d: not responding', this happens on both hosts, (i just tried it on both to see if the error was in the driver, since they have different cards). it's almost obvious that i've hit on a deadlock, where can i look for some hint? thanks, danny