From owner-freebsd-current Sun Oct 14 0:34: 6 2001 Delivered-To: freebsd-current@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id F03BF37B40B for ; Sun, 14 Oct 2001 00:33:58 -0700 (PDT) Received: (qmail 36771 invoked by uid 1000); 14 Oct 2001 07:33:57 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 14 Oct 2001 07:33:57 -0000 Date: Sun, 14 Oct 2001 02:33:57 -0500 (CDT) From: Mike Silbersack To: Terry Lambert Cc: Subject: Re: Some interrupt coalescing tests In-Reply-To: <3BC93111.E0804A37@mindspring.com> Message-ID: <20011014014546.L36700-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 13 Oct 2001, Terry Lambert wrote: > Mike Silbersack wrote: > > One issue to be careful of here is that the removal of the > tcptmpl actually causes a performance hit that wasn't there > in the 4.3 code. My original complaint about tcptmpl taking > up 256 instead of 60 bytes stands, but I'm more than half > convinced that making it take up 60 bytes is OK... or at > least is more OK than allocating and deallocating each time, > and I don't yet have a better answer to the problem. 4.3 > doesn't have this change, but 4.4 does. I need benchmarks to prove the slowdown, Terry. The testing I performed (which is limited, of course) showed no measureable speed difference. Remember that the only time the tcptempl mbuf ever gets allocated now is when a keepalive is sent, which is a rare event. The rest of the time, it's just copying the data from the preexisting structures over to the new packet. If you can show me that this method is slower, I will move it over to a zone allocated setup like you proposed. > > I'm not sure if the number was lower because the celeron couldn't run the > > flooder as quickly, or if the -current box was dropping packets. I > > suspect the latter, as the -current box was NOTICEABLY slowed down; I > > could watch systat refresh the screen. > > This is unfortunate; it's an effect that I expected with > the -current code, because of the change to the interrupt > processing path. > > To clarify here, the slowdown occurred both with and without > the patch, right? > > The problem here is that when you hit livelock (full CPU > utilization), then you are pretty much unable to do anything > at all, unless the code path goes all the way to the top of > the stack. Yep, the -current box livelocked with and without the patch. I'm not sure if -current is solely to blame, though. My -current box is using a PNIC, which incurs additional overhead relative to other tulip clones, according to the driver's comments. And the 3com in that box hasn't worked in a while... maybe I should try debugging that so I have an additional test point. > > The conclusion? I think that the dc driver does a good enough job of > > grabbing multiple packets at once, and won't be helped by Terry's patch > > except in a few very cases. > > 10% is a good improvement; my gut feeling is that it would > have been less than that. This is actually good news for > me, since it means that my 30% number is bounded by the > user space program not being run (in other words, I should > be able to get considerably better performance, using a > weighted fair share scheduler). As long as it doesn't > damage performance, I think that it's proven itself. Hm, true, I guess the improvement is respectable. My thought is mostly that I'm not sure how much it's extending the performance range of a system; testing with more varied packet loads as suggested by Alfred would help tell us the answer to this. > > In fact, I have a sneaky suspicion that Terry's patch may > > increase bus traffic slightly. I'm not sure how much of > > an issue this is, perhaps Bill or Luigi could comment. > > This would be interesting to me, as well. I gave Luigi an > early copy of the patch to play with a while ago, and also > copied Bill. > > I'm interested in how you think it could increase traffic; > the only credible reason I've been able to come up with is > the ability to push more packets through, when they would > otherwise end up being dropped because of the queue full > condition -- if this is the case, the bus traffic is real > work, and not additonal overhead. The extra polling of the bus in cases where there are no additional packets to grab is what I was wondering about. I guess in comparison to the quantity of packet data going by, it's not a real issue. > > In short, if we're going to try to tackle high interrupt load, > > it should be done by disabling interrupts and going to polling > > under high load; > > I would agree with this, except that it's only really a > useful observation if FreeBSD is being used as purely a > network processor. Without interrupts, the polling will > take a significant portion of the available CPU to do, and > you can't burn that CPU if, for example, you have an SSL > card that does your handshakes, but you need to run the SSL > sessions themselves up in user space. Straight polling isn't necessarily the solution I was thinking of, but rather some form of interrupt disabling at high rates. For example, if the driver were to keep track of how many interrupts/second it was taking, perhaps it could up the number of receive buffers from 64 to something higher, then disable the card's interrupt and set a callback to run in a short bit of time at which point interrupts would be reenabled and the interrupt handler would be run. Ideally, this could reduce the number of interrupts greatly, increasing efficiency under load. Paired with this could be receive polling during transmit, something which does not seem to be done at current, if I'm reading correctly. I'm not sure of the feasibility of the above, unfortunately - it would seem highly dependant on how short of a timeout we can realistically get along with how many mbufs we can spare for receive buffers. > I'd argue that the complexity is coming, no matter what. If > you seperate out the tx_eof and rx_eof entry points, and > externalize them into the ethernet driver interface, in order > to enable polling, you are going to need to have a return > value on them, as well. > > To implement scheduling, this return value is going to need > to give a packet count, so that you can forego polling every > N packets (N > fair share threshold), or else you are not > going to be able to do any additional processing. True. > NB: If you are interested in pure connection rate, and you > want to protect against SYN flood, then your best bet is > actually to simply put a SYN-cookie implementation into the > firmware for the card, and deal with connection setup that > way. With that approach, you should be able to easily > support a quarter million connections a second. True. Note that in my test I wasn't actually simulating a syn flood, even though I was using a syn flooder: I just pointed it at a closed port. In the case of most NICs, offloading syn cookies to them isn't an option. > > I suppose this would all change if we were using LRP and doing lots of > > processing in the interrupt handler... but we aren't. > > This is probably a back-handed poke at me not making the > code available. I have to either clear it with my employer, > or reimplement it from scratch (not hard; I could probably > improve it significantly, were I to do this, knowing what I > now know). I'm in the process of getting an approval list > together. It's a statement of reality more than anything. Even if you were (able) to release the LRP code, I'm not sure if getting it integrated would be possible unless it's -current compatible. Of course, I guess one could argue that if it increases performance then -current should be made compatible with it... let's stick to discussing interrupts for now. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Oct 14 1:49:44 2001 Delivered-To: freebsd-current@freebsd.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85]) by hub.freebsd.org (Postfix) with ESMTP id 0815037B406 for ; Sun, 14 Oct 2001 01:49:41 -0700 (PDT) Received: from mindspring.com (dialup-209.247.143.225.Dial1.SanJose1.Level3.net [209.247.143.225]) by gull.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id BAA14310; Sun, 14 Oct 2001 01:49:37 -0700 (PDT) Message-ID: <3BC951D4.E9638595@mindspring.com> Date: Sun, 14 Oct 2001 01:50:28 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack Cc: freebsd-current@freebsd.org Subject: Re: Some interrupt coalescing tests References: <20011014014546.L36700-100000@achilles.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Silbersack wrote: > Hm, true, I guess the improvement is respectable. My thought is mostly > that I'm not sure how much it's extending the performance range of a > system; testing with more varied packet loads as suggested by Alfred would > help tell us the answer to this. I didn't respond to Alfred's post, and I probably should have; he had some very good comments, including varying the load. My main interest has been in increasing throughput as much as possible; as such, my packet load has been geared towards moving the most data possible. The tests we did were with just connections per second, 1k HTTP transfers, and 10k HTTP transfers. Unfortunately, I can't give you seperate numbers without the LRP, since we didn't bother after the connection rate went from ~7000/second to 23500/second with LRP, it wasn't worth it. > The extra polling of the bus in cases where there are no additional > packets to grab is what I was wondering about. I guess in comparison to > the quantity of packet data going by, it's not a real issue. It could be, if you were doing something that was network triggered, relatively low cost, but CPU intensive; on the whole, though, there's very little that isn't going to be network related, these days, and what there is, will end up not taking the overhead, unless you are also doing networking. Maybe it should be a tunable? But these days, everything is pretty much I/O bound, not CPU bound. The one thing I _would_ add -- though I'm waiting for it to be a problem before doing it -- is to limit the total number of packets processed per interrupt by keeping a running count. You would have to be _AMAZINGLY_ loaded to hit this, though; since it would mean absolutely continuous DMAs. I think it is self-limiting, should that happen, since once you are out of mbufs, you're out. The correct thing to do is probably to let it run out, but keep a seperate transmit reserve, so that you can process requests to completion. I don't know if anyone has tested what happens to apache in a denial of service attack consisting of a huge number of partial "GET" requests that are incomplete, and so leave state hanging around in the HTTP server... [ ... polling vs. interrupt load ... ] > Straight polling isn't necessarily the solution I was thinking of, but > rather some form of interrupt disabling at high rates. For example, if > the driver were to keep track of how many interrupts/second it was taking, > perhaps it could up the number of receive buffers from 64 to something > higher, then disable the card's interrupt and set a callback to run in a > short bit of time at which point interrupts would be reenabled and the > interrupt handler would be run. Ideally, this could reduce the number of > interrupts greatly, increasing efficiency under load. Paired with this > could be receive polling during transmit, something which does not seem to > be done at current, if I'm reading correctly. > > I'm not sure of the feasibility of the above, unfortunately - it would > seem highly dependant on how short of a timeout we can realistically get > along with how many mbufs we can spare for receive buffers. Yes. Floyd and Druschel recommend using high and low watermarks on the amount of data pending processing in user space. The most common approach is to use a fair share scheduling algorithm, which reserves a certain amount of CPU for user space processing, but this is somewhat wasteful, if there is no work, since it denies quantum to the interrupt processing, potentially wrongly. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Oct 14 6:40:48 2001 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 32CCE37B406 for ; Sun, 14 Oct 2001 06:40:45 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 4713914C2E; Sun, 14 Oct 2001 15:40:43 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Bob Willcox Cc: current list , imp@village.org Subject: Re: Best way to get a system on current? References: <20011012111534.C49550@luke.immure.com> <20011013144945.A18662@luke.immure.com> From: Dag-Erling Smorgrav Date: 14 Oct 2001 15:40:42 +0200 In-Reply-To: <20011013144945.A18662@luke.immure.com> Message-ID: Lines: 12 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bob Willcox writes: > The first proplem was that the "make installkernel" got an error due to > not finding the program kldxref. This didn't seem to serious so I simply > ignored it (it appeared to be right at the end of things, the kernel and > modules were already installed). Known bug. The kldxref step is the last in the installkernel target, and you can safely ignore this failure. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Oct 14 7:31:41 2001 Delivered-To: freebsd-current@freebsd.org Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by hub.freebsd.org (Postfix) with ESMTP id 4481D37B406 for ; Sun, 14 Oct 2001 07:31:38 -0700 (PDT) Received: from trantor.xs4all.nl (trantor.xs4all.nl [194.109.61.248]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9EEVwvH059846 for ; Sun, 14 Oct 2001 16:31:58 +0200 (CEST) Received: from trantor.xs4all.nl (localhost [127.0.0.1]) by trantor.xs4all.nl (8.11.6/8.9.3) with ESMTP id f9EEVFh22336 for ; Sun, 14 Oct 2001 16:31:15 +0200 (MET DST) (envelope-from paulz@trantor.xs4all.nl) Message-Id: <200110141431.f9EEVFh22336@trantor.xs4all.nl> To: freebsd-current@FreeBSD.ORG Subject: Multiple NFS server problems with Solaris 8 clients Date: Sun, 14 Oct 2001 16:31:14 +0200 From: Paul van der Zwan Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I am using -current box as a homedir server for my Solaris clients and have noticed a wierd problem. When I login my homedir gets mounted ok but when I type ls -l it just waits until I ^C it. If I run snoop on Solaris I see a getattr request being sent and an answer being received but apparently it gets ignored by Solaris. This happens on both Sol x86 and Sparc ( both with MU5 installed) Another problem I see is that rebooting the client causes the server to ignore request afterwards. I see SYNS sent to the server but no respons at all... One more problem is in nfsd, if I set it to use udp only it starts eating all cpu cycles it can get,but only the master process. Trussing the proces shows no system calls whatsoever being performed. BTW This is -current built yesterday ( oct 13). Paul PS Snoop logs or tcpdump logs are avialable for those who know what to look for... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Oct 14 7:37:41 2001 Delivered-To: freebsd-current@freebsd.org Received: from hfep02.dion.ne.jp (hfep02.dion.ne.jp [203.181.105.68]) by hub.freebsd.org (Postfix) with ESMTP id 7B1AD37B405; Sun, 14 Oct 2001 07:37:37 -0700 (PDT) Received: from localhost ([211.134.73.170]) by hfep02.dion.ne.jp with ESMTP id <20011014143735714.NCAN@hfep02.dion.ne.jp>; Sun, 14 Oct 2001 23:37:35 +0900 To: current@FreeBSD.org, acpi-jp@jp.freebsd.org Cc: msmith@FreeBSD.org, brian@freebsd-services.com Subject: Re: ACPI panic at boot time in -current In-Reply-To: <200110120015.f9C0FcP00724@hak.lan.Awfulhak.org> References: <200110120015.f9C0FcP00724@hak.lan.Awfulhak.org> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011014233619F.haro@h4.dion.ne.jp> Date: Sun, 14 Oct 2001 23:36:19 +0900 From: Munehiro Matsuda X-Dispatcher: imput version 20000228(IM140) Lines: 55 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi all, From: Brian Somers Date: Fri, 12 Oct 2001 01:15:38 +0100 ::Hi, :: ::I was wondering if anybody has any suggestions about why this might ::be happening in -current: ::pccbb1: irq 0 at device 10.1 on pci0 ::pccbb1: PCI Memory allocated: 10001000 ::acpi_pcib0: possible interrupts: 9 ::panic: free: multiple freed item 0xc14f75f0 ::Debugger("panic") ::Stopped at Debugger+0x44: pushl %ebx ::db> t I also get the same kind of panic, after import of ACPICA 20010920 snapshot. If I boot very current kernel with old acpi.ko based on 20010831 snapshot, system boots up just fine. Panic message from current kernel with acpi.ko based on 20010920 snapshot: -----8<---------8<---------8<---------8<---------8<---------8<---------8<---- uhci0: port 0xfc60-0xfc7f at device 7. 2 on pci0 acpi_pcib0: possible interrupts: 9 panic: free: multiple freed item 0xc13843d0 Debugger("panic") Stopped at Debugger+0x44: pushl %ebx db> -----8<---------8<---------8<---------8<---------8<---------8<---------8<---- Related dmesg from the same kernel with old acpi.ko based on 20010831 snapshot: -----8<---------8<---------8<---------8<---------8<---------8<---------8<---- uhci0: port 0xfc60-0xfc7f at device 7.2 on pci0 acpi_pcib0: matched entry for 0.7.INTD (source \\_SB_.LNKD) acpi_pcib0: possible interrupts: 9 acpi_pcib0: routed interrupt 9 via \\_SB_.LNKD usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub1: Philips Semiconductors hub, class 9/0, rev 1.10/1.10, addr 2 uhub1: 3 ports with 3 removable, self powered -----8<---------8<---------8<---------8<---------8<---------8<---------8<---- Hope this helps, Haro =------------------------------------------------------------------------------ _ _ Munehiro (haro) Matsuda -|- /_\ |_|_| Business Incubation Dept., Kubota Corp. /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome Chuo-ku Tokyo 103-8310, Japan Tel: +81-3-3245-3318 Fax: +81-3-3245-3315 Email: haro@kubota.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Oct 14 8:36:43 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.dada.it (mail3.dada.it [195.110.96.70]) by hub.freebsd.org (Postfix) with SMTP id 2DCBD37B403 for ; Sun, 14 Oct 2001 08:36:39 -0700 (PDT) Received: (qmail 28790 invoked from network); 14 Oct 2001 15:36:32 -0000 Received: from unknown (HELO torrini.org) (195.110.114.101) by mail.dada.it with SMTP; 14 Oct 2001 15:36:32 -0000 Received: (from riccardo@localhost) by torrini.org (8.11.6/8.11.6) id f9EFaR215932; Sun, 14 Oct 2001 17:36:27 +0200 (CEST) (envelope-from riccardo) Message-ID: X-Mailer: XFMail 1.5.1 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 14 Oct 2001 17:36:27 +0200 (CEST) From: Riccardo Torrini To: freebsd-current@FreeBSD.ORG Subject: New features for -current Cc: esperti@gufi.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Over than an year ago (9.9.2000) I submitted a pr (kern/21154) to ask renaming from actual *_saver.ko to saver_*.ko of saver modules to uniform names under /boot/kernel as sound (snd_*), interfaces (if_*), splash (splash_*) and netgraph (ng_*). I tryed to figure where are used and I found only /etc/rc.i386: kldstat -v | grep -q _saver || kldload ${saver}_saver need to be changed to: kldstat -v | grep -q saver_ || kldload saver_${saver} Is this really so stupid? I think order is important... Another question: I noticed good support for USB peripherals like scanner, mp3 player (rio) mouse and ethernet but nothing to use a photo camera (yes, I buy an inexpensive usb digital photo camera, Agfa ePhoto-CL18) and I try to compile gphoto because it recently added support for CL-18 (w/out success). Would be a great idea add /dev/uphoto and even better a sort of photo-file-system, where read is mapped to download image, unlink to delete and maybe create file to take a picture so we can use ls, cp, rm and touch to access photo camera... Riccardo. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Oct 14 8:47:20 2001 Delivered-To: freebsd-current@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id ABE3C37B40E; Sun, 14 Oct 2001 08:47:15 -0700 (PDT) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.11.6+3.4W/8.11.6/tasogare/smtpfeed 1.14) with ESMTP/inet id f9EFl0m98637; Mon, 15 Oct 2001 00:47:00 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Mon, 15 Oct 2001 00:46:57 +0900 (JST) Message-Id: <20011015.004657.74755975.iwasaki@jp.FreeBSD.org> To: acpi-jp@jp.freebsd.org, haro@h4.dion.ne.jp Cc: current@FreeBSD.org, msmith@FreeBSD.org, brian@freebsd-services.com, iwasaki@jp.FreeBSD.org Subject: Re: [acpi-jp 1343] Re: ACPI panic at boot time in -current From: Mitsuru IWASAKI In-Reply-To: <20011014233619F.haro@h4.dion.ne.jp> References: <200110120015.f9C0FcP00724@hak.lan.Awfulhak.org> <20011014233619F.haro@h4.dion.ne.jp> X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, Intel folks. I've just found the bug in rsutils.c which double free(); AcpiUtRemoveReference() and ACPI_MEM_FREE(). Here is a fix. Index: rsutils.c =================================================================== RCS file: /home/ncvs/src/sys/contrib/dev/acpica/rsutils.c,v retrieving revision 1.1.1.7 diff -u -r1.1.1.7 rsutils.c --- rsutils.c 4 Oct 2001 23:12:13 -0000 1.1.1.7 +++ rsutils.c 14 Oct 2001 15:23:13 -0000 @@ -490,7 +490,6 @@ */ Cleanup: - ACPI_MEM_FREE (ByteStream); return_ACPI_STATUS (Status); } I suspect that this should be removed in ACPICA 20010831-to-20010920 changes. Matsuda-san, thanks. I missed the original mail in current ML written by brian. Thanks > Hi all, > > From: Brian Somers > Date: Fri, 12 Oct 2001 01:15:38 +0100 > ::Hi, > :: > ::I was wondering if anybody has any suggestions about why this might > ::be happening in -current: > > ::pccbb1: irq 0 at device 10.1 on pci0 > ::pccbb1: PCI Memory allocated: 10001000 > ::acpi_pcib0: possible interrupts: 9 > ::panic: free: multiple freed item 0xc14f75f0 > ::Debugger("panic") > ::Stopped at Debugger+0x44: pushl %ebx > ::db> t > > I also get the same kind of panic, after import of ACPICA 20010920 snapshot. > If I boot very current kernel with old acpi.ko based on 20010831 snapshot, > system boots up just fine. > > Panic message from current kernel with acpi.ko based on 20010920 snapshot: > -----8<---------8<---------8<---------8<---------8<---------8<---------8<---- > uhci0: port 0xfc60-0xfc7f at device 7. > 2 on pci0 > acpi_pcib0: possible interrupts: 9 > panic: free: multiple freed item 0xc13843d0 > Debugger("panic") > Stopped at Debugger+0x44: pushl %ebx > db> > -----8<---------8<---------8<---------8<---------8<---------8<---------8<---- > > Related dmesg from the same kernel with old acpi.ko based on 20010831 snapshot: > -----8<---------8<---------8<---------8<---------8<---------8<---------8<---- > uhci0: port 0xfc60-0xfc7f at device 7.2 on pci0 > acpi_pcib0: matched entry for 0.7.INTD (source \\_SB_.LNKD) > acpi_pcib0: possible interrupts: 9 > acpi_pcib0: routed interrupt 9 via \\_SB_.LNKD > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > uhub1: Philips Semiconductors hub, class 9/0, rev 1.10/1.10, addr 2 > uhub1: 3 ports with 3 removable, self powered > -----8<---------8<---------8<---------8<---------8<---------8<---------8<---- > > Hope this helps, > Haro > =------------------------------------------------------------------------------ > _ _ Munehiro (haro) Matsuda > -|- /_\ |_|_| Business Incubation Dept., Kubota Corp. > /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome > Chuo-ku Tokyo 103-8310, Japan > Tel: +81-3-3245-3318 Fax: +81-3-3245-3315 > Email: haro@kubota.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Oct 14 9: 9:25 2001 Delivered-To: freebsd-current@freebsd.org Received: from lurza.secnetix.de (lurza.secnetix.de [212.66.1.130]) by hub.freebsd.org (Postfix) with ESMTP id 8A0EE37B406 for ; Sun, 14 Oct 2001 09:09:20 -0700 (PDT) Received: (from olli@localhost) by lurza.secnetix.de (8.11.6/8.11.6) id f9EG9Ja37319; Sun, 14 Oct 2001 18:09:19 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Date: Sun, 14 Oct 2001 18:09:19 +0200 (CEST) Message-Id: <200110141609.f9EG9Ja37319@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG Reply-To: freebsd-current@FreeBSD.ORG Subject: Re: New features for -current In-Reply-To: X-Newsgroups: list.freebsd-current User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.4-RELEASE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Riccardo Torrini wrote: > Would be a great idea add /dev/uphoto and even better a sort > of photo-file-system, where read is mapped to download image, > unlink to delete and maybe create file to take a picture so > we can use ls, cp, rm and touch to access photo camera... Yes, great idea, Riccardo -- please do it. :-) However, there is no standard for accessing digital photo cameras via USB. Recently, some of them seem to comply with the mass storage protocol (BSD's umass driver), but the majority of them use proprietary protocols. Even the same vendor uses different protocols for different of his cameras. So, basically you would have to write a separate kernel driver for every camera. This isn't feasible. It is probably much better to handle these issues in userland code. As an example, you could have a look at the "oPhoto" tool which handles the Kodak DC240, DC280 and DC3400 under Free- BSD (and possibly also others, but _not_ the Kodak DC220, DC260 and DC265). These are all USB photo cameras. The tool is written in userland code and uses the generic ugen driver to access the camera, which works pretty well. If you absolutely want to access the images like a real filesystem (I don't think this would have any real advan- tage), you could wrap an NFS userland server around the code. Bloating the kernel with such stuff is a bad idea, IMO. Regards Oliver PS: oPhoto: http://www.fromme.com/ophoto/ -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Oct 14 10:16:10 2001 Delivered-To: freebsd-current@freebsd.org Received: from updraft.jp.freebsd.org (updraft.jp.FreeBSD.ORG [210.157.158.42]) by hub.freebsd.org (Postfix) with ESMTP id 7CFBC37B409 for ; Sun, 14 Oct 2001 10:16:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by updraft.jp.freebsd.org (8.11.6+3.4W/8.11.3) with ESMTP/inet id f9EHG2Y41323 for ; Mon, 15 Oct 2001 02:16:02 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) X-User-Agent: Mew/1.94.2 XEmacs/21.5 (alfalfa) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 23 From: Makoto MATSUSHITA To: current@FreeBSD.org Subject: gunzip returned -1 when installing Date: Mon, 15 Oct 2001 02:15:59 +0900 Message-Id: <20011015021559Y.matusita@jp.FreeBSD.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I tried to install latest 5-current via ftp. However, when sysinstall fetches all bin distribution, following dialog (sorry, I've forget to copy a screenshot) is shown: User Confirmation Requested Unable to transfer the bin distribution from ... Do you want to try to retrieve it again ? I switched to VTY2 and see what's message are there. The last 5 lines of them are: /stand/cpio: root/.profile linked to .profile .profile DEBUG: wait for gunzip returned status of -1! COPYRIGHT 12888 blocks Hmm, sysinstall says something goes wrong with gunzip. Anybody can confirm this behaviro or this is my local error? -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Oct 14 12:14:15 2001 Delivered-To: freebsd-current@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 86AF737B409 for ; Sun, 14 Oct 2001 12:14:09 -0700 (PDT) Received: from mindspring.com (dialup-209.247.141.170.Dial1.SanJose1.Level3.net [209.247.141.170]) by pintail.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id MAA26111; Sun, 14 Oct 2001 12:13:48 -0700 (PDT) Message-ID: <3BC9E41F.2D7BC40@mindspring.com> Date: Sun, 14 Oct 2001 12:14:39 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul van der Zwan Cc: freebsd-current@FreeBSD.ORG Subject: Re: Multiple NFS server problems with Solaris 8 clients References: <200110141431.f9EEVFh22336@trantor.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Paul van der Zwan wrote: > If I run snoop on Solaris I see a getattr request being sent and > an answer being received but apparently it gets ignored by Solaris. > This happens on both Sol x86 and Sparc ( both with MU5 installed) Please do a tcpdump, and examine it; I suspect you will find that your problem is that the IP address it was sent to is not the same as the IP address it was replied from. In general, this is because the code doesn't explicitly use recvfrom/sendto semantics, and just takes the route. This will most often occur when you mount it using an IP alias, but the primary (non-alias) IP address is is on the same subnet as the alias. It can also occur if you are using two address sets on the same wire, and do not use an intervening router. > Another problem I see is that rebooting the client causes the server > to ignore request afterwards. I see SYNS sent to the server but no > respons at all... Again, you will need to tcpdump it. One prospect is for the ARP table to be different on the "who has" after the reboot. I've noticed that a ping socket gets a route, and even after an ICMP redirect, I still get a bunch of redirects, since FreeBSD does not update the route table for already created clones (this is a bug in FreeBSD's routing code). Another possibility is the reboot reset the sequence number; a common thing is to ensure that the random sequence number used is later than the one that was used last for the same IP/port pairs. The client will most likely reuse the same numbers, or lower numbers, even if it is RFC compliant as to non-guessable sequence numbers (you will see this on the tcpdump). FreeBSD will not guarantee increasing sequence numbers -- and will thus "ignore" the packets -- unless you enable the sysctl to disable the "pure random" sequence nu,mber hack. Look for it via the command "sysctl -A | grep -i seq". NB: FreeBSD also does not reset connections in TIME_WAIT, if it gets packets from the same IP/port on the client while the server is in TIME_WAIT because the connections are dead. This is a common hack (NT does this by default, and so does Solaris), but it opens you up for connection force-down attacks for active connections, if your network is improperly firewalled. > One more problem is in nfsd, if I set it to use udp only it starts > eating all cpu cycles it can get,but only the master process. > Trussing the proces shows no system calls whatsoever being performed. The I/O daemons make a system call and never return to user space. To track down this problem, truss is of no use: you must use DDB in the kernel (or remote kernel debugging, if you have two systems available: see the FreeBSD Developer's Handbook), and find out what it's doing in the kernel when this happens... I suspect that you are having one of the problems above, and are being packet-flooded by the clients, when they get no response, or at least none they like, from the server. > BTW This is -current built yesterday ( oct 13). You may also want to try 4.3 or 4.4 instead. > PS Snoop logs or tcpdump logs are avialable for those who know what > to look for... I'll look at them if they are up on a web site, but not if you mail them, so _DON'T_ mail them to me! -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Oct 14 12:24:16 2001 Delivered-To: freebsd-current@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 6A5D937B411 for ; Sun, 14 Oct 2001 12:24:11 -0700 (PDT) Received: from wonky.feral.com (wonky.feral.com [192.67.166.7]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f9EJNxH07822; Sun, 14 Oct 2001 12:23:59 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Sun, 14 Oct 2001 12:23:59 -0700 (PDT) From: Matthew Jacob Reply-To: To: Terry Lambert Cc: Paul van der Zwan , Subject: Re: Multiple NFS server problems with Solaris 8 clients In-Reply-To: <3BC9E41F.2D7BC40@mindspring.com> Message-ID: <20011014121551.Y45231-100000@wonky.feral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Actually, I've also noticed problems in FreeBSD-current also- ls and reads work, but things like mkdir hang. Here's the tcpdump output: Script started on Sun Oct 14 12:21:50 2001 quarm.feral.com > root tcpdump -vv -i fxp0 host antares tcpdump: listening on fxp0 12:21:58.498568 antares.1294025654 > quarm.nfs: 116 getattr [|nfs] (DF) (ttl 64, id 2722, len 156) 12:21:58.498746 quarm.nfs > antares.1294025654: reply ok 116 getattr [|nfs] (DF) (ttl 64, id 29331, len 156) 12:21:58.501021 antares.1294025655 > quarm.nfs: 116 getattr [|nfs] (DF) (ttl 64, id 2723, len 156) 12:21:58.501184 quarm.nfs > antares.1294025655: reply ok 116 getattr [|nfs] (DF) (ttl 64, id 29332, len 156) 12:21:58.501657 antares.1294025656 > quarm.nfs: 116 getattr [|nfs] (DF) (ttl 64, id 2724, len 156) 12:21:58.501707 quarm.nfs > antares.1294025656: reply ok 116 getattr [|nfs] (DF) (ttl 64, id 29333, len 156) 12:21:58.502062 antares.1294025657 > quarm.nfs: 116 getattr [|nfs] (DF) (ttl 64, id 2725, len 156) 12:21:58.502117 quarm.nfs > antares.1294025657: reply ok 116 getattr [|nfs] (DF) (ttl 64, id 29334, len 156) 12:21:58.502475 antares.1294025658 > quarm.nfs: 116 getattr [|nfs] (DF) (ttl 64, id 2726, len 156) 12:21:58.502519 quarm.nfs > antares.1294025658: reply ok 116 getattr [|nfs] (DF) (ttl 64, id 29335, len 156) 12:21:58.598618 antares.1018 > quarm.nfsd: . [tcp sum ok] 437975440:437975440(0) ack 4039870942 win 24820 (DF) (ttl 64, id 2727, len 40) ----- OKAY- that was the ls that workes 12:22:10.893273 antares.1294025660 > quarm.nfs: 116 getattr [|nfs] (DF) (ttl 64, id 2728, len 156) 12:22:10.893409 quarm.nfs > antares.1294025660: reply ok 116 getattr [|nfs] (DF) (ttl 64, id 29367, len 156) 12:22:10.893740 antares.1294025661 > quarm.nfs: 120 getattr [|nfs] (DF) (ttl 64, id 2729, len 160) 12:22:10.992986 quarm.nfsd > antares.1018: . [tcp sum ok] 117:117(0) ack 236 win 62459 (DF) (ttl 64, id 29368, len 40) ----- that was the mkdir (that hung) ^C 218 packets received by filter 0 packets dropped by kernel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Oct 14 13: 2: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by hub.freebsd.org (Postfix) with ESMTP id E2CE637B40C for ; Sun, 14 Oct 2001 13:02:02 -0700 (PDT) Received: from levais.imp.ch (levais.imp.ch [157.161.4.66]) by mail.imp.ch (8.11.1/8.11.1) with ESMTP id f9EK1dR46866; Sun, 14 Oct 2001 22:01:39 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Sun, 14 Oct 2001 22:03:07 +0200 (CEST) From: Martin Blapp To: Paul van der Zwan Cc: Subject: Re: Multiple NFS server problems with Solaris 8 clients Message-ID: <20011014215919.S63907-100000@levais.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, > One more problem is in nfsd, if I set it to use udp only it starts > eating all cpu cycles it can get,but only the master process. Trussing > the process shows no system calls whatsoever being performed. The last one is a know problem. There is a (unfinished) patch available to solve this problem. Thomas Moestl is still working on some issues of the patch. Please contact him if you like to know more. Here is the URL for the patch: http://home.teleport.ch/freebsd/userland/nfsd-loop.diff Martin Martin Blapp, mb@imp.ch ------------------------------------------------------------------ Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: 57E 7CCD 2769 E7AC C5FA DF2C 19C6 DCD1 1B3A EC9C ------------------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Oct 14 13:38:47 2001 Delivered-To: freebsd-current@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 60F2B37B408; Sun, 14 Oct 2001 13:38:27 -0700 (PDT) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 14 Oct 2001 21:38:26 +0100 (BST) To: Martin Blapp Cc: Paul van der Zwan , freebsd-current@FreeBSD.ORG, Thomas Moestl Subject: Re: Multiple NFS server problems with Solaris 8 clients In-Reply-To: Your message of "Sun, 14 Oct 2001 22:03:07 +0200." <20011014215919.S63907-100000@levais.imp.ch> Date: Sun, 14 Oct 2001 21:38:26 +0100 From: Ian Dowse Message-ID: <200110142138.aa70774@salmon.maths.tcd.ie> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > >The last one is a know problem. There is a (unfinished) patch available to >solve this problem. Thomas Moestl is still working on >some issues of the patch. Please contact him if you like to know more. > >Here is the URL for the patch: > >http://home.teleport.ch/freebsd/userland/nfsd-loop.diff That patch is a bit out of date, because Peter removed a big chunk of kerberos code from nfsd since. I was actually just looking at this problem again, so I include an updated version of Thomas's patch below. This version also removes entries from the children[] array when a slave nfsd dies to avoid the possibility of accidentally killing unrelated processes. The issue that remains open with the patch is that currently if a slave nfsd dies, then all nfsds will shut down. This is because nfssvc() in the master nfsd returns 0 when the master nfsd receives a SIGCHLD. This behaviour is probably reasonable enough, but the way it happens is a bit odd. Thomas, I'll probably commit this within the next few days if you have no objections, and if you don't get there before me. The exiting behaviour can be resolved later if necessary. Ian Index: nfsd.c =================================================================== RCS file: /dump/FreeBSD-CVS/src/sbin/nfsd/nfsd.c,v retrieving revision 1.21 diff -u -r1.21 nfsd.c --- nfsd.c 20 Sep 2001 02:18:06 -0000 1.21 +++ nfsd.c 14 Oct 2001 20:19:18 -0000 @@ -52,6 +52,8 @@ #include #include #include +#include +#include #include #include @@ -64,6 +66,7 @@ #include #include +#include #include #include #include @@ -86,12 +89,16 @@ int nfsdcnt; /* number of children */ void cleanup(int); +void child_cleanup(int); void killchildren(void); -void nonfs (int); -void reapchild (int); -int setbindhost (struct addrinfo **ia, const char *bindhost, struct addrinfo hints); -void unregistration (void); -void usage (void); +void nfsd_exit(int); +void nonfs(int); +void reapchild(int); +int setbindhost(struct addrinfo **ia, const char *bindhost, + struct addrinfo hints); +void start_server(int); +void unregistration(void); +void usage(void); /* * Nfs server daemon mostly just a user context for nfssvc() @@ -126,13 +133,12 @@ fd_set ready, sockbits; fd_set v4bits, v6bits; int ch, connect_type_cnt, i, len, maxsock, msgsock; - int nfssvc_flag, on = 1, unregister, reregister, sock; + int on = 1, unregister, reregister, sock; int tcp6sock, ip6flag, tcpflag, tcpsock; - int udpflag, ecode, s; - int bindhostc = 0, bindanyflag, rpcbreg, rpcbregcnt; + int udpflag, ecode, s, srvcnt; + int bindhostc, bindanyflag, rpcbreg, rpcbregcnt; char **bindhost = NULL; pid_t pid; - int error; if (modfind("nfsserver") < 0) { /* Not present in kernel, try loading it */ @@ -141,8 +147,8 @@ } nfsdcnt = DEFNFSDCNT; - unregister = reregister = tcpflag = 0; - bindanyflag = udpflag; + unregister = reregister = tcpflag = maxsock = 0; + bindanyflag = udpflag = connect_type_cnt = bindhostc = 0; #define GETOPT "ah:n:rdtu" #define USAGE "[-ardtu] [-n num_servers] [-h bindip]" while ((ch = getopt(argc, argv, GETOPT)) != -1) @@ -313,8 +319,6 @@ daemon(0, 0); (void)signal(SIGHUP, SIG_IGN); (void)signal(SIGINT, SIG_IGN); - (void)signal(SIGSYS, nonfs); - (void)signal(SIGUSR1, cleanup); /* * nfsd sits in the kernel most of the time. It needs * to ignore SIGTERM/SIGQUIT in order to stay alive as long @@ -324,40 +328,31 @@ (void)signal(SIGTERM, SIG_IGN); (void)signal(SIGQUIT, SIG_IGN); } + (void)signal(SIGSYS, nonfs); (void)signal(SIGCHLD, reapchild); - openlog("nfsd:", LOG_PID, LOG_DAEMON); + openlog("nfsd", LOG_PID, LOG_DAEMON); - for (i = 0; i < nfsdcnt; i++) { + /* If we use UDP only, we start the last server below. */ + srvcnt = tcpflag ? nfsdcnt : nfsdcnt - 1; + for (i = 0; i < srvcnt; i++) { switch ((pid = fork())) { case -1: syslog(LOG_ERR, "fork: %m"); - killchildren(); - exit (1); + nfsd_exit(1); case 0: break; default: children[i] = pid; continue; } - + (void)signal(SIGUSR1, child_cleanup); setproctitle("server"); - nfssvc_flag = NFSSVC_NFSD; - nsd.nsd_nfsd = NULL; - while (nfssvc(nfssvc_flag, &nsd) < 0) { - if (errno) { - syslog(LOG_ERR, "nfssvc: %m"); - exit(1); - } - nfssvc_flag = NFSSVC_NFSD; - } - exit(0); - } - - if (atexit(killchildren) == -1) { - syslog(LOG_ERR, "atexit: %s", strerror(errno)); - exit(1); - } + + start_server(0); + } + + (void)signal(SIGUSR1, cleanup); FD_ZERO(&v4bits); FD_ZERO(&v6bits); @@ -379,14 +374,14 @@ ai_udp->ai_protocol)) < 0) { syslog(LOG_ERR, "can't create udp socket"); - exit(1); + nfsd_exit(1); } if (bind(sock, ai_udp->ai_addr, ai_udp->ai_addrlen) < 0) { syslog(LOG_ERR, "can't bind udp addr %s: %m", bindhost[i]); - exit(1); + nfsd_exit(1); } freeaddrinfo(ai_udp); nfsdargs.sock = sock; @@ -394,7 +389,7 @@ nfsdargs.namelen = 0; if (nfssvc(NFSSVC_ADDSOCK, &nfsdargs) < 0) { syslog(LOG_ERR, "can't Add UDP socket"); - exit(1); + nfsd_exit(1); } (void)close(sock); } @@ -409,7 +404,7 @@ if (ecode != 0) { syslog(LOG_ERR, "getaddrinfo udp: %s", gai_strerror(ecode)); - exit(1); + nfsd_exit(1); } nconf_udp = getnetconfigent("udp"); if (nconf_udp == NULL) @@ -440,7 +435,7 @@ ai_udp6->ai_protocol)) < 0) { syslog(LOG_ERR, "can't create udp6 socket"); - exit(1); + nfsd_exit(1); } if (setsockopt(sock, IPPROTO_IPV6, IPV6_BINDV6ONLY, @@ -448,14 +443,14 @@ syslog(LOG_ERR, "can't set v6-only binding for " "udp6 socket: %m"); - exit(1); + nfsd_exit(1); } if (bind(sock, ai_udp6->ai_addr, ai_udp6->ai_addrlen) < 0) { syslog(LOG_ERR, "can't bind udp6 addr %s: %m", bindhost[i]); - exit(1); + nfsd_exit(1); } freeaddrinfo(ai_udp6); nfsdargs.sock = sock; @@ -464,7 +459,7 @@ if (nfssvc(NFSSVC_ADDSOCK, &nfsdargs) < 0) { syslog(LOG_ERR, "can't add UDP6 socket"); - exit(1); + nfsd_exit(1); } (void)close(sock); } @@ -479,7 +474,7 @@ if (ecode != 0) { syslog(LOG_ERR, "getaddrinfo udp6: %s", gai_strerror(ecode)); - exit(1); + nfsd_exit(1); } nconf_udp6 = getnetconfigent("udp6"); if (nconf_udp6 == NULL) @@ -509,7 +504,7 @@ 0)) < 0) { syslog(LOG_ERR, "can't create tpc socket"); - exit(1); + nfsd_exit(1); } if (setsockopt(tcpsock, SOL_SOCKET, SO_REUSEADDR, @@ -521,11 +516,11 @@ syslog(LOG_ERR, "can't bind tcp addr %s: %m", bindhost[i]); - exit(1); + nfsd_exit(1); } if (listen(tcpsock, 5) < 0) { syslog(LOG_ERR, "listen failed"); - exit(1); + nfsd_exit(1); } freeaddrinfo(ai_tcp); FD_SET(tcpsock, &sockbits); @@ -545,7 +540,7 @@ if (ecode != 0) { syslog(LOG_ERR, "getaddrinfo tcp: %s", gai_strerror(ecode)); - exit(1); + nfsd_exit(1); } nconf_tcp = getnetconfigent("tcp"); if (nconf_tcp == NULL) @@ -577,7 +572,7 @@ ai_tcp6->ai_protocol)) < 0) { syslog(LOG_ERR, "can't create tcp6 socket"); - exit(1); + nfsd_exit(1); } if (setsockopt(tcp6sock, SOL_SOCKET, SO_REUSEADDR, @@ -589,18 +584,18 @@ syslog(LOG_ERR, "can't set v6-only binding for tcp6 " "socket: %m"); - exit(1); + nfsd_exit(1); } if (bind(tcp6sock, ai_tcp6->ai_addr, ai_tcp6->ai_addrlen) < 0) { syslog(LOG_ERR, "can't bind tcp6 addr %s: %m", bindhost[i]); - exit(1); + nfsd_exit(1); } if (listen(tcp6sock, 5) < 0) { syslog(LOG_ERR, "listen failed"); - exit(1); + nfsd_exit(1); } freeaddrinfo(ai_tcp6); FD_SET(tcp6sock, &sockbits); @@ -620,7 +615,7 @@ if (ecode != 0) { syslog(LOG_ERR, "getaddrinfo tcp6: %s", gai_strerror(ecode)); - exit(1); + nfsd_exit(1); } nconf_tcp6 = getnetconfigent("tcp6"); if (nconf_tcp6 == NULL) @@ -636,15 +631,24 @@ if (rpcbregcnt == 0) { syslog(LOG_ERR, "rpcb_set() failed, nothing to do: %m"); - exit(1); + nfsd_exit(1); } - if ((tcpflag) && (connect_type_cnt == 0)) { + if (tcpflag && connect_type_cnt == 0) { syslog(LOG_ERR, "tcp connects == 0, nothing to do: %m"); - exit(1); + nfsd_exit(1); } setproctitle("master"); + /* + * We always want a master to have a clean way to to shut nfsd down + * (with unregistration): if the master is killed, it unregisters and + * kills all children. If we run for UDP only (and so do not have to + * loop waiting waiting for accept), we instead make the parent + * a "server" too. start_server will not return. + */ + if (!tcpflag) + start_server(1); /* * Loop forever accepting connections and passing the sockets @@ -656,7 +660,7 @@ if (select(maxsock + 1, &ready, NULL, NULL, NULL) < 1) { syslog(LOG_ERR, "select failed: %m"); - exit(1); + nfsd_exit(1); } } for (tcpsock = 0; tcpsock <= maxsock; tcpsock++) { @@ -666,7 +670,7 @@ if ((msgsock = accept(tcpsock, (struct sockaddr *)&inetpeer, &len)) < 0) { syslog(LOG_ERR, "accept failed: %m"); - exit(1); + nfsd_exit(1); } memset(inetpeer.sin_zero, 0, sizeof(inetpeer.sin_zero)); @@ -676,7 +680,7 @@ "setsockopt SO_KEEPALIVE: %m"); nfsdargs.sock = msgsock; nfsdargs.name = (caddr_t)&inetpeer; - nfsdargs.namelen = sizeof(inetpeer); + nfsdargs.namelen = len; nfssvc(NFSSVC_ADDSOCK, &nfsdargs); (void)close(msgsock); } else if (FD_ISSET(tcpsock, &v6bits)) { @@ -686,7 +690,7 @@ &len)) < 0) { syslog(LOG_ERR, "accept failed: %m"); - exit(1); + nfsd_exit(1); } if (setsockopt(msgsock, SOL_SOCKET, SO_KEEPALIVE, (char *)&on, @@ -695,7 +699,7 @@ "SO_KEEPALIVE: %m"); nfsdargs.sock = msgsock; nfsdargs.name = (caddr_t)&inet6peer; - nfsdargs.namelen = sizeof(inet6peer); + nfsdargs.namelen = len; nfssvc(NFSSVC_ADDSOCK, &nfsdargs); (void)close(msgsock); } @@ -767,8 +771,14 @@ reapchild(signo) int signo; { + pid_t pid; + int i; - while (wait3(NULL, WNOHANG, NULL) > 0); + while ((pid = wait3(NULL, WNOHANG, NULL)) > 0) { + for (i = 0; i < nfsdcnt; i++) + if (pid == children[i]) + children[i] = -1; + } } void @@ -783,32 +793,52 @@ killchildren() { int i; - sigset_t sigs; - sigemptyset(&sigs); - /* - * Block SIGCHLD to avoid killing a reaped process (although it is - * unlikely, the pid might have been reused). - */ - sigaddset(&sigs, SIGCHLD); - if (sigprocmask(SIG_BLOCK, &sigs, NULL) == -1) { - syslog(LOG_ERR, "sigprocmask: %s", - strerror(errno)); - return; - } for (i = 0; i < nfsdcnt; i++) { if (children[i] > 0) kill(children[i], SIGKILL); } - if (sigprocmask(SIG_UNBLOCK, &sigs, NULL) == -1) { - syslog(LOG_ERR, "sigprocmask: %s", strerror(errno)); - } - unregistration(); } +/* + * Cleanup master after SIGUSR1. + */ void cleanup(signo) { + nfsd_exit(0); +} + +/* + * Cleanup child after SIGUSR1. + */ +void +child_cleanup(signo) +{ + exit(0); +} + +void +nfsd_exit(int status) +{ killchildren(); - exit (0); + unregistration(); + exit(status); +} + +void +start_server(int master) +{ + int status; + + status = 0; + nsd.nsd_nfsd = NULL; + if (nfssvc(NFSSVC_NFSD, &nsd) < 0) { + syslog(LOG_ERR, "nfssvc: %m"); + status = 1; + } + if (master) + nfsd_exit(status); + else + exit(status); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Oct 14 13:47:21 2001 Delivered-To: freebsd-current@freebsd.org Received: from vlmfg.com (w194.z064000243.lax-ca.dsl.cnc.net [64.0.243.194]) by hub.freebsd.org (Postfix) with ESMTP id 85A9137B40E for ; Sun, 14 Oct 2001 13:47:09 -0700 (PDT) Received: from localhost [64.225.124.232] by vlmfg.com (SMTPD32-6.00) id AB38164B018A; Sun, 14 Oct 2001 13:53:12 -0700 To: freebsd-current@FreeBSD.org From: friendz@openxxx.net X-Mailer: Perl+Mail::Sender 0.7.08 by Jan Krynicky Subject: Hello, your friend recommended openxxx.net to you Message-Id: <200110141353290.SM00207@localhost> Date: Sun, 14 Oct 2001 13:53:22 -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG You have been invited to check out this adult site by one of your friends who visited us. click here , our URL is: http://www.openxxx.net/ enjoy, OpenXXX TEAM 2001 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Oct 14 15:15:40 2001 Delivered-To: freebsd-current@freebsd.org Received: from hfep02.dion.ne.jp (hfep02.dion.ne.jp [203.181.105.68]) by hub.freebsd.org (Postfix) with ESMTP id B5C0137B40B; Sun, 14 Oct 2001 15:15:34 -0700 (PDT) Received: from localhost ([61.200.141.136]) by hfep02.dion.ne.jp with ESMTP id <20011014221532330.PIFF@hfep02.dion.ne.jp>; Mon, 15 Oct 2001 07:15:32 +0900 To: acpi-jp@jp.freebsd.org, iwasaki@jp.freebsd.org Cc: current@FreeBSD.org, msmith@FreeBSD.org, brian@freebsd-services.com Subject: Re: ACPI panic at boot time in -current In-Reply-To: <20011015.004657.74755975.iwasaki@jp.FreeBSD.org> References: <200110120015.f9C0FcP00724@hak.lan.Awfulhak.org> <20011014233619F.haro@h4.dion.ne.jp> <20011015.004657.74755975.iwasaki@jp.FreeBSD.org> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011015071417Q.haro@h4.dion.ne.jp> Date: Mon, 15 Oct 2001 07:14:17 +0900 From: Munehiro Matsuda X-Dispatcher: imput version 20000228(IM140) Lines: 43 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG From: Mitsuru IWASAKI Date: Mon, 15 Oct 2001 00:46:57 +0900 (JST) ::Hi, Intel folks. I've just found the bug in rsutils.c which double ::free(); AcpiUtRemoveReference() and ACPI_MEM_FREE(). Here is a fix. :: ::Index: rsutils.c ::=================================================================== ::RCS file: /home/ncvs/src/sys/contrib/dev/acpica/rsutils.c,v ::retrieving revision 1.1.1.7 ::diff -u -r1.1.1.7 rsutils.c ::--- rsutils.c 4 Oct 2001 23:12:13 -0000 1.1.1.7 ::+++ rsutils.c 14 Oct 2001 15:23:13 -0000 ::@@ -490,7 +490,6 @@ :: */ :: Cleanup: :: ::- ACPI_MEM_FREE (ByteStream); :: return_ACPI_STATUS (Status); :: } :: :: ::I suspect that this should be removed in ACPICA 20010831-to-20010920 ::changes. :: ::Matsuda-san, thanks. I missed the original mail in current ML written ::by brian. :: ::Thanks Hi Iwasaki-san, That fixed my panic problem. Thanks for the patch. Haro =------------------------------------------------------------------------------ _ _ Munehiro (haro) Matsuda -|- /_\ |_|_| Business Incubation Dept., Kubota Corp. /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome Chuo-ku Tokyo 103-8310, Japan Tel: +81-3-3245-3318 Fax: +81-3-3245-3315 Email: haro@kubota.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Oct 14 15:48:20 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id 8A0C737B405 for ; Sun, 14 Oct 2001 15:48:14 -0700 (PDT) Received: (qmail 12974 invoked by uid 0); 14 Oct 2001 22:48:13 -0000 Received: from pd9e165e8.dip.t-dialin.net (HELO forge.local) (217.225.101.232) by mail.gmx.net (mp020-rz3) with SMTP; 14 Oct 2001 22:48:13 -0000 Received: from tmm by forge.local with local (Exim 3.30 #1) id 15su3D-0001TU-00; Mon, 15 Oct 2001 00:48:07 +0200 Date: Mon, 15 Oct 2001 00:48:07 +0200 From: Thomas Moestl To: Ian Dowse Cc: Martin Blapp , Paul van der Zwan , freebsd-current@FreeBSD.ORG Subject: Re: Multiple NFS server problems with Solaris 8 clients Message-ID: <20011015004807.D449@crow.dom2ip.de> References: <20011014215919.S63907-100000@levais.imp.ch> <200110142138.aa70774@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110142138.aa70774@salmon.maths.tcd.ie>; from iedowse@maths.tcd.ie on Sun, Oct 14, 2001 at 09:38:26PM +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 2001/10/14 at 21:38:26 +0100, Ian Dowse wrote: > > > >The last one is a know problem. There is a (unfinished) patch available to > >solve this problem. Thomas Moestl is still working on > >some issues of the patch. Please contact him if you like to know more. > > > >Here is the URL for the patch: > > > >http://home.teleport.ch/freebsd/userland/nfsd-loop.diff > > That patch is a bit out of date, because Peter removed a big chunk > of kerberos code from nfsd since. I was actually just looking at > this problem again, so I include an updated version of Thomas's > patch below. > > This version also removes entries from the children[] array when > a slave nfsd dies to avoid the possibility of accidentally killing > unrelated processes. > > The issue that remains open with the patch is that currently if a > slave nfsd dies, then all nfsds will shut down. This is because > nfssvc() in the master nfsd returns 0 when the master nfsd receives > a SIGCHLD. This behaviour is probably reasonable enough, but the > way it happens is a bit odd. > > Thomas, I'll probably commit this within the next few days if you > have no objections, and if you don't get there before me. The > exiting behaviour can be resolved later if necessary. Thanks! I've been meaning to update and commit this patch for quite some time, but was rather focused on sparc64 development recently when I had time. I also wanted to resolve this exiting behaviour before, but I agree that it is probably not a real issue. - thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Oct 14 22:49:42 2001 Delivered-To: freebsd-current@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 25BDE37B409 for ; Sun, 14 Oct 2001 22:49:36 -0700 (PDT) Received: by relay.butya.kz (Postfix, from userid 1000) id 908A228D7B; Mon, 15 Oct 2001 12:49:27 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 20C7228C7B; Mon, 15 Oct 2001 12:49:27 +0700 (ALMST) Date: Mon, 15 Oct 2001 12:49:26 +0700 (ALMST) From: Boris Popov To: Sheldon Hearn Cc: Julian Elischer , current@FreeBSD.org Subject: Re: KSE settling in (smbfs broken) again In-Reply-To: <22231.1002315702@axl.seasidesoftware.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 5 Oct 2001, Sheldon Hearn wrote: > > I need to look at it again.. (I figured I just didn't have the time to try > > understand it all AND do the rest of the kernel.) Of course the best woudl > > be if Mr. Popov did the conversion but I believe he's incredibly busy at > > the moment.. Certainly if someone else wants to make an effort at it. > > they are welcome to do it.. otherwise I will eventually get to it. > > (but I have no way to test them). > > Boris goes through phases, like the rest of us. :-) Yes, this is correct. Doing hardware stuff consumes a lot of my time :( > His last round of changes from Mac OS X sorted out my panics quite > nicely. Good to hear. I've selected most critical bugfixes and there is still big diffs to merge. > It sounds like the message is "I'd like to help with smbfs, but don't > have time right now, and it'd make a whole lot more sense for someone > closer to the code to take a look." Obviously, I'll do the job at some moment. If someone can do it before - feel free to do this. This may even include import of userland part in the /contrib hierarchy. -- Boris Popov http://rbp.euro.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Oct 14 23:24:52 2001 Delivered-To: freebsd-current@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 8D2B937B407 for ; Sun, 14 Oct 2001 23:24:39 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id f9F6O7460112; Mon, 15 Oct 2001 00:24:07 -0600 (MDT) (envelope-from ken) Date: Mon, 15 Oct 2001 00:24:07 -0600 From: "Kenneth D. Merry" To: Terry Lambert Cc: current@FreeBSD.ORG Subject: Re: Why do soft interrupt coelescing? Message-ID: <20011015002407.A59917@panzer.kdm.org> References: <3BBF5E49.65AF9D8E@mindspring.com> <20011006144418.A6779@panzer.kdm.org> <3BC00ABC.20ECAAD8@mindspring.com> <20011008231046.A10472@panzer.kdm.org> <3BC34FC2.6AF8C872@mindspring.com> <20011010000604.A19388@panzer.kdm.org> <3BC40E04.D89ECB05@mindspring.com> <20011010232020.A27019@panzer.kdm.org> <3BC55201.EC273414@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3BC55201.EC273414@mindspring.com>; from tlambert2@mindspring.com on Thu, Oct 11, 2001 at 01:02:09AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Oct 11, 2001 at 01:02:09 -0700, Terry Lambert wrote: > "Kenneth D. Merry" wrote: > > If the receive ring for that packet size is full, it will hold off on > > DMAs. If all receive rings are full, there's no reason to send more > > interrupts. > > I think that this does nothing, in the FreeBSD case, since the > data from the card will generally be drained much faster than > it accrues, into the input queue. Whether it gets processed > out of there before you run out of mbufs is another matter. > > [ ... ] > > > Anyway, if all three rings fill up, then yes, there won't be a reason to > > send receive interrupts. > > I think this can't really happen, since interrupt processing > has the highest priority, compared to stack processing or > application level processing. 8-(. Yep, it doesn't happen very often in the default case. > > > OK, assuming you meant that the copies would stall, and the > > > data not be copied (which is technically the right thing to > > > do, assuming a source quench style livelock avoidance, which > > > doesn't currently exist)... > > > > The data isn't copied, it's DMAed from the card to host memory. The card > > will save incoming packets to a point, but once it runs out of memory to > > store them it starts dropping packets altogether. > > I think that the DMA will not be stalled, at least as the driver > currently exists; you and I agreed on that already (see below). > My concern in this case is that, if the card is using the bus to > copy packets from card memory to the receive ring, then the bus > isn't available for other work, which is bad. It's better to > drop the packets before putting them in card memory (FIFO drop > fails to avoid the case where a continuous attack pushes all > good packets out). Dropping packets before they get into card memory would only be possible with some sort of traffic shaper/dropping mechanism on the wire to drop things before they get to the card at all. > > > The problem is still that you end up doing interrupt processing > > > until you run out of mbufs, and then you have the problem of > > > not being able to transmit responses, for lack of mbufs. > > > > In theory you would have configured your system with enough mbufs > > to handle the situation, and the slowness of the system would cause > > the windows on the sender to fill up, so they'll stop sending data > > until the receiver starts responding again. That's the whole purpose > > of backoff and slow start -- to find a happy medium for the > > transmitter and receiver so that data flows at a constant rate. > > In practice, mbuf memory is just as overcommitted as all other > memory, and given a connection count target, you are talking a > full transmit and full receive window worth of data at 16k a > pop -- 32k per connection. > > Even a modest maximum connection count of ~30,000 connections -- > something even an unpatches 4.3 FreeBSD could handle -- means > that you need 1G of RAM for the connections alone, if you disallow > overcommit. In practice, that would mean ~20,000 connections, > when you count page table entries, open file table entries, vnodes, > inpcb's, tcpcb's, etc.. And that's a generaous estimate, which > assumes that you tweak your kernel properly. You could always just put 4G of RAM in the machine, since memory is so cheap now. :) At some point you'll hit a limit in the number of connections the processor can actually handle. > One approach to this is to control the window sizes based on > th amount of free reserve you have available, but this will > actually damage overall throughput, particularly on links > with a higher latency. Yep. > > > In the ti driver case, the inability to get another mbuf to > > > replace the one that will be taken out of the ring means that > > > the mbuf gets reused for more data -- NOT that the data flow > > > in the form of DMA from the card ends up being halted until > > > mbufs become available. > > > > True. > > This is actually very bad: you want to drop packets before you > insert them into the queue, rather than after they are in the > queue. This is because you want the probability of the drop > (assuming the queue is not maxed out: otherwise, the probabilty > should be 100%) to be proportional to the exponential moving > average of the queue depth, after that depth exceeds a drop > threshold. In other words, you want to use RED. Which queue? The packets are dropped before they get to ether_input(). Dropping random packets would be difficult. > > > Please look at what happens in the case of an allocation > > > failure, for any driver that does not allow shrinking the > > > ring of receive mbufs (the ti is one example). > > > > It doesn't spam things, which is what you were suggesting before, but > > as you pointed out, it will effectively drop packets if it can't get new > > mbufs. > > Maybe I'm being harsh in calling it "spam'ming". It does the > wrong thing, by dropping the oldest unprocessed packets first. > A FIFO drop is absolutely the wrong thing to do in an attack > or overload case, when you want to shed load. I consider the > packet that is being dropped to have been "spam'med" by the > card replacing it with another packet, rather than dropping > the replacement packet instead. > > The real place for this drop is "before it gets to card memory", > not "after it is in host memory"; Floyd, Jacobsen, Mogul, etc., > all agree on that. As I mentioned above, how would you do that without some sort of traffic shaper on the wire? > > Yes, it could shrink the pool, by just not replacing those mbufs in the > > ring (and therefore not notifying the card that that slot is available > > again), but then it would likely need some mechanism to allow it to be > > notified that another buffer is available for it, so it can then allocate > > receive buffers again. > > > > In practice I haven't found the number of mbufs in the system to be a > > problem that would really make this a big issue. I generally configure > > the number of mbufs to be high enough that it isn't a problem in the > > first place. > > I have a nice test that I would be happy to run for you in > the lab. It loads a server up with 100,000 simultaneous > long duration downloads, replacing each client with a new > one when that client's download is complete. > > In the case that you run out of mbufs, FreeBSD just locks > up solid, unless you make modifications to the way that > packets are processed (or maintain a "transmit mbufs free > reserve" to endure against the deadly embrace deadlock). > > If you have another approach to resolving the deadlock, > I'm all ears... I'll repeat it for you in the lab, if you > are willing to stare at it with me... we would probably be > willing to put you on full time, if you were able to do > something about the problem, other than what I've done. 8-). My focus with gigabit ethernet was to get maximal throughput out of a small number of connections. Dealing with a large number of connections is a different problem, and I'm sure it uncovers lots of nifty bugs. > > > The driver does it on purpose, by not giving away the mbuf > > > in the receive ring, until it has an mbuf to replace it. > > > > The driver does effectively drop packets, but it doesn't spam > > over another packet that has already gone up the stack. > > It wastes a DMA, by DMA'ing over the already DMA'ed packet, > so we eat unnecessary bus bandwidth lossage as a result (see > above, as to why I called it "spam"). Yep. > > > Maybe this should be rewritten to not mark the packet as > > > received, and thus allow the card to overwrite it. > > > > That wouldn't really work, since the card knows it has DMAed into that > > slot, and won't DMA another packet in its place. The current approach is > > the equivalent, really. The driver tells the card the packet is received, > > and if it can't allocate another mbuf to replace that mbuf, it just puts > > that mbuf back in place. So the card will end up overwriting that packet. > > I'd actually prefer to avoid the other DMA; I'd also like > to avoid the packet receipt order change that results from > DMA'ing over the previous contents, in the case that an mbuf > can't be allocated. I'd rather just let good packets in with > a low (but non-zero) statistical probability, relative to a > slew of bad packets, rather than letting a lot of bad packets > from a persistant attacker push my good data out with the bad. Easier said than done -- dumping random packets would be difficult with a ring-based structure. Probably what you'd have to do is have an extra pool of mbufs lying around that would get thrown in at random times when mbufs run out to allow some packets to get through. The problem is, once you exhaust that pool, you're back to the same old problem if you're completely out of mbufs. You could probably also start shrinking the number of buffers in the ring, but as I said before, you'd need a method for the kernel to notify the driver that more mbufs are available. > [ ... ] > > > The main thing I would see is that when an interrupt handler takes > > a long time to complete, it's going to hold off other devices > > sharing that interrupt. (Or interrupt mask, perhaps.) > > If you are sharing interrupts at this network load, then > you are doing the wrong thing in your system setup. If > you don't have such a high load, then it's not a problem; > either way, you can avoid the problem, for the most part. It's easier with a SMP system (i.e. you've got an APIC.) > > This may have changed in -current with interrupt threads, though. > > It hasn't, as far as I can tell; in fact, the move to a > seperate kernel thread in order to process the NETISR > makes things worse, from what I can see. > > The thing you have to do to reintroduce fairness is to make > a decision to _not_ reenable the interrupts. The most > simplistic way to do this is to maintain queue depth counts > for amount of data on its way to user space, and then make > a conscious decision at the high watermark to _not_ reenable > interrupts. The draining of the queue then looks for the > low watermark, and when you hit it, reenables the interrupts. > > This is a really crude form of what's called "Weighted Fair > Share Queueing". There's actually a good paper on it off > the main page of the QLinux project (second hit on a Google > search for "QLinux"). > > > > Is this a request for me to resend the diffs? > > > > Yes. > > OK, I will rediff and generate context diffs; expect them to > be sent in 24 hours or so from now. It's been longer than that... > > > Sure. So you set the DF bit, and then start with honking big > > > packets, sending progressively smaller ones, until you get > > > a response. > > > > Generally the ICMP response tells you how big the maximum MTU is, so you > > don't have to guess. > > Maybe it's the ICMP response; I still haven't had a chance to > hold Michael down and drag the information out of him. 8-). Maybe what's the ICMP response? > [ ... ] > > > The two Product X boxes use TCP connections between each other, and happily > > negotiate a MSS of 8960 or so. They start sending data packets, but > > nothing gets through. > > > > How would product X detect this situation? Most switches I've seen don't > > send back ICMP packets to tell the sender to change his route MTU. They > > just drop the packets. In that situation, though, you can't tell the > > difference between the other end being down, the cable getting pulled, > > switch getting powered off or the MTU on the switch being too small. > > Cicso boxes detect "black hole" routes; I'd have to read the > white paper, rather than just its abstract, to tell you how, > though... It depends on what they're trying to do with the information. If they're just trying to route around a problem, that's one thing. If they're trying to diagnose MTU problems, that's quite another. In general, it's going to be pretty easy for routers to detect when a packet exceeds the MTU for one of their interfaces and send back a ICMP packet. > > It's a lot easier to just have the user configure the MTU. > > Not for the user. Configuring the MTU is a standard part of configuring IP networks. If your users aren't smart enough to do it, you'll pretty much have to default to 1500 bytes for ethernet. You can let the more clueful users increase the MTU. If you're supplying enough of the equipment, you can make some assumptions about the equipment setup. This was the case with my former employer -- in many cases we supplied the switch as well as the machines to go onto the network, so we knew ahead of time that jumbo frames would work. Otherwise, we'd work with the customer to set things up with standard or jumbo frames depending on their network architecture. > Maybe making gigabit cards not need twisty cables to wire them > together has just set expectations too high... 8-). Well, they do use twisty cables, but that's hidden inside a sheath. :) > > So, what if you did try to back off and retransmit at progressively smaller > > sizes? That won't work in all cases. If you're the receiver, and the > > sender isn't one of your boxes, you have no way of knowing whether the > > sender is down or what, and you have no way of guessing that his problem is > > that the switch doesn't support the large MSS you've negotiated. There's > > also no way for you to back off, since you're not the one transmitting the > > data, and your acks get through just fine. > > It's ugly, but possible. You can alway detect this by dicking > with the hop count, etc.. As I said above, if you're the receiver, you don't know there is a problem, because your acks get back just fine. > Actually, given gigabit speeds, you should be able to sink an > incredible amount of processing into it, and still get done > relatively quickly after the carrier goes on. At least on the receiving end, processing doesn't have a lot to do with it. > In any case, Intel cards appear to do it, and so do Tigon III's. That's nice, but there's no reason a card has to accept packets with a higher MTU than it is configured for. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Oct 15 2:41:40 2001 Delivered-To: freebsd-current@freebsd.org Received: from oahu.WURLDLINK.NET (oahu.WURLDLINK.NET [216.235.52.1]) by hub.freebsd.org (Postfix) with ESMTP id 143A837B401 for ; Mon, 15 Oct 2001 02:41:37 -0700 (PDT) Received: from localhost (vince@localhost) by oahu.WURLDLINK.NET (8.11.3/8.11.3) with ESMTP id f9F9fPO16567 for ; Sun, 14 Oct 2001 23:41:26 -1000 (HST) (envelope-from vince@oahu.WURLDLINK.NET) Date: Sun, 14 Oct 2001 23:41:25 -1000 (HST) From: Vincent Poy To: current@FreeBSD.ORG Subject: latest -current buildworld fails Message-ID: <20011014233910.T16499-100000@oahu.WURLDLINK.NET> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG cd /usr/src/kerberos5/lib/libasn1; make build-tools cc -O -pipe -I/usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/include -I/usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I/usr/src/kerberos5/lib/libasn1/../../include -I/usr/obj/usr/src/kerberos5/lib/libasn1 -Wall -I/usr/src/kerberos5/lib/libasn1/../../include -I/usr/src/kerberos5/lib/libasn1/../../include -DHAVE_CONFIG_H -DKRB5_KRB4_COMPAT -DKRB4 -DINET6 -I/usr/include -static -o make-print-version /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/vers/make-print-version.c yacc -d /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/parse.y yacc -d /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/parse.y awk -f /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken/roken.awk /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken/roken.h.in > make-roken.c mv y.tab.c parse.c mv y.tab.h parse.h mv y.tab.c parse.c mv y.tab.h parse.h mv: y.tab.h: No such file or directory cc -O -pipe -I/usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/include -I/usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I/usr/src/kerberos5/lib/libasn1/../../include -I/usr/obj/usr/src/kerberos5/lib/libasn1 -Wall -I/usr/src/kerberos5/lib/libasn1/../../include -I/usr/src/kerberos5/lib/libasn1/../../include -DHAVE_CONFIG_H -DKRB5_KRB4_COMPAT -DKRB4 -DINET6 -I/usr/include make-roken.c -o make-roken *** Error code 1 ./make-print-version print_version.h 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error root@pele [11:22pm][/usr/src] >> Cheers, Vince - vince@WURLDLINK.NET - Vice President ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Oct 15 3: 3:23 2001 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 487F837B403; Mon, 15 Oct 2001 03:03:18 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id B7CB314C3F; Mon, 15 Oct 2001 12:03:16 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: current@freebsd.org Cc: cg@freebsd.org, msmith@freebsd.org Subject: Audio stopped working on TP600E, possible ACPI casualty? From: Dag-Erling Smorgrav Date: 15 Oct 2001 12:03:16 +0200 Message-ID: Lines: 75 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The pcm driver in -CURRENT no longer attaches to the audio hardware in my ThinkPad 600E. It identifies the chip as a CS461x, and fails to attach: des@aes ~% dmesg | egrep '(csa|pcm)' csa0: mem 0x50000000-0x500fffff,0x50100000-0x50100fff irq 9 at device 6.0 on pci0 csa: card is Unknown/invalid SSID (CS4610) pcm0: on csa0 pcm0: ac97 codec invalid or not present (id == 0) device_probe_and_attach: pcm0 attach returned 6 but it used to identify it as a CS423x, and attach properly: pcm0: at port 0x530-0x537,0x388-0x38b,0x220-0x233 irq 5 drq 1,0 on isa0 Here's what pciconf says: root@aes /usr/home/des# pciconf -lv hostb0@pci0:0:0: class=0x060000 card=0x00000000 chip=0x71908086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82443BX/ZX 440BX/ZX AGPset Host Bridge' class = bridge subclass = HOST-PCI pcib1@pci0:1:0: class=0x060400 card=0x00000000 chip=0x71918086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82443BX/ZX 440BX/ZX AGPset PCI-to-PCI bridge' class = bridge subclass = PCI-PCI pccbb0@pci0:2:0: class=0x060700 card=0x00eb1014 chip=0xac1d104c rev=0x00 hdr=0x02 vendor = 'Texas Instruments' device = 'PCI1251 PC card Cardbus Controller' class = bridge subclass = PCI-CardBus pccbb1@pci0:2:1: class=0x060700 card=0x00eb1014 chip=0xac1d104c rev=0x00 hdr=0x02 vendor = 'Texas Instruments' device = 'PCI1251 PC card Cardbus Controller' class = bridge subclass = PCI-CardBus csa0@pci0:6:0: class=0x040100 card=0x10101014 chip=0x60011013 rev=0x01 hdr=0x00 vendor = 'Cirrus Logic' device = 'CS4610 CrystalClear SoundFusion PCI Audio Accel' class = multimedia subclass = audio isab0@pci0:7:0: class=0x068000 card=0x00000000 chip=0x71108086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82371AB PIIX4 ISA Bridge' class = bridge subclass = PCI-unknown atapci0@pci0:7:1: class=0x010180 card=0x00000000 chip=0x71118086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82371AB PIIX4 IDE Controller' class = mass storage subclass = ATA uhci0@pci0:7:2: class=0x0c0300 card=0x00000000 chip=0x71128086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82371AB PIIX4 USB Interface' class = serial bus subclass = USB none0@pci0:7:3: class=0x068000 card=0x00000000 chip=0x71138086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82371AB PIIX4 Power Management Controller' class = bridge subclass = PCI-unknown none1@pci1:0:0: class=0x030000 card=0x00dd1014 chip=0x000510c8 rev=0x12 hdr=0x00 vendor = 'Neomagic Corporation' device = 'NM2200 MagicMedia 256AV' class = display subclass = VGA I suspect the change occurred with the switch to ACPI, but I'll spare you the 9,400 lines of acpidump output unless you really want them :) DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Oct 15 4:45:15 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 3198D37B401; Mon, 15 Oct 2001 04:45:06 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA25299; Mon, 15 Oct 2001 21:44:57 +1000 Date: Mon, 15 Oct 2001 21:43:55 +1000 (EST) From: Bruce Evans X-X-Sender: To: Cc: , , Subject: coredump() broken for nfs filesystems Message-ID: <20011015211333.B576-100000@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG coredump() now usually creates empty core files for nfs filesystems. This seems to be caused by the changes in rev.1.132 (-current) and rev.1.72.2.9 (RELENG_4), and braindamage in nfs_dolock(): Index: kern_sig.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_sig.c,v retrieving revision 1.131 retrieving revision 1.132 diff -u -2 -r1.131 -r1.132 --- kern_sig.c 6 Sep 2001 22:20:41 -0000 1.131 +++ kern_sig.c 8 Sep 2001 20:02:32 -0000 1.132 > ... @@ -1896,6 +1898,17 @@ NDFREE(&nd, NDF_ONLY_PNBUF); vp = nd.ni_vp; + + VOP_UNLOCK(vp, 0, p); + lf.l_whence = SEEK_SET; + lf.l_start = 0; + lf.l_len = 0; + lf.l_type = F_WRLCK; + error = VOP_ADVLOCK(vp, (caddr_t)p, F_SETLK, &lf, F_FLOCK); + if (error) + goto out2; + This usually goes to out2 with error EOPNOTSUPP if the core file is on an nfs filesystem. From nfs_dolock(): % /* % * XXX Hack to temporarily allow this process (regardless of it's creds) % * to open the fifo we need to write to. vn_open() really should % * take a ucred (and once it does, this code should be fixed to use % * proc0's ucred. % */ % saved_uid = p->p_ucred->cr_uid; % p->p_ucred->cr_uid = 0; /* temporarly run the vn_open as root */ % % fmode = FFLAGS(O_WRONLY); % error = vn_open(&nd, &fmode, 0); This vn_open() usually fails, because root is usually mapped so has even less write permission than most users. I don't see how nfs write locks can work for syscalls either. % p->p_ucred->cr_uid = saved_uid; % if (error != 0) { % return (error == ENOENT ? EOPNOTSUPP : error); % } EOPNOTSUPP is a strange error for foot shooting. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Oct 15 9:15: 8 2001 Delivered-To: freebsd-current@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id EF0D237B411; Mon, 15 Oct 2001 09:15:01 -0700 (PDT) Received: (from dillon@localhost) by earth.backplane.com (8.11.6/8.11.2) id f9FGEwB55018; Mon, 15 Oct 2001 09:14:58 -0700 (PDT) (envelope-from dillon) Date: Mon, 15 Oct 2001 09:14:58 -0700 (PDT) From: Matt Dillon Message-Id: <200110151614.f9FGEwB55018@earth.backplane.com> To: Bruce Evans Cc: , , Subject: Re: coredump() broken for nfs filesystems References: <20011015211333.B576-100000@delplex.bde.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :coredump() now usually creates empty core files for nfs filesystems. :This seems to be caused by the changes in rev.1.132 (-current) and :rev.1.72.2.9 (RELENG_4), and braindamage in nfs_dolock(): I think if we change it to an flock() equivalent it should work. I'll play with it. -Matt :Index: kern_sig.c :=================================================================== :RCS file: /home/ncvs/src/sys/kern/kern_sig.c,v :retrieving revision 1.131 :retrieving revision 1.132 :diff -u -2 -r1.131 -r1.132 :--- kern_sig.c 6 Sep 2001 22:20:41 -0000 1.131 :+++ kern_sig.c 8 Sep 2001 20:02:32 -0000 1.132 :> ... :@@ -1896,6 +1898,17 @@ : NDFREE(&nd, NDF_ONLY_PNBUF); : vp = nd.ni_vp; :+ :+ VOP_UNLOCK(vp, 0, p); :+ lf.l_whence = SEEK_SET; :+ lf.l_start = 0; :+ lf.l_len = 0; :+ lf.l_type = F_WRLCK; :+ error = VOP_ADVLOCK(vp, (caddr_t)p, F_SETLK, &lf, F_FLOCK); :+ if (error) :+ goto out2; :+ : :This usually goes to out2 with error EOPNOTSUPP if the core file is on :an nfs filesystem. : :... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Oct 15 9:53:29 2001 Delivered-To: freebsd-current@freebsd.org Received: from bgmail4.impsat.net.co (bgmail4.impsat.net.co [200.31.19.6]) by hub.freebsd.org (Postfix) with ESMTP id EC95E37B408 for ; Mon, 15 Oct 2001 09:53:17 -0700 (PDT) Received: from [206.114.11.102] (helo=oemcomputer) by bgmail4.impsat.net.co with smtp (Exim 3.16 #1) id 15tAFn-0003mJ-00 for freebsd-current@freebsd.org; Mon, 15 Oct 2001 11:06:12 -0500 Reply-To: From: " Rueda" To: Subject: =?iso-8859-1?Q?M=E1s_de_15.000_Empresas_a_su_disposici=F3n?= Date: Mon, 15 Oct 2001 11:04:15 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mensaje enviado por rueda@elsitio.net.co Empres@s - Colombia Potente Herramienta para Mercadeo y Ventas. Encuentre los clientes que usted necesita, con un simple click en nuestra base de datos de más de 15Mil Empresas Importantes de Colombia, con más de 70.000 directivos y ejecutivos. La Base de Datos y la Aplicación le permiten localizar y calificar sus mejores prospectos, aprender más sobre sus clientes, proveedores y competidores y crear eficientes campañas de correo, teléfono, e-mail, fax y campañas de campo. La Base de Datos de Empresas (más de 15Mil) maneja los siguientes campos: Razón Social, sigla, Nit, dirección, teléfono, fax, actividad empresarial (código CIIU Rev. 3.0), número de empleados, ciudad y departamento. La Base de Datos de directivos y ejecutivos (más de 70Mil) maneja los siguientes campos: nombre, cargo, area por cargos, dirección, teléfono, fax. Estas bases de datos se encuentran relacionadas, de tal forma que la aplicación hace búsquedas simples o complejas por todos estos campos, agrupa diferentes tipos de búsquedas, prepara e imprime reportes, rótulos y cartas, hace llamadas telefónicas y envía email´s. COMO VALOR AGREGADO le damos acceso a toda la información sobre COMERCIO EXTERIOR, a través de enlaces Vía Internet a las Bases de Datos de MINCOMEX (27000 Importadores), PROEXPO (4.000 Exportadores y sus ejecutivos), Y LA COMUNIDAD ANDINA. También le facilitamos la conexión a sus propios enlaces. Solicite información adicional vía email sobre contenido de la base de datos, fuentes de la información, actualización, funciones que permite ejecutar la aplicación, versiones, precios y empresas que la estan utilizando, o enviando los siguientes datos al Fax 6178102 - 6179073 Bogotá – Colombia o llamando directamente a Florentino Rueda, gerente comercial al Cel. 033-3396180 Empresa Nit Ciudad Dirección Teléfono Fax Nombre Cargo P.D. Si este mensaje no es de su interés, considere dirigirlo a la Gerencia General y/o Mercadeo, si no desea recibir mensajes como este, por favor déjenos saberlo a rueda@elsitio.net.co para eliminar su dirección en nuestra base de datos. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Oct 15 11:35:25 2001 Delivered-To: freebsd-current@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 6983F37B407 for ; Mon, 15 Oct 2001 11:35:15 -0700 (PDT) Received: from mindspring.com (dialup-209.245.128.127.Dial1.SanJose1.Level3.net [209.245.128.127]) by pintail.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id LAA00345; Mon, 15 Oct 2001 11:35:00 -0700 (PDT) Message-ID: <3BCB2C87.BEF543A0@mindspring.com> Date: Mon, 15 Oct 2001 11:35:51 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kenneth D. Merry" Cc: current@FreeBSD.ORG Subject: Re: Why do soft interrupt coelescing? References: <3BBF5E49.65AF9D8E@mindspring.com> <20011006144418.A6779@panzer.kdm.org> <3BC00ABC.20ECAAD8@mindspring.com> <20011008231046.A10472@panzer.kdm.org> <3BC34FC2.6AF8C872@mindspring.com> <20011010000604.A19388@panzer.kdm.org> <3BC40E04.D89ECB05@mindspring.com> <20011010232020.A27019@panzer.kdm.org> <3BC55201.EC273414@mindspring.com> <20011015002407.A59917@panzer.kdm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Kenneth D. Merry" wrote: > Dropping packets before they get into card memory would only be possible > with some sort of traffic shaper/dropping mechanism on the wire to drop > things before they get to the card at all. Actually, DEC had a congestion control mechanism that worked by marking all packets, over a certainl level of congestion (this was sometimes called the "DECbits" approach). You can do the same thing with any intermediate hop router, so long as it is better at moving packets than your destination host. It turns out that even if the intermediate hop and the host at the destination are running the same hardware and OS, the cost is going to be higher to do the terminal processing than it is to do the network processing, so you are able to use the tagging to indicate to the terminal hop which flows to drop packets out of before processing. Cisco routers can do this (using the CMU firmware) on a per flow basis, leaving policy up to the end node. Very neat. [ ... per connection overhead, and overcommit ... ] > You could always just put 4G of RAM in the machine, since memory is so > cheap now. :) > > At some point you'll hit a limit in the number of connections the processor > can actually handle. In practice, particularly for HTTP or FTP flows, you can halve the amount of memory expected to be used. This is because the vast majority of the data is generally pushed in only one direction. For HTTP 1.1 persistant connections, you can, for the most part, also assume that the connections are bursty -- that is, that there is a human attached to the other end, who will spend some time examining the content before making another request (you can assume the same thing for 1.0, but that doesn't count against persistant connection count, unless you also include time spent in TIME_WAIT). So overcommit turns out to be O.K. -- which is what I was trying to say in a back-handed way, in the last post. If you include window control (i.e. you care about overall throughput, and not about individual connections), then you can safely service 1,000,000 connections with 4G on a FreeBSD box. > > This is actually very bad: you want to drop packets before you > > insert them into the queue, rather than after they are in the > > queue. This is because you want the probability of the drop > > (assuming the queue is not maxed out: otherwise, the probabilty > > should be 100%) to be proportional to the exponential moving > > average of the queue depth, after that depth exceeds a drop > > threshold. In other words, you want to use RED. > > Which queue? The packets are dropped before they get to ether_input(). The easy answer is "any queue", since what you are becoming concerned with is pool retention time: you want to throw away packets before a queue overflow condition makes it so you are getting more than you can actually process. > Dropping random packets would be difficult. The "R" in "RED" is "Random" for "Random Early Detection" (or "Random Early Drop", for a minority of the literature), true. But the randomness involved is whether you drop vs. insert a given packet, not whether you drop a random packet from the queue contents. Really dropping random queue elements would be incredibly bad. The problem is that, during an attack, the number of packets you get is proportionally huge, compared to the non-attack packets (the ones you want to let through). A RED approach will prevent new packets being enqueued: it protects the host system's ability to continue degraded processing, by making the link appear "lossy" -- the closer to queue full, the more lossy the link. If you were to drop random packets already in the queue, then the proportional probability of dumping good packets is equal to the queue depth times the number of bad packets divided by the number of total packets. In other words, a continuous attack will almost certainly push all good packets out of the queue before they reach the head. Dropping packets prior to insertion maintains the ratio of bad and good packets, so it doesn't inflate the danger to the good packets by the relative queue depth: thus dropping before insertion is a significantly better strategy than dropping after insertion, for any queue depth over 1. > > Maybe I'm being harsh in calling it "spam'ming". It does the > > wrong thing, by dropping the oldest unprocessed packets first. > > A FIFO drop is absolutely the wrong thing to do in an attack > > or overload case, when you want to shed load. I consider the > > packet that is being dropped to have been "spam'med" by the > > card replacing it with another packet, rather than dropping > > the replacement packet instead. > > > > The real place for this drop is "before it gets to card memory", > > not "after it is in host memory"; Floyd, Jacobsen, Mogul, etc., > > all agree on that. > > As I mentioned above, how would you do that without some sort of traffic > shaper on the wire? The easiest answer is to RED queue in the card firmware. > My focus with gigabit ethernet was to get maximal throughput out of a small > number of connections. Dealing with a large number of connections is a > different problem, and I'm sure it uncovers lots of nifty bugs. 8-). I guess that you are more interested in intermediate hops and site to site VPN, while I'm more interested in connection termination (big servers, SSL termination, and single client VPN). > > I'd actually prefer to avoid the other DMA; I'd also like > > to avoid the packet receipt order change that results from > > DMA'ing over the previous contents, in the case that an mbuf > > can't be allocated. I'd rather just let good packets in with > > a low (but non-zero) statistical probability, relative to a > > slew of bad packets, rather than letting a lot of bad packets > > from a persistant attacker push my good data out with the bad. > > Easier said than done -- dumping random packets would be difficult with a > ring-based structure. Probably what you'd have to do is have an extra pool > of mbufs lying around that would get thrown in at random times when mbufs > run out to allow some packets to get through. > > The problem is, once you exhaust that pool, you're back to the same old > problem if you're completely out of mbufs. > > You could probably also start shrinking the number of buffers in the ring, > but as I said before, you'd need a method for the kernel to notify the > driver that more mbufs are available. You'd be better off shrinking the window size across all the connections, I think. As to difficult to do, I actually have RED queue code, which I adapted from the formula in a paper. I have no problem giving that code out. The real issue is that the BSD queue macros involved in the queues really need to be modified to include an "elements on queue" count for the calculation of the moving average. > > If you are sharing interrupts at this network load, then > > you are doing the wrong thing in your system setup. If > > you don't have such a high load, then it's not a problem; > > either way, you can avoid the problem, for the most part. > > It's easier with a SMP system (i.e. you've got an APIC.) Virtual wire mode is actually bad. It's better to do asymmetric interrupt handling, if you have a number of identical or even similar interrupt sources (e.g. two gigabit cards in a box). > > OK, I will rediff and generate context diffs; expect them to > > be sent in 24 hours or so from now. > > It's been longer than that... Sorry; I've been doing a lot this weekend. I will redo them at work today, and resend them tonight... definitely. > > > Generally the ICMP response tells you how big the maximum MTU is, so you > > > don't have to guess. > > > > Maybe it's the ICMP response; I still haven't had a chance to > > hold Michael down and drag the information out of him. 8-). > > Maybe what's the ICMP response? The difference between working and not working. > > Cicso boxes detect "black hole" routes; I'd have to read the > > white paper, rather than just its abstract, to tell you how, > > though... > > It depends on what they're trying to do with the information. If they're > just trying to route around a problem, that's one thing. If they're trying > to diagnose MTU problems, that's quite another. > > In general, it's going to be pretty easy for routers to detect when a > packet exceeds the MTU for one of their interfaces and send back a ICMP > packet. A "black hole" route doesn't ICMP back, either because some idiot has blocked ICMP, or because it's just too dumb... > > Not for the user. > > Configuring the MTU is a standard part of configuring IP networks. > If your users aren't smart enough to do it, you'll pretty much have > to default to 1500 bytes for ethernet. Or figure out how to negotiate higher... > You can let the more clueful users increase the MTU. That doesn't improve performance, and so "default configuration" benchmarks like "Polygraph" really suffer, as a result. > If you're supplying enough of the equipment, you can make some assumptions > about the equipment setup. This was the case with my former employer -- in > many cases we supplied the switch as well as the machines to go onto the > network, so we knew ahead of time that jumbo frames would work. Otherwise, > we'd work with the customer to set things up with standard or jumbo frames > depending on their network architecture. This approach only works if you're Cisco or another big iron vendor, in an established niche. [ ... more on MTU negotiation for jumbograms ... ] > > In any case, Intel cards appear to do it, and so do Tigon III's. > > That's nice, but there's no reason a card has to accept packets with a > higher MTU than it is configured for. True, but then there's no reason I have to buy the cards that choose to not do this. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Oct 15 13:32:55 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.ezrx.com (mail.ezrx.com [216.62.99.36]) by hub.freebsd.org (Postfix) with SMTP id 4D28C37B407 for ; Mon, 15 Oct 2001 13:32:31 -0700 (PDT) Received: (qmail 11918 invoked from network); 15 Oct 2001 20:14:11 -0000 Received: from softdnserror (HELO home.kr.netscape.com) (216.25.167.77) by mail.ezrx.com with SMTP; 15 Oct 2001 20:14:11 -0000 Message-ID: <00001551515c$00004d3b$00004c6e@kdskor.co.kr> To: Cc: , , , , , , , , , , , , , , , From: ham@coksa.com Subject: 6 & 8 all night long 19566 Date: Mon, 15 Oct 2001 02:29:53 -0500 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG

=
Best Casino of Web offering a massive
40% Instant CASH Bonus !

Thats right folks, deposit $20.00 or more at
Best Casino of Web & get= 40% BONUS over it!

* MORE THAN 34 NEW EXCITING GAMES
* MULTIPL= AYER GAMES
* ONLINE CASHOUTS
* PERMANENT BONUSES

No maximums, so no matter= what amount you buy chips for YOU'LL GET IT! The bonus is credited ins= tantly so no waiting, just playing!
L= imited time offer Expires on Oct. 19
Coupon Code: JDPHA
This offer is available only at
http://www.b= estcasinoofweb.com
and no other web ad= dress

Bookmark now for future reference or call our Toll= Free number: 1-888-527-2982 to sign up now.

=



The more you play the better chance you have!
To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Oct 15 15:21:50 2001 Delivered-To: freebsd-current@freebsd.org Received: from femail30.sdc1.sfba.home.com (femail30.sdc1.sfba.home.com [24.254.60.20]) by hub.freebsd.org (Postfix) with ESMTP id 7D32B37B410 for ; Mon, 15 Oct 2001 15:21:48 -0700 (PDT) Received: from laptop.baldwin.cx ([24.2.39.156]) by femail30.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20011015222148.VIZR24280.femail30.sdc1.sfba.home.com@laptop.baldwin.cx>; Mon, 15 Oct 2001 15:21:48 -0700 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 15 Oct 2001 15:21:47 -0700 (PDT) From: John Baldwin To: Dag-Erling Smorgrav Subject: Re: Strike three, you're out Cc: freebsd-current@FreeBSD.ORG, Doug Barton , Sheldon Hearn Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 13-Oct-01 Dag-Erling Smorgrav wrote: > Sheldon Hearn writes: >> Perhaps the analogous solution is to be more careful about the use of >> printf() in the kernel? Perhaps a similar approach as is used in >> userland signal handlers should be taken, where a flag is set and later >> the printf() is performed conditional on the state of the flag? > > I think the correct approach would be for printf() to store the > printed text in a circular buffer if it detected that printing it > would cause a locking violation, and for some other part of the kernel > to check and empty the circular buffer regularly, in a safe context. Something like that, yes. Chuck Paterson has patches to do all this for our printf() if I can extract them. It basically ends up with 3 different versions of printf in the kernel. I'll see if I can't get ahold of them. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Oct 15 16: 6:44 2001 Delivered-To: freebsd-current@freebsd.org Received: from c001.snv.cp.net (c001-h010.c001.snv.cp.net [209.228.32.124]) by hub.freebsd.org (Postfix) with SMTP id 6099637B403 for ; Mon, 15 Oct 2001 16:06:37 -0700 (PDT) Received: (cpmta 10849 invoked from network); 15 Oct 2001 16:06:36 -0700 Date: 15 Oct 2001 16:06:36 -0700 Message-ID: <20011015230636.10848.cpmta@c001.snv.cp.net> X-Sent: 15 Oct 2001 23:06:36 GMT Received: from [212.116.158.140] by mail.l123.org with HTTP; 15 Oct 2001 16:06:36 PDT Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: current@freebsd.org From: ivan@l123.org X-Mailer: Web Mail 3.9.3.5 X-Sent-From: ivan@l123.org Subject: weird sysctl output Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG After playing with the nvidia kernel driver from http://nvidia.netexplorer.org/ I noticed the following in the output of sysctl -a (cutted a little bit because it was nearly 50 k) ----- SNIP ---- kern.devstat.generation: 1 kern.devstat.version: 4 kern.disks: ad0 kern.log_wakeups_per_second: 5 kern.msgbuf: 0 osMemCopyToUser 4 0x828de54 osMemCopyToUser 4 0x828de58 osMemCopyToUser 4 0x828de5c ----- SNIP ---- NV0: close osMemSet osMemSet NV: nv_release_resources kmem_free: ce634000 <6>pid 16140 (more), uid 0: exited on signal 11 (core dumped) <118>Oct 14 14:02:34 shtaiga /boot/kernel/kernel: pid 16140 (more), uid 0: exite d on signal 11 (core dumped) Control! nv_ctl_ioctl: addy 0828eab0 cmd c0044602 NV_IOCTL_CARD_INFO nv_ctl_ioctl: addy bfbffa3c cmd c0044622 ----- SNIP ---- osMemSet osMemSet NV: nv_release_resources kmem_free: ce634000 <6>pid 18172 (tput), uid 0: exited on signal 11 (core dumped) <118>Oct 14 19:27:01 shtaiga /boot/kernel/kernel: pid 18172 (tput), uid 0: exite d on signal 11 (core dumped) link_elf: symbol gd_curproc undefined kern.msgbuf_clear: 0 kern.nselcoll: 0 kern.drainwait: 300 kern.tty_nin: 344345 ---- and so on as you may suggest from the /boot/kernel/kernel lines this reproduces exactly the console (and /var/log/messages). After rebooting I explicitly tried to achieve the same result but was unlucky. the cause MIGHT be that I accidently ran a small program with the following typo in it while playing with this stuff test = sysctl(fd, VNIOCGSET, allocated); instead of test = ioctl(fd, VNIOCGSET, allocated); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Oct 15 20:54:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail-relay1.yahoo.com (mail-relay1.yahoo.com [216.145.48.34]) by hub.freebsd.org (Postfix) with ESMTP id D04FD37B412 for ; Mon, 15 Oct 2001 20:54:13 -0700 (PDT) Received: from DougBarton.net (db-cvad-2-tmp.yahoo.com [216.145.48.243]) by mail-relay1.yahoo.com (Postfix) with ESMTP id 687128B5A6; Mon, 15 Oct 2001 20:54:12 -0700 (PDT) Message-ID: <3BCBAF7E.F27B67C0@DougBarton.net> Date: Mon, 15 Oct 2001 20:54:38 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Riccardo Torrini Cc: freebsd-current@FreeBSD.ORG, esperti@gufi.org Subject: Re: New features for -current References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Riccardo Torrini wrote: > > Over than an year ago (9.9.2000) I submitted a pr (kern/21154) > to ask renaming from actual *_saver.ko to saver_*.ko of saver > modules to uniform names under /boot/kernel as sound (snd_*), > interfaces (if_*), splash (splash_*) and netgraph (ng_*). Thanks for the reminder, I just closed that PR. :) This change would cause a lot of uphevel, a lot of source duplication in the cvs repository, and wouldn't provide any clear benefit, other than making ls(1) a little more orderly in the modules directory. Things work fine the way they are, so changing this isn't worth what it would cost. > Another question: I noticed good support for USB peripherals > like scanner, mp3 player (rio) mouse and ethernet but nothing > to use a photo camera (yes, I buy an inexpensive usb digital > photo camera, Agfa ePhoto-CL18) and I try to compile gphoto > because it recently added support for CL-18 (w/out success). Nothing gets done around here unless someone who cares does it... someone else already explained why doing this in userland would be a better way to handle it, good luck. :) -- "We will not tire, we will not falter, and we will not fail." - George W. Bush, President of the United States September 20, 2001 Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Oct 16 2:46: 1 2001 Delivered-To: freebsd-current@freebsd.org Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by hub.freebsd.org (Postfix) with ESMTP id 50C0D37B407 for ; Tue, 16 Oct 2001 02:45:45 -0700 (PDT) Received: by teletubbie.het.net.je (Postfix, from userid 500) id D1CFD1B251; Tue, 16 Oct 2001 11:45:43 +0200 (CEST) To: current@freebsd.org Subject: pcmcia cdrom/irq sharing problem? Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline X-Mutt-Fcc: =current Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, I've just upgraded my system to today's -CURRENT (I was running a -CURRENT from April 2001). Although I encountered some problems, the UPDATING file got me through (I love the way FreeBSD documents stuff) and my system is running fine (background fsck, great!) except for my PCMCIA CDROM player. I have a Sony VAIO Z600 laptop by the way. I was hoping somebody can point me in the right direction (searching the web/mailinglist archives didn't help). My CDROM player was always correctly identified with my previous install as NinjaATA on irq 3 (slot 0 on pccard0). After the upgrade, it is recognised, but assigned irq 9 (which is not in pccard.conf) after which the system hangs until the card is removed. This irq is (and was) shared with fxp0, pcm0. I've turned off PnP in the BIOS to no avail. I've tried a NEWCARD kernel, which does not even recognise the card. My PCMCIA wireless card works fine (also on irq 9). Attached are kernel messages when inserting the card (with the april 2001 -CURRENT, today's -CURRENT with oldcard and today's -CURRENT with newcard), dmesg output and kernel config file. Regards, Walter. -- Walter Belgers "Si hoc signum legere potes, operis boni in rebus walter@belgers.com Latinis alacribus et fructuosis potiri potes!" --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=cdrommsgs_april_oldcard kernel messages with April 2001 kernel Sep 19 20:18:32 bwerk /boot/kernel/kernel: pccard: card inserted, slot 0 Sep 19 20:18:31 bwerk pccardd[178]: Card " "("NinjaATA-") [V1.0] [AP00 ] matched " " ("NinjaATA-") [(null)] [(null)] Sep 19 20:18:37 bwerk /boot/kernel/kernel: ata4 at port 0x180-0x187,0x386 iomem 0xd4000-0xd4fff irq 3 slot 0 on pccard0 Sep 19 20:18:37 bwerk /boot/kernel/kernel: ata4-slave: identify retries exceeded Sep 19 20:18:37 bwerk /boot/kernel/kernel: acd0: CDROM at ata4-master BIOSPIO Sep 19 20:18:37 bwerk pccardd[178]: ata4: NinjaATA inserted. --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=cdrommsgs_today_newcard Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb0: card inserted: event=0x00000000, state=30000510 Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccard0: chip_socket_enable Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb_pcic_socket_enable: Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb0: pccbb_power: CARD_VCC_0V and CARD_VPP_0V [44] Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb0: pccbb_power: CARD_VCC_5V and CARD_VPP_VCC [15] Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb0: pccbb_pcic_wait_ready: status 0x7f Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb0: card type is mem Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccard0: read_cis Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb_pcic_mem_map window 0 bus 10001000+400+effff000 card addr 0 Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb_pcic_do_mem_map window 0: 8001 8001 3fff 10 (10001000+00000400.00001000*effff000) Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb_pcic_do_mem_map window 0: 8001 8001 7fff 10 (10001000+00000400.00001000*effff000) Oct 16 10:59:37 bwerk /boot/kernel/kernel: cis mem map c8569000 Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccard0: CIS tuple chain: Oct 16 10:59:37 bwerk /boot/kernel/kernel: CISTPL_DEVICE type=funcspec speed=100ns Oct 16 10:59:37 bwerk /boot/kernel/kernel: 01 03 dc 00 ff Oct 16 10:59:37 bwerk /boot/kernel/kernel: CISTPL_VERS_1 Oct 16 10:59:37 bwerk /boot/kernel/kernel: 15 1a 04 01 20 00 4e 69 6e 6a 61 41 54 41 2d 00 Oct 16 10:59:37 bwerk /boot/kernel/kernel: 56 31 2e 30 00 41 50 30 30 20 00 ff Oct 16 10:59:37 bwerk /boot/kernel/kernel: CISTPL_CONFIG Oct 16 10:59:37 bwerk /boot/kernel/kernel: 1a 05 01 23 00 02 03 Oct 16 10:59:37 bwerk /boot/kernel/kernel: CISTPL_CFTABLE_ENTRY Oct 16 10:59:37 bwerk /boot/kernel/kernel: 1b 15 e1 01 3d 11 55 1e fc 23 f0 61 80 01 07 86 Oct 16 10:59:37 bwerk /boot/kernel/kernel: 03 01 30 68 d0 10 00 Oct 16 10:59:37 bwerk /boot/kernel/kernel: CISTPL_CFTABLE_ENTRY Oct 16 10:59:37 bwerk /boot/kernel/kernel: 1b 0f 22 38 f0 61 90 01 07 96 03 01 30 68 d0 10 Oct 16 10:59:37 bwerk /boot/kernel/kernel: 00 Oct 16 10:59:37 bwerk /boot/kernel/kernel: CISTPL_CFTABLE_ENTRY Oct 16 10:59:37 bwerk /boot/kernel/kernel: 1b 0f 23 38 f0 61 a0 01 07 a6 03 01 30 68 d0 10 Oct 16 10:59:38 bwerk /boot/kernel/kernel: 00 Oct 16 10:59:38 bwerk /boot/kernel/kernel: CISTPL_NO_LINK Oct 16 10:59:38 bwerk /boot/kernel/kernel: 14 00 Oct 16 10:59:38 bwerk /boot/kernel/kernel: CISTPL_END Oct 16 10:59:38 bwerk /boot/kernel/kernel: ff Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: check_cis_quirks Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: CIS version PCCARD 2.0 or 2.1 Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: CIS info: , NinjaATA-, V1.0, AP00 Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: Manufacturer code 0xffffffff, product 0xffffffff Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: function 0: unspecified, ccr addr 200 mask 3 Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: function 0, config table entry 33: I/O card; irq mask d068; iomask 10, iospace 180-187 386-387; memspace 0-fff; rdybsy_active wp_active bvd_active io8 io16 irqlevel Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: function 0, config table entry 34: I/O card; irq mask d068; iomask 10, iospace 190-197 396-397; memspace 0-fff; rdybsy_active wp_active bvd_active io8 io16 irqlevel Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: function 0, config table entry 35: I/O card; irq mask d068; iomask 10, iospace 1a0-1a7 3a6-3a7; memspace 0-fff; rdybsy_active wp_active bvd_active io8 io16 irqlevel Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: functions scanning Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccbb_pcic_socket_enable: Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccbb0: pccbb_power: CARD_VCC_0V and CARD_VPP_0V [44] Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccbb0: pccbb_power: CARD_VCC_5V and CARD_VPP_VCC [15] Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccbb0: pccbb_pcic_wait_ready: status 0x7f Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccbb0: card type is io Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccbb_pcic_mem_map window 0 bus 10001000+400+effff000 card addr 0 Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccbb_pcic_do_mem_map window 0: 8001 8001 3fff 10 (10001000+00000400.00001000*effff000) Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: ccr_res == 10001000-100013ff, base=200 Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccbb_pcic_do_mem_map window 0: 8001 8001 7fff 10 (10001000+00000400.00001000*effff000) Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccbb_pcic_do_mem_map window 0: 8001 8001 7fff 10 (10001000+00000400.00001000*effff000) Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: function 0 CCR at 0 offset 200: 61 0 ff ff, ff ff ff ff, ff Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccbb_pcic_socket_disable Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccbb0: pccbb_power: CARD_VCC_0V and CARD_VPP_0V [44] --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=cdrommsgs_today_oldcard kernel messages with latest -CURRENT, classic pcmcia kernel INSERTING Oct 14 15:44:35 bwerk /boot/kernel/kernel: pccard: card inserted, slot 0 Oct 14 15:44:40 bwerk pccardd[182]: Card " "("NinjaATA-") [V1.0] [AP00 ] matched " " ("NinjaATA-") [(null)] [(null)] Oct 14 15:44:45 bwerk /boot/kernel/kernel: ata4 at port 0x180-0x187,0x386 iomem 0xd4000-0xd4fff irq 9 slot 0 on pccard0 -system hangs- REMOVING Oct 14 15:45:18 bwerk /boot/kernel/kernel: ata4-slave: no status, reselecting device Oct 14 15:45:18 bwerk /boot/kernel/kernel: ata4-slave: no status, reselecting device Oct 14 15:45:18 bwerk /boot/kernel/kernel: ata4-slave: timeout waiting to give command=a1 s=ff e=04 Oct 14 15:45:18 bwerk /boot/kernel/kernel: ata4-slave: ATAPI identify failed Oct 14 15:45:18 bwerk /boot/kernel/kernel: ata4-master: no status, reselecting device Oct 14 15:45:18 bwerk /boot/kernel/kernel: ata4-master: timeout waiting to givecommand=a1 s=ff e=04 Oct 14 15:45:18 bwerk /boot/kernel/kernel: ata4-master: ATAPI identify failed Oct 14 15:45:18 bwerk /boot/kernel/kernel: pccard: delete of ata4 failed: 6 Oct 14 15:45:18 bwerk /boot/kernel/kernel: pccard: card removed, slot 0 Oct 14 15:45:17 bwerk pccardd[182]: ata4: NinjaATA inserted. Oct 14 15:45:18 bwerk pccardd[182]: ata4: NinjaATA removed. --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=dmesg Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #3: Tue Oct 16 10:28:16 CEST 2001 walter@bwerk.giga.nl:/usr/obj/usr/src/sys/BWERK Timecounter "i8254" frequency 1193160 Hz CPU: Pentium III/Pentium III Xeon/Celeron (496.30-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Features=0x383f9ff real memory = 134152192 (131008K bytes) avail memory = 125673472 (122728K bytes) Preloaded elf kernel "/boot/kernel/kernel" at 0xc04c3000. Preloaded elf module "/boot/kernel/splash_bmp.ko" at 0xc04c30a8. Preloaded splash_image_data "/boot/splash_matrix.bmp" at 0xc04c3158. Pentium Pro MTRR support enabled VESA: v2.0, 2496k memory, flags:0x0, mode table:0xc03777a2 (1000022) VESA: MagicMedia 256AV 48K Using $PIR table, 8 entries at 0xc00fdf40 apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xfc90-0xfc9f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xfca0-0xfcbf irq 9 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) pci0: at device 8.0 (no driver attached) pcm0: port 0xfc8c-0xfc8f,0xfcc0-0xfcff mem 0xfedf8000-0xfedfffff irq 9 at device 9.0 on pci0 fxp0: port 0xfc40-0xfc7f mem 0xfec00000-0xfecfffff,0xfedf6000-0xfedf6fff irq 9 at device 11.0 on pci0 fxp0: Ethernet address 08:00:46:06:84:f2 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci_cfgintr_linked: linked (61) to hard-routed irq 9 pci_cfgintr: 0:12 INTA routed to irq 9 pcic0: irq 9 at device 12.0 on pci0 pcic0: PCI Memory allocated: 0x44000000 pccard0: on pcic0 pci0: at device 13.0 (no driver attached) orm0: =20 Instantly Get a Brand New AAA Credit Profile in 24 = Hours!
Here's How You Can = Have a Brand New
Credit Profile in 24 = Hours!
The Best Part is... It's 100% Legal, 100% Ethical, and Fully = GUARANTEED!
Dear Friend,

Do you have bad = credit, judgements, bankruptcies or
any other = credit problems? Does it seem like your bad
credit is = holding you back from qualifying for a major
credit card, = car loan, or even a department store card?

Are you sick of = the embarrassment of being rejected at
your attempts = to get any credit at all? If so... I've got
some extremely = good news for you.

I = Will Show You Precisely How to Get a New, Separate, = Clean
Credit File... and it will be Clear of Any Past Credit = History!

And it's 100% LEGAL!

  • It = doesn't matter, if you have judgements!
  • It = doesn't matter, if you've filed for = bankruptcy!
  • It = doesn't matter, if you've been = foreclosed!
  • It = doesn't matter, if you have a tax lien!
  • It = doesn't matter, if have been a slow payer in the past!
It Doesn't Matter, Because Your Credit File Will Be = Completely
New And Completely Independent Of Any Negative Past = File!

With my = kit...within the next 60 days, you will quickly and = easily

  • Get ALL Major Credit = Cards
  • Learn Basic and = Advanced Credit Billing Techniques
  • Get Bank Loans FAST = and Simple
  • Get Mortgages = NOW
  • Have AAA Credit on = "Your Brand New File" in 30-60 Days
  • Get INSTANT Credit = From Real Department Stores
  • Car Loans FAST and = SIMPLE

    • And much, much = more!
     
     

    CLICK HERE TO LEARN MORE!

    This email was sent to = you by Coconut Bay Marketing Services in full compliance with all = existing and proposed email legislation.
    You may automatically remove yourself from = any future mailings by clicking here. The reply address on this = email was active
    at the time this email was sent. Coconut Bay = Marketing Services, SJO3016 PO Box 025216, Miami, FL = 33102
------=_NextPart_061247626454081008884444-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Oct 20 11:10:27 2001 Delivered-To: freebsd-current@freebsd.org Received: from EnContacto.Net (adsl-64-173-182-158.dsl.mtry01.pacbell.net [64.173.182.158]) by hub.freebsd.org (Postfix) with ESMTP id B062037B40A for ; Sat, 20 Oct 2001 11:10:22 -0700 (PDT) Received: (from root@localhost) by EnContacto.Net (8.11.6/8.11.4) id f9KIAML21227 for current@FreeBSD.ORG; Sat, 20 Oct 2001 11:10:22 -0700 (PDT) (envelope-from eculp@EnContacto.Net) Received: from 24.20.19.75 ( [24.20.19.75]) as user eculp@SavvyWorld.Net by Mail.SavvyWorld.Net with HTTP; Sat, 20 Oct 2001 11:10:21 -0700 Message-ID: <1003601421.3bd1be0dc5ebf@Mail.SavvyWorld.Net> Date: Sat, 20 Oct 2001 11:10:21 -0700 From: Edwin Culp To: current@FreeBSD.ORG Subject: Current makeworld seems broken. MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs X-Originating-IP: 24.20.19.75 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In case no one has seen this, I'm getting (cd /usr/src/etc; install -c -o root -g wheel -m 444 amd.map apmd.conf auth.con f crontab csh.cshrc csh.login csh.logout dhclient.conf dm.conf fbtab ftpusers gettytab group hosts hosts.allow hosts.equiv hosts.lpd inetd.conf login.access login.conf motd modems netconfig networks newsyslog.conf pam.conf phones prin tcap profile protocols rc rc.atm rc.devfs rc.diskless1 rc.diskless2 rc.firewall rc.firewall6 rc.network rc.network6 rc.pccard rc.serial rc.shutdown rc.syscon s rc.sysctl remote rpc security services shells sysctl.conf syslog.conf usbd.co nf etc.i386/disktab etc.i386/rc.i386 etc.i386/ttys /usr/src/etc/../gnu/usr.b in/man/manpath/manpath.config /usr/src/etc/../usr.bin/mail/misc/mail.rc /usr/s rc/etc/../usr.bin/locate/locate/locate.rc rc.isdn netstart pccard_ether rc.suspe nd rc.resume opieaccess /usr/share/examples/etc; install -c -o root -g wheel - m 444 defaults/rc.conf /usr/share/examples/etc/defaults; install -c -o root -g wheel -m 444 defaults/pccard.conf /usr/share/examples/etc/defaults; install - c -o root -g wheel -m 444 defaults/periodic.conf /usr/share/examples/etc/defaul ts) make: don't know how to make copies. Stop *** Error code 2 ed --- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Oct 20 17:40:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from mta10.onebox.com (mta10.onebox.com [64.68.76.184]) by hub.freebsd.org (Postfix) with ESMTP id C57E837B407 for ; Sat, 20 Oct 2001 17:40:07 -0700 (PDT) Received: from onebox.com ([10.1.111.11]) by mta10.onebox.com (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20011021004007.FGLF16495.mta10.onebox.com@onebox.com>; Sat, 20 Oct 2001 17:40:07 -0700 Received: from [66.32.44.111] by onebox.com with HTTP; Sat, 20 Oct 2001 17:40:07 -0700 Date: Sat, 20 Oct 2001 17:40:07 -0700 Subject: Re: Current makeworld seems broken. From: "Glenn Gombert" To: Edwin Culp Cc: current@FreeBSD.ORG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Message-Id: <20011021004007.FGLF16495.mta10.onebox.com@onebox.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Yes..I seem to be getting the same error message as well when I try to make/install world..... -- Glenn Gombert glenngombert@onebox.com - email (513) 587-2643 x2263 - voicemail/fax ---- Edwin Culp wrote: > In case no one has seen this, I'm getting > > (cd /usr/src/etc; install -c -o root -g wheel -m 444 amd.map apmd.conf > auth.con > f crontab csh.cshrc csh.login csh.logout dhclient.conf dm.conf fbtab > ftpusers > gettytab group hosts hosts.allow hosts.equiv hosts.lpd inetd.conf > login.access > login.conf motd modems netconfig networks newsyslog.conf pam.conf > phones prin > tcap profile protocols rc rc.atm rc.devfs rc.diskless1 rc.diskless2 > rc.firewall > rc.firewall6 rc.network rc.network6 rc.pccard rc.serial rc.shutdown > rc.syscon > s rc.sysctl remote rpc security services shells sysctl.conf syslog.conf > usbd.co > nf etc.i386/disktab etc.i386/rc.i386 etc.i386/ttys /usr/src/etc/../gnu/usr.b > in/man/manpath/manpath.config /usr/src/etc/../usr.bin/mail/misc/mail.rc > /usr/s > rc/etc/../usr.bin/locate/locate/locate.rc rc.isdn netstart pccard_ether > rc.suspe > nd rc.resume opieaccess /usr/share/examples/etc; install -c -o root > -g wheel - > m 444 defaults/rc.conf /usr/share/examples/etc/defaults; install > -c -o root -g > wheel -m 444 defaults/pccard.conf /usr/share/examples/etc/defaults; > install - > c -o root -g wheel -m 444 defaults/periodic.conf /usr/share/examples/etc/defaul > ts) > make: don't know how to make copies. Stop > *** Error code 2 > > ed > > > --- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > __________________________________________________ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Oct 20 20:18:47 2001 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 3EE0F37B401 for ; Sat, 20 Oct 2001 20:18:44 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9L3IZq56810; Sat, 20 Oct 2001 20:18:35 -0700 (PDT) (envelope-from dillon) Date: Sat, 20 Oct 2001 20:18:35 -0700 (PDT) From: Matthew Dillon Message-Id: <200110210318.f9L3IZq56810@apollo.backplane.com> To: Mark Huizer Cc: current@FreeBSD.ORG Subject: Re: NT filesystem panicking my current box References: <20011020153616.A76111@eeyore.local.dohd.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Try turning off vmiodirenable: sysctl -w vfs.vmiodirenable=0 And see if that makes a difference. -Matt :On one of my current boxes I run amanda, which some 2 weeks ago (after an :upgrade to that current) started dying reliable when the backup started. : :the ntfs FS is mounted on /nt : :2 seconds of testing showed that 'tar -czf /dev/null /nt' was enough for :a kernel panick within 2 seconds. : :A few upgrades later the problem still exists. : :Before I go through the trouble of collecting the backtraces and make :kernel dumps and all: do other people have this problem as well? Or is :this part of the NTFS module not really updated after the KSE happening? :(I have now disabled all local filesystems from the backup, since only :excluding the NTFS backup didn't solve the problem, still a crash, that :one I haven't looked at later on) : :Mark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message