From owner-freebsd-current Sun Feb 24 0:58:35 2002 Delivered-To: freebsd-current@freebsd.org Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 7BD8F37B416; Sun, 24 Feb 2002 00:58:32 -0800 (PST) Received: from pool0175.cvx22-bradley.dialup.earthlink.net ([209.179.198.175] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16euU2-00005i-00; Sun, 24 Feb 2002 00:58:15 -0800 Message-ID: <3C78AB18.B30A8D6E@mindspring.com> Date: Sun, 24 Feb 2002 00:58:00 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jake Burkholder Cc: Matthew Dillon , Alfred Perlstein , Bosko Milekic , Seigo Tanimura , current@FreeBSD.ORG, John Baldwin Subject: Re: malloc_bucket() idea (was Re: How to fix malloc.) References: <200201051752.g05Hq3gG074525@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <200201241022.g0OAMISM093913@faber.r.dl.itc.u-tokyo.ac.jp> <20020124024534.V13686@elvis.mu.org> <200202131739.g1DHdZT5023794@rina.r.dl.itc.u-tokyo.ac.jp> <200202190945.g1J9j9kg076110@rina.r.dl.itc.u-tokyo.ac.jp> <200202232051.g1NKpE741310@apollo.backplane.com> <20020223211449.GJ80761@elvis.mu.org> <200202232243.g1NMhZP49110@apollo.backplane.com> <20020223182947.A35990@locore.ca> 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 Jake Burkholder wrote: > Jeff Roberson (jeff@) has been working on a slab allocator that goes > a long way to making malloc(), free() and the zone allocator not require > giant. I've reviewed what he's got so far and it looks pretty damn good > to me, I'll see about getting him to post it. He's working on adding the > per-cpu queues now. A design like this resolves my objection to the pure SLAB allocator; Vahalia suggests this as a potential enhancment in his book, and the authors of the SLAB allocator mention it in their second paper (~1996/1997). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 1: 0: 3 2002 Delivered-To: freebsd-current@freebsd.org Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by hub.freebsd.org (Postfix) with ESMTP id 9981237B404; Sun, 24 Feb 2002 00:59:58 -0800 (PST) Received: (from jake@localhost) by k6.locore.ca (8.11.6/8.11.6) id g1O90gL39934; Sun, 24 Feb 2002 04:00:42 -0500 (EST) (envelope-from jake) Date: Sun, 24 Feb 2002 04:00:41 -0500 From: Jake Burkholder To: Julian Elischer Cc: John Baldwin , dillon@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: First (easy) td_ucred patch Message-ID: <20020224040041.C35990@locore.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from julian@elischer.org on Sat, Feb 23, 2002 at 11:21:24AM -0800 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 Apparently, On Sat, Feb 23, 2002 at 11:21:24AM -0800, Julian Elischer said words to the effect of; > > > On Fri, 22 Feb 2002, John Baldwin wrote: > > > > > http://www.FreeBSD.org/~jhb/patches/ucred.patch > > > the structural rewriting in kern_proc.c should be done as a separate > commit. (though I agree it should be done) > > the structural rewriting in kern/sysv_*.c > could be done as a separate commit as well. > (I agree it is worth doing) > > I'll let you get away with unp_listen() :-) I'd like to point out that in all cases that you mention, the original structure before the "giant pushdown" is being restored. A lot of structural rewriting occured in those commits. It was not done separately. I don't recall if the patches were posted for review, I certainly never saw them. This strikes me as a double standard. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 1:16:10 2002 Delivered-To: freebsd-current@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 7077637B402; Sun, 24 Feb 2002 01:16:06 -0800 (PST) Received: from pool0175.cvx22-bradley.dialup.earthlink.net ([209.179.198.175] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16eulJ-0001s8-00; Sun, 24 Feb 2002 01:16:05 -0800 Message-ID: <3C78AF48.5493B893@mindspring.com> Date: Sun, 24 Feb 2002 01:15:52 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: Matthew Dillon , Bosko Milekic , Seigo Tanimura , current@FreeBSD.ORG, John Baldwin Subject: Re: malloc_bucket() idea (was Re: How to fix malloc.) References: <200201051752.g05Hq3gG074525@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <200201241022.g0OAMISM093913@faber.r.dl.itc.u-tokyo.ac.jp> <20020124024534.V13686@elvis.mu.org> <200202131739.g1DHdZT5023794@rina.r.dl.itc.u-tokyo.ac.jp> <200202190945.g1J9j9kg076110@rina.r.dl.itc.u-tokyo.ac.jp> <200202232051.g1NKpE741310@apollo.backplane.com> <20020223211449.GJ80761@elvis.mu.org> <200202232243.g1NMhZP49110@apollo.backplane.com> <20020224003739.GL80761@elvis.mu.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 Alfred Perlstein wrote: > * Matthew Dillon [020223 14:43] wrote: > > This is approximately what I am thinking. Note that this gives us the > > flexibility to create a larger infrastructure around the bucket cache, > > such as implement per-cpu caches and so on and so forth. What I have > > here is the minimal implementation. > > I strongly object to this implementation right now, please do not > commit it. I already explained to you how to make the problem > go away but instead you insist on some complex api that pins > memory down like the damn zone allocator. It's not needed, so > please don't do it. Actually, the zone allocator is not far off, I think. Imagine if the entire possible KVA space (real RAM + swap) was preallocated PTEs. Allocations could treat it as anonymous memory, for which a mapping process was not required, and all allocations would be interrupt safe by default, without having to special case the code one way or the other. This seems, to me, to be the right idea. The only issue left is that the maps take real memory that is wired down. This raises the possibility of adding to the swap where swap + RAM << KVA && swap + RAM + new_swap <= KVA, which would imply mappings bneing required on the adding of swap (via swapon). Not that painful, but it does imply a 1:1000 limit ratio on real vs. virtual RAM to get to the page mapping overhead. 4M pages would cover some of that problem... but making allocations swappable is often desirable, even in the kernel, so you would need to special case those mappings... and 4M and 4K pages play badly together, unless you know what you are doing, and you know the undocumented bugs (c.v. the recent AMD AGP thing). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 1:20:13 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 2D38E37B417 for ; Sun, 24 Feb 2002 01:20:12 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020224092006.RMJM1147.rwcrmhc52.attbi.com@InterJet.elischer.org>; Sun, 24 Feb 2002 09:20:06 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA82360; Sun, 24 Feb 2002 01:00:43 -0800 (PST) Date: Sun, 24 Feb 2002 01:00:41 -0800 (PST) From: Julian Elischer To: Garance A Drosihn Cc: Dag-Erling Smorgrav , current@FreeBSD.org Subject: Re: -CURRENT in pretty good shape, after all In-Reply-To: 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 hmmmm julian@jules:uname -a FreeBSD jules.elischer.org 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Thu Feb 21 00:32:02 PST 2002 root@jules.elischer.org:/usr/src/sys/i386/compile/NMDM i386 julian@jules: I'm using vmware2 to run turbotax to do my taxes and it seems fine.... On Sat, 23 Feb 2002, Garance A Drosihn wrote: > > It is working fairly well for me too, on a dual-pentium machine. > I can't get vmware2 working, but most of everything else that I > do is working, and I'm not running into any mysterious crashes. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 1:20:22 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 91C3437B402; Sun, 24 Feb 2002 01:20:14 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020224092014.RMKK1147.rwcrmhc52.attbi.com@InterJet.elischer.org>; Sun, 24 Feb 2002 09:20:14 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA82368; Sun, 24 Feb 2002 01:06:47 -0800 (PST) Date: Sun, 24 Feb 2002 01:06:46 -0800 (PST) From: Julian Elischer To: Jake Burkholder Cc: John Baldwin , dillon@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: First (easy) td_ucred patch In-Reply-To: <20020224040041.C35990@locore.ca> 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 I'm just saying that if this is the "simple p->p_ucred => td->td_ucred change that do only that and do the rewrite in a separate commit.. I'm not against doing hte commit as is however.. it's only 3 small nits.. the one that may be real is the other one I mention (I think in another email) where the capability of coping with a NULL td is lost. On Sun, 24 Feb 2002, Jake Burkholder wrote: > Apparently, On Sat, Feb 23, 2002 at 11:21:24AM -0800, > Julian Elischer said words to the effect of; > > > > > > > On Fri, 22 Feb 2002, John Baldwin wrote: > > > > > > > > http://www.FreeBSD.org/~jhb/patches/ucred.patch > > > > > > the structural rewriting in kern_proc.c should be done as a separate > > commit. (though I agree it should be done) > > > > the structural rewriting in kern/sysv_*.c > > could be done as a separate commit as well. > > (I agree it is worth doing) > > > > I'll let you get away with unp_listen() :-) > > I'd like to point out that in all cases that you mention, the original > structure before the "giant pushdown" is being restored. A lot of structural > rewriting occured in those commits. It was not done separately. I don't > recall if the patches were posted for review, I certainly never saw them. > > This strikes me as a double standard. > > Jake > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 1:28:37 2002 Delivered-To: freebsd-current@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 5A5D737B402 for ; Sun, 24 Feb 2002 01:28:35 -0800 (PST) Received: from pool0175.cvx22-bradley.dialup.earthlink.net ([209.179.198.175] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16euxJ-0006y3-00; Sun, 24 Feb 2002 01:28:29 -0800 Message-ID: <3C78B22F.FD17855B@mindspring.com> Date: Sun, 24 Feb 2002 01:28:15 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Garance A Drosihn , Dag-Erling Smorgrav , current@FreeBSD.org Subject: Re: -CURRENT in pretty good shape, after all 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 SMP? -- Terry Julian Elischer wrote: > > hmmmm > > julian@jules:uname -a > FreeBSD jules.elischer.org 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Thu Feb 21 > 00:32:02 PST 2002 > root@jules.elischer.org:/usr/src/sys/i386/compile/NMDM i386 > julian@jules: > > I'm using vmware2 to run turbotax to do my taxes and it seems fine.... > > On Sat, 23 Feb 2002, Garance A Drosihn wrote: > > > > > It is working fairly well for me too, on a dual-pentium machine. > > I can't get vmware2 working, but most of everything else that I > > do is working, and I'm not running into any mysterious crashes. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 2:52: 7 2002 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 52A7237B404 for ; Sun, 24 Feb 2002 02:52:05 -0800 (PST) Received: from DougBarton.net (12-234-22-238.client.attbi.com [12.234.22.238]) by mail-relay1.yahoo.com (Postfix) with ESMTP id 7D9188B5D8; Sun, 24 Feb 2002 02:52:04 -0800 (PST) Message-ID: <3C78C5D4.4A785D1F@DougBarton.net> Date: Sun, 24 Feb 2002 02:52:04 -0800 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling Smorgrav , David Wolfskill , current@FreeBSD.ORG, ggombert@imatowns.com Subject: Re: Install World fails in -Current References: <200202221338.g1MDceE75453@bunrab.catwhisker.org> <3C7895E9.A79E91CA@DougBarton.net> 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 Doug Barton wrote: > > Dag-Erling Smorgrav wrote: > > > > David Wolfskill writes: > > > Sounds like a botched (or not run) "mergemaster" execution: > > > > No - mergemaster will croak because it runs mtree to build its temp > > directory, so if you're trying to update a pre-smmsp system you have > > to add the smmsp user and group manually. Ok, I decided to go proactive and add -p mode for "pre {build|install}world" which compares master.passwd, group, and the variables in /etc/make.conf to /usr/src/share/examples/etc/make.conf. This should give people a fairly painless way to handle the transition if they choose to accept it. While I was there, I added some other code I've been using for a while to compare variables in /etc/rc.conf[.local] with the same variables in /etc/defaults/rc.conf. Use 'mergemaster -C' to use that feature. If someone has suggestions on more files to add to -p mode, let me know. I'll update the man page after people have had a chance to play with these. Enjoy, Doug -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 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 Sun Feb 24 3:10: 0 2002 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 9674237B420; Sun, 24 Feb 2002 03:09:44 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1OB9cn68688; Sun, 24 Feb 2002 03:09:38 -0800 (PST) (envelope-from dillon) Date: Sun, 24 Feb 2002 03:09:38 -0800 (PST) From: Matthew Dillon Message-Id: <200202241109.g1OB9cn68688@apollo.backplane.com> To: Bruce Evans Cc: Terry Lambert , Alfred Perlstein , Bosko Milekic , Seigo Tanimura , , John Baldwin Subject: Success! critical_enter()/critical_exit() revamp (was Re: malloc_bucket() idea (was Re: How to fix malloc.)) References: <20020224131027.I31343-100000@gamplex.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 I'm going to wait until tomorrow before posting it. I have a bunch of cleanup to do. Bruce, your sys.dif was *invaluable*! It would have taken me a lot longer to figure out the interrupt disablement requirement around the icu_lock, and the statclock and hardclock forwarding issues (which I got working by the way!). It turns out that putting the pending masks in the per-cpu area was the right solution! It made statclock and hardclock forwarding easy (I can see why you didn't even try in your patch set, doing it with a global mask would be nearly impossible). In fact, it made everything unbelievably easy. Apart from all the assembly coding, there were two serious issues. fork_exit() assumes that interrupts are hard-disabled on entry. I readjusted the code such that the trampoline assembly initialized the td_critnest count so it could STI prior to calling fork_exit(). The second issue is that cpu_switch() does not save/restore the PSL_I (interrupt disablement mask). I added a PSL word to the PCB structure to take care of the problem. Without this if you have a thread switch away while holding interrupts hard-disabled, the next thread will inherit the hard disablement. I saw the sti's you added in various places but I figured the best solution was to simply save/restore the state. The original code didn't have this problem because interrupts were always hard-disabled while holding the sched_lock and, of course, cpu_switch() is always called while holding sched_lock. (Similarly, icu_lock needed hard-disablements wrapped around it for the same reason, because a level interrupt still needs to be able to get icu_lock in order to defer itself). In anycase, I have successfully built the world in a -current SMP + apic_vector system. Tomorrow I will cleanup on the UP icu_vector code to match the apic_vector code and post the results. I also have a sysctl that allows developers to toggle the mode for testing purposes (old way or new way). Finally, I took your suggestion in regards to not trying to combine the masks together. I have a 'some sort of interrupt is pending' variable then I have fpending (for fast interrupts), ipending (for normal interrupt threads), and spending (which I use for the stat and hardclock forwarding). They're all per-cpu entities, of course. unpend() prioritizes them. In anycase, I'll post it all tomorrow after I've got icu_vector cleaned up. One of the best things about this patch set is that it is really flexible. We should be able to really make interrupts fly. In fact, it should even be possible for one cpu to steal another cpu's pending interrupt(s) fairly trivially, without having to resort to IPIs. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 3:27:16 2002 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 3B38A37B41C for ; Sun, 24 Feb 2002 03:27:02 -0800 (PST) Received: (qmail 11427 invoked from network); 24 Feb 2002 11:26:55 -0000 Received: from unknown (HELO torrini.org) (195.110.114.101) by mail.dada.it with SMTP; 24 Feb 2002 11:26:55 -0000 Received: from trudy.home.torrini.org (localhost.home.torrini.org [127.0.0.1]) by torrini.org (8.12.2/8.12.2) with ESMTP id g1OBQts0000386; Sun, 24 Feb 2002 12:26:56 +0100 (CET) (envelope-from riccardo@trudy.home.torrini.org) Received: (from riccardo@localhost) by trudy.home.torrini.org (8.12.2/8.12.2/Submit) id g1OBQqCl000385; Sun, 24 Feb 2002 12:26:52 +0100 (CET) Message-ID: X-Mailer: XFMail 1.5.2 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: Sun, 24 Feb 2002 12:26:52 +0100 (CET) From: Riccardo Torrini To: Dag-Erling Smorgrav , Dan Nelson Subject: I have found /dev/speaker :-) Cc: current@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 On 15-Feb-2002 (22:17:10/GMT) Dan Nelson wrote: > If you find out what killed /dev/speaker, let us know, too :) On 23-Feb-2002 (22:03:56/GMT) Dag-Erling Smorgrav wrote: >>> # kldload atspeaker >> This doesn't work. I'm missing something obvious? > Not that I can see... works for me Now /dev/speaker is in place again. I found his killer... I removed _all_ hints from /boot/device.hints and _all_ device from my custom kernel, than added again one line at a time... After 42 {build,install}kernel I found it again in /dev/ Compiling kernel with both this lines kill /dev/speaker and leave only /dev/pcaudio and /dev/pcaudioctl. Using only one at a time works fine. Also kldload atspeaker, if none of them are present into kernel, works (thank DES for hint). # pca: PCM audio through your PC speaker ## :-( device pca #Play IBM BASIC-style noises out your speaker device speaker After good news the bad ones: detaching uscanner0 doesn't execute my code, only play tune on attach, as on mid December :( Ricardo. -----8<-----[ /etc/usbd.conf ]-----8<----- [...] devname "uscanner[0-9]+" attach "/bin/chmod 666 /dev/${DEVNAME} && echo L16cce > /dev/speaker" detach "echo L16eec > /dev/speaker" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 6: 8: 7 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.wearix.com (lorien.wearix.com [193.197.4.2]) by hub.freebsd.org (Postfix) with ESMTP id 2BA1337B402 for ; Sun, 24 Feb 2002 06:08:01 -0800 (PST) Received: from hry.muc.wearix.com (ad96e1d2b.dsl.de.colt.net [217.110.29.43]) by mail.wearix.com (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 426793580 for ; Sun, 24 Feb 2002 15:07:54 +0100 (CET) Subject: snapshots? WAS: Re: -CURRENT in pretty good shape, after all From: Harald Schmalzbauer To: current@freebsd.org In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution/1.0 (Preview Release) Date: 24 Feb 2002 15:08:27 +0100 Message-Id: <1014559707.3098.4.camel@hry.muc.wearix.com> Mime-Version: 1.0 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 Am Sa , 2002-02-23 um 18.24 schrieb Dag-Erling Smorgrav: > Thumbs up and big cheers to all of you (well, us) guys working on > -CURRENT. It's pretty stable and has been for a while now - and even > on my poor old 350 MHz K6-2, it performs well enough to make a kickass > desktop & development platform. Let's hope it'll only get better from > here on out :) Hello all, this sounds great. Thanks to all people. But this brings me to one question: What's about snapshot-releases? Some years ago (from 3 on) I had a supscription for current snapshots. The last I got was 2 years ago an April2000 -4 snapshot. Since I changed my employer I made new subscriptions at bsdmall.com but I couldn't find any snapshot subscription. Are you still doing these snapshots and they are just no more offered or don't you do any snapshot releases any more. Thanks all, -Harry >=20 > DES > --=20 > Dag-Erling Smorgrav - des@ofug.org >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message --=20 Wearix Software GmbH Harald Schmalzbauer, IT-Engineer Unterhachinger Strasse 75 81737 M=FCnchen +49 89 548828-702 http://www.wearix.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 8:34:32 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 6365C37B405 for ; Sun, 24 Feb 2002 08:34:26 -0800 (PST) Received: from hades.hell.gr (patr530-a186.otenet.gr [212.205.215.186]) by mailsrv.otenet.gr (8.12.2/8.12.2) with ESMTP id g1OGYFqO016298; Sun, 24 Feb 2002 18:34:17 +0200 (EET) Received: (from charon@localhost) by hades.hell.gr (8.11.6/8.11.6) id g1O4MCP17382; Sun, 24 Feb 2002 06:22:12 +0200 (EET) (envelope-from keramida@freebsd.org) Date: Sun, 24 Feb 2002 06:22:11 +0200 From: Giorgos Keramidas To: Dag-Erling Smorgrav Cc: current@freebsd.org Subject: Re: -CURRENT in pretty good shape, after all Message-ID: <20020224042210.GC4789@hades.hell.gr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i 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 2002-02-23 18:24, Dag-Erling Smorgrav wrote: > Thumbs up and big cheers to all of you (well, us) guys working on > -CURRENT. It's pretty stable and has been for a while now - and even > on my poor old 350 MHz K6-2, it performs well enough to make a kickass > desktop & development platform. Let's hope it'll only get better from > here on out :) It does work perfectly nice for me too, here. I've been building worlds without a single problem ever since Feb 7, 2002. Oh, and since I like living in the edge, I erased my 4-STABLE installation on Feb 10, and formatted that partition. Now I use it as /c, a workspace where temporary development work is done. Thank you all, who have put efforts in making this happen! Giorgos Keramidas FreeBSD Documentation Project keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 9:10:13 2002 Delivered-To: freebsd-current@freebsd.org Received: from voi.aagh.net (pc1-hart4-0-cust168.mid.cable.ntl.com [62.254.84.168]) by hub.freebsd.org (Postfix) with ESMTP id F181337B400; Sun, 24 Feb 2002 09:10:07 -0800 (PST) Received: from freaky by voi.aagh.net with local (Exim 3.35 #1) id 16f2A2-000NoO-00; Sun, 24 Feb 2002 17:10:06 +0000 Date: Sun, 24 Feb 2002 17:10:06 +0000 From: Thomas Hurst To: freebsd-smp@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: TWiki as promised... Message-ID: <20020224171006.GB90595@voi.aagh.net> Mail-Followup-To: freebsd-smp@FreeBSD.ORG, freebsd-current@FreeBSD.ORG References: <200202240607.WAA929178@meer.meer.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200202240607.WAA929178@meer.meer.net> User-Agent: Mutt/1.3.27i Organization: Not much. X-Operating-System: FreeBSD/4.5-PRERELEASE (i386) X-Uptime: 5:06PM up 66 days, 1:51, 5 users, load averages: 2.06, 2.05, 2.01 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 * George V. Neville-Neil (gnn@neville-neil.com) wrote: > > BTW, why don't you want a FreeBSD WikiTerm? > > Well it's a bit odd. Anywhere you put the word FreeBSD lights up as a > link. I guess we could put a generic page under it or something but > it's annoying (to me at least) to see FreeBSD as a link everywhere > when it's mostly just a name. You can always style it to look like normal text. a[href=""] { text-decoration: none; color: black; background-color: inherit; } You probably want to do the same for the :link/:hover/:active/:visited elements too. And you'll want to use a browser with a decent CSS implimentation (i.e. not MSIE :) You can even just put it in your user stylesheet if you don't want it to be on the site :) -- Thomas 'Freaky' Hurst - freaky@aagh.net - http://www.aagh.net/ - On the whole, I'd rather be in Philadelphia. -- W.C. Fields' epitaph To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 10: 4: 8 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.datanet.hu (mx1.datanet.hu [194.149.13.160]) by hub.freebsd.org (Postfix) with ESMTP id 428BB37B419 for ; Sun, 24 Feb 2002 10:04:05 -0800 (PST) Received: from fonix.adamsfamily.xx (nilus-207.adsl.datanet.hu [195.56.92.206]) by mx1.datanet.hu (DataNet) with ESMTP id 30820F99D for ; Sun, 24 Feb 2002 19:04:03 +0100 (CET) Received: from fonix.adamsfamily.xx (localhost [127.0.0.1]) by fonix.adamsfamily.xx (8.12.2/8.12.2) with ESMTP id g1OI4TYY000486 for ; Sun, 24 Feb 2002 19:04:29 +0100 (CET) (envelope-from sziszi@bsd.hu) Received: (from cc@localhost) by fonix.adamsfamily.xx (8.12.2/8.12.2/Submit) id g1OI4S8n000485 for current@FreeBSD.ORG; Sun, 24 Feb 2002 19:04:28 +0100 (CET) X-Authentication-Warning: fonix.adamsfamily.xx: cc set sender to sziszi@bsd.hu using -f Date: Sun, 24 Feb 2002 19:04:28 +0100 From: Szilveszter Adam To: current@FreeBSD.ORG Subject: Re: -CURRENT in pretty good shape, after all Message-ID: <20020224180426.GA406@fonix.adamsfamily.xx> Mail-Followup-To: Szilveszter Adam , current@FreeBSD.ORG References: <20020224042210.GC4789@hades.hell.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020224042210.GC4789@hades.hell.gr> User-Agent: Mutt/1.3.27i 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, Feb 24, 2002 at 06:22:11AM +0200, Giorgos Keramidas wrote: > It does work perfectly nice for me too, here. I've been building worlds > without a single problem ever since Feb 7, 2002. Oh, and since I like > living in the edge, I erased my 4-STABLE installation on Feb 10, and > formatted that partition. Now I use it as /c, a workspace where temporary > development work is done. Well, just to put my "Me too!" here. I have been following 5.x for as long as it existed and during all this exercise, I have found it to be fairly useable at all times. There were some bumps along the road, but nothing that a careful study of this and other mailing lists would not have solved. In fact, ever since 5.x branched from 4.0 way back when:-) it was the only installation of FreeBSD that I had on my workstation. I wrote my university thesis on this machine, while religiously keeping up with the latest and greatest -CURRENT source, the box has served as a dialup and later as an ADSL gateway without problems. Of course, debugging code has slowed it down at times but that was expected. Although I do not consider myself a developer/programmer, I always tried to report problems in a useful way when found. It is just that I did not have a lot to do on this front:-) (Maybe I am the kind of user who should start using -CURRENT in greater numbers? OK, I'm here already:-) This machine is a PII-233 UP, with an Intel 440-LX based mobo and only IDE peripherals. It is no longer "state of the art" or even close, but, thanks to FreeBSD, it runs as snappy as ever. > Thank you all, who have put efforts in making this happen! Indeed. It is really refreshing to see that, despite occasional ramblimngs and otbreaks of flame on the lists, the project really makes headway, especially looked at from a historical perspective. Keep up the good work! P.S.: This message is also test to see if the upgrade to the latest sendmail worked well:-) -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 11:13:12 2002 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 D813A37B400; Sun, 24 Feb 2002 11:12:23 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1OJCMx95238; Sun, 24 Feb 2002 11:12:22 -0800 (PST) (envelope-from dillon) Date: Sun, 24 Feb 2002 11:12:22 -0800 (PST) From: Matthew Dillon Message-Id: <200202241912.g1OJCMx95238@apollo.backplane.com> To: Bruce Evans , Terry Lambert , Alfred Perlstein , Bosko Milekic , Seigo Tanimura , , John Baldwin Subject: Patch for critical_enter()/critical_exit() & interrupt assembly revamp, please review! References: <20020224131027.I31343-100000@gamplex.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 NOTES: I would like to thank Bruce for supplying the sample code that allowed me to do this in a day instead of several days. * debug.critical_mode sysctl. This will not be in the final commit, nor will any of the code that tests the variable. The final commit will use code as if the critical_mode were '1'. The default is 1, which means to use the new streamlined interrupt and cpu_critical_enter/exit() code. Setting it to 0 will revert to the old hard-interrupt-disablement operation. You can change the mode at any time. * Additional cpu_critical_enter/exit() calls around icu_lock. Since critical_enter() no longer disables interrupts, special care must be taken when dealing with the icu_lock spin mutex because it is the one thing the interrupt code needs to be able to defer the interrupt. * MACHINE_CRITICAL_ENTER define. This exists to maintain compatibility with other architectures. i386 defines this to cause fork_exit to use the new API and to allow the i386 MD code to supply the critical_enter() and critical_exit() procedures rather then kern_switch.c I would much prefer it if the other architectures were brought around to use this new mechanism. The old mechanism makes assumptions in regards to hard disablement that is no longer correct for i386. * Trampoline 'sti'. In the final commit, the trampoline will simply 'sti' after setting up td_critnest. The other junk to handle the hard-disablement case will be gone. * PSL save/restore in cpu_switch(). In the original code interrupts were always hard-disabled due to holding the sched_lock. cpu_switch never bothered to save/restore the hard interrupt enable/disable bit (the PSL). In the new code, hard disablement has no relationship to the holding of spin mutexes and so we have to save/restore the PSL. If we don't, one thread's interrupt disablement will propogate to another thread unexpectedly. * Additional STI's. It may be possible to emplace additional STI's in the code. For example, we should be able to enable interrupts in the dounpend() code after we complete processing of FAST interrupts and start processing normal interrupts. * Additional cpu_critical_enter()/exit() calls in CY and TIMER code. Bruce had additional hard interrupt disablements in these modules. I'm not sure why so if I need to do that as well I would like to know. * Additional optimization and work. This is ongoing work but this basic patch set, with some cleanups, is probably what I will commit initially. This code will give us a huge amount of flexibility in regards to handling interrupts. -Matt Index: i386/i386/exception.s =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/exception.s,v retrieving revision 1.91 diff -u -r1.91 exception.s --- i386/i386/exception.s 11 Feb 2002 03:41:58 -0000 1.91 +++ i386/i386/exception.s 24 Feb 2002 08:41:40 -0000 @@ -222,6 +222,18 @@ pushl %esp /* trapframe pointer */ pushl %ebx /* arg1 */ pushl %esi /* function */ + movl PCPU(CURTHREAD),%ebx /* setup critnest */ + movl $1,TD_CRITNEST(%ebx) + cmpl $0,critical_mode + jne 1f + pushfl + popl TD_SAVECRIT(%ebx) + orl $PSL_I,TD_SAVECRIT(%ebx) + jmp 2f +1: + movl $-1,TD_SAVECRIT(%ebx) + sti /* enable interrupts */ +2: call fork_exit addl $12,%esp /* cut from syscall */ Index: i386/i386/genassym.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/genassym.c,v retrieving revision 1.121 diff -u -r1.121 genassym.c --- i386/i386/genassym.c 17 Feb 2002 17:40:27 -0000 1.121 +++ i386/i386/genassym.c 24 Feb 2002 09:06:56 -0000 @@ -89,6 +89,8 @@ ASSYM(TD_KSE, offsetof(struct thread, td_kse)); ASSYM(TD_PROC, offsetof(struct thread, td_proc)); ASSYM(TD_INTR_NESTING_LEVEL, offsetof(struct thread, td_intr_nesting_level)); +ASSYM(TD_CRITNEST, offsetof(struct thread, td_critnest)); +ASSYM(TD_SAVECRIT, offsetof(struct thread, td_savecrit)); ASSYM(P_MD, offsetof(struct proc, p_md)); ASSYM(MD_LDT, offsetof(struct mdproc, md_ldt)); @@ -134,6 +136,7 @@ ASSYM(PCB_DR3, offsetof(struct pcb, pcb_dr3)); ASSYM(PCB_DR6, offsetof(struct pcb, pcb_dr6)); ASSYM(PCB_DR7, offsetof(struct pcb, pcb_dr7)); +ASSYM(PCB_PSL, offsetof(struct pcb, pcb_psl)); ASSYM(PCB_DBREGS, PCB_DBREGS); ASSYM(PCB_EXT, offsetof(struct pcb, pcb_ext)); @@ -176,6 +179,10 @@ ASSYM(PC_SIZEOF, sizeof(struct pcpu)); ASSYM(PC_PRVSPACE, offsetof(struct pcpu, pc_prvspace)); ASSYM(PC_CURTHREAD, offsetof(struct pcpu, pc_curthread)); +ASSYM(PC_INT_PENDING, offsetof(struct pcpu, pc_int_pending)); +ASSYM(PC_IPENDING, offsetof(struct pcpu, pc_ipending)); +ASSYM(PC_FPENDING, offsetof(struct pcpu, pc_fpending)); +ASSYM(PC_SPENDING, offsetof(struct pcpu, pc_spending)); ASSYM(PC_FPCURTHREAD, offsetof(struct pcpu, pc_fpcurthread)); ASSYM(PC_IDLETHREAD, offsetof(struct pcpu, pc_idlethread)); ASSYM(PC_CURPCB, offsetof(struct pcpu, pc_curpcb)); Index: i386/i386/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v retrieving revision 1.497 diff -u -r1.497 machdep.c --- i386/i386/machdep.c 17 Feb 2002 17:40:28 -0000 1.497 +++ i386/i386/machdep.c 24 Feb 2002 19:04:20 -0000 @@ -138,6 +138,8 @@ #endif /* CPU_ENABLE_SSE */ SYSINIT(cpu, SI_SUB_CPU, SI_ORDER_FIRST, cpu_startup, NULL) +void unpend(void); /* note: not static */ + int _udatasel, _ucodesel; u_int atdevbase; @@ -148,6 +150,9 @@ SYSCTL_INT(_debug, OID_AUTO, tlb_flush_count, CTLFLAG_RD, &tlb_flush_count, 0, ""); #endif +int critical_mode = 1; +SYSCTL_INT(_debug, OID_AUTO, critical_mode, + CTLFLAG_RW, &critical_mode, 0, ""); #ifdef PC98 static int ispc98 = 1; @@ -270,6 +275,121 @@ } /* + * Critical section handling. + * + * Note that our interrupt code handles any interrupt race that occurs + * after we decrement td_critnest. + */ +void +critical_enter(void) +{ + struct thread *td = curthread; + + if (critical_mode == 0) { + if (td->td_critnest == 0) + td->td_savecrit = cpu_critical_enter(); + td->td_critnest++; + } else { + ++td->td_critnest; + } +} + +void +critical_exit(void) +{ + struct thread *td = curthread; + KASSERT(td->td_critnest > 0, ("bad td_critnest value!")); + if (--td->td_critnest == 0) { + if (td->td_savecrit != (critical_t)-1) { + cpu_critical_exit(td->td_savecrit); + td->td_savecrit = (critical_t)-1; + } else { + /* + * We may have to schedule pending interrupts. Create + * conditions similar to an interrupt context and call + * unpend(). + */ + if (PCPU_GET(int_pending) && td->td_intr_nesting_level == 0) { + critical_t eflags; + + eflags = cpu_critical_enter(); + if (PCPU_GET(int_pending)) { + ++td->td_intr_nesting_level; + unpend(); + --td->td_intr_nesting_level; + } + cpu_critical_exit(eflags); + } + } + } +} + +/* + * Called from critical_exit() or called from the assembly vector code + * to process any interrupts which may have occured while we were in + * a critical section. + * + * - interrupts must be disabled + * - td_intr_nesting_level may not be 0 + * - td_critnest must be 0 + */ +void +unpend(void) +{ + curthread->td_critnest = 1; + for (;;) { + u_int32_t mask; + + /* + * Fast interrupts have priority + */ + if ((mask = PCPU_GET(fpending)) != 0) { + int irq = bsfl(mask); + PCPU_SET(fpending, mask & ~(1 << irq)); + call_fast_unpend(irq); + continue; + } + + /* + * Threaded interrupts come next + */ + if ((mask = PCPU_GET(ipending)) != 0) { + int irq = bsfl(mask); + PCPU_SET(ipending, mask & ~(1 << irq)); + sched_ithd((void *)irq); + continue; + } + + /* + * Software interrupts and delayed IPIs are last + * + * XXX give the bits #defined names. see also + * isa/xxx_vector.s + */ + if ((mask = PCPU_GET(spending)) != 0) { + int irq = bsfl(mask); + PCPU_SET(spending, mask & ~(1 << irq)); + switch(irq) { + case 0: /* bit 0 - hardclock */ + mtx_lock_spin(&sched_lock); + hardclock_process(curthread, 0); + mtx_unlock_spin(&sched_lock); + break; + case 1: /* bit 1 - statclock */ + mtx_lock_spin(&sched_lock); + statclock_process(curthread->td_kse, (register_t)unpend, 0); + mtx_unlock_spin(&sched_lock); + break; + } + continue; + } + break; + } + PCPU_SET(int_pending, 0); + curthread->td_critnest = 0; +} + +/* * Send an interrupt to process. * * Stack is set up to allow sigcode stored @@ -1732,12 +1852,17 @@ /* * Initialize mutexes. + * + * icu_lock: in order to allow an interrupt to occur in a critical + * section, to set pcpu->ipending (etc...) properly, we + * must be able to get the icu lock, so it can't be + * under witness. */ mtx_init(&Giant, "Giant", MTX_DEF | MTX_RECURSE); mtx_init(&sched_lock, "sched lock", MTX_SPIN | MTX_RECURSE); mtx_init(&proc0.p_mtx, "process lock", MTX_DEF); mtx_init(&clock_lock, "clk", MTX_SPIN | MTX_RECURSE); - mtx_init(&icu_lock, "icu", MTX_SPIN); + mtx_init(&icu_lock, "icu", MTX_SPIN | MTX_NOWITNESS); mtx_lock(&Giant); /* make ldt memory segments */ Index: i386/i386/mp_machdep.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v retrieving revision 1.174 diff -u -r1.174 mp_machdep.c --- i386/i386/mp_machdep.c 22 Feb 2002 13:31:55 -0000 1.174 +++ i386/i386/mp_machdep.c 24 Feb 2002 08:09:50 -0000 @@ -2306,6 +2306,9 @@ /* * For statclock, we send an IPI to all CPU's to have them call this * function. + * + * WARNING! unpend() will call statclock_process() directly and skip this + * routine. */ void forwarded_statclock(struct trapframe frame) @@ -2337,6 +2340,9 @@ * sched_lock if we could simply peek at the CPU to determine the user/kernel * state and call hardclock_process() on the CPU receiving the clock interrupt * and then just use a simple IPI to handle any ast's if needed. + * + * WARNING! unpend() will call hardclock_process() directly and skip this + * routine. */ void forwarded_hardclock(struct trapframe frame) Index: i386/i386/mpapic.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/mpapic.c,v retrieving revision 1.52 diff -u -r1.52 mpapic.c --- i386/i386/mpapic.c 5 Jan 2002 06:44:27 -0000 1.52 +++ i386/i386/mpapic.c 24 Feb 2002 10:49:23 -0000 @@ -190,6 +190,7 @@ u_int32_t target; /* the window register is 32 bits */ u_int32_t vector; /* the window register is 32 bits */ int level; + critical_t crit; target = IOART_DEST; @@ -210,11 +211,13 @@ * shouldn't and stop the carnage. */ vector = NRSVIDT + pin; /* IDT vec */ + crit = cpu_critical_enter(); mtx_lock_spin(&icu_lock); io_apic_write(apic, select, (io_apic_read(apic, select) & ~IOART_INTMASK & ~0xff)|IOART_INTMSET|vector); mtx_unlock_spin(&icu_lock); + cpu_critical_exit(crit); /* we only deal with vectored INTs here */ if (apic_int_type(apic, pin) != 0) @@ -258,10 +261,12 @@ printf("IOAPIC #%d intpin %d -> irq %d\n", apic, pin, irq); vector = NRSVIDT + irq; /* IDT vec */ + crit = cpu_critical_enter(); mtx_lock_spin(&icu_lock); io_apic_write(apic, select, flags | vector); io_apic_write(apic, select + 1, target); mtx_unlock_spin(&icu_lock); + cpu_critical_exit(crit); } int Index: i386/i386/swtch.s =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/swtch.s,v retrieving revision 1.128 diff -u -r1.128 swtch.s --- i386/i386/swtch.s 7 Feb 2002 22:40:34 -0000 1.128 +++ i386/i386/swtch.s 24 Feb 2002 09:09:05 -0000 @@ -96,6 +96,8 @@ movl %esi,PCB_ESI(%edx) movl %edi,PCB_EDI(%edx) movl %gs,PCB_GS(%edx) + pushfl /* PSL */ + popl PCB_PSL(%edx) /* Test if debug registers should be saved. */ testl $PCB_DBREGS,PCB_FLAGS(%edx) @@ -233,6 +235,8 @@ movl PCB_EDI(%edx),%edi movl PCB_EIP(%edx),%eax movl %eax,(%esp) + pushl PCB_PSL(%edx) + popfl #if defined(SMP) && defined(GRAB_LOPRIO) /* Hold LOPRIO for interrupts. */ @@ -339,6 +343,8 @@ movl %esi,PCB_ESI(%ecx) movl %edi,PCB_EDI(%ecx) movl %gs,PCB_GS(%ecx) + pushfl + popl PCB_PSL(%ecx) #ifdef DEV_NPX /* Index: i386/i386/vm_machdep.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/vm_machdep.c,v retrieving revision 1.181 diff -u -r1.181 vm_machdep.c --- i386/i386/vm_machdep.c 12 Feb 2002 05:50:43 -0000 1.181 +++ i386/i386/vm_machdep.c 24 Feb 2002 09:11:16 -0000 @@ -193,6 +193,7 @@ pcb2->pcb_esp = (int)td2->td_frame - sizeof(void *); pcb2->pcb_ebx = (int)td2; /* fork_trampoline argument */ pcb2->pcb_eip = (int)fork_trampoline; + pcb2->pcb_psl = td2->td_frame->tf_eflags & ~PSL_I; /* ints disabled */ /*- * pcb2->pcb_dr*: cloned above. * pcb2->pcb_savefpu: cloned above. Index: i386/include/cpufunc.h =================================================================== RCS file: /home/ncvs/src/sys/i386/include/cpufunc.h,v retrieving revision 1.108 diff -u -r1.108 cpufunc.h --- i386/include/cpufunc.h 12 Feb 2002 21:06:48 -0000 1.108 +++ i386/include/cpufunc.h 24 Feb 2002 03:36:24 -0000 @@ -52,7 +52,11 @@ #define writew(va, d) (*(volatile u_int16_t *) (va) = (d)) #define writel(va, d) (*(volatile u_int32_t *) (va) = (d)) +#if 0 #define CRITICAL_FORK (read_eflags() | PSL_I) +#else +#define MACHINE_CRITICAL_ENTER /* MD code defines critical_enter/exit/fork */ +#endif #ifdef __GNUC__ Index: i386/include/pcb.h =================================================================== RCS file: /home/ncvs/src/sys/i386/include/pcb.h,v retrieving revision 1.41 diff -u -r1.41 pcb.h --- i386/include/pcb.h 17 Jan 2002 17:49:23 -0000 1.41 +++ i386/include/pcb.h 24 Feb 2002 09:06:27 -0000 @@ -69,7 +69,8 @@ caddr_t pcb_onfault; /* copyin/out fault recovery */ int pcb_gs; struct pcb_ext *pcb_ext; /* optional pcb extension */ - u_long __pcb_spare[3]; /* adjust to avoid core dump size changes */ + int pcb_psl; /* process status long */ + u_long __pcb_spare[2]; /* adjust to avoid core dump size changes */ }; /* Index: i386/isa/apic_vector.s =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/apic_vector.s,v retrieving revision 1.75 diff -u -r1.75 apic_vector.s --- i386/isa/apic_vector.s 5 Jan 2002 08:47:10 -0000 1.75 +++ i386/isa/apic_vector.s 24 Feb 2002 17:58:34 -0000 @@ -19,11 +19,19 @@ #define PUSH_FRAME \ pushl $0 ; /* dummy error code */ \ pushl $0 ; /* dummy trap type */ \ - pushal ; \ + pushal ; /* 8 ints */ \ pushl %ds ; /* save data and extra segments ... */ \ pushl %es ; \ pushl %fs +#define PUSH_DUMMY \ + pushfl ; /* eflags */ \ + pushl %cs ; /* cs */ \ + pushl $0 ; /* dummy eip */ \ + pushl $0 ; /* dummy error code */ \ + pushl $0 ; /* dummy trap type */ \ + subl $11*4,%esp ; + #define POP_FRAME \ popl %fs ; \ popl %es ; \ @@ -31,37 +39,8 @@ popal ; \ addl $4+4,%esp -/* - * Macros for interrupt entry, call to handler, and exit. - */ - -#define FAST_INTR(irq_num, vec_name) \ - .text ; \ - SUPERALIGN_TEXT ; \ -IDTVEC(vec_name) ; \ - PUSH_FRAME ; \ - movl $KDSEL,%eax ; \ - mov %ax,%ds ; \ - mov %ax,%es ; \ - movl $KPSEL,%eax ; \ - mov %ax,%fs ; \ - FAKE_MCOUNT(13*4(%esp)) ; \ - call critical_enter ; \ - movl PCPU(CURTHREAD),%ebx ; \ - incl TD_INTR_NESTING_LEVEL(%ebx) ; \ - pushl intr_unit + (irq_num) * 4 ; \ - call *intr_handler + (irq_num) * 4 ; /* do the work ASAP */ \ - addl $4, %esp ; \ - movl $0, lapic+LA_EOI ; \ - lock ; \ - incl cnt+V_INTR ; /* book-keeping can wait */ \ - movl intr_countp + (irq_num) * 4, %eax ; \ - lock ; \ - incl (%eax) ; \ - decl TD_INTR_NESTING_LEVEL(%ebx) ; \ - call critical_exit ; \ - MEXITCOUNT ; \ - jmp doreti +#define POP_DUMMY \ + addl $16*4,%esp #define IOAPICADDR(irq_num) CNAME(int_to_apicintpin) + 16 * (irq_num) + 8 #define REDIRIDX(irq_num) CNAME(int_to_apicintpin) + 16 * (irq_num) + 12 @@ -114,9 +93,9 @@ */ #define UNMASK_IRQ(irq_num) \ ICU_LOCK ; /* into critical reg */ \ - testl $IRQ_BIT(irq_num), _apic_imen ; \ + testl $IRQ_BIT(irq_num), apic_imen ; \ je 7f ; /* bit clear, not masked */ \ - andl $~IRQ_BIT(irq_num), _apic_imen ;/* clear mask bit */ \ + andl $~IRQ_BIT(irq_num), apic_imen ;/* clear mask bit */ \ movl IOAPICADDR(irq_num), %ecx ; /* ioapic addr */ \ movl REDIRIDX(irq_num), %eax ; /* get the index */ \ movl %eax, (%ecx) ; /* write the index */ \ @@ -126,6 +105,92 @@ 7: ; /* already unmasked */ \ ICU_UNLOCK +/* + * Test to see whether we are handling an edge or level triggered INT. + * Level-triggered INTs have to be unmasked. + */ +#define UNMASK_LEVEL_IRQ(irq_num) \ + testl $IRQ_BIT(irq_num), apic_pin_trigger ; \ + jz 9f ; /* edge, don't unmask */ \ + UNMASK_IRQ(irq_num) ; \ +9: + +/* + * Macros for interrupt entry, call to handler, and exit. + */ + +#define FAST_INTR(irq_num, vec_name) \ + .text ; \ + SUPERALIGN_TEXT ; \ +IDTVEC(vec_name) ; \ + PUSH_FRAME ; \ + movl $KDSEL,%eax ; \ + mov %ax,%ds ; \ + mov %ax,%es ; \ + movl $KPSEL,%eax ; \ + mov %ax,%fs ; \ + FAKE_MCOUNT(13*4(%esp)) ; \ + movl PCPU(CURTHREAD),%ebx ; \ + cmpl $0,TD_CRITNEST(%ebx) ; \ + je 1f ; \ +; \ + movl $1,PCPU(INT_PENDING) ; \ + orl $IRQ_BIT(irq_num),PCPU(FPENDING) ; \ + MASK_LEVEL_IRQ(irq_num) ; \ + movl $0, lapic+LA_EOI ; \ + jmp 10f ; \ +1: ; \ + incl TD_CRITNEST(%ebx) ; \ + incl TD_INTR_NESTING_LEVEL(%ebx) ; \ + pushl intr_unit + (irq_num) * 4 ; \ + call *intr_handler + (irq_num) * 4 ; /* do the work ASAP */ \ + addl $4, %esp ; \ + movl $0, lapic+LA_EOI ; \ + lock ; \ + incl cnt+V_INTR ; /* book-keeping can wait */ \ + movl intr_countp + (irq_num) * 4, %eax ; \ + lock ; \ + incl (%eax) ; \ + decl TD_CRITNEST(%ebx) ; \ + cmpl $0,PCPU(INT_PENDING) ; \ + je 2f ; \ +; \ + call unpend ; \ +2: ; \ + decl TD_INTR_NESTING_LEVEL(%ebx) ; \ +10: ; \ + MEXITCOUNT ; \ + jmp doreti + +/* + * Restart a fast interrupt that was held up by a critical section. + * This routine is called from unpend(). unpend() ensures we are + * in a critical section and deals with the interrupt nesting level + * for us. If we previously masked the irq, we have to unmask it. + * + * We have a choice. We can regenerate the irq using the 'int' + * instruction or we can create a dummy frame and call the interrupt + * handler directly. I've chosen to use the dummy-frame method. + */ +#define FAST_UNPEND(irq_num, vec_name) \ + .text ; \ + SUPERALIGN_TEXT ; \ +IDTVEC(vec_name) ; \ +; \ + PUSH_DUMMY ; \ + pushl intr_unit + (irq_num) * 4 ; \ + call *intr_handler + (irq_num) * 4 ; /* do the work ASAP */ \ + addl $4, %esp ; \ + lock ; \ + incl cnt+V_INTR ; /* book-keeping can wait */ \ + movl intr_countp + (irq_num) * 4, %eax ; \ + lock ; \ + incl (%eax) ; \ + UNMASK_LEVEL_IRQ(irq_num) ; \ + POP_DUMMY ; \ + ret ; \ + + /* * Slow, threaded interrupts. * @@ -151,16 +216,27 @@ ; \ MASK_LEVEL_IRQ(irq_num) ; \ EOI_IRQ(irq_num) ; \ -0: ; \ +; \ movl PCPU(CURTHREAD),%ebx ; \ + cmpl $0,TD_CRITNEST(%ebx) ; \ + je 1f ; \ + movl $1,PCPU(INT_PENDING) ; \ + orl $IRQ_BIT(irq_num),PCPU(IPENDING) ; \ + jmp 10f ; \ +1: ; \ incl TD_INTR_NESTING_LEVEL(%ebx) ; \ ; \ FAKE_MCOUNT(13*4(%esp)) ; /* XXX avoid dbl cnt */ \ + cmpl $0,PCPU(INT_PENDING) ; \ + je 9f ; \ + call unpend ; \ +9: ; \ pushl $irq_num; /* pass the IRQ */ \ call sched_ithd ; \ addl $4, %esp ; /* discard the parameter */ \ ; \ decl TD_INTR_NESTING_LEVEL(%ebx) ; \ +10: ; \ MEXITCOUNT ; \ jmp doreti @@ -226,9 +302,16 @@ movl $0, lapic+LA_EOI /* End Of Interrupt to APIC */ movl PCPU(CURTHREAD),%ebx + cmpl $0,TD_CRITNEST(%ebx) + je 1f + movl $1,PCPU(INT_PENDING) + orl $1,PCPU(SPENDING); + jmp 10f +1: incl TD_INTR_NESTING_LEVEL(%ebx) call forwarded_hardclock decl TD_INTR_NESTING_LEVEL(%ebx) +10: MEXITCOUNT jmp doreti @@ -250,10 +333,18 @@ movl $0, lapic+LA_EOI /* End Of Interrupt to APIC */ FAKE_MCOUNT(13*4(%esp)) + movl PCPU(CURTHREAD),%ebx + cmpl $0,TD_CRITNEST(%ebx) + je 1f + movl $1,PCPU(INT_PENDING) + orl $2,PCPU(SPENDING); + jmp 10f +1: incl TD_INTR_NESTING_LEVEL(%ebx) call forwarded_statclock decl TD_INTR_NESTING_LEVEL(%ebx) +10: MEXITCOUNT jmp doreti @@ -417,6 +508,41 @@ INTR(30,intr30,) INTR(31,intr31,) MCOUNT_LABEL(eintr) + +MCOUNT_LABEL(bfunpend) + FAST_UNPEND(0,fastunpend0) + FAST_UNPEND(1,fastunpend1) + FAST_UNPEND(2,fastunpend2) + FAST_UNPEND(3,fastunpend3) + FAST_UNPEND(4,fastunpend4) + FAST_UNPEND(5,fastunpend5) + FAST_UNPEND(6,fastunpend6) + FAST_UNPEND(7,fastunpend7) + FAST_UNPEND(8,fastunpend8) + FAST_UNPEND(9,fastunpend9) + FAST_UNPEND(10,fastunpend10) + FAST_UNPEND(11,fastunpend11) + FAST_UNPEND(12,fastunpend12) + FAST_UNPEND(13,fastunpend13) + FAST_UNPEND(14,fastunpend14) + FAST_UNPEND(15,fastunpend15) + FAST_UNPEND(16,fastunpend16) + FAST_UNPEND(17,fastunpend17) + FAST_UNPEND(18,fastunpend18) + FAST_UNPEND(19,fastunpend19) + FAST_UNPEND(20,fastunpend20) + FAST_UNPEND(21,fastunpend21) + FAST_UNPEND(22,fastunpend22) + FAST_UNPEND(23,fastunpend23) + FAST_UNPEND(24,fastunpend24) + FAST_UNPEND(25,fastunpend25) + FAST_UNPEND(26,fastunpend26) + FAST_UNPEND(27,fastunpend27) + FAST_UNPEND(28,fastunpend28) + FAST_UNPEND(29,fastunpend29) + FAST_UNPEND(30,fastunpend30) + FAST_UNPEND(31,fastunpend31) +MCOUNT_LABEL(efunpend) /* * Executed by a CPU when it receives a RENDEZVOUS IPI from another CPU. Index: i386/isa/clock.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/clock.c,v retrieving revision 1.180 diff -u -r1.180 clock.c --- i386/isa/clock.c 30 Jan 2002 12:41:11 -0000 1.180 +++ i386/isa/clock.c 24 Feb 2002 10:43:58 -0000 @@ -995,6 +995,7 @@ int apic_8254_trial; void *clkdesc; #endif /* APIC_IO */ + critical_t crit; if (statclock_disable) { /* @@ -1029,9 +1030,11 @@ inthand_add("clk", apic_8254_intr, (driver_intr_t *)clkintr, NULL, INTR_TYPE_CLK | INTR_FAST, &clkdesc); + crit = cpu_critical_enter(); mtx_lock_spin(&icu_lock); INTREN(1 << apic_8254_intr); mtx_unlock_spin(&icu_lock); + cpu_critical_exit(crit); #else /* APIC_IO */ @@ -1042,9 +1045,11 @@ */ inthand_add("clk", 0, (driver_intr_t *)clkintr, NULL, INTR_TYPE_CLK | INTR_FAST, NULL); + crit = cpu_critical_enter(); mtx_lock_spin(&icu_lock); INTREN(IRQ0); mtx_unlock_spin(&icu_lock); + cpu_critical_exit(crit); #endif /* APIC_IO */ @@ -1067,6 +1072,7 @@ inthand_add("rtc", 8, (driver_intr_t *)rtcintr, NULL, INTR_TYPE_CLK | INTR_FAST, NULL); + crit = cpu_critical_enter(); mtx_lock_spin(&icu_lock); #ifdef APIC_IO INTREN(APIC_IRQ8); @@ -1074,6 +1080,7 @@ INTREN(IRQ8); #endif /* APIC_IO */ mtx_unlock_spin(&icu_lock); + cpu_critical_exit(crit); writertc(RTC_STATUSB, rtc_statusb); @@ -1090,9 +1097,13 @@ * on the IO APIC. * Workaround: Limited variant of mixed mode. */ + critical_t crit; + + crit = cpu_critical_enter(); mtx_lock_spin(&icu_lock); INTRDIS(1 << apic_8254_intr); mtx_unlock_spin(&icu_lock); + cpu_critical_exit(crit); inthand_remove(clkdesc); printf("APIC_IO: Broken MP table detected: " "8254 is not connected to " @@ -1115,9 +1126,11 @@ inthand_add("clk", apic_8254_intr, (driver_intr_t *)clkintr, NULL, INTR_TYPE_CLK | INTR_FAST, NULL); + crit = cpu_critical_enter(); mtx_lock_spin(&icu_lock); INTREN(1 << apic_8254_intr); mtx_unlock_spin(&icu_lock); + cpu_critical_exit(crit); } } Index: i386/isa/icu_vector.s =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/icu_vector.s,v retrieving revision 1.31 diff -u -r1.31 icu_vector.s --- i386/isa/icu_vector.s 5 Jan 2002 08:47:11 -0000 1.31 +++ i386/isa/icu_vector.s 24 Feb 2002 19:01:27 -0000 @@ -16,17 +16,23 @@ #define ICU_EOI 0x20 /* XXX - define elsewhere */ #define IRQ_BIT(irq_num) (1 << ((irq_num) % 8)) +#define IRQ_LBIT(irq_num) (1 << (irq_num)) #define IRQ_BYTE(irq_num) ((irq_num) >> 3) #ifdef AUTO_EOI_1 + #define ENABLE_ICU1 /* use auto-EOI to reduce i/o */ #define OUTB_ICU1 + #else -#define ENABLE_ICU1 \ - movb $ICU_EOI,%al ; /* as soon as possible send EOI ... */ \ + +#define ENABLE_ICU1 \ + movb $ICU_EOI,%al ; /* as soon as possible send EOI ... */ \ OUTB_ICU1 /* ... to clear in service bit */ -#define OUTB_ICU1 \ + +#define OUTB_ICU1 \ outb %al,$IO_ICU1 + #endif #ifdef AUTO_EOI_2 @@ -34,48 +40,124 @@ * The data sheet says no auto-EOI on slave, but it sometimes works. */ #define ENABLE_ICU1_AND_2 ENABLE_ICU1 + #else -#define ENABLE_ICU1_AND_2 \ - movb $ICU_EOI,%al ; /* as above */ \ - outb %al,$IO_ICU2 ; /* but do second icu first ... */ \ + +#define ENABLE_ICU1_AND_2 \ + movb $ICU_EOI,%al ; /* as above */ \ + outb %al,$IO_ICU2 ; /* but do second icu first ... */ \ OUTB_ICU1 /* ... then first icu (if !AUTO_EOI_1) */ + #endif +#define PUSH_FRAME \ + pushl $0 ; /* dummy error code */ \ + pushl $0 ; /* dummy trap type */ \ + pushal ; /* 8 ints */ \ + pushl %ds ; /* save data and extra segments ... */ \ + pushl %es ; \ + pushl %fs + +#define PUSH_DUMMY \ + pushfl ; /* eflags */ \ + pushl %cs ; /* cs */ \ + pushl $0 ; /* dummy eip */ \ + pushl $0 ; /* dummy error code */ \ + pushl $0 ; /* dummy trap type */ \ + subl $11*4,%esp + +#define POP_FRAME \ + popl %fs ; \ + popl %es ; \ + popl %ds ; \ + popal ; \ + addl $4+4,%esp + +#define POP_DUMMY \ + addl $16*4,%esp + +#define MASK_IRQ(icu, irq_num) \ + movb imen + IRQ_BYTE(irq_num),%al ; \ + orb $IRQ_BIT(irq_num),%al ; \ + movb %al,imen + IRQ_BYTE(irq_num) ; \ + outb %al,$icu+ICU_IMR_OFFSET + +#define UNMASK_IRQ(icu, irq_num) \ + movb imen + IRQ_BYTE(irq_num),%al ; \ + andb $~IRQ_BIT(irq_num),%al ; \ + movb %al,imen + IRQ_BYTE(irq_num) ; \ + outb %al,$icu+ICU_IMR_OFFSET /* * Macros for interrupt interrupt entry, call to handler, and exit. */ -#define FAST_INTR(irq_num, vec_name, enable_icus) \ - .text ; \ - SUPERALIGN_TEXT ; \ -IDTVEC(vec_name) ; \ - pushl $0 ; /* dummy error code */ \ - pushl $0 ; /* dummy trap type */ \ - pushal ; \ - pushl %ds ; \ - pushl %es ; \ - pushl %fs ; \ - mov $KDSEL,%ax ; \ - mov %ax,%ds ; \ - mov %ax,%es ; \ - mov $KPSEL,%ax ; \ - mov %ax,%fs ; \ - FAKE_MCOUNT((12+ACTUALLY_PUSHED)*4(%esp)) ; \ - call critical_enter ; \ - movl PCPU(CURTHREAD),%ebx ; \ - incl TD_INTR_NESTING_LEVEL(%ebx) ; \ - pushl intr_unit + (irq_num) * 4 ; \ - call *intr_handler + (irq_num) * 4 ; /* do the work ASAP */ \ - enable_icus ; /* (re)enable ASAP (helps edge trigger?) */ \ - addl $4,%esp ; \ - incl cnt+V_INTR ; /* book-keeping can wait */ \ - movl intr_countp + (irq_num) * 4,%eax ; \ - incl (%eax) ; \ - decl TD_INTR_NESTING_LEVEL(%ebx) ; \ - call critical_exit ; \ - MEXITCOUNT ; \ +#define FAST_INTR(irq_num, vec_name, icu, enable_icus) \ + .text ; \ + SUPERALIGN_TEXT ; \ +IDTVEC(vec_name) ; \ + PUSH_FRAME ; \ + mov $KDSEL,%ax ; \ + mov %ax,%ds ; \ + mov %ax,%es ; \ + mov $KPSEL,%ax ; \ + mov %ax,%fs ; \ + FAKE_MCOUNT((12+ACTUALLY_PUSHED)*4(%esp)) ; \ + movl PCPU(CURTHREAD),%ebx ; \ + cmpl $0,TD_CRITNEST(%ebx) ; \ + je 1f ; \ +; \ + movl $1,PCPU(INT_PENDING) ; \ + orl $IRQ_LBIT(irq_num),PCPU(FPENDING) ; \ + MASK_IRQ(icu, irq_num) ; \ + enable_icus ; \ + jmp 10f ; \ +1: ; \ + incl TD_CRITNEST(%ebx) ; \ + incl TD_INTR_NESTING_LEVEL(%ebx) ; \ + pushl intr_unit + (irq_num) * 4 ; \ + call *intr_handler + (irq_num) * 4 ; \ + addl $4,%esp ; \ + enable_icus ; \ + incl cnt+V_INTR ; /* book-keeping can wait */ \ + movl intr_countp + (irq_num) * 4,%eax ; \ + incl (%eax) ; \ + decl TD_CRITNEST(%ebx) ; \ + cmpl $0,PCPU(INT_PENDING) ; \ + je 2f ; \ +; \ + call unpend ; \ +2: ; \ + decl TD_INTR_NESTING_LEVEL(%ebx) ; \ +10: ; \ + MEXITCOUNT ; \ jmp doreti +/* + * Restart a fast interrupt that was held up by a critical section. + * This routine is called from unpend(). unpend() ensures we are + * in a critical section and deals with the interrupt nesting level + * for us. If we previously masked the irq, we have to unmask it. + * + * We have a choice. We can regenerate the irq using the 'int' + * instruction or we can create a dummy frame and call the interrupt + * handler directly. I've chosen to use the dummy-frame method. + */ +#define FAST_UNPEND(irq_num, vec_name, icu) \ + .text ; \ + SUPERALIGN_TEXT ; \ +IDTVEC(vec_name) ; \ +; \ + PUSH_DUMMY ; \ + pushl intr_unit + (irq_num) * 4 ; \ + call *intr_handler + (irq_num) * 4 ; /* do the work ASAP */ \ + addl $4, %esp ; \ + incl cnt+V_INTR ; /* book-keeping can wait */ \ + movl intr_countp + (irq_num) * 4,%eax ; \ + incl (%eax) ; \ + UNMASK_IRQ(icu, irq_num) ; \ + POP_DUMMY ; \ + ret + /* * Slow, threaded interrupts. * @@ -85,74 +167,100 @@ * interrupt handler and don't run anything. We could just do an * iret. FIXME. */ -#define INTR(irq_num, vec_name, icu, enable_icus, reg, maybe_extra_ipending) \ - .text ; \ - SUPERALIGN_TEXT ; \ -IDTVEC(vec_name) ; \ - pushl $0 ; /* dummy error code */ \ - pushl $0 ; /* dummy trap type */ \ - pushal ; \ - pushl %ds ; /* save our data and extra segments ... */ \ - pushl %es ; \ - pushl %fs ; \ - mov $KDSEL,%ax ; /* load kernel ds, es and fs */ \ - mov %ax,%ds ; \ - mov %ax,%es ; \ - mov $KPSEL,%ax ; \ - mov %ax,%fs ; \ - maybe_extra_ipending ; \ - movb imen + IRQ_BYTE(irq_num),%al ; \ - orb $IRQ_BIT(irq_num),%al ; \ - movb %al,imen + IRQ_BYTE(irq_num) ; \ - outb %al,$icu+ICU_IMR_OFFSET ; \ - enable_icus ; \ - movl PCPU(CURTHREAD),%ebx ; \ - incl TD_INTR_NESTING_LEVEL(%ebx) ; \ +#define INTR(irq_num, vec_name, icu, enable_icus, maybe_extra_ipending) \ + .text ; \ + SUPERALIGN_TEXT ; \ +IDTVEC(vec_name) ; \ + PUSH_FRAME ; \ + mov $KDSEL,%ax ; /* load kernel ds, es and fs */ \ + mov %ax,%ds ; \ + mov %ax,%es ; \ + mov $KPSEL,%ax ; \ + mov %ax,%fs ; \ +; \ + maybe_extra_ipending ; \ + MASK_IRQ(icu, irq_num) ; \ + enable_icus ; \ +; \ + movl PCPU(CURTHREAD),%ebx ; \ + cmpl $0,TD_CRITNEST(%ebx) ; \ + je 1f ; \ + movl $1,PCPU(INT_PENDING); \ + orl $IRQ_LBIT(irq_num),PCPU(IPENDING) ; \ + jmp 10f ; \ +1: ; \ + incl TD_INTR_NESTING_LEVEL(%ebx) ; \ +; \ FAKE_MCOUNT(13*4(%esp)) ; /* XXX late to avoid double count */ \ - pushl $irq_num; /* pass the IRQ */ \ - call sched_ithd ; \ - addl $4, %esp ; /* discard the parameter */ \ - decl TD_INTR_NESTING_LEVEL(%ebx) ; \ - MEXITCOUNT ; \ - /* We could usually avoid the following jmp by inlining some of */ \ - /* doreti, but it's probably better to use less cache. */ \ - jmp doreti /* and catch up inside doreti */ + cmpl $0,PCPU(INT_PENDING) ; \ + je 9f ; \ + call unpend ; \ +9: ; \ + pushl $irq_num; /* pass the IRQ */ \ + call sched_ithd ; \ + addl $4, %esp ; /* discard the parameter */ \ +; \ + decl TD_INTR_NESTING_LEVEL(%ebx) ; \ +10: ; \ + MEXITCOUNT ; \ + jmp doreti MCOUNT_LABEL(bintr) - FAST_INTR(0,fastintr0, ENABLE_ICU1) - FAST_INTR(1,fastintr1, ENABLE_ICU1) - FAST_INTR(2,fastintr2, ENABLE_ICU1) - FAST_INTR(3,fastintr3, ENABLE_ICU1) - FAST_INTR(4,fastintr4, ENABLE_ICU1) - FAST_INTR(5,fastintr5, ENABLE_ICU1) - FAST_INTR(6,fastintr6, ENABLE_ICU1) - FAST_INTR(7,fastintr7, ENABLE_ICU1) - FAST_INTR(8,fastintr8, ENABLE_ICU1_AND_2) - FAST_INTR(9,fastintr9, ENABLE_ICU1_AND_2) - FAST_INTR(10,fastintr10, ENABLE_ICU1_AND_2) - FAST_INTR(11,fastintr11, ENABLE_ICU1_AND_2) - FAST_INTR(12,fastintr12, ENABLE_ICU1_AND_2) - FAST_INTR(13,fastintr13, ENABLE_ICU1_AND_2) - FAST_INTR(14,fastintr14, ENABLE_ICU1_AND_2) - FAST_INTR(15,fastintr15, ENABLE_ICU1_AND_2) + FAST_INTR(0,fastintr0, IO_ICU1, ENABLE_ICU1) + FAST_INTR(1,fastintr1, IO_ICU1, ENABLE_ICU1) + FAST_INTR(2,fastintr2, IO_ICU1, ENABLE_ICU1) + FAST_INTR(3,fastintr3, IO_ICU1, ENABLE_ICU1) + FAST_INTR(4,fastintr4, IO_ICU1, ENABLE_ICU1) + FAST_INTR(5,fastintr5, IO_ICU1, ENABLE_ICU1) + FAST_INTR(6,fastintr6, IO_ICU1, ENABLE_ICU1) + FAST_INTR(7,fastintr7, IO_ICU1, ENABLE_ICU1) + FAST_INTR(8,fastintr8, IO_ICU2, ENABLE_ICU1_AND_2) + FAST_INTR(9,fastintr9, IO_ICU2, ENABLE_ICU1_AND_2) + FAST_INTR(10,fastintr10, IO_ICU2, ENABLE_ICU1_AND_2) + FAST_INTR(11,fastintr11, IO_ICU2, ENABLE_ICU1_AND_2) + FAST_INTR(12,fastintr12, IO_ICU2, ENABLE_ICU1_AND_2) + FAST_INTR(13,fastintr13, IO_ICU2, ENABLE_ICU1_AND_2) + FAST_INTR(14,fastintr14, IO_ICU2, ENABLE_ICU1_AND_2) + FAST_INTR(15,fastintr15, IO_ICU2, ENABLE_ICU1_AND_2) #define CLKINTR_PENDING movl $1,CNAME(clkintr_pending) /* Threaded interrupts */ - INTR(0,intr0, IO_ICU1, ENABLE_ICU1, al, CLKINTR_PENDING) - INTR(1,intr1, IO_ICU1, ENABLE_ICU1, al,) - INTR(2,intr2, IO_ICU1, ENABLE_ICU1, al,) - INTR(3,intr3, IO_ICU1, ENABLE_ICU1, al,) - INTR(4,intr4, IO_ICU1, ENABLE_ICU1, al,) - INTR(5,intr5, IO_ICU1, ENABLE_ICU1, al,) - INTR(6,intr6, IO_ICU1, ENABLE_ICU1, al,) - INTR(7,intr7, IO_ICU1, ENABLE_ICU1, al,) - INTR(8,intr8, IO_ICU2, ENABLE_ICU1_AND_2, ah,) - INTR(9,intr9, IO_ICU2, ENABLE_ICU1_AND_2, ah,) - INTR(10,intr10, IO_ICU2, ENABLE_ICU1_AND_2, ah,) - INTR(11,intr11, IO_ICU2, ENABLE_ICU1_AND_2, ah,) - INTR(12,intr12, IO_ICU2, ENABLE_ICU1_AND_2, ah,) - INTR(13,intr13, IO_ICU2, ENABLE_ICU1_AND_2, ah,) - INTR(14,intr14, IO_ICU2, ENABLE_ICU1_AND_2, ah,) - INTR(15,intr15, IO_ICU2, ENABLE_ICU1_AND_2, ah,) + INTR(0,intr0, IO_ICU1, ENABLE_ICU1, CLKINTR_PENDING) + INTR(1,intr1, IO_ICU1, ENABLE_ICU1,) + INTR(2,intr2, IO_ICU1, ENABLE_ICU1,) + INTR(3,intr3, IO_ICU1, ENABLE_ICU1,) + INTR(4,intr4, IO_ICU1, ENABLE_ICU1,) + INTR(5,intr5, IO_ICU1, ENABLE_ICU1,) + INTR(6,intr6, IO_ICU1, ENABLE_ICU1,) + INTR(7,intr7, IO_ICU1, ENABLE_ICU1,) + INTR(8,intr8, IO_ICU2, ENABLE_ICU1_AND_2,) + INTR(9,intr9, IO_ICU2, ENABLE_ICU1_AND_2,) + INTR(10,intr10, IO_ICU2, ENABLE_ICU1_AND_2,) + INTR(11,intr11, IO_ICU2, ENABLE_ICU1_AND_2,) + INTR(12,intr12, IO_ICU2, ENABLE_ICU1_AND_2,) + INTR(13,intr13, IO_ICU2, ENABLE_ICU1_AND_2,) + INTR(14,intr14, IO_ICU2, ENABLE_ICU1_AND_2,) + INTR(15,intr15, IO_ICU2, ENABLE_ICU1_AND_2,) MCOUNT_LABEL(eintr) + +MCOUNT_LABEL(bfunpend) + FAST_UNPEND(0,fastunpend0, IO_ICU1) + FAST_UNPEND(1,fastunpend1, IO_ICU1) + FAST_UNPEND(2,fastunpend2, IO_ICU1) + FAST_UNPEND(3,fastunpend3, IO_ICU1) + FAST_UNPEND(4,fastunpend4, IO_ICU1) + FAST_UNPEND(5,fastunpend5, IO_ICU1) + FAST_UNPEND(6,fastunpend6, IO_ICU1) + FAST_UNPEND(7,fastunpend7, IO_ICU1) + FAST_UNPEND(8,fastunpend8, IO_ICU2) + FAST_UNPEND(9,fastunpend9, IO_ICU2) + FAST_UNPEND(10,fastunpend10, IO_ICU2) + FAST_UNPEND(11,fastunpend11, IO_ICU2) + FAST_UNPEND(12,fastunpend12, IO_ICU2) + FAST_UNPEND(13,fastunpend13, IO_ICU2) + FAST_UNPEND(14,fastunpend14, IO_ICU2) + FAST_UNPEND(15,fastunpend15, IO_ICU2) +MCOUNT_LABEL(efunpend) + + Index: i386/isa/intr_machdep.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/intr_machdep.c,v retrieving revision 1.65 diff -u -r1.65 intr_machdep.c --- i386/isa/intr_machdep.c 8 Feb 2002 18:30:35 -0000 1.65 +++ i386/isa/intr_machdep.c 24 Feb 2002 10:50:26 -0000 @@ -117,6 +117,27 @@ #endif /* APIC_IO */ }; +static unpendhand_t *fastunpend[ICU_LEN] = { + &IDTVEC(fastunpend0), &IDTVEC(fastunpend1), + &IDTVEC(fastunpend2), &IDTVEC(fastunpend3), + &IDTVEC(fastunpend4), &IDTVEC(fastunpend5), + &IDTVEC(fastunpend6), &IDTVEC(fastunpend7), + &IDTVEC(fastunpend8), &IDTVEC(fastunpend9), + &IDTVEC(fastunpend10), &IDTVEC(fastunpend11), + &IDTVEC(fastunpend12), &IDTVEC(fastunpend13), + &IDTVEC(fastunpend14), &IDTVEC(fastunpend15), +#if defined(APIC_IO) + &IDTVEC(fastunpend16), &IDTVEC(fastunpend17), + &IDTVEC(fastunpend18), &IDTVEC(fastunpend19), + &IDTVEC(fastunpend20), &IDTVEC(fastunpend21), + &IDTVEC(fastunpend22), &IDTVEC(fastunpend23), + &IDTVEC(fastunpend24), &IDTVEC(fastunpend25), + &IDTVEC(fastunpend26), &IDTVEC(fastunpend27), + &IDTVEC(fastunpend28), &IDTVEC(fastunpend29), + &IDTVEC(fastunpend30), &IDTVEC(fastunpend31), +#endif /* APIC_IO */ +}; + static inthand_t *slowintr[ICU_LEN] = { &IDTVEC(intr0), &IDTVEC(intr1), &IDTVEC(intr2), &IDTVEC(intr3), &IDTVEC(intr4), &IDTVEC(intr5), &IDTVEC(intr6), &IDTVEC(intr7), @@ -291,13 +312,16 @@ void icu_reinit() { int i; + critical_t crit; + crit = cpu_critical_enter(); mtx_lock_spin(&icu_lock); init_i8259(); for(i=0;i= ICU_LEN) /* no 8259 SLAVE to ignore */ @@ -488,6 +516,7 @@ return (EBUSY); #endif + crit = cpu_critical_enter(); mtx_lock_spin(&icu_lock); intr_handler[intr] = handler; intr_unit[intr] = arg; @@ -530,6 +559,7 @@ #endif /* FAST_HI */ INTREN(1 << intr); mtx_unlock_spin(&icu_lock); + cpu_critical_exit(crit); return (0); } @@ -543,10 +573,12 @@ int intr; driver_intr_t *handler; { + critical_t crit; if ((u_int)intr >= ICU_LEN || handler != intr_handler[intr]) return (EINVAL); + crit = cpu_critical_enter(); mtx_lock_spin(&icu_lock); INTRDIS(1 << intr); intr_countp[intr] = &intrcnt[1 + intr]; @@ -564,6 +596,7 @@ GSEL(GCODE_SEL, SEL_KPL)); #endif /* FAST_HI */ mtx_unlock_spin(&icu_lock); + cpu_critical_exit(crit); return (0); } @@ -578,19 +611,25 @@ static void ithread_enable(int vector) { + critical_t crit; + crit = cpu_critical_enter(); mtx_lock_spin(&icu_lock); INTREN(1 << vector); mtx_unlock_spin(&icu_lock); + cpu_critical_exit(crit); } static void ithread_disable(int vector) { + critical_t crit; + crit = cpu_critical_enter(); mtx_lock_spin(&icu_lock); INTRDIS(1 << vector); mtx_unlock_spin(&icu_lock); + cpu_critical_exit(crit); } int @@ -672,3 +711,10 @@ return (ithread_remove_handler(cookie)); } + +void +call_fast_unpend(int irq) +{ + fastunpend[irq](); +} + Index: i386/isa/intr_machdep.h =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/intr_machdep.h,v retrieving revision 1.33 diff -u -r1.33 intr_machdep.h --- i386/isa/intr_machdep.h 20 Dec 2001 23:48:30 -0000 1.33 +++ i386/isa/intr_machdep.h 24 Feb 2002 05:55:23 -0000 @@ -140,6 +140,7 @@ * Type of the first (asm) part of an interrupt handler. */ typedef void inthand_t __P((u_int cs, u_int ef, u_int esp, u_int ss)); +typedef void unpendhand_t __P((void)); #define IDTVEC(name) __CONCAT(X,name) @@ -163,6 +164,18 @@ IDTVEC(intr4), IDTVEC(intr5), IDTVEC(intr6), IDTVEC(intr7), IDTVEC(intr8), IDTVEC(intr9), IDTVEC(intr10), IDTVEC(intr11), IDTVEC(intr12), IDTVEC(intr13), IDTVEC(intr14), IDTVEC(intr15); +unpendhand_t + IDTVEC(fastunpend0), IDTVEC(fastunpend1), IDTVEC(fastunpend2), + IDTVEC(fastunpend3), IDTVEC(fastunpend4), IDTVEC(fastunpend5), + IDTVEC(fastunpend6), IDTVEC(fastunpend7), IDTVEC(fastunpend8), + IDTVEC(fastunpend9), IDTVEC(fastunpend10), IDTVEC(fastunpend11), + IDTVEC(fastunpend12), IDTVEC(fastunpend13), IDTVEC(fastunpend14), + IDTVEC(fastunpend15), IDTVEC(fastunpend16), IDTVEC(fastunpend17), + IDTVEC(fastunpend18), IDTVEC(fastunpend19), IDTVEC(fastunpend20), + IDTVEC(fastunpend21), IDTVEC(fastunpend22), IDTVEC(fastunpend23), + IDTVEC(fastunpend24), IDTVEC(fastunpend25), IDTVEC(fastunpend26), + IDTVEC(fastunpend27), IDTVEC(fastunpend28), IDTVEC(fastunpend29), + IDTVEC(fastunpend30), IDTVEC(fastunpend31); #if defined(SMP) || defined(APIC_IO) inthand_t @@ -228,6 +241,7 @@ enum intr_type flags, void **cookiep); int inthand_remove(void *cookie); void sched_ithd(void *dummy); +void call_fast_unpend(int irq); #endif /* LOCORE */ Index: i386/isa/npx.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/npx.c,v retrieving revision 1.123 diff -u -r1.123 npx.c --- i386/isa/npx.c 30 Jan 2002 12:41:11 -0000 1.123 +++ i386/isa/npx.c 24 Feb 2002 10:50:55 -0000 @@ -429,9 +429,15 @@ * XXX hack around brokenness of bus_teardown_intr(). If we left the * irq active then we would get it instead of exception 16. */ - mtx_lock_spin(&icu_lock); - INTRDIS(1 << irq_num); - mtx_unlock_spin(&icu_lock); + { + critical_t crit; + + crit = cpu_critical_enter(); + mtx_lock_spin(&icu_lock); + INTRDIS(1 << irq_num); + mtx_unlock_spin(&icu_lock); + cpu_critical_exit(crit); + } bus_release_resource(dev, SYS_RES_IRQ, irq_rid, irq_res); bus_release_resource(dev, SYS_RES_IOPORT, ioport_rid, ioport_res); Index: kern/kern_fork.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_fork.c,v retrieving revision 1.135 diff -u -r1.135 kern_fork.c --- kern/kern_fork.c 23 Feb 2002 11:12:53 -0000 1.135 +++ kern/kern_fork.c 24 Feb 2002 05:57:59 -0000 @@ -777,12 +777,19 @@ td->td_kse->ke_oncpu = PCPU_GET(cpuid); /* - * Setup the sched_lock state so that we can release it. + * Setup the sched_lock state so that we can release it. If + * MACHINE_CRITICAL_ENTER is set by the MD architecture, the + * trampoline returns with the critical section pre-set. + * XXX note: all architectures should do this, because this code + * improperly assumes that a critical section == hard interrupt + * disablement on entry, which is not necessarily true. */ sched_lock.mtx_lock = (uintptr_t)td; sched_lock.mtx_recurse = 0; +#ifndef MACHINE_CRITICAL_ENTER td->td_critnest = 1; td->td_savecrit = CRITICAL_FORK; +#endif CTR3(KTR_PROC, "fork_exit: new proc %p (pid %d, %s)", p, p->p_pid, p->p_comm); if (PCPU_GET(switchtime.sec) == 0) Index: kern/kern_switch.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_switch.c,v retrieving revision 1.20 diff -u -r1.20 kern_switch.c --- kern/kern_switch.c 11 Feb 2002 20:37:51 -0000 1.20 +++ kern/kern_switch.c 24 Feb 2002 03:03:38 -0000 @@ -69,6 +69,8 @@ runq_add(&runq, td->td_kse); } +#ifndef MACHINE_CRITICAL_ENTER + /* Critical sections that prevent preemption. */ void critical_enter(void) @@ -93,6 +95,8 @@ } else td->td_critnest--; } + +#endif /* * Clear the status bit of the queue corresponding to priority level pri, Index: sys/pcpu.h =================================================================== RCS file: /home/ncvs/src/sys/sys/pcpu.h,v retrieving revision 1.4 diff -u -r1.4 pcpu.h --- sys/pcpu.h 22 Feb 2002 13:32:01 -0000 1.4 +++ sys/pcpu.h 24 Feb 2002 08:01:06 -0000 @@ -57,6 +57,10 @@ u_int pc_cpuid; /* This cpu number */ u_int pc_cpumask; /* This cpu mask */ u_int pc_other_cpus; /* Mask of all other cpus */ + u_int32_t pc_int_pending; /* master int pending flag */ + u_int32_t pc_ipending; /* pending slow interrupts */ + u_int32_t pc_fpending; /* pending fast interrupts */ + u_int32_t pc_spending; /* pending soft interrupts */ SLIST_ENTRY(pcpu) pc_allcpu; struct lock_list_entry *pc_spinlocks; #ifdef KTR_PERCPU To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 11:14: 6 2002 Delivered-To: freebsd-current@freebsd.org Received: from tank.siteone.net (tank.siteone.net [146.145.78.19]) by hub.freebsd.org (Postfix) with SMTP id F27B837B405 for ; Sun, 24 Feb 2002 11:13:59 -0800 (PST) Received: (qmail 46119 invoked by uid 0); 24 Feb 2002 19:15:18 -0000 Received: from bgp491461bgs.verona01.nj.comcast.net (HELO brianlaptop) (68.37.201.250) by smtp.siteone.net with SMTP; 24 Feb 2002 19:15:18 -0000 Message-ID: <001201c1bd67$1a490a00$b900000a@brianlaptop> From: "Brian K. White" To: References: <20020224042210.GC4789@hades.hell.gr> <20020224180426.GA406@fonix.adamsfamily.xx> Subject: Re: -CURRENT in pretty good shape, after all Date: Sun, 24 Feb 2002 14:11:45 -0500 Organization: Aljex Software MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 ----- Original Message ----- From: "Szilveszter Adam" To: Sent: Sunday, February 24, 2002 1:04 PM Subject: Re: -CURRENT in pretty good shape, after all > On Sun, Feb 24, 2002 at 06:22:11AM +0200, Giorgos Keramidas wrote: > > It does work perfectly nice for me too, here. I've been building worlds > > without a single problem ever since Feb 7, 2002. Oh, and since I like > > living in the edge, I erased my 4-STABLE installation on Feb 10, and > > formatted that partition. Now I use it as /c, a workspace where temporary > > development work is done. > > Well, just to put my "Me too!" here. I have been following 5.x for as > long as it existed and during all this exercise, I have found it to be > fairly useable at all times. There were some bumps along the road, but > nothing that a careful study of this and other mailing lists would not > have solved. In fact, ever since 5.x branched from 4.0 way back when:-) > it was the only installation of FreeBSD that I had on my workstation. > > I wrote my university thesis on this machine, while religiously keeping > up with the latest and greatest -CURRENT source, the box has served as a > dialup and later as an ADSL gateway without problems. Of course, > debugging code has slowed it down at times but that was expected. > > Although I do not consider myself a developer/programmer, I always tried > to report problems in a useful way when found. It is just that I did not > have a lot to do on this front:-) (Maybe I am the kind of user who > should start using -CURRENT in greater numbers? OK, I'm here already:-) > > This machine is a PII-233 UP, with an Intel 440-LX based mobo and only > IDE peripherals. It is no longer "state of the art" or even close, but, > thanks to FreeBSD, it runs as snappy as ever. > > > Thank you all, who have put efforts in making this happen! > > Indeed. It is really refreshing to see that, despite occasional > ramblimngs and otbreaks of flame on the lists, the project really makes > headway, especially looked at from a historical perspective. > > Keep up the good work! > > P.S.: This message is also test to see if the upgrade to the latest > sendmail worked well:-) another "me too" I have had a 5.0 box running continuously for several months, I don't use the box much but I do use it a little at least a few times a day. It just sits there on my cable modem at home and I use it as a samba (pre-3.0beta) server for mp3's at home, or via http/ftp from work. It's been running seti@home since day one, I use it to test ssh and rsync procedures and other miscelaneous things where I need a unix box to try something on and don't want to use a customers machine. I have done a couple buildworlds and buildkernels but only a couple and not in months, but it went without a hitch. I have built a few ports like vnc and samba, again no hitches and again the results have also been running for months. there was a problem with my mouse for a while, I applied a patch from a post on this list, rebuilt and no more mouse problem. all in all, it's been just great for me even though it's a pretty old -CURRENT. oh and the hardware is just a crappy emachine with an amd k6-2 350 (running at 385) that was a desktop win98 machine at a customers that they threw away for being too old and slow. I just put in a new power supply and a little ram and it's been a damned fine freebsd box for me. neven gnome and enlightenment and gimp and netscape et al are fast enough to be useable, although I did disable gnome and E in favor of icewm just on general principle. Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/ +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 11:14:40 2002 Delivered-To: freebsd-current@freebsd.org Received: from etek.chalmers.se (quarl0.etek.chalmers.se [129.16.32.20]) by hub.freebsd.org (Postfix) with ESMTP id EE50D37B416; Sun, 24 Feb 2002 11:14:14 -0800 (PST) Received: from downy.etek.chalmers.se (_7-268@downy.etek.chalmers.se [129.16.32.207]) by etek.chalmers.se (8.10.0/8.8.8) with ESMTP id g1OJEDV28686; Sun, 24 Feb 2002 20:14:13 +0100 (MET) Received: from localhost (b@localhost) by downy.etek.chalmers.se (8.10.0/8.10.0) with ESMTP id g1OJEDu09112; Sun, 24 Feb 2002 20:14:13 +0100 (MET) Date: Sun, 24 Feb 2002 20:14:12 +0100 (MET) From: Magnus B{ckstr|m To: Mike Smith Cc: current@freebsd.org Subject: Re: HEADS UP: ACPI CA updated In-Reply-To: <20020222215647.A54975@hub.freebsd.org> 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 Wow! This did away with the once-a-minute error messages from Notify()s on processor objects on my laptop. However, I am now getting frequent panics from from a GIANT_REQUIRED assertion in kmem_malloc(). kmem_malloc() gets called via malloc() from AcpiOsAllocate(), without Giant locked. The call to AcpiOsAllocate() happens deep in a AML object evaluation in from acpi_tz_thread(). I tried naively to modify AcpiOsAllocate to grab Giant before malloc() and release it afterward, but this appears to be a very bad idea: There is a mtx_assert(&Giant, MA_NOTOWNED) in ithread_loop() in kern/kern_intr.c which blows up during boot. Regards, Magnus On Fri, 22 Feb 2002, Mike Smith wrote: > Subject: HEADS UP: ACPI CA updated > > > I've finally updated the ACPI CA codebase with Intel's 20020214 drop > (yes, I tagged it 0217, my bad). > > This is the first drop that Intel haven't asked me not to commit since > the 20011120 version, so there are a large number of changes and > bugfixes. See Intel's logs at > http://developer.intel.com/technology/iapc/acpi for more details. > > There aren't many changes in the FreeBSD-specific code, this is just > catching up with major improvements in the interpreter. > > As usual, please report any problems or success to the list. > > Regards, > Mike > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 11:29:31 2002 Delivered-To: freebsd-current@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id 854A937B402 for ; Sun, 24 Feb 2002 11:29:27 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id 4A03F492; Sun, 24 Feb 2002 19:29:07 +0000 (GMT) Date: Sun, 24 Feb 2002 19:29:07 +0000 From: Josef Karthauser To: Dag-Erling Smorgrav Cc: current@freebsd.org Subject: Re: -CURRENT in pretty good shape, after all Message-ID: <20020224192907.GA16523@genius.tao.org.uk> Mail-Followup-To: Josef Karthauser , Dag-Erling Smorgrav , current@freebsd.org References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i 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 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Feb 23, 2002 at 06:24:39PM +0100, Dag-Erling Smorgrav wrote: > Thumbs up and big cheers to all of you (well, us) guys working on > -CURRENT. It's pretty stable and has been for a while now - and even > on my poor old 350 MHz K6-2, it performs well enough to make a kickass > desktop & development platform. Let's hope it'll only get better from > here on out :) Hear hear (or is that hear here?). I've been running current on my laptop since the first FreeBSDCon, and over all I'm pretty happy with it. I rebooted onto a new kernel a few days ago, but before that I'd amassed over three weeks of uptime on the laptop with no problems at all - terrific. (Three weeks on a laptop? Maybe I should get out more). Joe --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjx5PwIACgkQXVIcjOaxUBbsUQCeJVxf5nCC6Hp8uzx0u6HL2Jwd 2p4AoM1c61C0B5C8mJxXeakGmnGpa1Uu =J+yf -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 11:47: 6 2002 Delivered-To: freebsd-current@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id D380637B419; Sun, 24 Feb 2002 11:46:47 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id g1OJkgD93364; Sun, 24 Feb 2002 14:46:42 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 24 Feb 2002 14:46:41 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Alfred Perlstein Cc: Matthew Dillon , Bosko Milekic , Seigo Tanimura , current@FreeBSD.ORG, John Baldwin Subject: Re: malloc_bucket() idea (was Re: How to fix malloc.) In-Reply-To: <20020224004347.GN80761@elvis.mu.org> 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 Sat, 23 Feb 2002, Alfred Perlstein wrote: > Usually when I see diff(1) output from you I usually expect a commit > within the next half hour or so, I just wanted to make myself clear on > the issue. No worries. :) > > Yes, and hopefully JeffR's allocator will fix our problems, that is if > it ever makes it out of p4. :) That assumes that it was actually in P4 in the first place. Jeffr's commit bit was approved in the last two days, and he's begun posting his patches to -arch. I hope to see his memory allocator patch there soon :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 12:18:54 2002 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id 10D8037B400 for ; Sun, 24 Feb 2002 12:18:51 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g1OKIUG00719; Sun, 24 Feb 2002 12:18:30 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200202242018.g1OKIUG00719@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Magnus B{ckstr|m Cc: current@freebsd.org Subject: Re: HEADS UP: ACPI CA updated In-reply-to: Your message of "Sun, 24 Feb 2002 20:14:12 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 24 Feb 2002 12:18:30 -0800 From: Michael Smith 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 > Wow! This did away with the once-a-minute error messages from Notify()s > on processor objects on my laptop. > > However, I am now getting frequent panics from from a GIANT_REQUIRED > assertion in kmem_malloc(). kmem_malloc() gets called via malloc() from > AcpiOsAllocate(), without Giant locked. > > The call to AcpiOsAllocate() happens deep in a AML object evaluation > in from acpi_tz_thread(). > > I tried naively to modify AcpiOsAllocate to grab Giant before malloc() > and release it afterward, but this appears to be a very bad idea: There > is a mtx_assert(&Giant, MA_NOTOWNED) in ithread_loop() in kern/kern_intr.c > which blows up during boot. Try grabbing Giant in acpi_tz_thread when it wakes up, then dropping it again before it goes to sleep. This is probably a hack, but I'd guess a required one for now. If that works, send me a diff and I'll commit it with thanks! Regards, Mike -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 12:22: 1 2002 Delivered-To: freebsd-current@freebsd.org Received: from ns.ulstu.ru (ns.ulstu.ru [62.76.34.36]) by hub.freebsd.org (Postfix) with ESMTP id E080137B400 for ; Sun, 24 Feb 2002 12:21:55 -0800 (PST) Received: by ns.ulstu.ru (Postfix-ULSTU, from userid 3909) id 7D60410780C; Sun, 24 Feb 2002 23:21:53 +0300 (MSK) Date: Sun, 24 Feb 2002 23:21:53 +0300 From: zhuravlev alexander To: current@freebsd.org Subject: can't assign resources Message-ID: <20020224232153.A95673@ns.ulstu.ru> Reply-To: zhuravlev alexander Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i 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 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi ! [zaa:/u/zaa]>uname -a FreeBSD zaa.ulstu.ru 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sun Feb 24 22:38:36 MSK 2002 root@zaa.ulstu.ru:/usr/src/sys/i386/compile/GENERIC i386 --------- /var/run/dmesg.boot ----------- sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources ad0: 4125MB [8940/15/63] at ata0-master UDMA33 acd0: CDROM at ata0-slave PIO4 Mounting root from ufs:/dev/ad0s2a ----------------- end -------------------- is this normal ? full dmesg.boot attached. -- zhuravlev alexander u l s t u n o c e-mail:zaa@ulstu.ru --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.boot" Copyright (c) 1992-2002 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 #0: Sun Feb 24 22:38:36 MSK 2002 root@zaa.ulstu.ru:/usr/src/sys/i386/compile/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc052a000. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 266616007 Hz CPU: Pentium II/Pentium II Xeon/Celeron (266.62-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x634 Stepping = 4 Features=0x80fbff real memory = 134217728 (131072K bytes) avail memory = 125222912 (122288K bytes) Pentium Pro MTRR support enabled 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 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xdf80-0xdf9f irq 10 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) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it atkbdc0: at port 0x64,0x60 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources ad0: 4125MB [8940/15/63] at ata0-master UDMA33 acd0: CDROM at ata0-slave PIO4 Mounting root from ufs:/dev/ad0s2a --TB36FDmn/VVEgNH/-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 13: 7: 7 2002 Delivered-To: freebsd-current@freebsd.org Received: from zebra.siol.net (zebra.siol.net [193.189.160.16]) by hub.freebsd.org (Postfix) with ESMTP id A7B5537B405 for ; Sun, 24 Feb 2002 13:07:04 -0800 (PST) Received: from [213.250.14.40] by zebra.siol.net (InterMail vK.4.03.04.00 201-232-130 license 5ac1ec526f2360901e54ffce7671dc4c) with ESMTP id <20020224210629.PTYI6894.zebra@[213.250.14.40]> for ; Sun, 24 Feb 2002 22:06:29 +0100 Date: Sun, 24 Feb 2002 22:07:01 +0100 From: Uros Gruber X-Mailer: The Bat! (v1.53d) Reply-To: Uros Gruber Organization: Slovenska Internet Revija X-Priority: 3 (Normal) Message-ID: <28129300013.20020224220701@sir-mag.com> To: freebsd-current@freebsd.org Subject: Locale in FreeBSD 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! I wan't to know when will be suported LC_NUMERIC and LC_MONETARY in FreeBSD, not hardcoded to C lang. -- bye, Uros To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 13:12:33 2002 Delivered-To: freebsd-current@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 51F0B37B404 for ; Sun, 24 Feb 2002 13:12:28 -0800 (PST) Received: from pool0309.cvx40-bradley.dialup.earthlink.net ([216.244.43.54] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16f5wJ-0005tU-00; Sun, 24 Feb 2002 13:12:11 -0800 Message-ID: <3C795720.5EEA58F6@mindspring.com> Date: Sun, 24 Feb 2002 13:12:00 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: zhuravlev alexander Cc: current@freebsd.org Subject: [Patch: clarity] Re: can't assign resources References: <20020224232153.A95673@ns.ulstu.ru> Content-Type: multipart/mixed; boundary="------------741846253D1D9002AE8EAD96" 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 This is a multi-part message in MIME format. --------------741846253D1D9002AE8EAD96 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit zhuravlev alexander wrote: > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > unknown: can't assign resources > unknown: can't assign resources > unknown: can't assign resources > unknown: can't assign resources > unknown: can't assign resources > unknown: can't assign resources > ad0: 4125MB [8940/15/63] at ata0-master UDMA33 > acd0: CDROM at ata0-slave PIO4 > Mounting root from ufs:/dev/ad0s2a > ----------------- end -------------------- > > is this normal ? It is if you have your BIOS configured incorrectly with regard to whether you are running a "PNP OS". It's also normal if you have more hardware in a box than it's possible to handle simultaneously, e.g. if you had a bunch of slots full of resource hungry hardware. Probably you will need to fiddle with your BIOS. Try the following patch; the failure message will be somewhat less cryptic, since it will tell you the proximal reason for failure out of the 5 possibles for the message you are seeing. 8-). -- Terry --------------741846253D1D9002AE8EAD96 Content-Type: text/plain; charset=us-ascii; name="pnp.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pnp.patch" Index: isa_common.c =================================================================== RCS file: /usr/cvs/src/sys/isa/isa_common.c,v retrieving revision 1.16.2.1 diff -u -r1.16.2.1 isa_common.c --- isa_common.c 16 Sep 2000 15:49:52 -0000 1.16.2.1 +++ isa_common.c 24 Feb 2002 21:07:23 -0000 @@ -387,15 +387,20 @@ struct isa_device *idev = DEVTOISA(child); struct isa_config_entry *ice; struct isa_config config; + char *reason = "Empty ISA id_configs"; bzero(&config, sizeof config); TAILQ_FOREACH(ice, &idev->id_configs, ice_link) { + reason = "memory"; if (!isa_find_memory(child, &ice->ice_config, &config)) continue; + reason = "port"; if (!isa_find_port(child, &ice->ice_config, &config)) continue; + reason = "irq"; if (!isa_find_irq(child, &ice->ice_config, &config)) continue; + reason = "drq"; if (!isa_find_drq(child, &ice->ice_config, &config)) continue; @@ -403,6 +408,7 @@ * A working configuration was found enable the device * with this configuration. */ + reason = "no callback"; if (idev->id_config_cb) { idev->id_config_cb(idev->id_config_arg, &config, 1); @@ -414,7 +420,7 @@ * Disable the device. */ bus_print_child_header(device_get_parent(child), child); - printf(" can't assign resources\n"); + printf(" can't assign resources (%s)\n", reason); if (bootverbose) isa_print_child(device_get_parent(child), child); bzero(&config, sizeof config); --------------741846253D1D9002AE8EAD96-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 13:27:52 2002 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id 313CD37B404 for ; Sun, 24 Feb 2002 13:27:14 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g1OLPZG01102; Sun, 24 Feb 2002 13:25:35 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200202242125.g1OLPZG01102@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert Cc: zhuravlev alexander , current@freebsd.org Subject: Re: [Patch: clarity] Re: can't assign resources In-reply-to: Your message of "Sun, 24 Feb 2002 13:12:00 PST." <3C795720.5EEA58F6@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 24 Feb 2002 13:25:35 -0800 From: Michael Smith 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 > This is a multi-part message in MIME format. > --------------741846253D1D9002AE8EAD96 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > zhuravlev alexander wrote: > > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > > unknown: can't assign resources > > unknown: can't assign resources > > unknown: can't assign resources > > unknown: can't assign resources > > unknown: can't assign resources > > unknown: can't assign resources > > ad0: 4125MB [8940/15/63] at ata0-master UDMA33 > > acd0: CDROM at ata0-slave PIO4 > > Mounting root from ufs:/dev/ad0s2a > > ----------------- end -------------------- > > > > is this normal ? > > It is if you have your BIOS configured incorrectly with > regard to whether you are running a "PNP OS". It's also normal if you have hints loaded for things that could have been autoconfigured, which is what the above seems to suggest. -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 13:30:48 2002 Delivered-To: freebsd-current@freebsd.org Received: from etek.chalmers.se (quarl0.etek.chalmers.se [129.16.32.20]) by hub.freebsd.org (Postfix) with ESMTP id 1C63837B416; Sun, 24 Feb 2002 13:30:45 -0800 (PST) Received: from downy.etek.chalmers.se (_7-268@downy.etek.chalmers.se [129.16.32.207]) by etek.chalmers.se (8.10.0/8.8.8) with ESMTP id g1OLUhV02989; Sun, 24 Feb 2002 22:30:43 +0100 (MET) Received: from localhost (b@localhost) by downy.etek.chalmers.se (8.10.0/8.10.0) with ESMTP id g1OLUhk10826; Sun, 24 Feb 2002 22:30:43 +0100 (MET) Date: Sun, 24 Feb 2002 22:30:42 +0100 (MET) From: Magnus B{ckstr|m To: Michael Smith Cc: current@freebsd.org Subject: Re: HEADS UP: ACPI CA updated In-Reply-To: <200202242018.g1OKIUG00719@mass.dis.org> 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 Sun, 24 Feb 2002, Michael Smith wrote: > Try grabbing Giant in acpi_tz_thread when it wakes up, then dropping it > again before it goes to sleep. This is probably a hack, but I'd guess a > required one for now. > > If that works, send me a diff and I'll commit it with thanks! Yow! Works absolutely fine. Patch below! Thanks! Magnus --- sys/dev/acpica/acpi_thermal.c.ctm Sun Feb 24 13:55:13 2002 +++ sys/dev/acpica/acpi_thermal.c Sun Feb 24 23:20:39 2002 @@ -31,6 +31,8 @@ #include #include #include +#include +#include #include #include #include @@ -780,6 +782,8 @@ for (;;) { tsleep(&acpi_tz_proc, PZERO, "nothing", hz * acpi_tz_polling_rate); + mtx_lock(&Giant); + if (devcount == 0) devclass_get_devices(acpi_tz_devclass, &devs, &devcount); @@ -787,5 +791,7 @@ for (i = 0; i < devcount; i++) acpi_tz_timeout(device_get_softc(devs[i])); ACPI_UNLOCK; + + mtx_unlock(&Giant); } } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 14:13:49 2002 Delivered-To: freebsd-current@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 93F3A37B400; Sun, 24 Feb 2002 14:13:46 -0800 (PST) Received: from pool0039.cvx22-bradley.dialup.earthlink.net ([209.179.198.39] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16f6tt-0004Kq-00; Sun, 24 Feb 2002 14:13:46 -0800 Message-ID: <3C79658C.1717C6D5@mindspring.com> Date: Sun, 24 Feb 2002 14:13:32 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Smith Cc: zhuravlev alexander , current@freebsd.org Subject: Re: [Patch: clarity] Re: can't assign resources References: <200202242125.g1OLPZG01102@mass.dis.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 Michael Smith wrote: > > It is if you have your BIOS configured incorrectly with > > regard to whether you are running a "PNP OS". > > It's also normal if you have hints loaded for things that could have been > autoconfigured, which is what the above seems to suggest. OK. 8-). I've always seen it when my "PNP OS" setting was wrong. The card IDs made me pretty sure it wasn't 8 muti-I/O cards. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 14:18: 5 2002 Delivered-To: freebsd-current@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 5FDFA37B400 for ; Sun, 24 Feb 2002 14:18:02 -0800 (PST) Received: from dan.emsphone.com (dan@localhost [127.0.0.1]) by dan.emsphone.com (8.12.2/8.12.2) with ESMTP id g1OMHxxP077143; Sun, 24 Feb 2002 16:18:01 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.2/8.12.2/Submit) id g1OMHv7I077140; Sun, 24 Feb 2002 16:17:58 -0600 (CST) Date: Sun, 24 Feb 2002 16:17:57 -0600 From: Dan Nelson To: Terry Lambert Cc: zhuravlev alexander , current@FreeBSD.ORG Subject: Re: [Patch: clarity] Re: can't assign resources Message-ID: <20020224221757.GA67607@dan.emsphone.com> References: <20020224232153.A95673@ns.ulstu.ru> <3C795720.5EEA58F6@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C795720.5EEA58F6@mindspring.com> User-Agent: Mutt/1.3.27i X-OS: FreeBSD 5.0-CURRENT X-message-flag: Outlook Error 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 the last episode (Feb 24), Terry Lambert said: > zhuravlev alexander wrote: > > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > > unknown: can't assign resources > > unknown: can't assign resources > > unknown: can't assign resources > > unknown: can't assign resources > > unknown: can't assign resources > > unknown: can't assign resources > > ad0: 4125MB [8940/15/63] at ata0-master UDMA33 > > acd0: CDROM at ata0-slave PIO4 > > Mounting root from ufs:/dev/ad0s2a > > ----------------- end -------------------- > > > > is this normal ? > > It is if you have your BIOS configured incorrectly with > regard to whether you are running a "PNP OS". Not many BIOSes even give you this option anymore.. -- Dan Nelson dnelson@allantgroup.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 14:28:55 2002 Delivered-To: freebsd-current@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 5252637B400 for ; Sun, 24 Feb 2002 14:28:52 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 29D97AE20B; Sun, 24 Feb 2002 14:28:52 -0800 (PST) Date: Sun, 24 Feb 2002 14:28:52 -0800 From: Alfred Perlstein To: Terry Lambert Cc: current@freebsd.org Subject: Re: [Patch: clarity] Re: can't assign resources Message-ID: <20020224222852.GU80761@elvis.mu.org> References: <20020224232153.A95673@ns.ulstu.ru> <3C795720.5EEA58F6@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C795720.5EEA58F6@mindspring.com> User-Agent: Mutt/1.3.27i 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 * Terry Lambert [020224 13:12] wrote: > > Try the following patch; the failure message will be > somewhat less cryptic, since it will tell you the > proximal reason for failure out of the 5 possibles > for the message you are seeing. 8-). Cool explanation, the attached patch was committed but had to be modified because it wouldn't apply cleanly. Was it meant for -stable? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 14:33:30 2002 Delivered-To: freebsd-current@freebsd.org Received: from ip68-2-87-144.ph.ph.cox.net (ip68-2-87-144.ph.ph.cox.net [68.2.87.144]) by hub.freebsd.org (Postfix) with ESMTP id 4223B37B400 for ; Sun, 24 Feb 2002 14:33:21 -0800 (PST) Received: from whale.home-net (whale [192.168.1.2]) by ip68-2-87-144.ph.ph.cox.net (8.11.6/8.11.6) with ESMTP id g1OMXK441499 for ; Sun, 24 Feb 2002 15:33:20 -0700 (MST) (envelope-from johnjen@reynoldsnet.org) Received: (from jjreynold@localhost) by whale.home-net (8.11.6/8.11.6) id g1OMXJa82416; Sun, 24 Feb 2002 15:33:19 -0700 (MST) (envelope-from johnjen@reynoldsnet.org) From: John Reynolds MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15481.27183.749281.980128@whale.home-net> Date: Sun, 24 Feb 2002 15:33:19 -0700 To: current@freebsd.org Subject: libusb build broken due to structure member renaming X-Mailer: VM 6.88 under Emacs 20.7.1 Cc: 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 hello, I've got a -current-related question to ask. akbeech forwarded me his build log when trying to build the "linux" user-land libusb from the port which I maintain (it is below). At first I said "impossible" because I'd tested things thoroughly, but then noticed he was on a -current system. Digging into things I see that sys/dev/usb/usb.h has had some commits lately that renamed the usb structures. Things like "interface_index" went to uai_interface_index, etc. Question #1: are there plans to MFC these changes in the USB structures to -stable in the near future? Question #2: If not, is __FreeBSD_version >= 500030 the appropriate thing to "key" off of in order to make a patch set for libusb so that it will compile and work cleanly on a "fresh" -current? (info obtained from http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-versions.html ) If these changes are not going to be MFC'ed in the near future (i.e. for 4.6-RELEASE) then my tendency is to not put #ifdef flags all over the libusb code testing for FreeBSD-current, but rather to locally patch the source if make(1) can determine it's on a system with the 'new' structures. Comments? -Jr (please cc: as I don't subscribe directly to -current) ------- start of forwarded message ------- From: Beech Rintoul Subject: libusb build broken To: johnjen@reynoldsnet.org Date: Sun, 24 Feb 2002 08:39:09 -0900 I,m getting the following when trying to compile libusb: rm -f .libs/bsd.lo cc -DHAVE_CONFIG_H -I. -I. -I. -O -pipe -Wall -c bsd.c -Wp,-MD,.deps/bsd.TPlo -fPIC -DPIC -o .libs/bsd.lo bsd.c: In function `usb_set_altinterface': bsd.c:154: structure has no member named `interface_index' bsd.c:155: structure has no member named `alt_no' bsd.c: In function `usb_control_msg': bsd.c:287: structure has no member named `request' bsd.c:288: structure has no member named `request' bsd.c:289: structure has no member named `request' bsd.c:289: structure has no member named `request' bsd.c:289: warning: left-hand operand of comma expression has no effect bsd.c:290: structure has no member named `request' bsd.c:290: structure has no member named `request' bsd.c:290: warning: left-hand operand of comma expression has no effect bsd.c:291: structure has no member named `request' bsd.c:291: structure has no member named `request' bsd.c:291: warning: left-hand operand of comma expression has no effect bsd.c:293: structure has no member named `data' bsd.c:294: structure has no member named `flags' bsd.c:306: structure has no member named `request' bsd.c:306: structure has no member named `request' bsd.c:307: warning: control reaches end of non-void function bsd.c: In function `usb_find_devices_on_bus': bsd.c:324: structure has no member named `addr' bsd.c:330: structure has no member named `devnames' bsd.c:335: structure has no member named `devnames' *** Error code 1 Stop in /usr/ports/devel/libusb/work/libusb-0.1.5. *** Error code 1 My machine is a Celeron 500MHz runing -current (yesterday's build). Beech -- ------------------------------------------------------------------- Beech Rintoul - IT Manager - Instructor - akbeech@anchoragerescue.org /"\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission \ / - NO HTML/RTF in e-mail | P.O. Box 230510 X - NO Word docs in e-mail | Anchorage, AK 99523-0510 / \ ----------------------------------------------------------------- ------- end of forwarded message ------- -- John & Jennifer Reynolds johnjen@reynoldsnet.org http://www.reynoldsnet.org/ Senior CAD Engineer, WCCG, Intel Corporation jreynold@sedona.ch.intel.com Running FreeBSD since 2.1.5-RELEASE. FreeBSD: The Power to Serve! "Unix is user friendly, it's just particular about the friends it chooses." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 14:43:50 2002 Delivered-To: freebsd-current@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 1277237B402 for ; Sun, 24 Feb 2002 14:43:47 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id E1A52AE2C1; Sun, 24 Feb 2002 14:43:46 -0800 (PST) Date: Sun, 24 Feb 2002 14:43:46 -0800 From: Alfred Perlstein To: John Reynolds Cc: current@freebsd.org Subject: Re: libusb build broken due to structure member renaming Message-ID: <20020224224346.GX80761@elvis.mu.org> References: <15481.27183.749281.980128@whale.home-net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15481.27183.749281.980128@whale.home-net> User-Agent: Mutt/1.3.27i 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 * John Reynolds [020224 14:33] wrote: > > hello, I've got a -current-related question to ask. akbeech forwarded me > his build log when trying to build the "linux" user-land libusb from the > port which I maintain (it is below). At first I said "impossible" because I'd > tested things thoroughly, but then noticed he was on a -current system. Digging > into things I see that sys/dev/usb/usb.h has had some commits lately that > renamed the usb structures. Things like "interface_index" went to > uai_interface_index, etc. > > Question #1: are there plans to MFC these changes in the USB structures to > -stable in the near future? I did that last night. > Question #2: If not, is __FreeBSD_version >= 500030 the appropriate thing to > "key" off of in order to make a patch set for libusb so that it will compile > and work cleanly on a "fresh" -current? I didn't bump FreeBSD_version specifically for it although I guess I will be now. In both -current and -stable. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 14:45:20 2002 Delivered-To: freebsd-current@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 7ABD737B41B for ; Sun, 24 Feb 2002 14:45:04 -0800 (PST) Received: from pool0039.cvx22-bradley.dialup.earthlink.net ([209.179.198.39] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16f7OB-0005GV-00; Sun, 24 Feb 2002 14:45:03 -0800 Message-ID: <3C796CE1.A7607302@mindspring.com> Date: Sun, 24 Feb 2002 14:44:49 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: current@freebsd.org Subject: Re: [Patch: clarity] Re: can't assign resources References: <20020224232153.A95673@ns.ulstu.ru> <3C795720.5EEA58F6@mindspring.com> <20020224222852.GU80761@elvis.mu.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 Alfred Perlstein wrote: > * Terry Lambert [020224 13:12] wrote: > > Try the following patch; the failure message will be > > somewhat less cryptic, since it will tell you the > > proximal reason for failure out of the 5 possibles > > for the message you are seeing. 8-). > > Cool explanation, the attached patch was committed but had to > be modified because it wouldn't apply cleanly. Was it meant for > -stable? Ugh. Should have done a context diff. Yeah, it was against 4.5-stable on my machine here. I can't upgrade that particular machine for you-know-why. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 14:51:52 2002 Delivered-To: freebsd-current@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id B29B837B421 for ; Sun, 24 Feb 2002 14:51:21 -0800 (PST) Received: from pool0039.cvx22-bradley.dialup.earthlink.net ([209.179.198.39] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16f7UG-00049F-00; Sun, 24 Feb 2002 14:51:20 -0800 Message-ID: <3C796E5A.CAD49BDB@mindspring.com> Date: Sun, 24 Feb 2002 14:51:06 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Reynolds Cc: current@freebsd.org Subject: Re: libusb build broken due to structure member renaming References: <15481.27183.749281.980128@whale.home-net> 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 John Reynolds wrote: > hello, I've got a -current-related question to ask. akbeech forwarded me > his build log when trying to build the "linux" user-land libusb from the > port which I maintain (it is below). At first I said "impossible" because I'd > tested things thoroughly, but then noticed he was on a -current system. Digging > into things I see that sys/dev/usb/usb.h has had some commits lately that > renamed the usb structures. Things like "interface_index" went to > uai_interface_index, etc. > > Question #1: are there plans to MFC these changes in the USB structures to > -stable in the near future? Dunno. Ask Alfred. He made the changes, on my advice, because there was a namespace collision with a C++ reserved word. I don't think there was a requirement to keep things portable between the versions. Usually, this kind of thing makes it back as an MFC, eventually. If you want to back-port the changes as a patch, I think Alfred would commit it for you. > Question #2: If not, is __FreeBSD_version >= 500030 the appropriate thing to > "key" off of in order to make a patch set for libusb so that it will compile > and work cleanly on a "fresh" -current? Yes, usually. In this case, it should be true. > If these changes are not going to be MFC'ed in the near future (i.e. for > 4.6-RELEASE) then my tendency is to not put #ifdef flags all over the libusb > code testing for FreeBSD-current, but rather to locally patch the source if > make(1) can determine it's on a system with the 'new' structures. Comments? Probably a patch would help?... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 14:56:52 2002 Delivered-To: freebsd-current@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 1384437B41E for ; Sun, 24 Feb 2002 14:56:40 -0800 (PST) Received: from pool0039.cvx22-bradley.dialup.earthlink.net ([209.179.198.39] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16f7ZP-0002ox-00; Sun, 24 Feb 2002 14:56:39 -0800 Message-ID: <3C796F99.D16A8A93@mindspring.com> Date: Sun, 24 Feb 2002 14:56:25 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Reynolds , current@freebsd.org Subject: Re: libusb build broken due to structure member renaming References: <15481.27183.749281.980128@whale.home-net> <3C796E5A.CAD49BDB@mindspring.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 Terry Lambert wrote: > > Question #1: are there plans to MFC these changes in the USB structures to > > -stable in the near future? Too late. Alfred is too fast. > > Question #2: If not, is __FreeBSD_version >= 500030 the appropriate thing to > > "key" off of in order to make a patch set for libusb so that it will compile > > and work cleanly on a "fresh" -current? See Alfred's posting; he's promised to bump things. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 16: 8:35 2002 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 EB63E37B405; Sun, 24 Feb 2002 16:08:27 -0800 (PST) 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 LAA06139; Mon, 25 Feb 2002 11:08:13 +1100 Date: Mon, 25 Feb 2002 11:08:34 +1100 (EST) From: Bruce Evans X-X-Sender: To: Matthew Dillon Cc: Terry Lambert , Alfred Perlstein , Bosko Milekic , Seigo Tanimura , , John Baldwin Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assembly revamp, please review! In-Reply-To: <200202241912.g1OJCMx95238@apollo.backplane.com> Message-ID: <20020225105853.G35771-100000@gamplex.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 On Sun, 24 Feb 2002, Matthew Dillon wrote: > NOTES: > > I would like to thank Bruce for supplying the sample code that allowed > me to do this in a day instead of several days. Thanks. > * debug.critical_mode sysctl. This will not be in the final commit, > nor will any of the code that tests the variable. The final commit > will use code as if the critical_mode were '1'. Won't it be needed for longer for non-i386's arches? > * Additional cpu_critical_enter/exit() calls around icu_lock. Since > critical_enter() no longer disables interrupts, special care must > be taken when dealing with the icu_lock spin mutex because it is > the one thing the interrupt code needs to be able to defer the > interrupt. clock_lock needs these too, at least in my version where the soft critical_enter() doesn't mask fast interrupts. > * MACHINE_CRITICAL_ENTER define. This exists to maintain compatibility > with other architectures. i386 defines this to cause fork_exit to > use the new API and to allow the i386 MD code to supply the > critical_enter() and critical_exit() procedures rather then > kern_switch.c > > I would much prefer it if the other architectures were brought around > to use this new mechanism. The old mechanism makes assumptions > in regards to hard disablement that is no longer correct for i386. The old mechanism basically forces mtx_lock_spin() to do the hard disablement. I never liked this. > * Trampoline 'sti'. In the final commit, the trampoline will simply > 'sti' after setting up td_critnest. The other junk to handle the > hard-disablement case will be gone. Maybe all of the fiddling with sched_lock belongs in MD code. IIRC, in my version, the hard interrupt enablement in fork_exit() is only needed at boot time. Something neglects to do it earlier in that case, at least for some threads. I was surprised by this -- hard interrupts are enabled early in the boot, and everything later should disable and enable them reentrantly. > * Additional cpu_critical_enter()/exit() calls in CY and TIMER code. > Bruce had additional hard interrupt disablements in these modules. > > I'm not sure why so if I need to do that as well I would like to > know. There are also some in sio. The ones in sio an cy are needed because my critical_enter() doesn't mask fast interrupts. Something is needed to mask them, and cpu_critical_enter() is used. I think you don't need these yet. The ones in timer code are to make the timer code as hard- real-time as possible. I think this is important in i8254_get_timecounter() but not elsewhere in clock.c. > Index: i386/i386/machdep.c > =================================================================== > RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v > retrieving revision 1.497 > diff -u -r1.497 machdep.c > --- i386/i386/machdep.c 17 Feb 2002 17:40:28 -0000 1.497 > +++ i386/i386/machdep.c 24 Feb 2002 19:04:20 -0000 > ... > @@ -270,6 +275,121 @@ > } > > /* > + * Critical section handling. > + * > + * Note that our interrupt code handles any interrupt race that occurs > + * after we decrement td_critnest. > + */ > +void > +critical_enter(void) i386/machdep.c is a different wrong place for this and unpend(). I put it in isa/ithread.c. It is not very MD, and is even less isa-dependent. > +void > +critical_exit(void) > +{ > + struct thread *td = curthread; > + KASSERT(td->td_critnest > 0, ("bad td_critnest value!")); > + if (--td->td_critnest == 0) { > + if (td->td_savecrit != (critical_t)-1) { > + cpu_critical_exit(td->td_savecrit); > + td->td_savecrit = (critical_t)-1; > + } else { > + /* > + * We may have to schedule pending interrupts. Create > + * conditions similar to an interrupt context and call > + * unpend(). > + */ > + if (PCPU_GET(int_pending) && td->td_intr_nesting_level == 0) { I'm trying to kill td_intr_nesting_level. I think/hope you don't need it. In ithread_schedule(), we begin with interrupts hard-enabled but don't have any other locks, so things are delicate -- an mtx_unlock_spin() immediately after the mtx_lock_spin() would do too much without the above test. Perhaps add a critical_enter()/critical_exit() wrapper to sync the software interrupt disablement with the hardware disablement. Xfastintr* in -current already does this. > Index: i386/isa/apic_vector.s > =================================================================== > RCS file: /home/ncvs/src/sys/i386/isa/apic_vector.s,v > retrieving revision 1.75 > diff -u -r1.75 apic_vector.s > --- i386/isa/apic_vector.s 5 Jan 2002 08:47:10 -0000 1.75 > +++ i386/isa/apic_vector.s 24 Feb 2002 17:58:34 -0000 Please do this without so many changes to the assembly code. Especially not the reordering and style changes. I think I see how to do this (see call_fast_unpend()) > ... > @@ -417,6 +508,41 @@ > INTR(30,intr30,) > INTR(31,intr31,) > MCOUNT_LABEL(eintr) > + > +MCOUNT_LABEL(bfunpend) > + FAST_UNPEND(0,fastunpend0) >... > + FAST_UNPEND(31,fastunpend31) > +MCOUNT_LABEL(efunpend) THe interrupt routines must go between the special labels bintr and eintr so that mcount understands them. > Index: i386/isa/intr_machdep.c > =================================================================== > RCS file: /home/ncvs/src/sys/i386/isa/intr_machdep.c,v > retrieving revision 1.65 > diff -u -r1.65 intr_machdep.c > --- i386/isa/intr_machdep.c 8 Feb 2002 18:30:35 -0000 1.65 > +++ i386/isa/intr_machdep.c 24 Feb 2002 10:50:26 -0000 > ... > @@ -672,3 +711,10 @@ > > return (ithread_remove_handler(cookie)); > } > + > +void > +call_fast_unpend(int irq) > +{ > + fastunpend[irq](); > +} > + I think this can be done using with few changes to the assembler by using INTREN(irq) followed by a call to the usual Xfastintr[irq] entry point, or (perhaps after a few adjustments) even to the driver's entry point. Efficiency is not very important, since most entries are handled directly and the overhead for INTREN() is dominant anyway. We just need to be careful to provide a normal interrupt frame for clock interrupt handlers (it needs to have %cs in it so that hardclock() can tell if the interrupt was from user mode). OTOH, non-clock fast interrupt handlers don't care about the frame at all, so just calling them (with interrupts disabled) works right. RELENG_4 still has complications related to this and I was pleased to see them go away in -current. See vec0, vec8 and BUILD_VEC() in icu_ipl.s (the vecN routines are stubs to avoid duplication of Xintr*). -current made things simpler for normal interrupt handlers, and fast interrupt handlers are simpler at this level except for the problem with the frame. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 16:35:27 2002 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 1786A37B404; Sun, 24 Feb 2002 16:35:20 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1P0ZFT25722; Sun, 24 Feb 2002 16:35:15 -0800 (PST) (envelope-from dillon) Date: Sun, 24 Feb 2002 16:35:15 -0800 (PST) From: Matthew Dillon Message-Id: <200202250035.g1P0ZFT25722@apollo.backplane.com> To: Bruce Evans Cc: Terry Lambert , Alfred Perlstein , Bosko Milekic , Seigo Tanimura , , John Baldwin Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assembly revamp, please review! References: <20020225105853.G35771-100000@gamplex.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 : :On Sun, 24 Feb 2002, Matthew Dillon wrote: : :> * debug.critical_mode sysctl. This will not be in the final commit, :> nor will any of the code that tests the variable. The final commit :> will use code as if the critical_mode were '1'. : :Won't it be needed for longer for non-i386's arches? No, 99% of it is in 386-specific files, it won't effect other arches. :> * Additional cpu_critical_enter/exit() calls around icu_lock. Since :> critical_enter() no longer disables interrupts, special care must :> be taken when dealing with the icu_lock spin mutex because it is :> the one thing the interrupt code needs to be able to defer the :> interrupt. : :clock_lock needs these too, at least in my version where the soft :critical_enter() doesn't mask fast interrupts. I wasn't sure whether it was due to that, or whether you just wanted the two I8254 accesses to be right next to each other. Since I am msking fast interrupts I think we are safe. :> * MACHINE_CRITICAL_ENTER define. This exists to maintain compatibility :.. :> :> I would much prefer it if the other architectures were brought around :> to use this new mechanism. The old mechanism makes assumptions :> in regards to hard disablement that is no longer correct for i386. : :The old mechanism basically forces mtx_lock_spin() to do the hard disablement. :I never liked this. In my case, the term 'dislike' would be an understatement. Every time I looked at what critical_enter() was doing I got angry. Heh. :> * Trampoline 'sti'. In the final commit, the trampoline will simply :> 'sti' after setting up td_critnest. The other junk to handle the :> hard-disablement case will be gone. : :Maybe all of the fiddling with sched_lock belongs in MD code. I think it wound up outside of MD because the only other place to put it is in cpu_switch() (assembly), and people are understandably trying to avoid imposing more assembly on all the architectures. I'm willing to leave it be for now but I agree that it is really ugly. :IIRC, in my version, the hard interrupt enablement in fork_exit() is :only needed at boot time. Something neglects to do it earlier in that :case, at least for some threads. I was surprised by this -- hard :interrupts are enabled early in the boot, and everything later should :disable and enable them reentrantly. I couldn't figure out who was leaving hard interrupts enabled. Did you ever figure out who it was? At the moment I am able to enable interrupts in the trampoline code just before the call to fork_exit(), but it has to be disabled on entry to the trampoline code because the task's td_critnest count is still 0 at that point and we can't afford to execute a real (fast) interrupt's service routine until we clean up the sched_lock. :> * Additional cpu_critical_enter()/exit() calls in CY and TIMER code. :> Bruce had additional hard interrupt disablements in these modules. :> :> I'm not sure why so if I need to do that as well I would like to :> know. : :There are also some in sio. The ones in sio an cy are needed because :my critical_enter() doesn't mask fast interrupts. Something is needed :to mask them, and cpu_critical_enter() is used. I think you don't need :these yet. The ones in timer code are to make the timer code as hard- :real-time as possible. I think this is important in :i8254_get_timecounter() but not elsewhere in clock.c. Ok, that's what I thought. Since I am masking fast interrupts I believe we are safe there too. In regards to i8254_get_timecounter() the 8254 latches the full count on the first access so we are theoretically safe. I'll change my timecounter to use the 8254 to see if it still works as expected. :... :> /* :> + * Critical section handling. :> + * :> + * Note that our interrupt code handles any interrupt race that occurs :> + * after we decrement td_critnest. :> + */ :> +void :> +critical_enter(void) : :i386/machdep.c is a different wrong place for this and unpend(). I put it :in isa/ithread.c. It is not very MD, and is even less isa-dependent. Yah. I'm all ears as to where to put it :-) There's no good place to put inline versions of critical_enter() or critical_exit() either. machine/cpufunc.h doesn't have access to the struct thread. p.s. all discussion here and below, except for the bintr/eintr cleanup, would be for a second work/commit round after I commit the current stuff. :I'm trying to kill td_intr_nesting_level. I think/hope you don't need it. :In ithread_schedule(), we begin with interrupts hard-enabled but don't :have any other locks, so things are delicate -- an mtx_unlock_spin() :immediately after the mtx_lock_spin() would do too much without the above :test. Perhaps add a critical_enter()/critical_exit() wrapper to sync the :software interrupt disablement with the hardware disablement. Xfastintr* :in -current already does this. I noticed that it didn't seem to be used much. I am currently leaving interrupts disabled in both fast and normal interrupts, and we both bump td_critnest in the fast interrupt code already. So I agree that a simple bump of td_critnest in the scheduled interrupt code ought to be sufficient to allow us to kill td_intr_nesting_level. There are also a few places where I can use movl instead of incl and decl. :> Index: i386/isa/apic_vector.s :> =================================================================== :> RCS file: /home/ncvs/src/sys/i386/isa/apic_vector.s,v :> retrieving revision 1.75 :> diff -u -r1.75 apic_vector.s :> --- i386/isa/apic_vector.s 5 Jan 2002 08:47:10 -0000 1.75 :> +++ i386/isa/apic_vector.s 24 Feb 2002 17:58:34 -0000 : :Please do this without so many changes to the assembly code. Especially :not the reordering and style changes. I think I see how to do this :(see call_fast_unpend()) No such luck. In order to be able to mask fast interrupts I had to move all the macros from between fast and slow ints to above fast ints. I also decided to tab-out the backslashes in the icu_vector code, because I couldn't read the code easily with the backslashes slammed up against the instructions :-( :> @@ -417,6 +508,41 @@ :> INTR(30,intr30,) :> INTR(31,intr31,) :> MCOUNT_LABEL(eintr) :> + :> +MCOUNT_LABEL(bfunpend) :> + FAST_UNPEND(0,fastunpend0) :>... :> + FAST_UNPEND(31,fastunpend31) :> +MCOUNT_LABEL(efunpend) : :THe interrupt routines must go between the special labels bintr and eintr :so that mcount understands them. Ok, I'll get rid of bfunpend and efunpend and just put the whole mess around bintr and eintr. :> +void :> +call_fast_unpend(int irq) :> +{ :> + fastunpend[irq](); :> +} :> + : :I think this can be done using with few changes to the assembler by :using INTREN(irq) followed by a call to the usual Xfastintr[irq] entry :point, or (perhaps after a few adjustments) even to the driver's entry :point. Efficiency is not very important, since most entries are handled :directly and the overhead for INTREN() is dominant anyway. We just :need to be careful to provide a normal interrupt frame for clock :interrupt handlers (it needs to have %cs in it so that hardclock() can :tell if the interrupt was from user mode). OTOH, non-clock fast :interrupt handlers don't care about the frame at all, so just calling :them (with interrupts disabled) works right. I was going to do this but the trap frame is passed to the fast interrupt function. I could either do an inline 'int' instruction or simulate the trap frame. For the slow interrupt unpend code I of course just call sched_ithd() directly. :RELENG_4 still has complications related to this and I was pleased to :see them go away in -current. See vec0, vec8 and BUILD_VEC() in :icu_ipl.s (the vecN routines are stubs to avoid duplication of Xintr*). :-current made things simpler for normal interrupt handlers, and fast :interrupt handlers are simpler at this level except for the problem :with the frame. : :Bruce Yup! -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 24 16:49:11 2002 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 E0F8F37B405 for ; Sun, 24 Feb 2002 16:49:09 -0800 (PST) Received: from DougBarton.net (12-234-22-238.client.attbi.com [12.234.22.238]) by mail-relay1.yahoo.com (Postfix) with ESMTP id 50BF28B5AC; Sun, 24 Feb 2002 16:49:09 -0800 (PST) Message-ID: <3C798A04.5333A65F@DougBarton.net> Date: Sun, 24 Feb 2002 16:49:08 -0800 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Mark Murray , freebsd-current@freebsd.org Subject: New pam doesn't work with xdm 4.2 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 I installed XFree86 version 4.2 in binary format from the xfree86.org website. I just upgraded my -current installation to today's latest bits, and now I can't log in with xdm. This is the output to the console (minus date/host info for readability): PAM unable to dlopen(/usr/lib/pam_unix.so) PAM [dlerror: /usr/lib/pam_unix.so: Undefined symbol "setnetconfig"] PAM adding faulty module: /usr/lib/pam_unix.so PAM unable to dlopen(/usr/lib/pam_opie.so) PAM [dlerror: /usr/lib/libopie.so.2: Undefined symbol "__xuname"] PAM adding faulty module: /usr/lib/pam_opie.so PAM unable to dlopen(/usr/lib/pam_opieaccess.so) PAM [dlerror: /usr/lib/libopie.so.2: Undefined symbol "__xuname"] PAM adding faulty module: /usr/lib/pam_opieaccess.so This is my home workstation, so I can just use startx for now, but this should be fixed long term. Doug -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 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 Sun Feb 24 16:56:46 2002 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 CE0EB37B400 for ; Sun, 24 Feb 2002 16:56:36 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g1P0uad47485 for current@FreeBSD.org; Sun, 24 Feb 2002 17:56:36 -0700 (MST) (envelope-from ken) Date: Sun, 24 Feb 2002 17:56:36 -0700 From: "Kenneth D. Merry" To: current@FreeBSD.org Subject: -current hangs with SMP enabled Message-ID: <20020224175635.A47442@panzer.kdm.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i 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 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I've got a SMP machine with a Supermicro P3TDE6 motherboard. (Serverworks HE-SL chipset, dual 1.26GHz Pentium III's.) It boots just fine with a GENERIC -current kernel (sources cvsupped yesterday at ~1500 MST), but hangs (at the "Waiting 15 seconds for SCSI devices to settle" message) when SMP and APIC_IO are enabled. Those two options are the only things different between the broken and working GENERIC kernels. I've attached dmesg output from the stock GENERIC kernel. Anyone have any ideas on how to get SMP working? Thanks, Ken -- Kenneth Merry ken@kdm.org --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.current.20020224" Copyright (c) 1992-2002 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 #0: Sun Feb 24 17:29:36 MST 2002 ken@gondolin.kdm.org:/usr/home/ken/perforce/FreeBSD-ken/src/sys/i386/compile/GENERIC Preloaded elf kernel "/boot/kernel.GENERIC.new/kernel" at 0xc0564000. Preloaded elf module "/boot/kernel.GENERIC.new/acpi.ko" at 0xc05640b4. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 1266068202 Hz CPU: Pentium III/Pentium III Xeon/Celeron (1266.07-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 Features=0x383fbff real memory = 2684289024 (2621376K bytes) avail memory = 2608848896 (2547704K bytes) Pentium Pro MTRR support enabled Using $PIR table, 10 entries at 0xc00f52e0 ACPI-0204: *** Error: AcpiLoadTables: Could not load namespace: AE_NOT_FOUND ACPI-0213: *** Error: AcpiLoadTables: Could not load tables: AE_NOT_FOUND ACPI: table load failed: AE_NOT_FOUND npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 0.1 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) ahc0: port 0xd000-0xd0ff mem 0xfeafc000-0xfeafcfff irq 5 at device 5.0 on pci0 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/255 SCBs ahc1: port 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff irq 10 at device 5.1 on pci0 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/255 SCBs fxp0: port 0xd400-0xd43f mem 0xfe900000-0xfe9fffff,0xfeafd000-0xfeafdfff irq 9 at device 6.0 on pci0 fxp0: Ethernet address 00:30:48:21:bb:74 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: port 0x580-0x58f at device 15.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ohci0: mem 0xfeafe000-0xfeafefff irq 10 at device 15.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: (unknown) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered pcib2: at pcibus 2 on motherboard pci2: on pcib2 pci2: at device 2.0 (no driver attached) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it orm0: