From owner-freebsd-hackers Sun Feb 21 0:21:56 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 SMTP id B36D510E0B for ; Sun, 21 Feb 1999 00:21:32 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 10EU8o-0003Nf-00; Sun, 21 Feb 1999 01:21:30 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.2/8.8.3) with ESMTP id BAA00506; Sun, 21 Feb 1999 01:20:56 -0700 (MST) Message-Id: <199902210820.BAA00506@harmony.village.org> To: John Polstra Subject: Re: FreeBSD mention in LWN interview with A.C. Cc: Jamie Bowden , hackers@FreeBSD.ORG In-reply-to: Your message of "Tue, 16 Feb 1999 11:09:15 PST." References: Date: Sun, 21 Feb 1999 01:20:56 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message John Polstra writes: : Of course I'm biased, but that doesn't change the validity of my : statement. cvsup is faster than perforce, from what I can tell, but perforce is faster at remote operations, generally, the cvs. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 0:37:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id BEB2E10E0B for ; Sun, 21 Feb 1999 00:37:28 -0800 (PST) (envelope-from sthaug@nethelp.no) Received: (qmail 21257 invoked by uid 1001); 21 Feb 1999 08:26:28 +0000 (GMT) To: jkb@best.com Cc: grog@lemis.com, hackers@FreeBSD.ORG, FreeBSD-isp@FreeBSD.ORG Subject: Re: New breakin technique? From: sthaug@nethelp.no In-Reply-To: Your message of "Sat, 20 Feb 1999 22:14:53 -0800" References: <19990220221453.B15747@best.com> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sun, 21 Feb 1999 09:26:28 +0100 Message-ID: <21255.919585588@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This should go to -security@ but anyway - they think that > freebie is a solaris box. There is remote exploit for rpc.statd > for solaris. See: > http://www.geek-girl.com/bugtraq/1997_4/0378.html > But please don't run rpc.statd if you don't need it in any > case? Thanks, :) So why are rpc.statd and portmap started by default in FreeBSD? (I've been turning them off since I started using FreeBSD. Now, with the /etc/defaults/rc.conf mechanism, it's real easy to keep my local mods :-) Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 0:43: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 3BB5610E6E for ; Sun, 21 Feb 1999 00:43:02 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id AAA18826; Sun, 21 Feb 1999 00:42:51 -0800 (PST) (envelope-from dillon) Date: Sun, 21 Feb 1999 00:42:51 -0800 (PST) From: Matthew Dillon Message-Id: <199902210842.AAA18826@apollo.backplane.com> To: Kevin Day Cc: hackers@FreeBSD.ORG Subject: Re: ESTALE the best approach? References: <199902210737.BAA21850@home.dragondata.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Anyone have any comments on this? Only cron is maintained here. All the other programs are maintained by their authors or groups elsewhere. There isn't much we can do about them. Also, most of these are IRC tools. IRC tools are notoriously badly written. To give you an example, there was an eggdrop floating around for months about a year ago which had hacked in signal(SIGSEGV, handler) to make the program ignore segv violations because the programmer who made the mod was too clueless to understand what sigsegv actually meant. -Matt Matthew Dillon : :I've found that at least these programs cannot deal with ESTALE in some :manner: : :cron :apache httpd :eggdrop :afio :bnc :ircii :bitchx : : : :Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 0:53:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from home.dragondata.com (home.dragondata.com [204.137.237.2]) by hub.freebsd.org (Postfix) with ESMTP id BDD1210E54 for ; Sun, 21 Feb 1999 00:53:13 -0800 (PST) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.9.2/8.9.2) id CAA25778; Sun, 21 Feb 1999 02:53:11 -0600 (CST) From: Kevin Day Message-Id: <199902210853.CAA25778@home.dragondata.com> Subject: Re: ESTALE the best approach? In-Reply-To: <199902210842.AAA18826@apollo.backplane.com> from Matthew Dillon at "Feb 21, 1999 0:42:51 am" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Sun, 21 Feb 1999 02:53:10 -0600 (CST) Cc: hackers@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 > : > :Anyone have any comments on this? > > Only cron is maintained here. All the other programs are maintained > by their authors or groups elsewhere. There isn't much we can do about > them. > > Also, most of these are IRC tools. IRC tools are notoriously badly > written. To give you an example, there was an eggdrop floating around > for months about a year ago which had hacked in signal(SIGSEGV, handler) > to make the program ignore segv violations because the programmer who > made the mod was too clueless to understand what sigsegv actually meant. Most of my customers are running irc tools, so that's probably why i'm mostly finding irc tools causing the problems. I'll probably end up patching something locally to just shoot the program down if it would have ESTALE'ed, since my chances of getting ~1000 people to patch their software is pretty well 0. Having a confused piece of software saturate a 100MB ethernet link with nfs getattr requests, and knock the load up on both the nfs client and server is definately a bad thing. Setting a cpu limit on for the client doesn't work either. Most of the time spent doing this isn't accounted to the buggy program, and, when a process gets killed for 'cpu time exceeded', and the executable is ran from an nfs mount, hell tends to break loose. (vm_fault: pager input (probably hardware error) messages begin to flood you to death) But... Does anyone really take ESTALE and do anything productive with it? I can't really think of many situations where you're going to do anything but abort after seeing this. At least... Nothing I'm running needs to know about it. :) Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 0:56:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from shell6.ba.best.com (shell6.ba.best.com [206.184.139.137]) by hub.freebsd.org (Postfix) with ESMTP id 5A90210E64; Sun, 21 Feb 1999 00:56:56 -0800 (PST) (envelope-from jkb@shell6.ba.best.com) Received: (from jkb@localhost) by shell6.ba.best.com (8.9.3/8.9.2/best.sh) id AAA01604; Sun, 21 Feb 1999 00:56:15 -0800 (PST) Message-ID: <19990221005615.A559@best.com> Date: Sun, 21 Feb 1999 00:56:15 -0800 From: "Jan B. Koum " To: sthaug@nethelp.no Cc: grog@lemis.com, hackers@FreeBSD.ORG, FreeBSD-isp@FreeBSD.ORG Subject: Re: New breakin technique? References: <19990220221453.B15747@best.com> <21255.919585588@verdi.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <21255.919585588@verdi.nethelp.no>; from sthaug@nethelp.no on Sun, Feb 21, 1999 at 09:26:28AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Feb 21, 1999 at 09:26:28AM +0100, sthaug@nethelp.no wrote: > > This should go to -security@ but anyway - they think that > > freebie is a solaris box. There is remote exploit for rpc.statd > > for solaris. See: > > http://www.geek-girl.com/bugtraq/1997_4/0378.html > > But please don't run rpc.statd if you don't need it in any > > case? Thanks, :) > > So why are rpc.statd and portmap started by default in FreeBSD? AFAIK only portmap is started. Not rpc.statd - but I do agree with you that portmap should not be started by default. Jordan - your call? > > (I've been turning them off since I started using FreeBSD. Now, with the > /etc/defaults/rc.conf mechanism, it's real easy to keep my local mods :-) > Same here... I kill portmap, inetd and start syslogd with -s among other things. -- Yan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 1: 2:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id DB155112CE for ; Sun, 21 Feb 1999 01:02:34 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id HAA13519; Sun, 21 Feb 1999 07:51:42 +0100 From: Luigi Rizzo Message-Id: <199902210651.HAA13519@labinfo.iet.unipi.it> Subject: Re: HEADS UP: FS Disaster To: root@tomqnx.com (Tom Torrance at home Root) Date: Sun, 21 Feb 1999 07:51:41 +0100 (MET) Cc: hackers@FreeBSD.ORG In-Reply-To: from "Tom Torrance at home Root" at Feb 20, 99 11:24:42 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 892 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I am also missing the 'Mail' directory from the RELENG_2_2-stable root > partition which is NOT available to the RELENG_3-stable system. > > There is a very good chance that this is related to luigi's change, > which is the only new item that went into the RELENG_2_2-stable said change only affects packets which go through a dummynet pipe, and moreover it is a NOP unless you have a pkt larger than MTU and with the DF bit set, in which case you the code before the patch gives a very repeatable panic/reboot. Such pkts are extremely unlikely i'd say. Beside that, i have tested that the above patch works as expected (this on a diskless machine, so the net code is pretty well exercised...) > kernel recompile today. Extreme appologies in advance if I am wrong, > but I would look there first! no problem, but i really think your problem is unrelated to my patch. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 1: 5:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id 91BC81155A for ; Sun, 21 Feb 1999 01:05:22 -0800 (PST) (envelope-from sthaug@nethelp.no) Received: (qmail 21713 invoked by uid 1001); 21 Feb 1999 09:05:22 +0000 (GMT) To: jkb@best.com Cc: hackers@FreeBSD.ORG, FreeBSD-isp@FreeBSD.ORG Subject: Re: New breakin technique? From: sthaug@nethelp.no In-Reply-To: Your message of "Sun, 21 Feb 1999 00:56:15 -0800" References: <19990221005615.A559@best.com> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sun, 21 Feb 1999 10:05:22 +0100 Message-ID: <21711.919587922@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > So why are rpc.statd and portmap started by default in FreeBSD? > > AFAIK only portmap is started. Not rpc.statd - but I do > agree with you that portmap should not be started by > default. Jordan - your call? $Id: rc.conf,v 1.83 1999/02/09 04:17:45 dillon Exp $ ... rpc_statd_enable="YES" # Run NFS rpc.statd if nfs_server (or NO). portmap_enable="YES" # Run the portmapper service (or NO). AFAIK starting those have been the defaults for at least a couple of years. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 1:19:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from shell6.ba.best.com (shell6.ba.best.com [206.184.139.137]) by hub.freebsd.org (Postfix) with ESMTP id 2EFCE10E0B; Sun, 21 Feb 1999 01:19:47 -0800 (PST) (envelope-from jkb@shell6.ba.best.com) Received: (from jkb@localhost) by shell6.ba.best.com (8.9.3/8.9.2/best.sh) id BAA03504; Sun, 21 Feb 1999 01:19:20 -0800 (PST) Message-ID: <19990221011920.A3370@best.com> Date: Sun, 21 Feb 1999 01:19:20 -0800 From: "Jan B. Koum " To: sthaug@nethelp.no Cc: hackers@FreeBSD.ORG, FreeBSD-isp@FreeBSD.ORG Subject: Re: New breakin technique? References: <19990221005615.A559@best.com> <21711.919587922@verdi.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <21711.919587922@verdi.nethelp.no>; from sthaug@nethelp.no on Sun, Feb 21, 1999 at 10:05:22AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Feb 21, 1999 at 10:05:22AM +0100, sthaug@nethelp.no wrote: > > > So why are rpc.statd and portmap started by default in FreeBSD? > > > > AFAIK only portmap is started. Not rpc.statd - but I do > > agree with you that portmap should not be started by > > default. Jordan - your call? > > $Id: rc.conf,v 1.83 1999/02/09 04:17:45 dillon Exp $ > ... > rpc_statd_enable="YES" # Run NFS rpc.statd if nfs_server (or NO). Since NFR is not on by default rpc.statd is not on by default either. Plus I tend to stay way from NFS when I need security :) -- Yan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 1:48: 9 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 992E110E01 for ; Sun, 21 Feb 1999 01:48:05 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA55204; Sun, 21 Feb 1999 09:47:16 GMT (envelope-from dfr@nlsystems.com) Date: Sun, 21 Feb 1999 09:47:16 +0000 (GMT) From: Doug Rabson To: Terry Lambert Cc: dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday In-Reply-To: <199902210011.RAA22231@usr08.primenet.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, 21 Feb 1999, Terry Lambert wrote: > > I think promoting directory writes (and directory reads probably) might be > > the simplest solution. > > Hum. This is trivial... > > Let's see... is there a free flag? Yes... > > OK, here's code to add the ability to expedite placement of async > writes. It' doesn't insert them in order behind other expedited > writes, so it turns the expedited stuff LIFO. This is probably > suboptimal, but can't happen in dependent operations, so what the > heck... > > When you use the code, be sure to *not* set the flag if soft updates > are in effect (I think that's a caller issue, not a callee issue, since > it would complicate the bdwrite code, probably unacceptably. I don't think this will do the job at all. The buffers in question are not delayed writes, so all this patch will do is change the order of the LOCKED and LRU lists, probably pessimising the reuse of those buffers. I think the flag needs to be implemented in the driver. The driver should check for the EXPEDITE flag and either maintain two queues for the two possible priorities or place the buffer at the front of a single work queue. -- 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 Sun Feb 21 2:10:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from shibumi.feralmonkey.org (shibumi.feralmonkey.org [203.41.114.182]) by hub.freebsd.org (Postfix) with ESMTP id B994B111E8 for ; Sun, 21 Feb 1999 02:10:29 -0800 (PST) (envelope-from nick@FERALMONKEY.ORG) Received: from shibumi (shibumi [203.41.114.182]) by shibumi.feralmonkey.org (Postfix) with ESMTP id 63953780B; Sat, 21 Feb 1998 21:15:39 +1100 (EST) Date: Sat, 21 Feb 1998 21:15:38 +1100 (EST) From: To: John Smith Cc: freebsd-hackers@freebsd.org Subject: Re: Packet generation. 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 Perhaps if you outlined what you intend to do, we would be better able to suggest a solution. Nick -- "We all agree that your theory is crazy, but is it crazy enough?" - Niels Bohr (1885 - 1962) On Sun, 21 Feb 1999, John Smith wrote: > > Hello; > > Can anyone help me find a packet generator that will compile on > FreeBSD? I've tried spak, libnet, and spoofit.h; and spak does not compile > under freebsd, libnet can't really do what I want; and spoofit.h is only > of sending tcp and udp stuff; also for linux. (btw; spak does not really > work under linux too) > > I would like to be able to send all kind of packets, and it must > be native freebsd code. > > Any ideas/help appreciated. > > -John > > > > > > > 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 Feb 21 2:15: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [208.221.12.98]) by hub.freebsd.org (Postfix) with ESMTP id D4AE911601 for ; Sun, 21 Feb 1999 02:15:06 -0800 (PST) (envelope-from root@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 CAA12398; Sun, 21 Feb 1999 02:12:16 -0800 (PST) Message-Id: <199902211012.CAA12398@implode.root.com> To: Greg Skafte Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: intel ether express pro 100's In-reply-to: Your message of "Sat, 20 Feb 1999 18:13:10 MST." <19990220181309.A6999@gras-varg.worldgate.com> From: David Greenman Reply-To: dg@root.com Date: Sun, 21 Feb 1999 02:12:15 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >are there any issues or quirks with the new 100+ _management_ adapters >they are based on the 82559 instead of the 82558 I've not heard of the 82559 until just now...I have no idea what it is. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 2:20:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from shibumi.feralmonkey.org (shibumi.feralmonkey.org [203.41.114.182]) by hub.freebsd.org (Postfix) with ESMTP id 5F8F111A31 for ; Sun, 21 Feb 1999 02:20:47 -0800 (PST) (envelope-from nick@FERALMONKEY.ORG) Received: from shibumi (shibumi [203.41.114.182]) by shibumi.feralmonkey.org (Postfix) with ESMTP id 2464B780B; Sat, 21 Feb 1998 21:26:03 +1100 (EST) Date: Sat, 21 Feb 1998 21:26:03 +1100 (EST) From: To: John Smith Cc: freebsd-hackers@freebsd.org Subject: Re: Packet generation. 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 You might also wish to look at Net::RawIP, a perl module "to manipulate raw IP packets" (from webpage). The url is http://quake.skif.net/RawIP/ Nick -- "We all agree that your theory is crazy, but is it crazy enough?" - Niels Bohr (1885 - 1962) On Sun, 21 Feb 1999, John Smith wrote: > > Hello; > > Can anyone help me find a packet generator that will compile on > FreeBSD? I've tried spak, libnet, and spoofit.h; and spak does not compile > under freebsd, libnet can't really do what I want; and spoofit.h is only > of sending tcp and udp stuff; also for linux. (btw; spak does not really > work under linux too) > > I would like to be able to send all kind of packets, and it must > be native freebsd code. > > Any ideas/help appreciated. > > -John > > > > > > > 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 Feb 21 2:39:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [208.221.12.98]) by hub.freebsd.org (Postfix) with ESMTP id A6DB411721 for ; Sun, 21 Feb 1999 02:39:49 -0800 (PST) (envelope-from root@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 CAA12487; Sun, 21 Feb 1999 02:37:07 -0800 (PST) Message-Id: <199902211037.CAA12487@implode.root.com> To: Bill Paul Cc: hackers@FreeBSD.ORG Subject: Re: How to handle jumbo etherney frames In-reply-to: Your message of "Sat, 20 Feb 1999 23:58:02 EST." <199902210458.XAA12913@skynet.ctr.columbia.edu> From: David Greenman Reply-To: dg@root.com Date: Sun, 21 Feb 1999 02:37:07 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The jumbo frames are only useful if you also have VLAN support, which we don't have currently. We also need support for large mbuf clusters; this probably should be done by implementing external-buffer management functions ala sendfile's sf_bufs. For now I think the sensible thing to do is use standard ethernet frames and deal with jumbo's when the infrustructure is there to support them. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project >Recently I obtained the programming info for the Alteon Tigon gigabit >ethernet chip (http://www.alteon.com/support/openkits). This is the >chip used in the Alteon AceNIC, the 3Com 3c985 and the Netgear GA620 >ethernet boards. The Tigon supports jumbo ethernet frames, which are >9014 bytes in size (14 bytes header, 9000 bytes data). > >The use of jumbo frames is optional, but I'd like to support them. >The question is, what's the best mbuf allocation strategy for receiving >frames this size? The scheme I normally use is to allocate a single mbuf >with MGETHDR and then attach an mbuf cluster to that with MCLGET. >An mbuf cluster buffer is 2K, which is enough to hold a complete >ethernet frame up to the maximum frame size (1514). The address >of the cluster buffer is passed to the ethernet controller, so that >it can DMA received packets directly into the mbuf which can then >be passed directly to ether_input() without any buffer copying. >(And avoiding buffer copying at gigabit speeds is highly desireable.) > >I would like to use something similar for the jumbo frames, but >I'm not entirely sure how to pre-allocate the buffers. I thought >about allocating external mbuf storage independent of the cluster >buffer pool, but 9K is larger than the page size, so I'd need to use >contigmalloc() in order to be sure of getting contiguous pages (the >chip will be DMAing into the buffers and it has no knowledge of the >kernel's virtual page mappings). Using contigmalloc() can easily >fail as memory becomes fragmented however. > >The alternative is to allocate an mbuf cluster chain, breaking up >the packet into 2K chunks. I think this involves one MGETHDR(), >four MGET()s and five MCLGETS(). It would be nice to find a >quick and dirty way to allocate the chain, but I don't see one >offhand. > >It's very possible that there's a more elegant way to handle this, >but I haven't been able to think of any. If anyone has any suggesstions, >I'd love to hear them. > >-Bill > >-- >============================================================================= >-Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu >Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research >Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City >============================================================================= > "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" >============================================================================= > > >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 Feb 21 4:38:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [208.221.12.98]) by hub.freebsd.org (Postfix) with ESMTP id B0210118BF for ; Sun, 21 Feb 1999 04:38:13 -0800 (PST) (envelope-from root@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 EAA12927; Sun, 21 Feb 1999 04:35:00 -0800 (PST) Message-Id: <199902211235.EAA12927@implode.root.com> To: Luigi Rizzo Cc: wpaul@skynet.ctr.columbia.edu, hackers@FreeBSD.ORG Subject: Re: How to handle jumbo etherney frames In-reply-to: Your message of "Sun, 21 Feb 1999 11:01:57 +0100." <199902211001.LAA13773@labinfo.iet.unipi.it> From: David Greenman Reply-To: dg@root.com Date: Sun, 21 Feb 1999 04:35:00 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> The jumbo frames are only useful if you also have VLAN support, which we >> don't have currently. We also need support for large mbuf clusters; this > >hmmm i don't get this -- why is this related to VLAN ? Because most ethernets consist of a mix of hosts that don't have jumbo frame capability. If you use jumbo frames without VLANs, then ALL hosts must support jumbo frames (and I think would also have to be gigabit ethernet connected since jumbo frames weren't supported in 802.3...although I'm assuming that the gigabit spec allows for jumbo frames, which may be a bad assumption on my part). -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 4:54:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from baerenklau.de.freebsd.org (baerenklau.de.freebsd.org [195.185.195.14]) by hub.freebsd.org (Postfix) with ESMTP id 64CC711B68 for ; Sun, 21 Feb 1999 04:54:46 -0800 (PST) (envelope-from wosch@panke.de.freebsd.org) Received: (from uucp@localhost) by baerenklau.de.freebsd.org (8.8.8/8.8.8) with UUCP id NAA13021 for hackers@freebsd.org; Sun, 21 Feb 1999 13:54:46 +0100 (CET) (envelope-from wosch@panke.de.freebsd.org) Received: (from wosch@localhost) by paula.panke.de.freebsd.org (8.9.3/8.8.8) id MAA01078; Sun, 21 Feb 1999 12:47:16 +0100 (CET) (envelope-from wosch) Message-ID: <19990221124716.57180@panke.de.freebsd.org> Date: Sun, 21 Feb 1999 12:47:16 +0100 From: Wolfram Schneider To: hackers@freebsd.org Subject: CVSup collection for a NetBSD CVS tree Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I created a private, non-tainted NetBSD CVS tree. The NetBSD CVS tree contain the releases NetBSD 1.0, 1.1, 1.2, 1.2.1, 1.3 and -current. Unfortunately, the log messages are empty and only available from the NetBSD mailing list archive. The NetBSD CVS tree is available from the host cvsup.de.freebsd.org, supported collections: NetBSD-base # NetBSD CVSROOT NetBSD-src # NetBSD CVS source tree NetBSD-doc # NetBSD CVS documentation tree Web: http://www.de.freebsd.org/cgi/cvsweb.cgi The NetBSD sources are updated daily. For more information about CVSup, see http://www.freebsd.org/handbook/cvsup.html -- Wolfram Schneider http://wolfram.schneider.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 5: 0:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id DE49F11BC7 for ; Sun, 21 Feb 1999 05:00:41 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id LAA13773; Sun, 21 Feb 1999 11:01:57 +0100 From: Luigi Rizzo Message-Id: <199902211001.LAA13773@labinfo.iet.unipi.it> Subject: Re: How to handle jumbo etherney frames To: dg@root.com Date: Sun, 21 Feb 1999 11:01:57 +0100 (MET) Cc: wpaul@skynet.ctr.columbia.edu, hackers@FreeBSD.ORG In-Reply-To: <199902211037.CAA12487@implode.root.com> from "David Greenman" at Feb 21, 99 02:36:48 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 217 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The jumbo frames are only useful if you also have VLAN support, which we > don't have currently. We also need support for large mbuf clusters; this hmmm i don't get this -- why is this related to VLAN ? luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 6:29:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns1.seidata.com (ns1.seidata.com [208.10.211.2]) by hub.freebsd.org (Postfix) with ESMTP id D427A10E0B for ; Sun, 21 Feb 1999 06:29:09 -0800 (PST) (envelope-from mike@seidata.com) Received: from localhost (mike@localhost) by ns1.seidata.com (8.8.8/8.8.5) with ESMTP id JAA06755; Sun, 21 Feb 1999 09:29:09 -0500 (EST) Date: Sun, 21 Feb 1999 09:29:09 -0500 (EST) From: To: David Greenman Cc: Greg Skafte , freebsd-hackers@FreeBSD.ORG Subject: Re: intel ether express pro 100's In-Reply-To: <199902211012.CAA12398@implode.root.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, 21 Feb 1999, David Greenman wrote: > I've not heard of the 82559 until just now...I have no idea what it is. I was talking to an Intel guy the other day... hmm... was it the 82559 that was a sort of NIC management interface for VLAN stuff... Intel's also providing Linux drivers for these new 'smart' NICs with OpenSource licensing. The guy I spoke to said FreeBSD drivers aren't officially planned, but he said it'd be easy to port (he used to work for a FreeBSD-based ISP and is familiar with the OS). Isn't technology amazing... ;) -- Mike Hoskins Systems/Network Administrator SEI Data Network Services, Inc. http://www.seidata.com "In a world where an admin is rendered useless when the ball in his mouse has been taken out, its good to know that I know UNIX." -- toaster.sun4c.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 9:16:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.scl.ameslab.gov (mailhub.scl.ameslab.gov [147.155.137.127]) by hub.freebsd.org (Postfix) with ESMTP id B945D10E01 for ; Sun, 21 Feb 1999 09:16:53 -0800 (PST) (envelope-from ghelmer@scl.ameslab.gov) Received: from demios.ether.scl.ameslab.gov ([147.155.137.54]) by mailhub.scl.ameslab.gov with esmtp (Exim 1.90 #1) id 10EcVB-0000J4-00; Sun, 21 Feb 1999 11:17:09 -0600 Date: Sun, 21 Feb 1999 11:16:34 -0600 From: Guy Helmer To: David Greenman Cc: Luigi Rizzo , wpaul@skynet.ctr.columbia.edu, hackers@FreeBSD.ORG Subject: Re: How to handle jumbo etherney frames In-Reply-To: <199902211235.EAA12927@implode.root.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, 21 Feb 1999, David Greenman wrote: > >> The jumbo frames are only useful if you also have VLAN support, which we > >> don't have currently. We also need support for large mbuf clusters; this > > > >hmmm i don't get this -- why is this related to VLAN ? > > Because most ethernets consist of a mix of hosts that don't have jumbo > frame capability. If you use jumbo frames without VLANs, then ALL hosts must > support jumbo frames (and I think would also have to be gigabit ethernet > connected since jumbo frames weren't supported in 802.3...although I'm > assuming that the gigabit spec allows for jumbo frames, which may be a > bad assumption on my part). AFAIK, Alteon is the only source right now for a Gigabit Ethernet switch that can handle jumbo frames (we have one on-site right now), and it will automatically fragment packets when a jumbo frame is forwarded to a link that uses normal frames. Seems like VLANs will not be necessary, as long as other switch manufactures provide this feature. (I'm not sure what the performance hit due to fragmentation would be, though.) BTW, we've found that jumbo frames make a significant difference in performance on the new RS/6000's we have -- peak TCP performance jumps from the 500Mbps range to the 800Mpbs range for 1500 vs. 9000 byte MTU. We assume that the Gigabit NICs in the RS/6000's are Alteon NICs, but there is no identification on the NICs other than IBM's. Guy Helmer, Ph.D. Candidate, Iowa State University Dept. of Computer Science Research Assistant, Ames Laboratory --- ghelmer@scl.ameslab.gov Research Assistant, Dept. of Computer Science --- ghelmer@cs.iastate.edu http://www.cs.iastate.edu/~ghelmer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 9:17:31 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 BF31F114C3 for ; Sun, 21 Feb 1999 09:17:28 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id JAA02713; Sun, 21 Feb 1999 09:17:12 -0800 Date: Sun, 21 Feb 1999 09:17:12 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Doug Rabson Cc: freebsd-hackers@freebsd.org Subject: Re: Panic in FFS/4.0 as of yesterday - update 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 to say that during testing last night (in the middle of which a buildworld got started) the system paniced again with a 'panic: getnewbuf infinite recursion failure'. I've left it in the debugger if anyone could suggest looking at something. I'm going to New Orleans tomorrow so it can sit in the debugger until Friday... A very cursory look at the code makes me wonder 'why the value of 5 for a limit'? It doesn't seem to me a panic is a good solution. On Sat, 20 Feb 1999, Doug Rabson wrote: > On Sat, 20 Feb 1999, Matthew Jacob wrote: > > > > > As of the last set of fixes that added some more splbio protection, the > > testing has gone a lot better. Many thanks. Now I'll start raising the bar > > from 9GB filesystems to > 100GB filesystems with larger blocksizes (unless > > someone says "No! No! Don't do that!") > > Its good that your panic seems to have been addressed but I can't see any > quick solutions for the responsiveness problem. It appears to be a > combination of the way that BSD looks up pathnames and the lack of any > mechanism from stopping writer processes from monopolising the i/o queues. > > -- > 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 Sun Feb 21 9:21:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (Postfix) with ESMTP id 67351111D2 for ; Sun, 21 Feb 1999 09:21: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.8.8/8.8.8) with SMTP id MAA06921; Sun, 21 Feb 1999 12:21:02 -0500 (EST) Date: Sun, 21 Feb 1999 12:21:02 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Chad David Cc: freebsd-hackers@freebsd.org Subject: Re: coda and tunX 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, 18 Feb 1999, Chad David wrote: > A while back I wrote a simple IP over UDP tunnel program > using the tunX driver to solve a problem with my ISP. It > has worked perfectly for months (we even run NFS over it). I did this also at one point, but switched to looking at nos-tun now in 3.0 and 4.0. It has the advantage of not being home-rolled; I never implemented some of MTU handling code described in the relevant RFCs. Although, to be honest, I haven't checked if nos-tun does either :-). > In the last week I installed coda 5.0.1 and got it working > locally, but when I attempted to install the client on a > remote machine venus would just time out. I am able to > connect to the test server at CMU, but it refuses to use > the tunnel interface. > > I work on the remote machine by sshing onto the machine over > the tunnel, so I know it is working (NFS is mounted over it > as I write this), but coda refuses to talk? > > Does anybody have any idea what is going on? May need a little more information. What kind of errors are you seeing from Coda (take a look at /usr/coda/etc/console, as well as venus.log in the cache directory). Coda does not like multiple interfaces very much for a variety of reasons; if it's a machine using tunneling, that might be related. What version of FreeBSD are you running, et al? You may want to send questions to codadiscuss@coda.cs.cmu.edu as that is usually more carefully followed by the coda folk,. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 9:24:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from shell.monmouth.com (bg-tc-ppp283.monmouth.com [209.191.61.30]) by hub.freebsd.org (Postfix) with ESMTP id BD17011481 for ; Sun, 21 Feb 1999 09:24:17 -0800 (PST) (envelope-from pechter@shell.monmouth.com) Received: (from pechter@localhost) by shell.monmouth.com (8.9.2/8.9.1) id MAA37204; Sun, 21 Feb 1999 12:24:07 -0500 (EST) (envelope-from pechter) From: Bill Pechter Message-Id: <199902211724.MAA37204@shell.monmouth.com> Subject: Net/2 license and CD In-Reply-To: from freebsd-hackers-digest at "Feb 20, 1999 4:11:29 pm" To: hackers@FreeBSD.ORG Date: Sun, 21 Feb 1999 12:23:24 -0500 (EST) Cc: tlambert@primenet.com Reply-To: bpechter@shell.monmouth.com X-Phone-Number: 908-389-3592 X-OS-Type: FreeBSD 3.0-Stable 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 Actually, you can get Net/2, but it requires a license from SCO which is $100 for non-commercial hobbiest use only (or the Western Electric AT&T license for V7/32V/SysIII/SysV). I believe Kirk is selling a Lite set, but that the PUPS folks are making Net/2 available if you have the correct Western Electric or SCO source license. The PUPS folks have an available archive with the sources for a lot of early UNIX (TM) 8-) varieties... V5, V6, V7, 32V (I think) and the BSD's... Check the PUPS archive for more information on the licenses. http://minnie.cs.adfa.oz.au/PUPS/ PDP Unix Presevation Society home page. Bill > Date: Sat, 20 Feb 1999 22:05:38 +0000 (GMT) > From: Terry Lambert > Subject: Re: Searching an "old" BSD stdio > > > Doesn't Kirk McKusick sell a complete BSD sources set on CDROM? I'd > > check the web page, but it appears to be inaccessible to me at the > > moment. I seem to recall that he required you obtain some kind of a > > license from SCO first, though... > > The settlement agreement between UCB and USL, the terms of which > are not permitted to be disclosed, made the Net and Net/2 > distribution supposedly "illegal". Since you can't revoke a > license granted in perpetuity (which is why Apple still has a > valid license for the UCSD P system that they used to implement > the original "QuickDraw"), DEC has declined to remove it from > their gatekeeper.dec.com archive, as have hundreds of other > licensees (even some institutions with more money than Bill Gates). > > Net was BSD 4.2, and Net/2 was BSD 4.3. > > I believe Kirk sells the 4.4-Lite2 CDROMs. If he sells others, it's > only with proof of a Western Electric or later UNIX source license, > to keep himself out of hot water. > > The specific requirement of the original poster was a BSD 4.2 > stdio that could be linked against, presumably because of either > promisucous reference to the implementation details of stdio, which > have subsequently changed, or because a preexisting object file > for which source is not available. > > If it's an object file, I'm pretty sure that they're screwed, > unless they can contact the vendor of the box for the code; the > stdio subsystem is one that every company thought they could > "make better". > > If it's source, it'll probably have to be rewritten. > > > Terry Lambert > terry@lambert.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 9:31:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 2553B114B0 for ; Sun, 21 Feb 1999 09:31:24 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id JAA06492; Sun, 21 Feb 1999 09:31:14 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.2/8.9.1) id JAA19087; Sun, 21 Feb 1999 09:31:14 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [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: <199902210820.BAA00506@harmony.village.org> Date: Sun, 21 Feb 1999 09:31:14 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Warner Losh Subject: Re: FreeBSD mention in LWN interview with A.C. Cc: hackers@FreeBSD.ORG, Jamie Bowden Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > cvsup is faster than perforce, from what I can tell, but perforce is > faster at remote operations, generally, the cvs. No argument about that from me. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 9:44: 6 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 2BF7511C4F for ; Sun, 21 Feb 1999 09:44:00 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id RAA56064; Sun, 21 Feb 1999 17:43:48 GMT (envelope-from dfr@nlsystems.com) Date: Sun, 21 Feb 1999 17:43:48 +0000 (GMT) From: Doug Rabson To: Matthew Jacob Cc: freebsd-hackers@freebsd.org Subject: Re: Panic in FFS/4.0 as of yesterday - update 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, 21 Feb 1999, Matthew Jacob wrote: > > Sorry to say that during testing last night (in the middle of which a > buildworld got started) the system paniced again with a 'panic: getnewbuf > infinite recursion failure'. I've left it in the debugger if anyone could > suggest looking at something. I'm going to New Orleans tomorrow so it can > sit in the debugger until Friday... > > A very cursory look at the code makes me wonder 'why the value of 5 for a > limit'? It doesn't seem to me a panic is a good solution. Apart from the use of 5 as a 'magic' number, this code doesn't cope with being reentered by another process - the recursion test needs to be on a per-process basis. I'm sure that if you check the stack trace, you won't see any kind of recursion happening. I would suggest disabling it entirely to see if the system survives any better. If that helps, perhaps it should be using a field in struct proc to record the recursion depth. -- 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 Sun Feb 21 10:13:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 44E5911ABD for ; Sun, 21 Feb 1999 10:13:13 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id TAA18063; Sun, 21 Feb 1999 19:13:04 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id BB8A31516; Sun, 21 Feb 1999 12:41:03 +0100 (CET) Date: Sun, 21 Feb 1999 12:41:03 +0100 From: Ollivier Robert To: hackers@FreeBSD.ORG Cc: Bill Paul Subject: Re: How to handle jumbo etherney frames Message-ID: <19990221124103.A18787@keltia.freenix.fr> Mail-Followup-To: hackers@FreeBSD.ORG, Bill Paul References: <199902210458.XAA12913@skynet.ctr.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.3i In-Reply-To: <199902210458.XAA12913@skynet.ctr.columbia.edu>; from Bill Paul on Sat, Feb 20, 1999 at 11:58:02PM -0500 X-Operating-System: FreeBSD 3.0-CURRENT/ELF ctm#5026 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Bill Paul: > the packet into 2K chunks. I think this involves one MGETHDR(), > four MGET()s and five MCLGETS(). It would be nice to find a > quick and dirty way to allocate the chain, but I don't see one > offhand. Did you looked at the FDDI driver we have in the tree ? The MTU for FDDI is around 4.5 KB I think so you my find some ideas here. /sys/net/if_fddisubr.c -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #69: Mon Jan 18 02:02:12 CET 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 10:17:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (Postfix) with SMTP id CAAAC11AC9 for ; Sun, 21 Feb 1999 10:17:12 -0800 (PST) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id NAA13983; Sun, 21 Feb 1999 13:24:01 -0500 From: Bill Paul Message-Id: <199902211824.NAA13983@skynet.ctr.columbia.edu> Subject: Re: How to handle jumbo etherney frames To: bright@cygnus.rush.net (Alfred Perlstein) Date: Sun, 21 Feb 1999 13:24:00 -0500 (EST) Cc: hackers@freebsd.org In-Reply-To: from "Alfred Perlstein" at Feb 21, 99 06:30:44 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2338 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Of all the gin joints in all the towns in all the world, Alfred Perlstein had to walk into mine and say: > > > The use of jumbo frames is optional, but I'd like to support them. > > The question is, what's the best mbuf allocation strategy for receiving > > frames this size? The scheme I normally use is to allocate a single mbuf > > with MGETHDR and then attach an mbuf cluster to that with MCLGET. > > An mbuf cluster buffer is 2K, which is enough to hold a complete > > ethernet frame up to the maximum frame size (1514). The address > > of the cluster buffer is passed to the ethernet controller, so that > > it can DMA received packets directly into the mbuf which can then > > be passed directly to ether_input() without any buffer copying. > > (And avoiding buffer copying at gigabit speeds is highly desireable.) > > please excuse genrally cluelessness here, but why not have some sort of > flag to tell the driver how much space to pre-allocate? when done at > boot time, i thought that contiqalloc is ok to use. having a seperate > memory allocator is bad form, but for maximal performance it may be > nessesary. Because I want to avoid buffer copying. If I allocate a bunch of buffers for jumbo frames at boot time, then I can't hand them off to the upper protocol layers because then they'll get freed back to the OS and I'll eventually run out. I could just keep the 9K buffers to myself and use m_devget() to transfer the packet data from the contiguous buffer to an mbuf chain when a frame arrives, but that means copying. > I know DG is proposing using smaller buffers, but if you can can preallocate > and the performance tradeoff is worth the nasty code, woudn't it be worth > it in the long run? At 100Mbps on a really fast CPU, maybe. At 1000Mbps? I doubt it. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 10:23:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by hub.freebsd.org (Postfix) with ESMTP id 8590F115D9 for ; Sun, 21 Feb 1999 10:23:41 -0800 (PST) (envelope-from lyndon@execmail.ca) Received: from ht46l.orthanc.ab.ca (thingfish.v-wave.com [24.108.17.129]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id CAA01476; Mon, 22 Feb 1999 02:32:01 -0700 From: Lyndon Nerenberg Date: Sun, 21 Feb 1999 18:24:44 +0000 To: Robert Watson Subject: nos-tun using IP protocol 94 (was: coda and tunX) Cc: Chad David , freebsd-hackers@FreeBSD.ORG In-Reply-To: References: Message-ID: X-Mailer: Execmail for Win32 Version 5.0 pc5 Build (35) MIME-Version: 1.0 Content-Type: Multipart/signed; boundary="Part9902211824.B"; protocol="application/pgp-signature"; micalg="pgp-sha1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --Part9902211824.B Content-Type: Text/Plain; charset="us-ascii"; name="ipm.txt" Content-Disposition: inline; filename="ipm.txt" > I did this also at one point, but switched to looking at nos-tun now in > 3.0 and 4.0. It has the advantage of not being home-rolled I was looking at this the other week, and noticed it uses the old protocol 94 encapsulation, instead of protocol 4. We dropped the "94" tunnels on ampr-net years ago. nos-tun should probably be changed to use the standard encapsulation protocol number. --lyndon --Part9902211824.B Content-Type: Application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.5.2 (C) 1997-1998 Network Associates, Inc. and its affiliated companies. iQA/AwUBNtBPbxvgRSChfsw2EQLFjQCg9WM9D4h2YWd8C9Scw8mCcbTq2icAoOx+ L6MsS1meITNimjI/wse4gj/0 =m3R1 -----END PGP SIGNATURE----- --Part9902211824.B-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 10:58:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (Postfix) with SMTP id B07EA111D2 for ; Sun, 21 Feb 1999 10:58:18 -0800 (PST) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id OAA14038; Sun, 21 Feb 1999 14:03:31 -0500 From: Bill Paul Message-Id: <199902211903.OAA14038@skynet.ctr.columbia.edu> Subject: Re: How to handle jumbo etherney frames To: ghelmer@scl.ameslab.gov (Guy Helmer) Date: Sun, 21 Feb 1999 14:03:30 -0500 (EST) Cc: dg@root.com, luigi@labinfo.iet.unipi.it, hackers@freebsd.org In-Reply-To: from "Guy Helmer" at Feb 21, 99 11:16:34 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 6741 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Of all the gin joints in all the towns in all the world, Guy Helmer had to walk into mine and say: > > On Sun, 21 Feb 1999, David Greenman wrote: > > >> The jumbo frames are only useful if you also have VLAN support, which we > > >> don't have currently. We also need support for large mbuf clusters; this > > > > > >hmmm i don't get this -- why is this related to VLAN ? > > > > Because most ethernets consist of a mix of hosts that don't have jumbo > > frame capability. If you use jumbo frames without VLANs, then ALL hosts must > > support jumbo frames (and I think would also have to be gigabit ethernet > > connected since jumbo frames weren't supported in 802.3...although I'm > > assuming that the gigabit spec allows for jumbo frames, which may be a > > bad assumption on my part). Programming the chip to use a single vlan tag wouldn't require that much work. I was contemplating whipping up a small control program that could grovel around in /dev/kmem and grab ahold of the driver's softc struct and set the tag value, then re-init the interface. (And don't tell me how this is hard and messy and I should be using sysctl instead, because I've already written a program that does almost exactly this for a different driver as an experiment. So there.) > AFAIK, Alteon is the only source right now for a Gigabit Ethernet switch > that can handle jumbo frames (we have one on-site right now), and it will > automatically fragment packets when a jumbo frame is forwarded to a link > that uses normal frames. Seems like VLANs will not be necessary, as long > as other switch manufactures provide this feature. (I'm not sure what the > performance hit due to fragmentation would be, though.) It seems to me this would only work for IP (or some other protocol(s) that the switch knows about), since merely splitting up an ethernet frame into chunks doesn't do a lot of good unless the host knows the frame has been split and can reassemble it before passing it to the protocols. I'm not really inclined to just implement only standard frame support and wait around for large mbuf cluster support to materialize since there's no telling how long that could take. I think I may be stuck between a rock and a hard place though since I found something in the manual which seems to suggest that the mbuf cluster chaining approach won't work. The Tigon supports several different receive rings: the standard ring, which holds buffers large enough to accomodate normal sized ethernet frames, the jumbo receive ring, which contains buffers large enough for jumbo frames, and the mini ring, which contains small buffers of a user-chosen size for very small non-jumbo ethernet frames. The mini ring is an optimization for handling small packets which would end up wasting a lot of space were they to be DMAed into standard ring buffers. (It's possible to perform this optimization in the driver by copying very small frames into small mbuf chains and recycling the cluster buffer, but using the mini ring avoids the need to copy). Note that the mini ring is only availanle on the Tigon 2. For the jumbo ring, you're allowed to use one of two kinds of ring descriptors. You can use either the normal ring descriptor type (the same as for the standard receive ring) or a special extended jumbo receive descriptor, which differs from the normaal descriptor in that it can point to four non-contiguous buffers while the normal type can only point to one. You can specify the kind of descriptor you want by setting a flag in the ring control block during initialization. This is important because the manual seems to claim that as far as the jumbo ring is concerned, if you use normal descriptors, each descriptor buffer will always contain one complete frame. In other words, each descriptor must point to a contiguous buffer large enough to hold a 9K frame. If you want to use several non-contiguous buffers, then you have to use the extended descriptor format, which only allows four buffers. Since an mbuf cluster is only 2K, this isn't enough. The only way I can think of to get around this problem is to use an mbuf with external storage consisting of a single 9K buffer. However, since 9K is larger than the page size, I can't be assured of always getting 9K of contiguous storage, so I need to engage in a little subterfuge. What I'm thinking of doing is this: - Program the chip to use extended jumbo ring descriptors. - Get an mbuf using MGETHDR(). - malloc() a 9K buffer and attach it to the mbuf as external storage. - Assign the start address of the 9K buffer to the first host address pointer in the ring descriptor. - Round the address up to a page boundary. - Assign this page address to the second host address pointer in the descriptor. - Round up to the next page again. - Assign that address to the third host address pointer. - Set all the fragment lengths accordingly so we end up with a total of 9K. Basically I'm doing page mapping for the chip. It's possible that I might end up with contiguously allocated space in which case all of this is a pessimization, but I can never know that without grovelling around in the kernel page tables, and that would take a lot more work. Am I insane? Well, wait: that's a given. But does this scheme at least sound reasonable? > BTW, we've found that jumbo frames make a significant difference in > performance on the new RS/6000's we have -- peak TCP performance jumps > from the 500Mbps range to the 800Mpbs range for 1500 vs. 9000 byte MTU. > We assume that the Gigabit NICs in the RS/6000's are Alteon NICs, but > there is no identification on the NICs other than IBM's. One trick I sometimes use to identify NICs is to do strings -a on the driver object modules and look for something incriminating. If something like 'tigon' or 'acenic' or 'alt(eon)' leaps out at you, then you know it's a Tigon chip. Given that the Tigon is a PCI chip, IBM's card must also be PCI. If IBM really is using the Tigon chip, then you could probably use the IBM card in an x86 box given the right driver (IBM probably uses their own PCI vendor and device IDs for their card, but that's easy enough to handle). -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 11:11:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from heathers.stdio.com (heathers.stdio.com [199.89.192.5]) by hub.freebsd.org (Postfix) with ESMTP id 749A810E01 for ; Sun, 21 Feb 1999 11:11:29 -0800 (PST) (envelope-from lile@stdio.com) Received: from heathers.stdio.com (lile@heathers.stdio.com [199.89.192.5]) by heathers.stdio.com (8.8.8/8.8.8) with ESMTP id NAA10773; Sun, 21 Feb 1999 13:56:35 -0500 (EST) (envelope-from lile@stdio.com) Date: Sun, 21 Feb 1999 13:56:35 -0500 (EST) From: Larry Lile To: Bill Paul Cc: Guy Helmer , dg@root.com, luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG Subject: Re: How to handle jumbo etherney frames In-Reply-To: <199902211903.OAA14038@skynet.ctr.columbia.edu> 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 would also like to see the mbuf cluster size increased. I have to glue them together for token-ring support. With mtu's up to 18K I could probably starve a system of mbuf's pretty quickly. Although currently the rest of the network stack seems to deal with the big mtu's without a whimper, good job guys! Larry Lile lile@stdio.com On Sun, 21 Feb 1999, Bill Paul wrote: > Of all the gin joints in all the towns in all the world, Guy Helmer had > to walk into mine and say: > > > On Sun, 21 Feb 1999, David Greenman wrote: > > > > >> The jumbo frames are only useful if you also have VLAN support, which we > > > >> don't have currently. We also need support for large mbuf clusters; this > > > > > > > >hmmm i don't get this -- why is this related to VLAN ? > > > > > > Because most ethernets consist of a mix of hosts that don't have jumbo > > > frame capability. If you use jumbo frames without VLANs, then ALL hosts must > > > support jumbo frames (and I think would also have to be gigabit ethernet > > > connected since jumbo frames weren't supported in 802.3...although I'm > > > assuming that the gigabit spec allows for jumbo frames, which may be a > > > bad assumption on my part). > > Programming the chip to use a single vlan tag wouldn't require that much > work. I was contemplating whipping up a small control program that could > grovel around in /dev/kmem and grab ahold of the driver's softc struct > and set the tag value, then re-init the interface. (And don't tell me how > this is hard and messy and I should be using sysctl instead, because I've > already written a program that does almost exactly this for a different > driver as an experiment. So there.) > > > AFAIK, Alteon is the only source right now for a Gigabit Ethernet switch > > that can handle jumbo frames (we have one on-site right now), and it will > > automatically fragment packets when a jumbo frame is forwarded to a link > > that uses normal frames. Seems like VLANs will not be necessary, as long > > as other switch manufactures provide this feature. (I'm not sure what the > > performance hit due to fragmentation would be, though.) > > It seems to me this would only work for IP (or some other protocol(s) > that the switch knows about), since merely splitting up an ethernet > frame into chunks doesn't do a lot of good unless the host knows > the frame has been split and can reassemble it before passing it to > the protocols. > > I'm not really inclined to just implement only standard frame support > and wait around for large mbuf cluster support to materialize since there's > no telling how long that could take. I think I may be stuck between a > rock and a hard place though since I found something in the manual which > seems to suggest that the mbuf cluster chaining approach won't work. > > The Tigon supports several different receive rings: the standard ring, > which holds buffers large enough to accomodate normal sized ethernet > frames, the jumbo receive ring, which contains buffers large enough for > jumbo frames, and the mini ring, which contains small buffers of a > user-chosen size for very small non-jumbo ethernet frames. The mini > ring is an optimization for handling small packets which would end > up wasting a lot of space were they to be DMAed into standard ring > buffers. (It's possible to perform this optimization in the driver by > copying very small frames into small mbuf chains and recycling the cluster > buffer, but using the mini ring avoids the need to copy). > > Note that the mini ring is only availanle on the Tigon 2. > > For the jumbo ring, you're allowed to use one of two kinds of ring > descriptors. You can use either the normal ring descriptor type (the > same as for the standard receive ring) or a special extended jumbo > receive descriptor, which differs from the normaal descriptor in that > it can point to four non-contiguous buffers while the normal type can > only point to one. You can specify the kind of descriptor you want > by setting a flag in the ring control block during initialization. > > This is important because the manual seems to claim that as far as the > jumbo ring is concerned, if you use normal descriptors, each descriptor > buffer will always contain one complete frame. In other words, each > descriptor must point to a contiguous buffer large enough to hold a > 9K frame. If you want to use several non-contiguous buffers, then you > have to use the extended descriptor format, which only allows four buffers. > Since an mbuf cluster is only 2K, this isn't enough. > > The only way I can think of to get around this problem is to use an > mbuf with external storage consisting of a single 9K buffer. However, > since 9K is larger than the page size, I can't be assured of always > getting 9K of contiguous storage, so I need to engage in a little > subterfuge. > > What I'm thinking of doing is this: > > - Program the chip to use extended jumbo ring descriptors. > - Get an mbuf using MGETHDR(). > - malloc() a 9K buffer and attach it to the mbuf as external storage. > - Assign the start address of the 9K buffer to the first host address > pointer in the ring descriptor. > - Round the address up to a page boundary. > - Assign this page address to the second host address pointer in the > descriptor. > - Round up to the next page again. > - Assign that address to the third host address pointer. > - Set all the fragment lengths accordingly so we end up with a total > of 9K. > > Basically I'm doing page mapping for the chip. It's possible that I > might end up with contiguously allocated space in which case all of this > is a pessimization, but I can never know that without grovelling around > in the kernel page tables, and that would take a lot more work. > > Am I insane? Well, wait: that's a given. But does this scheme at > least sound reasonable? > > > BTW, we've found that jumbo frames make a significant difference in > > performance on the new RS/6000's we have -- peak TCP performance jumps > > from the 500Mbps range to the 800Mpbs range for 1500 vs. 9000 byte MTU. > > We assume that the Gigabit NICs in the RS/6000's are Alteon NICs, but > > there is no identification on the NICs other than IBM's. > > One trick I sometimes use to identify NICs is to do strings -a on the > driver object modules and look for something incriminating. If something > like 'tigon' or 'acenic' or 'alt(eon)' leaps out at you, then you know > it's a Tigon chip. > > Given that the Tigon is a PCI chip, IBM's card must also be PCI. > If IBM really is using the Tigon chip, then you could probably use the > IBM card in an x86 box given the right driver (IBM probably uses their > own PCI vendor and device IDs for their card, but that's easy enough to > handle). > > -Bill > > -- > ============================================================================= > -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu > Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research > Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City > ============================================================================= > "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" > ============================================================================= > > > 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 Feb 21 13:30:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by hub.freebsd.org (Postfix) with ESMTP id C270610FA4 for ; Sun, 21 Feb 1999 13:30:01 -0800 (PST) (envelope-from mark.hannon@stockholm.mail.telia.com) Received: from d1o1.telia.com (root@d1o1.telia.com [195.67.240.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id WAA05740 for ; Sun, 21 Feb 1999 22:30:00 +0100 (CET) Received: from doorway.home.lan (t6o1p16.telia.com [195.67.241.76]) by d1o1.telia.com (8.8.8/8.8.5) with ESMTP id WAA25402 for ; Sun, 21 Feb 1999 22:29:58 +0100 (CET) Received: from stockholm.mail.telia.com (putte.home.lan [192.168.255.2]) by doorway.home.lan (8.9.2/8.8.7) with ESMTP id WAA23173; Sun, 21 Feb 1999 22:29:22 +0100 (CET) (envelope-from mark.hannon@stockholm.mail.telia.com) Message-ID: <36D07AB1.E75044A6@stockholm.mail.telia.com> Date: Sun, 21 Feb 1999 22:29:21 +0100 From: Mark Hannon X-Mailer: Mozilla 4.07 [en] (X11; I; FreeBSD 3.1-RELEASE i386) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Announce: Ndump (a dump that traverse by name not inode) 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 have just uploaded a modified dump utility that has a -N option to traverse the filesystem in a logical manner by file/directory name (instead of by a straight inode list) when building its list of files to dump. This allows one to set nodump at the top of a directory tree and exclude it from the dump (instead of having to set nodump for every file). See it at http://w1.874.telia.com/~u87405149/ftape.html Cheers, Mark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 13:31:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from waldorf.cs.uni-dortmund.de (waldorf.cs.uni-dortmund.de [129.217.4.42]) by hub.freebsd.org (Postfix) with ESMTP id BBC6611B7C for ; Sun, 21 Feb 1999 13:31:05 -0800 (PST) (envelope-from grossjoh@ramses.informatik.uni-dortmund.de) Received: from ramses.informatik.uni-dortmund.de (ramses.cs.uni-dortmund.de [129.217.20.180]) by waldorf.cs.uni-dortmund.de with SMTP id WAA05338 for ; Sun, 21 Feb 1999 22:31:03 +0100 (MET) Received: (grossjoh@localhost) by ramses.informatik.uni-dortmund.de id WAA03199; Sun, 21 Feb 1999 22:31:02 +0100 To: freebsd-hackers@freebsd.org Subject: organization of own extensions to programs installed as ports? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Kai.Grossjohann@CS.Uni-Dortmund.DE Date: 21 Feb 1999 22:31:02 +0100 Message-ID: Lines: 23 User-Agent: Gnus/5.070077 (Pterodactyl Gnus v0.77) Emacs/20.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I like the ports mechanism a lot, but it appears I don't really grok it just yet. Maybe you can give me a hand, please? A number of programs support user extensions. Emacs, for instance, has a site-lisp directory where one can put Emacs Lisp programs. Perl has a site_perl directory where one can install additional Perl modules. Now, some ports install stuff in these directories. For instance, ispell installs its ispell.el into the Emacs site-lisp directory. Suppose I wanted to install additional extensions, not provided as ports. If I install those in the directories mentioned above, chaos will quickly result: I can't tell the difference between files anymore which come from a port and which I installed myself. Besides, a port might overwrite one of the files I installed myself, or vice versa. What is the customary way to deal with this situation? tia, kai -- I like _b_o_t_h kinds of music. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 13:53:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pacman.redwoodsoft.com (redwoodsoft.com [207.181.199.182]) by hub.freebsd.org (Postfix) with SMTP id C11EB1165E for ; Sun, 21 Feb 1999 13:53:28 -0800 (PST) (envelope-from dnelson@pacman.redwoodsoft.com) Received: (qmail 2513 invoked by uid 1000); 21 Feb 1999 21:53:25 -0000 Date: Sun, 21 Feb 1999 13:53:25 -0800 (PST) From: Dru Nelson To: freebsd-hackers@freebsd.org Subject: Re: YP-like mySQL thing 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 option, Luke Howard has worked on standardizing LDAP as a replacement for YP/Netinfo/NIS+/etc. I saw part of his talk, and it looks like it might go somewhere. There is an RFC for the Schema, I believe. Dru Nelson Redwood City, California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 14:41:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from trinity.radio-do.de (trinity.Radio-do.de [193.101.164.3]) by hub.freebsd.org (Postfix) with ESMTP id E682910E36 for ; Sun, 21 Feb 1999 14:41:19 -0800 (PST) (envelope-from fn@trinity.radio-do.de) Received: (from fn@localhost) by trinity.radio-do.de (8.9.2/8.9.1) id XAA54423; Sun, 21 Feb 1999 23:41:18 +0100 (CET) (envelope-from fn) To: freebsd-hackers@FreeBSD.ORG Subject: Re: ISA DMA problems if >= 512 Mb RAM? References: <199902122303.AAA05641@dorifer.heim3.tu-clausthal.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Frank Nobis Date: 21 Feb 1999 23:41:17 +0100 In-Reply-To: Oliver Fromme's message of "Sat, 13 Feb 1999 00:03:11 +0100 (CET)" Message-ID: Lines: 55 User-Agent: Gnus/5.070075 (Pterodactyl Gnus v0.75) XEmacs/20.4 (Emerald) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Oliver" == Oliver Fromme writes: Oliver> Hi, I submitted a PR regarding this last month, but it Oliver> seems like that was rather inappropriate (and obviously it Oliver> didn't get any attention). Admittedly, I'm not that much Oliver> of a VM expert, so maybe the information that I provide is Oliver> insufficient. In that case please let me know what I can Oliver> do to help fixing this problem. Oliver> This is the situation: ASUS P2B-LS mainboard with 512 Mb Oliver> RAM, Soundblaster AWE64 PnP. (This is NOT a problem with Oliver> PnP or the sound drivers!). We're running 3.0-stable of Oliver> 1999-01-28. This is what happens (dmesg excerpt): I have a P2B-DS with 512 M Ram and AWE64 Until today I had the same problem. Today I build a new kernel and now the problem ist gone. FreeBSD 4.0-CURRENT #1: Sun Feb 21 21:30:37 CET 1999 root@trinity.radio-do.de:/usr/src/sys/compile/TRINITY Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (686-class CPU) Origin = "GenuineIntel" Id = 0x651 Stepping=1 Features=0x183fbff real memory = 536870912 (524288K bytes) config> pnp 1 0 os enable port0 0x220 port1 0x330 port2 0x388 irq0 5 drq0 1 drq 5 config> pnp 1 1 os disable config> pnp 1 2 os enable port0 0x620 port1 0xa20 port2 0xe20 avail memory = 519380992 (507208K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard . . . sb0 at 0x220 irq 5 drq 1 on isa snd0: sbxvi0 at drq 5 on isa snd0: sbmidi0 at 0x330 on isa snd0: awe0 at 0x620 on isa awe0: opl0 at 0x388 on isa snd0: If you would like I sent you my kernel config file. Frank -- Frank Nobis Email: PGP AVAILABLE Landgrafenstr. 130 dg3dcn http://www.radio-do.de/~fn/ 44139 Dortmund Powered by SMP FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 15: 2:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 1C27B10F4D for ; Sun, 21 Feb 1999 15:02:50 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.com (zaphod.softweyr.com [204.68.178.35]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id QAA09730; Sun, 21 Feb 1999 16:02:35 -0700 (MST) (envelope-from wes@softweyr.com) Message-ID: <36D0908B.D1F2B30A@softweyr.com> Date: Sun, 21 Feb 1999 16:02:35 -0700 From: Wes Peters Organization: Softweyr llc X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mike@seidata.com Cc: David Greenman , Greg Skafte , freebsd-hackers@FreeBSD.ORG Subject: Re: intel ether express pro 100's References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG mike@seidata.com wrote: > > On Sun, 21 Feb 1999, David Greenman wrote: > > > I've not heard of the 82559 until just now...I have no idea what it is. > > I was talking to an Intel guy the other day... hmm... was it the > 82559 that was a sort of NIC management interface for VLAN stuff... It's basically an 82558 with the "wake on lan" crap built in. You can find everything you wanted to know about it, or at least everything Intel wants you to know about it, by surfing on over to http://developer.intel.com/sites/developer/search.htm and searching for 82559. > Intel's also providing Linux drivers for these new 'smart' NICs with > OpenSource licensing. The guy I spoke to said FreeBSD drivers aren't > officially planned, but he said it'd be easy to port (he used to work > for a FreeBSD-based ISP and is familiar with the OS). They're not mentioned on the web page(s) yet. Some ftp-server spelunking might be in order. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@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 Feb 21 15: 5:42 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 9FFD310F4D for ; Sun, 21 Feb 1999 15:05:39 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id OAA20749; Sun, 21 Feb 1999 14:59:56 -0800 (PST) Received: from s204m82.isp.whistle.com(207.76.204.82) via SMTP by alpo.whistle.com, id smtpdD20747; Sun Feb 21 22:59:51 1999 Date: Sun, 21 Feb 1999 14:59:30 -0800 (PST) From: Julian Elischer X-Sender: julian@s204m82.isp.whistle.com To: David Greenman Cc: Luigi Rizzo , wpaul@skynet.ctr.columbia.edu, hackers@FreeBSD.ORG Subject: Re: How to handle jumbo etherney frames In-Reply-To: <199902211235.EAA12927@implode.root.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 no, we ised to use 15.5KB (k byte) frames on a project (I believe the ifdefs may still be in the if_de driver). We also had other machines on that net. At one time SUNS would crash but that problem went away. I presume that the jumbo packets are only sent between machines that support them.. On Sun, 21 Feb 1999, David Greenman wrote: > >> The jumbo frames are only useful if you also have VLAN support, which we > >> don't have currently. We also need support for large mbuf clusters; this > > > >hmmm i don't get this -- why is this related to VLAN ? > > Because most ethernets consist of a mix of hosts that don't have jumbo > frame capability. If you use jumbo frames without VLANs, then ALL hosts must > support jumbo frames (and I think would also have to be gigabit ethernet > connected since jumbo frames weren't supported in 802.3...although I'm > assuming that the gigabit spec allows for jumbo frames, which may be a > bad assumption on my part). > > -DG > > David Greenman > Co-founder/Principal Architect, The FreeBSD Project > > > 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 Feb 21 15:12:44 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 8302510F2F for ; Sun, 21 Feb 1999 15:12:37 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id PAA20890; Sun, 21 Feb 1999 15:08:38 -0800 (PST) Received: from s204m82.isp.whistle.com(207.76.204.82) via SMTP by alpo.whistle.com, id smtpdr20888; Sun Feb 21 23:08:28 1999 Date: Sun, 21 Feb 1999 15:08:08 -0800 (PST) From: Julian Elischer X-Sender: julian@s204m82.isp.whistle.com To: Bill Paul Cc: Guy Helmer , dg@root.com, luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG Subject: Re: How to handle jumbo etherney frames In-Reply-To: <199902211903.OAA14038@skynet.ctr.columbia.edu> 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, 21 Feb 1999, Bill Paul wrote: > Of all the gin joints in all the towns in all the world, Guy Helmer had > to walk into mine and say: > > > On Sun, 21 Feb 1999, David Greenman wrote: > > > > >> The jumbo frames are only useful if you also have VLAN support, which we > > > >> don't have currently. We also need support for large mbuf clusters; this > > > > > > > >hmmm i don't get this -- why is this related to VLAN ? > > > > > > Because most ethernets consist of a mix of hosts that don't have jumbo > > > frame capability. If you use jumbo frames without VLANs, then ALL hosts must > > > support jumbo frames (and I think would also have to be gigabit ethernet > > > connected since jumbo frames weren't supported in 802.3...although I'm > > > assuming that the gigabit spec allows for jumbo frames, which may be a > > > bad assumption on my part). > > Programming the chip to use a single vlan tag wouldn't require that much > work. I was contemplating whipping up a small control program that could > grovel around in /dev/kmem and grab ahold of the driver's softc struct > and set the tag value, then re-init the interface. (And don't tell me how > this is hard and messy and I should be using sysctl instead, because I've > already written a program that does almost exactly this for a different > driver as an experiment. So there.) > > > AFAIK, Alteon is the only source right now for a Gigabit Ethernet switch > > that can handle jumbo frames (we have one on-site right now), and it will > > automatically fragment packets when a jumbo frame is forwarded to a link > > that uses normal frames. Seems like VLANs will not be necessary, as long > > as other switch manufactures provide this feature. (I'm not sure what the > > performance hit due to fragmentation would be, though.) > > It seems to me this would only work for IP (or some other protocol(s) > that the switch knows about), since merely splitting up an ethernet > frame into chunks doesn't do a lot of good unless the host knows > the frame has been split and can reassemble it before passing it to > the protocols. > > I'm not really inclined to just implement only standard frame support > and wait around for large mbuf cluster support to materialize since there's > no telling how long that could take. I think I may be stuck between a > rock and a hard place though since I found something in the manual which > seems to suggest that the mbuf cluster chaining approach won't work. > > The Tigon supports several different receive rings: the standard ring, > which holds buffers large enough to accomodate normal sized ethernet > frames, the jumbo receive ring, which contains buffers large enough for > jumbo frames, and the mini ring, which contains small buffers of a > user-chosen size for very small non-jumbo ethernet frames. The mini > ring is an optimization for handling small packets which would end > up wasting a lot of space were they to be DMAed into standard ring > buffers. (It's possible to perform this optimization in the driver by > copying very small frames into small mbuf chains and recycling the cluster > buffer, but using the mini ring avoids the need to copy). > > Note that the mini ring is only availanle on the Tigon 2. > > For the jumbo ring, you're allowed to use one of two kinds of ring > descriptors. You can use either the normal ring descriptor type (the > same as for the standard receive ring) or a special extended jumbo > receive descriptor, which differs from the normaal descriptor in that > it can point to four non-contiguous buffers while the normal type can > only point to one. You can specify the kind of descriptor you want > by setting a flag in the ring control block during initialization. > > This is important because the manual seems to claim that as far as the > jumbo ring is concerned, if you use normal descriptors, each descriptor > buffer will always contain one complete frame. In other words, each > descriptor must point to a contiguous buffer large enough to hold a > 9K frame. If you want to use several non-contiguous buffers, then you > have to use the extended descriptor format, which only allows four buffers. > Since an mbuf cluster is only 2K, this isn't enough. > > The only way I can think of to get around this problem is to use an > mbuf with external storage consisting of a single 9K buffer. However, > since 9K is larger than the page size, I can't be assured of always > getting 9K of contiguous storage, so I need to engage in a little > subterfuge. This is what we used at TRW.. We had 16KB physical buffers reserved for use by the jumbo (in our case 15.5 KB) packets. This is why I fixed the external buffer code in mbuf.h and uipc_mbuf.c several years ago. All packets when there, but packets under a certain size (100 bytes I think) were copied out to normal mbufs. > > What I'm thinking of doing is this: > > - Program the chip to use extended jumbo ring descriptors. > - Get an mbuf using MGETHDR(). > - malloc() a 9K buffer and attach it to the mbuf as external storage. We kept a special pool of them and they were contiguous memory. > - Assign the start address of the 9K buffer to the first host address > pointer in the ring descriptor. > - Round the address up to a page boundary. > - Assign this page address to the second host address pointer in the > descriptor. > - Round up to the next page again. > - Assign that address to the third host address pointer. > - Set all the fragment lengths accordingly so we end up with a total > of 9K. might work. > > Basically I'm doing page mapping for the chip. It's possible that I > might end up with contiguously allocated space in which case all of this > is a pessimization, but I can never know that without grovelling around > in the kernel page tables, and that would take a lot more work. > > Am I insane? Well, wait: that's a given. But does this scheme at > least sound reasonable? sounds fine, but how much ram do you have? we just allocated 4MB to buffers contiguously and left it at that.. Mind you we weren't using fast etehrnet let alone gigiabit, but we were using 68020s on a VME bus, and then 386 on ISA. > > > BTW, we've found that jumbo frames make a significant difference in > > performance on the new RS/6000's we have -- peak TCP performance jumps > > from the 500Mbps range to the 800Mpbs range for 1500 vs. 9000 byte MTU. > > We assume that the Gigabit NICs in the RS/6000's are Alteon NICs, but > > there is no identification on the NICs other than IBM's. > > One trick I sometimes use to identify NICs is to do strings -a on the > driver object modules and look for something incriminating. If something > like 'tigon' or 'acenic' or 'alt(eon)' leaps out at you, then you know > it's a Tigon chip. > > Given that the Tigon is a PCI chip, IBM's card must also be PCI. > If IBM really is using the Tigon chip, then you could probably use the > IBM card in an x86 box given the right driver (IBM probably uses their > own PCI vendor and device IDs for their card, but that's easy enough to > handle). > > -Bill > > -- > ============================================================================= > -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu > Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research > Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City > ============================================================================= > "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" > ============================================================================= > > > 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 Feb 21 15:53:21 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 2DD4510F1F for ; Sun, 21 Feb 1999 15:53:18 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id SAA12884; Sun, 21 Feb 1999 18:53:14 -0500 (EST) (envelope-from luoqi) Date: Sun, 21 Feb 1999 18:53:14 -0500 (EST) From: Luoqi Chen Message-Id: <199902212353.SAA12884@lor.watermarkgroup.com> To: dfr@nlsystems.com, mjacob@feral.com Subject: Re: Panic in FFS/4.0 as of yesterday - update Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sun, 21 Feb 1999, Matthew Jacob wrote: > > > > > Sorry to say that during testing last night (in the middle of which a > > buildworld got started) the system paniced again with a 'panic: getnewbuf > > infinite recursion failure'. I've left it in the debugger if anyone could > > suggest looking at something. I'm going to New Orleans tomorrow so it can > > sit in the debugger until Friday... > > > > A very cursory look at the code makes me wonder 'why the value of 5 for a > > limit'? It doesn't seem to me a panic is a good solution. > > Apart from the use of 5 as a 'magic' number, this code doesn't cope with > being reentered by another process - the recursion test needs to be on a > per-process basis. I'm sure that if you check the stack trace, you won't > see any kind of recursion happening. > What troubled me here is why these supposedly async writes block (and ccd is not involved)? I'd really like to see a dump of ps listing from ddb. -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 16:12:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 027F311886 for ; Sun, 21 Feb 1999 16:12:15 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.com (zaphod.softweyr.com [204.68.178.35]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id RAA09841; Sun, 21 Feb 1999 17:11:43 -0700 (MST) (envelope-from wes@softweyr.com) Message-ID: <36D0A0BE.3A725943@softweyr.com> Date: Sun, 21 Feb 1999 17:11:42 -0700 From: Wes Peters Organization: Softweyr llc X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: dg@root.com Cc: Luigi Rizzo , wpaul@skynet.ctr.columbia.edu, hackers@FreeBSD.ORG Subject: Re: How to handle jumbo etherney frames References: <199902211235.EAA12927@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: > > >> The jumbo frames are only useful if you also have VLAN support, which we > >> don't have currently. We also need support for large mbuf clusters; this > > > >hmmm i don't get this -- why is this related to VLAN ? > > Because most ethernets consist of a mix of hosts that don't have jumbo > frame capability. If you use jumbo frames without VLANs, then ALL hosts must > support jumbo frames This requires switching (or routing) between the hosts that do and do not support jumbo frames, but probably doesn't require VLAN tagging. You need to have all hosts on a physical segment support jumbo frames in order to run jumbo frames on that segment. > (and I think would also have to be gigabit ethernet > connected since jumbo frames weren't supported in 802.3...although I'm > assuming that the gigabit spec allows for jumbo frames, which may be a > bad assumption on my part). I think the jumbo frame specification is being added to the spec, but haven't read it yet. I will be in the next few weeks, though. Ugh. Supporting jumbo frames is an upcoming project for me. I'm watching this thread with great interest, as having support for jumbos in FreeBSD would make testing much simpler for me. It would also be nice to know that my implementation works with at least one other existing one before throwing it over the wall to testing. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@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 Feb 21 17: 3:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [208.221.12.98]) by hub.freebsd.org (Postfix) with ESMTP id D2C6E11665 for ; Sun, 21 Feb 1999 17:03:41 -0800 (PST) (envelope-from root@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 RAA15362; Sun, 21 Feb 1999 17:00:59 -0800 (PST) Message-Id: <199902220100.RAA15362@implode.root.com> To: Wes Peters Cc: hackers@FreeBSD.ORG Subject: Re: How to handle jumbo etherney frames In-reply-to: Your message of "Sun, 21 Feb 1999 17:11:42 MST." <36D0A0BE.3A725943@softweyr.com> From: David Greenman Reply-To: dg@root.com Date: Sun, 21 Feb 1999 17:00:59 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >This requires switching (or routing) between the hosts that do and do not >support jumbo frames, but probably doesn't require VLAN tagging. You >need to have all hosts on a physical segment support jumbo frames in >order to run jumbo frames on that segment. Uh, no, that's why you use VLANs. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 17:13: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [208.221.12.98]) by hub.freebsd.org (Postfix) with ESMTP id 6B2B111A40 for ; Sun, 21 Feb 1999 17:13:03 -0800 (PST) (envelope-from root@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 RAA15394; Sun, 21 Feb 1999 17:10:15 -0800 (PST) Message-Id: <199902220110.RAA15394@implode.root.com> To: Bill Paul Cc: hackers@freebsd.org Subject: Re: How to handle jumbo etherney frames In-reply-to: Your message of "Sun, 21 Feb 1999 14:03:30 EST." <199902211903.OAA14038@skynet.ctr.columbia.edu> From: David Greenman Reply-To: dg@root.com Date: Sun, 21 Feb 1999 17:10:15 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Programming the chip to use a single vlan tag wouldn't require that much >work. Whether to use a VLAN and/or which VLAN to use is a per destination thing, not a per host/interface thing, so I don't think a single VLAN would be very useful. >I'm not really inclined to just implement only standard frame support >and wait around for large mbuf cluster support to materialize since there's >no telling how long that could take. I think I may be stuck between a Then implement large mbuf support. :-) >This is important because the manual seems to claim that as far as the >jumbo ring is concerned, if you use normal descriptors, each descriptor >buffer will always contain one complete frame. In other words, each >descriptor must point to a contiguous buffer large enough to hold a >9K frame. If you want to use several non-contiguous buffers, then you >have to use the extended descriptor format, which only allows four buffers. >Since an mbuf cluster is only 2K, this isn't enough. > >The only way I can think of to get around this problem is to use an >mbuf with external storage consisting of a single 9K buffer. However, >since 9K is larger than the page size, I can't be assured of always >getting 9K of contiguous storage, so I need to engage in a little >subterfuge. > >What I'm thinking of doing is this: > >- Program the chip to use extended jumbo ring descriptors. >- Get an mbuf using MGETHDR(). >- malloc() a 9K buffer and attach it to the mbuf as external storage. >- Assign the start address of the 9K buffer to the first host address > pointer in the ring descriptor. >- Round the address up to a page boundary. >- Assign this page address to the second host address pointer in the > descriptor. >- Round up to the next page again. >- Assign that address to the third host address pointer. >- Set all the fragment lengths accordingly so we end up with a total > of 9K. > >Basically I'm doing page mapping for the chip. It's possible that I >might end up with contiguously allocated space in which case all of this >is a pessimization, but I can never know that without grovelling around >in the kernel page tables, and that would take a lot more work. > >Am I insane? Well, wait: that's a given. But does this scheme at >least sound reasonable? Using malloc for this is probably not a good idea since it wants to allocate power of two sizes, so you'd needlessly waste a whole page. This really needs a special allocator specifically designed to deal with the needs of large mbuf clusters. Again, I think using the external mbuf storage mechanism is the right way to glue this in. One other comment...when I was looking at this stuff I came to the conclusion that supporting the Tigon 1 was a waste of time since it appears to be obsolete. Support for just the Tigon 2 should simplify the driver. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 18:32:45 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 DCDCF10F1E for ; Sun, 21 Feb 1999 18:32:35 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id SAA04491; Sun, 21 Feb 1999 18:32:09 -0800 Date: Sun, 21 Feb 1999 18:32:09 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Luoqi Chen Cc: dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday - update In-Reply-To: <199902212353.SAA12884@lor.watermarkgroup.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, 21 Feb 1999, Matthew Jacob wrote: > > > > > > > > Sorry to say that during testing last night (in the middle of which a > > > buildworld got started) the system paniced again with a 'panic: getnewbuf > > > infinite recursion failure'. I've left it in the debugger if anyone could > > > suggest looking at something. I'm going to New Orleans tomorrow so it can > > > sit in the debugger until Friday... > > > > > > A very cursory look at the code makes me wonder 'why the value of 5 for a > > > limit'? It doesn't seem to me a panic is a good solution. > > > > Apart from the use of 5 as a 'magic' number, this code doesn't cope with > > being reentered by another process - the recursion test needs to be on a > > per-process basis. I'm sure that if you check the stack trace, you won't > > see any kind of recursion happening. > > > What troubled me here is why these supposedly async writes block (and ccd > is not involved)? I'd really like to see a dump of ps listing from ddb. Ask and ye shall receive (some 'Mores' editted out): panic: getnewbuf: cannot get buffer, infinite recursion failure panic Stopped at Debugger..ng+0x24: ldq ra,0(sp) <0xfffffe0007ef99f0> db> $c ? db> t Debugger..ng() at Debugger..ng+0x24 panic..ng() at panic..ng+0xf0 getnewbuf..ng() at getnewbuf..ng+0x424 getblk..ng() at getblk..ng+0x3e0 ffs_balloc..ng() at ffs_balloc..ng+0xa50 ffs_write..ng() at ffs_write..ng+0x384 vn_write..ng() at vn_write..ng+0x160 write..ng() at write..ng+0x12c syscall..ng() at syscall..ng+0x1dc XentSys() at XentSys+0x50 (null)() at 0x120000fe8 db> ps axl Symbol not found db> ps pid proc addr uid ppid pgrp flag stat wmesg wchan cmd 14173 fffffe0007b44f80 fffffe0007f5e000 0 12549 4274 004004 2 make 14164 fffffe0007b45b60 fffffe0007f98000 31154 14163 13374 004004 2 ld 14163 fffffe0007b4a040 fffffe0007b86000 31154 14148 13374 004084 3 wait fffffe0007b4a040 cc 14148 fffffe0007b45dc0 fffffe0007f94000 31154 13374 13374 004084 3 wait fffffe0007b45dc0 make 13377 fffffe000707b900 fffffe0007b04000 0 13372 147 004184 3 piperd fffffe0007a4ee40 sendmail 13374 fffffe0007b496c0 fffffe0007b98000 31154 13372 13374 004084 3 wait fffffe0007b496c0 sh 13372 fffffe0007b48fa0 fffffe0007bac000 0 147 147 000084 3 piperd fffffe0007a4f620 cron 12549 fffffe0007b46020 fffffe0007f5a000 0 12545 4274 004084 3 wait fffffe0007b46020 sh 12545 fffffe000707da40 fffffe0007ac4000 0 90946 4274 004084 3 wait fffffe000707da40 make 10908 fffffe0007b47580 fffffe0007efa000 31154 770 10908 004006 3 getblk fffffe00044537f0 writeit 10907 fffffe0007b49920 fffffe0007b94000 31154 770 10907 004006 3 getblk fffffe00044640f0 writeit 10906 fffffe0007b4b0e0 fffffe0007b62000 31154 770 10906 004006 3 getblk fffffe00044a2ff0 writeit 10905 fffffe000707d0c0 fffffe0007ad4000 31154 770 10905 004006 3 getblk fffffe0004470460 writeit 10904 fffffe0007b45900 fffffe0007f9c000 31154 770 10904 004006 3 getblk fffffe0004470460 writeit 10903 fffffe000707b1e0 fffffe0007b10000 31154 770 10903 004006 3 nfsrcvlk fffffe0007a55b00 writeit 10902 fffffe0007b47320 fffffe0007efe000 31154 770 10902 004006 3 nfsrcvlk fffffe0007a55b00 writeit 10901 fffffe000707d7e0 fffffe0007ac8000 31154 770 10901 004006 3 getblk fffffe0004483d68 writeit 10900 fffffe0007b49460 fffffe0007b9c000 31154 770 10900 004006 3 getblk fffffe0004470460 writeit 10899 fffffe0007b48ae0 fffffe0007bb6000 31154 770 10899 004006 3 nfsrcvlk fffffe0007a55b00 writeit 10898 fffffe0007b48880 fffffe0007bba000 31154 770 10898 004006 3 getblk fffffe0004470460 writeit 10897 fffffe0007079ee0 fffffe0007b3e000 31154 770 10897 004006 3 nfsrcvlk fffffe0007a55b00 writeit 10896 fffffe0007b44600 fffffe0007f6a000 31154 770 10896 004006 3 nfsrcvlk fffffe0007a55b00 writeit 10895 fffffe0007b46e60 fffffe0007f0e000 31154 770 10895 004006 2 writeit 10894 fffffe0007b4ac20 fffffe0007b6a000 31154 770 10894 004006 3 getblk fffffe0004456cf0 writeit 10892 fffffe0007b48d40 fffffe0007bb2000 31154 770 10892 004006 3 getblk fffffe0004470460 writeit 10891 fffffe000707cc00 fffffe0007ae0000 31154 770 10891 004006 3 getblk fffffe0004470460 writeit 10890 fffffe0007b45440 fffffe0007fa4000 31154 770 10890 004006 3 getblk fffffe00044a2108 writeit 10889 fffffe000707b440 fffffe0007b0c000 31154 770 10889 004006 3 getblk fffffe0004470460 writeit 10888 fffffe0007b47a40 fffffe0007ef2000 31154 770 10888 004006 3 getblk fffffe0004467e38 writeit 10887 fffffe0007b48620 fffffe0007bc0000 31154 770 10887 004006 3 getblk fffffe000445f9b8 writeit 10886 fffffe0007b46c00 fffffe0007f12000 31154 770 10886 004006 2 writeit 10885 fffffe0007b477e0 fffffe0007ef6000 31154 770 10885 004006 2 writeit 10884 fffffe0007b4b340 fffffe0007b5e000 31154 770 10884 004006 2 writeit 10883 fffffe0007b44ac0 fffffe0007f66000 31154 770 10883 004006 2 writeit 10882 fffffe0007b4a2a0 fffffe0007b80000 31154 770 10882 004006 3 getblk fffffe0004470460 writeit 10880 fffffe000707ce60 fffffe0007adc000 31154 770 10880 004006 3 nfsrcvlk fffffe0007a55b00 writeit 10879 fffffe0007b451e0 fffffe0007fa8000 31154 770 10879 004006 3 getblk fffffe0004470460 writeit 10878 fffffe000707a140 fffffe0007b3a000 31154 770 10878 004006 3 getblk fffffe0004470460 writeit 10877 fffffe000707e160 fffffe0007ab4000 31154 770 10877 004006 2 writeit 10875 fffffe0007b46280 fffffe0007f24000 31154 770 10875 004006 2 writeit 10874 fffffe0007b49200 fffffe0007ba8000 31154 770 10874 004006 3 getblk fffffe0004470460 writeit 10872 fffffe0007b47ca0 fffffe0007eee000 31154 770 10872 004006 2 writeit 10870 fffffe0007b464e0 fffffe0007f28000 31154 770 10870 004006 2 writeit 10868 fffffe0007b483c0 fffffe0007ee2000 31154 770 10868 004006 2 writeit 10867 fffffe000707bdc0 fffffe0007afa000 31154 770 10867 004006 2 writeit 10866 fffffe0007b49b80 fffffe0007b90000 31154 770 10866 004006 3 getblk fffffe0004444e68 writeit 10865 fffffe0007b4b5a0 fffffe0007b5a000 31154 770 10865 004006 2 writeit 10864 fffffe000707a3a0 fffffe0007b36000 31154 770 10864 004006 3 getblk fffffe0004470460 writeit 10863 fffffe0007b4a500 fffffe0007b78000 31154 770 10863 004006 2 writeit 10862 fffffe0007b470c0 fffffe0007f0a000 31154 770 10862 004006 3 getblk fffffe0004470460 writeit 10861 fffffe0007b46740 fffffe0007f1a000 31154 770 10861 004006 2 writeit 10859 fffffe0007b4ba60 fffffe0007b52000 31154 770 10859 004006 3 getblk fffffe0004470460 writeit 90946 fffffe000707a600 fffffe0007b32000 0 90943 4274 004084 3 wait fffffe000707a600 sh 90943 fffffe000707dca0 fffffe0007abe000 0 90942 4274 004084 3 wait fffffe000707dca0 make 90942 fffffe000707aac0 fffffe0007b1e000 0 4285 4274 004084 3 wait fffffe000707aac0 sh 4285 fffffe0007b4bcc0 fffffe0007b4c000 0 4284 4274 004084 3 wait fffffe0007b4bcc0 make 4284 fffffe000707c4e0 fffffe0007aee000 0 4283 4274 004084 3 wait fffffe000707c4e0 sh 4283 fffffe000707d580 fffffe0007acc000 0 4282 4274 004084 3 wait fffffe000707d580 make 4282 fffffe000707c280 fffffe0007af2000 0 4279 4274 004084 3 wait fffffe000707c280 sh 4279 fffffe000707bb60 fffffe0007afe000 0 4278 4274 004084 3 wait fffffe000707bb60 make 4278 fffffe000707d320 fffffe0007ad0000 0 4275 4274 004084 3 wait fffffe000707d320 sh 4275 fffffe000707a860 fffffe0007b2c000 31154 4274 4274 004084 3 wait fffffe000707a860 sh 4274 fffffe000707efa0 fffffe0007a9a000 31154 4272 4274 004084 3 wait fffffe000707efa0 sh 4272 fffffe000707ad20 fffffe0007b18000 0 147 147 000084 3 piperd fffffe0007a4fa80 cron 770 fffffe000707f460 fffffe0007a8e000 31154 193 770 004086 3 pause fffffe0007a8e1a8 csh 261 fffffe000707e3c0 fffffe0007aae000 31154 230 261 004186 3 nanslp fffffc000056b890 iostat 230 fffffe000707eae0 fffffe0007aa2000 31154 229 230 004086 3 wait fffffe000707eae0 bash 229 fffffe000707ed40 fffffe0007a9e000 0 144 229 004184 3 select fffffc000058fa20 rlogind 193 fffffe000707f200 fffffe0007a96000 31154 192 193 004086 3 wait fffffe000707f200 bash 192 fffffe00070802a0 fffffe0007a72000 0 144 192 004184 3 select fffffc000058fa20 rlogind 188 fffffe0007081340 fffffe0007a38000 0 1 188 004086 3 ttyin fffffc0000589810 getty 147 fffffe000707f6c0 fffffe0007a88000 0 1 147 000084 3 nanslp fffffc000056b890 cron 144 fffffe000707f920 fffffe0007a82000 0 1 144 000084 3 select fffffc000058fa20 inetd 126 fffffe000707fb80 fffffe0007a7e000 0 1 118 000084 3 nfsidl fffffc0000592a98 nfsiod 125 fffffe000707fde0 fffffe0007a7a000 0 1 118 000084 3 nfsidl fffffc0000592a90 nfsiod 124 fffffe0007080040 fffffe0007a76000 0 1 118 000084 3 nfsidl fffffc0000592a88 nfsiod 123 fffffe00070810e0 fffffe0007a3c000 0 1 118 000084 3 nfsidl fffffc0000592a80 nfsiod 107 fffffe0007080500 fffffe0007a6e000 0 1 107 000084 3 select fffffc000058fa20 ypbind 103 fffffe0007080760 fffffe0007a6a000 1 1 103 000184 3 select fffffc000058fa20 portmap 99 fffffe00070809c0 fffffe0007a5a000 0 1 99 000084 3 select fffffc000058fa20 xntpd 91 fffffe0007080e80 fffffe0007a40000 0 1 91 000084 3 select fffffc000058fa20 syslogd 20 fffffe0007080c20 fffffe0007a44000 0 1 20 000284 3 mfsidl fffffe0007073500 mount_mfs 4 fffffe00070815a0 fffffe0007094000 0 0 0 000204 3 syncer fffffc000058f970 syncer 3 fffffe0007081800 fffffe0007090000 0 0 0 000204 3 psleep fffffc0000588034 vmdaemon 2 fffffe0007081a60 fffffe000708c000 0 0 0 000204 3 psleep fffffc00005527f8 pagedaemon 1 fffffe0007081cc0 fffffe0007088000 0 0 1 004084 3 wait fffffe0007081cc0 init 0 fffffc000058e1b0 fffffc000061c000 0 0 0 000204 3 sched fffffc000058e1b0 swapper db> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 20:13: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gras-varg.worldgate.com (gras-varg.worldgate.com [198.161.84.12]) by hub.freebsd.org (Postfix) with ESMTP id 431831237B for ; Sun, 21 Feb 1999 20:12:11 -0800 (PST) (envelope-from skafte@gras-varg.worldgate.com) Received: (from skafte@localhost) by gras-varg.worldgate.com (8.9.1a/8.9.1) id VAA12832 for freebsd-hackers@freebsd.org; Sun, 21 Feb 1999 21:12:11 -0700 (MST) Date: Sun, 21 Feb 1999 21:12:10 -0700 From: Greg Skafte To: freebsd-hackers@freebsd.org Subject: kde Message-ID: <19990221211210.A12674@gras-varg.worldgate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i Organization: WorldGate Inc. X-PGP-Fingerprint: 42 9C 2C A8 4D 2B C9 C4 7D B6 00 B0 50 47 20 97 X-URL: http://gras-varg.worldgate.com/~skafte Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here's one for any of you kde11 users.... I've got a 3.1-STABLE box running XFree86-3.3.3.1 It's a PII-333 (non-celeron) w/ 128M ram and a S3virge card. occasionally the box will lock hard just after logging out and the machine corupts the video display memory ( Iget a but of vertical lines). First I though it was kdm, so I converted back to xdm to call the startkde. It happend under xdm, so I tried just doing a bunch of startx. similar result, so I'm back to kdm. I've noticed that _IF_ you have a wallpaper that the wall paper will disappear and then the next logout boom the machine is locked. no kernel messages no syslogs, no keyboard, no network can only hit the reset switch. just curious if its an XFree issue, or a kde11 issue... the kde lists are very linux oriented and more my kppp isn't working than anything else (so far). -- Email: skafte@worldgate.com Voice: +403 413 1910 Fax: +403 421 4929 #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 -- -- When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex. (Janet Morris) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 20:13:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 4C5A411E72 for ; Sun, 21 Feb 1999 20:13:18 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id UAA08671; Sun, 21 Feb 1999 20:13:16 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.2/8.9.1) id UAA20256; Sun, 21 Feb 1999 20:13:16 -0800 (PST) (envelope-from jdp@polstra.com) Date: Sun, 21 Feb 1999 20:13:16 -0800 (PST) Message-Id: <199902220413.UAA20256@vashon.polstra.com> To: mrcpu@internetcds.com Subject: Re: Anybody got the Linux PAM module for Apache 1.3.3 on FreeBSD 3.1-stable? In-Reply-To: Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article , Jaye Mathisen wrote: > > I've got it all compiled, but suspect that I must have pam.conf boobered > up, or something. > > Apache 1.3.3ssl compiled out of ports, > the Apache PAM module: http://blank.pages.de/pam/ > > modified the apache compile to link with -lpam. > > /etc/pam.conf contains: > > > httpd auth required pam_unix.so try_first_pass > httpd account required pam_unix.so try_first_pass > httpd password required pam_unix.so try_first_pass We don't have any modules that support "account" or "password" yet. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 20:31:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id D6DC011E0D for ; Sun, 21 Feb 1999 20:30:04 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.com (zaphod.softweyr.com [204.68.178.35]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id VAA10259; Sun, 21 Feb 1999 21:29:49 -0700 (MST) (envelope-from wes@softweyr.com) Message-ID: <36D0DD3C.FD6086D6@softweyr.com> Date: Sun, 21 Feb 1999 21:29:48 -0700 From: Wes Peters Organization: Softweyr llc X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: dg@root.com Cc: Bill Paul , hackers@FreeBSD.ORG Subject: Re: How to handle jumbo etherney frames References: <199902220110.RAA15394@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: > > >Programming the chip to use a single vlan tag wouldn't require that much > >work. > > Whether to use a VLAN and/or which VLAN to use is a per destination thing, > not a per host/interface thing, so I don't think a single VLAN would be > very useful. Unless you use a smart switch that does that for you, in which case you can use any (supported by the switch) frame type you want, with or without tags. > >I'm not really inclined to just implement only standard frame support > >and wait around for large mbuf cluster support to materialize since there's > >no telling how long that could take. I think I may be stuck between a > > Then implement large mbuf support. :-) That would certainly be "the best" way to handle it. That *and* a zero-copy interface to userland. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@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 Feb 21 20:42:18 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 478A310FAB for ; Sun, 21 Feb 1999 20:42:15 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id XAA14152; Sun, 21 Feb 1999 23:42:10 -0500 (EST) (envelope-from luoqi) Date: Sun, 21 Feb 1999 23:42:10 -0500 (EST) From: Luoqi Chen Message-Id: <199902220442.XAA14152@lor.watermarkgroup.com> To: mjacob@feral.com Subject: Re: Panic in FFS/4.0 as of yesterday - update Cc: dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > What troubled me here is why these supposedly async writes block (and ccd > > is not involved)? I'd really like to see a dump of ps listing from ddb. > The async writes blocked on "nfsrcvlk". It looked like the test program writeit was trying to clean some dirty nfs bufs. This situation shouldn't be fatal as it is impossible to avoid blocking during async writes, getnewbuf should simply return a NULL. The following patch should do the trick. -lq Index: vfs_bio.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v retrieving revision 1.199 diff -u -r1.199 vfs_bio.c --- vfs_bio.c 1999/01/27 21:49:58 1.199 +++ vfs_bio.c 1999/02/22 04:19:06 @@ -993,6 +993,7 @@ bp->b_qindex); #endif } +waitforany: if (!bp) { /* wait for a free buffer of any kind */ needsbuffer |= VFS_BIO_NEED_ANY; @@ -1069,8 +1070,10 @@ bp = TAILQ_NEXT(bp, b_freelist); } } - if (bp == NULL) - panic("getnewbuf: cannot get buffer, infinite recursion failure"); + if (bp == NULL) { + printf("getnewbuf: cannot get buffer, infinite recursion failure\n"); + goto waitforany; + } } else { bremfree(bp); bp->b_flags |= B_BUSY | B_AGE | B_ASYNC; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 20:44:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rah.star-gate.com (rah.star-gate.com [209.249.129.138]) by hub.freebsd.org (Postfix) with ESMTP id 29EE111061 for ; Sun, 21 Feb 1999 20:44:28 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.1/8.8.8) with ESMTP id UAA88362 for ; Sun, 21 Feb 1999 20:43:25 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199902220443.UAA88362@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: hackers@FreeBSD.ORG Subject: gcc 2.8.1 Exceptions? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Feb 1999 20:43:25 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does anyone know what is the magic incatation to make C++ exceptions work with gcc-2.8.1 from the ports distribution? . Exception handling appears to work with the stock gcc... /usr/local/bin/g++ -g -o foox foo.cpp foo.cpp: In function `void terminate()': foo.cpp:19: warning: `noreturn' function `terminate()' does return ./foox Abort (core dumped) /usr/bin/g++ -g -fhandle-exceptions -o foox foo.cpp {hasty} ./foox hello hello a Exception caught I shot the compiler! main() { int i = 0; try { i = i + 1; if (i > 0 ) throw "I shot the compiler!"; } catch ( char *p) { printf("hello \n"); printf("hello a \n"); printf("Exception caught %s\n", p); } } void terminate() { printf("hello terminate \n"); } Tnks, Amancio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 21:22:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id AE2C110EF3 for ; Sun, 21 Feb 1999 21:22:21 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id WAA06796; Sun, 21 Feb 1999 22:22:10 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp02.primenet.com, id smtpd006770; Sun Feb 21 22:22:06 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id WAA00546; Sun, 21 Feb 1999 22:21:50 -0700 (MST) From: Terry Lambert Message-Id: <199902220521.WAA00546@usr07.primenet.com> Subject: Re: UNIX license issues (was: Searching an "old" BSD stdio) To: wes@softweyr.com (Wes Peters) Date: Mon, 22 Feb 1999 05:21:49 +0000 (GMT) Cc: tlambert@primenet.com, grog@lemis.com, Dom.Mitchell@palmerharvey.co.uk, desar@club-internet.fr, freebsd-hackers@FreeBSD.ORG Reply-To: chat@FreeBSD.ORG In-Reply-To: <36CF995E.C1ED0E8E@softweyr.com> from "Wes Peters" at Feb 20, 99 10:27:58 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 > > Also unfortunately, I don't have media, and I think media costs on > > SVR3 still exceed $100. 8-(. > > I've probably still got Johnnie's set in a box downstairs. It took > a LOT of 1.2MB 5.25" floppies to store the entire SVR3 source code, > you know? It's OK, you're in the clear; they're dead by now. > Now VAX/VMS source was really hard to get your hands on, but we had > that, too. Or, you could just get it the way Kevin Mitnick did - > steal it from Rob Clyde. ;^) The VMS source license was on microfiche, more's the pity. It's still in "The VAX Cave". You could get the source on mag tape, and you could get a Bliss compiler ("Bliss is Ingnorance"), but they were too expensive. I seem to remember it being a choice between Icarus and machine readable VMS sources. Heh. We probably ought to take "old fart days" off the list, or at least move it to chat (I've set the "Reply-To:"). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 21:34:24 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 751BD10E8F for ; Sun, 21 Feb 1999 21:34:19 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id WAA11941; Sun, 21 Feb 1999 22:34:19 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp03.primenet.com, id smtpd011911; Sun Feb 21 22:34:16 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id WAA01171; Sun, 21 Feb 1999 22:34:09 -0700 (MST) From: Terry Lambert Message-Id: <199902220534.WAA01171@usr07.primenet.com> Subject: Re: Panic in FFS/4.0 as of yesterday To: dfr@nlsystems.com (Doug Rabson) Date: Mon, 22 Feb 1999 05:34:08 +0000 (GMT) Cc: tlambert@primenet.com, dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Doug Rabson" at Feb 21, 99 09:47:16 am 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 > > > I think promoting directory writes (and directory reads probably) might be > > > the simplest solution. > > > > OK, here's code to add the ability to expedite placement of async > > writes. It' doesn't insert them in order behind other expedited > > writes, so it turns the expedited stuff LIFO. This is probably > > suboptimal, but can't happen in dependent operations, so what the > > heck... > > > > When you use the code, be sure to *not* set the flag if soft updates > > are in effect (I think that's a caller issue, not a callee issue, since > > it would complicate the bdwrite code, probably unacceptably. > > I don't think this will do the job at all. The buffers in question are > not delayed writes, so all this patch will do is change the order of the > LOCKED and LRU lists, probably pessimising the reuse of those buffers. Check the code paths and look for B_ASYNC getting unset. I believe this is the correct patch. > I think the flag needs to be implemented in the driver. The driver should > check for the EXPEDITE flag and either maintain two queues for the two > possible priorities or place the buffer at the front of a single work > queue. This has some serious flaws. The first is, you have to get it right in more than one driver. This is really like the "wakeup" character change I did to the serial drivers to allow for unanticipated "hotchar" in binary only drivers from third parties, like E.T. Inc.. The second is that the lock cascade occurs because of locked vnodes over an operation queued through this code, and only completion notification will get rid of the lock. The third is that, however you do it, it needs to be harmless to disk integrity in the soft updates and standard mount cases. The standard mount case comes for free, by not using the B_ASYNC flag; but the soft updates case is harder. You won't be able to add an assert check at the queue-to-driver level to make sure the code is right, since the buffer is no longer associated with the structure that contains the soft dependency active/inactive information. Look at the cases where the I/O call is actually made in the UFS code, and trace the function calls down. I'm willing to be wrong. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 23: 3:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (Postfix) with SMTP id 865CA10E84 for ; Sun, 21 Feb 1999 23:02:52 -0800 (PST) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id CAA14944; Mon, 22 Feb 1999 02:09:40 -0500 From: Bill Paul Message-Id: <199902220709.CAA14944@skynet.ctr.columbia.edu> Subject: Re: How to handle jumbo etherney frames To: dg@root.com Date: Mon, 22 Feb 1999 02:09:38 -0500 (EST) Cc: hackers@freebsd.org In-Reply-To: <199902220110.RAA15394@implode.root.com> from "David Greenman" at Feb 21, 99 05:10:15 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2604 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Of all the gin joints in all the towns in all the world, David Greenman had to walk into mine and say: > >Programming the chip to use a single vlan tag wouldn't require that much > >work. > > Whether to use a VLAN and/or which VLAN to use is a per destination thing, > not a per host/interface thing, so I don't think a single VLAN would be > very useful. Well, supposedly we have some vlan support code in /sys/net/if_vlan.c. What are the odds of getting this to work with for this purpose? > >I'm not really inclined to just implement only standard frame support > >and wait around for large mbuf cluster support to materialize since there's > >no telling how long that could take. I think I may be stuck between a > > Then implement large mbuf support. :-) That's not even remotely funny. All I want to do is write a device driver. That's enough work as it is. You're the principal architect; _you_ implement large mbuf support. > Using malloc for this is probably not a good idea since it wants to > allocate power of two sizes, so you'd needlessly waste a whole page. This > really needs a special allocator specifically designed to deal with the > needs of large mbuf clusters. Again, I think using the external mbuf storage > mechanism is the right way to glue this in. I'm not going to build a whole memory allocator/management subsystem into this driver. Until something else comes along, malloc() will have to do. > One other comment...when I was looking at this stuff I came to the > conclusion that supporting the Tigon 1 was a waste of time since it appears > to be obsolete. Support for just the Tigon 2 should simplify the driver. I disagree. The differences between the Tigon 1 and the Tigon 2 are not that extensive. The Tigon 1 doesn't support the mini receive ring, there are one or two commands that have changed, and you need to load a different firmware image, but for the most part operation is the same. I'd much rather be able to say that the driver supports both chip revs than save a few lines of code. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 23: 3:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pegasus.freibergnet.de (pegasus.freibergnet.de [194.123.255.9]) by hub.freebsd.org (Postfix) with ESMTP id 4A1C310F9B for ; Sun, 21 Feb 1999 23:03:48 -0800 (PST) (envelope-from holm@pegasus.freibergnet.de) Received: (from holm@localhost) by pegasus.freibergnet.de (8.9.3/8.9.1) id IAA14880; Mon, 22 Feb 1999 08:03:15 +0100 (CET) (envelope-from holm) Date: Mon, 22 Feb 1999 08:03:15 +0100 From: Holm Tiffe To: "Richard Seaman, Jr." Cc: Peter Wemm , Geoff Rehmet , "'hackers@freebsd.org'" Subject: Re: Star Office 5 woes Message-ID: <19990222080315.A14805@pegasus.freibergnet.de> Reply-To: holm@freibergnet.de References: <19990218102949.A38074@tar.com> <199902191623.AAA07202@spinner.netplex.com.au> <19990219110255.B44582@tar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.95i In-Reply-To: <19990219110255.B44582@tar.com>; from Richard Seaman, Jr. on Fri, Feb 19, 1999 at 11:02:55AM -0600 Organization: FreibergNet Internet Services X-Phone: +49-3731-781279 X-Fax: +49-3731-781377 X-PGP-fingerprint: 86 EC A5 63 B5 28 78 13 8B FC E9 09 04 6E 86 FC Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Richard Seaman, Jr. wrote: > On Sat, Feb 20, 1999 at 12:23:51AM +0800, Peter Wemm wrote: > > > I don't know anybody who's been able to get it to work, except for you. :-) I'm such a person too, exactly the same basic related runtime error, including those lib's does'nt work fo me. The machine here is an PII-350 w. 256 Mbytes of RAM. OS is -current from Feb. 17. Holm -- FreibergNet Systemhaus GbR Holm Tiffe * Administration, Development Systemhaus für Daten- und Netzwerktechnik phone +49 3731 781279 Unternehmensgruppe Liebscher & Partner fax +49 3731 781377 D-09599 Freiberg * Am St. Niclas Schacht 13 http://www.freibergnet.de/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 21 23:30:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pacman.redwoodsoft.com (redwoodsoft.com [207.181.199.182]) by hub.freebsd.org (Postfix) with SMTP id EECE710F3F for ; Sun, 21 Feb 1999 23:30:14 -0800 (PST) (envelope-from dnelson@pacman.redwoodsoft.com) Received: (qmail 4061 invoked by uid 1000); 22 Feb 1999 07:30:11 -0000 Date: Sun, 21 Feb 1999 23:30:11 -0800 (PST) From: Dru Nelson To: freebsd-hackers@freebsd.org Subject: RE: SMP and libc_r (mysql) 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 User space threads (like the one used by MySQL) are actually great as far as threads packages go. However, it can onlny block nicely on sockets, pipes, char devices, etc. It really doesn't schedule well around blocking file reads and writes. I believe it uses a signal to cause the scheduler to kick in (a signal is not an inexepensive thing) and switch threads... So, with MySQL, which does A LOT of file seeks/reads/writes etc, it might be better to have some kernel support (Which IS comming RSN) to schedule around that I/O blocking. However, its existing performance may be fine for the problem you are trying to solve (it is very fast). Am I too far off on this one guys.... Three side notes: 1. We use MySQL, and we found the performance to be a little better under linux (however, we have the 2 GIG limit on the linux system, and we're not going to patch around this just yet). However, when memory gets scarce it dies horribly. 2. MySQL is not that great. I know this is heresy, but it's true. When you have a lot of clients banging on the server, a database that can do row level locking is a lot nicer. (Also, the database's lack of real transactions and real replication bothers me a lot.) So, you might want to look around. Otherwise, it is great for getting a project done quickly. 3. You might look into getting a really fast RAID and a lot of memory. This will do wonders for your database... Dru Nelson Redwood City, California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 0: 9:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id A6EFF10E84 for ; Mon, 22 Feb 1999 00:09:19 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id BAA14479; Mon, 22 Feb 1999 01:09:18 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp01.primenet.com, id smtpd014450; Mon Feb 22 01:09:08 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id BAA21559; Mon, 22 Feb 1999 01:09:06 -0700 (MST) From: Terry Lambert Message-Id: <199902220809.BAA21559@usr09.primenet.com> Subject: Re: YP-like mySQL thing To: dnelson@redwoodsoft.com (Dru Nelson) Date: Mon, 22 Feb 1999 08:09:05 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Dru Nelson" at Feb 21, 99 01:53:25 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 > Another option, Luke Howard has worked on standardizing > LDAP as a replacement for YP/Netinfo/NIS+/etc. > > I saw part of his talk, and it looks like it might go somewhere. > > There is an RFC for the Schema, I believe. RFC 2307. http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2307.txt I have an implementation suitable for framing (under an nsswitch) if anyone is interested in doing an nsswitch for FreeBSD, and will donate the code back under BSD license. I actually think I handle error cases better than Luke Howard. Unfortunately, I was unable the attend Luke's Bay LISA talk due to a prior commitment with the local Neighborhood Watch. From what I understand, it was rather opaque, except to people like me. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 0: 9:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.dyn.ml.org (pm3-22.ppp.wenet.net [206.15.85.22]) by hub.freebsd.org (Postfix) with ESMTP id 40ADA11B46 for ; Mon, 22 Feb 1999 00:09:15 -0800 (PST) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost [127.0.0.1]) by zippy.dyn.ml.org (8.9.2/8.9.1) with ESMTP id AAA01057; Mon, 22 Feb 1999 00:07:43 -0800 (PST) (envelope-from garbanzo@hooked.net) Date: Mon, 22 Feb 1999 00:07:43 -0800 (PST) From: Alex Zepeda To: Amancio Hasty Cc: hackers@FreeBSD.ORG Subject: Re: gcc 2.8.1 Exceptions? In-Reply-To: <199902220443.UAA88362@rah.star-gate.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, 21 Feb 1999, Amancio Hasty wrote: > Exception handling appears to work with the stock gcc... Uhh I don't think so. That's one of the selling points of gcc 2.8 or newer. To get exception handling working you'll need to use -fsjlj-exceptions (setjmp/longjmp exceptions). If you need thread safe exceptions, get egcs 1.1.1, and use the various startup objects from it (and then you can ditch -fsjlj-exceptions). - alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 0:14:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.Technion.AC.IL (csa.cs.technion.ac.il [132.68.32.1]) by hub.freebsd.org (Postfix) with ESMTP id C4B2D1177D; Mon, 22 Feb 1999 00:14:16 -0800 (PST) (envelope-from nadav@cs.technion.ac.il) Received: from csd.csa (csd.cs.technion.ac.il [132.68.32.8]) by cs.Technion.AC.IL (8.9.0/8.9.0) with SMTP id KAA18841; Mon, 22 Feb 1999 10:15:52 +0200 (IST) Received: from localhost by csd.csa (SMI-8.6/SMI-SVR4) id KAA13238; Mon, 22 Feb 1999 10:15:46 +0200 Date: Mon, 22 Feb 1999 10:15:46 +0200 (IST) From: Nadav Eiron X-Sender: nadav@csd To: chat@FreeBSD.ORG Cc: Wes Peters , tlambert@primenet.com, grog@lemis.com, Dom.Mitchell@palmerharvey.co.uk, desar@club-internet.fr, freebsd-hackers@FreeBSD.ORG Subject: Re: UNIX license issues (was: Searching an "old" BSD stdio) In-Reply-To: <199902220521.WAA00546@usr07.primenet.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, 22 Feb 1999, Terry Lambert wrote: > > > Also unfortunately, I don't have media, and I think media costs on > > > SVR3 still exceed $100. 8-(. > > > > I've probably still got Johnnie's set in a box downstairs. It took > > a LOT of 1.2MB 5.25" floppies to store the entire SVR3 source code, > >you know? > > It's OK, you're in the clear; they're dead by now. > > > > Now VAX/VMS source was really hard to get your hands on, but we had > > that, too. Or, you could just get it the way Kevin Mitnick did - > > steal it from Rob Clyde. ;^) > > The VMS source license was on microfiche, more's the pity. It's still > in "The VAX Cave". You could get the source on mag tape, and you could > get a Bliss compiler ("Bliss is Ingnorance"), but they were too expensive. > I seem to remember it being a choice between Icarus and machine readable > VMS sources. That was *very* long time ago. About 3 years ago, when I was with my previous employer, we got the OpenVMS/Alpha sources, on CD, for about $2000 (and DEC's Bliss compiler is now in the public domain). Still, you don't get the code for the LMF (license management facility) and other stuff DEC doesn't want you to know about, and it's only listings, so you have to work hard to get source that compiles from it. On the other hand, it was fun (and sometimes even useful) reading. > > Heh. We probably ought to take "old fart days" off the list, or at > least move it to chat (I've set the "Reply-To:"). > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are myown and not those of my present > or previous employers. > > Nadav To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 0:29:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rah.star-gate.com (rah.star-gate.com [209.249.129.138]) by hub.freebsd.org (Postfix) with ESMTP id 920B510EA0 for ; Mon, 22 Feb 1999 00:29:23 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.1/8.8.8) with ESMTP id AAA17995; Mon, 22 Feb 1999 00:28:18 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199902220828.AAA17995@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Alex Zepeda Cc: hackers@FreeBSD.ORG Subject: Re: gcc 2.8.1 Exceptions? In-reply-to: Your message of "Mon, 22 Feb 1999 00:07:43 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Feb 1999 00:28:18 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Alex, Not sure if exception handling on gcc-2.7.3 is buggy or what however per the simple minded program which I posted exception handling on gcc-2.7.3 appears to work. Now to get exception handling with gcc-2.8.1 from the porst dristribution working on FreeBSD defined in defaults.h: #define DWARF2_UNWIND_INFO 0 ^^^ which was 1 before. If I am not mistaken the above sets the exception handling to something like -fsjlj-exceptions. Currently working on porting Netscape's Electric Fire to FreeBSD. "EF" is a very cool java vm which translates java classes straight to machine instructions 8) If you are interested on EF see: http://www.mozilla.org/projects/ef Cheers, Amancio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 0:33:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 2E06810EA0 for ; Mon, 22 Feb 1999 00:33:47 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id BAA18325; Mon, 22 Feb 1999 01:33:47 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp01.primenet.com, id smtpd018291; Mon Feb 22 01:33:38 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id BAA22122; Mon, 22 Feb 1999 01:33:37 -0700 (MST) From: Terry Lambert Message-Id: <199902220833.BAA22122@usr09.primenet.com> Subject: Re: gcc 2.8.1 Exceptions? To: hasty@rah.star-gate.com (Amancio Hasty) Date: Mon, 22 Feb 1999 08:33:36 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <199902220443.UAA88362@rah.star-gate.com> from "Amancio Hasty" at Feb 21, 99 08:43:25 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 > Does anyone know what is the magic incatation to make C++ exceptions work > with gcc-2.8.1 from the ports distribution? . The GCC 2.8.(2?) from the ports has Jeremey Allison's code, developed while he was employed at Whistle, for GCC 2.8.x, for threads exceptions in C++ (this was the same threads work donated back to FreeBSD for Draft 4 complaince for the pthreads implementation). This should work fine, since I used it with PMTA (POP Mail Transfer Agent), a fetchmail replacement using the "cathedral" rather than the "bazaar" model to work around about 15 fetchmail bugs. It's in the Whistle source tree, which you have access to, though it's a strategic rather than a tactical technology (would that I could publish it to repudiate Eric Raymonds silly claims). Basically, I have reimplemented almost all of JAVA's functionality in C++, including the full exception typing, to implement the full JavaMail API, as documented by Sun, in C++. It took about two weeks, total (look at the checkin logs to see dates) JAVA is a triviality, IMO. Any competent engineer could recreate a complete JAVA in two months, at most. Makes me wonder what the WINE guys are actually doing with their time. One "gotcha" is that FreeBSD is totally screwed with regard to the .mk files treatment of DESTDIR, since it make no distinction between build and target environments (this comes from assuming that the universe is x86, but also precludes targetting embedded x86 systems). Take a look at the PMTA Makefile; it overrides the DESTDIR build environment overrides of the include directories. Basically, FreeBSD is stupid with regard to the overide of the include paths. Most likely, what is biting you is the FreeBSD override of the include paths to the 2.7.x compiler's RTTI header files, which are broken in about six places, from using 2.8.x as a port rather than as the default compiler. Hopefully this stupidity will go away as the powers that be reorganize the way that ports are installed as system components instead of add-on's, and the source tree becomes less Intel-centric (c.v. the SPARC box in my cube at work). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 0:35:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rah.star-gate.com (rah.star-gate.com [209.249.129.138]) by hub.freebsd.org (Postfix) with ESMTP id 36E42112FE for ; Mon, 22 Feb 1999 00:35:10 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.1/8.8.8) with ESMTP id AAA18057; Mon, 22 Feb 1999 00:34:04 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199902220834.AAA18057@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Greg Skafte Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: kde In-reply-to: Your message of "Sun, 21 Feb 1999 21:12:10 MST." <19990221211210.A12674@gras-varg.worldgate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Feb 1999 00:34:04 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sounds like an Xserver or harware problem . Whats your card and the color depth that you are running with X server with? Amancio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 0:40:14 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 E69A4115B3 for ; Mon, 22 Feb 1999 00:40:12 -0800 (PST) (envelope-from mjacob@feral.com) Received: from float59.feral.com (mjacob@float59 [192.67.166.59]) by feral.com (8.8.7/8.8.7) with ESMTP id AAA14749; Mon, 22 Feb 1999 00:39:52 -0800 Date: Mon, 22 Feb 1999 00:44:18 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Luoqi Chen Cc: dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday - update In-Reply-To: <199902220442.XAA14152@lor.watermarkgroup.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 Sigh.. sorry- Unfortunately it'll have to wait. My alpha system hung on the way back up and I won't be physically there to unwedge it until after I get back from OSDI... sorry... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 0:49: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.ucb.crimea.ua (relay.ucb.crimea.ua [212.110.138.1]) by hub.freebsd.org (Postfix) with ESMTP id D668110F67 for ; Mon, 22 Feb 1999 00:48:17 -0800 (PST) (envelope-from ru@ucb.crimea.ua) Received: (from ru@localhost) by relay.ucb.crimea.ua (8.9.2/8.9.2/UCB) id KAA65051; Mon, 22 Feb 1999 10:48:07 +0200 (EET) (envelope-from ru) Date: Mon, 22 Feb 1999 10:48:07 +0200 From: Ruslan Ermilov To: FreeBSD Hackers Subject: Hackers! Any comments on bin/9963? Message-ID: <19990222104807.A63652@ucb.crimea.ua> Mail-Followup-To: FreeBSD Hackers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.17i X-Operating-System: FreeBSD 3.1-STABLE i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear Hackers! Could someone who has commitright take a look at bin/9963? Thanks, -- Ruslan Ermilov Sysadmin and DBA of the ru@ucb.crimea.ua United Commercial Bank +380.652.247.647 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 0:54: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lenka.ph.ipex.cz (lenka.ph.ipex.cz [62.168.16.2]) by hub.freebsd.org (Postfix) with ESMTP id 0DB2C10F92 for ; Mon, 22 Feb 1999 00:53:55 -0800 (PST) (envelope-from kan@sti.cz) Received: from linux.sti.cz (linux.sti.cz [62.168.16.129]) by lenka.ph.ipex.cz (8.8.5/IPEX) with ESMTP id JAA18843; Mon, 22 Feb 1999 09:53:52 +0100 Received: from sti.cz (kan.sti.cz [192.168.0.18]) by linux.sti.cz (8.8.7/8.7.3) with ESMTP id LAA25199; Mon, 22 Feb 1999 11:00:26 +0100 Message-ID: <36D11BA9.72C58018@sti.cz> Date: Mon, 22 Feb 1999 09:56:09 +0100 From: "Alexander N. Kabaev" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.1-STABLE i386) X-Accept-Language: ru, en MIME-Version: 1.0 Cc: Greg Skafte , freebsd-hackers@FreeBSD.ORG Subject: Re: kde References: <199902220834.AAA18057@rah.star-gate.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG XFree86 has problems with some S3 Virge chipsets, both PCI and AGP versions. I remember someone talking about S3 Virge GX2 card being incompatible with newest Intel motherboards. The only thing you could possibly do is to get new card. Alexander Kabaev To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 1:12:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.dyn.ml.org (pm3-22.ppp.wenet.net [206.15.85.22]) by hub.freebsd.org (Postfix) with ESMTP id E00DB10FF2 for ; Mon, 22 Feb 1999 01:11:57 -0800 (PST) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost [127.0.0.1]) by zippy.dyn.ml.org (8.9.2/8.9.1) with ESMTP id BAA01303; Mon, 22 Feb 1999 01:10:27 -0800 (PST) (envelope-from garbanzo@hooked.net) Date: Mon, 22 Feb 1999 01:10:27 -0800 (PST) From: Alex Zepeda To: Amancio Hasty Cc: hackers@FreeBSD.ORG Subject: Re: gcc 2.8.1 Exceptions? In-Reply-To: <199902220828.AAA17995@rah.star-gate.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, 22 Feb 1999, Amancio Hasty wrote: > Not sure if exception handling on gcc-2.7.3 is buggy or what however per the > simple > minded program which I posted exception handling on gcc-2.7.3 appears to work. AFAIK it's non-existant without some patches or somesuch. > Now to get exception handling with gcc-2.8.1 from the porst dristribution > working on FreeBSD > defined in defaults.h: > > #define DWARF2_UNWIND_INFO 0 > ^^^ which was 1 before. > > If I am not mistaken the above sets the exception handling to something like > -fsjlj-exceptions. Well this may have fixed it for a.out, but didn't work for me with ELF binaries. The best solution is to use egcs and its startup objects so you can get threadsafe exceptions and not have to deal with stupid defines. There's a patch to do this in the egcs port (patch-ak). Plus from what I've heard egcs 1.1.1 is a more reliable C++ compiler (hey it works with KOffice and *shudder* mico). > Currently working on porting Netscape's Electric Fire to FreeBSD. "EF" > is a very cool java vm which translates java classes straight to > machine instructions 8) Cool. - alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 1:16:58 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 08CA710FFA for ; Mon, 22 Feb 1999 01:16:43 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA57495; Mon, 22 Feb 1999 09:14:40 GMT (envelope-from dfr@nlsystems.com) Date: Mon, 22 Feb 1999 09:14:39 +0000 (GMT) From: Doug Rabson To: Holm Tiffe Cc: "Richard Seaman, Jr." , Peter Wemm , Geoff Rehmet , "'hackers@freebsd.org'" Subject: Re: Star Office 5 woes In-Reply-To: <19990222080315.A14805@pegasus.freibergnet.de> 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, 22 Feb 1999, Holm Tiffe wrote: > Richard Seaman, Jr. wrote: > > > On Sat, Feb 20, 1999 at 12:23:51AM +0800, Peter Wemm wrote: > > > > > I don't know anybody who's been able to get it to work, except for you. :-) > > I'm such a person too, exactly the same basic related runtime error, > including those lib's does'nt work fo me. > The machine here is an PII-350 w. 256 Mbytes of RAM. > OS is -current from Feb. 17. Download the new version from the same place you got so50. The registration process has been streamlined and doesn't seem to involve basic at all (its managed by the installer). -- 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 Mon Feb 22 1:19:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rah.star-gate.com (rah.star-gate.com [209.249.129.138]) by hub.freebsd.org (Postfix) with ESMTP id 5EE9C11526 for ; Mon, 22 Feb 1999 01:19:23 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.1/8.8.8) with ESMTP id BAA35954; Mon, 22 Feb 1999 01:18:18 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199902220918.BAA35954@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Alex Zepeda Cc: hackers@FreeBSD.ORG Subject: Re: gcc 2.8.1 Exceptions? In-reply-to: Your message of "Mon, 22 Feb 1999 01:10:27 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Feb 1999 01:18:18 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tnks I know that egcs is better than gcc-2.8 is just that egcs semantics for template handling got fixed or changed and it fails to compile "EF". EF uses default arguments in template functions which gcc alows however egcs does not . Will look into later to switch to egcs ... gcc-2.8.1 exception handling with elf objects works on 3.0 system s per my posting. Best Regards, Amancio > On Mon, 22 Feb 1999, Amancio Hasty wrote: > > > Not sure if exception handling on gcc-2.7.3 is buggy or what however per the > > simple > > minded program which I posted exception handling on gcc-2.7.3 appears to work. > > AFAIK it's non-existant without some patches or somesuch. > > > Now to get exception handling with gcc-2.8.1 from the porst dristribution > > working on FreeBSD > > defined in defaults.h: > > > > #define DWARF2_UNWIND_INFO 0 > > ^^^ which was 1 before. > > > > If I am not mistaken the above sets the exception handling to something like > > -fsjlj-exceptions. > > Well this may have fixed it for a.out, but didn't work for me with ELF > binaries. The best solution is to use egcs and its startup objects so you > can get threadsafe exceptions and not have to deal with stupid defines. > There's a patch to do this in the egcs port (patch-ak). Plus from what > I've heard egcs 1.1.1 is a more reliable C++ compiler (hey it works with > KOffice and *shudder* mico). > > > Currently working on porting Netscape's Electric Fire to FreeBSD. "EF" > > is a very cool java vm which translates java classes straight to > > machine instructions 8) > > Cool. > > - alex > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 1:24:20 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 06C0C1162B for ; Mon, 22 Feb 1999 01:23:31 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA57510; Mon, 22 Feb 1999 09:22:48 GMT (envelope-from dfr@nlsystems.com) Date: Mon, 22 Feb 1999 09:22:48 +0000 (GMT) From: Doug Rabson To: Terry Lambert Cc: dillon@apollo.backplane.com, freebsd-hackers@freebsd.org Subject: Re: Panic in FFS/4.0 as of yesterday In-Reply-To: <199902220534.WAA01171@usr07.primenet.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, 22 Feb 1999, Terry Lambert wrote: > > > > I think promoting directory writes (and directory reads probably) might be > > > > the simplest solution. > > > > > > OK, here's code to add the ability to expedite placement of async > > > writes. It' doesn't insert them in order behind other expedited > > > writes, so it turns the expedited stuff LIFO. This is probably > > > suboptimal, but can't happen in dependent operations, so what the > > > heck... > > > > > > When you use the code, be sure to *not* set the flag if soft updates > > > are in effect (I think that's a caller issue, not a callee issue, since > > > it would complicate the bdwrite code, probably unacceptably. > > > > I don't think this will do the job at all. The buffers in question are > > not delayed writes, so all this patch will do is change the order of the > > LOCKED and LRU lists, probably pessimising the reuse of those buffers. > > Check the code paths and look for B_ASYNC getting unset. I believe this > is the correct patch. As I said before, the reads and writes in question are not delayed writes. The reason I have a problem is that the i/o queue in the driver has grown to an obscene length, increasing latency to unreasonable levels. Changing the order of processing delayed writes is irrelavent to this problem. > > > I think the flag needs to be implemented in the driver. The driver should > > check for the EXPEDITE flag and either maintain two queues for the two > > possible priorities or place the buffer at the front of a single work > > queue. > > This has some serious flaws. > > The first is, you have to get it right in more than one driver. This > is really like the "wakeup" character change I did to the serial > drivers to allow for unanticipated "hotchar" in binary only drivers > from third parties, like E.T. Inc.. The driver changes would be small and the code can be arranged so that a a driver doesn't have to change at all to keep functioning, just to improve perceived performance. > > The second is that the lock cascade occurs because of locked vnodes > over an operation queued through this code, and only completion > notification will get rid of the lock. > > The third is that, however you do it, it needs to be harmless to > disk integrity in the soft updates and standard mount cases. The > standard mount case comes for free, by not using the B_ASYNC flag; > but the soft updates case is harder. You won't be able to add an > assert check at the queue-to-driver level to make sure the code is > right, since the buffer is no longer associated with the structure > that contains the soft dependency active/inactive information. > > Look at the cases where the I/O call is actually made in the UFS code, > and trace the function calls down. I'm willing to be wrong. I've been looking at the UFS code all day, trying to make it set B_EXPEDITE for all reads and writes for directories with only limited success. I no longer think this is the correct solution and I am starting to try a priority based scheme which uses a number similar to p->p_estcpu to identify processes which are performing large amounts of i/o and to penalise them by placing their subsequent i/o requests behind processes with a lower i/o priority. -- 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 Mon Feb 22 1:30: 6 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 EA41810F58 for ; Mon, 22 Feb 1999 01:30:03 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA57532; Mon, 22 Feb 1999 09:28:42 GMT (envelope-from dfr@nlsystems.com) Date: Mon, 22 Feb 1999 09:28:42 +0000 (GMT) From: Doug Rabson To: Luoqi Chen Cc: mjacob@feral.com, freebsd-hackers@freebsd.org Subject: Re: Panic in FFS/4.0 as of yesterday - update In-Reply-To: <199902220442.XAA14152@lor.watermarkgroup.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, 21 Feb 1999, Luoqi Chen wrote: > > > What troubled me here is why these supposedly async writes block (and ccd > > > is not involved)? I'd really like to see a dump of ps listing from ddb. > > > The async writes blocked on "nfsrcvlk". It looked like the test program > writeit was trying to clean some dirty nfs bufs. This situation shouldn't > be fatal as it is impossible to avoid blocking during async writes, getnewbuf > should simply return a NULL. The following patch should do the trick. Its certainly better than panicing but I'm still not happy about the recursion check (which is really just a reentrancy check since no recursion is actually happening). -- 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 Mon Feb 22 1:32:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id EE1BF119E8 for ; Mon, 22 Feb 1999 01:32:31 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id BAA29386; Mon, 22 Feb 1999 01:32:25 -0800 (PST) (envelope-from dillon) Date: Mon, 22 Feb 1999 01:32:25 -0800 (PST) From: Matthew Dillon Message-Id: <199902220932.BAA29386@apollo.backplane.com> To: Doug Rabson Cc: Terry Lambert , freebsd-hackers@freebsd.org Subject: Re: Panic in FFS/4.0 as of yesterday References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I don't think B_EXPIDITE could ever be made to work well. Why not limit the number of async I/O write operations allowed to be in-progress at any given moment for ops run by the syncer, swapper, or flushdirtybufs?. Either on a vnode-by-vnode or a mount-by-mount basis? I do a poor-man's version of this for the swapper. At least then the hacks would be concentrated together rather then strewn all over the codebase. The write queueing problem seems to be quite general in nature, which means that the solution should not be to have to hack each and every device that might do I/O ( aka UFS in this case ). -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 Feb 22 2:11: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bamboo.verinet.com (bamboo.verinet.com [204.144.246.5]) by hub.freebsd.org (Postfix) with ESMTP id 348E410EA0 for ; Mon, 22 Feb 1999 02:11:01 -0800 (PST) (envelope-from allenc@verinet.com) Received: from struct. (allenc.verinet.com [199.45.180.181]) by bamboo.verinet.com (8.8.8/8.7.1) with ESMTP id DAA26184 for ; Mon, 22 Feb 1999 03:11:00 -0700 Received: from verinet.com (struct. [192.168.1.3]) by struct. (8.8.8/8.8.8) with ESMTP id DAA01620 for ; Mon, 22 Feb 1999 03:10:57 -0700 (MST) (envelope-from allenc@verinet.com) Message-ID: <36D12D31.1C649D7F@verinet.com> Date: Mon, 22 Feb 1999 03:10:57 -0700 From: Allen Campbell X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.7-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: Privileged port problems Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG My ISP appears to be filtering outgoing packets for privileged source port numbers. This is preventing me from accessing anoncvs.freebsd.org; the CVS client attempts to authenticate to anoncvs.freebsd.org using a privileged source port (via rsh) and the operation times out. I also observe that rpcinfo as a non-privileged user works correctly, but fails as root because it then attempts to use a privileged source port. I'm fairly certain I will have no luck convincing my ISP to allow these connections. No doubt they will claim it prevents their customers from using their system to attack other hosts. I am able to access the Mozilla anonymous CVS server successfully because they are using :pserver: authentication which uses no reserved port to authenticate. Would it be possible to provide :pserver: anonymous CVS authentication to anoncvs.freebsd.org? Disclaimer: If I have made some hopeless mistake in my analysis of this please forgive me. I don't claim some network guru status; I'm just trying to figure this out. Thanks -- Allen Campbell | Lurking at the bottom of the allenc@verinet.com | gravity well, getting old. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 2:51:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rah.star-gate.com (rah.star-gate.com [209.249.129.138]) by hub.freebsd.org (Postfix) with ESMTP id 8FEC110E6A for ; Mon, 22 Feb 1999 02:51:50 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.1/8.8.8) with ESMTP id CAA56071; Mon, 22 Feb 1999 02:50:44 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199902221050.CAA56071@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Alex Zepeda Cc: hackers@FreeBSD.ORG Subject: egcs and EF 8) was (Re: gcc 2.8.1 Exceptions? ) In-reply-to: Your message of "Mon, 22 Feb 1999 01:10:27 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Feb 1999 02:50:44 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, With my latest little hacks I managed to get "EF" compiled with egcs from the ports distribution: egcs-2.91.60 Not bad 8) time ./sajava -nosys -classpath $CLASSPATH Test 0.348u 0.038s 0:00.39 94.8% 44+1195k 0+0io 0pf+0w time /maxtor/jdk116.src/javasrc/build/bin/java Test 7.594u 0.074s 0:07.85 97.5% 6+786k 0+0io 0pf+0w public class Test { public static void main (String args[]) { int j = 0; for (int i = 0; i < 10000000; i++) { j += 1;^ }^ }^ }^ The port is still not complete. I am having other problems now and I think it is due to floating point exceptions: The same program with a Hello printf and compiling on the fly the supporting java classes by taking out the "-nosys" option: time ./sajava -classpath $CLASSPATH Test linker_path = /maxtor/gcsns/ef/mozilla/dist/FreeBSD3.0_EMU_DBG.OBJ/lib:/maxtor/ gcsns/ef/mozilla/ef/dist/FreeBSD3.0_x86_DBG.OBJ/bin:/root:/usr/local/netscape/l ib/freebsd Netscape_Java_java_lang_Thread_registerNatives not implemented Netscape_Java_java_security_AccessController_getStackAccessControlContext not implemented Hello 6.701u 0.187s 0:07.14 96.3% 42+15657k 0+0io 0pf+0w The respective jdk run : {hasty} time /maxtor/jdk116.src/javasrc/build/bin/java Test 7.596u 0.101s 0:07.84 98.0% 6+781k 0+0io 0pf+0w So it is about the same as the jdk :( During the compilation phase EF's gets a little confused due to the treatment of NaN in our enviroment . I will track down the problem later on this week ... Cheers, Amancio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 3: 8:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rucus.ru.ac.za (rucus.ru.ac.za [146.231.29.2]) by hub.freebsd.org (Postfix) with SMTP id 4A7DC10E6A for ; Mon, 22 Feb 1999 03:07:44 -0800 (PST) (envelope-from geoff@rucus.ru.ac.za) Received: (qmail 28157 invoked by uid 268); 22 Feb 1999 13:07:44 -0000 Message-ID: <19990222130744.28156.qmail@rucus.ru.ac.za> Subject: Re: Star Office 5 woes In-Reply-To: from Doug Rabson at "Feb 22, 1999 9:14:39 am" To: dfr@nlsystems.com (Doug Rabson) Date: Mon, 22 Feb 1999 13:07:44 +0000 (GMT) Cc: hackers@freebsd.org Reply-To: "Geoff Rehmet" From: "Geoff Rehmet" 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 Doug Rabson writes : > Download the new version from the same place you got so50. The > registration process has been streamlined and doesn't seem to involve > basic at all (its managed by the installer). Registration problems aside (I'm busy downloading the new version), I noticed, from my log files, that so50 is using the sched_yield syscall. It appears to be a good idea to compile your kernel with: options "P1003_1B" options "_KPOSIX_PRIORITY_SCHEDULING" options "_KPOSIX_VERSION=199309L" (I don't know if anyone mentioned that explicitly.) Otherwise, watch syslogd go beserk - vrey noticeable on a P133 :-) Geoff. -- Geoff Rehmet, The Internet Solution geoffr@is.co.za; geoff@rucus.ru.ac.za; csgr@freebsd.org tel: +27-83-292-5800 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 4: 1:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dfw-ix4.ix.netcom.com (dfw-ix4.ix.netcom.com [206.214.98.4]) by hub.freebsd.org (Postfix) with ESMTP id 8FC8210F49 for ; Mon, 22 Feb 1999 04:01:25 -0800 (PST) (envelope-from asami@stampede.cs.berkeley.edu) Received: (from smap@localhost) by dfw-ix4.ix.netcom.com (8.8.4/8.8.4) id GAA11175 for ; Mon, 22 Feb 1999 06:01:19 -0600 (CST) Received: from sji-ca44-119.ix.netcom.com(209.111.212.247) by dfw-ix4.ix.netcom.com via smap (V1.3) id rma011145; Mon Feb 22 06:01:09 1999 Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.2/8.6.9) id DAA25746; Mon, 22 Feb 1999 03:59:07 -0800 (PST) Date: Mon, 22 Feb 1999 03:59:07 -0800 (PST) Message-Id: <199902221159.DAA25746@silvia.hip.berkeley.edu> To: hackers@freebsd.org Subject: http://advisor.gartner.com/n_inbox/hotcontent/hc_2121999_3.html From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG He's comparing pretty old versions (FreeBSD-2.2.6 vs. Linux kernel 2.0.34) but the method should be valid since he contends "FreeBSD Provides the Best of Both Worlds". :) Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 4: 9:20 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 0DF1410EB0 for ; Mon, 22 Feb 1999 04:09:15 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id VAA08835; Mon, 22 Feb 1999 21:08:09 +0900 (JST) Message-ID: <36D142EB.416F0489@newsguy.com> Date: Mon, 22 Feb 1999 20:43:39 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Ruslan Ermilov Cc: FreeBSD Hackers Subject: Re: Hackers! Any comments on bin/9963? References: <19990222104807.A63652@ucb.crimea.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ruslan Ermilov wrote: > > Dear Hackers! > > Could someone who has commitright take a look at bin/9963? Bug wollman. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "To make it absolutely clear: you stand on the wrong end of my blasters, so you better get lost before I start target practice!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 4:19:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.ucb.crimea.ua (relay.ucb.crimea.ua [212.110.138.1]) by hub.freebsd.org (Postfix) with ESMTP id 5533510F07; Mon, 22 Feb 1999 04:18:48 -0800 (PST) (envelope-from ru@ucb.crimea.ua) Received: (from ru@localhost) by relay.ucb.crimea.ua (8.9.2/8.9.2/UCB) id OAA12578; Mon, 22 Feb 1999 14:17:40 +0200 (EET) (envelope-from ru) Date: Mon, 22 Feb 1999 14:17:39 +0200 From: Ruslan Ermilov To: "Daniel C. Sobral" Cc: wollman@freebsd.org, hackers@freebsd.org Subject: Re: Hackers! Any comments on bin/9963? Message-ID: <19990222141739.A11675@ucb.crimea.ua> Mail-Followup-To: "Daniel C. Sobral" , wollman@freebsd.org, hackers@FreeBSD.ORG References: <19990222104807.A63652@ucb.crimea.ua> <36D142EB.416F0489@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.17i In-Reply-To: <36D142EB.416F0489@newsguy.com>; from Daniel C. Sobral on Mon, Feb 22, 1999 at 08:43:39PM +0900 X-Operating-System: FreeBSD 3.1-STABLE i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 22, 1999 at 08:43:39PM +0900, Daniel C. Sobral wrote: > Ruslan Ermilov wrote: > > > > Dear Hackers! > > > > Could someone who has commitright take a look at bin/9963? > > Bug wollman. > I tried that first... He doesn't react. [attaching him to this thread] Cheers, -- Ruslan Ermilov Sysadmin and DBA of the ru@ucb.crimea.ua United Commercial Bank +380.652.247.647 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 5:40:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.tar.com (ns.tar.com [204.95.187.2]) by hub.freebsd.org (Postfix) with ESMTP id 446C811032 for ; Mon, 22 Feb 1999 05:40:27 -0800 (PST) (envelope-from dick@ns.tar.com) Received: (from dick@localhost) by ns.tar.com (8.9.3/8.9.3) id HAA80755; Mon, 22 Feb 1999 07:39:56 -0600 (CST) (envelope-from dick) Date: Mon, 22 Feb 1999 07:39:56 -0600 From: "Richard Seaman, Jr." To: Geoff Rehmet Cc: Doug Rabson , hackers@FreeBSD.ORG Subject: Re: Star Office 5 woes Message-ID: <19990222073956.A68736@tar.com> References: <19990222130744.28156.qmail@rucus.ru.ac.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <19990222130744.28156.qmail@rucus.ru.ac.za>; from Geoff Rehmet on Mon, Feb 22, 1999 at 01:07:44PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 22, 1999 at 01:07:44PM +0000, Geoff Rehmet wrote: > Doug Rabson writes : > > Download the new version from the same place you got so50. The > > registration process has been streamlined and doesn't seem to involve > > basic at all (its managed by the installer). > Registration problems aside (I'm busy downloading the new version), > I noticed, from my log files, that so50 is using the sched_yield > syscall. It appears to be a good idea to compile your kernel > with: > > options "P1003_1B" > options "_KPOSIX_PRIORITY_SCHEDULING" > options "_KPOSIX_VERSION=199309L" > > (I don't know if anyone mentioned that explicitly.) > Otherwise, watch syslogd go beserk - vrey noticeable on a P133 :-) Linux threads running under linux emu requires the above options in the kernel. Not only will syslogd "go beserk", the threads code won't work correctly, without it. This has been noted at http://lt.tar.com for several months now. There are also fixes that need to be made to the posix scheduling code. At one point it looked like the fixes would be committed, and the posix scheduling stuff made standard, before 3.1 was released. It didn't happen, though I understand it may happen in the next week or two. Peter Dufault has been working on it. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 5:42:49 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 34A0111AC1 for ; Mon, 22 Feb 1999 05:42:46 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id WAA27130; Mon, 22 Feb 1999 22:42:47 +0900 (JST) Message-ID: <36D15C80.BD0D14EE@newsguy.com> Date: Mon, 22 Feb 1999 22:32:48 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Satoshi Asami , hackers@freebsd.org Subject: Re: http://advisor.gartner.com/n_inbox/hotcontent/hc_2121999_3.html References: <199902221159.DAA25746@silvia.hip.berkeley.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Satoshi Asami wrote: > > He's comparing pretty old versions (FreeBSD-2.2.6 vs. Linux kernel > 2.0.34) but the method should be valid since he contends "FreeBSD > Provides the Best of Both Worlds". :) I think he is actually comparing FreeBSD-2.2.7. What the text says and what the graphic says differs. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "To make it absolutely clear: you stand on the wrong end of my blasters, so you better get lost before I start target practice!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 5:56:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [208.221.12.98]) by hub.freebsd.org (Postfix) with ESMTP id 1F24B10EB0 for ; Mon, 22 Feb 1999 05:56:13 -0800 (PST) (envelope-from root@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 FAA17708; Mon, 22 Feb 1999 05:53:19 -0800 (PST) Message-Id: <199902221353.FAA17708@implode.root.com> To: Bill Paul Cc: hackers@freebsd.org Subject: Re: How to handle jumbo etherney frames In-reply-to: Your message of "Mon, 22 Feb 1999 02:09:38 EST." <199902220709.CAA14944@skynet.ctr.columbia.edu> From: David Greenman Reply-To: dg@root.com Date: Mon, 22 Feb 1999 05:53:19 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> Whether to use a VLAN and/or which VLAN to use is a per destination thing, >> not a per host/interface thing, so I don't think a single VLAN would be >> very useful. > >Well, supposedly we have some vlan support code in /sys/net/if_vlan.c. >What are the odds of getting this to work with for this purpose? I think it's an almost orphaned child of Garrett's. You'll have to ask him about his plans for it. >> >I'm not really inclined to just implement only standard frame support >> >and wait around for large mbuf cluster support to materialize since there's >> >no telling how long that could take. I think I may be stuck between a >> >> Then implement large mbuf support. :-) > >That's not even remotely funny. > >All I want to do is write a device driver. That's enough work as it is. >You're the principal architect; _you_ implement large mbuf support. Wimp! :-) >> Using malloc for this is probably not a good idea since it wants to >> allocate power of two sizes, so you'd needlessly waste a whole page. This >> really needs a special allocator specifically designed to deal with the >> needs of large mbuf clusters. Again, I think using the external mbuf storage >> mechanism is the right way to glue this in. > >I'm not going to build a whole memory allocator/management subsystem into >this driver. Until something else comes along, malloc() will have to do. It should be external to the driver. I need to think about this some more. >> One other comment...when I was looking at this stuff I came to the >> conclusion that supporting the Tigon 1 was a waste of time since it appears >> to be obsolete. Support for just the Tigon 2 should simplify the driver. > >I disagree. The differences between the Tigon 1 and the Tigon 2 are not >that extensive. The Tigon 1 doesn't support the mini receive ring, there >are one or two commands that have changed, and you need to load a different >firmware image, but for the most part operation is the same. I'd much rather >be able to say that the driver supports both chip revs than save a few >lines of code. Okay...sounds fine to me. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 6:14:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [208.221.12.98]) by hub.freebsd.org (Postfix) with ESMTP id 4D37C10FE3 for ; Mon, 22 Feb 1999 06:14:23 -0800 (PST) (envelope-from root@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 GAA17798 for ; Mon, 22 Feb 1999 06:12:09 -0800 (PST) Message-Id: <199902221412.GAA17798@implode.root.com> To: hackers@freebsd.org Subject: Usenix OSDI conference From: David Greenman Reply-To: dg@root.com Date: Mon, 22 Feb 1999 06:12:09 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm leaving now for the OSDI (Operating Systems Design and Implementation) conference in New Orleans. I hope to meet as many FreeBSD developers as possible. See you there! -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 6:24: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 043E511EEF for ; Mon, 22 Feb 1999 06:24:06 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id GAA16299; Mon, 22 Feb 1999 06:23:32 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id GAA10558; Mon, 22 Feb 1999 06:23:30 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id GAA28922; Mon, 22 Feb 1999 06:23:29 -0800 (PST) From: Don Lewis Message-Id: <199902221423.GAA28922@salsa.gv.tsc.tdk.com> Date: Mon, 22 Feb 1999 06:23:29 -0800 In-Reply-To: Terry Lambert "Re: Panic in FFS/4.0 as of yesterday" (Feb 20, 10:42pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Terry Lambert , dillon@apollo.backplane.com (Matthew Dillon) Subject: Re: Panic in FFS/4.0 as of yesterday Cc: dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Feb 20, 10:42pm, Terry Lambert wrote: } Subject: Re: Panic in FFS/4.0 as of yesterday } I think the way to "fix" this is to have two queue insertion points, } and insert directory writes as far forward as you can (some pigs are } more equal than others). This would ensure short duration for } directory operations. What about directory reads? I think the same problem will occur if they have long latencies. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 6:26:48 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 9BE4811C75 for ; Mon, 22 Feb 1999 06:25:59 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id JAA17234; Mon, 22 Feb 1999 09:25:42 -0500 (EST) (envelope-from luoqi) Date: Mon, 22 Feb 1999 09:25:42 -0500 (EST) From: Luoqi Chen Message-Id: <199902221425.JAA17234@lor.watermarkgroup.com> To: dfr@nlsystems.com Subject: Re: Panic in FFS/4.0 as of yesterday - update Cc: freebsd-hackers@freebsd.org, mjacob@feral.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Its certainly better than panicing but I'm still not happy about the > recursion check (which is really just a reentrancy check since no > recursion is actually happening). > > -- > Doug Rabson Mail: dfr@nlsystems.com > Nonlinear Systems Ltd. Phone: +44 181 442 9037 > I agree. A per-process recursion count is the way to go. -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 6:29:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id B38281102F for ; Mon, 22 Feb 1999 06:29:21 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id GAA16373; Mon, 22 Feb 1999 06:28:59 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id GAA10579; Mon, 22 Feb 1999 06:28:58 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id GAA28942; Mon, 22 Feb 1999 06:28:57 -0800 (PST) From: Don Lewis Message-Id: <199902221428.GAA28942@salsa.gv.tsc.tdk.com> Date: Mon, 22 Feb 1999 06:28:56 -0800 In-Reply-To: Terry Lambert "Re: Panic in FFS/4.0 as of yesterday" (Feb 20, 10:52pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Terry Lambert , dfr@nlsystems.com (Doug Rabson) Subject: Re: Panic in FFS/4.0 as of yesterday Cc: dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Feb 20, 10:52pm, Terry Lambert wrote: } Subject: Re: Panic in FFS/4.0 as of yesterday } > If it works, then changing lookup to not require locks on both vnodes at } > the same time would be a good thing. One of the reasons that NFS doesn't } > have proper node locks is that a dead NFS server can lead to a hung } > machine though a lock cascade from the NFS mount point. I suggested doing something like this, but only at mount points, which should be sufficient to fix the NFS problem. The only race conditions that would open would be for things you probably don't want to do at mountpoints anyway. } The correct way to do this, IMO, is a back-off/retry, which would } unlock the lock and queue the operation for retry, which would } reacquire the lock. Wouldn't you have to relock the parent before unlocking the lock (nasty because it reverses the locking order and might cause a deadlock). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 7:15: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from paul.rutgers.edu (paul.rutgers.edu [128.6.5.53]) by hub.freebsd.org (Postfix) with ESMTP id 8BDA111FA6 for ; Mon, 22 Feb 1999 07:14:40 -0800 (PST) (envelope-from talukdar@paul.rutgers.edu) Received: (from talukdar@localhost) by paul.rutgers.edu (8.8.8/8.8.8) id KAA08685; Mon, 22 Feb 1999 10:14:42 -0500 (EST) Date: Mon, 22 Feb 1999 10:14:42 -0500 (EST) From: Anup Talukdar Message-Id: <199902221514.KAA08685@paul.rutgers.edu> To: freebsd-hackers@freebsd.org Subject: cannot configure soundcard Cc: talukdar@paul.rutgers.edu Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I am trying to use the soundcard in my laptop. I have the following setup : Dell Latitude XPi P133ST laptop with the following audio specifications : Audio type : Soundblaster Pro-compatible 3.01 Audio controller : ES1888 According to the Dell reference guide, the default resource settings are : DMA channel : 1 IRQ line : 5 Port address : 220h In the Kernel configuration file I have included the following lines : controller snd0 device sb0 at isa? port 0x220 irq 5 drq 1 vector sbintr device sbxvi0 at isa? drq 5 device sbmidi0 at isa? port 0x300 After making and installing the new kernel, I get the following messages when rebooting the machine : sb0 not found at 0x220 sbxvi0 not found sbmidi0 not found at 0x300 I am trying to use VAT (audio tool from LBL) and it complains that , soundcard is not configured. It will be of great help if anyone can inform what I am doing wrong here and what I should do to correct the problem. Since I don't subscribe to this mailing list, I will appreciate if the responses are sent directly to my e-mail address : talukdar@paul.rutgers.edu Thank you, Regards, Anup To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 7:25:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from carp.gbr.epa.gov (carp.gbr.epa.gov [204.46.159.110]) by hub.freebsd.org (Postfix) with ESMTP id B5B3610EA2; Mon, 22 Feb 1999 07:25:51 -0800 (PST) (envelope-from mjenkins@carp.gbr.epa.gov) Received: (from mjenkins@localhost) by carp.gbr.epa.gov (8.8.8/8.8.8) id JAA24778; Mon, 22 Feb 1999 09:25:34 -0600 (CST) (envelope-from mjenkins) Date: Mon, 22 Feb 1999 09:25:34 -0600 (CST) From: Mike Jenkins Message-Id: <199902221525.JAA24778@carp.gbr.epa.gov> To: sthaug@nethelp.no Subject: Re: New breakin technique? Cc: FreeBSD-isp@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <21255.919585588@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > So why are rpc.statd and portmap started by default in FreeBSD? I believe that rc.conf is created at install time so depending on what options you pick various things gets turned on or off. > (I've been turning them off since I started using FreeBSD. Now, with the > /etc/defaults/rc.conf mechanism, it's real easy to keep my local mods :-) On FreeBSD 2.2.x systems, rc.conf reads in rc.conf.local at the end, so I've always put local mods in rc.conf.local: # /etc/rc.conf (at the end) ############################################################## ### Allow local configuration override at the very end here ## ############################################################## if [ -f /etc/rc.conf.local ]; then . /etc/rc.conf.local fi # /etc/rc.conf.local sendmail_enable="YES" # Run the sendmail daemon (or NO). sendmail_flags="-q30m" # queue-mode only (running smtpd) Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 7:58:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tornado.cisco.com (tornado.cisco.com [171.69.104.22]) by hub.freebsd.org (Postfix) with ESMTP id 4DD3D10E64 for ; Mon, 22 Feb 1999 07:57:51 -0800 (PST) (envelope-from bmcgover@bmcgover-pc.cisco.com) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147]) by tornado.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA26492 for ; Mon, 22 Feb 1999 10:57:50 -0500 (EST) Received: from bmcgover-pc.cisco.com (localhost.pa.dtd.cisco.com [127.0.0.1]) by bmcgover-pc.cisco.com (8.9.1/8.9.1) with ESMTP id KAA10051 for ; Mon, 22 Feb 1999 10:57:51 -0500 (EST) (envelope-from bmcgover@bmcgover-pc.cisco.com) Message-Id: <199902221557.KAA10051@bmcgover-pc.cisco.com> To: hackers@freebsd.org Subject: HOW TO QUESTION: 'Flagging' characters in t_outq.... Date: Mon, 22 Feb 1999 10:57:51 -0500 From: Brian McGovern Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have just finished a line discipline that does packet framing. I tried using the upper bits on the int to do start and end of packet framing, following the lead of the input side (for things like parity errors, etc). However, it appears that only the TTY_QUOTE bit seems to get passed (having looked at the code). I'd really like to know if/why the other bits get stripped, and if there is a way around this, so I can get the full number of bits passed down..... Comments? -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 8:17:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cerebus.nectar.com (nectar-gw.nectar.com [204.0.249.101]) by hub.freebsd.org (Postfix) with ESMTP id C333B116ED for ; Mon, 22 Feb 1999 08:17:14 -0800 (PST) (envelope-from nectar@nectar.com) Received: (from smap@localhost) by cerebus.nectar.com (8.9.1/8.9.1) id KAA20766; Mon, 22 Feb 1999 10:17:13 -0600 (CST) (envelope-from nectar@nectar.com) Received: from spawn.nectar.com(10.0.0.101) by cerebus.nectar.com via smap (V2.1) id xma020761; Mon, 22 Feb 99 10:17:03 -0600 Received: from spawn.nectar.com (localhost [127.0.0.1]) by spawn.nectar.com (8.9.3/8.9.1) with ESMTP id KAA67943; Mon, 22 Feb 1999 10:17:03 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Message-Id: <199902221617.KAA67943@spawn.nectar.com> X-Mailer: exmh version 2.0.2 2/24/98 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: lists/freebsd X-PGP-RSAfprint: 00 F9 E6 A2 C5 4D 0A 76 26 8B 8B 57 73 D0 DE EE X-PGP-RSAkey: http://www.nectar.com/nectar-pgp262.txt From: Jacques Vidrine In-reply-to: <36D12D31.1C649D7F@verinet.com> References: <36D12D31.1C649D7F@verinet.com> Subject: Re: Privileged port problems Mime-Version: 1.0 Content-Type: text/plain To: Allen Campbell Cc: hackers@FreeBSD.ORG Date: Mon, 22 Feb 1999 10:17:03 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22 February 1999 at 3:10, Allen Campbell wrote: > My ISP appears to be filtering outgoing packets for privileged > source port numbers. This is preventing me from accessing > anoncvs.freebsd.org; the CVS client attempts to authenticate to > anoncvs.freebsd.org using a privileged source port (via rsh) and the > operation times out. I also observe that rpcinfo as a > non-privileged user works correctly, but fails as root because it > then attempts to use a privileged source port. > > I'm fairly certain I will have no luck convincing my ISP to allow > these connections. No doubt they will claim it prevents their > customers from using their system to attack other hosts. Bah! Complain and, if necessary, switch ISPs. You are paying your ISP to route transport IP traffic. By filtering your legitimate IP packets, they are not living up to their part of the bargain. Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 8:31:41 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 2BAE510FB2 for ; Mon, 22 Feb 1999 08:31:35 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id IAA16271; Mon, 22 Feb 1999 08:31:06 -0800 Date: Mon, 22 Feb 1999 08:31:05 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Doug Rabson Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday 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 > > > > Check the code paths and look for B_ASYNC getting unset. I believe this > > is the correct patch. > > As I said before, the reads and writes in question are not delayed writes. > The reason I have a problem is that the i/o queue in the driver has grown > to an obscene length, increasing latency to unreasonable levels. Changing > the order of processing delayed writes is irrelavent to this problem. This isn't a new problem. When I did driver level clustering at Sun back in 1990, I was regularly seeing queue lengths in excess of 1000 for a 16MB memory Sparc2. > > > > > > I think the flag needs to be implemented in the driver. The driver should > > > check for the EXPEDITE flag and either maintain two queues for the two > > > possible priorities or place the buffer at the front of a single work > > > queue. > > > > This has some serious flaws. > > > > The first is, you have to get it right in more than one driver. This > > is really like the "wakeup" character change I did to the serial > > drivers to allow for unanticipated "hotchar" in binary only drivers > > from third parties, like E.T. Inc.. > > The driver changes would be small and the code can be arranged so that a > a driver doesn't have to change at all to keep functioning, just to > improve perceived performance. I think this would be a very good idea. This is exactly the kind of thing that HEAD OF QUEUE tags are designed for. I agree with Doug that this is not a requirement for continuing to run- just an improvement. And if you think about it, it's really only two drivers (scsi_da, wd). > > I've been looking at the UFS code all day, trying to make it set > B_EXPEDITE for all reads and writes for directories with only limited > success. > > I no longer think this is the correct solution and I am starting to try a > priority based scheme which uses a number similar to p->p_estcpu to > identify processes which are performing large amounts of i/o and to > penalise them by placing their subsequent i/o requests behind processes > with a lower i/o priority. > The only problem with this approach is not all I/O is or will be driven by a process. Let's say we port a new filesystem in that creates a *lot* of I/O via threads or wads of async r/w. Unless you start doing thread scheduling it's hard to figure out whome to penalize. I still would like to see a B_EXPEDITE (although B_PRIORITY seems a better name). Should we also be paying attention to B_ORDERED and should you consider doing buffer generations? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 9:41:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gras-varg.worldgate.com (gras-varg.worldgate.com [198.161.84.12]) by hub.freebsd.org (Postfix) with ESMTP id 247C810F82 for ; Mon, 22 Feb 1999 09:41:18 -0800 (PST) (envelope-from skafte@gras-varg.worldgate.com) Received: (from skafte@localhost) by gras-varg.worldgate.com (8.9.1a/8.9.1) id KAA16575 for freebsd-hackers@FreeBSD.ORG; Mon, 22 Feb 1999 10:41:18 -0700 (MST) Date: Mon, 22 Feb 1999 10:41:17 -0700 From: Greg Skafte To: freebsd-hackers@FreeBSD.ORG Subject: Re: kde Message-ID: <19990222104117.B16459@gras-varg.worldgate.com> References: <19990221211210.A12674@gras-varg.worldgate.com> <199902220834.AAA18057@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199902220834.AAA18057@rah.star-gate.com>; from Amancio Hasty on Mon, Feb 22, 1999 at 12:34:04AM -0800 Organization: WorldGate Inc. X-PGP-Fingerprint: 42 9C 2C A8 4D 2B C9 C4 7D B6 00 B0 50 47 20 97 X-URL: http://gras-varg.worldgate.com/~skafte Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG we were using 800x600 24bit on a 2Meg card we dropped that to 800x600x16bit we are now trying a differnet S3V card .... We are suspecting its the card but when a card is CAD$30 we had to give it a try..... Quoting Amancio Hasty (hasty@rah.star-gate.com) On Subject: Re: kde Date: Mon, Feb 22, 1999 at 12:34:04AM -0800 > Sounds like an Xserver or harware problem . Whats your card and the color depth > that you are running with X server with? > > Amancio > -- Email: skafte@worldgate.com Voice: +403 413 1910 Fax: +403 421 4929 #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 -- -- When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex. (Janet Morris) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 11: 5:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay2.mail.uk.psi.net (relay2.mail.uk.psi.net [154.32.107.6]) by hub.freebsd.org (Postfix) with ESMTP id 6233711DC0 for ; Mon, 22 Feb 1999 11:04:43 -0800 (PST) (envelope-from amobbs@allstor-sw.co.uk) Received: from mail.plasmon.co.uk ([193.115.5.217]) by relay2.mail.uk.psi.net with smtp (Exim 2.02 #3) id 10F0en-0004sY-00 for freebsd-hackers@freebsd.org; Mon, 22 Feb 1999 19:04:42 +0000 Received: by mail.plasmon.co.uk(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 80256720.00688A1A ; Mon, 22 Feb 1999 19:01:50 +0000 X-Lotus-FromDomain: PLASNOTES From: amobbs@allstor-sw.co.uk To: freebsd-hackers@freebsd.org Message-ID: <80256720.006889BA.00@mail.plasmon.co.uk> Date: Mon, 22 Feb 1999 19:01:49 +0000 Subject: CAM open errors 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 Is there a reson (such as meeting spec.) that cam_open_btl et. al. don't return an error code, but just stick a string in cam_errbuf? I'm using an application which uses the CAM passthrough drivers, and basically tries to grab everything on a given bus, and I'd like to be able to distinguish a genuine failure from simply one caused by the device not being there. I've looked at camcontrol.c, and it doesn't deal with this, it simply prints the cam_errbuf and exits. I could always just hack camlib to do what I want, but if there's a better, or more standard solution I'd prefer that. Andrew. -- Andrew Mobbs - Software Engineer - Allstor Software Ltd. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 11:14:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (s205m7.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id B3D3811607 for ; Mon, 22 Feb 1999 11:14:17 -0800 (PST) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id LAA76945; Mon, 22 Feb 1999 11:12:05 -0800 (PST) From: Archie Cobbs Message-Id: <199902221912.LAA76945@bubba.whistle.com> Subject: Re: Interesting ld.so bug In-Reply-To: <199902202154.OAA18160@usr08.primenet.com> from Terry Lambert at "Feb 20, 99 09:54:19 pm" To: terry@whistle.com (Terry Lambert) Date: Mon, 22 Feb 1999 11:12:05 -0800 (PST) Cc: jdp@polstra.com, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (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 Terry Lambert writes: > There appears to be a bug with ld.so. The following steps illustrate > the bug: After some further playing around, it seems like it may be a linker problem, or a least a problem in the way we're using it. Here's my test case that reproduces the problem: We compile a shared library "libfoo" containing these source files: bar.c - Containing functions bar1() and bar2(), which are both exported. Function bar1() calls function bar2(). java_jni.c - Java JNI method to interface to function bar1(), call it Java_bar1(). db.c - Other exported routines. The C code in this file uses GDBM routines. NOTE: GDBM routines live in a static library, /usr/local/lib/libgdbm.a. Now when we run a java class that uses the java_jni.c native method, the call to Java_bar1() succeeds, and the call from there to bar1() succeeds, but when bar1() tries to call bar2(), it jumps to a very low address and segfaults. It seems that the bar2() trampoline is using an uninitialized base address or whatever. NOW, if we remove "db.c" from the compilation of "libfoo.so", then everything works! Any ideas about what is going on here? Thanks, -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 Mon Feb 22 11:32:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axe.cablenet.net (axe.cablenet.net [195.248.96.20]) by hub.freebsd.org (Postfix) with ESMTP id 2677411DE3 for ; Mon, 22 Feb 1999 11:32:15 -0800 (PST) (envelope-from damian@cablenet.net) Received: from cablenet.net (localhost [127.0.0.1]) by axe.cablenet.net (8.9.0.Beta3/8.9.0.Beta3) with ESMTP id TAA15812; Mon, 22 Feb 1999 19:27:59 GMT Message-ID: <36D1AFBF.58BCFFEF@cablenet.net> Date: Mon, 22 Feb 1999 19:27:59 +0000 From: Damian Hamill Organization: CableNet Ltd X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 4.1.4 sun4m) MIME-Version: 1.0 To: Terry Lambert , hackers@freebsd.org Subject: Re: Interesting ld.so bug References: <199902202154.OAA18160@usr08.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > There appears to be a bug with ld.so. The following steps illustrate > the bug: > I've recently installed version 3 on a system and upgraded to 3.1 and noticed dynamic loading strangeness too. The Apache port won't load dynamic modules as it can't resolve some of the undefined symbols from the module being loaded which are contained in the loading process, ap_make_sub_pool for example. Using dlsym(NULL,"symbol_name") in one of my own dynamically loaded modules fails to find "symbol_name" in the loading process, contrary to the man page and previous behaviour. Similarly I find that I now don't need a leading underscore before the symbol name to resolve symbols in the module being loaded from the loading process, again contrary to the man page and previous behaviour. Is this all part of the transition to elf ? Do I need to add -elf to CFLAGS ? regards damian -- * Damian Hamill M.D. damian@cablenet.net * CableNet & The Landscape Channel * http://www.cablenet.net/ http://www.landscapetv.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 11:56: 0 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 351E21107E for ; Mon, 22 Feb 1999 11:55:08 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA16414; Mon, 22 Feb 1999 11:46:50 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdO16408; Mon Feb 22 19:46:40 1999 Date: Mon, 22 Feb 1999 11:46:33 -0800 (PST) From: Julian Elischer To: Don Lewis Cc: Terry Lambert , Matthew Dillon , dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday In-Reply-To: <199902221423.GAA28922@salsa.gv.tsc.tdk.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 softupdates already "kinda" doesn this.. it queues data writes at one point in the future and directory writes at a different point in the future. I believe that data writes must be completed before inode writes which must be completed before directory writes. If they are not the the dependencies will FORCE that ordering. The reason to preschedule the different actions is to make it all happen in the right order anyhow, so that the dependency tracking is a big NOP. On Mon, 22 Feb 1999, Don Lewis wrote: > On Feb 20, 10:42pm, Terry Lambert wrote: > } Subject: Re: Panic in FFS/4.0 as of yesterday > > } I think the way to "fix" this is to have two queue insertion points, > } and insert directory writes as far forward as you can (some pigs are > } more equal than others). This would ensure short duration for > } directory operations. > > What about directory reads? I think the same problem will occur if > they have long latencies. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 12:24:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from shibumi.feralmonkey.org (shibumi.feralmonkey.org [203.41.114.182]) by hub.freebsd.org (Postfix) with ESMTP id BA5D911256 for ; Mon, 22 Feb 1999 12:24:54 -0800 (PST) (envelope-from nick@FERALMONKEY.ORG) Received: from shibumi (shibumi [203.41.114.182]) by shibumi.feralmonkey.org (Postfix) with ESMTP id 4FC95780B; Tue, 23 Feb 1999 07:29:53 +1100 (EST) Date: Tue, 23 Feb 1999 07:29:52 +1100 (EST) From: To: Anup Talukdar Cc: freebsd-hackers@freebsd.org Subject: Re: cannot configure soundcard In-Reply-To: <199902221514.KAA08685@paul.rutgers.edu> 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 noticed a similiar problem on my Acer Extensa notebook. It's running 2.2.8-RELEASE+PAO, and has a sound blaster-compatible clone. For some bizarre reason it occasionally detects the soundcard, but other times it doesn't. I have a sneaking suspicion that it works if I boot into FreeBSD after restarting from NT but not if I boot straight into FreeBSD. Nick -- "We all agree that your theory is crazy, but is it crazy enough?" - Niels Bohr (1885 - 1962) On Mon, 22 Feb 1999, Anup Talukdar wrote: > > Hi, > > I am trying to use the soundcard in my laptop. I have the > following setup : > > > Dell Latitude XPi P133ST laptop with the following > audio specifications : > > Audio type : Soundblaster Pro-compatible 3.01 > Audio controller : ES1888 > > According to the Dell reference guide, the default > resource settings are : > > DMA channel : 1 > IRQ line : 5 > Port address : 220h > > In the Kernel configuration file I have included the following > lines : > > controller snd0 > > device sb0 at isa? port 0x220 irq 5 drq 1 vector sbintr > device sbxvi0 at isa? drq 5 > device sbmidi0 at isa? port 0x300 > > After making and installing the new kernel, I get the following messages > when rebooting the machine : > > sb0 not found at 0x220 > sbxvi0 not found > sbmidi0 not found at 0x300 > > I am trying to use VAT (audio tool from LBL) and it complains that , > soundcard is not configured. > > It will be of great help if anyone can inform what I am doing wrong here > and what I should do to correct the problem. > > Since I don't subscribe to this mailing list, I will appreciate > if the responses are sent directly to my e-mail address : > > talukdar@paul.rutgers.edu > > Thank you, > Regards, > Anup > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 13:15:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id A11071105B for ; Mon, 22 Feb 1999 13:15:44 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.2/8.8.5) id OAA28164; Mon, 22 Feb 1999 14:15:40 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199902222115.OAA28164@panzer.plutotech.com> Subject: Re: CAM open errors In-Reply-To: <80256720.006889BA.00@mail.plasmon.co.uk> from "amobbs@allstor-sw.co.uk" at "Feb 22, 1999 7: 1:49 pm" To: amobbs@allstor-sw.co.uk Date: Mon, 22 Feb 1999 14:15:40 -0700 (MST) Cc: freebsd-hackers@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 amobbs@allstor-sw.co.uk wrote... > > Is there a reson (such as meeting spec.) that cam_open_btl et. al. don't > return an error code, but just stick a string in cam_errbuf? The system error codes aren't entirely descriptive, and that's just the way I wrote it. :) > I'm using an application which uses the CAM passthrough drivers, and > basically tries to grab everything on a given bus, and I'd like to be able > to distinguish a genuine failure from simply one caused by the device not > being there. > > I've looked at camcontrol.c, and it doesn't deal with this, it simply > prints the cam_errbuf and exits. Yep, it assumes the user knows which device he's talking about, and doesn't attempt to second guess him by searching around for another device. That could have potentially disastrous results if the user was trying to format da5 and ended up formatting da6 instead... > I could always just hack camlib to do what I want, but if there's a better, > or more standard solution I'd prefer that. It really would be easier if you just used the device matching code to grab everything on a given bus. It will tell you which devices are there, and you can even do things like list all of the 'da' devices on a particular bus. Look at the code for 'camcontrol devlist' in getdevtree() in camcontrol.c. You can pull out whatever devices you're looking for that way, so you don't have to go opening every bus, target and lun. cdrecord uses a similar approach for its '-scanbus' code, and I've got some more sample code that will match against various peripheral driver types. What is it that you're trying to do, anyway? BTW, it might be better to send SCSI-type queries to the freebsd-scsi list. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 13:28:40 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 SMTP id 0D63810F01 for ; Mon, 22 Feb 1999 13:28:33 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 10F2ts-0005iE-00; Mon, 22 Feb 1999 14:28:24 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.2/8.8.3) with ESMTP id OAA15308; Mon, 22 Feb 1999 14:28:11 -0700 (MST) Message-Id: <199902222128.OAA15308@harmony.village.org> To: Vincent Fleming Subject: Re: cdrom.com bandwidth limits Cc: "'Dennis'" , "hackers@FreeBSD.ORG" In-reply-to: Your message of "Thu, 18 Feb 1999 16:02:52 EST." <01BE5B58.23FEBFA0@rembrandt> References: <01BE5B58.23FEBFA0@rembrandt> Date: Mon, 22 Feb 1999 14:28:11 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm usually bandwidth limited by the T1 that is my connection to the outside world, so I usually see 100-140kBps. This is about 1000-1400 kbps, which is near the max 1500 kbps a T1 supports. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 13:37:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 2AFF31111F for ; Mon, 22 Feb 1999 13:37:00 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id NAA10509; Mon, 22 Feb 1999 13:35:50 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id NAA24385; Mon, 22 Feb 1999 13:35:49 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id OAA19958; Mon, 22 Feb 1999 14:35:45 -0700 Message-ID: <36D1CDAF.3ACDE687@softweyr.com> Date: Mon, 22 Feb 1999 14:35:43 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: dg@root.com Cc: Bill Paul , hackers@FreeBSD.ORG Subject: Re: How to handle jumbo etherney frames References: <199902221353.FAA17708@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: > > >> >I'm not really inclined to just implement only standard frame support > >> >and wait around for large mbuf cluster support to materialize since there's > >> >no telling how long that could take. I think I may be stuck between a > >> > >> Then implement large mbuf support. :-) > > > >That's not even remotely funny. > > > >All I want to do is write a device driver. That's enough work as it is. > >You're the principal architect; _you_ implement large mbuf support. > > Wimp! :-) Go for it. It'll make you a hero with the Token Ring crowd, too. -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 13:42:20 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 230371129A for ; Mon, 22 Feb 1999 13:42:15 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40336>; Tue, 23 Feb 1999 08:31:18 +1100 Date: Tue, 23 Feb 1999 08:42:04 +1100 From: Peter Jeremy Subject: Re: Semaphore handling To: tlambert@primenet.com Cc: hackers@FreeBSD.ORG Message-Id: <99Feb23.083118est.40336@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: >> 3) Neither FreeBSD nor TOG not clearly define semadj behaviour. ... >Solaris and UnixWare are definitive. I'll try writing some code to check the behaviour on Solaris (I don't have access to UnixWare). >You may want to dig up a copy of the SVID III, if you can; I don't think I can manage this. I don't suppose anyone who has a copy would be willing to fax or mail me the semaphore-related section? >see semaphore.h on the CDROM, as well. Unfortunately, there doesn't appear to be anything other than the function prototypes in this header file. It seems that no-one's gotten around to implementing the functionality (and I'm not volunteering). >Another possibile authority is the NIST/PCTS code, which tests >POSIX Conformance, and *may* test this boundary I've just downloaded it and checked - it doesn't do any semaphore tests. >SCO has put out their packaging system. They may be willing to let >out the SVID III compliance test, if someone hinted about maybe >"standardizing on an ABI". This sounds promising. Does anyone have the appropriate contacts to approach SCO? I suspect that an approach would be better made by someone able to speak on behalf of the FreeBSD Project. Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 14:26:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 26B541103A for ; Mon, 22 Feb 1999 14:24:48 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id OAA00876; Mon, 22 Feb 1999 14:19:42 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902222219.OAA00876@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Greg Skafte Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: kde In-reply-to: Your message of "Mon, 22 Feb 1999 10:41:17 MST." <19990222104117.B16459@gras-varg.worldgate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Feb 1999 14:19:42 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG S3V cards are all 100% suspect; I've seen them cause innumerable problems (basic hardware issues). If at all possible dump the card and use something else. > we were using 800x600 24bit on a 2Meg card we dropped that to 800x600x16bit > we are now trying a differnet S3V card .... > > We are suspecting its the card but when a card is CAD$30 we had to give it > a try..... > > > Quoting Amancio Hasty (hasty@rah.star-gate.com) > On Subject: Re: kde > Date: Mon, Feb 22, 1999 at 12:34:04AM -0800 > > > Sounds like an Xserver or harware problem . Whats your card and the color depth > > that you are running with X server with? > > > > Amancio > > > > -- > Email: skafte@worldgate.com Voice: +403 413 1910 Fax: +403 421 4929 > #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 > -- -- > When things can't get any worse, they simplify themselves by getting a whole > lot worse then complicated. A complete and utter disaster is the simplest > thing in the world; it's preventing one that's complex. (Janet Morris) > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ 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 Feb 22 14:52:37 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 6E481110A7 for ; Mon, 22 Feb 1999 14:52:31 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id OAA23298 for ; Mon, 22 Feb 1999 14:42:43 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdK23285; Mon Feb 22 22:42:33 1999 Date: Mon, 22 Feb 1999 14:42:27 -0800 (PST) From: Julian Elischer To: hackers@freebsd.org Subject: Re: FreeBSD early days... (fwd) 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 was asked to write a bit on my memories.. so having done it, I figured it needed to be shared out and maybe those there might comment. (also tell me how to spell cgd's name) ---------- Forwarded message ---------- Date: Mon, 22 Feb 1999 13:01:22 -0800 (PST) From: Julian Elischer To: Gianmarco Giovannelli Cc: Amancio Hasty , Julian Elischer Subject: Re: FreeBSD early days... In 1990 I started working for TFS, a branch of TRW, a large american company with fingers in many industries. The section I was working for was doing back-end processing systems for banks and similar financial institutions. As part of these systems they needed small unix-based workstations with specialised hardware. We chose to use MACH 2.5 which was based upon BSD4.3 for much of it's userland and kernel functions. In 1991 I attended a course at UC Berkeley on BSD4.4 Kernel internals (taught by Kirk McKusick). At that course, Chris Demitriou (spelling?) brought in a copy (On floppies) of the just released 386BSD 0.1 system which had been brought to life by Bill Jolitz. Since MACH 2.5 required a licence, I found the ftp site for 386BSD and downloded a copy for myself to play with. I discoverd that MACH 2.5 and 386BSD used the same filesystem so I was able to build a machine that could run them both with shared filesystems. This allowed me to very quickly have a fully functionning system with a lot of abilities that I could not get from the fledgling 396BSD on it's own. At around that time I had written a SCSI system for MACH2.5. It was modular and had drivers for several adapters, and several device types. It was pretty easy work (about 2 weeks) to port this to 386BSD, and TFS allowed me to release it to the BSD world (via CMU). To make this work I also needed to provide bootblocks that could use SCSI disks. I started with the PD MACH bootblocks and rewrote sections of them to understand the BSD disklabels etc. These bootblocks used the BIOS and could thus boot of anything the BIOS understood, including SCSI drives. This was a vast improvement over the previous BSD bootblocks that specifically drove the hardware of the IDE/ESDI interface. They also allowed the user to type the name of analternate kernel or analternate root device, a lifesaver for people testing new kernels. Once we had a system capable of running on more hardware, the problem became that we didn't have a way for developers to co-operate, except for the newsgroup. I got permission from TFS to place a large PC with (at the time) a lot of memory and disk space, on the outside of the TFS firewall, directly attached to our T1. I then gave accounts on this machine to anyone who's name I recognised as being a developer, and kept that machine running on a 7x24 basis, with backups and some security. All users were actually in a chroot partition (though most of them never realised that). At one stage we had over 400 users on that machine with an average of 10 to 15 active at any time. This became the 386BSD reference machine. It's name was ref.tfs.com. (The name still exists now but is the TFS public ftp server and runs solaris). At this time there was what was called the "Patch kit". The patch kit was an "official" (ha!) set of patches that when applied to a 386BSD standard system, produced a system that was approximatly at the state that ref.tfs.com was at. Terry Lambert, Rod Grimes, and Chris Demitriou (sp?) were names that I remember being associated with the patchkit. (possibly also Nate Williams and Jordan hubbard). Charlse Hannum and some of the (later NetBSD) crew were also pretty visible. It was pretty common practice at that time to start with 386BSD0.1, add the patchkit, and then pull over new changes from ref. Some time in 1992 NetBSD formed as a separate organisation due to differences of opinion with Bill Jolitz. Some of us felt that the split was bad and decided to TRY maintain a position that was compatible with that of Bill Jolitz, however Bill at that time decided tha the distraction of being mentor to the entire group was stopping him from getting anything done, and decided that he needed to retire from "public life" to work on a new version of 386BSD (the fabled 0.2). Shortly after this his father died which left him with a lot of work to do with his father's affairs and basically took him right out of the picture. He later returned with a new version of 386BSD but by then things had progressed too far with NetBSD and by then FreeBSD for it to keep the mainstream position. Bill had some good ideas for changes in the kernel some of which are still not implemented anywhere that I know of. In 1993 (I think) Those of us that had been hoping to keep working with Bill eventually had to give up due to Bills dissappearance, and as Bill had a trademark on 386BSD which he wished to use for some books etc. we had to find another name. FreeBSD was chosen. Net BSD had chosen their name as they had a primary goal of porting BSD to many platforms and wanted to get rid of the 386 limitation. FreeBSD on the other hand wanted to concentrate on where the greatest market was. Thus it maintained a strong 386 basis. Only in 1998 did a port for any other hardware actually emerge. With the emergence of FreeBSD, came the connection with Walnut Creak cdrom. They hired Rod Grimes to ride hurd on it full time, and the new group decided that a CVS server was the way to go for tracking the software. Thus focus shifted from ref.tfs.com to Freefall.cdrom.com which later also became freefall.freebsd.org. Rod was (still is) a skydiver and thus the names of some of the machines.. freefall, and thud. After Rod left to persue his own businesses, those who followed didn't keep up the skydiving references. I left TFS in March 1993. When I left, ref became hard to maintain, and fell out of general use. It's functions were generally switched to freefall, and it was shut down sometime in June I believe after a catastrophic disk crash. It was rebuilt when I returned on contract later that year, but by then it had returned to the position of my personal sandbox. hope that helps (gee I should post this somewhere..) do you mind if I mail this to 'chat' or something? julian On Mon, 22 Feb 1999, Gianmarco Giovannelli wrote: > At 01.10 22/02/99 -0800, you wrote: > >You can also ask Julian Elisher julian@whistle.com -- FreeBSD or 386bsd I > >forgot which > >really got a boost by allowing hackers from all over the world to hack on the > >system 8) > > Hello Julian, a friend of you :-) said you have a lot of spare time and > wants to tell me what happens in these days ... > > Can you said me some stories, little things, rebus of that days... I am > writing my final thesis and I a need to know some little background of the > period on FreeBSD and UNIX in general... > > Btw I am now serious , don't feel you obliged, but if you wants I'll be > very happy to hear something from you :-) > > > > > Best Regards, > Gianmarco Giovannelli , "Unix expert since yesterday" > http://www.giovannelli.it/~gmarco > http://www2.masternet.it > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 14:59:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gras-varg.worldgate.com (gras-varg.worldgate.com [198.161.84.12]) by hub.freebsd.org (Postfix) with ESMTP id 979C3115C4 for ; Mon, 22 Feb 1999 14:59:44 -0800 (PST) (envelope-from skafte@gras-varg.worldgate.com) Received: (from skafte@localhost) by gras-varg.worldgate.com (8.9.1a/8.9.1) id PAA18989 for freebsd-hackers@FreeBSD.ORG; Mon, 22 Feb 1999 15:59:43 -0700 (MST) Date: Mon, 22 Feb 1999 15:59:43 -0700 From: Greg Skafte To: freebsd-hackers@FreeBSD.ORG Subject: Re: kde Message-ID: <19990222155943.C18403@gras-varg.worldgate.com> References: <19990222104117.B16459@gras-varg.worldgate.com> <199902222219.OAA00876@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199902222219.OAA00876@dingo.cdrom.com>; from Mike Smith on Mon, Feb 22, 1999 at 02:19:42PM -0800 Organization: WorldGate Inc. X-PGP-Fingerprint: 42 9C 2C A8 4D 2B C9 C4 7D B6 00 B0 50 47 20 97 X-URL: http://gras-varg.worldgate.com/~skafte Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG that's the plan we've got a couple of differnet non-S3* cards on order. The machine is for testing a proof of concept.... now that we know that the video card is the problem we can get back to business..... thanks all Quoting Mike Smith (mike@smith.net.au) On Subject: Re: kde Date: Mon, Feb 22, 1999 at 02:19:42PM -0800 > > S3V cards are all 100% suspect; I've seen them cause innumerable > problems (basic hardware issues). If at all possible dump the card and > use something else. > > > we were using 800x600 24bit on a 2Meg card we dropped that to 800x600x16bit > > we are now trying a differnet S3V card .... > > > > We are suspecting its the card but when a card is CAD$30 we had to give it > > a try..... > > > > > > Quoting Amancio Hasty (hasty@rah.star-gate.com) > > On Subject: Re: kde > > Date: Mon, Feb 22, 1999 at 12:34:04AM -0800 > > > > > Sounds like an Xserver or harware problem . Whats your card and the color depth > > > that you are running with X server with? > > > > > > Amancio > > > > > > > -- > > Email: skafte@worldgate.com Voice: +403 413 1910 Fax: +403 421 4929 > > #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 > > -- -- > > When things can't get any worse, they simplify themselves by getting a whole > > lot worse then complicated. A complete and utter disaster is the simplest > > thing in the world; it's preventing one that's complex. (Janet Morris) > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ mike@smith.net.au > \\ The race is long, and in the \\ msmith@freebsd.org > \\ end it's only with yourself. \\ msmith@cdrom.com > -- Email: skafte@worldgate.com Voice: +403 413 1910 Fax: +403 421 4929 #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 -- -- When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex. (Janet Morris) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 15:42: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id 2D1D311294 for ; Mon, 22 Feb 1999 15:42:00 -0800 (PST) (envelope-from bright@cygnus.rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.8.7/8.8.7) with SMTP id TAA18766; Mon, 22 Feb 1999 19:04:05 -0500 (EST) Date: Mon, 22 Feb 1999 19:04:04 -0500 (EST) From: Alfred Perlstein To: Allen Campbell Cc: hackers@FreeBSD.ORG Subject: Re: Privileged port problems In-Reply-To: <36D12D31.1C649D7F@verinet.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, 22 Feb 1999, Allen Campbell wrote: > My ISP appears to be filtering outgoing packets for privileged source port > numbers. This is preventing me from accessing anoncvs.freebsd.org; the CVS > client attempts to authenticate to anoncvs.freebsd.org using a privileged source > port (via rsh) and the operation times out. I also observe that rpcinfo as a > non-privileged user works correctly, but fails as root because it then attempts > to use a privileged source port. > Have you tried telling cvs to use ssh? export CVS_RSH=ssh this resolved my issues, i'm too lazy to look if ssh requires the same ports. > I'm fairly certain I will have no luck convincing my ISP to allow these > connections. No doubt they will claim it prevents their customers from using > their system to attack other hosts. you really should complain to the ISP, this is beyond lame. alternativly you can use cvsup to grab the entire CVS repo, or just the distros you want, keeping a local copy is much easier on yourself. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 15:50:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (Postfix) with ESMTP id 85CF310ED5 for ; Mon, 22 Feb 1999 15:49:38 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id QAA15887; Mon, 22 Feb 1999 16:49:35 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id QAA06336; Mon, 22 Feb 1999 16:49:28 -0700 Date: Mon, 22 Feb 1999 16:49:28 -0700 Message-Id: <199902222349.QAA06336@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD early days... (fwd) In-Reply-To: References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > At this time there was what was called the "Patch kit". The patch kit > was an "official" (ha!) set of patches that when applied to a 386BSD > standard system, produced a system that was approximatly at the state that > ref.tfs.com was at. Terry Lambert, Rod Grimes, and Chris Demitriou (sp?) > were names that I remember being associated with the patchkit. (possibly > also Nate Williams and Jordan hubbard). Charlse Hannum and some of the > (later NetBSD) crew were also pretty visible. As those involved (feel free to pipe up Jordan), the patchkit was originally Terry's. I did the 'Bug Report', which mostly overlapped the patchkit, but was much less organized, so Terry handed the reins of the patchkit off to me. Then, I got overwhelmed and handed it off to Jordan, who handed it off to Rod, and ultimately we all banded together to form FreeBSD after Bill abandoned us. AFAIK, Chris never made any public patches, but he was the sys. admin on 'agate', the 386BSD distribution site, and later started up 'NetBSD' after Chris got angry with Bill. Hannum didn't get involved much until after NetBSD got off the ground. > Some time in 1992 NetBSD formed as a separate organisation due to > differences of opinion with Bill Jolitz. Some of us felt that the split > was bad and decided to TRY maintain a position that was compatible with > that of Bill Jolitz, however Bill at that time decided tha the distraction > of being mentor to the entire group was stopping him from getting anything > done, and decided that he needed to retire from "public life" to work on a > new version of 386BSD (the fabled 0.2). Shortly after this his father died > which left him with a lot of work to do with his father's affairs and > basically took him right out of the picture. This is all news to me. I remember Lynn yelling at me on the phone telling me how I was a traitor to Bill after we decided to re-release 0.1 with the patchkit bundled in it. > He later returned with a new version of 386BSD He *NEVER* released a new version of 386BSD. His book is still based mostly on the original 0.1 release. > but by then things had progressed too far with NetBSD > and by then FreeBSD for it to keep the mainstream position. Bill had some > good ideas for changes in the kernel some of which are still not > implemented anywhere that I know of. Anywhere. :) > In 1993 (I think) Those of us that had been hoping to keep working > with Bill eventually had to give up due to Bills dissappearance, and > as Bill had a trademark on 386BSD which he wished to use for some > books etc. we had to find another name. FreeBSD was chosen. FreeBSD never existed as anything but a re-rolled 386BSD until the Bill/Lynn blowup, at which point a number of us felt it was best to put as much distance between Bill/Lynn as possible, hence the new project name. > With the emergence of FreeBSD, came the connection with Walnut Creak > cdrom. They hired Rod Grimes to ride hurd on it full time, and the new > group decided that a CVS server was the way to go for tracking the > software. Thus focus shifted from ref.tfs.com to Freefall.cdrom.com > which later also became freefall.freebsd.org. ref died a *LONG* time before freefall ever came into being. You left TFS, and a bunch of corrupted backups ended up at Montana State University. I tried to sort through these, and finally gave up when it became obvious that the backups were trashed. So, I volunteered my box (bsd.coe.montana.edu) and MSU donated 4GB of disk space and the project continued. However, it became apparent that MSU's 56K link was severely inadequate for the task, so Jordan (who lived in Ireland at the tim) approached Bob Bruce @ Walnut Creek who graciously donated hardware and allowed the project to use (abuse) it's T1 to help co-ordinate the project. J.T. Conklin actually helped us setup the CVS repository. Many of the scripts we are using as well as a number of BSD speedups are based on his early work. > Rod was (still is) a skydiver and thus the names of some of the machines.. > freefall, and thud. After Rod left to persue his own businesses, those who > followed didn't keep up the skydiving references. > > I left TFS in March 1993. When I left, ref became hard to maintain, > and fell out of general use. It's functions were generally switched to > freefall, and it was shut down sometime in June I believe after a > catastrophic disk crash. Ahh, the reason the dumps were trashed was because the disk was trashed. Now I know. :) > It was rebuilt when I returned on contract later > that year, but by then it had returned to the position of my personal > sandbox. > > hope that helps > (gee I should post this somewhere..) > do you mind if I mail this to 'chat' or something? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 16:15:45 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 4BA9E1100E for ; Mon, 22 Feb 1999 16:15:13 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id AAA58986; Tue, 23 Feb 1999 00:15:06 GMT (envelope-from dfr@nlsystems.com) Date: Tue, 23 Feb 1999 00:15:05 +0000 (GMT) From: Doug Rabson To: Geoff Rehmet Cc: hackers@freebsd.org Subject: Re: Star Office 5 woes In-Reply-To: <19990222130744.28156.qmail@rucus.ru.ac.za> 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, 22 Feb 1999, Geoff Rehmet wrote: > Doug Rabson writes : > > Download the new version from the same place you got so50. The > > registration process has been streamlined and doesn't seem to involve > > basic at all (its managed by the installer). > Registration problems aside (I'm busy downloading the new version), > I noticed, from my log files, that so50 is using the sched_yield > syscall. It appears to be a good idea to compile your kernel > with: > > options "P1003_1B" > options "_KPOSIX_PRIORITY_SCHEDULING" > options "_KPOSIX_VERSION=199309L" > > (I don't know if anyone mentioned that explicitly.) > Otherwise, watch syslogd go beserk - vrey noticeable on a P133 :-) > I noticed that too. I noticed the disk thrashing on my laptop whenever I used SO. It took me a while to realise it was syslogd :-). -- 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 Mon Feb 22 16:15:54 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 CA06210E5C for ; Mon, 22 Feb 1999 16:15:06 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id AAA58971; Tue, 23 Feb 1999 00:13:52 GMT (envelope-from dfr@nlsystems.com) Date: Tue, 23 Feb 1999 00:13:52 +0000 (GMT) From: Doug Rabson To: Luoqi Chen Cc: freebsd-hackers@freebsd.org, mjacob@feral.com Subject: Re: Panic in FFS/4.0 as of yesterday - update In-Reply-To: <199902221425.JAA17234@lor.watermarkgroup.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, 22 Feb 1999, Luoqi Chen wrote: > > Its certainly better than panicing but I'm still not happy about the > > recursion check (which is really just a reentrancy check since no > > recursion is actually happening). > > > > -- > > Doug Rabson Mail: dfr@nlsystems.com > > Nonlinear Systems Ltd. Phone: +44 181 442 9037 > > > I agree. A per-process recursion count is the way to go. My only worry is that its not clear from the comment exactly what kind of deadlock is being fixed here. If it is a deadlock which could happen for simple reentrancy, then the code should stay as it is. If not, then a different check should be used. -- 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 Mon Feb 22 17: 0:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.psn.ie (mailhub.psn.ie [194.106.150.254]) by hub.freebsd.org (Postfix) with ESMTP id 95C8110EC9 for ; Mon, 22 Feb 1999 17:00:10 -0800 (PST) (envelope-from ad@psn.ie) Received: from gromit.psn.ie ([194.106.150.251] helo=psn.ie ident=soprano) by mailhub.psn.ie with esmtp (Exim 2.12 #1) id 10F5q1-0007Ls-00; Tue, 23 Feb 1999 00:36:37 +0000 Message-ID: <36D1F85C.ECDB269F@psn.ie> Date: Tue, 23 Feb 1999 00:37:48 +0000 From: Andy Doran Organization: Pobalscoil Neasain X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Damian Hamill Cc: Terry Lambert , hackers@freebsd.org Subject: Re: Interesting ld.so bug References: <199902202154.OAA18160@usr08.primenet.com> <36D1AFBF.58BCFFEF@cablenet.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Damian Hamill wrote: > > Terry Lambert wrote: > > > > There appears to be a bug with ld.so. The following steps illustrate > > the bug: > > > > I've recently installed version 3 on a system and upgraded to 3.1 and > noticed dynamic loading strangeness too. > > The Apache port won't load dynamic modules as it can't resolve some of > the undefined symbols from the module being loaded which are contained > in the loading process, ap_make_sub_pool for example. I've seen this with glib; the gmodule interface breaks with exactly the same type of error, and they use the dlopen() interface too. Hence I've never been able to get the development versions of Gimp and Gtk+ to run properly on 3.x. Andy. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 17:56:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gras-varg.worldgate.com (gras-varg.worldgate.com [198.161.84.12]) by hub.freebsd.org (Postfix) with ESMTP id 1A98011A17 for ; Mon, 22 Feb 1999 17:56:32 -0800 (PST) (envelope-from skafte@gras-varg.worldgate.com) Received: (from skafte@localhost) by gras-varg.worldgate.com (8.9.1a/8.9.1) id SAA20173 for freebsd-hackers@freebsd.org; Mon, 22 Feb 1999 18:56:32 -0700 (MST) Date: Mon, 22 Feb 1999 18:56:31 -0700 From: Greg Skafte To: freebsd-hackers@freebsd.org Subject: Re: kde Message-ID: <19990222185631.D18403@gras-varg.worldgate.com> References: <19990222104117.B16459@gras-varg.worldgate.com> <199902222219.OAA00876@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199902222219.OAA00876@dingo.cdrom.com>; from Mike Smith on Mon, Feb 22, 1999 at 02:19:42PM -0800 Organization: WorldGate Inc. X-PGP-Fingerprint: 42 9C 2C A8 4D 2B C9 C4 7D B6 00 B0 50 47 20 97 X-URL: http://gras-varg.worldgate.com/~skafte Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG actually I'm starting to like it quite alot..... I thought I'd miss HP-Vue, and I'm really not liking any of my CDE setups.... everything is well integrated and a very consistent look and feel.... consistency is a good thing (tm) when trying to convert users from an M$ platform..... I also am intrigued by their licensing..... Quoting Mike Smith (mike@smith.net.au) On Subject: Re: kde Date: Mon, Feb 22, 1999 at 02:19:42PM -0800 > > S3V cards are all 100% suspect; I've seen them cause innumerable > problems (basic hardware issues). If at all possible dump the card and > use something else. > > > we were using 800x600 24bit on a 2Meg card we dropped that to 800x600x16bit > > we are now trying a differnet S3V card .... > > > > We are suspecting its the card but when a card is CAD$30 we had to give it > > a try..... > > > > > > Quoting Amancio Hasty (hasty@rah.star-gate.com) > > On Subject: Re: kde > > Date: Mon, Feb 22, 1999 at 12:34:04AM -0800 > > > > > Sounds like an Xserver or harware problem . Whats your card and the color depth > > > that you are running with X server with? > > > > > > Amancio > > > > > > > -- > > Email: skafte@worldgate.com Voice: +403 413 1910 Fax: +403 421 4929 > > #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 > > -- -- > > When things can't get any worse, they simplify themselves by getting a whole > > lot worse then complicated. A complete and utter disaster is the simplest > > thing in the world; it's preventing one that's complex. (Janet Morris) > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ mike@smith.net.au > \\ The race is long, and in the \\ msmith@freebsd.org > \\ end it's only with yourself. \\ msmith@cdrom.com > -- Email: skafte@worldgate.com Voice: +403 413 1910 Fax: +403 421 4929 #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 -- -- When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex. (Janet Morris) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 18:11:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bbcc.ctc.edu (bbcc.ctc.edu [134.39.180.254]) by hub.freebsd.org (Postfix) with ESMTP id 818FF111FA for ; Mon, 22 Feb 1999 18:11:18 -0800 (PST) (envelope-from chris@bbcc.ctc.edu) Received: from localhost (chris@localhost) by bbcc.ctc.edu (8.8.8/8.6.12) with SMTP id SAA13403; Mon, 22 Feb 1999 18:04:37 -0800 (PST) Date: Mon, 22 Feb 1999 18:04:37 -0800 (PST) From: Chris Coleman To: Nate Williams Cc: Julian Elischer , hackers@FreeBSD.ORG Subject: Re: FreeBSD early days... (fwd) In-Reply-To: <199902222349.QAA06336@mt.sri.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 If someone is would like it, I have an opening for the "All Things BSD" column in the Daemon News. The Column would be about Early BSD, humorous technical stories of BSD, and what ever else you felt like putting in there. We generally have two authors per column, and they alternate months. We have one author alread, and need the 2nd. Anyone who has participated in this thread would be a good candidate. If anyone is interested: editor@daemonnews.org #the Editors. article@daemonnews.org #send all articles to be published. -Chris Coleman. On Mon, 22 Feb 1999, Nate Williams wrote: > > At this time there was what was called the "Patch kit". The patch kit > > was an "official" (ha!) set of patches that when applied to a 386BSD > > standard system, produced a system that was approximatly at the state that > > ref.tfs.com was at. Terry Lambert, Rod Grimes, and Chris Demitriou (sp?) > > were names that I remember being associated with the patchkit. > > (possibly > > also Nate Williams and Jordan hubbard). Charlse Hannum and some of the > > (later NetBSD) crew were also pretty visible. > > As those involved (feel free to pipe up Jordan), the patchkit was > originally Terry's. > > I did the 'Bug Report', which mostly overlapped the patchkit, but was > much less organized, so Terry handed the reins of the patchkit off to > me. > > Then, I got overwhelmed and handed it off to Jordan, who handed it off > to Rod, and ultimately we all banded together to form FreeBSD after Bill > abandoned us. > > AFAIK, Chris never made any public patches, but he was the sys. admin on > 'agate', the 386BSD distribution site, and later started up 'NetBSD' > after Chris got angry with Bill. Hannum didn't get involved much until > after NetBSD got off the ground. > > > Some time in 1992 NetBSD formed as a separate organisation due to > > differences of opinion with Bill Jolitz. Some of us felt that the split > > was bad and decided to TRY maintain a position that was compatible with > > that of Bill Jolitz, however Bill at that time decided tha the distraction > > of being mentor to the entire group was stopping him from getting anything > > done, and decided that he needed to retire from "public life" to work on a > > new version of 386BSD (the fabled 0.2). Shortly after this his father died > > which left him with a lot of work to do with his father's affairs and > > basically took him right out of the picture. > > This is all news to me. I remember Lynn yelling at me on the phone > telling me how I was a traitor to Bill after we decided to re-release > 0.1 with the patchkit bundled in it. > > > He later returned with a new version of 386BSD > > He *NEVER* released a new version of 386BSD. His book is still based > mostly on the original 0.1 release. > > > but by then things had progressed too far with NetBSD > > and by then FreeBSD for it to keep the mainstream position. Bill had some > > good ideas for changes in the kernel some of which are still not > > implemented anywhere that I know of. > > Anywhere. :) > > > In 1993 (I think) Those of us that had been hoping to keep working > > with Bill eventually had to give up due to Bills dissappearance, and > > as Bill had a trademark on 386BSD which he wished to use for some > > books etc. we had to find another name. FreeBSD was chosen. > > FreeBSD never existed as anything but a re-rolled 386BSD until the > Bill/Lynn blowup, at which point a number of us felt it was best to put > as much distance between Bill/Lynn as possible, hence the new project > name. > > > With the emergence of FreeBSD, came the connection with Walnut Creak > > cdrom. They hired Rod Grimes to ride hurd on it full time, and the new > > group decided that a CVS server was the way to go for tracking the > > software. Thus focus shifted from ref.tfs.com to Freefall.cdrom.com > > which later also became freefall.freebsd.org. > > ref died a *LONG* time before freefall ever came into being. You left > TFS, and a bunch of corrupted backups ended up at Montana State > University. I tried to sort through these, and finally gave up when it > became obvious that the backups were trashed. > > So, I volunteered my box (bsd.coe.montana.edu) and MSU donated 4GB of > disk space and the project continued. However, it became apparent that > MSU's 56K link was severely inadequate for the task, so Jordan (who > lived in Ireland at the tim) approached Bob Bruce @ Walnut Creek who > graciously donated hardware and allowed the project to use (abuse) it's > T1 to help co-ordinate the project. > > J.T. Conklin actually helped us setup the CVS repository. Many of the > scripts we are using as well as a number of BSD speedups are based on > his early work. > > > Rod was (still is) a skydiver and thus the names of some of the machines.. > > freefall, and thud. After Rod left to persue his own businesses, those who > > followed didn't keep up the skydiving references. > > > > I left TFS in March 1993. When I left, ref became hard to maintain, > > and fell out of general use. It's functions were generally switched to > > freefall, and it was shut down sometime in June I believe after a > > catastrophic disk crash. > > Ahh, the reason the dumps were trashed was because the disk was > trashed. Now I know. :) > > > It was rebuilt when I returned on contract later > > that year, but by then it had returned to the position of my personal > > sandbox. > > > > hope that helps > > (gee I should post this somewhere..) > > do you mind if I mail this to 'chat' or something? > > > > Nate > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 18:56:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from TomQNX.tomqnx.com (cpu2745.adsl.bellglobal.com [207.236.55.214]) by hub.freebsd.org (Postfix) with ESMTP id 40B07110A9; Mon, 22 Feb 1999 18:56:53 -0800 (PST) (envelope-from tom@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m10F81h-000I1oC; Mon, 22 Feb 1999 21:56:49 -0500 (EST) Message-Id: From: tom@tomqnx.com (Tom Torrance at home) Subject: Missing files/directories To: hackers@freebsd.org, current@freebsd.org Date: Mon, 22 Feb 1999 21:56:49 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2753 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On the weekend I reported to hackers about problems experienced with 2.2-stable and RELENG-3 systems where I experienced files that disappeared from cache and Mail directories that disappeared. The RELENG-3 system had files affected with softupdates enabled. The 2.2-stable system had sub-directories missing from the same directories that I was writing to via nfsv2. By coincidence, I had cvsup'd and compiled new kernels and naturally made the assumption that there was causality there. Subsequently I have come to believe that the problem may have more to do with what I was doing, not changes to the code. For about 3-4 hours prior to noticing the problems, I had been repetitively editing dot files, then writing a kludge of dot files to the local system hard drive and to the nfs exported FS of the other computer, while occasionally checking mail on that computer. All files and directories missing were being updated for one reason or another by myself or by mail processes while I was doing this. It is speculation, but there is a good chance that there is a bug in the cache-handling code that causes problems with other files or directories being dropped from cache because of bad processing common to BOTH or ALL releases, when large numbers of dot files are being written. The dot files themselves did not disappear - other items to be written disappeared before their writes actually occurred. I know that this is a frustrating kind of message to receive, but I am not a developer & not qualified to go into the code myself. Also no logs or hard output are available - files/directories simply disappeared without any error messages. I just did a scan of the entire /usr/src/sys tree for \"\\.\" and \'\\.\' to see what code sections might be affected - mostly cache-handling. In quantity, not bad, really. Others have apparently reported missing files to do with nfs I believe. THis might or might not be a related problem. I guess that I am asking someone who is qualified, and concerned about missing files or directories, if they would be willing to do what I cannot - check the code for bad interactions when dot files are being written- bearing in mind that it is OTHER files/directories that are disappearing from cache before being written. Is anyone out there sufficiently intrigued by the possibility to invest some valuable time? I am a QA tester, not a developer, and therefore much more comfortable with discussion of symptoms and speculative causality than most developers I have known. I hope that someone thinks enough of the possibility to invest some time, which I know is in very short supply. I cannot deny that this is (informed) speculation - there are no guarantees. Regards and best wishes, Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 19: 5:44 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 286CF11552 for ; Mon, 22 Feb 1999 19:04:55 -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.2) with ESMTP id TAA62109; Mon, 22 Feb 1999 19:04:51 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Julian Elischer Cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD early days... (fwd) In-reply-to: Your message of "Mon, 22 Feb 1999 14:42:27 PST." Date: Mon, 22 Feb 1999 19:04:50 -0800 Message-ID: <62105.919739090@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > With the emergence of FreeBSD, came the connection with Walnut Creak > cdrom. They hired Rod Grimes to ride hurd on it full time, and the new > group decided that a CVS server was the way to go for tracking the > software. Thus focus shifted from ref.tfs.com to Freefall.cdrom.com > which later also became freefall.freebsd.org. > > Rod was (still is) a skydiver and thus the names of some of the machines.. > freefall, and thud. After Rod left to persue his own businesses, those who > followed didn't keep up the skydiving references. Actually, just a few corrections here. The connection with Walnut Creek CDROM came about through my calling them on the phone from Ireland purely because I liked their Aminet CDROM and thought they had the best "production values" of any of the 5 or 6 CDROM publishers represented on my shelf. Once we had established the basis for some sort of relationship, they asked for someone to work with them on a more personal basis and Rod, who was just up the west U.S. coast a bit and far closer than I in Ireland or Nate in Montana, was hired to come down for 3 months (was it 3, Rod? I can't remember the initial fabled number :) and do the CD. He ended up staying closer to a year and creating their entire internal LAN as well as a number of servers and god-only-knows what else and, oh yes, just happened to eventually produce a CD while he was down there as well. :-) I think I took over the next CD after that and I've been basically doing them ever since. Also, just to really pick nits, "thud" was not one of Rod's machine names, that was mine and based on the Dilbert cartoon which we'd stuck on freefall. In this cartoon, Dilbert says "I'm thinking of taking up skydiving, Dogbert, what do you think?" Dogbert replies "Thud" and Dilbert, now looking rather concerned, says "You mean ``thud, ouch!'' or just ``Thud!?''" As I recall, Rod didn't find the joke anywhere nearly as amusing as the rest of us, but ah well - thud is gone now, RIP. :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 19:32: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 D0DB111052 for ; Mon, 22 Feb 1999 19:32:28 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id TAA03165; Mon, 22 Feb 1999 19:27:42 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdtB3157; Tue Feb 23 03:27:39 1999 Date: Mon, 22 Feb 1999 19:27:31 -0800 (PST) From: Julian Elischer To: "Jordan K. Hubbard" Cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD early days... (fwd) In-Reply-To: <62105.919739090@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, 22 Feb 1999, Jordan K. Hubbard wrote: > > With the emergence of FreeBSD, came the connection with Walnut Creak > > cdrom. They hired Rod Grimes to ride hurd on it full time, and the new > > group decided that a CVS server was the way to go for tracking the > > software. Thus focus shifted from ref.tfs.com to Freefall.cdrom.com > > which later also became freefall.freebsd.org. > > > > Rod was (still is) a skydiver and thus the names of some of the machines.. > > freefall, and thud. After Rod left to persue his own businesses, those who > > followed didn't keep up the skydiving references. > > Actually, just a few corrections here. The connection with Walnut > Creek CDROM came about through my calling them on the phone from > Ireland purely because I liked their Aminet CDROM and thought they had > the best "production values" of any of the 5 or 6 CDROM publishers > represented on my shelf. I didn't say HOW the connection to WC was made, just that it ended up with rod working there :-) I often wondered what the first contact was... Do you remeember when FreeBSD diverged (and how the people were selected for what became "core"? I think I was having a non 386BSD week that week and seem to have missed it.. I do know that my departure to AUS took me out of the picture for a while, and was responsible for ref being unavailable. I don't know what the influence of that was however.. > Once we had established the basis for some > sort of relationship, they asked for someone to work with them on a > more personal basis and Rod, who was just up the west U.S. coast a bit > and far closer than I in Ireland or Nate in Montana, was hired to come > down for 3 months (was it 3, Rod? I can't remember the initial fabled > number :) and do the CD. He ended up staying closer to a year and > creating their entire internal LAN as well as a number of servers and > god-only-knows what else and, oh yes, just happened to eventually > produce a CD while he was down there as well. :-) I think I took > over the next CD after that and I've been basically doing them ever > since. > > Also, just to really pick nits, "thud" was not one of Rod's machine > names, that was mine and based on the Dilbert cartoon which we'd stuck > on freefall. In this cartoon, Dilbert says "I'm thinking of taking up > skydiving, Dogbert, what do you think?" Dogbert replies "Thud" > and Dilbert, now looking rather concerned, says "You mean ``thud, > ouch!'' or just ``Thud!?''" As I recall, Rod didn't find the joke > anywhere nearly as amusing as the rest of us, but ah well - thud is > gone now, RIP. :-) yes but it's still a skydiving name right? :-) There was I think another, but I can't remember what it was.. > > - Jordan > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 19:40: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id BE73010EEC for ; Mon, 22 Feb 1999 19:39:10 -0800 (PST) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id EAA05604 for freebsd-hackers@FreeBSD.ORG; Tue, 23 Feb 1999 04:39:09 +0100 (CET) (envelope-from olli) Date: Tue, 23 Feb 1999 04:39:09 +0100 (CET) From: Oliver Fromme Message-Id: <199902230339.EAA05604@dorifer.heim3.tu-clausthal.de> To: freebsd-hackers@FreeBSD.ORG Subject: Re: ISA DMA problems if >= 512 Mb RAM? Newsgroups: list.freebsd-hackers Organization: Administration Heim 3 Reply-To: freebsd-hackers@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Frank Nobis wrote in list.freebsd-hackers: > [...] > I have a P2B-DS with 512 M Ram and AWE64 > > Until today I had the same problem. Today I build a new kernel and now > the problem ist gone. Did you change anything significant in your kernel config? Maybe you threw some drivers away which made the kernel take up less memory? Can you send a diff of your dmesg output from before (when the problem still existed) and after (when it went away), please? > real memory = 536870912 (524288K bytes) > avail memory = 519380992 (507208K bytes) I'm specifically interested in these two lines. ;-) I'd be very happy if the problem is really fixed... However, this is a production machine, so going to 4.0-current is not what I intended... Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 19:40:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 73067110BD for ; Mon, 22 Feb 1999 19:40:08 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id TAA15314; Mon, 22 Feb 1999 19:40:02 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.2/8.9.1) id TAA22528; Mon, 22 Feb 1999 19:40:02 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [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: <199902221912.LAA76945@bubba.whistle.com> Date: Mon, 22 Feb 1999 19:40:02 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Archie Cobbs Subject: Re: Interesting ld.so bug Cc: hackers@FreeBSD.ORG, (Terry Lambert) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Archie Cobbs wrote: > Terry Lambert writes: >> There appears to be a bug with ld.so. The following steps illustrate >> the bug: > > After some further playing around, it seems like it may be a linker > problem, or a least a problem in the way we're using it. > > Here's my test case that reproduces the problem: > > We compile a shared library "libfoo" containing these source files: > > bar.c - Containing functions bar1() and bar2(), which are > both exported. Function bar1() calls function bar2(). > > java_jni.c - Java JNI method to interface to function bar1(), > call it Java_bar1(). > > db.c - Other exported routines. The C code in this file > uses GDBM routines. NOTE: GDBM routines live in > a static library, /usr/local/lib/libgdbm.a. > > Now when we run a java class that uses the java_jni.c native method, > the call to Java_bar1() succeeds, and the call from there to bar1() > succeeds, but when bar1() tries to call bar2(), it jumps to a very > low address and segfaults. It seems that the bar2() trampoline is > using an uninitialized base address or whatever. > > NOW, if we remove "db.c" from the compilation of "libfoo.so", > then everything works! Was the code in the static libgdbm.a library compiled with -fpic? I bet it wasn't, and that's probably the problem. All code that's included in a shared library should be PIC code. John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 20:13: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (s205m7.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id C7F8F10F2E for ; Mon, 22 Feb 1999 20:12:24 -0800 (PST) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id UAA72778; Mon, 22 Feb 1999 20:10:55 -0800 (PST) From: Archie Cobbs Message-Id: <199902230410.UAA72778@bubba.whistle.com> Subject: Re: Interesting ld.so bug In-Reply-To: from John Polstra at "Feb 22, 99 07:40:02 pm" To: jdp@polstra.com (John Polstra) Date: Mon, 22 Feb 1999 20:10:54 -0800 (PST) Cc: hackers@FreeBSD.ORG, terry@whistle.com X-Mailer: ELM [version 2.4ME+ PL38 (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 John Polstra writes: > > Now when we run a java class that uses the java_jni.c native method, > > the call to Java_bar1() succeeds, and the call from there to bar1() > > succeeds, but when bar1() tries to call bar2(), it jumps to a very > > low address and segfaults. It seems that the bar2() trampoline is > > using an uninitialized base address or whatever. > > > > NOW, if we remove "db.c" from the compilation of "libfoo.so", > > then everything works! > > Was the code in the static libgdbm.a library compiled with -fpic? > I bet it wasn't, and that's probably the problem. All code that's > included in a shared library should be PIC code. Actually, now something else is going on.. here's some more info: With db.c Without db.c --------- ------------ RTLD_LAZY fails works! RTLD_NOW fails fails Terry thinks there is a screwup in RTLD_NOW in that it's failing to recurse. Example of failure without db.c: Program received signal SIGSEGV, Segmentation fault. 0x337a in ?? () (gdb) bt #0 0x337a in ?? () #1 0x286a3879 in Java_Locat_IjGetLanguage (env=0x280db038, clazz=0x818ef30) at java_locat.c:82 #2 0x816acf0 in ?? () #3 0x81cc49d in ?? () Example of failure with db.c: Program received signal SIGSEGV, Segmentation fault. 0x3192 in ?? () (gdb) bt #0 0x3192 in ?? () #1 0x816acf0 in ?? () #2 0x81cc49d in ?? () Java_Locat_IjGetLanguage is the native routine, and it's trying to call another routine in the same shared library and dieing. It looks like the fixup for the second routine (which is also exported) is not being done for some reason. However, this can be worked around by adding this to the build of the library (discoverd by Amancio): -export-dynamic -lgdbm -lc Any ideas on what's going on? -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 Mon Feb 22 20:50:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id 9EAC110E6F for ; Mon, 22 Feb 1999 20:50:19 -0800 (PST) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id FAA29749; Tue, 23 Feb 1999 05:50:15 +0100 (CET) (envelope-from olli) Date: Tue, 23 Feb 1999 05:50:15 +0100 (CET) From: Oliver Fromme Message-Id: <199902230450.FAA29749@dorifer.heim3.tu-clausthal.de> To: freebsd-hackers@FreeBSD.ORG Subject: Re: Oskit and 3.0? Cc: ambrisko@whistle.com Newsgroups: list.freebsd-hackers Organization: Administration Heim 3 Reply-To: freebsd-hackers@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG (Cc: to ambrisko@whistle.com) Doug Ambrisko wrote in list.freebsd-hackers: > Julian Elischer writes: > | we netboot elf kernels and aout kernels here.. > | check with doug ambrisko (ambrisko@whistle.com) for his netbooting stuff. > > It would be nice if some commiter would commit pr: > [1999/01/13] ports/9480 ports ELF kernel netboot I had a look at it. It doesn't seem to support loading of configuration files like the new FreeBSD loader does (e.g. to set up PnP), does it? Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 21:11:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (Postfix) with ESMTP id 8604910EDE for ; Mon, 22 Feb 1999 21:11:21 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id WAA18172; Mon, 22 Feb 1999 22:11:18 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id WAA07468; Mon, 22 Feb 1999 22:11:11 -0700 Date: Mon, 22 Feb 1999 22:11:11 -0700 Message-Id: <199902230511.WAA07468@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: FreeBSD early days... (fwd) In-Reply-To: References: <62105.919739090@zippy.cdrom.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Do you remeember when FreeBSD diverged (and how the people were selected > for what became "core"? I don't remember any 'divergence' except one that just sort of happened. I remember hoping/thinking that Bill's promise would eventually come true (unlike the folks who started NetBSD). We kept hoping that the must anticipated 386BSD 0.2 release would be released 'Real Soon Now'. The NetBSD folks had a lesser view of Bill, as well as decidely negative view of BSD on the x86, so gave up earlier on the promise of 0.2 and started doing their own thing. Even when this occurrred, there was a positive working relationship between the 'interim' group and the 'BSD on everything else' group. We (the FreeBSD folks) continue to work on providing a stable/usable BSD release on the x86, and when Bill bailed out the the 'focus' of the interim group was already decidedly different than the NetBSD group that both groups could do well working apart. This worked well, until at one point someone (I don't even remember who) in the NetBSD group felt that FreeBSD was just copying all of the bits from NetBSD and not giving proper credit, at which time *ALL* of the FreeBSD members lost their CVS privileges on the the NetBSD box (sunlamp). > I think I was having a non 386BSD week that week and seem to have missed > it.. I do know that my departure to AUS took me out of the picture for a > while, and was responsible for ref being unavailable. I don't know what > the influence of that was however.. IMO, ref's disappearance had little to do with Free/NetBSD, except that at the time it was the only public machine that Bill had an account. It may have participated in making Bill feel even more isolate, but I can't speak for him. Although ref's demise was untimely, I don't believe that even had it existed would things have turned out much different. Because ref was not managed by someone who had lots of time and the BSD portions of it were of secondary importance to TFS, it could never have gotten enough critical mass to do much, which is why Rod/Jordan/WC's resources were critical to the success of the project. > There was I think another, but I can't remember what it was.. gndrsh (ground rush). Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 21:47:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from snake.supranet.net (snake.supranet.net [205.164.160.19]) by hub.freebsd.org (Postfix) with ESMTP id 344221126B; Mon, 22 Feb 1999 21:46:09 -0800 (PST) (envelope-from john@arnie.jfive.com) Received: from localhost (john@localhost) by snake.supranet.net (8.8.8/8.8.8) with SMTP id XAA00932; Mon, 22 Feb 1999 23:46:09 -0600 (CST) (envelope-from john@arnie.jfive.com) Date: Mon, 22 Feb 1999 23:46:09 -0600 (CST) From: John Heyer X-Sender: john@snake.supranet.net To: hackers@freebsd.org Cc: mozilla@freebsd.org Subject: Netscape 3.04 and FreeBSD 3.1-RELEASE 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 Anybody running Netscape 3.X on FreeBSD 3.1-RELEASE? I've installed Netscape 3.04 both from the packages by downloading, and can't see any Java applets (i.e. I get a blank area where the applet is supposed to be), and it worked fine on 3.0-RELEASE. Unfortunately, I only have one box to test this on, so am hesitant to fill out a bug report. -- "Your illogical approach ... does have its advantages." -- Spock, after being Checkmated by Kirk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 22:37:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 42654118FC for ; Mon, 22 Feb 1999 22:37:52 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id WAA15801; Mon, 22 Feb 1999 22:37:50 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.2/8.9.1) id WAA22825; Mon, 22 Feb 1999 22:37:50 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [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: <19990219074445.C4890@internal> Date: Mon, 22 Feb 1999 22:37:50 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Andre Albsmeier Subject: Re: UIDs greater than 65535? Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Andre Albsmeier wrote: > On Thu, 18-Feb-1999 at 21:15:51 -0800, John Polstra wrote: >> >> Thanks for telling me about this. I took a brief look at it. It >> looks like it won't be a problem for me, as long as the UID space is >> tightly packed. > > Hmm, I don't think it is the _packing_ of the UID space. It's the high > UID's... If I understood it correctly, the quotas are handled as an > array of structs (one 32 Byte struct for each user). My quota > file has a size of 2097120. That means, 2097120/32 = 65535 entries > which is correct. If you got a user ID of 10.000.000 the quota > array should be already 320.000.000 bytes of size at least. I understand. But I'm thinking in terms of, say, 80000 users with UIDs numbered from 0 to 79999. So in my case, there's no intrinsic problem beyond the fact that it's a helluva lot of users. It would be different if I had 80000 users numbered from 1000000 to 1079999. That's what I meant when I referred to the packing of the UID space. John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 22 23:15:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail0.atl.bellsouth.net (mail0.atl.bellsouth.net [205.152.0.27]) by hub.freebsd.org (Postfix) with ESMTP id A7F3E11B7B for ; Mon, 22 Feb 1999 23:15:12 -0800 (PST) (envelope-from wghicks@bellsouth.net) Received: from wghicks.bellsouth.net (host-209-214-67-118.atl.bellsouth.net [209.214.67.118]) by mail0.atl.bellsouth.net (8.8.8-spamdog/8.8.5) with ESMTP id CAA23982; Tue, 23 Feb 1999 02:15:01 -0500 (EST) Received: from wghicks (localhost [127.0.0.1]) by wghicks.bellsouth.net (8.9.2/8.9.2) with ESMTP id CAA38026; Tue, 23 Feb 1999 02:33:00 -0500 (EST) (envelope-from wghicks@wghicks.bellsouth.net) Message-Id: <199902230733.CAA38026@bellsouth.net> To: John Heyer Cc: freebsd-hackers@freebsd.org Subject: Re: Netscape 3.04 and FreeBSD 3.1-RELEASE In-reply-to: Your message of "Mon, 22 Feb 1999 23:46:09 CST." Date: Tue, 23 Feb 1999 02:32:59 -0500 From: W Gerald Hicks Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm running it on 3.1-STABLE; Seems fine. Did you do the mkfontdir thing? If not, search dejanews for 'mkfontdir' and 'netscape' for the exact commands, I can't remember them just now. Good Luck, Jerry Hicks wghicks@bellsouth.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 0:33:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bamboo.verinet.com (bamboo.verinet.com [204.144.246.5]) by hub.freebsd.org (Postfix) with ESMTP id BE0C6120EC for ; Tue, 23 Feb 1999 00:33:10 -0800 (PST) (envelope-from allenc@verinet.com) Received: from struct. (allenc.verinet.com [199.45.180.181]) by bamboo.verinet.com (8.8.8/8.7.1) with ESMTP id BAA10461; Tue, 23 Feb 1999 01:33:08 -0700 Received: from verinet.com (struct. [192.168.1.3]) by struct. (8.8.8/8.8.8) with ESMTP id BAA01552; Tue, 23 Feb 1999 01:33:04 -0700 (MST) (envelope-from allenc@verinet.com) Message-ID: <36D267BF.117A6839@verinet.com> Date: Tue, 23 Feb 1999 01:33:03 -0700 From: Allen Campbell X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.7-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: hackers@FreeBSD.ORG Subject: Re: Privileged port problems References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > > On Mon, 22 Feb 1999, Allen Campbell wrote: > > > My ISP appears to be filtering outgoing packets for > > privileged source port numbers. This is preventing > > me from accessing anoncvs.freebsd.org; the CVS client > > attempts to authenticate to anoncvs.freebsd.org using > > a privileged source port (via rsh) and the operation > > times out. I also observe that rpcinfo as a > > non-privileged user works correctly, but fails as > > root because it then attempts to use a privileged > > source port. > > > > Have you tried telling cvs to use ssh? > > export CVS_RSH=ssh > > this resolved my issues, i'm too lazy to look if ssh requires the same > ports. This did the trick. I configured ssh to not use privileged ports with UsePrivilegedPort = no anoncvs.freebsd.org is happy with this. Thank you. > > I'm fairly certain I will have no luck convincing my > > ISP to allow these connections. No doubt they will claim > > it prevents their customers from using their system to > > attack other hosts. > > you really should complain to the ISP, this is beyond lame. Some random Joe user griping about some weird CVS thing. Believe me, if anti-social wasn't my middle name I might have already found the motivation to take on the absolute cluelessness I will confront. However, for the sake of random Joe users everywhere I'll take a stab at it (figuratively, at first. :) > alternativly you can use cvsup to grab the entire CVS repo, or just > the distros you want, keeping a local copy is much easier on yourself. I haven't been tracking stable or current; usually I just want to patch some man page for spelling or missing options and submit a PR. Sometimes I need to butcher a program (hexdump being the most recent example) for special behavior. Anonymous CVS is perfect here. > -Alfred -- Allen Campbell | Lurking at the bottom of the allenc@verinet.com | gravity well, getting old. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 0:46:40 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 C4AEE1220C for ; Tue, 23 Feb 1999 00:46:31 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id IAA60371; Tue, 23 Feb 1999 08:45:41 GMT (envelope-from dfr@nlsystems.com) Date: Tue, 23 Feb 1999 08:45:41 +0000 (GMT) From: Doug Rabson To: Matthew Jacob Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday 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, 22 Feb 1999, Matthew Jacob wrote: > > > > > > Check the code paths and look for B_ASYNC getting unset. I believe this > > > is the correct patch. > > > > As I said before, the reads and writes in question are not delayed writes. > > The reason I have a problem is that the i/o queue in the driver has grown > > to an obscene length, increasing latency to unreasonable levels. Changing > > the order of processing delayed writes is irrelavent to this problem. > > This isn't a new problem. When I did driver level clustering at Sun back in > 1990, I was regularly seeing queue lengths in excess of 1000 for a 16MB > memory Sparc2. Thats a lot of memory to be using in a 16Mb box. Was the machine still usable with this kind of i/o load? > > > > > > > > > > > I think the flag needs to be implemented in the driver. The driver should > > > > check for the EXPEDITE flag and either maintain two queues for the two > > > > possible priorities or place the buffer at the front of a single work > > > > queue. > > > > > > This has some serious flaws. > > > > > > The first is, you have to get it right in more than one driver. This > > > is really like the "wakeup" character change I did to the serial > > > drivers to allow for unanticipated "hotchar" in binary only drivers > > > from third parties, like E.T. Inc.. > > > > The driver changes would be small and the code can be arranged so that a > > a driver doesn't have to change at all to keep functioning, just to > > improve perceived performance. > > I think this would be a very good idea. This is exactly the kind of thing > that HEAD OF QUEUE tags are designed for. I agree with Doug that this is > not a requirement for continuing to run- just an improvement. And if you > think about it, it's really only two drivers (scsi_da, wd). > > > > > I've been looking at the UFS code all day, trying to make it set > > B_EXPEDITE for all reads and writes for directories with only limited > > success. > > > > I no longer think this is the correct solution and I am starting to try a > > priority based scheme which uses a number similar to p->p_estcpu to > > identify processes which are performing large amounts of i/o and to > > penalise them by placing their subsequent i/o requests behind processes > > with a lower i/o priority. > > > > The only problem with this approach is not all I/O is or will be driven > by a process. Let's say we port a new filesystem in that creates a > *lot* of I/O via threads or wads of async r/w. Unless you start doing > thread scheduling it's hard to figure out whome to penalize. That could be a problem I suppose. > > I still would like to see a B_EXPEDITE (although B_PRIORITY seems a better > name). Should we also be paying attention to B_ORDERED and should you > consider doing buffer generations? I'll keep fiddling with it and see if I can get a noticable improvement for directory operations. With a simple scheme like this the latency for e.g. an uncached small read could still be unbounded if there is a lot of async i/o happening. -- 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 Feb 23 0:52:59 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 610E611694 for ; Tue, 23 Feb 1999 00:52:54 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id IAA60504; Tue, 23 Feb 1999 08:50:57 GMT (envelope-from dfr@nlsystems.com) Date: Tue, 23 Feb 1999 08:50:57 +0000 (GMT) From: Doug Rabson To: Julian Elischer Cc: Don Lewis , Terry Lambert , Matthew Dillon , freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday 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, 22 Feb 1999, Julian Elischer wrote: > softupdates already "kinda" doesn this.. > it queues data writes at one point in the future and directory writes > at a different point in the future. I believe that data writes must be > completed before inode writes which must be completed before directory > writes. If they are not the the dependencies will FORCE that ordering. > > The reason to preschedule the different actions is to make it all happen > in the right order anyhow, so that the dependency tracking is a big NOP. I think softupdates will be less affected by this but there can still be problems with latency. The time for a simple directory read (not a softupdate controlled operation) can be delayed significantly since it gets queued behind all the rest of the async i/o. In Matt's test, I saw about 5Mb queued at one point which translates to a latency of over 0.5sec, assuming the drive throughput is about 8Mb/sec. -- 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 Feb 23 0:55:27 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 726AD10E9A for ; Tue, 23 Feb 1999 00:55:23 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id IAA60508; Tue, 23 Feb 1999 08:54:14 GMT (envelope-from dfr@nlsystems.com) Date: Tue, 23 Feb 1999 08:54:14 +0000 (GMT) From: Doug Rabson To: Don Lewis Cc: Terry Lambert , dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday In-Reply-To: <199902221428.GAA28942@salsa.gv.tsc.tdk.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, 22 Feb 1999, Don Lewis wrote: > On Feb 20, 10:52pm, Terry Lambert wrote: > } Subject: Re: Panic in FFS/4.0 as of yesterday > > } > If it works, then changing lookup to not require locks on both vnodes at > } > the same time would be a good thing. One of the reasons that NFS doesn't > } > have proper node locks is that a dead NFS server can lead to a hung > } > machine though a lock cascade from the NFS mount point. > > I suggested doing something like this, but only at mount points, which > should be sufficient to fix the NFS problem. The only race conditions > that would open would be for things you probably don't want to do > at mountpoints anyway. It sounds as if it might work. Are you interested in coding this? > > } The correct way to do this, IMO, is a back-off/retry, which would > } unlock the lock and queue the operation for retry, which would > } reacquire the lock. > > Wouldn't you have to relock the parent before unlocking the lock (nasty > because it reverses the locking order and might cause a deadlock). If you have a locking protocol like the one we have at present with a pair of locks moving along the pathname, always with the parent and child locked, then you must always lock in the same order to avoid deadlock. If you need to unlock the parent, then you must unlock the child first etc. -- 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 Feb 23 1:21:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 92A2911257 for ; Tue, 23 Feb 1999 01:20:49 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id BAA44464; Tue, 23 Feb 1999 01:20:45 -0800 (PST) (envelope-from dillon) Date: Tue, 23 Feb 1999 01:20:45 -0800 (PST) From: Matthew Dillon Message-Id: <199902230920.BAA44464@apollo.backplane.com> To: Doug Rabson Cc: Matthew Jacob , freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday - update References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I would suggest disabling it entirely to see if the system survives any :better. If that helps, perhaps it should be using a field in struct proc :to record the recursion depth. : :-- :Doug Rabson Mail: dfr@nlsystems.com :Nonlinear Systems Ltd. Phone: +44 181 442 9037 No, don't disable it. Unless you want the process to overflow it's supervisor stack, that is! The code is obviously broken, but disabling it will break it even worse. The write recursion test could actually be used as a count of the number of I/O's which are 'starting up' ( verses in progress ). It's an obvious failure as a stack recursion counter but judging from the comments, it was designed to handle both conditions. What appears to be happening is that both the buffer pool and the KVA space for the buffer pool is being exhausted. The code appears to be designed to deal only with the exhaustion of the KVA space. It assumes that the buffer pool still has bp's available. That is why there was a panic. I think the proper solution is to have getnewbuf() speed up the syncer daemon to retire the dirty buffers in the case where getnewbuf() gets itself tied into knots, then wait and return NULL. Also, I think we need to implement a hard wait if numfreebuffers < lofreebuffers and the caller to getnewbuf() is not the syncer daemon ( update_proc ), but allow it otherwise. writerecursion would then simply block waiting for the syncer when it gets too big rather then panic. It actually doesn't look too complex. I'll mess with Matt's test code. -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 Tue Feb 23 1:26:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp2.tig.com.au (smtp2.tig.com.au [209.76.102.3]) by hub.freebsd.org (Postfix) with ESMTP id D82AF112ED; Tue, 23 Feb 1999 01:26:23 -0800 (PST) (envelope-from z2172268@student.unsw.edu.au) Received: from student.unsw.edu.au (p59-max2.syd.ihug.com.au [207.214.7.123]) by smtp2.tig.com.au (8.9.1/8.9.1) with ESMTP id UAA19836; Tue, 23 Feb 1999 20:26:20 +1100 Message-ID: <36D23C91.F39053E9@student.unsw.edu.au> Date: Tue, 23 Feb 1999 16:28:49 +1100 From: chris/reman X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: hackers@freebsd.org, questions@freebsd.org Subject: CDROM detection problems 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 have sent this to hackers and questions just in case. I have one hard drive which is master first controller, I have a pioneer A04s 32x cdrom as a slave on the secondary controller. I insert FreeBSD 2.2.6 CDROM, ATAPI boot works and sysinstall is started from the CDROM. Go straight into probe. wd0 is detected along with the hard drive. however when we get to wd1 it is not detected at all. I have tried setting flags, rebooting from dos etc etc. It detects under linux and win95. Abit BH6 celeron 333a 128mb ram ibm deskstar hdd CL banshee NE2000 PCI network card AWE64 I have searched the PR's and the mailing list search is not available. Is this just related to the BH6? do I need to upgrade to >2.2.6. The cdrom has worked fine on my old TX motherboard and under 2.2.6 and 2.2.7 If any more info is needed just write back and tell me what. regards, chris -- Christopher Day E-Mail the_reman@hotmail.com Homepage http://www.geocities.com/TimesSquare/Lair/1218 when the rain/when the children reign/keep your conscience in the dark melt the statues in the park - Fall On Me, REM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 1:33:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pens.ion.sci.fi (pens.ion.sci.fi [195.74.8.141]) by hub.freebsd.org (Postfix) with ESMTP id 4BF1810ED5 for ; Tue, 23 Feb 1999 01:33:33 -0800 (PST) (envelope-from kaipila@pens.ion.sci.fi) Received: (from kaipila@localhost) by pens.ion.sci.fi (8.8.8/8.8.8) id LAA17602; Tue, 23 Feb 1999 11:33:31 +0200 (EET) (envelope-from kaipila) To: hackers@freebsd.org Subject: glibstdc 2.8 and linux emulation From: Antti Kaipila Date: 23 Feb 1999 11:33:30 +0200 Message-ID: <87u2wdea6t.fsf@pens.ion.sci.fi> Lines: 10 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Any pointers how to get glibstdc 2.8 to work with linux applications under FreeBSD's linux emulation. I don't have access to any linux machine right now. The purpose is to get Linux Office Suite 99's Applixware running under FreeBSD. -- Antti Kaipila To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 4:28:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rnocserv.urc.ac.ru (rnocserv.urc.ac.ru [193.233.85.48]) by hub.freebsd.org (Postfix) with ESMTP id CAA1F111F9 for ; Tue, 23 Feb 1999 04:28:14 -0800 (PST) (envelope-from joy@urc.ac.ru) Received: from urc.ac.ru (y.urc.ac.ru [193.233.85.37]) by rnocserv.urc.ac.ru (8.8.8/8.8.8) with ESMTP id RAA23935 for ; Tue, 23 Feb 1999 17:27:53 +0500 (ES) (envelope-from joy@urc.ac.ru) Message-ID: <36D29EC9.27B554DA@urc.ac.ru> Date: Tue, 23 Feb 1999 17:27:53 +0500 From: Konstantin Chuguev Organization: Southern Regional Center of FREEnet X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-STABLE i386) X-Accept-Language: ru, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: ELF default format vs. a.out default binary name Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! Just curious: if ELF is the default binary file format now, then why gcc still produces a.out file by default? Well, I know, I've changed the reason and the consequence, so it's a kind of joke :-) -- Konstantin V. Chuguev. System administrator of Southern http://www.urc.ac.ru/~joy/ Ural Regional Center of FREEnet, mailto:joy@urc.ac.ru Chelyabinsk, Russia. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 4:56: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.ucb.crimea.ua (relay.ucb.crimea.ua [212.110.138.1]) by hub.freebsd.org (Postfix) with ESMTP id DF5FF10F61 for ; Tue, 23 Feb 1999 04:54:40 -0800 (PST) (envelope-from ru@ucb.crimea.ua) Received: (from ru@localhost) by relay.ucb.crimea.ua (8.9.2/8.9.2/UCB) id OAA86065; Tue, 23 Feb 1999 14:44:16 +0200 (EET) (envelope-from ru) Date: Tue, 23 Feb 1999 14:44:15 +0200 From: Ruslan Ermilov To: Konstantin Chuguev Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ELF default format vs. a.out default binary name Message-ID: <19990223144415.A86038@ucb.crimea.ua> Mail-Followup-To: Konstantin Chuguev , freebsd-hackers@FreeBSD.ORG References: <36D29EC9.27B554DA@urc.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.17i In-Reply-To: <36D29EC9.27B554DA@urc.ac.ru>; from Konstantin Chuguev on Tue, Feb 23, 1999 at 05:27:53PM +0500 X-Operating-System: FreeBSD 3.1-STABLE i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 23, 1999 at 05:27:53PM +0500, Konstantin Chuguev wrote: > Hi! > > Just curious: if ELF is the default binary file format now, then why gcc > still produces a.out file by default? > > Well, I know, I've changed the reason and the consequence, so it's a > kind of joke :-) > Either set OBJFORMAT=elf or put this line into /etc/objformat. -- Ruslan Ermilov Sysadmin and DBA of the ru@ucb.crimea.ua United Commercial Bank +380.652.247.647 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 5: 0:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rnocserv.urc.ac.ru (rnocserv.urc.ac.ru [193.233.85.48]) by hub.freebsd.org (Postfix) with ESMTP id 19D881110D for ; Tue, 23 Feb 1999 04:58:32 -0800 (PST) (envelope-from joy@urc.ac.ru) Received: from urc.ac.ru (y.urc.ac.ru [193.233.85.37]) by rnocserv.urc.ac.ru (8.8.8/8.8.8) with ESMTP id RAA24514; Tue, 23 Feb 1999 17:56:42 +0500 (ES) (envelope-from joy@urc.ac.ru) Message-ID: <36D2A58A.B6571F5B@urc.ac.ru> Date: Tue, 23 Feb 1999 17:56:42 +0500 From: Konstantin Chuguev Organization: Southern Regional Center of FREEnet X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-STABLE i386) X-Accept-Language: ru, en MIME-Version: 1.0 To: Ruslan Ermilov Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ELF default format vs. a.out default binary name References: <36D29EC9.27B554DA@urc.ac.ru> <19990223144415.A86038@ucb.crimea.ua> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ruslan Ermilov wrote: > On Tue, Feb 23, 1999 at 05:27:53PM +0500, Konstantin Chuguev wrote: > > Hi! > > > > Just curious: if ELF is the default binary file format now, then why gcc > > still produces a.out file by default? > > > > Well, I know, I've changed the reason and the consequence, so it's a > > kind of joke :-) > > > > Either set OBJFORMAT=elf or put this line into /etc/objformat. > Oh, sorry, I wrote not accurately. I meant, if you don't set -o option in gcc, then the file will be named a.out, even if it's in ELF format :-) -- Konstantin V. Chuguev. System administrator of Southern http://www.urc.ac.ru/~joy/ Ural Regional Center of FREEnet, mailto:joy@urc.ac.ru Chelyabinsk, Russia. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 6:31:15 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 A678610EDE for ; Tue, 23 Feb 1999 06:31:11 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id GAA20620; Tue, 23 Feb 1999 06:30:44 -0800 Date: Tue, 23 Feb 1999 06:30:44 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Doug Rabson Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday 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, 23 Feb 1999, Doug Rabson wrote: > On Mon, 22 Feb 1999, Matthew Jacob wrote: > > > > > > > > > Check the code paths and look for B_ASYNC getting unset. I believe this > > > > is the correct patch. > > > > > > As I said before, the reads and writes in question are not delayed writes. > > > The reason I have a problem is that the i/o queue in the driver has grown > > > to an obscene length, increasing latency to unreasonable levels. Changing > > > the order of processing delayed writes is irrelavent to this problem. > > > > This isn't a new problem. When I did driver level clustering at Sun back in > > 1990, I was regularly seeing queue lengths in excess of 1000 for a 16MB > > memory Sparc2. > > Thats a lot of memory to be using in a 16Mb box. Was the machine still > usable with this kind of i/o load? > Not really for interactive performance, no. But it did keep serving files. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 6:45:40 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 39E0A1115B for ; Tue, 23 Feb 1999 06:45:37 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id JAA02311; Tue, 23 Feb 1999 09:44:38 -0500 (EST) (envelope-from luoqi) Date: Tue, 23 Feb 1999 09:44:38 -0500 (EST) From: Luoqi Chen Message-Id: <199902231444.JAA02311@lor.watermarkgroup.com> To: dfr@nlsystems.com, dillon@apollo.backplane.com Subject: Re: Panic in FFS/4.0 as of yesterday - update Cc: freebsd-hackers@FreeBSD.ORG, mjacob@feral.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :I would suggest disabling it entirely to see if the system survives any > :better. If that helps, perhaps it should be using a field in struct proc > :to record the recursion depth. > : > :-- > :Doug Rabson Mail: dfr@nlsystems.com > :Nonlinear Systems Ltd. Phone: +44 181 442 9037 > > No, don't disable it. Unless you want the process to overflow it's > supervisor stack, that is! > It won't overflow kernel stack in this case, which was reentrancy rather than recursion. I don't see any real danger of recursion unless there's a broken layered FS implementation, which the comment says it tries to protect against, in which case we really should fix the fs instead. > The code is obviously broken, but disabling it will break it even worse. > > The write recursion test could actually be used as a count of the number > of I/O's which are 'starting up' ( verses in progress ). It's an obvious > failure as a stack recursion counter but judging from the comments, it > was designed to handle both conditions. > I don't think the code was designed to protect from too many 'starting up' I/O's (it would not panic if this is the case), but true run-away situations. > What appears to be happening is that both the buffer pool and the KVA > space for the buffer pool is being exhausted. The code appears to be > designed to deal only with the exhaustion of the KVA space. It assumes > that the buffer pool still has bp's available. That is why there was > a panic. > There's a test for numfreebuffers < lofreebuffers in getblk(), so there should still be bufs available and must be on the EMPTY queue, but couldn't be used because of the exhaustion of KVA space. > I think the proper solution is to have getnewbuf() speed up the syncer > daemon to retire the dirty buffers in the case where getnewbuf() > gets itself tied into knots, then wait and return NULL. Also, I think This sounds good. There's a variable just for that: rushjob :) > we need to implement a hard wait if numfreebuffers < lofreebuffers The test is in getblk(), but I agree it belongs to getnewbuf(). > and the caller to getnewbuf() is not the syncer daemon ( update_proc ), I'm not sure if this exemption is useful -- there's not much we can do if we run out of KVA space. > but allow it otherwise. writerecursion would then simply block waiting > for the syncer when it gets too big rather then panic. > Then the name "writerecursion" would be a little misleading, now it becomes a variable to limit too many async I/O's being started at one time. > It actually doesn't look too complex. I'll mess with Matt's test code. > > -Matt > Matthew Dillon > > -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 8: 2:25 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 6AB7711594 for ; Tue, 23 Feb 1999 08:02:21 -0800 (PST) (envelope-from ambrisko@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id HAA16471 for ; Tue, 23 Feb 1999 07:56:58 -0800 (PST) Received: from crab.whistle.com(207.76.205.112), claiming to be "whistle.com" via SMTP by alpo.whistle.com, id smtpdL16469; Tue Feb 23 15:56:50 1999 Received: (from ambrisko@localhost) by whistle.com (8.9.1/8.9.1) id HAA76796 for freebsd-hackers@FreeBSD.ORG; Tue, 23 Feb 1999 07:56:43 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <199902231556.HAA76796@whistle.com> Subject: Re: Oskit and 3.0? In-Reply-To: <199902230450.FAA29749@dorifer.heim3.tu-clausthal.de> from Oliver Fromme at "Feb 23, 99 05:50:15 am" To: freebsd-hackers@FreeBSD.ORG Date: Tue, 23 Feb 1999 07:56:43 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL29 (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 Oliver Fromme writes: | (Cc: to ambrisko@whistle.com) | | Doug Ambrisko wrote in list.freebsd-hackers: | > Julian Elischer writes: | > | we netboot elf kernels and aout kernels here.. | > | check with doug ambrisko (ambrisko@whistle.com) for his netbooting stuff. | > | > It would be nice if some commiter would commit pr: | > [1999/01/13] ports/9480 ports ELF kernel netboot | | I had a look at it. It doesn't seem to support loading of | configuration files like the new FreeBSD loader does (e.g. | to set up PnP), does it? Nope it doesn't yet. Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 8:18: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.nacamar.de (mail.nacamar.de [194.162.162.200]) by hub.freebsd.org (Postfix) with ESMTP id 83FA61113A for ; Tue, 23 Feb 1999 08:17:59 -0800 (PST) (envelope-from rohrbach@mail.nacamar.de) Received: (from rohrbach@localhost) by mail.nacamar.de (8.8.7/8.8.8MB-19980212) id RAA03354 for freebsd-hackers@FreeBSD.ORG; Tue, 23 Feb 1999 17:17:58 +0100 (CET) Message-ID: <19990223171758.C2095@nacamar.net> Date: Tue, 23 Feb 1999 17:17:58 +0100 From: "Karsten W. Rohrbach" To: freebsd-hackers@FreeBSD.ORG Subject: Re: ISA DMA problems if >= 512 Mb RAM? Reply-To: rohrbach@nacamar.net Mail-Followup-To: freebsd-hackers@FreeBSD.ORG References: <199902230339.EAA05604@dorifer.heim3.tu-clausthal.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.93.2i In-Reply-To: <199902230339.EAA05604@dorifer.heim3.tu-clausthal.de>; from Oliver Fromme on Tue, Feb 23, 1999 at 04:39:09AM +0100 X-Arbitrary-Number-Of-The-Day: 42 X-Sender: rohrbach@nacamar.net X-Organisation: Nacamar Data Communications GmbH X-Address: Robert-Bosch-Str. 32, 63303 Dreieich, Germany X-Phone: vox: +49 6103 993 870 fax: +49 6103 993 199 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG could it be, that there is some side effect with the graphics aperture mapping on intel bx chipset boards? i remember some similar problem with a linux box of a friend of mine, he got a 1542b for scanner connection and the driver refused to alloc the dma buffers. when we changed the graphics aperture from (default) 64mb to 32mb it suddenly worked. dont ask me any details, this was quite a while ago and i am not dug this deep into hardware/bios/motherboard issues... /k Oliver Fromme (olli@dorifer.heim3.tu-clausthal.de) @ Tue, Feb 23, 1999 at 04:39:09AM +0100: > Frank Nobis wrote in list.freebsd-hackers: > > [...] > > I have a P2B-DS with 512 M Ram and AWE64 > > > > Until today I had the same problem. Today I build a new kernel and now > > the problem ist gone. > > Did you change anything significant in your kernel config? > Maybe you threw some drivers away which made the kernel take > up less memory? > > Can you send a diff of your dmesg output from before (when > the problem still existed) and after (when it went away), > please? > > > real memory = 536870912 (524288K bytes) > > avail memory = 519380992 (507208K bytes) > > I'm specifically interested in these two lines. ;-) > > I'd be very happy if the problem is really fixed... However, > this is a production machine, so going to 4.0-current is not > what I intended... > > Regards > Oliver > > -- > Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany > (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) > > "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" > (Terry Pratchett) > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- "The path of excess leads to the tower of wisdom." -- W. Blake http://www.nacamar.de - http://www.nacamar.net - http://www.webmonster.de http://www.apache.de - http://www.quakeforum.de - finger rohrbach@nacamar.net PGP Key fingerprint = F9 A0 DF 91 74 07 6A 1C 5F 0B E0 6B 4D CD 8C 44 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 9: 0:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from TomQNX.tomqnx.com (cpu2745.adsl.bellglobal.com [207.236.55.214]) by hub.freebsd.org (Postfix) with ESMTP id D5CB6113DD for ; Tue, 23 Feb 1999 09:00:49 -0800 (PST) (envelope-from tom@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m10FLCO-000I1oC; Tue, 23 Feb 1999 12:00:44 -0500 (EST) Message-Id: From: tom@tomqnx.com (Tom Torrance at home) Subject: Re: Missing files/directories In-Reply-To: <199902230332.WAA25146@loverso.southborough.ma.us> from John Robert LoVerso at "Feb 22, 1999 10:32:17 pm" To: john@loverso.southborough.ma.us (John Robert LoVerso) Date: Tue, 23 Feb 1999 12:00:43 -0500 (EST) Cc: hackers@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 Content-Length: 1422 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I just did a scan of the entire /usr/src/sys tree for \"\\.\" > > and \'\\.\' to see what code sections might be affected - mostly > > cache-handling. In quantity, not bad, really. > > Tom, > > I assume by "dot files" you mean things like ".login" or ".profile". > The UNIX kernel does nothing special with these files compared to > files that don't start with a dot. Yes - I was writing them in groups of about 12, to /root (ufs,softupdates) and to /home/tom (nfsv2 mounted). > The special code you'll find in the kernel is for dealing with the > special "." and ".." links in each directory. This is wholey different > from files that begin with ".". Agreed in theory. When I am not writing dot files my systems are apparently rock solid. When I do, I occasionally lose other files or directories that need to be written. They definitely get queued for writing, but disappear from cache before actually getting written to the disk. FOr example, I had copies of all the modified dot files in "dot.xxx" format that I was writing to a directory "/etc/dotfiles". I copied them there and confirmed via "ls" that they were there. 10-15 minutes later, the same ls command would show /etc/dotfiles as entirely empty. Could there be a bug in the code somewhere that ostensibly deals with the "." and ".." files in the cache processing? Is there another theory as to what could cause such behaviour? Regards, Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 9: 7:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fleming.cs.strath.ac.uk (fleming.cs.strath.ac.uk [130.159.196.126]) by hub.freebsd.org (Postfix) with ESMTP id 74C7C1108E for ; Tue, 23 Feb 1999 09:05:47 -0800 (PST) (envelope-from roger@cs.strath.ac.uk) Received: from muir-11 (roger@muir-11.cs.strath.ac.uk [130.159.148.11]) by fleming.cs.strath.ac.uk (8.8.8/8.8.8) with SMTP id RAA12539 Tue, 23 Feb 1999 17:05:43 GMT Message-ID: <36D2DFE6.41C6@cs.strath.ac.uk> Date: Tue, 23 Feb 1999 17:05:43 +0000 From: Roger Hardiman Organization: University of Strathclyde X-Mailer: Mozilla 3.04Gold (X11; I; OSF1 V4.0 alpha) MIME-Version: 1.0 To: hackers@freebsd.org Subject: KLD (LKM) for PCI device 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 have a new PCI device which I want to write a device devier for (The PCI1750 32bit digital IO card). Are there any examples of writing a KLD for a PCI device. Thanks Roger Roger Hardiman roger@cs.strath.ac.uk roger@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 9:25:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gras-varg.worldgate.com (gras-varg.worldgate.com [198.161.84.12]) by hub.freebsd.org (Postfix) with ESMTP id 0C43111554 for ; Tue, 23 Feb 1999 09:25:17 -0800 (PST) (envelope-from skafte@gras-varg.worldgate.com) Received: (from skafte@localhost) by gras-varg.worldgate.com (8.9.1a/8.9.1) id KAA24049; Tue, 23 Feb 1999 10:25:10 -0700 (MST) Date: Tue, 23 Feb 1999 10:25:10 -0700 From: Greg Skafte To: David Wolfskill Cc: Freebsd-hackers@freebsd.org Subject: Re: kde Message-ID: <19990223102509.A23992@gras-varg.worldgate.com> References: <19990221211210.A12674@gras-varg.worldgate.com> <199902231544.HAA10281@pau-amma.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199902231544.HAA10281@pau-amma.whistle.com>; from David Wolfskill on Tue, Feb 23, 1999 at 07:44:16AM -0800 Organization: WorldGate Inc. X-PGP-Fingerprint: 42 9C 2C A8 4D 2B C9 C4 7D B6 00 B0 50 47 20 97 X-URL: http://gras-varg.worldgate.com/~skafte Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just cvsuped all the ports and then built the ports. one thing that you might check is that on my ports I do a "tag=." instead of tag=RELENG_3 when they add or patch ports they don't always move the TAG to the lastest cvs version. I also manually redid any dependant packages before the kde install to ensure that I had elf versions of things not aout. Quoting David Wolfskill (dhw@whistle.com) On Subject: Re: kde Date: Tue, Feb 23, 1999 at 07:44:16AM -0800 > >Date: Sun, 21 Feb 1999 21:12:10 -0700 > >From: Greg Skafte > > >Here's one for any of you kde11 users.... > > Well, I'm not one (shudder! :-)), but one of my colleagues was... until > we upgraded his box from 2.2.6-R to 3.0-SNAP-19990201. > > >I've got a 3.1-STABLE box running XFree86-3.3.3.1 > >It's a PII-333 (non-celeron) w/ 128M ram and a S3virge card. > > Well, I haven't been able to build the kde or kde11 ports -- either way, > it rolls over & dies during the build of Mesa3, with a whine about > collect2 being unable to find crt0.o. > > My colleage would *really* like to have kde back.... How did you > install it? > > Thanks, > david > -- > David Wolfskill UNIX System Administrator > dhw@whistle.com voice: (650) 577-7158 pager: (650) 371-4621 -- Email: skafte@worldgate.com Voice: +403 413 1910 Fax: +403 421 4929 #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 -- -- When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex. (Janet Morris) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 9:45:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.bitmine.com (adsl-209-233-238-103.dsl.pacbell.net [209.233.238.103]) by hub.freebsd.org (Postfix) with ESMTP id 26DB710E65 for ; Tue, 23 Feb 1999 09:45:36 -0800 (PST) (envelope-from rdas@bitmine.com) Received: from bitmine.com (doorknob.justintime.com [209.24.252.99]) by ns.bitmine.com (8.8.7/8.8.7) with ESMTP id JAA03598 for ; Tue, 23 Feb 1999 09:45:36 -0800 (PST) (envelope-from rdas@bitmine.com) Message-ID: <36D2E988.1F75E142@bitmine.com> Date: Tue, 23 Feb 1999 09:46:48 -0800 From: Rob Das X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: OTP only from FreeBSD Boxes? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is there any reason why the S/Key one time password stuff will only work from a FreeBSD or Unix client? In other words, I try telnetting in using a shareware telnet program "CRT" from any NT box and it disconnects me immediately after entering my login. It also fails after login if I telnet in from NT's telnet. When I login to a FreeBSD box and telenet in from there, the s/key stuff works fine. Any ideas? Thanks in advance. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 10:14:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dfw-ix12.ix.netcom.com (dfw-ix12.ix.netcom.com [206.214.98.12]) by hub.freebsd.org (Postfix) with ESMTP id 3056A110E0 for ; Tue, 23 Feb 1999 10:14:52 -0800 (PST) (envelope-from asami@stampede.cs.berkeley.edu) Received: (from smap@localhost) by dfw-ix12.ix.netcom.com (8.8.4/8.8.4) id MAA04950; Tue, 23 Feb 1999 12:14:44 -0600 (CST) Received: from sji-ca44-119.ix.netcom.com(209.111.212.247) by dfw-ix12.ix.netcom.com via smap (V1.3) id rma004776; Tue Feb 23 12:13:59 1999 Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.2/8.6.9) id KAA30585; Tue, 23 Feb 1999 10:13:16 -0800 (PST) Date: Tue, 23 Feb 1999 10:13:16 -0800 (PST) Message-Id: <199902231813.KAA30585@silvia.hip.berkeley.edu> To: skafte@worldgate.com Cc: dhw@whistle.com, Freebsd-hackers@freebsd.org In-reply-to: <19990223102509.A23992@gras-varg.worldgate.com> (message from Greg Skafte on Tue, 23 Feb 1999 10:25:10 -0700) Subject: Re: kde From: asami@freebsd.org (Satoshi Asami) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * From: Greg Skafte * I just cvsuped all the ports and then built the ports. one thing that you * might check is that on my ports I do a "tag=." instead of tag=RELENG_3 * when they add or patch ports they don't always move the TAG to the lastest * cvs version. This is a little inaccurate. We don't have any branches in the ports tree (actually there are some but those are accidents). You will just get an empty tree if you really try RELENG_3. :) If you want a specific release version, then you can, for instance, use RELEASE_3_1_0 or some such to get the ports tree for 3.1R. Satsohi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 10:48: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id D7B92114CE for ; Tue, 23 Feb 1999 10:48:05 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA51270; Tue, 23 Feb 1999 10:48:01 -0800 (PST) (envelope-from dillon) Date: Tue, 23 Feb 1999 10:48:01 -0800 (PST) From: Matthew Dillon Message-Id: <199902231848.KAA51270@apollo.backplane.com> To: Luoqi Chen Cc: dfr@nlsystems.com, dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG, mjacob@feral.com Subject: Re: Panic in FFS/4.0 as of yesterday - update References: <199902231444.JAA02311@lor.watermarkgroup.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> No, don't disable it. Unless you want the process to overflow it's :> supervisor stack, that is! :> :It won't overflow kernel stack in this case, which was reentrancy rather :than recursion. I don't see any real danger of recursion unless there's :a broken layered FS implementation, which the comment says it tries to :protect against, in which case we really should fix the fs instead. getnewbuf() is starting vfs_bio_awrite()'s on essentially random buffers - not necessarily just buffers related to the VFS recursion. This means that it is possible for it to recurse through unrelated bp's and overflow the stack. :> failure as a stack recursion counter but judging from the comments, it :> was designed to handle both conditions. :> :I don't think the code was designed to protect from too many 'starting up' :I/O's (it would not panic if this is the case), but true run-away situations. : :> I think the proper solution is to have getnewbuf() speed up the syncer :> daemon to retire the dirty buffers in the case where getnewbuf() :> gets itself tied into knots, then wait and return NULL. Also, I think : :This sounds good. There's a variable just for that: rushjob :) :> we need to implement a hard wait if numfreebuffers < lofreebuffers : :The test is in getblk(), but I agree it belongs to getnewbuf(). : :> and the caller to getnewbuf() is not the syncer daemon ( update_proc ), : :I'm not sure if this exemption is useful -- there's not much we can do if :we run out of KVA space. : :> but allow it otherwise. writerecursion would then simply block waiting :> for the syncer when it gets too big rather then panic. :> :Then the name "writerecursion" would be a little misleading, now it becomes :a variable to limit too many async I/O's being started at one time. : :-lq getnewbuf() appears to have the same problem that the ufs fsync code has -- it's assuming that when it converts a DELWRI bp to async, that the I/O operation will either be in-progress or completely resolved after the call. But there are cases, such as with softupdates, where this isn't true.. where the bp may be requeued synchronously due to their being unresolved dependancies. In this case, both getnewbuf() and the ufs fsync code will potentially loop on the same bp over and over again. -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 Tue Feb 23 10:57:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gras-varg.worldgate.com (gras-varg.worldgate.com [198.161.84.12]) by hub.freebsd.org (Postfix) with ESMTP id 654911161C; Tue, 23 Feb 1999 10:57:27 -0800 (PST) (envelope-from skafte@gras-varg.worldgate.com) Received: (from skafte@localhost) by gras-varg.worldgate.com (8.9.1a/8.9.1) id LAA24702; Tue, 23 Feb 1999 11:57:26 -0700 (MST) Date: Tue, 23 Feb 1999 11:57:26 -0700 From: Greg Skafte To: Satoshi Asami Cc: freebsd-hackers@freebsd.org Subject: Re: kde Message-ID: <19990223115725.E23992@gras-varg.worldgate.com> References: <19990223102509.A23992@gras-varg.worldgate.com> <199902231813.KAA30585@silvia.hip.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199902231813.KAA30585@silvia.hip.berkeley.edu>; from Satoshi Asami on Tue, Feb 23, 1999 at 10:13:16AM -0800 Organization: WorldGate Inc. X-PGP-Fingerprint: 42 9C 2C A8 4D 2B C9 C4 7D B6 00 B0 50 47 20 97 X-URL: http://gras-varg.worldgate.com/~skafte Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Quoting Satoshi Asami (asami@freebsd.org) On Subject: Re: kde Date: Tue, Feb 23, 1999 at 10:13:16AM -0800 > * From: Greg Skafte > > * I just cvsuped all the ports and then built the ports. one thing that you > * might check is that on my ports I do a "tag=." instead of tag=RELENG_3 > * when they add or patch ports they don't always move the TAG to the lastest > * cvs version. > > This is a little inaccurate. We don't have any branches in the ports > tree (actually there are some but those are accidents). > > You will just get an empty tree if you really try RELENG_3. :) > > If you want a specific release version, then you can, for instance, > use RELEASE_3_1_0 or some such to get the ports tree for 3.1R. > > Satsohi ok partially inaccurate I would do a tag=RELEASE_3_0_0 or now a RELEASE_3_1_0 but I found that in the case of kde11 that the RELEASE_3_0_0 tag was the beta where tag=. had the "latest" stuff..... -- Email: skafte@worldgate.com Voice: +403 413 1910 Fax: +403 421 4929 #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 -- -- When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex. (Janet Morris) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 11: 7: 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 65CCE11061 for ; Tue, 23 Feb 1999 11:07:01 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony [10.0.0.6]) by rover.village.org (8.9.3/8.6.6) with ESMTP id TAA02014; Tue, 23 Feb 1999 19:06:59 GMT Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.9.2/8.8.3) with ESMTP id EAA33058; Tue, 23 Feb 1999 04:08:41 -0700 (MST) Message-Id: <199902231108.EAA33058@harmony.village.org> To: Alfred Perlstein Subject: Re: Privileged port problems Cc: Allen Campbell , hackers@FreeBSD.org In-reply-to: Your message of "Mon, 22 Feb 1999 19:04:04 EST." References: Date: Tue, 23 Feb 1999 04:08:40 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Alfred Perlstein writes: : this resolved my issues, i'm too lazy to look if ssh requires the same : ports. I've turned off rsh stuff in my .ssh/config file so that it will slide through firewalls with more ease. Host * RhostsRSAAuthentication no RhostsAuthentication no FallBackToRsh no UseRsh no PasswordAuthentication no Maybe the above is overkill, and all you need is the UseRsh and RhostsAuthentication lines, but a little extra tightness never hurt anything :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 11: 7:21 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 3057E11118 for ; Tue, 23 Feb 1999 11:07:07 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony [10.0.0.6]) by rover.village.org (8.9.3/8.6.6) with ESMTP id TAA02011; Tue, 23 Feb 1999 19:06:58 GMT Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.9.2/8.8.3) with ESMTP id EAA33071; Tue, 23 Feb 1999 04:10:30 -0700 (MST) Message-Id: <199902231110.EAA33071@harmony.village.org> To: freebsd-hackers@FreeBSD.org Subject: Re: Oskit and 3.0? Cc: ambrisko@whistle.com In-reply-to: Your message of "Tue, 23 Feb 1999 05:50:15 +0100." <199902230450.FAA29749@dorifer.heim3.tu-clausthal.de> References: <199902230450.FAA29749@dorifer.heim3.tu-clausthal.de> Date: Tue, 23 Feb 1999 04:10:30 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199902230450.FAA29749@dorifer.heim3.tu-clausthal.de> Oliver Fromme writes: : to set up PnP), does it? How does one do this? I can't find a man page for it. a man poitner would suffice. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 11:14:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dfw-ix2.ix.netcom.com (dfw-ix2.ix.netcom.com [206.214.98.2]) by hub.freebsd.org (Postfix) with ESMTP id 5C096110BE for ; Tue, 23 Feb 1999 11:14:34 -0800 (PST) (envelope-from asami@stampede.cs.berkeley.edu) Received: (from smap@localhost) by dfw-ix2.ix.netcom.com (8.8.4/8.8.4) id NAA28617; Tue, 23 Feb 1999 13:14:25 -0600 (CST) Received: from sji-ca44-119.ix.netcom.com(209.111.212.247) by dfw-ix2.ix.netcom.com via smap (V1.3) id rma028498; Tue Feb 23 13:14:02 1999 Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.2/8.6.9) id LAA30778; Tue, 23 Feb 1999 11:13:38 -0800 (PST) Date: Tue, 23 Feb 1999 11:13:38 -0800 (PST) Message-Id: <199902231913.LAA30778@silvia.hip.berkeley.edu> To: skafte@worldgate.com Cc: freebsd-hackers@freebsd.org In-reply-to: <19990223115725.E23992@gras-varg.worldgate.com> (message from Greg Skafte on Tue, 23 Feb 1999 11:57:26 -0700) Subject: Re: kde From: asami@freebsd.org (Satoshi Asami) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * From: Greg Skafte * ok partially inaccurate I would do a tag=RELEASE_3_0_0 or now a RELEASE_3_1_0 * but I found that in the case of kde11 that the RELEASE_3_0_0 tag was the beta * where tag=. had the "latest" stuff..... Assuming I'm understanding you correctly, you're confusing branch tags with (release) tags. I'm saying that there is no RELENG_* in the ports tree because that's a branch tag. There do exist RELEASE_* tags which are basically "snapshots" of a given release date. So, with RELEASE_3_1_0, you get the tree in the shape when 3.1R was released. Since these are snapshots, they never move, so you won't get anything new by cvsupping with those tags daily. Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 11:19:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cc942873-a.ewndsr1.nj.home.com (cc942873-a.ewndsr1.nj.home.com [24.2.89.207]) by hub.freebsd.org (Postfix) with ESMTP id 44A541110A for ; Tue, 23 Feb 1999 11:18:50 -0800 (PST) (envelope-from cjc@cc942873-a.ewndsr1.nj.home.com) Received: (from cjc@localhost) by cc942873-a.ewndsr1.nj.home.com (8.9.3/8.8.8) id OAA26914 for freebsd-hackers@freebsd.org; Tue, 23 Feb 1999 14:20:28 -0500 (EST) (envelope-from cjc) From: "Crist J. Clark" Message-Id: <199902231920.OAA26914@cc942873-a.ewndsr1.nj.home.com> Subject: inetd Output To: freebsd-hackers@freebsd.org Date: Tue, 23 Feb 1999 14:20:28 -0500 (EST) Reply-To: cjclark@home.com X-Mailer: ELM [version 2.4ME+ PL40 (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 [Originally sent to -questions, but I _think_ this is a better venue] I just had a really ugly problem with a mailserver at work. It's a little ol' PentiumPro with 24 MB RAM and 60 MB of swap. In hindsight, I should have given it more swap, but it never occured to me that POP and IMAP servers would be memory intensive. Someone mailed a 40+ MB file to another user. This combined with the load of some other people eating memory with IMAP and large mailspools caused the recipient of the 40+ MB file's IMAP daemon to fill the swap to the top. I had the user quit from IMAP, and I removed the big mail item using elm as root. Much credit to FreeBSD that such a situation did not cause Very Bad Things to happen, like a panic, crash, or freeze up (I know I wouldn't trust my IRIX machines to survive a full swap partition). Once I had removed the offending mail and the user's IMAP process had shutdown gracefully, I had assumed everything would be OK, but... Some bad behavior from both the inetd on the FreeBSD server, and Outlook POP and IMAP clients gave me headaches. The inetd process was returning a (this is from memory, I can't seem to find any logs of the exact message), Warning: inetd: realloc(): junk pointer too low Message to connecting clients. inetd continued to return these after the swap problem had been fixed and even after a 'killall -HUP inetd.' Further, when Outlook catches this warning message, it gives up as if it was a fatal error (which it is not, Netscape clients worked fine). I ended up fixing the problem by killing inted completely and restarting it. I did not have to restart the kernel (this machine has been up a reasonable 60 days or so). Has anyone seen behavior like this from inetd before? I occasionally get those 'junk pointer' messages on several of my FreeBSD systems for a number of different applications, is that unusual? Is there a way to stop this? I worry that junk pointer messages might be the sign of a memory leak. System info, # uname -a FreeBSD newmail.mydomain.org 2.2.7-RELEASE FreeBSD 2.2.7-RELEASE #1: Tue Dec 22 15:29:51 EST 1998 postman@newmail.mydomain.org:/usr/src/sys/compile/NEWMAIL i386 -- Crist J. Clark cjclark@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 11:21:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (Postfix) with SMTP id 994AD11061 for ; Tue, 23 Feb 1999 11:21:54 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 12557 invoked from network); 23 Feb 1999 19:21:52 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 23 Feb 1999 19:21:52 -0000 Received: (from toor@localhost) by y.dyson.net (8.9.1/8.9.1) id OAA03755; Tue, 23 Feb 1999 14:21:49 -0500 (EST) Message-Id: <199902231921.OAA03755@y.dyson.net> Subject: Re: cdrom.com bandwidth limits In-Reply-To: <199902222128.OAA15308@harmony.village.org> from Warner Losh at "Feb 22, 99 02:28:11 pm" To: imp@village.org (Warner Losh) Date: Tue, 23 Feb 1999 14:21:49 -0500 (EST) Cc: vincef@penmax.com, dennis@etinc.com, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (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 Warner Losh said: > > I'm usually bandwidth limited by the T1 that is my connection to the > outside world, so I usually see 100-140kBps. > > This is about 1000-1400 kbps, which is near the max 1500 kbps a T1 > supports. > approx: 1500 / (8bits + epsilon) or 187Kbytes/sec. It is not likely to get that much due to protocol overheads, but I have seen >160KBytes/sec on a good T1. Don't T1's do bit stealing for signalling (I forget?) So, the "epsilon" above should account for that. It all depends on type of T1 (T1 is a hardware transport, that mostly implies some of the upper levels also, but you can have a T1 type transport for PRI ISDN also.) Most people do mean the standard T1 when they say T1 though. Framing (or byte) overheads suck away bandwdith, and the T1 is pretty good in that area. Some people don't realize that the T1 is bidirectional also (most people who work with them do realize this though.) This is a bit of a bonus, so you can sustain 150Kbytes/sec inward and outward. (I just realized that I am also sending this to dennis@etinc.com :-), correct me if I am wrong :-)). -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 11:26:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gras-varg.worldgate.com (gras-varg.worldgate.com [198.161.84.12]) by hub.freebsd.org (Postfix) with ESMTP id 366F610E7C; Tue, 23 Feb 1999 11:26:16 -0800 (PST) (envelope-from skafte@gras-varg.worldgate.com) Received: (from skafte@localhost) by gras-varg.worldgate.com (8.9.1a/8.9.1) id MAA24915; Tue, 23 Feb 1999 12:26:16 -0700 (MST) Date: Tue, 23 Feb 1999 12:26:16 -0700 From: Greg Skafte To: Satoshi Asami Cc: freebsd-hackers@freebsd.org Subject: Re: kde Message-ID: <19990223122615.F23992@gras-varg.worldgate.com> References: <19990223115725.E23992@gras-varg.worldgate.com> <199902231913.LAA30778@silvia.hip.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199902231913.LAA30778@silvia.hip.berkeley.edu>; from Satoshi Asami on Tue, Feb 23, 1999 at 11:13:38AM -0800 Organization: WorldGate Inc. X-PGP-Fingerprint: 42 9C 2C A8 4D 2B C9 C4 7D B6 00 B0 50 47 20 97 X-URL: http://gras-varg.worldgate.com/~skafte Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Quoting Satoshi Asami (asami@freebsd.org) On Subject: Re: kde Date: Tue, Feb 23, 1999 at 11:13:38AM -0800 > * From: Greg Skafte > > * ok partially inaccurate I would do a tag=RELEASE_3_0_0 or now a RELEASE_3_1_0 > * but I found that in the case of kde11 that the RELEASE_3_0_0 tag was the beta > * where tag=. had the "latest" stuff..... > > Assuming I'm understanding you correctly, you're confusing branch tags > with (release) tags. I'm saying that there is no RELENG_* in the > ports tree because that's a branch tag. yup ... except for the odd one that sneaks in .... > > There do exist RELEASE_* tags which are basically "snapshots" of a > given release date. So, with RELEASE_3_1_0, you get the tree in the > shape when 3.1R was released. Since these are snapshots, they never > move, so you won't get anything new by cvsupping with those tags > daily. > > Satoshi exactly, so to get the daily changes to the ports tree you need tag=. -- Email: skafte@worldgate.com Voice: +403 413 1910 Fax: +403 421 4929 #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 -- -- When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex. (Janet Morris) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 11:32:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.scl.ameslab.gov (mailhub.scl.ameslab.gov [147.155.137.127]) by hub.freebsd.org (Postfix) with ESMTP id 322781105F for ; Tue, 23 Feb 1999 11:32:12 -0800 (PST) (envelope-from ghelmer@scl.ameslab.gov) Received: from demios.ether.scl.ameslab.gov ([147.155.137.54]) by mailhub.scl.ameslab.gov with esmtp (Exim 1.90 #1) id 10FNZW-0001dw-00; Tue, 23 Feb 1999 13:32:46 -0600 Date: Tue, 23 Feb 1999 13:32:10 -0600 From: Guy Helmer To: cjclark@home.com Cc: freebsd-hackers@freebsd.org Subject: Re: inetd Output In-Reply-To: <199902231920.OAA26914@cc942873-a.ewndsr1.nj.home.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, 23 Feb 1999, Crist J. Clark wrote: > I just had a really ugly problem with a mailserver at work. It's a > little ol' PentiumPro with 24 MB RAM and 60 MB of swap. In hindsight, > I should have given it more swap, but it never occured to me that POP > and IMAP servers would be memory intensive. > ... > Some bad behavior from both the inetd on the FreeBSD server, and > Outlook POP and IMAP clients gave me headaches. The inetd process was > returning a (this is from memory, I can't seem to find any logs of the > exact message), > > Warning: inetd: realloc(): junk pointer too low This is a well-known problem that seemed to appear with some frequency when machines ran low on swap space. It's been fixed in 3.1-RELEASE. A different fix for the same problem is in 2.2-STABLE. You might be able to build the inetd sources from ftp://ftp.freebsd.org/pub/FreeBSD/3.1-STABLE/src/usr.sbin/inetd/ or, if that doesn't work, ftp://ftp.freebsd.org/pub/FreeBSD/2.2.8-STABLE/src/usr.sbin/inetd/ and use it on your 2.2.7 system until you can upgrade to 2.2.8-STABLE or 3.1. Guy Guy Helmer, Ph.D. Candidate, Iowa State University Dept. of Computer Science Research Assistant, Ames Laboratory --- ghelmer@scl.ameslab.gov Research Assistant, Dept. of Computer Science --- ghelmer@cs.iastate.edu http://www.cs.iastate.edu/~ghelmer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 11:35:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id 3C63B11222; Tue, 23 Feb 1999 11:35:00 -0800 (PST) (envelope-from bright@cygnus.rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.8.7/8.8.7) with SMTP id OAA24733; Tue, 23 Feb 1999 14:57:03 -0500 (EST) Date: Tue, 23 Feb 1999 14:57:02 -0500 (EST) From: Alfred Perlstein To: Greg Skafte Cc: Satoshi Asami , freebsd-hackers@FreeBSD.ORG Subject: Re: kde In-Reply-To: <19990223115725.E23992@gras-varg.worldgate.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, 23 Feb 1999, Greg Skafte wrote: > Quoting Satoshi Asami (asami@freebsd.org) > On Subject: Re: kde > Date: Tue, Feb 23, 1999 at 10:13:16AM -0800 > > > * From: Greg Skafte > > > > * I just cvsuped all the ports and then built the ports. one thing that you > > * might check is that on my ports I do a "tag=." instead of tag=RELENG_3 > > * when they add or patch ports they don't always move the TAG to the lastest > > * cvs version. > > > > This is a little inaccurate. We don't have any branches in the ports > > tree (actually there are some but those are accidents). > > > > You will just get an empty tree if you really try RELENG_3. :) > > > > If you want a specific release version, then you can, for instance, > > use RELEASE_3_1_0 or some such to get the ports tree for 3.1R. > > > > Satsohi > > ok partially inaccurate I would do a tag=RELEASE_3_0_0 or now a RELEASE_3_1_0 > but I found that in the case of kde11 that the RELEASE_3_0_0 tag was the beta > where tag=. had the "latest" stuff..... from: http://www.freebsd.org/handbook/cvsup.html (reformatted) WARNING: Be very careful to specify any "tag=" fields correctly. Some tags are valid only for certain collections of files. If you specify an incorrect or misspelled tag, CVSup will delete files which you probably do not want deleted. In particular, use only "tag=." for the "ports-*" collections. --end cvsup is very useful if for instance, you have a machine that you cannot upgrade, but you need a port, the current port doesn't seem to work, you can CVSup backwards to your particular SNAP do build the port. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 11:41:43 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 E7A141128F for ; Tue, 23 Feb 1999 11:41:40 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id OAA21444; Tue, 23 Feb 1999 14:30:01 -0500 (EST) (envelope-from luoqi) Date: Tue, 23 Feb 1999 14:30:01 -0500 (EST) From: Luoqi Chen Message-Id: <199902231930.OAA21444@lor.watermarkgroup.com> To: dillon@apollo.backplane.com Subject: Re: Panic in FFS/4.0 as of yesterday - update Cc: dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG, mjacob@feral.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :It won't overflow kernel stack in this case, which was reentrancy rather > :than recursion. I don't see any real danger of recursion unless there's > :a broken layered FS implementation, which the comment says it tries to > :protect against, in which case we really should fix the fs instead. > > getnewbuf() is starting vfs_bio_awrite()'s on essentially random > buffers - not necessarily just buffers related to the VFS recursion. > This means that it is possible for it to recurse through unrelated > bp's and overflow the stack. > Hmm, vfs_bio_awrite() only tries to write bufs already in core, no buffer reconstitution is needed. I fail to see why it would recurse back into getnewbuf(). > getnewbuf() appears to have the same problem that the ufs fsync code > has -- it's assuming that when it converts a DELWRI bp to async, that > the I/O operation will either be in-progress or completely resolved > after the call. But there are cases, such as with softupdates, where > this isn't true.. where the bp may be requeued synchronously due to > their being unresolved dependancies. In this case, both getnewbuf() > and the ufs fsync code will potentially loop on the same bp over > and over again. > Is this what caused the "bmsafemap" panic? I'll take a look. > -Matt > Matthew Dillon > > -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 12: 1:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hp9000.chc-chimes.com (hp9000.chc-chimes.com [206.67.97.84]) by hub.freebsd.org (Postfix) with ESMTP id 883A110E74 for ; Tue, 23 Feb 1999 12:01:03 -0800 (PST) (envelope-from billf@chc-chimes.com) Received: from localhost by hp9000.chc-chimes.com with SMTP (1.39.111.2/16.2) id AA244300058; Tue, 23 Feb 1999 15:00:58 -0500 Date: Tue, 23 Feb 1999 15:00:58 -0500 (EST) From: Bill Fumerola To: Greg Skafte Cc: David Wolfskill , Freebsd-hackers@FreeBSD.ORG Subject: Re: kde In-Reply-To: <19990223102509.A23992@gras-varg.worldgate.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, 23 Feb 1999, Greg Skafte wrote: > I just cvsuped all the ports and then built the ports. one thing that you > might check is that on my ports I do a "tag=." instead of tag=RELENG_3 > when they add or patch ports they don't always move the TAG to the lastest > cvs version. __ports are not branched!__ tag=. is ALWAYS the proper way to do it, and anything else is always the wrong way (and shouldn't even work). - 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 Feb 23 12:43:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 89D3A1143F for ; Tue, 23 Feb 1999 12:43:29 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA53144; Tue, 23 Feb 1999 12:43:22 -0800 (PST) (envelope-from dillon) Date: Tue, 23 Feb 1999 12:43:22 -0800 (PST) From: Matthew Dillon Message-Id: <199902232043.MAA53144@apollo.backplane.com> To: Luoqi Chen Cc: dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG, mjacob@feral.com Subject: Re: Panic in FFS/4.0 as of yesterday - update References: <199902231930.OAA21444@lor.watermarkgroup.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> getnewbuf() is starting vfs_bio_awrite()'s on essentially random :> buffers - not necessarily just buffers related to the VFS recursion. :> This means that it is possible for it to recurse through unrelated :> bp's and overflow the stack. :> :Hmm, vfs_bio_awrite() only tries to write bufs already in core, no buffer :reconstitution is needed. I fail to see why it would recurse back into :getnewbuf(). If there is no VFS layering, then true. If there *IS* VFS layering, then the VOP_BWRITE() may try to consistitute another buffer. For example, if you are going through a VN device which is file-backed, it must do a BMAP operation which may constitute a new buffer ( or several ). This will loop back to the getnewbuf() code, which then may decide to do the same thing all over again with a different random bp and cause another recursion. And so on. Until the supervisor stack goes poof. :> getnewbuf() appears to have the same problem that the ufs fsync code :> has -- it's assuming that when it converts a DELWRI bp to async, that :> the I/O operation will either be in-progress or completely resolved :> after the call. But there are cases, such as with softupdates, where :> this isn't true.. where the bp may be requeued synchronously due to :> their being unresolved dependancies. In this case, both getnewbuf() :> and the ufs fsync code will potentially loop on the same bp over :> and over again. :> :Is this what caused the "bmsafemap" panic? I'll take a look. It shouldn't be the cause... the bmsafemap panic wasn't supposed to occur at all, no matter what the dirty buffer situation. I currently have case added to report the BMSAFEMAP condition and ignore it, and all my problems went away. I've added debugging code supplied by Kirk ( just a vprintf(), really ) so when it happens again I'll be able to give him some more meaningful information in regards to the type of vnode the condition occured on. -Matt :-lq Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 12:56: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mailbox.reptiles.org (mailbox.reptiles.org [198.96.117.155]) by hub.freebsd.org (Postfix) with SMTP id 98DEB1162A; Tue, 23 Feb 1999 12:55:45 -0800 (PST) (envelope-from jim@reptiles.org) Received: from localhost (1617 bytes) by mailbox.reptiles.org via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) (ident using unix) id for ; Tue, 23 Feb 1999 15:55:44 -0500 (EST) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Nov-26) Message-Id: From: jim@reptiles.org (Jim Mercer) Subject: problems with the ep (ethernet) driver? 2.2.[67] To: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Date: Tue, 23 Feb 1999 15:55:44 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1182 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG we have a core router running 2.2.7. it has 2 PCI de ethernets, a PCI vx ethernet and an ISA ep ethernet. we have interior router running 2.2.6 with PCI de ethernets. the interior machine is connected to the ep ethernet of the core machine. recently, we swapped out the previous core router (was NetBSD with ed ethernet) for the above machine. since the swap, gated (running on both machines) seems to lose contact and the interior machine (and/or the core) decides that it can't pass packets over the route. oddly enough, if i fire up a tcpdump on the core router ep interface, packets start flowing instantly. my feeling is that for some reason, kicking the ep driver into promiscuous mode causes gated to retrun to normal operation. is there some bug with the ep driver, and promiscuous mode? or is it possibly a bug in gated, misinterpreting the ep driver? -- [ Jim Mercer Reptilian Research jim@reptiles.org +1 416 410-5633 ] [ The telephone, for those of you who have forgotten, was a commonly used ] [ communications technology in the days before electronic mail. ] [ They're still easy to find in most large cities. -- Nathaniel Borenstein ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 13:26: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id BA44A1141B for ; Tue, 23 Feb 1999 13:25:58 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id OAA10417; Tue, 23 Feb 1999 14:46:52 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd010258; Tue Feb 23 14:46:45 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id OAA13140; Tue, 23 Feb 1999 14:25:24 -0700 (MST) From: Terry Lambert Message-Id: <199902232125.OAA13140@usr06.primenet.com> Subject: Re: Panic in FFS/4.0 as of yesterday To: dfr@nlsystems.com (Doug Rabson) Date: Tue, 23 Feb 1999 21:25:24 +0000 (GMT) Cc: julian@whistle.com, Don.Lewis@tsc.tdk.com, tlambert@primenet.com, dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Doug Rabson" at Feb 23, 99 08:50:57 am 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 > > softupdates already "kinda" doesn this.. > > it queues data writes at one point in the future and directory writes > > at a different point in the future. I believe that data writes must be > > completed before inode writes which must be completed before directory > > writes. If they are not the the dependencies will FORCE that ordering. > > > > The reason to preschedule the different actions is to make it all happen > > in the right order anyhow, so that the dependency tracking is a big NOP. > > I think softupdates will be less affected by this but there can still be > problems with latency. The time for a simple directory read (not a > softupdate controlled operation) can be delayed significantly since it > gets queued behind all the rest of the async i/o. In Matt's test, I saw > about 5Mb queued at one point which translates to a latency of over > 0.5sec, assuming the drive throughput is about 8Mb/sec. Soft updates is still vulnerable to this, though directory operations are promoted forward, they are not grouped forward, so one set of file I/O can find itself in front of a set of (unrelated) directory I/O. I think the dangers are lessened by "clocking it forward", however; the worst interference is a process with itself, after queueing a tremendous amount of normal I/O before engaging in directory operations. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 13:53:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from eta.ee.fit.edu (eta.ee.fit.edu [163.118.30.136]) by hub.freebsd.org (Postfix) with ESMTP id 986BF11947 for ; Tue, 23 Feb 1999 13:52:53 -0800 (PST) (envelope-from cr@eta.ee.fit.edu) Received: from localhost (cr@localhost) by eta.ee.fit.edu (8.8.7/8.8.7) with SMTP id QAA23365 for ; Tue, 23 Feb 1999 16:38:26 -0500 Date: Tue, 23 Feb 1999 16:38:26 -0500 (EST) From: John Smith To: freebsd-hackers@freebsd.org Subject: /dev/lkm 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 All; I am on 3.1; and when I try to do modload. i get /dev/lkm not configured. Do I need to compile my kernel with a special keyword so that it supports loadable kernel modules, (/dev/lkm exists); or lkm does not exist anymore? Any ideas? Thanks; -John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 14: 2:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from schizo.cdsnet.net (schizo.cdsnet.net [204.118.244.32]) by hub.freebsd.org (Postfix) with ESMTP id 62FA41197F for ; Tue, 23 Feb 1999 14:02:29 -0800 (PST) (envelope-from mrcpu@internetcds.com) Received: from localhost (mrcpu@localhost) by schizo.cdsnet.net (8.8.8/8.7.3) with SMTP id NAA02966 for ; Tue, 23 Feb 1999 13:56:51 -0800 (PST) Date: Tue, 23 Feb 1999 13:56:51 -0800 (PST) From: Jaye Mathisen X-Sender: mrcpu@schizo.cdsnet.net To: hackers@freebsd.org Subject: Disk-on-chip? 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 was looking at some boards from siliconrax, and they have this feature called "Disk On Chip", which I assume is some big old chunk of flash-type memory. Has anybody seen anything like this, or better yet, booted FreeBSD using it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 14:27:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from awfulhak.org (awfulhak.force9.co.uk [195.166.136.63]) by hub.freebsd.org (Postfix) with ESMTP id 5ABD71140C; Tue, 23 Feb 1999 14:27:39 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (keep.lan.Awfulhak.org [172.16.0.8]) by awfulhak.org (8.8.8/8.8.8) with ESMTP id WAA01117; Tue, 23 Feb 1999 22:26:09 GMT (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (localhost [127.0.0.1]) by keep.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id IAA00707; Tue, 23 Feb 1999 08:22:47 GMT (envelope-from brian@keep.lan.Awfulhak.org) Message-Id: <199902230822.IAA00707@keep.lan.Awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: tom@tomqnx.com (Tom Torrance at home) Cc: hackers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Missing files/directories In-reply-to: Your message of "Mon, 22 Feb 1999 21:56:49 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Feb 1999 08:22:47 +0000 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I don't claim to know a great deal about cache code etc, but I'm pretty sure that it's extremely unlikely that the file name has any chance of affecting the buffer cache. While NFS has its fair share of problems (with which Matt is dealing with admirably), I would think that the code that does the work there is equally unlikely to know anything about file names. Having said all that in as vague a way as possible, the reason I'm posting this is that you seem to be experiencing difficulties with ppp that are of a similar nature - that is, completely inexplicable and unseen by anyone else - disappearing default routes, ppp.linkdown not being processed, I'm beginning to suspect a hardware problem - perhaps with your disk controller or something. This wouldn't easily explain the default route problem, but may explain the failure to process ppp.linkdown.... Maybe you could try treating the other machine (your son's machine?) as the gateway, and see if things become more stable. If they do, the finger might be pointed more firmly at hardware. > On the weekend I reported to hackers about problems experienced with > 2.2-stable and RELENG-3 systems where I experienced files that > disappeared from cache and Mail directories that disappeared. > The RELENG-3 system had files affected with softupdates enabled. > The 2.2-stable system had sub-directories missing from the > same directories that I was writing to via nfsv2. > > By coincidence, I had cvsup'd and compiled new kernels and naturally > made the assumption that there was causality there. Subsequently > I have come to believe that the problem may have more to do with what > I was doing, not changes to the code. > > For about 3-4 hours prior to noticing the problems, I had been > repetitively editing dot files, then writing a kludge of dot files > to the local system hard drive and to the nfs exported FS of the > other computer, while occasionally checking mail on that computer. > > All files and directories missing were being updated for > one reason or another by myself or by mail processes while > I was doing this. > > It is speculation, but there is a good chance that there is a bug > in the cache-handling code that causes problems with other files > or directories being dropped from cache because of bad processing > common to BOTH or ALL releases, when large numbers of dot files are > being written. The dot files themselves did not disappear - other > items to be written disappeared before their writes actually > occurred. > > I know that this is a frustrating kind of message to receive, but > I am not a developer & not qualified to go into the code myself. > Also no logs or hard output are available - files/directories > simply disappeared without any error messages. > > I just did a scan of the entire /usr/src/sys tree for \"\\.\" > and \'\\.\' to see what code sections might be affected - mostly > cache-handling. In quantity, not bad, really. > > Others have apparently reported missing files to do with nfs > I believe. THis might or might not be a related problem. > > I guess that I am asking someone who is qualified, and concerned > about missing files or directories, if they would be willing > to do what I cannot - check the code for bad interactions when > dot files are being written- bearing in mind that it is OTHER > files/directories that are disappearing from cache before being > written. > > Is anyone out there sufficiently intrigued by the possibility > to invest some valuable time? > > I am a QA tester, not a developer, and therefore much more > comfortable with discussion of symptoms and speculative > causality than most developers I have known. I hope that > someone thinks enough of the possibility to invest some > time, which I know is in very short supply. I cannot deny > that this is (informed) speculation - there are no guarantees. > > Regards and best wishes, > Tom -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 16:57:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 4BE1811061 for ; Tue, 23 Feb 1999 16:56:10 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id SAA11714; Tue, 23 Feb 1999 18:17:11 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpd011654; Tue Feb 23 18:17:04 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id RAA22403; Tue, 23 Feb 1999 17:55:51 -0700 (MST) From: Terry Lambert Message-Id: <199902240055.RAA22403@usr09.primenet.com> Subject: Re: ESTALE the best approach? To: toasty@home.dragondata.com (Kevin Day) Date: Wed, 24 Feb 1999 00:55:51 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <199902210737.BAA21850@home.dragondata.com> from "Kevin Day" at Feb 21, 99 01:37:42 am 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 > Forgetting standards and past practices, is ESTALE a good approach to > dealing with an NFS outage/reboot/whatever? > > Very few programs know how to deal with ESTALE, and I really have yet to see > one that knows how to recover from it. Programs have to be able to deal with errors. They either have specific per-error strategies, or they have an "all other errors" strategy. Is it right to put the onus of reestablishing the state onto the stateful application, instead of on the stateless NFS? The answer has traditionally been "yes". There is a fundamental breakdown in the idea of coding for transactions, and this is what has driven this decision. At some future point, when transaction guaranbtees are made by the kernel to user space applications, it may well be a good idea to revisit the idea of state recovery. Alternatively, at that time, it will still be the onus of the application to deal with transaction failures, either via implicit roll-back, or retry. > 28591 eggdrop 0.000037 CALL read(0x6,0xd6800,0x400) > 28591 eggdrop 0.000379 RET read -1 errno 70 Stale NFS file handle Whatever is calling this is not checking the return value for read. This is acceptable for tty's, since the tty is supposed to guarantee a signal to the process group leader, which is then sent to each process in the group as the group leade fails away, leaving each process a group leader (and thus subject to signal requirements). Some people will argue against this, using POSIX as evidence, but POSIX is a documentation of existing System V derived UNIX practice, so those people are arguably wrong because That's What SVR4 Does. > 28591 eggdrop 0.000381 RET read -1 errno 70 Stale NFS file handle > > Because they not realize that ESTALE is a fatal condition, or lots of > programs tend to just go bezerk at having a FD closed on them... It's not so much that they don't know how to handle ESTALE, it's more that they are (evilly) ignoring the -1 return from read. > I've been experimenting here with making any ESTALE return something other > than ESTALE, to see what happens. > > EBADF was nearly as bad, as most programs that couldn't deal with ESTALE > probably didn't expect a fd that they had already opened to be suddenly > closed. Plus it was never closed. The vnode is still hanging out. The EBADF'ed descriptor is unrecoverable, since only a stupid program would close an already closed fd. So the struct file * pointing to the vnode is also still hanging out. > EINVAL seemed to make most programs die on their own, but not all. Some also > left some very cryptic/wrong diagnostics behind. Well, that's because you gave it the wrong error code. 8-). > > My next step is going to be to make nfsrv_fhtovp(?) actually kill the > process instead of returning anything, in a final attempt to fix this, > locally. Is there some justification for treating ESTALE like a transient > error anyway? Did some implementation somewhere eventually restore things? Yes. The main problem is that the ESTALE does not trigger a remount attempt, like it should, and a subsequent cleanup of the mount specific portions of the outstanding NFSnodes. Generally, the remount attempt is signalled by statd. The ESTALE is actually a result of the mount going south, and not getting reset like it's supposed to be. In theory, it should never make user space, unless the remount attempts are time or attempt-count constrained by mount options. The only way you get a stale node is a server reboot, and that's as a result of the "security" cruft that was nont implemented link-layer like it should have been (packet sequence randomization, etc.). Basically, an operation was attempted against the server with an NFS mount that was invalid because the server reset the sequence base out from under you. NFS security was never intended to use weak techniques against session replay of plaintext; instead, it was intended to use DES or Kerberos, and not protect against replay at all (who care if you replay garbage?). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 17: 3:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from korin.warman.org.pl (korin.nask.waw.pl [195.187.243.10]) by hub.freebsd.org (Postfix) with ESMTP id 8734F11036 for ; Tue, 23 Feb 1999 17:02:01 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id CAA06679; Wed, 24 Feb 1999 02:09:37 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Wed, 24 Feb 1999 02:09:36 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Jaye Mathisen Cc: hackers@FreeBSD.ORG Subject: Re: Disk-on-chip? 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, 23 Feb 1999, Jaye Mathisen wrote: > > > I was looking at some boards from siliconrax, and they have this feature > called "Disk On Chip", which I assume is some big old chunk of flash-type > memory. > > Has anybody seen anything like this, or better yet, booted FreeBSD using > it? Yes, and yes. See the archives of freebsd-small. BTW, "big old chunk" doesn't give it a justice - it's quite modern and very useful. Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+-------+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| | 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 Tue Feb 23 17:15:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 256721117B for ; Tue, 23 Feb 1999 17:15:08 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA54511; Tue, 23 Feb 1999 17:15:08 -0800 (PST) (envelope-from dillon) Date: Tue, 23 Feb 1999 17:15:08 -0800 (PST) From: Matthew Dillon Message-Id: <199902240115.RAA54511@apollo.backplane.com> To: Terry Lambert Cc: toasty@home.dragondata.com (Kevin Day), hackers@FreeBSD.ORG Subject: Re: ESTALE the best approach? References: <199902240055.RAA22403@usr09.primenet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :> 28591 eggdrop 0.000037 CALL read(0x6,0xd6800,0x400) :> 28591 eggdrop 0.000379 RET read -1 errno 70 Stale NFS file handle : :Whatever is calling this is not checking the return value for read. :... :Yes. The main problem is that the ESTALE does not trigger a remount :attempt, like it should, and a subsequent cleanup of the mount specific :portions of the outstanding NFSnodes. : :Generally, the remount attempt is signalled by statd. : :The ESTALE is actually a result of the mount going south, and not :getting reset like it's supposed to be. In theory, it should never :make user space, unless the remount attempts are time or attempt-count :constrained by mount options. : :The only way you get a stale node is a server reboot, and that's as a :result of the "security" cruft that was nont implemented link-layer :like it should have been (packet sequence randomization, etc.). The most common occurance of ESTALE that I know of is when a file is deleted on an NFS server. This is an unrecoverable condition. That is, the open descriptor in question should return ESTALE forever. You'd have to reopen the file to fix it. It is not appropriate to automatically remount the file in that situation. For example, if someone on the server reinstalls a binary there is no way in hell a process already running that binary image on a client can recover. It must seg-fault, die, and be restarted. -Matt Matthew Dillon :Basically, an operation was attempted against the server with an :NFS mount that was invalid because the server reset the sequence :base out from under you. : :NFS security was never intended to use weak techniques against session :replay of plaintext; instead, it was intended to use DES or Kerberos, :and not protect against replay at all (who care if you replay garbage?). : : : Terry Lambert : terry@lambert.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 17:21:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bangkok.office.cdsnet.net (bangkok.office.cdsnet.net [204.118.245.23]) by hub.freebsd.org (Postfix) with ESMTP id 3EDE511559 for ; Tue, 23 Feb 1999 17:21:24 -0800 (PST) (envelope-from cts@bangkok.office.cdsnet.net) Received: (from cts@localhost) by bangkok.office.cdsnet.net (8.8.8/8.8.5) id RAA25148; Tue, 23 Feb 1999 17:21:24 -0800 (PST) Date: Tue, 23 Feb 1999 17:21:24 -0800 (PST) Message-Id: <199902240121.RAA25148@bangkok.office.cdsnet.net> X-Authentication-Warning: bangkok.office.cdsnet.net: cts set sender to cts@bangkok.office.cdsnet.net using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Craig Spannring To: hackers@FreeBSD.ORG Subject: CVS and Y2K X-Mailer: VM 6.31 under Emacs 20.3.1 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Does FreeBSD still ship with CVS version 1.9.26? If so it needs to be upgraded within the next 9 months or so. 1.9.26 can't parse dates past 1999-12-31. -- ======================================================================= Life is short. | Craig Spannring Ski hard, Bike fast. | cts@internetcds.com --------------------------------+------------------------------------ Any sufficiently horrible technology is indistinguishable from Perl. ======================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 17:31:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 7740B1117B for ; Tue, 23 Feb 1999 17:31:38 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id SAA00469; Tue, 23 Feb 1999 18:31:38 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp01.primenet.com, id smtpd000422; Tue Feb 23 18:31:33 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id SAA24606; Tue, 23 Feb 1999 18:31:26 -0700 (MST) From: Terry Lambert Message-Id: <199902240131.SAA24606@usr09.primenet.com> Subject: Re: Panic in FFS/4.0 as of yesterday To: dillon@apollo.backplane.com (Matthew Dillon) Date: Wed, 24 Feb 1999 01:31:26 +0000 (GMT) Cc: dfr@nlsystems.com, tlambert@primenet.com, freebsd-hackers@freebsd.org In-Reply-To: <199902220932.BAA29386@apollo.backplane.com> from "Matthew Dillon" at Feb 22, 99 01:32:25 am 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 > I don't think B_EXPIDITE could ever be made to work well. Why not limit > the number of async I/O write operations allowed to be in-progress at any > given moment for ops run by the syncer, swapper, or flushdirtybufs?. > Either on a vnode-by-vnode or a mount-by-mount basis? I do a poor-man's > version of this for the swapper. At least then the hacks would be > concentrated together rather then strewn all over the codebase. The > write queueing problem seems to be quite general in nature, which means > that the solution should not be to have to hack each and every device > that might do I/O ( aka UFS in this case ). Mostly, you don't want to do this because it destroys the reason for wanting to mount the thing async in the first place. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 17:33: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from home.dragondata.com (home.dragondata.com [204.137.237.2]) by hub.freebsd.org (Postfix) with ESMTP id 841311153C for ; Tue, 23 Feb 1999 17:33:00 -0800 (PST) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.9.2/8.9.2) id TAA25796; Tue, 23 Feb 1999 19:32:48 -0600 (CST) From: Kevin Day Message-Id: <199902240132.TAA25796@home.dragondata.com> Subject: Re: ESTALE the best approach? In-Reply-To: <199902240055.RAA22403@usr09.primenet.com> from Terry Lambert at "Feb 24, 1999 0:55:51 am" To: tlambert@primenet.com (Terry Lambert) Date: Tue, 23 Feb 1999 19:32:47 -0600 (CST) Cc: hackers@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 > > Forgetting standards and past practices, is ESTALE a good approach to > > dealing with an NFS outage/reboot/whatever? > > > > Very few programs know how to deal with ESTALE, and I really have yet to see > > one that knows how to recover from it. > > Programs have to be able to deal with errors. They either have > specific per-error strategies, or they have an "all other errors" > strategy. The problem I've seen is that some poorly designed software lists what it thinks are fatal, and everything else is to be retried. > > 28591 eggdrop 0.000037 CALL read(0x6,0xd6800,0x400) > > 28591 eggdrop 0.000379 RET read -1 errno 70 Stale NFS file handle > > 28591 eggdrop 0.000037 CALL read(0x6,0xd6800,0x400) > > 28591 eggdrop 0.000379 RET read -1 errno 70 Stale NFS file handle > > Whatever is calling this is not checking the return value for read. > Here for example, the executable checks for a few errors, if they don't match what it thinks are fatal, it retries. I'd think that good programming practice should be the reverse. Add what you know to be temporary, and everything else (and errors you don't even know about) should be fatal. > This is acceptable for tty's, since the tty is supposed to guarantee > a signal to the process group leader, which is then sent to each > process in the group as the group leade fails away, leaving each > process a group leader (and thus subject to signal requirements). > > Some people will argue against this, using POSIX as evidence, but > POSIX is a documentation of existing System V derived UNIX practice, > so those people are arguably wrong because That's What SVR4 Does. > I'm not even going to touch this argument waiting to happen. :) > > > 28591 eggdrop 0.000381 RET read -1 errno 70 Stale NFS file handle > > > > Because they not realize that ESTALE is a fatal condition, or lots of > > programs tend to just go bezerk at having a FD closed on them... > > It's not so much that they don't know how to handle ESTALE, it's > more that they are (evilly) ignoring the -1 return from read. Looking at the read(2) man page... The only error that could happen that isn't a result of a programming error that could happen on a standard file is 'EIO', which would probably be a hardware error. (At that point, when hardware fails, I consider any application's behavior as 'undefined', on the PC architecture) I can see why people aren't checking for errors on a read(2), really... Lots of FreeBSD's internal utilities don't do it, even. :) (however, most don't retry ad nausem in response to an error) > > > I've been experimenting here with making any ESTALE return something other > > than ESTALE, to see what happens. > > > > EBADF was nearly as bad, as most programs that couldn't deal with ESTALE > > probably didn't expect a fd that they had already opened to be suddenly > > closed. > > Plus it was never closed. The vnode is still hanging out. The > EBADF'ed descriptor is unrecoverable, since only a stupid program > would close an already closed fd. So the struct file * pointing to > the vnode is also still hanging out. > Eeep, I hadn't thought of that. I guess I realize that has to be true, otherwise you'd be getting EBADF. > > > > My next step is going to be to make nfsrv_fhtovp(?) actually kill the > > process instead of returning anything, in a final attempt to fix this, > > locally. Is there some justification for treating ESTALE like a transient > > error anyway? Did some implementation somewhere eventually restore things? > > Yes. The main problem is that the ESTALE does not trigger a remount > attempt, like it should, and a subsequent cleanup of the mount specific > portions of the outstanding NFSnodes. > > Generally, the remount attempt is signalled by statd. > > The ESTALE is actually a result of the mount going south, and not > getting reset like it's supposed to be. In theory, it should never > make user space, unless the remount attempts are time or attempt-count > constrained by mount options. > > The only way you get a stale node is a server reboot, and that's as a > result of the "security" cruft that was nont implemented link-layer > like it should have been (packet sequence randomization, etc.). > I'm actually seeing this on a network that has an 100MB ethernet segment exculsively for NFS. I'll see this: nfs server home.internal:/home: not responding nfs server home.internal:/home: is alive again in my syslog, with the timestamps being identical, and chances are, after that, one or two processes goes bezerk afterwards. I've mucked with the dynamic retry estimator, and other settings, and it still happens. I'm pretty sure the nfs server is responding just fine, because other nfs clients don't report the error at the same time. I realize I'm fixing the symptom, not the problem, but fixing NFS is not something I have the time for. :) (For reference, the server is 2.2.5, clients are 2.2.8 and 4.0... If I could get the 4.0 server to stay up long enough without getting deadlocked leaving all the clients in 'inode', I could tell you if the problem is in 4.0 as well) Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 17:35:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 3CF5D11590 for ; Tue, 23 Feb 1999 17:35:25 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id SAA28829; Tue, 23 Feb 1999 18:56:29 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpd028745; Tue Feb 23 18:56:20 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id SAA24729; Tue, 23 Feb 1999 18:35:00 -0700 (MST) From: Terry Lambert Message-Id: <199902240135.SAA24729@usr09.primenet.com> Subject: Re: Panic in FFS/4.0 as of yesterday To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Wed, 24 Feb 1999 01:34:59 +0000 (GMT) Cc: tlambert@primenet.com, dillon@apollo.backplane.com, dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199902221423.GAA28922@salsa.gv.tsc.tdk.com> from "Don Lewis" at Feb 22, 99 06:23:29 am 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 > } I think the way to "fix" this is to have two queue insertion points, > } and insert directory writes as far forward as you can (some pigs are > } more equal than others). This would ensure short duration for > } directory operations. > > What about directory reads? I think the same problem will occur if > they have long latencies. It's my understanding that having a single queue for both reads and write to a device went out with VMS. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 17:37:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 7C86D115DD for ; Tue, 23 Feb 1999 17:37:11 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id SAA29700; Tue, 23 Feb 1999 18:58:14 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpd029570; Tue Feb 23 18:58:11 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id SAA24815; Tue, 23 Feb 1999 18:36:50 -0700 (MST) From: Terry Lambert Message-Id: <199902240136.SAA24815@usr09.primenet.com> Subject: Re: Panic in FFS/4.0 as of yesterday To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Wed, 24 Feb 1999 01:36:50 +0000 (GMT) Cc: tlambert@primenet.com, dfr@nlsystems.com, dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199902221428.GAA28942@salsa.gv.tsc.tdk.com> from "Don Lewis" at Feb 22, 99 06:28:56 am 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 > } The correct way to do this, IMO, is a back-off/retry, which would > } unlock the lock and queue the operation for retry, which would > } reacquire the lock. > > Wouldn't you have to relock the parent before unlocking the lock (nasty > because it reverses the locking order and might cause a deadlock). You would have to unlock the child *then* unlock the parent to do this, yes. That was the point of the "relookup" reference for rename, which has to open a race window to do the locks correctly. Since the operation is supposed to appear atomic, a failure + retry is an OK outcome. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 17:42:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id A5FE411AAD for ; Tue, 23 Feb 1999 17:42:35 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id SAA20219; Tue, 23 Feb 1999 18:42:29 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp02.primenet.com, id smtpd019993; Tue Feb 23 18:42:10 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id SAA25033; Tue, 23 Feb 1999 18:42:06 -0700 (MST) From: Terry Lambert Message-Id: <199902240142.SAA25033@usr09.primenet.com> Subject: Re: Panic in FFS/4.0 as of yesterday To: mjacob@feral.com Date: Wed, 24 Feb 1999 01:42:05 +0000 (GMT) Cc: dfr@nlsystems.com, freebsd-hackers@FreeBSD.org In-Reply-To: from "Matthew Jacob" at Feb 22, 99 08:31:05 am 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 > The only problem with this approach is not all I/O is or will be driven > by a process. Let's say we port a new filesystem in that creates a > *lot* of I/O via threads or wads of async r/w. Unless you start doing > thread scheduling it's hard to figure out whome to penalize. I think this would be an evil thing (kernel threads). The idea that you have an atomic context semi-precludes preemption without a lot of redesign work. On the plus side, it might force a redesign, but I doubt the code would make it in if that happened. > I still would like to see a B_EXPEDITE (although B_PRIORITY seems a better > name). Should we also be paying attention to B_ORDERED and should you > consider doing buffer generations? I stayed away from B_PRIORITY because that implies a spectrum of priority levels, not just an "I may be slow, but I'm in front of you". Passing the bits down is somewhat problematic, since they are pretty much stripped before they get there. It's really an interface isolation issue that I think would be very hard to deal with. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 17:50:19 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 3D68511C06; Tue, 23 Feb 1999 17:48:05 -0800 (PST) (envelope-from doconnor@gsoft.com.au) Received: from lot.gsoft.com.au (doconnor@lot.gsoft.com.au [203.38.152.106]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id MAA15506; Wed, 24 Feb 1999 12:16:54 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [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: <36D23C91.F39053E9@student.unsw.edu.au> Date: Wed, 24 Feb 1999 12:16:53 +1030 (CST) From: "Daniel O'Connor" To: chris/reman Subject: RE: CDROM detection problems Cc: questions@FreeBSD.ORG, hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23-Feb-99 chris/reman wrote: > I have one hard drive which is master first controller, I have a pioneer > A04s 32x cdrom as a slave on the secondary controller. The FreeBSD wd code doesn't deal with only having a slave connected to a controller without a master.. --- 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 Tue Feb 23 17:53: 7 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 A9F9A11C44 for ; Tue, 23 Feb 1999 17:53:04 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id SAA25157; Tue, 23 Feb 1999 18:52:58 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp03.primenet.com, id smtpd024872; Tue Feb 23 18:52:43 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id SAA25555; Tue, 23 Feb 1999 18:52:27 -0700 (MST) From: Terry Lambert Message-Id: <199902240152.SAA25555@usr09.primenet.com> Subject: Re: ELF default format vs. a.out default binary name To: joy@urc.ac.ru (Konstantin Chuguev) Date: Wed, 24 Feb 1999 01:52:27 +0000 (GMT) Cc: ru@ucb.crimea.ua, freebsd-hackers@FreeBSD.ORG In-Reply-To: <36D2A58A.B6571F5B@urc.ac.ru> from "Konstantin Chuguev" at Feb 23, 99 05:56:42 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 > Oh, sorry, I wrote not accurately. I meant, if you don't set -o > option in gcc, then the file will be named a.out, even if it's > in ELF format :-) a.out = assembler output Perhaps because you are still using an assembler from the compiler? 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 18: 4:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id D833511390 for ; Tue, 23 Feb 1999 18:04:47 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id TAA13468; Tue, 23 Feb 1999 19:25:52 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpd013289; Tue Feb 23 19:25:41 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id TAA26138; Tue, 23 Feb 1999 19:04:20 -0700 (MST) From: Terry Lambert Message-Id: <199902240204.TAA26138@usr09.primenet.com> Subject: Re: ESTALE the best approach? To: dillon@apollo.backplane.com (Matthew Dillon) Date: Wed, 24 Feb 1999 02:04:20 +0000 (GMT) Cc: tlambert@primenet.com, toasty@home.dragondata.com, hackers@FreeBSD.ORG In-Reply-To: <199902240115.RAA54511@apollo.backplane.com> from "Matthew Dillon" at Feb 23, 99 05:15: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 > The most common occurance of ESTALE that I know of is when a file is > deleted on an NFS server. This is the least common, by my reckoning, but YMMV; you were certainly running a different environment at Best. > This is an unrecoverable condition. That is, the open descriptor in > question should return ESTALE forever. You'd have to reopen the file > to fix it. It is not appropriate to automatically remount the file > in that situation. For example, if someone on the server reinstalls a > binary there is no way in hell a process already running that binary image > on a client can recover. It must seg-fault, die, and be restarted. The deletion must have occurred on the server. It it occurred on another client, then it would be moved to a "." file until the last close. The correct client interlock is to lock the file, which of course it can not do in FreeBSD, without patches. The most common case I saw (in an environment where locking actually worked, as did NFSv3 LEASEs) was a server reboot rotating the numbers out from under the client, and the client failing a restart. In any case, if the ESTALE gets propagated to user space, rightly or wrongly, then the program must examine the return from "read" and take appropriate action (up to and including croaking). As a point of reference, I believe ESTALE to be intended as a purely kernel error. It is the lack of references to struct file *'s that reference a particular vnode (that may reference an NFSnode) that preclude invalidating the open file instances, resulting in the correct error to user space, which is EBADF. An interesting causal effect of this lack of reference backpointer is the need to support deadfs as a placeholder on vnode revocation (this is, in fact, a kludge to "repair" the kludge of no reference backpointer). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 18:14:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id A00CE115BA for ; Tue, 23 Feb 1999 18:14:07 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id TAA20450; Tue, 23 Feb 1999 19:14:06 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp01.primenet.com, id smtpd020318; Tue Feb 23 19:13:56 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id TAA26428; Tue, 23 Feb 1999 19:13:47 -0700 (MST) From: Terry Lambert Message-Id: <199902240213.TAA26428@usr09.primenet.com> Subject: Re: ESTALE the best approach? To: toasty@home.dragondata.com (Kevin Day) Date: Wed, 24 Feb 1999 02:13:39 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <199902240132.TAA25796@home.dragondata.com> from "Kevin Day" at Feb 23, 99 07:32:47 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 > > Programs have to be able to deal with errors. They either have > > specific per-error strategies, or they have an "all other errors" > > strategy. > > The problem I've seen is that some poorly designed software lists what it > thinks are fatal, and everything else is to be retried. Well, that's poorly designed code. It needs to be fixed. > Here for example, the executable checks for a few errors, if they don't > match what it thinks are fatal, it retries. I'd think that good programming > practice should be the reverse. Add what you know to be temporary, and > everything else (and errors you don't even know about) should be fatal. Right. > > > Because they not realize that ESTALE is a fatal condition, or lots of > > > programs tend to just go bezerk at having a FD closed on them... > > > > It's not so much that they don't know how to handle ESTALE, it's > > more that they are (evilly) ignoring the -1 return from read. > > Looking at the read(2) man page... The only error that could happen that > isn't a result of a programming error that could happen on a standard file > is 'EIO', which would probably be a hardware error. (At that point, when > hardware fails, I consider any application's behavior as 'undefined', on > the PC architecture) See my response to Matt. I believe that ESTALE should not be sent to user space under any circumstances. However, that said, POSIX requires that programs treat non-understood error codes as fatal. > I can see why people aren't checking for errors on a read(2), really... Lots > of FreeBSD's internal utilities don't do it, even. :) (however, most don't > retry ad nausem in response to an error) Well, they're broken, and need to be fixed, eventually. > > > EBADF was nearly as bad, as most programs that couldn't deal with ESTALE > > > probably didn't expect a fd that they had already opened to be suddenly > > > closed. > > > > Plus it was never closed. The vnode is still hanging out. The > > EBADF'ed descriptor is unrecoverable, since only a stupid program > > would close an already closed fd. So the struct file * pointing to > > the vnode is also still hanging out. > > Eeep, I hadn't thought of that. I guess I realize that has to be true, > otherwise you'd be getting EBADF. You should be. The bug is that FreeBSD is structurally incapable of doing a revocation, short of deadfs. > > The only way you get a stale node is a server reboot, and that's as a > > result of the "security" cruft that was nont implemented link-layer > > like it should have been (packet sequence randomization, etc.). Matt very correctly pointed out that you could get it on a server file deletion in the absence of locking (a lock would count as an open file reference, keeping the file around, even if deleted). Ignoring locking, the ESTALE shoudl result in revocation + EBADF (see other posting). > I'm actually seeing this on a network that has an 100MB ethernet segment > exculsively for NFS. > > I'll see this: > > nfs server home.internal:/home: not responding > nfs server home.internal:/home: is alive again > > in my syslog, with the timestamps being identical, and chances are, after > that, one or two processes goes bezerk afterwards. Right. This is the remount problem, not updating the existing NFSnodes. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 18:27:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id EF8E5115BD; Tue, 23 Feb 1999 18:27:38 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id MAA20888; Wed, 24 Feb 1999 12:57:36 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id MAA52293; Wed, 24 Feb 1999 12:57:34 +1030 (CST) Message-ID: <19990224125734.V93492@lemis.com> Date: Wed, 24 Feb 1999 12:57:34 +1030 From: Greg Lehey To: John Smith , freebsd-questions@FreeBSD.ORG Subject: Re: /dev/lkm References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from John Smith on Tue, Feb 23, 1999 at 04:38:26PM -0500 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [moved to -questions] On Tuesday, 23 February 1999 at 16:38:26 -0500, John Smith wrote: > > > I am on 3.1; and when I try to do modload. i get /dev/lkm not > configured. > > Do I need to compile my kernel with a special keyword so that it > supports loadable kernel modules, (/dev/lkm exists); or lkm does not exist > anymore? This doesn't really qualify as an in-depth technical discussion, so I'm moving it to -questions. LKMs have gone away in 3.1, though support for them remains. They've been replaced by klds, for which unfortunately not much documentation exists. I'm attaching something that is going into a revised version of ``The Complete FreeBSD''. Greg Kernel loadable modules _______________________ Older versions of FreeBSD supplied Loadable Kernel Modules or LKMs, object files which could be loaded and executed in the kernel while the kernel was running. We discussed them in passing on page 294. The ELF kernel and the new bootstrap of FreeBSD version 3 allow you to load additional modules at boot time. To do so, however, the format of the modules needed to be changed. To avoid (too much) confusion, the name changed from loadable kernel module to kernel loadable module (kld). FreeBSD still supports LKMs as well, so klds are stored in a different directory and loaded and unloaded by different programs: Table E-1. Differences between LKMs and klds +---------------+-----------+-----------+ |Parameter | LKM | kld | +---------------+-----------+-----------+ |Directory | /lkm | /modules | |Load program | modload | kldload | |Unload program | modunload | kldunload | |List program | modstat | kldstat | +---------------+-----------+-----------+ Some other details have changed as well. kldload knows an internal path for finding klds, so you don't need to specify the path. It also assumes that the name of the kld ends in .ko, and you don't need to specify that either. For example, to load the Linux emulator as an LKM, you might have entered: # modload /lkm/linux_mod.o To load the kld, you could enter: # kldload linux -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 18:31:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from TomQNX.tomqnx.com (cpu2745.adsl.bellglobal.com [207.236.55.214]) by hub.freebsd.org (Postfix) with ESMTP id AF6071166A; Tue, 23 Feb 1999 18:31:00 -0800 (PST) (envelope-from tom@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m10FU3m-000I5dC; Tue, 23 Feb 1999 21:28:26 -0500 (EST) Message-Id: From: tom@tomqnx.com (Tom Torrance at home) Subject: Re: Missing files/directories In-Reply-To: <199902230822.IAA00707@keep.lan.Awfulhak.org> from Brian Somers at "Feb 23, 1999 8:22:47 am" To: brian@Awfulhak.org (Brian Somers) Date: Tue, 23 Feb 1999 21:28:26 -0500 (EST) Cc: tom@tomqnx.com, hackers@FreeBSD.ORG, current@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 Content-Length: 514 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, brian, Good idea - I will set up tests tomorrow following your advice. I don't want to be right - I want to be problem-free:-) I can't use my son's machine as he is behind a firewall I can't breach so I will set it up with a couple of machines here on my LAN, internally. I might just swap out the old 2.2-stable server for another machine running the latest RELENG_3. I'll have to think about that... I'll get the results to you as soon as I can. Hopefully within the next couple of days. Regards, Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 18:33: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from holly.dyndns.org (ip220.houston2.tx.pub-ip.psi.net [38.11.201.220]) by hub.freebsd.org (Postfix) with ESMTP id 5D9E1114C2 for ; Tue, 23 Feb 1999 18:32:57 -0800 (PST) (envelope-from chris@holly.dyndns.org) Received: (from chris@localhost) by holly.dyndns.org (8.9.2/8.9.2) id UAA00764; Tue, 23 Feb 1999 20:33:20 -0600 (CST) (envelope-from chris) Date: Tue, 23 Feb 1999 20:33:16 -0600 From: Chris Costello To: John Smith Cc: FreeBSD-hackers@freebsd.org Subject: Re: /dev/lkm Message-ID: <19990223203316.C539@holly.dyndns.org> Reply-To: chris@calldei.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3us In-Reply-To: ; from John Smith on Tue, Feb 23, 1999 at 04:38:26PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 23, 1999, John Smith put this into my mailbox: > > Hello All; > > I am on 3.1; and when I try to do modload. i get /dev/lkm not > configured. > > Do I need to compile my kernel with a special keyword so that it > supports loadable kernel modules, (/dev/lkm exists); or lkm does not exist > anymore? lkm exists, but it's apparently broken and *SHOULD* be removed. I added the LKM device to my kernel config and modload does not work. I get a bunch of ld errors > > Any ideas? > > Thanks; > -John -Chris -- /* * There aren't nearly enough comments in this code, so I'll * add a popular comment here. * * XXX: This sucks */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 23 18:34:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id DF47B11755 for ; Tue, 23 Feb 1999 18:34:43 -0800 (PST) (envelope-from bright@cygnus.rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.8.7/8.8.7) with SMTP id VAA12509; Tue, 23 Feb 1999 21:57:01 -0500 (EST) Date: Tue, 23 Feb 1999 21:56:59 -0500 (EST) From: Alfred Perlstein To: Terry Lambert Cc: mjacob@feral.com, dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday In-Reply-To: <199902240142.SAA25033@usr09.primenet.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, 24 Feb 1999, Terry Lambert wrote: > > The only problem with this approach is not all I/O is or will be driven > > by a process. Let's say we port a new filesystem in that creates a > > *lot* of I/O via threads or wads of async r/w. Unless you start doing > > thread scheduling it's hard to figure out whome to penalize. > > I think this would be an evil thing (kernel threads). The idea that > you have an atomic context semi-precludes preemption without a lot > of redesign work. On the plus side, it might force a redesign, but > I doubt the code would make it in if that happened. What alternatives would you suggest? I had an idea about lock queues and cooperative work but the problem was that i couldn't figure out how to hold multiple locks. I would REALLY appreciate a repost of what you wanted to do several months ago with SMP. You wanted people with several doctorates on your team, at the time the message really confused me, but i'd love to have another shot at reading it. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 13:25: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from excalibur.oceanis.net (ns.dotcom.fr [195.154.74.11]) by hub.freebsd.org (Postfix) with ESMTP id 68F8B11271 for ; Wed, 24 Feb 1999 13:21:58 -0800 (PST) (envelope-from pixel@excalibur.oceanis.net) Received: (from pixel@localhost) by excalibur.oceanis.net (8.9.1/8.9.1) id PAA16546 for hackers@FreeBSD.ORG; Wed, 24 Feb 1999 15:27:11 GMT From: Emmanuel DELOGET Message-Id: <199902241527.PAA16546@excalibur.oceanis.net> Subject: just a few questions... To: hackers@FreeBSD.ORG (FreeBSD Hackers Mail List) Date: Wed, 24 Feb 1999 16:27:11 +0100 (MET) 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 was playing _very_ badly with my 2.2.8 kernel sources (yes... 2.2.8 again... I know I should use a 3.x but I still use 2.2.8... sounds crazy, huh...) and I had some nasty messages that sound very strange to my ears... After I took a look to the code, I still don't understand (well... I'm not very sure of what I understand, in fact). First, if somebody could explain me what is the "double fault" panic (yes, I done it...:). And then, if anybody knows what is the message that tells : vfsload(procfs) : bad address... (yes, I done it to...). Note that this is *NOT* a FreeBSD bug. This shows my own bugs added to the FreeBSD kernel code :). Thx a lot. -- ____________________________________________________________________ Emmanuel DELOGET [pixel] pixel@{dotcom.fr,epita.fr} ---- DotCom SA -------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 13:29:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (Postfix) with ESMTP id 424FC117A1 for ; Wed, 24 Feb 1999 13:26:53 -0800 (PST) (envelope-from Dom.Mitchell@palmerharvey.co.uk) Received: from ho-nt-01.pandhm.co.uk (unverified) by mail.palmerharvey.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Wed, 24 Feb 1999 12:52:28 +0000 Received: from voodoo.pandhm.co.uk ([10.100.35.12]) by ho-nt-01.pandhm.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id F1KNMLR1; Tue, 23 Feb 1999 12:58:51 -0000 Received: from dom by voodoo.pandhm.co.uk with local (Exim 2.10 #1) id 10FHYC-000GQk-00; Tue, 23 Feb 1999 13:07:00 +0000 To: Konstantin Chuguev Cc: freebsd-hackers@freebsd.org Subject: Re: ELF default format vs. a.out default binary name X-Mailer: nmh v0.26 X-Colour: Green Organization: Palmer & Harvey McLane In-Reply-To: Konstantin Chuguev's message of "Tue, 23 Feb 1999 17:27:53 +0500" <36D29EC9.27B554DA@urc.ac.ru> Date: Tue, 23 Feb 1999 13:06:59 +0000 From: Dom Mitchell Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23 February 1999, Konstantin Chuguev proclaimed: > Just curious: if ELF is the default binary file format now, then why gcc > still produces a.out file by default? > > Well, I know, I've changed the reason and the consequence, so it's a > kind of joke :-) Well: It'd confuse people who aren't used to it. It didn't happen the last time a binary format change happened (COFF on SysV?). It's still Assembler OUTput. The Union Of Pixies raised an objection claiming racism. -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator Free your mind -- http://www.opensource.org/ -- ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 13:32: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 1083811AA1 for ; Wed, 24 Feb 1999 13:31:16 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.com (zaphod.softweyr.com [204.68.178.35]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id XAA19865; Tue, 23 Feb 1999 23:55:39 -0700 (MST) (envelope-from wes@softweyr.com) Message-ID: <36D3A26A.922CE5A9@softweyr.com> Date: Tue, 23 Feb 1999 23:55:38 -0700 From: Wes Peters Organization: Softweyr llc X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: dyson@iquest.net Cc: Warner Losh , vincef@penmax.com, dennis@etinc.com, hackers@FreeBSD.ORG Subject: Re: cdrom.com bandwidth limits References: <199902231921.OAA03755@y.dyson.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "John S. Dyson" wrote: > > It is not likely to get that much due to protocol overheads, but I > have seen >160KBytes/sec on a good T1. Don't T1's do bit stealing > for signalling (I forget?) Unless you are on a "clear channel." If you are, the throughput is 24 x 64 Kbits/sec, if not, 24 x 64 Kbits/sec - 8 Kbits/sec. The bit stealing totals 8 Kbits/sec for the entire channel, regardless of how "big" the channel is. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 14: 9:24 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 EBD9912392 for ; Wed, 24 Feb 1999 14:07:21 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id IAA62903; Wed, 24 Feb 1999 08:59:57 GMT (envelope-from dfr@nlsystems.com) Date: Wed, 24 Feb 1999 08:59:57 +0000 (GMT) From: Doug Rabson To: John Smith Cc: freebsd-hackers@freebsd.org Subject: Re: /dev/lkm 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, 23 Feb 1999, John Smith wrote: > > Hello All; > > I am on 3.1; and when I try to do modload. i get /dev/lkm not > configured. > > Do I need to compile my kernel with a special keyword so that it > supports loadable kernel modules, (/dev/lkm exists); or lkm does not exist > anymore? > > Any ideas? The LKM mechanism has been replaced by a newer kernel-based linker called KLD. If you absolutely must use LKM, you can add it as an option to your kernel config but I would urge you to move to the new mechanism. There are plenty of examples of how to build KLD modules in /usr/share/examples/kld and /usr/src/sys/modules. -- 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 Feb 24 14:14:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from paert.tse-online.de (paert.tse-online.de [194.97.69.172]) by hub.freebsd.org (Postfix) with SMTP id 3BB6012140 for ; Wed, 24 Feb 1999 14:10:45 -0800 (PST) (envelope-from ab@paert.tse-online.de) Received: (qmail 24174 invoked by uid 1000); 24 Feb 1999 08:43:32 -0000 Date: Wed, 24 Feb 1999 09:43:32 +0100 From: Andreas Braukmann To: hackers@FreeBSD.ORG Subject: Re: glibstdc 2.8 and linux emulation Message-ID: <19990224094332.G8751@paert.tse-online.de> References: <87u2wdea6t.fsf@pens.ion.sci.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <87u2wdea6t.fsf@pens.ion.sci.fi>; from Antti Kaipila on Tue, Feb 23, 1999 at 11:33:30AM +0200 Organization: TSE TeleService GmbH Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, On Tue, Feb 23, 1999 at 11:33:30AM +0200, Antti Kaipila wrote: > Any pointers how to get glibstdc 2.8 to work with linux applications > under FreeBSD's linux emulation. I don't have access to any linux > machine right now. > The purpose is to get Linux Office Suite 99's Applixware running under > FreeBSD. Hmmm, what about simply running the non-glibc based Applixware? I've just updated to Applixware 4.4.1 from my former (ca. one year old) version. The installation was a breeze. I just followed the installation instructions for "Slackware" [ rpm2cpio /cdrom/fullnames/... | cpio -iduv ] -ab -- : TSE TeleService GmbH : Gsf: Arne Reuter : : : Hovestrasse 14 : Andreas Braukmann : We do it with : : D-48351 Everswinkel : HRB: 1430, AG WAF : FreeBSD/SMP : :--------------------------------------------------------------------: : PGP-Key: http://www.tse-online.de/~ab/public-key : : Key fingerprint: 12 13 EF BC 22 DD F4 B6 3C 25 C9 06 DC D3 45 9B : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 14:15:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (Postfix) with ESMTP id 0179A12371 for ; Wed, 24 Feb 1999 14:11:30 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id VAA28558; Tue, 23 Feb 1999 21:20:20 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id VAA13186; Tue, 23 Feb 1999 21:20:13 -0700 Date: Tue, 23 Feb 1999 21:20:13 -0700 Message-Id: <199902240420.VAA13186@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Craig Spannring Cc: hackers@FreeBSD.ORG Subject: Re: CVS and Y2K In-Reply-To: <199902240121.RAA25148@bangkok.office.cdsnet.net> References: <199902240121.RAA25148@bangkok.office.cdsnet.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Does FreeBSD still ship with CVS version 1.9.26? If so it needs to be > upgraded within the next 9 months or so. 1.9.26 can't parse dates > past 1999-12-31. Have you verified this? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 14:15:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 7938812379; Wed, 24 Feb 1999 14:11:21 -0800 (PST) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.9.1/8.9.1) id JAA66846; Wed, 24 Feb 1999 09:15:49 +0100 (CET) (envelope-from sos) From: Sĝren Schmidt Message-Id: <199902240815.JAA66846@freebsd.dk> Subject: Re: CDROM detection problems In-Reply-To: from "Daniel O'Connor" at "Feb 24, 1999 12:16:53 pm" To: doconnor@gsoft.com.au (Daniel O'Connor) Date: Wed, 24 Feb 1999 09:15:49 +0100 (CET) Cc: z2172268@student.unsw.edu.au, questions@freebsd.org, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Daniel O'Connor wrote: > > On 23-Feb-99 chris/reman wrote: > > I have one hard drive which is master first controller, I have a pioneer > > A04s 32x cdrom as a slave on the secondary controller. > > The FreeBSD wd code doesn't deal with only having a slave connected to a > controller without a master.. That is not true, but its true that it fails for some devices. However I have overcome this problem together with the excessive waits for nonexistent drives in the new ata/atapi driver, or at least I have on all the HW I have access to :) -Sĝren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 14:17:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from schizo.cdsnet.net (schizo.cdsnet.net [204.118.244.32]) by hub.freebsd.org (Postfix) with ESMTP id 82A4712137 for ; Wed, 24 Feb 1999 14:13:20 -0800 (PST) (envelope-from mrcpu@internetcds.com) Received: from localhost (mrcpu@localhost) by schizo.cdsnet.net (8.8.8/8.7.3) with SMTP id NAA08123 for ; Wed, 24 Feb 1999 13:34:10 -0800 (PST) Date: Wed, 24 Feb 1999 13:34:09 -0800 (PST) From: Jaye Mathisen X-Sender: mrcpu@schizo.cdsnet.net To: hackers@freebsd.org Subject: Multi-link PPP over 2 T1's or 2 ethernet's? 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 need to load balance 2 T1's using ETInc's serial cards. I suppose it's possible over OSPF, if I used gated, but doing it inside a daemon so that it looks like 1 3Mbit pipe would be OK as well. Let me know please. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 14:22:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bangkok.office.cdsnet.net (bangkok.office.cdsnet.net [204.118.245.23]) by hub.freebsd.org (Postfix) with ESMTP id 2A0E1120B0 for ; Wed, 24 Feb 1999 14:16:30 -0800 (PST) (envelope-from cts@bangkok.office.cdsnet.net) Received: (from cts@localhost) by bangkok.office.cdsnet.net (8.8.8/8.8.5) id VAA26449; Tue, 23 Feb 1999 21:06:07 -0800 (PST) Date: Tue, 23 Feb 1999 21:06:07 -0800 (PST) Message-Id: <199902240506.VAA26449@bangkok.office.cdsnet.net> X-Authentication-Warning: bangkok.office.cdsnet.net: cts set sender to cts@bangkok.office.cdsnet.net using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Craig Spannring To: Nate Williams Cc: Craig Spannring , hackers@FreeBSD.ORG Subject: Re: CVS and Y2K In-Reply-To: <199902240420.VAA13186@mt.sri.com> References: <199902240121.RAA25148@bangkok.office.cdsnet.net> <199902240420.VAA13186@mt.sri.com> X-Mailer: VM 6.31 under Emacs 20.3.1 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams writes: > > Does FreeBSD still ship with CVS version 1.9.26? If so it needs to be > > upgraded within the next 9 months or so. 1.9.26 can't parse dates > > past 1999-12-31. > > Have you verified this? Yup. I was hit by it a few months ago. It is documented at: http://www.cyclic.com/cvs/dev-y2k.html It only affects client/server installations. -- ======================================================================= Life is short. | Craig Spannring Ski hard, Bike fast. | cts@internetcds.com --------------------------------+------------------------------------ Any sufficiently horrible technology is indistinguishable from Perl. ======================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 14:31:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vmunix.psn.ie (db-126.dialup.eunet.ie [193.120.3.222]) by hub.freebsd.org (Postfix) with ESMTP id 2CA9D11920 for ; Wed, 24 Feb 1999 14:23:36 -0800 (PST) (envelope-from ad@psn.ie) Received: from localhost.psn.ie ([127.0.0.1] helo=localhost) by vmunix.psn.ie with esmtp (Exim 2.10 #1) id 10FmjF-0000Hu-00; Wed, 24 Feb 1999 22:24:29 +0000 Date: Wed, 24 Feb 1999 22:24:28 +0000 (GMT) From: Andy Doran To: Emmanuel DELOGET Cc: FreeBSD Hackers Mail List Subject: Re: just a few questions... In-Reply-To: <199902241527.PAA16546@excalibur.oceanis.net> Message-ID: X-Mailer: Pine 4.05 (FreeBSD/i386) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > First, if somebody could explain me what is the "double fault" panic > (yes, I done it...:). It means the kernel has faulted (caused an exception) while dealing with an already existing one. Andy. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 14:40: 5 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 3EB3A1152F for ; Wed, 24 Feb 1999 14:40:01 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id UAA23470; Tue, 23 Feb 1999 20:57:30 -0800 Date: Tue, 23 Feb 1999 20:57:30 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Terry Lambert Cc: dfr@nlsystems.com, freebsd-hackers@FreeBSD.org Subject: Re: Panic in FFS/4.0 as of yesterday In-Reply-To: <199902240142.SAA25033@usr09.primenet.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 There was some moderately appropos discussion today at OSDI about this - plus a quite amusing discussion of virtual machines. One of the issues has to do with resource allocation (and, by relation, resource scheduling) problems when it's hard to figure out whom is driving or paying for an I/O. But I can see there isn't much interest in this in FreeBSD. That's okay- I'd be just happy to have a system that doesn't crash. On Wed, 24 Feb 1999, Terry Lambert wrote: > > The only problem with this approach is not all I/O is or will be driven > > by a process. Let's say we port a new filesystem in that creates a > > *lot* of I/O via threads or wads of async r/w. Unless you start doing > > thread scheduling it's hard to figure out whome to penalize. > > I think this would be an evil thing (kernel threads). The idea that > you have an atomic context semi-precludes preemption without a lot > of redesign work. On the plus side, it might force a redesign, but > I doubt the code would make it in if that happened. > > > > I still would like to see a B_EXPEDITE (although B_PRIORITY seems a better > > name). Should we also be paying attention to B_ORDERED and should you > > consider doing buffer generations? > > I stayed away from B_PRIORITY because that implies a spectrum of > priority levels, not just an "I may be slow, but I'm in front of you". > > Passing the bits down is somewhat problematic, since they are pretty > much stripped before they get there. It's really an interface > isolation issue that I think would be very hard to deal with. > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 14:46:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mercury.inktomi.com (mercury.inktomi.com [209.1.32.126]) by hub.freebsd.org (Postfix) with ESMTP id AF4F21136F for ; Wed, 24 Feb 1999 14:46:32 -0800 (PST) (envelope-from jplevyak@inktomi.com) Received: from proxydev.inktomi.com (proxydev.inktomi.com [209.1.32.44]) by mercury.inktomi.com (8.9.1a/8.9.1) with ESMTP id VAA07743 for ; Tue, 23 Feb 1999 21:47:53 -0800 (PST) Received: (from jplevyak@localhost) by proxydev.inktomi.com (8.8.5/8.7.3) id VAA25006 for hackers@FreeBSD.ORG; Tue, 23 Feb 1999 21:47:44 -0800 (PST) Message-ID: <19990223214744.A24606@proxydev.inktomi.com> Date: Tue, 23 Feb 1999 21:47:44 -0800 From: John Plevyak To: hackers@FreeBSD.ORG Subject: flock and kernel threads Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I believe there may be a problem with lockfiles (flock) and kernel threads. The problem is demonstrated by the enclosed program, which if run twice will fail the second time. The problem seems to be that termination via signal of the non-main thread (non-leader) does not (always) result in a call to closef and hence a call to lf_clearlock. Suggestions, comments welcome. john ======================== CUT HERE ============================== #include #include #include #include #include #include #include #include #include #include #include #include #include #include pthread_t ink_thread_create(void*(*f)(void *),void * a) { pthread_t t; int ret; pthread_attr_t attr; pthread_attr_init(&attr); pthread_attr_setscope(&attr, PTHREAD_SCOPE_SYSTEM); ret = pthread_create(&t, &attr, f, a); assert(!ret); pthread_attr_destroy(&attr); return t; } int lockfile_open (const char *lockfile, int *fd_ptr) { #define FAIL(x) \ { \ if (fd > 0) \ close (fd); \ return (x); \ } struct flock lock; int size; int val; int err; int fd; *fd_ptr = -1; // Try and open the lockfile. Create it if it does not already // exist. do { fd = open (lockfile, O_RDWR | O_CREAT, 0600); } while ((fd < 0) && (errno == EINTR)); if (fd < 0) FAIL (-errno); // Lock it. Note that if we can't get the lock EAGAIN will be the // error we receive. lock.l_type = F_WRLCK; lock.l_start = 0; lock.l_whence = SEEK_SET; lock.l_len = 0; do { err = fcntl (fd, F_SETLK, &lock); } while ((err < 0) && (errno == EINTR)); if (err < 0) FAIL(0); // Return the file descriptor of the opened lockfile. When this file // descriptor is closed the lock will be released. *fd_ptr = fd; return(1); // success #undef FAIL } void * dthread(void * a) { (void)kill(0, SIGKILL); // or (void)kill(getpid(), SIGKILL); } int main(int argc, char ** argv) { int fd, i; int res = lockfile_open("lockfile.lock", &fd); printf("res = %d, fd = %d\n", res, fd); if (!res) exit(0); ink_thread_create(dthread, 0); sleep(10); } ======================== CUT HERE ============================== -- John Bradley Plevyak, PhD, jplevyak@inktomi.com, PGP KeyID: 051130BD Inktomi Corporation, 1900 S. Norfolk Street, Suite 110, San Mateo, CA 94403 W:(415)653-2830 F:(415)653-2801 P:(888)491-1332/5103192436.4911332@pagenet.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 15:36:32 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 5763114E0A for ; Wed, 24 Feb 1999 15:36:08 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40372>; Thu, 25 Feb 1999 10:24:42 +1100 Date: Thu, 25 Feb 1999 10:35:36 +1100 From: Peter Jeremy Subject: bcmp() [was Re: vm_page_zero_fill] To: hackers@FreeBSD.ORG Cc: bright@cygnus.rush.net Message-Id: <99Feb25.102442est.40372@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 19 Feb 1999, Alfred Perlstein wrote: > I think it's more effecient because gcc is smart enough to >use the index instead of 2 seperate pointers. On the i[34]86 (I'm not sure about the Pentium and later), having base+index slows down the operation. In theory, there's no difference in speed between the following two lines: movl (%esi),%eax; incl %esi movl (%esi,%ebx),%eax >> Sort of true. In theory, an explicit loop is faster than "rep cmps". >> Lack of CPU<->RAM bandwidth tends to make this less of an issue unless >> both strings are in L1 cache. > >Aren't they both forced into L1 as soon as they are first accessed, making >the rest of the code execute quicker? (at least on i586+) This is true on all cached architectures. For a large or infrequent compare, the strings are unlikely to already be in the case, so it comes back to CPU (or cache) <-> RAM bandwidth. The following partially unrolled code shows the i486 behaviour (assuming %esi and %edi both point at addresses not in L1 cache): movb (%esi),%al Initiate line[1] load. stall[a] until (%esi) available cmpb (%edi),%al stall[b] until [1] complete, Initiate line[2] load. stall[c] until (%edi) available decl %ecx jne ... movb 1(%esi),%al line[1] loaded - no stall cmpb 1(%edi),%al stall[d] until [2] complete, decl %ecx jne ... Note the large number of stalls. In particular, stall[d] occurs because the 486 can't use partially-filled cache lines - it will short-cut the initial reference, but the next reference will wait until the load is complete. (I don't know if this behaviour is also true of newer ix86 processors). There's not much that can be done about stall[b] since there's only one memory bus - but the Alpha implements a packetized memory bus, so the processor can initiate the line[2] load before line[1] is loaded - this partially overlaps stall[b] and stall[c]. I did some real testing on a variety of processors (i386SX-25 (no cache), i486DX2-50 (256k L2), pentium-133 (512k L2), PII-266 (512k L2), AlphaServer 4100 5/466 (4M L2)), comparing a number of different bcmp() implementations - with various string alignments. These tests were all on fairly long strings, so algorithm overheads don't affect results. The code I used was as follows: cmc1 C byte-compare using pointers (ie libkern/bcmp.c) cmc2 C byte-compare using index register (ie Alfred's code) cmc3 C long compare using aligned loads and shift/mask compares cmi1 i386 repe cmpsb cmi2 i386 repe cmpsl (ie i386/support.s) cmi3 i386 long compare using aligned loads and shift/mask compares (shld) bcmp Digital UNIX AXP libc.a bcmp() The actual code (except for the DU bcmp) is at the end of this article. Note that the code for both cmc3 and cmi3 access the longword beyond the end of the strings. This would need to be corrected for a standard implementation (though the impact on speed would be negligible). The code was compiled with gcc-2.7.2.1 except on the 486 and Alpha - where gcc-2.8.1 was used. In all cases, -O2 was specified. The absolute speed of the best implementation was (as expected) in the above order, though the implementation that performed best did vary. The long compares (cmc3, cmi2, cmi3, bcmp) are sensitive to operand alignment - cmi2 does best with both operands are longword aligned, the rest when the alignment is the same for both operands - there's around a 2:1 variation between optimal and worst case for cmc3, somewhat less for cmi3 and bcmp. In all cases, cmc3 was the fastest of the C algorithms. For the 386, the best code was cmi2 - 5-8 times as fast as cmc1 (which was faster then cmc2). For the 486DX2 and P-133, the best code depends on the operand alignment: cmi3 faster when both strings had the same non-longword alignment, cmi2 otherwise. As the strings get bigger (ie as cache effects reduce), the differences become smaller. cmc1 is faster than cmc2. The PII-266 results were similar, but weighted more towards cmi3. The Alpha results most clearly show the advantages of well-written assembler: for aligned operands, DEC's bcmp was 27 times as fast as cmc1 (which was itself about 50% faster than cmc2) - when both operands were in L1 cache. cmc3 was several times as fast as cmc1 - though nowhere as good as DEC's code. This order remains unchanged (though the ratios reduce) as the strings get larger. When the DEC cc was used (and the optimisation level cranked up), the C code was several times faster - gcc is _very_ poor at generating Alpha code - in fact cmc3 outperformed DEC's bcmp. (But unfortunately this isn't an option for FreeBSD/Alpha). Overall: On the i386, it's probably not worthwhile moving away from what we currently have. On the Alpha, we can make bcmp (and presumable bcopy and bzero) >30 times faster by hand-coding it in assembler. [If one of the Alpha developers wants it, I can probably send them the output from 'cc -O5 -S' on cmc3 - I don't think this infringes on any DEC copyrights]. ---------------------------------------------------------------- typedef const void *cvp; typedef const char *string; typedef unsigned long ul; typedef const unsigned long *culp; int cmc1(cvp b1, cvp b2, size_t len) { register string p1, p2; if (len == 0) return(0); p1 = (string)b1; p2 = (string)b2; do { if (*p1++ != *p2++) break; } while (--len); return(len); } int cmc2(cvp b1, cvp b2, size_t len) { size_t i; for (i = 0; i < len; i++) { if (i[(string)b1] != i[(string)b2]) break; } return (i < len); } static int cmc3(cvp b1, cvp b2, size_t _len) { int shl, shr, len = _len; string p1 = b1, p2 = b2; ul va, vb; if (len == 0) return(0); /* * align p1 to a longword boundary */ while (((long)p1) & (sizeof(long) - 1)) { if (*p1++ != *p2++) return (1); if (--len <= 0) return (0); } /* * align p2 to longword boundary and calculate the shift required to * align p1 and p2 */ shr = ((long)p2) & (sizeof(long) - 1); if (shr != 0) { p2 -= shr; shr <<= 3; shl = (sizeof(long) << 3) - shr; va = *(culp)p2; p2 += sizeof(long); while ((len -= sizeof(long)) >= 0) { vb = *(culp)p2; p2 += sizeof(long); if (*(culp)p1 != ((va >> shr) | (vb << shl))) return (1); p1 += sizeof(long); va = vb; } /* * At this point, len is between -sizeof(long) and -1, * representing 0 .. sizeof(long)-1 bytes remaining. * do the final masked compare. */ if (!(len += sizeof(long))) return (0); return ((*(culp)p1 ^ ((va >> shr) | (*(culp)p2 << shl))) & ((1L << (len << 3)) - 1)); } else { while ((len -= sizeof(long)) >= 0) { if (*(culp)p1 != *(culp)p2) return (1); p1 += sizeof(long); p2 += sizeof(long); } /* * At this point, len is between -sizeof(long) and -1, * representing 0 .. sizeof(long)-1 bytes remaining. * do the final masked compare. */ if (!(len += sizeof(long))) return (0); return ((*(culp)p1 ^ *(culp)p2) & ((1L << (len << 3)) - 1)); } } static int cmi1(cvp b1, cvp b2, size_t len) { int ret; __asm("cld\n" /* set compare direction forward */ " repe; cmpsb\n" " je 2f\n" "1: incl %0\n" "2:" : "=a" (ret) : "0" (0), "S" (b1), "D" (b2), "c" (len)); return (ret); } static int cmi2(cvp b1, cvp b2, size_t len) { int ret; __asm("cld\n" /* set compare direction forward */ " movl %4,%%ecx\n" /* compare by words */ " shrl $2,%%ecx\n" " repe; cmpsl\n" " jne 1f\n" " movl %4,%%ecx\n" /* compare remainder by bytes */ " andl $3,%%ecx\n" " repe; cmpsb\n" " je 2f\n" "1: incl %0\n" "2:" : "=a" (ret) : "0" (0), "S" (b1), "D" (b2), "rm" (len) : "%ecx"); return (ret); } static int cmi3(cvp b1, cvp b2, size_t len) { int ret; if (len == 0) return(0); __asm("cld\n" /* set compare direction forward */ "1: testl $3,%1\n" /* align b1 to word boundary */ " je 2f\n" " movb (%1),%b0\n" /* if (*b1 != *b2) */ " incl %1\n" " xorb (%2),%b0\n" " jne 8f\n" /* return (non-zero) */ " incl %2\n" " decl %3\n" /* if (--len <= 0) return (0) */ " jg 1b\n" " jmp 9f\n" /* return (0) */ "2: movl %2,%%ecx\n" /* offs = (((int)b2) & 3) << 3 */ " andl $3,%%ecx\n" " je 5f\n" /* b1 & b2 are aligned */ " subl %%ecx,%2\n" /* align b2 to word */ " shl $3,%%ecx\n" " movl (%2),%0; addl $4,%2\n" " subl $4,%3\n" " jl 4f\n" /* while (len >= 4) */ ".align 4,0x90\n" "3: movl (%2),%%edx; addl $4,%2\n" " shrd %%cl,%%edx,%0\n" " xorl (%1),%0\n" /* aligned compare */ " jne 8f\n" /* return (non-zero) */ " addl $4,%1\n" " movl %%edx,%0\n" " subl $4,%3\n" " jge 3b\n" /* * At this point, len (in %3) is between -4 and -1, * representing 0..3 bytes remaining */ "4: addl $4,%3\n" " je 9f\n" /* if (!(len += 4)) return (0); */ " movl (%2),%%edx\n" " shrd %%cl,%%edx,%0\n" " xorl (%1),%0\n" /* eax = (*(long *)b1 ^ *(long *)b2) */ " shll $3,%3\n" " movl %3,%%ecx\n" " movl $1,%%edx\n" " shll %%cl,%%edx\n" " decl %%edx\n" " andl %%edx,%0\n" /* eax & ((1 << (len << 3)) - 1) */ " jmp 8f\n" "5: subl $4,%3\n" /* aligned operands */ " jl 7f\n" /* while (len >= 4) */ " .align 4,0x90\n" "6: movl (%2),%0; addl $4,%2\n" " xorl (%1),%0\n" /* aligned compare */ " jne 8f\n" /* return (non-zero) */ " addl $4,%1\n" " subl $4,%3\n" " jge 6b\n" /* * At this point, len (in %3) is between -4 and -1, * representing 0..3 bytes remaining */ "7: addl $4,%3\n" " je 9f\n" /* if (!(len += 4)) return (0); */ " movl (%2),%0\n" " xorl (%1),%0\n" /* eax = (*(long *)b1 ^ *(long *)b2) */ " shll $3,%3\n" " movl %3,%%ecx\n" " movl $1,%%edx\n" " shll %%cl,%%edx\n" " decl %%edx\n" " andl %%edx,%0\n" /* eax & ((1 << (len << 3)) - 1) */ " jmp 8f\n" "9: xor %0,%0\n" "8:" : "=a" (ret) : "S" (b1), "D" (b2), "b" (len) : "%ecx", "%edx"); return (ret); } ---------------------------------------------------------------- Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 15:46:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from h24-64-221-247.gv.wave.shaw.ca (24.64.221.247.bc.wave.home.com [24.64.221.247]) by hub.freebsd.org (Postfix) with ESMTP id 86F6B14C4B for ; Wed, 24 Feb 1999 15:46:10 -0800 (PST) (envelope-from jake@h24-64-221-247.gv.wave.shaw.ca) Received: from h24-64-221-247.gv.wave.shaw.ca (localhost [127.0.0.1]) by h24-64-221-247.gv.wave.shaw.ca (8.9.3/8.9.2) with ESMTP id PAA01479 for ; Wed, 24 Feb 1999 15:45:59 -0800 (PST) (envelope-from jake@h24-64-221-247.gv.wave.shaw.ca) Message-Id: <199902242345.PAA01479@h24-64-221-247.gv.wave.shaw.ca> X-Mailer: exmh version 2.0.2 2/24/98 To: hackers@freebsd.org Subject: Re: CVS and Y2K Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Feb 1999 15:45:58 -0800 From: Jake Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry, I accidently sent this to -current > > Does FreeBSD still ship with CVS version 1.9.26? If so it needs to be > > upgraded within the next 9 months or so. 1.9.26 can't parse dates > > past 1999-12-31. > > Have you verified this? from http://www.cyclic.com/cvs/info-y2k.html: Do not plan to continue to use CVS 1.9 or older beyond the year 2000. Such versions of CVS have known bugs in their ability to handle dates beyond 2000. These bugs are fixed in CVS 1.10, and we recommend an upgrade to CVS 1.10 some time before the year 2000. ( 4.0-current as of yesterday ) [15:36:04]102<0> cvs -v Concurrent Versions System (CVS) 1.9.26 (client/server) bummer... -- obfuscate v.t. darken; obscure; bewilder. int i;main(){for(;i["] X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 24 Feb 1999 18:13:05 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: (Jim Mercer) Subject: RE: problems with the ep (ethernet) driver? 2.2.[67] Cc: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23-Feb-99 Jim Mercer wrote: > > oddly enough, if i fire up a tcpdump on the core router ep interface, > packets start flowing instantly. > > my feeling is that for some reason, kicking the ep driver into > promiscuous mode causes gated to retrun to normal operation. Correct assumption. > is there some bug with the ep driver, and promiscuous mode? > or is it possibly a bug in gated, misinterpreting the ep driver? It isn't a bug in gated I think since the packet stream gets initialised by kicking it into promiscuous mode like ye said. This is a driver problem. I do remember a thread about a likewise problem, but cannot for the gods remember which forum it was. Try a search of questions and net with promiscuous mode as the search key. I'll try and see what I can find myself. --- Jeroen Ruigrok van der Werven http://www.freebsdzine.org> asmodai(at)wxs.nl The idea does not replace the work... Network/Security Specialist *BSD: Powered by Knowledge & Know-how To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 16:59:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mercury.inktomi.com (mercury.inktomi.com [209.1.32.126]) by hub.freebsd.org (Postfix) with ESMTP id 7C4D614C87 for ; Wed, 24 Feb 1999 16:58:57 -0800 (PST) (envelope-from jplevyak@inktomi.com) Received: from proxydev.inktomi.com (proxydev.inktomi.com [209.1.32.44]) by mercury.inktomi.com (8.9.1a/8.9.1) with ESMTP id QAA22338 for ; Wed, 24 Feb 1999 16:58:49 -0800 (PST) Received: (from jplevyak@localhost) by proxydev.inktomi.com (8.8.5/8.7.3) id QAA19283 for hackers@freebsd.org; Wed, 24 Feb 1999 16:58:40 -0800 (PST) Message-ID: <19990224165840.A19033@proxydev.inktomi.com> Date: Wed, 24 Feb 1999 16:58:40 -0800 From: John Plevyak To: hackers@freebsd.org Subject: lockf and kernel threads Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, I found the problem with using kernel threads and fcntl( .. F_SETLK ..). The issue is two fold. 1. the locks are keyed off pid, and if the first thread to exit and close them is not the one that took out the lock the close will occur without the lock being removed. 2. the P_ADVLOCK flag is set in p_flags on a per processes basis, so we don't even check to see if locks need to be removed if the closing (struct proc*) is not the locking (struct proc*). I have a simple patch, but it requires removing two lines with a comment indicating that they are needed (however, inspection and simple testing indicate that this may not be the case): in kern_exit.c the function exit1() has the lines: /* * orphan the threads so we don't mess up * when they call exit */ nq->p_peers = 0; nq->p_leader = nq; These lines serve to disassociate the peers from the leader, making it difficult to get the leaders pid or p_flags for use in kern_descrip.c. Does anyone know what the comment refers to? See contenxt diff patch at end. john -- John Bradley Plevyak, PhD, jplevyak@inktomi.com, PGP KeyID: 051130BD Inktomi Corporation, 1900 S. Norfolk Street, Suite 110, San Mateo, CA 94403 W:(415)653-2830 F:(415)653-2801 P:(888)491-1332/5103192436.4911332@pagenet.net ============================== CUT HERE ============================= Index: kern_descrip.c =================================================================== RCS file: /usr/cvsroot/src/sys/kern/kern_descrip.c,v retrieving revision 1.58 diff -c -r1.58 kern_descrip.c *** kern_descrip.c 1999/01/08 17:31:08 1.58 --- kern_descrip.c 1999/02/24 15:52:22 *************** *** 286,298 **** case F_RDLCK: if ((fp->f_flag & FREAD) == 0) return (EBADF); ! p->p_flag |= P_ADVLOCK; return (VOP_ADVLOCK(vp, (caddr_t)p, F_SETLK, &fl, flg)); case F_WRLCK: if ((fp->f_flag & FWRITE) == 0) return (EBADF); ! p->p_flag |= P_ADVLOCK; return (VOP_ADVLOCK(vp, (caddr_t)p, F_SETLK, &fl, flg)); case F_UNLCK: --- 286,298 ---- case F_RDLCK: if ((fp->f_flag & FREAD) == 0) return (EBADF); ! p->p_leader->p_flag |= P_ADVLOCK; return (VOP_ADVLOCK(vp, (caddr_t)p, F_SETLK, &fl, flg)); case F_WRLCK: if ((fp->f_flag & FWRITE) == 0) return (EBADF); ! p->p_leader->p_flag |= P_ADVLOCK; return (VOP_ADVLOCK(vp, (caddr_t)p, F_SETLK, &fl, flg)); case F_UNLCK: *************** *** 1041,1053 **** * If the descriptor was in a message, POSIX-style locks * aren't passed with the descriptor. */ ! if (p && (p->p_flag & P_ADVLOCK) && fp->f_type == DTYPE_VNODE) { lf.l_whence = SEEK_SET; lf.l_start = 0; lf.l_len = 0; lf.l_type = F_UNLCK; vp = (struct vnode *)fp->f_data; ! (void) VOP_ADVLOCK(vp, (caddr_t)p, F_UNLCK, &lf, F_POSIX); } if (--fp->f_count > 0) return (0); --- 1041,1053 ---- * If the descriptor was in a message, POSIX-style locks * aren't passed with the descriptor. */ ! if (p && (p->p_leader->p_flag & P_ADVLOCK) && fp->f_type == DTYPE_VNODE) { lf.l_whence = SEEK_SET; lf.l_start = 0; lf.l_len = 0; lf.l_type = F_UNLCK; vp = (struct vnode *)fp->f_data; ! (void) VOP_ADVLOCK(vp, (caddr_t)p->p_leader, F_UNLCK, &lf, F_POSIX); } if (--fp->f_count > 0) return (0); Index: kern_exit.c =================================================================== RCS file: /usr/cvsroot/src/sys/kern/kern_exit.c,v retrieving revision 1.71.2.1 diff -c -r1.71.2.1 kern_exit.c *** kern_exit.c 1999/01/27 20:51:41 1.71.2.1 --- kern_exit.c 1999/02/24 15:51:38 *************** *** 141,152 **** --- 141,155 ---- kill(p, &killArgs); nq = q; q = q->p_peers; + /* messes up signals */ + #if 0 /* * orphan the threads so we don't mess up * when they call exit */ nq->p_peers = 0; nq->p_leader = nq; + #endif } /* otherwise are we a peer? */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 18:46:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from marvin.albury.net.au (marvin.albury.NET.AU [203.15.244.108]) by hub.freebsd.org (Postfix) with ESMTP id 23B0F14C9E for ; Wed, 24 Feb 1999 18:46:54 -0800 (PST) (envelope-from josh2@marvin.albury.net.au) Received: (from josh2@localhost) by marvin.albury.net.au (8.9.1a/8.9.1) id NAA08019 for freebsd-hackers@freebsd.org; Thu, 25 Feb 1999 13:44:23 +1100 (EST) Message-ID: X-Mailer: XFMail 1.1 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Thu, 25 Feb 1999 13:21:24 +1100 (EST) From: Josh To: freebsd-hackers@freebsd.org Subject: structures Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi. I am looking for a structure definition (ifreq) which I think is ....., well I have no idea where it is really. I would love a way to find "system" structure definitions like time_t for example. The structure I am looking for is used in trafshow but I dont think its defined within that program. I have used gtags for the functions, is theresomething similar for structures ? As you can tell I floundering a bit and would love to know how the people on this list manage it. Any pointers appreciated. I am looking at hacking trafshow2 to get byte counting on the ethernet by IP (MAC would be fine) address, if anyone has suggestions regarding this please comment. Josh ---------------------------------- E-Mail: Josh Date: 25-Feb-99 ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 19: 0:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 0E4B414BE6 for ; Wed, 24 Feb 1999 19:00:46 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id TAA24930; Wed, 24 Feb 1999 19:00:30 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.2/8.9.1) id TAA00395; Wed, 24 Feb 1999 19:00:29 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [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: <199902230410.UAA72778@bubba.whistle.com> Date: Wed, 24 Feb 1999 19:00:29 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Archie Cobbs Subject: Re: Interesting ld.so bug Cc: terry@whistle.com, hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Archie Cobbs wrote: > John Polstra writes: >> > Now when we run a java class that uses the java_jni.c native method, >> > the call to Java_bar1() succeeds, and the call from there to bar1() >> > succeeds, but when bar1() tries to call bar2(), it jumps to a very >> > low address and segfaults. It seems that the bar2() trampoline is >> > using an uninitialized base address or whatever. >> > >> > NOW, if we remove "db.c" from the compilation of "libfoo.so", >> > then everything works! >> >> Was the code in the static libgdbm.a library compiled with -fpic? >> I bet it wasn't, and that's probably the problem. All code that's >> included in a shared library should be PIC code. Hey, you never responded to that. Could you try rebuilding libgdbm.a with -fpic and see if it fixes the problem? > Actually, now something else is going on.. here's some more info: > > With db.c Without db.c > --------- ------------ > > RTLD_LAZY fails works! > > RTLD_NOW fails fails > > Terry thinks there is a screwup in RTLD_NOW in that it's failing > to recurse. I don't think that's it. The code is correct as far as I can see. The relocation function isn't supposed to recurse -- it simply loops over all objects that have been loaded since the last time it ran, relocating each one of them. The recursion was done prior to that, in load_needed_objects(). Any time lazy binding works when immediate binding fails, it's most likely because the program doesn't ever actually call the problematic function. So it never has to be bound, therefore the bug isn't encountered. > However, this can be worked around by adding this to the build > of the library (discoverd by Amancio): > > -export-dynamic -lgdbm -lc If you are building a shared library, don't link it against non-PIC static libraries. It kills performance at best, and at worst it is asking for trouble. You should be using "-lc_pic" here, and libgdbm needs to have PIC object files in it. The --export-dynamic thing might be a clue, but it's awfully hard for me to tell. There's no way I can duplicate the problem in any reasonable amount of time based on the description you guys have given me. Every time I think of trying it, I start to wonder if this is a trick -- like maybe I'm on Candid Camera, or America's Funniest Home Videos. "Now let's see if we can get him to attempt constructing THIS test case, *snicker* *giggle* ..." :-) Could you try to distill the test case down to a set of files packed all together into one gzipped tar file smaller than 2 MB, with a Makefile such that I can type "make" to build it and "./test" to run it, and I don't have to install anything into root-owned directories? That's the only way I'm going to be able to do anything on this one. John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 19:10:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id B51F314C8D for ; Wed, 24 Feb 1999 19:10:41 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA70703; Wed, 24 Feb 1999 19:10:23 -0800 (PST) (envelope-from dillon) Date: Wed, 24 Feb 1999 19:10:23 -0800 (PST) From: Matthew Dillon Message-Id: <199902250310.TAA70703@apollo.backplane.com> To: Matthew Jacob Cc: Terry Lambert , dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :There was some moderately appropos discussion today at OSDI about this - :plus a quite amusing discussion of virtual machines. One of the issues :has to do with resource allocation (and, by relation, resource scheduling) :problems when it's hard to figure out whom is driving or paying for an :I/O. : :But I can see there isn't much interest in this in FreeBSD. That's okay- :I'd be just happy to have a system that doesn't crash. We can pray. ( Bends Head ) ... pause ... I'M JOKING! I'M JOKING! -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 19:18:17 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 B568814C9E for ; Wed, 24 Feb 1999 19:17:35 -0800 (PST) (envelope-from dennis@etinc.com) Received: from dbsys (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.8.8/8.6.9) with SMTP id WAA12134 for ; Wed, 24 Feb 1999 22:18:31 -0500 (EST) Message-Id: <199902250318.WAA12134@etinc.com> X-Sender: dennis@etinc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 24 Feb 1999 22:27:27 -0500 To: hackers@freebsd.org From: Dennis Subject: Interrupts in 3.x Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG One of our cards doesnt generate interupts under 3.1R...whats changed that might cause a problem? Is there a doc that outlines the device level changes? dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 19:19: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id AE5D414C4A for ; Wed, 24 Feb 1999 19:18:57 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 2.12 #1) id 10FrJg-000FGl-00; Thu, 25 Feb 1999 05:18:24 +0200 From: Sheldon Hearn To: Josh Cc: freebsd-hackers@freebsd.org Subject: Re: structures In-reply-to: Your message of "Thu, 25 Feb 1999 13:21:24 +1100." Date: Thu, 25 Feb 1999 05:18:24 +0200 Message-ID: <58698.919912704@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 25 Feb 1999 13:21:24 +1100, Josh wrote: > I am looking for a structure definition (ifreq) which I think > is ....., well I have no idea where it is really. Heh, lemme guess, you did this: cd /usr/include; grep -aR 'struct ifreq' * ...and came up with nothing useful, yes? :) It's one of those icky stickies, because the whitespace between struct and ifreq is actually a tab character. :-( Do this instead: cd /usr/include; grep -aR 'struct[ ^V ]* ifreq' * ...where " ^V " is space Control-V TAB (to get your shell to use a literal tab) and you'll find your answer: net/if.h:struct ifreq { Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 19:20:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id DBA5A14C85 for ; Wed, 24 Feb 1999 19:20:40 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id TAA25075; Wed, 24 Feb 1999 19:20:22 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.2/8.9.1) id TAA00439; Wed, 24 Feb 1999 19:20:22 -0800 (PST) (envelope-from jdp@polstra.com) Date: Wed, 24 Feb 1999 19:20:22 -0800 (PST) Message-Id: <199902250320.TAA00439@vashon.polstra.com> To: damian@cablenet.net Subject: Re: Interesting ld.so bug In-Reply-To: <36D1AFBF.58BCFFEF@cablenet.net> References: <199902202154.OAA18160@usr08.primenet.com> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <36D1AFBF.58BCFFEF@cablenet.net>, Damian Hamill wrote: > > I've recently installed version 3 on a system and upgraded to 3.1 and > noticed dynamic loading strangeness too. > > The Apache port won't load dynamic modules as it can't resolve some of > the undefined symbols from the module being loaded which are contained > in the loading process, ap_make_sub_pool for example. > > Using dlsym(NULL,"symbol_name") in one of my own dynamically loaded > modules fails to find "symbol_name" in the loading process, contrary to > the man page and previous behaviour. This has been answered in the mailing lists zillions of times. Your port is out of date, I suspect. You have to add "--export-dynamic" to the linker command line when building the main executable. All of the ports have been updated to do that already, as far as I know. > Similarly I find that I now don't need a leading underscore before > the symbol name to resolve symbols in the module being loaded from > the loading process, again contrary to the man page and previous > behaviour. You're right about the man page -- it's out of date. Thanks for pointing that out. "Previous behavior" has actually accepted the symbol with or without the underscore for probably close to a year by now. > Is this all part of the transition to elf ? Yes. > Do I need to add -elf to CFLAGS ? No, it should already be the default on your system. Type "objformat" and see what it says. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 19:23:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 4656214C8B for ; Wed, 24 Feb 1999 19:23:11 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 2.12 #1) id 10FrNs-000FHr-00; Thu, 25 Feb 1999 05:22:44 +0200 From: Sheldon Hearn To: Josh Cc: freebsd-hackers@freebsd.org Subject: Re: structures In-reply-to: Your message of "Thu, 25 Feb 1999 05:18:24 +0200." <58698.919912704@axl.noc.iafrica.com> Date: Thu, 25 Feb 1999 05:22:44 +0200 Message-ID: <58766.919912964@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 25 Feb 1999 05:18:24 +0200, Sheldon Hearn wrote: > cd /usr/include; grep -aR 'struct[ ^V ]* ifreq' * ^^^ Lose the space between the asterisk and ifreq. Sorry, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 19:25:11 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 AA1DD14C85 for ; Wed, 24 Feb 1999 19:25:09 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id TAA17163; Wed, 24 Feb 1999 19:22:25 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdI17148; Thu Feb 25 03:22:15 1999 Date: Wed, 24 Feb 1999 19:22:01 -0800 (PST) From: Julian Elischer To: John Polstra Cc: Archie Cobbs , terry@whistle.com, hackers@FreeBSD.ORG Subject: Re: Interesting ld.so bug 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 we used bsd.lib.mk so it did -pic automatically On Wed, 24 Feb 1999, John Polstra wrote: > Archie Cobbs wrote: > > John Polstra writes: > >> > Now when we run a java class that uses the java_jni.c native method, > >> > the call to Java_bar1() succeeds, and the call from there to bar1() > >> > succeeds, but when bar1() tries to call bar2(), it jumps to a very > >> > low address and segfaults. It seems that the bar2() trampoline is > >> > using an uninitialized base address or whatever. > >> > > >> > NOW, if we remove "db.c" from the compilation of "libfoo.so", > >> > then everything works! > >> > >> Was the code in the static libgdbm.a library compiled with -fpic? > >> I bet it wasn't, and that's probably the problem. All code that's > >> included in a shared library should be PIC code. > > Hey, you never responded to that. Could you try rebuilding > libgdbm.a with -fpic and see if it fixes the problem? > > > Actually, now something else is going on.. here's some more info: > > > > With db.c Without db.c > > --------- ------------ > > > > RTLD_LAZY fails works! > > > > RTLD_NOW fails fails > > > > Terry thinks there is a screwup in RTLD_NOW in that it's failing > > to recurse. > > I don't think that's it. The code is correct as far as I can see. > The relocation function isn't supposed to recurse -- it simply loops > over all objects that have been loaded since the last time it ran, > relocating each one of them. The recursion was done prior to that, > in load_needed_objects(). > > Any time lazy binding works when immediate binding fails, it's most > likely because the program doesn't ever actually call the problematic > function. So it never has to be bound, therefore the bug isn't > encountered. > > > However, this can be worked around by adding this to the build > > of the library (discoverd by Amancio): > > > > -export-dynamic -lgdbm -lc > > If you are building a shared library, don't link it against non-PIC > static libraries. It kills performance at best, and at worst it is > asking for trouble. You should be using "-lc_pic" here, and libgdbm > needs to have PIC object files in it. > > The --export-dynamic thing might be a clue, but it's awfully hard > for me to tell. There's no way I can duplicate the problem in any > reasonable amount of time based on the description you guys have given > me. Every time I think of trying it, I start to wonder if this is a > trick -- like maybe I'm on Candid Camera, or America's Funniest Home > Videos. "Now let's see if we can get him to attempt constructing THIS > test case, *snicker* *giggle* ..." :-) > > Could you try to distill the test case down to a set of files packed > all together into one gzipped tar file smaller than 2 MB, with a > Makefile such that I can type "make" to build it and "./test" to run > it, and I don't have to install anything into root-owned directories? > That's the only way I'm going to be able to do anything on this one. > > John > --- > John Polstra jdp@polstra.com > John D. Polstra & Co., Inc. Seattle, Washington USA > "Nobody ever went broke underestimating the taste of the American public." > -- H. L. Mencken > > > 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 Feb 24 20:27:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 42D5914D13 for ; Wed, 24 Feb 1999 20:27:32 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id OAA26719; Thu, 25 Feb 1999 14:57:15 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id OAA26154; Thu, 25 Feb 1999 14:57:13 +1030 (CST) Message-ID: <19990225145713.B26110@lemis.com> Date: Thu, 25 Feb 1999 14:57:13 +1030 From: Greg Lehey To: Josh , freebsd-hackers@FreeBSD.ORG Subject: Re: structures References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Josh on Thu, Feb 25, 1999 at 01:21:24PM +1100 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thursday, 25 February 1999 at 13:21:24 +1100, Josh wrote: > Hi. > > I am looking for a structure definition (ifreq) which I think > is ....., well I have no idea where it is really. It's in /sys/sys/net/if.h. > I would love a way to find "system" structure definitions like > time_t for example. The structure I am looking for is used in > trafshow but I dont think its defined within that program. > > I have used gtags for the functions, is there=1Bsomething similar for > structures ? etags will do both functions and structures. That's what I used to look it up, but I believe it only works with Emacs. ctags might do the same if you're a vi user. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 20:36:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ikhala.tcimet.net (ikhala.tcimet.net [198.109.166.215]) by hub.freebsd.org (Postfix) with ESMTP id 4F2DF14CFB for ; Wed, 24 Feb 1999 20:36:41 -0800 (PST) (envelope-from dervish@ikhala.tcimet.net) Received: (from dervish@localhost) by ikhala.tcimet.net (8.9.3/8.9.2) id AAA07711; Thu, 25 Feb 1999 00:00:17 -0500 (EST) (envelope-from dervish) Date: Thu, 25 Feb 1999 00:00:17 -0500 From: Natty Rebel To: Josh Cc: hackers@freebsd.org Subject: Re: structures Message-ID: <19990225000017.A5776@ikhala.tcimet.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Josh on Thu, Feb 25, 1999 at 01:21:24PM +1100 X-Operating-System: FreeBSD 4.0-CURRENT i386 X-PGP-Fingerprint: 2C CE A5 D7 FA 4D D5 FD 9A CC 2B 23 04 46 48 F8 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Quoting Josh (josh2@marvin.albury.net.au): > Hi. Hey there ... #;^) >=20 > I am looking for a structure definition (ifreq) which I think > is ....., well I have no idea where it is really. I would love > a way to find "system" structure definitions like time_t for example. > The structure I am looking for is used in trafshow but I dont think=20 > its defined within that program.=20 > I have used gtags for the functions, is there=1Bsomething similar > for structures ? > As you can tell I floundering a bit and would love to know how > the people on this list manage it. > Any pointers appreciated. grep is your friend. try the following commands: grep -n time_t /usr/include/*|more grep -n ifreq /usr/include/sys/*|more This is what I usually do to find definitions. Also there is a site http://lxr.linux.no/freebsd/source you'll find a cross referencing tool that they used on freebsd sources ... >=20 > I am looking at hacking trafshow2 to get byte counting on the > ethernet by IP (MAC would be fine) address, if anyone has > suggestions regarding this please comment. >=20 > Josh >=20 > ---------------------------------- > E-Mail: Josh > Date: 25-Feb-99 > ---------------------------------- >=20 #;^) --=20 natty rebel harder than the rest ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 20:41: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from TomQNX.tomqnx.com (cpu2745.adsl.bellglobal.com [207.236.55.214]) by hub.freebsd.org (Postfix) with ESMTP id DACBC14D02; Wed, 24 Feb 1999 20:40:49 -0800 (PST) (envelope-from tom@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m10FsYd-000I5dC; Wed, 24 Feb 1999 23:37:55 -0500 (EST) Message-Id: From: tom@tomqnx.com (Tom Torrance at home) Subject: Re: Missing files/directories In-Reply-To: <199902230822.IAA00707@keep.lan.Awfulhak.org> from Brian Somers at "Feb 23, 1999 8:22:47 am" To: brian@Awfulhak.org (Brian Somers) Date: Wed, 24 Feb 1999 23:37:55 -0500 (EST) Cc: tom@tomqnx.com, hackers@FreeBSD.ORG, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM919917475-1022-0_ Content-Transfer-Encoding: 7bit Content-Length: 11787 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --ELM919917475-1022-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Brian, It was a good thought, but we can't put the blame on bad hardware. These tests were done on the RELENG_3 system cvsup'd as of Feb 22 @ 20:00 EST. All tests were run internal to the same machine. So that I don't remain the only guy in the world to see these test results, Control files are included so you can test locally:-) "ppp0 -direct" on localhost is started by port 6671. I know (now) that setting up the test this way the ppp's were communicating via localhost rather than the tunnel, but this way was much cleaner as far as verifying exactly how close the results were to what I saw running the server under 2.2-stable. There were differences, but the main issues are demonstrated. You will recall our discussion about the server hanging around under 2.2-stable after the client is terminated? Required by the RFCs you said? Under RELENG_3 the server meekly goes away, which makes sense to me. Two tests were done. The first involved "kill -KILL clientpid". The second was "kill -TERM clientpid". In the first test, the server illegally removed the default route. In the second test, the server did the same - neither ppp actioned the second command in the linkdown scripts. I was surprised that the first test ended immediately - I thought the LQR packets would cause the server to terminate after 1 minute. Files: test1.netstat0 shows routing after boot test1.netstat1 shows routing after "ppp -background testloop" test1.psaxl show ps results for the executing processes. test1.netstat2 shows routing after killing the client. test1.tun0 ifconfig while active. test1.tun1 ifconfig while active. test2.netstat routing tables after terminating the client. Logs are supplied for both tests. I hope that this is very helpful to you. I really appreciate your efforts!! Cheers, Tom > Hi, > > I don't claim to know a great deal about cache code etc, but I'm > pretty sure that it's extremely unlikely that the file name has any > chance of affecting the buffer cache. While NFS has its fair > share of problems (with which Matt is dealing with admirably), I > would think that the code that does the work there is equally unlikely > to know anything about file names. > > Having said all that in as vague a way as possible, the reason I'm > posting this is that you seem to be experiencing difficulties with > ppp that are of a similar nature - that is, completely inexplicable > and unseen by anyone else - disappearing default routes, ppp.linkdown > not being processed, > > I'm beginning to suspect a hardware problem - perhaps with your disk > controller or something. This wouldn't easily explain the default > route problem, but may explain the failure to process ppp.linkdown.... > > Maybe you could try treating the other machine (your son's machine?) > as the gateway, and see if things become more stable. If they do, > the finger might be pointed more firmly at hardware. > > > On the weekend I reported to hackers about problems experienced with > > 2.2-stable and RELENG-3 systems where I experienced files that > > disappeared from cache and Mail directories that disappeared. > > The RELENG-3 system had files affected with softupdates enabled. > > The 2.2-stable system had sub-directories missing from the > > same directories that I was writing to via nfsv2. > > > > By coincidence, I had cvsup'd and compiled new kernels and naturally > > made the assumption that there was causality there. Subsequently > > I have come to believe that the problem may have more to do with what > > I was doing, not changes to the code. > > > > For about 3-4 hours prior to noticing the problems, I had been > > repetitively editing dot files, then writing a kludge of dot files > > to the local system hard drive and to the nfs exported FS of the > > other computer, while occasionally checking mail on that computer. > > > > All files and directories missing were being updated for > > one reason or another by myself or by mail processes while > > I was doing this. > > > > It is speculation, but there is a good chance that there is a bug > > in the cache-handling code that causes problems with other files > > or directories being dropped from cache because of bad processing > > common to BOTH or ALL releases, when large numbers of dot files are > > being written. The dot files themselves did not disappear - other > > items to be written disappeared before their writes actually > > occurred. > > > > I know that this is a frustrating kind of message to receive, but > > I am not a developer & not qualified to go into the code myself. > > Also no logs or hard output are available - files/directories > > simply disappeared without any error messages. > > > > I just did a scan of the entire /usr/src/sys tree for \"\\.\" > > and \'\\.\' to see what code sections might be affected - mostly > > cache-handling. In quantity, not bad, really. > > > > Others have apparently reported missing files to do with nfs > > I believe. THis might or might not be a related problem. > > > > I guess that I am asking someone who is qualified, and concerned > > about missing files or directories, if they would be willing > > to do what I cannot - check the code for bad interactions when > > dot files are being written- bearing in mind that it is OTHER > > files/directories that are disappearing from cache before being > > written. > > > > Is anyone out there sufficiently intrigued by the possibility > > to invest some valuable time? > > > > I am a QA tester, not a developer, and therefore much more > > comfortable with discussion of symptoms and speculative > > causality than most developers I have known. I hope that > > someone thinks enough of the possibility to invest some > > time, which I know is in very short supply. I cannot deny > > that this is (informed) speculation - there are no guarantees. > > > > Regards and best wishes, > > Tom > > -- > Brian > > Don't _EVER_ lose your sense of humour ! > > > --ELM919917475-1022-0_ Content-Type: application/x-gtar Content-Disposition: attachment; filename=testppp.tgz Content-Description: Test1 and test2 results Content-Transfer-Encoding: base64 H4sIAMfM1DYAA+1dbXPaSBLO1/Ar5nJ1VcmVQ/SCJKAue+XCSdZXjs2ZcPshlQ+yELbOILFIjp37 9TejdwmNpkcSsN5MV23AQD+al+6eme6e3sD2g/5ms+lbnrt8sR+SJUkfDNALhGRDk8grpuQVfyjL A4R0XdfkgS6rOvlEV7QXSNpTewr04AfmFqEXgbeu/d3jnW2vDtGgw9LCXpoPq2Dce+nbAQqcte09 BEiK/lz9vt3YW8dbIDn5xLtF0zvTt9HkzgzQxHNd2wrQxWSKzqf4n4m3Xpvuovdy4fjmzcpG/hbj 2X7vpe2Gf2PI3kvTsuxNCN/rrTxvEz99YX93LButTWf11Mfz8bv7hMVyPdZ1Q45/4ZirtCGOG701 H4I711zbaOt5QfbRvf0DTf97PzT+9noUfeoszcVii/vSl/pyX07eKEjRtH7ynxQ16a3jjtNGW3fm Brd6tfIe0dpb2LgdW9ztKlQlg4++9u3td3uL3n03t++C9ebdxgxu/AV69QpJsmH0eqRL3A+TkCJp fVmT+gO1L1c/iABjxc6e5MdDvfLMBSLvC6O+8ixzdef5QTTcPTxpARdDr3dsWRbET0Fi/1eOe7/w Ht09PINh/xE2+5n9N4j9VzRZ2P+DUGKtsJov7JUd2Jll6UvvlEH6cfLDXi+xdBmLrI36ymCEP5be yXqZRRGW4Y9LBf1/2OzlGUz9N4xM/zWD6D/+odD/Q1BO//HOoqT8mQaHX2YbJ8Xoh+8LxiD8ScES ZEYjz6/k+I/d/Z+eiP7LfdcOsBoEe1I4lv7rUqL/Kj7/Dcj5z5Alof+HoGt8PHPcWxSQs4ff6527 gb3F4jDunWHJcFwzcDw3mahPZmA/mj9Qjj6uzFs/fHdtL6M3c3w6JHRpB84SfXja4PNLLz5n5llz Rxgl/mj+aWalXydvpOjF3ki91HBkKBUfzX/NPSR+HcYoK0/qZQ9Of0ZWv78qKE/zSfZeqmhLRfOl sS6Nh9Z4YY9vlmNbDtty8VvCrMWvowyFvOjDwfHsYEH/5f08g+X/wat+sv4rkq6F+q8K/T8IPTP9 T3YgGaWbipzm5vQ//WmEEjy4Mnr/Swr0Tk0ZqwxJrjllE0AMScWzK1pY3xwp1xylZXO4raMe/0rP o0RbuFwHKjtFbwsZ48w67qAoYJTjW2pVTlHIizGU/mw71oL9V/bzDNb+z5C1dP9n6Epo/xVZ2P9D 0KHsf0cGl9vCxYZD1pUM5XnbJiVpsZKihB8bRhPbFOl/6ADybjuXroiI/ksSTf/xic9I9n+qIUX6 r+lC/w9CH+0bpAyQoowleayM0MLc3ocjgkXiqypr38ZRvG+M1ZrYCYfYh6Vp4Q/CzUsPDoC3gERB xmiytbEhWWAsZK08H78ji48NwooDjCFaGLhEpUhjQ5QsPNkQIItp8gGkcTaUhtn4ACJmVvy0MaZj rpryhjHapsyFqG4bEBIH/ntMTXFgkeOmE08NqjIB9Uy7ptMpmuFviGK9vjGt+1usD+4iDCG/6fMg 3WC2FX794JNNgePf8TCnSh5r9ttfkLexXWI6mqDECQbhDsVrMTplQHvxl0bsSV9wt0CaQTBIpkQO 4ozwmUFgr7G5kJG3RM16Ej4ftwOmZVUIESeBsNg2hwBcTKZj9HH2OVkMXsVQr5DpIxMFW9P1N96W ra4pWNqWWbgCWHeme2ujc9cJwt7htk0iOWqJGKMQwFngbTY7iKrERrwwf9jbUMcaMM9sd4GFb+nc Xtu/v5bfxGvee/72oNPJx8nV5+lX5RsH0/T66ssVP9vpZPL5dPpV/4akJykmDvbP1/Ovg28I73C5 uE4/nU8u55+jx6o3Q1Vd3pgcAP+en16EHf46/IY2Ww/bDktStJNo+/Idi5ZMOrIu7xZAE5mXq2Ty iGDheX2LZ7mJcFzb1vdK4eDH/OmkQ1Itc2kfWTrQ6fzLrxGmRlplKYqKXk9+PZ2SkdHetDIYp9a9 kAkhE2Xbk8oBMT5YRtobn5KgtcAsNDTFIQ29wjuo5qvvvLxRqeYs7WRP8TEAP9+xdk+Ztfzps+8c H48HmboTtHZcMjiu53Jh4V3gBm9sNg94L4iBLi4+XH76gF4vt94awUQhD3T1EIRI1x9m06vLGQYi xyR+nLhBs/lk8mE2azQ2ZPMY7/KbzM2lHTx623sQK0kxbrIBrUNruAMFQWYbxvIBDNYi2paRu0X4 5fTs7JpYx1x+MpydrAKRJQsRdPSffyF/5QU+enSCu/Atsrz1Zmv7PvEXtx3+3Hada7UrYXazraIO ofJHG8JOdgzPp7vdLIZUmWmzGtY1telyWGVc5hsey7L+UXRj4WUt/OA93xSnLqw0eRDV5A62gdzN OGSi5RzOU3OLhzlyjUX+3QVstAr8eKUPnKWDJ8lbIv/BsrDEYphjO+47ojT+I+0vAMSI/2jqQMri P0aY/6cPRPznIFTnVpOwOhhYHaz4lle4V019sLkIQ61zLkGpCSMxHKAlhHZxpASsZSCJDgONJNER oKGkHYTk4hrKXSVrClF/ta05JuU+XBqhIXfVYPi/mVvii8crIRFJfKJwyMNOcYuxhUbmCkvH4gcR jgcfKBMpYtZQfNwwHbxwoAGXjBaiMdEFPlAkpgTDGYqhKQpnLIaqb8DYCY0/FzxhRhwSjG5CDgW0 bmIOAEjeoEM1JPUQw48J9gMWueCOwPLTeD2BRX6wK7DE1iB6UEToyBlIEZFWgSAxnyDf7v7ns513 lyUapbOnEI3nqeq0UCHMl8BaDxo5KAAt5XZQVGOCHPaUDQ/cY0/bbEQue+KlT132oXLygBVc7ZnT nhsi9rJnzvrwJAXw2Ne1B+Szp40O2GlPmR+Q1z7h7chtX4Trxm9PwQQ77mltauO5L2LyO2JL/J16 YiFzwO28p4C29N4zh5HhSzzGMLZz4D/HHrf04TNFp9Ua2akXv87UMN34ReaiH1/Z9eMDJ7rsdVdi r3v1Jf52mDt3/wtw6liF+RCIUwe9lt6M0Scsfv+ztx66+VH21lHRKjYoZ96j24S5IAzx/Ecnfbxq lF0s4O6FC3KFf4SnRx8dt+wpatKntCOkV8m6CgKtknAyzOPqBYyKUyFKlQVnSmgDsGCW6tTAcOqM AlsOYKC5eezzACT12EgdN9xRrKK+bfljJCHPCmxsuR33JPuDVHrjAEeBF2ARkCKFe4eRT9DGNu/z nyC8DvyGR6CMKo9Go/bDCxBJCmpp+/rF3q7J3TabizuXwu1b1b5QMER5puR4pkZGYa5GI517tuJH xdMlazvzJatqlzNGOVtYu1td6PScESPPw0jc7emc4vXB9bZrc/XmzxOm3RvF8V/ffNpfcJN1/1fJ 4r+6pqsk/qsYAxH/PQQl11FVOaoFIMd/K+GLbKg6uaA5wNZpRczVLLzi+89/RvdUJbxwakQd0dv4 xlEvwzMIGqnmkcfTB0OMp0h0vFGo3uhtXPXy2OPzZ6dI/8lVzv09g1n/TUvr/0rSINR/SVGF/h+C yMyP0ZLc4n8/lDT5H/PpyfTq/PLLVfjvyfX88vL88tPJ5/nFl/PJ6ezLL2gdPISO+t5Lx7WD7HhI NmXpVhp/szZ9vDd8Wi6TcMCx+ypol1L931PtJ0Jc+q+H9b8lVeR/HYTIzHei/0pe/2Wh/8+EiP4r Sf2fPT0DXv9noA3UcP3XVbH+H4SeWf2fI9VJGyQLVVUVoePU/0HKMEUhLyNVb1r/Rzlq/R9Fknb1 X9OE/h+EMiebOhrjM3vhNoQyzN2GYNb/YQHw5G1TsbjStjlQqrO2OQCqk7bZAIz6P2wA/vo/XJgl FzsP705lEh5mav0fXhBa/R8eHP76PzwTD6r/UwlIyzivrf/DQqpNOmcxw3LOwSjQ+j+8gKW4DZi9 pv4PFYOv/g+4KdT6P2AEWv0fKkCTZPx6sCZZXE0Q61PxCeKQjVhd/wfIzJP2XQ9JSe1lMNEye5nP qk/sZbBT8npZXIW0Xt0aSkNTUjkAGmX1QieSp/4PEJMr1U1IR1468AFKGY0WN8eVDp7bANwGA5AM KGTi55AJrnRJbuMDSJZs0lBGqiTP6jvf2ahUcgJvE7D4eer/sLDA9X9AQID6PzwNqrhLAB4bylUC 6NxU3CSgsja6SMBAa7oDhUBSrhGAWwS/RcCAZOWCs9hbpII3Gn7GFQIoZjfbKtg9jD/CEHayY3g+ 3e1mMWxzdaBRU5suh4CLAwxevvo/VLDm9X94Ievr/1Si7dTvodf/YS1RtfV/CjDaqAZm5ty6YSLu CQqSHFUYADORvjwc1TAVg1v5/3ptCcbVpgrTlSbwEmOtZIpXqSIwVEpuPlleSh7JgTSWlJYNpcBq QKuTwhLD0w0s7R4Bg7+YnD4weG4RMKCbXSKIQMsp6dBR2NlaJFcIdvdRVEjIBQIqM+DaEZCXT0+g oHxqUjc+rItMjacsblLFpQ9gJ7vSMNCFqyYD31AwYU5vnnED33YBI8RHRNKqB5g41F+XGQxji6Qr ct4maYbGa5WKl2Xwj3cvyxgdWqYdx0I0JJXXZaC2qHxbhsUnLssISinN/zle/UfdyPJ/0/w/TRH5 P4egurCqhO3G8Btf/Uc6CrT+IxOhXR5RAtYykYgOA80koiNAU4l2EFj1H3kgoPUfeTF56z/S8ZvW fwQgsuo/MmUUVv+RCcOZikNTFM5cHKq+AXNnaPz0+o90jG5STgpo3eScACB5k06qIXnqPzIwwXHg Ihc8EFx+Gm8kuMgPDgWX2BpkjxQROgoGU0SkVSLQTz+fsNj+/uezXXSfJRrs+o9CNJ6BqvPUf+Rf DxoFqAAt5Q5QVWOCEjYoGx54xgZtswGo/8gEY9d/hEEA6z/ytQeUs0EbHXDSBmV+QFkbCW9HaRtF uG7yNiiY4MQNWpvaZG4UMfkD8SX+TiPxkDngTt6ggLbM3mAOIyOWfIxhbJfA8Rx73DKHgyk6rdbI TrM46kwNM42jyMxX/5GO1rz+Iz9mbf3H3YB+zcS2yROomwR6iUI6TpMShbvxmR3/05m9QqEXEi1D 79MYSeGgSXjl9dy39pPjByUppqOmbUwxauoe0mHqEiFK8VRIJBqiY4Vyinj3zIzRNpCaVsB1g8AH XBOsbhDmr9mQsxMP6GfTLuYbWkWVZ/AaJx/QACBVZht1Me0XrUQo11xCEg9Ajaovq9lMeVt0tXEW UxGg2zSm0u5or3lMsPFtOmvNcplousKRHsIILJSzO3LpHGSqcske4Mk6VHoH45wNSe6gzA47u6Mi 9CTSOwQJEiRIkCBBggQJEiRIkCBBggQJEiRIkCBBggQJEiRIkKCfif4P0wx0aQDIAAA= --ELM919917475-1022-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 20:54: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id F279614D41 for ; Wed, 24 Feb 1999 20:54:01 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id UAA25442; Wed, 24 Feb 1999 20:53:44 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.2/8.9.1) id UAA00519; Wed, 24 Feb 1999 20:53:43 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [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: Wed, 24 Feb 1999 20:53:43 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Julian Elischer Subject: Re: Interesting ld.so bug Cc: hackers@FreeBSD.ORG, terry@whistle.com, Archie Cobbs Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > we used bsd.lib.mk so it did -pic automatically It doesn't add -fpic when building object files for archive libraries. John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 21: 5:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from TomQNX.tomqnx.com (cpu2745.adsl.bellglobal.com [207.236.55.214]) by hub.freebsd.org (Postfix) with ESMTP id EEDBD14D60; Wed, 24 Feb 1999 20:58:02 -0800 (PST) (envelope-from tom@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m10FspL-000I5dC; Wed, 24 Feb 1999 23:55:11 -0500 (EST) Message-Id: From: tom@tomqnx.com (Tom Torrance at home) Subject: Re: Missing files/directories In-Reply-To: <199902230822.IAA00707@keep.lan.Awfulhak.org> from Brian Somers at "Feb 23, 1999 8:22:47 am" To: brian@Awfulhak.org (Brian Somers) Date: Wed, 24 Feb 1999 23:55:11 -0500 (EST) Cc: tom@tomqnx.com, hackers@FreeBSD.ORG, current@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 Content-Length: 717 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I forgot to mention to those following this thread, files and directories were definitely removed from /root that were not scheduled for writing under ANY circumstances, on the RELENG_3 machine. In fact, on the RELENG_3 machine all files and directories (except ALL the .xxxxx files) were removed from /root. I put a union on the /home directory nfsv2 exported from the 2.2-stable machine, which has been rock-solid ever since. THe problems that system had were when I was writing to its file system from RELENG_3. I am still very suspicious of those dot files even if I am the only one. All files and directories missing are ONLY missing from the directories to which I was writing the dot files! Cheers, Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 21:15:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (s205m7.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id D084514CFC for ; Wed, 24 Feb 1999 21:15:52 -0800 (PST) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id VAA26196; Wed, 24 Feb 1999 21:15:03 -0800 (PST) From: Archie Cobbs Message-Id: <199902250515.VAA26196@bubba.whistle.com> Subject: Re: Interesting ld.so bug In-Reply-To: from John Polstra at "Feb 24, 99 07:00:29 pm" To: jdp@polstra.com (John Polstra) Date: Wed, 24 Feb 1999 21:15:03 -0800 (PST) Cc: terry@whistle.com, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (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 John Polstra writes: > Could you try to distill the test case down to a set of files packed > all together into one gzipped tar file smaller than 2 MB, with a > Makefile such that I can type "make" to build it and "./test" to run > it, and I don't have to install anything into root-owned directories? Certainly, I guess I was hoping you'd say "aha" but if not we can put together a test case.. -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 Wed Feb 24 21:22:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (s205m7.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id A098414E54 for ; Wed, 24 Feb 1999 21:22:08 -0800 (PST) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id VAA26209; Wed, 24 Feb 1999 21:21:20 -0800 (PST) From: Archie Cobbs Message-Id: <199902250521.VAA26209@bubba.whistle.com> Subject: Re: Interesting ld.so bug In-Reply-To: from John Polstra at "Feb 24, 99 08:53:43 pm" To: jdp@polstra.com (John Polstra) Date: Wed, 24 Feb 1999 21:21:20 -0800 (PST) Cc: terry@whistle.com (Terry Lambert), julian@whistle.com (Julian Elischer), hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (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 John Polstra writes: > Julian Elischer wrote: > > we used bsd.lib.mk so it did -pic automatically > > It doesn't add -fpic when building object files for archive libraries. We built both, and even with the shared version it failed.. but whatever, this is just talk.. I'll try to put together a test case. By the way, the workaround works for now so it's become less urgent to fix... though I still believe there's a bug in there somewhere. -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 Wed Feb 24 21:40:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 90E9D14F6C for ; Wed, 24 Feb 1999 21:40:23 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id VAA25579; Wed, 24 Feb 1999 21:40:05 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.2/8.9.1) id VAA00713; Wed, 24 Feb 1999 21:40:04 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [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: <199902250521.VAA26209@bubba.whistle.com> Date: Wed, 24 Feb 1999 21:40:04 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Archie Cobbs Subject: Re: Interesting ld.so bug Cc: hackers@FreeBSD.ORG, (Julian Elischer) , (Terry Lambert) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Archie Cobbs wrote: > John Polstra writes: >> Julian Elischer wrote: >> > we used bsd.lib.mk so it did -pic automatically >> >> It doesn't add -fpic when building object files for archive libraries. > > We built both, and even with the shared version it failed.. Oh well. :-( > but whatever, this is just talk.. I'll try to put together a test > case. By the way, the workaround works for now so it's become less > urgent to fix... though I still believe there's a bug in there > somewhere. I'm inclined to believe you. There's also an outstanding P/R describing what sounds like a similar problem. If you could put together a test case, it would be great. John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 24 22: 6:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rah.star-gate.com (rah.star-gate.com [209.249.129.138]) by hub.freebsd.org (Postfix) with ESMTP id 26A8A14CEE for ; Wed, 24 Feb 1999 22:06:14 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.1/8.8.8) with ESMTP id WAA71554; Wed, 24 Feb 1999 22:04:16 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199902250604.WAA71554@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: John Polstra Cc: Archie Cobbs , terry@whistle.com, hackers@FreeBSD.ORG Subject: Re: Interesting ld.so bug In-reply-to: Your message of "Wed, 24 Feb 1999 19:00:29 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Feb 1999 22:04:16 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I made sure prior to your posting that libgdbm.a was compiled with -fPIC that failed;consequently, I made libdbm a shared library (libdbm compiled with -fPIC ) and kaffe failed with the exact symptom. Amancio > Archie Cobbs wrote: > > John Polstra writes: > >> > Now when we run a java class that uses the java_jni.c native method, > >> > the call to Java_bar1() succeeds, and the call from there to bar1() > >> > succeeds, but when bar1() tries to call bar2(), it jumps to a very > >> > low address and segfaults. It seems that the bar2() trampoline is > >> > using an uninitialized base address or whatever. > >> > > >> > NOW, if we remove "db.c" from the compilation of "libfoo.so", > >> > then everything works! > >> > >> Was the code in the static libgdbm.a library compiled with -fpic? > >> I bet it wasn't, and that's probably the problem. All code that's > >> included in a shared library should be PIC code. > > Hey, you never responded to that. Could you try rebuilding > libgdbm.a with -fpic and see if it fixes the problem? > > > Actually, now something else is going on.. here's some more info: > > > > With db.c Without db.c > > --------- ------------ > > > > RTLD_LAZY fails works! > > > > RTLD_NOW fails fails > > > > Terry thinks there is a screwup in RTLD_NOW in that it's failing > > to recurse. > > I don't think that's it. The code is correct as far as I can see. > The relocation function isn't supposed to recurse -- it simply loops > over all objects that have been loaded since the last time it ran, > relocating each one of them. The recursion was done prior to that, > in load_needed_objects(). > > Any time lazy binding works when immediate binding fails, it's most > likely because the program doesn't ever actually call the problematic > function. So it never has to be bound, therefore the bug isn't > encountered. > > > However, this can be worked around by adding this to the build > > of the library (discoverd by Amancio): > > > > -export-dynamic -lgdbm -lc > > If you are building a shared library, don't link it against non-PIC > static libraries. It kills performance at best, and at worst it is > asking for trouble. You should be using "-lc_pic" here, and libgdbm > needs to have PIC object files in it. > > The --export-dynamic thing might be a clue, but it's awfully hard > for me to tell. There's no way I can duplicate the problem in any > reasonable amount of time based on the description you guys have given > me. Every time I think of trying it, I start to wonder if this is a > trick -- like maybe I'm on Candid Camera, or America's Funniest Home > Videos. "Now let's see if we can get him to attempt constructing THIS > test case, *snicker* *giggle* ..." :-) > > Could you try to distill the test case down to a set of files packed > all together into one gzipped tar file smaller than 2 MB, with a > Makefile such that I can type "make" to build it and "./test" to run > it, and I don't have to install anything into root-owned directories? > That's the only way I'm going to be able to do anything on this one. > > John > --- > John Polstra jdp@polstra.com > John D. Polstra & Co., Inc. Seattle, Washington USA > "Nobody ever went broke underestimating the taste of the American public." > -- H. L. Mencken > > > 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 Feb 24 23:41:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rnocserv.urc.ac.ru (rnocserv.urc.ac.ru [193.233.85.48]) by hub.freebsd.org (Postfix) with ESMTP id 7F75214C11 for ; Wed, 24 Feb 1999 23:40:44 -0800 (PST) (envelope-from joy@urc.ac.ru) Received: from urc.ac.ru (y.urc.ac.ru [193.233.85.37]) by rnocserv.urc.ac.ru (8.8.8/8.8.8) with ESMTP id MAA01070 for ; Thu, 25 Feb 1999 12:40:08 +0500 (ES) (envelope-from joy@urc.ac.ru) Message-ID: <36D4FE57.9D9C5D2E@urc.ac.ru> Date: Thu, 25 Feb 1999 12:40:07 +0500 From: Konstantin Chuguev Organization: Southern Regional Center of FREEnet X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-STABLE i386) X-Accept-Language: ru, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: tkined dynamic loading problem Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi. Am I the only one who has a problem with tkined since scotty and tcl/tk have been moved to ELF? The ptoblem is with tkined script which tries to load tkined1.4.9.so, which in turn SHOULD load libtk.so, but it CANNOT do it. The output is: joy@y:~> tkined Error in startup script: couldn't load file "/usr/local/lib/tkined1.4.9.so": /usr/local/lib/tkined1.4.9.so: Undefined symbol "Tk_CanvasTagsParseProc" while executing "load /usr/local/lib/tkined1.4.9.so" ("package ifneeded" script) invoked from within "package require -exact Tkined 1.4.9" (file "/usr/local/bin/tkined1.4.9" line 12) I know there are some difficulties with implementing such dynamic loading from dynamic libraries/modules in ELF (don't know details, unfortunately), and I know GNU libtool can solve them just fine. But whis would require using libtool for scotty port (and probably for tcl/tk ports). Anyway, as I suppose, libtool just automatically passes some "magic" flags and paths to a linker. I don't know which exactly. ELF linking gurus, please help. -- Konstantin V. Chuguev. System administrator of Southern http://www.urc.ac.ru/~joy/ Ural Regional Center of FREEnet, mailto:joy@urc.ac.ru Chelyabinsk, Russia. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 0: 1:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from svarog.posluh.hr (svarog.posluh.hr [195.29.205.4]) by hub.freebsd.org (Postfix) with ESMTP id C133914CB5 for ; Thu, 25 Feb 1999 00:00:35 -0800 (PST) (envelope-from dmarion@svarog.posluh.hr) Received: (from dmarion@localhost) by svarog.posluh.hr (8.9.2/8.9.1) id JAA15824 for freebsd-hackers@freebsd.org; Thu, 25 Feb 1999 09:00:27 +0100 (CET) (envelope-from dmarion) Date: Thu, 25 Feb 1999 09:00:27 +0100 From: Damjan Marion To: freebsd-hackers@freebsd.org Subject: radio cards Message-ID: <19990225090026.A15749@POSLuH.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i X-no-SPAM: Please don't send me _ANY_ junk mail. X-Operating-System: FreeBSD 3.0-STABLE i386 X-Face: 6|guY+QO+*@'=P`TTtDh+y~?e!RDQ}f?E?^e8y+6\qG_T%Ds(j(V,"(mh7Q?TFk[ZYGuVc" Z2!G:g,U~HKiLT4Y9(#Hs^WX/|K6~Wigp?&`9VRP'o|U)g<1{j?E@i/vDM_jn1o*vE`mfJJK>:6[oh s\9^`=e+Xc\z+d6+|We*h#tGlu#V2y Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does anybody working on support for radio cards on FreeBSD? I wrote driver for GemTek FM Tuner (ISA card), but will be nice to have official support for that type of hardware. -- ________________________________________________________________________ Damjan Marion PGP: http://ds.carnet.hr:11371/pks/lookup?op=get&search=0x39381B15 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 1:16:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 3609814CCE for ; Thu, 25 Feb 1999 01:16:35 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id BAA02250; Thu, 25 Feb 1999 01:16:16 -0800 (PST) (envelope-from dillon) Date: Thu, 25 Feb 1999 01:16:16 -0800 (PST) From: Matthew Dillon Message-Id: <199902250916.BAA02250@apollo.backplane.com> To: Matthew Dillon Cc: Luoqi Chen , dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG, mjacob@feral.com Subject: Re: Panic in FFS/4.0 as of yesterday - update References: <199902231444.JAA02311@lor.watermarkgroup.com> <199902231848.KAA51270@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Oof! Well, that takes the cake. I just had a supervisor stack overflow due to the writerecursion junk in getnewbuf(). 5 levels of (FFS + VN + NFS-FILE) resulted in 60+ subroutine levels in DDB's traceback. That is after DDB faulted on itself with just me hitting return. Doh. I think I have a solution. Normally, B_DELWRI buffers are pushed out by the syncer. Normally getnewbuf() never needs to deal with B_DELWRI buffers. It is only during heavy buffered write I/O where the dirty buffers trash the buffer queues. At the moment, getnewbuf() attempts to convert B_DELWRI buffers into async writes in order to push them out. This is what leads to the recursion problem. I don't think we can afford to recurse even once, therefore we cannot push out B_DELWRI buffers in getnewbuf(). At all. I think the proper solution is to speed up the syncer when getnewbuf() gets starved. I also see a fairly serious potential low-free-buffer lockup. At the moment, getblk() ( which calls getnewbuf() ) treats the lo buffer limit as 'lofreebuffers' and blocks if numfreebuffers < lofreebuffers. I believe we must relax that rule if curproc == updateproc ( i.e. the syncer ), thus guarenteeing sufficient buffers for the syncer to be able to operate in extreme conditions. So, to whit, I am going to start testing changes that remove the async write code from getnewbuf() entirely and implement the emergency reserve for updateproc. It should be fairly straightforward. I'll get the thing reliable and then submit a patch for review. -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 Thu Feb 25 1:47: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (hda-bicnet.bicnet.net [209.244.238.132]) by hub.freebsd.org (Postfix) with ESMTP id 004F714D1F for ; Thu, 25 Feb 1999 01:46:47 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id EAA24470 for hackers@freebsd.org; Thu, 25 Feb 1999 04:38:41 -0500 (EST) From: Peter Dufault Message-Id: <199902250938.EAA24470@hda.hda.com> Subject: pccardd, pccardc, the LabPC+, and the NIDAQ 1200 To: hackers@freebsd.org Date: Thu, 25 Feb 1999 04:38:40 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL25 (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 When I went to write a driver for the PCCARD NI DAQCard 1200 I was pleased to discover that it is register compatible with the LABPC+ with the exception of not supporting DMA. Since the FBSD driver doesn't support DMA it almost works perfectly out of the box. The gotcha is probing. The only way I can get it to probe is with the following machinations. First I run pccardd with this entry in /etc/pccard.conf: > card "National Instruments" "DAQCard-1200" > config 0x1 "labpc0" 5 > insert echo National Instruments DAQCard-1200 inserted > remove echo National Instruments DAQCard-1200 removed and it will then fail with a "Return IRQ=5" on the console and the no "driver allocation failed" message from pccardd. Now if I enable it by hand using pccardc via: pccardc enabler 1 labpc0 -a 0x260 -i 5 it pops up and works fine. If I don't first use "pccardd" "pccardc" doesn't work at all - it won't do a "dumpcis", pccardd must initialize something. Kernel config is: > device labpc0 at isa? port 0x260 tty irq 5 vector labpcintr I assume the kernel looks here for the I/O port, and breakpoints in the probe show that when probed via pccardd it is looking at 0x260, however, it fails the probe when it can't overrun the ADC FIFO. Does anyone understand the interaction between pccardc, pccardd, and the access to I/O ports for pccards to know what the fix is? Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 1:58:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from excalibur.oceanis.net (ns.dotcom.fr [195.154.74.11]) by hub.freebsd.org (Postfix) with ESMTP id 0C8ED14C43 for ; Thu, 25 Feb 1999 01:58:31 -0800 (PST) (envelope-from pixel@excalibur.oceanis.net) Received: (from pixel@localhost) by excalibur.oceanis.net (8.9.1/8.9.1) id JAA29214; Thu, 25 Feb 1999 09:58:05 GMT From: Emmanuel DELOGET Message-Id: <199902250958.JAA29214@excalibur.oceanis.net> Subject: Re: structures In-Reply-To: <58698.919912704@axl.noc.iafrica.com> from Sheldon Hearn at "Feb 25, 1999 5:18:24 am" To: sheldonh@iafrica.com (Sheldon Hearn) Date: Thu, 25 Feb 1999 10:58:05 +0100 (MET) Cc: hackers@FreeBSD.ORG (FreeBSD Hackers Mail List), josh2@marvin.albury.net.au 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 the well known Sheldon Hearn said... ->Do this instead: -> -> cd /usr/include; grep -aR 'struct[ ^V ]* ifreq' * cd /usr/include; grep -n -R -E "struct[[:blank:]]*ifreq" * would include both spaces and tabs, without having to deal with this so simple SPACE-C-V-TAB key sequence :). -> ->net/if.h:struct ifreq { -> -- ____________________________________________________________________ Emmanuel DELOGET [pixel] pixel@{dotcom.fr,epita.fr} ---- DotCom SA -------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 2: 3:45 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 183A314D33 for ; Thu, 25 Feb 1999 02:03:40 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony [10.0.0.6]) by rover.village.org (8.9.3/8.6.6) with ESMTP id KAA10133; Thu, 25 Feb 1999 10:03:23 GMT 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 DAA03943; Thu, 25 Feb 1999 03:03:22 -0700 (MST) Message-Id: <199902251003.DAA03943@harmony.village.org> To: Peter Dufault Subject: Re: pccardd, pccardc, the LabPC+, and the NIDAQ 1200 Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Thu, 25 Feb 1999 04:38:40 EST." <199902250938.EAA24470@hda.hda.com> References: <199902250938.EAA24470@hda.hda.com> Date: Thu, 25 Feb 1999 03:03:21 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199902250938.EAA24470@hda.hda.com> Peter Dufault writes: : Does anyone understand the interaction between pccardc, pccardd, and : the access to I/O ports for pccards to know what the fix is? Generally I've had to hack the drivers to add pcmcia support to them. Take a look at, for example, the ed or sio drivers to see how this is done. Usually it is just a matter of a few lines. I don't know why pccardc enabler would work, but I don't understand that at all... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 2: 8:58 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 039BD14BEA for ; Thu, 25 Feb 1999 02:08:52 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id KAA68421; Thu, 25 Feb 1999 10:08:18 GMT (envelope-from dfr@nlsystems.com) Date: Thu, 25 Feb 1999 10:08:18 +0000 (GMT) From: Doug Rabson To: Matthew Dillon Cc: Luoqi Chen , freebsd-hackers@freebsd.org, mjacob@feral.com Subject: Re: Panic in FFS/4.0 as of yesterday - update In-Reply-To: <199902250916.BAA02250@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 Thu, 25 Feb 1999, Matthew Dillon wrote: > Oof! Well, that takes the cake. I just had a supervisor stack overflow > due to the writerecursion junk in getnewbuf(). 5 levels of > (FFS + VN + NFS-FILE) resulted in 60+ subroutine levels in DDB's traceback. > That is after DDB faulted on itself with just me hitting return. > > Doh. > > I think I have a solution. > > Normally, B_DELWRI buffers are pushed out by the syncer. Normally > getnewbuf() never needs to deal with B_DELWRI buffers. It is only > during heavy buffered write I/O where the dirty buffers trash the > buffer queues. > > At the moment, getnewbuf() attempts to convert B_DELWRI buffers into > async writes in order to push them out. This is what leads to the > recursion problem. I don't think we can afford to recurse even once, > therefore we cannot push out B_DELWRI buffers in getnewbuf(). At all. > > I think the proper solution is to speed up the syncer when getnewbuf() > gets starved. > > I also see a fairly serious potential low-free-buffer lockup. At the > moment, getblk() ( which calls getnewbuf() ) treats the lo buffer limit > as 'lofreebuffers' and blocks if numfreebuffers < lofreebuffers. I > believe we must relax that rule if curproc == updateproc ( i.e. the > syncer ), thus guarenteeing sufficient buffers for the syncer to be > able to operate in extreme conditions. > > So, to whit, I am going to start testing changes that remove the async > write code from getnewbuf() entirely and implement the emergency reserve > for updateproc. It should be fairly straightforward. I'll get the thing > reliable and then submit a patch for review. That sounds like a good idea. The syncer (I think) would write things out in a better order anyway. The writes started by getnewbuf are essentially random, as has been already noted. -- 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 Thu Feb 25 2:11:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 9784514CF6 for ; Thu, 25 Feb 1999 02:09:41 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id CAA02488; Thu, 25 Feb 1999 02:09:24 -0800 (PST) (envelope-from dillon) Date: Thu, 25 Feb 1999 02:09:24 -0800 (PST) From: Matthew Dillon Message-Id: <199902251009.CAA02488@apollo.backplane.com> To: Luoqi Chen , dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG, mjacob@feral.com Subject: Re: Panic in FFS/4.0 as of yesterday - update References: <199902231444.JAA02311@lor.watermarkgroup.com> <199902231848.KAA51270@apollo.backplane.com> <199902250916.BAA02250@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ah. It looks like the numfreebuffers accounting is messed up as well. I had a lockup with processes sitting in 'newbuf' after I added a hard check/sleep based on 'numfreebuffers'. test2:/home/dillon> sysctl -a | fgrep buffers vfs.numdirtybuffers: 149 vfs.lodirtybuffers: 95 vfs.hidirtybuffers: 191 vfs.numfreebuffers: 16715 <----- actually, there were none vfs.lofreebuffers: 81 vfs.hifreebuffers: 162 That could account for quite a bit, actually. It means getblk() wouldn't block when it should. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 2:13:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (hda-bicnet.bicnet.net [209.244.238.132]) by hub.freebsd.org (Postfix) with ESMTP id 5766414D6B for ; Thu, 25 Feb 1999 02:13:08 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id FAA24538; Thu, 25 Feb 1999 05:04:57 -0500 (EST) From: Peter Dufault Message-Id: <199902251004.FAA24538@hda.hda.com> Subject: Re: pccardd, pccardc, the LabPC+, and the NIDAQ 1200 In-Reply-To: <199902251003.DAA03943@harmony.village.org> from Warner Losh at "Feb 25, 99 03:03:21 am" To: imp@harmony.village.org (Warner Losh) Date: Thu, 25 Feb 1999 05:04:57 -0500 (EST) Cc: dufault@hda.com, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (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 > In message <199902250938.EAA24470@hda.hda.com> Peter Dufault writes: > : Does anyone understand the interaction between pccardc, pccardd, and > : the access to I/O ports for pccards to know what the fix is? > > Generally I've had to hack the drivers to add pcmcia support to them. > Take a look at, for example, the ed or sio drivers to see how this is > done. Usually it is just a matter of a few lines. I did that part and during boot I see: > Initializing PC-card drivers: ep labpc sio Both ep and sio continue to work OK. I/O ranges and interrupts in pccard.conf permit 0x260 and 5 and I know I have no conflicts. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 3:29:36 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 48F5A14D32 for ; Thu, 25 Feb 1999 03:29:34 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id DAA28307; Thu, 25 Feb 1999 03:28:54 -0800 Date: Thu, 25 Feb 1999 03:28:54 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday - update In-Reply-To: <199902251009.CAA02488@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 Yow! Indeed that would bung things up. I like also what you said about getnewbuf shouldn't be converting to async writes. Sounds like real good progress is happening here. I'll be back tonight and as sooon as folks are happy with some patches, I'll throw somwe big iron on the testing. On Thu, 25 Feb 1999, Matthew Dillon wrote: > Ah. It looks like the numfreebuffers accounting is messed up as well. > I had a lockup with processes sitting in 'newbuf' after I added a hard > check/sleep based on 'numfreebuffers'. > > test2:/home/dillon> sysctl -a | fgrep buffers > vfs.numdirtybuffers: 149 > vfs.lodirtybuffers: 95 > vfs.hidirtybuffers: 191 > vfs.numfreebuffers: 16715 <----- actually, there were none > vfs.lofreebuffers: 81 > vfs.hifreebuffers: 162 > > That could account for quite a bit, actually. It means getblk() wouldn't > block when it should. > > -Matt > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 3:52:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id F405214D5D for ; Thu, 25 Feb 1999 03:52:24 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id DAA03926; Thu, 25 Feb 1999 03:52:06 -0800 (PST) (envelope-from dillon) Date: Thu, 25 Feb 1999 03:52:06 -0800 (PST) From: Matthew Dillon Message-Id: <199902251152.DAA03926@apollo.backplane.com> To: Matthew Jacob Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday - update References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : : :Yow! Indeed that would bung things up. I like also what you said about :getnewbuf shouldn't be converting to async writes. Sounds like real :good progress is happening here. I'll be back tonight and as sooon as :folks are happy with some patches, I'll throw somwe big iron on the :testing. I'll have a tentitive patch tomorrow. I've got all the code in, including fixing the numfreebuffers/numdirtybuffers counters, but it's pretty involved ( not complex, but lots of little changes in kern/vfs_bio.c and nfs/nfs_vnops.c ) and I gotta get to bed. nfs/nfs_vnops.c is mostly responsible for messing up numfreebuffers but kern/vfs_bio.c also screws it up in certain cases, mainly because people have hacked it over the years and never documented the rules. I think it's going to be a whole lot happier with numfreebuffers fixed *AND* the write recursion removed from getnewbuf(). -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 Thu Feb 25 4:35:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 2096414BFC; Thu, 25 Feb 1999 04:35:46 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 2.12 #1) id 10Fzxh-000FpP-00; Thu, 25 Feb 1999 14:32:17 +0200 From: Sheldon Hearn To: tom@tomqnx.com (Tom Torrance at home) Cc: brian@Awfulhak.org (Brian Somers), hackers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Missing files/directories In-reply-to: Your message of "Wed, 24 Feb 1999 23:55:11 EST." Date: Thu, 25 Feb 1999 14:32:17 +0200 Message-ID: <60846.919945937@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Feb 1999 23:55:11 EST, Tom Torrance at home wrote: > I am still very suspicious of those dot files even if I am the > only one. Hi Tom, Since it does indeed look like you _are_ the only one, I'd suggest putting this discussion on hold until you can come back to the list with the only thing that will carry the thread forward in a productive direction. Namely, come up with an _exact_ set of (preferably command-line) instructions for reproducing the problem. Since we're discussing free software, you can be fairly confident that this isn't a conspiracy to shut you up. It's just difficult for anyone to comment on symptoms he or she imagines impossible without seeing the problem you're reporting. If you can produce a step-by-step guide to reproducing the problem, you're more likely to get some solid answers to your questions. Until then, I imagine everyone else is probably thinking the same thing I am -- "wtf?!" :-) Later, Sheldon PS: I'd also suggest that you use just _one_ FreeBSD mailing list when you do follow up. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 5:46:10 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 7CB5614D76 for ; Thu, 25 Feb 1999 05:46:07 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id IAA26707; Thu, 25 Feb 1999 08:43:25 -0500 (EST) (envelope-from luoqi) Date: Thu, 25 Feb 1999 08:43:25 -0500 (EST) From: Luoqi Chen Message-Id: <199902251343.IAA26707@lor.watermarkgroup.com> To: dillon@apollo.backplane.com Subject: Re: Panic in FFS/4.0 as of yesterday - update Cc: dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG, luoqi@watermarkgroup.com, mjacob@feral.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Oof! Well, that takes the cake. I just had a supervisor stack overflow > due to the writerecursion junk in getnewbuf(). 5 levels of > (FFS + VN + NFS-FILE) resulted in 60+ subroutine levels in DDB's traceback. > That is after DDB faulted on itself with just me hitting return. > > Doh. > > I think I have a solution. > > Normally, B_DELWRI buffers are pushed out by the syncer. Normally > getnewbuf() never needs to deal with B_DELWRI buffers. It is only > during heavy buffered write I/O where the dirty buffers trash the > buffer queues. > There seems to be a problem with buffer kva space accounting: buffer_map is allocated with nbuf*BKVASIZE amount of kva space, but maxbufspace is only initialized to (nbuf+8)*DFLTBSIZE, that means half of the kva space will not be utilized (DFLTBSIZE=4096 BKVASIZE=8192)??? Maybe this is why getblk() didn't block on numfreebuffers and instead thought kva space was out and started to flush the B_DELWRI buffers. > At the moment, getnewbuf() attempts to convert B_DELWRI buffers into > async writes in order to push them out. This is what leads to the > recursion problem. I don't think we can afford to recurse even once, > therefore we cannot push out B_DELWRI buffers in getnewbuf(). At all. > The recurse doesn't seem to be avoidable though, if we have any kind of layered fs. We recurse either with getnewbuf() caller's stack or with syncer's stack. > I think the proper solution is to speed up the syncer when getnewbuf() > gets starved. > This won't help if we can't even recurse once. > I also see a fairly serious potential low-free-buffer lockup. At the > moment, getblk() ( which calls getnewbuf() ) treats the lo buffer limit > as 'lofreebuffers' and blocks if numfreebuffers < lofreebuffers. I > believe we must relax that rule if curproc == updateproc ( i.e. the > syncer ), thus guarenteeing sufficient buffers for the syncer to be > able to operate in extreme conditions. > Yes, if syncer has to recurse. > So, to whit, I am going to start testing changes that remove the async > write code from getnewbuf() entirely and implement the emergency reserve > for updateproc. It should be fairly straightforward. I'll get the thing > reliable and then submit a patch for review. > I don't think we have a thorough understanding of the problem yet (or is it just me?:) For example, we need to answer this question first, what if we're out of kva space instead of free buffers (I believe this was what actually happened and could well be just a false alarm) ? We may need to implement hi/lo watermark for bufspace as well. Another question, do we want to assume syncer's stack can withstand all recursions resulted from a single async write? I feel it's better to have all these design issues sorted out before we start to write code. > -Matt > Matthew Dillon > > > -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 5:58:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from firewall.reed.wattle.id.au (darren2.lnk.telstra.net [139.130.53.33]) by hub.freebsd.org (Postfix) with ESMTP id 81DA014D79 for ; Thu, 25 Feb 1999 05:58:14 -0800 (PST) (envelope-from darrenr@reed.wattle.id.au) Received: (from root@localhost) by firewall.reed.wattle.id.au (8.9.1/8.8.7) id NAA24968 for ; Thu, 25 Feb 1999 13:57:57 GMT Received: from avalon.reed.wattle.id.au(192.168.1.1) by firewall.reed.wattle.id.au via smap (V1.3) id sma024966; Thu Feb 25 13:57:48 1999 Received: from percival.reed.wattle.id.au. (percival.reed.wattle.id.au [192.168.1.5]) by avalon.reed.wattle.id.au (8.9.0.Beta3/8.9.0.Beta3) with SMTP id AAA03961 for ; Fri, 26 Feb 1999 00:57:48 +1100 (EST) From: Darren Reed Message-Id: <199902251357.AAA03961@avalon.reed.wattle.id.au> Subject: boot floppy fails To: hackers@freebsd.org Date: Fri, 26 Feb 1999 00:57:47 +1100 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG using the 2.2.8 boot floppy, it panics and falls over in a heap if there is no wd0 but there is a wd2. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 6:22:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from awfulhak.org (awfulhak.force9.co.uk [195.166.136.63]) by hub.freebsd.org (Postfix) with ESMTP id 37DD014D82; Thu, 25 Feb 1999 06:22:16 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (keep.lan.Awfulhak.org [172.16.0.8]) by awfulhak.org (8.8.8/8.8.8) with ESMTP id OAA29673; Thu, 25 Feb 1999 14:21:56 GMT (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (localhost [127.0.0.1]) by keep.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id NAA39130; Thu, 25 Feb 1999 13:34:32 GMT (envelope-from brian@keep.lan.Awfulhak.org) Message-Id: <199902251334.NAA39130@keep.lan.Awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Sheldon Hearn Cc: tom@tomqnx.com (Tom Torrance at home), brian@Awfulhak.org (Brian Somers), hackers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Missing files/directories In-reply-to: Your message of "Thu, 25 Feb 1999 14:32:17 +0200." <60846.919945937@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Feb 1999 13:34:32 +0000 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [.....] > PS: I'd also suggest that you use just _one_ FreeBSD mailing list when > you do follow up. Indeed - Tom's using RELENG_3, not -current ;^P -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 6:22:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from awfulhak.org (awfulhak.force9.co.uk [195.166.136.63]) by hub.freebsd.org (Postfix) with ESMTP id CAA2914D86; Thu, 25 Feb 1999 06:22:21 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (keep.lan.Awfulhak.org [172.16.0.8]) by awfulhak.org (8.8.8/8.8.8) with ESMTP id OAA29676; Thu, 25 Feb 1999 14:22:00 GMT (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (localhost [127.0.0.1]) by keep.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id NAA39106; Thu, 25 Feb 1999 13:31:19 GMT (envelope-from brian@keep.lan.Awfulhak.org) Message-Id: <199902251331.NAA39106@keep.lan.Awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: tom@tomqnx.com (Tom Torrance at home) Cc: brian@Awfulhak.org (Brian Somers), hackers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Missing files/directories In-reply-to: Your message of "Wed, 24 Feb 1999 23:37:55 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Feb 1999 13:31:19 +0000 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi Brian, > > It was a good thought, but we can't put the blame on bad hardware. > > These tests were done on the RELENG_3 system cvsup'd > as of Feb 22 @ 20:00 EST. All tests were run internal to the > same machine. So that I don't remain the only guy in the world > to see these test results, Control files are included so you > can test locally:-) Your best test engine would be either -current or using the latest ppp from my web site. The RELENG_3 version doesn't have a lot of recent changes. > "ppp0 -direct" on localhost is started by port 6671. > > I know (now) that setting up the test this way the ppp's were > communicating via localhost rather than the tunnel, but this way > was much cleaner as far as verifying exactly how close the results > were to what I saw running the server under 2.2-stable. There were > differences, but the main issues are demonstrated. Hmm, not 100% - see below. > You will recall our discussion about the server hanging around > under 2.2-stable after the client is terminated? Required by the > RFCs you said? Under RELENG_3 the server meekly goes away, which > makes sense to me. > > Two tests were done. The first involved "kill -KILL clientpid". > The second was "kill -TERM clientpid". > In the first test, the server illegally removed the default route. > In the second test, the server did the same - neither ppp actioned > the second command in the linkdown scripts. If a kill -KILL results in your default route disappearing, then that conclusively proves that ppp is not to blame :-/ If find this a bit strange though - this certainly doesn't happen on my machines - I frequently instruct my machine to connect to the 'net and then tunnel into an internal machine with something like ``ssh realmachine ssh internalmachine ppp -direct in''. In my setup, internalmachine is using realmachine as it's default gateway, and that default has never disappeared unexpectedly. WRT the second command, it looks like you've hit a problem that's next on my list to fix - since the radius changes, the interface netmasks are a bit faulty, and it's likely that there were some not-quite-so-bad problems in RELENG_3 too. Your commands should work ok if you change them to ``add 10.0.1.1/32 127.0.0.1'' and ``add 10.0.1.2/32 127.0.0.1''. > I was surprised that the first test ended immediately - I thought > the LQR packets would cause the server to terminate after 1 minute. When you specify the device as a tcp link or a program to execute, ppp can tell immediately when the peer goes away - the results are exactly the same as loosing carrier. This is why testing via the tcp link doesn't always cover all angles (I've suffered from these problems myself). The only problem is when we're using a device that's a character special that doesn't support CD (carrier) > Files: > test1.netstat0 shows routing after boot > test1.netstat1 shows routing after "ppp -background testloop" > test1.psaxl show ps results for the executing processes. > test1.netstat2 shows routing after killing the client. > test1.tun0 ifconfig while active. > test1.tun1 ifconfig while active. > test2.netstat routing tables after terminating the client. > Logs are supplied for both tests. > > I hope that this is very helpful to you. I really appreciate > your efforts!! And I yours - thanks. > Cheers, > Tom -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 6:35:30 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 C9E6314D8E for ; Thu, 25 Feb 1999 06:35:28 -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.2/8.9.1) with ESMTP id JAA48676; Thu, 25 Feb 1999 09:34:53 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <199902251434.JAA48676@whizzo.transsys.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Wes Peters Cc: dyson@iquest.net, Warner Losh , vincef@penmax.com, dennis@etinc.com, hackers@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: cdrom.com bandwidth limits References: <199902231921.OAA03755@y.dyson.net> <36D3A26A.922CE5A9@softweyr.com> In-reply-to: Your message of "Tue, 23 Feb 1999 23:55:38 MST." <36D3A26A.922CE5A9@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Feb 1999 09:34:53 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > "John S. Dyson" wrote: > > > > It is not likely to get that much due to protocol overheads, but I > > have seen >160KBytes/sec on a good T1. Don't T1's do bit stealing > > for signalling (I forget?) > > Unless you are on a "clear channel." If you are, the throughput is > 24 x 64 Kbits/sec, if not, 24 x 64 Kbits/sec - 8 Kbits/sec. The bit > stealing totals 8 Kbits/sec for the entire channel, regardless of how > "big" the channel is. Some CSU/DSU's can be pretty stupid when framing the synchronous data coming in for transmission on the T1 span. The problem they face is that there is a specific one's density requirement when pushing bits over the wire; if you have too many zero bits in a row, then the T1 span will blow it's clocking. So, some really stupid CSU/DSU's will format the data where they "force" every 8th bit to a one. This is how you end up with 1344 kb/s of bandwidth. The other more common way to do this is to observe that most modern uses of T1 spans for data transmission use HDLC bit-synchronous framing these days. If the DSU inverts the data coming in, then the HDCL framing will ensure adequate one's density on the T1 span. In this instance, you get to use all 1536 kb/s of capacity (64kb/s*24 channels) of the T1 span. The 1544 kb/s number you see including the T1 frame overhead, and isn't normally available if you expect to push your bits though a transmission system with other multiplexing equipment (M31 muxes, digital cross connect systems, etc.) louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 7:22:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pan.ch.intel.com (pan.ch.intel.com [143.182.246.24]) by hub.freebsd.org (Postfix) with ESMTP id 3F13C14CF6 for ; Thu, 25 Feb 1999 07:22:11 -0800 (PST) (envelope-from jreynold@sedona.ch.intel.com) Received: from sedona.intel.com (sedona.ch.intel.com [143.182.218.21]) by pan.ch.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id PAA12056 for ; Thu, 25 Feb 1999 15:21:54 GMT Received: from hip186.ch.intel.com (hip186.ch.intel.com [143.182.225.68]) by sedona.intel.com (8.9.1a/8.9.1/d: sendmail.cf,v 1.7 1999/02/08 16:00:31 steved Exp steved $) with ESMTP id IAA03135 for ; Thu, 25 Feb 1999 08:21:46 -0700 (MST) Received: (from jreynold@localhost) by hip186.ch.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) id KAA02086; Thu, 25 Feb 1999 10:21:48 -0500 (EST) From: John Reynolds~ MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14037.27274.794014.568566@hip186.ch.intel.com> Date: Thu, 25 Feb 1999 08:21:46 -0700 (MST) To: freebsd-hackers@freebsd.org Subject: benchmark "challenge" ... X-Mailer: VM 6.64 under Emacs 19.34.1 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG One of my friends who is a zealot in the Linux camp recently sent me this article that he pulled off their kernel mailing list. It's from "mr. lmbench" Larry McVoy: I've been stress testing for the last day or so because I added a 128MB DIMM and started getting crashes (turns out it is a known problem with the FIC 503+ MB, so get the biggest DIMM you can afford - it doesn't seem to like two of them at once). I'm sitting at the system, which is currently doing the following - running X, with an xfishtank & xearth in the background, the fish are moving, albeit slowly - running a "make -j 24" on the kernel - running a "tar cf - . | cat /dev/null" of my home directory, which is NFS mounted, so lots of network traffic - running "scrubber 120" which is a program which allocates 120MB of memory and then walks through it over and over, checking and setting values (this found "bad" memory when I had 2 DIMMS in). I'm running in 128MB total, and this program has an average RSS of 100MB - running lat_pipe and bw_pipe in background, in an infinite loop - running top to watch all this And the system is, while sluggish, responsive while I'm typing. I've opened up windows during all of this and it works, again, sluggish but not so sluggish that you give up. You could actually get work done on a system this busy. I'm very impressed - I do not think that SunOS (or any of the other Unices) ever got to this point. If you did this to them, it was just intolerable. So whatever you did, it's worth it. Quite impressive, actually. Not that, in the grand scheme of the planet, it REALLY matters, but what sorts of "stress tests" do people routinely pull out of -current or more importantly 3.1-stable? I still have a lowly 486 (upgrading RSN :), but I've had more things running at 1 time under X than I thought possible for a 486 (I used to "stress test" OS/2 by starting up gobs of things and it would eventually require a reboot to come back to normal). It would have been nice had he told us what CPU he was using--but I just have to believe that FreeBSD is on par with this "impressive" (well it impressed him) Linux achievement. See ya, -Jr -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | John Reynolds CEG, CCE, Next Generation Flows, HLA | | Intel Corporation MS: CH6-210 Phone: 554-9092 pgr: 868-6512 | | jreynold@sedona.ch.intel.com http://www-aec.ch.intel.com/~jreynold/ | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 7:26:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.ttn.com.tw (mail.ttn.com.tw [210.17.1.3]) by hub.freebsd.org (Postfix) with ESMTP id 2B63D14DB9 for ; Thu, 25 Feb 1999 07:26:00 -0800 (PST) (envelope-from jonahkuo@mail.ttn.com.tw) Received: from mail.ttn.com.tw (cs1p09.txg.ttn.net.tw [210.17.80.105]) by mail.ttn.com.tw (8.9.1/8.9.1) with ESMTP id XAA14710 for ; Thu, 25 Feb 1999 23:25:40 +0800 (CST) Message-ID: <36D6158D.C5CD1482@mail.ttn.com.tw> Date: Fri, 26 Feb 1999 11:31:25 +0800 From: Jonah Kuo X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: wdtimeout. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I recently upgraded my system to 3.1S, and found this message appeared on the console: wd0: interrupt timeout (status 58 error 0) wd0: wdtimeout() DMA status 4 What does it exactly imply? Jonah Kuo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 9:15:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flex.com (flex.com [206.126.0.13]) by hub.freebsd.org (Postfix) with ESMTP id 1609814D8B for ; Thu, 25 Feb 1999 09:14:58 -0800 (PST) (envelope-from localkin@localkine.com) Received: from localhost (localkin@localhost) by flex.com (8.9.1a/8.9.1) with ESMTP id HAA26998; Thu, 25 Feb 1999 07:13:15 -1000 (HST) Date: Thu, 25 Feb 1999 07:13:14 -1000 (HST) From: Terrance Young X-Sender: localkin@flex.com To: jreynold@sedona.ch.intel.com Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: benchmark "challenge" ... 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 John Reynolds~ wrote: > One of my friends who is a zealot in the Linux camp recently sent me this > article that he pulled off their kernel mailing list. It's from "mr. lmbench" > Larry McVoy: > I've been stress testing for the last day or so because I added a > 128MB DIMM and started getting crashes (turns out it is a known > problem with the FIC 503+ MB, so get the biggest DIMM you can > afford - it doesn't seem to like two of them at once). <-- Clip, Ouch was that my finger? --> > Not that, in the grand scheme of the planet, it REALLY matters, but what > sorts of "stress tests" do people routinely pull out of -current or more > importantly 3.1-stable? I still have a lowly 486 (upgrading RSN :), but > I've had more things running at 1 time under X than I thought possible for > a 486 (I used to "stress test" OS/2 by starting up gobs of things and it > would eventually require a reboot to come back to normal). It would have been > nice had he told us what CPU he was using--but I just have to believe that > FreeBSD is on par with this "impressive" (well it impressed him) Linux > achievement. The FIC 503+ Motherboard supports; (P54CT/P54CTB/P55C MMX)Intel Pentium 166~233MHz; AMD-K6 166-300MHz, AMD K6 2 with 3DNow! 266~400Mhz , & Cyrix/IBM 6x86MX & MII chips.. yeah, I think FreeBSD should do good compared to Linux, :-) I have a 2 AMD 586/133's running 2.2.6 and 3.0 and both perform great under load. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 9:43: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (Postfix) with ESMTP id 31A5A14DA6; Thu, 25 Feb 1999 09:43:03 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id KAA14636; Thu, 25 Feb 1999 10:42:46 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA18218; Thu, 25 Feb 1999 10:42:38 -0700 Date: Thu, 25 Feb 1999 10:42:38 -0700 Message-Id: <199902251742.KAA18218@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Craig Spannring Cc: Nate Williams , hackers@FreeBSD.ORG, peter@FreeBSD.ORG Subject: Re: CVS and Y2K In-Reply-To: <199902240506.VAA26449@bangkok.office.cdsnet.net> References: <199902240121.RAA25148@bangkok.office.cdsnet.net> <199902240420.VAA13186@mt.sri.com> <199902240506.VAA26449@bangkok.office.cdsnet.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Does FreeBSD still ship with CVS version 1.9.26? If so it needs > to be > > > upgraded within the next 9 months or so. 1.9.26 can't parse > dates > > > past 1999-12-31. > > > > Have you verified this? > > Yup. I was hit by it a few months ago. It is documented at: > > http://www.cyclic.com/cvs/dev-y2k.html > > It only affects client/server installations. If I remember correctly (and I just perused the CVS sources), this is fixed in 1.9.28. Also, the other major Y2K bugs are easily fixed by using the version of 'getdate.y' from more recent releases. However, I'm not sure if this is acceptable. What I'd like to do (if Peter doesn't mind) is import 1.9.28 (which is what SRI has been using since it was released), and then also import the getdate.[cy] from 1.10 which should fix all known Y2K bugs in CVS, and still keep us totally compatible with older FreeBSD/CVS releases. (We had problems mixing 1.9/1.10 client/servers at SRI, so we reverted to using 1.9.28 client/servers on everything.) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 9:53:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tahiti.oss.uswest.net (tahiti.oss.uswest.net [204.147.85.151]) by hub.freebsd.org (Postfix) with ESMTP id 01FA414D6B for ; Thu, 25 Feb 1999 09:53:10 -0800 (PST) (envelope-from rantapaa@uswest.net) Received: (from rantapaa@localhost) by tahiti.oss.uswest.net (8.8.5/8.6.12) id LAA29330; Thu, 25 Feb 1999 11:52:53 -0600 (CST) Message-ID: <19990225115253.A26408@oss.uswest.net> Date: Thu, 25 Feb 1999 11:52:53 -0600 From: Erik E Rantapaa To: hackers@FreeBSD.ORG Subject: threading options Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, Thanks to all who replied to my previous question about select setting errno to ECHILD. It indeed was a badly written signal handler which was not preserving errno. I would like to inquire about what threading options are available under 2.2.X and 3.X. I've seen references to mit-pthreads, user-level threads, and kernel level threads. Which option would you say is the most reliable at this time, and where could I find documentation on these packages? Initially I will be developing for 2.2.[5-8] and will need to use multi- threaded Sun RPC (client side only) in this application. -- Erik Rantapaa rantapaa@uswest.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 9:55:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from opus.cts.cwu.edu (opus.cts.cwu.edu [198.104.92.71]) by hub.freebsd.org (Postfix) with ESMTP id 034F114DD9 for ; Thu, 25 Feb 1999 09:55:53 -0800 (PST) (envelope-from skynyrd@opus.cts.cwu.edu) Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.9.1/8.9.1) with SMTP id JAA04930; Thu, 25 Feb 1999 09:53:14 -0800 (PST) Date: Thu, 25 Feb 1999 09:53:14 -0800 (PST) From: Chris Timmons To: Konstantin Chuguev Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: tkined dynamic loading problem In-Reply-To: <36D4FE57.9D9C5D2E@urc.ac.ru> 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 Check your Tcl/Tk installation. I am running scotty-2.1.10 on 3.1-stable (elf) without trouble (built from the distribution, not our port) in conjunction with our Tcl80 port. -Chris On Thu, 25 Feb 1999, Konstantin Chuguev wrote: > Hi. > > Am I the only one who has a problem with tkined since scotty and tcl/tk > have been moved to ELF? The ptoblem is with tkined script which tries to > load tkined1.4.9.so, which in turn SHOULD load libtk.so, but it CANNOT > do it. The output is: > joy@y:~> tkined > Error in startup script: couldn't load file > "/usr/local/lib/tkined1.4.9.so": /usr/local/lib/tkined1.4.9.so: > Undefined symbol "Tk_CanvasTagsParseProc" > while executing > "load /usr/local/lib/tkined1.4.9.so" > ("package ifneeded" script) > invoked from within > "package require -exact Tkined 1.4.9" > (file "/usr/local/bin/tkined1.4.9" line 12) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 10:46:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C447E14DA5 for ; Thu, 25 Feb 1999 10:46:41 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA07913; Thu, 25 Feb 1999 10:46:19 -0800 (PST) (envelope-from dillon) Date: Thu, 25 Feb 1999 10:46:19 -0800 (PST) From: Matthew Dillon Message-Id: <199902251846.KAA07913@apollo.backplane.com> To: Luoqi Chen Cc: dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG, luoqi@watermarkgroup.com, mjacob@feral.com Subject: Re: Panic in FFS/4.0 as of yesterday - update References: <199902251343.IAA26707@lor.watermarkgroup.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :There seems to be a problem with buffer kva space accounting: buffer_map :is allocated with nbuf*BKVASIZE amount of kva space, but maxbufspace is :only initialized to (nbuf+8)*DFLTBSIZE, that means half of the kva space :will not be utilized (DFLTBSIZE=4096 BKVASIZE=8192)??? Maybe this is why :getblk() didn't block on numfreebuffers and instead thought kva space was :out and started to flush the B_DELWRI buffers. I noticed that too, but it wasn't the cause of my lockup. If I understand the buffer cache, other entities use the buffer KVA space too, not just the primary buffer cache. There is also the getpbuf() pool. :> At the moment, getnewbuf() attempts to convert B_DELWRI buffers into :> async writes in order to push them out. This is what leads to the :> recursion problem. I don't think we can afford to recurse even once, :> therefore we cannot push out B_DELWRI buffers in getnewbuf(). At all. :> :The recurse doesn't seem to be avoidable though, if we have any kind of :layered fs. We recurse either with getnewbuf() caller's stack or with :syncer's stack. Not exactly. The getnewbuf() recursion occurs because getnewbuf() calls an asynch-write which then, due to the VFS layering, calls getnewbuf() again. getnewbuf() then calls a asynch-write for a totally unrelated buffer that also has VFS layering an the whole thing repeats. If getnewbuf() lets the syncer start the async I/O, getnewbuf() simply blocks in the calling process. There is no recursion. Of course, the syncer may indirectly call getnewbuf() as well, which is why getnewbuf() needs to be able to allocate out of an emergency reserve ( < lonumfreebuffers ) - in order to guarentee that if it *does* block, there are enough writes in progress to clear out some more free buffers. The same emergency reserve must be implemented for KVA space, for the same reason. These 'emergecy reserves' are really just comparisons against summary counters, aka 'numfreebuffers' and 'kvafreespace'. :> as 'lofreebuffers' and blocks if numfreebuffers < lofreebuffers. I :> believe we must relax that rule if curproc == updateproc ( i.e. the :> syncer ), thus guarenteeing sufficient buffers for the syncer to be :> able to operate in extreme conditions. :> :Yes, if syncer has to recurse. That's what the emergency reserve is for. The syncer can, in fact, block, because if the emergency reserve is exhausted then there is known to be I/O in progress by the syncer that will soon be freed up in brelse(). So the syncer shouldn't have to recurse in that case. We may have to play a little with brelse/bqrelse. I don't know yet. I'm fixing the problems one at a time. -Matt : :-lq Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 11:35:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from arjun.niksun.com (gw.niksun.com [206.20.52.122]) by hub.freebsd.org (Postfix) with ESMTP id 6A7DA14DA3 for ; Thu, 25 Feb 1999 11:35:41 -0800 (PST) (envelope-from ath@niksun.com) Received: from stiegl.niksun.com (stiegl.niksun.com [10.0.0.44]) by arjun.niksun.com (8.8.8/8.8.8) with ESMTP id OAA26572 for ; Thu, 25 Feb 1999 14:35:25 -0500 (EST) Received: from stiegl.niksun.com (localhost.niksun.com [127.0.0.1]) by stiegl.niksun.com (8.8.8/8.8.7) with ESMTP id OAA06361 for ; Thu, 25 Feb 1999 14:35:23 -0500 (EST) (envelope-from ath@stiegl.niksun.com) Message-Id: <199902251935.OAA06361@stiegl.niksun.com> From: Andrew Heybey To: freebsd-hackers@freebsd.org Subject: Advice wanted on tracking down bug (or hw problem?) in 3.1R Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 25 Feb 1999 14:35:23 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have just submitted PR kern/10243, but I thought I would ask for some advice on hackers as well. The bug is that under certain loads, read(2) can return corrupted data (ie data that are not in the file on disk). The instances I have seen are relatively small amounts (8-64 bytes) of corrupt data at the end of a 4k page. The corrupt data is from a file previously read or another position in the current file. I have also seen this problem in 3.0-RELEASE but not in 2.2.8-RELEASE. The load under which I see this bug is several programs reading data from disk combined with a very high network interrupt rate (about 45k pkts/sec on an fxp interface in promiscuous mode with a bpf listener). The PR has a longer description of exactly what I am doing to reproduce the bug. I put a tar file containing a small set of programs that I use to generate this load at http://www.niksun.com/~ath/fbsd_bug.tgz if anyone wants to try to reproduce this. It looks to me like not enough splfoo() calls someplace, but I'm not sure where to start looking. Cam? VM? UFS? BPF (though it seems unlikely that BPF would reach out and mess with data from another process)? It is extremely load sensitive so it is difficult to reproduce the same way every time. I can almost always make it happen within 5-10 minutes of testing but not in exactly the same way.q I have reproduced the bug on two different machines, so I don't think that the hw is defective (though the machines have substantially the same kind of hardware so it could be a HW bug of some kind). I would sure appreciate it if someone with a larger collection of clues than I would take a look at this or give me some advice as to where I should start looking. thanks, andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 11:52:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay03.indigo.ie (relay03.indigo.ie [194.125.133.227]) by hub.freebsd.org (Postfix) with SMTP id 0AA7C14DA3 for ; Thu, 25 Feb 1999 11:52:25 -0800 (PST) (envelope-from nsmart@kira.team400.ie) Received: (qmail 14301 messnum 46117 invoked from network[194.125.207.199/ts99-250.dublin.indigo.ie]); 25 Feb 1999 19:52:07 -0000 Received: from ts99-250.dublin.indigo.ie (HELO kira.team400.ie) (194.125.207.199) by relay03.indigo.ie (qp 14301) with SMTP; 25 Feb 1999 19:52:07 -0000 Message-ID: <36D5AA35.898A44C7@kira.team400.ie> Date: Thu, 25 Feb 1999 19:53:25 +0000 From: Niall Smart Organization: Trinity Commerce X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.1-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Bill Paul Cc: hackers@freebsd.org Subject: Re: How to handle jumbo etherney frames References: <199902210458.XAA12913@skynet.ctr.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bill Paul wrote: [snip] > so I'd need to use > contigmalloc() in order to be sure of getting contiguous pages (the > chip will be DMAing into the buffers and it has no knowledge of the > kernel's virtual page mappings). Using contigmalloc() can easily > fail as memory becomes fragmented however. Out of interest, do you know of anyone who has attempted to find out the probability of a contigmalloc of X pages failing given a particular load characteristic? It would be interesting to profile a busy web server, a development box, a file server, a news server, etc to get a rough idea of how likely it is that you'll be able to contigmalloc X pages. Making a wild guess for the moment, lets say 75% of the time you can expect a contigmalloc of three pages to succeed (you need three pages for each 9K frame, right?). When it succeeds you place a normal descriptor on the jumbo ring buffer, when it fails you call malloc and use the scheme you've described involving an extended descriptor. Would this work? Regards Niall (hoping he's making even a moderate amount of sense :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 11:57: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hotmail.com (law-f35.hotmail.com [209.185.131.98]) by hub.freebsd.org (Postfix) with SMTP id 91A4514DA3 for ; Thu, 25 Feb 1999 11:56:56 -0800 (PST) (envelope-from frix_bsd@hotmail.com) Received: (qmail 27071 invoked by uid 0); 18 Jan 1999 12:47:17 -0000 Message-ID: <19990118124717.27070.qmail@hotmail.com> Received: from 147.110.52.37 by www.hotmail.com with HTTP; Mon, 18 Jan 1999 04:47:12 PST X-Originating-IP: [147.110.52.37] From: "Frikkie Thirion" To: freebsd-hackers@freebsd.org Subject: make world fails Date: Mon, 18 Jan 1999 04:47:12 PST Mime-Version: 1.0 Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi there I'm currently running FreeBSD 3.0-RELEASE with only the base bin set installed, along with the CTM src-cur patch set up to 10 January 1999. I'm receiving the following compilation failure when trying to "make aout-to-elf-build" or "make buildworld". It apears asif the compiler wants to use kzip, and reports that it couldn't be found, even though it is there... Any idea on what could have gone wrong? Kind regards Frikkie Thirion I've included the last piece of the log: ===> sys/boot/i386/loader ln -sf /usr/src/sys/boot/i386/loader/../../../i386/include machine cc -nostdinc -O -pipe -DBOOT_FORTH -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/i386/loader/../../common -I/usr/src/sys/boot/i386/loader/../../.. -I. -Wall -I/usr/src/sys/boot/i386/loader/.. -I/usr/src/sys/boot/i386/loader/../btx/lib -elf -DNEW_LINKER_SET -I/usr/obj/elf/usr/src/tmp/usr/include -c /usr/src/sys/boot/i386/loader/main.c /usr/src/sys/boot/i386/loader/main.c: In function `main': /usr/src/sys/boot/i386/loader/main.c:103: warning: implicit declaration of function `bcache_init' cc -nostdinc -O -pipe -DBOOT_FORTH -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/i386/loader/../../common -I/usr/src/sys/boot/i386/loader/../../.. -I. -Wall -I/usr/src/sys/boot/i386/loader/.. -I/usr/src/sys/boot/i386/loader/../btx/lib -elf -DNEW_LINKER_SET -I/usr/obj/elf/usr/src/tmp/usr/include -c /usr/src/sys/boot/i386/loader/conf.c cc -nostdinc -O -pipe -DBOOT_FORTH -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/i386/loader/../../common -I/usr/src/sys/boot/i386/loader/../../.. -I. -Wall -I/usr/src/sys/boot/i386/loader/.. -I/usr/src/sys/boot/i386/loader/../btx/lib -elf -DNEW_LINKER_SET -I/usr/obj/elf/usr/src/tmp/usr/include -c /usr/src/sys/boot/i386/loader/../../common/bcache.c /usr/src/sys/boot/i386/loader/../../common/bcache.c: In function `command_bcache': /usr/src/sys/boot/i386/loader/../../common/bcache.c:255: warning: unsigned int format, long unsigned int arg (arg 3) cc -nostdinc -O -pipe -DBOOT_FORTH -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/i386/loader/../../common -I/usr/src/sys/boot/i386/loader/../../.. -I. -Wall -I/usr/src/sys/boot/i386/loader/.. -I/usr/src/sys/boot/i386/loader/../btx/lib -elf -DNEW_LINKER_SET -I/usr/obj/elf/usr/src/tmp/usr/include -c /usr/src/sys/boot/i386/loader/../../common/boot.c cc -nostdinc -O -pipe -DBOOT_FORTH -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/i386/loader/../../common -I/usr/src/sys/boot/i386/loader/../../.. -I. -Wall -I/usr/src/sys/boot/i386/loader/.. -I/usr/src/sys/boot/i386/loader/../btx/lib -elf -DNEW_LINKER_SET -I/usr/obj/elf/usr/src/tmp/usr/include -c /usr/src/sys/boot/i386/loader/../../common/commands.c cc -nostdinc -O -pipe -DBOOT_FORTH -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/i386/loader/../../common -I/usr/src/sys/boot/i386/loader/../../.. -I. -Wall -I/usr/src/sys/boot/i386/loader/.. -I/usr/src/sys/boot/i386/loader/../btx/lib -elf -DNEW_LINKER_SET -I/usr/obj/elf/usr/src/tmp/usr/include -c /usr/src/sys/boot/i386/loader/../../common/console.c cc -nostdinc -O -pipe -DBOOT_FORTH -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/i386/loader/../../common -I/usr/src/sys/boot/i386/loader/../../.. -I. -Wall -I/usr/src/sys/boot/i386/loader/.. -I/usr/src/sys/boot/i386/loader/../btx/lib -elf -DNEW_LINKER_SET -I/usr/obj/elf/usr/src/tmp/usr/include -c /usr/src/sys/boot/i386/loader/../../common/devopen.c cc -nostdinc -O -pipe -DBOOT_FORTH -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/i386/loader/../../common -I/usr/src/sys/boot/i386/loader/../../.. -I. -Wall -I/usr/src/sys/boot/i386/loader/.. -I/usr/src/sys/boot/i386/loader/../btx/lib -elf -DNEW_LINKER_SET -I/usr/obj/elf/usr/src/tmp/usr/include -c /usr/src/sys/boot/i386/loader/../../common/interp.c /usr/src/sys/boot/i386/loader/../../common/interp.c: In function `interact': /usr/src/sys/boot/i386/loader/../../common/interp.c:96: warning: implicit declaration of function `bf_init' /usr/src/sys/boot/i386/loader/../../common/interp.c:121: warning: implicit declaration of function `bf_run' cc -nostdinc -O -pipe -DBOOT_FORTH -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/i386/loader/../../common -I/usr/src/sys/boot/i386/loader/../../.. -I. -Wall -I/usr/src/sys/boot/i386/loader/.. -I/usr/src/sys/boot/i386/loader/../btx/lib -elf -DNEW_LINKER_SET -I/usr/obj/elf/usr/src/tmp/usr/include -c /usr/src/sys/boot/i386/loader/../../common/interp_backslash.c cc -nostdinc -O -pipe -DBOOT_FORTH -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/i386/loader/../../common -I/usr/src/sys/boot/i386/loader/../../.. -I. -Wall -I/usr/src/sys/boot/i386/loader/.. -I/usr/src/sys/boot/i386/loader/../btx/lib -elf -DNEW_LINKER_SET -I/usr/obj/elf/usr/src/tmp/usr/include -c /usr/src/sys/boot/i386/loader/../../common/interp_parse.c cc -nostdinc -O -pipe -DBOOT_FORTH -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/i386/loader/../../common -I/usr/src/sys/boot/i386/loader/../../.. -I. -Wall -I/usr/src/sys/boot/i386/loader/.. -I/usr/src/sys/boot/i386/loader/../btx/lib -elf -DNEW_LINKER_SET -I/usr/obj/elf/usr/src/tmp/usr/include -c /usr/src/sys/boot/i386/loader/../../common/load_aout.c cc -nostdinc -O -pipe -DBOOT_FORTH -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/i386/loader/../../common -I/usr/src/sys/boot/i386/loader/../../.. -I. -Wall -I/usr/src/sys/boot/i386/loader/.. -I/usr/src/sys/boot/i386/loader/../btx/lib -elf -DNEW_LINKER_SET -I/usr/obj/elf/usr/src/tmp/usr/include -c /usr/src/sys/boot/i386/loader/../../common/load_elf.c cc -nostdinc -O -pipe -DBOOT_FORTH -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/i386/loader/../../common -I/usr/src/sys/boot/i386/loader/../../.. -I. -Wall -I/usr/src/sys/boot/i386/loader/.. -I/usr/src/sys/boot/i386/loader/../btx/lib -elf -DNEW_LINKER_SET -I/usr/obj/elf/usr/src/tmp/usr/include -c /usr/src/sys/boot/i386/loader/../../common/ls.c cc -nostdinc -O -pipe -DBOOT_FORTH -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/i386/loader/../../common -I/usr/src/sys/boot/i386/loader/../../.. -I. -Wall -I/usr/src/sys/boot/i386/loader/.. -I/usr/src/sys/boot/i386/loader/../btx/lib -elf -DNEW_LINKER_SET -I/usr/obj/elf/usr/src/tmp/usr/include -c /usr/src/sys/boot/i386/loader/../../common/misc.c cc -nostdinc -O -pipe -DBOOT_FORTH -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/i386/loader/../../common -I/usr/src/sys/boot/i386/loader/../../.. -I. -Wall -I/usr/src/sys/boot/i386/loader/.. -I/usr/src/sys/boot/i386/loader/../btx/lib -elf -DNEW_LINKER_SET -I/usr/obj/elf/usr/src/tmp/usr/include -c /usr/src/sys/boot/i386/loader/../../common/module.c cc -nostdinc -O -pipe -DBOOT_FORTH -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/i386/loader/../../common -I/usr/src/sys/boot/i386/loader/../../.. -I. -Wall -I/usr/src/sys/boot/i386/loader/.. -I/usr/src/sys/boot/i386/loader/../btx/lib -elf -DNEW_LINKER_SET -I/usr/obj/elf/usr/src/tmp/usr/include -c /usr/src/sys/boot/i386/loader/../../common/panic.c cc -nostdinc -O -pipe -DBOOT_FORTH -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/i386/loader/../../common -I/usr/src/sys/boot/i386/loader/../../.. -I. -Wall -I/usr/src/sys/boot/i386/loader/.. -I/usr/src/sys/boot/i386/loader/../btx/lib -elf -DNEW_LINKER_SET -I/usr/obj/elf/usr/src/tmp/usr/include -c /usr/src/sys/boot/i386/loader/../../common/isapnp.c /usr/src/sys/boot/i386/loader/../../common/isapnp.c:69: warning: `isapnp_read' defined but not used cc -nostdinc -O -pipe -DBOOT_FORTH -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/i386/loader/../../common -I/usr/src/sys/boot/i386/loader/../../.. -I. -Wall -I/usr/src/sys/boot/i386/loader/.. -I/usr/src/sys/boot/i386/loader/../btx/lib -elf -DNEW_LINKER_SET -I/usr/obj/elf/usr/src/tmp/usr/include -c /usr/src/sys/boot/i386/loader/../../common/pnp.c cc -nostdinc -O -pipe -DBOOT_FORTH -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/i386/loader/../../common -I/usr/src/sys/boot/i386/loader/../../.. -I. -Wall -I/usr/src/sys/boot/i386/loader/.. -I/usr/src/sys/boot/i386/loader/../btx/lib -elf -DNEW_LINKER_SET -I/usr/obj/elf/usr/src/tmp/usr/include -c /usr/src/sys/boot/i386/loader/../../common/interp_forth.c /usr/src/sys/boot/i386/loader/../../common/interp_forth.c: In function `bf_init': /usr/src/sys/boot/i386/loader/../../common/interp_forth.c:120: warning: passing arg 1 of `ficlBuild' discards `const' from pointer target type sh /usr/src/sys/boot/i386/loader/newvers.sh /usr/src/sys/boot/i386/loader/version "bootstrap loader" cc -c vers.c cc -nostdlib -static -Ttext 0x1000 -o loader.sym /usr/obj/elf/usr/src/sys/boot/i386/loader/../btx/lib/crt0.o main.o conf.o bcache.o boot.o commands.o console.o devopen.o interp.o interp_backslash.o interp_parse.o load_aout.o load_elf.o ls.o misc.o module.o panic.o isapnp.o pnp.o interp_forth.o vers.o /usr/obj/elf/usr/src/sys/boot/i386/loader/../../ficl/libficl.a -lstand /usr/obj/elf/usr/src/sys/boot/i386/loader/../libi386/libi386.a -lstand cp loader.sym loader.bin strip loader.bin perl /usr/src/sys/boot/i386/loader/../../common/merge_help.pl /usr/src/sys/boot/i386/loader/../../common/help.common /usr/src/sys/boot/i386/loader/help.i386 > loader.help btxld -v -f aout -e 0x100000 -o loader -l /usr/obj/elf/usr/src/sys/boot/i386/loader/../btx/btxldr/btxldr -b /usr/obj/elf/usr/src/sys/boot/i386/loader/../btx/btx/btx loader.bin kernel: ver=0.87 size=6d0 load=9000 entry=9010 map=16M pgctl=1:18 client: fmt=elf size=1b024 text=178cf data=1760 bss=1968 entry=1000 output: fmt=aout size=1e000 text=1000 data=1c000 org=100000 entry=100000 kzip loader kzip: not found *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. bash-2.02# exit exit ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 12: 3:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id AD2B714DF8 for ; Thu, 25 Feb 1999 12:03:42 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA08737; Thu, 25 Feb 1999 12:03:24 -0800 (PST) (envelope-from dillon) Date: Thu, 25 Feb 1999 12:03:24 -0800 (PST) From: Matthew Dillon Message-Id: <199902252003.MAA08737@apollo.backplane.com> To: Luoqi Chen , dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG, mjacob@feral.com Subject: Re: Panic in FFS/4.0 as of yesterday - update References: <199902231444.JAA02311@lor.watermarkgroup.com> <199902231848.KAA51270@apollo.backplane.com> <199902250916.BAA02250@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is very messy, so only hard-core kernel hackers should try this. This should solve the getnewbuf problems, but it required some significant rewriting to re-encapsulate the free/dirty/bufferspace accounting, implement emergency reserves for the updateproc, and to fix NFS. http://freefall.freebsd.org/~dillon/getnewbuf-diff.txt This is not well tested yet. IT MAY BLOW UP YOUR MACHINE! However, I think it is very close to ideal. If there are bugs, they are going to be simple-stupid things rather then design issues. This patch contains a bunch of other cruft from other things, but mainly bug fixes. The size of struct buf also changes ( due to one of the pieces of cruft ). I didn't want to strip this stuff out because then it will not patch cleanly into -current for the people trying to test the getnewbuf() problem. If you want, though, you can remove the struct chain_info junk from the sys/buf.h portion of the patch. It's part of the new VN device's direct-swap support ( not yet committed ). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 12:19:18 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 69EF714FE2 for ; Thu, 25 Feb 1999 12:19:14 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id PAA00939; Thu, 25 Feb 1999 15:18:12 -0500 (EST) (envelope-from luoqi) Date: Thu, 25 Feb 1999 15:18:12 -0500 (EST) From: Luoqi Chen Message-Id: <199902252018.PAA00939@lor.watermarkgroup.com> To: dillon@apollo.backplane.com Subject: Re: Panic in FFS/4.0 as of yesterday - update Cc: dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG, luoqi@watermarkgroup.com, mjacob@feral.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I noticed that too, but it wasn't the cause of my lockup. If I understand > the buffer cache, other entities use the buffer KVA space too, not just > the primary buffer cache. There is also the getpbuf() pool. > P-bufs get their kva from pager_map, seperate from regular bufs which use buffer_map. I did a global search for "buffer_map", and it turned out it's only used by getnewbuf() to allocate buffer kva space, so I'm pretty sure buffer_map is under utilized. > Of course, the syncer may indirectly call getnewbuf() as well, which is > why getnewbuf() needs to be able to allocate out of an emergency reserve > ( < lonumfreebuffers ) - in order to guarentee that if it *does* block, > there are enough writes in progress to clear out some more free buffers. > Yes, this is what I meant. I was a little mistaken though, I was worried this recursion might cause syncer's stack to overflow, but this would not happen, because syncer can tap into the emergency reserve, therefore there won't be a cascade of writes of totally irrelevent bufs. > The same emergency reserve must be implemented for KVA space, for the same > reason. These 'emergecy reserves' are really just comparisons against > summary counters, aka 'numfreebuffers' and 'kvafreespace'. > Agreed. -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 12:24: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id ADD5615097 for ; Thu, 25 Feb 1999 12:23:59 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA08967; Thu, 25 Feb 1999 12:23:38 -0800 (PST) (envelope-from dillon) Date: Thu, 25 Feb 1999 12:23:38 -0800 (PST) From: Matthew Dillon Message-Id: <199902252023.MAA08967@apollo.backplane.com> To: Luoqi Chen Cc: dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG, luoqi@watermarkgroup.com, mjacob@feral.com Subject: Re: Panic in FFS/4.0 as of yesterday - update References: <199902252018.PAA00939@lor.watermarkgroup.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> I noticed that too, but it wasn't the cause of my lockup. If I understand :> the buffer cache, other entities use the buffer KVA space too, not just :> the primary buffer cache. There is also the getpbuf() pool. :> :P-bufs get their kva from pager_map, seperate from regular bufs which use :buffer_map. I did a global search for "buffer_map", and it turned out it's :only used by getnewbuf() to allocate buffer kva space, so I'm pretty sure :buffer_map is under utilized. Ah, ok... that is very easy to fix but I would ask anyone who is testing my patch to *NOT* fix the maxbufspace initialization. Having it artificially low will exercise the buffer cache more. The code needs to be robust enough to survive extreme usage on a small buffer cache. We'll fix it when we commit the final patch. :> Of course, the syncer may indirectly call getnewbuf() as well, which is :> why getnewbuf() needs to be able to allocate out of an emergency reserve :> ( < lonumfreebuffers ) - in order to guarentee that if it *does* block, :> there are enough writes in progress to clear out some more free buffers. :> :Yes, this is what I meant. I was a little mistaken though, I was worried this :recursion might cause syncer's stack to overflow, but this would not happen, :because syncer can tap into the emergency reserve, therefore there won't be :a cascade of writes of totally irrelevent bufs. Right, plus it will block if the emergency reserve runs out. I'm not 100% sure that is safe, but I think it should be .. there should be enough in-transit I/O already in progress so buffers/kva-space free up even when the syncer is blocked. :> The same emergency reserve must be implemented for KVA space, for the same :> reason. These 'emergecy reserves' are really just comparisons against :> summary counters, aka 'numfreebuffers' and 'kvafreespace'. :> :Agreed. : :-lq -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 Thu Feb 25 12:30:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mercury.inktomi.com (mercury.inktomi.com [209.1.32.126]) by hub.freebsd.org (Postfix) with ESMTP id 6298A14EE4 for ; Thu, 25 Feb 1999 12:30:36 -0800 (PST) (envelope-from jplevyak@inktomi.com) Received: from proxydev.inktomi.com (proxydev.inktomi.com [209.1.32.44]) by mercury.inktomi.com (8.9.1a/8.9.1) with ESMTP id MAA01575 for ; Thu, 25 Feb 1999 12:30:28 -0800 (PST) Received: (from jplevyak@localhost) by proxydev.inktomi.com (8.8.5/8.7.3) id MAA07508 for hackers@FreeBSD.ORG; Thu, 25 Feb 1999 12:30:19 -0800 (PST) Message-ID: <19990225123019.B5166@proxydev.inktomi.com> Date: Thu, 25 Feb 1999 12:30:19 -0800 From: John Plevyak To: hackers@FreeBSD.ORG Subject: file locking and kernel pthreads Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I submitted the problem with file locking and kernel pthreads as a bug. There was a race in my last posted fix where the leader could die before all the peers had gotten done with it, so the new patch (attached to the bug report) corrects this problem by having leader's wait until all their peers have died. I would suspect that there are other issues with kernel threads which might be solved more easily if we could guarantee that the 'process leader' did not disappear until all the threads had. john -- John Bradley Plevyak, PhD, jplevyak@inktomi.com, PGP KeyID: 051130BD Inktomi Corporation, 1900 S. Norfolk Street, Suite 110, San Mateo, CA 94403 W:(415)653-2830 F:(415)653-2801 P:(888)491-1332/5103192436.4911332@pagenet.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 13: 4:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from thithle.watson.org (THITHLE.RES.CMU.EDU [128.2.93.231]) by hub.freebsd.org (Postfix) with ESMTP id 4F95514CD0 for ; Thu, 25 Feb 1999 13:04:32 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by thithle.watson.org (8.8.8/8.8.8) with SMTP id QAA03837 for ; Thu, 25 Feb 1999 16:04:15 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Thu, 25 Feb 1999 16:04:14 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: hackers@freebsd.org Subject: Signal--how to find address in SIGSEGV? 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 a userland library that will provide a simple paging service to code linked against it. As such, it catches SIGSEGV and watches for trap 12 (T_PAGEFLT). I notice that i386/i386/machdep.c places the fault address sf.sf_addr; i.e., in the stack frame. However, the signal handler prototype: int signal_handler(int signal, int code, struct sigcontext *scp) does not appear to see that as a possible argument. How can I get access to the address in question in a C-friendly way? Also, is there a way to tell whether or not the address was used in a read or a write (I am guessing not, other than to mprotect the page as neither, then try allowing a read, then a write...?) Thanks, Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 13:11:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ceia.nordier.com (196-31-98-123.iafrica.com [196.31.98.123]) by hub.freebsd.org (Postfix) with ESMTP id C227014DB2 for ; Thu, 25 Feb 1999 13:11:23 -0800 (PST) (envelope-from rnordier@nordier.com) Received: (from rnordier@localhost) by ceia.nordier.com (8.8.7/8.6.12) id XAA09650; Thu, 25 Feb 1999 23:07:11 +0200 (SAT) From: Robert Nordier Message-Id: <199902252107.XAA09650@ceia.nordier.com> Subject: Re: make world fails In-Reply-To: <19990118124717.27070.qmail@hotmail.com> from Frikkie Thirion at "Jan 18, 99 04:47:12 am" To: frix_bsd@hotmail.com (Frikkie Thirion) Date: Thu, 25 Feb 1999 23:07:08 +0200 (SAT) Cc: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (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 Frikkie Thirion wrote: > I'm currently running FreeBSD 3.0-RELEASE with only the base bin set > installed, along with the CTM src-cur patch set up to 10 January 1999. > > I'm receiving the following compilation failure when trying to "make > aout-to-elf-build" or "make buildworld". > > It apears asif the compiler wants to use kzip, and reports that it > couldn't be found, even though it is there... > Any idea on what could have gone wrong? > > Kind regards > Frikkie Thirion You seem to have /sys/boot/i386/loader/Makefile revision 1.24 (or maybe 1.25). This was a known problem that was corrected on 10 or 11 January 1999. You could either update the Makefile to 1.26, or just comment out the two offending lines: Index: Makefile =================================================================== RCS file: /home/ncvs/src/sys/boot/i386/loader/Makefile,v retrieving revision 1.24 diff -u -r1.24 Makefile --- Makefile 1999/01/09 02:38:40 1.24 +++ Makefile 1999/02/25 20:50:17 @@ -71,8 +71,8 @@ ${BASE}: ${BASE}.bin ${BTXLDR} ${BTXKERN} ${BTXCRT} ${BASE}.help btxld -v -f aout -e 0x100000 -o ${.TARGET} -l ${BTXLDR} -b ${BTXKERN} \ ${BASE}.bin - kzip ${.TARGET} - mv ${.TARGET}.kz ${.TARGET} +# kzip ${.TARGET} +# mv ${.TARGET}.kz ${.TARGET} ${BASE}.bin: ${BASE}.sym cp ${.ALLSRC} ${.TARGET} -- Robert Nordier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 13:25:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (Postfix) with ESMTP id 2ACA614E06 for ; Thu, 25 Feb 1999 13:24:48 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id QAA00264 for ; Thu, 25 Feb 1999 16:24:35 -0500 (EST) Date: Thu, 25 Feb 1999 16:24:34 -0500 (EST) From: "Matthew N. Dodd" To: hackers@freebsd.org Subject: IO port access under DOSCMD 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 trying to use DOSCMD to snoop the 'under the hood operation' of some diagnostic utils that muck about with a network card. I'm getting some fairly useless results that lead me to believe that DOSCMD isn't allowing access to the ports in question. (For if it were I would expect the utils to find the cards.) Granted that allowing something to muck about with the IO port space could cause bad things to happen on the test box, I still want to be able to give access to the ports in question. Anyone have any ideas? 'doscmd -P' appears to be invocation to use to enable tracing of all port operations, and I've adjusted MAXPORT in doscmd.h to allow access to ports in the EISA IO address range but nothing works. Thanks. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 14: 4:29 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 38E8214D74 for ; Thu, 25 Feb 1999 14:04:27 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id NAA13502; Thu, 25 Feb 1999 13:58:13 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdW13493; Thu Feb 25 21:58:02 1999 Date: Thu, 25 Feb 1999 13:57:56 -0800 (PST) From: Julian Elischer To: Matthew Dillon Cc: Luoqi Chen , dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG, mjacob@feral.com Subject: Re: Panic in FFS/4.0 as of yesterday - update In-Reply-To: <199902252003.MAA08737@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 a related note.... and something PHK has been on about... the BUF struct.. (yech) this is overlayed with two totally separate functions. one id to keep track of IO states, and the other is to track content of the buf and the state of the contents. Poul has talked of splitting these tow functions and I tend to agree with him.. take this line from the patch file Matt posted about.. (not actually a line h changed, but in the patch) } else if ((bp->b_flags & (B_NOCACHE | B_INVAL | B_ERROR | B_FREEBUF)) || (bp->b_bufsize <= 0)) { bp->b_flags |= B_INVAL; now the flag B_ERROR being true indicates tha the last IO failed. Because of other code nearby we know it was a read. This says that the contents are invalid. This is stupid. Whatever failed the IO should have set the B_INVAL bit and thrown the buf into whatever resource pool is for invalid bufs. The B_ERROR bit really might only be useful as a -ve cache reference.. (don't bother try read this again.. it will fail) but other than this, it is not a state of the buffer. It's a report of a requested operation on the buffer. This is one of the reasons that the vfs, device and vm systems often get confused about buffer states.. The buffer is overloaded. Has anyone got suggestions about this? As I said earlier, I know PHK had some... julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 14: 7:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 4A27714D74 for ; Thu, 25 Feb 1999 14:07:13 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id OAA00656; Thu, 25 Feb 1999 14:06:56 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.2/8.9.1) id OAA01887; Thu, 25 Feb 1999 14:06:56 -0800 (PST) (envelope-from jdp@polstra.com) Date: Thu, 25 Feb 1999 14:06:56 -0800 (PST) Message-Id: <199902252206.OAA01887@vashon.polstra.com> To: robert+freebsd@cyrus.watson.org Subject: Re: Signal--how to find address in SIGSEGV? In-Reply-To: Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article , Robert Watson wrote: > > I'm playing with a userland library that will provide a simple paging > service to code linked against it. As such, it catches SIGSEGV and > watches for trap 12 (T_PAGEFLT). I notice that i386/i386/machdep.c places > the fault address sf.sf_addr; i.e., in the stack frame. However, the > signal handler prototype: > > int > signal_handler(int signal, int code, struct sigcontext *scp) > > does not appear to see that as a possible argument. How can I get access > to the address in question in a C-friendly way? On the i386, the faulting address is in "scp->sc_err". On the alpha, I believe it's in "scp->sc_traparg_a0". > Also, is there a way to tell whether or not the address was used in > a read or a write I don't know of one. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 15: 1:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 680D614E73 for ; Thu, 25 Feb 1999 15:01:17 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA09541; Thu, 25 Feb 1999 15:00:49 -0800 (PST) (envelope-from dillon) Date: Thu, 25 Feb 1999 15:00:49 -0800 (PST) From: Matthew Dillon Message-Id: <199902252300.PAA09541@apollo.backplane.com> To: Julian Elischer Cc: Luoqi Chen , dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG, mjacob@feral.com Subject: Re: Panic in FFS/4.0 as of yesterday - update References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : : : :On a related note.... :and something PHK has been on about... : :the BUF struct.. (yech) :this is overlayed with two totally separate functions. : :one id to keep track of IO states, :and the other is to track content of the buf and the state of the :contents. Poul has talked of splitting these tow functions and I tend to :agree with him.. I tend to agree. There are actually three things: * logical block translation * I/O in progress * Contents of the buffer But lets fix what we have first before we rip it up. The patch I've supplied has one bug in it that came up... While building the world one of my 'ranlib's got stuck in 'newbuf' even after plenty of buffers were freed up. I think it's a simple missing wakeup... when I spiked the load the ranlib got going again ( too bad, I was trying to gdb -k the running system and the gdb command unstuck the ranlib! ). I should be able to find this bug fairly quickly and supply a new patch. It's the only bug I've found so far. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 15:41: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 54CAD14E8E for ; Thu, 25 Feb 1999 15:40:57 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA09708; Thu, 25 Feb 1999 15:40:39 -0800 (PST) (envelope-from dillon) Date: Thu, 25 Feb 1999 15:40:39 -0800 (PST) From: Matthew Dillon Message-Id: <199902252340.PAA09708@apollo.backplane.com> To: Julian Elischer , Luoqi Chen , dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG, mjacob@feral.com Subject: Re: Panic in FFS/4.0 as of yesterday - update References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : The patch I've supplied has one bug in it that came up... While building : the world one of my 'ranlib's got stuck in 'newbuf' even after plenty of : buffers were freed up. I think it's a simple missing wakeup... when : I spiked the load the ranlib got going again ( too bad, I was trying to : gdb -k the running system and the gdb command unstuck the ranlib! ). Fragmentation in the buffer_map, even though it is *twice* the size of maxbufspace, can cause map allocations to fail due to fragmentation. Joy. -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 Thu Feb 25 15:58:31 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 4C31C14D57 for ; Thu, 25 Feb 1999 15:58:24 -0800 (PST) (envelope-from dennis@etinc.com) Received: from dbsys (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.8.8/8.6.9) with SMTP id SAA17347 for ; Thu, 25 Feb 1999 18:59:31 -0500 (EST) Message-Id: <199902252359.SAA17347@etinc.com> X-Sender: dennis@etinc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 25 Feb 1999 19:08:18 -0500 To: hackers@freebsd.org From: Dennis Subject: Device Info on 3.X Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Can anyone point me at info on what changed, specifically for pci devices, in 3.0 vs 2.2? A bullet list would help greatly. VM mapping? thanks, Dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 16: 5:47 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 A639214E44; Thu, 25 Feb 1999 16:04:29 -0800 (PST) (envelope-from lynch@rush.net) Received: from localhost (lynch@localhost) by bytor.rush.net (8.9.3/8.9.3) with ESMTP id TAA01874; Thu, 25 Feb 1999 19:04:09 -0500 (EST) Date: Thu, 25 Feb 1999 19:04:08 -0500 (EST) From: Pat Lynch To: chat@freebsd.org, hackers@freebsd.org Subject: FUNY 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 Hey all.... just a reminder that tomorrow night we will be holding a meeting of the FreeBSD Users of New York at the Bombay Palace at 30 West 52nd Street. (btwn 5th and 6th) We will meet for socialization around 7:30 with business to be attended to around 8:15-8:30. Reservations are under my name. Hope to see you all (the NYC people) there! -Pat ___________________________________________________________________________ Pat Lynch lynch@rush.net Systems Administrator Rush Networking Remark made by Bertrand Meyer (inventor of the Eiffel language) at a panel discussion at OOPSLA '89: "COBOL programmers are destined to code COBOL for the rest of their lives, and thereafter." ___________________________________________________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 18: 1:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id E3F3514DFA for ; Thu, 25 Feb 1999 18:01:40 -0800 (PST) (envelope-from faber@ISI.EDU) Received: from ISI.EDU (vex-e.isi.edu [128.9.160.240]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id SAA03524; Thu, 25 Feb 1999 18:01:22 -0800 (PST) Message-Id: <199902260201.SAA03524@boreas.isi.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: Dennis Cc: hackers@freebsd.org Subject: Re: Device Info on 3.X In-Reply-To: Your message of "Thu, 25 Feb 1999 19:08:18 EST." <199902252359.SAA17347@etinc.com> X-Url: http://www.isi.edu/~faber Date: Thu, 25 Feb 1999 18:01:21 -0800 From: Ted Faber Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- Dennis wrote: > >Can anyone point me at info on what changed, specifically for pci devices, >in 3.0 vs 2.2? A bullet list would help greatly. VM mapping? I'm having a similar problem (a PCI ethernet device that worked under 2.2.7 won't work under 3.0) and I think it might be due to the changes in pci_map_port(). Under 2.2.7 there's some code in pci_map_port() that apparently enables intermediate bridges, but I don't see the same functionality in the pci_map_port in the PCI compatibility code. I've sent some mail to Stefan about this, but he's apparently swamped. If anyone else can take a look at the PCI code and confirm my diagnosis and provide me a workaround or a patch, I'd really appreciate it. It may also be causing you a problem, too. I'd patch it myself, but without a PCI spec, that code looks pretty daunting... - ---------------------------------------------------------------------- Ted Faber faber@isi.edu USC/ISI Computer Scientist http://www.isi.edu/~faber (310) 822-1511 x190 PGP Key: http://www.isi.edu/~faber/pubkey.asc -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNtYAcIb4eisfQ5rpAQHyGwP/S80mLywaVH9KG3HksXSCHQZiLooGCyPj WlSrpBaCdqDqux9H1B/Kru5iVnrSf/QzuHL8sY9minQtr+wWKT0TTplS8qvFg4Rr f0v3Np1GkgTtXjbw0mjwsrYvAiqnK0yp23CGm4Wnth31Q3zlXhfXakGNlrtuJURb 13gj3Vs865o= =gdkp -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 18:37:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id 00F5B14E83; Thu, 25 Feb 1999 18:37:52 -0800 (PST) (envelope-from piet@cup.hp.com) Received: from hpfsvr02.cup.hp.com (root@hpfsvr02.cup.hp.com [15.28.74.198]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id SAA04939; Thu, 25 Feb 1999 18:37:28 -0800 (PST) Received: from piet1.sparc.engr.sgi.com (piet1.cup.hp.com [15.28.75.241]) by hpfsvr02.cup.hp.com with SMTP (8.8.6/8.7.3 TIS Messaging 5.0) id SAA24779; Thu, 25 Feb 1999 18:37:25 -0800 (PST) Date: Thu, 25 Feb 1999 18:37:25 -0800 (PST) From: Piet Delaney Message-Id: <199902260237.SAA24779@hpfsvr02.cup.hp.com> To: johns@umr.edu Subject: Re: 24ibt on ZX/leo framebuffer, cg8/12, and doing kernel src debugging with kernel kgdb stub and ddd+gdb Cc: toddf@acm.org, frivara@otmcorp.com, obrien@nuxi.com, hasty@star-gate.com, piet@piet.net, piet@hpfsvr02.cup.hp.com, charleymeyer@earthlink.net, Loc.Tran@Eng.Sun.COM, netbsd-help@netBSD.Org, tech-kern@netBSD.Org, port-sparc@netBSD.Org, misc@openbsd.org, freebsd-hackers@FreeBSD.Org, freebsd-sparc@FreeBSD.Org, freebsd-chat@FreeBSD.Org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi John: This afternoon I received mail from Todd Fries and he suggested touching bases with you on working on the leo driver(s). I've got a Leo and an sbus based cg8/cg12, I'll have to check which, anyway both are 24 bit true color cards and I wrote a 24 bit true color driver a while back and was wondering about helping out on one. I've got NetBSD, OpenBSD, and Linix running at home on some old SPARCstations and I'm about to install FreeBSD on an Ultra SCSI dual processor Pentium. I'd like to work on the kernel with kgdb but I've been having trouble getting the kgdb stub code linked on the OpenBSD kernel. I used something like kgdb here at HP and have used it on SunOS and Solaris (kdbx). Seems ddd on top should be no sweat. I find it hard to believe that the OpenBSD kernel hackers aren't using kgdb on OpenBSD. Worlds a bit strange. I have to admit I didn't try very hard yet; just a few hours. We really should be running the stub over it's own ethernet code and minimal hooks into the ethernet drivers. Then you can remote debug a lot of kernel bugs on system anywhere in the world; it's real slick. I was a bit impressed that microsoft releases NT with a version compiled -g on the CD for remote src level debugging. I wonder why the major UNIX corporation aren't also doing this. Seem like some lawyers told them the debugger information could be reverse engineered back into code; I really doubt that. If you have any suggestion on the true color frame buffer drivers on setting up kgdb on openbsd, I'd appreciate hearing about it. I know it works on Linux but I'm not sure abot FreeBSD. Likley still works on NetBSD but the code has changes a lot since my old NetBSD got installed. OpenBSD is running pretty good these days, I used ddd and gdb on a core file but the problem wasn't obvious other than I unpluged the scsi connector; seems it shouldn't panic. I set up kgdb on sunos over a few weekends so I doubt it will take very long. The frame buffer driver I did last took about 3 months but all I had was adb. With kgdb I'd expect we could get it working in a few weeks. -piet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 20:37:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hokkshideh.jetcafe.org (hokkshideh.jetcafe.org [205.147.43.4]) by hub.freebsd.org (Postfix) with ESMTP id 0063714EA3 for ; Thu, 25 Feb 1999 20:37:50 -0800 (PST) (envelope-from dave@jetcafe.org) Received: from hokkshideh.jetcafe.org (localhost [127.0.0.1]) by hokkshideh.jetcafe.org (8.8.8/8.8.5) with ESMTP id UAA09666 for ; Thu, 25 Feb 1999 20:37:30 -0800 (PST) Message-Id: <199902260437.UAA09666@hokkshideh.jetcafe.org> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-hackers@freebsd.org Subject: Quake2 and UDP recvspace Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Feb 1999 20:37:30 -0800 From: Dave Hayes Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm runing Quake2 on FreeBSD 2.2.8-RELEASE as a dedicated server. Quake2 with many players basically slams the UDP layer of my machine, for those of you who don't already know. :) Netstat -s reports: udp: 110301027 datagrams received 0 with incomplete header 30 with bad data length field 1377 with bad checksum >> 29882 dropped due to no socket 651167 broadcast/multicast datagrams dropped due to no socket >> 15494 dropped due to full socket buffers 0 not for hashed pcb 109603077 delivered 36475854 datagrams output Now I have my sysctl variables set up like so: net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 9216 net.inet.udp.recvspace: 246723 Note that the recvspace is basically as big as I can make it. I noticed a decrease in the "dropped due to full socket buffers" when I increased the recvspace from the default 16K value. I know that the max value is in the kernel somewhere. My questions are "where?" and "what will this screw up if I change it?". ------ Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org Keep Usenet Free - http://www.jetcafe.org/~dave/usenet >>> The opinions expressed above are entirely my own <<< For hatred can never put an end to hatred, love alone can. This is an unalterable law. -The Dhammapada To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 21:17:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gms.gmsnet.com (gms.gmsnet.com [206.154.112.1]) by hub.freebsd.org (Postfix) with ESMTP id 4540414DD6; Thu, 25 Feb 1999 21:17:31 -0800 (PST) (envelope-from drkhoe@gmsnet.com) Received: (from drkhoe@localhost) by gms.gmsnet.com (GMS888/GMS888) id VAA07090; Thu, 25 Feb 1999 21:17:12 -0800 (PST) Message-Id: <199902260517.VAA07090@gms.gmsnet.com> From: drkhoe@gms.gmsnet.com (Dr. Mosh) Date: Thu, 25 Feb 1999 21:17:11 -0800 Reply-To: drkhoe@gmsnet.com Current: drkhoe@gmsnet.com Other: drkhoe@arkane.com Location: MoshLand (A suburb of LIMBO) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: freebsd-questions@freebsd.org Subject: HELP! Upgrade failure Cc: freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok... I tried using the sysinstall to upgrade from 2.2.8 to 3.1 RELEASE... after the upgrade, it seems the binaries are out of sync or something... if complains about not being able to exec _mount not found in /sbin or /usr/sbin So I can't mount any of the old slices in read-write mode. The new kernel does not respond to bootstrap at all. Upon booting... the boot will respond with Invalid Format Any help is appreciated! Please Respond to: drkhoe@gmsnet.com -- *#&*@#@*(#@#*@(#!@*#(!@#(&!#(@!*#@((#@$(#@(($@#($(#@$@#($@#(*$@(*$*(#(#(##(#(# computersarefasterthanhumans - devastatetoinnovate - hyperspacialparallelcomp\ drkhoe@gmsnet.com = http://progmetal.gmsnet.com = internetcyberwetwaregamedev+ s*o#o$n@@c*o!m^e)s@@t>h gaMECoReTeKN0 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 21:57:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id 298BE14EB0 for ; Thu, 25 Feb 1999 21:57:15 -0800 (PST) (envelope-from bright@cygnus.rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id AAA00994; Fri, 26 Feb 1999 00:56:49 -0500 (EST) Date: Fri, 26 Feb 1999 00:56:47 -0500 (EST) From: Alfred Perlstein To: Dave Hayes Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Quake2 and UDP recvspace In-Reply-To: <199902260437.UAA09666@hokkshideh.jetcafe.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 Thu, 25 Feb 1999, Dave Hayes wrote: > I'm runing Quake2 on FreeBSD 2.2.8-RELEASE as a dedicated server. > Quake2 with many players basically slams the UDP layer of my > machine, for those of you who don't already know. :) > > Netstat -s reports: > > udp: > 110301027 datagrams received > 0 with incomplete header > 30 with bad data length field > 1377 with bad checksum > >> 29882 dropped due to no socket > 651167 broadcast/multicast datagrams dropped due to no socket > >> 15494 dropped due to full socket buffers > 0 not for hashed pcb > 109603077 delivered > 36475854 datagrams output Just from what they mean, i would ignore "29882 dropped due to no socket" that means people were sending you UDP on ports there was no listener. so, realistically: (15494*100) / 109603077 == 0.014136464435 0.01% Is that acceptable packet loss? I also think that it's less the kernel's fault and more the quake server's fault for not eating packets that are sent to it. basically, 0.01% of the time the quake server doesn't recv() fast enough and drops some packets. you could also imagine that some other program may not be recv() fast enough to get packets as this is _total_ not per-socket. i would suggest not worrying about it. -Alfred > > Now I have my sysctl variables set up like so: > > net.inet.udp.checksum: 1 > net.inet.udp.maxdgram: 9216 > net.inet.udp.recvspace: 246723 > > Note that the recvspace is basically as big as I can make it. I > noticed a decrease in the "dropped due to full socket buffers" when I > increased the recvspace from the default 16K value. > > I know that the max value is in the kernel somewhere. My questions > are "where?" and "what will this screw up if I change it?". > ------ > Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org > Keep Usenet Free - http://www.jetcafe.org/~dave/usenet > >>> The opinions expressed above are entirely my own <<< > > For hatred can never put an end to hatred, love alone can. This is an > unalterable law. -The Dhammapada > > > > > 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 Feb 25 23:20:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.nacamar.de (mail.nacamar.de [194.162.162.200]) by hub.freebsd.org (Postfix) with ESMTP id E9DAF14E8A for ; Thu, 25 Feb 1999 23:20:31 -0800 (PST) (envelope-from rohrbach@mail.nacamar.de) Received: (from rohrbach@localhost) by mail.nacamar.de (8.8.7/8.8.8MB-19980212) id IAA07854; Fri, 26 Feb 1999 08:20:11 +0100 (CET) Message-ID: <19990226082011.B7551@nacamar.net> Date: Fri, 26 Feb 1999 08:20:11 +0100 From: "Karsten W. Rohrbach" To: Dave Hayes , freebsd-hackers@FreeBSD.ORG Subject: Re: Quake2 and UDP recvspace Reply-To: rohrbach@nacamar.net Mail-Followup-To: Dave Hayes , freebsd-hackers@FreeBSD.ORG References: <199902260437.UAA09666@hokkshideh.jetcafe.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199902260437.UAA09666@hokkshideh.jetcafe.org>; from Dave Hayes on Thu, Feb 25, 1999 at 08:37:30PM -0800 X-Arbitrary-Number-Of-The-Day: 42 X-Sender: rohrbach@nacamar.net X-Organisation: Nacamar Data Communications GmbH X-Address: Robert-Bosch-Str. 32, 63303 Dreieich, Germany X-Phone: vox: +49 6103 993 870 fax: +49 6103 993 199 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG what boy are you running that qukaeserver on and with what effective bandwidth and how many simultaneous players connected? is it quake or quake2? i got one server here running quakeworld on 2.2.8-r and a qw/quake2 box running on 3.0-current as of july 13 1997 (ouch!) in linux emulation (ouch2!) ;-) but it runs perfectly. /k Dave Hayes (dave@jetcafe.org) @ Thu, Feb 25, 1999 at 08:37:30PM -0800: > I'm runing Quake2 on FreeBSD 2.2.8-RELEASE as a dedicated server. > Quake2 with many players basically slams the UDP layer of my > machine, for those of you who don't already know. :) > > Netstat -s reports: > > udp: > 110301027 datagrams received > 0 with incomplete header > 30 with bad data length field > 1377 with bad checksum > >> 29882 dropped due to no socket > 651167 broadcast/multicast datagrams dropped due to no socket > >> 15494 dropped due to full socket buffers > 0 not for hashed pcb > 109603077 delivered > 36475854 datagrams output > > Now I have my sysctl variables set up like so: > > net.inet.udp.checksum: 1 > net.inet.udp.maxdgram: 9216 > net.inet.udp.recvspace: 246723 > > Note that the recvspace is basically as big as I can make it. I > noticed a decrease in the "dropped due to full socket buffers" when I > increased the recvspace from the default 16K value. > > I know that the max value is in the kernel somewhere. My questions > are "where?" and "what will this screw up if I change it?". > ------ > Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org > Keep Usenet Free - http://www.jetcafe.org/~dave/usenet > >>> The opinions expressed above are entirely my own <<< > > For hatred can never put an end to hatred, love alone can. This is an > unalterable law. -The Dhammapada > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- "The path of excess leads to the tower of wisdom." -- W. Blake http://www.nacamar.de - http://www.nacamar.net - http://www.webmonster.de http://www.apache.de - http://www.quakeforum.de - finger rohrbach@nacamar.net PGP Key fingerprint = F9 A0 DF 91 74 07 6A 1C 5F 0B E0 6B 4D CD 8C 44 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 25 23:50:10 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 5568714EE0; Thu, 25 Feb 1999 23:50:06 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id QAA11748; Fri, 26 Feb 1999 16:49:52 +0900 (JST) Message-ID: <36D64342.535BC758@newsguy.com> Date: Fri, 26 Feb 1999 15:46:26 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Jeroen Ruigrok/Asmodai Cc: "(Jim Mercer)" , freebsd-questions@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: problems with the ep (ethernet) driver? 2.2.[67] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jeroen Ruigrok/Asmodai wrote: > > I do remember a thread about a likewise problem, but cannot for the gods > remember which forum it was. Try a search of questions and net with > promiscuous mode as the search key. I'll try and see what I can find myself. I suspect you might be remembering a thread concerning broadcasts and bad netmasks. The broadcasts were not being received because the netmask was incorrect. When you put the card in promiscuous mode, the netmask ceased to be relevant, and the broadcasts were received. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "To make it absolutely clear: you stand on the wrong end of my blasters, so you better get lost before I start target practice!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 0: 7: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gilberto.physik.RWTH-Aachen.DE (gilberto.physik.rwth-aachen.de [137.226.30.2]) by hub.freebsd.org (Postfix) with ESMTP id CE40414EFA for ; Fri, 26 Feb 1999 00:06:02 -0800 (PST) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: (from kuku@localhost) by gilberto.physik.RWTH-Aachen.DE (8.8.8/8.8.7) id JAA21262 for hackers@freebsd.org; Fri, 26 Feb 1999 09:05:53 +0100 (MET) (envelope-from kuku) Date: Fri, 26 Feb 1999 09:05:53 +0100 (MET) From: Christoph Kukulies Message-Id: <199902260805.JAA21262@gilberto.physik.RWTH-Aachen.DE> To: hackers@freebsd.org Subject: cpu detection program Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Found this in another mailing list. FWIW, ftp://ftp.scitechsoft.com/devel/cpu/readme.txt (may be 'cold coffee', as we say in Germany, or 'yesterday's snow') -- 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 Feb 26 0:21:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id E965814EEA for ; Fri, 26 Feb 1999 00:21:23 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id AAA13377; Fri, 26 Feb 1999 00:21:06 -0800 (PST) (envelope-from dillon) Date: Fri, 26 Feb 1999 00:21:06 -0800 (PST) From: Matthew Dillon Message-Id: <199902260821.AAA13377@apollo.backplane.com> To: dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG, mjacob@feral.com Subject: New patch available... getnewbuf() bug References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've put up a new patchset at: http://www.backplane.com/FreeBSD4/ For those people who are testing the getnewbuf() problems. I managed to buildworld with it once so far. You may want to wait for me to get a few more builds under my test machine's belt before you spend time messing with it. Also on this site are patches for umpteen other things, which I am slowly organizing. The most interesting one is the new VN device which supports direct swap-backing if you so choose ( but don't you dare run out of swap using it :-) ). Not all patches are destined for commit, but most of them are. -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 Feb 26 0:28: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from waldorf.appli.se (waldorf.appli.se [194.198.196.14]) by hub.freebsd.org (Postfix) with ESMTP id 24AFB14EE4; Fri, 26 Feb 1999 00:27:55 -0800 (PST) (envelope-from niklas@petra.appli.se) Received: from petra.appli.se (petra.appli.se [194.198.196.24]) by waldorf.appli.se (8.9.1a/8.9.1) with ESMTP id JAA00123; Fri, 26 Feb 1999 09:14:47 +0100 (CET) Message-Id: <199902260814.JAA00123@waldorf.appli.se> To: Piet Delaney Cc: johns@umr.edu, toddf@acm.org, frivara@otmcorp.com, obrien@nuxi.com, hasty@star-gate.com, piet@piet.net, piet@hpfsvr02.cup.hp.com, charleymeyer@earthlink.net, Loc.Tran@Eng.Sun.COM, netbsd-help@netBSD.Org, tech-kern@netBSD.Org, port-sparc@netBSD.Org, misc@openbsd.org, freebsd-hackers@FreeBSD.Org, freebsd-sparc@FreeBSD.Org, freebsd-chat@FreeBSD.Org Subject: Re: 24ibt on ZX/leo framebuffer, cg8/12, and doing kernel src debugging with kernel kgdb stub and ddd+gdb In-reply-to: Your message of "Thu, 25 Feb 1999 18:37:25 PST." <199902260237.SAA24779@hpfsvr02.cup.hp.com> Date: Fri, 26 Feb 1999 09:14:47 +0100 From: Niklas Hallqvist Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Date: Thu, 25 Feb 1999 18:37:25 -0800 (PST) > From: Piet Delaney > If you have any suggestion on the true color frame buffer drivers on > setting up kgdb on openbsd, I'd appreciate hearing about it. I have KGDB in the pipe, at least for i386, should not be hard to fix for sparc. The only problem is with me getting time to test this stuff. I used the NetBSD support as a base. Most of us have developped a skill with DDB so KGDB has not been as asked for as it could be. I agree DDB is a poor substitute for KGDB though. But it works on a single machine, KGDB requires 2, so it has at least one advantage. Niklas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 0:36:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by hub.freebsd.org (Postfix) with ESMTP id 5766114F0C for ; Fri, 26 Feb 1999 00:35:54 -0800 (PST) (envelope-from dmm125@bellatlantic.net) Received: from dmm125 (client201-122-166.bellatlantic.net [151.201.122.166]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with SMTP id DAA29935 for ; Fri, 26 Feb 1999 03:35:20 -0500 (EST) Message-ID: <000701be6162$b52458e0$02000003@dmm125> From: "Donn Miller" To: Subject: Accessing the BIOS... Date: Fri, 26 Feb 1999 03:33:18 -0500 X-Priority: 3 X-Mailer: Microsoft Outlook Express 5.00.0810.800 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I need to find out some information about how to write apps that access the BIOS in FreeBSD. Obviously, since we are dealing with proteced mode, we can't use INT 10h. My understanding is this (help me out here if I'm wrong): (*) FreeBSD makes a copy of the Bios image, which is what, 32kB in length? We need to find a pointer to the start of the Bios image, also known as the protected mode entry point. (*) FreeBSD also makes a copy of the first 0x600 bytes of conventional memory, which may or may not be stored within the already existing BIOS image. Obviously, a far pointer is required to access this if it is outside the range of the 32kB BIOS image. FWIU, DOS uses address locations 0x000-0x600 for some BIOS services, such as writing to the VGA display. It does this by passing arguments in the various registers (such as AX or EAX) and calling INT 10. In 16-bit or 32-bit protected mode, I don't know which, you can't pass arguments in AX and call int10. You have to get a pointer to the protected mode entry point. (*) Does FBSD use 16 or 32 bit protected-mode BIOS calls? If they are 16-bit, I think you use a selector:offest in the format 16:16. 32-bit protected-mode calls have a selector:offset format of 16:32. I know this must involve using some arithmetic with DS or ES registers, but I'm not sure. (*) When FreeBSD makes a copy of the 32kB of BIOS, does it put it in the same location every time? Also, I imagine Linux is very similar in its handling of protected-mode BIOS calls, but it probably puts the image in a different place, etc. It seems like BIOS calls are pretty complicated in protected mode. Why aren't we allowed to use INT 0x10, and use the registers (AX, etc.) in protected mode, but real mode allows this? I know other platforms, such as Macs, Sun SPARCS, and Alpha Stations don't have an explicit BIOS, but they do have some equivalent, like some kind of firmware. Is programming the "BIOS" in non-intel platforms as difficult as programming the BIOS on PC's? I think a good source of info would be Ralph's interrupt list. ;-) Thanks Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 1:41:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from leaf.lumiere.net (leaf.lumiere.net [207.218.152.15]) by hub.freebsd.org (Postfix) with ESMTP id 6CAFF14F50; Fri, 26 Feb 1999 01:41:33 -0800 (PST) (envelope-from j@leaf.lumiere.net) Received: (from j@localhost) by leaf.lumiere.net (8.9.2/8.9.1) id BAA66884; Fri, 26 Feb 1999 01:41:17 -0800 (PST) Date: Fri, 26 Feb 1999 01:41:16 -0800 (PST) From: Jesse To: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Subject: fails to recognize any PCI cards (PicMG) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I have three servers with PicMG motherboards that I'm trying to convert from Windows NT to FreeBSD. I don't have much experience with this type of setup (passive backplanes), so you'll have to excuse me if I'm missing something obvious. I've tried installing FreeBSD 2.2.8-RELEASE and 3.1-RELEASE on these servers, however they fail to recognize any PCI cards (Adaptec 2940UWs, Intel EtherExpress Pro 10/100 Bs). Just to see what would happen, I tried install Redhat 5.2 on one of the servers. It installed fine. Is there any way to get FreeBSD working on this motherboard? Some special patch or kernel build? Any help would be appreciated. PicMG Model: PCI-14S Ver: B Thanks in advance, --- Jesse http://www.lumiere.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 3:41: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from excalibur.oceanis.net (ns.dotcom.fr [195.154.74.11]) by hub.freebsd.org (Postfix) with ESMTP id 8A12514F34 for ; Fri, 26 Feb 1999 03:40:45 -0800 (PST) (envelope-from pixel@excalibur.oceanis.net) Received: (from pixel@localhost) by excalibur.oceanis.net (8.9.1/8.9.1) id LAA18798 for hackers@FreeBSD.ORG; Fri, 26 Feb 1999 11:40:28 GMT From: Emmanuel DELOGET Message-Id: <199902261140.LAA18798@excalibur.oceanis.net> Subject: mount --> page fault To: hackers@FreeBSD.ORG (FreeBSD Hackers Mail List) Date: Fri, 26 Feb 1999 12:40:28 +0100 (MET) 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, Hackers, I'm currently hacking the 2.2.8 kern_sysctl.c file (no... stop with this 'go up to 3.x'... I just can't... :)). After some interresting errors that I think I have fixed, the boot process began... And then stops on a page fault (trap 12, supervisor read, no page) when it began to mount the / filesystem. I don't know what's the problem - I must be dumb, but I tried to debug the kernel and it didn't work :(. If anybody has an idea, that would be nice. Thx in advance, -- ____________________________________________________________________ Emmanuel DELOGET [pixel] pixel@{dotcom.fr,epita.fr} ---- DotCom SA -------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 3:48:45 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 711C414F29 for ; Fri, 26 Feb 1999 03:48:19 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id LAA71222; Fri, 26 Feb 1999 11:47:43 GMT (envelope-from dfr@nlsystems.com) Date: Fri, 26 Feb 1999 11:47:31 +0000 (GMT) From: Doug Rabson To: Matthew Dillon Cc: Julian Elischer , Luoqi Chen , freebsd-hackers@FreeBSD.ORG, mjacob@feral.com Subject: Re: Panic in FFS/4.0 as of yesterday - update In-Reply-To: <199902252340.PAA09708@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 Thu, 25 Feb 1999, Matthew Dillon wrote: > : The patch I've supplied has one bug in it that came up... While building > : the world one of my 'ranlib's got stuck in 'newbuf' even after plenty of > : buffers were freed up. I think it's a simple missing wakeup... when > : I spiked the load the ranlib got going again ( too bad, I was trying to > : gdb -k the running system and the gdb command unstuck the ranlib! ). > > Fragmentation in the buffer_map, even though it is *twice* the size of > maxbufspace, can cause map allocations to fail due to fragmentation. Defragment by moving non-busy buffers around in the map? Not a huge amount of fun to be had there :-(. -- 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 Fri Feb 26 3:52:36 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 DF1B114C2F for ; Fri, 26 Feb 1999 03:52:33 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id LAA71371; Fri, 26 Feb 1999 11:52:11 GMT (envelope-from dfr@nlsystems.com) Date: Fri, 26 Feb 1999 11:52:11 +0000 (GMT) From: Doug Rabson To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, mjacob@feral.com Subject: Re: New patch available... getnewbuf() bug In-Reply-To: <199902260821.AAA13377@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 Fri, 26 Feb 1999, Matthew Dillon wrote: > I've put up a new patchset at: > > http://www.backplane.com/FreeBSD4/ > > For those people who are testing the getnewbuf() problems. I managed to > buildworld with it once so far. You may want to wait for me to get > a few more builds under my test machine's belt before you spend time > messing with it. > > Also on this site are patches for umpteen other things, which I am > slowly organizing. The most interesting one is the new VN device > which supports direct swap-backing if you so choose ( but don't you > dare run out of swap using it :-) ). Not all patches are destined > for commit, but most of them are. I probably won't get a chance to look at this until the weekend. It sounds like you are making good progress with it though. -- 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 Fri Feb 26 7:18:36 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 CF18E14FA5 for ; Fri, 26 Feb 1999 07:18:34 -0800 (PST) (envelope-from dennis@etinc.com) Received: from dbsys (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.8.8/8.6.9) with SMTP id KAA20037; Fri, 26 Feb 1999 10:19:46 -0500 (EST) Message-Id: <199902261519.KAA20037@etinc.com> X-Sender: dennis@etinc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 26 Feb 1999 10:28:26 -0500 To: Ted Faber From: Dennis Subject: Re: PCI Card Failures in 3.1 Cc: hackers@freebsd.org, se@mi.uni-koeln.de In-Reply-To: <199902260201.SAA03524@boreas.isi.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 06:01 PM 2/25/99 -0800, you wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >Dennis wrote: >> >>Can anyone point me at info on what changed, specifically for pci devices, >>in 3.0 vs 2.2? A bullet list would help greatly. VM mapping? > >I'm having a similar problem (a PCI ethernet device that worked under >2.2.7 won't work under 3.0) and I think it might be due to the changes >in pci_map_port(). Under 2.2.7 there's some code in pci_map_port() >that apparently enables intermediate bridges, but I don't see the same >functionality in the pci_map_port in the PCI compatibility code. I've >sent some mail to Stefan about this, but he's apparently swamped. If >anyone else can take a look at the PCI code and confirm my diagnosis >and provide me a workaround or a patch, I'd really appreciate it. It >may also be causing you a problem, too. > >I'd patch it myself, but without a PCI spec, that code looks pretty >daunting... We had problems in 2.2 with PCI shared memory not working properly, but this is a much bigger problem. One or our PCI cards works, and the other doesnt for no apparent reason. The one that doesnt work is a bus master, and it cant seem to write to system memory. All of the registers read the correct values, so its either that the physical addresses arent right or the card cant access the memory. What card are you haveing problems with, and what are the symptoms? Does it detect the card? Dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 7:25: 5 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 9231514F44 for ; Fri, 26 Feb 1999 07:25:04 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.9.1/8.9.1) id JAA37760; Fri, 26 Feb 1999 09:24:45 -0600 (CST) Date: Fri, 26 Feb 1999 09:24:45 -0600 From: Dan Nelson To: Dave Hayes Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Quake2 and UDP recvspace Message-ID: <19990226092445.A37611@dan.emsphone.com> References: <199902260437.UAA09666@hokkshideh.jetcafe.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <199902260437.UAA09666@hokkshideh.jetcafe.org>; from "Dave Hayes" on Thu Feb 25 20:37:30 GMT 1999 X-OS: FreeBSD 3.1-STABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Feb 25), Dave Hayes said: > I'm runing Quake2 on FreeBSD 2.2.8-RELEASE as a dedicated server. > Quake2 with many players basically slams the UDP layer of my > machine, for those of you who don't already know. :) > > Netstat -s reports: > > udp: > 110301027 datagrams received > 0 with incomplete header > 30 with bad data length field > 1377 with bad checksum > 29882 dropped due to no socket > 651167 broadcast/multicast datagrams dropped due to no socket > >> 15494 dropped due to full socket buffers > 0 not for hashed pcb > 109603077 delivered > 36475854 datagrams output Here's my netstat output (QuakeWorld server, 20 players, P200/MMX machine, avg 15-20 players from 9am-3am) 9:14AM up 5 days, 15:49, 12 users, load averages: 0.76, 0.60, 0.48 udp: 166078807 datagrams received 0 with incomplete header 134 with bad data length field 1753 with bad checksum 130043 dropped due to no socket 36529 broadcast/multicast datagrams dropped due to no socket >> 396138 dropped due to full socket buffers 0 not for hashed pcb 165514210 delivered 124239423 datagrams output So that's .2 % packet loss due to full buffers on my machine, which is pegged at 100% cpu when all 20 players are on. You lose more packets just from lossage over the Net. Hm. I notice that your #received is twice your #output. QuakeWorld (at least) does approximately the same traffic in and out for each player. Do you have any other UDP traffic on this box? > Now I have my sysctl variables set up like so: > > net.inet.udp.checksum: 1 > net.inet.udp.maxdgram: 9216 > net.inet.udp.recvspace: 246723 I'm still using the default net.inet.udp.recvspace=41600. What you might want to do is log the "full socket buffers" count every 5 minutes or so and verify whether the count increases slowly over the entire day or in spurts. Maybe something other than your server is causing it. I'm putting my money on /etc/periodic/daily/* :) -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 Fri Feb 26 7:45:23 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 D6F3814EDA for ; Fri, 26 Feb 1999 07:45:20 -0800 (PST) (envelope-from dennis@etinc.com) Received: from dbsys (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.8.8/8.6.9) with SMTP id KAA20180; Fri, 26 Feb 1999 10:46:34 -0500 (EST) Message-Id: <199902261546.KAA20180@etinc.com> X-Sender: dennis@etinc.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 26 Feb 1999 10:55:12 -0500 To: Ted Faber From: Dennis Subject: Re: PCI Card Failures in 3.1 - FYI Cc: hackers@FreeBSD.ORG, se@mi.uni-koeln.de Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Also, we dont call pci_map_port(), so I doubt that is the problem. The mapping seems to work (when we map the registers into memory we can read them and they have the correct default values). the problem is that is cant seem to dma to memory...its impossible to tell if it can read however. dennis At 06:01 PM 2/25/99 -0800, you wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >Dennis wrote: >> >>Can anyone point me at info on what changed, specifically for pci devices, >>in 3.0 vs 2.2? A bullet list would help greatly. VM mapping? > >I'm having a similar problem (a PCI ethernet device that worked under >2.2.7 won't work under 3.0) and I think it might be due to the changes >in pci_map_port(). Under 2.2.7 there's some code in pci_map_port() >that apparently enables intermediate bridges, but I don't see the same >functionality in the pci_map_port in the PCI compatibility code. I've >sent some mail to Stefan about this, but he's apparently swamped. If >anyone else can take a look at the PCI code and confirm my diagnosis >and provide me a workaround or a patch, I'd really appreciate it. It >may also be causing you a problem, too. > >I'd patch it myself, but without a PCI spec, that code looks pretty >daunting... We had problems in 2.2 with PCI shared memory not working properly, but this is a much bigger problem. One or our PCI cards works, and the other doesnt for no apparent reason. The one that doesnt work is a bus master, and it cant seem to write to system memory. All of the registers read the correct values, so its either that the physical addresses arent right or the card cant access the memory. What card are you haveing problems with, and what are the symptoms? Does it detect the card? Dennis 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 Feb 26 7:53: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zoe.iserve.net (zoe.iserve.net [207.250.219.7]) by hub.freebsd.org (Postfix) with ESMTP id 014D814BF1 for ; Fri, 26 Feb 1999 07:53:03 -0800 (PST) (envelope-from rch@iserve.net) Received: from acidic (acidic.iserve.net [207.250.219.40]) by zoe.iserve.net (8.9.1/8.9.1) with SMTP id KAA16033 for ; Fri, 26 Feb 1999 10:52:47 -0500 (EST) Message-Id: <199902261552.KAA16033@zoe.iserve.net> X-Sender: rch@iserve.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 26 Feb 1999 10:53:49 -0500 To: hackers@FreeBSD.ORG From: Robert Hough Subject: FreeBSD & Sendmail Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does anyone know what this message means? I've got like 2-3 people with this problem, and cant seem to figure out what it is. NOQUEUE: Null connection from cthulu.iserve.net [207.250.219.24] __ _______ |__| __|.-----.----.--.--.-----. .--------------------------------. | |__ || -__| _| | | -__| | Robert Hough (rch@iserve.net) | |__|_______||_____|__| \___/|_____| | 317-802-3036 -/- 317-876-0846 | ----------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 8: 3: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pau-amma.whistle.com (s205m64.whistle.com [207.76.205.64]) by hub.freebsd.org (Postfix) with ESMTP id A6CB014CC1 for ; Fri, 26 Feb 1999 08:03:03 -0800 (PST) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id IAA25847; Fri, 26 Feb 1999 08:02:47 -0800 (PST) Date: Fri, 26 Feb 1999 08:02:47 -0800 (PST) From: David Wolfskill Message-Id: <199902261602.IAA25847@pau-amma.whistle.com> To: hackers@FreeBSD.ORG, rch@iserve.net Subject: Re: FreeBSD & Sendmail In-Reply-To: <199902261552.KAA16033@zoe.iserve.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Date: Fri, 26 Feb 1999 10:53:49 -0500 >From: Robert Hough >Does anyone know what this message means? I've got like 2-3 people with >this problem, and cant seem to figure out what it is. >NOQUEUE: Null connection from cthulu.iserve.net [207.250.219.24] I believe I've seen that when I've telnetted to the SMTP port, then typed "quit" without attempting to engage in an [E]SMTP conversation. david -- David Wolfskill UNIX System Administrator dhw@whistle.com voice: (650) 577-7158 pager: (650) 371-4621 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 8: 5:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (Postfix) with ESMTP id 7377114F5B for ; Fri, 26 Feb 1999 08:05:04 -0800 (PST) (envelope-from Dom.Mitchell@palmerharvey.co.uk) Received: from ho-nt-01.pandhm.co.uk (unverified) by mail.palmerharvey.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Fri, 26 Feb 1999 16:04:57 +0000 Received: from voodoo.pandhm.co.uk ([10.100.35.12]) by ho-nt-01.pandhm.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id FSG3LDKQ; Fri, 26 Feb 1999 15:58:59 -0000 Received: from dom by voodoo.pandhm.co.uk with local (Exim 2.10 #1) id 10GPnD-0005M1-00; Fri, 26 Feb 1999 16:07:11 +0000 To: Robert Hough Cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD & Sendmail X-Mailer: nmh-1.0 X-Colour: Green Organization: Palmer & Harvey McLane In-Reply-To: Robert Hough's message of "Fri, 26 Feb 1999 10:53:49 EST" <199902261552.KAA16033@zoe.iserve.net> Date: Fri, 26 Feb 1999 16:07:11 +0000 From: Dom Mitchell Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 26 February 1999, Robert Hough proclaimed: > Does anyone know what this message means? I've got like 2-3 people with > this problem, and cant seem to figure out what it is. > > NOQUEUE: Null connection from cthulu.iserve.net [207.250.219.24] It's probably a port-scan. What has happened is that some port scanning tool (say nmap, in the ports collection) has connected and disconnected immediately to your host without actually sending any data down the connection. If you set up yuor inetd to enable logging (-l option?), then you will probably find these types of port scans easier to pick up from your logs. -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator Free your mind -- http://www.opensource.org/ -- ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 8:13:10 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 383D214CBE for ; Fri, 26 Feb 1999 08:13:00 -0800 (PST) (envelope-from dennis@etinc.com) Received: from dbsys (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.8.8/8.6.9) with SMTP id LAA20285; Fri, 26 Feb 1999 11:14:12 -0500 (EST) Message-Id: <199902261614.LAA20285@etinc.com> X-Sender: dennis@etinc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 26 Feb 1999 11:22:50 -0500 To: Ted Faber From: Dennis Subject: Re: PCI Card Failures in 3.1 - fixed!!! Cc: hackers@FreeBSD.ORG, se@mi.uni-koeln.de Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Its seems that our 2.2 driver was not properly setting the BM bit in the status/command register and Freebsd 2.2. didnt seem to care, but 3.1 does. the card is working fine now. Dennis >Also, we dont call pci_map_port(), so I doubt that is the >problem. The mapping seems to work (when we map the >registers into memory we can read them and they have >the correct default values). the problem is that is cant >seem to dma to memory...its impossible to tell if it >can read however. > >dennis > At 06:01 PM 2/25/99 -0800, you wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >Dennis wrote: >> >>Can anyone point me at info on what changed, specifically for pci devices, >>in 3.0 vs 2.2? A bullet list would help greatly. VM mapping? > >I'm having a similar problem (a PCI ethernet device that worked under >2.2.7 won't work under 3.0) and I think it might be due to the changes >in pci_map_port(). Under 2.2.7 there's some code in pci_map_port() >that apparently enables intermediate bridges, but I don't see the same >functionality in the pci_map_port in the PCI compatibility code. I've >sent some mail to Stefan about this, but he's apparently swamped. If >anyone else can take a look at the PCI code and confirm my diagnosis >and provide me a workaround or a patch, I'd really appreciate it. It >may also be causing you a problem, too. > >I'd patch it myself, but without a PCI spec, that code looks pretty >daunting... We had problems in 2.2 with PCI shared memory not working properly, but this is a much bigger problem. One or our PCI cards works, and the other doesnt for no apparent reason. The one that doesnt work is a bus master, and it cant seem to write to system memory. All of the registers read the correct values, so its either that the physical addresses arent right or the card cant access the memory. What card are you haveing problems with, and what are the symptoms? Does it detect the card? Dennis 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 Fri Feb 26 8:44:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bingsun1.cc.binghamton.edu (bingsun1.cc.binghamton.edu [128.226.1.2]) by hub.freebsd.org (Postfix) with ESMTP id C37DF14F80 for ; Fri, 26 Feb 1999 08:44:07 -0800 (PST) (envelope-from bf20761@binghamton.edu) Received: from localhost (bf20761@localhost) by bingsun1.cc.binghamton.edu (8.8.7/8.6.9) with SMTP id LAA17113 for ; Fri, 26 Feb 1999 11:43:49 -0500 (EST) Date: Fri, 26 Feb 1999 11:43:48 -0500 (EST) From: zhihuizhang X-Sender: bf20761@bingsun1 To: freebsd-hackers@FreeBSD.ORG Subject: Where is device name table intrnames[] modified? 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 am reading PCI support codes of FreeBSD 2.2.8 (file pci.c, pcisupport.c. etc.). I come across the device string name table intrnames[] which is defined and initialied in vector.s. But I can not find where they are modified to contain strings like "pci irqnn" -- They are initialized to contain "stray irqnn". I also can not find where the contants NR_DEVICES, DEVICE_NAMES are defined. Please point out for me where the intrnames[] gets modified. As for the contants, I guess they are defined in "vector.h". I am about to do a make world (for the first time) to see if it will create vector.h (and other files with names "opt_xxx.h") included with " and " (not < and >). I hope that if these header files are created during the make, they will still be there after the make process so that I can examine them. Any help is appreciated. -------------------------------------------------- | Zhihui Zhang, http://cs.binghamton.edu/~zzhang | | Dept. of Computer Science, SUNY at Binghamton | -------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 9:12:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.ucb.crimea.ua (relay.ucb.crimea.ua [212.110.138.1]) by hub.freebsd.org (Postfix) with ESMTP id 6BA1514F88 for ; Fri, 26 Feb 1999 09:07:30 -0800 (PST) (envelope-from ru@ucb.crimea.ua) Received: (from ru@localhost) by relay.ucb.crimea.ua (8.9.2/8.9.2/UCB) id TAA45527; Fri, 26 Feb 1999 19:04:56 +0200 (EET) (envelope-from ru) Date: Fri, 26 Feb 1999 19:04:55 +0200 From: Ruslan Ermilov To: Robert Hough Cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD & Sendmail Message-ID: <19990226190455.A44323@ucb.crimea.ua> Mail-Followup-To: Robert Hough , hackers@FreeBSD.ORG References: <199902261552.KAA16033@zoe.iserve.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.17i In-Reply-To: <199902261552.KAA16033@zoe.iserve.net>; from Robert Hough on Fri, Feb 26, 1999 at 10:53:49AM -0500 X-Operating-System: FreeBSD 3.1-STABLE i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 26, 1999 at 10:53:49AM -0500, Robert Hough wrote: > Does anyone know what this message means? I've got like 2-3 people with > this problem, and cant seem to figure out what it is. > > NOQUEUE: Null connection from cthulu.iserve.net [207.250.219.24] > > Do 207.250.219.24 run BigBrother (ports/net/bb)? It periodically checks that sendmail is alive. -- Ruslan Ermilov Sysadmin and DBA of the ru@ucb.crimea.ua United Commercial Bank +380.652.247.647 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 9:35:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles134.castles.com [208.214.165.134]) by hub.freebsd.org (Postfix) with ESMTP id C536B14FB5; Fri, 26 Feb 1999 09:35:43 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id JAA08270; Fri, 26 Feb 1999 09:27:46 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902261727.JAA08270@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Jesse Cc: se@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: fails to recognize any PCI cards (PicMG) In-reply-to: Your message of "Fri, 26 Feb 1999 01:41:16 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Feb 1999 09:27:45 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I have three servers with PicMG motherboards that I'm trying to convert > from Windows NT to FreeBSD. I don't have much experience with this type of > setup (passive backplanes), so you'll have to excuse me if I'm missing > something obvious. > > I've tried installing FreeBSD 2.2.8-RELEASE and 3.1-RELEASE on these > servers, however they fail to recognize any PCI cards (Adaptec 2940UWs, > Intel EtherExpress Pro 10/100 Bs). Please send us the output from booting with -v set; it looks like maybe funny PCI hardware. (use 3.1 for this) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ 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 Feb 26 9:48:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id DEC9814F89 for ; Fri, 26 Feb 1999 09:48:47 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA17514; Fri, 26 Feb 1999 09:48:08 -0800 (PST) (envelope-from dillon) Date: Fri, 26 Feb 1999 09:48:08 -0800 (PST) From: Matthew Dillon Message-Id: <199902261748.JAA17514@apollo.backplane.com> To: Doug Rabson Cc: Julian Elischer , Luoqi Chen , freebsd-hackers@FreeBSD.ORG, mjacob@feral.com Subject: Re: Panic in FFS/4.0 as of yesterday - update References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> maxbufspace, can cause map allocations to fail due to fragmentation. : :Defragment by moving non-busy buffers around in the map? Not a huge :amount of fun to be had there :-(. : :-- :Doug Rabson Mail: dfr@nlsystems.com :Nonlinear Systems Ltd. Phone: +44 181 442 9037 It's easy to defragment, you just deallocate kva associate with the buffer ( like a normal free ) -- the problem is that you may have to do this even if bufspace < maxbufspace. Shoot, there's still a bug. My third make buildworld locked up in 'newbuf'. Grr. -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 Feb 26 9:51:22 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 1B63F14F8A for ; Fri, 26 Feb 1999 09:51:15 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id JAA01736; Fri, 26 Feb 1999 09:50:57 -0800 Date: Fri, 26 Feb 1999 09:50:57 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday - update In-Reply-To: <199902261748.JAA17514@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 just got back, so I was sitting down to do some testing... So- Matt, you have a bunch of patches (not quite ready yet if I read your last mail rightly)- did this include the patch that Luoqi sent me earlier this week? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 10: 0:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles169.castles.com [208.214.165.169]) by hub.freebsd.org (Postfix) with ESMTP id 8333E14F89 for ; Fri, 26 Feb 1999 10:00:32 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id JAA08432; Fri, 26 Feb 1999 09:52:34 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902261752.JAA08432@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Andrew Heybey Cc: freebsd-hackers@freebsd.org Subject: Re: Advice wanted on tracking down bug (or hw problem?) in 3.1R In-reply-to: Your message of "Thu, 25 Feb 1999 14:35:23 EST." <199902251935.OAA06361@stiegl.niksun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Feb 1999 09:52:33 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I have just submitted PR kern/10243, but I thought I would ask for > some advice on hackers as well. > > The bug is that under certain loads, read(2) can return corrupted data > (ie data that are not in the file on disk). The instances I have seen > are relatively small amounts (8-64 bytes) of corrupt data at the end > of a 4k page. The corrupt data is from a file previously read or > another position in the current file. I have also seen this problem > in 3.0-RELEASE but not in 2.2.8-RELEASE. Can you look at the corrupt data and see if you can identify it? In particular, look for objects that look like IP addresses, MAC addresses, pointers into kernel space, ascii text, etc. This is usually the best way to work out where the data is coming from. > I would sure appreciate it if someone with a larger collection of > clues than I would take a look at this or give me some advice as to > where I should start looking. We do appear to have at least one 'sniper' bug in the kernel at the moment; this might be the same one or another. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ 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 Feb 26 10: 2:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles169.castles.com [208.214.165.169]) by hub.freebsd.org (Postfix) with ESMTP id 86D6614FA4 for ; Fri, 26 Feb 1999 10:01:13 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id JAA08392; Fri, 26 Feb 1999 09:46:16 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902261746.JAA08392@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Donn Miller" Cc: hackers@freebsd.org Subject: Re: Accessing the BIOS... In-reply-to: Your message of "Fri, 26 Feb 1999 03:33:18 EST." <000701be6162$b52458e0$02000003@dmm125> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Feb 1999 09:46:16 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Please format your messages so that they can be replied to. > I need to find out some information about how to write apps that > access the BIOS in FreeBSD. Obviously, since we are dealing with > proteced mode, we can't use INT 10h. My understanding is this (help me > out here if I'm wrong): You don't access the BIOS from applications under FreeBSD. > (*) FreeBSD makes a copy of the Bios image, which is what, 32kB in > length? We need to find a pointer to the start of the Bios image, also > known as the protected mode entry point. It doesn't, it isn't, no you don't, and it's not. > (*) FreeBSD also makes a copy of the first 0x600 bytes of > conventional memory, which may or may not be stored within the already > existing BIOS image. It doesn't. > Obviously, a far pointer is required to access > this if it is outside the range of the 32kB BIOS image. FWIU, DOS uses > address locations 0x000-0x600 for some BIOS services, such as writing to > the VGA display. It does this by passing arguments in the various > registers (such as AX or EAX) and calling INT 10. In 16-bit or 32-bit > protected mode, I don't know which, you can't pass arguments in AX and > call int10. You don't use the BIOS for text output under FreeBSD. > You have to get a pointer to the protected mode entry > point. Again, no you don't. > (*) Does FBSD use 16 or 32 bit protected-mode BIOS calls? If they > are 16-bit, I think you use a selector:offest in the format 16:16. > 32-bit protected-mode calls have a selector:offset format of 16:32. I > know this must involve using some arithmetic with DS or ES registers, > but I'm not sure. The kernel can (and does) make real-mode, 16- and 32-bit protected mode BIOS calls. Applications make none of the above. > (*) When FreeBSD makes a copy of the 32kB of BIOS, does it put it in > the same location every time? Also, I imagine Linux is very similar in > its handling of protected-mode BIOS calls, but it probably puts the > image in a different place, etc. AFAIK, Linux only uses the 32-bit PCI BIOS entrypoints. Neither FreeBSD nor Linux make copies of the BIOS. > It seems like BIOS calls are pretty complicated in protected mode. Why > aren't we allowed to use INT 0x10, and use the registers (AX, etc.) in > protected mode, but real mode allows this? Because interrupts are handled by the OS supervisor, and this is typically not the BIOS. > I know other platforms, such as Macs, Sun SPARCS, and Alpha Stations > don't have an explicit BIOS, but they do have some equivalent, like some > kind of firmware. Is programming the "BIOS" in non-intel platforms as > difficult as programming the BIOS on PC's? It's rarely as badly broken, but typically restricted to bootstrapping only. > I think a good source of info would be Ralph's interrupt list. ;-) I would suggest you forget everything you think you know about programming under DOS, and learn to program under FreeBSD from scratch. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ 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 Feb 26 10:10:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gatewaya.anheuser-busch.com (gatewaya.anheuser-busch.com [151.145.250.252]) by hub.freebsd.org (Postfix) with SMTP id 60AF414FE2 for ; Fri, 26 Feb 1999 10:10:42 -0800 (PST) (envelope-from Matthew.Alton@anheuser-busch.com) Received: by gatewaya.anheuser-busch.com; id MAA14640; Fri, 26 Feb 1999 12:03:42 -0600 Received: from stlabcexg006.anheuser-busch.com(stlabcexg006 151.145.101.161) by gatewaya via smap (V2.1) id xma014582; Fri, 26 Feb 99 12:03:25 -0600 Received: by stlabcexg006.anheuser-busch.com with Internet Mail Service (5.5.2232.9) id ; Fri, 26 Feb 1999 12:06:16 -0600 Message-ID: From: "Alton, Matthew" To: "'Hackers@FreeBSD.ORG'" Cc: "Ladendorf, Matt" Subject: printf wierdness Date: Fri, 26 Feb 1999 12:06:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Why is this happening? $ vi foo.c #include int main(void) { unsigned long long int foo = 0; char *bar = "Hidely Ho!"; (void)printf("%llu %s\n", foo, bar); (void)printf("%s %llu\n", bar, foo); return 0; } ~ ~ ~ ~ ~ ~ ~ ~ ~ foo.c: 14 lines, 196 characters. $ make foo cc foo.c -o foo $ ./foo 0 (null) Hidely Ho! 0 $ Matthew Alton Computer Services - UNIX Systems Administration (314)632-6644 matthew.alton@anheuser-busch.com alton@plantnet.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 10:19:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 5FC8914F93 for ; Fri, 26 Feb 1999 10:19:10 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA17688; Fri, 26 Feb 1999 10:18:52 -0800 (PST) (envelope-from dillon) Date: Fri, 26 Feb 1999 10:18:52 -0800 (PST) From: Matthew Dillon Message-Id: <199902261818.KAA17688@apollo.backplane.com> To: Matthew Jacob Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday - update References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I just got back, so I was sitting down to do some testing... So- Matt, you :have a bunch of patches (not quite ready yet if I read your last mail :rightly)- did this include the patch that Luoqi sent me earlier this week? : :-matt : Pop the patch at 1:00 p.m. today. By then I should have an update. The one I have now is very close - just a couple of missing wakeups. -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 Feb 26 10:23:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 82F7C1508E for ; Fri, 26 Feb 1999 10:23:15 -0800 (PST) (envelope-from faber@ISI.EDU) Received: from ISI.EDU (vex-e.isi.edu [128.9.160.240]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id KAA05447; Fri, 26 Feb 1999 10:22:52 -0800 (PST) Message-Id: <199902261822.KAA05447@boreas.isi.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: Dennis Cc: hackers@freebsd.org, se@mi.uni-koeln.de Subject: Re: PCI Card Failures in 3.1 In-Reply-To: Your message of "Fri, 26 Feb 1999 10:28:26 EST." <199902261519.KAA20037@etinc.com> X-Url: http://www.isi.edu/~faber Date: Fri, 26 Feb 1999 10:22:52 -0800 From: Ted Faber Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- Dennis wrote: >What card are you haveing problems with, and what are the symptoms? >Does it detect the card? It's the Hitachi MX-133's internal ethernet card. I haven't opened it up to see who's card it is, but the lance chip is the Am79C970A. The PCI probe succeeds, but it fails to initialize. I think that's because it can read the PCI config registers, but not map the device registers. I'm glad your problem is solved. - ---------------------------------------------------------------------- Ted Faber faber@isi.edu USC/ISI Computer Scientist http://www.isi.edu/~faber (310) 822-1511 x190 PGP Key: http://www.isi.edu/~faber/pubkey.asc -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNtbme4b4eisfQ5rpAQFzQwP/UNCHWtteEU78qOPk9pviKU/jT7HN2RA0 zln3/dSmiTF0H65L6V5/NUMf0NmZTQ5v2DFAiGePhYP/PV3LmpgeOR88T+voDKbT jhGVPwvxTZtr8wH42XG+bPCcaOZgMbBNdbWmAh/mgypFjU78D5V6ulJcVC52zp/t jh8qs7DmSUc= =oXe1 -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 10:25: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from arjun.niksun.com (gw.niksun.com [206.20.52.122]) by hub.freebsd.org (Postfix) with ESMTP id 4F4B51508E for ; Fri, 26 Feb 1999 10:24:34 -0800 (PST) (envelope-from ath@niksun.com) Received: from stiegl.niksun.com (stiegl.niksun.com [10.0.0.44]) by arjun.niksun.com (8.8.8/8.8.8) with ESMTP id NAA00961; Fri, 26 Feb 1999 13:24:14 -0500 (EST) Received: from stiegl.niksun.com (localhost.niksun.com [127.0.0.1]) by stiegl.niksun.com (8.8.8/8.8.7) with ESMTP id NAA12066; Fri, 26 Feb 1999 13:24:12 -0500 (EST) (envelope-from ath@stiegl.niksun.com) Message-Id: <199902261824.NAA12066@stiegl.niksun.com> From: Andrew Heybey To: Mike Smith Cc: freebsd-hackers@freebsd.org Subject: Re: Advice wanted on tracking down bug (or hw problem?) in 3.1R In-reply-to: Your message of Fri, 26 Feb 1999 09:52:33 -0800. <199902261752.JAA08432@dingo.cdrom.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 26 Feb 1999 13:24:12 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>On Fri, 26 Feb 1999 09:52:33 -0800, Mike Smith said: >> I have just submitted PR kern/10243, but I thought I would ask >> for some advice on hackers as well. >> >> The bug is that under certain loads, read(2) can return corrupted >> data (ie data that are not in the file on disk). The instances I >> have seen are relatively small amounts (8-64 bytes) of corrupt >> data at the end of a 4k page. The corrupt data is from a file >> previously read or another position in the current file. I have >> also seen this problem in 3.0-RELEASE but not in 2.2.8-RELEASE. mike> Can you look at the corrupt data and see if you can identify mike> it? In particular, look for objects that look like IP mike> addresses, MAC addresses, pointers into kernel space, ascii mike> text, etc. This is usually the best way to work out where the mike> data is coming from. The data is always (in every instance that I have examined) from some other part of the file currently being read or some other file in my set of test files. How my test setup works is that I have 30 50MB files. The files are filled with sequential integers (counting over the entire 1.5GB). My test program reads from the files (in order, starting over at file #0 when it reaches file #29) and compares what read(2) returns to what should be there (based on file number and file offset). One other possible clue: This morning I hooked my disks up to the regular Ultra SCSI (40MB/s) port of the 7890 controller rather than the Ultra/2 (80MB/s) port and I haven't seen the bug yet. I am not 100% positive since I have only run it for a few hours so far, but before I could almost always make the bug happen withing 10-15 minutes. andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 10:49:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from turkey.ispro.net.tr (turkey.ispro.net.tr [195.174.18.2]) by hub.freebsd.org (Postfix) with ESMTP id 910C6150ED; Fri, 26 Feb 1999 10:49:25 -0800 (PST) (envelope-from yurtesen@turkey.ispro.net.tr) Received: from localhost (yurtesen@localhost) by turkey.ispro.net.tr (8.8.8/8.8.8) with SMTP id UAA13846; Fri, 26 Feb 1999 20:48:16 +0200 (EET) (envelope-from yurtesen@turkey.ispro.net.tr) Date: Fri, 26 Feb 1999 20:48:16 +0200 (EET) From: Evren Yurtesen To: drkhoe@gmsnet.com Cc: freebsd-questions@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: HELP! Upgrade failure In-Reply-To: <199902260517.VAA07090@gms.gmsnet.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 you have used the sysinstall program of 2.2.8 release? you should make floppies of 3.1 release and then boot from them and upgrade with them... check the mount points from /etc/fstab sysinstall will ask for them the 3.1 release uses ELF kernel instead of a.out so your system should load /boot/loader prior to loading kernel... that is why it says invalid format send me email to yurtesen@ispro.net.tr if you have any more problems. Evren On Thu, 25 Feb 1999, Dr. Mosh wrote: > Ok... I tried using the sysinstall to upgrade from 2.2.8 to 3.1 RELEASE... > after the upgrade, it seems the binaries are out of sync or something... > if complains about not being able to > > exec _mount not found in /sbin or /usr/sbin > > So I can't mount any of the old slices in read-write mode. The new kernel > does not respond to bootstrap at all. Upon booting... the boot will > respond with > > Invalid Format > > Any help is appreciated! > > Please Respond to: drkhoe@gmsnet.com > > > -- > *#&*@#@*(#@#*@(#!@*#(!@#(&!#(@!*#@((#@$(#@(($@#($(#@$@#($@#(*$@(*$*(#(#(##(#(# > computersarefasterthanhumans - devastatetoinnovate - hyperspacialparallelcomp\ > drkhoe@gmsnet.com = http://progmetal.gmsnet.com = internetcyberwetwaregamedev+ > s*o#o$n@@c*o!m^e)s@@t>h gaMECoReTeKN0 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" 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 Feb 26 11: 5:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from buffnet4.buffnet.net (buffnet4.buffnet.net [205.246.19.13]) by hub.freebsd.org (Postfix) with ESMTP id 0BF8014F5C; Fri, 26 Feb 1999 11:05:38 -0800 (PST) (envelope-from shovey@buffnet.net) Received: from buffnet11.buffnet.net (buffnet11.buffnet.net [205.246.19.55]) by buffnet4.buffnet.net (8.8.7/8.7.3) with ESMTP id OAA09379; Fri, 26 Feb 1999 14:05:23 -0500 (EST) Date: Fri, 26 Feb 1999 14:05:21 -0500 (EST) From: Steve Hovey To: freebsd-hackers@freebsd.org, freebsd-isp@freebsd.org Subject: strange nis/application problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG arose last night, and went most of today. While the boxes would let a NIS based user log in - pine reported it couldnt figure out who a nis user was, and wouldnt expand the to: line names of people that were NIS based radius failed authentications with USER-ID missing errors erpcd (annex 4000) just wouldnt let in NIS based users without any error details. I checked and checked the master password file on the master nis server to no avail. I wrote test programs to work out the getpw.. routines - and they were fine. The problem occured only on my 2.2.5 machines - not my 2.1.5's - so then I compared some libs and noted that the sizes on libc.so.2.2 was different - I overwrote the ones on 2.2.5 with the one from 2.1.5 and the problem cleared. I have no idea why ------------------------------------------------------------------ Steve Hovey Chief Network Administrator BuffNET More Than Just a Connection! ------------------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 11: 7:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp1.vnet.net (smtp1.vnet.net [166.82.1.31]) by hub.freebsd.org (Postfix) with ESMTP id 168EE14FE5 for ; Fri, 26 Feb 1999 11:07:28 -0800 (PST) (envelope-from rivers@dignus.com) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by smtp1.vnet.net (8.9.1a/8.9.1) with ESMTP id OAA11562; Fri, 26 Feb 1999 14:06:51 -0500 (EST) Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3]) by dignus.com (8.9.1/8.8.5) with ESMTP id OAA06090; Fri, 26 Feb 1999 14:06:50 -0500 (EST) Received: (from rivers@localhost) by lakes.dignus.com (8.9.1/8.6.9) id OAA14251; Fri, 26 Feb 1999 14:07:15 -0500 (EST) Date: Fri, 26 Feb 1999 14:07:15 -0500 (EST) From: Thomas David Rivers Message-Id: <199902261907.OAA14251@lakes.dignus.com> To: Hackers@FreeBSD.ORG, Matthew.Alton@anheuser-busch.com Subject: Re: printf wierdness Cc: Matt.Ladendorf@anheuser-busch.com In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Why is this happening? > > > $ vi foo.c > > #include > > int > main(void) > { > unsigned long long int foo = 0; > char *bar = "Hidely Ho!"; > > (void)printf("%llu %s\n", foo, bar); > (void)printf("%s %llu\n", bar, foo); > > return 0; > } I believe you've got the wrong printf() specifications. I think you want: printf("%qu %s\n", foo, bar); printf("%s %qu\n", bar, foo); - Dave R. - > foo.c: 14 lines, 196 characters. > $ make foo > cc foo.c -o foo > $ ./foo > 0 (null) > Hidely Ho! 0 > $ > > Matthew Alton > Computer Services - UNIX Systems Administration > (314)632-6644 matthew.alton@anheuser-busch.com > alton@plantnet.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 11:41:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-sd.peregrine.com (mail-sd.peregrine.com [204.33.94.40]) by hub.freebsd.org (Postfix) with ESMTP id 7D24115023 for ; Fri, 26 Feb 1999 11:41:50 -0800 (PST) (envelope-from amarder@Peregrine.com) Received: by mail-sd.peregrine.com with Internet Mail Service (5.5.2232.9) id ; Fri, 26 Feb 1999 11:42:42 -0800 Message-ID: <1F089B018C73D2118A3D0008C709F4543657EF@mail3-sd.peregrine.com> From: Anton Marder To: "'hackers@FreeBSD.ORG'" Subject: FreeBSD for RISC Date: Fri, 26 Feb 1999 11:41:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi I'm just wondering where I can get FreeBSD for RISC processor? I know it's on its way out. Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 12: 1:33 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 339CD14FC4 for ; Fri, 26 Feb 1999 12:01:22 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id PAA12093; Fri, 26 Feb 1999 15:00:34 -0500 (EST) (envelope-from luoqi) Date: Fri, 26 Feb 1999 15:00:34 -0500 (EST) From: Luoqi Chen Message-Id: <199902262000.PAA12093@lor.watermarkgroup.com> To: dillon@apollo.backplane.com, mjacob@feral.com Subject: Re: Panic in FFS/4.0 as of yesterday - update Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I just got back, so I was sitting down to do some testing... So- Matt, you > have a bunch of patches (not quite ready yet if I read your last mail > rightly)- did this include the patch that Luoqi sent me earlier this week? > > -matt > My patch was just a temporary hack. Matt is working on a better fix to the problem. -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 12:14:22 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 17BDB1506F for ; Fri, 26 Feb 1999 12:14:20 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id MAA02668; Fri, 26 Feb 1999 12:13:43 -0800 Date: Fri, 26 Feb 1999 12:13:42 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Anton Marder Cc: "'hackers@FreeBSD.ORG'" Subject: Re: FreeBSD for RISC In-Reply-To: <1F089B018C73D2118A3D0008C709F4543657EF@mail3-sd.peregrine.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 Which RISC? Sparc? Alpha? PPC? StrongARM? AMD29000? On Fri, 26 Feb 1999, Anton Marder wrote: > Hi > I'm just wondering where I can get FreeBSD for RISC processor? > I know it's on its way out. > Thanks > > > 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 Feb 26 12:30:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (hda-bicnet.bicnet.net [209.244.238.132]) by hub.freebsd.org (Postfix) with ESMTP id 7F6C614F94 for ; Fri, 26 Feb 1999 12:30:29 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id PAA29088; Fri, 26 Feb 1999 15:22:04 -0500 (EST) From: Peter Dufault Message-Id: <199902262022.PAA29088@hda.hda.com> Subject: Re: pccardd, pccardc, the LabPC+, and the NIDAQ 1200 In-Reply-To: <199902251003.DAA03943@harmony.village.org> from Warner Losh at "Feb 25, 99 03:03:21 am" To: imp@harmony.village.org (Warner Losh) Date: Fri, 26 Feb 1999 15:21:59 -0500 (EST) Cc: dufault@hda.com, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I don't know why pccardc enabler would work, but I don't understand > that at all... I lied earlier - pccardc and pccardd weren't using the same port. By hand I was using 0x260 while pccardd was trying to use 0x250. The board says it can decode 5 address lines and from this pccardd is deciding it needs 32 consecutive ports without any restriction on the alignment, and in this case handing it port 0x250. I assume this is wrong unless the PCCARD mapping registers are more sophisticated than I expect. I'm about to change pccardd to ensure the returned port address is aligned on a mod bus size boundary - if I'm missing something shout now. I should check gnats on this one to see if I'm encountering a known problem. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 12:31: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles169.castles.com [208.214.165.169]) by hub.freebsd.org (Postfix) with ESMTP id 4E65E15034 for ; Fri, 26 Feb 1999 12:31:03 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id MAA09175; Fri, 26 Feb 1999 12:22:26 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902262022.MAA09175@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Andrew Heybey Cc: Mike Smith , freebsd-hackers@freebsd.org Subject: Re: Advice wanted on tracking down bug (or hw problem?) in 3.1R In-reply-to: Your message of "Fri, 26 Feb 1999 13:24:12 EST." <199902261824.NAA12066@stiegl.niksun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Feb 1999 12:22:25 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >>On Fri, 26 Feb 1999 09:52:33 -0800, Mike Smith said: > >> I have just submitted PR kern/10243, but I thought I would ask > >> for some advice on hackers as well. > >> > >> The bug is that under certain loads, read(2) can return corrupted > >> data (ie data that are not in the file on disk). The instances I > >> have seen are relatively small amounts (8-64 bytes) of corrupt > >> data at the end of a 4k page. The corrupt data is from a file > >> previously read or another position in the current file. I have > >> also seen this problem in 3.0-RELEASE but not in 2.2.8-RELEASE. > > mike> Can you look at the corrupt data and see if you can identify > mike> it? In particular, look for objects that look like IP > mike> addresses, MAC addresses, pointers into kernel space, ascii > mike> text, etc. This is usually the best way to work out where the > mike> data is coming from. > > The data is always (in every instance that I have examined) from some > other part of the file currently being read or some other file in my > set of test files. How my test setup works is that I have 30 50MB > files. The files are filled with sequential integers (counting over > the entire 1.5GB). My test program reads from the files (in order, > starting over at file #0 when it reaches file #29) and compares what > read(2) returns to what should be there (based on file number and file > offset). > > One other possible clue: This morning I hooked my disks up to the > regular Ultra SCSI (40MB/s) port of the 7890 controller rather than > the Ultra/2 (80MB/s) port and I haven't seen the bug yet. I am not > 100% positive since I have only run it for a few hours so far, but > before I could almost always make the bug happen withing 10-15 > minutes. Could you try bzero'ing your buffers before every read? This sniffs very much like short transfers rather than sniping... -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ 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 Feb 26 12:33:33 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 CDC761500E for ; Fri, 26 Feb 1999 12:33:28 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony [10.0.0.6]) by rover.village.org (8.9.3/8.6.6) with ESMTP id UAA15972; Fri, 26 Feb 1999 20:33:11 GMT 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 NAA12068; Fri, 26 Feb 1999 13:33:26 -0700 (MST) Message-Id: <199902262033.NAA12068@harmony.village.org> To: Peter Dufault Subject: Re: pccardd, pccardc, the LabPC+, and the NIDAQ 1200 Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Fri, 26 Feb 1999 15:21:59 EST." <199902262022.PAA29088@hda.hda.com> References: <199902262022.PAA29088@hda.hda.com> Date: Fri, 26 Feb 1999 13:33:26 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199902262022.PAA29088@hda.hda.com> Peter Dufault writes: : I assume this is wrong unless the PCCARD mapping registers are more : sophisticated than I expect. I'm about to change pccardd to ensure : the returned port address is aligned on a mod bus size boundary - : if I'm missing something shout now. I should check gnats on this : one to see if I'm encountering a known problem. I'm not aware of this problem being a known problem. I can either review your changes, or look at them once they go into the tree. I don't have my pcmica books here, or I'd look to see if there was something in the CIS that would tell you how the card expects things to be aligned. warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 12:36:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157]) by hub.freebsd.org (Postfix) with ESMTP id 39C38151AF for ; Fri, 26 Feb 1999 12:36:34 -0800 (PST) (envelope-from dmm125@bellatlantic.net) Received: from bellatlantic.net (client201-122-100.bellatlantic.net [151.201.122.100]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id PAA10942; Fri, 26 Feb 1999 15:38:05 -0500 (EST) Message-ID: <36D70538.8D09F7F@bellatlantic.net> Date: Fri, 26 Feb 1999 15:34:00 -0500 From: Donn Miller X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: Mike Smith Cc: hackers@freebsd.org Subject: Re: Accessing the BIOS... References: <199902261746.JAA08392@dingo.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: > > > Obviously, a far pointer is required to access > > this if it is outside the range of the 32kB BIOS image. FWIU, DOS uses > > address locations 0x000-0x600 for some BIOS services, such as writing to > > the VGA display. It does this by passing arguments in the various > > registers (such as AX or EAX) and calling INT 10. In 16-bit or 32-bit > > protected mode, I don't know which, you can't pass arguments in AX and > > call int10. > > You don't use the BIOS for text output under FreeBSD. > > > You have to get a pointer to the protected mode entry > > point. > > Again, no you don't. The reason I was asking is that I was interested in programming with the VESA BIOS extensions. It was saying in their docs (ftp://ftp.vesa.org/pub/VBE/vbe3.pdf) that an app needs to obtain the entry points to the BIOS in order to carry out the VESA graphics operations. > > > > (*) Does FBSD use 16 or 32 bit protected-mode BIOS calls? If they > > are 16-bit, I think you use a selector:offest in the format 16:16. > > 32-bit protected-mode calls have a selector:offset format of 16:32. I > > know this must involve using some arithmetic with DS or ES registers, > > but I'm not sure. > > The kernel can (and does) make real-mode, 16- and 32-bit protected mode > BIOS calls. Applications make none of the above. So if I wanted to use the Vesa BIOS extensions to build an extension onto libvgl, I would have to make certain calls to the kernel, and let the kernel access the VESA BIOS instead of my letting app doing it directly? In a nutshell, I wanted to help Soren out with his work on libvgl -- he was going to add capabilities to libvgl that enable it to use VBE, or VESA BIOS extensions. By using VBE, you can get hi-res modes like 1024x768x16 million colors without having a specific driver for the video card. The disadvantage would be, well, you'd have to have your app call the VESA BIOS in protected mode, and using BIOS graphics would be a lot slower than using a specific driver for a particular VGA card, without BIOS calls. How can I access the BIOS then, would I have to use certain kernel functions, or would I have to use a protected mode entry point? If so, where is the entry point located? Thanks. I'm kind of confused here. ;) --Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 12:47:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from arjun.niksun.com (gw.niksun.com [206.20.52.122]) by hub.freebsd.org (Postfix) with ESMTP id 3DC0D15049 for ; Fri, 26 Feb 1999 12:47:35 -0800 (PST) (envelope-from ath@niksun.com) Received: from stiegl.niksun.com (stiegl.niksun.com [10.0.0.44]) by arjun.niksun.com (8.8.8/8.8.8) with ESMTP id PAA01588; Fri, 26 Feb 1999 15:47:14 -0500 (EST) Received: from stiegl.niksun.com (localhost.niksun.com [127.0.0.1]) by stiegl.niksun.com (8.8.8/8.8.7) with ESMTP id PAA12740; Fri, 26 Feb 1999 15:47:13 -0500 (EST) (envelope-from ath@stiegl.niksun.com) Message-Id: <199902262047.PAA12740@stiegl.niksun.com> From: Andrew Heybey To: Mike Smith Cc: freebsd-hackers@freebsd.org, ken@plutotech.com, gibbs@plutotech.com Subject: Re: Advice wanted on tracking down bug (or hw problem?) in 3.1R In-reply-to: Your message of Fri, 26 Feb 1999 12:22:25 -0800. <199902262022.MAA09175@dingo.cdrom.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 26 Feb 1999 15:47:13 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [cc'd to Ken Merry & Justin Gibbs to ask if they have ever seen such behavior. In short, under heavy network load (40k pkts/sec) my reads from disk sometimes return 8-64 bytes of garbage at the end of a 4k page. The controller is an aic7890 with IBM DRVS09V LVD disks. See PR kern/10243 for more info.] >>On Fri, 26 Feb 1999 12:22:25 -0800, Mike Smith said: >> The data is always (in every instance that I have examined) from >> some other part of the file currently being read or some other >> file in my set of test files. How my test setup works is that I >> have 30 50MB files. The files are filled with sequential >> integers (counting over the entire 1.5GB). My test program reads >> from the files (in order, starting over at file #0 when it >> reaches file #29) and compares what read(2) returns to what >> should be there (based on file number and file offset). >> >> One other possible clue: This morning I hooked my disks up to the >> regular Ultra SCSI (40MB/s) port of the 7890 controller rather >> than the Ultra/2 (80MB/s) port and I haven't seen the bug yet. I >> am not 100% positive since I have only run it for a few hours so >> far, but before I could almost always make the bug happen withing >> 10-15 minutes. mike> Could you try bzero'ing your buffers before every read? This mike> sniffs very much like short transfers rather than sniping... Will do. Yes it does seem like a short transfer someplace. If I zero my buffers before every read then what will that tell me? If I get zeros rather than garbage from another file then I guess that somehow the data is not being moved into user space properly. If I still get garbage, then maybe a DMA is stopping short? Also, I still have not been able to reproduce the problem with the disks connected to the 40MB/s SCSI bus. I have cc'd ken & justin (sorry guys--don't know if you read hackers) to ask whether they have ever seen such behavior and whether there are any differences in the ahc driver for ultra vs. ultra2. andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 12:47:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles169.castles.com [208.214.165.169]) by hub.freebsd.org (Postfix) with ESMTP id BAF301507D for ; Fri, 26 Feb 1999 12:47:41 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id MAA09282; Fri, 26 Feb 1999 12:38:16 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902262038.MAA09282@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Donn Miller Cc: hackers@freebsd.org Subject: Re: Accessing the BIOS... In-reply-to: Your message of "Fri, 26 Feb 1999 15:34:00 EST." <36D70538.8D09F7F@bellatlantic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Feb 1999 12:38:16 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > You have to get a pointer to the protected mode entry > > > point. > > > > Again, no you don't. > > The reason I was asking is that I was interested in programming with the VESA > BIOS extensions. It was saying in their docs > (ftp://ftp.vesa.org/pub/VBE/vbe3.pdf) that an app needs to obtain the entry > points to the BIOS in order to carry out the VESA graphics operations. The kernel will/should make the VESA BIOS calls on your behalf. There is already basic support for this in the kernel; it probably needs to be extended. > > > (*) Does FBSD use 16 or 32 bit protected-mode BIOS calls? If they > > > are 16-bit, I think you use a selector:offest in the format 16:16. > > > 32-bit protected-mode calls have a selector:offset format of 16:32. I > > > know this must involve using some arithmetic with DS or ES registers, > > > but I'm not sure. > > > > The kernel can (and does) make real-mode, 16- and 32-bit protected mode > > BIOS calls. Applications make none of the above. > > So if I wanted to use the Vesa BIOS extensions to build an extension onto > libvgl, I would have to make certain calls to the kernel, and let the kernel > access the VESA BIOS instead of my letting app doing it directly? Yup. > In a nutshell, I wanted to help Soren out with his work on libvgl -- he was > going to add capabilities to libvgl that enable it to use VBE, or VESA BIOS > extensions. By using VBE, you can get hi-res modes like 1024x768x16 million > colors without having a specific driver for the video card. The disadvantage > would be, well, you'd have to have your app call the VESA BIOS in protected > mode, and using BIOS graphics would be a lot slower than using a specific > driver for a particular VGA card, without BIOS calls. Since the VESA BIOS doesn't actually contain any drawing functions, the only "speed" issues are page flipping and palette operations. Page flipping shouldn't be a real problem because in almost every case you would want to use the linear framebuffer mode and memory-map the LFB aperture into your application. > How can I access the BIOS then, would I have to use certain kernel functions, > or would I have to use a protected mode entry point? If so, where is the > entry point located? Again, you cannot call the BIOS from your application. Noway, nohow. Forget about even *dreaming* of doing that. See /sys/i386/isa/vesa.c, consult with Soren and Kazu about how best to implement any missing functionality inre VESA calls, and then do everything across the /dev/vesa interface. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ 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 Feb 26 12:51:15 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 52289150AB for ; Fri, 26 Feb 1999 12:51:02 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id UAA72253; Fri, 26 Feb 1999 20:50:00 GMT (envelope-from dfr@nlsystems.com) Date: Fri, 26 Feb 1999 20:50:00 +0000 (GMT) From: Doug Rabson To: Anton Marder Cc: "'hackers@FreeBSD.ORG'" Subject: Re: FreeBSD for RISC In-Reply-To: <1F089B018C73D2118A3D0008C709F4543657EF@mail3-sd.peregrine.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 Fri, 26 Feb 1999, Anton Marder wrote: > Hi > I'm just wondering where I can get FreeBSD for RISC processor? > I know it's on its way out. > Thanks The only 'RISC' processor supported is the alpha. You can find FreeBSD snapshots for the alpha on ftp.cdrom.com. -- 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 Fri Feb 26 13: 0:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.psn.ie (mailhub.psn.ie [194.106.150.254]) by hub.freebsd.org (Postfix) with ESMTP id DDE5415092 for ; Fri, 26 Feb 1999 13:00:40 -0800 (PST) (envelope-from ad@psn.ie) Received: from gromit.psn.ie ([194.106.150.251] helo=psn.ie) by mailhub.psn.ie with esmtp (Exim 2.12 #3) id 10GUMe-0004Zr-00; Fri, 26 Feb 1999 21:00:05 +0000 Message-ID: <36D70B99.4A2DAF4E@psn.ie> Date: Fri, 26 Feb 1999 21:01:13 +0000 From: Andy Doran Organization: Pobalscoil Neasain X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Doug Rabson , "'hackers@FreeBSD.ORG'" Subject: Re: FreeBSD for RISC References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Was a MIPS port ever started (I'm thinking of DECstations here)? I was thinking of it a while back, since a lot of the Alpha device support is the same (well, for DEC machines anyway). Andy. Doug Rabson wrote: > > On Fri, 26 Feb 1999, Anton Marder wrote: > > > Hi > > I'm just wondering where I can get FreeBSD for RISC processor? > > I know it's on its way out. > > Thanks > > The only 'RISC' processor supported is the alpha. You can find FreeBSD > snapshots for the alpha on ftp.cdrom.com. > > -- > 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 13: 1: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.psn.ie (mailhub.psn.ie [194.106.150.254]) by hub.freebsd.org (Postfix) with ESMTP id 09F0714FFC for ; Fri, 26 Feb 1999 13:01:06 -0800 (PST) (envelope-from ad@psn.ie) Received: from gromit.psn.ie ([194.106.150.251] helo=psn.ie) by mailhub.psn.ie with esmtp (Exim 2.12 #3) id 10GUJI-0004Zi-00; Fri, 26 Feb 1999 20:56:36 +0000 Message-ID: <36D70AC8.A862B8C0@psn.ie> Date: Fri, 26 Feb 1999 20:57:44 +0000 From: Andy Doran Organization: Pobalscoil Neasain X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "Alton, Matthew" Cc: "'Hackers@FreeBSD.ORG'" , "Ladendorf, Matt" Subject: Re: printf wierdness References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG printf() is treating the %llu type as an unsigned long (%lu), so it's taking the value for %s from the second 32-bits in 'foo'. Check the printf(3) manpage. Andy. "Alton, Matthew" wrote: > > Why is this happening? > > $ vi foo.c > > #include > > int > main(void) > { > unsigned long long int foo = 0; > char *bar = "Hidely Ho!"; > > (void)printf("%llu %s\n", foo, bar); > (void)printf("%s %llu\n", bar, foo); > > return 0; > } > > ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~ > foo.c: 14 lines, 196 characters. > $ make foo > cc foo.c -o foo > $ ./foo > 0 (null) > Hidely Ho! 0 > $ > > Matthew Alton > Computer Services - UNIX Systems Administration > (314)632-6644 matthew.alton@anheuser-busch.com > alton@plantnet.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 Fri Feb 26 13:30:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns1.seidata.com (ns1.seidata.com [208.10.211.2]) by hub.freebsd.org (Postfix) with ESMTP id 077A615178 for ; Fri, 26 Feb 1999 13:30:16 -0800 (PST) (envelope-from mike@seidata.com) Received: from localhost (mike@localhost) by ns1.seidata.com (8.8.8/8.8.5) with ESMTP id QAA13220; Fri, 26 Feb 1999 16:30:01 -0500 (EST) Date: Fri, 26 Feb 1999 16:30:01 -0500 (EST) From: To: Robert Hough Cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD & Sendmail In-Reply-To: <199902261552.KAA16033@zoe.iserve.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, 26 Feb 1999, Robert Hough wrote: > NOQUEUE: Null connection from cthulu.iserve.net [207.250.219.24] I believe people are connecting to your SMTP port (25) with telnet. Probably attempting to find some sort of exploit. -- Mike Hoskins Systems/Network Administrator SEI Data Network Services, Inc. http://www.seidata.com "In a world where an admin is rendered useless when the ball in his mouse has been taken out, its good to know that I know UNIX." -- toaster.sun4c.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 14:13:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from arjun.niksun.com (gw.niksun.com [206.20.52.122]) by hub.freebsd.org (Postfix) with ESMTP id B2AC014FFB for ; Fri, 26 Feb 1999 14:13:44 -0800 (PST) (envelope-from ath@niksun.com) Received: from stiegl.niksun.com (stiegl.niksun.com [10.0.0.44]) by arjun.niksun.com (8.8.8/8.8.8) with ESMTP id RAA01891; Fri, 26 Feb 1999 17:13:22 -0500 (EST) Received: from stiegl.niksun.com (localhost.niksun.com [127.0.0.1]) by stiegl.niksun.com (8.8.8/8.8.7) with ESMTP id RAA13223; Fri, 26 Feb 1999 17:13:20 -0500 (EST) (envelope-from ath@stiegl.niksun.com) Message-Id: <199902262213.RAA13223@stiegl.niksun.com> From: Andrew Heybey To: Mike Smith Cc: freebsd-hackers@freebsd.org Subject: Re: Advice wanted on tracking down bug (or hw problem?) in 3.1R In-reply-to: Your message of Fri, 26 Feb 1999 12:22:25 -0800. <199902262022.MAA09175@dingo.cdrom.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 26 Feb 1999 17:13:20 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>On Fri, 26 Feb 1999 12:22:25 -0800, Mike Smith said: mike> Could you try bzero'ing your buffers before every read? This mike> sniffs very much like short transfers rather than sniping... I have tried this (bzero'ing the buffer before every read) now. I still get the same results. As an example, here is the output from my test program when it encounters the bug: 18: unexpected value: file offset 1605560, buffer offset 32696 read (starting at i-4): 000e161fea 000e161feb 000e161fec 000e161fed 000c58ffee 000c58ffef 000c58fff0 000c58fff1 000c58fff2 000c58fff3 000c58fff4 000c58fff5 expected: 000e161fea 000e161feb 000e161fec 000e161fed 000e161fee 000e161fef 000e161ff0 000e161ff1 000e161ff2 000e161ff3 000e161ff4 000e161ff5 0x000c58ffee is the first bogus value. The program is reading 32k buffers, so this garbage is near the end of the buffer (I have seen it in the middle also, but always near the end of a page). While the printout above does not show it, the garbage extends to the end of the buffer (the test program calls abort() when it detects a bad value so I can look at it with gdb), so the total number of garbage bytes is 72. It seems to me that either the controller or the driver is reporting that the disk DMA is finished before it really is, or that the DMA is simply not copying all the bytes that it should. I start four test processes reading files: two of them read starting with file 0, two of them read starting at file 14 (out of 30) so that there are two processes reading the same file at any given time. In the example above both processes reading file 18 find the same garbage in their buffers at the same offset in the file. This leads me to believe that the garbage is ensconced in the buffer cache. andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 14:52: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 8393E14F94 for ; Fri, 26 Feb 1999 14:52:02 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA19591; Fri, 26 Feb 1999 14:51:46 -0800 (PST) (envelope-from dillon) Date: Fri, 26 Feb 1999 14:51:46 -0800 (PST) From: Matthew Dillon Message-Id: <199902262251.OAA19591@apollo.backplane.com> To: Matthew Jacob , freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday - update References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : Pop the patch at 1:00 p.m. today. By then I should have an update. : The one I have now is very close - just a couple of missing wakeups. This patch seems to fix buildworld. I ran Matt Jacob's STEST and managed to lock it up -- looks like flushdirtybuffers() needs to allow the syncer to get in whether or not some other process is flushing dirty buffers at the same time. I'll have another update to vfs_bio on my site at around 4:00 p.m. -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 Feb 26 15:35:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 0619914ECA for ; Fri, 26 Feb 1999 15:35:25 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id PAA00741; Fri, 26 Feb 1999 15:33:17 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id PAA03118; Fri, 26 Feb 1999 15:33:16 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id QAA23885; Fri, 26 Feb 1999 16:33:09 -0700 Message-ID: <36D72F37.6A1057D3@softweyr.com> Date: Fri, 26 Feb 1999 16:33:11 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mjacob@feral.com Cc: Anton Marder , "'hackers@FreeBSD.ORG'" Subject: Re: FreeBSD for RISC References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Jacob wrote: > > Which RISC? Sparc? Alpha? PPC? StrongARM? AMD29000? MIPS, ROMP, Power/Power2, PRISM, PIC. Yeah, PIC. I'd like to see FreeBSD on that! ;^) > On Fri, 26 Feb 1999, Anton Marder wrote: > > > Hi > > I'm just wondering where I can get FreeBSD for RISC processor? > > I know it's on its way out. > > Thanks > > > > > > 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 -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 15:41:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lambic.physics.montana.edu (lambic.physics.montana.edu [153.90.192.128]) by hub.freebsd.org (Postfix) with ESMTP id 79C2B14EC7 for ; Fri, 26 Feb 1999 15:41:21 -0800 (PST) (envelope-from handy@lambic.physics.montana.edu) Received: from localhost (handy@localhost) by lambic.physics.montana.edu (8.8.8/8.8.7) with ESMTP id QAA06403 for ; Fri, 26 Feb 1999 16:40:49 -0700 (MST) (envelope-from handy@lambic.physics.montana.edu) Date: Fri, 26 Feb 1999 16:40:49 -0700 (MST) From: Brian Handy To: hackers@freebsd.org Subject: unwanted packets in secure mode Message-ID: X-files: The truth is out there MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hey folks, I'm running syslogd in secure mode ("-s" option in rc.conf), and I got these messages today: Message from syslogd@lambic at Fri Feb 26 16:01:57 1999 ... lambic syslogd: discarded 1 unwanted packets in secure mode Message from syslogd@lambic at Fri Feb 26 16:01:57 1999 ... lambic syslogd: discarded 2 unwanted packets in secure mode ... I discarded 8 packets, all told. I recognize I asked syslogd to discard these, and sure enough, if I look at the syslogd man page, that's what it says it's supposed to do. What's it doing? Any way to tell where these are coming from? Should I wonder about this? Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 15:44:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hp9000.chc-chimes.com (hp9000.chc-chimes.com [206.67.97.84]) by hub.freebsd.org (Postfix) with ESMTP id 8C7CD14FFA for ; Fri, 26 Feb 1999 15:44:13 -0800 (PST) (envelope-from billf@chc-chimes.com) Received: from localhost by hp9000.chc-chimes.com with SMTP (1.39.111.2/16.2) id AA289182529; Fri, 26 Feb 1999 18:42:09 -0500 Date: Fri, 26 Feb 1999 18:42:08 -0500 (EST) From: Bill Fumerola To: Wes Peters Cc: mjacob@feral.com, Anton Marder , "'hackers@FreeBSD.ORG'" Subject: Re: FreeBSD for RISC In-Reply-To: <36D72F37.6A1057D3@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 Fri, 26 Feb 1999, Wes Peters wrote: > Matthew Jacob wrote: > > > > Which RISC? Sparc? Alpha? PPC? StrongARM? AMD29000? > > MIPS, ROMP, Power/Power2, PRISM, PIC. Yeah, PIC. I'd like to see > FreeBSD on that! ;^) My POS HP9000/e35 would be nice. :> - 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 Fri Feb 26 16:19:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 70A9A15027 for ; Fri, 26 Feb 1999 16:19:27 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA20214; Fri, 26 Feb 1999 16:19:11 -0800 (PST) (envelope-from dillon) Date: Fri, 26 Feb 1999 16:19:11 -0800 (PST) From: Matthew Dillon Message-Id: <199902270019.QAA20214@apollo.backplane.com> To: Matthew Jacob , freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday - update References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :: Pop the patch at 1:00 p.m. today. By then I should have an update. :: The one I have now is very close - just a couple of missing wakeups. : : This patch seems to fix buildworld. I ran Matt Jacob's STEST and managed : to lock it up -- looks like flushdirtybuffers() needs to allow the syncer : to get in whether or not some other process is flushing dirty buffers : at the same time. : : I'll have another update to vfs_bio on my site at around 4:00 p.m. : -Matt Ugh. inode lock now - if a process has a lock on an inode and then blocks in getnewbuf(), the syncer can still allocate buffers but can deadlock trying to lock the inode. I'll bet the inode lockup reported a few days ago under heavy test loads is due to this problem too. I think the solution may be to have the syncer reschedule a vnode which it finds locked rather then block getting the lock as it does now. ( excerpt from kern/vfs_subr.c, sched_sync() ) splx(s); while ((vp = LIST_FIRST(slp)) != NULL) { vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, p); (void) VOP_FSYNC(vp, p->p_ucred, MNT_LAZY, p); VOP_UNLOCK(vp, 0, p); s = splbio(); if (LIST_FIRST(slp) == vp) { ... -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 Feb 26 16:44:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.scl.ameslab.gov (mailhub.scl.ameslab.gov [147.155.137.127]) by hub.freebsd.org (Postfix) with ESMTP id E404415009 for ; Fri, 26 Feb 1999 16:44:37 -0800 (PST) (envelope-from ghelmer@scl.ameslab.gov) Received: from demios.ether.scl.ameslab.gov ([147.155.137.54]) by mailhub.scl.ameslab.gov with esmtp (Exim 1.90 #1) id 10GXsD-0000VI-00; Fri, 26 Feb 1999 18:44:53 -0600 Date: Fri, 26 Feb 1999 18:44:17 -0600 From: Guy Helmer To: Brian Handy Cc: hackers@freebsd.org Subject: Re: unwanted packets in secure mode 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, 26 Feb 1999, Brian Handy wrote: > Hey folks, > > I'm running syslogd in secure mode ("-s" option in rc.conf), and I got > these messages today: > > Message from syslogd@lambic at Fri Feb 26 16:01:57 1999 ... > lambic syslogd: discarded 1 unwanted packets in secure mode > > .... > > I discarded 8 packets, all told. I recognize I asked syslogd to discard > these, and sure enough, if I look at the syslogd man page, that's what it > says it's supposed to do. > > What's it doing? Any way to tell where these are coming from? Should I > wonder about this? Maybe easiest way to find out where these packets are coming from would be to use a kernel built with options IP_FIREWALL and IP_FIREWALL_VERBOSE, turn on firewalling in /etc/rc.conf, and include a firewall rule (probably in the rc.firewall client section) like $fwcmd add deny log udp from any to ${ip} 514 This would log the source info for all packets that try to get to udp port 514 on your system. Of course, you would probably have to adjust the remaining firewall rules to allow your system to run normally :-) Guy Guy Helmer, Ph.D. Candidate, Iowa State University Dept. of Computer Science Research Assistant, Ames Laboratory --- ghelmer@scl.ameslab.gov Research Assistant, Dept. of Computer Science --- ghelmer@cs.iastate.edu http://www.cs.iastate.edu/~ghelmer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 17:54:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from helen.CS.Berkeley.EDU (helen.CS.Berkeley.EDU [128.32.131.251]) by hub.freebsd.org (Postfix) with ESMTP id 1E8EC1505D for ; Fri, 26 Feb 1999 17:54:45 -0800 (PST) (envelope-from jmacd@helen.CS.Berkeley.EDU) Received: (from jmacd@localhost) by helen.CS.Berkeley.EDU (8.9.1a/8.9.1) id RAA03568; Fri, 26 Feb 1999 17:54:28 -0800 (PST) Message-ID: <19990226175427.46545@helen.CS.Berkeley.EDU> Date: Fri, 26 Feb 1999 17:54:27 -0800 From: Josh MacDonald To: freebsd-hackers@freebsd.org Subject: SCSI Tape (HP SureStore T20) trouble Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just installed a HP SureStore T20 SCSI tape drive on 3.0-RELEASE. My kernel is configured with the sa0 device, and dmesg reports: sa0 at ncr0 bus 0 target 5 lun 0 sa0: Removable Sequential Access SCSI2 device sa0: 3.300MB/s transfers when I boot. My other SCSI devices have been, and continue to work just fine. When I run `mt status' I get 3 lines of console message: (sa0:ncr0:0:5:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 (sa0:ncr0:0:5:0): ILLEGAL REQUEST asc:20,0 (sa0:ncr0:0:5:0): Invalid command operation code and the output: Mode Density Blocksize bpi Compression Current: 0x47 512 bytes 0 unsupported ---------available modes--------- 0: 0x47 512 bytes 0 unsupported 1: 0x47 512 bytes 0 unsupported 2: 0x47 512 bytes 0 unsupported 3: 0x47 512 bytes 0 unsupported The density 0x47 is not listed in the mt man page. It is a minicartridge format (QIC-3220) with a native capacity of 10GB. Does anyone know what this means? -josh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 18: 2:23 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 E997315019 for ; Fri, 26 Feb 1999 18:02:18 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id SAA04204; Fri, 26 Feb 1999 18:01:59 -0800 Date: Fri, 26 Feb 1999 18:01:59 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Josh MacDonald Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: SCSI Tape (HP SureStore T20) trouble In-Reply-To: <19990226175427.46545@helen.CS.Berkeley.EDU> 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, 26 Feb 1999, Josh MacDonald wrote: > I just installed a HP SureStore T20 SCSI tape drive on 3.0-RELEASE. > My kernel is configured with the sa0 device, and dmesg reports: > > sa0 at ncr0 bus 0 target 5 lun 0 > sa0: Removable Sequential Access SCSI2 device > sa0: 3.300MB/s transfers Synchronous mode? How cheap.... > > when I boot. My other SCSI devices have been, and continue to work > just fine. > > When I run `mt status' I get 3 lines of console message: > > (sa0:ncr0:0:5:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 > (sa0:ncr0:0:5:0): ILLEGAL REQUEST asc:20,0 > (sa0:ncr0:0:5:0): Invalid command operation code That's been cleaned up recently. It's 'do not worry' anyway. > > and the output: > > Mode Density Blocksize bpi Compression > Current: 0x47 512 bytes 0 unsupported > ---------available modes--------- > 0: 0x47 512 bytes 0 unsupported > 1: 0x47 512 bytes 0 unsupported > 2: 0x47 512 bytes 0 unsupported > 3: 0x47 512 bytes 0 unsupported > > The density 0x47 is not listed in the mt man page. It is a minicartridge > format (QIC-3220) with a native capacity of 10GB. Does anyone know what > this means? > This means this is what the drive is reporting as the density code. I don't know what this particular drive is, but I suspect that sadness for 3.0-RELEASE may result if it's QIC of some kind. I'd get a 3.1-STABLE kernel, and even then not all the QIC related bugs have been shaken out (I'm still working on a couple). -mtt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 19:33:21 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 BDD1915087 for ; Fri, 26 Feb 1999 19:32:31 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id TAA29867 for ; Fri, 26 Feb 1999 19:26:29 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdP29862; Sat Feb 27 03:26:19 1999 Date: Fri, 26 Feb 1999 19:26:15 -0800 (PST) From: Julian Elischer To: hackers@freebsd.org Subject: Cobalt blames linux for their security problems! 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 http://www.wired.com/news/news/technology/story/18109.html There's a good idea.. use a free OS and then blame it for your problems.. BTW did I tell you about the huge security holes we got from BSD (only kidding) julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 19:42:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id E4D5A1507A; Fri, 26 Feb 1999 19:40:34 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id NAA09792; Sat, 27 Feb 1999 13:39:26 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id NAA07409; Sat, 27 Feb 1999 13:38:58 +1030 (CST) Message-ID: <19990227133842.D7279@lemis.com> Date: Sat, 27 Feb 1999 13:38:42 +1030 From: Greg Lehey To: Robert Hough Cc: FreeBSD Questions Subject: Re: FreeBSD & Sendmail References: <199902261552.KAA16033@zoe.iserve.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199902261552.KAA16033@zoe.iserve.net>; from Robert Hough on Fri, Feb 26, 1999 at 10:53:49AM -0500 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [moved to -questions] On Friday, 26 February 1999 at 10:53:49 -0500, Robert Hough wrote: > Does anyone know what this message means? I've got like 2-3 people with > this problem, and cant seem to figure out what it is. > > NOQUEUE: Null connection from cthulu.iserve.net [207.250.219.24] This message was originally sent to -hackers. It's not an in-depth technical discussion, so I think it belongs on -questions. It would be nice to know if you have any other messages along with it. One possibility, which the hackers mentioned, is that it's a telnet to the smtp port which didn't send a message. In normal use, it's probably the result of a connection which failed, possibly because your system rejected it as spam. Here's an example of the latter case: Feb 24 21:22:23 allegro sendmail[22165]: NOQUEUE: ruleset=check_relay, arg1=f230.hotmail.com, arg2=207.82.251.121, relay=f230.hotmail.com [207.82.251.121], reject=550 Sorry, we no longer accept mail from hotmail due to the high spam content. See http://www.lemis.com/dontspam.html Feb 24 21:22:25 allegro sendmail[22165]: NOQUEUE: Null connection from f230.hotmail.com [207.82.251.121] Greg -- When replying to this message, please copy the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 19:48: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (Postfix) with ESMTP id 3E4C1150A6 for ; Fri, 26 Feb 1999 19:48:04 -0800 (PST) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:EYm3hwZBJx8WPwRqivQuBUJuCmrUpECi@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.9.1/8.9.1) with ESMTP id MAA22414; Sat, 27 Feb 1999 12:46:16 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id MAA06084; Sat, 27 Feb 1999 12:49:19 +0900 (JST) Message-Id: <199902270349.MAA06084@zodiac.mech.utsunomiya-u.ac.jp> To: Donn Miller Cc: Mike Smith , hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: Accessing the BIOS... In-reply-to: Your message of "Fri, 26 Feb 1999 15:34:00 EST." <36D70538.8D09F7F@bellatlantic.net> References: <199902261746.JAA08392@dingo.cdrom.com> <36D70538.8D09F7F@bellatlantic.net> Date: Sat, 27 Feb 1999 12:49:18 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> > You have to get a pointer to the protected mode entry >> > point. >> >> Again, no you don't. > >The reason I was asking is that I was interested in programming with the VESA >BIOS extensions. It was saying in their docs >(ftp://ftp.vesa.org/pub/VBE/vbe3.pdf) that an app needs to obtain the entry >points to the BIOS in order to carry out the VESA graphics operations. 3.0 or later versions of FreeBSD has the VESA module which will take care of these. The userland programs are not expected call the VESA BIOS directly, but is served by the VESA module to which the programs access via ioctl. >> > (*) Does FBSD use 16 or 32 bit protected-mode BIOS calls? If they >> > are 16-bit, I think you use a selector:offest in the format 16:16. >> > 32-bit protected-mode calls have a selector:offset format of 16:32. I >> > know this must involve using some arithmetic with DS or ES registers, >> > but I'm not sure. >> >> The kernel can (and does) make real-mode, 16- and 32-bit protected mode >> BIOS calls. Applications make none of the above. > >So if I wanted to use the Vesa BIOS extensions to build an extension onto >libvgl, I would have to make certain calls to the kernel, and let the kernel >access the VESA BIOS instead of my letting app doing it directly? The kernel VESA module should provide necessary services. If the current version of the module lacks certain functions you need, it must be added. But, the idea is clear; it is the VESA module which will call the VESA BIOS, not the userland programs. >In a nutshell, I wanted to help Soren out with his work on libvgl -- he was >going to add capabilities to libvgl that enable it to use VBE, or VESA BIOS >extensions. Yes, we need that! >By using VBE, you can get hi-res modes like 1024x768x16 million >colors without having a specific driver for the video card. The disadvantage >would be, well, you'd have to have your app call the VESA BIOS in protected >mode, and using BIOS graphics would be a lot slower than using a specific >driver for a particular VGA card, without BIOS calls. The VESA BIOS does not provide any graphic drawing functions. The userland program would set the desired video mode, mmap the video memory to the user memory space, and draws whatever it wants to the memory location. Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 21:43:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 0548315089 for ; Fri, 26 Feb 1999 21:43:53 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id VAA08207 for ; Fri, 26 Feb 1999 21:43:37 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.2/8.9.1) id VAA05852; Fri, 26 Feb 1999 21:43:36 -0800 (PST) (envelope-from jdp@polstra.com) Date: Fri, 26 Feb 1999 21:43:36 -0800 (PST) Message-Id: <199902270543.VAA05852@vashon.polstra.com> To: hackers@freebsd.org Subject: Re: Fixing dlopen, ld.so, and upgrading the resolver In-Reply-To: <199902200101.SAA16228@usr02.primenet.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199902200101.SAA16228@usr02.primenet.com>, Terry Lambert wrote: > > PAM and an nsswitch imply a need for statically linked objects to > be able to access dlopen and friends (or an end to static linking). PAM works for static linking NOW, and it has nothing to do with dlopen. > SVR4 handles this with a libdlopen, and the execution class loader > premaps the ld.so into all images. The library stub is basically > jump table data for the premapped ld.so. Terry keeps claiming that operating system X supports dlopen in static programs, and I keep saying he's wrong. Rather than go through it again, I'll just suggest that interested readers go to this URL: http://www.freebsd.org/cgi/search.cgi?words=dlopen+AND+static+AND+jdp&max=50&sort=date&source=freebsd-stable&source=freebsd-current&source=freebsd-hackers As you'll see, Terry has spewed this particular bit of misinformation over and over since January, 1996. It's just as wrong today as it was then. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 26 23:16:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns1.seidata.com (ns1.seidata.com [208.10.211.2]) by hub.freebsd.org (Postfix) with ESMTP id DCBB1150FB for ; Fri, 26 Feb 1999 23:16:20 -0800 (PST) (envelope-from mike@seidata.com) Received: from localhost (mike@localhost) by ns1.seidata.com (8.8.8/8.8.5) with ESMTP id CAA08445; Sat, 27 Feb 1999 02:16:03 -0500 (EST) Date: Sat, 27 Feb 1999 02:16:02 -0500 (EST) From: To: Julian Elischer Cc: hackers@FreeBSD.ORG Subject: Re: Cobalt blames linux for their security problems! 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, 26 Feb 1999, Julian Elischer wrote: > There's a good idea.. use a free OS and then blame it for your problems.. Tell me about it... here's my response. In the recent (Feb. 25th) article, "Teenager Finds Web-Server Hole" by Polly Sprenger, I'd like to comment on the following quote: "Vivek Mehra, vice president of product development at Cobalt, said the hole, which could give a hacker access to a history file documenting a user's activities, wasn't specific to their appliance, but to the Linux operating system. Righi disagreed and said RaQ's default settings are to blame." Namely, I'd like to express 100% agreement... with Righi. Mr. Mehra's comment clearly shows a lack of technical prowess, and is hopefully not shared by Cobalt. I can immediately think of three "quick fixes" to the history file hole... First, you can (as suggested) simply disable the history file, or symlink it so that no information is saved. This is a "work around", however, not a real fix. Two other (preferred) methods would be a.) place the administrative home and web server home under different directories and b.) configure Apache (the HTTP server Cobalt runs) to disallow web viewing of the history file. Regardless of which method you choose, it is neither Linux' or Apache's fault. It's also not the shell's fault. It's Cobalt's fault. We're all human. We all make mistakes. The difference between moving on after a mistake with maintained respect by your peers and wallowing in finger-pointing techniques that show your own stupidity is one that Mr. Mehra (hopefully not Cobalt as a whole) has apparently not yet grasped. I had actually looked into some of Cobalt's products... must say I've lost quite a bit of respect for them as a result of their reponse to this issue. Then again, what's to consider anyway... They don't run FreeBSD. ;) -- Mike Hoskins Systems/Network Administrator SEI Data Network Services, Inc. http://www.seidata.com "In a world where an admin is rendered useless when the ball in his mouse has been taken out, its good to know that I know UNIX." -- toaster.sun4c.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 27 2: 3:10 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 407B61513E for ; Sat, 27 Feb 1999 02:02:44 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id KAA76621; Sat, 27 Feb 1999 10:01:25 GMT (envelope-from dfr@nlsystems.com) Date: Sat, 27 Feb 1999 10:01:25 +0000 (GMT) From: Doug Rabson To: Andy Doran Cc: "'hackers@FreeBSD.ORG'" Subject: Re: FreeBSD for RISC In-Reply-To: <36D70B99.4A2DAF4E@psn.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, 26 Feb 1999, Andy Doran wrote: > Was a MIPS port ever started (I'm thinking of DECstations here)? > I was thinking of it a while back, since a lot of the Alpha > device support is the same (well, for DEC machines anyway). > > Andy. I believe that Warner Losh is working on it. -- 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 Sat Feb 27 2: 9:47 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 BAF2215151 for ; Sat, 27 Feb 1999 02:09:42 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id KAA76640; Sat, 27 Feb 1999 10:09:08 GMT (envelope-from dfr@nlsystems.com) Date: Sat, 27 Feb 1999 10:09:08 +0000 (GMT) From: Doug Rabson To: Matthew Dillon Cc: Matthew Jacob , freebsd-hackers@freebsd.org Subject: Re: Panic in FFS/4.0 as of yesterday - update In-Reply-To: <199902270019.QAA20214@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 Fri, 26 Feb 1999, Matthew Dillon wrote: > :: Pop the patch at 1:00 p.m. today. By then I should have an update. > :: The one I have now is very close - just a couple of missing wakeups. > : > : This patch seems to fix buildworld. I ran Matt Jacob's STEST and managed > : to lock it up -- looks like flushdirtybuffers() needs to allow the syncer > : to get in whether or not some other process is flushing dirty buffers > : at the same time. > : > : I'll have another update to vfs_bio on my site at around 4:00 p.m. > : -Matt > > Ugh. inode lock now - if a process has a lock on an inode and then blocks > in getnewbuf(), the syncer can still allocate buffers but can deadlock > trying to lock the inode. > > I'll bet the inode lockup reported a few days ago under heavy test loads > is due to this problem too. The responsiveness problem which I was looking at wasn't a complete deadlock. It was just taking an unreasonable time to update directory entries (about 0.5sec). When combined with the fact that 100 processes were trying to create files, this left the root inode locked for a long time. > > I think the solution may be to have the syncer reschedule a vnode which > it finds locked rather then block getting the lock as it does now. That sounds like the right thing to do. -- 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 Sat Feb 27 2:18:37 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 BC7F915151 for ; Sat, 27 Feb 1999 02:18:06 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id KAA76661; Sat, 27 Feb 1999 10:16:45 GMT (envelope-from dfr@nlsystems.com) Date: Sat, 27 Feb 1999 10:16:45 +0000 (GMT) From: Doug Rabson To: Andy Doran Cc: "Alton, Matthew" , "'Hackers@FreeBSD.ORG'" , "Ladendorf, Matt" Subject: Re: printf wierdness In-Reply-To: <36D70AC8.A862B8C0@psn.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, 26 Feb 1999, Andy Doran wrote: > printf() is treating the %llu type as an unsigned long (%lu), > so it's taking the value for %s from the second 32-bits in > 'foo'. Check the printf(3) manpage. I would like to change this. I noticed the problem when building an alpha cross debugger (hosted on i386, targetted at alpha). Locally, I have changed printf to treat "%lld" the same as "%qd": Index: vfprintf.c =================================================================== RCS file: /home/ncvs/src/lib/libc/stdio/vfprintf.c,v retrieving revision 1.20 diff -u -r1.20 vfprintf.c --- vfprintf.c 1998/09/16 04:17:44 1.20 +++ vfprintf.c 1999/02/20 10:20:08 @@ -545,7 +545,10 @@ flags |= SHORTINT; goto rflag; case 'l': - flags |= LONGINT; + if (flags & LONGINT) + flags |= QUADINT; + else + flags |= LONGINT; goto rflag; case 'q': flags |= QUADINT; @@ -1016,7 +1019,10 @@ flags |= SHORTINT; goto rflag; case 'l': - flags |= LONGINT; + if (flags & LONGINT) + flags |= QUADINT; + else + flags |= LONGINT; goto rflag; case 'q': flags |= QUADINT; -- 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 Sat Feb 27 2:49:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 0853414F29 for ; Sat, 27 Feb 1999 02:49:22 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id VAA10829; Sat, 27 Feb 1999 21:19:01 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id VAA08680; Sat, 27 Feb 1999 21:18:55 +1030 (CST) Message-ID: <19990227211853.N7279@lemis.com> Date: Sat, 27 Feb 1999 21:18:53 +1030 From: Greg Lehey To: mike@seidata.com, Julian Elischer Cc: hackers@FreeBSD.ORG Subject: Re: Cobalt blames linux for their security problems! References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from mike@seidata.com on Sat, Feb 27, 1999 at 02:16:02AM -0500 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Saturday, 27 February 1999 at 2:16:02 -0500, mike@seidata.com wrote: > On Fri, 26 Feb 1999, Julian Elischer wrote: > >> There's a good idea.. use a free OS and then blame it for your problems.. > > Tell me about it... here's my response. > > > [snip] > > > I had actually looked into some of Cobalt's products... must say I've > lost quite a bit of respect for them as a result of their reponse to > this issue. Then again, what's to consider anyway... They don't run > FreeBSD. ;) They could just as well have run FreeBSD. The issue here is that they (or somebody else) are blaming the OS for their own mistakes. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 27 5:17:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from leaf.lumiere.net (leaf.lumiere.net [207.218.152.15]) by hub.freebsd.org (Postfix) with ESMTP id CFD121505D; Sat, 27 Feb 1999 05:17:27 -0800 (PST) (envelope-from j@leaf.lumiere.net) Received: (from j@localhost) by leaf.lumiere.net (8.9.2/8.9.1) id FAA78555; Sat, 27 Feb 1999 05:16:29 -0800 (PST) Date: Sat, 27 Feb 1999 05:16:29 -0800 (PST) From: Jesse To: Mike Smith Cc: se@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: fails to recognize any PCI cards (PicMG) In-Reply-To: <199902261727.JAA08270@dingo.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 Fri, 26 Feb 1999, Mike Smith wrote: > > I have three servers with PicMG motherboards that I'm trying to convert > > from Windows NT to FreeBSD. I don't have much experience with this type of > > setup (passive backplanes), so you'll have to excuse me if I'm missing > > something obvious. > > > > I've tried installing FreeBSD 2.2.8-RELEASE and 3.1-RELEASE on these > > servers, however they fail to recognize any PCI cards (Adaptec 2940UWs, > > Intel EtherExpress Pro 10/100 Bs). > > Please send us the output from booting with -v set; it looks like maybe > funny PCI hardware. (use 3.1 for this) Someone mentioned that the SBC card model might be more helpful than that of the passive backplane. All I was able to find about it was "PSC-586". A couple people also mentioned that they remember a patch for something similar (although perhaps not the same) a while back. I searched the archives and came up with nothing. Any better ways to search for it? Someone else suggested it might be useful to look at the model numbers on the chips on the SBC. Here they are: VIA VT82C42N 9512CF (VIA's website lists VT82C42 as a keyboard/mouse controller chip) ALI M1449 A3 9445 TS2 B27925 ALI M1451 B1 9450 TS2 AB1831 SMC FDC37C665GT B9525-D3470AIC 6H75 865-3 BENCHMARQ bq3287MT 9525SB2 PM525016 (website looks like they make CMOS stuff) Output from booting with -v set: 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.1-19990225-STABLE #0: Thu Feb 25 10:53:53 GMT 1999 root@usw3.freebsd.org:/usr/src/sys/compile/GENERIC Calibrating clock(s) ... TSC clock: 132775454 Hz, i8254 clock: 1193622 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter "TSC" frequency 132728279 Hz CPU: Pentium/P54C (132.73-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52b Stepping=11 Features=0x1bf real memory = 33554432 (32768K bytes) Physical memory chunk(s): 0x00001000 - 0x0009ffff, 651264 bytes (159 pages) 0x0034d000 - 0x01ffdfff, 30085120 bytes (7345 pages) avail memory = 29507584 (28816K bytes) Found BIOS32 Service Directory header at 0xf00fc8f0 Entry = 0xfcc20 (0xf00fcc20) Rev = 0 Len = 1 PCI BIOS entry at 0xcc50 Other BIOS signatures found: ACPI: 00000000 $PnP: 00000000 Preloaded elf kernel "kernel" at 0xf0340000. Math emulator present pci_open(1): mode 1 addr port (0x0cf8) is 0x00000000 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=145110b9) Probing for devices on PCI bus 0: found-> vendor=0x10b9, dev=0x1451, revid=0xad class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 chip0: rev 0xad on pci0.0.0 found-> vendor=0x10b9, dev=0x1449, revid=0xb2 class=00-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 found-> vendor=0x10b7, dev=0x5950, revid=0x00 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=11 map[0]: type 4, range 32, base 00006000, size 5 vx0: <3COM 3C595 Fast Etherlink III PCI> rev 0x00 int a irq 11 on pci0.13.0 utp/tx[*utp*]: disable 'auto select' with DOS util! address 00:a0:24:48:78:c1 Probing for devices on the ISA bus: ... Wait a sec! It detected my ethernet card there! After a lot more investigation, I've found that (with a fully installed system) if I cold start the machine, it won't detect the PCI bus (it won't even detect any chips). However, if I restart the machine, it'll detect it on the next bootup. HOWEVER even though it detects the PCI cards they don't appear to work. I tried both the 3Com card and an fxp0 card, both which I know work. I could ifconfig both, but whenever I tried to ping anything over the network nothing would come back (but it will under linux). With the fxp card, the kernel would report fxp0: device timed out So maybe it can kinda see the PCI stuff, but it's not communicating properly with it? I don't know. :/ --- Jesse http://www.lumiere.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 27 5:35: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fep02-svc.tin.it (mta02-acc.tin.it [212.216.176.33]) by hub.freebsd.org (Postfix) with ESMTP id 9DC4B14F0F for ; Sat, 27 Feb 1999 05:35:04 -0800 (PST) (envelope-from paipai@box4.tin.it) Received: from winworkstation ([212.216.237.20]) by fep02-svc.tin.it (InterMail v4.0 201-221-105) with SMTP id <19990227133443.CLKK4420.fep02-svc@winworkstation> for ; Sat, 27 Feb 1999 14:34:43 +0100 From: "Paolo Di Francesco" To: hackers@freebsd.org Date: Sat, 27 Feb 1999 11:46:12 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Accessing the BIOS... In-reply-to: <199902270349.MAA06084@zodiac.mech.utsunomiya-u.ac.jp> References: Your message of "Fri, 26 Feb 1999 15:34:00 EST." <36D70538.8D09F7F@bellatlantic.net> X-mailer: Pegasus Mail for Win32 (v3.01d) Message-Id: <19990227133443.CLKK4420.fep02-svc@winworkstation> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >By using VBE, you can get hi-res modes like 1024x768x16 million > >colors without having a specific driver for the video card. The disadvantage > >would be, well, you'd have to have your app call the VESA BIOS in protected > >mode, and using BIOS graphics would be a lot slower than using a specific > >driver for a particular VGA card, without BIOS calls. > Yes, I suppose it will be very slow (compared to accelerated). The VESA approach is used by QNX for their demo. It's slow, but one driver for many not supported video card. Better than nothing. Ciao Ciao Paolo Di Francesco _ ->B<- All Recycled Bytes Message ... ~ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 27 10:21:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from luke.pmr.com (luke.pmr.com [207.170.114.132]) by hub.freebsd.org (Postfix) with ESMTP id 4583A15138 for ; Sat, 27 Feb 1999 10:19:59 -0800 (PST) (envelope-from bob@luke.pmr.com) Received: (from bob@localhost) by luke.pmr.com (8.9.2/8.9.2) id MAA03163 for freebsd-hackers@freebsd.org; Sat, 27 Feb 1999 12:19:38 -0600 (CST) (envelope-from bob) Date: Sat, 27 Feb 1999 12:19:38 -0600 From: Bob Willcox To: hackers list Subject: LS-120 for FreeBSD, can't boot Message-ID: <19990227121938.A3113@luke.pmr.com> Reply-To: Bob Willcox Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi All, Can anyone tell me if the FreeBSD 3.1-RELEASE kern.flp will boot from a LS-120 (Superdisk) floppy drive? I have one of these LS-120 drives that I would like to replace my 1.44MB floppy drive with but I would like to know if this should work before proceeding. (A friend of mine was unable to get his system to boot the kern.flp disk on an LS-120 drive so I'm a little skeptical.) Thanks, Bob -- Bob Willcox The man who follows the crowd will usually get no bob@luke.pmr.com further than the crowd. The man who walks alone is Austin, TX likely to find himself in places no one has ever been. -- Alan Ashley-Pitt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 27 11: 1:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 2633B1513C for ; Sat, 27 Feb 1999 11:01:26 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA28577; Sat, 27 Feb 1999 11:01:10 -0800 (PST) (envelope-from dillon) Date: Sat, 27 Feb 1999 11:01:10 -0800 (PST) From: Matthew Dillon Message-Id: <199902271901.LAA28577@apollo.backplane.com> To: Matthew Jacob , freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday - update References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : Ugh. inode lock now - if a process has a lock on an inode and then blocks : in getnewbuf(), the syncer can still allocate buffers but can deadlock : trying to lock the inode. : : I'll bet the inode lockup reported a few days ago under heavy test loads : is due to this problem too. : : I think the solution may be to have the syncer reschedule a vnode which : it finds locked rather then block getting the lock as it does now. I'm still working on it. I found out why softupdates was creating such a mess -- it disables the flushing of dirty buffers in bdwrite(), which can easily cause a low memory deadlock. I managed to get through 25 iterations of STEST, then NFS got into an endless loop. I'm tracking that down now. I've also determined that flushdirtybuffers() has aweful performance compared to the syncer. It's so bad that if you ever hit it, the disk goes nuts. It may be a few more days before I can get a working patch. I need to get feedback from Kirk re: the softupdates problem. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 27 11: 6:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 93C9B150F3 for ; Sat, 27 Feb 1999 11:06:14 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id LAA12569; Sat, 27 Feb 1999 11:05:57 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.2/8.9.1) id LAA10250; Sat, 27 Feb 1999 11:05:56 -0800 (PST) (envelope-from jdp@polstra.com) Date: Sat, 27 Feb 1999 11:05:56 -0800 (PST) Message-Id: <199902271905.LAA10250@vashon.polstra.com> To: tas@stephens.org Subject: Re: ELF, System V and multiple ABIs In-Reply-To: <199902171844.SAA24903@stephens.ml.org> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199902171844.SAA24903@stephens.ml.org>, Thomas Stephens wrote: > I was looking over the latest System V ABI draft, and noticed there is > an update (dated April 1998) which includes modifications to the ELF > format. Significantly, the usage of the e_ident array in the ElfXX_Ehdr > structure has changed slightly, in order to allow for multiple ABIs on > each hardware platform. > > While the ELF format defined in the previous draft only used the first > seven bytes of e_ident, with byte eight (EI_PAD) representing the start > of padding, the current one adds two new values to support an OS/ABI > identifier number followed by a version. As a side-effect, EI_PAD has > been redefined: > > EI_OSABI 7 (OS/ABI identifier) > EI_ABIVERSION 8 (OS/ABI version) > EI_PAD 9 > > This new version of ELF currently defines EI_OSABI values for System V, > HP-UX and stand-alone (embedded) applications, but it seems to me it > would make things much easier if all ELF-compatible systems were to > adopt it. Thanks very much for pointing this out! I wasn't aware of it. I think it would be great to adopt this, and it looks like we could do it without breaking backward compatibility for our current "branding" scheme. Today I have written to a contact at SCO to try to get an OS/ABI code assigned to FreeBSD. Hopefully that will bear some fruit and we can move on to this scheme. Again, thanks! John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 27 11:15: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ceia.nordier.com (m1-34-dbn.dial-up.net [196.34.155.34]) by hub.freebsd.org (Postfix) with ESMTP id 408AA15121 for ; Sat, 27 Feb 1999 11:14:27 -0800 (PST) (envelope-from rnordier@nordier.com) Received: (from rnordier@localhost) by ceia.nordier.com (8.8.7/8.6.12) id VAA03101; Sat, 27 Feb 1999 21:12:14 +0200 (SAT) From: Robert Nordier Message-Id: <199902271912.VAA03101@ceia.nordier.com> Subject: Re: LS-120 for FreeBSD, can't boot In-Reply-To: <19990227121938.A3113@luke.pmr.com> from Bob Willcox at "Feb 27, 99 12:19:38 pm" To: bob@pmr.com Date: Sat, 27 Feb 1999 21:12:08 +0200 (SAT) Cc: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (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 Bob Willcox wrote: > Can anyone tell me if the FreeBSD 3.1-RELEASE kern.flp will boot from a > LS-120 (Superdisk) floppy drive? I have one of these LS-120 drives that > I would like to replace my 1.44MB floppy drive with but I would like > to know if this should work before proceeding. (A friend of mine was > unable to get his system to boot the kern.flp disk on an LS-120 drive so > I'm a little skeptical.) To get this working, a few small changes are required to the boot code, AFAIK. I was intending to get this sorted out a few days ago, but haven't been able to do anything about it yet. -- Robert Nordier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 27 11:15: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.128.1.71]) by hub.freebsd.org (Postfix) with ESMTP id 64AB515121 for ; Sat, 27 Feb 1999 11:15:01 -0800 (PST) (envelope-from housley@frenchknot.ne.mediaone.net) Received: from frenchknot.ne.mediaone.net (frenchknot.ne.mediaone.net [24.128.74.10]) by chmls06.mediaone.net (8.8.7/8.8.7) with ESMTP id OAA23499; Sat, 27 Feb 1999 14:14:43 -0500 (EST) Received: from frenchknot.ne.mediaone.net (localhost [127.0.0.1]) by frenchknot.ne.mediaone.net (8.9.2/8.9.1) with ESMTP id OAA16004; Sat, 27 Feb 1999 14:14:43 -0500 (EST) (envelope-from housley@frenchknot.ne.mediaone.net) Message-ID: <36D84421.1F2B4755@frenchknot.ne.mediaone.net> Date: Sat, 27 Feb 1999 14:14:41 -0500 From: "James E. Housley" X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Dave Hayes Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Quake2 and UDP recvspace References: <199902260437.UAA09666@hokkshideh.jetcafe.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dave Hayes wrote: > > I'm runing Quake2 on FreeBSD 2.2.8-RELEASE as a dedicated server. > Quake2 with many players basically slams the UDP layer of my > machine, for those of you who don't already know. :) > > Netstat -s reports: > > udp: > 110301027 datagrams received > 0 with incomplete header > 30 with bad data length field > 1377 with bad checksum > >> 29882 dropped due to no socket > 651167 broadcast/multicast datagrams dropped due to no socket > >> 15494 dropped due to full socket buffers > 0 not for hashed pcb > 109603077 delivered > 36475854 datagrams output > > Now I have my sysctl variables set up like so: > > net.inet.udp.checksum: 1 > net.inet.udp.maxdgram: 9216 > net.inet.udp.recvspace: 246723 > > Note that the recvspace is basically as big as I can make it. I > noticed a decrease in the "dropped due to full socket buffers" when I > increased the recvspace from the default 16K value. > > I know that the max value is in the kernel somewhere. My questions > are "where?" and "what will this screw up if I change it?". I am running 2 or 3 quakeII servers on my machine. I was getting lost of lost packets due to full buffers. I added this to my kernel: options NMBCLUSTERS=8192 And that reduced it greatly, (found in the mailing list archives) -- James E. Housley PGP: 1024/03983B4D System Supply, Inc. 2C 3F 3A 0D A8 D8 C3 13 Pager: pagejim@notepage.com 7C F0 B5 BF 27 8B 92 FE To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 27 11:26:23 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 2F608150D6 for ; Sat, 27 Feb 1999 11:26:21 -0800 (PST) (envelope-from dennis@etinc.com) Received: from dbsys (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.8.8/8.6.9) with SMTP id OAA26965; Sat, 27 Feb 1999 14:27:40 -0500 (EST) Message-Id: <199902271927.OAA26965@etinc.com> X-Sender: dennis@etinc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sat, 27 Feb 1999 14:36:06 -0500 To: Greg Lehey From: Dennis Subject: Re: Cobalt blames linux for their security problems! Cc: hackers@freebsd.org In-Reply-To: <19990227211853.N7279@lemis.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 09:18 PM 2/27/99 +1030, you wrote: >On Saturday, 27 February 1999 at 2:16:02 -0500, mike@seidata.com wrote: >> On Fri, 26 Feb 1999, Julian Elischer wrote: >> >>> There's a good idea.. use a free OS and then blame it for your problems.. >> >> Tell me about it... here's my response. >> >> >> [snip] >> >> >> I had actually looked into some of Cobalt's products... must say I've >> lost quite a bit of respect for them as a result of their reponse to >> this issue. Then again, what's to consider anyway... They don't run >> FreeBSD. ;) > >They could just as well have run FreeBSD. The issue here is that they >(or somebody else) are blaming the OS for their own mistakes. Well the RAQ is a RISC processor that FreeBSD doesnt support, so I dont think that that was an option. Blaming an OS is an OK thing I think...you cant as a vendor be expected to fix everything thats wrong....PCI shared memory on secondary buses doesnt seem to work in FreeBSD2.2 (havent tried 3.1 yet)... you have to blame the OS as its not practical to fix it yourself. One problem with cobalt is that they arent running the latest kernels which fix the problem....it seems that THAT is their fault. Dennis Emerging Technologies, Inc. http://www.etinc.com ISA and PCI T1/V35/HSSI Cards for FreeBSD and LINUX HSSI/T3 UNIX-based Routers Bandwidth Manager http://www.etinc.com/bwmgr.htm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 27 11:31:18 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 69F211515B for ; Sat, 27 Feb 1999 11:31:15 -0800 (PST) (envelope-from dennis@etinc.com) Received: from dbsys (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.8.8/8.6.9) with SMTP id OAA26993 for ; Sat, 27 Feb 1999 14:32:43 -0500 (EST) Message-Id: <199902271932.OAA26993@etinc.com> X-Sender: dennis@etinc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sat, 27 Feb 1999 14:41:09 -0500 To: hackers@freebsd.org From: Dennis Subject: 3.1-RELEASE - a real pig??? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A load tester that we use (its an IOCTL interface that I'm currently using to fill HSSI lines) runs a magnitude slower on 3.1 than it did on 2.2.7. A simple APP that passes packets to a driver maxed out at about 28000pps on a 2.2.7 machine (200mhz Pentium). The exact machine upgraded to 3.1-RELEASE can only do about 16000pps. Any ideas, or is the OS just getting really fat? Dennis Emerging Technologies, Inc. http://www.etinc.com ISA and PCI T1/V35/HSSI Cards for FreeBSD and LINUX HSSI/T3 UNIX-based Routers Bandwidth Manager http://www.etinc.com/bwmgr.htm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 27 11:58:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 9AE4B14BDB for ; Sat, 27 Feb 1999 11:58:19 -0800 (PST) (envelope-from chuckr@mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id OAA49970; Sat, 27 Feb 1999 14:56:16 -0500 (EST) Date: Sat, 27 Feb 1999 14:56:15 -0500 (EST) From: Chuck Robey To: Dennis Cc: Greg Lehey , hackers@FreeBSD.ORG Subject: Re: Cobalt blames linux for their security problems! In-Reply-To: <199902271927.OAA26965@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 Sat, 27 Feb 1999, Dennis wrote: > At 09:18 PM 2/27/99 +1030, you wrote: > >On Saturday, 27 February 1999 at 2:16:02 -0500, mike@seidata.com wrote: > >> On Fri, 26 Feb 1999, Julian Elischer wrote: > >> > >>> There's a good idea.. use a free OS and then blame it for your problems.. > >> > >> Tell me about it... here's my response. > >> > >> > >> [snip] > >> > >> > >> I had actually looked into some of Cobalt's products... must say I've > >> lost quite a bit of respect for them as a result of their reponse to > >> this issue. Then again, what's to consider anyway... They don't run > >> FreeBSD. ;) > > > >They could just as well have run FreeBSD. The issue here is that they > >(or somebody else) are blaming the OS for their own mistakes. > > Well the RAQ is a RISC processor that FreeBSD doesnt support, so I dont > think that that was an option. Blaming an OS is an OK thing I think...you cant > as a vendor be expected to fix everything thats wrong....PCI shared memory on > secondary buses doesnt seem to work in FreeBSD2.2 (havent tried 3.1 yet)... > you have to blame the OS as its not practical to fix it yourself. Dennis, did you read enough of that article? Their problem was leaving around a .history file, it hadn't anything at all to do with pci probing. That article had more factual screwups (on both sides, to be fair) than I can believe ... let's not make it worse by skimming the facts to fit our moods. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 27 12: 8:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zoe.iserve.net (zoe.iserve.net [207.250.219.7]) by hub.freebsd.org (Postfix) with ESMTP id 6EEAC14FAA for ; Sat, 27 Feb 1999 12:08:41 -0800 (PST) (envelope-from rch@iserve.net) Received: from acidic (acidic.iserve.net [207.250.219.40]) by zoe.iserve.net (8.9.1/8.9.1) with SMTP id PAA03540 for ; Sat, 27 Feb 1999 15:08:24 -0500 (EST) Message-Id: <199902272008.PAA03540@zoe.iserve.net> X-Sender: rch@iserve.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Sat, 27 Feb 1999 15:09:27 -0500 To: hackers@FreeBSD.ORG From: Robert Hough Subject: Re: Cobalt blames linux for their security problems! In-Reply-To: <199902271927.OAA26965@etinc.com> References: <19990227211853.N7279@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Lots of good information here, but I got it several other places too, we have several raq's in our office, cause their just purty. But... What exactly does any of this have to do with FreeBSD, because this is actually the last place I expected to see anything about hardware that is running linux... __ _______ |__| __|.-----.----.--.--.-----. .--------------------------------. | |__ || -__| _| | | -__| | Robert Hough (rch@iserve.net) | |__|_______||_____|__| \___/|_____| | 317-802-3036 -/- 317-876-0846 | ----------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 27 12:26:42 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 E6B0814BDB for ; Sat, 27 Feb 1999 12:26:40 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony [10.0.0.6]) by rover.village.org (8.9.3/8.6.6) with ESMTP id UAA21464; Sat, 27 Feb 1999 20:26:23 GMT 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 NAA47747; Sat, 27 Feb 1999 13:26:50 -0700 (MST) Message-Id: <199902272026.NAA47747@harmony.village.org> To: Andy Doran Subject: Re: FreeBSD for RISC Cc: "'hackers@FreeBSD.ORG'" In-reply-to: Your message of "Fri, 26 Feb 1999 21:01:13 GMT." <36D70B99.4A2DAF4E@psn.ie> References: <36D70B99.4A2DAF4E@psn.ie> Date: Sat, 27 Feb 1999 13:26:49 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <36D70B99.4A2DAF4E@psn.ie> Andy Doran writes: : Was a MIPS port ever started (I'm thinking of DECstations here)? Yes. Work continues on it even. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 27 12:28:16 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 45B2D15151 for ; Sat, 27 Feb 1999 12:27:40 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id NAA11820; Sat, 27 Feb 1999 13:27:24 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp03.primenet.com, id smtpd011806; Sat Feb 27 13:27:14 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id NAA13546; Sat, 27 Feb 1999 13:27:13 -0700 (MST) From: Terry Lambert Message-Id: <199902272027.NAA13546@usr09.primenet.com> Subject: Re: flock and kernel threads To: jplevyak@inktomi.com (John Plevyak) Date: Sat, 27 Feb 1999 20:27:13 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <19990223214744.A24606@proxydev.inktomi.com> from "John Plevyak" at Feb 23, 99 09:47:44 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 > I believe there may be a problem with lockfiles (flock) and > kernel threads. The problem is demonstrated by the enclosed > program, which if run twice will fail the second time. > > The problem seems to be that termination via signal of > the non-main thread (non-leader) does not (always) result > in a call to closef and hence a call to lf_clearlock. > > Suggestions, comments welcome. This happens because fd's are scoped to the process (it's an index intpo the per process open file table) and not to the thread that opened them. Consider that if they were scoped to the thread that did the open, you would not be able to do useful things like handing incoming socket connections off to worker threads. To resolve this, you either need to register a cleanup mechanism that knows about per thread state: man pthread_cleanup_push This is less than ideal, since it means that your threading architecture in your program is not very SMP scalable, by its design. In general, thread use should be limited as much as possible to a "work to do model", with any persistent state that will survive across transactions scoped globally in a per "session" state structure. Refeerences to the literature available on request (or you can scan the -current and -hackers list archives). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 27 12:40:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (Postfix) with SMTP id 1927E15153 for ; Sat, 27 Feb 1999 12:39:38 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 3873 invoked from network); 27 Feb 1999 20:39:10 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 27 Feb 1999 20:39:10 -0000 Received: (from toor@localhost) by y.dyson.net (8.9.1/8.9.1) id PAA07081; Sat, 27 Feb 1999 15:39:09 -0500 (EST) Message-Id: <199902272039.PAA07081@y.dyson.net> Subject: Re: Cobalt blames linux for their security problems! In-Reply-To: from Julian Elischer at "Feb 26, 99 07:26:15 pm" To: julian@whistle.com (Julian Elischer) Date: Sat, 27 Feb 1999 15:39:09 -0500 (EST) Cc: hackers@freebsd.org From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (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 Julian Elischer said: > > > http://www.wired.com/news/news/technology/story/18109.html > > There's a good idea.. use a free OS and then blame it for your problems.. > > BTW did I tell you about the huge security holes we got from BSD (only > kidding) > Did I tell you about the broken finger that I got from a hammer? It must be the hammer's fault. It is a BAD hammer :-). -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 27 12:44: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id A11941516B for ; Sat, 27 Feb 1999 12:44:01 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id OAA24671; Sat, 27 Feb 1999 14:10:05 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpd024645; Sat Feb 27 14:09:59 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id NAA14007; Sat, 27 Feb 1999 13:43:35 -0700 (MST) From: Terry Lambert Message-Id: <199902272043.NAA14007@usr09.primenet.com> Subject: Re: lockf and kernel threads To: jplevyak@inktomi.com (John Plevyak) Date: Sat, 27 Feb 1999 20:43:33 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <19990224165840.A19033@proxydev.inktomi.com> from "John Plevyak" at Feb 24, 99 04:58:40 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 > Ok, I found the problem with using kernel threads and fcntl( .. F_SETLK ..). > The issue is two fold. > > 1. the locks are keyed off pid, and if the first thread to exit and close > them is not the one that took out the lock the close will occur without > the lock being removed. Probably the correct way to deal with this is to put the locks into seperate collision domains for the keying. A very simple way to do this would be to take the NFS server locking kernel patches from www.freebsd.org/~terry/, and then make rpid the same as pid for unthreaded process, the same as the thread ID for threaded processes, and then make the rpid value significant for both hash bucket selection and locally asserted locks. This would result in the locks locking against each other. > 2. the P_ADVLOCK flag is set in p_flags on a per processes basis, so > we don't even check to see if locks need to be removed if the > closing (struct proc*) is not the locking (struct proc*). POSIX is very explicit, that the first close on a file within a single process results in the locks being deasserted. I think that your patches fail to address this issue, since in reality, I believe that you want to treat each thread as if it were a seperate process for the purpose of specifying POSIX close semantics. The patches also have the coeslescence problem that made me seperate the VOP_ADVLOCK code into an assert-veto/affirm-coelesce, instead of what they do now. Basically, the problem is that when you assert a byte range lock on a file (e.g., a read lock), and an overlapping lock is granted to another thread in your process (e.g. a read lock with some overlap), and one or the other of the locks (but not both) are deasserted, then the overlapping region is no longer read locked for the thread that did not release it's lock. In effect, the locks cast "shadows" onto a linear contention space for each file, and shadows with the same indices are coelesced. The purpose in dealing with this for NFS server locking is that a single process in user space proxies the locks for a large number of clients, and locks from one client machine that overlap another lock from the same client machine results in a condition similar to multiple threads within the same process asserting locks, and expecting them to be enforced as if they weren't in the same contention domain (it happens to clean up VFS advisory locking on union FS stacking at the same time, but that's just a nice side effect). As a general comment on your original problem, the correct way to handle signals (according to the pthreads model) is to disable disnals in all threads but one, which is designated as the signal handling thread. One problem here is that FreeBSD kernel threads using rfork get different PID's, so the signal handling will never work correctly anyway. For user space threads and the Linux crap, the signal handling should be possible, if you follow the disallow-all-but-one-thread rule. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 27 13: 7: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles79.castles.com [208.214.165.79]) by hub.freebsd.org (Postfix) with ESMTP id E213815018 for ; Sat, 27 Feb 1999 13:07:03 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id NAA07483; Sat, 27 Feb 1999 13:01:51 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902272101.NAA07483@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Bob Willcox Cc: hackers list Subject: Re: LS-120 for FreeBSD, can't boot In-reply-to: Your message of "Sat, 27 Feb 1999 12:19:38 CST." <19990227121938.A3113@luke.pmr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Feb 1999 13:01:51 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Can anyone tell me if the FreeBSD 3.1-RELEASE kern.flp will boot from a > LS-120 (Superdisk) floppy drive? I have one of these LS-120 drives that > I would like to replace my 1.44MB floppy drive with but I would like > to know if this should work before proceeding. (A friend of mine was > unable to get his system to boot the kern.flp disk on an LS-120 drive so > I'm a little skeptical.) Not at this time, no. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ 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 Feb 27 13:15:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 05C741508C for ; Sat, 27 Feb 1999 13:15:33 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id OAA05743; Sat, 27 Feb 1999 14:15:16 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp02.primenet.com, id smtpd005694; Sat Feb 27 14:15:07 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id OAA15310; Sat, 27 Feb 1999 14:15:05 -0700 (MST) From: Terry Lambert Message-Id: <199902272115.OAA15310@usr09.primenet.com> Subject: Re: FreeBSD & Sendmail To: rch@iserve.net (Robert Hough) Date: Sat, 27 Feb 1999 21:15:03 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <199902261552.KAA16033@zoe.iserve.net> from "Robert Hough" at Feb 26, 99 10:53:49 am 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 > Does anyone know what this message means? I've got like 2-3 people with > this problem, and cant seem to figure out what it is. > > NOQUEUE: Null connection from cthulu.iserve.net [207.250.219.24] Your loglevel is greater than 5? 8-) 8-). No, wait... you enabled "lognullconnection"? 8-) 8-). It means that whoever connected you you either immediately disconnected, or sent a quit command and caused you to disconnect. If the message immediately before this in the log is "lost input channel..." Then it's a disconnect; otherwise it's a quit. Are you seeing a lot of processes in FIN_WAIT_2? It's pretty easy to stage a denial of service attack against a FreeBSD machine by using a Windows box and writing a program that: 1) Opens the SMTP port 2) Sends a "quit" 3) Waits for the "221" disconnect 4) Waits for the server shutdown. 5) Does *not* call "shutdown" on the socket 6) Calls "close" on the socket to discard the local context 7) Go to (1) This is because the socket resource tracking that results in the CTL,ACK is based on an explicit call to "shutdown" in WinSock... in other words, a close of a socket on Windows will not result in a proper shutdown. This is actually a bug in the design of the TCP/IP protocol, in that it requires two response packets from the client for one packet from the server, and places no limitations on the time it takes to send it. FreeBSD and a number of other OS's hack around the problem by putting a time-to-live on FIN_WAIT_2 state, but of course these are just hacks to limit the damage from broken clients. The hacks are pretty useless in the face of an intentional denial of service attack. NT server's TCP/IP stack fixes this by, after 2 MSL, pretending it "lost" the ACK that caused the FIN_WAIT_1 to FIN_WAIT_2 transition on the server. As a result, it resends the solicitation. If you sniff the wire on any relatively busy office connected to the Internet, you will see NT servers from all over "attACKing" you; this is what they are doing. If the remote machine ACK's again, it means that it knows about the TCP/IP session, and that it wasn't closed. If, however, it RST's you, then you treat it as if the FIN,ACK had been sent, and close down the connection. This should probably be implemeneted as an official change to the TCP/IP specification to deal with denial of service attacks (worst case, the attacker is DOS'ed back and required to ACK you to keep the attack up). So far, despite multiple reports, FreeBSD and other OS's seem to not care about preventing this attack. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 27 14: 5:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns1.seidata.com (ns1.seidata.com [208.10.211.2]) by hub.freebsd.org (Postfix) with ESMTP id 5A1391504A for ; Sat, 27 Feb 1999 14:05:18 -0800 (PST) (envelope-from mike@seidata.com) Received: from localhost (mike@localhost) by ns1.seidata.com (8.8.8/8.8.5) with ESMTP id RAA20500; Sat, 27 Feb 1999 17:04:54 -0500 (EST) Date: Sat, 27 Feb 1999 17:04:53 -0500 (EST) From: To: Dennis Cc: Greg Lehey , hackers@FreeBSD.ORG Subject: Re: Cobalt blames linux for their security problems! In-Reply-To: <199902271927.OAA26965@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 Sat, 27 Feb 1999, Dennis wrote: > One problem with cobalt is that they arent running the latest kernels which > fix the problem....it seems that THAT is their fault. The recent problem with Cobalt RAQs really had nothing to do with the kernel. It was related to poor security practice on Cobalt's part (putting the root home and web home in the same place) and could have easily been fixed without any modifications to the OS itself - it was not a Linux problem, it was an oversight on Cobalt's part. It would have been nice to simply see them quickly release an announcement with suggested fixes (as said before, the numerous fixes are quick and easy). However, it showed immaturity on Cobalt's part when they attempted to blame the OS. Still, quite discouraging. -- Mike Hoskins Systems/Network Administrator SEI Data Network Services, Inc. http://www.seidata.com "In a world where an admin is rendered useless when the ball in his mouse has been taken out, its good to know that I know UNIX." -- toaster.sun4c.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 27 14:54:50 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 B36AB14BDA for ; Sat, 27 Feb 1999 14:54:47 -0800 (PST) (envelope-from dennis@etinc.com) Received: from dbsys (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.8.8/8.6.9) with SMTP id RAA27543; Sat, 27 Feb 1999 17:56:15 -0500 (EST) Message-Id: <199902272256.RAA27543@etinc.com> X-Sender: dennis@etinc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sat, 27 Feb 1999 18:04:39 -0500 To: Chuck Robey From: Dennis Subject: Re: Cobalt blames linux for their security problems! Cc: hackers@freebsd.org In-Reply-To: References: <199902271927.OAA26965@etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 02:56 PM 2/27/99 -0500, you wrote: >On Sat, 27 Feb 1999, Dennis wrote: > >> At 09:18 PM 2/27/99 +1030, you wrote: >> >On Saturday, 27 February 1999 at 2:16:02 -0500, mike@seidata.com wrote: >> >> On Fri, 26 Feb 1999, Julian Elischer wrote: >> >> >> >>> There's a good idea.. use a free OS and then blame it for your problems.. >> >> >> >> Tell me about it... here's my response. >> >> >> >> >> >> [snip] >> >> >> >> >> >> I had actually looked into some of Cobalt's products... must say I've >> >> lost quite a bit of respect for them as a result of their reponse to >> >> this issue. Then again, what's to consider anyway... They don't run >> >> FreeBSD. ;) >> > >> >They could just as well have run FreeBSD. The issue here is that they >> >(or somebody else) are blaming the OS for their own mistakes. >> >> Well the RAQ is a RISC processor that FreeBSD doesnt support, so I dont >> think that that was an option. Blaming an OS is an OK thing I think...you cant >> as a vendor be expected to fix everything thats wrong....PCI shared memory on >> secondary buses doesnt seem to work in FreeBSD2.2 (havent tried 3.1 yet)... >> you have to blame the OS as its not practical to fix it yourself. > >Dennis, did you read enough of that article? Their problem was leaving >around a .history file, it hadn't anything at all to do with pci >probing. > >That article had more factual screwups (on both sides, to be fair) than >I can believe ... let's not make it worse by skimming the facts to fit >our moods. I was generalizing more on the point that many seemed to be making that you shouldnt blame a free OS for its fallacies that the specifics of the cobalt situation. Sorry if I didnt make that clear. Dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 27 15:16:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from shibumi.feralmonkey.org (shibumi.feralmonkey.org [203.41.114.182]) by hub.freebsd.org (Postfix) with ESMTP id A9D6114F47 for ; Sat, 27 Feb 1999 15:15:34 -0800 (PST) (envelope-from nick@FERALMONKEY.ORG) Received: from shibumi (shibumi [203.41.114.182]) by shibumi.feralmonkey.org (Postfix) with ESMTP id 3120F780B; Sun, 28 Feb 1999 10:21:36 +1100 (EST) Date: Sun, 28 Feb 1999 10:21:36 +1100 (EST) From: To: Brian Handy Cc: hackers@freebsd.org Subject: Re: unwanted packets in secure mode 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 following will help you locate where these packets are coming from. # tcpdump -i udp and dst host and dst port 514 Nick -- "We all agree that your theory is crazy, but is it crazy enough?" - Niels Bohr (1885 - 1962) On Fri, 26 Feb 1999, Brian Handy wrote: > Hey folks, > > I'm running syslogd in secure mode ("-s" option in rc.conf), and I got > these messages today: > > Message from syslogd@lambic at Fri Feb 26 16:01:57 1999 ... > lambic syslogd: discarded 1 unwanted packets in secure mode > > Message from syslogd@lambic at Fri Feb 26 16:01:57 1999 ... > lambic syslogd: discarded 2 unwanted packets in secure mode > > ... > > I discarded 8 packets, all told. I recognize I asked syslogd to discard > these, and sure enough, if I look at the syslogd man page, that's what it > says it's supposed to do. > > What's it doing? Any way to tell where these are coming from? Should I > wonder about this? > > > Brian > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 27 21:33:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id 23FD215143 for ; Sat, 27 Feb 1999 21:33:36 -0800 (PST) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id GAA18725 for freebsd-hackers@freebsd.org; Sun, 28 Feb 1999 06:33:19 +0100 (CET) (envelope-from olli) Date: Sun, 28 Feb 1999 06:33:19 +0100 (CET) From: Oliver Fromme Message-Id: <199902280533.GAA18725@dorifer.heim3.tu-clausthal.de> To: freebsd-hackers@freebsd.org Subject: Re: ISA DMA problems if >= 512 Mb RAM? Newsgroups: list.freebsd-hackers Organization: Administration Heim 3 Reply-To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Karsten W. Rohrbach wrote in list.freebsd-hackers: you wrote (23 Feb 1999 18:52:28 +0100): > could it be, that there is some side effect with the graphics aperture > mapping on intel bx chipset boards? There is no graphics aperture at all, so that's not the problem. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message