From owner-freebsd-hackers Sun Dec 5 3:34: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id 2BE611514C; Sun, 5 Dec 1999 03:34:00 -0800 (PST) (envelope-from hibma@skylink.it) Received: from skylink.it (va-160.skylink.it [194.185.55.160]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id MAA04596; Sun, 5 Dec 1999 12:33:08 +0100 Received: from localhost (localhost [127.0.0.1]) by skylink.it (8.9.3/8.9.3) with ESMTP id LAA01897; Sun, 5 Dec 1999 11:14:20 +0100 (CET) (envelope-from hibma@skylink.it) Date: Sun, 5 Dec 1999 11:14:20 +0100 (CET) From: Nick Hibma X-Sender: n_hibma@henny.jrc.it Reply-To: Nick Hibma To: Garance A Drosihn Cc: Julian Elischer , hackers@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Hardware list idea In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think openbsd asks users to email them the output of 'dmesg', > so they can tell which drivers are really of interest to the > greatest number of their users. Seems like a reasonable idea. You might want to include the list of packages installed from the base CD's as well to prime the packages that need to be there. Nick -- hibma@skylink.it n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 3:34:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id 1910915063 for ; Sun, 5 Dec 1999 03:33:59 -0800 (PST) (envelope-from hibma@skylink.it) Received: from skylink.it (va-160.skylink.it [194.185.55.160]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id MAA04590; Sun, 5 Dec 1999 12:33:07 +0100 Received: from localhost (localhost [127.0.0.1]) by skylink.it (8.9.3/8.9.3) with ESMTP id KAA01879; Sun, 5 Dec 1999 10:55:32 +0100 (CET) (envelope-from hibma@skylink.it) Date: Sun, 5 Dec 1999 10:55:32 +0100 (CET) From: Nick Hibma X-Sender: n_hibma@henny.jrc.it Reply-To: Nick Hibma To: Doug Barton Cc: freebsd-hackers@FreeBSD.org Subject: Re: Basic question about threads and SMP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Being multi-threaded has almost nothing to do with being multi-processor. Multi-threading means that your application has multiple threads of execution that are able to run simultaneously. The multi-processing capability of your box means that 2 threads of execution, be it a process or a thread within a process, are executed _literally_ at the same time, and not in simulated concurrency like it happens on a UP box. Whether or not any application should be compiled with libc_r depends solely on the application itself. And, as you suggest, that is decided at build time. If applications support multi-threading they normally come with a Makefile using libc_r. Now, whether you want to multi-thread Apache is totally different issue ... Nick On Wed, 1 Dec 1999, Doug Barton wrote: > You know, a stray thought just occured to me, which hopefully > won't sound to silly to people who know about this stuff. :) If I have an > SMP box (using -Current specifically) do I want to be compiling things > with -lc_r? I'm thinking specifically of mission critical things like > apache, but in general will other ports and such take advantage of > libc_r if they are compiled with it, or would a program that _can_ take > advantage of it already have that built in, say into autoconf or some > such? What about other parts of the base system? I'm assuming that the > kernel is covered by virtue of the fact that I've enabled the SMP options, > yes? > > I'm trying to learn more about SMP, threads, and such like in > general. The recent conversations about those topics on the lists have > been very educational. I'm still wading through them, but I appreciate > being able to sit on the sidelines and glean bits here and there. > > Thanks, > > Doug > -- > "Welcome to the desert of the real." > > - Laurence Fishburne as Morpheus, "The Matrix" > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- hibma@skylink.it n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 3:34: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id 935321503B for ; Sun, 5 Dec 1999 03:33:59 -0800 (PST) (envelope-from hibma@skylink.it) Received: from skylink.it (va-160.skylink.it [194.185.55.160]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id MAA04589; Sun, 5 Dec 1999 12:33:07 +0100 Received: from localhost (localhost [127.0.0.1]) by skylink.it (8.9.3/8.9.3) with ESMTP id LAA01895; Sun, 5 Dec 1999 11:12:18 +0100 (CET) (envelope-from hibma@skylink.it) Date: Sun, 5 Dec 1999 11:12:18 +0100 (CET) From: Nick Hibma X-Sender: n_hibma@henny.jrc.it Reply-To: Nick Hibma To: Ulf Zimmermann Cc: hackers@FreeBSD.ORG Subject: Re: Digi AccelePort-USB 2, 4 or 8 port serial terminal server ? In-Reply-To: <19991130155555.B91042@PacHell.TelcoSucks.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Nice serial server, anyone working for serial support on USB ? > Have an 8 port and could help getting support for it or testing > drivers. If you are or someone else is willing to write a driver under NDA I can give you the e-mail address of a guy who can give you the specifications for it. I dropped the idea of writing the driver as there were other, open source projects to be working on. Nick -- hibma@skylink.it n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 4: 4:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 608) id E6F4514C3E; Sun, 5 Dec 1999 04:04:28 -0800 (PST) From: "Jonathan M. Bresler" To: dillon@apollo.backplane.com Cc: kris@hub.freebsd.org, freebsd-hackers@FreeBSD.ORG In-reply-to: <199912050514.VAA58998@apollo.backplane.com> (message from Matthew Dillon on Sat, 4 Dec 1999 21:14:41 -0800 (PST)) Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) Message-Id: <19991205120428.E6F4514C3E@hub.freebsd.org> Date: Sun, 5 Dec 1999 04:04:28 -0800 (PST) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [snip] > I am a good programmer and can fix things :-). But I've had to deal with > a number of nightmare situations by commercial entities deploying FreeBSD > and at least three (including one very recently) where commercial entities > have refused to upgrade past 2.2.x due to perceived stability problems. [snip] > > -Matt > Matthew Dillon we can not identify the specific problem from this message. without sufficient information to indentify and hopefully reproduce the problem, we can not address it. please provide this information if it is available to you. if it is not, please provide us contact information for the commercial entities experiencing the problem. jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 10: 9:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 48B58153C8; Sun, 5 Dec 1999 10:09:18 -0800 (PST) (envelope-from dennis@etinc.com) Received: from workstation.etinc.com (port35.netsvr1.cst.vastnet.net [207.252.73.35]) by etinc.com (8.9.3/8.9.3) with SMTP id NAA19322; Sun, 5 Dec 1999 13:12:07 -0500 (EST) Message-Id: <199912051812.NAA19322@etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 06 Dec 1999 01:31:06 -0500 To: Matthew Dillon , Wes Peters From: Dennis Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) Cc: Kris Kennaway , freebsd-hackers@FreeBSD.ORG In-Reply-To: <199912050646.WAA59445@apollo.backplane.com> References: <199912050514.VAA58998@apollo.backplane.com> <3849FD95.F0434263@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The "issue" that i first cited is that the core people in FreeBSD seemed disinterested in 3.x soon after its release. Development on 4.0 shouldnt even have begun until 3.x was stabilized. 3.0 wasnt ready for prime time when it was released and the work needed to get it there hasnt been done due to the fascination with 4.0. DB At 10:46 PM 12/4/99 -0800, Matthew Dillon wrote: > >:> >:> He didn't say this until after the situation had started to degrade. >:> >:> Besides, he's right. 3.x has serious problems. >: >:All running software has serious problems, that's why it is never considered >:done. Taking the time to enumerate specific problems that are currently >:plaguing an installation is the only way anyone can possibly hope to help. >:Problems reports of "It don't work" are helpful to absolutely noone. > > This simply isn't true. I have written plenty of software (large > projects) that do not have serious problems and, in fact, some do not > have any known problems at all. I have written several operating systems > and one of them is least as complex as the FreeBSD core (but not as > complex if you count drivers) which are bug-free (that is, there have > been no recorded crashes and except for feature updates have never been > rebooted). > > FreeBSD can become 'bug free' insofar as it is possible to become bug > free. You have to believe that it can happen or it won't. I believe > it can -- my personal goal for the project is to make the core bug free > and uncrashable (and here I mean only with a network and disk driver, > and not all the other drivers out there which would be an impossible > task). Since I've actually *written* bug-free and uncrashable OS cores > I am confident that it is possible to do with FreeBSD. > > Many of the issues relating to FreeBSD's instability and the many bugs > in the core have nothing to do with continuing development work > per-say, but instead has to do with an attitude that allows major > pollution to be introduced into the code to optimize very specific > cases (which destabilizes the source at the same time), and the lack of > proper documention within the source code. It is precisely these two > things which I have concentrated on the most - by rewriting where > necessary, generalizing optimizations (and ripping quite a few out of > the VM system entirely), and documenting the hell out of any procedure > I modify with succinct comments. > > There are two good examples of code pollution and, needless to say, they > have been responsible for a huge number of bugs over the years. Hundreds > of bugs at least. The first example is all the VM hacking that was > done to accomodate partial cache instantiation and, most noteably, > partial byte-range writes for NFS. So far this year I have managed to > rip about half of those hacks out at relatively little cost (a few > esoteric NFS write cases will be slower is all and buffer cache writing > is slightly slower due to the extra system process, but hopefully made up > by the move to an O(1) algorithm (previously an O(N^2) algorithm). > > The second example is the VFS layer implemenation and, most especially, > VOP_LOOKUP(). VOP_LOOKUP() has caused no end of trouble but the VFS layer > implementation with all of its locking assumptions and return requirements > has made filesystem design problematic at best. There is enormous > complexity in the lookup, directory scanning, VFS cache code that hides > bugs and that could be removed with a rewrite. > > In general, it is possible to fix these problems but some of those fixes > require significant rewriting. You have to be willing to rewrite and > take your lumps up front or you may be faced with a situation where > new problems are found with a subsystem for years to come. The best > example of this in my case is the getnewbuf() code. The code was > originally optimized with so many 'hacks' that it created at least half > a dozen serious bugs in the system. When I first rewrote it I encountered > a huge amount of resistance from certain people who believed (wrongly) that > rewriting would create more bugs then it fixed. While a few bugs were > introduced (that's the 'taking your lumps part), the generalization of > the code made finding and fixing them much, much easier and this will > ultimately lead to a better track record down the road. > > I applaud the removal of dead code that has been going on, though I have > major problems with the way some of it has been gone about. Compared > to what some committers have been doing recently, the dead code removal > that Alan and I had done to the VM system earlier in the year was a walk > in the part. I am dead set against 'hiding' bugs by trying to cache > around them instead of fixing them, which is essentially the category > in which I put most of the recent changes to procfs and /bin/ps. > > It may seem counter-productive, but in order to fix bugs and make the > system stable we actually need to cause the bugs to come to light > more quickly and in a manner that is so blazingly obvious that we can > fix them more quickly. Hence the reason for putting KASSERT()'s all > throughout the VM system (which led to the discovery that VM pages were > being put on the cache queue while still dirty and led to a fix for > a serious filesystem corruption bug, amoung other things). When I did > that some people screamed at me because they thought it would make the > system unstable, but how many panics have we ever seen from it? > > I am happy to see other people start to do the same thing. > > So, I think it *IS* possible to make FreeBSD sufficiently bug-free that > people become 'surprised' when they are able to crash a box running it. > > -Matt > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 10:24:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mojave.sitaranetworks.com (mojave.sitaranetworks.com [199.103.141.157]) by hub.freebsd.org (Postfix) with ESMTP id BC15815411 for ; Sun, 5 Dec 1999 10:24:15 -0800 (PST) (envelope-from grog@mojave.sitaranetworks.com) Message-ID: <19991205120810.21867@mojave.sitaranetworks.com> Date: Sun, 5 Dec 1999 12:08:10 -0500 From: Greg Lehey To: David Gilbert , freebsd-hackers@FreeBSD.ORG Subject: Re: Inverting a gdb -k mapping? Reply-To: Greg Lehey References: <14407.14812.812358.220983@trooper.velocet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <14407.14812.812358.220983@trooper.velocet.net>; from David Gilbert on Thu, Dec 02, 1999 at 10:32:44PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thursday, 2 December 1999 at 22:32:44 -0500, David Gilbert wrote: > I can grep through the vmcore.x file and find the offset of the string > I put on the stack by > > strings -t x > ... but how do I associate that back with an address inside gdb -k? With utmost difficult. > My problem is that vinum (or something related to it) is trashing > the stack and trying to return to 0x0 is panic'ing the kernel (of > course). > > ... now... bt in gdb -k on this shows the series of trap calls and > ends with frame 5 as: > > #5 0x0 in ?? () I think I probably should take a look at this. I don't know what I'll find, but there are a number of possibilities. I don't think that mapping the physical memory image to the virtual memory address is one of them. What might help is searching the area round frame 5 for a likely looking ebp value which would point further back down the stack. You can also help it, of course, by setting a static variable, say "dgilbert_last_stack" to the ebp value every time you enter a function. You don't need any other information; the backtrace will take you straight back. Use the 'btr' command (in /usr/src/sys/modules/vinum/.gdbinit.kernel). You'll get faster response from me if you copy me on messages like this; I read them eventually (usually), but I read messages sent directly to me sooner. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 11:17:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from monkeys.com (i180.value.net [206.14.136.180]) by hub.freebsd.org (Postfix) with ESMTP id 03EAF1540E for ; Sun, 5 Dec 1999 11:17:56 -0800 (PST) (envelope-from rfg@monkeys.com) Received: from monkeys.com (localhost [127.0.0.1]) by monkeys.com (8.9.3/8.9.3) with ESMTP id LAA21239; Sun, 5 Dec 1999 11:17:36 -0800 (PST) To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: tmpfs .. ? In-reply-to: Your message of Sat, 04 Dec 1999 20:47:11 -0800. <199912050447.UAA58828@apollo.backplane.com> Date: Sun, 05 Dec 1999 11:17:36 -0800 Message-ID: <21237.944421456@monkeys.com> From: "Ronald F. Guilmette" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199912050447.UAA58828@apollo.backplane.com>, Matthew Dillon wrote: > Mail queue files are persistant enough (upwards of 5 days if a destination > is down) that you run a real risk of losing something important if > you crash and wipe. I would not use MFS at all and I would only use VN > with persistant store, but the performance is going to be similar to > using a normal filesystem so it may not be worth doing. Yea, someone else I was talking with about this said the same thing. I just can't get over the nagging feeling that (for the mail spool directory) there ought to be something that is ultra-super-deluxe fast that I should be using. :-) > Normal > filesystems with softupdates turned on make pretty good mail spools though OK, I've seen several mentions now of `softupdates', and I think that I have a general (vague?) notion of what `softupdates' is all about, but allow me to disaply my ignorance one more time and ask which man page (or document) I should be looking at to learn all of the specifics regarding `softupdates'. (I looked at `man tunefs' and I don't see nuttin' there, so where exactly is/are `softupdates' documented?) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 11:28: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 2DAFD1540E; Sun, 5 Dec 1999 11:26:55 -0800 (PST) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost [127.0.0.1]) by green.dyndns.org (8.9.3/8.9.3) with ESMTP id OAA62007; Sun, 5 Dec 1999 14:20:18 -0500 (EST) (envelope-from green@FreeBSD.org) Date: Sun, 5 Dec 1999 14:20:17 -0500 (EST) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Dennis Cc: Matthew Dillon , Wes Peters , Kris Kennaway , freebsd-hackers@FreeBSD.org Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-Reply-To: <199912051812.NAA19322@etinc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 6 Dec 1999, Dennis wrote: > The "issue" that i first cited is that the core people in FreeBSD seemed > disinterested in 3.x soon after its release. Development on 4.0 shouldnt > even have begun until 3.x was stabilized. 3.0 wasnt ready for prime time > when it was released and the work needed to get it there hasnt been done > due to the fascination with 4.0. > > DB It was never stated that 3.0 was ready for prime-time, and in fact, quite the opposite was stated. Development on 4.0 did start when 3.X was stable, but that doesn't mean bugs which cause instability under very specific conditions still weren't found. MANY of the things done in 4.0 by Matt, for instance, cannot be merged into RELENG_3 without making huge, sweeping changes. These changes wouldn't have been made in the "stable", non-development branch. They weren't. They were made in the development branch, HEAD, 4.0. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 11:43:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from screech.weirdnoise.com (209-128-78-198.bayarea.net [209.128.78.198]) by hub.freebsd.org (Postfix) with ESMTP id 47F9A1544B; Sun, 5 Dec 1999 11:43:46 -0800 (PST) (envelope-from edhall@screech.weirdnoise.com) Received: from screech.weirdnoise.com (localhost [127.0.0.1]) by screech.weirdnoise.com (8.8.7/8.8.7) with ESMTP id LAA17720; Sun, 5 Dec 1999 11:44:58 -0800 Message-Id: <199912051944.LAA17720@screech.weirdnoise.com> X-Mailer: exmh version 2.0.2 To: "Jonathan M. Bresler" Cc: dillon@apollo.backplane.com, kris@hub.freebsd.org, freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-Reply-To: Your message of "Sun, 05 Dec 1999 04:04:28 PST." <19991205120428.E6F4514C3E@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 05 Dec 1999 11:44:57 -0800 From: Ed Hall Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You write: : we can not identify the specific problem from this message. : without sufficient information to indentify and hopefully reproduce : the problem, we can not address it. please provide this information : if it is available to you. if it is not, please provide us contact : information for the commercial entities experiencing the problem. I work at Yahoo. My address there is "edhall@yahoo-inc.com". On a recent project I encountered two show-stopping bugs with 3.3-release that did not exist in 2.2.8-release: 1) Random crashes in FXP interrupt or low-level IP code. Something is clobbering the kernel stack--possibly the NCR driver, since using an Adaptec made the problem stop, as did a backport of the CAM driver Peter Wemm tried. This was on an N440BX, which is becoming quite common in server applications. Other installations are apparantly seeing the same problem on this hardware. 2) A hard loop in the pagedaemon. This was especially egregious, since it meant the system had to be rebooted from the console--and since the application could elicit the problem within a few minutes. Disabling the use of mmap() for file update in the application prevented the problem. After spending a day trying to cook up a test program that elicited the same behavior that the application did, I gave up for lack of time. But there have been other reports of late that sound like this problem, mostly in high VM/RAM situations. That's two serious bugs that exist in 3.3-release but not in 2.2.8-release. Looking back through the archives, I can see that I'm not the only one who has experienced them. I came away from the experience with the feeling that the FreeBSD project has some serious Q/A problems... and I can assure you, I'm not alone in this feeling. -Ed To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 11:44:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from monkeys.com (i180.value.net [206.14.136.180]) by hub.freebsd.org (Postfix) with ESMTP id 61E7215466 for ; Sun, 5 Dec 1999 11:44:21 -0800 (PST) (envelope-from rfg@monkeys.com) Received: from monkeys.com (localhost [127.0.0.1]) by monkeys.com (8.9.3/8.9.3) with ESMTP id LAA21356 for ; Sun, 5 Dec 1999 11:43:36 -0800 (PST) To: freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-reply-to: Your message of Sat, 04 Dec 1999 22:46:01 -0800. <199912050646.WAA59445@apollo.backplane.com> Date: Sun, 05 Dec 1999 11:43:36 -0800 Message-ID: <21354.944423016@monkeys.com> From: "Ronald F. Guilmette" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199912050646.WAA59445@apollo.backplane.com>, Matthew Dillon wrote: > So, I think it *IS* possible to make FreeBSD sufficiently bug-free that > people become 'surprised' when they are able to crash a box running it. FYI - Part of the reason that _I_ jumped onto the FreeBSD bandwagon (not that long ago) was that FreeBSD was advertised as being basically uncrashable. As you might imagine, I was rather disappointed to learn that the ``never crashes'' claims that I had read (on www.freebsd.org?) were not always true in practice... at least not on the heavily-stressed 2.2.8 system that I was running awhile back. (That system has now been taken out of service for reasons entirely unrelated to the OS.) Having said that however, I guess that I should also clarify that the crashes I had been experiencing with that 2.2.8 system might perhaps have been easily solved (at the time) if it had not been for an unfortunate combination of factors (i.e. swap partition having been allocated too small, more memory being added to the system) that made it impossible for me to get any sort of a system crash dump to analyze. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 11:50:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.enteract.com (mail.enteract.com [207.229.143.33]) by hub.freebsd.org (Postfix) with ESMTP id B5B2E14D35 for ; Sun, 5 Dec 1999 11:50:38 -0800 (PST) (envelope-from dscheidt@enteract.com) Received: from shell-2.enteract.com (dscheidt@shell-2.enteract.com [207.229.143.41]) by mail.enteract.com (8.9.3/8.9.3) with SMTP id NAA08558; Sun, 5 Dec 1999 13:50:23 -0600 (CST) (envelope-from dscheidt@enteract.com) Date: Sun, 5 Dec 1999 13:50:23 -0600 (CST) From: David Scheidt To: "Ronald F. Guilmette" Cc: Matthew Dillon , freebsd-hackers@FreeBSD.ORG Subject: Re: tmpfs .. ? In-Reply-To: <21237.944421456@monkeys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 5 Dec 1999, Ronald F. Guilmette wrote: > > Normal > > filesystems with softupdates turned on make pretty good mail spools though > > OK, I've seen several mentions now of `softupdates', and I think that I > have a general (vague?) notion of what `softupdates' is all about, but > allow me to disaply my ignorance one more time and ask which man page > (or document) I should be looking at to learn all of the specifics > regarding `softupdates'. (I looked at `man tunefs' and I don't see > nuttin' there, so where exactly is/are `softupdates' documented?) See src/sys/ufs/ffs/README.softupdates, which tells you what you need to get them to work, and http://www.ece.cmu.edu/~ganger/CSE-TR-254-95/ David Scheidt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 12: 6:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from monkeys.com (i180.value.net [206.14.136.180]) by hub.freebsd.org (Postfix) with ESMTP id A4C6015455 for ; Sun, 5 Dec 1999 12:05:50 -0800 (PST) (envelope-from rfg@monkeys.com) Received: from monkeys.com (localhost [127.0.0.1]) by monkeys.com (8.9.3/8.9.3) with ESMTP id MAA21543 for ; Sun, 5 Dec 1999 12:05:06 -0800 (PST) To: freebsd-hackers@FreeBSD.ORG Subject: Strange SCSI sickness Date: Sun, 05 Dec 1999 12:05:06 -0800 Message-ID: <21541.944424306@monkeys.com> From: "Ronald F. Guilmette" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG My apologies for posting this digression from the usual weighty matters that are discussed here on -hackers, but I'm really in a tizzy about this. Going through my waiting mail this morning (on my personal desktop system named `segfault.monkeys.com') I found the following message from the nightly Security Check run. (This system is running stock 3.3 from a CD.) I'm really quite worried about this, and I want to know what it all means. `da0' is my primary SCSI drive and holds a LOT of stuff that is near and dear to me (including a lot of stuff which I DO NOT HAVE BACKED UP) along with all of the OS files. The controller is an AHA-2940U (not wide). The da0 disk is a Quantum Viking 4.5GB SCSI. I have never had any problem with this drive before, even though I used it on Linux for several months. This (FreeBSD) system has been running just fine, with no problems, for several weeks. And now this! I looked at the log files in /var/log and found out that these SCSI errors mostly seem to have occured at around 2:00 local time last night... when I was in bed and asleep. This morning, the system still _seems_ to be running just fine, but I'm worried... I just want to know, on a scale from 1 to 10, what level of panic should I now be experiencing relative to the kernel SCSI errors shown below? Should I be furiously backing everything up to tape as we speak? ------- Forwarded Message Return-Path: root Received: (from root@localhost) by monkeys.com (8.9.3/8.9.3) id BAA20422 for root; Sun, 5 Dec 1999 01:59:42 -0800 (PST) Date: Sun, 5 Dec 1999 01:59:42 -0800 (PST) From: Charlie Root Message-Id: <199912050959.BAA20422@monkeys.com> Subject: segfault.monkeys.com security check output X-Original-Recipient: RFC822;root@monkeys.com checking setuid files and devices: checking for uids of 0: root 0 toor 0 checking for passwordless accounts: segfault.monkeys.com kernel log messages: > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x53 > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x53 > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Message-In phase. > SEQADDR == 0x152 > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Command phase. > SEQADDR == 0x152 > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Message-In phase. > SEQADDR == 0x152 > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Message-In phase. > SEQADDR == 0x152 > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x118 > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x53 > SCSIRATE == 0xf segfault.monkeys.com login failures: segfault.monkeys.com refused connections: ------- End of Forwarded Message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 12: 9:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id D352C1544F for ; Sun, 5 Dec 1999 12:09:42 -0800 (PST) (envelope-from billf@chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id C2D9B1C4A; Sun, 5 Dec 1999 14:10:29 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id BFAA2381B; Sun, 5 Dec 1999 14:10:29 -0500 (EST) Date: Sun, 5 Dec 1999 14:10:29 -0500 (EST) From: Bill Fumerola To: "Ronald F. Guilmette" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Strange SCSI sickness In-Reply-To: <21541.944424306@monkeys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 5 Dec 1999, Ronald F. Guilmette wrote: > The controller is an AHA-2940U (not wide). The da0 disk is a Quantum > Viking 4.5GB SCSI. I have never had any problem with this drive before, > even though I used it on Linux for several months. > > This (FreeBSD) system has been running just fine, with no problems, for > several weeks. And now this! Before throwing the "this worked in Linux!" crap around, please consider that it is possible Linux just didn't report the errors. just a possibility... -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 12:14:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pak2.texar.com (pak2.texar.com [216.208.160.130]) by hub.freebsd.org (Postfix) with ESMTP id 2F85C15435 for ; Sun, 5 Dec 1999 12:14:52 -0800 (PST) (envelope-from dseg@pak2.texar.com) Received: from localhost (dseg@localhost) by pak2.texar.com (8.9.2/8.8.3) with ESMTP id PAA13719; Sun, 5 Dec 1999 15:14:06 -0500 (EST) Date: Sun, 5 Dec 1999 15:14:06 -0500 (EST) From: Dan Seguin To: Bill Fumerola Cc: "Ronald F. Guilmette" , freebsd-hackers@FreeBSD.ORG Subject: Re: Strange SCSI sickness In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 5 Dec 1999, Bill Fumerola wrote: > On Sun, 5 Dec 1999, Ronald F. Guilmette wrote: > > > The controller is an AHA-2940U (not wide). The da0 disk is a Quantum > > Viking 4.5GB SCSI. I have never had any problem with this drive before, > > even though I used it on Linux for several months. > > > > This (FreeBSD) system has been running just fine, with no problems, for > > several weeks. And now this! > > Before throwing the "this worked in Linux!" crap around, please consider > that it is possible Linux just didn't report the errors. > > just a possibility... > > -- > - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - > - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - "... even though I used it on Linux for several months." I read that as meaning "the drive worked despite the fact that it was on Linux". -------------------------------------------------------------------------------- Dan Seguin Texar Software, Corporation. The trouble with doing something right the first time is that nobody appreciates how difficult it was. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 12:16: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tardis.patho.gen.nz (tardis.patho.gen.nz [203.97.2.226]) by hub.freebsd.org (Postfix) with ESMTP id 4DC6815435 for ; Sun, 5 Dec 1999 12:15:56 -0800 (PST) (envelope-from jabley@tardis.patho.gen.nz) Received: (from jabley@localhost) by tardis.patho.gen.nz (8.9.3/8.9.3) id JAA04223 for freebsd-hackers@freebsd.org; Mon, 6 Dec 1999 09:15:55 +1300 (NZDT) Date: Mon, 6 Dec 1999 09:15:55 +1300 From: Joe Abley To: freebsd-hackers@freebsd.org Subject: NFS server bound to specific local address Message-ID: <19991206091552.B31032@patho.gen.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0i X-Files: the Truth is Out There Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I've just noticed that (on STABLE, at least) it doesn't seem possible to run an NFS server on a machine, and have it service requests from clients talking to anything other than the base address. For example, if I ifconfig fxp0 inet 192.168.0.11 ifconfig fxp0 inet 192.168.0.16 alias and then have clients attempt to mount 192.168.0.16:/foo, the clients will not successfully mount the shared volume; this is (according to some posts on the subject I found in the -questions archive) because the client is expecting replies from 192.168.0.16, but the server is sending them from 192.168.0.16. This is correct behaviour by the client, since trusting NFS replies from any old address would be silly. It seems to me that _my_ requirements would be satisfied if an NFS request from a client could have its destination address recorded, so that any replies to that specific request could be sourced from the address expected by the client. Would this obviously break anything else? Would this be a security-conscious modification? Does -current already do this? If "no, yes, no" I'll have a look myself. Just keen not to overlap with anybody else's effort. -- Ua lawa küpono ka hakahaka pä o këia pä malule To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 12:46:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 1679E15452 for ; Sun, 5 Dec 1999 12:46:19 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.9.3/8.9.3) id OAA85386; Sun, 5 Dec 1999 14:46:07 -0600 (CST) (envelope-from dan) Date: Sun, 5 Dec 1999 14:46:07 -0600 From: Dan Nelson To: "Ronald F. Guilmette" Cc: Matthew Dillon , freebsd-hackers@FreeBSD.ORG Subject: Sendmail (was Re: tmpfs .. ?) Message-ID: <19991205144607.A84813@dan.emsphone.com> References: <199912050447.UAA58828@apollo.backplane.com> <21237.944421456@monkeys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <21237.944421456@monkeys.com>; from "Ronald F. Guilmette" on Sun Dec 5 11:17:36 GMT 1999 X-OS: FreeBSD 4.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Dec 05), Ronald F. Guilmette said: > Matthew Dillon wrote: > > Mail queue files are persistant enough (upwards of 5 days if a > > destination is down) that you run a real risk of losing something > > important if you crash and wipe. I would not use MFS at all and I > > would only use VN with persistant store, but the performance is > > going to be similar to using a normal filesystem so it may not be > > worth doing. > > Yea, someone else I was talking with about this said the same thing. > > I just can't get over the nagging feeling that (for the mail spool > directory) there ought to be something that is ultra-super-deluxe > fast that I should be using. :-) Sendmail 8.10 seems to have some performance enhancements, including "memory-buffered files to reduce file system overhead by not creating temporary files on disk", "New queue file naming system which uses a filename guaranteed to be unique for 60 years. This allows queue IDs to be assigned without fancy file system locking", and "QueueSortOrder=Filename will sort the queue by filename. This avoids opening and reading each queue file when preparing to run the queue". I don't know if any of them really help, but it's worth looking at. -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 12:57:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from monkeys.com (i180.value.net [206.14.136.180]) by hub.freebsd.org (Postfix) with ESMTP id 416C715452 for ; Sun, 5 Dec 1999 12:57:46 -0800 (PST) (envelope-from rfg@monkeys.com) Received: from monkeys.com (localhost [127.0.0.1]) by monkeys.com (8.9.3/8.9.3) with ESMTP id MAA22014; Sun, 5 Dec 1999 12:57:42 -0800 (PST) To: David Scheidt Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: tmpfs .. ? In-reply-to: Your message of Sun, 05 Dec 1999 13:50:23 -0600. Date: Sun, 05 Dec 1999 12:57:42 -0800 Message-ID: <22012.944427462@monkeys.com> From: "Ronald F. Guilmette" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , you wrote: >See src/sys/ufs/ffs/README.softupdates, which tells you what you need to get >them to work Thank you. I'll definitely be looking at that. P.S. The other reference you gave: >http://www.ece.cmu.edu/~ganger/CSE-TR-254-95/ seem to no longer be useful/functional. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 13: 0:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 4A83C15452 for ; Sun, 5 Dec 1999 13:00:32 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id MAA44947; Sun, 5 Dec 1999 12:59:39 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Dan Seguin Cc: Bill Fumerola , "Ronald F. Guilmette" , freebsd-hackers@FreeBSD.ORG Subject: Re: Strange SCSI sickness In-reply-to: Your message of "Sun, 05 Dec 1999 15:14:06 EST." Date: Sun, 05 Dec 1999 12:59:39 -0800 Message-ID: <44943.944427579@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > "... even though I used it on Linux for several months." > > I read that as meaning "the drive worked despite the fact that it was on > Linux". Well, just to inject a note of reality into this discussion: 1. It's quite possible that the drive and/or the cabling in this system has been defective all along. 2. It's equally possible that the linux driver simply doesn't report the errors but, as FreeBSD does, retries the failing operations. This would result in a system which appeared to work just fine, just more slowly at times (which would probably not even be noticed). 3. Any system I saw spitting out errors like this would get the following treatment, in roughly this order: 3a) Complete check of all cables and the seating of connectors. 3b) Examination of the drive(s) in question for any cooling or mounting deficiencies. Depending on the SCSI errors in question, I might even investigate firmware updates for the drive(s). 3c) Examination of the controller for correct seating and bus slot (in older PCI mobos, this makes a difference) as well as its firmware revision level. I'd also, obviously, look into any recent FreeBSD driver updates to see if I was running afoul of something recently added. If nothing in software appeared to be the culprit and I was still seeing the errors after doing steps 3a-3c above, I'd then pop in another drive and copy my data to it, removing the old drive afterwards and setting it aside in my "suspect" pile. If the errors still occurred, I'd replace the SCSI cabling and move the old drive from the "suspect" to the "spare" pile. If it still didn't work, I'd move the old SCSI cabling to my spare pile as well and replace the controller. After that I can't tell you what I'd do next since I've never had a problem persist after going all the way down this road. :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 13:16:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from kronos.alcnet.com (kronos.alcnet.com [63.69.28.22]) by hub.freebsd.org (Postfix) with ESMTP id 47BAB14CE2 for ; Sun, 5 Dec 1999 13:16:26 -0800 (PST) (envelope-from kbyanc@posi.net) X-Provider: ALC Communications, Inc. http://www.alcnet.com/ Received: from localhost (kbyanc@localhost) by kronos.alcnet.com (8.9.3/8.9.3/antispam) with ESMTP id QAA35945; Sun, 5 Dec 1999 16:15:51 -0500 (EST) Date: Sun, 5 Dec 1999 16:15:51 -0500 (EST) From: Kelly Yancey X-Sender: kbyanc@kronos.alcnet.com To: "Jordan K. Hubbard" Cc: Dan Seguin , Bill Fumerola , "Ronald F. Guilmette" , freebsd-hackers@FreeBSD.ORG Subject: Re: Strange SCSI sickness In-Reply-To: <44943.944427579@zippy.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 3b) Examination of the drive(s) in question for any cooling or > mounting deficiencies. Depending on the SCSI errors in question, > I might even investigate firmware updates for the drive(s). > I actually used to get these *exact* errors a couple of years ago on various 2.x systems. At first, I had assumed a bug in the driver (the ahc driver was noted as still having some bugs at the time, if I recall correctly). The errors would rare (every month or so, but they would come in batches). I kept upgrading, from 2.1.5, through 2.2.5 hoping that the errors would go away. Now, my ignorance being point out, it turned out that the errors were actually heat-induced. I had 2 5-year old 7200RPM drives in each of the systems, that besides being noisy, got pretty hot. Of course, they weren't hot when I mounted them :), and I had mounted them right next to each other in the case. It helped a little when I spaced the drives apart from each other. Then I found these neat full-length expansion cards which have 2 fans mounted on them. Got that situated to circulate additional air across the drives and never had any problem since (those systems have been running for over a year since without incident). Kelly -- Kelly Yancey - kbyanc@posi.net - Richmond, VA Director of Technical Services, ALC Communications http://www.alcnet.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSD http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 13:36:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id D9484152A9 for ; Sun, 5 Dec 1999 13:36:53 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.8.7/8.8.7) with ESMTP id NAA14622; Sun, 5 Dec 1999 13:37:04 -0800 Date: Sun, 5 Dec 1999 13:37:04 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Jordan K. Hubbard" Cc: Dan Seguin , Bill Fumerola , "Ronald F. Guilmette" , freebsd-hackers@FreeBSD.ORG Subject: Re: Strange SCSI sickness In-Reply-To: <44943.944427579@zippy.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 3. Any system I saw spitting out errors like this would get the following > treatment, in roughly this order: > > 3a) Complete check of all cables and the seating of connectors. > > 3b) Examination of the drive(s) in question for any cooling or > mounting deficiencies. Depending on the SCSI errors in question, > I might even investigate firmware updates for the drive(s). > > 3c) Examination of the controller for correct seating and bus slot > (in older PCI mobos, this makes a difference) as well as its > firmware revision level. > 3d) Any system experiencieng scsi parity errors should have all components power cycled (for self healing termpwr- fuses) and any pluggable termpwr fuses checked (these are exceedingly rare now- but if you had a SparcStation, they'd be the first thing to check- they're next to the ethernet connector on the motherboard). If you're not using an active terminator, you should be. Check for multiple termination- both ends of the bus must have termination enabled, nothing else- check drive and hba. If necessary, derate off of Ultra to Fast to see if this was the source of problems. [ a parity error indicates trashed signals. a parity error in data phase indicates signal reflection, skew, or rise time problems. signal quality is greatly affected by: bus length, termination, cable impedance mismatches ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 13:38:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from monkeys.com (i180.value.net [206.14.136.180]) by hub.freebsd.org (Postfix) with ESMTP id B055615428 for ; Sun, 5 Dec 1999 13:38:42 -0800 (PST) (envelope-from rfg@monkeys.com) Received: from monkeys.com (localhost [127.0.0.1]) by monkeys.com (8.9.3/8.9.3) with ESMTP id NAA22123 for ; Sun, 5 Dec 1999 13:37:59 -0800 (PST) To: freebsd-hackers@FreeBSD.ORG Subject: Re: Strange SCSI sickness In-reply-to: Your message of Sun, 05 Dec 1999 14:10:29 -0500. Date: Sun, 05 Dec 1999 13:37:59 -0800 Message-ID: <22121.944429879@monkeys.com> From: "Ronald F. Guilmette" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Bill Fumerola wrote: >On Sun, 5 Dec 1999, Ronald F. Guilmette wrote: > >> The controller is an AHA-2940U (not wide). The da0 disk is a Quantum >> Viking 4.5GB SCSI. I have never had any problem with this drive before, >> even though I used it on Linux for several months. >> >> This (FreeBSD) system has been running just fine, with no problems, for >> several weeks. And now this! > >Before throwing the "this worked in Linux!" crap around, please consider >that it is possible Linux just didn't report the errors. > >just a possibility... Ummm.... Hellooooo! Is it just vaguely possible that you are perhaps just a little bit touchy about anything that might even perversely be (mis-)construed as a compari- son between FreeBSD and Linux? Please read what I wrote. No comparison of any kind between these two OSes was either expressed or implied. In order to help clarify the problem, I merely noted that this specific *DISK DRIVE* has been operating with no problems (under *both* FreeBSD and Linux) for some time now. If anything, I believe that this combined evidence strongly points to a newly-developed *HARDWARE* problem in the *DISK DRIVE*. To reiterate, no OS comparisons were either expressed or implied. Furthermore, having just witnessed (here) someone else being roasted over an open flame for having FAILED to provide all relevant details regarding the background of some problem, I find it rather inexplicable that _I_ should now be roasted for having done the exact opposite, i.e. having provided as much potentially useful background information about my specific problem as possible. P.S. I'm a complete agnostic with regards to OSes. I have neither any specific religious beliefs with regards to OSes, nor any desire whatsoever to engage in religious flame wars about them. I have better things to do. P.P.S. Since joining the -hackers list only a short time ago, I've made every effort to restrain myself from my natural tendency to either begin, or to participate in flame wars. I've done that despite the fact that at about half of the traffic here on -hackers since I joined seem to consist of flames (of one form or another) that I have been tempted to jump into the middle of, _and_ despite the fact that I myself have a well and widely known propensity to start or participate in flaming myself. I came here only to learn and to benefit from the combined wisdom here... not to read flames or to be flamed. A simple plea: Can we all just get along? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 13:45:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.enteract.com (mail.enteract.com [207.229.143.33]) by hub.freebsd.org (Postfix) with ESMTP id 4866715428 for ; Sun, 5 Dec 1999 13:45:19 -0800 (PST) (envelope-from dscheidt@enteract.com) Received: from shell-2.enteract.com (dscheidt@shell-2.enteract.com [207.229.143.41]) by mail.enteract.com (8.9.3/8.9.3) with SMTP id PAA19674; Sun, 5 Dec 1999 15:45:17 -0600 (CST) (envelope-from dscheidt@enteract.com) Date: Sun, 5 Dec 1999 15:45:17 -0600 (CST) From: David Scheidt To: "Ronald F. Guilmette" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: tmpfs .. ? In-Reply-To: <22012.944427462@monkeys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 5 Dec 1999, Ronald F. Guilmette wrote: > > In message , you > P.S. The other reference you gave: > > >http://www.ece.cmu.edu/~ganger/CSE-TR-254-95/ > > seem to no longer be useful/functional. That is because it should be ~ganger/CSE-TR-254-95/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 13:52:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from monkeys.com (i180.value.net [206.14.136.180]) by hub.freebsd.org (Postfix) with ESMTP id 7627515428 for ; Sun, 5 Dec 1999 13:52:11 -0800 (PST) (envelope-from rfg@monkeys.com) Received: from monkeys.com (localhost [127.0.0.1]) by monkeys.com (8.9.3/8.9.3) with ESMTP id NAA22339 for ; Sun, 5 Dec 1999 13:52:10 -0800 (PST) To: freebsd-hackers@FreeBSD.ORG Subject: Re: Strange SCSI sickness In-reply-to: Your message of Sun, 05 Dec 1999 12:59:39 -0800. <44943.944427579@zippy.cdrom.com> Date: Sun, 05 Dec 1999 13:52:10 -0800 Message-ID: <22337.944430730@monkeys.com> From: "Ronald F. Guilmette" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <44943.944427579@zippy.cdrom.com>, "Jordan K. Hubbard" wrote: >> "... even though I used it on Linux for several months." >> >> I read that as meaning "the drive worked despite the fact that it was on >> Linux". > >Well, just to inject a note of reality into this discussion: > >1. It's quite possible that the drive and/or the cabling in this > system has been defective all along. I suspect not, based upon the history. I think that the drive and/or controler has just developed this sickness within the past 24 hours. >2. It's equally possible that the linux driver simply doesn't report > the errors but, as FreeBSD does, retries the failing operations. > This would result in a system which appeared to work just fine, > just more slowly at times (which would probably not even be > noticed). FreeBSD was also perfectly happy with this drive (and controller) for weeks... up until last night. >3. Any system I saw spitting out errors like this would get the following > treatment, in roughly this order: (I now think that my first order of business should be to start making backup tapes as quick as I can. :-) > 3a) Complete check of all cables and the seating of connectors. > > 3b) Examination of the drive(s) in question for any cooling or ^^^^^^^ The drive is mounted in a crappy external box with perfectly lousy ventilation. I just touched the drive and guess what... It's hot as Hades. I think I found my answer. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 13:56:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 386D715464 for ; Sun, 5 Dec 1999 13:56:53 -0800 (PST) (envelope-from kvandel@cs.duke.edu) Received: from wookie.vandelden.com (IDENT:root@s-kvandel.cs.duke.edu [152.3.134.91]) by duke.cs.duke.edu (8.9.1/8.9.1) with SMTP id QAA16850 for ; Sun, 5 Dec 1999 16:56:50 -0500 (EST) From: kvandel Reply-To: kvandel@cs.duke.edu Organization: Duke University To: freebsd-hackers@FreeBSD.ORG Date: Sun, 5 Dec 1999 16:37:38 -0600 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <99120516514304.01102@wookie.vandelden.com> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Question, I am a graduate student at Duke University. Currently, I am part of a team to build a terabit router using a cluster connected with Myrinet. One aspect of the project is to tune the devices & drivers to perform cooperatively... In a routing situation, the 1500B dma takes roughly 11us over PCI 32/33Mhz. If the processor (driver) is checking the command accept status of a NIC, it can take a "long" time to get a response from the NIC. For gigabit routing, you have to roughly processes 1pkt/ 8-10us . For starters, I changed up the driver code in fxp_start to break up a large dma transactions into smaller chunks,.. to make bus arbitration work using a finer grain time slice. Hence, the processor stalls less when it checks if a NIC command was accepted. The question: Why doesn't this work... it seem so straight forward... using netperf, the driver works when the message size is less than FXP_MAX_SEGMENT_SIZE, .. I am using FXP_MAX_SEGMENT_SIZE of 1024 ---------------------------------------------------------- fxp_start()........ /* * Go through each of the mbufs in the chain and initialize * the transmit buffer descriptors with the physical address * and size of the mbuf. */ tbdinit: for (m = mb_head, segment = 0; m != NULL; m = m->m_next) { if (m->m_len != 0) { unsigned int sub_segments, counter; uint8_t *mbuf_data_addr = mtod(m,uint8_t *); sub_segments = (m->m_len / FXP_MAX_SEGMENT_SIZE) + (((m->m_len % FXP_MAX_SEGMENT_SIZE) != 0)?1:0); if (segment + sub_segments >= FXP_NTXSEG) break; for(counter = 0;counter < sub_segments;counter++) { txp->tbd[segment].tb_addr = vtophys(mbuf_data_addr + (counter * FXP_MAX_SEGMENT_SIZE)); txp->tbd[segment].tb_size = (sub_segments == (counter+1))?(m->m_len % FXP_MAX_SEGMENT_SIZE):FXP_MAX_SEGMENT_SIZE; /* vtophys(mtod(m, vm_offset_t)) + (counter * FXP_MAX_SEGMENT_SIZE); */ segment++; } } } if (m != NULL) { ..... ------------------------------------------------------------------------------------------------- Unfortunately, I don't have the intel docs on the card, which requires a NDA... If you can help, it would be much appreciated. thanks, kurt -- Some output when it's running /*if(mb_head->m_pkthdr.len > FXP_MAX_SEGMENT_SIZE) printf("Pha %u, Kva %u, counter %u,segment %u, length %u, subs %u, tbs %u, mss %u\n", txp->tbd[segment].tb_addr, mbuf_data_addr + (counter * FXP_MAX_SEGMENT_SIZE), counter, segment, m->m_len, sub_segments, txp->tbd[segment].tb_size, FXP_MAX_SEGMENT_SIZE); */ Pha 39110690, Kva 3229624354, counter 0,segment 0, length 34, subs 1, tbs 34, mss 1024 Pha 129788744, Kva 3229076296, counter 0,segment 1, length 1208, subs 2, tbs 1024, mss 1024 Pha 129789768, Kva 3229077320, counter 1,segment 2, length 1208, subs 2, tbs 184, mss 1024 Pha 131485696, Kva 3229200384, counter 0,segment 3, length 272, subs 1, tbs 272, mss 1024 Pha 39637282, Kva 3229626658, counter 0,segment 0, length 34, subs 1, tbs 34, mss 1024 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 13:58:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pak2.texar.com (pak2.texar.com [216.208.160.130]) by hub.freebsd.org (Postfix) with ESMTP id 9475B15464 for ; Sun, 5 Dec 1999 13:58:11 -0800 (PST) (envelope-from dseg@pak2.texar.com) Received: from localhost (dseg@localhost) by pak2.texar.com (8.9.2/8.8.3) with ESMTP id QAA17146; Sun, 5 Dec 1999 16:57:36 -0500 (EST) Date: Sun, 5 Dec 1999 16:57:36 -0500 (EST) From: Dan Seguin To: "Ronald F. Guilmette" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Strange SCSI sickness In-Reply-To: <22337.944430730@monkeys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >1. It's quite possible that the drive and/or the cabling in this > > system has been defective all along. > > I suspect not, based upon the history. > > I think that the drive and/or controler has just developed this sickness > within the past 24 hours. > > >2. It's equally possible that the linux driver simply doesn't report > > the errors but, as FreeBSD does, retries the failing operations. > > This would result in a system which appeared to work just fine, > > just more slowly at times (which would probably not even be > > noticed). > > FreeBSD was also perfectly happy with this drive (and controller) for > weeks... up until last night. > > >3. Any system I saw spitting out errors like this would get the following > > treatment, in roughly this order: > > (I now think that my first order of business should be to start making > backup tapes as quick as I can. :-) > > > 3a) Complete check of all cables and the seating of connectors. > > > > 3b) Examination of the drive(s) in question for any cooling or > ^^^^^^^ > > The drive is mounted in a crappy external box with perfectly lousy > ventilation. > > I just touched the drive and guess what... It's hot as Hades. > > I think I found my answer. > [stuff snipped] If it already hasn't been done, we should capture the procedure that Jordan posted, added to by Matt and maybe post it to the troubleshooting part of the guide(s). Unlike some of us who've been fooling with computers since pre-1985, this standard operating procedure may not be second nature. -------------------------------------------------------------------------------- Dan Seguin Texar Software, Corporation. The trouble with doing something right the first time is that nobody appreciates how difficult it was. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 14:29: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id DC23B14C3D for ; Sun, 5 Dec 1999 14:28:58 -0800 (PST) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 5 Dec 1999 22:28:57 +0000 (GMT) Date: Sun, 5 Dec 1999 22:28:57 +0000 From: David Malone To: Joe Abley Cc: freebsd-hackers@freebsd.org Subject: Re: NFS server bound to specific local address Message-ID: <19991205222857.A27688@walton.maths.tcd.ie> References: <19991206091552.B31032@patho.gen.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <19991206091552.B31032@patho.gen.nz> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Dec 06, 1999 at 09:15:55AM +1300, Joe Abley wrote: > I've just noticed that (on STABLE, at least) it doesn't seem possible > to run an NFS server on a machine, and have it service requests from > clients talking to anything other than the base address. We've some patches which Matt Dillon just applied to -current which allow this to work correctly. The patches are quite simple and were developed here for a 3.3-STABLE machine, so it should be easy to backport them. It is probably too late to get them into 3.4 at this stage. (The pr was kern/13049 but something slightly different got committed in the end). David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 14:34:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id BC36B14CAD for ; Sun, 5 Dec 1999 14:34:08 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40335>; Mon, 6 Dec 1999 09:26:20 +1100 Content-return: prohibited Date: Mon, 6 Dec 1999 09:33:41 +1100 From: Peter Jeremy Subject: Re: tmpfs .. ? To: hackers@FreeBSD.ORG Cc: rfg@monkeys.com Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Dec6.092620est.40335@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 04 Dec 1999 15:44:49 -0800, "Ronald F. Guilmette" wrote: >Specifically, I'm planning a large mail server... which will use Sendmail... >and I'd really like to allocate the Sendmail queue files... which typically >have a rather short lifespan... on/in some sort of filesystem (e.g. an >mfs or else this VN thing you are talking about) that would tend to give >petter performance than just using an ordinary disk-based filesystem. This doesn't sound like a good application for a temporary filesystem. Whilst the files do typically have a short lifetime, and there are lots of them, they represent mail items which your server has accepted responsibility for delivering. Also, the queue files can potentially exist for several days (the default timeout is 5 days). I would suggest that UFS with softupdates represents a better performance/ reliability tradeoff than MFS or a swap-backed vnode. The main problem is that sendmail places all queue files (and there are several for each undelivered message) in one directory - and very large directories are not handled particularly efficently by UFS. The simple solutions are: 1) switch to an alternative MTA that doesn't display this behaviour. 2) hack sendmail to have multiple subdirectories within the main queue directory - with the subdirectory chosen by hashing the sendmail job id. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 14:39:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 49F6414A0A for ; Sun, 5 Dec 1999 14:39:19 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id XAA27525; Sun, 5 Dec 1999 23:28:15 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id WAA74217; Sun, 5 Dec 1999 22:50:26 +0100 (CET) (envelope-from wilko) From: Wilko Bulte Message-Id: <199912052150.WAA74217@yedi.iaf.nl> Subject: Re: Strange SCSI sickness In-Reply-To: from Kelly Yancey at "Dec 5, 1999 4:15:51 pm" To: kbyanc@posi.net (Kelly Yancey) Date: Sun, 5 Dec 1999 22:50:26 +0100 (CET) Cc: jkh@zippy.cdrom.com, dseg@texar.com, billf@chc-chimes.com, rfg@monkeys.com, freebsd-hackers@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Kelly Yancey wrote ... > > > > 3b) Examination of the drive(s) in question for any cooling or > > mounting deficiencies. Depending on the SCSI errors in question, > > I might even investigate firmware updates for the drive(s). > > > > I actually used to get these *exact* errors a couple of years ago on > various 2.x systems. At first, I had assumed a bug in the driver (the ahc > driver was noted as still having some bugs at the time, if I recall > correctly). The errors would rare (every month or so, but they would come > in batches). I kept upgrading, from 2.1.5, through 2.2.5 hoping that the > errors would go away. Now, my ignorance being point out, it turned out > that the errors were actually heat-induced. Another interesting cause for problems is duff powersupplies. As the proverb goes "every machine is as good as it's PSU". E.g. I just struggeled with a DLT tape unit that inexplicable reset itself. After examining the 5Volts rail with a scope I found glitches on it whenever the drive did a bit of rewinding (dropping out of streaming mode). Had me stumped for a while. W/ -- | / o / / _ Arnhem, The Netherlands - The FreeBSD Project |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 14:41:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 83F2A14A0A for ; Sun, 5 Dec 1999 14:41:49 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.8.7/8.8.7) with ESMTP id OAA14911; Sun, 5 Dec 1999 14:42:55 -0800 Date: Sun, 5 Dec 1999 14:42:55 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Wilko Bulte Cc: Kelly Yancey , jkh@zippy.cdrom.com, dseg@texar.com, billf@chc-chimes.com, rfg@monkeys.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Strange SCSI sickness In-Reply-To: <199912052150.WAA74217@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Another interesting cause for problems is duff powersupplies. As the > proverb goes "every machine is as good as it's PSU". E.g. I just struggeled > with a DLT tape unit that inexplicable reset itself. After examining the > 5Volts rail with a scope I found glitches on it whenever the drive did a > bit of rewinding (dropping out of streaming mode). Had me stumped for a > while. > That's pretty rare these days. It used to happen all the time when switching power supplies first appeared (motorboating is what we called it), but even recently I had a marginal supply that supplied 4.4VDC- *just* enough to function *most* of the time. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 14:46:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from monkeys.com (i180.value.net [206.14.136.180]) by hub.freebsd.org (Postfix) with ESMTP id 52EAE14A15 for ; Sun, 5 Dec 1999 14:46:21 -0800 (PST) (envelope-from rfg@monkeys.com) Received: from monkeys.com (localhost [127.0.0.1]) by monkeys.com (8.9.3/8.9.3) with ESMTP id OAA22947 for ; Sun, 5 Dec 1999 14:46:21 -0800 (PST) To: freebsd-hackers@FreeBSD.ORG Subject: Re: Strange SCSI sickness In-reply-to: Your message of Sun, 05 Dec 1999 16:15:51 -0500. Date: Sun, 05 Dec 1999 14:46:20 -0800 Message-ID: <22945.944433980@monkeys.com> From: "Ronald F. Guilmette" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Kelly Yancey wrote: >> >> 3b) Examination of the drive(s) in question for any cooling or >> mounting deficiencies. Depending on the SCSI errors in question, >> I might even investigate firmware updates for the drive(s). >> > > I actually used to get these *exact* errors a couple of years ago on >various 2.x systems. At first, I had assumed a bug in the driver (the ahc >driver was noted as still having some bugs at the time, if I recall >correctly). The errors would rare (every month or so, but they would come >in batches). I kept upgrading, from 2.1.5, through 2.2.5 hoping that the >errors would go away. Now, my ignorance being point out, it turned out >that the errors were actually heat-induced. > I had 2 5-year old 7200RPM drives in each of the systems, that besides >being noisy, got pretty hot. Of course, they weren't hot when I mounted >them :), and I had mounted them right next to each other in the case. >It helped a little when I spaced the drives apart from each other. Then >I found these neat full-length expansion cards which have 2 fans mounted >on them. Got that situated to circulate additional air across the drives >and never had any problem since (those systems have been running for over >a year since without incident). Yowza. I found two web sites recently where a nice veriety of different types of useful cooling devices (mostly for PeeCee type systems) are available: http://www.3dcool.com/ and: http://www.icedmocha.com/ I bought two ``slot fans'' from www.icedmocha.com recently, and I think I'm sure now where one of those two fans is going. :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 14:53:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (Postfix) with ESMTP id 7F7B914CEC for ; Sun, 5 Dec 1999 14:53:33 -0800 (PST) (envelope-from brdean@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.28]) by lamb.sas.com (8.9.3/8.9.1) with SMTP id RAA13787; Sun, 5 Dec 1999 17:52:59 -0500 (EST) Received: from dean.pc.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA27532; Sun, 5 Dec 1999 17:52:29 -0500 Received: (from brdean@localhost) by dean.pc.sas.com (8.9.3/8.9.3) id RAA66212; Sun, 5 Dec 1999 17:52:28 -0500 (EST) (envelope-from brdean) From: Brian Dean Message-Id: <199912052252.RAA66212@dean.pc.sas.com> Subject: Re: natd is jumpy In-Reply-To: <17505.944347628@monkeys.com> from "Ronald F. Guilmette" at "Dec 4, 1999 02:47:08 pm" To: rfg@monkeys.com (Ronald F. Guilmette) Date: Sun, 5 Dec 1999 17:52:28 -0500 (EST) Cc: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, > >and disable natd and the firewall code, these delays go away so I am > >assuming that it is natd/firewall/divert that is responsible for this > >delay. > > I think that is a bad assumption. [snip] > I'm running FreeBSD 3.3 with IPFIREWALL, IPDIVERT, and natd also over a > 56k modem, and I _never_ have seen the kind of slow echo effect you > are speaking of, except on very rare occasions when _somebody_ between > me and whichever machine I'm talking to happens to be dropping a lot of > packets. And obviously, in those cases, it ain't the fault of my FreeBSD > box. > > >Is there a parameter or anything that I can tune to eliminate or > >reduce this affect? > > But seriously, next time it happens, try doing some pings to the remote > system that you are telnetting to. Look for dropped packets. Doing a > couple of traceroutes to the remote system from your location might pro- > vide some useful info also. OK, here's a little snippet from 'ping': [bsd@vger]:/conf- ping dean PING dean (10.26.2.60): 56 data bytes 64 bytes from 10.26.2.60: icmp_seq=0 ttl=252 time=3146.649 ms 64 bytes from 10.26.2.60: icmp_seq=1 ttl=252 time=2172.951 ms 64 bytes from 10.26.2.60: icmp_seq=2 ttl=252 time=1184.808 ms 64 bytes from 10.26.2.60: icmp_seq=3 ttl=252 time=198.578 ms 64 bytes from 10.26.2.60: icmp_seq=4 ttl=252 time=1725.051 ms 64 bytes from 10.26.2.60: icmp_seq=5 ttl=252 time=737.457 ms 64 bytes from 10.26.2.60: icmp_seq=6 ttl=252 time=128.368 ms 64 bytes from 10.26.2.60: icmp_seq=7 ttl=252 time=127.593 ms 64 bytes from 10.26.2.60: icmp_seq=8 ttl=252 time=160.611 ms 64 bytes from 10.26.2.60: icmp_seq=9 ttl=252 time=148.561 ms 64 bytes from 10.26.2.60: icmp_seq=10 ttl=252 time=138.905 ms 64 bytes from 10.26.2.60: icmp_seq=11 ttl=252 time=194.196 ms 64 bytes from 10.26.2.60: icmp_seq=12 ttl=252 time=226.685 ms 64 bytes from 10.26.2.60: icmp_seq=13 ttl=252 time=1194.855 ms 64 bytes from 10.26.2.60: icmp_seq=14 ttl=252 time=127.343 ms 64 bytes from 10.26.2.60: icmp_seq=15 ttl=252 time=138.772 ms No dropped packets, but definitely some occasional long delays before I get the echo. However, I must concede, based on other respondants, that something else must be going on and I cannot necessarily attribute this to divert/firewall/natd. However, the above numbers don't really illustrate the long response times that I experience while typing at the shell prompt, or in elm. It's really frustrating. I have an external US Robotics Sportster modem and I can see the rx/tx leds which are both off during the times when there was a delay, so I can confirm that there was no other line-contention on my end. Currently, I am connected from my home into work via a ppp link. I notice the delays primarily when connected into work. Here's a traceroute from my home machine to my work machine: [bsd@vger]:/bsd- traceroute dean traceroute to dean (10.26.2.60), 30 hops max, 40 byte packets 1 R09d016Rb410nc0.net.sas.com (172.16.0.1) 120.659 ms 139.603 ms 121.679 ms 2 R01r025Rb319nc0.net.sas.com (172.25.1.2) 116.139 ms 113.945 ms 119.767 ms 3 R42axxxRb319nc0.net.sas.com (10.19.0.3) 118.763 ms 125.350 ms 184.147 ms 4 dean (10.26.2.60) 132.987 ms 119.363 ms 120.193 ms Using netstat, I see 6 input errors on my ppp0 interface. I can't account for the cause of these, maybe they are a clue: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ppp0 1500 68826 6 73148 0 0 ppp0 1500 172.16 brdean 68826 6 73148 0 0 Thanks for the suggestions. I'll keep looking. -Brian -- Brian Dean brdean@unx.sas.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 15:11: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 6480314C2F for ; Sun, 5 Dec 1999 15:11:04 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id SAA86846; Sun, 5 Dec 1999 18:07:06 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Sun, 5 Dec 1999 18:12:51 -0500 To: Robert Watson , Assar Westerlund From: Garance A Drosihn Subject: Re: Portable way to compare struct stat's? Cc: Wes Peters , Randell Jesup , freebsd-hackers@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 3:17 PM -0500 12/4/99, Robert Watson wrote: >On 4 Dec 1999, Assar Westerlund wrote: > > > Garance A Drosihn writes: > > > In the case of AFS, I think you'd want to expand the size of st_dev. > > > All files in an AFS volume are "one device", I would think. If the > > > "device" is gone (ie, the volume is not mounted), then all files in > > > that "device" (volume) will not be available. > > > > I'm confused. Did you mean `st_ino' there? I agree that you want to > > see the whole AFS space as a single device. > >I agree. Well, I'm happy to have it that way if everyone prefers that, but I really did mean to suggest that each AFS volume would be a separate device. Not "all of AFS" as one device, or even "all of one AFS cell" as one device. Do we have one device for "all NFS filesystems from all hosts"? (my assumption is "no", but maybe I'm wrong (*)). In local filesystems, a device is a partition on one hard disk. That one partition could be unavailable (ie, "not mounted"), in which case all files in that partition are not available. In AFS, the "mountable quantity" is a volume. You can mount the same volume in multiple places in AFS-land, in fact. If there's an AFS problem, you can be in a situation where "most" of an AFS cell is up, but particular volumes are not available because they are being salvaged. To me, all of this seems to indicate that AFS volumes are pretty analogous to what are used for devices on a local file system. But really, any way we could arrange it would be fine with me... (*) - I'm told that SGI's claim that all mounts (except lofs) will have a unique st_dev, including NFS mounts. On the other hand, I'm also told that linux seems to use the same st_dev value for all NFS mounts from a given host. In my mind, the linux behavior would suggest one st_dev value per AFS cell... --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 15:13:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id E7D3B14CA4 for ; Sun, 5 Dec 1999 15:13:42 -0800 (PST) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id RAA21154 for freebsd-hackers@freebsd.org; Sun, 5 Dec 1999 17:13:41 -0600 (CST) From: Mohit Aron Message-Id: <199912052313.RAA21154@cs.rice.edu> Subject: new Intel 100Mbps card To: freebsd-hackers@freebsd.org Date: Sun, 5 Dec 1999 17:13:41 -0600 (CST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I got some new Intel 10/100Mbps network interfaces recently, but unfortunately found that FreeBSD (version 4.0-19990827-CURRENT) doesn't recognize them. These are called the "Intel InBusiness 10/100 PCI Network Adaptor". Unfortunately, these are the only ones supported in the stores now, so I can't find the older 10/100+ and 10/100B kind. After looking at the boot messages, I found that these cards have a device_id of 0x1030 - which is different than the one supported by the fxp driver in FreeBSD (0x1229 - defined in /sys/pci/if_fxpreg.h as FXP_DEVICEID_i82557). I changed the driver (fxp_probe() function in /sys/pci/if_fxp.c) to also recognize the device_id 0x1030. The cards now work, but I haven't stress tested them for performance. Can someone tell me if the fxp driver is compatible with these cards (at least it seems to work). If so, it'll be nice if the future releases of the driver also support this card. - Mohit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 15:28:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from arnold.neland.dk (mail.neland.dk [194.255.12.232]) by hub.freebsd.org (Postfix) with ESMTP id 2948E14DC4 for ; Sun, 5 Dec 1999 15:28:31 -0800 (PST) (envelope-from leifn@neland.dk) Received: from gina (gina.neland.dk [192.168.0.14]) by arnold.neland.dk (8.9.3/8.9.3) with SMTP id AAA80303; Mon, 6 Dec 1999 00:28:09 +0100 (CET) (envelope-from leifn@neland.dk) Message-ID: <026001bf3f78$9090d720$0e00a8c0@neland.dk> Reply-To: "Leif Neland" From: "Leif Neland" To: "Dan Seguin" Cc: References: Subject: Sv: Strange SCSI sickness Date: Mon, 6 Dec 1999 00:28:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >=20 > If it already hasn't been done, we should capture the procedure that > Jordan posted, added to by Matt and maybe post it to the = troubleshooting > part of the guide(s). >=20 >=20 > Unlike some of us who've been fooling with computers since pre-1985, = this > standard operating procedure may not be second nature. >=20 Perhaps the order of checking could be weighted(sp?) against the price = of equipment, eg feeling the temperature of the drive before replacing a = $0.50 termpwr fuse before replacing $xx cable or a $xxx diskdrive... Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 17: 8:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (castles536.castles.com [208.214.165.100]) by hub.freebsd.org (Postfix) with ESMTP id 83A3E14D03 for ; Sun, 5 Dec 1999 17:08:45 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id RAA09520; Sun, 5 Dec 1999 17:10:21 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912060110.RAA09520@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Ed Hall Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-reply-to: Your message of "Sun, 05 Dec 1999 11:44:57 PST." <199912051944.LAA17720@screech.weirdnoise.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 05 Dec 1999 17:10:20 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On a recent project I encountered two show-stopping bugs with 3.3-release > that did not exist in 2.2.8-release: > > 1) Random crashes in FXP interrupt or low-level IP code. Something is > clobbering the kernel stack--possibly the NCR driver, since using an > Adaptec made the problem stop, as did a backport of the CAM driver > Peter Wemm tried. This was on an N440BX, which is becoming quite > common in server applications. Other installations are apparantly > seeing the same problem on this hardware. So far the problem appears to require a combination of the 440BX chipset, an Intel EtherExpress and the 'fxp' driver, and an NCR/Symbios/LSI SCSI adapter and either the 'ncr' or 'sym' driver. We've tried on a number of occasions to diagnose this problem, but there have been many issues that have prevented it's resolution. These have included lack of interest on the driver developers' parts, lack of access to or cooperation from people complaining of the bug, and an inability to reproduce it in a useful fashion. It's been an eye-opening exercise and we're trying to learn what we can from it, as well as actually fix it for good. > 2) A hard loop in the pagedaemon. This was especially egregious, since > it meant the system had to be rebooted from the console--and since > the application could elicit the problem within a few minutes. > Disabling the use of mmap() for file update in the application > prevented the problem. After spending a day trying to cook up a > test program that elicited the same behavior that the application > did, I gave up for lack of time. But there have been other reports > of late that sound like this problem, mostly in high VM/RAM situations. > > That's two serious bugs that exist in 3.3-release but not in 2.2.8-release. > Looking back through the archives, I can see that I'm not the only one who > has experienced them. I came away from the experience with the feeling that > the FreeBSD project has some serious Q/A problems... and I can assure you, > I'm not alone in this feeling. Neither are we. But, since FreeBSD is a volunteer-developed project, and since you admit above that you have contributed to the lack of QA, I'm not entirely sure what your point is. We need this feedback in a timely fashion in order to do something with it. 3 months after a release is not "timely" by any stretch of the imagination, and without that sort of assistance, I have no idea what you think we can do to improve the situation. Yes, we want to improve our QA. But when customers come up months after the fact and complain about something that we could never possibly have either known or even guessed about during the development process, the best we can do is try to fix the problem then and there. If you want to improve that situation, you can; in your position you have plenty of opportunities to make a major contribution to the overall quality of FreeBSD releases. OTOH, if you choose not to do so, it's mere honesty to observe that you need to take a share of the blame for the current situation. ps: The N440BX is actually being phased out, however there are very large numbers of them still in production, yes. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 17:17:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id A55C614BDA for ; Sun, 5 Dec 1999 17:17:27 -0800 (PST) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id RAA77164; Sun, 5 Dec 1999 17:15:25 -0800 (PST) From: Archie Cobbs Message-Id: <199912060115.RAA77164@bubba.whistle.com> Subject: Re: natd is jumpy In-Reply-To: <199912052252.RAA66212@dean.pc.sas.com> from Brian Dean at "Dec 5, 1999 05:52:28 pm" To: brdean@unx.sas.com (Brian Dean) Date: Sun, 5 Dec 1999 17:15:25 -0800 (PST) Cc: rfg@monkeys.com (Ronald F. Guilmette), freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian Dean writes: > No dropped packets, but definitely some occasional long delays before > I get the echo. However, I must concede, based on other respondants, > that something else must be going on and I cannot necessarily > attribute this to divert/firewall/natd. > > However, the above numbers don't really illustrate the long response > times that I experience while typing at the shell prompt, or in elm. > It's really frustrating. > > I have an external US Robotics Sportster modem and I can see the rx/tx > leds which are both off during the times when there was a delay, so I > can confirm that there was no other line-contention on my end. Could be you have a noisy line and your modem error correction is kicking in. Try configuring your modem to disable error correction and see if it changes things. This is consistent with your rx/tx lights -- typically they only light up when there's traffic on the serial line (not the telephone line). -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 17:23:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id DAC4A14C86 for ; Sun, 5 Dec 1999 17:23:46 -0800 (PST) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) with ESMTP id RAA15831; Sun, 5 Dec 1999 17:52:57 -0800 (PST) Date: Sun, 5 Dec 1999 17:52:57 -0800 (PST) From: Alfred Perlstein To: Matthew Dillon Cc: hackers@freebsd.org Subject: vfs_bio questions/nfs cluster commit Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've been trying to workout mega-clusters for NFS, since afaik the vfs_cluster code will only do 64k chunks and we can benifit greatly by compacting ranges for commit RPCs. The problem, is that it seems that NFS has been having issues, doing large appends on my box (lptest 80 100000 > /nfsmount/foo) seems to just get stuck even without my new code. Is anyone else having this problem on a recent -current? It seems that taking out the sync rpc commit in nfs_writebp may have been a mistake, it appears that it allows a buffer that _must_ be free'd to be delayed for commit, i'm not sure if the code makes sure that the buffer is written sync if we need it to be? I'm not sure it's ok to do this becasue afaik a written but uncommitted bp is marked as delay-write? (B_DELWRI) We don't really get our buffers back until a buffer is committed. Anyhow back to the commit clustering.. Does anyone want to take a look at this? When a buffer is scheduled to be committed from nfs_doio() the nfs_cluster_commit() function trys to find adjacent buffers and include them in one giant mega-commit, then it frees the buffers. Last thing, the paranioa check in nfs_subr.c looks bogus because we are at splbio(), or is it essential that this check be done? XXX: this code _almost_ works :) Index: nfs_bio.c =================================================================== RCS file: /home/ncvs/src/sys/nfs/nfs_bio.c,v retrieving revision 1.80 diff -u -u -r1.80 nfs_bio.c --- nfs_bio.c 1999/10/29 18:09:11 1.80 +++ nfs_bio.c 1999/12/06 05:01:33 @@ -62,6 +62,8 @@ #include #include +static int nfs_cluster_commit __P((struct vnode *vp, struct buf *bp, + struct proc *p)); static struct buf *nfs_getcacheblk __P((struct vnode *vp, daddr_t bn, int size, struct proc *p)); @@ -1006,6 +1008,10 @@ nmp = VFSTONFS(mp); if (nmp->nm_flag & NFSMNT_INT) { + /* + * don't spin on signals not applicable to interupting an + * NFS operation, try short term non-interuptable requests + */ bp = getblk(vp, bn, size, PCATCH, 0); while (bp == (struct buf *)0) { if (nfs_sigintr(nmp, (struct nfsreq *)0, p)) @@ -1347,27 +1353,9 @@ /* * If we only need to commit, try to commit */ - if (bp->b_flags & B_NEEDCOMMIT) { - int retv; - off_t off; - - off = ((u_quad_t)bp->b_blkno) * DEV_BSIZE + bp->b_dirtyoff; - bp->b_flags |= B_WRITEINPROG; - retv = nfs_commit( - bp->b_vp, off, bp->b_dirtyend-bp->b_dirtyoff, - bp->b_wcred, p); - bp->b_flags &= ~B_WRITEINPROG; - if (retv == 0) { - bp->b_dirtyoff = bp->b_dirtyend = 0; - bp->b_flags &= ~B_NEEDCOMMIT; - bp->b_resid = 0; - biodone(bp); + if (bp->b_flags & B_NEEDCOMMIT && + nfs_cluster_commit(vp, bp, p) == 0) return (0); - } - if (retv == NFSERR_STALEWRITEVERF) { - nfs_clearcommit(bp->b_vp->v_mount); - } - } /* * Setup for actual write @@ -1460,4 +1448,172 @@ nfs_clearcommit(vp->v_mount); biodone(bp); return (error); +} + +/* + * nfs_cluster_commit(vp, bp, p) + * + * This function is called on a NFS buffer that needs a commit RPC + * Even though the buffer may already be clustered, clustering is limited + * to 64k chunks, try to grab an even bigger range by scanning forward and + * backward in the file. + */ +static int +nfs_cluster_commit(vp, bp, p) + struct vnode *vp; + struct buf *bp; + struct proc *p; +{ + struct buf *cbufs[16], *holdbp; + int commit_idx, retv, flags, pass, i, dirty_off, dirty_end, s, gap; + int pre_count=0, post_count=0; + u_quad_t sblkno, eblkno, lblkno; + /* start, end, logical block number */ + + KASSERT(bp->b_flags & B_NEEDCOMMIT, ("NFS commit without B_NEEDCOMMIT")); + + flags = B_DELWRI | B_NEEDCOMMIT; + gap = 0; + commit_idx = 0; + pass = 0; + sblkno = eblkno = (u_quad_t)bp->b_blkno; + dirty_end = bp->b_dirtyend; + dirty_off = bp->b_dirtyoff; + + s = splbio(); + /* + * first pass scan forward, second backwards from bp + */ +pass: + lblkno = bp->b_blkno; + holdbp = bp; + + /* + * don't scan too much and don't overflow buf pointer array + */ + while (gap < 4 && commit_idx < (sizeof(cbufs)/sizeof(cbufs[0]))) { + + /* scan forward or backward */ + if (pass == 1) { /* backwards */ + /* + * backwards is easy just subtracting one from the lbn + * should get us the previous buffer if it exists + */ + if (lblkno == 0) + break; + else + lblkno--; + } else { + /* + * when going forward make sure to remeber to account + * for buffers that span more than one block + * if holdbp == NULL then gbincore() failed, try + * going forward only a single block + */ + if (lblkno == (u_quad_t)-1) + break; + else if (holdbp == NULL) + lblkno++; + else + lblkno += holdbp->b_bufsize / DEV_BSIZE; + } + + /* + * if the buffer isn't in memory bump the gap count + * and try the next one + */ + holdbp = gbincore(vp, lblkno); + if (holdbp == NULL) { + gap++; + continue; + } + lblkno = holdbp->b_blkno; + + /* + * make sure flags and cred are the same as the first buffer + * also make sure we can lock the buffer + * if not we have to escape the loop + */ + if (((holdbp->b_flags & flags) != flags) || + holdbp->b_wcred != bp->b_wcred || + BUF_LOCK(holdbp, LK_EXCLUSIVE)) + break; + + gap = 0; /* scan more */ + + bremfree(holdbp); /* buffer accounting */ + + holdbp->b_flags |= B_WRITEINPROG; + vfs_busy_pages(holdbp, 1); + cbufs[ commit_idx++ ] = holdbp; + if (pass == 1) { + /* going backwards so set start block and offset */ + sblkno = lblkno; + dirty_off = holdbp->b_dirtyoff; + ++pre_count; + } else { + /* going forward so set end block and end pointer */ + eblkno = lblkno; + dirty_end = holdbp->b_dirtyend; + ++post_count; + } + } + gap = 0; + if (++pass == 1) + goto pass; + + splx(s); + + retv = nfs_commit(bp->b_vp, + sblkno * DEV_BSIZE + dirty_off, + (eblkno - sblkno) * DEV_BSIZE + dirty_end, + bp->b_wcred, p); + + printf("nfs commit @%lld %d bytes, behind bufs = %d, forward bufs = %d\n", + sblkno * DEV_BSIZE + dirty_off, + (int)(eblkno - sblkno) * DEV_BSIZE + dirty_end, + pre_count, post_count); + + for (i = 0; i < commit_idx; i++) { + holdbp = cbufs[i]; + holdbp->b_flags &= ~(B_WRITEINPROG|B_NEEDCOMMIT); + if (retv) { + /* + * Error, leave B_DELWRI intact + */ + vfs_unbusy_pages(holdbp); + brelse(holdbp); + } else { + /* + * Success, remove B_DELWRI ( bundirty() ). + * + * b_dirtyoff/b_dirtyend seem to be NFS + * specific. We should probably move that + * into bundirty(). XXX + */ + s = splbio(); + vp->v_numoutput++; + holdbp->b_flags |= B_ASYNC; + bundirty(holdbp); + holdbp->b_flags &= ~(B_READ|B_DONE|B_ERROR); + holdbp->b_dirtyoff = holdbp->b_dirtyend = 0; + holdbp->b_resid = 0; + splx(s); + biodone(holdbp); + } + } + bp->b_flags &= ~B_WRITEINPROG; + if (retv == 0) { + bp->b_dirtyoff = bp->b_dirtyend = 0; + bp->b_flags &= ~B_NEEDCOMMIT; + bp->b_resid = 0; + biodone(bp); + return (0); + } + + if (retv == NFSERR_STALEWRITEVERF) + nfs_clearcommit(bp->b_vp->v_mount); + + return (retv); + } Index: nfs_subs.c =================================================================== RCS file: /home/ncvs/src/sys/nfs/nfs_subs.c,v retrieving revision 1.85 diff -u -u -r1.85 nfs_subs.c --- nfs_subs.c 1999/10/03 12:18:26 1.85 +++ nfs_subs.c 1999/12/04 18:12:38 @@ -2156,18 +2156,14 @@ nfs_clearcommit(mp) struct mount *mp; { - register struct vnode *vp, *nvp; - register struct buf *bp, *nbp; + register struct vnode *vp; + register struct buf *bp; int s; s = splbio(); loop: - for (vp = mp->mnt_vnodelist.lh_first; vp; vp = nvp) { - if (vp->v_mount != mp) /* Paranoia */ - goto loop; - nvp = vp->v_mntvnodes.le_next; - for (bp = TAILQ_FIRST(&vp->v_dirtyblkhd); bp; bp = nbp) { - nbp = TAILQ_NEXT(bp, b_vnbufs); + LIST_FOREACH(vp, &mp->mnt_vnodelist, v_mntvnodes) { + TAILQ_FOREACH(bp, &vp->v_dirtyblkhd, b_vnbufs) { if (BUF_REFCNT(bp) == 0 && (bp->b_flags & (B_DELWRI | B_NEEDCOMMIT)) == (B_DELWRI | B_NEEDCOMMIT)) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 17:30:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 4B77D14F6F for ; Sun, 5 Dec 1999 17:30:11 -0800 (PST) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) with ESMTP id RAA15947; Sun, 5 Dec 1999 17:59:21 -0800 (PST) Date: Sun, 5 Dec 1999 17:59:21 -0800 (PST) From: Alfred Perlstein To: Matthew Dillon Cc: hackers@FreeBSD.ORG Subject: Re: vfs_bio questions/nfs cluster commit In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG oh, one more thing... (replying to myself) On Sun, 5 Dec 1999, Alfred Perlstein wrote: > > I've been trying to workout mega-clusters for NFS, since afaik the > vfs_cluster code will only do 64k chunks and we can benifit greatly > by compacting ranges for commit RPCs. My code seems to have the strange side-effect that it also fixes normal commit clustering for NFS which afaik is broken. can anyone confirm this? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 18:20:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 0C19C14EE0 for ; Sun, 5 Dec 1999 18:20:09 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id SAA15209; Sun, 5 Dec 1999 18:19:02 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id SAA24310; Sun, 5 Dec 1999 18:19:02 -0800 Received: from softweyr.com ([204.68.178.39]) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA22264; Sun, 5 Dec 99 18:18:51 PST Message-Id: <384B1D25.DFAF198E@softweyr.com> Date: Sun, 05 Dec 1999 19:19:17 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Nick Hibma Cc: Doug Barton , freebsd-hackers@FreeBSD.ORG Subject: Re: Basic question about threads and SMP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nick Hibma wrote: > > Being multi-threaded has almost nothing to do with being > multi-processor. Multi-threading means that your application has > multiple threads of execution that are able to run simultaneously. > > The multi-processing capability of your box means that 2 threads of > execution, be it a process or a thread within a process, are executed > _literally_ at the same time, and not in simulated concurrency like it > happens on a UP box. Note that this happens ONLY if both threads of execution are processor mobile. If your system supports user-space threads as part of a process and the process can't be split across CPUs, you might as well have a UP system. (Except everything else can run on the other processor, so SMP is still a small win.) This is the situation with threads and SMP in -current. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 18:38:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 0A2A214EE0 for ; Sun, 5 Dec 1999 18:38:53 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id SAA15278; Sun, 5 Dec 1999 18:38:50 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id SAA24569; Sun, 5 Dec 1999 18:38:50 -0800 Received: from softweyr.com ([204.68.178.39]) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA22557; Sun, 5 Dec 99 18:38:47 PST Message-Id: <384B21D1.415FD524@softweyr.com> Date: Sun, 05 Dec 1999 19:39:13 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Mohit Aron Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: new Intel 100Mbps card References: <199912052313.RAA21154@cs.rice.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mohit Aron wrote: > > Hi, > I got some new Intel 10/100Mbps network interfaces recently, but > unfortunately found that FreeBSD (version 4.0-19990827-CURRENT) doesn't > recognize them. These are called the "Intel InBusiness 10/100 PCI Network > Adaptor". Unfortunately, these are the only ones supported in the stores now, > so I can't find the older 10/100+ and 10/100B kind. > > After looking at the boot messages, I found that these cards have a device_id > of 0x1030 - which is different than the one supported by the fxp driver in > FreeBSD (0x1229 - defined in /sys/pci/if_fxpreg.h as FXP_DEVICEID_i82557). It's probably an 82558 chip. Does it support Wake-on-LAN? > I changed the driver (fxp_probe() function in /sys/pci/if_fxp.c) to also > recognize the device_id 0x1030. The cards now work, but I haven't stress tested > them for performance. > > Can someone tell me if the fxp driver is compatible with these cards (at least > it seems to work). If so, it'll be nice if the future releases of the driver > also support this card. Add the device IDs to the list in the driver and recompile. If it works, send me the diffs and I'll commit it for you. I might even be able to beat one of the cards out of Intel, I used to work for the InBusiness (formerly Dayna Communications) crowd. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 18:43: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id EC66D14EE0; Sun, 5 Dec 1999 18:42:33 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id SAA15286; Sun, 5 Dec 1999 18:41:58 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id SAA24610; Sun, 5 Dec 1999 18:41:57 -0800 Received: from softweyr.com ([204.68.178.39]) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA22609; Sun, 5 Dec 99 18:41:55 PST Message-Id: <384B228D.FFE9728@softweyr.com> Date: Sun, 05 Dec 1999 19:42:21 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Matthew Dillon Cc: Kris Kennaway , freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) References: <199912050514.VAA58998@apollo.backplane.com> <3849FD95.F0434263@softweyr.com> <199912050646.WAA59445@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > : > :All running software has serious problems, that's why it is never considered > :done. Taking the time to enumerate specific problems that are currently > :plaguing an installation is the only way anyone can possibly hope to help. > :Problems reports of "It don't work" are helpful to absolutely noone. > > This simply isn't true. I have written plenty of software (large > projects) that do not have serious problems and, in fact, some do not > have any known problems at all. I have written several operating systems > and one of them is least as complex as the FreeBSD core (but not as > complex if you count drivers) which are bug-free (that is, there have > been no recorded crashes and except for feature updates have never been > rebooted). So you haven't discovered the rest of the bugs in the system. Software is created by humans, and humans are fallible, therefore the software is also fallible. Any claims of divinity on your part will be summarily rejected. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 18:50: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cairo.anu.edu.au (cairo.anu.edu.au [150.203.224.11]) by hub.freebsd.org (Postfix) with ESMTP id CB98A14BC4 for ; Sun, 5 Dec 1999 18:50:00 -0800 (PST) (envelope-from avalon@cairo.anu.edu.au) Received: (from avalon@localhost) by cairo.anu.edu.au (8.9.3/8.9.3) id NAA16461 for hackers@freebsd.org; Mon, 6 Dec 1999 13:51:20 +1100 (EST) From: Darren Reed Message-Id: <199912060251.NAA16461@cairo.anu.edu.au> Subject: 3c589d w/ freebsd 3.3 works badly. To: hackers@freebsd.org Date: Mon, 6 Dec 1999 13:51:20 +1100 (Australia/NSW) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG How reliable should the ep0 driver be with 3c389d pcmcia cards ? It gets detected by pccardd without any problems and a driver is attached to it, but I'm not getting much in the way of performance from it with "link2" selected for UTP (doesn't work with "media 10baset/utp"). It's being used in conjunction with cardbus on a gateway solo 9100. I suspect that it isn't getting interrupted properly, although nothing is telling me what IRQ is being given to it. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 18:57:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cairo.anu.edu.au (cairo.anu.edu.au [150.203.224.11]) by hub.freebsd.org (Postfix) with ESMTP id 07DF214A05 for ; Sun, 5 Dec 1999 18:57:08 -0800 (PST) (envelope-from avalon@cairo.anu.edu.au) Received: (from avalon@localhost) by cairo.anu.edu.au (8.9.3/8.9.3) id NAA17727 for hackers@freebsd.org; Mon, 6 Dec 1999 13:58:29 +1100 (EST) From: Darren Reed Message-Id: <199912060258.NAA17727@cairo.anu.edu.au> Subject: ejecting card with 3.3 causes hang ? To: hackers@freebsd.org Date: Mon, 6 Dec 1999 13:58:29 +1100 (Australia/NSW) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ejecting a modem pcmcia card caused 3.3 to do the following: /kernel: sio2 unload,gone /kernel: Return IRQ=11 /kernel: Card removed, slot 1 /kernel: Card inserted, slot 0 and then it was frozen. Will there be a 3.4 with things like this fixed ? Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 19: 7:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id BCC7814A05 for ; Sun, 5 Dec 1999 19:07:56 -0800 (PST) (envelope-from rcarter@pinyon.org) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id UAA14254; Sun, 5 Dec 1999 20:07:16 -0700 (MST) Received: from ip-83-085.prc.primenet.com(207.218.83.85), claiming to be "pinyon.org" via SMTP by smtp03.primenet.com, id smtpdAAAeHaaZB; Sun Dec 5 20:07:08 1999 Received: from chomsky.Pinyon.ORG (localhost [127.0.0.1]) by pinyon.org (Postfix) with ESMTP id A376248; Sun, 5 Dec 1999 20:07:40 -0700 (MST) X-Mailer: exmh version 2.1.0 09/18/1999 To: Wes Peters Cc: Nick Hibma , Doug Barton , freebsd-hackers@FreeBSD.ORG, rcarter@pinyon.org Subject: Re: Basic question about threads and SMP In-Reply-To: Your message of "Sun, 05 Dec 1999 19:19:17 MST." <384B1D25.DFAF198E@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 05 Dec 1999 20:07:40 -0700 From: "Russell L. Carter" Message-Id: <19991206030740.A376248@pinyon.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG %Nick Hibma wrote: %> %> Being multi-threaded has almost nothing to do with being %> multi-processor. Multi-threading means that your application has %> multiple threads of execution that are able to run simultaneously. %> %> The multi-processing capability of your box means that 2 threads of %> execution, be it a process or a thread within a process, are executed %> _literally_ at the same time, and not in simulated concurrency like it %> happens on a UP box. % %Note that this happens ONLY if both threads of execution are processor %mobile. If your system supports user-space threads as part of a %process and the process can't be split across CPUs, you might as well %have a UP system. (Except everything else can run on the other %processor, so SMP is still a small win.) % %This is the situation with threads and SMP in -current. % The LinuxThreads port is currently busted for SMP but when it is fixed it will indeed use multiple processors: last pid: 395; load averages: 0.50, 0.11, 0.04 up 0+00:13:00 20:00:40 37 processes: 6 running, 31 sleeping CPU states: 65.8% user, 0.0% nice, 0.0% system, 0.0% interrupt, 34.2% idle Mem: 8780K Active, 9116K Inact, 19M Wired, 68K Cache, 7000K Buf, 466M Free Swap: 1024M Total, 1024M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND 393 rcarter 31 0 876K 152K CPU1 1 0:01 17.16% 2.39% ex3 394 rcarter 29 0 876K 152K RUN 0 0:00 15.76% 2.20% ex3 391 rcarter 30 0 876K 152K RUN 1 0:01 14.71% 2.05% ex3 395 rcarter 30 0 876K 152K RUN 0 0:01 14.01% 1.95% ex3 392 rcarter 30 0 876K 152K RUN 0 0:00 13.66% 1.90% ex3 Russell %-- % "Where am I, and what am I doing in this handbasket?" % %Wes Peters Softweyr LLC %wes@softweyr.com http://softweyr.com/ % % %To Unsubscribe: send mail to majordomo@FreeBSD.org %with "unsubscribe freebsd-hackers" in the body of the message % To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 19:36:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from screech.weirdnoise.com (209-128-78-198.bayarea.net [209.128.78.198]) by hub.freebsd.org (Postfix) with ESMTP id 8E24314E1E; Sun, 5 Dec 1999 19:36:30 -0800 (PST) (envelope-from edhall@screech.weirdnoise.com) Received: from screech.weirdnoise.com (localhost [127.0.0.1]) by screech.weirdnoise.com (8.8.7/8.8.7) with ESMTP id TAA22053; Sun, 5 Dec 1999 19:37:45 -0800 Message-Id: <199912060337.TAA22053@screech.weirdnoise.com> X-Mailer: exmh version 2.0.2 To: Mike Smith Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-Reply-To: Your message of "Sun, 05 Dec 1999 17:10:20 PST." <199912060110.RAA09520@mass.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 05 Dec 1999 19:37:44 -0800 From: Ed Hall Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike, So I'm to blame that my project schedule didn't happen to coincide with the FreeBSD release schedule? Give me a break. The project hasn't even gone into production yet. And I think you'll find that your apparent assumption that no one was told about the problems is equally rash. I posted a note here, and spent a considerable amount of time working with one of the core members in outlining the problems and finding workarounds. Yahoo devoted six machines to a series of experiments to characterize the problems and seek solutions even though using 2.2.8 was always a ready option. I think you'll find that people's willingness to contribute to your "volunteer-developed project" depends upon a little forbearance and understanding on your part. Communication is neither going to be as timely nor as well-formed as you might like. Scan the archives and you'll find ample evidence for phenomena like both issues I described, but never in a form that says, "here's your bug--now fix it." If you take a defensive attitude, you'll never see such things. Believe it or not, I'm on your side. -Ed To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 19:47:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 5063114E1E for ; Sun, 5 Dec 1999 19:47:46 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id WAA15622; Sun, 5 Dec 1999 22:47:38 -0500 (EST) Date: Sun, 5 Dec 1999 22:47:37 -0500 (EST) From: "Matthew N. Dodd" To: Darren Reed Cc: hackers@FreeBSD.ORG Subject: Re: 3c589d w/ freebsd 3.3 works badly. In-Reply-To: <199912060251.NAA16461@cairo.anu.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 6 Dec 1999, Darren Reed wrote: > How reliable should the ep0 driver be with 3c389d pcmcia cards ? It gets > detected by pccardd without any problems and a driver is attached to it, > but I'm not getting much in the way of performance from it with "link2" > selected for UTP (doesn't work with "media 10baset/utp"). It's being > used in conjunction with cardbus on a gateway solo 9100. I suspect that > it isn't getting interrupted properly, although nothing is telling me > what IRQ is being given to it. I'm still trying to track down a watchdog timeout problem with if_ep. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 20: 9: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by hub.freebsd.org (Postfix) with ESMTP id 6C69C14CFE; Sun, 5 Dec 1999 20:09:02 -0800 (PST) (envelope-from rminnich@lanl.gov) Received: from localhost (rminnich@localhost) by acl.lanl.gov (8.8.8/8.8.5) with ESMTP id VAA467744; Sun, 5 Dec 1999 21:08:52 -0700 (MST) X-Authentication-Warning: acl.lanl.gov: rminnich owned process doing -bs Date: Sun, 5 Dec 1999 21:08:52 -0700 From: "Ronald G. Minnich" To: Chuck Youse Cc: Mike Smith , freebsd-hackers@FreeBSD.ORG Subject: Re: tmpfs .. ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry I missed this question. Check www.acl.lanl.gov/~rminnich for v9fs and see if you can use it. ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 20:26: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 26D5D14F17 for ; Sun, 5 Dec 1999 20:26:04 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.8.7/8.8.7) with ESMTP id UAA15891; Sun, 5 Dec 1999 20:27:13 -0800 Date: Sun, 5 Dec 1999 20:27:13 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Leif Neland Cc: Dan Seguin , freebsd-hackers@FreeBSD.ORG Subject: Re: Sv: Strange SCSI sickness In-Reply-To: <026001bf3f78$9090d720$0e00a8c0@neland.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 6 Dec 1999, Leif Neland wrote: > > > > > If it already hasn't been done, we should capture the procedure that > > Jordan posted, added to by Matt and maybe post it to the troubleshooting > > part of the guide(s). > > > > > > Unlike some of us who've been fooling with computers since pre-1985, this > > standard operating procedure may not be second nature. > > > > Perhaps the order of checking could be weighted(sp?) against the price > of equipment, eg feeling the temperature of the drive before replacing > a $0.50 termpwr fuse before replacing $xx cable or a $xxx diskdrive... How about using a VOM to check the fuse? > > Leif > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 20:38:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (castles554.castles.com [208.214.165.118]) by hub.freebsd.org (Postfix) with ESMTP id 112E914DF1 for ; Sun, 5 Dec 1999 20:38:55 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id UAA00678; Sun, 5 Dec 1999 20:40:48 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912060440.UAA00678@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: kvandel@cs.duke.edu Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Sun, 05 Dec 1999 16:37:38 CST." <99120516514304.01102@wookie.vandelden.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 05 Dec 1999 20:40:48 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Question, > > I am a graduate student at Duke University. Currently, I am part of a team to > build a terabit router using a cluster connected with Myrinet. One aspect of > the project is to tune the devices & drivers to perform cooperatively... In a > routing situation, the 1500B dma takes roughly 11us over PCI 32/33Mhz. If the > processor (driver) is checking the command accept status of a NIC, it can > take a "long" time to get a response from the NIC. For gigabit routing, you > have to roughly processes 1pkt/ 8-10us . For starters, I changed up the > driver code in fxp_start to break up a large dma transactions into smaller > chunks,.. to make bus arbitration work using a finer grain time slice. Hence, > the processor stalls less when it checks if a NIC command was accepted. > > The question: Why doesn't this work... it seem so straight forward... I'm not sure about the code in question, but the basic assumptions you're making about PCI's behaviour are flawed. To achieve the goal you're trying to, you need to reduce the value of the PCI bus latency timer for the peripheral(s) that you're hoping to interrupt. Breaking up the DMA transactions leaves you vulnerable to the PCI peripheral noticing that the two segments are contiguous and coalescing them again into a single master write. Also, you don't want the (high) overhead of forcing a re-arbitration all the time, rather you want to guarantee the worst-case cycle time involved in polling the peripheral. Again, to achieve this, you want to look at how the PCI bus latency timer works and use it instead. You will always get the best performance out of PCI by avoiding _anything_ that involves arbitrating for the bus. PCI bus transactions are reasonably expensive to start. 8( -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 20:39:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (castles554.castles.com [208.214.165.118]) by hub.freebsd.org (Postfix) with ESMTP id 9D43A14DF1 for ; Sun, 5 Dec 1999 20:39:11 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id UAA00732; Sun, 5 Dec 1999 20:41:04 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912060441.UAA00732@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Mohit Aron Cc: freebsd-hackers@freebsd.org Subject: Re: new Intel 100Mbps card In-reply-to: Your message of "Sun, 05 Dec 1999 17:13:41 CST." <199912052313.RAA21154@cs.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 05 Dec 1999 20:41:04 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I got some new Intel 10/100Mbps network interfaces recently, but > unfortunately found that FreeBSD (version 4.0-19990827-CURRENT) doesn't > recognize them. These are called the "Intel InBusiness 10/100 PCI Network > Adaptor". Unfortunately, these are the only ones supported in the stores now, > so I can't find the older 10/100+ and 10/100B kind. > > After looking at the boot messages, I found that these cards have a device_id > of 0x1030 - which is different than the one supported by the fxp driver in > FreeBSD (0x1229 - defined in /sys/pci/if_fxpreg.h as FXP_DEVICEID_i82557). > I changed the driver (fxp_probe() function in /sys/pci/if_fxp.c) to also > recognize the device_id 0x1030. The cards now work, but I haven't stress tested > them for performance. Bah. It sounds like an Intel ploy so that they can trivially identify these cards and put the "right" name up in the Windows network setup box. This isn't quite what the idea was with PCI IDs originally. 8( > Can someone tell me if the fxp driver is compatible with these cards (at least > it seems to work). If so, it'll be nice if the future releases of the driver > also support this card. It's probably reasonable to assume that if the driver works at all, it'll work just fine. You can help us out here by looking closely at the large funny-looking chip on the card and telling us what the part numbers on it are, since that's the only way for us to work out what the part actually is. There's quite a good chance that it's a part we already support, and all that Intel have done is change the PCI device ID in the EEPROM. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 20:39:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (castles554.castles.com [208.214.165.118]) by hub.freebsd.org (Postfix) with ESMTP id 7FA5A14FA3 for ; Sun, 5 Dec 1999 20:39:37 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id UAA00805; Sun, 5 Dec 1999 20:41:31 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912060441.UAA00805@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: mjacob@feral.com Cc: hackers@FreeBSD.ORG Subject: Re: tty level buffer overflows In-reply-to: Your message of "Sat, 04 Dec 1999 09:36:30 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 05 Dec 1999 20:41:31 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Er, you should read the sio(4) manpage too. tty-level buffer overflows > > have nothing to do with interrupt latency/execution time. > > You mean this: > > sio%d: tty-level buffer overflow. Problem in the application. Input has > arrived faster than the given module could process it and some has been > lost. Yup. Ignore the "problem in the application" part, as that predicates that the kernel and driver are working properly, which doesn't seem to be the case. The problem here is that the buffer between the top side of the driver and the application isn't being drained fast enough. It would be educational to know what the app is sleeping on when these messages are emitted; just dropping to ddb and using 'ps' would probably be enough. There has to be some reason that the process is either not being woken when data arrives, or is being held up somewhere else for long enough that the clist overflows. Does the problem still manifest with the recent scheduler changes? Perhaps the comms processes are being unfairly scheduled against for some reason? > Normally I might agree with this, but I use a tty line on a 150Mhz i386 to > be a serial console for another freebsd box. This is a NS16550A with a 16 > byte fifo. This systems is effectively idle except for this task. So, I'm > running tip and I get constant tty-level buffer overflows at 9600 baud. > > I also have a 8 (well, 6 now since I moved and one of the system boards > blew a backplane interface chip) 50 Mhz processor SS1000 running Solaris > 2.6. It has 5 Zilog (2 byte fifo) 8530 chips running constant console > sessions with regular large amounts of output (debugging and panicing > other solaris systems for Fibre Channel work) via tip. There has never > been a lost character that I can see except due to power outage. I am > convinced to a moral certainty and beyond a reasonable doubt that if I had > a single 50Mhz processor I'd have the same experience. > > Since the Solaris tip and the FreeBSD tip are essentially identical (both > derive from BSD 4.X tip), I'd like to try and understand how this is an > application problem :-). > > -matt > > > > -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 21: 3:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id DDE7614DF1 for ; Sun, 5 Dec 1999 21:03:27 -0800 (PST) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id XAA25613; Sun, 5 Dec 1999 23:01:25 -0600 (CST) From: Mohit Aron Message-Id: <199912060501.XAA25613@cs.rice.edu> Subject: Re: new Intel 100Mbps card To: wes@softweyr.com (Wes Peters) Date: Sun, 5 Dec 1999 23:01:25 -0600 (CST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <384B21D1.415FD524@softweyr.com> from "Wes Peters" at Dec 5, 99 07:39:13 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > It's probably an 82558 chip. Does it support Wake-on-LAN? > Not sure what Wake-on-LAN means. I believe there are some cards out there now that support some kind of network management. This is not that if that helps. > > Add the device IDs to the list in the driver and recompile. If it works, > send me the diffs and I'll commit it for you. I might even be able to beat > one of the cards out of Intel, I used to work for the InBusiness (formerly > Dayna Communications) crowd. ;^) > Like I said in my last mail, I've already done that. It works. Here are the patches for FreeBSD-4.0-19990827-CURRENT. Please note that I tested it out on FreeBSD-2.2.6 and ported it to FreeBSD-4.0-19990827-CURRENT (I don't have root on a FreeBSD-4.0-19990827-CURRENT machine). Also please read the results of some tests that I've done on the card - they're discussed after the patch below. --------------------------- Cut Here ----------------------------------------- diff -ur /sys/pci/if_fxp.c pci/if_fxp.c --- /sys/pci/if_fxp.c Tue Jul 6 14:23:25 1999 +++ pci/if_fxp.c Sun Dec 5 22:33:33 1999 @@ -501,10 +501,20 @@ static int fxp_probe(device_t dev) { - if ((pci_get_vendor(dev) == FXP_VENDORID_INTEL) && - (pci_get_device(dev) == FXP_DEVICEID_i82557)) { - device_set_desc(dev, "Intel EtherExpress Pro 10/100B Ethernet"); - return 0; + if (pci_get_vendor(dev) == FXP_VENDORID_INTEL) { + switch (pci_get_device(dev)) { + case FXP_DEVICEID_i82557: + device_set_desc(dev, + "Intel EtherExpress Pro 10/100B Ethernet"); + return 0; + + case FXP_DEVICEID_i82558: + device_set_desc(dev, + "Intel InBusiness 10/100 Ethernet"); + + return 0; + } + } return ENXIO; diff -ur /sys/pci/if_fxpreg.h pci/if_fxpreg.h --- /sys/pci/if_fxpreg.h Thu Feb 11 17:41:21 1999 +++ pci/if_fxpreg.h Sun Dec 5 22:29:13 1999 @@ -29,6 +29,7 @@ #define FXP_VENDORID_INTEL 0x8086 #define FXP_DEVICEID_i82557 0x1229 +#define FXP_DEVICEID_i82558 0x1030 #define FXP_PCI_MMBA 0x10 #define FXP_PCI_IOBA 0x14 --------------------------- Cut Here ----------------------------------------- I tested out the card by doing some long TCP transfers over it on a LAN. It seems to work fine but once in a while (1 in 1000 packets approximately), it seems to receive truncated IP packets. I have thoroughly tested this out - the sending host is not sending any truncated packets. The problem only lies on the receiving host - the one that's using the new card. Also, it seems that the packet in question is finally received correctly - however the sending host never transmitted the packet again. It seems the receiving host (the one with the new card) first gets a truncated packet and then gets the full packet. I'm attaching a segment of tcpdump trace that demonstrates this problem. The first and the last packets in this trace are the truncated and full versions in question. Finally, I must add that I repeated the experiment with two hosts both having the old 10/100B cards - I didn't see any truncated IP packets. However, each time I used the new card, I saw truncated IP packets. I've also the other Intel InBusiness cards - they all give the same problem (this rules out the possibility that any one card has a hardware problem). 22:19:26.072982 truncated-ip - 8 bytes missing!192.168.12.103.6500 > 192.168.12.106.1030: . ack 3661249462 win 7920 (DF) 22:19:26.072995 192.168.12.106.1030 > 192.168.12.103.6500: . 3661250902:3661252342(1440) ack 1511615746 win 17280 (DF) 22:19:26.073031 192.168.12.106.1030 > 192.168.12.103.6500: . 3661252342:3661253782(1440) ack 1511615746 win 17280 (DF) 22:19:26.073057 192.168.12.106.1030 > 192.168.12.103.6500: . 3661253782:3661255222(1440) ack 1511615746 win 17280 (DF) 22:19:26.073082 192.168.12.106.1030 > 192.168.12.103.6500: . 3661255222:3661256662(1440) ack 1511615746 win 17280 (DF) 22:19:26.073108 192.168.12.106.1030 > 192.168.12.103.6500: . 3661256662:3661258102(1440) ack 1511615746 win 17280 (DF) 22:19:26.073132 192.168.12.106.1030 > 192.168.12.103.6500: . 3661258102:3661259542(1440) ack 1511615746 win 17280 (DF) 22:19:26.073158 192.168.12.106.1030 > 192.168.12.103.6500: . 3661259542:3661260982(1440) ack 1511615746 win 17280 (DF) 22:19:26.073182 192.168.12.106.1030 > 192.168.12.103.6500: . 3661260982:3661262422(1440) ack 1511615746 win 17280 (DF) 22:19:26.073206 192.168.12.106.1030 > 192.168.12.103.6500: . 3661262422:3661263862(1440) ack 1511615746 win 17280 (DF) 22:19:26.074336 192.168.12.103.6500 > 192.168.12.106.1030: . ack 3661249462 win 7920 (DF) - Mohit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 21: 6:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 8C0AC1538E; Sun, 5 Dec 1999 21:06:30 -0800 (PST) (envelope-from kvandel@cs.duke.edu) Received: from wookie.vandelden.com (IDENT:root@s-kvandel.cs.duke.edu [152.3.134.91]) by duke.cs.duke.edu (8.9.1/8.9.1) with SMTP id AAA23279; Mon, 6 Dec 1999 00:06:21 -0500 (EST) From: kvandel Reply-To: kvandel@cs.duke.edu Organization: Duke University To: Mike Smith Subject: Re: fxp, xl driver question .. (routing) Date: Sun, 5 Dec 1999 23:38:55 -0600 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <199912060440.UAA00678@mass.cdrom.com> In-Reply-To: <199912060440.UAA00678@mass.cdrom.com> Cc: freebsd-hackers@FreeBSD.ORG MIME-Version: 1.0 Message-Id: <99120600010702.01504@wookie.vandelden.com> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 05 Dec 1999, you wrote: > > > The question: Why doesn't this work... it seem so straight forward... > > I'm not sure about the code in question, but the basic assumptions you're > making about PCI's behaviour are flawed. To achieve the goal you're > trying to, you need to reduce the value of the PCI bus latency timer for > the peripheral(s) that you're hoping to interrupt. I don't want to interrupt the devices.. which would require the transaction to reoccur... I do agree(from the book PCI System Architecture), the Master Latency Timer should be decreased, but I still need the DMA transactions to complete sooner from the time GNT# is removed by the arbiter. > Breaking up the DMA transactions leaves you vulnerable to the PCI > peripheral noticing that the two segments are contiguous and coalescing > them again into a single master write. I don't think the NIC will do this... However it it possible... From 3com docs, the 3c509bs don't... But I could probably reorder the dma requests to force seperate transactions... maybe, maybe not. > Also, you don't want the (high) > overhead of forcing a re-arbitration all the time, rather you want to > guarantee the worst-case cycle time involved in polling the peripheral. > Again, to achieve this, you want to look at how the PCI bus latency timer > works and use it instead. I understand how it is working, but the I still beleive smaller DMA transactions, while somewhat inefficient, will shorten the latency to something reasonable. > You will always get the best performance out of PCI by avoiding > _anything_ that involves arbitrating for the bus. PCI bus transactions > are reasonably expensive to start. 8( > I agree. If I knew I could avoid handshaking the device, I would skip it... It takes 20+% of the forwarding time.. I have another question: Is there a way to get the compiler to do a non blocking mem read ? load to a hardwired zeroed register? thanks a bunch, kurt > > > > -- > \\ Give a man a fish, and you feed him for a day. \\ Mike Smith > \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org > \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com -- uname -a > Linux wookie.vandelden.com 2.2.13 #1 < To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 21:10:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 2838814F19 for ; Sun, 5 Dec 1999 21:10:41 -0800 (PST) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id VAA13283; Sun, 5 Dec 1999 21:09:08 -0800 (PST) Message-Id: <199912060509.VAA13283@implode.root.com> To: Mohit Aron Cc: wes@softweyr.com (Wes Peters), freebsd-hackers@FreeBSD.ORG Subject: Re: new Intel 100Mbps card In-reply-to: Your message of "Sun, 05 Dec 1999 23:01:25 CST." <199912060501.XAA25613@cs.rice.edu> From: David Greenman Reply-To: dg@root.com Date: Sun, 05 Dec 1999 21:09:08 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > #define FXP_VENDORID_INTEL 0x8086 > #define FXP_DEVICEID_i82557 0x1229 >+#define FXP_DEVICEID_i82558 0x1030 This wouldn't be correct. The 82558 has been used for years on Pro/100+ boards and they ID as 0x1229. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 21:12:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 5C16E15393 for ; Sun, 5 Dec 1999 21:12:32 -0800 (PST) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id XAA25784; Sun, 5 Dec 1999 23:12:24 -0600 (CST) From: Mohit Aron Message-Id: <199912060512.XAA25784@cs.rice.edu> Subject: Re: new Intel 100Mbps card To: dg@root.com Date: Sun, 5 Dec 1999 23:12:24 -0600 (CST) Cc: wes@softweyr.com, freebsd-hackers@freebsd.org In-Reply-To: <199912060509.VAA13283@implode.root.com> from "David Greenman" at Dec 5, 99 09:09:08 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > #define FXP_VENDORID_INTEL 0x8086 > > #define FXP_DEVICEID_i82557 0x1229 > >+#define FXP_DEVICEID_i82558 0x1030 > > This wouldn't be correct. The 82558 has been used for years on Pro/100+ > boards and they ID as 0x1229. > Sorry, I forgot to say about the above. Since Wes Peters suggested that it might be a 82558, it put the above name. Please correct it to whatever the name should be. - Mohit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 21:16:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 902E014F19; Sun, 5 Dec 1999 21:16:32 -0800 (PST) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id XAA25860; Sun, 5 Dec 1999 23:16:31 -0600 (CST) From: Mohit Aron Message-Id: <199912060516.XAA25860@cs.rice.edu> Subject: Re: new Intel 100Mbps card To: msmith@freebsd.org (Mike Smith) Date: Sun, 5 Dec 1999 23:16:31 -0600 (CST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199912060441.UAA00732@mass.cdrom.com> from "Mike Smith" at Dec 5, 99 08:41:04 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Bah. It sounds like an Intel ploy so that they can trivially identify > these cards and put the "right" name up in the Windows network setup box. > This isn't quite what the idea was with PCI IDs originally. 8( Probably. One of our faculty actually bought what seems like a slightly different version of this card. That had some kind of network management on it. The difference is that it has the same device_id as the earlier 82557 and is recognized by FreeBSD without any changes. However, upon looking at the two cards (the one that I got and the on that that faculty member got) they look pretty much the same (except for some small chips missing on my card that seem to control the network management features). I tried the other card out too - it also seems to give the IP truncated packet errors (I just posted about that in my last mail to freebsd-hackers list). > > It's probably reasonable to assume that if the driver works at all, it'll > work just fine. You can help us out here by looking closely at the large > funny-looking chip on the card and telling us what the part numbers on it > are, since that's the only way for us to work out what the part actually > is. There's quite a good chance that it's a part we already support, and > all that Intel have done is change the PCI device ID in the EEPROM. > This time there is no "large" chip on the card. The older cards that I have do have a large chip with 82557 etched on them. There is a thin, square and rather small (compared to the older cards) chip that says GD82559 on it. The same chip seems to be also there on the card that I mentioned above (from the faculty member). Please let me know if I can help in any other way with the cards - there are several chips on it and I'm not sure which one you're really looking for. - Mohit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 21:30: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id C19FD14BF5 for ; Sun, 5 Dec 1999 21:29:57 -0800 (PST) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id VAA13359; Sun, 5 Dec 1999 21:24:18 -0800 (PST) Message-Id: <199912060524.VAA13359@implode.root.com> To: Mohit Aron Cc: wes@softweyr.com, freebsd-hackers@freebsd.org Subject: Re: new Intel 100Mbps card In-reply-to: Your message of "Sun, 05 Dec 1999 23:12:24 CST." <199912060512.XAA25784@cs.rice.edu> From: David Greenman Reply-To: dg@root.com Date: Sun, 05 Dec 1999 21:24:18 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> >> > #define FXP_VENDORID_INTEL 0x8086 >> > #define FXP_DEVICEID_i82557 0x1229 >> >+#define FXP_DEVICEID_i82558 0x1030 >> >> This wouldn't be correct. The 82558 has been used for years on Pro/100+ >> boards and they ID as 0x1229. >> > > >Sorry, I forgot to say about the above. Since Wes Peters suggested that it >might be a 82558, it put the above name. Please correct it to whatever the >name should be. From your other email it sounds like it has an 82559. Intel has been shipping that for more than a year as well on boards that ID as 0x1229, so apparantly the chip being used doesn't correlate with the ID number. In this case I'd recommend changing the above defines to "FXP_DEVICE_ID_1" and "FXP_DEVICE_ID_2" respectively. If you are confident that your 0x1230 Pro/100 is working correctly, including stuff related to manual selection of the speed and duplex, then I'll take care of making the changes to the driver. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 21:43:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 94B3714F0C for ; Sun, 5 Dec 1999 21:43:28 -0800 (PST) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id XAA26211; Sun, 5 Dec 1999 23:43:16 -0600 (CST) From: Mohit Aron Message-Id: <199912060543.XAA26211@cs.rice.edu> Subject: Re: new Intel 100Mbps card To: dg@root.com Date: Sun, 5 Dec 1999 23:43:15 -0600 (CST) Cc: wes@softweyr.com, freebsd-hackers@freebsd.org In-Reply-To: <199912060524.VAA13359@implode.root.com> from "David Greenman" at Dec 5, 99 09:24:18 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > From your other email it sounds like it has an 82559. Intel has been > shipping that for more than a year as well on boards that ID as 0x1229, > so apparantly the chip being used doesn't correlate with the ID number. I mentioned another similar card in my last posting. That one I got from a faculty member (he's Alan Cox - also works on FreeBSD). That card is very similar (in looks and performance) to the one that I got but has the device ID of 0x1229 (same as 10/100B). Additionally, Alan mentioned that some small additional chips on it are supposed to do some kind of network mgmnt - I believe that was the Wake-on-LAN feature. The card that I have, however, is similar, but has a different PCI device_Id - 0x1030. So you're probably right in that the chip doesn't correlate with the ID number. > In this case I'd recommend changing the above defines to "FXP_DEVICE_ID_1" > and "FXP_DEVICE_ID_2" respectively. If you are confident that your 0x1230 > Pro/100 is working correctly, including stuff related to manual selection > of the speed and duplex, then I'll take care of making the changes to > the driver. Its 0x1030 - not 0x1230. I've tried it only in full-duplex and it works fine (except for the truncated IP packets that I mailed about). My /etc/rc.conf has "media 100baseTX mediaopt full-duplex" for the ifconfig command. I was able to get about 77 Mbps on a 100Mbps LAN with this card. With the older ones, I can get about 93 Mbps (which is the maximum if packet headers are taken into account). The difference in performance is probably due to the truncated IP packets I mentioned. I can try other settings on this card if you can tell me which ones you're interested in. - Mohit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 22: 5:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 8E34614F60 for ; Sun, 5 Dec 1999 22:05:51 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id WAA16056; Sun, 5 Dec 1999 22:05:50 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id WAA27153; Sun, 5 Dec 1999 22:05:49 -0800 Received: from softweyr.com ([204.68.178.39]) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA25673; Sun, 5 Dec 99 22:05:47 PST Message-Id: <384B5255.EE6CF1B7@softweyr.com> Date: Sun, 05 Dec 1999 23:06:13 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Mohit Aron , freebsd-hackers@freebsd.org Subject: Re: new Intel 100Mbps card References: <199912060512.XAA25784@cs.rice.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mohit Aron wrote: > > > > > > #define FXP_VENDORID_INTEL 0x8086 > > > #define FXP_DEVICEID_i82557 0x1229 > > >+#define FXP_DEVICEID_i82558 0x1030 > > > > This wouldn't be correct. The 82558 has been used for years on Pro/100+ > > boards and they ID as 0x1229. > > > > Sorry, I forgot to say about the above. Since Wes Peters suggested that it > might be a 82558, it put the above name. Please correct it to whatever the > name should be. If you can't find the id on the chip, I'll see what I can track down at Intel tomorrow. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 22:12:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id C95E114DDA for ; Sun, 5 Dec 1999 22:12:14 -0800 (PST) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id AAA26520; Mon, 6 Dec 1999 00:12:10 -0600 (CST) From: Mohit Aron Message-Id: <199912060612.AAA26520@cs.rice.edu> Subject: Re: new Intel 100Mbps card To: wes@softweyr.com (Wes Peters) Date: Mon, 6 Dec 1999 00:12:10 -0600 (CST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <384B5255.EE6CF1B7@softweyr.com> from "Wes Peters" at Dec 5, 99 11:06:13 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > If you can't find the id on the chip, I'll see what I can track down at > Intel tomorrow. > I am looking up the Intel website. The chip indeed is 82559. Also there doesn't seem to be a correlation between the chip and the PCI device_id. I have two network cards (I mentioned them in my last postings) with different device_ids but the same 82559 chip on them. From the Intel's page, I was able to find the technical names for the two cards that I've been talking about. 1) Intel InBusiness 10/100 adaptor - this one has a device_id of 0x1030. 2) Pro/100+ PCI Management adaptor (board id number is 721383-xxx). This has the usual PCI device_id of 0x1229. The relevant website that displays the above information is: http://support.intel.com/support/network/adapter/pro100/21397.htm - Mohit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 22:25:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from c62443-a.frmt1.sfba.home.com (c62443-a.frmt1.sfba.home.com [24.0.69.165]) by hub.freebsd.org (Postfix) with ESMTP id F0AE414D74 for ; Sun, 5 Dec 1999 22:25:00 -0800 (PST) (envelope-from adsharma@sharmas.dhs.org) Received: from sharmas.dhs.org (astra.sharmas.org [192.168.0.12]) by c62443-a.frmt1.sfba.home.com (8.9.3/8.9.3) with ESMTP id WAA23152 for ; Sun, 5 Dec 1999 22:24:55 -0800 Received: (from adsharma@localhost) by sharmas.dhs.org (8.9.3/8.9.3) id WAA01408 for freebsd-hackers@freebsd.org; Sun, 5 Dec 1999 22:24:23 -0800 (PST) (envelope-from adsharma) Date: Sun, 5 Dec 1999 22:24:23 -0800 From: Arun Sharma To: freebsd-hackers@freebsd.org Subject: Per CPU timekeeping for SMP Message-ID: <19991205222423.A1391@sharmas.dhs.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6TrnltStXW4iwmi0" X-Mailer: Mutt 1.0i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Here's a reimplementation of my earlier per cpu time keeping patch on SMP. The attached patch is against a 11/20/99 -current that I cvsup'ed. 1. On UP, sys_time is a global and contains the system wide stats cpu_time is a global and is essentially the same as sys_time. 2. On SMP sys_time contains the system wide stats cpu_time has been changed to a pointer in the per-cpu space. On BSP, this pointer points to a static array cpu0_cpu_time On APs, this space is kmem_alloc'ed Perhaps I should wrap cpu_time in a structure (cpu_info ?), which could be the right place to store all per CPU info. 3. I've taken the liberty of changing CP_* to CPU_*. I hope the new names better convey the meaning of the variables and are acceptable. 4. I've gotten sysctls working for sys_time - $ sysctl -A | grep kern.stats kern.stats.systime.user: 25150 kern.stats.systime.nice: 3878 kern.stats.systime.sys: 14071 kern.stats.systime.intr: 7395 kern.stats.systime.idle: 5326029 I'm working on generating the per cpu sysctls. 5. The machine specific code for Alpha will need some changes - which I can implement, but have no way of compiling or testing. 6. All the existing utilties which depended on peeking at cp_time will break (which is a good thing, IMO - so that I can fix them. :-) They will all be converted to use sysctl, as time permits. Now, about the release schedule for this work - am I too late for the 12/15 feature freeze ? I'd appreciate some comments on the implementation, so that if there are any issues, I can fix them before 12/15. -Arun --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mp_cpu_time.patch" Index: i386/i386/genassym.c =================================================================== RCS file: /home/adsharma/cvs_root/freebsd-sys/i386/i386/genassym.c,v retrieving revision 1.1.1.4 diff -u -r1.1.1.4 genassym.c --- genassym.c 1999/11/20 23:46:06 1.1.1.4 +++ genassym.c 1999/12/05 19:45:42 @@ -205,6 +205,7 @@ printf("#define\tGD_PRV_PADDR1 %#x\n", OS(globaldata, gd_prv_PADDR1)); printf("#define\tPS_IDLESTACK %#x\n", OS(privatespace, idlestack)); printf("#define\tPS_IDLESTACK_TOP %#x\n", sizeof(struct privatespace)); + printf("#define\tGD_CPU_TIME %#x\n", OS(globaldata, gd_cpu_time)); #endif printf("#define\tKCSEL %#x\n", GSEL(GCODE_SEL, SEL_KPL)); Index: i386/i386/globals.s =================================================================== RCS file: /home/adsharma/cvs_root/freebsd-sys/i386/i386/globals.s,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 globals.s --- globals.s 1999/08/31 05:12:09 1.1.1.2 +++ globals.s 1999/12/05 19:46:11 @@ -79,6 +79,7 @@ .set gd_currentldt,globaldata + GD_CURRENTLDT #endif + #ifndef SMP .globl _curproc, _curpcb, _npxproc .globl _common_tss, _switchtime, _switchticks @@ -122,6 +123,9 @@ .set gd_prv_CADDR2,globaldata + GD_PRV_CADDR2 .set gd_prv_CADDR3,globaldata + GD_PRV_CADDR3 .set gd_prv_PADDR1,globaldata + GD_PRV_PADDR1 + + .globl gd_cpu_time + .set gd_cpu_time,globaldata + GD_CPU_TIME #endif #if defined(SMP) || defined(APIC_IO) Index: i386/i386/machdep.c =================================================================== RCS file: /home/adsharma/cvs_root/freebsd-sys/i386/i386/machdep.c,v retrieving revision 1.1.1.4 diff -u -r1.1.1.4 machdep.c --- machdep.c 1999/11/20 23:46:07 1.1.1.4 +++ machdep.c 1999/12/05 21:59:13 @@ -114,6 +114,7 @@ #ifdef SMP #include #include +#include /* For cpu_time */ #endif #ifdef PERFMON #include @@ -143,6 +144,10 @@ static MALLOC_DEFINE(M_MBUF, "mbuf", "mbuf"); +#ifdef SMP +static cpu0_cpu_time[NCPUSTATES]; +#endif + int _udatasel, _ucodesel; u_int atdevbase; @@ -1964,6 +1969,11 @@ proc0.p_addr->u_pcb.pcb_mpnest = 1; #endif proc0.p_addr->u_pcb.pcb_ext = 0; + +#ifdef SMP + /* Setup cpu0's cpu_time */ + cpu_time = &cpu0_cpu_time; +#endif } #if defined(I586_CPU) && !defined(NO_F00F_HACK) Index: i386/i386/mp_machdep.c =================================================================== RCS file: /home/adsharma/cvs_root/freebsd-sys/i386/i386/mp_machdep.c,v retrieving revision 1.1.1.4 diff -u -r1.1.1.4 mp_machdep.c --- mp_machdep.c 1999/11/20 23:46:07 1.1.1.4 +++ mp_machdep.c 1999/12/05 19:48:29 @@ -243,6 +243,11 @@ /** XXX FIXME: what system files declare these??? */ extern struct region_descriptor r_gdt, r_idt; +extern long sys_time[NCPUSTATES]; +#ifndef SMP +extern long cpu_time[NCPUSTATES]; +#endif + int bsp_apic_ready = 0; /* flags useability of BSP apic */ int mp_ncpus; /* # of CPUs, including BSP */ int mp_naps; /* # of Applications processors */ @@ -1798,6 +1803,9 @@ SMPpt[pg + 3] = 0; /* *prv_CMAP3 */ SMPpt[pg + 4] = 0; /* *prv_PMAP1 */ + /* space for cpu time */ + gd->gd_cpu_time = (long *) kmem_alloc(kernel_map, sizeof(long) + * NCPUSTATES); /* prime data page for it to use */ gd->gd_cpuid = x; gd->gd_cpu_lockid = x << 24; @@ -2222,8 +2230,6 @@ int checkstate_cpustate[NCPU]; u_long checkstate_pc[NCPU]; -extern long cp_time[CPUSTATES]; - #define PC_TO_INDEX(pc, prof) \ ((int)(((u_quad_t)((pc) - (prof)->pr_off) * \ (u_quad_t)((prof)->pr_scale)) >> 16) & ~1) @@ -2272,10 +2278,13 @@ if (pscnt > 1) return; p->p_uticks++; - if (p->p_nice > NZERO) - cp_time[CP_NICE]++; - else - cp_time[CP_USER]++; + if (p->p_nice > NZERO) { + cpu_time[CPU_NICE]++; + sys_time[CPU_NICE]++; + } else { + cpu_time[CPU_USER]++; + sys_time[CPU_USER]++; + } break; case CHECKSTATE_SYS: #ifdef GPROF @@ -2294,11 +2303,13 @@ if (pscnt > 1) return; - if (!p) - cp_time[CP_IDLE]++; - else { + if (!p) { + cpu_time[CPU_IDLE]++; + sys_time[CPU_IDLE]++; + } else { p->p_sticks++; - cp_time[CP_SYS]++; + cpu_time[CPU_SYS]++; + sys_time[CPU_SYS]++; } break; case CHECKSTATE_INTR: @@ -2320,7 +2331,7 @@ return; if (p) p->p_iticks++; - cp_time[CP_INTR]++; + cpu_time[CPU_INTR]++; } if (p != NULL) { p->p_cpticks++; Index: i386/include/globaldata.h =================================================================== RCS file: /home/adsharma/cvs_root/freebsd-sys/i386/include/globaldata.h,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 globaldata.h --- globaldata.h 1999/08/31 05:12:13 1.1.1.2 +++ globaldata.h 1999/12/05 19:45:30 @@ -26,6 +26,8 @@ * $FreeBSD: src/sys/i386/include/globaldata.h,v 1.11 1999/08/28 00:44:12 peter Exp $ */ +#include + /* * This structure maps out the global data that needs to be kept on a * per-cpu basis. genassym uses this to generate offsets for the assembler @@ -65,6 +67,7 @@ caddr_t gd_prv_CADDR2; caddr_t gd_prv_CADDR3; unsigned *gd_prv_PADDR1; + long *gd_cpu_time; #endif }; Index: i386/include/globals.h =================================================================== RCS file: /home/adsharma/cvs_root/freebsd-sys/i386/include/globals.h,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 globals.h --- globals.h 1999/08/31 05:12:13 1.1.1.2 +++ globals.h 1999/12/05 19:48:01 @@ -95,6 +95,7 @@ #define currentldt GLOBAL_LVALUE(currentldt, int) #endif + #ifdef SMP #define cpuid GLOBAL_RVALUE(cpuid, u_int) #define other_cpus GLOBAL_LVALUE(other_cpus, u_int) @@ -107,6 +108,7 @@ #define prv_CADDR2 GLOBAL_RVALUE(prv_CADDR2, caddr_t) #define prv_CADDR3 GLOBAL_RVALUE(prv_CADDR3, caddr_t) #define prv_PADDR1 GLOBAL_RVALUE(prv_PADDR1, unsigned *) +#define cpu_time GLOBAL_LVALUE(cpu_time, long *) #endif #endif /*UP kernel*/ @@ -123,6 +125,8 @@ #ifdef USER_LDT GLOBAL_FUNC(currentldt) #endif + +GLOBAL_FUNC(cpu_time) #ifdef SMP GLOBAL_FUNC(cpuid) Index: kern/kern_clock.c =================================================================== RCS file: /home/adsharma/cvs_root/freebsd-sys/kern/kern_clock.c,v retrieving revision 1.1.1.4 diff -u -r1.1.1.4 kern_clock.c --- kern_clock.c 1999/11/20 23:46:37 1.1.1.4 +++ kern_clock.c 1999/12/05 22:00:34 @@ -70,6 +70,14 @@ #include #endif +/* System wide statistics */ +long sys_time[NCPUSTATES]; + +#ifndef SMP +/* In the SMP case, this is in the per cpu private page */ +long cpu_time[NCPUSTATES]; +#endif + /* * Number of timecounters used to implement stable storage */ @@ -87,13 +95,6 @@ static void tco_setscales __P((struct timecounter *tc)); static __inline unsigned tco_delta __P((struct timecounter *tc)); -/* Some of these don't belong here, but it's easiest to concentrate them. */ -#if defined(SMP) && defined(BETTER_CLOCK) -long cp_time[CPUSTATES]; -#else -static long cp_time[CPUSTATES]; -#endif - long tk_cancc; long tk_nin; long tk_nout; @@ -392,10 +393,14 @@ * If this process is being profiled record the tick. */ p->p_uticks++; - if (p->p_nice > NZERO) - cp_time[CP_NICE]++; - else - cp_time[CP_USER]++; + if (p->p_nice > NZERO) { + cpu_time[CPU_NICE]++; + sys_time[CPU_NICE]++; + + } else { + cpu_time[CPU_USER]++; + sys_time[CPU_NICE]++; + } } else { #ifdef GPROF /* @@ -432,12 +437,16 @@ if (CLKF_INTR(frame)) { if (p != NULL) p->p_iticks++; - cp_time[CP_INTR]++; + cpu_time[CPU_INTR]++; + sys_time[CPU_INTR]++; } else if (p != NULL) { p->p_sticks++; - cp_time[CP_SYS]++; - } else - cp_time[CP_IDLE]++; + cpu_time[CPU_SYS]++; + sys_time[CPU_SYS]++; + } else { + cpu_time[CPU_IDLE]++; + sys_time[CPU_IDLE]++; + } } pscnt = psdiv; Index: sys/dkstat.h =================================================================== RCS file: /home/adsharma/cvs_root/freebsd-sys/sys/dkstat.h,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 dkstat.h --- dkstat.h 1999/08/31 05:13:41 1.1.1.2 +++ dkstat.h 1999/12/05 07:28:40 @@ -42,12 +42,12 @@ #ifndef _SYS_DKSTAT_H_ #define _SYS_DKSTAT_H_ 1 -#define CP_USER 0 -#define CP_NICE 1 -#define CP_SYS 2 -#define CP_INTR 3 -#define CP_IDLE 4 -#define CPUSTATES 5 +#define CPU_USER 0 +#define CPU_NICE 1 +#define CPU_SYS 2 +#define CPU_INTR 3 +#define CPU_IDLE 4 +#define NCPUSTATES 5 #ifdef KERNEL --6TrnltStXW4iwmi0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 22:34:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 448D614CB1 for ; Sun, 5 Dec 1999 22:34:53 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id WAA16110; Sun, 5 Dec 1999 22:34:17 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id WAA27543; Sun, 5 Dec 1999 22:34:16 -0800 Received: from softweyr.com ([204.68.178.39]) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA26153; Sun, 5 Dec 99 22:33:55 PST Message-Id: <384B58E5.D1B926C9@softweyr.com> Date: Sun, 05 Dec 1999 23:34:13 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: dg@root.com Cc: Mohit Aron , freebsd-hackers@FreeBSD.ORG Subject: Re: new Intel 100Mbps card References: <199912060524.VAA13359@implode.root.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Greenman wrote: > > > > >Sorry, I forgot to say about the above. Since Wes Peters suggested that it > >might be a 82558, it put the above name. Please correct it to whatever the > >name should be. > > From your other email it sounds like it has an 82559. Intel has been > shipping that for more than a year as well on boards that ID as 0x1229, > so apparantly the chip being used doesn't correlate with the ID number. > In this case I'd recommend changing the above defines to "FXP_DEVICE_ID_1" > and "FXP_DEVICE_ID_2" respectively. If you are confident that your 0x1230 > Pro/100 is working correctly, including stuff related to manual selection > of the speed and duplex, then I'll take care of making the changes to > the driver. This might be the new 82559ER; I'm downloading the datasheet now. Have a peek at: http://developer.intel.com/design/network/datashts/index.htm -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 5 22:56:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 571B714DEE for ; Sun, 5 Dec 1999 22:56:15 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id WAA16179; Sun, 5 Dec 1999 22:55:40 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id WAA27843; Sun, 5 Dec 1999 22:55:40 -0800 Received: from softweyr.com ([204.68.178.39]) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA26517; Sun, 5 Dec 99 22:55:37 PST Message-Id: <384B5DFF.ED230ACB@softweyr.com> Date: Sun, 05 Dec 1999 23:55:59 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: dg@root.com, Mohit Aron , freebsd-hackers@FreeBSD.ORG Subject: Re: new Intel 100Mbps card References: <199912060524.VAA13359@implode.root.com> <384B58E5.D1B926C9@softweyr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters wrote: > > This might be the new 82559ER; I'm downloading the datasheet now. Have > a peek at: > > http://developer.intel.com/design/network/datashts/index.htm Nope, that one is apparently device ID 0x1209. Too bad they don't have a PCI device ID cross-reference on the web site. Bleh. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 0: 4: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (castles554.castles.com [208.214.165.118]) by hub.freebsd.org (Postfix) with ESMTP id B09CD15129; Mon, 6 Dec 1999 00:04:02 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id AAA01467; Mon, 6 Dec 1999 00:05:53 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912060805.AAA01467@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: kvandel@cs.duke.edu Cc: Mike Smith , freebsd-hackers@FreeBSD.ORG Subject: Re: fxp, xl driver question .. (routing) In-reply-to: Your message of "Sun, 05 Dec 1999 23:38:55 CST." <99120600010702.01504@wookie.vandelden.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Dec 1999 00:05:53 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sun, 05 Dec 1999, you wrote: > > > > > The question: Why doesn't this work... it seem so straight forward... > > > > I'm not sure about the code in question, but the basic assumptions you're > > making about PCI's behaviour are flawed. To achieve the goal you're > > trying to, you need to reduce the value of the PCI bus latency timer for > > the peripheral(s) that you're hoping to interrupt. > I don't want to interrupt the devices.. which would require the > transaction to reoccur... Er, as I understand your original requirement this is exactly what you want to do - you want to push them off the bus so that the CPU can poll a status register on a given card. > I do agree(from the book PCI System Architecture), > the Master Latency Timer should be decreased, but I still need the DMA > transactions to complete sooner from the time GNT# is removed by the > arbiter. The only case where the device will _not_ release the bus on loss of #GNT is when its latency timer has not yet expired. This is my point; you can guarantee an upper bound on the time from #GNT loss to bus release _only_ by changing the latency timer. Dropping the size of all of your DMA transactions increases your losses due to arbitration delays, because the device will (normally) _always_ give up the bus at the end of a DMA transaction. > > Also, you don't want the (high) > > overhead of forcing a re-arbitration all the time, rather you want to > > guarantee the worst-case cycle time involved in polling the peripheral. > > > Again, to achieve this, you want to look at how the PCI bus latency timer > > works and use it instead. > > I understand how it is working, but the I still beleive smaller DMA > transactions, while somewhat inefficient, will shorten the latency to > something reasonable. No, this is basically wrong. Sure, shortening your DMA transactions absurdly will give you some control over burst length, but you'd have to reduce them to less than the latency-timer-protected window before you noticed any effect, and the overhead-related losses would be painful. Consider the optimal situation; you have a descriptor set up for a ~1500 byte DMA, and the latency timer is set to 32 cycles. The worst-case latency is then a little over 1us (including arbitration). To do any better than this, you need to reduce your DMA burst size to less than 32/4 or 128 bytes. This increases your arbitration overhead by a factor of more than 10. This is a _constant_ loss factor, and at this point you still haven't actually gained anything. To improve your worst-case latency by a factor of 2, you have to increase your arbitration loss to twenty times that of the 'optimal' case. I can assure you that PCI is not very efficient when you are only bursting 64 bytes at a time. 8) Conversely, you can achieve the same latency reduction by setting the latency timer to 16, without increasing your overheads there. (This isn't actually entirely true, as you may run into busmaster ping-pong with more than one in the system, but you'll get this with reduced DMA bursts as well.) > > You will always get the best performance out of PCI by avoiding > > _anything_ that involves arbitrating for the bus. PCI bus transactions > > are reasonably expensive to start. 8( > > I agree. If I knew I could avoid handshaking the device, I would skip it... > It takes 20+% of the forwarding time.. You may want to give up and use another device... > I have another question: Is there a way to get the compiler to do a non > blocking mem read ? load to a hardwired zeroed register? I'm not sure what you're talking about here. "non-blocking" against what? -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 0:11:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (castles554.castles.com [208.214.165.118]) by hub.freebsd.org (Postfix) with ESMTP id 1CB0E15156; Mon, 6 Dec 1999 00:11:14 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id AAA01499; Mon, 6 Dec 1999 00:13:09 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912060813.AAA01499@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Mike Smith Cc: kvandel@cs.duke.edu, freebsd-hackers@freebsd.org Subject: Re: fxp, xl driver question .. (routing) In-reply-to: Your message of "Mon, 06 Dec 1999 00:05:53 PST." <199912060805.AAA01467@mass.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Dec 1999 00:13:09 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > On Sun, 05 Dec 1999, you wrote: > Conversely, you can achieve the same latency reduction by setting the > latency timer to 16, without increasing your overheads there. (This isn't > actually entirely true, as you may run into busmaster ping-pong with more > than one in the system, but you'll get this with reduced DMA bursts as > well.) I should have summarised this by saying: Correct use of the latency timer will shorten your DMA bursts for you when necessary, giving you the best of both worlds. When it's safe to run a long burst, you will. When you need to push a device off the bus, that will happen too. And the obvious extension to the "worst case" calculation is that if you have N master devices each with a latency timer of X, your worst-case timing for CPU access to a device is (N * X) + (N * arb overhead), just in case that wasn't clear. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 1:40:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 5DBF415129 for ; Mon, 6 Dec 1999 01:40:16 -0800 (PST) (envelope-from nick@rapidnet.com) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id CAA96328; Mon, 6 Dec 1999 02:38:57 -0700 (MST) Date: Mon, 6 Dec 1999 02:38:57 -0700 (MST) From: Nick Rogness To: Archie Cobbs Cc: Brian Dean , "Ronald F. Guilmette" , freebsd-hackers@FreeBSD.ORG Subject: Re: natd is jumpy In-Reply-To: <199912060115.RAA77164@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 5 Dec 1999, Archie Cobbs wrote: > Brian Dean writes: > > No dropped packets, but definitely some occasional long delays before > > I get the echo. However, I must concede, based on other respondants, > > that something else must be going on and I cannot necessarily > > attribute this to divert/firewall/natd. I forgot to mention, are you connecting at V.90 speeds? If so renegotiations/retrains will take place and you will see a speed jump or hesitation. Disable this in the modem. There are specific S registers to do this. Also what type of term/com server gear are you connecting to? I would also recommend upgrading your modem BIOS. > > > > However, the above numbers don't really illustrate the long response > > times that I experience while typing at the shell prompt, or in elm. > > It's really frustrating. How often does this happen? Is it a fixed time period? [snip] > > Could be you have a noisy line and your modem error correction is > kicking in. Try configuring your modem to disable error correction > and see if it changes things. uuhhh, don't disable error correction for long. You might see massive problems then. But it might be useful to see if it is involved in your problem. Also, get your ISP involved. Most admins have access to debug or PPP trace tools to help you. Good luck. ******************************************************** Nick Rogness File not found... System Administrator Should I fake it (Y/N)? RapidNet, INC ******************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 3:20: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 0AECE1518A for ; Mon, 6 Dec 1999 03:19:58 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 9675B1CC7; Mon, 6 Dec 1999 19:19:57 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Wes Peters Cc: dg@root.com, Mohit Aron , freebsd-hackers@FreeBSD.ORG Subject: Re: new Intel 100Mbps card In-Reply-To: Message from Wes Peters of "Sun, 05 Dec 1999 23:55:59 MST." <384B5DFF.ED230ACB@softweyr.com> Date: Mon, 06 Dec 1999 19:19:57 +0800 From: Peter Wemm Message-Id: <19991206111957.9675B1CC7@overcee.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters wrote: > Wes Peters wrote: > > > > This might be the new 82559ER; I'm downloading the datasheet now. Have > > a peek at: > > > > http://developer.intel.com/design/network/datashts/index.htm > > Nope, that one is apparently device ID 0x1209. Too bad they don't have > a PCI device ID cross-reference on the web site. Bleh. if_fxpreg.h presently has: #define FXP_VENDORID_INTEL 0x8086 #define FXP_DEVICEID_i82557 0x1229 /* 82557 - 82559 "classic" */ #define FXP_DEVICEID_i82559 0x1030 /* New 82559 device id.. */ And: if ((pci_get_vendor(dev) == FXP_VENDORID_INTEL) && (pci_get_device(dev) == FXP_DEVICEID_i82557)) { device_set_desc(dev, "Intel EtherExpress Pro 10/100B Ethernet"); return 0; } if ((pci_get_vendor(dev) == FXP_VENDORID_INTEL) && (pci_get_device(dev) == FXP_DEVICEID_i82559)) { device_set_desc(dev, "Intel InBusiness 10/100 Ethernet"); return 0; } I was told that the device ID is programmable in rom, as well as whether the modem/com/16550 logical device is active and so on. Does adding the new ID work with if_fxp on the new device? Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 3:31: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id B9EA7150FF for ; Mon, 6 Dec 1999 03:31:04 -0800 (PST) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id DAA13928; Mon, 6 Dec 1999 03:28:04 -0800 (PST) Message-Id: <199912061128.DAA13928@implode.root.com> To: Peter Wemm Cc: Wes Peters , Mohit Aron , freebsd-hackers@FreeBSD.ORG Subject: Re: new Intel 100Mbps card In-reply-to: Your message of "Mon, 06 Dec 1999 19:19:57 +0800." <19991206111957.9675B1CC7@overcee.netplex.com.au> From: David Greenman Reply-To: dg@root.com Date: Mon, 06 Dec 1999 03:28:03 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Wes Peters wrote: >> Wes Peters wrote: >> > >> > This might be the new 82559ER; I'm downloading the datasheet now. Have >> > a peek at: >> > >> > http://developer.intel.com/design/network/datashts/index.htm >> >> Nope, that one is apparently device ID 0x1209. Too bad they don't have >> a PCI device ID cross-reference on the web site. Bleh. > >if_fxpreg.h presently has: > >#define FXP_VENDORID_INTEL 0x8086 >#define FXP_DEVICEID_i82557 0x1229 /* 82557 - 82559 "classic" */ >#define FXP_DEVICEID_i82559 0x1030 /* New 82559 device id.. */ Oops, I forgot that you had already added this. This should be merged into 3.x for the 3.4 release (with Jordan's permission of course). Are you going to take care of that, Peter, or would you like me to? -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 4:54:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cairo.anu.edu.au (cairo.anu.edu.au [150.203.224.11]) by hub.freebsd.org (Postfix) with ESMTP id 309591513A for ; Mon, 6 Dec 1999 04:54:07 -0800 (PST) (envelope-from avalon@cairo.anu.edu.au) Received: (from avalon@localhost) by cairo.anu.edu.au (8.9.3/8.9.3) id XAA27078; Mon, 6 Dec 1999 23:55:18 +1100 (EST) From: Darren Reed Message-Id: <199912061255.XAA27078@cairo.anu.edu.au> Subject: Re: 3c589d w/ freebsd 3.3 works badly. To: winter@jurai.net (Matthew N. Dodd) Date: Mon, 6 Dec 1999 23:55:18 +1100 (Australia/NSW) Cc: hackers@freebsd.org In-Reply-To: from "Matthew N. Dodd" at Dec 05, 1999 10:47:37 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In some mail from Matthew N. Dodd, sie said: > > On Mon, 6 Dec 1999, Darren Reed wrote: > > How reliable should the ep0 driver be with 3c389d pcmcia cards ? It gets > > detected by pccardd without any problems and a driver is attached to it, > > but I'm not getting much in the way of performance from it with "link2" > > selected for UTP (doesn't work with "media 10baset/utp"). It's being > > used in conjunction with cardbus on a gateway solo 9100. I suspect that > > it isn't getting interrupted properly, although nothing is telling me > > what IRQ is being given to it. > > I'm still trying to track down a watchdog timeout problem with if_ep. FWIW, I get 800kb/s transfer rates with NetBSD-current Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 5:59:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from eth0-gw.poli.hu (eth0-gw.poli.hu [195.199.8.27]) by hub.freebsd.org (Postfix) with ESMTP id 3AB9D14FB0 for ; Mon, 6 Dec 1999 05:59:12 -0800 (PST) (envelope-from mauzi@faber.poli.hu) Received: from faber.poli.hu ([195.199.8.29]) by eth0-gw.poli.hu with esmtp (Exim 3.03 #1 (Debian)) id 11uyfU-0000tG-00 for ; Mon, 06 Dec 1999 14:59:08 +0100 Received: from mauzi (helo=localhost) by faber.poli.hu with local-esmtp (Exim 3.03 #1 (Debian)) id 11uyfU-0008D4-00 for ; Mon, 06 Dec 1999 14:59:08 +0100 Date: Mon, 6 Dec 1999 14:59:08 +0100 (CET) From: Egervary Gergely To: freebsd-hackers@freebsd.org Subject: Re: cdrom speed adjustment ioctl In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I've just hacked a new ioctl into the ATAPI cdrom driver, which > lets the user to specify (pronounce: ``slow down'' :) the speed > of todays' extremely high speed drives. ok, so i see you like the idea - so the question is: should we implement a new ioctl for it, or - as like scsi - should we use a program like camcontrol for it? basically i prefer doing both, as the current atapi implementation includes the most important atapi commands, it could be more complete, and i think it's nice to have a user space program for sending packet commands... :) -- mauzi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 11:12:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 78FAB15A08 for ; Mon, 6 Dec 1999 11:12:39 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA70797; Mon, 6 Dec 1999 09:54:46 -0800 (PST) (envelope-from dillon) Date: Mon, 6 Dec 1999 09:54:46 -0800 (PST) From: Matthew Dillon Message-Id: <199912061754.JAA70797@apollo.backplane.com> To: Alfred Perlstein Cc: hackers@FreeBSD.ORG Subject: Re: vfs_bio questions/nfs cluster commit References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I haven't finished looking at the whole thing yet, but I see one immediate (trivial to fix) problem: + BUF_LOCK(holdbp, LK_EXCLUSIVE)) I would recommend getting a *NON* blocking lock, and bumping your gap mechanism if you can't get the lock (and not store the buffer). Otherwise you may create a deadlock situation elsewhere. - Alred, in your followup email you said something about the existing clustering being broken. It seems to work for me (64KB clustering), could you give me an example? NFS clustering is based very heavily only VFS clustering. If you aren't seeing NFS clustering for commit messages then perhaps VFS clustering got broken somehow... -Matt :I've been trying to workout mega-clusters for NFS, since afaik the :vfs_cluster code will only do 64k chunks and we can benifit greatly :by compacting ranges for commit RPCs. :... : :Index: nfs_bio.c :=================================================================== :RCS file: /home/ncvs/src/sys/nfs/nfs_bio.c,v :retrieving revision 1.80 :... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 11:12:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 2E94B15535; Mon, 6 Dec 1999 11:12:39 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA71515; Mon, 6 Dec 1999 11:05:18 -0800 (PST) (envelope-from dillon) Date: Mon, 6 Dec 1999 11:05:18 -0800 (PST) From: Matthew Dillon Message-Id: <199912061905.LAA71515@apollo.backplane.com> To: "Jonathan M. Bresler" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) References: <19991205120428.E6F4514C3E@hub.freebsd.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : : :[snip] :> I am a good programmer and can fix things :-). But I've had to deal with :> a number of nightmare situations by commercial entities deploying FreeBSD :> and at least three (including one very recently) where commercial entities :> have refused to upgrade past 2.2.x due to perceived stability problems. :[snip] :> :> -Matt :> Matthew Dillon : : we can not identify the specific problem from this message. :without sufficient information to indentify and hopefully reproduce :the problem, we can not address it. please provide this information :if it is available to you. if it is not, please provide us contact :information for the commercial entities experiencing the problem. : :jmb First, the statement was anecdotal -- all of the problems have been fixed in -current. Second, these people posted their questions and problems on -hackers or -stable or -current and got not one useful response, then came to me privately and asked for help. For you, or anyone, to attempt to dismiss the statement by implying help after the fact is bogus. This being a freeware development project it is perfectly ok to say "I can't help" or "I don't have time". It is NOT ok to imply help when none would otherwise be forthcoming. Two commercial entities approached me on helping fix INN bugs. Those turned out to be related to a VM/mmap bug (2.x, 3.x, 4.x), which I fixed in 4.x, and a swap bug (2.x, 3.x) which I couldn't fix in 2.x or 3.x but which was already fixed in 4.x by the rewrite of the swap code I had done earlier in the year. This bug turned out to be a KVM fragmentation problem due to the large linear arrays that 2.x and 3.x allocate for swap metadata. I had another commercial entity approach me in regards to dealing with low-memory lockup problems which, again, I was unable to completely fix in 3.x but was able to fix in 4.x because of the getnewbuf() rewrite. I had another commercial entity approach me in regards to the ps/procfs problem (before Poul went on his procfs rampage) and I gave that person the workaround I used at BEST, which is simply to flock() around the procfs code in /bin/ps to force serialization. That's just the recent stuff, off the top of my head. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 11:13: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 8CAE21555F for ; Mon, 6 Dec 1999 11:12:39 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA71233; Mon, 6 Dec 1999 10:38:43 -0800 (PST) (envelope-from dillon) Date: Mon, 6 Dec 1999 10:38:43 -0800 (PST) From: Matthew Dillon Message-Id: <199912061838.KAA71233@apollo.backplane.com> To: "Ronald F. Guilmette" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: tmpfs .. ? References: <21237.944421456@monkeys.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :In message <199912050447.UAA58828@apollo.backplane.com>, :Matthew Dillon wrote: : :> Mail queue files are persistant enough (upwards of 5 days if a destination :> is down) that you run a real risk of losing something important if :> you crash and wipe. I would not use MFS at all and I would only use VN :> with persistant store, but the performance is going to be similar to :> using a normal filesystem so it may not be worth doing. : :Yea, someone else I was talking with about this said the same thing. : :I just can't get over the nagging feeling that (for the mail spool :directory) there ought to be something that is ultra-super-deluxe :fast that I should be using. :-) : :> Normal :> filesystems with softupdates turned on make pretty good mail spools though : :OK, I've seen several mentions now of `softupdates', and I think that I :have a general (vague?) notion of what `softupdates' is all about, but :allow me to disaply my ignorance one more time and ask which man page :(or document) I should be looking at to learn all of the specifics :regarding `softupdates'. (I looked at `man tunefs' and I don't see :nuttin' there, so where exactly is/are `softupdates' documented?) Softupdates requires a little kernel hacking. cd /usr/src/sys/ufs/ffs read the README.softupdates file in that directory. Don't worry about Kirk's license until you actually decide you intend to use it in production on a commercial system. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 11:13: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id EDCE4154E1 for ; Mon, 6 Dec 1999 11:12:39 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA70974; Mon, 6 Dec 1999 10:13:50 -0800 (PST) (envelope-from dillon) Date: Mon, 6 Dec 1999 10:13:50 -0800 (PST) From: Matthew Dillon Message-Id: <199912061813.KAA70974@apollo.backplane.com> To: Peter Jeremy Cc: hackers@FreeBSD.ORG, rfg@monkeys.com Subject: Re: tmpfs .. ? References: <99Dec6.092620est.40335@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Sat, 04 Dec 1999 15:44:49 -0800, "Ronald F. Guilmette" wrote: :>Specifically, I'm planning a large mail server... which will use Sendmail... :>and I'd really like to allocate the Sendmail queue files... which typically :>have a rather short lifespan... on/in some sort of filesystem (e.g. an :>mfs or else this VN thing you are talking about) that would tend to give :>petter performance than just using an ordinary disk-based filesystem. : :This doesn't sound like a good application for a temporary filesystem. :Whilst the files do typically have a short lifetime, and there are lots :of them, they represent mail items which your server has accepted :responsibility for delivering. Also, the queue files can potentially :exist for several days (the default timeout is 5 days). : :I would suggest that UFS with softupdates represents a better performance/ :reliability tradeoff than MFS or a swap-backed vnode. : :The main problem is that sendmail places all queue files (and there :are several for each undelivered message) in one directory - and very :large directories are not handled particularly efficently by UFS. The :simple solutions are: :1) switch to an alternative MTA that doesn't display this behaviour. :2) hack sendmail to have multiple subdirectories within the main : queue directory - with the subdirectory chosen by hashing the : sendmail job id. : :Peter The actual problem is sendmail's constant *rescanning* of the directory. So you don't really need to hack sendmail to fix it though it would be nice if sendmail built the feature in. What you want to do is move the queue file to a queue directory based on the number of retries that have occured on the queue file. You then run fewer sendmail -q's on the directories representing higher retry counts and more sendmail's on the directories representing lower retry counts. The retry count happens to be a field in the queue control file so it's relatively easy to write a program to move queue files around baed on it. You have to be sure you properly lock the queue file while renaming it, of course, so you cannot (easily) use a script, and you have to test for duplicate queue id's so you do not rename-over, but that's it. Running sendmail's on multiple queues is trivial: sendmail -q1m -OMaxDaemonChildren=50 sendmail -q1m -OMaxDaemonChildren=20 -OQueueDirectory= sendmail -q1m -OMaxDaemonChildren=10 -OQueueDirectory= sendmail -q1m -OMaxDaemonChildren=5 -OQueueDirectory= sendmail -q1m -OMaxDaemonChildren=5 -OQueueDirectory= sendmail -q1m -OMaxDaemonChildren=5 -OQueueDirectory= sendmail -q1m -OMaxDaemonChildren=5 -OQueueDirectory= ... I used this trick at BEST and it works extremely well. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 11:13:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id E5D3215528; Mon, 6 Dec 1999 11:12:39 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA71206; Mon, 6 Dec 1999 10:34:35 -0800 (PST) (envelope-from dillon) Date: Mon, 6 Dec 1999 10:34:35 -0800 (PST) From: Matthew Dillon Message-Id: <199912061834.KAA71206@apollo.backplane.com> To: Ed Hall Cc: "Jonathan M. Bresler" , kris@hub.freebsd.org, freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) References: <199912051944.LAA17720@screech.weirdnoise.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :You write: :: we can not identify the specific problem from this message. :: without sufficient information to indentify and hopefully reproduce :: the problem, we can not address it. please provide this information :: if it is available to you. if it is not, please provide us contact :: information for the commercial entities experiencing the problem. : :I work at Yahoo. My address there is "edhall@yahoo-inc.com". : :On a recent project I encountered two show-stopping bugs with 3.3-release :that did not exist in 2.2.8-release: : :1) Random crashes in FXP interrupt or low-level IP code. Something is : clobbering the kernel stack--possibly the NCR driver, since using an : Adaptec made the problem stop, as did a backport of the CAM driver : Peter Wemm tried. This was on an N440BX, which is becoming quite : common in server applications. Other installations are apparantly : seeing the same problem on this hardware. : :2) A hard loop in the pagedaemon. This was especially egregious, since : it meant the system had to be rebooted from the console--and since : the application could elicit the problem within a few minutes. : Disabling the use of mmap() for file update in the application : prevented the problem. After spending a day trying to cook up a : test program that elicited the same behavior that the application : did, I gave up for lack of time. But there have been other reports : of late that sound like this problem, mostly in high VM/RAM situations. : :That's two serious bugs that exist in 3.3-release but not in 2.2.8-release. :Looking back through the archives, I can see that I'm not the only one who :has experienced them. I came away from the experience with the feeling that :the FreeBSD project has some serious Q/A problems... and I can assure you, :I'm not alone in this feeling. : : -Ed Well, #2 at least should be fixed in -current. Unfortunately the changes to the VM system were too extensive to backport to 3.x. Or, I should say, that at the time I started working on the VM system core was not interested in allowing me to backport the changes, and then later it was simply too late - too many changes had been made. #1 has come up a couple of times. There was a conversation in October that closely relates to your problem: :From: Joe McGuckin :Subject: fxp related kernel panic : :I have a 3.3-stable machine that I use as a news router (running diablo). The :fxp0 interface averages 10-15 Mbps bandwidth continously. : :About once a week the machine crashes & reboots. We enabled the debugger this ti :me :and captured the following debug output: : :Fatal trap 12: page fault while in kernel mode :fault virtual address = 0x382e4641 :fault code = supervisor write, page not present :instruction pointer = 0x8:0xc01a372e :stack pointer = 0x10:0xc02523b0 :frame pointer = 0x10:0xc02523c0 :code segment = base 0x0, limit 0xfffff, type 0x1b : = DPL 0, pres 1, def32 1, gran 1 :processor eflags = interrupt enabled, resume, IOPL = 0 :current process = Idle :interrupt mask = net :kernel: type 12 trap, code=0 :Stopped at fxp_add_rfabuf+0x1de: movw %ax,0x4(%esi) :db> : :%uname -a :FreeBSD feeder.via.net 3.3-STABLE FreeBSD 3.3-STABLE #7: Mon Oct 18 17:14:40 PDT : 1999 lewis@feeder.via.net:/usr/src/sys/compile/DIABLO i386 : :%dmesg :Copyright (c) 1992-1999 FreeBSD Inc. :Copyright (c) 1982, 1986, 1989, 1991, 1993 : The Regents of the University of California. All rights reserved. :FreeBSD 3.3-STABLE #7: Mon Oct 18 17:14:40 PDT 1999 To which DG responded: :From: David Greenman :Subject: Re: fxp related kernel panic :To: Joe McGuckin :Cc: hackers@FreeBSD.ORG, lewis@lppi.com :Date: Tue, 26 Oct 1999 11:43:02 -0700 : : : Let me guess...your system has an Intel N440BX motherboard, right? If so, :then it's a known problem with no solution yet. : :-DG : :David Greenman :Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org :Creator of high-performance Internet servers - http://www.terasolutions.com :Pave the road of life with opportunities. And he also said: :From: David Greenman :Subject: Re: fxp related kernel panic :To: Lew Payne :Cc: hackers@FreeBSD.ORG, Joe McGuckin :Date: Tue, 26 Oct 1999 13:19:45 -0700 : : :>Hi David -- What if I install a *real* EtherExpress Pro-100B (or :>whatever it's known as today) in the PCI slot, and use it instead :>of the on-board (N440BX motherboard) fxp0 interface? :> :>Judging that you probably know the nature of the problem, do you :>think this might circumvent it? : : I think it is caused by the NCR/Symbios controller. It might be a side :effect of the NCR just using up a lot of PCI bandwidth, with the real bug :being in the fxp driver (although I've looked and haven't found one). So :I don't think putting in a real Pro/100 will have any effect on the problem. :Of course I don't really know what is causing it, so just about anything :is possible. : :-DG : :David Greenman And that, I'm afraid is where it has been left. Nobody is sure where the problem is. I suspect that it may be a DMA synchronization problem with either the NCR or the FXP driver, or perhaps heavy PCI bandwidth useage is generating a FIFO overrun error during the FXP DMA that the driver is not handling properly. I just don't know. The only current solution is to use an adaptec controller. I have personally had *extremely* good luck with adaptec's, 2940UW, 7896 (or 97) U2W (on-motherboard), and 7890 (or 91) U2W (PCI card). I think part of the reason the problem has not been fixed is that many of the hardcore developers are using Adaptec controllers rather then NCR controllers and simply cannot reproduce it. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 11:13:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 020F515BBE; Mon, 6 Dec 1999 11:12:39 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA70541; Mon, 6 Dec 1999 09:35:13 -0800 (PST) (envelope-from dillon) Date: Mon, 6 Dec 1999 09:35:13 -0800 (PST) From: Matthew Dillon Message-Id: <199912061735.JAA70541@apollo.backplane.com> To: Wes Peters Cc: Kris Kennaway , freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) References: <199912050514.VAA58998@apollo.backplane.com> <3849FD95.F0434263@softweyr.com> <199912050646.WAA59445@apollo.backplane.com> <384B228D.FFE9728@softweyr.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Matthew Dillon wrote: :> : :> :All running software has serious problems, that's why it is never considered :> :done. Taking the time to enumerate specific problems that are currently :> :plaguing an installation is the only way anyone can possibly hope to help. :> :Problems reports of "It don't work" are helpful to absolutely noone. :> :> This simply isn't true. I have written plenty of software (large :> projects) that do not have serious problems and, in fact, some do not :> have any known problems at all. I have written several operating systems :> and one of them is least as complex as the FreeBSD core (but not as :> complex if you count drivers) which are bug-free (that is, there have :> been no recorded crashes and except for feature updates have never been :> rebooted). : :So you haven't discovered the rest of the bugs in the system. Software :is created by humans, and humans are fallible, therefore the software :is also fallible. Any claims of divinity on your part will be summarily :rejected. : :-- : "Where am I, and what am I doing in this handbasket?" : :Wes Peters Softweyr LLC You are missing the point big time, Wes. Just because you can make the statement that "no software is without bugs" does not justify having software that has a *LOT* of bugs. It is possible to write robust software. Would you rather have Windows? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 11:13:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4BF1715BBA for ; Mon, 6 Dec 1999 11:12:39 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA71061; Mon, 6 Dec 1999 10:17:31 -0800 (PST) (envelope-from dillon) Date: Mon, 6 Dec 1999 10:17:31 -0800 (PST) From: Matthew Dillon Message-Id: <199912061817.KAA71061@apollo.backplane.com> To: Matthew Jacob Cc: "Jordan K. Hubbard" , Dan Seguin , Bill Fumerola , "Ronald F. Guilmette" , freebsd-hackers@FreeBSD.ORG Subject: Re: Strange SCSI sickness References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> treatment, in roughly this order: :> :> 3a) Complete check of all cables and the seating of connectors. :> :> 3b) Examination of the drive(s) in question for any cooling or :> mounting deficiencies. Depending on the SCSI errors in question, :> I might even investigate firmware updates for the drive(s). :> :> 3c) Examination of the controller for correct seating and bus slot :> (in older PCI mobos, this makes a difference) as well as its :> firmware revision level. :> : :3d) Any system experiencieng scsi parity errors should have all components : power cycled (for self healing termpwr- fuses) and any pluggable : termpwr fuses checked (these are exceedingly rare now- but if you : had a SparcStation, they'd be the first thing to check- they're next : to the ethernet connector on the motherboard). If you're not using : an active terminator, you should be. Check for multiple termination- : both ends of the bus must have termination enabled, nothing else- : check drive and hba. If necessary, derate off of Ultra to Fast to : see if this was the source of problems. : :[ a parity error indicates trashed signals. a parity error in data phase :indicates signal reflection, skew, or rise time problems. signal quality :is greatly affected by: bus length, termination, cable impedance mismatches ] Only buy terminators with terminator-power LEDs, and only use external terminators (it makes it easier to maintain the drives). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 11:26:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 7C49614C93; Mon, 6 Dec 1999 11:26:29 -0800 (PST) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (cs1-gw.cs.binghamton.edu [128.226.171.72]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with SMTP id OAA10187; Mon, 6 Dec 1999 14:26:20 -0500 (EST) Date: Mon, 6 Dec 1999 13:13:18 -0500 (EST) From: Zhihui Zhang To: freebsd-hackers@freebsd.org, freebsd-fs@freebsd.org Subject: ELF & putting inode at the front of a file Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have modified FFS filesystem code to put the disk inode at the beginning of a file, i.e, the logical block #0 of each file begins with 128 bytes of its disk inode and the rest of it are file data. Everything seems to be working. But I am stuck with an ELF executable file stored in this layout - I can not run it. The kernel uses memory map to read the ELF file and assumes that the file data begins at offset 0. I have looked at the files kern_exec.c and imgact_elf.c trying to adjust the header pointers by an offset of 128 bytes to at least let the kernel recognize that it is an ELF file. But still I got messages like "too few PT_LOAD segments". Obviously, I need to modify the kernel files elsewhere, perhaps those under directory contrib/rtld-elf/*, which I have never read before. My questions are: (1) What consequences will my file layout affect the load and execution of an ELF file? Do I have to adjust the virtual addresses in the ELF object file as well? (2) If I modify any files under contrib/rtld-elf, how to make the modifications take effect. Is that as simple as "make" and followed by "make install". I am new to these kernel stuff. Any help or hints are very appreciated. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 11:31:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from monkeys.com (i180.value.net [206.14.136.180]) by hub.freebsd.org (Postfix) with ESMTP id 95D7015DD3 for ; Mon, 6 Dec 1999 11:31:09 -0800 (PST) (envelope-from rfg@monkeys.com) Received: from monkeys.com (localhost [127.0.0.1]) by monkeys.com (8.9.3/8.9.3) with ESMTP id KAA02744 for ; Mon, 6 Dec 1999 10:25:51 -0800 (PST) To: freebsd-hackers@FreeBSD.ORG Subject: Re: natd is jumpy In-reply-to: Your message of Mon, 06 Dec 1999 02:38:57 -0700. Date: Mon, 06 Dec 1999 10:25:51 -0800 Message-ID: <2742.944504751@monkeys.com> From: "Ronald F. Guilmette" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Nick Rogness wrote: >On Sun, 5 Dec 1999, Archie Cobbs wrote: > >> Brian Dean writes: >> > No dropped packets, but definitely some occasional long delays before >> > I get the echo. However, I must concede, based on other respondants, >> > that something else must be going on and I cannot necessarily >> > attribute this to divert/firewall/natd. > > > I forgot to mention, are you connecting at V.90 speeds? If so > renegotiations/retrains will take place and you will see a speed > jump or hesitation. Disable this in the modem. There are > specific S registers to do this... Ummm yea! That comment reminds me about all of the V.90 modem woes I was experiencing awhile back. I had an older Zoom 56k modem that seemed to work just fine with my _old_ ISP. Then I changed ISPs, and I started to see frequent problems. Some- times the modem would just seem to take a little nap for about 30 seconds or so. (Perhaps it was doing that retraining/renegotiation thing. I'm not sure.) But other times, I would just abruptly lose carrier for no apparent reason. (This was an external modem, so I could watch the various LEDs.) Of course, at first I blamed my new ISP. I figured that _they_ were doing something wrong because the modem had woked just fine with my prior ISP. So I called them up and started giving their tech support folks a hard time... in a friendly way of course. :-) The only idea/theory/suggestion that they came up with was that I must have a modem with Rockwell 56K chipset in it, and they said that they had had a number of problems with people using Rockwell-based modems because (they alleged) the Rockwell chipset was less than perfect, and because it didn't play well with the Lucent-chipset-based stuff that they had in their Portmasters. OK, so I run down to the local computer store and I'm looking for a _new_ V.90 modem with a *Lucent* chipset. The only one they had was a newer version of the same bloody Zoom modem I already have. Now I already don't like Zoom, because their tech support sucks, but I buy one of these new Zoom modems with the Lucent chipset anyway. Result: I have _never_ had a single problem since. The only problem I have now is finding the time to list the old (Rockwell- based) modem on eBay. :-) P.S. Please DO NOT flame me for any of the above. I most definitely DO NOT own stock in either Lucent or Rockwell, and I would be the first one to admit that I have absolutely NO IDEA for sure what exactly was causing my earlier problems with the Rockwell-based Zoom modem. For all I know, it was working fine and I just had it configured wrong. I'm just telling the story, as it happened. P.P.S. More info: Model # of old modem: Zoom 2849 Model # of new modem: Zoom 2949L To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 11:35:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 5637415191; Mon, 6 Dec 1999 11:35:40 -0800 (PST) (envelope-from kvandel@cs.duke.edu) Received: from wookie.vandelden.com (IDENT:root@s-kvandel.cs.duke.edu [152.3.134.91]) by duke.cs.duke.edu (8.9.1/8.9.1) with SMTP id LAA03707; Mon, 6 Dec 1999 11:36:36 -0500 (EST) From: kvandel Reply-To: kvandel@cs.duke.edu Organization: Duke University To: Mike Smith Subject: Re: fxp, xl driver question .. (routing)(SOLVED) Date: Mon, 6 Dec 1999 11:10:33 -0600 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <199912060813.AAA01499@mass.cdrom.com> In-Reply-To: <199912060813.AAA01499@mass.cdrom.com> Cc: freebsd-hackers@freebsd.org MIME-Version: 1.0 Message-Id: <99120611312500.00860@wookie.vandelden.com> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike- > I should have summarised this by saying: Correct use of the latency > timer will shorten your DMA bursts for you when necessary, giving you the > best of both worlds. When it's safe to run a long burst, you will. When > you need to push a device off the bus, that will happen too. After re-reading the PCI System Architecture section.. you are correct. The Text: If the current master has exhausted its LT, still has its GNT# and has not yet completed its burst transfer, it may retain ownership of the bus and continue to burst data until either: a. it completes its overall burst transfer b. its GNT# is removed by the arbiter In the latter case, the current master is permitted to complete one or more data transfer and must then yield the bus. My misunderstanding: From the wording in the text, it is ambiguous as whether the a "data transfer" is a frame(one adress cycle + multiple data cycles), or a data cycle. > And the obvious extension to the "worst case" calculation is that if you > have N master devices each with a latency timer of X, your worst-case > timing for CPU access to a device is (N * X) + (N * arb overhead), just > in case that wasn't clear. Much better... thanks, kurt > > -- > \\ Give a man a fish, and you feed him for a day. \\ Mike Smith > \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org > \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com -- uname -a > Linux wookie.vandelden.com 2.2.13 #1 < To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 11:35:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 4EC7F15185 for ; Mon, 6 Dec 1999 11:35:53 -0800 (PST) (envelope-from dennis@etinc.com) Received: from dbsys (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.9.3/8.9.3) with SMTP id OAA22030; Mon, 6 Dec 1999 14:39:01 -0500 (EST) Message-Id: <199912061939.OAA22030@etinc.com> X-Sender: dennis@etinc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 06 Dec 1999 14:34:42 -0500 To: Matthew Dillon From: Dennis Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) Cc: hackers@freebsd.org In-Reply-To: <199912061905.LAA71515@apollo.backplane.com> References: <19991205120428.E6F4514C3E@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 11:05 AM 12/6/99 -0800, you wrote: > >: >: >:[snip] >:> I am a good programmer and can fix things :-). But I've had to deal with >:> a number of nightmare situations by commercial entities deploying FreeBSD >:> and at least three (including one very recently) where commercial entities >:> have refused to upgrade past 2.2.x due to perceived stability problems. >:[snip] >:> >:> -Matt >:> Matthew Dillon >: >: we can not identify the specific problem from this message. >:without sufficient information to indentify and hopefully reproduce >:the problem, we can not address it. please provide this information >:if it is available to you. if it is not, please provide us contact >:information for the commercial entities experiencing the problem. >: >:jmb > > First, the statement was anecdotal -- all of the problems have been > fixed in -current. THIS is EXACTLY what I was saying. What good does it do anyone in a commercial environment that its fixed in -current? Thats the reason we dumped NetBSD, because everyone was using -current the the releases were always unstable. Of course moving to -current to fix the problems in 3.x introduce a whole new set of problems, in which case you have an OS that is never going to be stable. When 4.0 is released we'll be told that the problems of 4.0 are fixed in -current. When does it end? DB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 11:51:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by hub.freebsd.org (Postfix) with ESMTP id 6F4F21535C for ; Mon, 6 Dec 1999 11:51:47 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id LAA00484; Mon, 6 Dec 1999 11:53:43 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912061953.LAA00484@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Warner Losh Cc: hackers@FreeBSD.ORG Subject: Re: tty level buffer overflows In-reply-to: Your message of "Fri, 03 Dec 1999 11:14:47 MST." <199912031814.LAA11849@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Dec 1999 11:53:43 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <199912030155.RAA02824@mass.cdrom.com> Mike Smith writes: > : It's documented in the sio(4) manpage, which is always worth reading. > > Even reading the sio manpage is unclear. All it says is that things > are too slow. Steady state I don't get these, just every now and > again it happens. No apparent correlation to the time of day, cron > jobs running, etc. > > What I was wondering is if there is a way to, say, double the buffer > size. Also, what is the number of overflows mean? Is that bytes? > clists? 16byte chunks? The overflow seems to happen just once and it > is always a number less than 1000. I'd gladly spend an extra 1-2k of > memory to help my poor ppp machine over the humps. Growing the buffer isn't the solution; it should be big enough already. We need to work out why a system that should have no trouble with the data rate in question is croaking so trivially. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 11:53:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id A58D414E86 for ; Mon, 6 Dec 1999 11:53:31 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id UAA31703; Mon, 6 Dec 1999 20:19:28 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id UAA01101; Mon, 6 Dec 1999 20:06:26 +0100 (CET) (envelope-from wilko) From: Wilko Bulte Message-Id: <199912061906.UAA01101@yedi.iaf.nl> Subject: Re: Strange SCSI sickness In-Reply-To: from Matthew Jacob at "Dec 5, 1999 2:42:55 pm" To: mjacob@feral.com Date: Mon, 6 Dec 1999 20:06:26 +0100 (CET) Cc: kbyanc@posi.net, jkh@zippy.cdrom.com, dseg@texar.com, billf@chc-chimes.com, rfg@monkeys.com, freebsd-hackers@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Matthew Jacob wrote ... > > > Another interesting cause for problems is duff powersupplies. As the > > proverb goes "every machine is as good as it's PSU". E.g. I just struggeled > > with a DLT tape unit that inexplicable reset itself. After examining the > > 5Volts rail with a scope I found glitches on it whenever the drive did a > > bit of rewinding (dropping out of streaming mode). Had me stumped for a > > while. > That's pretty rare these days. It used to happen all the time when > switching power supplies first appeared (motorboating is what we called > it), but even recently I had a marginal supply that supplied 4.4VDC- > *just* enough to function *most* of the time. This was a DLT4500 5 cartridge changer. I've seen multiple failures similar to this one due to degraded electrolytic output caps that made the feedback circuitry of the switching PSU unhappy. DLT4500 has it's PSU stashed away in an ill ventilated spot, the fact that the heatsinks are close to the output caps does not help either. Heat tends to kill electr. caps. Anyway, the topic at hand is more suitable for -hardware (or so) I guess. Wilko -- Wilko Bulte Arnhem, The Netherlands - The FreeBSD Project WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 11:54:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from orthanc.ab.ca (orthanc.ab.ca [207.167.3.130]) by hub.freebsd.org (Postfix) with ESMTP id 9DF3315516 for ; Mon, 6 Dec 1999 11:54:54 -0800 (PST) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost.orthanc.ab.ca [127.0.0.1]) by orthanc.ab.ca (8.10.0.Beta6/8.10.0.Beta6) with ESMTP id dB6JspQ24367 for ; Mon, 6 Dec 1999 12:54:51 -0700 (MST) Message-Id: <199912061954.dB6JspQ24367@orthanc.ab.ca> To: hackers@FreeBSD.ORG Subject: Re: tmpfs .. ? In-reply-to: Your message of "Mon, 06 Dec 1999 10:13:50 PST." <199912061813.KAA70974@apollo.backplane.com> Date: Mon, 06 Dec 1999 12:54:51 -0700 From: Lyndon Nerenberg Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :The main problem is that sendmail > places all queue files (and there :are several for each > undelivered message) in one directory Sendmail 8.10 addresses this by allowing for multiple queue directories. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 11:54:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 4819C15129; Mon, 6 Dec 1999 11:54:53 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id JAA17769; Mon, 6 Dec 1999 09:58:59 -0800 Date: Mon, 6 Dec 1999 09:58:59 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Mike Smith Cc: hackers@freebsd.org Subject: Re: tty level buffer overflows In-Reply-To: <199912060441.UAA00805@mass.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > > Er, you should read the sio(4) manpage too. tty-level buffer overflows > > > have nothing to do with interrupt latency/execution time. > > > > You mean this: > > > > sio%d: tty-level buffer overflow. Problem in the application. Input has > > arrived faster than the given module could process it and some has been > > lost. > > Yup. Ignore the "problem in the application" part, as that predicates > that the kernel and driver are working properly, which doesn't seem to be > the case. The problem here is that the buffer between the top side of > the driver and the application isn't being drained fast enough. It would > be educational to know what the app is sleeping on when these messages > are emitted; just dropping to ddb and using 'ps' would probably be > enough. There has to be some reason that the process is either not being > woken when data arrives, or is being held up somewhere else for long > enough that the clist overflows. That's tough because it's transitory and hard to notice as I only rlogin into this machine! Sounds to me a gdb breakpoint is what's needed, but this is difficult to do for this machine. > Does the problem still manifest with the recent scheduler changes? > Perhaps the comms processes are being unfairly scheduled against for some > reason? The kernel is a November 12 kernel. Maybe it's better now. However, I'm still staggering under the recent bdev changes - when everything has settled down and all my other freebsd machines can boot all the way up and are all up to date, I'll revisit this. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 12: 1:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.interactive.net (smtp.interactive.net [216.107.133.18]) by hub.freebsd.org (Postfix) with ESMTP id 9FB7E14E33 for ; Mon, 6 Dec 1999 12:01:28 -0800 (PST) (envelope-from viren@interactive.net) Received: from nebula ([216.107.141.67]) by smtp.interactive.net (InterMail v4.01.00 201-232-112) with ESMTP id <19991206200007.BATY2929.smtp@nebula> for ; Mon, 6 Dec 1999 15:00:07 -0500 Message-Id: <4.2.0.58.19991206150019.00a63380@pop.interactive.net> X-Sender: viren@pop.interactive.net (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 06 Dec 1999 15:01:20 -0500 To: freebsd-hackers@freebsd.org From: Viren Jain Subject: Linking problems w/ pthreads on 3.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG NOTE: Please reply directly to my email address (viren@interactive.net) Platform: x86, FreeBSD 3.3 While trying to link a threaded application with -pthread using the following command line: gcc -I/usr/local/include -L/usr/local/lib/mysql -pthread -o impd daemon.o db.o handlers.o imp_list.o imp_util.o log.o main.o net.o opt.o request.o sig.o statsd.o util.o -lmysqlclient I receive the following errors: daemon.o(.text+0x10): undefined reference to `__pthread_fork' db.o(.text+0x33c): undefined reference to `__pthread_sleep' main.o(.text+0xce): undefined reference to `__pthread_detach' net.o(.text+0x196): undefined reference to `__pthread_select' net.o(.text+0x411): undefined reference to `__pthread_read' net.o(.text+0x535): undefined reference to `__pthread_write' Threaded libraries appear to be installed in /usr/lib (libc_r.a, libc_r.so, libc_r.so.3, and libc_r_p.a) and thus I am unsure of how to correct this problem. Any help or advice would be appreciated. -- Viren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 12: 5:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 7D27D15037 for ; Mon, 6 Dec 1999 12:05:25 -0800 (PST) (envelope-from billf@chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 4421A1C4F; Mon, 6 Dec 1999 14:06:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id 35D7B381B; Mon, 6 Dec 1999 14:06:14 -0500 (EST) Date: Mon, 6 Dec 1999 14:06:14 -0500 (EST) From: Bill Fumerola To: Dennis Cc: Matthew Dillon , hackers@freebsd.org Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-Reply-To: <199912061939.OAA22030@etinc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 6 Dec 1999, Dennis wrote: > Of course moving to -current to fix the problems in 3.x introduce a whole > new set of problems, in which case you have an OS that is never going to be > stable. When 4.0 is released we'll be told that the problems of 4.0 are > fixed in -current. When does it end? A rose by any other name.... 4.0 will soon be 4.0-{RELEASE,STABLE} will it be okay for you to use then? When does it end? Hopefully never. -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 12:19:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 712661564F for ; Mon, 6 Dec 1999 12:19:37 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA72301; Mon, 6 Dec 1999 12:19:20 -0800 (PST) (envelope-from dillon) Date: Mon, 6 Dec 1999 12:19:20 -0800 (PST) From: Matthew Dillon Message-Id: <199912062019.MAA72301@apollo.backplane.com> To: Dennis Cc: hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) References: <19991205120428.E6F4514C3E@hub.freebsd.org> <199912061939.OAA22030@etinc.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :>:the problem, we can not address it. please provide this information :>:if it is available to you. if it is not, please provide us contact :>:information for the commercial entities experiencing the problem. :>: :>:jmb :> :> First, the statement was anecdotal -- all of the problems have been :> fixed in -current. : :THIS is EXACTLY what I was saying. What good does it do anyone in a :commercial environment that its fixed in -current? Thats the reason we :dumped NetBSD, because everyone was using -current the the releases were :always unstable. : :Of course moving to -current to fix the problems in 3.x introduce a whole :new set of problems, in which case you have an OS that is never going to be :stable. When 4.0 is released we'll be told that the problems of 4.0 are :fixed in -current. When does it end? : :DB I think the solution here is to change the release mechanism slightly. I believe we made a huge mistake splitting of the 4.x tree from 3.x so early. This time around I think that we should *not* split the tree for four months or so. That is, have a period of 4 months where there is only 4.x, no 5.x. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 12:21:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from screech.weirdnoise.com (209-128-78-198.bayarea.net [209.128.78.198]) by hub.freebsd.org (Postfix) with ESMTP id 8402615737; Mon, 6 Dec 1999 12:21:13 -0800 (PST) (envelope-from edhall@screech.weirdnoise.com) Received: from screech.weirdnoise.com (localhost [127.0.0.1]) by screech.weirdnoise.com (8.8.7/8.8.7) with ESMTP id MAA30052; Mon, 6 Dec 1999 12:22:17 -0800 Message-Id: <199912062022.MAA30052@screech.weirdnoise.com> X-Mailer: exmh version 2.0.2 To: Matthew Dillon Cc: "Jonathan M. Bresler" , kris@hub.freebsd.org, freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-Reply-To: Your message of "Mon, 06 Dec 1999 10:34:35 PST." <199912061834.KAA71206@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Dec 1999 12:22:17 -0800 From: Ed Hall Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've confirmed that neither problem exists in 4.0. There are ample work-arounds, both hardware and software, including just not using 3.3. No fixes, though, just work-arounds... Workarounds for the NCR/FXP issue included: 1) Using 2.2.8 (4.0 isn't a production option). 2) Using a different NIC (a Tulip worked fine). 3) Using a different SCSI adapter (Adaptec, as Matt suggested, works fine). 4) Using a different SCSI driver (Peter managed to get a driver from 4.0 hooked up under 3.3, and it survived two days of torture that would have toasted things within an hour using the stock driver; you'll have to ask him for details). Workarounds for the pagedaemon issue included: 1) Using 2.2.8 (4.0, too, but not as a production option) (do I see a pattern?) 2) Using read()/write() instead of mmap() for certain file updates in our application. In this case read()/write() performed better anyhow. So the two issues I described are no longer "active" for the purposes of my project. I posted because I feared that what I saw as the main issue--that 3.3 is regarded in some circles as not being up to FreeBSD standards--was getting lost in various unseemly side-issues. It could be that I was just plain unlucky, but my experiences suggest that there may be some merit to that view. You be the judge. I've been with BSD a long time--from back when my email address was decvax!randvax!edhall. I want it to succeed, for reasons that are more emotional than rational; my nightmare was having to say that my project (1) worked on Solaris, (2) worked on Linux, but (3) broke FreeBSD. I'd be a pretty poor engineer to play favorites when the facts point in another direction. Fortunately, we were able to discover a more favorable set of facts. This time. -Ed : Matthew Dillon wrote: : :You write: : :: we can not identify the specific problem from this message. : :: without sufficient information to indentify and hopefully reproduce : :: the problem, we can not address it. please provide this information : :: if it is available to you. if it is not, please provide us contact : :: information for the commercial entities experiencing the problem. : : : :I work at Yahoo. My address there is "edhall@yahoo-inc.com". : : : :On a recent project I encountered two show-stopping bugs with 3.3-release : :that did not exist in 2.2.8-release: : : : :1) Random crashes in FXP interrupt or low-level IP code. Something is : : clobbering the kernel stack--possibly the NCR driver, since using an : : Adaptec made the problem stop, as did a backport of the CAM driver : : Peter Wemm tried. This was on an N440BX, which is becoming quite : : common in server applications. Other installations are apparantly : : seeing the same problem on this hardware. : : : :2) A hard loop in the pagedaemon. This was especially egregious, since : : it meant the system had to be rebooted from the console--and since : : the application could elicit the problem within a few minutes. : : Disabling the use of mmap() for file update in the application : : prevented the problem. After spending a day trying to cook up a : : test program that elicited the same behavior that the application : : did, I gave up for lack of time. But there have been other reports : : of late that sound like this problem, mostly in high VM/RAM situations. : : : :That's two serious bugs that exist in 3.3-release but not in 2.2.8-release. : :Looking back through the archives, I can see that I'm not the only one who : :has experienced them. I came away from the experience with the feeling that : :the FreeBSD project has some serious Q/A problems... and I can assure you, : :I'm not alone in this feeling. : : : : -Ed : : Well, #2 at least should be fixed in -current. Unfortunately the : changes to the VM system were too extensive to backport to 3.x. Or, : I should say, that at the time I started working on the VM system core : was not interested in allowing me to backport the changes, and then later : it was simply too late - too many changes had been made. : : #1 has come up a couple of times. There was a conversation in October : that closely relates to your problem: : : :From: Joe McGuckin : :Subject: fxp related kernel panic : : : :I have a 3.3-stable machine that I use as a news router (running diablo). The : :fxp0 interface averages 10-15 Mbps bandwidth continously. : : : :About once a week the machine crashes & reboots. We enabled the debugger this ti : :me : :and captured the following debug output: : : : :Fatal trap 12: page fault while in kernel mode : :fault virtual address = 0x382e4641 : :fault code = supervisor write, page not present : :instruction pointer = 0x8:0xc01a372e : :stack pointer = 0x10:0xc02523b0 : :frame pointer = 0x10:0xc02523c0 : :code segment = base 0x0, limit 0xfffff, type 0x1b : : = DPL 0, pres 1, def32 1, gran 1 : :processor eflags = interrupt enabled, resume, IOPL = 0 : :current process = Idle : :interrupt mask = net : :kernel: type 12 trap, code=0 : :Stopped at fxp_add_rfabuf+0x1de: movw %ax,0x4(%esi) : :db> : : : :%uname -a : :FreeBSD feeder.via.net 3.3-STABLE FreeBSD 3.3-STABLE #7: Mon Oct 18 17:14:40 PDT : : 1999 lewis@feeder.via.net:/usr/src/sys/compile/DIABLO i386 : : : :%dmesg : :Copyright (c) 1992-1999 FreeBSD Inc. : :Copyright (c) 1982, 1986, 1989, 1991, 1993 : : The Regents of the University of California. All rights reserved. : :FreeBSD 3.3-STABLE #7: Mon Oct 18 17:14:40 PDT 1999 : : To which DG responded: : : :From: David Greenman : :Subject: Re: fxp related kernel panic : :To: Joe McGuckin : :Cc: hackers@FreeBSD.ORG, lewis@lppi.com : :Date: Tue, 26 Oct 1999 11:43:02 -0700 : : : : : : Let me guess...your system has an Intel N440BX motherboard, right? If so, : :then it's a known problem with no solution yet. : : : :-DG : : : :David Greenman : :Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org : :Creator of high-performance Internet servers - http://www.terasolutions.com : :Pave the road of life with opportunities. : : And he also said: : : :From: David Greenman : :Subject: Re: fxp related kernel panic : :To: Lew Payne : :Cc: hackers@FreeBSD.ORG, Joe McGuckin : :Date: Tue, 26 Oct 1999 13:19:45 -0700 : : : : : :>Hi David -- What if I install a *real* EtherExpress Pro-100B (or : :>whatever it's known as today) in the PCI slot, and use it instead : :>of the on-board (N440BX motherboard) fxp0 interface? : :> : :>Judging that you probably know the nature of the problem, do you : :>think this might circumvent it? : : : : I think it is caused by the NCR/Symbios controller. It might be a side : :effect of the NCR just using up a lot of PCI bandwidth, with the real bug : :being in the fxp driver (although I've looked and haven't found one). So : :I don't think putting in a real Pro/100 will have any effect on the problem. : :Of course I don't really know what is causing it, so just about anything : :is possible. : : : :-DG : : : :David Greenman : : And that, I'm afraid is where it has been left. Nobody is sure where : the problem is. I suspect that it may be a DMA synchronization problem : with either the NCR or the FXP driver, or perhaps heavy PCI bandwidth : useage is generating a FIFO overrun error during the FXP DMA that the : driver is not handling properly. I just don't know. : : The only current solution is to use an adaptec controller. I have : personally had *extremely* good luck with adaptec's, 2940UW, 7896 (or 97) : U2W (on-motherboard), and 7890 (or 91) U2W (PCI card). : : I think part of the reason the problem has not been fixed is that many : of the hardcore developers are using Adaptec controllers rather then NCR : controllers and simply cannot reproduce it. : : -Matt : Matthew Dillon : : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 12:24:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pau-amma.whistle.com (pau-amma.whistle.com [207.76.205.64]) by hub.freebsd.org (Postfix) with ESMTP id 2E97215664 for ; Mon, 6 Dec 1999 12:24:33 -0800 (PST) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id MAA44565; Mon, 6 Dec 1999 12:23:49 -0800 (PST) Date: Mon, 6 Dec 1999 12:23:49 -0800 (PST) From: David Wolfskill Message-Id: <199912062023.MAA44565@pau-amma.whistle.com> To: dillon@apollo.backplane.com, jeremyp@gsmx07.alcatel.com.au Subject: Re: tmpfs .. ? Cc: hackers@FreeBSD.ORG, rfg@monkeys.com In-Reply-To: <199912061813.KAA70974@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Date: Mon, 6 Dec 1999 10:13:50 -0800 (PST) >From: Matthew Dillon > The actual problem is sendmail's constant *rescanning* of the directory. To the extent that the directory is populated, yes. (Scanning an empty directory isn't an overwhelmingly resource-intensive operation.) > So you don't really need to hack sendmail to fix it though it would be > nice if sendmail built the feature in. What you want to do is move the > queue file to a queue directory based on the number of retries that have > occured on the queue file. You then run fewer sendmail -q's on the > directories representing higher retry counts and more sendmail's on the > directories representing lower retry counts. Actually, for a certain class of intended recipients, some of my colleagues & I have been working on (and support, in a production environment) some changes to sendmail to have sendmail (create and) use domain-specific queue directories. The class of recipients is that set that is intended to retrieve mail via the SMTP "ETRN" command. I submit that having sendmail use the separate queue directories in this fashion is rather more beneficial than post-processing the queue. :-) For those in the SF Bay area, I'll be giving a "short but cool" talk at the December (16th) BayLISA meeting about what we did. We were too late to get the code included in sendmail 8.10, but we expect it will be contributed back to sendmail.org in time to be part of 8.11. Cheers, david -- David Wolfskill dhw@whistle.com UNIX System Administrator voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 12:25:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by hub.freebsd.org (Postfix) with ESMTP id 0CF8A14F99; Mon, 6 Dec 1999 12:25:46 -0800 (PST) (envelope-from rminnich@lanl.gov) Received: from mini.acl.lanl.gov (root@mini.acl.lanl.gov [128.165.147.34]) by acl.lanl.gov (8.8.8/8.8.5) with ESMTP id NAA480510; Mon, 6 Dec 1999 13:25:46 -0700 (MST) Received: from localhost (rminnich@localhost) by mini.acl.lanl.gov (8.9.3/8.8.8) with ESMTP id NAA20227; Mon, 6 Dec 1999 13:25:46 -0700 X-Authentication-Warning: mini.acl.lanl.gov: rminnich owned process doing -bs Date: Mon, 6 Dec 1999 13:25:46 -0700 (MST) From: "Ronald G. Minnich" X-Sender: rminnich@mini.acl.lanl.gov To: freebsd-fs@FreeBSD.ORG Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ELF & putting inode at the front of a file In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 6 Dec 1999, Zhihui Zhang wrote: > I have modified FFS filesystem code to put the disk inode at the beginning > of a file, i.e, the logical block #0 of each file begins with 128 bytes of > its disk inode and the rest of it are file data. first question I have is, why? ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 12:38:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id CF80C15BB9 for ; Mon, 6 Dec 1999 12:37:50 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id MAA00949; Mon, 6 Dec 1999 12:37:58 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Matthew Dillon Cc: Dennis , hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-reply-to: Your message of "Mon, 06 Dec 1999 12:19:20 PST." <199912062019.MAA72301@apollo.backplane.com> Date: Mon, 06 Dec 1999 12:37:58 -0800 Message-ID: <945.944512678@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think the solution here is to change the release mechanism slightly. > I believe we made a huge mistake splitting of the 4.x tree from 3.x > so early. I was going to make a point about this, but thank you for making it for me. :-) My point was going to be that it was clearly not possible to please even a large fraction of the FreeBSD user base with respect to scheduling and Matt's statement above only underscores that in flashing neon. Those who were actually around at the time will remember that the -current branch had already gone "dot zero" with 3.0 and still we refused to branch 3.x-stable, despite great public pressure to do so. More months went by and finally the -current branch was running on 18 months with no branch, many feeling compelled to comment that we were supposed to "roll over" every 12 months and that this extra 6 month delay was unconscionable. Many arguments about how we were holding up progress and that volunteers were going to start wandering off to other *BSD projects were raised, along with more dire predictions, and finally enough was enough and we set a date by which all the late committers should get their stuff in so that we could finally branch the sucker. We did so and there was much rejoicing, at least up until now when various folks felt compelled to creatively reinterpret history and turn an "unconscionable delay" into a "precipitous rush to branch." I tell you, it's just not possible to win, especially when those doing the most yelling are always conspicuously absent when crunch time comes. Matt wasn't really fully on board at the time and I'm not pointing my finger at him specifically, but it seems like everyone's hindsight is 20-20 whereas their immediate vision concerning what needs to be fixed in a timely fashion often comes closer to the legal definition of blindness. If you want to make this or any other branch a decent release target, the time to start is not 10 days before it enters a feature freeze, the time to start is right after it branches! It's my hope that people will take this lesson more to heart when 4.0's own time to branch comes up. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 12:41: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id ED088152B9; Mon, 6 Dec 1999 12:41:00 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA72445; Mon, 6 Dec 1999 12:40:59 -0800 (PST) (envelope-from dillon) Date: Mon, 6 Dec 1999 12:40:59 -0800 (PST) From: Matthew Dillon Message-Id: <199912062040.MAA72445@apollo.backplane.com> To: Ed Hall Cc: "Jonathan M. Bresler" , kris@hub.freebsd.org, freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) References: <199912062022.MAA30052@screech.weirdnoise.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I've confirmed that neither problem exists in 4.0. There are ample :work-arounds, both hardware and software, including just not using 3.3. :No fixes, though, just work-arounds... Workarounds for the NCR/FXP :issue included: : :1) Using 2.2.8 (4.0 isn't a production option). :2) Using a different NIC (a Tulip worked fine). :3) Using a different SCSI adapter (Adaptec, as Matt suggested, works fine). :4) Using a different SCSI driver (Peter managed to get a driver from 4.0 : hooked up under 3.3, and it survived two days of torture that would : have toasted things within an hour using the stock driver; you'll have : to ask him for details). Ed, this is great stuff! Are you sure about #4? Is that the same ncr.c driver or something else? There are only a few differences between the 3.x and 4.x /usr/src/sys/pci/ncr.c drivers. Which Peter, Peter Wemm? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 12:42:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 5DDAB15EFD; Mon, 6 Dec 1999 12:41:35 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id MAA00980; Mon, 6 Dec 1999 12:41:39 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Ed Hall Cc: Matthew Dillon , "Jonathan M. Bresler" , kris@hub.freebsd.org, freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-reply-to: Your message of "Mon, 06 Dec 1999 12:22:17 PST." <199912062022.MAA30052@screech.weirdnoise.com> Date: Mon, 06 Dec 1999 12:41:39 -0800 Message-ID: <976.944512899@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I've been with BSD a long time--from back when my email address was > decvax!randvax!edhall. I want it to succeed, for reasons that are more > emotional than rational; my nightmare was having to say that my project > (1) worked on Solaris, (2) worked on Linux, but (3) broke FreeBSD. And I hope that you'll not hesitate to chime in the next time you run into a problem and not just wait for it to become the flame topic of the week. :-) If you have a hard time getting responses out of our developers, I'm also happy to offer my own phone numbers (both of which are in my finger entry at freebsd.org) and email address as a point of contact if something seems to be stuck and you need it fast-tracked. This is no more or less than I'd offer to anyone else in your position and I hope you realize that some people around here are more than willing to go the extra mile, with or without what others might consider a "proper bug report." - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 12:44: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from Genesis.Denninger.Net (209-176-244-82.inil.com [209.176.244.82]) by hub.freebsd.org (Postfix) with ESMTP id 1707F14D9B for ; Mon, 6 Dec 1999 12:43:51 -0800 (PST) (envelope-from karl@Genesis.Denninger.Net) Received: (from karl@localhost) by Genesis.Denninger.Net (8.9.3/8.8.2) id OAA25544; Mon, 6 Dec 1999 14:43:31 -0600 (CST) Message-ID: <19991206144330.B25513@Denninger.Net> Date: Mon, 6 Dec 1999 14:43:31 -0600 From: Karl Denninger To: Matthew Dillon , Dennis Cc: hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) References: <19991205120428.E6F4514C3E@hub.freebsd.org> <199912061939.OAA22030@etinc.com> <199912062019.MAA72301@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199912062019.MAA72301@apollo.backplane.com>; from Matthew Dillon on Mon, Dec 06, 1999 at 12:19:20PM -0800 Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Dec 06, 1999 at 12:19:20PM -0800, Matthew Dillon wrote: > :>:the problem, we can not address it. please provide this information > :>:if it is available to you. if it is not, please provide us contact > :>:information for the commercial entities experiencing the problem. > :>: > :>:jmb > :> > :> First, the statement was anecdotal -- all of the problems have been > :> fixed in -current. > : > :THIS is EXACTLY what I was saying. What good does it do anyone in a > :commercial environment that its fixed in -current? Thats the reason we > :dumped NetBSD, because everyone was using -current the the releases were > :always unstable. > : > :Of course moving to -current to fix the problems in 3.x introduce a whole > :new set of problems, in which case you have an OS that is never going to be > :stable. When 4.0 is released we'll be told that the problems of 4.0 are > :fixed in -current. When does it end? > : > :DB > > I think the solution here is to change the release mechanism slightly. > I believe we made a huge mistake splitting of the 4.x tree from 3.x > so early. > > This time around I think that we should *not* split the tree for > four months or so. That is, have a period of 4 months where there is > only 4.x, no 5.x. Well, I used to run -CURRENT in a commercial environment :-) And I got bashed here and elsewhere for doing it too. But, with the exception of some really egregious fuck-ups (on both my part and those of people who committed shit that didn't work AT ALL) it was, by far, the better option of those available. For quite some time there were special "hacks" that I had (primarily consisting of grabbing older versions of this module or that) to get around stupidities that were in the process of being resolved, and there were always things that I disabled or just didn't do because I knew they were broken. But, by and large, this was a very solid and appropriate path FOR ME. It *DOES* require TWO machines for testing purposes - one of which has the code base on it, and a second that can be "sacrificed" and reloaded if you really get your shorts in a knot. You also need to keep a known-good release around "just in case" you need to roll back after you commit a roll-forward. But, for me at least, I was happy with this path, despite the few instances over the years where I got bit in the ass by it. I truly believe I would have had MORE chunks out of my ass trying to run STABLE in the same world. And, today, I STILL live by that credo. My primary home machine, which is a production system in every sense of the word, runs CURRENT, although at this point the kernel is a few months old (I've had no reason to upgrade it recently, although I do peruse the "sys" commitlogs at least weekly). :-) -- -- Karl Denninger (karl@denninger.net) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 12:47:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 36EC215484; Mon, 6 Dec 1999 12:45:28 -0800 (PST) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (cs1-gw.cs.binghamton.edu [128.226.171.72]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with SMTP id PAA04476; Mon, 6 Dec 1999 15:44:24 -0500 (EST) Date: Mon, 6 Dec 1999 14:31:22 -0500 (EST) From: Zhihui Zhang To: "Ronald G. Minnich" Cc: freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: ELF & putting inode at the front of a file In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 6 Dec 1999, Ronald G. Minnich wrote: > On Mon, 6 Dec 1999, Zhihui Zhang wrote: > > I have modified FFS filesystem code to put the disk inode at the beginning > > of a file, i.e, the logical block #0 of each file begins with 128 bytes of > > its disk inode and the rest of it are file data. > > first question I have is, why? I am doing some research on filesystem. I guess it may be faster to put the disk inode with its file data together so that both can be read into memory in one I/O. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 12:54:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id CF905158EB for ; Mon, 6 Dec 1999 12:51:30 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA72513; Mon, 6 Dec 1999 12:51:25 -0800 (PST) (envelope-from dillon) Date: Mon, 6 Dec 1999 12:51:25 -0800 (PST) From: Matthew Dillon Message-Id: <199912062051.MAA72513@apollo.backplane.com> To: David Wolfskill Cc: jeremyp@gsmx07.alcatel.com.au, hackers@FreeBSD.ORG, rfg@monkeys.com Subject: Re: tmpfs .. ? References: <199912062023.MAA44565@pau-amma.whistle.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :>Date: Mon, 6 Dec 1999 10:13:50 -0800 (PST) :>From: Matthew Dillon : :> The actual problem is sendmail's constant *rescanning* of the directory. : :To the extent that the directory is populated, yes. (Scanning an empty :directory isn't an overwhelmingly resource-intensive operation.) :... : (lots of good stuff removed) :... :-- :David Wolfskill dhw@whistle.com UNIX System Administrator It's an O(N^2) failure mode. If your sendmail gets overloaded then queue files build up which in turn make sendmail less efficient. The result is a cascade failure - where the mail queue directory gets so large that it cannot recover even when the load drops back down to normal. We had dozens and dozens of such failures at BEST before I went to the multi-queue method. This obviously only applies to servers that have a lot of mail volume. When you are getting four or five emails a second at peak and something out of your control goes down, the queue can build up very rapidly. I will also note that the problem is exasperated by FreeBSD's current use of malloc buffers instead of the VM cache to cache directories. Once any given directory gets too large, the machine suddenly starts going to disk every time you scan it! In 4.x you can turn on VMIO backing for directories (sysctl -w vfs.vmiodirenable=1). It isn't on by default only due to a bug somewhere in softupdates that causes an occassional panic, apart from that all the necessary work has been done (by yours truely, of course :-)). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 12:58:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4523C15904; Mon, 6 Dec 1999 12:56:20 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA72561; Mon, 6 Dec 1999 12:56:14 -0800 (PST) (envelope-from dillon) Date: Mon, 6 Dec 1999 12:56:14 -0800 (PST) From: Matthew Dillon Message-Id: <199912062056.MAA72561@apollo.backplane.com> To: "Ronald G. Minnich" Cc: freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: ELF & putting inode at the front of a file References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Mon, 6 Dec 1999, Zhihui Zhang wrote: :> I have modified FFS filesystem code to put the disk inode at the beginning :> of a file, i.e, the logical block #0 of each file begins with 128 bytes of :> its disk inode and the rest of it are file data. : :first question I have is, why? : :ron Good god, is he joking? Offsetting the entire file by 128 bytes will break mmap() and make I/O extremely inefficient. Many filesystems over the years have mixed meta-data in the file data blocks on disk only to remove it later on when it was found to destroy performance. A good example of this is the Amiga's filesystem. The Amiga's old filesystem was emminently recoverable because each data block had a backpointer, but it was so inefficient due to all the copying required that the updated filesystem removed the metadata so disk blocks could be DMA'd directory into the buffer. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 12:58:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 430E515ABA; Mon, 6 Dec 1999 12:56:16 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id NAA38267; Mon, 6 Dec 1999 13:56:15 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id NAA36534; Mon, 6 Dec 1999 13:56:15 -0700 (MST) Message-Id: <199912062056.NAA36534@harmony.village.org> To: Mike Smith Subject: Re: tty level buffer overflows Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 06 Dec 1999 11:53:43 PST." <199912061953.LAA00484@mass.cdrom.com> References: <199912061953.LAA00484@mass.cdrom.com> Date: Mon, 06 Dec 1999 13:56:15 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199912061953.LAA00484@mass.cdrom.com> Mike Smith writes: : Growing the buffer isn't the solution; it should be big enough already. : We need to work out why a system that should have no trouble with the : data rate in question is croaking so trivially. Growing the buffer is a solution. I only get a few of these very rarely which tells me that the system is keeping up 99.999% of the time. Increasing the buffer size will, statistically speaking, increase that by another .0009%, which is all I'm looking for. Growing the buffer will allow the amont of latency in the worst case to expand, which is what I want. Also, it will work around the problem until I can get a better solution.... At least for my setup. I have a 486DX2-66 with lots of filter rules. I suspect that what is happening is lots of tiny packets are coming in which is causing increased latency in some cases. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 12:58:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from front1m.grolier.fr (front1m.grolier.fr [195.36.216.51]) by hub.freebsd.org (Postfix) with ESMTP id 4A06F14D5A; Mon, 6 Dec 1999 12:58:37 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-164-204.villette.club-internet.fr [195.36.164.204]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id VAA02684; Mon, 6 Dec 1999 21:57:08 +0100 (MET) Date: Mon, 6 Dec 1999 23:21:15 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Mike Smith Cc: Ed Hall , freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-Reply-To: <199912060110.RAA09520@mass.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have some remarks about the issue. I donnot claim it is not a software=20 problem, but ... 1) Given the actual differences between the ncr and sym drivers nowadays,= =20 I would be surprised if the problem was due to a driver software bug. A difference could be that recent drivers may use PCI optimized transactions (Memory Write and Invalidate, Memory Read Multiple). 2) In order to investigate some hardware problem, we need to know about the actual revision of PCI chips used on the system and to have access to correspondings errata listings. I can look into the ones I have (basically SYMBIOS chips), and into the specifications update of the 440BX that are available from Intel site, but I donnot have anything about the network board (neither I know of this board). 3) I donnot see the reasons that led to think the kernel stack having=20 been clobbered by some part involving the ncr/symbios chips, but may-be=20 a clear diagnosis exists. 4) Have all the pathes (PCI, memory,...) parity enabled and do corresponding parts parity checking ?=20 5) Did you give a try using normal IO instead of MMIO for the SYMBIOS chip= =20 and the Network chip, if code allows ? MMIO may confuse drivers that are not aware of posted buffers. For example a PCI device driver that writes using MMIO to some IO register to ack something and then assumes the chip knows about is just wrong since the transaction can be posted (a read, dummy if needed, must be performed prior such an assumption). This also acts as barriers for drivers that are not clean about actual instruction and memory ordering. Just my 0.02 euros. G=E9rard. =20 On Sun, 5 Dec 1999, Mike Smith wrote: > > On a recent project I encountered two show-stopping bugs with 3.3-relea= se > > that did not exist in 2.2.8-release: > >=20 > > 1) Random crashes in FXP interrupt or low-level IP code. Something is > > clobbering the kernel stack--possibly the NCR driver, since using an > > Adaptec made the problem stop, as did a backport of the CAM driver > > Peter Wemm tried. This was on an N440BX, which is becoming quite > > common in server applications. Other installations are apparantly > > seeing the same problem on this hardware. >=20 > So far the problem appears to require a combination of the 440BX chipset,= =20 > an Intel EtherExpress and the 'fxp' driver, and an NCR/Symbios/LSI SCSI= =20 > adapter and either the 'ncr' or 'sym' driver. We've tried on a number of= =20 > occasions to diagnose this problem, but there have been many issues that= =20 > have prevented it's resolution. These have included lack of interest on= =20 > the driver developers' parts, lack of access to or cooperation from=20 > people complaining of the bug, and an inability to reproduce it in a=20 > useful fashion. It's been an eye-opening exercise and we're trying to=20 > learn what we can from it, as well as actually fix it for good. >=20 > > 2) A hard loop in the pagedaemon. This was especially egregious, since > > it meant the system had to be rebooted from the console--and since > > the application could elicit the problem within a few minutes. > > Disabling the use of mmap() for file update in the application > > prevented the problem. After spending a day trying to cook up a > > test program that elicited the same behavior that the application > > did, I gave up for lack of time. But there have been other reports > > of late that sound like this problem, mostly in high VM/RAM situatio= ns. > >=20 > > That's two serious bugs that exist in 3.3-release but not in 2.2.8-rele= ase. > > Looking back through the archives, I can see that I'm not the only one = who > > has experienced them. I came away from the experience with the feeling= that > > the FreeBSD project has some serious Q/A problems... and I can assure y= ou, > > I'm not alone in this feeling. >=20 > Neither are we. But, since FreeBSD is a volunteer-developed project, and= =20 > since you admit above that you have contributed to the lack of QA, I'm=20 > not entirely sure what your point is. We need this feedback in a timely= =20 > fashion in order to do something with it. 3 months after a release is=20 > not "timely" by any stretch of the imagination, and without that sort of= =20 > assistance, I have no idea what you think we can do to improve the=20 > situation. >=20 > Yes, we want to improve our QA. But when customers come up months after= =20 > the fact and complain about something that we could never possibly have= =20 > either known or even guessed about during the development process, the=20 > best we can do is try to fix the problem then and there. If you want to= =20 > improve that situation, you can; in your position you have plenty of=20 > opportunities to make a major contribution to the overall quality of=20 > FreeBSD releases. OTOH, if you choose not to do so, it's mere honesty to= =20 > observe that you need to take a share of the blame for the current=20 > situation. >=20 > ps: The N440BX is actually being phased out, however there are very large= =20 > numbers of them still in production, yes. > --=20 > \\ Give a man a fish, and you feed him for a day. \\ Mike Smith > \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org > \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 13:13:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 903C21545D for ; Mon, 6 Dec 1999 13:13:08 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA72714; Mon, 6 Dec 1999 13:13:06 -0800 (PST) (envelope-from dillon) Date: Mon, 6 Dec 1999 13:13:06 -0800 (PST) From: Matthew Dillon Message-Id: <199912062113.NAA72714@apollo.backplane.com> To: "Jordan K. Hubbard" Cc: Dennis , hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) References: <945.944512678@zippy.cdrom.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I tell you, it's just not possible to win, especially when those doing :the most yelling are always conspicuously absent when crunch time :comes. Matt wasn't really fully on board at the time and I'm not :pointing my finger at him specifically, but it seems like everyone's :hindsight is 20-20 whereas their immediate vision concerning what :needs to be fixed in a timely fashion often comes closer to the legal :definition of blindness. If you want to make this or any other branch :a decent release target, the time to start is not 10 days before it :enters a feature freeze, the time to start is right after it branches! :It's my hope that people will take this lesson more to heart when 4.0's :own time to branch comes up. : :- Jordan Perhaps I should rephrase: The system was branched without any significant stabilizing period afterwords. It was a holy mess. What I am suggesting is that we have an enforced stabilizing period after the 4.0 release BEFORE we branch 5.0 that is long enough to actually get feedback and stabilize the system using that feedback. In otherwords, we should branch with the 4.1 release rather then the 4.0 release. 3 or 4 months seems about right to me. There are no projects which are going to get so far along that we can't wait 4 months to commit the patchsets (here I am talking about SMP and VFS). It gives everyone (including me) a chance to relax a bit and work on stabilizing what we have for the 4.1 release rather then going off and messing around with personal projects. While it is true that self-discipline can accomplish the same thing, I think having an official enforcing framework will yield much better results in an open-source project. I would also like to point out that doing this reduces the MFCing load as well, When 3.0 was released and we branched 4.x, many of us (including me) had to deal with issues relating to all *THREE* branches for a long time. While this doesn't entirely go away, waiting a few months to branch after a .0 release will allow people to continue to concentrate on the two existing branches for a little while and get them shipshape prior to starting work on a new branch. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 13:15:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 56E0F155C2 for ; Mon, 6 Dec 1999 13:15:53 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id NAA01225; Mon, 6 Dec 1999 13:16:01 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Matthew Dillon Cc: Dennis , hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-reply-to: Your message of "Mon, 06 Dec 1999 13:13:06 PST." <199912062113.NAA72714@apollo.backplane.com> Date: Mon, 06 Dec 1999 13:16:00 -0800 Message-ID: <1221.944514960@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In otherwords, we should branch with the 4.1 release rather then the > 4.0 release. Sounds a lot like 3.x to me. We didn't branch at 3.0 either, we branched one release afterwards and only after people threatened to mutiny if we didn't since the usual pattern up to that point had been to branch immmediate at the dot-zero. It didn't seem to help, as your own complaints would indicate. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 13:24:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 5BDAE14A1A for ; Mon, 6 Dec 1999 13:24:44 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA72775; Mon, 6 Dec 1999 13:24:36 -0800 (PST) (envelope-from dillon) Date: Mon, 6 Dec 1999 13:24:36 -0800 (PST) From: Matthew Dillon Message-Id: <199912062124.NAA72775@apollo.backplane.com> To: Karl Denninger Cc: Dennis , hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) References: <19991205120428.E6F4514C3E@hub.freebsd.org> <199912061939.OAA22030@etinc.com> <199912062019.MAA72301@apollo.backplane.com> <19991206144330.B25513@Denninger.Net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Well, I used to run -CURRENT in a commercial environment :-) : :And I got bashed here and elsewhere for doing it too. : :But, with the exception of some really egregious fuck-ups (on both my part :and those of people who committed shit that didn't work AT ALL) it was, by :far, the better option of those available. : :For quite some time there were special "hacks" that I had (primarily :consisting of grabbing older versions of this module or that) to get :around stupidities that were in the process of being resolved, and there :were always things that I disabled or just didn't do because I knew they :were broken. This was an unfortunate consequence which I take partial blame for in my little corner of the system -- but only partial blame. It was hard enough getting my stuff into -current with all the extra requirements core forced onto me, I didn't want to have to go through the same hell to get it MFC'd into -stable as well. At one point at the beginning, before the shit began to fly, I was actually considering only doing it for -current but as more and more bugs were found it became clear that if the stuff didn't get MFC'd into -stable soon it wouldn't at all. By that time the shit was already flying and I just didn't want to double it. Maybe 80% of the bug fixes have been MFC'd -- the ones that were easy to fix. The other 20% can't be MFC'd without the rest of the infrastructure in 4.x to support them. I hope the same thing will not repeat for 4.x/5.x, even without an enforced stabilizing period between 4.0 and 4.1 prior to branching off. However, I think that an enforced stabilizing period where *everyone* is concentrating on 4.1 for a couple of months would be extremely good for the project. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 13:25:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from screech.weirdnoise.com (209-128-78-198.bayarea.net [209.128.78.198]) by hub.freebsd.org (Postfix) with ESMTP id 3488414D74; Mon, 6 Dec 1999 13:25:20 -0800 (PST) (envelope-from edhall@screech.weirdnoise.com) Received: from screech.weirdnoise.com (localhost [127.0.0.1]) by screech.weirdnoise.com (8.8.7/8.8.7) with ESMTP id NAA30946; Mon, 6 Dec 1999 13:26:38 -0800 Message-Id: <199912062126.NAA30946@screech.weirdnoise.com> X-Mailer: exmh version 2.0.2 To: Matthew Dillon Cc: "Jonathan M. Bresler" , kris@hub.freebsd.org, freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-Reply-To: Your message of "Mon, 06 Dec 1999 12:40:59 PST." <199912062040.MAA72445@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Dec 1999 13:26:38 -0800 From: Ed Hall Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : you wrote: : : I wrote: : :4) Using a different SCSI driver (Peter managed to get a driver from 4.0 : : hooked up under 3.3, and it survived two days of torture that would : : have toasted things within an hour using the stock driver; you'll have : : to ask him for details). : : Ed, this is great stuff! : : Are you sure about #4? Is that the same ncr.c driver or something : else? There are only a few differences between the 3.x and 4.x : /usr/src/sys/pci/ncr.c drivers. Which Peter, Peter Wemm? It was Peter Wemm. I may be misunderstanding just what he did--trying the 4.0 driver was just one several experiments he proposed and performed. And saying that it "worked" is provisional; two days of testing strongly suggests that it reduced the problem with 3.3 to acceptible levels for my application. Is it truly a "fix?" I don't know. -Ed To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 13:27:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by hub.freebsd.org (Postfix) with ESMTP id 0C4D914D0F for ; Mon, 6 Dec 1999 13:27:41 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id NAA01671; Mon, 6 Dec 1999 13:28:40 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912062128.NAA01671@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Gerard Roudier Cc: Ed Hall , freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-reply-to: Your message of "Mon, 06 Dec 1999 23:21:15 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Date: Mon, 06 Dec 1999 13:28:40 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I have some remarks about the issue. I donnot claim it is not a softwar= e = > problem, but ... > = > 1) Given the actual differences between the ncr and sym drivers nowaday= s, = > I would be surprised if the problem was due to a driver software bug. > A difference could be that recent drivers may use PCI optimized > transactions (Memory Write and Invalidate, Memory Read Multiple). The problem has been seen manifesting under both the 'ncr' and 'sym' = drivers. The nature of the situation suggests that it may be a symptom = of the techniques used to talk to the LSI parts in conjunction with some = other bus circumstances, > 2) In order to investigate some hardware problem, we need to know about= > the actual revision of PCI chips used on the system and to have access = to > correspondings errata listings. I can look into the ones I have (basica= lly > SYMBIOS chips), and into the specifications update of the 440BX that ar= e > available from Intel site, but I donnot have anything about the network= > board (neither I know of this board). The symptoms seem to manifest across a range of part revisions; the Intel= = ethernet part involved is the 82558, for which not all data is available.= > 3) I donnot see the reasons that led to think the kernel stack having = > been clobbered by some part involving the ncr/symbios chips, but may-be= = > a clear diagnosis exists. This assumption stems from a diagnosis I performed some time back, and = may have been independantly corroborated. Analysis of a trap taken in = the EtherExpress driver showed register contents which were inconsistent = with the preceeding instruction stream, but consistent with the trap = itself. Given the highly repeatable nature of the trap, the only = conclusions that I could come to were: - Something about the instruction sequence was triggering a failure in = the CPU causing corruption of the register file. - An interrupt was being taken at a particular point as a direct = consequence of some interaction between the ethernet and SCSI = hardware, and the interrupt handler was damaging the stack such that on return the register contents were restored as garbage. In my original case, there were essentially only two common points of = failure, both inside the 'fxp' driver, and both showing the same signs of= = register corruption. > 4) Have all the pathes (PCI, memory,...) parity enabled and do > corresponding parts parity checking ? = We were using ECC memory and CPU cache in the case I was working with. I= = don't _think_ that PCI parity would have helped here (the problem seemed = too consistent to be a noise-related failure of that kind). > 5) Did you give a try using normal IO instead of MMIO for the SYMBIOS c= hip = > and the Network chip, if code allows ? > MMIO may confuse drivers that are not aware of posted buffers. For exam= ple > a PCI device driver that writes using MMIO to some IO register to ack > something and then assumes the chip knows about is just wrong since the= > transaction can be posted (a read, dummy if needed, must be performed > prior such an assumption). This also acts as barriers for drivers that = are > not clean about actual instruction and memory ordering. I'm not sure how this sort of error would lead to stack corruption unless= = it resulted in a deferred PCI dma to a stack variable. At any rate, if you're interested in looking at a kernel core from such a= = failure, I'm sure we can make one available to you. -- = \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 13:33:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 93A641532A; Mon, 6 Dec 1999 13:33:35 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA72851; Mon, 6 Dec 1999 13:33:33 -0800 (PST) (envelope-from dillon) Date: Mon, 6 Dec 1999 13:33:33 -0800 (PST) From: Matthew Dillon Message-Id: <199912062133.NAA72851@apollo.backplane.com> To: Zhihui Zhang Cc: "Ronald G. Minnich" , freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: ELF & putting inode at the front of a file References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Mon, 6 Dec 1999, Ronald G. Minnich wrote: : :> On Mon, 6 Dec 1999, Zhihui Zhang wrote: :> > I have modified FFS filesystem code to put the disk inode at the beginning :> > of a file, i.e, the logical block #0 of each file begins with 128 bytes of :> > its disk inode and the rest of it are file data. :> :> first question I have is, why? : :I am doing some research on filesystem. I guess it may be faster to put :the disk inode with its file data together so that both can be read into :memory in one I/O. : :-Zhihui Not really. The inode tends to wind up being cached by the system longer then file data, so placing it with the file data will not help -- since it is already probably cached, the system generally doesn't have to read it off the disk more then once anyway, and in a heavily loaded system the system caching is sufficiently detached from the file data processing that it is actually more beneficial to group inodes together (one disk read is able to cache many inodes all in one go). Another problem is that things like 'ls -la' or 'find' have to stat files and if you put the inode at the beginning of the file you essentially distribute the inodes all over the cylinder group rather then concentrate all the inodes in one place. p.s. I was wrong about it breaking mmap() - in fact offseting the file data on-disk will not break mmap(). But it will produce unaligned disk transfers and potentially extra seeking. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 13:41:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 99C2514D37 for ; Mon, 6 Dec 1999 13:41:20 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id QAA11369 for ; Mon, 6 Dec 1999 16:41:19 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id QAA86355; Mon, 6 Dec 1999 16:40:49 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 6 Dec 1999 16:40:49 -0500 (EST) To: freebsd-hackers@freebsd.org Subject: Is part of user stack always mapped? X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14412.10798.476867.196687@grasshopper.cs.duke.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've been getting the osf1ulator (alpha/osf1 abi ported from NetBSD over a year ago) on its feet again after this fall's signal changes. When looking closely at the emulators which are currently in the tree, I notice that they are they directly dereferencing memory which was allocated on the user's stack via stackgap_alloc() from within the kernel. stackgap_init() { #define szsigcode (*(curproc->p_sysent->sv_szsigcode)) return (caddr_t)(((caddr_t)PS_STRINGS) - szsigcode - SPARE_USRSPACE); } static __inline void * stackgap_alloc(sgp, sz) caddr_t *sgp; size_t sz; { void *p = (void *) *sgp; *sgp += ALIGN(sz); return p; } <...> sigset_t *set; caddr_t sg; sg = stackgap_init(); set = stackgap_alloc(&sg, sizeof(sigset_t)); *set = p->p_sigmask; <..> I was under the impression that this was a no-no & one should use copyin/copout & friends to access memory on users's stacks. Although this appears to work on the i386, if I try this on the alpha I take a fatal trap when accessing *set. So -- how does this work on the i386? Is the user's stack always mappeped into the kernel's address space? Should it also work on the alpha? Apologies for wasting your time if I'm missing something obvious, ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 13:43:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id D2FBA14FA0 for ; Mon, 6 Dec 1999 13:43:35 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA72923; Mon, 6 Dec 1999 13:43:33 -0800 (PST) (envelope-from dillon) Date: Mon, 6 Dec 1999 13:43:33 -0800 (PST) From: Matthew Dillon Message-Id: <199912062143.NAA72923@apollo.backplane.com> To: "Jordan K. Hubbard" Cc: Dennis , hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) References: <1221.944514960@zippy.cdrom.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> In otherwords, we should branch with the 4.1 release rather then the :> 4.0 release. : :Sounds a lot like 3.x to me. We didn't branch at 3.0 either, we :branched one release afterwards and only after people threatened to :mutiny if we didn't since the usual pattern up to that point had been :to branch immmediate at the dot-zero. It didn't seem to help, as your :own complaints would indicate. : :- Jordan Wait until 4.2? I don't know the answer, Jordan, but I am reasonably confident that an official stabiliziation period of a few months will help a lot. The circumstances of the 2.2.x -> 3.0 release (the 18 months you quoted) were special and should never be repeated, but I think it is precisely the fact that 2.2.x went on for so long that wound up causing people to give up and start working on new stuff prior to 3.0. This made 3.0 especially unstable. So going to the 12 month schedule is a wonderful idea, but doesn't quite get there in my book. There is no significant feature freeze prior to a .0 release which almost guarentees an unstable release. That's ok since we tell people that .0 is never stable. But .1 has to be stable and the only time we have to do it is between .0 and .1. If we enforce a stabilizing period between .0 and .1 and branch at .1 rather then at .0, this combined with the 12 month schedule should result in pretty damn good releases. If we just do the 12 month schedule, I don't think it will produce as good a result. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 13:46:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 2CD4014D37 for ; Mon, 6 Dec 1999 13:46:26 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40327>; Tue, 7 Dec 1999 08:38:29 +1100 Content-return: prohibited Date: Tue, 7 Dec 1999 08:46:11 +1100 From: Peter Jeremy Subject: Re: tmpfs .. ? In-reply-to: <199912062023.MAA44565@pau-amma.whistle.com> To: David Wolfskill Cc: hackers@FreeBSD.ORG, dillon@apollo.backplane.com Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Dec7.083829est.40327@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <199912061813.KAA70974@apollo.backplane.com> <199912062023.MAA44565@pau-amma.whistle.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Dec-07 07:23:49 +1100, David Wolfskill wrote: >>Date: Mon, 6 Dec 1999 10:13:50 -0800 (PST) >>From: Matthew Dillon > >> The actual problem is sendmail's constant *rescanning* of the directory. Which I forgot about :-(. >To the extent that the directory is populated, yes. (Scanning an empty >directory isn't an overwhelmingly resource-intensive operation.) Not quite. UFS directories only shrink when a new entry is created and free blocks exist at the end. This means there can be a large number of emply blocks that need to be scanned. (The worst case is when all the files in a large directory are deleted - the directory is empty, but hasn't shrunk). [domain-specific queue directories] >I submit that having sendmail use the separate queue directories in this >fashion is rather more beneficial than post-processing the queue. :-) It would be interesting to see a comparison of the schemes under heavy load + failure conditions. I think Matt's approach has the advantage of needing less tuning. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 14: 1:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id C6CDF14A05; Mon, 6 Dec 1999 14:01:16 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id OAA73739; Mon, 6 Dec 1999 14:01:12 -0800 (PST) Date: Mon, 6 Dec 1999 14:01:11 -0800 (PST) From: Julian Elischer To: Zhihui Zhang Cc: "Ronald G. Minnich" , freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: ELF & putting inode at the front of a file In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG how do you find the inode? On Mon, 6 Dec 1999, Zhihui Zhang wrote: > > On Mon, 6 Dec 1999, Ronald G. Minnich wrote: > > > On Mon, 6 Dec 1999, Zhihui Zhang wrote: > > > I have modified FFS filesystem code to put the disk inode at the beginning > > > of a file, i.e, the logical block #0 of each file begins with 128 bytes of > > > its disk inode and the rest of it are file data. > > > > first question I have is, why? > > I am doing some research on filesystem. I guess it may be faster to put > the disk inode with its file data together so that both can be read into > memory in one I/O. > > -Zhihui > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 14: 6:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 5EB9D14A05; Mon, 6 Dec 1999 14:06:24 -0800 (PST) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (cs1-gw.cs.binghamton.edu [128.226.171.72]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with SMTP id RAA24839; Mon, 6 Dec 1999 17:06:16 -0500 (EST) Date: Mon, 6 Dec 1999 15:53:14 -0500 (EST) From: Zhihui Zhang Reply-To: Zhihui Zhang To: Matthew Dillon Cc: "Ronald G. Minnich" , freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: ELF & putting inode at the front of a file In-Reply-To: <199912062133.NAA72851@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 6 Dec 1999, Matthew Dillon wrote: > :On Mon, 6 Dec 1999, Ronald G. Minnich wrote: > : > :> On Mon, 6 Dec 1999, Zhihui Zhang wrote: > :> > I have modified FFS filesystem code to put the disk inode at the beginning > :> > of a file, i.e, the logical block #0 of each file begins with 128 bytes of > :> > its disk inode and the rest of it are file data. > :> > :> first question I have is, why? > : > :I am doing some research on filesystem. I guess it may be faster to put > :the disk inode with its file data together so that both can be read into > :memory in one I/O. > : > :-Zhihui > > Not really. The inode tends to wind up being cached by the system > longer then file data, so placing it with the file data will not > help -- since it is already probably cached, the system generally doesn't > have to read it off the disk more then once anyway, and in a heavily > loaded system the system caching is sufficiently detached from the file > data processing that it is actually more beneficial to group inodes > together (one disk read is able to cache many inodes all in one go). I have read some papers. People have put disk inode with its file data. For small files, they can be read into memory with one I/O. In a distributed filesystem, if a inode block (contains 8192/128 inodes) is shared by multiple clients, it will hurt performance. One such paper may be "A 64-bit, shared disk file system for Linux" available at http://www.globalfilesystem.org/Pages/gfspapers.html. They call it "stuffed dinode". My understanding could be wrong though. > Another problem is that things like 'ls -la' or 'find' have to stat files > and if you put the inode at the beginning of the file you essentially > distribute the inodes all over the cylinder group rather then concentrate > all the inodes in one place. Yes. I have implemented most of the code. I noticed the "ls -al" is slow but "ls" is OK. > p.s. I was wrong about it breaking mmap() - in fact offseting the file > data on-disk will not break mmap(). But it will produce unaligned disk > transfers and potentially extra seeking. Yes. The cp command may use mmap(). I modify the mmap() so that this works. But this mmap() is done by the user, I can intercept it at the mmap() system call. As I said in my original email, the kernel uses memory map internally to load an ELF object file. I have to let the kernel know that there is a disk inode at the beginning of the ELF object file. It is hard for me to identify what part of the code is affected and to what extent. I think there should be a way. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 14: 8:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 4258514A05; Mon, 6 Dec 1999 14:07:55 -0800 (PST) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (cs1-gw.cs.binghamton.edu [128.226.171.72]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with SMTP id RAA25757; Mon, 6 Dec 1999 17:07:47 -0500 (EST) Date: Mon, 6 Dec 1999 15:54:44 -0500 (EST) From: Zhihui Zhang To: Julian Elischer Cc: "Ronald G. Minnich" , freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: ELF & putting inode at the front of a file In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 6 Dec 1999, Julian Elischer wrote: > how do you find the inode? There is an inode address map to look up. Each entry is four bytes. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 14:13:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 805BC14A05; Mon, 6 Dec 1999 14:13:42 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id OAA74101; Mon, 6 Dec 1999 14:13:39 -0800 (PST) Date: Mon, 6 Dec 1999 14:13:38 -0800 (PST) From: Julian Elischer To: Matthew Dillon Cc: Zhihui Zhang , "Ronald G. Minnich" , freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: ELF & putting inode at the front of a file In-Reply-To: <199912062133.NAA72851@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 6 Dec 1999, Matthew Dillon wrote: > :On Mon, 6 Dec 1999, Ronald G. Minnich wrote: > : > :> On Mon, 6 Dec 1999, Zhihui Zhang wrote: > :> > I have modified FFS filesystem code to put the disk inode at the beginning > :> > of a file, i.e, the logical block #0 of each file begins with 128 bytes of > :> > its disk inode and the rest of it are file data. > :> > :> first question I have is, why? > : > :I am doing some research on filesystem. I guess it may be faster to put > :the disk inode with its file data together so that both can be read into > :memory in one I/O. > : > :-Zhihui > > Not really. The inode tends to wind up being cached by the system > longer then file data, so placing it with the file data will not > help -- since it is already probably cached, the system generally doesn't > have to read it off the disk more then once anyway, and in a heavily > loaded system the system caching is sufficiently detached from the file > data processing that it is actually more beneficial to group inodes > together (one disk read is able to cache many inodes all in one go). > > Another problem is that things like 'ls -la' or 'find' have to stat files > and if you put the inode at the beginning of the file you essentially > distribute the inodes all over the cylinder group rather then concentrate > all the inodes in one place. > > p.s. I was wrong about it breaking mmap() - in fact offseting the file > data on-disk will not break mmap(). But it will produce unaligned disk > transfers and potentially extra seeking. At Usenix 98 there was a paper on puting the inode in ht edirectory entry for files with only one link. that DID speed a lot of things up.. Puting the inode in "frag -1" is interesting, but the question remains of how do you find the inode? I presume the directory entry needs to have the actual disk block in it.. > > -Matt > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 14:16:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id 28DE314C3F for ; Mon, 6 Dec 1999 14:16:32 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id RAA09858; Mon, 6 Dec 1999 17:16:31 -0500 (EST) (envelope-from luoqi) Date: Mon, 6 Dec 1999 17:16:31 -0500 (EST) From: Luoqi Chen Message-Id: <199912062216.RAA09858@lor.watermarkgroup.com> To: freebsd-hackers@FreeBSD.ORG, gallatin@cs.duke.edu Subject: Re: Is part of user stack always mapped? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I was under the impression that this was a no-no & one should use > copyin/copout & friends to access memory on users's stacks. Although > this appears to work on the i386, if I try this on the alpha I take a > fatal trap when accessing *set. > > So -- how does this work on the i386? Is the user's stack always > mappeped into the kernel's address space? Should it also work on the > alpha? > On i386, under the current implementation, the kernel can directly access curproc's address space (not just the stack, stack is used because we're sure the spare space won't/shouldn't be used by the user application). I don't know if the same is true for alpha, but this should definitely be considered an implementation dependent feature. I wish there were some other ways to bypass copyin/out in ioctls. -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 14:20:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by hub.freebsd.org (Postfix) with ESMTP id 7BD0A14C3F; Mon, 6 Dec 1999 14:20:14 -0800 (PST) (envelope-from rminnich@lanl.gov) Received: from mini.acl.lanl.gov (root@mini.acl.lanl.gov [128.165.147.34]) by acl.lanl.gov (8.8.8/8.8.5) with ESMTP id PAA500918; Mon, 6 Dec 1999 15:20:13 -0700 (MST) Received: from localhost (rminnich@localhost) by mini.acl.lanl.gov (8.9.3/8.8.8) with ESMTP id PAA20531; Mon, 6 Dec 1999 15:20:13 -0700 X-Authentication-Warning: mini.acl.lanl.gov: rminnich owned process doing -bs Date: Mon, 6 Dec 1999 15:20:13 -0700 (MST) From: "Ronald G. Minnich" X-Sender: rminnich@mini.acl.lanl.gov To: Zhihui Zhang Cc: freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: ELF & putting inode at the front of a file In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 6 Dec 1999, Zhihui Zhang wrote: > I am doing some research on filesystem. I guess it may be faster to put > the disk inode with its file data together so that both can be read into > memory in one I/O. I still don't get it. To get the file, you do a lookup. So the inode is in memory. The you call the handler for the executable. But the inode is in memory at this point .... what am I missing? ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 14:23:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 9E28D14F88; Mon, 6 Dec 1999 14:23:34 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id XAA24765; Mon, 6 Dec 1999 23:23:15 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Ronald G. Minnich" Cc: Zhihui Zhang , freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: ELF & putting inode at the front of a file In-reply-to: Your message of "Mon, 06 Dec 1999 15:20:13 MST." Date: Mon, 06 Dec 1999 23:23:15 +0100 Message-ID: <24763.944518995@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , "Ronal d G. Minnich" writes: >On Mon, 6 Dec 1999, Zhihui Zhang wrote: >> I am doing some research on filesystem. I guess it may be faster to put >> the disk inode with its file data together so that both can be read into >> memory in one I/O. > >I still don't get it. To get the file, you do a lookup. So the inode is in >memory. The you call the handler for the executable. But the inode is in >memory at this point .... what am I missing? The inode is not likely to be in memory for a news spool or similar. Only very recently used inodes are in memory actually. They die with the vnode which maybe still die to fast. Putting the inode with the data saves a little less than one diskaccess on average per file, which for truly random access filesystems is a good thing. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 14:25:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 45A0814F88 for ; Mon, 6 Dec 1999 14:25:24 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id OAA06597 for ; Mon, 6 Dec 1999 14:25:23 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id OAA01257; Mon, 6 Dec 1999 14:25:23 -0800 Received: from softweyr.com (dyn0.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA17148; Mon, 6 Dec 99 14:25:21 PST Message-Id: <384C37ED.5CCA93F0@softweyr.com> Date: Mon, 06 Dec 1999 15:25:50 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: hackers@freebsd.org Subject: HomePNA network cards Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Has anyone gotten one of these to work with the lnc driver in current? Looking at the chip specs, it is supposed to be software compatible with the PCNet PCI parts, but it sports the "home networking" PHY that are not supported on other LANCE parts. If you've had success with these, please let me know. A friend wants to setup a network but doesn't have access to the wall spaces in his house. Silly boy. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 14:30: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 4B8B314FEB; Mon, 6 Dec 1999 14:29:54 -0800 (PST) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (cs1-gw.cs.binghamton.edu [128.226.171.72]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with SMTP id RAA06876; Mon, 6 Dec 1999 17:29:32 -0500 (EST) Date: Mon, 6 Dec 1999 16:16:32 -0500 (EST) From: Zhihui Zhang To: "Ronald G. Minnich" Cc: freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: ELF & putting inode at the front of a file In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 6 Dec 1999, Ronald G. Minnich wrote: > On Mon, 6 Dec 1999, Zhihui Zhang wrote: > > I am doing some research on filesystem. I guess it may be faster to put > > the disk inode with its file data together so that both can be read into > > memory in one I/O. > > I still don't get it. To get the file, you do a lookup. So the inode is in > memory. The you call the handler for the executable. But the inode is in > memory at this point .... what am I missing? > When you read the disk inode, the first part of the data of its corresponding file is brought into the memory at the same time. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 14:41:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id B57DB14C30 for ; Mon, 6 Dec 1999 14:41:36 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id OAA75266; Mon, 6 Dec 1999 14:41:09 -0800 (PST) Date: Mon, 6 Dec 1999 14:41:08 -0800 (PST) From: Julian Elischer To: Wes Peters Cc: hackers@FreeBSD.ORG Subject: Re: HomePNA network cards In-Reply-To: <384C37ED.5CCA93F0@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have one here.. (and all the specs) the code changes needed to thte lnc driver are: 1/ new PCI ID :-) 2/ BSD equivalent of the following linux code: case 0x2626: chipname = "PCnet/Home 79C978"; fdx = 1; /* * This is based on specs published at www.amd.com. This section * assumes that a card with a 79C978 wants to go into 1Mb HomePNA * mode. The 79C978 can also go into standard ethernet, and there * probably should be some sort of module option to select the * mode by which the card should operate */ /* switch to home wiring mode */ media = a->read_bcr (ioaddr, 49); if (pcnet32_debug > 2) printk("pcnet32: pcnet32 media value %#x.\n", media); media &= ~3; media |= 1; if (pcnet32_debug > 2) printk("pcnet32: pcnet32 media reset to %#x.\n", media); a->write_bcr (ioaddr, 49, media); break; I have alrady added the HomePNA media type to the if_media.h list so all I need is to add this code.. (unless you beat me to it :-) Julian On Mon, 6 Dec 1999, Wes Peters wrote: > Has anyone gotten one of these to work with the lnc driver in current? > Looking at the chip specs, it is supposed to be software compatible with > the PCNet PCI parts, but it sports the "home networking" PHY that are > not supported on other LANCE parts. > > If you've had success with these, please let me know. A friend wants to > setup a network but doesn't have access to the wall spaces in his house. > Silly boy. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 14:42: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pinhead.parag.codegen.com (207-44-235-154.CodeGen.COM [207.44.235.154]) by hub.freebsd.org (Postfix) with ESMTP id 740E314C30; Mon, 6 Dec 1999 14:41:58 -0800 (PST) (envelope-from parag@pinhead.parag.codegen.com) Received: from pinhead.parag.codegen.com (parag@localhost.parag.codegen.com [127.0.0.1]) by pinhead.parag.codegen.com (8.9.3/8.9.3) with ESMTP id OAA06272; Mon, 6 Dec 1999 14:41:57 -0800 (PST) (envelope-from parag@pinhead.parag.codegen.com) To: Mike Smith Cc: Gerard Roudier , Ed Hall , freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-Reply-To: Message from Mike Smith of "Mon, 06 Dec 1999 13:28:40 PST." <199912062128.NAA01671@mass.cdrom.com> X-Image-URL: http://www.codegen.com/images/CG-logo-only.gif X-URL: http://www.codegen.com X-Face: =O'Kj74icvU|oS*<7gS/8'\Pbpm}okVj*@UC!IgkmZQAO!W[|iBiMs*|)n*`X ]pW%m>Oz_mK^Gdazsr.Z0/JsFS1uF8gBVIoChGwOy{EK=<6g?aHE`[\S]C]T0Wm Date: Mon, 06 Dec 1999 14:41:57 -0800 Message-ID: <6268.944520117@pinhead.parag.codegen.com> From: Parag Patel Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Regarding the PCI DMA problems and corruption, it reminds of me of a similar PCI and DMA-related problem we had when porting OpenBSD to a now-defunct NKK MIPS chipset. It may not be related, but here it is. The port was up and running but under heavy load, say a compile, apps (specifically one of the compiler passes) that were running would start dying with seg-faults and then locking up the system. We finally had to get out the logic-analyzer and MIPS probe, and even then we still couldn't watch everything due to the MIPS on-chip cache. The support chipset was locking up. This chip had to handle memory access from the MIPS CPU, handle DRAM directly, and handle DMA access from the PCI bus. It bridged all three (CPU, RAM, PCI) and seemed to us to be hosing itself in some funky meta-stable condition. Heavy simultaneous memory access, typically PCI DMA bursts from different devices, usually triggered the lockup. So it's quite possible that the host-to-PCI-to-memory controller chipset may be the real culprit and not the drivers or specific PCI devices. In the proecss, we discovered a very interesting thing about the NCR/Symbios chips, at least the 810 and 825 series. Turns out that when they are executing their scripts, and the scripts access an on-board PCI register, that access actually negotiates for the PCI bus and uses it to read the register! That's right - it uses the PCI bus to talk to itself - even when it's not DMA-ing anything! Freaked us out when we saw it, 'cause the CPU wasn't anywhere near any code that was accessing the NCR's registers. Of course it slows down script execution but could slow down the PCI bus depending on the script. And this is all without the CPU being involved. Certainly it'll cause more PCI-bus activity that most other chips, and perhaps this is why NCR controllers tend to trigger the DMA condition. It seems that whoever designed the NCR's script-engine glommed it onto the original programmed I/O SCSI core using the PCI bus instead of redesigning the chip. Cheap short-cut. Dunno if any other NCR chips exhibit this behavior, but I wouldn't be surprised. -- Parag Patel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 14:57:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from Genesis.Denninger.Net (209-176-244-82.inil.com [209.176.244.82]) by hub.freebsd.org (Postfix) with ESMTP id 6853F14C26 for ; Mon, 6 Dec 1999 14:57:10 -0800 (PST) (envelope-from karl@Genesis.Denninger.Net) Received: (from karl@localhost) by Genesis.Denninger.Net (8.9.3/8.8.2) id QAA25933; Mon, 6 Dec 1999 16:56:59 -0600 (CST) Message-ID: <19991206165659.A25917@Denninger.Net> Date: Mon, 6 Dec 1999 16:56:59 -0600 From: Karl Denninger To: Matthew Dillon Cc: Dennis , hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) References: <19991205120428.E6F4514C3E@hub.freebsd.org> <199912061939.OAA22030@etinc.com> <199912062019.MAA72301@apollo.backplane.com> <19991206144330.B25513@Denninger.Net> <199912062124.NAA72775@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199912062124.NAA72775@apollo.backplane.com>; from Matthew Dillon on Mon, Dec 06, 1999 at 01:24:36PM -0800 Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Dec 06, 1999 at 01:24:36PM -0800, Matthew Dillon wrote: > :Well, I used to run -CURRENT in a commercial environment :-) > : > :And I got bashed here and elsewhere for doing it too. > : > :But, with the exception of some really egregious fuck-ups (on both my part > :and those of people who committed shit that didn't work AT ALL) it was, by > :far, the better option of those available. > : > :For quite some time there were special "hacks" that I had (primarily > :consisting of grabbing older versions of this module or that) to get > :around stupidities that were in the process of being resolved, and there > :were always things that I disabled or just didn't do because I knew they > :were broken. > > This was an unfortunate consequence which I take partial blame for > in my little corner of the system -- but only partial blame. It was > hard enough getting my stuff into -current with all the extra requirements > core forced onto me, I didn't want to have to go through the same hell > to get it MFC'd into -stable as well. At one point at the beginning, > before the shit began to fly, I was actually considering only doing it > for -current but as more and more bugs were found it became clear that > if the stuff didn't get MFC'd into -stable soon it wouldn't at all. > By that time the shit was already flying and I just didn't want to > double it. Maybe 80% of the bug fixes have been MFC'd -- the ones that > were easy to fix. The other 20% can't be MFC'd without the rest of > the infrastructure in 4.x to support them. > > I hope the same thing will not repeat for 4.x/5.x, even without an > enforced stabilizing period between 4.0 and 4.1 prior to branching > off. However, I think that an enforced stabilizing period where > *everyone* is concentrating on 4.1 for a couple of months would be > extremely good for the project. > > -Matt I don't think you were to blame at all Matt, at least not in my particular set of circumstances. I'm the first to admit that when I use an OS I typically have both high expectations and also tend to have unique requirements. I stress parts of the system that many people do not. I frequently make performance demands on parts of the system that are unique, and they are inherent to how I design systems and software - I don't believe in throwing iron at a problem, rather, I expect the iron that is available to work with the code that is in the OS - and do so properly. When things don't work that way, its trouble. The list of vendors I have pissed off over the years because they either (1) broke something that worked horribly - usually by destroying its performance to the point that areas of the system I counted on were no longer usable for the production load I expected out of them, or (2) they flatly didn't bother supporting certain things that *should* work, is legion in the business in general. In some cases (commercialware, where you can have such expectations) I've found cooking of so-called "published performance levels" to literally outrageous levels, at least one commercial vendor has eaten six-digits worth of equipment over these types of issues, and another (many, many years ago) was literally driven from the US marketplace. I tend to find these situations very rapidly under commercial use conditions, because I select components and subsystems *precisely* due to those performance claims. When they cannot be met, or something is changed that breaks those claims, well, then the fur flies. This shouldn't imply that I dislike FreeBSD. On the contrary. It's still what I run on my OWN hardware for my OWN projects - after trying pretty much literally everything else at least once, and even after getting into some pretty serious pissing matches over the years with various members of CORE. Where I'm from that's known as a ringing endorsement. -- -- Karl Denninger (karl@denninger.net) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 15:12:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 1692A14E90 for ; Mon, 6 Dec 1999 15:12:50 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA38854; Mon, 6 Dec 1999 16:12:49 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA37583; Mon, 6 Dec 1999 16:12:49 -0700 (MST) Message-Id: <199912062312.QAA37583@harmony.village.org> To: Darren Reed Subject: Re: 3c589d w/ freebsd 3.3 works badly. Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 06 Dec 1999 13:51:20 +1100." <199912060251.NAA16461@cairo.anu.edu.au> References: <199912060251.NAA16461@cairo.anu.edu.au> Date: Mon, 06 Dec 1999 16:12:49 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199912060251.NAA16461@cairo.anu.edu.au> Darren Reed writes: : How reliable should the ep0 driver be with 3c389d pcmcia cards ? I had no problems using 3.3 and my 3C589D, but I've only done minor stuff with that. I've done most of my work on -current, however. The most likely problem is that you're using the wrong IRQ for the card. You'll want to check /etc/rc.conf to make sure that you are using the /etc/pccard.conf file. Also, you'll want to make sure that the irq line is correct. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 15:15:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 9082D14E90 for ; Mon, 6 Dec 1999 15:15:51 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA38870; Mon, 6 Dec 1999 16:15:50 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA37611; Mon, 6 Dec 1999 16:15:49 -0700 (MST) Message-Id: <199912062315.QAA37611@harmony.village.org> To: Darren Reed Subject: Re: ejecting card with 3.3 causes hang ? Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 06 Dec 1999 13:58:29 +1100." <199912060258.NAA17727@cairo.anu.edu.au> References: <199912060258.NAA17727@cairo.anu.edu.au> Date: Mon, 06 Dec 1999 16:15:49 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199912060258.NAA17727@cairo.anu.edu.au> Darren Reed writes: : ejecting a modem pcmcia card caused 3.3 to do the following: : /kernel: sio2 unload,gone : /kernel: Return IRQ=11 : /kernel: Card removed, slot 1 : /kernel: Card inserted, slot 0 : and then it was frozen. : : Will there be a 3.4 with things like this fixed ? Not likely. There are no known problems right now in the -stable code which don't represent a failure to detect pilor error and/or race conditions that cannot be worked around w/o huge performance penalties. I don't maintain -stable's pccard code and to the best of my knowledge, no one else does either. This means there is no one to look at them. I'll be happy to look at patches for -stable, however. The times I've made this offer in the past I've not gotten patches. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 15:21: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 1F24915049; Mon, 6 Dec 1999 15:21:04 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA38894; Mon, 6 Dec 1999 16:21:03 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA37653; Mon, 6 Dec 1999 16:21:03 -0700 (MST) Message-Id: <199912062321.QAA37653@harmony.village.org> To: Mike Smith Subject: Re: tty level buffer overflows Cc: mjacob@feral.com, hackers@FreeBSD.ORG In-reply-to: Your message of "Sun, 05 Dec 1999 20:41:31 PST." <199912060441.UAA00805@mass.cdrom.com> References: <199912060441.UAA00805@mass.cdrom.com> Date: Mon, 06 Dec 1999 16:21:03 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199912060441.UAA00805@mass.cdrom.com> Mike Smith writes: : Yup. Ignore the "problem in the application" part, as that predicates : that the kernel and driver are working properly, which doesn't seem to be : the case. The problem here is that the buffer between the top side of : the driver and the application isn't being drained fast enough. It would : be educational to know what the app is sleeping on when these messages : are emitted; just dropping to ddb and using 'ps' would probably be : enough. There has to be some reason that the process is either not being : woken when data arrives, or is being held up somewhere else for long : enough that the clist overflows. : : Does the problem still manifest with the recent scheduler changes? : Perhaps the comms processes are being unfairly scheduled against for some : reason? We're seeing it with our ppp link, which uses the kernel level ppp code. Since it doesn't happen for me often, it is hard to diagnose. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 15:25:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cairo.anu.edu.au (cairo.anu.edu.au [150.203.224.11]) by hub.freebsd.org (Postfix) with ESMTP id D119915065 for ; Mon, 6 Dec 1999 15:25:14 -0800 (PST) (envelope-from avalon@cairo.anu.edu.au) Received: (from avalon@localhost) by cairo.anu.edu.au (8.9.3/8.9.3) id KAA17817; Tue, 7 Dec 1999 10:26:27 +1100 (EST) From: Darren Reed Message-Id: <199912062326.KAA17817@cairo.anu.edu.au> Subject: Re: 3c589d w/ freebsd 3.3 works badly. To: imp@village.org (Warner Losh) Date: Tue, 7 Dec 1999 10:26:27 +1100 (Australia/NSW) Cc: hackers@FreeBSD.ORG In-Reply-To: <199912062312.QAA37583@harmony.village.org> from "Warner Losh" at Dec 06, 1999 04:12:49 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In some mail from Warner Losh, sie said: > > In message <199912060251.NAA16461@cairo.anu.edu.au> Darren Reed writes: > : How reliable should the ep0 driver be with 3c389d pcmcia cards ? > > I had no problems using 3.3 and my 3C589D, but I've only done minor > stuff with that. I've done most of my work on -current, however. The > most likely problem is that you're using the wrong IRQ for the card. > You'll want to check /etc/rc.conf to make sure that you are using the > /etc/pccard.conf file. Also, you'll want to make sure that the irq > line is correct. Did all of that. When ejecting the card it says "freeing IRQ 10" (or words to that effect), which is the IRQ I used with it under Windows and NetBSD. How much can I specify on the "config" lines in pccard.conf ? Can I `wire down' irq's, iomem and iobuf in the "?" part of the line ? Darren p.s. is the not printing of the IRQ being allocated at bootup a bug ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 15:30: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by hub.freebsd.org (Postfix) with ESMTP id 8C7D414F96 for ; Mon, 6 Dec 1999 15:30:05 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id PAA02867; Mon, 6 Dec 1999 15:31:35 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912062331.PAA02867@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Luoqi Chen Cc: freebsd-hackers@FreeBSD.ORG, gallatin@cs.duke.edu Subject: Re: Is part of user stack always mapped? In-reply-to: Your message of "Mon, 06 Dec 1999 17:16:31 EST." <199912062216.RAA09858@lor.watermarkgroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Dec 1999 15:31:35 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I was under the impression that this was a no-no & one should use > > copyin/copout & friends to access memory on users's stacks. Although > > this appears to work on the i386, if I try this on the alpha I take a > > fatal trap when accessing *set. > > > > So -- how does this work on the i386? Is the user's stack always > > mappeped into the kernel's address space? Should it also work on the > > alpha? > > > On i386, under the current implementation, the kernel can directly access > curproc's address space (not just the stack, stack is used because we're > sure the spare space won't/shouldn't be used by the user application). > I don't know if the same is true for alpha, but this should definitely > be considered an implementation dependent feature. I wish there were some > other ways to bypass copyin/out in ioctls. The problem wouldn't be a problem if the implementation portion of system call code didn't make assumptions about whether data is in user- or kernel-space. This has been an off and on topic of discussion for some time now. The ABI emulators use the stackgap because there are system call implementations that expect to be moving their data structures to/from user space. 8( -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 15:32:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id AB39814F96 for ; Mon, 6 Dec 1999 15:32:09 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA38977; Mon, 6 Dec 1999 16:31:59 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA37814; Mon, 6 Dec 1999 16:31:59 -0700 (MST) Message-Id: <199912062331.QAA37814@harmony.village.org> To: Darren Reed Subject: Re: 3c589d w/ freebsd 3.3 works badly. Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Tue, 07 Dec 1999 10:26:27 +1100." <199912062326.KAA17817@cairo.anu.edu.au> References: <199912062326.KAA17817@cairo.anu.edu.au> Date: Mon, 06 Dec 1999 16:31:59 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199912062326.KAA17817@cairo.anu.edu.au> Darren Reed writes: : Did all of that. When ejecting the card it says "freeing IRQ 10" (or : words to that effect), which is the IRQ I used with it under Windows : and NetBSD. How much can I specify on the "config" lines in pccard.conf ? : Can I `wire down' irq's, iomem and iobuf in the "?" part of the line ? For -stable, no you can't do it that way. You can do it with /boot/loader.conf by setting the following. If you are gunning for 10, then substitute 10 for the '0' below. machdep.pccard.pcic_irq="0" # Assigns PCCARD controller IRQ (0=polled) You wire down the memory part in /etc/rc.conf: pccard_mem="DEFAULT" # If pccard_enable=YES, this is card memory address. The irq/memory for the card itself is done /etc/pccard.conf, which is at best an exersize in black magic and at worst a frustration laden time for one and all. : p.s. is the not printing of the IRQ being allocated at bootup a bug ? Yes. I think so. We should print which IRQ we're using. The pcic/pccard module is a kludgey wort on the side of the kludgy old-config system... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 15:45:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bilby.prth.tensor.pgs.com (bilby.prth.tensor.pgs.com [157.147.232.237]) by hub.freebsd.org (Postfix) with ESMTP id 2D8D315138; Mon, 6 Dec 1999 15:44:50 -0800 (PST) (envelope-from shocking@bandicoot.prth.tensor.pgs.com) Received: from bandicoot.prth.tensor.pgs.com (bandicoot.prth.tensor.pgs.com [157.147.224.1]) by bilby.prth.tensor.pgs.com (8.9.3/8.8.8) with ESMTP id HAA00641; Tue, 7 Dec 1999 07:42:55 +0800 (WST) Received: from ariadne.prth.tensor.pgs.com (ariadne [157.147.227.36]) by bandicoot.prth.tensor.pgs.com (8.9.3/8.8.8) with ESMTP id HAA15548; Tue, 7 Dec 1999 07:44:45 +0800 (WST) From: Stephen Hocking-Senior Programmer PGS Perth Received: (from shocking@localhost) by ariadne.prth.tensor.pgs.com (8.9.1b+Sun/8.9.0) id HAA18057; Tue, 7 Dec 1999 07:44:44 +0800 (WST) Date: Tue, 7 Dec 1999 07:44:44 +0800 (WST) Message-Id: <199912062344.HAA18057@ariadne.prth.tensor.pgs.com> To: hackers@freebsd.org, multimedia@freebsd.org Subject: Glide source available Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Go look at http://linux.3dfx.com/open_source It's availabe for Voodoo 1, 2, & 3 cards. Register level specs too! I'm utterly freaked out. Stephen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 16:11:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from front6.grolier.fr (front6.grolier.fr [194.158.96.56]) by hub.freebsd.org (Postfix) with ESMTP id 9B34E14FD1; Mon, 6 Dec 1999 16:11:10 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-116-253.villette.club-internet.fr [194.158.116.253]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id BAA19174; Tue, 7 Dec 1999 01:11:01 +0100 (MET) Date: Tue, 7 Dec 1999 02:36:26 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Parag Patel Cc: Mike Smith , Ed Hall , freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-Reply-To: <6268.944520117@pinhead.parag.codegen.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 6 Dec 1999, Parag Patel wrote: =20 [ ... ] > In the proecss, we discovered a very interesting thing about the > NCR/Symbios chips, at least the 810 and 825 series. Turns out that when > they are executing their scripts, and the scripts access an on-board PCI > register, that access actually negotiates for the PCI bus and uses it to > read the register! That's right - it uses the PCI bus to talk to > itself - even when it's not DMA-ing anything! That's true for drivers that uses MEMORY MOVE scripts instructions to access chip IO registers from SCRIPTS, as does the ncr and most existing generic SYM53C8XX PCI device drivers. Such a technic is no longer PCI compliant since PCI specifications 2.2. The sym driver uses LOAD/STORE instead that donnot involve any self mastering from the chip and so preserves PCI 2.2 compliance. But this needed to drop support of 810 and 825. Btw, even using the sym driver has been reported to trigger the problem, so this should not be the cause of the problem.=20 > Freaked us out when we saw it, 'cause the CPU wasn't anywhere near any > code that was accessing the NCR's registers. Of course it slows down > script execution but could slow down the PCI bus depending on the > script. And this is all without the CPU being involved. Certainly > it'll cause more PCI-bus activity that most other chips, and perhaps > this is why NCR controllers tend to trigger the DMA condition. I donnot know about the fxp driver, but looking into the code as a newbie, I didn't get how this driver ensures instruction and memory ordering and PCI transaction ordering when it is needed (could it be never needed?). It also seems to write non atomically to some 32 bit quantities in memory that seem to be accessed by the PCI device. Indeed, I may for sure did miss lots of things, but this seems strange to me. Sorry if my remarks are irrelevant. I just was wondering. > It seems that whoever designed the NCR's script-engine glommed it onto > the original programmed I/O SCSI core using the PCI bus instead of > redesigning the chip. Cheap short-cut. Dunno if any other NCR chips > exhibit this behavior, but I wouldn't be surprised. A well designed PCI device must be capable of having its master part accessing its target part through the PCI BUS lines without contention.=20 This does not imply that using such a feature is recommended since it wastes PCI bandwidth (and btw is not compliant with PCI-2.2). Using internal pathes instead is recommended to access internal ressources. The sym driver does this the right way using LOAD/STORE (at least, it is what I beleive :), but this could not be achieved for ealiest 810/815/825 due to the lack of these SCRIPTS instructions for these chips.=20 G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 16:33:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 8844D14CC7 for ; Mon, 6 Dec 1999 16:33:06 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id TAA14617; Mon, 6 Dec 1999 19:33:04 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id TAA86625; Mon, 6 Dec 1999 19:32:34 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 6 Dec 1999 19:32:34 -0500 (EST) To: Luoqi Chen Cc: freebsd-hackers@FreeBSD.ORG, dfr@nlsystems.com Subject: Re: Is part of user stack always mapped? In-Reply-To: <199912062216.RAA09858@lor.watermarkgroup.com> References: <199912062216.RAA09858@lor.watermarkgroup.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14412.21471.227840.24484@grasshopper.cs.duke.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Luoqi Chen writes: > > I was under the impression that this was a no-no & one should use > > copyin/copout & friends to access memory on users's stacks. Although > > this appears to work on the i386, if I try this on the alpha I take a > > fatal trap when accessing *set. > > > > So -- how does this work on the i386? Is the user's stack always > > mappeped into the kernel's address space? Should it also work on the > > alpha? > > > On i386, under the current implementation, the kernel can directly access > curproc's address space (not just the stack, stack is used because we're > sure the spare space won't/shouldn't be used by the user application). > I don't know if the same is true for alpha, but this should definitely > be considered an implementation dependent feature. I wish there were some > other ways to bypass copyin/out in ioctls. > > -lq I think the alpha should be capable of doing this too. From reading the alpha pmap code, it looks like its marking memory as kernel readable/writeable whenever it does the same for the userspace access. I might be reading it wrong, though. Can anybody tell me why an access to memory allocated w/stackgap_alloc() would cause a kernel panic on alpha, but works just fine through the copyin/copyout interface? Eg: #0 0xfffffc0000391054 in boot (howto=256) at ../../kern/kern_shutdown.c:271 #1 0xfffffc0000391810 in panic (fmt=0xfffffc00005a2ca4 "trap") at ../../kern/kern_shutdown.c:523 #2 0xfffffc00005340a0 in trap (a0=301973216, a1=1, a2=1, entry=2, framep=0xfffffe0010699ce0) at ../../alpha/alpha/trap.c:529 #3 0xfffffc00005262ec in XentMM () at ../../alpha/alpha/exception.s:94 #4 0xfffffe0001afa440 in osf1_sigsuspend (p=0xfffffe000ed4ff00, uap=0x0) at /usr/project/ari_scratch2/gallatin/src/sys/modules/osf1/../../alpha/osf1/osf1_signal.c:613 #5 0xfffffc0000534304 in syscall (code=111, framep=0xfffffe0010699ee0) at ../../alpha/alpha/trap.c:633 #6 0xfffffc000052634c in XentSys () at ../../alpha/alpha/exception.s:127 <...> (gdb) frame 2 #2 0xfffffc00005340a0 in trap (a0=301973216, a1=1, a2=1, entry=2, framep=0xfffffe0010699ce0) at ../../alpha/alpha/trap.c:529 529 panic("trap"); (gdb) p/x a0 $1 = 0x11ffbee0 (gdb) p/x curproc->p_vmspace->vm_maxsaddr $2 = 0xfffc000 (gdb) p/x curproc->p_vmspace->vm_minsaddr $3 = 0x11ffb2c8 For you non-alpha people -- in the above, a0 is the faulting address. Thanks, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 16:46:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 32C461504B; Mon, 6 Dec 1999 16:46:38 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA73815; Mon, 6 Dec 1999 16:46:36 -0800 (PST) (envelope-from dillon) Date: Mon, 6 Dec 1999 16:46:36 -0800 (PST) From: Matthew Dillon Message-Id: <199912070046.QAA73815@apollo.backplane.com> To: Zhihui Zhang Cc: "Ronald G. Minnich" , freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: ELF & putting inode at the front of a file References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> distribute the inodes all over the cylinder group rather then concentrate :> all the inodes in one place. : :Yes. I have implemented most of the code. I noticed the "ls -al" is slow :but "ls" is OK. Yes, ls (without any options) is ok because the file type is now being stuffed in the directory entry, allowing ls (without any options) to avoid stat()ing the file. :> p.s. I was wrong about it breaking mmap() - in fact offseting the file :> data on-disk will not break mmap(). But it will produce unaligned disk :> transfers and potentially extra seeking. : :Yes. The cp command may use mmap(). I modify the mmap() so that this :works. But this mmap() is done by the user, I can intercept it at the :mmap() system call. As I said in my original email, the kernel uses :memory map internally to load an ELF object file. I have to let the kernel :know that there is a disk inode at the beginning of the ELF object file. :It is hard for me to identify what part of the code is affected and to :what extent. I think there should be a way. : :-Zhihui There's another issue that you should look at - generally functionally different caches work better as separate entities then as a single entity. In this case it is far easier for the system to cache an inode (or a set of inodes) then it is for the system to cache a data block. If you force a system to cache both at the same time when it only needs one type or the other (because one might already be cached), the result is that neither cache is able to run optimally. It might be interesting, as an exercise, to attempt to pre-cache the inode space in the traditional unmodified system when a directory is read and leave them as separate entities and see whether that gives you the same performance boost. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 16:50: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from www.geocrawler.com (sourceforge.net [209.81.8.17]) by hub.freebsd.org (Postfix) with ESMTP id 4A166150E1 for ; Mon, 6 Dec 1999 16:49:55 -0800 (PST) (envelope-from nobody@www.geocrawler.com) Received: (from nobody@localhost) by www.geocrawler.com (8.9.3/8.9.3) id QAA22811; Mon, 6 Dec 1999 16:49:58 -0800 Date: Mon, 6 Dec 1999 16:49:58 -0800 Message-Id: <199912070049.QAA22811@www.geocrawler.com> To: freebsd-hackers@freebsd.org Subject: PCI device drivers From: "Alex" Reply-To: "Alex" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message was sent from Geocrawler.com by "Alex" Be sure to reply to that address. Hello, I'm writting PCI device drivers (KLD) for FreeBSD 3.2. PCI board is probed and attached correclty during booting. Is exist any function, which I can use in my device driver, that can returns me device configuration (pcici_t)? (like in Linux - pcibios_find_device) Thanks for any help? Geocrawler.com - The Knowledge Archive To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 16:56:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from luna.lyris.net (luna.shelby.com [207.90.155.6]) by hub.freebsd.org (Postfix) with ESMTP id 45A0215075 for ; Mon, 6 Dec 1999 16:56:45 -0800 (PST) (envelope-from kip@lyris.com) Received: from luna.shelby.com by luna.lyris.net (8.9.1b+Sun/SMI-SVR4) id QAA19028; Mon, 6 Dec 1999 16:56:29 -0800 (PST) Received: from (luna.shelby.com [207.90.155.6]) by luna.shelby.com with SMTP (MailShield v1.50); Mon, 06 Dec 1999 16:56:29 -0800 Date: Mon, 6 Dec 1999 16:56:29 -0800 (PST) From: Kip Macy X-Sender: kip@luna To: Viren Jain Cc: freebsd-hackers@freebsd.org Subject: Re: Linking problems w/ pthreads on 3.3 In-Reply-To: <4.2.0.58.19991206150019.00a63380@pop.interactive.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: luna X-SMTP-MAIL-FROM: kip@lyris.com X-SMTP-RCPT-TO: viren@interactive.net,freebsd-hackers@freebsd.org X-SMTP-PEER-INFO: luna.shelby.com [207.90.155.6] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I had a similar problem from installing GNU's Portable Threads package. I fixed it by uninstalling the package. -Kip On Mon, 6 Dec 1999, Viren Jain wrote: > NOTE: Please reply directly to my email address (viren@interactive.net) > > Platform: x86, FreeBSD 3.3 > > While trying to link a threaded application with -pthread using the > following command line: > gcc -I/usr/local/include -L/usr/local/lib/mysql -pthread -o impd daemon.o > db.o handlers.o imp_list.o imp_util.o log.o main.o net.o opt.o request.o > sig.o statsd.o util.o -lmysqlclient > > I receive the following errors: > > daemon.o(.text+0x10): undefined reference to `__pthread_fork' > db.o(.text+0x33c): undefined reference to `__pthread_sleep' > main.o(.text+0xce): undefined reference to `__pthread_detach' > net.o(.text+0x196): undefined reference to `__pthread_select' > net.o(.text+0x411): undefined reference to `__pthread_read' > net.o(.text+0x535): undefined reference to `__pthread_write' > > Threaded libraries appear to be installed in /usr/lib (libc_r.a, libc_r.so, > libc_r.so.3, and libc_r_p.a) and thus I am unsure of how to correct this > problem. Any help or advice would be appreciated. > > -- Viren > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 17: 9:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.iol.ie (mail3.mail.iol.ie [194.125.2.194]) by hub.freebsd.org (Postfix) with ESMTP id ADE4B15061 for ; Mon, 6 Dec 1999 17:09:52 -0800 (PST) (envelope-from nick@iol.ie) Received: from beckett.earlsfort.iol.ie (beckett.earlsfort.iol.ie [194.125.21.2]) by mail.iol.ie Sendmail (v8.9.3) with ESMTP id BAA67675; Tue, 7 Dec 1999 01:09:51 GMT Received: (from nick@localhost) by beckett.earlsfort.iol.ie Sendmail (v8.9.3) id BAA12774; Tue, 7 Dec 1999 01:11:00 GMT From: Nick Hilliard Message-Id: <199912070111.BAA12774@beckett.earlsfort.iol.ie> Subject: Re: ejecting card with 3.3 causes hang ? To: imp@village.org Date: Tue, 7 Dec 1999 01:11:00 +0000 (GMT) Cc: hackers@freebsd.org X-NCC-RegID: ie.iol X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : I don't maintain -stable's pccard code and to the best of : my knowledge, no one else does either. This means there is no one to : look at them. : : I'll be happy to look at patches for -stable, however. The times I've : made this offer in the past I've not gotten patches. Now that you're volunteering, could you please change CIS_MAXSTR in usr.sbin/pccard/pccardd/readcis.h from 30 to something large - 254 would do fine? There's an open PR about this in GNATS, but it looks like GNATS is fubar at the moment, so I can't give you the exact number of it. It's categorised under bin/, was submitted in Q1 1999, and has a subject including the text "CIS_MAXSTR", so it shouldn't be too difficult to find. The change is completely benign and doesn't have any adverse side-effects. Nick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 17:34:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sr14.nsw-remote.bigpond.net.au (sr14.nsw-remote.bigpond.net.au [24.192.3.29]) by hub.freebsd.org (Postfix) with ESMTP id D21E314EE2 for ; Mon, 6 Dec 1999 17:34:24 -0800 (PST) (envelope-from a.reilly@lake.com.au) Received: from areilly.bpc-users.org (CPE-24-192-49-170.nsw.bigpond.net.au [24.192.49.170]) by sr14.nsw-remote.bigpond.net.au (Pro-8.9.3/8.9.3) with SMTP id MAA28219 for ; Tue, 7 Dec 1999 12:34:20 +1100 (EDT) Received: (qmail 76313 invoked by uid 1000); 7 Dec 1999 01:34:19 -0000 From: "Andrew Reilly" Date: Tue, 7 Dec 1999 12:34:19 +1100 To: Wes Peters Cc: Matthew Dillon , Kris Kennaway , freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) Message-ID: <19991207123419.A76129@gurney.reilly.home> References: <199912050514.VAA58998@apollo.backplane.com> <3849FD95.F0434263@softweyr.com> <199912050646.WAA59445@apollo.backplane.com> <384B228D.FFE9728@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <384B228D.FFE9728@softweyr.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Dec 05, 1999 at 07:42:21PM -0700, Wes Peters wrote: > Software > is created by humans, and humans are fallible, therefore the software > is also fallible. No, that doesn't logically follow. Just because it's possible for humans to make mistakes doesn't mean that it's impossible to do or make something (eventually) without mistakes. Even when formal proof isn't possible (the usual case) careful design, backed up by design-based assertions and tests can produce code that does not have bugs. FreeBSD is a big and complicated thing, but it's (largely) composed of subsystems that can be maintained, designed and tested by individuals. I think that a goal of "surprise at a crash of any sort" isn't unreasonable, and highly desirable. I'll take "right" over "fast", and both over "features" any day. -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 18:30:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pluto.cpe.ku.ac.th (pluto.cpe.ku.ac.th [158.108.32.150]) by hub.freebsd.org (Postfix) with ESMTP id B18B714BC4 for ; Mon, 6 Dec 1999 18:30:33 -0800 (PST) (envelope-from b39wys@pluto.cpe.ku.ac.th) Received: from localhost (b39wys@localhost) by pluto.cpe.ku.ac.th (8.9.3/8.9.3) with ESMTP id JAA14419 for ; Tue, 7 Dec 1999 09:32:08 GMT Date: Tue, 7 Dec 1999 09:32:08 +0000 (GMT) From: Witthaya Panichprechakorn To: freebsd-hackers@freebsd.org Subject: About divert socket Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear Sir, I use divert socket to captuer packets. I found that when I capture a set of fragmented packets, there are 2 incoming reassembled packets. The sin_port of sockaddr_in of the first packet is 0, and of another packet is the port number, which it bound to. However, when the packet is not fragmented, there is only one incoming packet with sin_port of sockaddr_in equals to the port number, which it bound to, similar to the second captured packet when framentation occured. What is the actual process when a set of fragmented packets is arrived? Why the system should divert two incoming packets? Best Regards, Withaya Panichpreechakorn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 18:47:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id F2F4914E2E for ; Mon, 6 Dec 1999 18:47:27 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 68080 invoked by uid 1001); 7 Dec 1999 02:45:04 -0000 Date: Mon, 6 Dec 1999 18:45:04 -0800 From: Jason Evans To: freebsd-hackers@freebsd.org Subject: *jmp() renaming in libc Message-ID: <19991206184504.N57183@sturm.canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm porting the most recent released version of LinuxThreads (glibc-linuxthreads-2.1.2), and ran into a bit of a problem with regard to longjmp() and siglongjmp(). LinuxThreads wraps these functions so that they work correctly in the presence of cleanup handlers. However, this doesn't appear to be possible with our C library, since there are no other names by which to access sigsetjmp() and siglongjmp(). I noticed the following comment in src/lib/libc/i386/gen/sigsetjmp.S: /*- * TODO: * Rename sigsetjmp to __sigsetjmp and siglongjmp to __siglongjmp, * remove the other *jmp functions and define everything in terms * of the renamed functions. This requires compiler support for * the renamed functions (introduced in gcc-2.5.3; previous versions * only supported *jmp with 0 or 1 leading underscores). * [...] */ If this were done, I think it would solve my problem. However, it looks to be an almost trivially easy change for someone familiar with libc, yet it hasn't happened for the several years that it has been possible. Also, for the alpha platform, sigsetjmp() and siglongjmp() are defined in terms of setjmp(), _setjmp(), longjmp(), and _longjmp(), which is essentially the opposite approach of what the TODO comment suggests. Is there a reason that this TODO comment hasn't been acted on, other than no one getting around to it? Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 21: 4:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id B314714EE9 for ; Mon, 6 Dec 1999 21:04:48 -0800 (PST) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id OAA11150; Tue, 7 Dec 1999 14:38:09 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3.1 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199912070049.QAA22811@www.geocrawler.com> Date: Tue, 07 Dec 1999 14:38:09 +1030 (CST) From: "Daniel O'Connor" To: Alex Subject: RE: PCI device drivers Cc: freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 07-Dec-99 Alex wrote: > in my device driver, that can returns me device > configuration (pcici_t)? (like in Linux - > pcibios_find_device) > Thanks for any help? Thats not the way its done in FreeBSD.. Your probe routine is called when the system wants to know if a given device can be handled by your driver. Read /usr/src/sys/pci/if_fxp.c Actually all of /usr/src/sys/pci/* is interesting reading :) --- 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 21:10:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id B9B8D14EE9 for ; Mon, 6 Dec 1999 21:10:42 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id AAA14443; Tue, 7 Dec 1999 00:10:42 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Tue, 7 Dec 1999 00:10:42 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Wes Peters Cc: hackers@freebsd.org Subject: Re: HomePNA network cards In-Reply-To: <384C37ED.5CCA93F0@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 6 Dec 1999, Wes Peters wrote: > Has anyone gotten one of these to work with the lnc driver in current? > Looking at the chip specs, it is supposed to be software compatible with > the PCNet PCI parts, but it sports the "home networking" PHY that are > not supported on other LANCE parts. > > If you've had success with these, please let me know. A friend wants to > setup a network but doesn't have access to the wall spaces in his house. > Silly boy. I submitted a pr in June with patches, and it seems to work fairly well. Never checked to see if it was commited though. I've had problems with dropped packets, however--at certain times of day (?) I can't pass any packets on phone wires that run vertically in my parents home. Ended up running ethernet between floors of their house, and the homepna stuff inside the floors. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 21:19:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 414C014EE9 for ; Mon, 6 Dec 1999 21:19:33 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id VAA93497; Mon, 6 Dec 1999 21:19:09 -0800 (PST) Date: Mon, 6 Dec 1999 21:19:08 -0800 (PST) From: Julian Elischer To: Robert Watson Cc: Wes Peters , hackers@FreeBSD.ORG Subject: Re: HomePNA network cards In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 7 Dec 1999, Robert Watson wrote: > On Mon, 6 Dec 1999, Wes Peters wrote: > > I submitted a pr in June with patches, and it seems to work fairly well. > Never checked to see if it was commited though. I've had problems with > dropped packets, however--at certain times of day (?) I can't pass any > packets on phone wires that run vertically in my parents home. Ended up > running ethernet between floors of their house, and the homepna stuff > inside the floors. I looked at the pr database and couldn't see it. can you give more info? Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 21:26:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 591AA14EE9 for ; Mon, 6 Dec 1999 21:26:09 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id AAA14473; Tue, 7 Dec 1999 00:24:57 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Tue, 7 Dec 1999 00:24:57 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Julian Elischer Cc: Wes Peters , hackers@FreeBSD.ORG Subject: Re: HomePNA network cards In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 6 Dec 1999, Julian Elischer wrote: > On Tue, 7 Dec 1999, Robert Watson wrote: > > > On Mon, 6 Dec 1999, Wes Peters wrote: > > > > I submitted a pr in June with patches, and it seems to work fairly well. > > Never checked to see if it was commited though. I've had problems with > > dropped packets, however--at certain times of day (?) I can't pass any > > packets on phone wires that run vertically in my parents home. Ended up > > running ethernet between floors of their house, and the homepna stuff > > inside the floors. > > I looked at the pr database and couldn't see it. can you give more info? > > Julian I believe it was kern/12275. Think it was even closed, but haven't checked in a while. All I know is the cards are working except for the warnings they give and the weird certain-times-of-day problems that case the warnings. It's weird--I guess everyone turns their flourescent lights on at the same time or something. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 21:26:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 6D6B614EE9 for ; Mon, 6 Dec 1999 21:26:21 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id VAA93662; Mon, 6 Dec 1999 21:23:46 -0800 (PST) Date: Mon, 6 Dec 1999 21:23:45 -0800 (PST) From: Julian Elischer To: Robert Watson Cc: Wes Peters , hackers@FreeBSD.ORG Subject: Re: HomePNA network cards In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 6 Dec 1999, Julian Elischer wrote: > > > On Tue, 7 Dec 1999, Robert Watson wrote: > > > On Mon, 6 Dec 1999, Wes Peters wrote: > > > > I submitted a pr in June with patches, and it seems to work fairly well. > > Never checked to see if it was commited though. I've had problems with > > dropped packets, however--at certain times of day (?) I can't pass any > > packets on phone wires that run vertically in my parents home. Ended up > > running ethernet between floors of their house, and the homepna stuff > > inside the floors. > > I looked at the pr database and couldn't see it. can you give more info? Found it... it's been committed to -current.. (and was therefore marked 'closed') > > Julian > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 23: 3:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 1F2F114CA2 for ; Mon, 6 Dec 1999 23:03:35 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id XAA97106 for ; Mon, 6 Dec 1999 23:03:34 -0800 (PST) Date: Mon, 6 Dec 1999 23:03:33 -0800 (PST) From: Julian Elischer To: hackers@freebsd.org Subject: Irda support. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm playing with Irda a bit and an wondering if anyone has also been doing do. The Linux Irda project lookes quite advanced. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 23:12: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 6913014CA2 for ; Mon, 6 Dec 1999 23:12:03 -0800 (PST) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id RAA13240; Tue, 7 Dec 1999 17:41:55 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3.1 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 07 Dec 1999 17:41:55 +1030 (CST) From: "Daniel O'Connor" To: Julian Elischer Subject: RE: Irda support. Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 07-Dec-99 Julian Elischer wrote: > I'm playing with Irda a bit and an wondering if anyone has also been doing > do. The Linux Irda project lookes quite advanced. I have been doing not much more than thinking about it :-/ I'd be interested in participating in a project to do IrDA for FreeBSD.. --- 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 23:13:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id CC5F41532A for ; Mon, 6 Dec 1999 23:13:10 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id CAA25127; Tue, 7 Dec 1999 02:12:22 -0500 (EST) Reply-To: Randell Jesup To: Egervary Gergely , freebsd-hackers@freebsd.org Subject: Re: cdrom speed adjustment ioctl From: Randell Jesup Date: 07 Dec 1999 02:14:34 -0500 In-Reply-To: Egervary Gergely's message of "Mon, 6 Dec 1999 14:59:08 +0100 (CET)" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Egervary Gergely writes: >> I've just hacked a new ioctl into the ATAPI cdrom driver, which >> lets the user to specify (pronounce: ``slow down'' :) the speed >> of todays' extremely high speed drives. > >ok, so i see you like the idea - so the question is: should we implement a >new ioctl for it, or - as like scsi - should we use a program like >camcontrol for it? One solution I used in the past (Amiga) was to implement the ATA (and ATAPI) support by writing the equivalent of SCSI CAM SIM; that is a SIM that actually controlled IDE hardware instead of SCSI hardware. This is quite easy, in fact, especially since ATAPI is basically SCSI-over-IDE with a few twists. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com CDA II has been passed and signed, sigh. The lawsuit has been filed. Please support the organizations fighting it - ACLU, EFF, CDT, etc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 6 23:52:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from www.ifrance.com (www.ifrance.com [209.67.249.134]) by hub.freebsd.org (Postfix) with SMTP id E813414DDF for ; Mon, 6 Dec 1999 23:52:10 -0800 (PST) (envelope-from brunoc@ifrance.com) Received: from 212.124.1.90 [212.124.1.90] by www.ifrance.com; Tue, 7 Dec 1999 07:42:28 GMT Message-ID: <001201bf4088$6e54bbc0$1ec809c0@motte.alpes-net.fr> From: "Christian Bruno" To: Subject: linux compatibility question Date: Tue, 7 Dec 1999 08:55:18 +0100 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 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hello, just a question on Linux compatibility : i was told linux binaries that access to the /proc special filesystem won't work on freebsd ? is that right for the last release of the linux compatibility package ? In your opinion, is it possible to trap all these access to /proc ? the reason why i ask this question is that most of commercial products are only available on Linux boxes. I know that Oracle 8.0.5 Linux can run on FreeBSD, and i cant imagine such an application do not use the /proc Regards, Christian brunoc@ifrance.com ______________________________________________________________________ Message envoye depuis iFrance >> http://www.ifrance.com Gratuit >> Hebergement (50 Mo)/Vos emails (POP&HTML,20 Mo) Votre agenda online gratuit >> http://agenda.ifrance.com NOUVEAU : Faxez gratuitement ! >> http://fax.ifrance.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 0: 2: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 8F22D14E1C; Tue, 7 Dec 1999 00:01:55 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id AAA12168; Tue, 7 Dec 1999 00:01:01 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id AAA08796; Tue, 7 Dec 1999 00:01:00 -0800 Received: from softweyr.com ([204.68.178.39]) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA00928; Tue, 7 Dec 99 00:00:56 PST Message-Id: <384CBED6.FECBC219@softweyr.com> Date: Tue, 07 Dec 1999 01:01:26 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Andrew Reilly Cc: Matthew Dillon , Kris Kennaway , freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) References: <199912050514.VAA58998@apollo.backplane.com> <3849FD95.F0434263@softweyr.com> <199912050646.WAA59445@apollo.backplane.com> <384B228D.FFE9728@softweyr.com> <19991207123419.A76129@gurney.reilly.home> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Andrew Reilly wrote: > > On Sun, Dec 05, 1999 at 07:42:21PM -0700, Wes Peters wrote: > > Software > > is created by humans, and humans are fallible, therefore the software > > is also fallible. > > No, that doesn't logically follow. Just because it's possible > for humans to make mistakes doesn't mean that it's impossible to > do or make something (eventually) without mistakes. And in theory, theory is better than practice. In practice, it rarely is. I've worked on formal proofs for software, and in the most rigorous software evaluations ever performed - the Nuclear Safety Cross Check Analysis for intercontinental ballistic missiles. With the exception of TeX, *no* software is bug-free. In my extensive experience, no software with the exception of TeX is free of serious bugs. This includes the ICBM control system. Your belief or lack thereof doesn't change the existence of the bugs, it just leads YOU to be surprised when they crop up in the oddest ways, while I am not. BTW, if you know anyone at Boeing, ask them if they ever *really* got the "uncommanded flap excursion" bug fixed, or if this is what killed EgyptAir 800. Watch them go into fits. If you can't PROVE it's correct, how much empirical testing are you going to accept? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 1:40:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sr14.nsw-remote.bigpond.net.au (sr14.nsw-remote.bigpond.net.au [24.192.3.29]) by hub.freebsd.org (Postfix) with ESMTP id 91B0E14C93 for ; Tue, 7 Dec 1999 01:40:31 -0800 (PST) (envelope-from A.Reilly@lake.com.au) Received: from areilly.bpc-users.org (CPE-24-192-49-170.nsw.bigpond.net.au [24.192.49.170]) by sr14.nsw-remote.bigpond.net.au (Pro-8.9.3/8.9.3) with SMTP id UAA03002 for ; Tue, 7 Dec 1999 20:40:28 +1100 (EDT) Received: (qmail 92166 invoked from network); 7 Dec 1999 09:40:27 -0000 Received: from localhost (HELO gurney.reilly.home) (@127.0.0.1) by localhost with SMTP; 7 Dec 1999 09:40:27 -0000 Message-ID: X-Mailer: XFMail 1.3.1 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <384CBED6.FECBC219@softweyr.com> Date: Tue, 07 Dec 1999 20:40:27 +1100 (EST) Organization: Lake Technology Limited From: Andrew Reilly To: Wes Peters Subject: Bugs and their ubiquity (was an extended rant about PCI DMA) Cc: freebsd-hackers@FreeBSD.ORG, Matthew Dillon Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Wes, On 07-Dec-99 Wes Peters wrote: > Andrew Reilly wrote: >> >> On Sun, Dec 05, 1999 at 07:42:21PM -0700, Wes Peters wrote: >> > Software >> > is created by humans, and humans are fallible, therefore the >> > software is also fallible. >> >> No, that doesn't logically follow. Just because it's possible >> for humans to make mistakes doesn't mean that it's impossible to >> do or make something (eventually) without mistakes. > With the exception of TeX, *no* software is bug-free. In my > extensive experience, no software with the exception of TeX is free > of serious bugs. That's a little strong, don't you think? I can't remember encountering any bugs, serious or not, in any of the consumer electronics devices I use on a day-to-day basis. I've written a number of embedded signal processing applications myself that do exactly what they're supposed to, and don't ever break. I suspect that it's probably easier to be confident about code that does the same thing hundreds or thousands of times a second than code that will (with good luck and good management) never be run in anger, though. Using the example of TeX, what do you consider is special about it? A happy accident? Isn't it more likely that careful coding to a good design, with well defined inputs and outputs, and subsequent exposure to a great deal of peer review and testing has a little to do with it? How are those conditions different from those faced by any of the subsystems of FreeBSD, except perhaps by degree? > Your belief or lack thereof doesn't change the existence of > the bugs, it just leads YOU to be surprised when they crop up in the > oddest ways, while I am not. My beliefs haven't got much to do with it. Most of my interaction with my own software involves the belief that the subtle bugs are being masked by the obvious bugs. But I use the bugs that I find to teach me about my code and the states that it can find itself in. I leave assertions and invariant checks behind to make sure that the eroneous conditions don't re-occur, or re-design to accommodate them if they represent legal states. In my experience this beats any amount of interactive debugger single-stepping or crash-dump analysis. Remember: in the message that you quoted, I mentioned that the desirable state was one where we were "surprised at a crash of any sort", rather than "convinced by analytic proof that crashes were impossible". Sure, the difference between "surprised by crashes" and "surprised by lack of crashes" is one of degree, but it's a pretty important degree. My personal perception is that FreeBSD is currently much closer to the former state than the latter. Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 2:36:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from nexus.plymovent.se (nexus.plymovent.se [212.247.77.253]) by hub.freebsd.org (Postfix) with ESMTP id 5AFEC150FE for ; Tue, 7 Dec 1999 02:36:15 -0800 (PST) (envelope-from thomas.uhrfelt@plymovent.se) Received: from tu ([192.168.1.21]) by nexus.plymovent.se (8.9.3/8.9.3) with SMTP id LAA13387; Tue, 7 Dec 1999 11:49:34 +0100 (CET) (envelope-from thomas.uhrfelt@plymovent.se) From: "Thomas Uhrfelt" To: "Julian Elischer" Cc: Subject: RE: Irda support. Date: Tue, 7 Dec 1999 11:36:44 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You might want to get in touch with Martin Nilsson (a friend of mine), look at the BSD driver database for further info. http://www.posi.net/freebsd/drivers/drivers.phtml > -----Original Message----- > From: owner-freebsd-hackers@FreeBSD.ORG > [mailto:owner-freebsd-hackers@FreeBSD.ORG]On Behalf Of Julian Elischer > Sent: Tuesday, December 07, 1999 8:04 AM > To: hackers@FreeBSD.ORG > Subject: Irda support. > > > > I'm playing with Irda a bit and an wondering if anyone has also been doing > do. The Linux Irda project lookes quite advanced. > > Julian > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 3:57:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id 4A6F714CEE for ; Tue, 7 Dec 1999 03:57:23 -0800 (PST) (envelope-from freebsd-hackers@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id MAA19601 for hackers@FreeBSD.org; Tue, 7 Dec 1999 12:36:12 +0100 (CET) (envelope-from freebsd-hackers@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for hackers@FreeBSD.org (hackers@FreeBSD.org) To: hackers@FreeBSD.org Date: Tue, 07 Dec 1999 12:36:07 +0100 From: Marcel Moolenaar Message-ID: <384CF127.5A8049F@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <001201bf4088$6e54bbc0$1ec809c0@motte.alpes-net.fr> Subject: Re: linux compatibility question Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Christian Bruno wrote: > I know that Oracle 8.0.5 Linux can run on FreeBSD, and i cant imagine such > an application do not use the /proc Oracle doesn't use /proc. -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 4: 1:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id A0B0914CA3 for ; Tue, 7 Dec 1999 04:01:40 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 869F01CC6; Tue, 7 Dec 1999 20:01:39 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Ed Hall Cc: Matthew Dillon , "Jonathan M. Bresler" , kris@hub.freebsd.org, freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-Reply-To: Message from Ed Hall of "Mon, 06 Dec 1999 13:26:38 PST." <199912062126.NAA30946@screech.weirdnoise.com> Date: Tue, 07 Dec 1999 20:01:39 +0800 From: Peter Wemm Message-Id: <19991207120139.869F01CC6@overcee.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ed Hall wrote: > : you wrote: > : : I wrote: > : :4) Using a different SCSI driver (Peter managed to get a driver from 4.0 > : : hooked up under 3.3, and it survived two days of torture that would > : : have toasted things within an hour using the stock driver; you'll have > : : to ask him for details). > : > : Ed, this is great stuff! > : > : Are you sure about #4? Is that the same ncr.c driver or something > : else? There are only a few differences between the 3.x and 4.x > : /usr/src/sys/pci/ncr.c drivers. Which Peter, Peter Wemm? > > It was Peter Wemm. I may be misunderstanding just what he did--trying > the 4.0 driver was just one several experiments he proposed and > performed. And saying that it "worked" is provisional; two days of > testing strongly suggests that it reduced the problem with 3.3 to > acceptible levels for my application. Is it truly a "fix?" I don't > know. > > -Ed I might add that others have found that using sym + fxp on the N440BX motherboards didn't solve their problems, or moved the problem elsewhere, eg: to the sbdrop() etc routines. One other interesting variable.. an ahc + pn driver combination on a 440BX motherboard under -current in late may 99 had the exact same problems we saw a number of times with ncr + fxp (ie: sbdrop, sbflush, m_copym etc panics). The same motherboard with ahc + de or fxp did not have the problems. In all cases the panics were extremely "strange". The original fxp+ncr combination changed it's crash pattern when we put extra debugging in it to sanity check and check conditions. The results varied from registers getting clobbered (as though an interrupt happened and the trapframe on the stack got changed by the interrupt handler and then returned with garbage contents in some registers.. this is what seems to be happening in the fxp_add_rfabuf() panics - %esi was getting loaded earlier on and when it got to do the vtophys() it was zero. People have printed the contents of "rfa" on the stack and seen garbage - in fact it's a register variable under normal circumstances. Adding debugging caused it to be stored in the local variable rather than being left in %esi, and then the panics moved elsewhere (!).) It had the markings of "something trashing something somewhere and then crashing quite a bit later". :-( Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 6:12:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 8064114EF0; Tue, 7 Dec 1999 06:12:45 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id JAA27117; Tue, 7 Dec 1999 09:12:32 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id JAA87970; Tue, 7 Dec 1999 09:12:02 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 7 Dec 1999 09:12:01 -0500 (EST) To: Peter Wemm Cc: Ed Hall , Matthew Dillon , "Jonathan M. Bresler" , kris@hub.freebsd.org, freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-Reply-To: <19991207120139.869F01CC6@overcee.netplex.com.au> References: <199912062126.NAA30946@screech.weirdnoise.com> <19991207120139.869F01CC6@overcee.netplex.com.au> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14413.5148.670641.885572@grasshopper.cs.duke.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Wemm writes: > > In all cases the panics were extremely "strange". The original fxp+ncr > combination changed it's crash pattern when we put extra debugging in it to > sanity check and check conditions. The results varied from registers getting > clobbered (as though an interrupt happened and the trapframe on the stack got > changed by the interrupt handler and then returned with garbage contents in > some registers.. this is what seems to be happening in the fxp_add_rfabuf() > panics - %esi was getting loaded earlier on and when it got to do the > vtophys() it was zero. People have printed the contents of "rfa" on the stack > and seen garbage - in fact it's a register variable under normal circumstances. > Adding debugging caused it to be stored in the local variable rather than > being left in %esi, and then the panics moved elsewhere (!).) > > It had the markings of "something trashing something somewhere and then crashing > quite a bit later". :-( I had a very similar experience when debugging what I thought were problems with the fxp driver when FreeBSD/alpha was used as a router. After the problem moved to the xl driver when we changed out NICs, my focus moved elsewhere. It turns out that the real problem was that the alpha port had serious interrupt handling problems inherited from NetBSD. There was a large window where the ipl was lowered to zero which allowed another interrupt to come in while still running on the interrupt stack. The interrupt stack grew very large & eventually trashed some critical areas of memory. Any chance that something like this could be happening on the i386? Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 6:56:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mojave.sitaranetworks.com (mojave.sitaranetworks.com [199.103.141.157]) by hub.freebsd.org (Postfix) with ESMTP id B9A8E14A25; Tue, 7 Dec 1999 06:56:35 -0800 (PST) (envelope-from grog@mojave.sitaranetworks.com) Message-ID: <19991206210033.19522@mojave.sitaranetworks.com> Date: Mon, 6 Dec 1999 21:00:33 -0500 From: Greg Lehey To: Warner Losh , Darren Reed Cc: FreeBSD mobile Mailing List Subject: Re: 3c589d w/ freebsd 3.3 works badly. Reply-To: Greg Lehey References: <199912060251.NAA16461@cairo.anu.edu.au> <199912062312.QAA37583@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <199912062312.QAA37583@harmony.village.org>; from Warner Losh on Mon, Dec 06, 1999 at 04:12:49PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Moved to FreeBSD-mobile] On Monday, 6 December 1999 at 16:12:49 -0700, Warner Losh wrote: > In message <199912060251.NAA16461@cairo.anu.edu.au> Darren Reed writes: > : How reliable should the ep0 driver be with 3c389d pcmcia cards ? > > I had no problems using 3.3 and my 3C589D, but I've only done minor > stuff with that. I've done most of my work on -current, however. The > most likely problem is that you're using the wrong IRQ for the card. > You'll want to check /etc/rc.conf to make sure that you are using the > /etc/pccard.conf file. Also, you'll want to make sure that the irq > line is correct. I don't know if this is the same issue, but I've seen terrible write performance on my 3C589C under -CURRENT, and so has phk. Read performance is OK. Looking at the hub, I see a short burst of activity and then nothing for the rest of a second. This repeats itself in this manner. No errors, but a write throughput of less than 50 kB/s. I've seen this before recent changes in -CURRENT, but it seems worse now (or maybe I've just paid more attention to it now :-). Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 6:58: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 2D859153EA for ; Tue, 7 Dec 1999 06:57:57 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p21-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.150]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id XAA01530; Tue, 7 Dec 1999 23:57:46 +0900 (JST) Message-ID: <384D1FC6.6E442B61@newsguy.com> Date: Tue, 07 Dec 1999 23:55:02 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Christian Bruno Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: linux compatibility question References: <001201bf4088$6e54bbc0$1ec809c0@motte.alpes-net.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Christian Bruno wrote: > > I know that Oracle 8.0.5 Linux can run on FreeBSD, and i cant imagine such > an application do not use the /proc Why would such an application use /proc? -- Daniel C. Sobral (8-DCS) who is as social as a wampas dcs@newsguy.com dcs@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 7: 8:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (vpn.iscape.fi [195.170.146.67]) by hub.freebsd.org (Postfix) with ESMTP id AC69914BE7 for ; Tue, 7 Dec 1999 07:08:48 -0800 (PST) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id RAA70155; Tue, 7 Dec 1999 17:06:42 +0200 (EET) (envelope-from will) To: vsilyaev@mindspring.com (Vladimir N. Silyaev) Cc: hackers@freebsd.org Subject: Re: vmnet (was: Linux ioctl not implemented error) References: <19991202160515.C536@jupiter.delta.ny.us> <19991202223604.B5379@jupiter.delta.ny.us> From: Ville-Pertti Keinonen Date: 07 Dec 1999 17:06:41 +0200 In-Reply-To: vsilyaev@mindspring.com's message of "3 Dec 1999 06:42:29 +0200" Message-ID: <86so1ekcxq.fsf@not.demophon.com> Lines: 10 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG vsilyaev@mindspring.com (Vladimir N. Silyaev) writes: > are need to have steal nerves. I fill that, at the time when I was porting > vmware. I have too much hours of very interested work - load driver, launch > vmware and then looking into the DDB double fault screen. Reload box, > and then again. I suppose that the incomplete virtualization of the x86 prevents you from running vmware on FreeBSD on vmware on Linux for debugging? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 7:31:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dns1.sei-iss.com (dns1.sei-iss.com [209.180.63.17]) by hub.freebsd.org (Postfix) with ESMTP id 7713414BE7 for ; Tue, 7 Dec 1999 07:31:32 -0800 (PST) (envelope-from jvanvleet@sei-it.com) Received: from javlaptop ([205.231.131.26]) by dns1.sei-iss.com (8.9.3/8.9.3) with ESMTP id JAA01295; Tue, 7 Dec 1999 09:32:36 -0600 Reply-To: From: "James Van Vleet" To: "Robert Watson" , Subject: RE: HomePNA network cards Date: Tue, 7 Dec 1999 09:30:12 -0600 Message-ID: <000501bf40c7$f3e676e0$6d83e7cd@vanvleet.net> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-reply-to: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have been using the driver with my linksys homePNA cards for at least 3-4 months. My setup is over a phone line that are buried in the ground, out to my garage. It's been working perfectly, at full speed. I was going to ask if it was going to get moved to stable anytime soon... -James > -----Original Message----- > From: owner-freebsd-hackers@FreeBSD.ORG > [mailto:owner-freebsd-hackers@FreeBSD.ORG]On Behalf Of Robert Watson > Sent: Monday, December 06, 1999 11:11 PM > To: Wes Peters > Cc: hackers@freebsd.org > Subject: Re: HomePNA network cards > > > On Mon, 6 Dec 1999, Wes Peters wrote: > > > Has anyone gotten one of these to work with the lnc driver in current? > > Looking at the chip specs, it is supposed to be software compatible with > > the PCNet PCI parts, but it sports the "home networking" PHY that are > > not supported on other LANCE parts. > > > > If you've had success with these, please let me know. A friend > wants to > > setup a network but doesn't have access to the wall spaces in his house. > > Silly boy. > > I submitted a pr in June with patches, and it seems to work fairly well. > Never checked to see if it was commited though. I've had problems with > dropped packets, however--at certain times of day (?) I can't pass any > packets on phone wires that run vertically in my parents home. Ended up > running ethernet between floors of their house, and the homepna stuff > inside the floors. > > Robert N M Watson > > robert@fledge.watson.org http://www.watson.org/~robert/ > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > TIS Labs at Network Associates, Safeport Network Services > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 10: 7:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.iol.ie (mail3.mail.iol.ie [194.125.2.194]) by hub.freebsd.org (Postfix) with ESMTP id 9BFBF14CBB for ; Tue, 7 Dec 1999 10:07:44 -0800 (PST) (envelope-from nick@iol.ie) Received: from beckett.earlsfort.iol.ie (beckett.earlsfort.iol.ie [194.125.21.2]) by mail.iol.ie Sendmail (v8.9.3) with ESMTP id SAA81200 for ; Tue, 7 Dec 1999 18:07:43 GMT Received: (from nick@localhost) by beckett.earlsfort.iol.ie Sendmail (v8.9.3) id SAA27365 for hackers@freebsd.org; Tue, 7 Dec 1999 18:08:59 GMT From: Nick Hilliard Message-Id: <199912071808.SAA27365@beckett.earlsfort.iol.ie> Subject: Re: [PATCHES] Two fixes for lpd/lpc for review and test To: hackers@freebsd.org Date: Tue, 7 Dec 1999 18:08:59 +0000 (GMT) X-NCC-RegID: ie.iol X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : Although with this crowd I'd probably have better luck with : something like: : "I have vmware running native on FreeBSD 3.2-release"... If anyone's interested, I have some patches to make the vmmon driver compile and load under 3.3, although it hangs the machine solid when vmware starts using it. Unfortunately, I don't have time to start debugging it any time soon due to workload. :-( Nick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 10:22: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id B1C5014D86 for ; Tue, 7 Dec 1999 10:21:58 -0800 (PST) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id KAA99479; Tue, 7 Dec 1999 10:20:28 -0800 (PST) From: Archie Cobbs Message-Id: <199912071820.KAA99479@bubba.whistle.com> Subject: Re: About divert socket In-Reply-To: from Witthaya Panichprechakorn at "Dec 7, 1999 09:32:08 am" To: b39wys@pluto.cpe.ku.ac.th (Witthaya Panichprechakorn) Date: Tue, 7 Dec 1999 10:20:27 -0800 (PST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Witthaya Panichprechakorn writes: > I use divert socket to captuer packets. I found that when > I capture a set of fragmented packets, there are 2 incoming reassembled > packets. The sin_port of sockaddr_in of the first packet is 0, > and of another packet is the port number, which it bound to. > However, when the packet is not fragmented, there is only one incoming > packet with sin_port of sockaddr_in equals to the port number, which it > bound to, similar to the second captured packet when framentation > occured. What is the actual process when a set of fragmented packets is > arrived? Why the system should divert two incoming packets? What version of FreeBSD? -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 11:30:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 51C7614DF3 for ; Tue, 7 Dec 1999 11:30:35 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id MAA43059; Tue, 7 Dec 1999 12:30:34 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA43539; Tue, 7 Dec 1999 12:30:34 -0700 (MST) Message-Id: <199912071930.MAA43539@harmony.village.org> To: Nick Hilliard Subject: Re: ejecting card with 3.3 causes hang ? Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Tue, 07 Dec 1999 01:11:00 GMT." <199912070111.BAA12774@beckett.earlsfort.iol.ie> References: <199912070111.BAA12774@beckett.earlsfort.iol.ie> Date: Tue, 07 Dec 1999 12:30:34 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Done in -current. I'll do for 3.4 before release. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 11:43:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id D9FDD14DD2; Tue, 7 Dec 1999 11:43:51 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id TAA23083; Tue, 7 Dec 1999 19:51:37 GMT (envelope-from dfr@nlsystems.com) Date: Tue, 7 Dec 1999 19:51:37 +0000 (GMT) From: Doug Rabson To: Stephen Hocking-Senior Programmer PGS Perth Cc: hackers@freebsd.org, multimedia@freebsd.org Subject: Re: Glide source available In-Reply-To: <199912062344.HAA18057@ariadne.prth.tensor.pgs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 7 Dec 1999, Stephen Hocking-Senior Programmer PGS Perth wrote: > > Go look at http://linux.3dfx.com/open_source > It's availabe for Voodoo 1, 2, & 3 cards. Register level specs too! I'm > utterly freaked out. Its pretty cool. I spent some time hacking the Voodoo2 sources today and I ported both the glide2x and glide3x libraries. I managed to run all the tests but haven't run anything substantial. Patches at: http://www.freebsd.org/~dfr/Glide-V2-2.53.diff http://www.freebsd.org/~dfr/Glide-V2-3.01.diff If someone can take these and maybe roll them into a couple of ports, I would be grateful. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 11:49:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 220AA15480; Tue, 7 Dec 1999 11:49:27 -0800 (PST) (envelope-from billf@chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 741971C2B; Tue, 7 Dec 1999 13:50:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id 6ED85381B; Tue, 7 Dec 1999 13:50:14 -0500 (EST) Date: Tue, 7 Dec 1999 13:50:14 -0500 (EST) From: Bill Fumerola To: Doug Rabson Cc: Stephen Hocking-Senior Programmer PGS Perth , hackers@freebsd.org, multimedia@freebsd.org Subject: Re: Glide source available In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 7 Dec 1999, Doug Rabson wrote: > Its pretty cool. I spent some time hacking the Voodoo2 sources today and I > ported both the glide2x and glide3x libraries. I managed to run all the > tests but haven't run anything substantial. Patches at: > > http://www.freebsd.org/~dfr/Glide-V2-2.53.diff > http://www.freebsd.org/~dfr/Glide-V2-3.01.diff > > If someone can take these and maybe roll them into a couple of ports, I > would be grateful. Hmmm. I bought my younger brother a Voodoo2 2000 PCI yesterday for his birthday. I think it's time to "help him install" it. -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 11:54:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id A406514D95; Tue, 7 Dec 1999 11:54:29 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id UAA23239; Tue, 7 Dec 1999 20:01:51 GMT (envelope-from dfr@nlsystems.com) Date: Tue, 7 Dec 1999 20:01:51 +0000 (GMT) From: Doug Rabson To: Peter Wemm Cc: Ed Hall , Matthew Dillon , "Jonathan M. Bresler" , kris@hub.freebsd.org, freebsd-hackers@freebsd.org Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-Reply-To: <19991207120139.869F01CC6@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 7 Dec 1999, Peter Wemm wrote: > Ed Hall wrote: > > : you wrote: > > : : I wrote: > > : :4) Using a different SCSI driver (Peter managed to get a driver from 4.0 > > : : hooked up under 3.3, and it survived two days of torture that would > > : : have toasted things within an hour using the stock driver; you'll have > > : : to ask him for details). > > : > > : Ed, this is great stuff! > > : > > : Are you sure about #4? Is that the same ncr.c driver or something > > : else? There are only a few differences between the 3.x and 4.x > > : /usr/src/sys/pci/ncr.c drivers. Which Peter, Peter Wemm? > > > > It was Peter Wemm. I may be misunderstanding just what he did--trying > > the 4.0 driver was just one several experiments he proposed and > > performed. And saying that it "worked" is provisional; two days of > > testing strongly suggests that it reduced the problem with 3.3 to > > acceptible levels for my application. Is it truly a "fix?" I don't > > know. > > > > -Ed > > I might add that others have found that using sym + fxp on the N440BX > motherboards didn't solve their problems, or moved the problem elsewhere, > eg: to the sbdrop() etc routines. One other interesting variable.. an ahc > + pn driver combination on a 440BX motherboard under -current in late may > 99 had the exact same problems we saw a number of times with ncr + fxp (ie: > sbdrop, sbflush, m_copym etc panics). The same motherboard with ahc + de or > fxp did not have the problems. > > In all cases the panics were extremely "strange". The original fxp+ncr > combination changed it's crash pattern when we put extra debugging in it to > sanity check and check conditions. The results varied from registers getting > clobbered (as though an interrupt happened and the trapframe on the stack got > changed by the interrupt handler and then returned with garbage contents in > some registers.. this is what seems to be happening in the fxp_add_rfabuf() > panics - %esi was getting loaded earlier on and when it got to do the > vtophys() it was zero. People have printed the contents of "rfa" on the stack > and seen garbage - in fact it's a register variable under normal circumstances. > Adding debugging caused it to be stored in the local variable rather than > being left in %esi, and then the panics moved elsewhere (!).) > > It had the markings of "something trashing something somewhere and then crashing > quite a bit later". :-( Has anyone tried fiddling with the latency timer on either fxp or ncr (or both)? -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 12:45:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from front6.grolier.fr (front6.grolier.fr [194.158.96.56]) by hub.freebsd.org (Postfix) with ESMTP id 4519514D49; Tue, 7 Dec 1999 12:45:42 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-104-226.villette.club-internet.fr [194.158.104.226]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id VAA17270; Tue, 7 Dec 1999 21:45:12 +0100 (MET) Date: Tue, 7 Dec 1999 23:10:39 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Peter Wemm Cc: Ed Hall , Matthew Dillon , "Jonathan M. Bresler" , kris@hub.freebsd.org, freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-Reply-To: <19991207120139.869F01CC6@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 7 Dec 1999, Peter Wemm wrote: > I might add that others have found that using sym + fxp on the N440BX > motherboards didn't solve their problems, or moved the problem elsewhere, > eg: to the sbdrop() etc routines. One other interesting variable.. an ah= c > + pn driver combination on a 440BX motherboard under -current in late may > 99 had the exact same problems we saw a number of times with ncr + fxp (i= e: > sbdrop, sbflush, m_copym etc panics). The same motherboard with ahc + de= or > fxp did not have the problems. (ncr || sym || ahc) && fxp =3D TRUE makes the fxp a better culprit. :-) If the corruption comes from some DMA from the BUS, then it may well have happened that some chip did grab some stale address or length value and did DMA inside the corresponding area. This may happen, for example if a BUS address is not passed atomically to a device, or for numerous other reasons. Note that for an atomicity problem, the chip could have been the cause by performing non DWORD access or have been victimized by a PCI transaction terminated with data between 2 DWORDS (note that in this latter case, something is wrong regarding alignement in memory). The 'link_addr' handling from the C code looks to me like some candidate such a atomicity problem for example, but since I donnot know of the fxp device this might be just a quite wrong idea from me.=20 > In all cases the panics were extremely "strange". The original fxp+ncr > combination changed it's crash pattern when we put extra debugging in it = to > sanity check and check conditions. The results varied from registers get= ting > clobbered (as though an interrupt happened and the trapframe on the stack= got > changed by the interrupt handler and then returned with garbage contents = in > some registers.. this is what seems to be happening in the fxp_add_rfabuf= () > panics - %esi was getting loaded earlier on and when it got to do the > vtophys() it was zero. Some DMA performed using some stale but valid address (a difference of less than 65536 against a valid address is unlikely to make the address invalid for example) may lead to similar effects, btw, since any register value comes from memory. > People have printed the contents of "rfa" on the stack > and seen garbage - in fact it's a register variable under normal circumst= ances. > Adding debugging caused it to be stored in the local variable rather than > being left in %esi, and then the panics moved elsewhere (!).) >=20 > It had the markings of "something trashing something somewhere and then c= rashing > quite a bit later". :-( G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 13:14:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 11DB014E72 for ; Tue, 7 Dec 1999 13:14:45 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 3C6571CC6; Wed, 8 Dec 1999 05:14:44 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Gerard Roudier Cc: Ed Hall , Matthew Dillon , "Jonathan M. Bresler" , kris@hub.freebsd.org, freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-Reply-To: Message from Gerard Roudier of "Tue, 07 Dec 1999 23:10:39 +0100." Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Wed, 08 Dec 1999 05:14:44 +0800 From: Peter Wemm Message-Id: <19991207211444.3C6571CC6@overcee.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Gerard Roudier wrote: > > > On Tue, 7 Dec 1999, Peter Wemm wrote: > > > I might add that others have found that using sym + fxp on the N440BX > > motherboards didn't solve their problems, or moved the problem elsewhere, > > eg: to the sbdrop() etc routines. One other interesting variable.. an ahc > > + pn driver combination on a 440BX motherboard under -current in late may > > 99 had the exact same problems we saw a number of times with ncr + fxp (ie: > > sbdrop, sbflush, m_copym etc panics). The same motherboard with ahc + de o r > > fxp did not have the problems. > > (ncr || sym || ahc) && fxp = TRUE makes the fxp a better culprit. :-) No no, ahc && fxp == FALSE. ahc && if_pn == TRUE. (or was true in june, on non-N440BX machines, with an *exact* match of a crash class the fxp && ncr machines were having in october). Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 13:33:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from penelope.skunk.org (penelope.skunk.org [208.133.204.51]) by hub.freebsd.org (Postfix) with ESMTP id 9458414E73 for ; Tue, 7 Dec 1999 13:33:52 -0800 (PST) (envelope-from ben@penelope.skunk.org) Received: from localhost (ben@localhost) by penelope.skunk.org (8.9.3/8.9.3) with ESMTP id QAA21024; Tue, 7 Dec 1999 16:41:29 -0500 (EST) Date: Tue, 7 Dec 1999 16:41:29 -0500 (EST) From: Ben Rosengart To: "Jordan K. Hubbard" Cc: Matthew Dillon , Dennis , hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-Reply-To: <945.944512678@zippy.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 6 Dec 1999, Jordan K. Hubbard wrote: > Many arguments about how we were holding up progress and that > volunteers were going to start wandering off to other *BSD projects > were raised, along with more dire predictions, and finally enough was > enough and we set a date by which all the late committers should get > their stuff in so that we could finally branch the sucker. We did so > and there was much rejoicing, at least up until now when various folks > felt compelled to creatively reinterpret history and turn an > "unconscionable delay" into a "precipitous rush to branch." I said at the time that 3.0 wasn't ready, and so did Greg Lehey, IIRC. It was he who said something to the effect that the so-called "beta testing" was actually integration testing. I didn't start recommending 3.x for production environments until after 3.2 came out and had taken enough pounding to give me some confidence in it. I'm not blaming anyone, nor am I saying that I would have run things better, but I *am* taking issue with the accusation of revisionism. -- Ben Rosengart UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 13:57:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 6F35D1542F for ; Tue, 7 Dec 1999 13:57:50 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id QAA10118 for ; Tue, 7 Dec 1999 16:57:04 -0500 (EST) Reply-To: Randell Jesup To: freebsd-hackers@freebsd.org Subject: Re: ELF & putting inode at the front of a file From: Randell Jesup Date: 07 Dec 1999 16:59:13 -0500 In-Reply-To: Matthew Dillon's message of "Mon, 6 Dec 1999 12:56:14 -0800 (PST)" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon writes: >:On Mon, 6 Dec 1999, Zhihui Zhang wrote: >:> I have modified FFS filesystem code to put the disk inode at the beginning >:> of a file, i.e, the logical block #0 of each file begins with 128 bytes of >:> its disk inode and the rest of it are file data. >: >:first question I have is, why? > > Good god, is he joking? Offsetting the entire file by 128 bytes will > break mmap() and make I/O extremely inefficient. Very true; though providing locality of the metadata and the beginning of the file has obvious benefits (and is used by many filesystems and experiments). (See below.) > Many filesystems over the years have mixed meta-data in the file data > blocks on disk only to remove it later on when it was found to destroy > performance. A good example of this is the Amiga's filesystem. The > Amiga's old filesystem was emminently recoverable because each data > block had a backpointer, but it was so inefficient due to all the copying > required that the updated filesystem removed the metadata so disk blocks > could be DMA'd directory into the buffer. Each block in OFS had a backpointer and a checksum; it was designed (apparently) for mass-storage systems that had no lower-level data integrity mechanisms. Amiga FFS (no relation to Unix FFS) removed all the data-block checksums and pointers, and as a result sequential file reads were able to run at close to raw disk bandwidth. (Direct destination DMA of reads/writes helps a lot here, and was used whenever possible - sector-unaligned IO's would commonly have only the head and tail go through the buffer cache; the middle portion would go direct to the user memory.) The big benefits to locality of meta & file data are to allow drive/driver caching to do sequential (or close to) reads in as large blocks as possible. There was a recent SigOS paper on a modified Unix filesystem that was designed to take advantage of modern disk systems, reduced the number of inode indirection levels, and changed the allocation patterns of data within cylinder groups. Looked nice. Ah, the days of multi-threaded (with co-routines) filesystems written in ultra-tight (for space) assembler, complete with co-routine- semaphores, and a built-in automatic fsck-equivalent. Not to mention file-locking and notification on file-modification (pretty cool, actually). Shudder. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 16:52:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 9B59C14C38 for ; Tue, 7 Dec 1999 16:52:29 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id TAA18913; Tue, 7 Dec 1999 19:51:43 -0500 (EST) Reply-To: Randell Jesup To: freebsd-hackers@freebsd.org, Matthew Dillon Subject: Re: ELF & putting inode at the front of a file From: Randell Jesup Date: 07 Dec 1999 19:53:51 -0500 In-Reply-To: Matthew Dillon's message of "Mon, 6 Dec 1999 16:46:36 -0800 (PST)" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon writes: >:> distribute the inodes all over the cylinder group rather then concentrate >:> all the inodes in one place. >: >:Yes. I have implemented most of the code. I noticed the "ls -al" is slow >:but "ls" is OK. > > Yes, ls (without any options) is ok because the file type is now being > stuffed in the directory entry, allowing ls (without any options) to > avoid stat()ing the file. Interesting - I made a similar mechanism in a hash-chain-based filesystem to speed up directory listings; by storing all the commonly accessed information about a file in the directory in a compressed format, thus avoiding fetching the fileheader (inode) block for every file. The speedup was impressive; I think I was getting 7-25 entries per 512-byte sector; including just all ls -l information. The downside was increased overhead on file-close-after-modify and create/delete, but not a lot. As a side-benefit, recovery after a trashed FS is slightly easier since there's more redundant information available (if the main directory sector/inode gets whacked). -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 18: 7:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from screech.weirdnoise.com (209-128-78-198.bayarea.net [209.128.78.198]) by hub.freebsd.org (Postfix) with ESMTP id B8C0614FEC; Tue, 7 Dec 1999 18:07:06 -0800 (PST) (envelope-from edhall@screech.weirdnoise.com) Received: from screech.weirdnoise.com (localhost [127.0.0.1]) by screech.weirdnoise.com (8.8.7/8.8.7) with ESMTP id SAA11430; Tue, 7 Dec 1999 18:08:08 -0800 Message-Id: <199912080208.SAA11430@screech.weirdnoise.com> X-Mailer: exmh version 2.0.2 To: Peter Wemm Cc: Matthew Dillon , "Jonathan M. Bresler" , kris@hub.freebsd.org, freebsd-hackers@FreeBSD.ORG Date: Tue, 07 Dec 1999 18:08:08 -0800 From: Ed Hall Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-Reply-To: Your message of "Tue, 07 Dec 1999 20:01:39 +0800." <19991207120139.869F01CC6@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii -------- I just reviewed the (so far) working 3.3 test system. I was mistaken about the 4.0 driver; looks like you didn't get around to that. You have a wrapper around ncr_intr() that sets up guard areas--and a call to splcam() that might well be what's stabilizing things. Here are the diffs (preceded by the CVS ident string): ** $FreeBSD: src/sys/pci/ncr.c,v 1.141.2.4 1999/08/29 16:31:53 peter Exp $ % diff /tmp/ncr.c ncr.c *** /tmp/ncr.c Tue Dec 7 15:37:50 1999 --- ncr.c Thu Oct 28 11:41:56 1999 *************** *** 3314,3319 **** --- 3314,3325 ---- found = -1; for (i = 0; i < sizeof(ncr_chip_table)/sizeof(ncr_chip_table[0]); i++) { + /* + * Ignore chips that support LOAD/STORE, so the sym_hipd driver will + * attach them without any conflict. + */ + if (ncr_chip_table[i].features & FE_LDSTR) + continue; if (device_id == ncr_chip_table[i].device_id && ncr_chip_table[i].minrevid <= revision_id) { if (found < 0 || *************** *** 3872,3883 **** **========================================================== */ static void ! ncr_intr(vnp) void *vnp; { ncb_p np = vnp; - int oldspl = splcam(); if (DEBUG_FLAGS & DEBUG_TINY) printf ("["); --- 3878,3890 ---- **========================================================== */ + int ncr_int_count = 0; + static void ! ncr_intr1(vnp) void *vnp; { ncb_p np = vnp; if (DEBUG_FLAGS & DEBUG_TINY) printf ("["); *************** *** 3893,3900 **** }; if (DEBUG_FLAGS & DEBUG_TINY) printf ("]\n"); ! splx (oldspl); } /*========================================================== --- 3900,3932 ---- }; if (DEBUG_FLAGS & DEBUG_TINY) printf ("]\n"); + } + + #define GUARDS 16 ! static void ! ncr_intr(vnp) ! void *vnp; ! { ! int i; ! int clobber; ! int guard[GUARDS]; ! ! clobber = 0; ! for (i = 0; i < GUARDS; i++) ! guard[i] = 0xcafebabe; ! ! ncr_int_count++; ! ncr_intr1(vnp); ! ! for (i = 0; i < GUARDS; i++) { ! if (guard[i] != 0xcafebabe) { ! printf("guard[%d] = 0x%x\n", i, guard[i]); ! clobber++; ! } ! } ! if (clobber != 0) ! panic("ncr_intr: stack clobber 0x%x\n", clobber); } /*========================================================== *************** *** 4878,4884 **** --- 4910,4920 ---- static void ncr_poll(struct cam_sim *sim) { + int oldspl; + + oldspl = splcam(); ncr_intr(cam_sim_softc(sim)); + splx(oldspl); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 19:10:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dustdevil.waterspout.com (dustdevil.waterspout.com [208.13.60.151]) by hub.freebsd.org (Postfix) with ESMTP id 528DF14C8F for ; Tue, 7 Dec 1999 19:10:46 -0800 (PST) (envelope-from csg@waterspout.com) Received: by dustdevil.waterspout.com (Postfix, from userid 1000) id DFCF29F; Tue, 7 Dec 1999 22:13:39 -0500 (EST) Received: from waterspout.com (localhost [127.0.0.1]) by dustdevil.waterspout.com (Postfix) with ESMTP id DD208BAB8 for ; Tue, 7 Dec 1999 22:13:39 -0500 (EST) To: freebsd-hackers@freebsd.org From: "C. Stephen Gunn" Subject: Upgrading rdist to v6.1.5 in -CURRENT? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <51758.944622814.1@waterspout.com> Date: Tue, 07 Dec 1999 22:13:34 -0500 Message-Id: <19991208031339.DFCF29F@dustdevil.waterspout.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Since rdist 6.1.5 is back under a BSD Style license, should we work towards updating it in -CURRENT, and perhaps -STABLE. It has several bug fixes and enhancements to the current supplied rdist. I'm preparing a recipe to save someone some work on importing it into /usr/src/contrib, and build rdist/rdistd in /usr/src/usr.bin. I'll send-pr the recipe, and post a reference here when I document how I worked around some of the magnicomp guys's kludged makefiles/includes. Comments? Suggestions? Discussion? - Steve -- C. Stephen Gunn URL: http://www.waterspout.com/ WaterSpout Communications, Inc. Email: csg@waterspout.com 427 North 6th Street Phone: +1 765.742.6628 Lafayette, IN 47901 Fax: +1 765.742.0646 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 20: 6: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by hub.freebsd.org (Postfix) with ESMTP id 8777B14D1B for ; Tue, 7 Dec 1999 20:05:58 -0800 (PST) (envelope-from vsilyaev@mindspring.com) Received: from mindspring.com (user-2iniie3.dialup.mindspring.com [165.121.73.195]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id XAA08548; Tue, 7 Dec 1999 23:05:56 -0500 (EST) Received: (from vsilyaev@localhost) by mindspring.com (8.9.3/8.9.3) id XAA06776; Tue, 7 Dec 1999 23:05:48 -0500 (EST) (envelope-from vsilyaev) Date: Tue, 7 Dec 1999 23:05:47 -0500 From: "Vladimir N. Silyaev" To: Ville-Pertti Keinonen Cc: "Vladimir N. Silyaev" , hackers@freebsd.org Subject: Re: vmnet (was: Linux ioctl not implemented error) Message-ID: <19991207230546.A6719@jupiter.delta.ny.us> References: <19991202160515.C536@jupiter.delta.ny.us> <19991202223604.B5379@jupiter.delta.ny.us> <86so1ekcxq.fsf@not.demophon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <86so1ekcxq.fsf@not.demophon.com>; from will@iki.fi on Tue, Dec 07, 1999 at 05:06:41PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Dec 07, 1999 at 05:06:41PM +0200, Ville-Pertti Keinonen wrote: > > are need to have steal nerves. I fill that, at the time when I was porting > > vmware. I have too much hours of very interested work - load driver, launch > > vmware and then looking into the DDB double fault screen. Reload box, > > and then again. > > I suppose that the incomplete virtualization of the x86 prevents you > from running vmware on FreeBSD on vmware on Linux for debugging? Yes, exactly. The VMware web site have a warning like this 'even don't try to run VMware on VMware guest, this don't work, and may be lock our computer'. But the vmware vmmon driver have some footprint of code, to support such thing in the special VMware version. But at any case, in the last night I have a success with FreeBSD version of the vmnet driver, see announce in emulation. -- Vladimir Silyaev To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 20:20: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by hub.freebsd.org (Postfix) with ESMTP id 639C714F40 for ; Tue, 7 Dec 1999 20:19:54 -0800 (PST) (envelope-from vsilyaev@mindspring.com) Received: from mindspring.com (user-2iniie3.dialup.mindspring.com [165.121.73.195]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id XAA17373 for ; Tue, 7 Dec 1999 23:19:52 -0500 (EST) Received: (from vsilyaev@localhost) by mindspring.com (8.9.3/8.9.3) id XAA06802 for hackers@freebsd.org; Tue, 7 Dec 1999 23:19:50 -0500 (EST) (envelope-from vsilyaev) Date: Tue, 7 Dec 1999 23:19:49 -0500 From: "Vladimir N. Silyaev" To: hackers@freebsd.org Subject: FreeBSD-i386 and GS selector register Message-ID: <19991207231949.B6719@jupiter.delta.ny.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi I have the next question. The FreeBSD on i386 don't use GS register, even kernel DDB don't show it. And at the time when kernel loaded and operational GS didn't initialized yet and have some garbage value (something like 0x1f, i.e. pointed to the LDT). But because no one don't touch that all working fine. Question. The some driver had code like this: push %gs <--- OK 0x1f saved on the stack ... call do_big_deal ... pop %gs <--- Restore 0x1f and have a fault, probably Double Fault I can't change that code. When I found this problem, I did simple hack, before call that code I'm clear GS. But I want to know may be exist a better solution? -- Vladimir Silyaev To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 21:53:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id 6275C15197 for ; Tue, 7 Dec 1999 21:53:52 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id AAA03932; Wed, 8 Dec 1999 00:53:51 -0500 (EST) (envelope-from luoqi) Date: Wed, 8 Dec 1999 00:53:51 -0500 (EST) From: Luoqi Chen Message-Id: <199912080553.AAA03932@lor.watermarkgroup.com> To: hackers@FreeBSD.ORG, vsilyaev@mindspring.com Subject: Re: FreeBSD-i386 and GS selector register Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi > > I have the next question. > The FreeBSD on i386 don't use GS register, even kernel DDB don't show > it. And at the time when kernel loaded and operational GS didn't > initialized yet and have some garbage value (something like 0x1f, i.e. > pointed to the LDT). But because no one don't touch that all working fine. > 0x1f is not garbage, it's (FreeBSD) standard user data segment. > Question. > The some driver had code like this: > push %gs <--- OK 0x1f saved on the stack > ... > call do_big_deal > ... > pop %gs <--- Restore 0x1f and have a fault, probably Double Fault > It could only be that the driver code changed the LDT descriptor and didn't restore it upon return. > I can't change that code. When I found this problem, I did simple hack, > before call that code I'm clear GS. But I want to know may be exist > a better solution? > > -- > Vladimir Silyaev > -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 7 22:49:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by hub.freebsd.org (Postfix) with ESMTP id 9A959154D2 for ; Tue, 7 Dec 1999 22:49:10 -0800 (PST) (envelope-from vsilyaev@mindspring.com) Received: from mindspring.com (user-2iniie3.dialup.mindspring.com [165.121.73.195]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id BAA21584; Wed, 8 Dec 1999 01:49:07 -0500 (EST) Received: (from vsilyaev@localhost) by mindspring.com (8.9.3/8.9.3) id BAA07596; Wed, 8 Dec 1999 01:49:06 -0500 (EST) (envelope-from vsilyaev) Date: Wed, 8 Dec 1999 01:49:05 -0500 From: "Vladimir N. Silyaev" To: Luoqi Chen Cc: hackers@FreeBSD.ORG, vsilyaev@mindspring.com Subject: Re: FreeBSD-i386 and GS selector register Message-ID: <19991208014905.A7546@jupiter.delta.ny.us> References: <199912080553.AAA03932@lor.watermarkgroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <199912080553.AAA03932@lor.watermarkgroup.com>; from luoqi@watermarkgroup.com on Wed, Dec 08, 1999 at 12:53:51AM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Dec 08, 1999 at 12:53:51AM -0500, Luoqi Chen wrote: > > I have the next question. > > The FreeBSD on i386 don't use GS register, even kernel DDB don't show > > it. And at the time when kernel loaded and operational GS didn't > > initialized yet and have some garbage value (something like 0x1f, i.e. > > pointed to the LDT). But because no one don't touch that all working fine. > > > 0x1f is not garbage, it's (FreeBSD) standard user data segment. Small mistake not 0x1f, but 0x2f, at any case it doesn't mean. About standard registers, I think you are mean user space? I wrote simple kld, and obtain the next results: ldt = 0x0028 gs = 0x0000002f, ds = 0x00000010 And also others selectors such as fs, cs, ss and es pointed to GTD. Only gs has a different case (doesn't change its value when a context switched). > > Question. > > The some driver had code like this: > > push %gs <--- OK 0x1f saved on the stack > > ... > > call do_big_deal > > ... > > pop %gs <--- Restore 0x1f and have a fault, probably Double Fault > > > It could only be that the driver code changed the LDT descriptor and didn't > restore it upon return. Oh, Exactly, you are right. Thanks! That code clear ldt, other selectors restored ok, but not gs. Before I think, that in the kernel ldt has a null value, and never tried to test it. -- Vladimir Silyaev To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 0: 1:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id B3C221502F; Wed, 8 Dec 1999 00:01:07 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id BAA45115; Wed, 8 Dec 1999 01:01:06 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id BAA02405; Wed, 8 Dec 1999 01:01:04 -0700 (MST) Message-Id: <199912080801.BAA02405@harmony.village.org> To: Atsushi Onoe Subject: Re: Newer pccard code Cc: mobile@FreeBSD.ORG, hackers@FreeBSD.ORG Reply-To: hackers@FreeBSD.ORG In-reply-to: Your message of "Wed, 08 Dec 1999 16:40:26 +0900." <199912080740.QAA00615@duplo.sm.sony.co.jp> References: <199912080740.QAA00615@duplo.sm.sony.co.jp> <199912080639.XAA01861@harmony.village.org> Date: Wed, 08 Dec 1999 01:01:04 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [[ I had observed that if_detach seemed to cause problems in the pccard code after the device had gone away. Redirected to -hackers since I think is where hairy network stuff is dealt with. --imp ]] In message <199912080740.QAA00615@duplo.sm.sony.co.jp> Atsushi Onoe writes: : There are some inconsistency of two TAILQs: : ifp->if_addrhead struct ifaddr : in_ifaddrhead struct in_ifaddr : : Both these two list are managed in in_control (netinet/in.c). : In case of removing pccard, if_detach() only cares about ifp->if_addrhead, : and the corresponding in_ifaddr entry in in_ifaddrhead is not removed. : Since free'd ifaddr is still referenced by in_ifaddr, : it will be the reason of possible crash or lock up by looped list. : : I'm not sure how to fix this, but if_detach() should not remove : ifaddr from ifp->if_addrhead, and should ask protocol specific layer : to delete all addresses through if_ioctl(). SIOCFIFADDR? I'll leave this one to those more skilled at the network layer than I am. I don't know the network layer that well right now. I did observe that I didn't get any more crashes after disabling my use of DHCP to get an address. Likely that was the dangling reference that cause me grief. dhcp uses bpf, which is likely the reference in question. W/o dhcp, I was able to insert/remove the card 4 times w/o a problem, where before doing it twice would alway give a crash. The machine was stable enough to then make the commits to -current from, which never has been the case before. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 2:18:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 7181214C57; Wed, 8 Dec 1999 02:18:06 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id KAA59155; Wed, 8 Dec 1999 10:25:57 GMT (envelope-from dfr@nlsystems.com) Date: Wed, 8 Dec 1999 10:25:57 +0000 (GMT) From: Doug Rabson To: Stephen Hocking-Senior Programmer PGS Perth Cc: hackers@freebsd.org, multimedia@freebsd.org Subject: Re: Glide source available In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 7 Dec 1999, Doug Rabson wrote: > On Tue, 7 Dec 1999, Stephen Hocking-Senior Programmer PGS Perth wrote: > > > > > Go look at http://linux.3dfx.com/open_source > > It's availabe for Voodoo 1, 2, & 3 cards. Register level specs too! I'm > > utterly freaked out. > > Its pretty cool. I spent some time hacking the Voodoo2 sources today and I > ported both the glide2x and glide3x libraries. I managed to run all the > tests but haven't run anything substantial. Patches at: > > http://www.freebsd.org/~dfr/Glide-V2-2.53.diff > http://www.freebsd.org/~dfr/Glide-V2-3.01.diff > > If someone can take these and maybe roll them into a couple of ports, I > would be grateful. I just remembered that a couple of files are missing from the 3.01 diff. I'll regenerate that today. To build 2.53, you will need gasp. I added gasp to the build yesterday but I mucked it up. I'll fix that too shortly and you will be able to install gasp by 'make all install' in src/gnu/usr.bin/binutils followed by src/usr.bin/objformat (which I also forgot to commit). -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 5:45:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 130CD14EF5 for ; Wed, 8 Dec 1999 05:45:42 -0800 (PST) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (cs1-gw.cs.binghamton.edu [128.226.171.72]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with SMTP id IAA26563; Wed, 8 Dec 1999 08:45:35 -0500 (EST) Date: Wed, 8 Dec 1999 07:32:30 -0500 (EST) From: Zhihui Zhang To: Randell Jesup Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ELF & putting inode at the front of a file In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The big benefits to locality of meta & file data are to allow > drive/driver caching to do sequential (or close to) reads in as large > blocks as possible. There was a recent SigOS paper on a modified Unix > filesystem that was designed to take advantage of modern disk systems, Do you still remember the title of that paper and tell me where can I find it (preferebly online)? -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 5:54:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pak2.texar.com (pak2.texar.com [216.208.160.130]) by hub.freebsd.org (Postfix) with ESMTP id 138801550D for ; Wed, 8 Dec 1999 05:54:51 -0800 (PST) (envelope-from dseg@pak2.texar.com) Received: from localhost (dseg@localhost) by pak2.texar.com (8.9.2/8.8.3) with ESMTP id IAA56826; Wed, 8 Dec 1999 08:53:59 -0500 (EST) Date: Wed, 8 Dec 1999 08:53:59 -0500 (EST) From: Dan Seguin To: Andrzej Bialecki Cc: Arun Sharma , freebsd-hackers@FreeBSD.ORG Subject: Re: Fwd: Re: kstat - an API for gathering kernel stats In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is it possible to make nodes dynamically that are immutable from userland (even by root), but modifyable from the kernel? On Mon, 29 Nov 1999, Andrzej Bialecki wrote: > > Yes. See for example linux emulator or my SPY module: > > http://www.freebsd.org/~abial/spy > > You can also create whole new branches, as the second example shows. > > Andrzej Bialecki > > // WebGiro AB, Sweden (http://www.webgiro.com) > // ------------------------------------------------------------------- > // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- > // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- -------------------------------------------------------------------------------- Dan Seguin Texar Software, Corporation. Visit us at the RSA Conference 2000, January 16-20, San Jose, Booth # 1241 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 7: 0:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tardis.patho.gen.nz (tardis.patho.gen.nz [203.97.2.226]) by hub.freebsd.org (Postfix) with ESMTP id 06C3814C92 for ; Wed, 8 Dec 1999 07:00:26 -0800 (PST) (envelope-from jabley@tardis.patho.gen.nz) Received: (from jabley@localhost) by tardis.patho.gen.nz (8.9.3/8.9.3) id EAA09591; Thu, 9 Dec 1999 04:00:18 +1300 (NZDT) Date: Thu, 9 Dec 1999 04:00:17 +1300 From: Joe Abley To: "C. Stephen Gunn" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Upgrading rdist to v6.1.5 in -CURRENT? Message-ID: <19991209040013.A20245@patho.gen.nz> References: <19991208031339.DFCF29F@dustdevil.waterspout.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <19991208031339.DFCF29F@dustdevil.waterspout.com>; from csg@waterspout.com on Tue, Dec 07, 1999 at 10:13:34PM -0500 X-Files: the Truth is Out There Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Dec 07, 1999 at 10:13:34PM -0500, C. Stephen Gunn wrote: > Since rdist 6.1.5 is back under a BSD Style license, should we work > towards updating it in -CURRENT, and perhaps -STABLE. It has several > bug fixes and enhancements to the current supplied rdist. Yaay. That's a good thing. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 7:42:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpha.netvision.net.il (alpha.netvision.net.il [194.90.1.13]) by hub.freebsd.org (Postfix) with ESMTP id 2029815172; Wed, 8 Dec 1999 07:42:34 -0800 (PST) (envelope-from danhil@cwnt.com) Received: from unspecified.host (ras3-p201.hfa.netvision.net.il [62.0.147.201]) by alpha.netvision.net.il (8.9.3/8.8.6) with SMTP id RAA00283; Wed, 8 Dec 1999 17:42:29 +0200 (IST) Received: from 192.168.0.46 ([192.168.0.46]) by 192.168.0.1 (WinRoute 3.04g) with SMTP; Wed, 8 Dec 1999 17:40:15 +0200 Message-ID: <060901bf4192$926e8350$2e00a8c0@cwnt.co.il> From: "Daniel Hilevich" To: , Subject: Use of the ppi interface Date: Wed, 8 Dec 1999 17:40:36 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0606_01BF41A3.55F138D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0606_01BF41A3.55F138D0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, I'm using the parallel port to control some sort of a hardware (i2c). = For that I generate pulses using the ppi device (geek port). The problem = is that in some cases, the pulse isn't generated. What I do is sending = an ioctl to make the device high (1) and another ioctl to set the device = low (0). It seems that in some cases, the two commands arrive together = to the device so the pulse isn't wide enough. Does the ppbus layer stores the ioctl's in some sort of a buffer and = than flushes its content to the hardware? If so, is there a way to control it? The pulses should be in fixed size, so any other idea will be welcomed. Thanx,=20 --- Daniel Hilevich mailto:danhil@cwnt.com=20 Tel: +972-4-9592203 ext. 214 Charlotte's Web Networks LTD.=20 http://www.cwnt.com ------=_NextPart_000_0606_01BF41A3.55F138D0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
Hi,
I'm using the parallel port = to control=20 some sort of a hardware (i2c). For that I generate pulses using the ppi = device=20 (geek port). The problem is that in some cases, the pulse isn't=20 generated. What I do is sending an ioctl to make the device high = (1) and=20 another ioctl to set the device low (0). It seems that in some cases, = the two=20 commands arrive together to the device so the pulse isn't wide=20 enough.
Does the ppbus layer stores = the ioctl's=20 in some sort of a buffer and than flushes its content to the=20 hardware?
If so, is there a way to = control=20 it?
The=20 pulses should be in fixed size, so any other idea will be=20 welcomed.
Thanx, 
---
Daniel Hilevich mailto:danhil@cwnt.com
Tel:=20 +972-4-9592203  ext. 214
Charlotte's Web Networks LTD.
http://www.cwnt.com
------=_NextPart_000_0606_01BF41A3.55F138D0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 7:59: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 608) id BEAE414C10; Wed, 8 Dec 1999 07:59:05 -0800 (PST) From: "Jonathan M. Bresler" To: zzhang@cs.binghamton.edu Cc: rjesup@wgate.com, freebsd-hackers@FreeBSD.ORG In-reply-to: (message from Zhihui Zhang on Wed, 8 Dec 1999 07:32:30 -0500 (EST)) Subject: Re: ELF & putting inode at the front of a file Message-Id: <19991208155905.BEAE414C10@hub.freebsd.org> Date: Wed, 8 Dec 1999 07:59:05 -0800 (PST) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > The big benefits to locality of meta & file data are to allow > > drive/driver caching to do sequential (or close to) reads in as large > > blocks as possible. There was a recent SigOS paper on a modified Unix > > filesystem that was designed to take advantage of modern disk systems, > > Do you still remember the title of that paper and tell me where can I find > it (preferebly online)? > > -Zhihui Author: Gregory R. Ganger Author: M. Frans Kaashoek Title: Embedded Inodes and Explicit Grouping: Exploiting Disk Bandwidth for Small Files Pages: 1-17 Publisher: USENIX Proceedings: 1997 Annual Technical Conference Date: January 6-10, 1997 Location: Anaheim, CA Institution: MIT available to usenix members in the online lirary at https://www.usenix.org//publications/publications.html. jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 8: 4: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mimer.webgiro.com (mimer.webgiro.com [212.209.29.5]) by hub.freebsd.org (Postfix) with ESMTP id C3DEE14C10 for ; Wed, 8 Dec 1999 08:03:56 -0800 (PST) (envelope-from abial@webgiro.com) Received: by mimer.webgiro.com (Postfix, from userid 66) id E2F4D2DC0A; Wed, 8 Dec 1999 17:04:46 +0100 (CET) Received: by mx.webgiro.com (Postfix, from userid 1001) id 100807811; Wed, 8 Dec 1999 17:01:09 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mx.webgiro.com (Postfix) with ESMTP id 0D89F10E10; Wed, 8 Dec 1999 17:01:09 +0100 (CET) Date: Wed, 8 Dec 1999 17:01:09 +0100 (CET) From: Andrzej Bialecki To: Dan Seguin Cc: Arun Sharma , freebsd-hackers@FreeBSD.ORG Subject: Re: Fwd: Re: kstat - an API for gathering kernel stats In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 8 Dec 1999, Dan Seguin wrote: > > Is it possible to make nodes dynamically that are immutable from userland > (even by root), but modifyable from the kernel? Yes, of course. Just mark them as read-only (CTLFLAG_RD). You are free to assign any value to them within the kernel. If it's more complex type handled with SYSCTL_PROC (like eg. vm.zone sysctl) you still can decide what value you return from kernel, and you can ignore any requests to assign new values. > > On Mon, 29 Nov 1999, Andrzej Bialecki wrote: > > > > > Yes. See for example linux emulator or my SPY module: > > > > http://www.freebsd.org/~abial/spy > > > > You can also create whole new branches, as the second example shows. > > > > Andrzej Bialecki > > > > // WebGiro AB, Sweden (http://www.webgiro.com) > > // ------------------------------------------------------------------- > > // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- > > // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- > > > > -------------------------------------------------------------------------------- > Dan Seguin Texar Software, Corporation. > > Visit us at the RSA Conference 2000, January 16-20, San Jose, Booth # 1241 > > > > Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 8:33:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from c62443-a.frmt1.sfba.home.com (c62443-a.frmt1.sfba.home.com [24.0.69.165]) by hub.freebsd.org (Postfix) with ESMTP id 5A81B14D12 for ; Wed, 8 Dec 1999 08:33:50 -0800 (PST) (envelope-from adsharma@c62443-a.frmt1.sfba.home.com) Received: (from adsharma@localhost) by c62443-a.frmt1.sfba.home.com (8.9.3/8.9.3) id IAA29838; Wed, 8 Dec 1999 08:33:48 -0800 Date: Wed, 8 Dec 1999 08:33:48 -0800 From: Arun Sharma To: Andrzej Bialecki Cc: freebsd-hackers@freebsd.org Subject: Re: Fwd: Re: kstat - an API for gathering kernel stats Message-ID: <19991208083348.A29811@sharmas.dhs.org> References: <199911290505.VAA01931@c62443-a.frmt1.sfba.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Andrzej Bialecki on Mon, Nov 29, 1999 at 10:09:35AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Nov 29, 1999 at 10:09:35AM +0100, Andrzej Bialecki wrote: > > I was thinking about implementing SMP cpu stats using sysctl today and > > I have a question - can I create sysctl nodes dynamically ? > > > > i.e. > > > > for (cpu = 0; cpu < get_num_cpus(); cpu++) { > > /* create sysctl node here ? */ > > } > > Yes. See for example linux emulator or my SPY module: > > http://www.freebsd.org/~abial/spy > > You can also create whole new branches, as the second example shows. Thanks - that was useful. However, I noticed that only the leaves (SYSCTL_INT/LONG/STRING) etc can be dynamically created. But nodes can't be dynamically created. Am I correct ? I'm interested in doing something like: kern.stats.cpu0.idle kern.stats.cpu0.nice ... kern.stats.cpu1.idle kern.stats.cpu1.nice ... and I want the nodes cpu0, cpu1 etc dynamically created. But that's no big deal. I'll define 4 cpus for now and zero the values for non-existent cpus. -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 8:43:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mimer.webgiro.com (mimer.webgiro.com [212.209.29.5]) by hub.freebsd.org (Postfix) with ESMTP id BCF7215658 for ; Wed, 8 Dec 1999 08:43:53 -0800 (PST) (envelope-from abial@webgiro.com) Received: by mimer.webgiro.com (Postfix, from userid 66) id 03B9B2DC07; Wed, 8 Dec 1999 17:44:45 +0100 (CET) Received: by mx.webgiro.com (Postfix, from userid 1001) id 366547811; Wed, 8 Dec 1999 17:44:34 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mx.webgiro.com (Postfix) with ESMTP id 30F1610E10; Wed, 8 Dec 1999 17:44:34 +0100 (CET) Date: Wed, 8 Dec 1999 17:44:31 +0100 (CET) From: Andrzej Bialecki To: Arun Sharma Cc: freebsd-hackers@freebsd.org Subject: Re: Fwd: Re: kstat - an API for gathering kernel stats In-Reply-To: <19991208083348.A29811@sharmas.dhs.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 8 Dec 1999, Arun Sharma wrote: > On Mon, Nov 29, 1999 at 10:09:35AM +0100, Andrzej Bialecki wrote: > > > I was thinking about implementing SMP cpu stats using sysctl today and > > > I have a question - can I create sysctl nodes dynamically ? > > > > > > i.e. > > > > > > for (cpu = 0; cpu < get_num_cpus(); cpu++) { > > > /* create sysctl node here ? */ > > > } > > > > Yes. See for example linux emulator or my SPY module: > > > > http://www.freebsd.org/~abial/spy > > > > You can also create whole new branches, as the second example shows. > > Thanks - that was useful. However, I noticed that only the leaves > (SYSCTL_INT/LONG/STRING) etc can be dynamically created. But nodes > can't be dynamically created. Am I correct ? Erhm.. No. Look closer at the SPY module. I create the whole branch from the root level. In the standard system there is no such thing as "kld" node, neither there is a "spy" node. I created both of them. Only then I created a bunch of leaves (of course, nothing stops you from creating some more leaves on each intermediate level, if you need them). The same is with linux emulator. It creates "compat" node, then "linux" node, and then a couple of sysctls. Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 8:48:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from c62443-a.frmt1.sfba.home.com (c62443-a.frmt1.sfba.home.com [24.0.69.165]) by hub.freebsd.org (Postfix) with ESMTP id BBAFF14C10 for ; Wed, 8 Dec 1999 08:48:37 -0800 (PST) (envelope-from adsharma@c62443-a.frmt1.sfba.home.com) Received: (from adsharma@localhost) by c62443-a.frmt1.sfba.home.com (8.9.3/8.9.3) id IAA29862; Wed, 8 Dec 1999 08:48:36 -0800 Date: Wed, 8 Dec 1999 08:48:36 -0800 From: Arun Sharma To: Andrzej Bialecki Cc: freebsd-hackers@freebsd.org Subject: Re: Fwd: Re: kstat - an API for gathering kernel stats Message-ID: <19991208084835.A29855@sharmas.dhs.org> References: <19991208083348.A29811@sharmas.dhs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Andrzej Bialecki on Wed, Dec 08, 1999 at 05:44:31PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Dec 08, 1999 at 05:44:31PM +0100, Andrzej Bialecki wrote: > On Wed, 8 Dec 1999, Arun Sharma wrote: > Erhm.. No. > > Look closer at the SPY module. I create the whole branch from the root > level. In the standard system there is no such thing as "kld" node, > neither there is a "spy" node. I created both of them. Only then I created > a bunch of leaves (of course, nothing stops you from creating some more > leaves on each intermediate level, if you need them). Given a number N, whose value is determined at run time, could you have created N kld nodes ? -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 10:13: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id B88A715798 for ; Wed, 8 Dec 1999 10:12:55 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA37897; Wed, 8 Dec 1999 09:21:52 -0800 (PST) (envelope-from dillon) Date: Wed, 8 Dec 1999 09:21:52 -0800 (PST) From: Matthew Dillon Message-Id: <199912081721.JAA37897@apollo.backplane.com> To: freebsd-hackers@freebsd.org Subject: Getting a new MAP_ flag into mmap() prior to 4.x freeze Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I would like to add a new MAP_ flag to mmap() prior to the 4.x freeze. The purpose of the flag is to prevent the syncer from syncing the file underlying the map. The VM system will still page to the file as needed and, of course, the data will remain consistent with the file. This will allow normal files to be used to back (for example) shared memory without incuring the extra overhead that sync causes every 30 seconds. Currently it is not possible to use normal files in this fashion (verses using MAP_ANON, for which sharability is limited, or SysV shared memory which often has unexpected limitations) and still have an efficient system. The flag will be called MAP_NOSYNC Operationally, the syncer will not sync the file while any mmap()'s exist with that flag set. Once such flagged maps go away, the syncer will be able to sync the file (if it still exists). Comments are welcome. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 10:24: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from penelope.skunk.org (penelope.skunk.org [208.133.204.51]) by hub.freebsd.org (Postfix) with ESMTP id 4FD1E14C04 for ; Wed, 8 Dec 1999 10:23:53 -0800 (PST) (envelope-from ben@penelope.skunk.org) Received: from localhost (ben@localhost) by penelope.skunk.org (8.9.3/8.9.3) with ESMTP id NAA28047; Wed, 8 Dec 1999 13:32:40 -0500 (EST) Date: Wed, 8 Dec 1999 13:32:39 -0500 (EST) From: Ben Rosengart To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Getting a new MAP_ flag into mmap() prior to 4.x freeze In-Reply-To: <199912081721.JAA37897@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 8 Dec 1999, Matthew Dillon wrote: > Operationally, the syncer will not sync the file while any mmap()'s > exist with that flag set. Once such flagged maps go away, the syncer > will be able to sync the file (if it still exists). > > Comments are welcome. I assume that this flag would require write permission to the file, to prevent bad security implications? -- Ben Rosengart UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 10:26:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dustdevil.waterspout.com (fourier.physics.purdue.edu [128.210.146.43]) by hub.freebsd.org (Postfix) with ESMTP id 7FA9315821 for ; Wed, 8 Dec 1999 10:23:57 -0800 (PST) (envelope-from csg@waterspout.com) Received: by dustdevil.waterspout.com (Postfix, from userid 1000) id 5774A59; Wed, 8 Dec 1999 13:26:56 -0500 (EST) Date: Wed, 8 Dec 1999 13:26:56 -0500 From: "C. Stephen Gunn" To: Joe Abley Cc: freebsd-hackers@freebsd.org Subject: Re: Upgrading rdist to v6.1.5 in -CURRENT? Message-ID: <19991208132656.A54455@dustdevil.waterspout.com> References: <19991208031339.DFCF29F@dustdevil.waterspout.com> <19991209040013.A20245@patho.gen.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <19991209040013.A20245@patho.gen.nz> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Dec 09, 1999 at 04:00:17AM +1300, Joe Abley wrote: > Yaay. That's a good thing. There had been some discussion and concern about the protocol incompatabilies. There was even some discussion if rdist was needed in the base system any more. It would still be available as a port. There are alternatives (rsync), but I still don't think they fill rdist's shoes for complex, or even some simple (dependant on your experience with rdist) tasks: ( /etc/aliases ) -> ( alpha beta gamma cosmic ) install /etc/aliases; special "/usr/sbin/newaliases"; I think you'd need a wrapper to do this successfully with rsync, which really is a lot more work than writing a Distfile. - Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 10:42:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from penelope.skunk.org (penelope.skunk.org [208.133.204.51]) by hub.freebsd.org (Postfix) with ESMTP id 4FD1E14C04 for ; Wed, 8 Dec 1999 10:23:53 -0800 (PST) (envelope-from ben@penelope.skunk.org) Received: from localhost (ben@localhost) by penelope.skunk.org (8.9.3/8.9.3) with ESMTP id NAA28047; Wed, 8 Dec 1999 13:32:40 -0500 (EST) Date: Wed, 8 Dec 1999 13:32:39 -0500 (EST) From: Ben Rosengart To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Getting a new MAP_ flag into mmap() prior to 4.x freeze In-Reply-To: <199912081721.JAA37897@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 8 Dec 1999, Matthew Dillon wrote: > Operationally, the syncer will not sync the file while any mmap()'s > exist with that flag set. Once such flagged maps go away, the syncer > will be able to sync the file (if it still exists). > > Comments are welcome. I assume that this flag would require write permission to the file, to prevent bad security implications? -- Ben Rosengart UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 10:43: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 1291F154CB for ; Wed, 8 Dec 1999 10:42:23 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id NAA07339; Wed, 8 Dec 1999 13:42:05 -0500 (EST) Date: Wed, 8 Dec 1999 13:42:05 -0500 (EST) From: "Matthew N. Dodd" To: Arun Sharma Cc: Andrzej Bialecki , freebsd-hackers@FreeBSD.ORG Subject: Re: Fwd: Re: kstat - an API for gathering kernel stats In-Reply-To: <19991208083348.A29811@sharmas.dhs.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 8 Dec 1999, Arun Sharma wrote: > I'm interested in doing something like: > > kern.stats.cpu0.idle > kern.stats.cpu0.nice > ... > kern.stats.cpu1.idle > kern.stats.cpu1.nice > ... > > and I want the nodes cpu0, cpu1 etc dynamically created. It would be better to have kern.stats.nice.cpu0 kern.stats.nice.cpu1 or simply kern.stats.nice.0 -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 10:58:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from web801.mail.yahoo.com (web801.mail.yahoo.com [128.11.23.61]) by hub.freebsd.org (Postfix) with SMTP id 2E5AF1580A for ; Wed, 8 Dec 1999 10:54:00 -0800 (PST) (envelope-from raysonlogin@yahoo.com) Received: (qmail 23457 invoked by uid 60001); 8 Dec 1999 18:09:24 -0000 Message-ID: <19991208180924.23456.qmail@web801.mail.yahoo.com> Received: from [128.100.13.59] by web801.mail.yahoo.com; Wed, 08 Dec 1999 10:09:24 PST Date: Wed, 8 Dec 1999 10:09:24 -0800 (PST) From: Rayson Ho Subject: Faster Malloc To: List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG http://www.cs.utexas.edu/users/emery/hoard/ Only Linux,Solaris,IRIX,NT, and BeOS supported at this stage. Anyone wants to port it to FreeBSD? Sorry if everyone knows this already... Rayson __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 11: 3:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 8E8741583B for ; Wed, 8 Dec 1999 11:03:39 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA40643; Wed, 8 Dec 1999 11:03:16 -0800 (PST) (envelope-from dillon) Date: Wed, 8 Dec 1999 11:03:16 -0800 (PST) From: Matthew Dillon Message-Id: <199912081903.LAA40643@apollo.backplane.com> To: Ben Rosengart Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Getting a new MAP_ flag into mmap() prior to 4.x freeze References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I assume that this flag would require write permission to the file, to :prevent bad security implications? : :-- : Ben Rosengart You can set the flag without write permission but it will not do anything in that case. The only way to get a page marked such that the syncer doesn't sync it is if you mmap() an area of memory and then take write-faults on pages within that area, which requires write permission to succeed. Only pages dirtied through a mmap marked to not sync will not sync. Things like file meta-data always sync, though if the only data written to a file is through such an mmap() the filesystem will not have much to do there. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 11:29:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bomber.avantgo.com (ws1.avantgo.com [207.214.200.194]) by hub.freebsd.org (Postfix) with ESMTP id 0584415D81 for ; Wed, 8 Dec 1999 11:27:39 -0800 (PST) (envelope-from scott@avantgo.com) Received: from river ([10.0.128.30]) by bomber.avantgo.com (Netscape Messaging Server 3.5) with SMTP id 402; Wed, 8 Dec 1999 11:23:22 -0800 Message-ID: <10f801bf41b2$403f2f10$1e80000a@avantgo.com> From: "Scott Hess" To: "Rayson Ho" , References: <19991208180924.23456.qmail@web801.mail.yahoo.com> Subject: Re: Faster Malloc Date: Wed, 8 Dec 1999 11:27:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From the web page: "Hoard is a fast, scalable and memory-efficient allocator for multiprocessors. Hoard solves the heap contention problem caused when multiple threads call dynamic memory allocation functions like malloc() and free() (or new and delete). Hoard can dramatically improve the performance of multithreaded programs running on multiprocessors." It doesn't sound like it would help much under the current FreeBSD pthread implementation, because userland threads shouldn't suffer from multiprocessor contention. Later, scott ----- Original Message ----- From: Rayson Ho To: List Sent: Wednesday, December 08, 1999 10:09 AM Subject: Faster Malloc > > http://www.cs.utexas.edu/users/emery/hoard/ > > Only Linux,Solaris,IRIX,NT, and BeOS supported at this > stage. Anyone wants to port it to FreeBSD? > > Sorry if everyone knows this already... > > > Rayson > > > > > __________________________________________________ > Do You Yahoo!? > Thousands of Stores. Millions of Products. All in one place. > Yahoo! Shopping: http://shopping.yahoo.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 12:30:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from luna.lyris.net (luna.shelby.com [207.90.155.6]) by hub.freebsd.org (Postfix) with ESMTP id 6539415860 for ; Wed, 8 Dec 1999 12:28:52 -0800 (PST) (envelope-from kip@lyris.com) Received: from luna.shelby.com by luna.lyris.net (8.9.1b+Sun/SMI-SVR4) id MAA05196; Wed, 8 Dec 1999 12:28:05 -0800 (PST) Received: from (luna.shelby.com [207.90.155.6]) by luna.shelby.com with SMTP (MailShield v1.50); Wed, 08 Dec 1999 12:28:05 -0800 Date: Wed, 8 Dec 1999 12:28:05 -0800 (PST) From: Kip Macy X-Sender: kip@luna To: Scott Hess Cc: Rayson Ho , freebsd-hackers@freebsd.org Subject: Re: Faster Malloc In-Reply-To: <10f801bf41b2$403f2f10$1e80000a@avantgo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: luna X-SMTP-MAIL-FROM: kip@lyris.com X-SMTP-RCPT-TO: scott@avantgo.com,raysonlogin@yahoo.com,freebsd-hackers@freebsd.org X-SMTP-PEER-INFO: luna.shelby.com [207.90.155.6] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It might be nice when LWP support is added. -Kip On Wed, 8 Dec 1999, Scott Hess wrote: > From the web page: > > "Hoard is a fast, scalable and memory-efficient allocator for > multiprocessors. Hoard solves the heap contention problem caused when > multiple threads call dynamic memory allocation functions like malloc() and > free() (or new and delete). Hoard can dramatically improve the performance > of multithreaded programs running on multiprocessors." > > It doesn't sound like it would help much under the current FreeBSD pthread > implementation, because userland threads shouldn't suffer from > multiprocessor contention. > > Later, > scott > > ----- Original Message ----- > From: Rayson Ho > To: List > Sent: Wednesday, December 08, 1999 10:09 AM > Subject: Faster Malloc > > > > > > http://www.cs.utexas.edu/users/emery/hoard/ > > > > Only Linux,Solaris,IRIX,NT, and BeOS supported at this > > stage. Anyone wants to port it to FreeBSD? > > > > Sorry if everyone knows this already... > > > > > > Rayson > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Thousands of Stores. Millions of Products. All in one place. > > Yahoo! Shopping: http://shopping.yahoo.com > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 13:26: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from www.geocrawler.com (sourceforge.net [209.81.8.17]) by hub.freebsd.org (Postfix) with ESMTP id B32CE15176 for ; Wed, 8 Dec 1999 13:25:58 -0800 (PST) (envelope-from nobody@www.geocrawler.com) Received: (from nobody@localhost) by www.geocrawler.com (8.9.3/8.9.3) id NAA30695; Wed, 8 Dec 1999 13:24:23 -0800 Date: Wed, 8 Dec 1999 13:24:23 -0800 Message-Id: <199912082124.NAA30695@www.geocrawler.com> To: freebsd-hackers@freebsd.org Subject: Interrupt handler for PCI From: "Alex" Reply-To: "Alex" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message was sent from Geocrawler.com by "Alex" Be sure to reply to that address. Hello, I'm writting driver for PCI board. Is't possible to set interrupt handler for PCI device not in attach function? If yes, how? For ISA is possible to do by calling reconfig_isadev(dev, &imask) for one device. Thank you Geocrawler.com - The Knowledge Archive To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 13:57:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 6B5C514CEB for ; Wed, 8 Dec 1999 13:57:49 -0800 (PST) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id QAA03009; Wed, 8 Dec 1999 16:57:44 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <199912082157.QAA03009@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Matthew N. Dodd" Cc: Arun Sharma , Andrzej Bialecki , freebsd-hackers@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: Fwd: Re: kstat - an API for gathering kernel stats References: In-reply-to: Your message of "Wed, 08 Dec 1999 13:42:05 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Dec 1999 16:57:44 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Wed, 8 Dec 1999, Arun Sharma wrote: > > I'm interested in doing something like: > > > > kern.stats.cpu0.idle > > kern.stats.cpu0.nice > > ... > > kern.stats.cpu1.idle > > kern.stats.cpu1.nice > > ... > > > > and I want the nodes cpu0, cpu1 etc dynamically created. > > It would be better to have > > kern.stats.nice.cpu0 > kern.stats.nice.cpu1 > > or simply > > kern.stats.nice.0 Yes, please! It would be helpful if the kernel's MIB used instances (and there was easy support for creating them) like the MIBs many of us use SNMP to access in network elements. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 14:17:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 21C8E1521B for ; Wed, 8 Dec 1999 14:17:38 -0800 (PST) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) with ESMTP id OAA20217; Wed, 8 Dec 1999 14:46:58 -0800 (PST) Date: Wed, 8 Dec 1999 14:46:58 -0800 (PST) From: Alfred Perlstein To: Kip Macy Cc: Scott Hess , Rayson Ho , freebsd-hackers@FreeBSD.ORG Subject: Re: Faster Malloc In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 8 Dec 1999, Kip Macy wrote: > > From: Rayson Ho > > > > > > http://www.cs.utexas.edu/users/emery/hoard/ > > > > > > Only Linux,Solaris,IRIX,NT, and BeOS supported at this > > > stage. Anyone wants to port it to FreeBSD? > > > > > > Sorry if everyone knows this already... > > > > On Wed, 8 Dec 1999, Scott Hess wrote: > > > From the web page: > > > > "Hoard is a fast, scalable and memory-efficient allocator for > > multiprocessors. Hoard solves the heap contention problem caused when > > multiple threads call dynamic memory allocation functions like malloc() and > > free() (or new and delete). Hoard can dramatically improve the performance > > of multithreaded programs running on multiprocessors." > > > > It doesn't sound like it would help much under the current FreeBSD pthread > > implementation, because userland threads shouldn't suffer from > > multiprocessor contention. > > It might be nice when LWP support is added. > > -Kip Userland threads can contend against themselves, right now the kernel doesn't but it would be a good thing to implement for later use. We also support shared address space fork, so this may be a good idea for programs that utilize that. This allocator is pretty much what the Dynix allocator is, it wouldn't be difficult to clean-room implement this with a BSD license. They should have given credit to Dynix or at least Uresh Vahalia (discussed on page 390 of his book Unix Internals section 12.9). -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 14:21:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 9ABCA150F8 for ; Wed, 8 Dec 1999 14:21:39 -0800 (PST) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) with ESMTP id OAA20332; Wed, 8 Dec 1999 14:51:17 -0800 (PST) Date: Wed, 8 Dec 1999 14:51:17 -0800 (PST) From: Alfred Perlstein To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Getting a new MAP_ flag into mmap() prior to 4.x freeze In-Reply-To: <199912081721.JAA37897@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 8 Dec 1999, Matthew Dillon wrote: > I would like to add a new MAP_ flag to mmap() prior to the 4.x freeze. > The purpose of the flag is to prevent the syncer from syncing the > file underlying the map. The VM system will still page to the file as > needed and, of course, the data will remain consistent with the file. > > This will allow normal files to be used to back (for example) shared > memory without incuring the extra overhead that sync causes every 30 > seconds. Currently it is not possible to use normal files in this > fashion (verses using MAP_ANON, for which sharability is limited, or > SysV shared memory which often has unexpected limitations) and still > have an efficient system. > > The flag will be called MAP_NOSYNC > > Operationally, the syncer will not sync the file while any mmap()'s > exist with that flag set. Once such flagged maps go away, the syncer > will be able to sync the file (if it still exists). > > Comments are welcome. I'd like to see this happen, go for it! :) Don't forget how getnewbuf refils the buffers though, it will need to somehow to communicate to the syncer to disregard MAP_NOSYNC during a shortage... ? :) -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 14:38:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 667E2151F5 for ; Wed, 8 Dec 1999 14:38:50 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA43939; Wed, 8 Dec 1999 14:38:48 -0800 (PST) (envelope-from dillon) Date: Wed, 8 Dec 1999 14:38:48 -0800 (PST) From: Matthew Dillon Message-Id: <199912082238.OAA43939@apollo.backplane.com> To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Getting a new MAP_ flag into mmap() prior to 4.x freeze References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I'd like to see this happen, go for it! :) : :Don't forget how getnewbuf refils the buffers though, it will need to :somehow to communicate to the syncer to disregard MAP_NOSYNC during a :shortage... ? :) : :-Alfred No, I don't bother with that. If there is a filesystem buffer associated with a dirty page the NOSYNC is ignored. The only time a filesystem buffer can be associated with a NOSYNC page is if you write(). In that case we allow the normal filesystem mechanisms to handle it. The tie-in is really trivial -- there is essentially one procedure which the object code calls to synchronize a range and it is comprised of two parts: Collecting dirty pages and constructing filesystem buffers for them, and flushing out filesystem buffers. NOSYNC simply prevents the first part from occuring for normal asynchronous flushes. The second part thus nevers sees the pages unless some other command indirectly associates them with a buffer -- like write() does for example. For low-memory situations we let the pagedaemon handle things. The pagedaemon ignores the NOSYNC flag. That is, NOSYNC space is treated just the same as swap-backed memory is treated - pageed only when necessary. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 14:50:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from users.anet-stl.com (users.anet-stl.com [209.145.150.20]) by hub.freebsd.org (Postfix) with ESMTP id 14876152C0 for ; Wed, 8 Dec 1999 14:50:07 -0800 (PST) (envelope-from doogie@anet-stl.com) Received: from earth.anet-stl.com (earth.anet-stl.com [209.83.128.12]) by users.anet-stl.com (8.9.3/8.8.5) with SMTP id QAA18385; Wed, 8 Dec 1999 16:49:55 -0600 (CST) Date: Wed, 8 Dec 1999 16:49:54 -0600 (CST) From: Jason Young To: Matthew Dillon Cc: Alfred Perlstein , freebsd-hackers@FreeBSD.ORG Subject: Re: Getting a new MAP_ flag into mmap() prior to 4.x freeze In-Reply-To: <199912082238.OAA43939@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think that you imply explicit msync() calls still flush data to disk. Is that the case? Jason Young accessUS Chief Network Engineer On Wed, 8 Dec 1999, Matthew Dillon wrote: > :I'd like to see this happen, go for it! :) > : > :Don't forget how getnewbuf refils the buffers though, it will need to > :somehow to communicate to the syncer to disregard MAP_NOSYNC during a > :shortage... ? :) > : > :-Alfred > > No, I don't bother with that. If there is a filesystem buffer associated > with a dirty page the NOSYNC is ignored. The only time a filesystem > buffer can be associated with a NOSYNC page is if you write(). In that > case we allow the normal filesystem mechanisms to handle it. > > The tie-in is really trivial -- there is essentially one procedure which > the object code calls to synchronize a range and it is comprised of two > parts: Collecting dirty pages and constructing filesystem buffers > for them, and flushing out filesystem buffers. > > NOSYNC simply prevents the first part from occuring for normal > asynchronous flushes. The second part thus nevers sees the pages unless > some other command indirectly associates them with a buffer -- like write() > does for example. > > For low-memory situations we let the pagedaemon handle things. The > pagedaemon ignores the NOSYNC flag. That is, NOSYNC space is treated > just the same as swap-backed memory is treated - pageed only when > necessary. > > -Matt > Matthew Dillon > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 14:54:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns0.netcraft.com (ns0.netcraft.com [195.188.192.4]) by hub.freebsd.org (Postfix) with ESMTP id 51BAD14FF9 for ; Wed, 8 Dec 1999 14:54:24 -0800 (PST) (envelope-from richard@netcraft.com) Received: (from richard@localhost) by ns0.netcraft.com (8.8.8/8.8.8) id WAA00863; Wed, 8 Dec 1999 22:46:34 GMT (envelope-from richard) From: Richard Wendland Message-Id: <199912082246.WAA00863@ns0.netcraft.com> Subject: mmap() and atime/mtime In-Reply-To: <199912081903.LAA40643@apollo.backplane.com> from Matthew Dillon at "Dec 8, 99 11:03:16 am" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Wed, 8 Dec 1999 22:46:34 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > Things like file meta-data always sync, though if the only data written > to a file is through such an mmap() the filesystem will not have much > to do there. Incidentally, I notice that files "read" through a mmap (PROT_READ, MAP_SHARED) don't cause the file's atime to be set, on 3.3-STABLE and 2.2.8-STABLE at least. This doesn't strike me as the right thing to do, even if the stat(2) man page says: st_atime Time when file data last accessed. Changed by the mknod(2), utimes(2) and read(2) system calls. From a quick test, it does seem that "writing" through mmap does cause mtime to be set, despite stat(2) saying: st_mtime Time when file data last modified. Changed by the mknod(2), utimes(2) and write(2) system calls. Good, other incremental backup systems might not work properly. However I do notice that the modification time isn't set until a short time after process exit (with an implied munmap & close), presumably by the syncer. However we do have the somewhat strange situation that atime < mtime. The Open Group Single UNIX Specification Version 2 says in: http://www.opengroup.org/onlinepubs/007908799/xsh/mmap.html "The st_atime field of the mapped file may be marked for update at any time between the mmap() call and the corresponding munmap() call. The initial read or write reference to a mapped region will cause the file's st_atime field to be marked for update if it has not already been marked for update. The st_ctime and st_mtime fields of a file that is mapped with MAP_SHARED and PROT_WRITE, will be marked for update at some point in the interval between a write reference to the mapped region and the next call to msync() with MS_ASYNC or MS_SYNC for that portion of the file by any process. If there is no such call, these fields may be marked for update at any time after a write reference if the underlying file is modified as a result." So it looks likely the commercial Unix's set atime. From a quick test it looks like Linux does as well. Seems to me FreeBSD should do the same. I'm inclined to the view that it would be nice if mtime was set at the first write reference that would change the underlying object, but not synced out to disk at that time. This means running processes do at least see the mtime change immediately, just as they'd see the changes if they mmap'd the file. Richard -- Richard Wendland richard@starburst.demon.co.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 15:22:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 5CC5A1527F for ; Wed, 8 Dec 1999 15:22:36 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA44403; Wed, 8 Dec 1999 15:22:33 -0800 (PST) (envelope-from dillon) Date: Wed, 8 Dec 1999 15:22:33 -0800 (PST) From: Matthew Dillon Message-Id: <199912082322.PAA44403@apollo.backplane.com> To: Jason Young Cc: Alfred Perlstein , freebsd-hackers@FreeBSD.ORG Subject: Re: Getting a new MAP_ flag into mmap() prior to 4.x freeze References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : : :I think that you imply explicit msync() calls still flush data to disk. Is :that the case? : :Jason Young :accessUS Chief Network Engineer msync never guarenteed the flushing of data to disk, it simply guarentees synchronization with the buffer cache. FreeBSD, however, uses a coherent VM/buffer-cache. The FreeBSD msync with the MS_SYNC flag appears to flush VM data to physical media, though in my test it is terribly slow (it doesn't cluster!). msync doesn't care whether the pages are NOSYNC or not. i.e. NOSYNC has no effect on the operation of msync(). msync() with the MS_ASYNC flag appears to cluster properly. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 15:41:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 4224514F55; Wed, 8 Dec 1999 15:41:25 -0800 (PST) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id PAA54148; Wed, 8 Dec 1999 15:41:24 -0800 (PST) From: Archie Cobbs Message-Id: <199912082341.PAA54148@bubba.whistle.com> Subject: New mpd with netgraph and PPTP To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Date: Wed, 8 Dec 1999 15:41:24 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A new version of 'mpd', a multi-link PPP daemon, is available as a beta release from Whistle Communications under the Whistle license (BSD style). * This new version is completely netgraph(4) based, which means that all of the negotiation protocols (IPCP, LCP, etc) are handled in user-land, while all data transmission, compression, encryption, etc. is handled strictly in the kernel. This approach combines the configuration flexibility of a user-mode PPP daemon with the speed of a kernel-only PPP daemon, not to mention the wide device type and protocol support of netgraph. * This version also includes support for the Point-to-Point Tunneling Protocol (PPTP), in both client "dial-in" mode and LAN-LAN VPN, and is compatible with Microsoft's Dial-Up Networking VPN adapter. To get the new mpd: 1. Update your -stable or -current system from CVS (ie, today's!) and make world (or at least build and install a new kernel, kernel includes, netgraph modules, and libnetgraph). 2. Run pkg_delete on any existing mpd port on your machine 3. Blow away /usr/ports/net/mpd, and replace it with this: ftp://ftp.whistle.com/pub/archie/mpd/port.tgz 4. Build and install the new port. Any bug reports, suggestions, etc. are greatly appreciated. I'd also be interested to hear if anyone does any speed comparisions between this version of mpd and other FreeBSD PPP implementations. Cheers, -Archie PS: We also have an MPPE (Microsoft Point-to-Point encryption) implementation (as a netgraph module). This allows Microsoft clients' PPTP connections to be encrypted, though the security of MPPE is not very strong. However, it includes RC4, which is patented, so you must get your own implementation of RC4 (legally!) and compile the node yourself. Let me know by email if you're interested in trying this out too. PPS: Does not understand PPPoE yet.. use 'ppp' for that. ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 18:25:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by hub.freebsd.org (Postfix) with ESMTP id E113E152AD for ; Wed, 8 Dec 1999 18:25:34 -0800 (PST) (envelope-from rminnich@lanl.gov) Received: from localhost (rminnich@localhost) by acl.lanl.gov (8.8.8/8.8.5) with ESMTP id TAA505133; Wed, 8 Dec 1999 19:25:26 -0700 (MST) X-Authentication-Warning: acl.lanl.gov: rminnich owned process doing -bs Date: Wed, 8 Dec 1999 19:25:26 -0700 From: "Ronald G. Minnich" To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Getting a new MAP_ flag into mmap() prior to 4.x freeze In-Reply-To: <199912081721.JAA37897@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG good flag. If you look at my old mnfs stuff you can see our solution : we ignored sync :-) This is a good move. ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 19:46:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 94F21152FA for ; Wed, 8 Dec 1999 19:46:47 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA45576; Wed, 8 Dec 1999 19:46:43 -0800 (PST) (envelope-from dillon) Date: Wed, 8 Dec 1999 19:46:43 -0800 (PST) From: Matthew Dillon Message-Id: <199912090346.TAA45576@apollo.backplane.com> To: Richard Wendland Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: mmap() and atime/mtime References: <199912082246.WAA00863@ns0.netcraft.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Matthew Dillon wrote: : :> Things like file meta-data always sync, though if the only data written :> to a file is through such an mmap() the filesystem will not have much :> to do there. : :Incidentally, I notice that files "read" through a mmap (PROT_READ, :MAP_SHARED) don't cause the file's atime to be set, on 3.3-STABLE :and 2.2.8-STABLE at least. : :This doesn't strike me as the right thing to do, even if the stat(2) man :page says: I think you're right, but it isn't something that I can fix this second. I recommend filing a PR and then emailing me the PR number. I'll assign it to myself so it shows up in my weekly reminder but I don't think I'm going to get to it for a couple of months. :I'm inclined to the view that it would be nice if mtime was set at :the first write reference that would change the underlying object, :but not synced out to disk at that time. This means running :processes do at least see the mtime change immediately, just as :they'd see the changes if they mmap'd the file. : : Richard :-- :Richard Wendland richard@starburst.demon.co.uk I would hesitate to delve that deeply into the VFS system from a VM fault for performance reasons. The Open Group specification you quoted seems reasonable to me, but the mtime specification is not 100% achieveable % in a coherent VM/buffer-cache because once the page is dirtied the process can make further modifications to it (that essentially modify the underlying file) without any further faulting. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 19:49:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 04E7715316 for ; Wed, 8 Dec 1999 19:49:12 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA45597; Wed, 8 Dec 1999 19:49:05 -0800 (PST) (envelope-from dillon) Date: Wed, 8 Dec 1999 19:49:05 -0800 (PST) From: Matthew Dillon Message-Id: <199912090349.TAA45597@apollo.backplane.com> To: Randell Jesup Cc: freebsd-hackers@freebsd.org Subject: Re: writing to an mmap()'ed region requires read access? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : : Shouldn't the mmap() return MAP_FAILED, probably with EACCES, :instead of causing a signal 10? : :-- :Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) It's one of those cases that occurs when you have a general purpose call where the mix of arguments is not expected to be used. I'm not sure 'fixing' it would accomplish anything in real terms. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 21: 1:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from koke.nibb.ac.jp (koke.nibb.ac.jp [133.48.46.82]) by hub.freebsd.org (Postfix) with ESMTP id 27738152DA for ; Wed, 8 Dec 1999 21:01:17 -0800 (PST) (envelope-from tomoaki@biol.s.u-tokyo.ac.jp) Received: from localhost (koke.nibb.ac.jp [127.0.0.1]) by koke.nibb.ac.jp (8.9.3/8.9.3) with ESMTP id OAA80806; Thu, 9 Dec 1999 14:01:16 +0900 (JST) (envelope-from tomoaki@biol.s.u-tokyo.ac.jp) To: freebsd-hackers@FreeBSD.ORG Cc: tomoaki@biol.s.u-tokyo.ac.jp Subject: ctype.h difines _T globaly From: Tomoaki NISHIYAMA X-Mailer: Mew version 1.94.2pre3 on XEmacs 21.1 (Big Bend) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19991209140116T.tomoaki@biol.s.u-tokyo.ac.jp> Date: Thu, 09 Dec 1999 14:01:16 +0900 X-Dispatcher: imput version 991025(IM133) Lines: 22 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I propose that ctype.h not define _T, but instead define _CTYPE_T. Other two letter macros also should be changed likewise. Definition of such macro by the system are perhaps allowed by the standard, but its better not to define such macros. One reason is that the STL code included in stdlibc++ currently uses _T as local identifier. This code will be broken by the macro in ctype.h. To change the situation one can change the c++ codes. Another way is to change the macro in ctype.h. Both action can be taken at the same time. The other reason is that it is not good to polute the global namespace by just a part of the system. One does not expect that _T is defined in ctype.h. But if the macro were _CTYPE_T it is easier to come to the idea that it might be defined in ctype.h. -- Tomoaki Nishiyama e-mail:tomoaki@biol.s.u-tokyo.ac.jp Department of Biological Sciences, Graduate School of Science, The University of Tokyo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 21:30:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 02E0B15323 for ; Wed, 8 Dec 1999 21:30:43 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA46209; Wed, 8 Dec 1999 21:30:37 -0800 (PST) (envelope-from dillon) Date: Wed, 8 Dec 1999 21:30:37 -0800 (PST) From: Matthew Dillon Message-Id: <199912090530.VAA46209@apollo.backplane.com> To: freebsd-hackers@FreeBSD.ORG Cc: Kirk McKusick Subject: mmap/write case brought up again - maybe its time to... Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Someone brought up the mmap/write case up again - that's a deadlock case that we haven't fixed yet where you write from one descriptor into shared writeable file-backed memory area and, from another process, do the vise-versa. Maybe it's time to make filesystem locks recursive by default. Doing so will allow the above case to be fixed 100% by allowing the read() and write() code to pre-lock the underlying vnodes in the correct order (by pointer comparison) prior to digging into them. I think Kirk may be the best person to make this determination - I seem to recall there being some (minor?) issues. Implementing recursive locks may be as simple as adding LK_RECURSE to vn_lock() but I haven't researched it heavily. This may also tie-in well with the revamping of the VOP code later on. There is a significant amount of complexity in the VOP code in having to deal with non-recursive locks when a passed argument is supposed to be locked and remain locked on return, the return argument is supposed to be locked, and the returned argument winds up being the same as the passed argument. With recursive locks as the norm we can remove nearly all of those special cases leaving just the one that deals with ".." (or perhaps dealing with namei directory locks in a different way). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 23:26:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flamingo.McKusick.COM (flamingo.mckusick.com [209.31.233.178]) by hub.freebsd.org (Postfix) with ESMTP id 58AD01532F for ; Wed, 8 Dec 1999 23:26:22 -0800 (PST) (envelope-from mckusick@flamingo.McKusick.COM) Received: from flamingo.McKusick.COM (mckusick@localhost [127.0.0.1]) by flamingo.McKusick.COM (8.9.3/8.9.0) with ESMTP id UAA15950; Wed, 8 Dec 1999 20:29:39 -0800 (PST) Message-Id: <199912090429.UAA15950@flamingo.McKusick.COM> To: Matthew Dillon Subject: Re: mmap/write case brought up again - maybe its time to... Cc: freebsd-hackers@freebsd.org In-reply-to: Your message of "Wed, 08 Dec 1999 21:30:37 PST." <199912090530.VAA46209@apollo.backplane.com> Date: Wed, 08 Dec 1999 20:29:38 -0800 From: Kirk McKusick Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Date: Wed, 8 Dec 1999 21:30:37 -0800 (PST) From: Matthew Dillon To: freebsd-hackers@FreeBSD.ORG Cc: Kirk McKusick Subject: mmap/write case brought up again - maybe its time to... Someone brought up the mmap/write case up again - that's a deadlock case that we haven't fixed yet where you write from one descriptor into shared writeable file-backed memory area and, from another process, do the vise-versa. Maybe it's time to make filesystem locks recursive by default. Doing so will allow the above case to be fixed 100% by allowing the read() and write() code to pre-lock the underlying vnodes in the correct order (by pointer comparison) prior to digging into them. I think Kirk may be the best person to make this determination - I seem to recall there being some (minor?) issues. Implementing recursive locks may be as simple as adding LK_RECURSE to vn_lock() but I haven't researched it heavily. This may also tie-in well with the revamping of the VOP code later on. There is a significant amount of complexity in the VOP code in having to deal with non-recursive locks when a passed argument is supposed to be locked and remain locked on return, the return argument is supposed to be locked, and the returned argument winds up being the same as the passed argument. With recursive locks as the norm we can remove nearly all of those special cases leaving just the one that deals with ".." (or perhaps dealing with namei directory locks in a different way). -Matt Recursive locks are easy to implement. Just add LK_CANRECURSE as the final argument to the call to lockinit at line 1077 in ffs_vget of ufs/ffs/ffs_vfsops.c. That's it. From there on out all FFS locks will be recursive and you can begin simplifying away. Kirk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 8 23:46:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 7918D155AB for ; Wed, 8 Dec 1999 23:46:36 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id CAA27645 for ; Thu, 9 Dec 1999 02:46:45 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Thu, 9 Dec 1999 02:46:45 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-hackers@freebsd.org Subject: question about boot loaders Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The documentation in /usr/src/sys/boot/i386 seems a little scant, and that still hanging out in /usr/src/sys/i386/boot is clearly outdated. Was wondering if someone could point me at docs, and/or post a short summary something in the form of: loader loadedby function -------------------------------- mbr BIOS whatever, maybe a couple of lines boot0 ??? "" ""... boot1 ??? "" ""... boot2 boot1 FreeBSD bootloader that speaks protected mode, etc, and can load the kernel around gaps in physical memory, etc. loader boot2 Forth interpreter + scripting for great fun kernel loader or boot2 The kernel Once we get into boot2 land, I recognize the FreeBSD-specific loading code, etc. What I don't know much about is those first three 512-byte chunks of code. Boot0 appears to be booteasy, but given some ignorance about the i386 boot process, I'm not sure whether it's loaded by mbr, or by the bios, and where it lives partition-wise. Similarly, how boot1 fits into it the whole scheme--I assume this is FreeBSD-specific as it knows about boot2, but don't know where it lives, etc. Preferably, afterwards, also drop the results into sys/boot/i386/README. :-) Thanks, Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 0:22:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns1.sunesi.net (ns1.sunesi.net [196.15.192.194]) by hub.freebsd.org (Postfix) with ESMTP id 45850151B4 for ; Thu, 9 Dec 1999 00:22:32 -0800 (PST) (envelope-from nbm@sunesi.net) Received: from nbm by ns1.sunesi.net with local (Exim 3.03 #1) id 11vypr-000OOc-00; Thu, 09 Dec 1999 10:21:59 +0200 Date: Thu, 9 Dec 1999 10:21:59 +0200 From: Neil Blakey-Milner To: Robert Watson Cc: freebsd-hackers@freebsd.org Subject: Re: question about boot loaders Message-ID: <19991209102159.B88680@ns1.sunesi.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: Organization: Rhodes University Computer Users' Society X-Operating-System: FreeBSD 3.3-RELEASE i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu 1999-12-09 (02:46), Robert Watson wrote: > Once we get into boot2 land, I recognize the FreeBSD-specific loading > code, etc. What I don't know much about is those first three 512-byte > chunks of code. Boot0 appears to be booteasy, but given some ignorance > about the i386 boot process, I'm not sure whether it's loaded by mbr, or > by the bios, and where it lives partition-wise. Similarly, how boot1 fits > into it the whole scheme--I assume this is FreeBSD-specific as it knows > about boot2, but don't know where it lives, etc. Preferably, afterwards, > also drop the results into sys/boot/i386/README. :-) I wrote up some basic stuff, which doesn't seem quite to describe what you're after, but which may be of use, at http://rucus.ru.ac.za/~nbm/boot/ It's intended for the handbook, but I haven't had time since starting my new job to work on it much more. Neil -- Neil Blakey-Milner nbm@rucus.ru.ac.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 0:34:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id C6CCB15281 for ; Thu, 9 Dec 1999 00:34:35 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id DAA27762; Thu, 9 Dec 1999 03:33:10 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Thu, 9 Dec 1999 03:33:10 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Neil Blakey-Milner Cc: freebsd-hackers@freebsd.org Subject: Re: question about boot loaders In-Reply-To: <19991209102159.B88680@ns1.sunesi.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 9 Dec 1999, Neil Blakey-Milner wrote: > On Thu 1999-12-09 (02:46), Robert Watson wrote: > > Once we get into boot2 land, I recognize the FreeBSD-specific loading > > code, etc. What I don't know much about is those first three 512-byte > > chunks of code. Boot0 appears to be booteasy, but given some ignorance > > about the i386 boot process, I'm not sure whether it's loaded by mbr, or > > by the bios, and where it lives partition-wise. Similarly, how boot1 fits > > into it the whole scheme--I assume this is FreeBSD-specific as it knows > > about boot2, but don't know where it lives, etc. Preferably, afterwards, > > also drop the results into sys/boot/i386/README. :-) > > I wrote up some basic stuff, which doesn't seem quite to describe > what you're after, but which may be of use, at > http://rucus.ru.ac.za/~nbm/boot/ > > It's intended for the handbook, but I haven't had time since starting > my new job to work on it much more. Looks interesting, but doesn't seem to mention the mbr/mbr.s code, and I'm not sure how this fit into the picture. There seem to be three 512-byte chunks of code: -r--r--r-- 1 root wheel 512 Sep 16 18:46 mbr -r--r--r-- 1 root wheel 512 Sep 16 18:46 boot0 -r--r--r-- 1 root wheel 512 Sep 16 18:46 boot1 -r--r--r-- 1 root wheel 7680 Sep 16 18:46 boot2 -r-xr-xr-x 1 root wheel 131072 Sep 16 18:46 loader* When there were two of them, I understood pretty much what was going on. Now there are three, and I clearly haven't been keeping a close enough eye on what is going on, because now I'm confused whereas previously I wasn't :-). Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 0:38: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id 87859152AD for ; Thu, 9 Dec 1999 00:38:01 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 76105 invoked by uid 1001); 9 Dec 1999 08:35:17 -0000 Date: Thu, 9 Dec 1999 00:35:17 -0800 From: Jason Evans To: freebsd-hackers@freebsd.org Subject: Possible libc changes to support LinuxThreads Message-ID: <19991209003517.E73529@sturm.canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've got a port of the most recent LinuxThreads (glibc-linuxthreads-2.1.2) running, but ran into a couple of minor problems integrating with our libc. LinuxThreads redefines a number of functions in order to make them either support thread cancellation or work correctly. The following functions need an alternative name, just as, for example, write() is actually _write(): lseek() pause() system() tcdrain() wait() waitpid() recv() send() This would allow implementing cancellation points for these functions. All in all, I won't lose much sleep over this, but if it's easy to do and doesn't violate some rule of symbol naming, it would be nice. The other issue has to do with longjmp() and siglongjmp(), and is of a similar nature, except that _longjmp() already exists as a separate interface. So, at least in the case of longjmp(), it needs to have a different alias, perhaps __longjmp(). Below is a *very* simplistic patch to libc that works, but it may make some people's skin crawl. Feedback is welcome. If there is no correct way to create aliases to function entry points, then we can do without them, but it will mean that the *jmp() functions cannot be used in conjunction with thread cleanup handlers when using LinuxThreads. Jason Index: i386/gen/setjmp.S =================================================================== RCS file: /home/ncvs/src/lib/libc/i386/gen/setjmp.S,v retrieving revision 1.11 diff -u -r1.11 setjmp.S --- setjmp.S 1999/10/10 08:38:33 1.11 +++ setjmp.S 1999/12/09 02:07:45 @@ -54,6 +54,7 @@ #include "DEFS.h" #include "SYS.h" +ENTRY(__setjmp) ENTRY(setjmp) movl 4(%esp),%ecx PIC_PROLOGUE @@ -80,6 +81,7 @@ xorl %eax,%eax ret +ENTRY(__longjmp) ENTRY(longjmp) movl 4(%esp),%edx PIC_PROLOGUE Index: i386/gen/sigsetjmp.S =================================================================== RCS file: /home/ncvs/src/lib/libc/i386/gen/sigsetjmp.S,v retrieving revision 1.13 diff -u -r1.13 sigsetjmp.S --- sigsetjmp.S 1999/09/29 15:18:35 1.13 +++ sigsetjmp.S 1999/12/09 02:07:45 @@ -59,6 +59,7 @@ * use sigreturn() if sigreturn() works. */ +ENTRY(__sigsetjmp) ENTRY(sigsetjmp) movl 8(%esp),%eax movl 4(%esp),%ecx @@ -89,6 +90,7 @@ xorl %eax,%eax ret +ENTRY(__siglongjmp) ENTRY(siglongjmp) movl 4(%esp),%edx cmpl $0,44(%edx) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 0:54: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 307F51526B for ; Thu, 9 Dec 1999 00:54:05 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id DAA27828; Thu, 9 Dec 1999 03:54:06 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Thu, 9 Dec 1999 03:54:05 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Neil Blakey-Milner Cc: freebsd-hackers@freebsd.org Subject: Re: question about boot loaders In-Reply-To: <19991209102159.B88680@ns1.sunesi.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG dcs suggests that the correct answer is: mbr is a replacement for boot0, without the OS choices. This seems to make sense, so I'll go with that unless someone has a better idea :-). We assume that you would never, therefore, use both mbr and boot0, explaining why there doesn't need to be an extra 512 bytes somewhere :-). Thanks, On Thu, 9 Dec 1999, Neil Blakey-Milner wrote: > On Thu 1999-12-09 (02:46), Robert Watson wrote: > > Once we get into boot2 land, I recognize the FreeBSD-specific loading > > code, etc. What I don't know much about is those first three 512-byte > > chunks of code. Boot0 appears to be booteasy, but given some ignorance > > about the i386 boot process, I'm not sure whether it's loaded by mbr, or > > by the bios, and where it lives partition-wise. Similarly, how boot1 fits > > into it the whole scheme--I assume this is FreeBSD-specific as it knows > > about boot2, but don't know where it lives, etc. Preferably, afterwards, > > also drop the results into sys/boot/i386/README. :-) > > I wrote up some basic stuff, which doesn't seem quite to describe > what you're after, but which may be of use, at > http://rucus.ru.ac.za/~nbm/boot/ > > It's intended for the handbook, but I haven't had time since starting > my new job to work on it much more. > > Neil > -- > Neil Blakey-Milner > nbm@rucus.ru.ac.za > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 2: 1: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 6DD6E1525C for ; Thu, 9 Dec 1999 02:00:52 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id C77CC1CA0; Thu, 9 Dec 1999 18:00:46 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Jason Evans Cc: freebsd-hackers@freebsd.org Subject: Re: Possible libc changes to support LinuxThreads In-Reply-To: Message from Jason Evans of "Thu, 09 Dec 1999 00:35:17 PST." <19991209003517.E73529@sturm.canonware.com> Date: Thu, 09 Dec 1999 18:00:46 +0800 From: Peter Wemm Message-Id: <19991209100046.C77CC1CA0@overcee.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jason Evans wrote: > I've got a port of the most recent LinuxThreads (glibc-linuxthreads-2.1.2) > running, but ran into a couple of minor problems integrating with our libc. > LinuxThreads redefines a number of functions in order to make them either > support thread cancellation or work correctly. > > The following functions need an alternative name, just as, for example, > write() is actually _write(): > > lseek() > pause() > system() > tcdrain() > wait() > waitpid() > recv() > send() > > This would allow implementing cancellation points for these functions. All > in all, I won't lose much sleep over this, but if it's easy to do and > doesn't violate some rule of symbol naming, it would be nice. You know about weak symbol redirection, right? It basically allows runtime resolution of symbols instead of link time. So, you could have a weak pointer from lseek to _lseek and provide a _lseek function in libc. When programs link against "lseek" (including within libc itself), they hold a pointer to the non-redirected name. If you *also* provide a "lseek" in libpthreads from linuxthreads, then at runtime everything (including libc) will use the lseek() in the thread library and not _lseek(). Look for __weak_reference() etc, there are some examples in libc/net/* (but those are for different problems). Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 3:35:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.tjohoo.se (b1.mediasvar.se [194.17.201.3]) by hub.freebsd.org (Postfix) with SMTP id 98522155CC for ; Thu, 9 Dec 1999 03:35:26 -0800 (PST) (envelope-from ralph@tjohoo.se) Received: (qmail 7894 invoked from network); 9 Dec 1999 12:34:11 -0000 Received: from b1.mediasvar.se (194.17.201.3) by b1.mediasvar.se with SMTP; 9 Dec 1999 12:34:11 -0000 X-Mailer: TjohooMAIL X-WebsiteUser-IP: 62.20.54.54 From: Ralph Utbult To: freebsd-hackers@freebsd.org Subject: firewall problem? Reply-To: ralph.utbult@gbg.abf.se MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: Quoted-printable Message-Id: <19991209113526.98522155CC@hub.freebsd.org> Date: Thu, 9 Dec 1999 03:35:26 -0800 (PST) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi I=B4m sitting behind a firewall consisting av FreeBsd and Squid. My mail pr= ogram is Popper. I can mail to (and from) every adress I=B4ve tried - excep= t freebsd.org. Here=B4s the error. The original message was received at Wed, 8 Dec 1999 16:40:08 +0100 (CET) from [192.168.1.2] ----- The following addresses had transient non-fatal errors ----- ----- Transcript of session follows ----- .. while talking to hub.freebsd.org.: >>> RCPT To: <<< 450 Client host rejected: cannot find your hostname, [62.20.54.54] ... Deferred: 450 Client host rejected: cannot= find your hostname, [62.20.54.54] Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old Reporting-MTA: dns; hyndan.gbg.abf.se Arrival-Date: Wed, 8 Dec 1999 16:40:08 +0100 (CET) Final-Recipient: RFC822; freebsd-hackers@FreeBSD.ORG Action: delayed Status: 4.2.0 Remote-MTA: DNS; hub.freebsd.org Diagnostic-Code: SMTP; 450 Client host rejected: cannot find your hostname,= [62.20.54.54] Last-Attempt-Date: Wed, 8 Dec 1999 20:52:11 +0100 (CET) Will-Retry-Until: Mon, 13 Dec 1999 16:40:08 +0100 (CET) Return-Path: Received: from ralph ([192.168.1.2]) by hyndan.gbg.abf.se (8.9.3/8.9.3) with ESMTP id QAA63400; Wed, 8 Dec 1999 16:40:08 +0100 (CET) Message-Id: <4.2.0.58.19991208174502.00a65820@192.168.1.1> X-Sender: ralph@192.168.1.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 08 Dec 1999 17:45:52 +0100 To: ralphtest@gbg.abf.se From: Ralph Utbult Subject: Test - ignore! Cc: freebsd-hackers@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=3D"iso-8859-1"; format=3Dflowed What is the problem? Regards, Ralph Utbult Systems Operator ABF G=F6teborg Sweden ____________________________________ Gratis epost med TJOHOOMAIL http://www.tjohoo.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 3:58:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from trltech.demon.co.uk (trltech.demon.co.uk [194.222.7.191]) by hub.freebsd.org (Postfix) with ESMTP id E82B3155D6 for ; Thu, 9 Dec 1999 03:58:37 -0800 (PST) (envelope-from rsmith@trltech.co.uk) Received: from ns.sw.wan (ns.sw.wan [192.9.200.19]) by trltech.demon.co.uk (8.9.2/8.9.2) with ESMTP id LAA21744; Thu, 9 Dec 1999 11:58:36 GMT (envelope-from rsmith@trltech.co.uk) Received: from trltech.co.uk (localhost.sw.wan [127.0.0.1]) by ns.sw.wan (8.9.3/8.9.3) with ESMTP id LAA60845; Thu, 9 Dec 1999 11:59:28 GMT (envelope-from rsmith@trltech.co.uk) Message-ID: <384F99A0.CF3EE8FA@trltech.co.uk> Date: Thu, 09 Dec 1999 11:59:28 +0000 From: Richard Smith Organization: http://www.trltech.co.uk X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ralph.utbult@gbg.abf.se Cc: freebsd-hackers@freebsd.org Subject: Re: firewall problem? References: <19991209113526.98522155CC@hub.freebsd.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ralph Utbult wrote: > = > Hi > = > I=B4m sitting behind a firewall consisting av FreeBsd and Squid. My mai= l program is Popper. I can mail to (and from) every adress I=B4ve tried -= except freebsd.org. Here=B4s the error. > The original message was received at Wed, 8 Dec 1999 16:40:08 +0100 (CE= T) > from [192.168.1.2] > = > ----- The following addresses had transient non-fatal errors ----- > > = > ----- Transcript of session follows ----- > .. while talking to hub.freebsd.org.: > >>> RCPT To: > <<< 450 Client host rejected: cannot find your hostname, [62.20.54.54] > ... Deferred: 450 Client host rejected: ca= nnot find your hostname, [62.20.54.54] > Warning: message still undelivered after 4 hours > Will keep trying until message is 5 days old > Reporting-MTA: dns; hyndan.gbg.abf.se [snip] No, name server problem. `hyndan.gbg.abf.se' resolves to `62.20.54.54'. But `62.20.54.54' resolves to `Non-existent host/domain' Check your name server's PTR records. Richard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 4:43: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from test.tar.com (test.tar.com [204.95.187.4]) by hub.freebsd.org (Postfix) with ESMTP id 70C8314D6F for ; Thu, 9 Dec 1999 04:43:00 -0800 (PST) (envelope-from dick@test.tar.com) Received: (from dick@localhost) by test.tar.com (8.9.3/8.9.3) id GAA99503; Thu, 9 Dec 1999 06:42:56 -0600 (CST) (envelope-from dick) Date: Thu, 9 Dec 1999 06:42:56 -0600 From: "Richard Seaman, Jr." To: Jason Evans Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Possible libc changes to support LinuxThreads Message-ID: <19991209064256.B34152@tar.com> References: <19991209003517.E73529@sturm.canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <19991209003517.E73529@sturm.canonware.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Dec 09, 1999 at 12:35:17AM -0800, Jason Evans wrote: > I've got a port of the most recent LinuxThreads (glibc-linuxthreads-2.1.2) > running, Great! > but ran into a couple of minor problems integrating with our libc. > LinuxThreads redefines a number of functions in order to make them either > support thread cancellation or work correctly. > > The following functions need an alternative name, just as, for example, > write() is actually _write(): > > lseek() > pause() > system() > tcdrain() > wait() > waitpid() > recv() > send() > > This would allow implementing cancellation points for these functions. All > in all, I won't lose much sleep over this, but if it's easy to do and > doesn't violate some rule of symbol naming, it would be nice. It's my impression that glibc uses a three (four?) tiered naming convention. The "pure" syscall (in our case, eg. _write()). Then there is the version used internally in glibc (eg. _libc_write(). And finally, the version exported from glibc (eg. write()). The merit to the three tiered system is that you might need to rewrite the version used internally to libc for threads, but still have this be different from the version exported from the library (eg. to implement cancallation points without propagating them throughout libc). In this case, you'd want, for example, an _lseek(), _libc_lseek(), and _seek(). The problem with cancellation points, libc and linuxthreads has been that you need to wade through libc and replace instances of, for example, write() with either _write() or _libc_write() in order to avoid propagating cancellation points where they don't belong. > The other issue has to do with longjmp() and siglongjmp(), and is of a > similar nature, except that _longjmp() already exists as a separate > interface. So, at least in the case of longjmp(), it needs to have a > different alias, perhaps __longjmp(). Below is a *very* simplistic patch > to libc that works, but it may make some people's skin crawl. Feedback is > welcome. If there is no correct way to create aliases to function entry > points, then we can do without them, but it will mean that the *jmp() > functions cannot be used in conjunction with thread cleanup handlers when > using LinuxThreads. __longjmp() and __siglongjmp() don't bother me at all. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 4:55:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from baynet.baynetworks.com (ns1.BayNetworks.COM [134.177.3.20]) by hub.freebsd.org (Postfix) with ESMTP id B588F14BDE for ; Thu, 9 Dec 1999 04:55:50 -0800 (PST) (envelope-from bwithrow@engeast.BayNetworks.COM) Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id EAA29127; Thu, 9 Dec 1999 04:53:54 -0800 (PST) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id HAA09934; Thu, 9 Dec 1999 07:50:48 -0500 (EST) Received: from tuva.engeast.baynetworks.com (tuva [192.32.150.102]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id HAA23108; Thu, 9 Dec 1999 07:55:11 -0500 for Received: from tuva.engeast.baynetworks.com (localhost [127.0.0.1]) by tuva.engeast.baynetworks.com (8.9.3/8.9.3) with ESMTP id HAA80978; Thu, 9 Dec 1999 07:54:55 -0500 (EST) (envelope-from bwithrow@tuva.engeast.baynetworks.com) Message-Id: <199912091254.HAA80978@tuva.engeast.baynetworks.com> X-Mailer: exmh version 2.0.2 2/24/98 To: hackers@freebsd.org Cc: bwithrow@engeast.BayNetworks.COM, witr@rwwa.com Subject: Weird output from vmstat -m? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Dec 1999 07:54:55 -0500 From: Robert Withrow Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The recent discussion about route table leaks led me to check some of my systems. On one of them I got this: bash-2.03$ uname -srm FreeBSD 3.2-RELEASE i386 bash-2.03$ uptime 7:45AM up 28 days, 12:38, 3 users, load averages: 0.61, 0.50, 0.43 bash-2.03$ vmstat -m | grep routetbl | grep K routetbl 60 8K 15K 40960K 1870 0 0 16,32,64,128,256 routetbl 60 8K 15K 40960K 1870 0 0 16,32,64,128,256 routetbl 60 8K 15K 40960K 1870 0 0 16,32,64,128,256 Eh... *Three* entries? In fact, lots of stuff is triplicated (or more): bash-2.03$ vmstat -m | sort | less [snip] kld 16 79K 84K 40960K 40 0 0 16,32,128,512,1K,4K,8K,64K kld 16 79K 84K 40960K 40 0 0 16,32,128,512,1K,4K,8K,64K kld 16 79K 84K 40960K 40 0 0 16,32,128,512,1K,4K,8K,64K kld 16 79K 84K 40960K 40 0 0 16,32,128,512,1K,4K,8K,64K [etc] And this: bash-2.03$ vmstat -m | less [snip] 64 file, lockf, namecache, devbuf, temp, session, shm, pcb, cluster_save buffer, vnodes, ifaddr, routetbl, NFS req, NFS daemon, file, lockf, namecache, devbuf, temp, session, shm, pcb, cluster_save buffer, vnodes, ifaddr, routetbl, NFS req, NFS daemon, file, lockf, namecache, devbuf, temp, session, shm, pcb, cluster_save buffer, vnodes, ifaddr, routetbl, NFS req, NFS daemon, file This doesn't look healthy to me. I didn't see anything about this in the archives... -- Robert Withrow -- (+1 978 288 8256) BWithrow@BayNetworks.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 5:36:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from Thingol.KryptoKom.DE (Thingol.KryptoKom.DE [194.245.91.1]) by hub.freebsd.org (Postfix) with ESMTP id 9316B15642 for ; Thu, 9 Dec 1999 05:36:45 -0800 (PST) (envelope-from Etienne.DeBruin@KryptoKom.DE) Received: (from root@localhost) by Thingol.KryptoKom.DE (8.9.1/8.9.1) id OAA13852 for ; Thu, 9 Dec 1999 14:34:50 +0100 Received: from cirdan.kryptokom.de by KryptoWall via smtpp (Version 1.2.0) id kwa13850; Thu Dec 09 14:34:35 1999 Received: from nt-notes.kryptokom.de ([192.168.6.247]) by cirdan.kryptokom.de (8.9.3/8.8.8) with SMTP id PAA05636 for ; Thu, 9 Dec 1999 15:47:21 +0100 Received: by nt-notes.kryptokom.de(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id C1256842.004AD1DB ; Thu, 9 Dec 1999 14:37:13 +0100 X-Lotus-FromDomain: UTIMACO From: "Etienne De Bruin" To: hackers@freebsd.org Message-ID: Date: Thu, 9 Dec 1999 14:35:10 +0100 Subject: Sequence of Events in Kernel source? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greetings Seniors. I am interested in establishing the sequence of events from a source code perspective from when the PC is switched on, to the login prompt. I am specifically interested in the setting up of lower level stuff like the drivers. memory etc. Can anyone please take a moment and give me some pointers? Kind regards eT To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 5:51:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by hub.freebsd.org (Postfix) with ESMTP id 4D5EC1567B for ; Thu, 9 Dec 1999 05:51:13 -0800 (PST) (envelope-from K.J.Koster@research.kpn.com) Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #35196) with ESMTP id <01JJAVAZAXNS0005DM@research.kpn.com> for freebsd-hackers@freebsd.org; Thu, 9 Dec 1999 14:51:09 +0100 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21) id ; Thu, 09 Dec 1999 14:51:08 +0100 Content-return: allowed Date: Thu, 09 Dec 1999 14:51:08 +0100 From: "Koster, K.J." Subject: RE: tty level buffer overflows To: 'Warner Losh' Cc: 'FreeBSD Hackers List' Message-id: <59063B5B4D98D311BC0D0001FA7E45220FD091@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > We're seeing it with our ppp link, which uses the kernel level ppp > code. Since it doesn't happen for me often, it is hard to diagnose. > You could set up a 486 (386?) and have it chew on a tonne of ipfw rules. If it is due to ipfw load, you should be able to force the problem to be reproduced by scaling down the hardware. Kees Jan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 9: 7:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id B3101155AC for ; Thu, 9 Dec 1999 09:07:22 -0800 (PST) (envelope-from sepotvin@videotron.ca) Received: from videotron.ca ([207.253.111.89]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.07.30.00.05.p8) with ESMTP id <0FMH00KFXFVRHX@falla.videotron.net> for freebsd-hackers@freebsd.org; Thu, 9 Dec 1999 11:45:30 -0500 (EST) Date: Thu, 09 Dec 1999 11:43:52 -0500 From: "Stephane E. Potvin" Subject: ifconfig panic using 3C574 card To: freebsd-hackers@freebsd.org Cc: Warner Losh Message-id: <384FDC48.C5EC7804@videotron.ca> Organization: InnoMediaLogic Inc. MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.7 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just upgraded my laptop to use a fresh current from this morning (fresh checkout with empty /usr/obj). The machine is an IBM ThinkPad 760XD with 88Mb RAM. Now when the ep driver attaches my 3COM 3C574 it reports the following mac address: ep0: <3Com 3C574> at port 0x240-0x25f irq 10 slot 0 on pccard0 ep0: Ethernet address 40:57:40:57:40:57 ep0: strange connector type in EEPROM: assuming AUI The error is mostly harmless as the card is functionning otherwise. (I'm not speaking about performances which are not very good right now). Now to the subject, when I run ifconfig on the machine, I instantly got the following panics. I guess that the second one is only an artefact of the first one and should not be considered. dmesg, pccardc dumpcis and config file follows. If you need anything else let me know. I'll try to look into this as soon as I get a few minutes (well, when I get the damn video console working on my 'winder). Steph Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0x0 stack pointer = 0x10:0xc71a6de8 frame pointer = 0x10:0xc71a6e0c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 266 (ifconfig) interrupt mask = net kernel: type 12 trap, code=0 Stopped at 0: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01bc10c stack pointer = 0x10:0xc71a6c54 frame pointer = 0x10:0xc71a6c58 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resule, IOPL = 0 current process = 266 (ifconfig) interrupt mask = net kernel: type 12 trap, code=0 symbols near 0xc01bc10c: c01bc0f0 T db_read_bytes c01bc128 T db_write_bytes dmesg output: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #1: Thu Dec 9 08:39:31 EST 1999 spotvin@alexis.videotron.ca:/mnt/.0/src/sys/compile/AZIMOV Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P55C (165.79-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x544 Stepping = 4 Features=0x8001bf real memory = 92274688 (90112K bytes) avail memory = 86859776 (84824K bytes) Preloaded elf kernel "kernel" at 0xc0269000. Intel Pentium detected, installing workaround for F00F bug npx0: on motherboard npx0: INT 16 interface apm0: on motherboard apm: found APM BIOS v1.2, connected at v1.2 pcib0: on motherboard pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 pcic-pci0: at device 2.0 on pci0 pcic-pci1: at device 2.1 on pci0 vga-pci0: irq 11 at device 3.0 on pci0 pci0: unknown card (vendor=0x1014, dev=0x0057) at 5.0 irq 11 atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 ata0 at port 0x1f0 irq 14 on isa0 fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold pcic: polling, can't alloc 0 pcic: polling, can't alloc 0 pcic0: on isa0 pccard0: on pcic0 pccard1: on pcic0 vga0: at port 0x3b0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A ppc0 at port 0x3bc-0x3c3 irq 7 on isa0 isa_compat: didn't get ports for ppc ppc0: PC87334 chipset (ECP/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold lpt0: on ppbus 0 lpt0: Interrupt-driven port ad0: ATA-3 disk at ata0 as master ad0: 2937MB (6015744 sectors), 5968 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 1 depth queue, PIO acd0: CDROM drive at ata0 as slave acd0: read 1377KB/s (1377KB/s), 256KB buffer, PIO acd0: supported read types: acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm data disc loaded, unlocked Mounting root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted pccard: card inserted, slot 0 ep0: <3Com 3C574> at port 0x240-0x25f irq 10 slot 0 on pccard0 ep0: Ethernet address 40:57:40:57:40:57 ep0: strange connector type in EEPROM: assuming AUI 'pccardc dumpcis' output: Configuration data for card in slot 0 Tuple #1, code = 0x1 (Common memory descriptor), length = 2 000: 00 ff Common memory device information: Device number 1, type No device, WPS = OFF Speed = No speed, Memory block size = reserved, 32 units Tuple #2, code = 0x17 (Attribute memory descriptor), length = 3 000: 43 02 ff Attribute memory device information: Device number 1, type EEPROM, WPS = OFF Speed = 150nS, Memory block size = 8Kb, 1 units Tuple #3, code = 0x20 (Manufacturer ID), length = 4 000: 01 01 74 05 PCMCIA ID = 0x101, OEM ID = 0x574 Tuple #4, code = 0x21 (Functional ID), length = 2 000: 06 00 Network/LAN adapter Tuple #5, code = 0x15 (Version 1 info), length = 46 000: 04 01 33 43 6f 6d 00 33 43 35 37 34 2d 54 58 20 010: 46 61 73 74 20 45 74 68 65 72 4c 69 6e 6b 20 50 020: 43 20 43 61 72 64 00 41 00 30 30 31 00 ff Version = 4.1, Manuf = [3Com],card vers = [3C574-TX Fast EtherLink PC Card] Addit. info = [A],[001] Tuple #6, code = 0x1a (Configuration map), length = 6 000: 02 03 00 00 01 03 Reg len = 3, config register addr = 0x10000, last config = 0x3 Registers: XX------ Tuple #7, code = 0x1b (Configuration entry), length = 15 000: c1 01 1d 71 55 35 55 54 e0 72 5d 65 30 ff ff Config index = 0x1(default) Interface byte = 0x1 (I/O) Vcc pwr: Nominal operating supply voltage: 5 x 1V Max current average over 1 second: 3 x 10mA Max current average over 10 ms: 5 x 10mA Power down supply current: 5 x 1mA Wait scale Speed = 7.0 x 100 ns RDY/BSY scale Speed = 7.0 x 100 ns Card decodes 18 address lines, full 8/16 Bit I/O IRQ modes: Level, Pulse IRQs: IOCK 1 4 5 6 8 10 11 12 14 Tuple #8, code = 0x19 (JEDEC descr for attribute memory), length = 3 000: 00 00 ff Tuple #9, code = 0x14 (No link), length = 0 Tuple #10, code = 0x10 (Checksum), length = 5 000: 9d ff 6c 00 00 Checksum from offset -99, length 108, value is 0x0 Tuple #11, code = 0xff (Terminator), length = 122 000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 050: ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 060: 00 00 00 00 74 00 00 00 02 00 07 00 62 01 1b 00 070: 00 00 86 10 ff ff 00 00 10 20 2 slots found config file: # # ALEXIS - kernel configuration fle # machine i386 cpu I586_CPU ident ALEXIS maxusers 32 makeoptions DEBUG=-g options INCLUDE_CONFIG_FILE options CPU_FASTER_5X86_FPU options COMPAT_43 options USER_LDT options SYSVSHM options SYSVSEM options SYSVMSG options DDB options KTRACE options UCONSOLE options INET options ICMP_BANDLIM options FFS options FFS_ROOT options SOFTUPDATES options MSGBUF_SIZE=32768 options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L options PSM_HOOKAPM options PSM_RESETAFTERSUSPEND options PCIC_RESUME_RESET pseudo-device ether pseudo-device loop pseudo-device bpf pseudo-device pty pseudo-device speaker pseudo-device gzip controller isa0 controller pnp0 controller atkbdc0 at isa? port IO_KBD controller ata0 at isa? port IO_WD1 irq 14 controller fdc0 at isa? port IO_FD1 irq 6 drq 2 controller pci0 controller smbus0 controller intpm0 controller ppbus0 controller card0 controller pcic0 at isa? controller pcic1 at isa? device atkbd0 at atkbdc? irq 1 device vga0 at isa? port? conflicts device sc0 at isa? device npx0 at nexus? port IO_NPX irq 13 device atadisk0 device atapicd0 device fd0 at fdc0 drive 0 device sio0 at isa? port IO_COM1 irq 4 device smb0 at smbus? device lpt0 device ppc0 at isa? port? irq 7 device psm0 at atkbdc? irq 12 device ep0 device apm0 -- Stephane E. Potvin InnoMediaLogic Inc. - http://www.multichassis.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 9:22: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from houston.matchlogic.com (houston.matchlogic.com [205.216.147.127]) by hub.freebsd.org (Postfix) with ESMTP id D3DBD1563B for ; Thu, 9 Dec 1999 09:21:59 -0800 (PST) (envelope-from crandall@matchlogic.com) Received: by houston.matchlogic.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Dec 1999 10:21:57 -0700 Message-ID: <64003B21ECCAD11185C500805F31EC0304D96AE8@houston.matchlogic.com> From: Charles Randall To: freebsd-hackers@freebsd.org Subject: Veritas Software Now Shipping With Linux Date: Thu, 9 Dec 1999 10:21:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG http://news.excite.com/news/r/991209/09/tech-veritas-linux Veritas Software Now Shipping With Linux MOUNTAIN VIEW, Calif. (Reuters) Veritas Software Corp. (VRTS.O) said on Thursday its software used to backup data on computer systems is being shipped with Red Hat Inc.'s Linux 6.1 Delux product. "This is the first step as a result of the agreement we announced in early November to jointly develop enterprise storage management solutions for the Red Hat Linux marketplace," Paul McNamara, general manager of the enterprise business unit at Red Hat, said. Linux is a free version of the Unix operating system that was developed by Finnish programmer Linus Torvalds and a network of programmers. It is an alternative to Microsoft Corp.'s Windows NT for some applications. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 9:24:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from blackbox.csres.utexas.edu (blackbox.csres.utexas.edu [128.83.141.207]) by hub.freebsd.org (Postfix) with ESMTP id 52EB41564C for ; Thu, 9 Dec 1999 09:24:16 -0800 (PST) (envelope-from emery@cs.utexas.edu) Received: from cs.utexas.edu (localhost [127.0.0.1]) by blackbox.csres.utexas.edu (8.9.3/8.9.3) with ESMTP id LAA17253; Thu, 9 Dec 1999 11:24:13 -0600 Message-ID: <384FE5BD.8C0B4A88@cs.utexas.edu> Date: Thu, 09 Dec 1999 11:24:13 -0600 From: Emery Berger Organization: University of Texas at Austin X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Cc: Rayson Ho Subject: Re: Faster Malloc Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: (regarding Hoard: ) > This allocator is pretty much what the Dynix allocator is, it wouldn't be > difficult to clean-room implement this with a BSD license. > > They should have given credit to Dynix or at least Uresh Vahalia > (discussed on page 390 of his book Unix Internals section 12.9). Hi all, The DYNIX kernel allocator was by McKenney and Slingwine, and I'll be citing them in a revised version of the paper. While there are a number of differences between my allocator (Hoard) and theirs, the most important are locality related. I'll just bring up one here: false sharing. Using the McKenney & Slingwine allocator (or the new Cilk allocator, discussed in my paper), a cache line can end up distributed across every CPU's free list and repeatedly re-used. This happens because freed blocks are placed back on a CPU's own freelist. This effect has been observed in practice and can dramatically worsen application performance. Hoard prevents this effect. Each superblock is owned by exactly one processor. When processor A free()'s a block from another CPU's superblock, it is put back in the superblock, and so will not be re-used by processor A's next malloc(). Regards, -- Emery -- Emery Berger | Parallel Programming emery@cs.utexas.edu | & Multiprogramming MP Groups | University of Texas at Austin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 9:40: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 608) id 2E5701500F; Thu, 9 Dec 1999 09:40:01 -0800 (PST) From: "Jonathan M. Bresler" To: ralph.utbult@gbg.abf.se Cc: freebsd-hackers@freebsd.org In-reply-to: <19991209113526.98522155CC@hub.freebsd.org> (message from Ralph Utbult on Thu, 9 Dec 1999 03:35:26 -0800 (PST)) Subject: Re: firewall problem? Message-Id: <19991209174001.2E5701500F@hub.freebsd.org> Date: Thu, 9 Dec 1999 09:40:01 -0800 (PST) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG your ip address 62.20.54.54 is not in DNS, you must have your address in DNS. we do not accept email from machines that do not have entries in DNS. amny spammer use addresses that do not appear in DNS jmb > Delivered-To: jmb@hub.freebsd.org > Delivered-To: freebsd-hackers@freebsd.org > X-Mailer: TjohooMAIL > X-WebsiteUser-IP: 62.20.54.54 > From: Ralph Utbult > Reply-To: ralph.utbult@gbg.abf.se > MIME-Version: 1.0 > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: Quoted-printable > Date: Thu, 9 Dec 1999 03:35:26 -0800 (PST) > Sender: owner-freebsd-hackers@FreeBSD.ORG > X-Loop: FreeBSD.ORG > Precedence: bulk > > Hi > > I=B4m sitting behind a firewall consisting av FreeBsd and Squid. My mail pr= > ogram is Popper. I can mail to (and from) every adress I=B4ve tried - excep= > t freebsd.org. Here=B4s the error. > The original message was received at Wed, 8 Dec 1999 16:40:08 +0100 (CET) > from [192.168.1.2] > > > ----- The following addresses had transient non-fatal errors ----- > > > > ----- Transcript of session follows ----- > .. while talking to hub.freebsd.org.: > >>> RCPT To: > <<< 450 Client host rejected: cannot find your hostname, [62.20.54.54] > ... Deferred: 450 Client host rejected: cannot= > find your hostname, [62.20.54.54] > Warning: message still undelivered after 4 hours > Will keep trying until message is 5 days old > Reporting-MTA: dns; hyndan.gbg.abf.se > Arrival-Date: Wed, 8 Dec 1999 16:40:08 +0100 (CET) > > > Final-Recipient: RFC822; freebsd-hackers@FreeBSD.ORG > Action: delayed > Status: 4.2.0 > Remote-MTA: DNS; hub.freebsd.org > Diagnostic-Code: SMTP; 450 Client host rejected: cannot find your hostname,= > [62.20.54.54] > Last-Attempt-Date: Wed, 8 Dec 1999 20:52:11 +0100 (CET) > Will-Retry-Until: Mon, 13 Dec 1999 16:40:08 +0100 (CET) > Return-Path: > Received: from ralph ([192.168.1.2]) > by hyndan.gbg.abf.se (8.9.3/8.9.3) with ESMTP id QAA63400; > Wed, 8 Dec 1999 16:40:08 +0100 (CET) > Message-Id: <4.2.0.58.19991208174502.00a65820@192.168.1.1> > X-Sender: ralph@192.168.1.1 > X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 > Date: Wed, 08 Dec 1999 17:45:52 +0100 > To: ralphtest@gbg.abf.se > From: Ralph Utbult > Subject: Test - ignore! > Cc: freebsd-hackers@FreeBSD.ORG > Mime-Version: 1.0 > Content-Type: text/plain; charset=3D"iso-8859-1"; format=3Dflowed > > What is the problem? > > Regards, > Ralph Utbult > Systems Operator > ABF G=F6teborg > Sweden > ____________________________________ > Gratis epost med TJOHOOMAIL > http://www.tjohoo.se > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 9:48:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.144.32]) by hub.freebsd.org (Postfix) with ESMTP id BCBB514CE4 for ; Thu, 9 Dec 1999 09:48:56 -0800 (PST) (envelope-from dwhite@resnet.uoregon.edu) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.9.3/8.9.3) with ESMTP id JAA80365; Thu, 9 Dec 1999 09:48:43 -0800 (PST) (envelope-from dwhite@resnet.uoregon.edu) Date: Thu, 9 Dec 1999 09:48:42 -0800 (PST) From: Doug White To: Robert Watson Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: question about boot loaders In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 9 Dec 1999, Robert Watson wrote: > loader loadedby function > -------------------------------- > mbr BIOS whatever, maybe a couple of lines /boot/mbr is a copy of the classic DOS MBR code. Used by fdisk. Simply loads the partition marked as 'active' (flag 0x80). Everything else was covered in Neil's handbook piece (which I should probably grab & commit! :-) ) Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 9:53:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from test.tar.com (test.tar.com [204.95.187.4]) by hub.freebsd.org (Postfix) with ESMTP id C3FB1155E5 for ; Thu, 9 Dec 1999 09:53:28 -0800 (PST) (envelope-from dick@test.tar.com) Received: (from dick@localhost) by test.tar.com (8.9.3/8.9.3) id LAA02474; Thu, 9 Dec 1999 11:53:17 -0600 (CST) (envelope-from dick) Date: Thu, 9 Dec 1999 11:53:17 -0600 From: "Richard Seaman, Jr." To: Jason Evans Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Possible libc changes to support LinuxThreads Message-ID: <19991209115317.B782@tar.com> References: <19991209003517.E73529@sturm.canonware.com> <19991209064256.B34152@tar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <19991209064256.B34152@tar.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Dec 09, 1999 at 06:42:56AM -0600, Richard Seaman, Jr. wrote: > In this case, you'd want, for example, an _lseek(), _libc_lseek(), > and _seek(). I meant "and lseek()", not _seek(). -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 10:17:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E109E1567E for ; Thu, 9 Dec 1999 10:17:08 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.8.7/8.8.7) with ESMTP id KAA30876; Thu, 9 Dec 1999 10:18:13 -0800 Date: Thu, 9 Dec 1999 10:18:13 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Charles Randall Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Veritas Software Now Shipping With Linux In-Reply-To: <64003B21ECCAD11185C500805F31EC0304D96AE8@houston.matchlogic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yes- this also concerned and annoyed the folks at Legato. It puts *me* in a bit of a bind because I have had business ties to both companies (I still do (at a very slow rate) Legato NetWorker client packages for *BSD and non-Intel Linux). On Thu, 9 Dec 1999, Charles Randall wrote: > http://news.excite.com/news/r/991209/09/tech-veritas-linux > > Veritas Software Now Shipping With Linux > > MOUNTAIN VIEW, Calif. (Reuters) Veritas Software > Corp. (VRTS.O) said on Thursday its software used to backup > data on computer systems is being shipped with Red Hat > Inc.'s Linux 6.1 Delux product. > > "This is the first step as a result of the agreement we > announced in early November to jointly develop enterprise > storage management solutions for the Red Hat Linux > marketplace," Paul McNamara, general manager of the > enterprise business unit at Red Hat, said. Linux is a free > version of the Unix operating system that was developed by > Finnish programmer Linus Torvalds and a network of > programmers. It is an alternative to Microsoft Corp.'s > Windows NT for some applications. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 12: 4:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from www.geocrawler.com (sourceforge.net [209.81.8.17]) by hub.freebsd.org (Postfix) with ESMTP id 69BE614C04 for ; Thu, 9 Dec 1999 12:04:28 -0800 (PST) (envelope-from nobody@www.geocrawler.com) Received: (from nobody@localhost) by www.geocrawler.com (8.9.3/8.9.3) id MAA01629; Thu, 9 Dec 1999 12:04:29 -0800 Date: Thu, 9 Dec 1999 12:04:29 -0800 Message-Id: <199912092004.MAA01629@www.geocrawler.com> To: freebsd-hackers@freebsd.org Subject: printf() from KLD From: "Alex" Reply-To: "Alex" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message was sent from Geocrawler.com by "Alex" Be sure to reply to that address. Hello, I use printf() function from my KLD for debugging. Always, when the kernel call printf, I see two same line, like : Dec 9 15:40:10 techno /kernel: Dec 9 15:40:10 techno /kernel: How can I remvoe second line? Thank you. Geocrawler.com - The Knowledge Archive To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 13: 0:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id 297C914E4F for ; Thu, 9 Dec 1999 13:00:34 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 78265 invoked by uid 1001); 9 Dec 1999 20:57:45 -0000 Date: Thu, 9 Dec 1999 12:57:45 -0800 From: Jason Evans To: "Richard Seaman, Jr." Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Possible libc changes to support LinuxThreads Message-ID: <19991209125745.G73529@sturm.canonware.com> References: <19991209003517.E73529@sturm.canonware.com> <19991209064256.B34152@tar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <19991209064256.B34152@tar.com>; from dick@tar.com on Thu, Dec 09, 1999 at 06:42:56AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Dec 09, 1999 at 06:42:56AM -0600, Richard Seaman, Jr. wrote: > On Thu, Dec 09, 1999 at 12:35:17AM -0800, Jason Evans wrote: > > The problem with cancellation points, libc and linuxthreads has been > that you need to wade through libc and replace instances of, for > example, write() with either _write() or _libc_write() in order to > avoid propagating cancellation points where they don't belong. Now I understand why you claimed that making cancellation work is a lot of work. Since that isn't currently done, do you think it would be better to leave broken cancellation in the LinuxThreads port, or to take it out? As things stand right now, "broken" means: 1) Not all mandatory cancellation points are implemented. 2) Some functions may act as cancellation points, even though they shouldn't. We can fix 1) with some symbol munging, but 2) is much more difficult, as you point out. > > The other issue has to do with longjmp() and siglongjmp(), and is of a > > similar nature, except that _longjmp() already exists as a separate > > interface. So, at least in the case of longjmp(), it needs to have a > > different alias, perhaps __longjmp(). Below is a *very* simplistic patch > > to libc that works, but it may make some people's skin crawl. Feedback is > > welcome. If there is no correct way to create aliases to function entry > > points, then we can do without them, but it will mean that the *jmp() > > functions cannot be used in conjunction with thread cleanup handlers when > > using LinuxThreads. > > __longjmp() and __siglongjmp() don't bother me at all. Following is a slightly better patch that uses weak aliases. longjmp() must be an alias for __longjmp() since _longjmp() is a public interface. However, siglongjmp() could be an alias for either _siglongjmp() or __siglongjmp(). Is _siglongjmp() more consistent? Of course, this doesn't matter at all if we leave out cancellation entirely. Index: i386/gen/setjmp.S =================================================================== RCS file: /home/ncvs/src/lib/libc/i386/gen/setjmp.S,v retrieving revision 1.11 diff -u -r1.11 setjmp.S --- setjmp.S 1999/10/10 08:38:33 1.11 +++ setjmp.S 1999/12/09 20:53:11 @@ -54,7 +54,9 @@ #include "DEFS.h" #include "SYS.h" -ENTRY(setjmp) +ENTRY(__setjmp) +.weak setjmp; +.set setjmp, __setjmp; movl 4(%esp),%ecx PIC_PROLOGUE leal 28(%ecx), %eax @@ -80,7 +82,9 @@ xorl %eax,%eax ret -ENTRY(longjmp) +ENTRY(__longjmp) +.weak longjmp; +.set longjmp, __longjmp; movl 4(%esp),%edx PIC_PROLOGUE pushl $0 /* (sigset_t*)oset */ Index: i386/gen/sigsetjmp.S =================================================================== RCS file: /home/ncvs/src/lib/libc/i386/gen/sigsetjmp.S,v retrieving revision 1.13 diff -u -r1.13 sigsetjmp.S --- sigsetjmp.S 1999/09/29 15:18:35 1.13 +++ sigsetjmp.S 1999/12/09 20:53:11 @@ -59,7 +59,9 @@ * use sigreturn() if sigreturn() works. */ -ENTRY(sigsetjmp) +ENTRY(__sigsetjmp) +.weak sigsetjmp; +.set sigsetjmp, __sigsetjmp; movl 8(%esp),%eax movl 4(%esp),%ecx movl %eax,44(%ecx) @@ -89,7 +91,9 @@ xorl %eax,%eax ret -ENTRY(siglongjmp) +ENTRY(__siglongjmp) +.weak siglongjmp; +.set siglongjmp, __siglongjmp; movl 4(%esp),%edx cmpl $0,44(%edx) jz 2f To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 13:22: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 4E254156C9 for ; Thu, 9 Dec 1999 13:22:03 -0800 (PST) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id MAA02691; Thu, 9 Dec 1999 12:25:14 -0800 (PST) From: Archie Cobbs Message-Id: <199912092025.MAA02691@bubba.whistle.com> Subject: Re: printf() from KLD In-Reply-To: <199912092004.MAA01629@www.geocrawler.com> from Alex at "Dec 9, 1999 12:04:29 pm" To: al.feldman@sangoma.com (Alex) Date: Thu, 9 Dec 1999 12:25:14 -0800 (PST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alex writes: > This message was sent from Geocrawler.com by "Alex" > Be sure to reply to that address. > > Hello, > > I use printf() function from my KLD for > debugging. Always, when the kernel call printf, I > see two same line, like : > Dec 9 15:40:10 techno /kernel: > Dec 9 15:40:10 techno /kernel: > > How can I remvoe second line? > Thank you. man syslog.conf Your message is matching more than one rule (eg, "root" and "console"). -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 13:25:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id EA09D15687 for ; Thu, 9 Dec 1999 13:25:37 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id QAA08177; Thu, 9 Dec 1999 16:25:26 -0500 (EST) Date: Thu, 9 Dec 1999 16:25:26 -0500 (EST) From: Daniel Eischen Message-Id: <199912092125.QAA08177@pcnet1.pcnet.com> To: dick@tar.com, jasone@canonware.com Subject: Re: Possible libc changes to support LinuxThreads Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jason Evans wrote: > On Thu, Dec 09, 1999 at 06:42:56AM -0600, Richard Seaman, Jr. wrote: > > On Thu, Dec 09, 1999 at 12:35:17AM -0800, Jason Evans wrote: > > > > The problem with cancellation points, libc and linuxthreads has been > > that you need to wade through libc and replace instances of, for > > example, write() with either _write() or _libc_write() in order to > > avoid propagating cancellation points where they don't belong. > > Now I understand why you claimed that making cancellation work is a lot of > work. Since that isn't currently done, do you think it would be better to > leave broken cancellation in the LinuxThreads port, or to take it out? As > things stand right now, "broken" means: > > 1) Not all mandatory cancellation points are implemented. > 2) Some functions may act as cancellation points, even though they > shouldn't. > > We can fix 1) with some symbol munging, but 2) is much more difficult, as > you point out. Have you looked at what NetBSD did with namespace? See: http://www.freebsd.org/cgi/cvsweb.cgi/basesrc/lib/libc/include/namespace.h?rev=1.42&cvsroot=netbsd Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 13:27:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 82A7414FF8 for ; Thu, 9 Dec 1999 13:27:24 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id NAA98335; Thu, 9 Dec 1999 13:27:17 -0800 (PST) Date: Thu, 9 Dec 1999 13:27:16 -0800 (PST) From: Julian Elischer To: Etienne De Bruin Cc: hackers@FreeBSD.ORG Subject: Re: Sequence of Events in Kernel source? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 9 Dec 1999, Etienne De Bruin wrote: > > > Greetings Seniors. > > I am interested in establishing the sequence of events from a source code > perspective from when the PC is switched on, to the login prompt. I am > specifically interested in the setting up of lower level stuff like the drivers. > memory etc. > > Can anyone please take a moment and give me some pointers? > > Kind regards > > eT > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > check the old bootblocks /usr/src/sys/i386/boot/biosboot for README.386BSD, README.MACH, README.serial for some background. then try find documentation (good luck) on the NEW bootblocks /usr/src/sys/boot/README is a start. The kernel starts in /sys/i386/i386/locore.s (at btext I think) then goes (from memory) to main() via mi_startup (I think). mi_startup is in init_main.c. mi_startup calls all teh initialisation modules linked into the kernel. (see kernel.h) eventually it starts up init.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 13:30:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from test.tar.com (test.tar.com [204.95.187.4]) by hub.freebsd.org (Postfix) with ESMTP id 5BF3915377 for ; Thu, 9 Dec 1999 13:30:51 -0800 (PST) (envelope-from dick@test.tar.com) Received: (from dick@localhost) by test.tar.com (8.9.3/8.9.3) id PAA03178; Thu, 9 Dec 1999 15:30:42 -0600 (CST) (envelope-from dick) Date: Thu, 9 Dec 1999 15:30:42 -0600 From: "Richard Seaman, Jr." To: Jason Evans Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Possible libc changes to support LinuxThreads Message-ID: <19991209153042.C782@tar.com> References: <19991209003517.E73529@sturm.canonware.com> <19991209064256.B34152@tar.com> <19991209125745.G73529@sturm.canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <19991209125745.G73529@sturm.canonware.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Dec 09, 1999 at 12:57:45PM -0800, Jason Evans wrote: > On Thu, Dec 09, 1999 at 06:42:56AM -0600, Richard Seaman, Jr. wrote: > > On Thu, Dec 09, 1999 at 12:35:17AM -0800, Jason Evans wrote: > > > > The problem with cancellation points, libc and linuxthreads has been > > that you need to wade through libc and replace instances of, for > > example, write() with either _write() or _libc_write() in order to > > avoid propagating cancellation points where they don't belong. > > Now I understand why you claimed that making cancellation work is a lot of > work. Since that isn't currently done, do you think it would be better to > leave broken cancellation in the LinuxThreads port, or to take it out? As > things stand right now, "broken" means: > > 1) Not all mandatory cancellation points are implemented. > 2) Some functions may act as cancellation points, even though they > shouldn't. > > We can fix 1) with some symbol munging, but 2) is much more difficult, as > you point out. I think #2 above is very dangerous, since you can get a cancellation point unexpectedly while the thread holds resources (eg a lock). If you cancel while holding a lock, you could deadlock. This could even happen within libc, where (for example) fread puts a lock around the read syscall. If read is a cancellation point, the libc lock for the FILE pointer won't get released (at least I don't think it will). A user app could have the same problem if there are unexpected cancellation points. The original linuxthreads port left the cancellation functions in, but didn't do any syscall wrapping to implement libc cancellation points. A user app can create cancellation points with pthread_test_cancel(), which helps a little, but he doesn't get the POSIX libc cancellation points. Actually, I don't think all that many apps use pthread_cancel(). Its kind of messy to use. Most can get along without it, which is why there have only been a limited number of complaints about the lack of pthread_cancel() in libc_r (until recently). BTW, I haven't looked at libc_r's new cancellation functions. How do they avoid propagating cancellation points in libc without changing libc? Maybe they have an idea that can be used here? -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 13:41:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by hub.freebsd.org (Postfix) with ESMTP id 1BF71156B6 for ; Thu, 9 Dec 1999 13:41:53 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id NAA01239; Thu, 9 Dec 1999 13:43:35 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912092143.NAA01239@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Robert Watson Cc: freebsd-hackers@freebsd.org Subject: Re: question about boot loaders In-reply-to: Your message of "Thu, 09 Dec 1999 02:46:45 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Dec 1999 13:43:35 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The documentation in /usr/src/sys/boot/i386 seems a little scant, and that > still hanging out in /usr/src/sys/i386/boot is clearly outdated. Was > wondering if someone could point me at docs, and/or post a short summary > something in the form of: http://www.freebsd.org/~msmith/FTL/tutorials/bootloader.txt It's incomplete and a little out of date, but I think it covers the questions you're asking. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 14: 5:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by hub.freebsd.org (Postfix) with ESMTP id 1C00D156F1 for ; Thu, 9 Dec 1999 14:05:27 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id OAA01568; Thu, 9 Dec 1999 14:07:43 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912092207.OAA01568@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Alex" Cc: freebsd-hackers@freebsd.org Subject: Re: printf() from KLD In-reply-to: Your message of "Thu, 09 Dec 1999 12:04:29 PST." <199912092004.MAA01629@www.geocrawler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Dec 1999 14:07:43 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This message was sent from Geocrawler.com by "Alex" > Be sure to reply to that address. > > Hello, > > I use printf() function from my KLD for > debugging. Always, when the kernel call printf, I > see two same line, like : > Dec 9 15:40:10 techno /kernel: > Dec 9 15:40:10 techno /kernel: > > How can I remvoe second line? Read the manpages related to syslogd(8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 14:22:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bytor.rush.net (bytor.rush.net [209.45.245.145]) by hub.freebsd.org (Postfix) with ESMTP id 0F6A915242; Thu, 9 Dec 1999 14:22:54 -0800 (PST) (envelope-from lynch@bsdunix.net) Received: from localhost (lynch@localhost) by bytor.rush.net (8.9.3/8.9.3) with ESMTP id RAA22719; Thu, 9 Dec 1999 17:22:42 -0500 (EST) Date: Thu, 9 Dec 1999 17:22:41 -0500 (EST) From: Pat Lynch X-Sender: lynch@bytor.rush.net To: Ed Hall Cc: Matthew Dillon , "Jonathan M. Bresler" , kris@hub.freebsd.org, freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-Reply-To: <199912062126.NAA30946@screech.weirdnoise.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG We are having a similar problem at the job I just started. A box meeting the exact specifications that Mike said caused the problem is essentially having the crap beat out of it as far as disk access and network activity (it might help to also say that this company is rather large in the scheme of things and would be a good example of how to use FreeBSD in a large enterprise environment). It is the only box out of alot of them having this problem, but its also the only one thats getting beat up as much as this one. it would be great if Peter could post his "patch" for the problem (how to migrate the -CURRENT driver into the 3.3 source) from what you say, Ed, it stands up a bit better than the current driver does, and can only probably get better. While this machine will probably be replaced with a different machine, FreeBSD is somewhat of a "Pride and Joy" here. -Pat -- Pat Lynch lynch@rush.net lynch@bsdunix.net Systems Administrator Rush Networking To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 14:41:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id B3F0A15097 for ; Thu, 9 Dec 1999 14:41:12 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id RAA19312; Thu, 9 Dec 1999 17:41:09 -0500 (EST) Date: Thu, 9 Dec 1999 17:41:09 -0500 (EST) From: Daniel Eischen Message-Id: <199912092241.RAA19312@pcnet1.pcnet.com> To: dick@tar.com, jasone@canonware.com Subject: Re: Possible libc changes to support LinuxThreads Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Richard Seaman, Jr. wrote: > Actually, I don't think all that many apps use pthread_cancel(). > Its kind of messy to use. Most can get along without it, which > is why there have only been a limited number of complaints about > the lack of pthread_cancel() in libc_r (until recently). BTW, > I haven't looked at libc_r's new cancellation functions. How do > they avoid propagating cancellation points in libc without > changing libc? Maybe they have an idea that can be used here? Hi Richard, Libc_r doesn't avoid propagating cancellation points. A read() from within a libc(_r) function will still be a cancellation point. We had to weigh the lack of having pthread_cancel() versus having pthread_cancel() with non-standard cancellation points. In the end, only those applications that use pthread_cancel() are affected. I think the number of complaints saying "Hey, pthread_cancel support has non-standard cancellation points" will be less than the number of complaints because we don't have _any_ pthread_cancel support. Well, that's what I hope anyways ;-) Time will probably prove me wrong... Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 14:49:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from test.tar.com (test.tar.com [204.95.187.4]) by hub.freebsd.org (Postfix) with ESMTP id 80A831527E for ; Thu, 9 Dec 1999 14:49:15 -0800 (PST) (envelope-from dick@test.tar.com) Received: (from dick@localhost) by test.tar.com (8.9.3/8.9.3) id QAA03510; Thu, 9 Dec 1999 16:48:54 -0600 (CST) (envelope-from dick) Date: Thu, 9 Dec 1999 16:48:54 -0600 From: "Richard Seaman, Jr." To: Daniel Eischen Cc: dick@tar.com, jasone@canonware.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Possible libc changes to support LinuxThreads Message-ID: <19991209164854.E782@tar.com> References: <199912092241.RAA19312@pcnet1.pcnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <199912092241.RAA19312@pcnet1.pcnet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Dec 09, 1999 at 05:41:09PM -0500, Daniel Eischen wrote: > Richard Seaman, Jr. wrote: > > Actually, I don't think all that many apps use pthread_cancel(). > > Its kind of messy to use. Most can get along without it, which > > is why there have only been a limited number of complaints about > > the lack of pthread_cancel() in libc_r (until recently). BTW, > > I haven't looked at libc_r's new cancellation functions. How do > > they avoid propagating cancellation points in libc without > > changing libc? Maybe they have an idea that can be used here? > > Hi Richard, > > Libc_r doesn't avoid propagating cancellation points. A read() > from within a libc(_r) function will still be a cancellation > point. Hmm.. What happens with (for example) fread() ? fread, in the thread safe version, can be: lock FILE pointer read unlock FILE pointer If fread is a cancellation point, don't you end up with the lock held still? Or, I guess since you keep track of lock owners you can unwind the locks if the thread cancels? -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 14:59: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id A43B1156E2 for ; Thu, 9 Dec 1999 14:59:03 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id RAA21820; Thu, 9 Dec 1999 17:59:01 -0500 (EST) Date: Thu, 9 Dec 1999 17:59:00 -0500 (EST) From: Daniel Eischen To: "Richard Seaman, Jr." Cc: jasone@canonware.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Possible libc changes to support LinuxThreads In-Reply-To: <19991209164854.E782@tar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 9 Dec 1999, Richard Seaman, Jr. wrote: > On Thu, Dec 09, 1999 at 05:41:09PM -0500, Daniel Eischen wrote: > > Richard Seaman, Jr. wrote: > > > Actually, I don't think all that many apps use pthread_cancel(). > > > Its kind of messy to use. Most can get along without it, which > > > is why there have only been a limited number of complaints about > > > the lack of pthread_cancel() in libc_r (until recently). BTW, > > > I haven't looked at libc_r's new cancellation functions. How do > > > they avoid propagating cancellation points in libc without > > > changing libc? Maybe they have an idea that can be used here? > > > > Hi Richard, > > > > Libc_r doesn't avoid propagating cancellation points. A read() > > from within a libc(_r) function will still be a cancellation > > point. > > Hmm.. > > What happens with (for example) fread() ? > > fread, in the thread safe version, can be: > > lock FILE pointer > read > unlock FILE pointer > > If fread is a cancellation point, don't you end up with > the lock held still? Or, I guess since you keep track of > lock owners you can unwind the locks if the thread cancels? Yes, we keep track of all internal locks and release them when the thread is cancelled. The only think not released just yet are standalone (not part of other locks, like file, mutex, condvar, etc) spinlocks. For instance the spinlock that protects malloc() wouldn't be released. It's easy enough to fix those with setting/clearing of lock wanted flags and/or held lock counts, but I'd thought I'd try to borrow a trick from the SA paper. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 17: 1:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 3B8A11572D; Thu, 9 Dec 1999 17:01:39 -0800 (PST) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id RAA76788; Thu, 9 Dec 1999 17:01:39 -0800 (PST) From: Archie Cobbs Message-Id: <199912100101.RAA76788@bubba.whistle.com> Subject: Crypto in the kernel: where & how? To: cvs-committers@freebsd.org, freebsd-hackers@freebsd.org Date: Thu, 9 Dec 1999 17:01:38 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What is the plan (if any) for including crypto stuff in the kernel? As time goes on this will be more and more needed, eg. for IPSec and other VPN applications. It would be nice if we had a /usr/src/sys/crypt directory, plus whatever export-controlled firewalling silliness is necessary. Proposal.. (to get things started) - Add /usr/src/sys/crypt directory - Put exportable crypto stuff in it, eg, md5.c. - Put non-exportable crypto stuff in the international repository (which is where?) .. and possibly a separate US repository (?) (Or can the CVSup mirrors be configured not to mirror it?) My ulterior motive is to checkin netgrapph/ng_mppc.c which adds MPPE/MPPC support for PPTP. However it's useless without an [A]RC4 implementation. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 17:10:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.33.127]) by hub.freebsd.org (Postfix) with ESMTP id 8D8C01576C; Thu, 9 Dec 1999 17:10:25 -0800 (PST) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id RAA15093; Thu, 9 Dec 1999 17:10:18 -0800 (PST) Message-Id: <199912100110.RAA15093@lestat.nas.nasa.gov> To: Archie Cobbs Cc: cvs-committers@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Crypto in the kernel: where & how? Reply-To: Jason Thorpe From: Jason Thorpe Date: Thu, 09 Dec 1999 17:10:18 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 9 Dec 1999 17:01:38 -0800 (PST) Archie Cobbs wrote: > What is the plan (if any) for including crypto stuff in the kernel? > As time goes on this will be more and more needed, eg. for IPSec > and other VPN applications. At NetBSD, we already solved this problem with some simple changes to our config(8). Also, we put e.g. md5 and sha1 in libkern (the kernel's `libc'), since they're in libc for userland. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 18:24:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id B352315715; Thu, 9 Dec 1999 18:24:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id A29311CD750; Thu, 9 Dec 1999 18:24:47 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Thu, 9 Dec 1999 18:24:47 -0800 (PST) From: Kris Kennaway To: Archie Cobbs Cc: cvs-committers@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Crypto in the kernel: where & how? In-Reply-To: <199912100101.RAA76788@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 9 Dec 1999, Archie Cobbs wrote: > It would be nice if we had a /usr/src/sys/crypt directory, plus whatever > export-controlled firewalling silliness is necessary. It'd presumably have to be /usr/src/secure/sys to fit with our existing distribution infrastructure. > - Add /usr/src/sys/crypt directory ^o > - Put exportable crypto stuff in it, eg, md5.c. > - Put non-exportable crypto stuff in the international repository > (which is where?) internat.freebsd.org, in south africa > .. and possibly a separate US repository (?) > (Or can the CVSup mirrors be configured not to mirror it?) US sites mirror their crypto from freebsd.org, international ones from the international repository. The preferred path is for code to be committed by international people to the international repository, since it can be imported from there back into the US - if we can avoid it we shouldn't commit stuff to the US repository on its own since that prevents most of our users (by geography) from accessing it. However at least in the case of OpenSSL (which I'm planning to import into internat when I go home to australia next week :-) the two will have to be divergent due to the patent restrictions on RSA. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 20:40: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dustdevil.waterspout.com (dustdevil.waterspout.com [208.13.60.151]) by hub.freebsd.org (Postfix) with ESMTP id 6DFE014CF0 for ; Thu, 9 Dec 1999 20:40:08 -0800 (PST) (envelope-from csg@waterspout.com) Received: by dustdevil.waterspout.com (Postfix, from userid 1000) id B50CC59; Thu, 9 Dec 1999 23:43:26 -0500 (EST) Date: Thu, 9 Dec 1999 23:43:26 -0500 From: "C. Stephen Gunn" To: freebsd-hackers@freebsd.org Subject: Re: Upgrading rdist to v6.1.5 in -CURRENT? Message-ID: <19991209234326.A60134@dustdevil.waterspout.com> References: <19991208031339.DFCF29F@dustdevil.waterspout.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <19991208031339.DFCF29F@dustdevil.waterspout.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Dec 07, 1999 at 10:13:34PM -0500, C. Stephen Gunn wrote: > I'll send-pr the recipe, and post a reference here when I document > how I worked around some of the magnicomp guys's kludged > makefiles/includes. I've send-pr'd my attempt at getting this ready for import. (bin/15390) You can fetch a tarball (relative to /usr/src) from: http://www.physics.purdue.edu/~csg/rdist-freebsd.tar.gz There's a readme file in what would become contrib/rdist/README-FreeBSD that documents my pruning of the distribution, and applied patches. I was a little disgusted with my soltion for building gram.h from the yacc grammar for rdistd to use. If someone with more make/import experience sees a better solution, let me know. - Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 9 23:42: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id A192F153AB; Thu, 9 Dec 1999 23:41:58 -0800 (PST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.10.0.Beta6/8.10.0.Beta6) with ESMTP id dBA7fgW23996; Fri, 10 Dec 1999 09:41:42 +0200 (SAST) Message-Id: <199912100741.dBA7fgW23996@gratis.grondar.za> To: Archie Cobbs Cc: cvs-committers@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: Crypto in the kernel: where & how? Date: Fri, 10 Dec 1999 09:41:41 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What is the plan (if any) for including crypto stuff in the kernel? > As time goes on this will be more and more needed, eg. for IPSec > and other VPN applications. The KAME/IPv6 guys have already brought this up; the agreement was that... > It would be nice if we had a /usr/src/sys/crypt directory, plus whatever > export-controlled firewalling silliness is necessary. ...a sys/crypt/ directory should hold their DES code. :-) > Proposal.. (to get things started) > > - Add /usr/src/sys/crypt directory The CTM things aleady know about this dir. > My ulterior motive is to checkin netgrapph/ng_mppc.c which adds > MPPE/MPPC support for PPTP. However it's useless without an [A]RC4 > implementation. I'd like DES, arc4 and MD5/SHA for Yarrow. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 0: 6:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by hub.freebsd.org (Postfix) with ESMTP id AEA10153E4; Fri, 10 Dec 1999 00:06:02 -0800 (PST) (envelope-from shin@nd.net.fujitsu.co.jp) Received: from m1.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX9911-Fujitsu Gateway) id RAA22216; Fri, 10 Dec 1999 17:05:54 +0900 (JST) Received: from chisato.nd.net.fujitsu.co.jp by m1.gw.fujitsu.co.jp (8.9.3/3.7W-9912-Fujitsu Domain Master) id RAA28030; Fri, 10 Dec 1999 17:05:53 +0900 (JST) Received: from localhost (dhcp7194.nd.net.fujitsu.co.jp [10.18.7.194]) by chisato.nd.net.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.3W8chisato-970826) with ESMTP id RAA00219; Fri, 10 Dec 1999 17:05:52 +0900 (JST) To: mark@grondar.za Cc: archie@whistle.com, cvs-committers@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: Crypto in the kernel: where & how? In-Reply-To: <199912100741.dBA7fgW23996@gratis.grondar.za> References: <199912100741.dBA7fgW23996@gratis.grondar.za> X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN) X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19991210170614E.shin@nd.net.fujitsu.co.jp> Date: Fri, 10 Dec 1999 17:06:14 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990905(IM130) Lines: 24 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > What is the plan (if any) for including crypto stuff in the kernel? > > As time goes on this will be more and more needed, eg. for IPSec > > and other VPN applications. > > The KAME/IPv6 guys have already brought this up; the agreement was > that... I just prepared IPsec related patches which includes crypto directory, and did kernel build and make world check on my remote machine. But I can't do reboot check because of the wd0 issue. I have not yet succeeded in booting my local machine with ATA disk. My remote machine has only SCSI disks but I'm afraid to reboot it. And I wonder if I can send the patches to lists to solicite comments. By the way, all crypto stuff are put under the sys/crypto dir in the patch. Should some of them put under sys/libkern instead? Yoshinobu Inoue To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 0:14: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id 5A7AE150E4; Fri, 10 Dec 1999 00:13:33 -0800 (PST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.10.0.Beta6/8.10.0.Beta6) with ESMTP id dBA8D8W24430; Fri, 10 Dec 1999 10:13:08 +0200 (SAST) Message-Id: <199912100813.dBA8D8W24430@gratis.grondar.za> To: Yoshinobu Inoue Cc: archie@whistle.com, cvs-committers@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: Crypto in the kernel: where & how? Date: Fri, 10 Dec 1999 10:13:08 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > And I wonder if I can send the patches to lists to solicite > comments. Send them to me if you like :-) > By the way, all crypto stuff are put under the sys/crypto dir > in the patch. Should some of them put under sys/libkern instead? No. Please leave them in sys/crypto/ M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 1: 8:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 2FC6914A14; Fri, 10 Dec 1999 01:08:39 -0800 (PST) (envelope-from jhay@zibbi.mikom.csir.co.za) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.9.3/8.9.3) id LAA17808; Fri, 10 Dec 1999 11:06:46 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <199912100906.LAA17808@zibbi.mikom.csir.co.za> Subject: Re: Crypto in the kernel: where & how? In-Reply-To: <199912100741.dBA7fgW23996@gratis.grondar.za> from Mark Murray at "Dec 10, 1999 09:41:41 am" To: mark@grondar.za (Mark Murray) Date: Fri, 10 Dec 1999 11:06:46 +0200 (SAT) Cc: archie@whistle.com (Archie Cobbs), cvs-committers@FreeBSD.org, freebsd-hackers@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > What is the plan (if any) for including crypto stuff in the kernel? > > As time goes on this will be more and more needed, eg. for IPSec > > and other VPN applications. > > The KAME/IPv6 guys have already brought this up; the agreement was > that... > > > It would be nice if we had a /usr/src/sys/crypt directory, plus whatever > > export-controlled firewalling silliness is necessary. > > ...a sys/crypt/ directory should hold their DES code. :-) ^^^^^ Shouldn't this be crypto ? That is what I see if I look on internat in the /usr/local/etc/cvsup/sup directory. John -- John Hay -- John.Hay@mikom.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 1:13:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id 11ADF15157; Fri, 10 Dec 1999 01:13:21 -0800 (PST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.10.0.Beta6/8.10.0.Beta6) with ESMTP id dBA9CoW24669; Fri, 10 Dec 1999 11:12:50 +0200 (SAST) Message-Id: <199912100912.dBA9CoW24669@gratis.grondar.za> To: John Hay Cc: archie@whistle.com (Archie Cobbs), cvs-committers@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: Crypto in the kernel: where & how? Date: Fri, 10 Dec 1999 11:12:49 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > ...a sys/crypt/ directory should hold their DES code. :-) > ^^^^^ > Shouldn't this be crypto ? That is what I see if I look on internat > in the /usr/local/etc/cvsup/sup directory. So it should, and in the patch that I have, it is :-). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 3:45:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from nets5.rz.rwth-aachen.de (nets5.rz.RWTH-Aachen.DE [137.226.144.13]) by hub.freebsd.org (Postfix) with ESMTP id 656D814D32 for ; Fri, 10 Dec 1999 03:45:39 -0800 (PST) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: from campino.informatik.rwth-aachen.de (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by nets5.rz.rwth-aachen.de (8.9.1a/8.9.1/8) with ESMTP id MAA18524 for ; Fri, 10 Dec 1999 12:45:37 +0100 (MET) Received: from gil.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.30.2]) by campino.informatik.rwth-aachen.de (8.9.1a/8.9.1/3) with ESMTP id MAA09378 for ; Fri, 10 Dec 1999 12:45:37 +0100 (MET) Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.9.3/8.6.9) id MAA07130 for hackers@freebsd.org; Fri, 10 Dec 1999 12:45:41 +0100 (CET) Date: Fri, 10 Dec 1999 12:45:41 +0100 (CET) From: Christoph Kukulies Message-Id: <199912101145.MAA07130@gil.physik.rwth-aachen.de> To: hackers@freebsd.org Subject: netnoot - INT 18 device Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I got a new machine (500 MHz PIII) with a 12 GB disk (nothing nowadays though :-). There was already NT 4.0 installed and a 3.9 GB unitialized partition left. I booted the 3.3 CD, chose Custom and tried to create a FreeBSD partition. 13200 blocks were left. I tried both, half of it and the whole left partition but afterwards in the label editor there was no entry I could define my filesystems on. Weird. Maybe a problem with large disks? Maybe that the FreeBSD partition has to be in the first 2 GB of a disk? Maybe because I could not create FreeBSD slices? Maybe I should repartition the whole disk, install FreeBSD and then reinstall NT . Sigh. To avoid all this the following idea came to me: while studying the BIOS boot options I saw ATAPI IDE, FD, and Int 18 device. Does FreeBSD support Int 18 Device? I assume this could be something like netboot, couldn't it? OTOH, the PCI 100 MBit ethernet card has a EPROM socket on it... With a 100MBit network, diskless could become interesting and I could try to netboot this machine. Any suggestions? -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 7:10:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 3557015356; Fri, 10 Dec 1999 07:10:39 -0800 (PST) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (cs1-gw.cs.binghamton.edu [128.226.171.72]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with SMTP id KAA02221; Fri, 10 Dec 1999 10:09:55 -0500 (EST) Date: Fri, 10 Dec 1999 08:56:47 -0500 (EST) From: Zhihui Zhang To: freebsd-hackers@freebsd.org, freebsd-fs@freebsd.org Subject: Why VMIO directory is a bad idea? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I read some postings on the Linux-Archive, complaining the slowness in looking up some big directory. Some claims that since the directory file is typically small, advanced techniques such as B+ tree (and I add hash method) are not necessary. We can simply pre-allocate the directory file contiguously and achieve good performance. This makes me wondering if we can read directory file into memory and keep it there as long as possible to get a good performance. I remember there is a discussion of VMIO directory early this year and only until now I begin to understand that idea. (1) If the directory file is less than one page, there will be a waste of memory due to internal fragmentation. Why do not we set a limit, say one page, on when we start VMIO a directory? (2) If VMIO directory is not desirable for some reasons, how about bump up the usecount of the buffer used by a directory file to let it stay in the queue longer? (3) Or maybe we can add a parameter to the filesytem, telling it to try to preallocate some contiguous disk space for all directory files. I guess that the cost per bit on disk is less than the cost per bit in memory. Can anyone give me an idea on how big a directory could be in some environment? Any comments or ideas are appreciated. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 7:45: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id C76DA14E18; Fri, 10 Dec 1999 07:45:01 -0800 (PST) (envelope-from dwmalone@maths.tcd.ie) Received: from hamilton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 10 Dec 1999 15:45:00 +0000 (GMT) Date: Fri, 10 Dec 1999 15:44:59 +0000 From: David Malone To: Zhihui Zhang Cc: freebsd-hackers@freebsd.org, freebsd-fs@freebsd.org Subject: Re: Why VMIO directory is a bad idea? Message-ID: <19991210154459.A1034@hamilton.maths.tcd.ie> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Dec 10, 1999 at 08:56:47AM -0500, Zhihui Zhang wrote: > Can anyone give me an idea on how big a directory could be in some > environment? Our inn's /news/spool/control/cancel directory is almost 300k. If we were a significantly larger news site we probably wouldn't be running inn though. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 8:19:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id C6CD4152E9; Fri, 10 Dec 1999 08:19:32 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id LAA34614; Fri, 10 Dec 1999 11:19:15 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Fri, 10 Dec 1999 11:19:15 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: David Malone Cc: Zhihui Zhang , freebsd-hackers@freebsd.org, freebsd-fs@freebsd.org Subject: Re: Why VMIO directory is a bad idea? In-Reply-To: <19991210154459.A1034@hamilton.maths.tcd.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 10 Dec 1999, David Malone wrote: > On Fri, Dec 10, 1999 at 08:56:47AM -0500, Zhihui Zhang wrote: > > > Can anyone give me an idea on how big a directory could be in some > > environment? > > Our inn's /news/spool/control/cancel directory is almost 300k. If > we were a significantly larger news site we probably wouldn't be > running inn though. > I use the CMU cyrus server to manage mail for my system, and also to handle mailing lists archives. I have an archive of the freebsd-current mailing list that contains around 33,000 messages, and with one file per message the directory size is about 530k. The big hit I see is Cyrus's use of dbm to manage index information, not the cost of directory operations. Typically, due to the way IMAP is usually used, no one reads in all the files, etc. However, performing an ls is non-trivially expensive: # time ls -af > /dev/null 1.018u 0.241s 0:01.25 100.0% 225+4365k 0+0io 0pf+0w 1.012u 0.288s 0:01.29 100.0% 225+4352k 0+0io 0pf+0w 1.053u 0.280s 0:01.33 100.0% 223+4273k 0+0io 0pf+0w 1.076u 0.253s 0:01.32 100.0% 219+4238k 0+0io 0pf+0w 1.091u 0.235s 0:01.33 99.2% 224+4273k 0+0io 0pf+0w # ls -af | wc -l 33323 This is under 2.2-STABLE, although I hope to push it to a 3.3-STABLE machine in the near future. This machine is currently a 486 dx2 66 w/24 mb of ram. It will become a Pentium sometime soon, with more memory. It should be observed, for the benefit of critics, that storing a mailbox in this format is far better from a performance perspective than storing all the messages in a single file :-). But it goes through a bunch of inodes (it almost justifies the default inode allocate on large disks :-), and does have drawbacks in terms of directory size. Because messages are hardly ever removed from this directory, my guess is that it's use of the directory space is fairly compact and unfragmented. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 8:32:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pmr.com (pmr.com [216.140.144.138]) by hub.freebsd.org (Postfix) with ESMTP id 5554214E1B for ; Fri, 10 Dec 1999 08:32:42 -0800 (PST) (envelope-from rbg@pmr.com) Received: from jeeves (jeeves.pmr.com [207.170.114.16]) by pmr.com (8.9.3/8.9.3) with SMTP id KAA01183 for ; Fri, 10 Dec 1999 10:22:33 -0600 (CST) (envelope-from rbg@pmr.com) Message-ID: <00e301bf432d$421169d0$1072aacf@pmr.com> Reply-To: "Robert Gordon" From: "Robert Gordon" To: Subject: Fw: Clustered Read/writes and NFS.. Date: Fri, 10 Dec 1999 10:40:24 -0600 Organization: PMR MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG reposting to the hackers ;-) ----- Original Message ----- From: Robert Gordon To: Sent: Thursday, December 09, 1999 1:56 PM Subject: Clustered Read/writes and NFS.. > Hello, > > I'm attempting to understand if the NFS implementation takes > advantage of clustered read/writes. So far I see that if NFS needs > a buf that (via getnewbuf()) a call could be made to vfs_bio_awrite() > which could cause a clustered write to free up some buffers... but I > don't see that NFS takes advantage of a clustered read/write.... > > Thanks, > Robert........................ rbg@pmr.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 10: 7:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from linux.gyarab.cz (miranda.gyarab.cz [194.50.7.50]) by hub.freebsd.org (Postfix) with SMTP id CDB8E152B1 for ; Fri, 10 Dec 1999 10:07:16 -0800 (PST) (envelope-from mhi@linux.gyarab.cz) Received: (qmail 4143 invoked by uid 500); 10 Dec 1999 18:24:44 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 10 Dec 1999 18:24:44 -0000 Date: Fri, 10 Dec 1999 19:24:44 +0100 (CET) From: Martin Hinner X-Sender: mhi@gyarab To: freebsd-hackers@freebsd.ORG Subject: Contribution Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, I originally posted this message to -questions mailing list, but it wasn't probably the right place :-( So, if you read it few days ago, please silently ignore ;-) I use FreeBSD on my home PC and one server. I must say, that I am *very* satisfied with it. a) I am maintainer/author of Filesystems-HOWTO. It's a document describing dozens of filesystems and accessing them from various OSes. I think it would be very useful to have this HOWTO in FreeBSD. What do you think? For more information see http://www.penguin.cz/~mhi/fs/. Should I make a port for you? b) I'd like to write in my HOWTO also about filesystems in FreeBSD. Can you help me? Any documents, links and other information are *very* welcome. I'd like to ask also BSD FFS developers. c) Few months ago I wrote BFS (UnixWare boot filesystem) Linux kernel implementation. Because implemented better (read-write) version of it, my version is obsolete. If you want to port this code to FreeBSD, I can re-release it under BSD license. There is small problem - I've never developed anything to FreeBSD kernel. But I have kernel-level development experience. d) I installed FreeBSD on extended partition using GRUB bootmanager (see GNU homepage). Are you interested? [Some people asked me to write step-by-step howto. But it is not easy, so I'd like to make small changes to sysinstall to accept also extended FreeBSD partitions]. Thanks, Martin. PS: Please CC all replies also to me, because I have no time to read carefully hackers mailing list. -- mhi@sunsite.unc.edu PGP: 1024/226C5935 2E A6 9F 01 D1 88 85 15 9B 08 12 34 4C 46 41 21 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 11: 0:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 618C7157F7 for ; Fri, 10 Dec 1999 11:00:47 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA59811; Fri, 10 Dec 1999 11:00:34 -0800 (PST) (envelope-from dillon) Date: Fri, 10 Dec 1999 11:00:34 -0800 (PST) From: Matthew Dillon Message-Id: <199912101900.LAA59811@apollo.backplane.com> To: "Robert Gordon" Cc: Subject: Re: Fw: Clustered Read/writes and NFS.. References: <00e301bf432d$421169d0$1072aacf@pmr.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :reposting to the hackers :;-) :----- Original Message ----- :From: Robert Gordon :To: :Sent: Thursday, December 09, 1999 1:56 PM :Subject: Clustered Read/writes and NFS.. : : :> Hello, :> :> I'm attempting to understand if the NFS implementation takes :> advantage of clustered read/writes. So far I see that if NFS needs :> a buf that (via getnewbuf()) a call could be made to vfs_bio_awrite() :> which could cause a clustered write to free up some buffers... but I :> don't see that NFS takes advantage of a clustered read/write.... :> :> Thanks, :> Robert........................ rbg@pmr.com Unfortunately there is no advantage to clustering NFS writes, because the NFS write packets are limited to the NFS write size which is usually 8K, so you still need to do separate RPCs. But there is an advantage to clustering NFS commits (essentially the write-verification part of an NFS write), and FreeBSD *does* do that. In fact, Alfred is working on a patch that will make the commit clustering even better. Under NFSv3 the NFS server may cluster NFS write packets it receives prior to writing the data to the physical media, and FreeBSD does do this. This is because NFSv3 writes are allowed to be asynchronous. NFSv2 writes are required to always be synchronous which prevents the server from clustering them when transfering the data to physical media. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 11:11:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id BAC2D15A5C; Fri, 10 Dec 1999 11:08:03 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA59861; Fri, 10 Dec 1999 11:07:46 -0800 (PST) (envelope-from dillon) Date: Fri, 10 Dec 1999 11:07:46 -0800 (PST) From: Matthew Dillon Message-Id: <199912101907.LAA59861@apollo.backplane.com> To: Zhihui Zhang Cc: freebsd-hackers@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: Why VMIO directory is a bad idea? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :(1) If the directory file is less than one page, there will be a waste of :memory due to internal fragmentation. Why do not we set a limit, say one :page, on when we start VMIO a directory? It is true that when we use VMIO to back directories that a minimum of one page of memory is used even for a small directory. However, unlike B_MALLOC space in the buffer cache the VM page cache is much better suited towards figuring out when cached VM pages can be reused. So even though there is waste the page may still be reused by the system fairly quickly if need be. When we use B_MALLOC space in the buffer to store a small directory 'efficiently', it tends to get reused too quickly due to the small size of the buffer cache which results in another physical I/O the next time the directory needs to be accessed. Given the choice being some wasteage (which is less then you think) and having to do another physical I/O, it is clear that the advantage is to keep the waste and avoid the physical I/O. :(2) If VMIO directory is not desirable for some reasons, how about bump up :the usecount of the buffer used by a directory file to let it stay in the :queue longer? This is how the old algorithm worked. It failed utterly to address the problem and in fact led to a considerable amount of complexity and wasted cpu cycles when the buffer cache became unbalanced (due to excessive write loading or directory scanning loading). :(3) Or maybe we can add a parameter to the filesytem, telling it to try to :preallocate some contiguous disk space for all directory files. I guess :that the cost per bit on disk is less than the cost per bit in memory. I believe the filesystem already does this. -Matt Matthew Dillon :Can anyone give me an idea on how big a directory could be in some :environment? : :Any comments or ideas are appreciated. : :-Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 11:33:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.144.32]) by hub.freebsd.org (Postfix) with ESMTP id B965F15B90 for ; Fri, 10 Dec 1999 11:29:12 -0800 (PST) (envelope-from dwhite@resnet.uoregon.edu) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.9.3/8.9.3) with ESMTP id LAA42235; Fri, 10 Dec 1999 11:28:52 -0800 (PST) (envelope-from dwhite@resnet.uoregon.edu) Date: Fri, 10 Dec 1999 11:28:52 -0800 (PST) From: Doug White To: Martin Hinner Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Contribution In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 10 Dec 1999, Martin Hinner wrote: > I originally posted this message to -questions mailing list, but it wasn't > probably the right place :-( So, if you read it few days ago, please silently > ignore ;-) > > I use FreeBSD on my home PC and one server. I must say, that I am *very* > satisfied with it. > > a) I am maintainer/author of Filesystems-HOWTO. It's a document describing > dozens of filesystems and accessing them from various OSes. I think it would > be very useful to have this HOWTO in FreeBSD. What do you think? For more > information see http://www.penguin.cz/~mhi/fs/. Should I make a port for you? I've found it's better to not ask and just do it, unless it's something controversial. Otherwise you'll get the resounding approval of silence. :) > b) I'd like to write in my HOWTO also about filesystems in FreeBSD. Can you > help me? Any documents, links and other information are *very* welcome. I'd > like to ask also BSD FFS developers. As you probably know, docs are sparse; the code is sometimes the best doc. > c) Few months ago I wrote BFS (UnixWare boot filesystem) Linux kernel > implementation. Because implemented better (read-write) > version of it, my version is obsolete. If you want to port this code to > FreeBSD, I can re-release it under BSD license. There is small problem - I've > never developed anything to FreeBSD kernel. But I have kernel-level > development experience. The filesystem layer isn't one of the easier parts of the system to work with, but since you're the writing type, document your attempt. > d) I installed FreeBSD on extended partition using GRUB bootmanager (see GNU > homepage). Are you interested? [Some people asked me to write step-by-step > howto. But it is not easy, so I'd like to make small changes to sysinstall to > accept also extended FreeBSD partitions]. Don't ask, just do it! :) Provide patches! Patches speak louder than words. Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 11:52:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.pernet.net (mail.pernet.net [205.229.0.40]) by hub.freebsd.org (Postfix) with ESMTP id CDD5D15950 for ; Fri, 10 Dec 1999 11:42:39 -0800 (PST) (envelope-from dimwit@pernet.net) Received: from deadpixi.pernet.net (deadpixi.pernet.net [205.229.0.243]) by mail.pernet.net (8.9.1a/8.9.1) with ESMTP id NAA01934 for ; Fri, 10 Dec 1999 13:42:36 -0600 (CST) Date: Fri, 10 Dec 1999 13:42:36 -0600 (CST) From: Rob King X-Sender: jking@deadpixi.pernet.net Reply-To: dimwit@pernet.net To: freebsd-hackers@freebsd.org Subject: AWE64 and 4.0 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Pardon me if this was sent to the wrong list, but -hackers seemed as good a place as any... I'm running FreeBSD4.0, current as of 12/10/99 (today)...I just traded with a friend and found myself with an SB AWE 64...while there are instructions on getting this card working under 3.2, there are none for 4.0 - in which the kernel config pnp syntax has totally changed. Even if it hadn't, my kernel still doesn't recognize it...if there's anyone out there that has any information, please, let me know. Thanks, Rob -- dimwit@pernet.net http://ota.pernet.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 11:52:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from spirit.jaded.net (spirit.jaded.net [216.94.113.12]) by hub.freebsd.org (Postfix) with ESMTP id C493C15218; Fri, 10 Dec 1999 11:48:52 -0800 (PST) (envelope-from dan@spirit.jaded.net) Received: (from dan@localhost) by spirit.jaded.net (8.9.3/8.9.3) id OAA03502; Fri, 10 Dec 1999 14:52:01 -0500 (EST) Date: Fri, 10 Dec 1999 14:52:01 -0500 From: Dan Moschuk To: Kris Kennaway Cc: Archie Cobbs , cvs-committers@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Crypto in the kernel: where & how? Message-ID: <19991210145201.G3187@spirit.jaded.net> References: <199912100101.RAA76788@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from kris@hub.freebsd.org on Thu, Dec 09, 1999 at 06:24:47PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG | US sites mirror their crypto from freebsd.org, international ones from the | international repository. The preferred path is for code to be committed | by international people to the international repository, since it can be | imported from there back into the US - if we can avoid it we shouldn't | commit stuff to the US repository on its own since that prevents most of | our users (by geography) from accessing it. However at least in the case | of OpenSSL (which I'm planning to import into internat when I go home to | australia next week :-) the two will have to be divergent due to the | patent restrictions on RSA. The RSA patent makes things a lot more difficult. If we do add some crypto into the kernel I suggest we use patent-free algorithms to start with. -- Dan Moschuk (TFreak!dan@freebsd.org) "Cure for global warming: One giant heatsink and dual fans!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 12:15:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 6031715F56; Fri, 10 Dec 1999 11:57:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 4D0841CD79B; Fri, 10 Dec 1999 11:57:14 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Fri, 10 Dec 1999 11:57:14 -0800 (PST) From: Kris Kennaway To: Dan Moschuk Cc: Archie Cobbs , cvs-committers@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Crypto in the kernel: where & how? In-Reply-To: <19991210145201.G3187@spirit.jaded.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 10 Dec 1999, Dan Moschuk wrote: > | our users (by geography) from accessing it. However at least in the case > | of OpenSSL (which I'm planning to import into internat when I go home to > | australia next week :-) the two will have to be divergent due to the > | patent restrictions on RSA. > > The RSA patent makes things a lot more difficult. If we do add some crypto > into the kernel I suggest we use patent-free algorithms to start with. This was actually part of an unrelated point I was making - RSA will definitely not be going into the kernel anywhere at this point! In general, we want the two crypto repositories to stay in sync which generally means propagating from internat -> freefall, but we can't do it for RSA. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 12:17:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id CCCB215AC0; Fri, 10 Dec 1999 12:06:03 -0800 (PST) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (cs1-gw.cs.binghamton.edu [128.226.171.72]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with SMTP id PAA20176; Fri, 10 Dec 1999 15:05:53 -0500 (EST) Date: Fri, 10 Dec 1999 13:52:46 -0500 (EST) From: Zhihui Zhang To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: Why VMIO directory is a bad idea? In-Reply-To: <199912101907.LAA59861@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :(3) Or maybe we can add a parameter to the filesytem, telling it to try to > :preallocate some contiguous disk space for all directory files. I guess > :that the cost per bit on disk is less than the cost per bit in memory. > > I believe the filesystem already does this. > The FFS tries to allocate space contiguously for any type of file. It does not PRE-allocate disk space, which will result wasteage of disk space if that space is not used later. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 12:17:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 0EEEE15919; Fri, 10 Dec 1999 12:13:18 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA60500; Fri, 10 Dec 1999 12:13:13 -0800 (PST) (envelope-from dillon) Date: Fri, 10 Dec 1999 12:13:13 -0800 (PST) From: Matthew Dillon Message-Id: <199912102013.MAA60500@apollo.backplane.com> To: Zhihui Zhang Cc: freebsd-hackers@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: Why VMIO directory is a bad idea? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :> :(3) Or maybe we can add a parameter to the filesytem, telling it to try to :> :preallocate some contiguous disk space for all directory files. I guess :> :that the cost per bit on disk is less than the cost per bit in memory. :> :> I believe the filesystem already does this. :> : :The FFS tries to allocate space contiguously for any type of file. It :does not PRE-allocate disk space, which will result wasteage of disk space :if that space is not used later. : :-Zhihui I'm sorry, I misread that ... I thought he had said 'allocate'. It definitely does not preallocate disk space. FFS is designed to to avoid fragmentation so the blocks that it allocates when appending to a file (or directory) tend to be contiguous. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 12:39:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id 0759215BBB for ; Fri, 10 Dec 1999 12:26:15 -0800 (PST) (envelope-from bsdx@looksharp.net) Received: from localhost (bsdx@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id PAA82537; Fri, 10 Dec 1999 15:26:08 -0500 (EST) (envelope-from bsdx@looksharp.net) Date: Fri, 10 Dec 1999 15:26:08 -0500 (EST) From: Adam To: Rob King Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: AWE64 and 4.0 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG try this: device pcm0 device sbc0 IIRC pnp is standard in the latest -current, so if yours is more than a few days old you may need controller pnp0 too. If the above doesnt work, try options PNPBIOS. And for further reference, the freebsd-multimedia list would be your best bet. On Fri, 10 Dec 1999, Rob King wrote: >Pardon me if this was sent to the wrong list, but -hackers seemed as good >a place as any... > >I'm running FreeBSD4.0, current as of 12/10/99 (today)...I just traded >with a friend and found myself with an SB AWE 64...while there are >instructions on getting this card working under 3.2, there are none for >4.0 - in which the kernel config pnp syntax has totally changed. Even if >it hadn't, my kernel still doesn't recognize it...if there's anyone out >there that has any information, please, let me know. > >Thanks, >Rob > >-- >dimwit@pernet.net >http://ota.pernet.net/ > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 13: 1:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from spirit.jaded.net (spirit.jaded.net [216.94.113.12]) by hub.freebsd.org (Postfix) with ESMTP id 137D114DCE; Fri, 10 Dec 1999 13:01:33 -0800 (PST) (envelope-from dan@spirit.jaded.net) Received: (from dan@localhost) by spirit.jaded.net (8.9.3/8.9.3) id QAA04511; Fri, 10 Dec 1999 16:04:40 -0500 (EST) Date: Fri, 10 Dec 1999 16:04:40 -0500 From: Dan Moschuk To: Kris Kennaway Cc: Dan Moschuk , Archie Cobbs , cvs-committers@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Crypto in the kernel: where & how? Message-ID: <19991210160440.A4224@spirit.jaded.net> References: <19991210145201.G3187@spirit.jaded.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from kris@hub.freebsd.org on Fri, Dec 10, 1999 at 11:57:14AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG | This was actually part of an unrelated point I was making - RSA will | definitely not be going into the kernel anywhere at this point! In | general, we want the two crypto repositories to stay in sync which | generally means propagating from internat -> freefall, but we can't do it | for RSA. Indeed. So, the crypto stuff stays on internat and is then imported to freefall? How does that affect our mirror sites? Are we not then exporting it out to the world from freefall, or is the crypto stuff snagged from internat as well? I would much rather see freefall move a few thousand miles north! :-) -- Dan Moschuk (TFreak!dan@freebsd.org) "Cure for global warming: One giant heatsink and dual fans!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 16:42: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by hub.freebsd.org (Postfix) with ESMTP id A49CE1541F for ; Fri, 10 Dec 1999 16:41:52 -0800 (PST) (envelope-from bobkat@azstarnet.com) Received: from atlas.tic.toc (dialup06ip054.tus.azstarnet.com [169.197.32.182]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with SMTP id RAA04354 for ; Fri, 10 Dec 1999 17:41:43 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ From: Bob Kot To: freebsd-hackers@FreeBSD.ORG Subject: Device driver - panics executing kvtop() when compiled as KLD module Date: Fri, 10 Dec 1999 17:15:43 -0700 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <99121017414100.00289@atlas.tic.toc> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am in the process of writing a device driver for the Turtle Beach Multisound Monterey soundcard. At the moment I am statically compiling my code into the kernel and it is somewhat operational. I have added conditional compilation code to also compile as a kld module. My problem is that when I kldload my module the machine panics in a subfunction of my attach() function that makes a call on kvtop() I drop into the debugger DDB and the instruction pointer is in the middle of the kvtop() function. If I disable my attach function the module will load and unload, but it is nonfunctional without the attach() being executed. Statically compiled into the kernel kvtop() executes with no problem. To be succinct can I use kvtop() in code that is a kld module? If not, what is the alternative to accomplish the same result? For those interested and/or willing to help more details follow, others can move on. The panic info is Fatal trap 12: page fault while in kernel mode fault virtual address = 0xbfc00340 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01c98d9 stack pointer = 0x10:0xc2cdbe70 frame pointer = 0x10:0xc2cdbe70 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor flags = interrupt enabled, resume, IOPL=0 current process = 250 (kldload) interrupt mask = kernel type 12 trap, code = 0 Stopped at kvtop+0x2d: movl PTmap(,%eax,4),%edx db> show registers cs 0x80000008 ds 0x10 es 0x10 ss 0x10 eax 0xd0 ecx 0xd0000 <<<< This is the physical address I want <<<<< edx 0 ebx 0xc0570a00 esp 0xc2cdbe70 ebp 0xc2cdbe70 esi 0xc0577100 edi 0 eip 0xc01c98d9 kvtop+0x2d efl 0x10212 end+0xb00e The TurtleBeach hardware demands that the driver has access to a 0x8000 (32K) byte contiguous chunk of physical memory in the ISA hole and more specifically it must start at one of the following locations B0000 || C8000 || D0000 || D8000 || E0000 || E8000 The line of my code that causes the panic as a module is switch (kvtop(msd->dev->id_maddr)) { ... } dev is a pointer to struct isa_device and id_maddr is 0xd0000 because my kernel config definition for this device is device msm0 at isa? port 0x290 irq 10 tty iomem 0xd0000 iosiz 0x8000 Which by some magic gets generated into ioconf.c in my kernel compile directory as struct isa_device isa_devtab_tty[] = { ..... other tty drivers omitted ..... { 18, &msmdriver, 0x0290, IRQ10, -1, C 0xD0000, 32768, 0, 0, 0x0000, 0 ,0, 0, 0, 1, 0, 0 }, 0}; My code to compile as a module must provide this information to the system as part of the module load. My conditional code as a module is as follows. static void msm_drvinit(void *unused) { dev_t dev; dev = makedev(CDEV_MAJOR, 0); cdevsw_add(&dev, &msm_cdevsw, NULL); } #ifndef MSM_MODULE SYSINIT(msmdev, SI_SUB_DRIVERS, SI_ORDER_MIDDLE+CDEV_MAJOR, msm_drvinit, NULL) #else /* MSM_MODULE */ /* * Here is the support for if we ARE a kld module */ #include /* * XXX Hardwiring this stuff is not wise, need to find some other * mechanism to specify this stuff */ static struct isa_device isadev = {0, &msmdriver, 0x290, IRQ10, -1, (caddr_t) 0x D0000, 0x8000, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}; static int msmm_event (module_t, modeventtype_t, void *); static int msmm_event (module_t mod, modeventtype_t cmd, void *arg) { int rv = 0; switch (cmd) { case MOD_LOAD: msm_drvinit(arg); if (msmprobe(&isadev) ) { msmattach(&isadev); } else { printf("msm driver: probe failed\n"); cdevsw[CDEV_MAJOR] = NULL; /* detach from cdevsw[] */ rv = 1; } break; case MOD_UNLOAD: if (sca[isadev.id_unit] != NULL) /* malloc in msmattach */ free(sca[isadev.id_unit], M_DEVBUF); /* deallocate buffers, MS_dev_t */ else printf("unload-msm0\n"); break; default: rv = EINVAL; break; } return rv; } /* This declares the kld module to the system MACRO in /sys/conf.h * I expanded this macro manually because the compiler was howling about the * msmm_event element structure initializer until I threw the cast on it. * I don't think this has anything to do with the problem I am having. * CDEV_MAJOR = 30 for soundcard drivers * CDEV_MODULE(msmm, CDEV_MAJOR, msm_cdevsw, msmm_event, 0); */ static struct cdevsw_module_data msmm_cdevsw_mod = { (modeventhand_t)msmm_event , 0 , 30 == NODEV ? NODEV : makedev( 30 , 0), & msm_cdevsw }; static moduledata_t msmm_mod = { "msmm", cdevsw_module_handler, & msmm_cdevsw_mod }; DECLARE_MODULE(msmm, msmm_mod, SI_SUB_DRIVERS, SI_ORDER_MIDDLE + 30); #endif /* MSM_MODULE */ I added a directory to /sys/modules/msm and in it put the file msm.h which is #define NMSM 4 #define MSM_MODULE and my module Makefile which is .PATH: ${.CURDIR}/../../i386/isa/sndm KMOD= msm SRCS= msm.c msmio.h dsp_code.h NOMAN= NMSM?= 4 CLEANFILES+= msm.h msm.h: echo "#define NMSM ${NMSM}" > msm.h echo "#define MSM_MODULE" >> msm.h .include Executing # make msm.h creates the header file and a subsequent # make creates msm.ko which I then manually copy to /modules so kldload finds it in the default location. Any and all comments and hopefully some insight would be appreciated. Bob Kot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 17: 3:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by hub.freebsd.org (Postfix) with ESMTP id E08FC14F46 for ; Fri, 10 Dec 1999 17:02:32 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id RAA01817; Fri, 10 Dec 1999 17:04:36 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912110104.RAA01817@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Alex" Cc: freebsd-hackers@freebsd.org Subject: Re: Interrupt handler for PCI In-reply-to: Your message of "Wed, 08 Dec 1999 13:24:23 PST." <199912082124.NAA30695@www.geocrawler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Dec 1999 17:04:36 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This message was sent from Geocrawler.com by "Alex" > Be sure to reply to that address. > > Hello, > > I'm writting driver for PCI board. > Is't possible to set interrupt handler for PCI > device not in attach function? If yes, how? > For ISA is possible to do by calling > reconfig_isadev(dev, &imask) for one device. That's the hard way of doing it. Much better just to register one interrupt handler and then vector inside that handler to the correct local function. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 17:12: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by hub.freebsd.org (Postfix) with ESMTP id 845E214D80 for ; Fri, 10 Dec 1999 17:11:55 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id RAA01977; Fri, 10 Dec 1999 17:13:58 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912110113.RAA01977@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Christoph Kukulies Cc: hackers@freebsd.org Subject: Re: netnoot - INT 18 device In-reply-to: Your message of "Fri, 10 Dec 1999 12:45:41 +0100." <199912101145.MAA07130@gil.physik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Dec 1999 17:13:58 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I got a new machine (500 MHz PIII) with a 12 GB disk (nothing nowadays > though :-). There was already NT 4.0 installed and a 3.9 GB unitialized > partition left. > > I booted the 3.3 CD, chose Custom and tried to create a FreeBSD > partition. 13200 blocks were left. I tried both, half of it and > the whole left partition but afterwards in the label editor > there was no entry I could define my filesystems on. > Weird. Some more details here would really help. Lots more details, like the exact size of the NT partition, which entry it occupied in the slice table, the various disk geometries in play (BIOS, NT, FreeBSD). The system boot messages from FreeBSD, the output with debugging enabled, the output in Wizard mode in the slice editor. Without these it's too hard to even begin to guess what's going on. > Maybe a problem with large disks? Not AFAIK. > Maybe that the FreeBSD partition has to be in the first 2 GB of a disk? Nope, modulo some booting issues on some broken BIOSsen. > Maybe because I could not create FreeBSD slices? Er, if you don't create a slice, of course you can't create any partitions. > while studying the BIOS boot options I saw ATAPI IDE, FD, and Int 18 device. > Does FreeBSD support Int 18 Device? No. > I assume this could be something like netboot, couldn't it? It could be. > OTOH, the PCI 100 MBit ethernet card has a EPROM socket on it... > > With a 100MBit network, diskless could become interesting and I could > try to netboot this machine. Not until we complete the software support for it. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 18:22:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp1.nikoma.de (smtp1.nikoma.de [212.122.128.19]) by hub.freebsd.org (Postfix) with ESMTP id 7315F14D4E for ; Fri, 10 Dec 1999 18:22:35 -0800 (PST) (envelope-from beckmann@nikoma.de) Received: from nikoma.de (dynip116.nikoma.de [212.122.131.116]) by smtp1.nikoma.de (8.9.3/8.9.3) with ESMTP id EAA29673 for ; Sat, 11 Dec 1999 04:25:41 +0100 (CET) (envelope-from beckmann@nikoma.de) Message-ID: <3851B5AE.2AA0D202@nikoma.de> Date: Sat, 11 Dec 1999 03:23:42 +0100 From: Michael Beckmann Organization: Nikoma GmbH, Hamburg, Germany X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: de,de-DE,de-AT,de-CH,en,nl,nl-BE MIME-Version: 1.0 To: hackers@freebsd.org Subject: large file aware utilities Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greetings, it appears that tail is not functioning properly with a file > 2 GB. What can I do to tail such a file (actually to make it smaller than 2 GB) ? Is there a large file capable tail for FreeBSD ? I have also found that 'less' is unable to display that file, but more is. :-/ Michael To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 23: 5:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (castles536.castles.com [208.214.165.100]) by hub.freebsd.org (Postfix) with ESMTP id 9996414DC2 for ; Fri, 10 Dec 1999 23:05:32 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id XAA00875; Fri, 10 Dec 1999 23:08:03 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912110708.XAA00875@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Bob Kot Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Device driver - panics executing kvtop() when compiled as KLD module In-reply-to: Your message of "Fri, 10 Dec 1999 17:15:43 MST." <99121017414100.00289@atlas.tic.toc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Dec 1999 23:08:02 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I am in the process of writing a device driver for the Turtle Beach Multisound > Monterey soundcard. At the moment I am statically compiling my code into the > kernel and it is somewhat operational. I have added conditional compilation > code to also compile as a kld module. My problem is that when I kldload my > module the machine panics in a subfunction of my attach() function that makes > a call on kvtop() I drop into the debugger DDB and the instruction pointer is > in the middle of the kvtop() function. If I disable my attach function the > module will load and unload, but it is nonfunctional without the attach() > being executed. Statically compiled into the kernel kvtop() executes with no > problem. > > To be succinct can I use kvtop() in code that is a kld module? Yes, althought it's not the right way to do this. > If not, what is the alternative to accomplish the same result? You should be using the bus_space functionality to hide the mapping. > switch (kvtop(msd->dev->id_maddr)) { Er. You do understand that kvtop() attempts to return a physical address when given a kernel virtual address, right? The isa_device id_maddr field is a physical address, for which you want a mapping in kernel virtual space. Assuming you don't want to do this properly and use bus_space, you need to use pmap_mapdev(), or to take advantage of the fact that the ISA hole is already mapped into kernel virtual space. You can convert a physical address in the ISA hole to a virtual address in kernel space with: #include #include ... vaddr = (paddr - ISA_HOLE_START) + atdevbase; Note that this approach is somewhat frowned upon, and if you're working with -current it is very definitely the wrong way to do it, but for an expedient solution it'll do the job. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 10 23:17:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (castles536.castles.com [208.214.165.100]) by hub.freebsd.org (Postfix) with ESMTP id 705D314CEC for ; Fri, 10 Dec 1999 23:17:54 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id XAA00953; Fri, 10 Dec 1999 23:20:29 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912110720.XAA00953@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Daniel Hilevich" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Use of the ppi interface In-reply-to: Your message of "Wed, 08 Dec 1999 17:40:36 +0200." <060901bf4192$926e8350$2e00a8c0@cwnt.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Dec 1999 23:20:29 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG - please only post to one list - please do not post HTML messages to public mailing lists > I'm using the parallel port to control some sort of a hardware (i2c). You should probably use the i2cbb driver for this, as it can be easily tweaked to do what you're trying to do here. > For that I generate pulses using the ppi device (geek port). The problem > is that in some cases, the pulse isn't generated. What I do is sending > an ioctl to make the device high (1) and another ioctl to set the device > low (0). It seems that in some cases, the two commands arrive together > to the device so the pulse isn't wide enough. The timing of the output transitions under ppi are very dependant on what the rest of the system is doing. It's not really suitable for this application as-is; you would be better off either using the 'lpbb' driver or building an external parallel-to-i2c interface adapter. > Does the ppbus layer stores the ioctl's in some sort of a buffer and > than flushes its content to the hardware? No. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 11 8:12:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 6D95B1521A for ; Sat, 11 Dec 1999 08:12:17 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p23-dn02kiryunisiki.gunma.ocn.ne.jp [210.163.200.120]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id BAA22041; Sun, 12 Dec 1999 01:11:48 +0900 (JST) Message-ID: <3852771D.8C8BFA3C@newsguy.com> Date: Sun, 12 Dec 1999 01:09:01 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Martin Hinner Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Contribution References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Martin Hinner wrote: > > I originally posted this message to -questions mailing list, but it wasn't > probably the right place :-( So, if you read it few days ago, please silently > ignore ;-) Perhaps -fs mailing list would be a more adequate choice? > a) I am maintainer/author of Filesystems-HOWTO. It's a document describing > dozens of filesystems and accessing them from various OSes. I think it would > be very useful to have this HOWTO in FreeBSD. What do you think? For more > information see http://www.penguin.cz/~mhi/fs/. Should I make a port for you? I notice you give the impression that a log filesystem is the same as a journalling filesystem, which is not the case. BTW, you could give NetBSD's LFS as an example of Log Filesystems. FreeBSD killed LFS because it broken long time ago, nobody ever fixed it, and it was made largely obsolete by softupdates. And, anyway, better work on a journalled filesystem than try to fix a log one. Also, I'd suggest removing "MD" as header for one section, since it only has meaning in Linux. Perhaps you could call it RAID filesystems, and have subsections of Linux, etc? FreeBSD has two. An old one, called ccd, which just concatenates devices, and a new one, called vinum, which does the whole RAID she-bang. Other feedback... :-) A Unix disklabel is like a DOS partition table. If you are referring to the actual partitions, they are called, in Unix, "partitions". And have been called that long before DOS came along. Information on AIX logical volume manager would be interesting too, given the scope of the document. Next... why don't you make mention of filesystems such as union fs or umap fs? Mmmm... no mention of Joliet access with FreeBSD. Gives the impression FreeBSD doesn't support it. Well, same can be said of FreeBSD and FAT-32/Ext2FS, actually. :-) Let's see... Ah, Sun Solaris is BSD based only up to SunOS 4.x (Solaris 1.x). From SunOS 5.x (Solaris 2.x) on, it's SysV. No mention of any stuff by Erez Zadok (http://www.cs.columbia.edu/~ezk/research/software/). Or the page itself. :-) Well, that's all I saw off-hand. Anyway, frankly, I don't think this document would be relevant to FreeBSD. Perhaps I'm missing something... what would be the purpose of having it? > b) I'd like to write in my HOWTO also about filesystems in FreeBSD. Can you > help me? Any documents, links and other information are *very* welcome. I'd > like to ask also BSD FFS developers. Look in /usr/share/doc/papers/, I think there is a document on ffs there. A reading of Kirk's paper on softupdates would also be interesting, but I don't have the url. Finally, it would be interesting to have a section of stacked filesystems (sorry if already there is one, I'm just scanning the document). I don't have the url to those papers (John Heidemann's) either. I'm sure you can get both urls if you ask at -fs. > c) Few months ago I wrote BFS (UnixWare boot filesystem) Linux kernel > implementation. Because implemented better (read-write) > version of it, my version is obsolete. If you want to port this code to > FreeBSD, I can re-release it under BSD license. There is small problem - I've > never developed anything to FreeBSD kernel. But I have kernel-level > development experience. Not much use unless supported by boot[12] and loader. > d) I installed FreeBSD on extended partition using GRUB bootmanager (see GNU > homepage). Are you interested? [Some people asked me to write step-by-step > howto. But it is not easy, so I'd like to make small changes to sysinstall to > accept also extended FreeBSD partitions]. If we supported it, people would foolishly install on them and then not be able to use them. Unless boot[12]/loader support it, I don't think it's a good idea. Requiring extra software that does not come with the system is a bad idea. -- Daniel C. Sobral (8-DCS) who is as social as a wampas dcs@newsguy.com dcs@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 11 8:15: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3C77314F6B for ; Sat, 11 Dec 1999 08:14:57 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id RAA15186; Sat, 11 Dec 1999 17:14:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA45257; Sat, 11 Dec 1999 17:14:48 +0100 (MET) Date: Sat, 11 Dec 1999 17:14:48 +0100 From: Eivind Eklund To: Matthew Dillon Cc: "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) Message-ID: <19991211171448.E36957@bitbox.follo.net> References: <1221.944514960@zippy.cdrom.com> <199912062143.NAA72923@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <199912062143.NAA72923@apollo.backplane.com>; from dillon@apollo.backplane.com on Mon, Dec 06, 1999 at 01:43:33PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Dec 06, 1999 at 01:43:33PM -0800, Matthew Dillon wrote: > If we enforce a stabilizing period between .0 and .1 and branch at .1 > rather then at .0, this combined with the 12 month schedule should result > in pretty damn good releases. > > If we just do the 12 month schedule, I don't think it will produce as > good a result. I'd just like to point out how I've understood what NetBSD is doing here: 1. Put down the branch 2. Ask all developers to switch to that branch, and drop using -current for stabilizing changes and other changes that should go into the release branch 3. After a suitable period of this (when the branch is considered ready to 'go golden'), ask all the developers to switch back to -current. 4. Merge the changes from the branch back to -current. This seems like a good way to kick-start a branch; you get a while when there is focus on stabilizing among developers that are actually running the branch, while there still is somewhere to stick the 'dangerous' changes. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 11 8:41:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id A3CBA14FB4 for ; Sat, 11 Dec 1999 08:41:13 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.9.3/8.9.3) id KAA25758; Sat, 11 Dec 1999 10:41:07 -0600 (CST) (envelope-from dan) Date: Sat, 11 Dec 1999 10:41:06 -0600 From: Dan Nelson To: Michael Beckmann Cc: hackers@FreeBSD.ORG Subject: Re: large file aware utilities Message-ID: <19991211104106.B25422@dan.emsphone.com> References: <3851B5AE.2AA0D202@nikoma.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3851B5AE.2AA0D202@nikoma.de>; from "Michael Beckmann" on Sat Dec 11 03:23:42 GMT 1999 X-OS: FreeBSD 4.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Dec 11), Michael Beckmann said: > Greetings, > > it appears that tail is not functioning properly with a file > 2 GB. > What can I do to tail such a file (actually to make it smaller than 2 > GB) ? It looks like 'tail' wants to mmap() the entire file when you ask for a standard (last ## lines) tail. If you ask for a particular number of *bytes* from the end, however, it simply seek()s to that offset and starts printing. So as a quick hack, you can do a "tail -c 10000000 file | tail", which will first grab the last 10 meg of the file in question, then print the last 10 lines from that. This bug has been reported as http://www.freebsd.org/cgi/query-pr.cgi?pr=14786 -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 11 12: 5:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from monkeys.com (i180.value.net [206.14.136.180]) by hub.freebsd.org (Postfix) with ESMTP id 10AE414D16 for ; Sat, 11 Dec 1999 12:05:36 -0800 (PST) (envelope-from rfg@monkeys.com) Received: from monkeys.com (localhost [127.0.0.1]) by monkeys.com (8.9.3/8.9.3) with ESMTP id MAA18801; Sat, 11 Dec 1999 12:05:34 -0800 (PST) To: freebsd-hackers@FreeBSD.ORG Cc: Martin Hinner Subject: Re: Contribution In-reply-to: Your message of Sun, 12 Dec 1999 01:09:01 +0900. <3852771D.8C8BFA3C@newsguy.com> From: "Ronald F. Guilmette" Date: Sat, 11 Dec 1999 12:05:34 -0800 Message-ID: <18799.944942734@monkeys.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3852771D.8C8BFA3C@newsguy.com>, Martin Hinner wrote: >Anyway, frankly, I don't think this document would be relevant to >FreeBSD. Perhaps I'm missing something... what would be the purpose >of having it? My two cents: I happen to think that the HOWTO- system of Linux is marvelous. If you want detailed information on one specific topic, e.g. filesystems, or parallel ports, or RAID, or some such thing, you just go and read the relevant HOWTO- file. A lot of the information in these HOWTO- files would NOT be appropriate to put into man pages... it's far too chatty. But it is still very very useful information and it's Good to have it exist (in writing) _somewhere_. Seems to me that the closest thing that FreeBSD has to the Linux HOWTO- files is the FreeBSD Handbook, but that's not as good, precisely because it _is_ one unified document with (I assume) a single maintainer. It seems to be better to distribute the psychological sense of ownership across many many individuals. That's what happens in the case of the Linux HOWTO- files. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 11 12:14:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.144.32]) by hub.freebsd.org (Postfix) with ESMTP id 81B7215017 for ; Sat, 11 Dec 1999 12:14:09 -0800 (PST) (envelope-from dwhite@resnet.uoregon.edu) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.9.3/8.9.3) with ESMTP id MAA86185; Sat, 11 Dec 1999 12:13:58 -0800 (PST) (envelope-from dwhite@resnet.uoregon.edu) Date: Sat, 11 Dec 1999 12:13:58 -0800 (PST) From: Doug White To: "Ronald F. Guilmette" Cc: freebsd-hackers@FreeBSD.ORG, Martin Hinner Subject: Re: Contribution In-Reply-To: <18799.944942734@monkeys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 11 Dec 1999, Ronald F. Guilmette wrote: > Seems to me that the closest thing that FreeBSD has to the Linux HOWTO- > files is the FreeBSD Handbook, but that's not as good, precisely because > it _is_ one unified document with (I assume) a single maintainer. It > seems to be better to distribute the psychological sense of ownership > across many many individuals. That's what happens in the case of the > Linux HOWTO- files. I would point to the Tutorials as being more HOWTO-like. As usual the trouble is finding people to write the documents in the first place. Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 11 12:31:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from server.baldwin.cx (jobaldwi.campus.vt.edu [198.82.67.146]) by hub.freebsd.org (Postfix) with ESMTP id 5677D15251 for ; Sat, 11 Dec 1999 12:31:21 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from john.baldwin.cx (john [10.0.0.2]) by server.baldwin.cx (8.9.3/8.9.3) with ESMTP id PAA65255; Sat, 11 Dec 1999 15:30:50 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-Id: <199912112030.PAA65255@server.baldwin.cx> X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <18799.944942734@monkeys.com> Date: Sat, 11 Dec 1999 15:30:50 -0500 (EST) From: John Baldwin To: "Ronald F. Guilmette" Subject: Re: Contribution Cc: Martin Hinner , freebsd-hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 11-Dec-99 Ronald F. Guilmette wrote: > > In message <3852771D.8C8BFA3C@newsguy.com>, > Martin Hinner wrote: > >>Anyway, frankly, I don't think this document would be relevant to >>FreeBSD. Perhaps I'm missing something... what would be the purpose >>of having it? > > My two cents: > > I happen to think that the HOWTO- system of Linux is marvelous. If you > want detailed information on one specific topic, e.g. filesystems, or > parallel ports, or RAID, or some such thing, you just go and read the > relevant HOWTO- file. > > A lot of the information in these HOWTO- files would NOT be appropriate > to put into man pages... it's far too chatty. But it is still very very > useful information and it's Good to have it exist (in writing) _somewhere_. > > Seems to me that the closest thing that FreeBSD has to the Linux HOWTO- > files is the FreeBSD Handbook, but that's not as good, precisely because > it _is_ one unified document with (I assume) a single maintainer. It > seems to be better to distribute the psychological sense of ownership > across many many individuals. That's what happens in the case of the > Linux HOWTO- files. No, the Handbook has many maintainers, and they all read the -doc list, which is where you probably should be posting documentation questions: freebsd-doc@FreeBSD.org. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 11 14:33:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by hub.freebsd.org (Postfix) with ESMTP id 4757F14F50 for ; Sat, 11 Dec 1999 14:33:42 -0800 (PST) (envelope-from vsilyaev@mindspring.com) Received: from mindspring.com (user-2ive619.dialup.mindspring.com [165.247.24.41]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id RAA17837 for ; Sat, 11 Dec 1999 17:33:39 -0500 (EST) Received: (from vsilyaev@localhost) by mindspring.com (8.9.3/8.9.3) id RAA00708 for hackers@freebsd.org; Sat, 11 Dec 1999 17:33:37 -0500 (EST) (envelope-from vsilyaev) Date: Sat, 11 Dec 1999 17:33:37 -0500 From: "Vladimir N. Silyaev" To: hackers@freebsd.org Subject: Multiple instances of the same character device Message-ID: <19991211173336.A635@jupiter.delta.ny.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The question is very simple. Is it possible to open the same character pseudo device, for example /dev/foo0, simultaneously from other programs, and to work with this instances independently? I'm asked as the developer of a driver with such requirements, so please don't complain about such technique. I read some discursion about this in the mailing list http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=854845+857264+/usr/local/www/db/text/1997/freebsd-hackers/19970727.freebsd-hackers . But it's old one (dated by begin of '97). -- Vladimir Silyaev To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 11 14:53:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191]) by hub.freebsd.org (Postfix) with ESMTP id 3CA2014FAD; Sat, 11 Dec 1999 14:53:52 -0800 (PST) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id SAA41702; Sat, 11 Dec 1999 18:53:56 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Sat, 11 Dec 1999 18:53:55 -0400 (AST) From: The Hermit Hacker To: David Malone Cc: Zhihui Zhang , freebsd-hackers@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: Why VMIO directory is a bad idea? In-Reply-To: <19991210154459.A1034@hamilton.maths.tcd.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 10 Dec 1999, David Malone wrote: > On Fri, Dec 10, 1999 at 08:56:47AM -0500, Zhihui Zhang wrote: > > > Can anyone give me an idea on how big a directory could be in some > > environment? > > Our inn's /news/spool/control/cancel directory is almost 300k. If > we were a significantly larger news site we probably wouldn't be > running inn though. If you run newer INN's, you could use a CNFS buffer for control, which would make your directory much smaller... My directory's for ~52gig of news: drwxr-xr-x 2 news news 512 Dec 10 12:50 buffer5 drwxr-xr-x 2 news news 512 Dec 10 10:50 buffer4 drwxr-xr-x 2 news news 512 Dec 10 10:25 buffer2 drwxr-xr-x 2 news news 512 Dec 8 07:13 buffer1 drwxr-xr-x 2 news news 512 Dec 8 07:13 buffer3 And they will never change from 512, as each directory contains but one file... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 11 17: 7:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mooseriver.com (superior.mooseriver.com [209.249.56.198]) by hub.freebsd.org (Postfix) with ESMTP id 96A3C14C0C for ; Sat, 11 Dec 1999 17:07:03 -0800 (PST) (envelope-from jgrosch@mooseriver.com) Received: (from jgrosch@localhost) by mooseriver.com (8.9.3/8.9.3) id RAA15746 for hackers@freebsd.org; Sat, 11 Dec 1999 17:06:52 -0800 (PST) (envelope-from jgrosch) Date: Sat, 11 Dec 1999 17:06:52 -0800 From: Josef Grosch To: hackers@freebsd.org Subject: incoming directory on freebsd.org Message-ID: <19991211170652.A15734@mooseriver.com> Reply-To: jgrosch@mooseriver.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a patch to FreeBSD but I am not sure where to upload this file. Can someone point me to the directory? Thanks Josef -- Josef Grosch | Another day closer to a | FreeBSD 3.3 jgrosch@MooseRiver.com | Micro$oft free world | UNIX for the masses To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 11 17:11:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mta2.rcsntx.swbell.net (mta2.rcsntx.swbell.net [151.164.30.26]) by hub.freebsd.org (Postfix) with ESMTP id 44D8414D37 for ; Sat, 11 Dec 1999 17:11:56 -0800 (PST) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org ([216.62.157.60]) by mta2.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FML0017ESNQ8B@mta2.rcsntx.swbell.net> for hackers@FreeBSD.ORG; Sat, 11 Dec 1999 19:11:50 -0600 (CST) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id TAA35721; Sat, 11 Dec 1999 19:13:37 -0600 (CST envelope-from chris) X-URL: http://www.FreeBSD.org/~chris/ Date: Sat, 11 Dec 1999 19:13:33 -0600 From: Chris Costello Subject: Re: incoming directory on freebsd.org In-reply-to: <19991211170652.A15734@mooseriver.com> To: Josef Grosch Cc: hackers@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <19991211191332.A35358@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i X-Operating-System: FreeBSD 4.0-CURRENT (i386) References: <19991211170652.A15734@mooseriver.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Dec 11, 1999, Josef Grosch wrote: > I have a patch to FreeBSD but I am not sure where to upload this file. Can > someone point me to the directory? Use send-pr and include it there. -- |Chris Costello |If it was easy, the hardware people would take care of it. `---------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 11 17:20: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (castles535.castles.com [208.214.165.99]) by hub.freebsd.org (Postfix) with ESMTP id E23E314BC3 for ; Sat, 11 Dec 1999 17:19:59 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id RAA00709; Sat, 11 Dec 1999 17:22:31 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912120122.RAA00709@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Gustavo V G C Rios Cc: hackers@freebsd.org Subject: Re: reboots In-reply-to: Your message of "Fri, 03 Dec 1999 23:04:44 -0200." <384868AC.C6D1CF2A@ddsecurity.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 11 Dec 1999 17:22:31 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi! > I am sending this message, in order to get a help from you wizards. > > Just after turn power on, i get into FreeBSD boot manager, it is given > me three choices: > F1: DOS > F2: FreeBSD > F3: Linux > > Then, i select FreeBSD (F2)! Now, after BTX delay time to boot i time > ESC, what brings me into the following prompt: > > disk2s2a:> > > I issue the reboot command, what cause some register values to be > printed into the screen, and the message: System Halted. This is unfortunately common; some BIOS component can't handle the int19 chain being re-entered before it's reset. This is arguably defective, but it doesn't help you much. I'd suggest that you shouldn't use "reboot". Does alt-ctrl-del work? > I choose FreeBSD (F2), and this is what a get: > > Fatal Trap 22: FPU device not available while in kernel mode I think your machine is in a terribly inconsistent state at this point; you look like you're getting an FPU trap in the kernel. "Don't do this". 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 11 19:16:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 5137614F50 for ; Sat, 11 Dec 1999 19:16:15 -0800 (PST) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id TAA03134; Sat, 11 Dec 1999 19:14:38 -0800 (PST) Message-Id: <199912120314.TAA03134@implode.root.com> To: "Vladimir N. Silyaev" Cc: hackers@FreeBSD.ORG Subject: Re: Multiple instances of the same character device From: David Greenman Reply-To: dg@root.com Date: Sat, 11 Dec 1999 19:14:37 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >The question is very simple. Is it possible to open the same character >pseudo device, for example /dev/foo0, simultaneously from other programs, and >to work with this instances independently? > >I'm asked as the developer of a driver with such requirements, so please don't >complain about such technique. > >I read some discursion about this in the mailing list >http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=854845+857264+/usr/local/www/db/text/1997/freebsd-hackers/19970727.freebsd-hackers . > >But it's old one (dated by begin of '97). The simple answer is yes. The only issue has to do with closing the device. If you don't care about the device driver close routine being called except on the last close, then everything should work just fine. I assume this question is related to you work on VMware for FreeBSD? -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 11 20:24:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by hub.freebsd.org (Postfix) with ESMTP id 2EE7014F41 for ; Sat, 11 Dec 1999 20:24:13 -0800 (PST) (envelope-from vsilyaev@mindspring.com) Received: from mindspring.com (user-2iveauh.dialup.mindspring.com [165.247.43.209]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id XAA13068; Sat, 11 Dec 1999 23:24:10 -0500 (EST) Received: (from vsilyaev@localhost) by mindspring.com (8.9.3/8.9.3) id XAA01743; Sat, 11 Dec 1999 23:24:08 -0500 (EST) (envelope-from vsilyaev) Date: Sat, 11 Dec 1999 23:24:07 -0500 From: "Vladimir N. Silyaev" To: David Greenman Cc: "Vladimir N. Silyaev" , hackers@FreeBSD.ORG Subject: Re: Multiple instances of the same character device Message-ID: <19991211232407.A1699@jupiter.delta.ny.us> References: <199912120314.TAA03134@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <199912120314.TAA03134@implode.root.com>; from dg@root.com on Sat, Dec 11, 1999 at 07:14:37PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Dec 11, 1999 at 07:14:37PM -0800, David Greenman wrote: > >The question is very simple. Is it possible to open the same character > >pseudo device, for example /dev/foo0, simultaneously from other programs, > >and to work with this instances independently? > > > The simple answer is yes. Ok. Where I could to store the pointer to instance of opened device? The data passed to d_open, I mean dev_t, is a specific only to major/minor device number. And how to have access to this context in other device methods? > The only issue has to do with closing the device. > If you don't care about the device driver close routine being called except > on the last close, then everything should work just fine. This is a unlikely future, to have only on last close, because close doing release of system resources (per instance allocated). > I assume this question is related to you work on VMware for FreeBSD? Exactly, this guys to create new virtual machine opened /dev/vmmon device, and stored private data in the special field of the 'struct file'. And the same, with networking. Of course I mean Linux version of their drivers. The FreeBSD version of these drivers store data in the dev_t structure, and because of that it's working fine until you are don't tried to open a new session. -- Vladimir Silyaev To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 11 20:38:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from monkeys.com (i180.value.net [206.14.136.180]) by hub.freebsd.org (Postfix) with ESMTP id D69E71502A for ; Sat, 11 Dec 1999 20:38:27 -0800 (PST) (envelope-from rfg@monkeys.com) Received: from monkeys.com (localhost [127.0.0.1]) by monkeys.com (8.9.3/8.9.3) with ESMTP id UAA01034 for ; Sat, 11 Dec 1999 20:37:44 -0800 (PST) To: freebsd-hackers@freebsd.org Subject: SCSI tape minor device numbers Date: Sat, 11 Dec 1999 20:37:44 -0800 Message-ID: <1032.944973464@monkeys.com> From: "Ronald F. Guilmette" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The sa(4) man page describes the semantics of the low-order two bits of the minor device numbers for SCSI tape devices. Can anyone tell me what the semantics of the next two higher bits of the minor device number are? # ls -l /dev/*sa* crw-rw---- 2 root operator 14, 2 Oct 25 19:41 /dev/ersa0 crw-rw---- 2 root operator 14, 2 Oct 25 19:41 /dev/ersa0.0 crw-rw---- 1 root operator 14, 6 Oct 25 19:41 /dev/ersa0.1 crw-rw---- 1 root operator 14, 10 Oct 25 19:41 /dev/ersa0.2 crw-rw---- 1 root operator 14, 14 Oct 25 19:41 /dev/ersa0.3 crw-rw---- 2 root operator 14, 1 Oct 25 19:41 /dev/nrsa0 crw-rw---- 2 root operator 14, 1 Oct 25 19:41 /dev/nrsa0.0 crw-rw---- 1 root operator 14, 5 Oct 25 19:41 /dev/nrsa0.1 crw-rw---- 1 root operator 14, 9 Oct 25 19:41 /dev/nrsa0.2 crw-rw---- 1 root operator 14, 13 Oct 25 19:41 /dev/nrsa0.3 crw-rw---- 2 root operator 14, 0 Oct 25 19:41 /dev/rsa0 crw-rw---- 2 root operator 14, 0 Oct 25 19:41 /dev/rsa0.0 crw-rw---- 1 root operator 14, 4 Oct 25 19:41 /dev/rsa0.1 crw-rw---- 1 root operator 14, 8 Oct 25 19:41 /dev/rsa0.2 crw-rw---- 1 root operator 14, 12 Oct 25 19:41 /dev/rsa0.3 crw-rw---- 1 root wheel 14, 0x20000000 Oct 25 19:41 /dev/rsa0.ctl Another question: I just plugged in my HP 35480A SCSI DAT drive to my FreeBSD system. Of course, FreeBSD seems not to like it, even though the drive itself gives no indication of any problems. Each time I try to access the drive, I get the following set of three log messages on the system console: (sa0:ahc0:0:5:0): RESERVE(06). CDB: 16 0 0 0 0 0 (sa0:ahc0:0:5:0): HARDWARE FAILURE asc:0,4 (sa0:ahc0:0:5:0): Beginning-of-partition/medium detected The first and the last of these three messages seem benign enough, but it seem awfully clear that the middle one is related to whatever is causing the relevant device file to yield only an `I/O Error' each time I try to open it. Can anyone interpret this for me: HARDWARE FAILURE asc:0,4 What does it mean? It this just the numeric code for ``Buy another tape drive''? :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 11 22:52: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id 2AB3C14F3D for ; Sat, 11 Dec 1999 22:52:00 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id BAA75450; Sun, 12 Dec 1999 01:51:58 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14419.17934.412876.592234@trooper.velocet.net> Date: Sun, 12 Dec 1999 01:51:58 -0500 (EST) To: freebsd-hackers@freebsd.org Subject: Holding daemon filehandles. X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Not that this is crucially important, but does nfsd really need to hold open 4 filehandles? I can understand the one on it's binary, but according to lsof, it holds open 3 copies of /dev/null (for stdin, stdout and stderr). Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 11 23: 8:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from onyx.extra.dp.ua (ltty12.dnepr.net.ua [195.248.169.28]) by hub.freebsd.org (Postfix) with ESMTP id D540914D5B; Sat, 11 Dec 1999 23:08:47 -0800 (PST) (envelope-from green@onyx.extra.dp.ua) Received: (from green@localhost) by onyx.extra.dp.ua (8.9.3/8.9.3/BSD) id JAA02806; Sun, 12 Dec 1999 09:08:43 +0200 (EET) Date: Sun, 12 Dec 1999 09:08:43 +0200 From: Alexey Prohorenko To: freebsd-questions@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Problem with FreeBSD/Apache! Message-ID: <19991212090843.A2778@la.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, I have some problem with Apache. I have few Apache modules (written by me), they are working with mySQL databases and based on Apache C API. They works perfectly well at my FreeBSD 2.2.8-STABLE with Apache 1.3.9 and mySQL 3.22.25. When I upgrade my system to FreeBSD 3.3-STABLE (Apache 1.3.9/mySQL 3.22.25) I found that my modules DOES NOT work on it! httpd fails with error 11 (so no core dump created). Some modules works, but I big part -- not. They are using ap_internal_redirect () fucntion, so I checked everything -- may be I did some wrong pathnames? No. Then, I though that this is because I am using gcc/ld and do not use apxs. After using apxs no changes appeared -- still httpd fails! So, I decide to test one of my modules step-by-step. And I found that when I am calling for little function like this: void dummy (void) { } it fails!!! Why? I do not understand. May be you will help me with this problem? At this moment, I think that Apache (or FreeBSD) has problems with ELF binaries. May be Apache couldn't work with ELF binaries correctly? I do not know the reason. Thank you. Looking forward your answer. -- green@la.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 11 23:35:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 24F10150B4; Sat, 11 Dec 1999 23:35:20 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA70827; Sat, 11 Dec 1999 23:35:19 -0800 (PST) (envelope-from dillon) Date: Sat, 11 Dec 1999 23:35:19 -0800 (PST) From: Matthew Dillon Message-Id: <199912120735.XAA70827@apollo.backplane.com> To: freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Reply-To: freebsd-hackers@freebsd.org Subject: Recent NFS commits, plus Heads up to 2.2.x users Hello everyone. There have been a number of recent NFS commits to fix bugs. Everything is hunky dory, but I do not have a 2.2.x box to test the MFC to 2.2.x so this is a head's up to 2.2.x users who are using NFS that these (relatively simple) bug fixes have been MFC'd, but not tested. It would be nice if I could get confirmation that 2.2.x hasn't blow up :-) -Matt Matthew Dillon dillon 1999/12/11 19:19:33 PST Modified files: sys/kern vfs_subr.c vfs_syscalls.c sys/vm vm_fault.c vm_map.c vm_map.h vm_mmap.c vm_object.c vm_object.h vm_page.c vm_page.h sys/sys mman.h lib/libc/sys madvise.2 mmap.2 Log: Add MAP_NOSYNC feature to mmap(), and MADV_NOSYNC and MADV_AUTOSYNC to madvise(). This feature prevents the update daemon from gratuitously flushing dirty pages associated with a mapped file-backed region of memory. The system pager will still page the memory as necessary and the VM system will still be fully coherent with the filesystem. Modifications made by other means to the same area of memory, for example by write(), are unaffected. The feature works on a page-granularity basis. MAP_NOSYNC allows one to use mmap() to share memory between processes without incuring any significant filesystem overhead, putting it in the same performance category as SysV Shared memory and anonymous memory. Reviewed by: julian, alc, dg Revision Changes Path 1.239 +2 -2 src/sys/kern/vfs_subr.c 1.147 +3 -2 src/sys/kern/vfs_syscalls.c 1.108 +17 -3 src/sys/vm/vm_fault.c 1.184 +16 -3 src/sys/vm/vm_map.c 1.52 +3 -2 src/sys/vm/vm_map.h 1.105 +5 -4 src/sys/vm/vm_mmap.c 1.171 +32 -5 src/sys/vm/vm_object.c 1.62 +4 -3 src/sys/vm/vm_object.h 1.147 +8 -4 src/sys/vm/vm_page.c 1.74 +5 -5 src/sys/vm/vm_page.h 1.27 +4 -1 src/sys/sys/mman.h 1.16 +28 -1 src/lib/libc/sys/madvise.2 1.18 +30 -1 src/lib/libc/sys/mmap.2 dillon 1999/12/11 19:28:15 PST Modified files: sys/kern vfs_syscalls.c Log: Remove accidental pollution unrelated to previous commit. The issue here is real but has not yet been discussed with Eivind. Revision Changes Path 1.148 +2 -3 src/sys/kern/vfs_syscalls.c dillon 1999/12/11 22:09:58 PST Modified files: sys/nfs nfs_bio.c nfs_subs.c nfs_vnops.c sys/sys buf.h Log: Synopsis of problem being fixed: Dan Nelson originally reported that blocks of zeros could wind up in a file written to over NFS by a client. The problem only occurs a few times per several gigabytes of data. This problem turned out to be bug #3 below. bug #1: B_CLUSTEROK must be cleared when an NFS buffer is reverted from stage 2 (ready for commit rpc) to stage 1 (ready for write). Reversions can occur when a dirty NFS buffer is redirtied with new data. Otherwise the VFS/BIO system may end up thinking that a stage 1 NFS buffer is clusterable. Stage 1 NFS buffers are not clusterable. bug #2: B_CLUSTEROK was inappropriately set for a 'short' NFS buffer (short buffers only occur near the EOF of the file). Change to only set when the buffer is a full biosize (usually 8K). This bug has no effect but should be fixed in -current anyway. It need not be backported. bug #3: B_NEEDCOMMIT was inappropriately set in nfs_flush() (which is typically only called by the update daemon). nfs_flush() does a multi-pass loop but due to the lack of vnode locking it is possible for new buffers to be added to the dirtyblkhd list while a flush operation is going on. This may result in nfs_flush() setting B_NEEDCOMMIT on a buffer which has *NOT* yet gone through its stage 1 write, causing only the commit rpc to be made and thus causing the contents of the buffer to be thrown away (never sent to the server). The patch also contains some cleanup, which only applies to the commit into -current. Reviewed by: dg, julian Originally Reported by: Dan Nelson Revision Changes Path 1.81 +27 -11 src/sys/nfs/nfs_bio.c 1.86 +15 -7 src/sys/nfs/nfs_subs.c 1.148 +3 -27 src/sys/nfs/nfs_vnops.c 1.85 +8 -1 src/sys/sys/buf.h dillon 1999/12/11 22:52:35 PST Modified files: (Branch: RELENG_3) sys/nfs nfs_bio.c nfs_subs.c nfs_vnops.c Log: MFC nfs_bio.c 1.81, nfs_subs.c 1.86, nfs_vnops.c 1.148. Fixed two rare-occuring bugs in NFS. First, B_CLUSTEROK must be cleared when B_NEEDCOMMIT is cleared since uncommitted dirty buffers may not be clustered. Second, B_NEEDCOMMIT cannot be gratuitously set in nfs_flush(). Due to lack of locking a buffer may be added to the dirtyblkhd list during the flush and setting B_NEEDCOMMIT can result in the buffer's data being thrown away rather then written to the server. Reviewed by: dg Approved by: jkh Revision Changes Path 1.65.2.3 +4 -4 src/sys/nfs/nfs_bio.c 1.70.2.4 +2 -2 src/sys/nfs/nfs_subs.c 1.116.2.8 +4 -4 src/sys/nfs/nfs_vnops.c dillon 1999/12/11 23:06:40 PST Modified files: sys/nfs nfs_nqlease.c nfs_serv.c nfs_subs.c Log: Fix a number of server-side issues related to aborting badly formed NFS packets, mainly initializing structure pointers to NULL which are conditionally freed prior to return. PR: kern/15249 Submitted by: Ian Dowse Revision Changes Path 1.47 +4 -2 src/sys/nfs/nfs_nqlease.c 1.89 +5 -5 src/sys/nfs/nfs_serv.c 1.87 +4 -1 src/sys/nfs/nfs_subs.c dillon 1999/12/11 23:16:21 PST Modified files: (Branch: RELENG_3) sys/nfs nfs_nqlease.c nfs_serv.c nfs_subs.c Log: MFC nfs_nqlease 1.47, nfs_serv.c 1.89, nfs_subs.c 1.87. Prevent panics in server side abort code when dealing with malformed NFS packets. Approved by: jkh Revision Changes Path 1.39.2.3 +4 -2 src/sys/nfs/nfs_nqlease.c 1.72.2.6 +5 -5 src/sys/nfs/nfs_serv.c 1.70.2.5 +4 -1 src/sys/nfs/nfs_subs.c dillon 1999/12/11 23:25:12 PST Modified files: (Branch: RELENG_2_2) sys/nfs nfs_nqlease.c nfs_subs.c Log: MFC nfs_nqlease 1.47, nfs_serv.c 1.89, nfs_subs.c 1.87. Note that no changes to nfs_serv.c were required, the bugs in that routine were introduced after 2.2.x. Revision Changes Path 1.20.2.2 +4 -2 src/sys/nfs/nfs_nqlease.c 1.33.2.4 +3 -1 src/sys/nfs/nfs_subs.c dillon 1999/12/11 23:28:52 PST Modified files: (Branch: RELENG_2_2) sys/nfs nfs_bio.c nfs_subs.c nfs_vnops.c Log: MFC nfs_bio.c 1.81, nfs_subs.c 1.86, nfs_vnops.c 1.148 Revision Changes Path 1.28.2.11 +3 -3 src/sys/nfs/nfs_bio.c 1.33.2.5 +2 -2 src/sys/nfs/nfs_subs.c 1.36.2.12 +4 -4 src/sys/nfs/nfs_vnops.c Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 11 23:37:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id CEC6414F5B for ; Sat, 11 Dec 1999 23:37:57 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA70858; Sat, 11 Dec 1999 23:37:55 -0800 (PST) (envelope-from dillon) Date: Sat, 11 Dec 1999 23:37:55 -0800 (PST) From: Matthew Dillon Message-Id: <199912120737.XAA70858@apollo.backplane.com> To: David Gilbert Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Holding daemon filehandles. References: <14419.17934.412876.592234@trooper.velocet.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Not that this is crucially important, but does nfsd really need to :hold open 4 filehandles? I can understand the one on it's binary, but :according to lsof, it holds open 3 copies of /dev/null (for stdin, :stdout and stderr). : :Dave. : :-- :============================================================================ :|David Gilbert, Velocet Communications. | Two things can only be | nfsd probably doesn't, but its a general safety feature when it daemonizes to prevent standard open()'s from using descriptors 0, 1, and 2. Don't worry, the file handles are simply 3 references to the same device and should not be taking up any space in the file table. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 11 23:38:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id E8A2B14CDE; Sat, 11 Dec 1999 23:38:47 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA70877; Sat, 11 Dec 1999 23:38:47 -0800 (PST) (envelope-from dillon) Date: Sat, 11 Dec 1999 23:38:47 -0800 (PST) From: Matthew Dillon Message-Id: <199912120738.XAA70877@apollo.backplane.com> To: freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Recent NFS commits, plus Heads up to 2.2.x users Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Holy formatting! Sorry about that. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message