From owner-freebsd-alpha Sun Jun 10 2:12:26 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by hub.freebsd.org (Postfix) with ESMTP id 2362237B403 for ; Sun, 10 Jun 2001 02:12:21 -0700 (PDT) (envelope-from mpkisbkl@xs4all.nl) Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id LAA06371; Sun, 10 Jun 2001 11:12:20 +0200 (CEST) Received: from localhost (mpkisbkl@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id LAA16725; Sun, 10 Jun 2001 11:12:20 +0200 (CEST) Date: Sun, 10 Jun 2001 11:12:19 +0200 (CEST) From: Martijn Pronk To: Andrew Gallatin Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: de network card not working on -current In-Reply-To: <15138.34490.249163.348223@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 9 Jun 2001, Andrew Gallatin wrote: > > Martijn Pronk writes: > > > > I hope you meant the following part of dec_axppci_33.c at line 273: > > Yes, those printfs haven't changed since we took the code from NetBSD, > that's why you get the compile error. Don't worry about it.. I think > I see the problem. Please try the appended patch & let me know if it > works. The AS200 (apecs) code will need it too, assuming it works. > > Thanks! > Well, this patch works! There are alse correct irq numbers again while probing for devices... (instead of irq 0 or 15) de0: port 0x10100-0x1017f mem 0x81000100-0x8100017f irq 5 at device 8.0 on pci0 de0: interrupting at ISA irq 5 de0: 21040 [10Mb/s] pass 2.4 de0: address 00:80:c8:0d:39:05 Thanks, Martijn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sun Jun 10 12:20:35 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 87E1F37B414 for ; Sun, 10 Jun 2001 12:20:25 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id PAA21767; Sun, 10 Jun 2001 15:20:24 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f5AJJs409480; Sun, 10 Jun 2001 15:19:54 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15139.51289.921776.638438@grasshopper.cs.duke.edu> Date: Sun, 10 Jun 2001 15:19:53 -0400 (EDT) To: Martijn Pronk Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: de network card not working on -current In-Reply-To: References: <15138.34490.249163.348223@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Martijn Pronk writes: > > > Well, this patch works! Thanks! I've just committed the fix to lca, apecs & cia. Interrupt mapping should finally work as well as it does in -stable. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sun Jun 10 14:23:21 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 7C7C037B408 for ; Sun, 10 Jun 2001 14:23:08 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id RAA23220; Sun, 10 Jun 2001 17:23:07 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f5ALMbm09830; Sun, 10 Jun 2001 17:22:37 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15139.58653.503153.281901@grasshopper.cs.duke.edu> Date: Sun, 10 Jun 2001 17:22:37 -0400 (EDT) To: Riccardo.Veraldi@fi.infn.it Cc: Subject: Re: a little bit of support on XFree86 pls... In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Riccardo.Veraldi@fi.infn.it writes: > > Hello, > In the last days I build XFree86 3.3.6_9 (unsuccesfully) , 4.0.3 and 4.1.0 > the last one works fine. the problem with the last two is that xdm > terminates immediately after it is launched. It gives no error, no > warning, it just terminates... anyone has some clue about it ?? Xdm from Free86-4.1.0_3 works fine here. Make sure you've deleted your xdm config files between 3.x and 4.x & installed fresh ones for 4.x. I vaguely remember that some config files changed between 3.x and 4.x & that might cause your problem. Also, I don't know how you got 4.1.0 to build. I just comitted a fix to the FreeBSD port last night. You are building from the ports collection, aren't you? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Jun 11 3: 7:11 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id 2F19037B408; Mon, 11 Jun 2001 03:06:57 -0700 (PDT) (envelope-from wkb@freebie.demon.nl) Received: from [195.11.243.26] (helo=Debug) by post.mail.nl.demon.net with smtp (Exim 3.22 #1) id 159Ob2-000A5J-00; Mon, 11 Jun 2001 10:06:56 +0000 To: freebsd-alpha@freebsd.org Cc: gallatin@freebsd.org From: Wilko Bulte Subject: followup on 8 way SMP pani Date: Mon, 11 Jun 2001 10:06:56 GMT X-Mailer: www.webmail.nl.demon.net X-Sender: postmaster@wkb@freebie.demon.nl X-Originating-IP: 207.122.110.166 Message-Id: Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This a followup to last weeks posting on the AS8400 8-way SMP panic I saw with -current. Hth Wilko ============= class=01-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=12 pci3: on pcib3 pci3: at 3.0 (no driver attached) fatal kernel trap: trap entry = 0x2 (memory management fault) cpuid = 0 faulting va = 0x78 type = access violation cause = load instructon pc = 0xfffffc0000491ae4 ra = 0xfffffc0000491ba8 sp = 0xfffffc00008d9b90 usp = 0x0 curproc = 0xfffffc0000831288 pid = 0, comm = swapper Stopped at sync_other_counter+0x24: ldq s1,0x78(s0) <0x78> db> trace sync_other_counter() at sync_other_counter+0x24 tc_windup() at tc_windup+0x28 hardclock() at hardclock+0x1e8 handleclock() at handleclock+0x22c alpha_clock_interrupt() at alpha_clock_interrupt+0x68 interrupt() at interrupt+0xb8 XentIntlgp() at XentIntlgp+0x14 db> halt ........... turbo#gdb kernel.debug GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "alpha-unknown-freebsd"... (gdb) l *0xfffffc0000491ae4 0xfffffc0000491ae4 is in sync_other_counter (../../kern/kern_tc.c:336). 331 struct timecounter *tc, *tcn, *tco; 332 unsigned delta; 333 334 tco = timecounter; 335 tc = tco->tc_other; 336 tcn = tc->tc_other; 337 *tc = *tco; 338 tc->tc_other = tcn; 339 delta = tco_delta(tc); 340 tc->tc_offset_count += delta; (gdb) quit -- | / o / / _ Arnhem, The Netherlands email: wilko@freebsd.org |/|/ / / /( (_) Bulte http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jun 12 2:17:33 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from postino.fi.infn.it (postino.fi.infn.it [192.84.145.9]) by hub.freebsd.org (Postfix) with ESMTP id 793FA37B401 for ; Tue, 12 Jun 2001 02:17:30 -0700 (PDT) (envelope-from Riccardo.Veraldi@fi.infn.it) Received: from nikita.fi.infn.it (nikita.fi.infn.it [192.84.146.189]) by postino.fi.infn.it (8.11.1/8.11.1) with ESMTP id f5C9HTm17436 for ; Tue, 12 Jun 2001 11:17:29 +0200 (CEST) From: Riccardo.Veraldi@fi.infn.it Received: by nikita.fi.infn.it (Postfix, from userid 1001) id 7099018CE9; Tue, 12 Jun 2001 11:17:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by nikita.fi.infn.it (Postfix) with ESMTP id 3719715902 for ; Tue, 12 Jun 2001 11:17:28 +0200 (CEST) Date: Tue, 12 Jun 2001 11:17:27 +0200 (CEST) X-X-Sender: To: Subject: memory management Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello I have 4.3 Release. I am heavily compiling now and this is the situation: Mem: 137M Active, 39M Inact, 50M Wired, 11M Cache, 45M Buf, 6952K Free Swap: 1024M Total, 38M Used, 985M Free, 3% Inuse isn't it strange that 38MB of swap are in use while 39MB of ram is still inactive ?? I have 256MB RAM total. thanks Rick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jun 12 3:50:30 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from postino.fi.infn.it (postino.fi.infn.it [192.84.145.9]) by hub.freebsd.org (Postfix) with ESMTP id CB6C037B401 for ; Tue, 12 Jun 2001 03:50:27 -0700 (PDT) (envelope-from Riccardo.Veraldi@fi.infn.it) Received: from nikita.fi.infn.it (nikita.fi.infn.it [192.84.146.189]) by postino.fi.infn.it (8.11.1/8.11.1) with ESMTP id f5CAoQm20604 for ; Tue, 12 Jun 2001 12:50:26 +0200 (CEST) From: Riccardo.Veraldi@fi.infn.it Received: by nikita.fi.infn.it (Postfix, from userid 1001) id 1805F18CE9; Tue, 12 Jun 2001 12:50:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by nikita.fi.infn.it (Postfix) with ESMTP id D852D15902 for ; Tue, 12 Jun 2001 12:50:25 +0200 (CEST) Date: Tue, 12 Jun 2001 12:50:25 +0200 (CEST) X-X-Sender: To: Subject: X11 memory usage Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 99154 fddi 2 0 12351M 40576K select 272:38 5.76% 5.76% XFree86 don't u think it looks like strange ?? Isn't too huge the memory usage ?? there must be some mistake perhaps in top ?? thanks Rick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jun 12 4:52:21 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from day.anthologeek.net (day.anthologeek.net [212.43.217.20]) by hub.freebsd.org (Postfix) with ESMTP id 1B26537B401 for ; Tue, 12 Jun 2001 04:52:19 -0700 (PDT) (envelope-from sw@anthologeek.net) Received: by day.anthologeek.net (Postfix, from userid 1000) id D66DA171B8; Tue, 12 Jun 2001 13:50:30 +0200 (CEST) Date: Tue, 12 Jun 2001 13:50:30 +0200 From: Sameh Ghane To: freebsd-alpha@freebsd.org Subject: PPPoE on Alpha Message-ID: <20010612135030.A75202@anthologeek.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i X-PGP-Keys: 0x1289F00D and 0x64565FB8: X-Complaints-To: Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I recently tried to move my ADSL connection, working *really* fine on my x86 FreeBSD system, to a brand new 4.3-RELEASE 21164 alpha system. I used the same ppp.conf, quite casual, just switching ed0 to xl0. I kldloaded netgraph, ng_socket, ng_ether, ng_pppoe, and tried to launch the ppp connection. It started « dialing », and stopped, with this kernel message, coming from ng_pppoe.c: « No matching session ». Does anyone ever experienced this ? What kind of logs could help people investigate this ? Did someone manage to get PPPoE working on FreeBSD-alpha ? Regards, -- Sameh. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jun 12 4:54:21 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from day.anthologeek.net (day.anthologeek.net [212.43.217.20]) by hub.freebsd.org (Postfix) with ESMTP id 7D4EE37B401 for ; Tue, 12 Jun 2001 04:54:19 -0700 (PDT) (envelope-from sw@anthologeek.net) Received: by day.anthologeek.net (Postfix, from userid 1000) id 618E2171B8; Tue, 12 Jun 2001 13:52:42 +0200 (CEST) Date: Tue, 12 Jun 2001 13:52:42 +0200 From: Sameh Ghane To: Riccardo.Veraldi@fi.infn.it Cc: freebsd-alpha@freebsd.org Subject: Re: X11 memory usage Message-ID: <20010612135242.B75202@anthologeek.net> 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 Riccardo.Veraldi@fi.infn.it on Tue, Jun 12, 2001 at 12:50:25PM +0200 X-PGP-Keys: 0x1289F00D and 0x64565FB8: X-Complaints-To: Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Le (On) Tue, Jun 12, 2001 at 12:50:25PM +0200, Riccardo.Veraldi@fi.infn.it ecrivit (wrote): > > 99154 fddi 2 0 12351M 40576K select 272:38 5.76% 5.76% XFree86 > > don't u think it looks like strange ?? Isn't too huge the memory usage ?? > there must be some mistake perhaps in top ?? XFree maps your video card memory, it could be this. -- Sameh. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jun 12 4:57:56 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from day.anthologeek.net (day.anthologeek.net [212.43.217.20]) by hub.freebsd.org (Postfix) with ESMTP id 5594237B40E for ; Tue, 12 Jun 2001 04:57:53 -0700 (PDT) (envelope-from sw@anthologeek.net) Received: by day.anthologeek.net (Postfix, from userid 1000) id 524E2171B8; Tue, 12 Jun 2001 13:56:19 +0200 (CEST) Date: Tue, 12 Jun 2001 13:56:19 +0200 From: Sameh Ghane To: Riccardo.Veraldi@fi.infn.it Cc: freebsd-alpha@freebsd.org Subject: Re: memory management Message-ID: <20010612135619.C75202@anthologeek.net> 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 Riccardo.Veraldi@fi.infn.it on Tue, Jun 12, 2001 at 11:17:27AM +0200 X-PGP-Keys: 0x1289F00D and 0x64565FB8: X-Complaints-To: Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Le (On) Tue, Jun 12, 2001 at 11:17:27AM +0200, Riccardo.Veraldi@fi.infn.it ecrivit (wrote): > > Hello I have 4.3 Release. > > I am heavily compiling now and this is the situation: > > Mem: 137M Active, 39M Inact, 50M Wired, 11M Cache, 45M Buf, 6952K Free > Swap: 1024M Total, 38M Used, 985M Free, 3% Inuse > > isn't it strange that 38MB of swap are in use while 39MB of ram is still > inactive ?? No, this is the normal virtual memory allocation behaviour. Use vmstat to see that these 38M are almost not used at all. -- Sameh. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jun 12 6:48:25 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 0D6E637B401 for ; Tue, 12 Jun 2001 06:48:20 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id JAA08680; Tue, 12 Jun 2001 09:48:19 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f5CDlno15452; Tue, 12 Jun 2001 09:47:49 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15142.7557.473834.213919@grasshopper.cs.duke.edu> Date: Tue, 12 Jun 2001 09:47:49 -0400 (EDT) To: Riccardo.Veraldi@fi.infn.it Cc: Subject: Re: memory management In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Riccardo.Veraldi@fi.infn.it writes: > > Hello I have 4.3 Release. > > I am heavily compiling now and this is the situation: > > Mem: 137M Active, 39M Inact, 50M Wired, 11M Cache, 45M Buf, 6952K Free > Swap: 1024M Total, 38M Used, 985M Free, 3% Inuse > > isn't it strange that 38MB of swap are in use while 39MB of ram is still > inactive ?? Not at all. Some large job, probably an "ld" forced other (more idle) processes out of memory, then exited freeing a large chunk of memory. Those (probably idle) processes have never paged in the memory that was swapped out, so it is still free. It looks like the pager made a good choice ;) This question would almost certainly be better asked in the freebsd-questions forum. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jun 12 7: 0:25 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by hub.freebsd.org (Postfix) with ESMTP id EEDCF37B408 for ; Tue, 12 Jun 2001 07:00:20 -0700 (PDT) (envelope-from ahobson@infloop.homeip.net) Received: from goto.infloop.com (user-vcauh43.dsl.mindspring.com [216.175.68.131]) by blount.mail.mindspring.net (8.9.3/8.8.5) with SMTP id KAA08436 for ; Tue, 12 Jun 2001 10:00:20 -0400 (EDT) Received: (qmail 42653 invoked from network); 12 Jun 2001 14:00:19 -0000 Received: from localhost (HELO goto.infloop.com.mindspring.com) (127.0.0.1) by localhost with SMTP; 12 Jun 2001 14:00:19 -0000 From: Andrew Hobson To: freebsd-alpha@freebsd.org Subject: Re: PPPoE on Alpha References: <20010612135030.A75202@anthologeek.net> Date: 12 Jun 2001 10:00:18 -0400 In-Reply-To: Sameh Ghane's message of "Tue, 12 Jun 2001 13:50:30 +0200" Message-ID: <877kyhhk7h.fsf@goto.infloop.com> Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 12 Jun 2001 13:50:30 +0200, Sameh Ghane said: > Does anyone ever experienced this ? What kind of logs could help > people investigate this ? Did someone manage to get PPPoE working on > FreeBSD-alpha ? Sudish Joseph got it working and filed some PRs that have some workarounds and/or fixes. Check out the PRs kern/27767 (contains a workaround patch) and alpha/27766 (this patch was committed to current and plans were made for it to be committed to stable). Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jun 12 16:10:55 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.127.132]) by hub.freebsd.org (Postfix) with ESMTP id AEECA37B403; Tue, 12 Jun 2001 16:10:49 -0700 (PDT) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (a213-84-32-253.adsl.xs4all.nl [213.84.32.253] (may be forged)) by smtp3.xs4all.nl (8.9.3/8.9.3) with ESMTP id BAA25691; Wed, 13 Jun 2001 01:10:48 +0200 (CEST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.3/8.11.3) id f5CMVas07938; Wed, 13 Jun 2001 00:31:36 +0200 (CEST) (envelope-from wkb) Date: Wed, 13 Jun 2001 00:31:36 +0200 From: Wilko Bulte To: Wilko Bulte Cc: freebsd-alpha@freebsd.org, gallatin@freebsd.org Subject: Re: followup on 8 way SMP pani Message-ID: <20010613003136.A7905@freebie.xs4all.nl> Reply-To: wilko@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from wkb@freebie.demon.nl on Mon, Jun 11, 2001 at 10:06:56AM +0000 X-OS: FreeBSD 4.3-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jun 11, 2001 at 10:06:56AM +0000, Wilko Bulte wrote: Does this make any sense to anybody? Drew, you asked for a traceback? [Or is this me, mucking up his email by switching ISPs?] Wilko > This a followup to last weeks posting on the AS8400 8-way > SMP panic I saw with -current. > > Hth > Wilko > ============= > > > class=01-00-00, hdrtype=0x00, mfdev=0 > intpin=a, irq=12 > pci3: on pcib3 > pci3: at 3.0 (no driver attached) > > fatal kernel trap: > > trap entry = 0x2 (memory management fault) > cpuid = 0 > faulting va = 0x78 > type = access violation > cause = load instructon > pc = 0xfffffc0000491ae4 > ra = 0xfffffc0000491ba8 > sp = 0xfffffc00008d9b90 > usp = 0x0 > curproc = 0xfffffc0000831288 > pid = 0, comm = swapper > > Stopped at sync_other_counter+0x24: ldq s1,0x78(s0) <0x78> > > db> trace > sync_other_counter() at sync_other_counter+0x24 > tc_windup() at tc_windup+0x28 > hardclock() at hardclock+0x1e8 > handleclock() at handleclock+0x22c > alpha_clock_interrupt() at alpha_clock_interrupt+0x68 > interrupt() at interrupt+0xb8 > XentIntlgp() at XentIntlgp+0x14 > db> halt > > > ........... > > turbo#gdb kernel.debug > GNU gdb 4.18 > Copyright 1998 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "alpha-unknown-freebsd"... > (gdb) l *0xfffffc0000491ae4 > 0xfffffc0000491ae4 is in sync_other_counter (../../kern/kern_tc.c:336). > 331 struct timecounter *tc, *tcn, *tco; > 332 unsigned delta; > 333 > 334 tco = timecounter; > 335 tc = tco->tc_other; > 336 tcn = tc->tc_other; > 337 *tc = *tco; > 338 tc->tc_other = tcn; > 339 delta = tco_delta(tc); > 340 tc->tc_offset_count += delta; > (gdb) quit > > > > -- > | / o / / _ Arnhem, The Netherlands email: wilko@freebsd.org > |/|/ / / /( (_) Bulte http://www.freebsd.org > http://www.nlfug.nl > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message ---end of quoted text--- -- | / o / / _ Arnhem, The Netherlands email: wilko@freebsd.org |/|/ / / /( (_) Bulte http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jun 12 18: 3:22 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id D97EF37B408; Tue, 12 Jun 2001 18:03:18 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id VAA24368; Tue, 12 Jun 2001 21:03:18 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f5D12mc16840; Tue, 12 Jun 2001 21:02:48 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15142.48056.299034.909499@grasshopper.cs.duke.edu> Date: Tue, 12 Jun 2001 21:02:48 -0400 (EDT) To: wilko@freebsd.org Cc: freebsd-alpha@freebsd.org, jhb@freebsd.org Subject: Re: followup on 8 way SMP pani In-Reply-To: <20010613003136.A7905@freebie.xs4all.nl> References: <20010613003136.A7905@freebie.xs4all.nl> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Wilko Bulte writes: > On Mon, Jun 11, 2001 at 10:06:56AM +0000, Wilko Bulte wrote: > > Does this make any sense to anybody? Drew, you asked for a traceback? <...> > > trap entry = 0x2 (memory management fault) > > cpuid = 0 > > faulting va = 0x78 > > type = access violation > > cause = load instructon > > pc = 0xfffffc0000491ae4 > > ra = 0xfffffc0000491ba8 > > sp = 0xfffffc00008d9b90 > > usp = 0x0 > > curproc = 0xfffffc0000831288 > > pid = 0, comm = swapper > > > > Stopped at sync_other_counter+0x24: ldq s1,0x78(s0) <0x78> > > > > db> trace > > sync_other_counter() at sync_other_counter+0x24 > > tc_windup() at tc_windup+0x28 > > hardclock() at hardclock+0x1e8 > > handleclock() at handleclock+0x22c > > alpha_clock_interrupt() at alpha_clock_interrupt+0x68 > > interrupt() at interrupt+0xb8 > > XentIntlgp() at XentIntlgp+0x14 > > db> halt > > Yes, sorry I never replied. According to Matt, the turbolaser doesn't have an i8254 timecounter. And the alpha timecounter is never initialized in alpha/alpha/clock.c if ncpus>1, so you're taking a clock interrupt with no timecounter. Oops. No MP for TurboLasers right now, I guess. Here's the code in question: /* * XXX: TurboLaser doesn't have an i8254 counter. * XXX: A replacement is needed, and another method * XXX: of determining this would be nice. */ if (hwrpb->rpb_type != ST_DEC_21000) { tc_init(&i8254_timecounter); } if (ncpus == 1) { alpha_timecounter.tc_frequency = freq; tc_init(&alpha_timecounter); } I think there are bigger fish to fry right now, but this needs to be fixed. I'm not at all sure what to do, since I don't think that the cycle counters on multiple cpus are in sync.. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jun 12 18:59:11 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id C78B737B403; Tue, 12 Jun 2001 18:59:07 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo (mjacob@beppo [192.67.166.79]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f5D1x4g39257; Tue, 12 Jun 2001 18:59:04 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Tue, 12 Jun 2001 18:59:04 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Andrew Gallatin Cc: wilko@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: followup on 8 way SMP pani In-Reply-To: <15142.48056.299034.909499@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Oh! I was really snoozing- many other things happening (mostly personal)! This should be easy to fix- let me look at this tomorrow. On Tue, 12 Jun 2001, Andrew Gallatin wrote: > > Wilko Bulte writes: > > On Mon, Jun 11, 2001 at 10:06:56AM +0000, Wilko Bulte wrote: > > > > Does this make any sense to anybody? Drew, you asked for a traceback? > > <...> > > > > trap entry = 0x2 (memory management fault) > > > cpuid = 0 > > > faulting va = 0x78 > > > type = access violation > > > cause = load instructon > > > pc = 0xfffffc0000491ae4 > > > ra = 0xfffffc0000491ba8 > > > sp = 0xfffffc00008d9b90 > > > usp = 0x0 > > > curproc = 0xfffffc0000831288 > > > pid = 0, comm = swapper > > > > > > Stopped at sync_other_counter+0x24: ldq s1,0x78(s0) <0x78> > > > > > > db> trace > > > sync_other_counter() at sync_other_counter+0x24 > > > tc_windup() at tc_windup+0x28 > > > hardclock() at hardclock+0x1e8 > > > handleclock() at handleclock+0x22c > > > alpha_clock_interrupt() at alpha_clock_interrupt+0x68 > > > interrupt() at interrupt+0xb8 > > > XentIntlgp() at XentIntlgp+0x14 > > > db> halt > > > > > Yes, sorry I never replied. According to Matt, the turbolaser doesn't > have an i8254 timecounter. And the alpha timecounter is never > initialized in alpha/alpha/clock.c if ncpus>1, so you're taking a > clock interrupt with no timecounter. Oops. No MP for TurboLasers > right now, I guess. > > Here's the code in question: > > /* > * XXX: TurboLaser doesn't have an i8254 counter. > * XXX: A replacement is needed, and another method > * XXX: of determining this would be nice. > */ > if (hwrpb->rpb_type != ST_DEC_21000) { > tc_init(&i8254_timecounter); > } > > if (ncpus == 1) { > alpha_timecounter.tc_frequency = freq; > tc_init(&alpha_timecounter); > } > > I think there are bigger fish to fry right now, but this needs to be > fixed. I'm not at all sure what to do, since I don't think that > the cycle counters on multiple cpus are in sync.. > > Drew > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jun 12 22: 7:37 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from technokratis.com (modemcable052.174-202-24.mtl.mc.videotron.ca [24.202.174.52]) by hub.freebsd.org (Postfix) with ESMTP id D918237B403; Tue, 12 Jun 2001 22:07:16 -0700 (PDT) (envelope-from bmilekic@technokratis.com) Received: (from bmilekic@localhost) by technokratis.com (8.11.3/8.11.3) id f5D57jT04198; Wed, 13 Jun 2001 01:07:45 -0400 (EDT) (envelope-from bmilekic) Date: Wed, 13 Jun 2001 01:07:44 -0400 From: Bosko Milekic To: freebsd-current@freebsd.org Cc: freebsd-alpha@freebsd.org Subject: New SMP Mbuf Allocator (PATCH and TESTING request) Message-ID: <20010613010744.A4083@technokratis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi -current && -alpha, If you run -CURRENT on multiprocessor alpha, please please please read this! :-) The final version (or next to final, depending on how this final testing stage goes) of the new mbuf allocator which I have been working on for the past 1.5 months and which I've already mentionned on -arch is now ready. I plan to commit the new bits within the next week. However, as is usually the case with commits of this magnitude, I'd like a few more tests to be run by a few more people. I've been testing the allocator myself (in several different ways, mainly resource exhaustion simulations) for the past couple of weeks and have been able to catch and fix a couple of bugs. Also, jake, jlemon, and Silby (Mike Silbersack) have provided me with some reviews, all of which have been integrated into the latest version of the patch (below). The latest version of the "mb_alloc" code, applying to -CURRENT as of 5 minutes ago can be found here: http://people.freebsd.org/~bmilekic/code/mb_slab/mb_alloc-LATEST.diff People who have the following hardware are needed to help test the patch: 1- UP -CURRENT systems (Intel && Alpha) 2- SMP -CURRENT systems (Intel) 3- SMP -CURRENT systems (Alpha) *** Especially important *** who are *not* using the if_vx.c driver [*] [*] The if_vx.c driver is broken for the Alpha, and is marked so by this patch. Before committing this, I plan to first fix the driver but, obviously, for now, if you are using if_vx, you won't be able to help with testing. :-( To test the patch: apply, build, reboot, do network-related things, check stats with `netstat -m', etc. For those looking at the code: Finally, a few things should be noted about the code itself (if you're just helping test, feel free to skip this part): - I disabled mbtypes[] related statistics _FOR NOW_. This is because if I were to presently enable them, I wouldn't be able to consistently update them (unless I do it atomic()ally, which is not so good for overall performance). I plan to re-enable them later on, but would prefer to wait and go over them (perhaps clean them up - add/remove types as needed - many are if 0'd anyway) rather than rush and waste time doing it now. - The patch is big. sys/mbuf.h includes need to also #include _BEFORE_ because sys/mbuf.h requires MALLOC_DECLARE() to be defined. - counters for m_ext objects are now all malloc()ed. This will likely eventually change for what concerns clusters (I am looking at storing the cluster counter in the cluster 2 region itself). For other object types, I plan to leave malloc() as the standard allocator for the counters, seeing as how the external objects are not allocated in a PCPU fashion anyway. That's it! This patch also sets up the way to more mbuf-related cleanups (i.e. obvious ones like merging uipc_mbuf.c code with uipc_mbuf2.c code, and ridding ourselves of the latter, etc.). It also moves a bundle of mbuf related things out of sys/conf/param.c and into subr_mbuf.c, where they will now belong. :-) Best Regards and PLEASE help test (especially if you have alpha hardware!!!), -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jun 12 22:13:30 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id DEEC137B40A; Tue, 12 Jun 2001 22:13:19 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo (mjacob@beppo [192.67.166.79]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f5D5DCg39508; Tue, 12 Jun 2001 22:13:16 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Tue, 12 Jun 2001 22:13:12 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Bosko Milekic Cc: freebsd-current@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: New SMP Mbuf Allocator (PATCH and TESTING request) In-Reply-To: <20010613010744.A4083@technokratis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Right, will do some testing, thanks.. can you give us a bit more than a week tho? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jun 12 22:23: 3 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from technokratis.com (modemcable052.174-202-24.mtl.mc.videotron.ca [24.202.174.52]) by hub.freebsd.org (Postfix) with ESMTP id 707EF37B401; Tue, 12 Jun 2001 22:22:56 -0700 (PDT) (envelope-from bmilekic@technokratis.com) Received: (from bmilekic@localhost) by technokratis.com (8.11.3/8.11.3) id f5D5NMX04378; Wed, 13 Jun 2001 01:23:22 -0400 (EDT) (envelope-from bmilekic) Date: Wed, 13 Jun 2001 01:23:21 -0400 From: Bosko Milekic To: Matthew Jacob Cc: freebsd-current@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: New SMP Mbuf Allocator (PATCH and TESTING request) Message-ID: <20010613012321.A4311@technokratis.com> References: <20010613010744.A4083@technokratis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mjacob@feral.com on Tue, Jun 12, 2001 at 10:13:12PM -0700 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jun 12, 2001 at 10:13:12PM -0700, Matthew Jacob wrote: > > Right, will do some testing, thanks.. can you give us a bit more than a week > tho? Your prompt reply is extremely encouraging. Thanks! :-)))) The reason I said "in the next week" is actually because on Sat. June 23rd (not this upcoming one, but the one after), I should be flying off to Yugoslavia (actually to London, and only then to Yugoslavia). I will be gone for 3 weeks and seeing as how maintaining this huge diff is a real **** (especially given the state of -CURRENT, as I'm sure you know :-)), I would really like to commit it before then. Preferably not this next Thursday (this week) but the thursday next week, to give me a 1.5 day `buffer zone' in case of emergency (The Infamous Pointy-Hat Award). I've given it considerable testing on Intel hardware and don't really expect any problems on alpha, but better be safe than accidently break alpha and have some very peeved developers on my tail. :-) Cheers and thanks again, -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jun 12 23:15:42 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 8C4AE37B401; Tue, 12 Jun 2001 23:15:36 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo (mjacob@beppo [192.67.166.79]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f5D6FWg39583; Tue, 12 Jun 2001 23:15:32 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Tue, 12 Jun 2001 23:15:32 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Bosko Milekic Cc: freebsd-current@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: New SMP Mbuf Allocator (PATCH and TESTING request) In-Reply-To: <20010613012321.A4311@technokratis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 13 Jun 2001, Bosko Milekic wrote: > > On Tue, Jun 12, 2001 at 10:13:12PM -0700, Matthew Jacob wrote: > > > > Right, will do some testing, thanks.. can you give us a bit more than a week > > tho? > > Your prompt reply is extremely encouraging. Thanks! :-)))) > > The reason I said "in the next week" is actually because on Sat. June 23rd > (not this upcoming one, but the one after), I should be flying off to > Yugoslavia (actually to London, and only then to Yugoslavia). I will be > gone for 3 weeks and seeing as how maintaining this huge diff is a real > **** (especially given the state of -CURRENT, as I'm sure you know :-)), > I would really like to commit it before then. Preferably not this next > Thursday (this week) but the thursday next week, to give me a 1.5 day > `buffer zone' in case of emergency (The Infamous Pointy-Hat Award). Okay- good- this gives me a bit of headroom to tackle this- there's about 10 days. > > I've given it considerable testing on Intel hardware and don't really > expect any problems on alpha, but better be safe than accidently break > alpha and have some very peeved developers on my tail. :-) > > Cheers and thanks again, > -- > Bosko Milekic > bmilekic@technokratis.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jun 12 23:33:51 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id CAAAD37B42F; Tue, 12 Jun 2001 23:33:41 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo (mjacob@beppo [192.67.166.79]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f5D6Xcg39686; Tue, 12 Jun 2001 23:33:39 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Tue, 12 Jun 2001 23:33:38 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Andrew Gallatin Cc: wilko@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: followup on 8 way SMP pani In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org No, I likely *won't* be able to fix this today, as kernels built with the latest panic with: recursed on non-recursive lock (sleep mutex) mbuf free list lock @ ../../kern/uipc_mbuf.c:582 first acquired @ ../../kern/uipc_socket.c:875 panic: recurse cpuid = 0; panic Stopped at Debugger+0x34: zapnot v0,#0xf,a0 db> t Debugger() at Debugger+0x34 panic() at panic+0x178 witness_lock() at witness_lock+0x488 m_freem() at m_freem+0x4e8 soreceive() at soreceive+0x19dc recvit() at recvit+0x1a4 recvfrom() at recvfrom+0x9c syscall() at syscall+0x708 XentSys() at XentSys+0x64 --- syscall (29, FreeBSD ELF, recvfrom) --- --- user mode --- What I needed to fix for turbolaser is to clear the timer interrupt for all CPUs but the primary CPU- this is the TLINTRMASK{0,1} registers. But, stupid me, I upgraded my source first. -matt On Tue, 12 Jun 2001, Matthew Jacob wrote: > > Oh! I was really snoozing- many other things happening (mostly personal)! > > This should be easy to fix- let me look at this tomorrow. > > On Tue, 12 Jun 2001, Andrew Gallatin wrote: > > > > > Wilko Bulte writes: > > > On Mon, Jun 11, 2001 at 10:06:56AM +0000, Wilko Bulte wrote: > > > > > > Does this make any sense to anybody? Drew, you asked for a traceback? > > > > <...> > > > > > > trap entry = 0x2 (memory management fault) > > > > cpuid = 0 > > > > faulting va = 0x78 > > > > type = access violation > > > > cause = load instructon > > > > pc = 0xfffffc0000491ae4 > > > > ra = 0xfffffc0000491ba8 > > > > sp = 0xfffffc00008d9b90 > > > > usp = 0x0 > > > > curproc = 0xfffffc0000831288 > > > > pid = 0, comm = swapper > > > > > > > > Stopped at sync_other_counter+0x24: ldq s1,0x78(s0) <0x78> > > > > > > > > db> trace > > > > sync_other_counter() at sync_other_counter+0x24 > > > > tc_windup() at tc_windup+0x28 > > > > hardclock() at hardclock+0x1e8 > > > > handleclock() at handleclock+0x22c > > > > alpha_clock_interrupt() at alpha_clock_interrupt+0x68 > > > > interrupt() at interrupt+0xb8 > > > > XentIntlgp() at XentIntlgp+0x14 > > > > db> halt > > > > > > > > Yes, sorry I never replied. According to Matt, the turbolaser doesn't > > have an i8254 timecounter. And the alpha timecounter is never > > initialized in alpha/alpha/clock.c if ncpus>1, so you're taking a > > clock interrupt with no timecounter. Oops. No MP for TurboLasers > > right now, I guess. > > > > Here's the code in question: > > > > /* > > * XXX: TurboLaser doesn't have an i8254 counter. > > * XXX: A replacement is needed, and another method > > * XXX: of determining this would be nice. > > */ > > if (hwrpb->rpb_type != ST_DEC_21000) { > > tc_init(&i8254_timecounter); > > } > > > > if (ncpus == 1) { > > alpha_timecounter.tc_frequency = freq; > > tc_init(&alpha_timecounter); > > } > > > > I think there are bigger fish to fry right now, but this needs to be > > fixed. I'm not at all sure what to do, since I don't think that > > the cycle counters on multiple cpus are in sync.. > > > > Drew > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-alpha" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 0:30:30 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by hub.freebsd.org (Postfix) with ESMTP id F09E037B409; Wed, 13 Jun 2001 00:30:12 -0700 (PDT) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (a213-84-32-253.adsl.xs4all.nl [213.84.32.253] (may be forged)) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id JAA24727; Wed, 13 Jun 2001 09:10:46 +0200 (CEST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.3/8.11.3) id f5D6mIH10247; Wed, 13 Jun 2001 08:48:18 +0200 (CEST) (envelope-from wkb) Date: Wed, 13 Jun 2001 08:48:18 +0200 From: Wilko Bulte To: Matthew Jacob Cc: Andrew Gallatin , wilko@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: followup on 8 way SMP pani Message-ID: <20010613084818.A10232@freebie.xs4all.nl> Reply-To: wilko@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from mjacob@feral.com on Tue, Jun 12, 2001 at 11:33:38PM -0700 X-OS: FreeBSD 4.3-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jun 12, 2001 at 11:33:38PM -0700, Matthew Jacob wrote: Not to worry. The 8 way box is going to be powered down tomorrow for moving it to another building. I don't expect it to be back /me having the time until end of next week (earliest). Wilko > No, I likely *won't* be able to fix this today, as kernels built with the > latest panic with: > > recursed on non-recursive lock (sleep mutex) mbuf free list lock @ > ../../kern/uipc_mbuf.c:582 > first acquired @ ../../kern/uipc_socket.c:875 > panic: recurse > cpuid = 0; panic > Stopped at Debugger+0x34: zapnot v0,#0xf,a0 > db> t > Debugger() at Debugger+0x34 > panic() at panic+0x178 > witness_lock() at witness_lock+0x488 > m_freem() at m_freem+0x4e8 > soreceive() at soreceive+0x19dc > recvit() at recvit+0x1a4 > recvfrom() at recvfrom+0x9c > syscall() at syscall+0x708 > XentSys() at XentSys+0x64 > --- syscall (29, FreeBSD ELF, recvfrom) --- > --- user mode --- > > > What I needed to fix for turbolaser is to clear the timer interrupt for all > CPUs but the primary CPU- this is the TLINTRMASK{0,1} registers. But, stupid > me, I upgraded my source first. > > -matt > > > On Tue, 12 Jun 2001, Matthew Jacob wrote: > > > > > Oh! I was really snoozing- many other things happening (mostly personal)! > > > > This should be easy to fix- let me look at this tomorrow. > > > > On Tue, 12 Jun 2001, Andrew Gallatin wrote: > > > > > > > > Wilko Bulte writes: > > > > On Mon, Jun 11, 2001 at 10:06:56AM +0000, Wilko Bulte wrote: > > > > > > > > Does this make any sense to anybody? Drew, you asked for a traceback? > > > > > > <...> > > > > > > > > trap entry = 0x2 (memory management fault) > > > > > cpuid = 0 > > > > > faulting va = 0x78 > > > > > type = access violation > > > > > cause = load instructon > > > > > pc = 0xfffffc0000491ae4 > > > > > ra = 0xfffffc0000491ba8 > > > > > sp = 0xfffffc00008d9b90 > > > > > usp = 0x0 > > > > > curproc = 0xfffffc0000831288 > > > > > pid = 0, comm = swapper > > > > > > > > > > Stopped at sync_other_counter+0x24: ldq s1,0x78(s0) <0x78> > > > > > > > > > > db> trace > > > > > sync_other_counter() at sync_other_counter+0x24 > > > > > tc_windup() at tc_windup+0x28 > > > > > hardclock() at hardclock+0x1e8 > > > > > handleclock() at handleclock+0x22c > > > > > alpha_clock_interrupt() at alpha_clock_interrupt+0x68 > > > > > interrupt() at interrupt+0xb8 > > > > > XentIntlgp() at XentIntlgp+0x14 > > > > > db> halt > > > > > > > > > > > Yes, sorry I never replied. According to Matt, the turbolaser doesn't > > > have an i8254 timecounter. And the alpha timecounter is never > > > initialized in alpha/alpha/clock.c if ncpus>1, so you're taking a > > > clock interrupt with no timecounter. Oops. No MP for TurboLasers > > > right now, I guess. > > > > > > Here's the code in question: > > > > > > /* > > > * XXX: TurboLaser doesn't have an i8254 counter. > > > * XXX: A replacement is needed, and another method > > > * XXX: of determining this would be nice. > > > */ > > > if (hwrpb->rpb_type != ST_DEC_21000) { > > > tc_init(&i8254_timecounter); > > > } > > > > > > if (ncpus == 1) { > > > alpha_timecounter.tc_frequency = freq; > > > tc_init(&alpha_timecounter); > > > } > > > > > > I think there are bigger fish to fry right now, but this needs to be > > > fixed. I'm not at all sure what to do, since I don't think that > > > the cycle counters on multiple cpus are in sync.. > > > > > > Drew > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-alpha" in the body of the message > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-alpha" in the body of the message > > ---end of quoted text--- -- | / o / / _ Arnhem, The Netherlands email: wilko@freebsd.org |/|/ / / /( (_) Bulte http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 0:37:59 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 5507E37B405; Wed, 13 Jun 2001 00:37:51 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.3/8.11.3) with ESMTP id f5D7mEn08071; Wed, 13 Jun 2001 00:48:14 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200106130748.f5D7mEn08071@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Bosko Milekic Cc: Matthew Jacob , freebsd-current@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: New SMP Mbuf Allocator (PATCH and TESTING request) In-reply-to: Your message of "Wed, 13 Jun 2001 01:23:21 EDT." <20010613012321.A4311@technokratis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Jun 2001 00:48:14 -0700 From: Mike Smith Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > The reason I said "in the next week" is actually because on Sat. June 23rd > (not this upcoming one, but the one after), I should be flying off to > Yugoslavia (actually to London, and only then to Yugoslavia). I will be > gone for 3 weeks and seeing as how maintaining this huge diff is a real > **** (especially given the state of -CURRENT, as I'm sure you know :-)), I realise that maintaining the diff is a major pain, but this is *not* a good reason to be rushing it now, *especially* when you're going to be gone for three weeks. I appreciate the extra work involved, but please take this as an extremely serious request to defer your commit until it's had some more testing, and until you're in a position to support it for more than 36 hours after you commit. Thanks. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 9: 5:41 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from schottky.phys.ksu.edu (schottky.phys.ksu.edu [129.130.5.45]) by hub.freebsd.org (Postfix) with SMTP id 1113D37B40C for ; Wed, 13 Jun 2001 09:05:33 -0700 (PDT) (envelope-from chriss@phys.ksu.edu) Received: (qmail 15863 invoked by uid 962); 13 Jun 2001 16:05:20 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 13 Jun 2001 16:05:20 -0000 Date: Wed, 13 Jun 2001 11:05:20 -0500 (CDT) From: Chris Casey To: David O'Brien Cc: Andrew Gallatin , alpha@FreeBSD.ORG Subject: Re: ccc In-Reply-To: <20010607091342.E91396@dragon.nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Welp... I've gotten nowhere. I cant seem to find a way to make ccc and fort play nice together when ccc makes native binaries. Dont know if ccc will make linux binaries ok, which might be the only alternative for me at the moment. should anyone decide to tackle this and make it all happy let me know Chris Casey Unix System Administrator KSU Physics Department (785) 532-6810 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 9:10:11 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [206.40.252.115]) by hub.freebsd.org (Postfix) with ESMTP id 1C33237B405 for ; Wed, 13 Jun 2001 09:10:07 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f5DGA3c27580; Wed, 13 Jun 2001 09:10:04 -0700 (PDT) (envelope-from obrien) Date: Wed, 13 Jun 2001 09:10:03 -0700 From: "David O'Brien" To: Chris Casey Cc: Andrew Gallatin , alpha@FreeBSD.ORG Subject: Re: ccc Message-ID: <20010613091003.A27559@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20010607091342.E91396@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from chriss@phys.ksu.edu on Wed, Jun 13, 2001 at 11:05:20AM -0500 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Jun 13, 2001 at 11:05:20AM -0500, Chris Casey wrote: > Welp... I've gotten nowhere. I cant seem to find a way to make ccc and > fort play nice together when ccc makes native binaries. Dont know if ccc > will make linux binaries ok, which might be the only alternative for me at > the moment. You have yet to post that you have followed my suggestion of manually installing the older 1.0.x Compaq Fortran version, with out linux_devel installed. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 9:30:16 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from schottky.phys.ksu.edu (schottky.phys.ksu.edu [129.130.5.45]) by hub.freebsd.org (Postfix) with SMTP id 9CE6D37B401 for ; Wed, 13 Jun 2001 09:30:07 -0700 (PDT) (envelope-from chriss@phys.ksu.edu) Received: (qmail 15933 invoked by uid 962); 13 Jun 2001 16:30:05 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 13 Jun 2001 16:30:05 -0000 Date: Wed, 13 Jun 2001 11:30:05 -0500 (CDT) From: Chris Casey Reply-To: Chris Casey To: David O'Brien Cc: Andrew Gallatin , alpha@FreeBSD.ORG Subject: Re: ccc In-Reply-To: <20010613091003.A27559@dragon.nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org sorry, been a mess here lately. If i'm overlooking something i'll gladly try things differently. This is fort with only linux_base, no linux_devtools. Looks to be the same symptoms with the newer version I tried before the same results it appears: lrwxr-xr-x 1 root wheel 10 Jun 13 16:20 cfal -> cfal-1.0.1 drwxr-xr-x 2 root wheel 512 Jun 11 16:49 cfal-1.0.1 lrwxr-xr-x 1 root wheel 13 Jun 11 16:49 cfalrtl -> cfalrtl-1.0.1 drwxr-xr-x 2 root wheel 512 Jun 11 16:49 cfalrtl-1.0.1 drwxr-xr-x 2 root wheel 512 Jun 11 16:57 cpml-5.1.0 drwxr-xr-x 2 root wheel 512 Jun 11 16:53 cxml-4.1.0 drwxr-xr-x 2 root wheel 512 Jun 11 16:49 ladebug-4.0.62 drwxr-xr-x 2 root wheel 512 Jun 11 16:48 libots-2.2.7 root@polaris:~test> /compat/linux/usr/bin/fort -v -extend_source -arch ev6 -L/compat/linux/usr/lib -lcxml -o CN1D_2 CrankNicholson.1D.f /usr/lib/compaq/cfal/decfort90 -extend_source -arch ev6 -o /tmp/forevKnT1.o CrankNicholson.1D.f /usr/bin/cc -v -L/compat/linux/usr/lib -o CN1D_2 /usr/lib/compaq/cfal/for_main.o /tmp/forevKnT1.o -O4 -lcxml -lUfor -lfor -lFutil -lcpml -lots Using builtin specs. gcc version 2.95.3 [FreeBSD] 20010315 (release) /usr/libexec/elf/ld -m elf64alpha -dynamic-linker /usr/libexec/ld-elf.so.1 -o CN1D_2 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/compat/linux/usr/lib -L/usr/libexec/elf -L/usr/libexec -L/usr/lib /usr/lib/compaq/cfal/for_main.o /tmp/forevKnT1.o -lcxml -lUfor -lfor -lFutil -lcpml -lots -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o /usr/libexec/elf/ld: warning: libcpml.so, needed by /compat/linux/usr/lib/libUfor.so, not found (try using -rpath or -rpath-link) /usr/libexec/elf/ld: warning: libc.so.6.1, needed by /compat/linux/usr/lib/libUfor.so, not found (try using -rpath or -rpath-link) /compat/linux/usr/lib/libfor.so: undefined reference to `getenv@GLIBC_2.0' /compat/linux/usr/lib/libUfor.so: undefined reference to `strcpy@GLIBC_2.0' /compat/linux/usr/lib/libfor.so: undefined reference to `strchr@GLIBC_2.0' /compat/linux/usr/lib/libUfor.so: undefined reference to `catclose@GLIBC_2.0' /compat/linux/usr/lib/libfor.so: undefined reference to `_IO_getc@GLIBC_2.0' /compat/linux/usr/lib/libfor.so: undefined reference to `strftime@GLIBC_2.0' /compat/linux/usr/lib/libcxml.so: undefined reference to `stdout' /compat/linux/usr/lib/libcxml.so: undefined reference to `__ieee_get_fp_control' /compat/linux/usr/lib/libUfor.so: undefined reference to `localtime@GLIBC_2.0' /compat/linux/usr/lib/libUfor.so: undefined reference to `strncpy@GLIBC_2.0' /compat/linux/usr/lib/libUfor.so: undefined reference to `strcmp@GLIBC_2.0' /compat/linux/usr/lib/libfor.so: undefined reference to `gettimeofday@GLIBC_2.1' /compat/linux/usr/lib/libUfor.so: undefined reference to `alarm@GLIBC_2.0' /compat/linux/usr/lib/libfor.so: undefined reference to `tolower@GLIBC_2.0' /compat/linux/usr/lib/libUfor.so: undefined reference to `sprintf@GLIBC_2.0' /compat/linux/usr/lib/libfor.so: undefined reference to `strncat@GLIBC_2.0' /compat/linux/usr/lib/libfor.so: undefined reference to `strncmp@GLIBC_2.0' /compat/linux/usr/lib/libUfor.so: undefined reference to `getrusage@GLIBC_2.1' /compat/linux/usr/lib/libUfor.so: undefined reference to `__lxstat@GLIBC_2.0' /compat/linux/usr/lib/libUfor.so: undefined reference to `gmtime@GLIBC_2.0' ... /compat/linux/usr/lib/libUfor.so: undefined reference to `abort@GLIBC_2.0' /compat/linux/usr/lib/libfor.so: undefined reference to `__xstat@GLIBC_2.0' /compat/linux/usr/lib/libfor.so: undefined reference to `getpwnam@GLIBC_2.0' fort: Severe: Failed while trying to link. root@polaris:~test> On Wed, 13 Jun 2001, David O'Brien wrote: > > You have yet to post that you have followed my suggestion of manually > installing the older 1.0.x Compaq Fortran version, with out linux_devel > installed. Chris Casey Unix System Administrator KSU Physics Department (785) 532-6810 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 9:31:17 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by hub.freebsd.org (Postfix) with ESMTP id 0900A37B40A; Wed, 13 Jun 2001 09:31:04 -0700 (PDT) (envelope-from bmah@cisco.com) Received: from bmah-freebsd-0.cisco.com (bmah-freebsd-0.cisco.com [171.70.84.42]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5DGV9k03296; Wed, 13 Jun 2001 09:31:09 -0700 (PDT) Received: (from bmah@localhost) by bmah-freebsd-0.cisco.com (8.11.3/8.11.3) id f5DGUos42334; Wed, 13 Jun 2001 09:30:50 -0700 (PDT) (envelope-from bmah) Message-Id: <200106131630.f5DGUos42334@bmah-freebsd-0.cisco.com> X-Mailer: exmh version 2.4+ 06/08/2001 with nmh-1.0.4 To: Andrew Gallatin Cc: Wilko Bulte , Nik Clayton , freebsd-doc@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: Alpha support In-Reply-To: <15142.32892.736852.905658@grasshopper.cs.duke.edu> References: <3B24B283.F3AE6732@microtecsecurite.com> <15141.34506.42116.225862@grasshopper.cs.duke.edu> <01061215581501.37769@clan.nothing-going-on.org> <15142.15013.507657.7384@grasshopper.cs.duke.edu> <20010612202042.A5507@freebie.xs4all.nl> <15142.32892.736852.905658@grasshopper.cs.duke.edu> Comments: In-reply-to Andrew Gallatin message dated "Tue, 12 Jun 2001 16:50:04 -0400." From: "Bruce A. Mah" Reply-To: bmah@FreeBSD.ORG X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1615275638P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 13 Jun 2001 09:30:50 -0700 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --==_Exmh_-1615275638P Content-Type: text/plain; charset=us-ascii [Discussion about the alpha hardware list moved to -doc and -alpha] If memory serves me right, Andrew Gallatin wrote: > > If we could get the html rendered HARDWARE.TXT (it is actually named > > different today but never mind) onto the web I would consider that to > > be a good start. dd did some work on trying to integrate RELNOTESng (which includes the content from the old HARDWARE.TXT, for the i386 and alpha) into the Web site build. I don't know what's necessary to finish this, but it's becoming more and more important. wilko, by the way, did a darn fine job in SGML-ifying his already-impressive HARDWARE.TXT file. > > Given that, I can probably crank out some sgml/html to glue things togethe > r. > > Related (somewhat) question: can we handle pictures? Given my new digital > > camera I was thinking of getting shots from the Alphas I have access to > > and integrate those somehow. We can do images in the DocBook documents...the FDP primer says how (SGML Markup->DocBook->Images). RELNOTESng right now doesn't use any images whatsoever, but I don't foresee this being a problem. > I'd love to see the html'ified HARDWARE.TXT on the web. I think > pictures and a cool design would be very neat, if doable. But I think > getting some useful information on the web site sooner rather than > later would be best. If you haven't seen it, it'll look something like this: http://people.freebsd.org/~bmah/relnotes/CURRENT/hardware-alpha.html Bruce. PS. As nik pointed out earlier, a lot of people on the -doc team (including myself) aren't all that familiar with the alpha. Concrete suggestions for fixing up the hardware list gratefully accepted (especially for devices that are only supported on the i386 but somehow showed up in the alpha document build). --==_Exmh_-1615275638P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: Exmh version 2.3.1+ 05/14/2001 iD8DBQE7J5U52MoxcVugUsMRAu3sAJ0QGQwEoPebpcu82xShP7bly1KTTwCfYfjv ++Yv2WtnGyDDg2OK/6rAmZI= =ryyw -----END PGP SIGNATURE----- --==_Exmh_-1615275638P-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 9:37:28 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from internet.hilbrink.nl (ns.hilbrink.nl [212.136.135.66]) by hub.freebsd.org (Postfix) with ESMTP id B678337B40A for ; Wed, 13 Jun 2001 09:37:06 -0700 (PDT) (envelope-from cor@hilbrink.nl) Received: from cpqpc (cpqpc.hilbrink.nl [212.136.135.151]) by internet.hilbrink.nl (8.8.8/8.8.8) with SMTP id SAA02915 for ; Wed, 13 Jun 2001 18:45:41 +0200 (CEST) (envelope-from cor@hilbrink.nl) Message-ID: <007f01c0f426$bc9b41c0$978788d4@hilbrink.nl> Reply-To: "Cor Hilbrink" From: "Cor Hilbrink" To: Subject: Graphical card Alpha DS10l supported under X11?? Date: Wed, 13 Jun 2001 18:34:37 +0200 Organization: Hilbrink IT Solutions MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01C0F437.7FE0EE40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-alpha@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. ------=_NextPart_000_007C_01C0F437.7FE0EE40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello. For the moment we are trying to install a DS10L with FreeBSD for Alpha. This machine contains a Elsa Gloria Synergy-8 video adapter, does anyone = know how to configure X? We tried several cardtypes, but thusfar we didn't suceed to get XWindows = running properly. I hope that anyone can tell us a bit more how this can be solved. Regards, Cor Hilbrink. ------=_NextPart_000_007C_01C0F437.7FE0EE40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello.
 
For the moment we are trying to install = a DS10L=20 with FreeBSD for Alpha.
This machine contains a Elsa Gloria = Synergy-8 video=20 adapter, does anyone know how to configure X?
We tried several cardtypes, but thusfar = we didn't=20 suceed to get XWindows running properly.
 
I hope that anyone can tell us a bit = more how this=20 can be solved.
 
Regards,
 
Cor = Hilbrink.
------=_NextPart_000_007C_01C0F437.7FE0EE40-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 9:45:11 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 8A08C37B403 for ; Wed, 13 Jun 2001 09:45:06 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id MAA10168; Wed, 13 Jun 2001 12:45:06 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f5DGiaD18823; Wed, 13 Jun 2001 12:44:36 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15143.39027.877073.655469@grasshopper.cs.duke.edu> Date: Wed, 13 Jun 2001 12:44:35 -0400 (EDT) To: "Cor Hilbrink" Cc: Subject: Re: Graphical card Alpha DS10l supported under X11?? In-Reply-To: <007f01c0f426$bc9b41c0$978788d4@hilbrink.nl> References: <007f01c0f426$bc9b41c0$978788d4@hilbrink.nl> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Cor Hilbrink writes: > Hello. > > For the moment we are trying to install a DS10L with FreeBSD for Alpha. > This machine contains a Elsa Gloria Synergy-8 video adapter, does anyone know how to configure X? > We tried several cardtypes, but thusfar we didn't suceed to get XWindows running properly. > > I hope that anyone can tell us a bit more how this can be solved. > You failed to mention what version of FreeBSD you're using, what version of the XFree86 distro you're using & what the trouble is. Without this informaiton, there's not a lot anybody here can do to help you, other than to make general suggestion. If you're using XFree86 3.x, note that (as David O'Brien pointed out): The "graphical" XFree86 configuration program -- XF86Setup program *requires* the VGA16 server. This server does NOT build on the Alpha. Not just FreeBSD/alpha, but AlphaLinux and Tru86 also. The issue with using the text-only xf86config is that it does not know about moused's sysmouse. Thus you either cannot use moused, or you must hack the /etc/XF86Config file xf86config creates to specify sysmouse. Note that you'll want to use the XF86_3DLabs Xserver under XF86 3.x For what its worth, I just built XF86 4.1.0 from ports & the XServer for the AGP Elsa Gloria Synergy card seems to work just fine on my UP1000. I'm not sure what the trailing -8 of your card signifies. I hope this random smattering of information is somewhat helpful. BTW, please don't post html on the freebsd mailing lists. Cheers, Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 9:57:10 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 65E8B37B403; Wed, 13 Jun 2001 09:57:01 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f5DGuk139217; Wed, 13 Jun 2001 09:56:46 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 13 Jun 2001 09:56:49 -0700 (PDT) From: John Baldwin To: Matthew Jacob Subject: Re: followup on 8 way SMP pani Cc: freebsd-alpha@FreeBSD.org, wilko@FreeBSD.org, Andrew Gallatin Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 13-Jun-01 Matthew Jacob wrote: > > > What I needed to fix for turbolaser is to clear the timer interrupt for all > CPUs but the primary CPU- this is the TLINTRMASK{0,1} registers. But, stupid > me, I upgraded my source first. Ok, then we will need to change how platform.clockintr works slightly. (It will need to do more) and then forward_*clock in sys/i386/i386/mp_machdep.c will need to be moved to sys/kern/subr_smp.c, and a few tweaks need to made to smp_handle_ipis() in alpha/alpha/mp_machdep.c, and the tlsb will need a custom platform.clockintr that handles clock interrupts the way x86 does by IPI'ing all other processses to go handle clock interrupts. Hmmm. Actually. You shouldn't even have to do this. SMP doesn't need the i8254 timecounter on the alpha actually, because we make it so that only the boot CPU actually messes with the timecounters, so a non-i8254 timecounter should work fine on SMP systems just fine right now. The reason I think dfr used hte i8254 before was that in pre-SMPng we did need to handle clock interrupts on whatever CPU owned the kernel lock, but now we don't have that same restriction. >> > Yes, sorry I never replied. According to Matt, the turbolaser doesn't >> > have an i8254 timecounter. And the alpha timecounter is never >> > initialized in alpha/alpha/clock.c if ncpus>1, so you're taking a >> > clock interrupt with no timecounter. Oops. No MP for TurboLasers >> > right now, I guess. >> > >> > Here's the code in question: >> > >> > /* >> > * XXX: TurboLaser doesn't have an i8254 counter. >> > * XXX: A replacement is needed, and another method >> > * XXX: of determining this would be nice. >> > */ >> > if (hwrpb->rpb_type != ST_DEC_21000) { >> > tc_init(&i8254_timecounter); >> > } >> > >> > if (ncpus == 1) { >> > alpha_timecounter.tc_frequency = freq; >> > tc_init(&alpha_timecounter); >> > } We should always init the alpha_timecounter. I'm not sure if we even want an i8254 timecounter anymore unless it is more reliable than the alpha version.. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 10: 6: 9 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id C3F2437B401; Wed, 13 Jun 2001 10:05:51 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo (mjacob@beppo [192.67.166.79]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f5DH5og40943; Wed, 13 Jun 2001 10:05:51 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Wed, 13 Jun 2001 10:05:50 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: freebsd-alpha@FreeBSD.ORG, wilko@FreeBSD.ORG, Andrew Gallatin Subject: Re: followup on 8 way SMP pani In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 13 Jun 2001, John Baldwin wrote: > > On 13-Jun-01 Matthew Jacob wrote: > > > > > > What I needed to fix for turbolaser is to clear the timer interrupt for all > > CPUs but the primary CPU- this is the TLINTRMASK{0,1} registers. But, stupid > > me, I upgraded my source first. > > Ok, then we will need to change how platform.clockintr works slightly. (It > will need to do more) and then forward_*clock in sys/i386/i386/mp_machdep.c > will need to be moved to sys/kern/subr_smp.c, and a few tweaks need to made to > smp_handle_ipis() in alpha/alpha/mp_machdep.c, and the tlsb will need a custom > platform.clockintr that handles clock interrupts the way x86 does by IPI'ing > all other processses to go handle clock interrupts. Hmmm. Actually. Now I'm confused. I guess I should go look at the code. Are you saying you would like all CPUs to receive clock interrupts? It was my belief/speculation that we ran into problems because all CPUs were getting a clock interrupt. Maybe that's not right? > > You shouldn't even have to do this. SMP doesn't need the i8254 > timecounter on the alpha actually, because we make it so that only the > boot CPU actually messes with the timecounters, so a non-i8254 timecounter > should work fine on SMP systems just fine right now. The reason I think > dfr used hte i8254 before was that in pre-SMPng we did need to handle > clock interrupts on whatever CPU owned the kernel lock, but now we don't > have that same restriction. There is no i8254 on the turbolaser. i8254 is only present on ISA bus machines. I hacked around this some weeks back. Maybe I need to to fix this again. > > >> > Yes, sorry I never replied. According to Matt, the turbolaser doesn't > >> > have an i8254 timecounter. And the alpha timecounter is never > >> > initialized in alpha/alpha/clock.c if ncpus>1, so you're taking a > >> > clock interrupt with no timecounter. Oops. No MP for TurboLasers > >> > right now, I guess. > >> > > >> > Here's the code in question: > >> > > >> > /* > >> > * XXX: TurboLaser doesn't have an i8254 counter. > >> > * XXX: A replacement is needed, and another method > >> > * XXX: of determining this would be nice. > >> > */ > >> > if (hwrpb->rpb_type != ST_DEC_21000) { > >> > tc_init(&i8254_timecounter); > >> > } > >> > > >> > if (ncpus == 1) { > >> > alpha_timecounter.tc_frequency = freq; > >> > tc_init(&alpha_timecounter); > >> > } > > We should always init the alpha_timecounter. I'm not sure if we even want an > i8254 timecounter anymore unless it is more reliable than the alpha version.. > There are other, more reliable, timers I'm sure. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 10:12:48 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by hub.freebsd.org (Postfix) with ESMTP id 01AD737B408; Wed, 13 Jun 2001 10:12:38 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1) id 15AEC4-000NqX-0C; Wed, 13 Jun 2001 17:12:36 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f5DHBK725226; Wed, 13 Jun 2001 18:11:20 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Wed, 13 Jun 2001 18:11:20 +0100 (BST) From: Doug Rabson To: John Baldwin Cc: Matthew Jacob , , , Andrew Gallatin Subject: Re: followup on 8 way SMP pani In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 13 Jun 2001, John Baldwin wrote: > > On 13-Jun-01 Matthew Jacob wrote: > > > > > > What I needed to fix for turbolaser is to clear the timer interrupt for all > > CPUs but the primary CPU- this is the TLINTRMASK{0,1} registers. But, stupid > > me, I upgraded my source first. > > Ok, then we will need to change how platform.clockintr works slightly. (It > will need to do more) and then forward_*clock in sys/i386/i386/mp_machdep.c > will need to be moved to sys/kern/subr_smp.c, and a few tweaks need to made to > smp_handle_ipis() in alpha/alpha/mp_machdep.c, and the tlsb will need a custom > platform.clockintr that handles clock interrupts the way x86 does by IPI'ing > all other processses to go handle clock interrupts. Hmmm. Actually. > > You shouldn't even have to do this. SMP doesn't need the i8254 timecounter on > the alpha actually, because we make it so that only the boot CPU actually > messes with the timecounters, so a non-i8254 timecounter should work fine on > SMP systems just fine right now. The reason I think dfr used hte i8254 before > was that in pre-SMPng we did need to handle clock interrupts on whatever CPU > owned the kernel lock, but now we don't have that same restriction. Are you saying that no code in the kernel calls nanotime(9) unless its running on the boot cpu? If so, then we can use the alpha timecounter. If not, then we need to find a decent clock somewhere in the tlaser hardware. I'd loke to do the same for rawhide too since the i8254 really sucks. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 10:15:44 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from technokratis.com (modemcable052.174-202-24.mtl.mc.videotron.ca [24.202.174.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A6C137B407; Wed, 13 Jun 2001 10:15:34 -0700 (PDT) (envelope-from bmilekic@technokratis.com) Received: (from bmilekic@localhost) by technokratis.com (8.11.3/8.11.3) id f5DHGG808524; Wed, 13 Jun 2001 13:16:16 -0400 (EDT) (envelope-from bmilekic) Date: Wed, 13 Jun 2001 13:16:16 -0400 From: Bosko Milekic To: Mike Smith Cc: Matthew Jacob , freebsd-current@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: New SMP Mbuf Allocator (PATCH and TESTING request) Message-ID: <20010613131616.C8224@technokratis.com> References: <20010613012321.A4311@technokratis.com> <200106130748.f5D7mEn08071@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106130748.f5D7mEn08071@mass.dis.org>; from msmith@FreeBSD.ORG on Wed, Jun 13, 2001 at 12:48:14AM -0700 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Jun 13, 2001 at 12:48:14AM -0700, Mike Smith wrote: > > The reason I said "in the next week" is actually because on Sat. June 23rd > > (not this upcoming one, but the one after), I should be flying off to > > Yugoslavia (actually to London, and only then to Yugoslavia). I will be > > gone for 3 weeks and seeing as how maintaining this huge diff is a real > > **** (especially given the state of -CURRENT, as I'm sure you know :-)), > > I realise that maintaining the diff is a major pain, but this is *not* a > good reason to be rushing it now, *especially* when you're going to be > gone for three weeks. I'm not rushing it. > I appreciate the extra work involved, but please take this as an > extremely serious request to defer your commit until it's had some more > testing, and until you're in a position to support it for more than 36 > hours after you commit. This is likely going to happen anyway, following some discussions with Bruce, in order to improve the situation of sys/mbuf.h :-) However, testing should still continue as none of the planned changes affect any of the conceptual/functional bits. > Thanks. > > -- > ... every activity meets with opposition, everyone who acts has his > rivals and unfortunately opponents also. But not because people want > to be opponents, rather because the tasks and relationships force > people to take different points of view. [Dr. Fritz Todt] > V I C T O R Y N O T V E N G E A N C E Cheers, -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 10:35:46 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 06C7D37B408; Wed, 13 Jun 2001 10:35:19 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f5DHYf139798; Wed, 13 Jun 2001 10:34:41 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 13 Jun 2001 10:34:44 -0700 (PDT) From: John Baldwin To: Doug Rabson Subject: Re: followup on 8 way SMP pani Cc: Andrew Gallatin , wilko@FreeBSD.org, freebsd-alpha@FreeBSD.org, Matthew Jacob Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 13-Jun-01 Doug Rabson wrote: > On Wed, 13 Jun 2001, John Baldwin wrote: > >> >> On 13-Jun-01 Matthew Jacob wrote: >> > >> > >> > What I needed to fix for turbolaser is to clear the timer interrupt for >> > all >> > CPUs but the primary CPU- this is the TLINTRMASK{0,1} registers. But, >> > stupid >> > me, I upgraded my source first. >> >> Ok, then we will need to change how platform.clockintr works slightly. (It >> will need to do more) and then forward_*clock in sys/i386/i386/mp_machdep.c >> will need to be moved to sys/kern/subr_smp.c, and a few tweaks need to made >> to >> smp_handle_ipis() in alpha/alpha/mp_machdep.c, and the tlsb will need a >> custom >> platform.clockintr that handles clock interrupts the way x86 does by IPI'ing >> all other processses to go handle clock interrupts. Hmmm. Actually. >> >> You shouldn't even have to do this. SMP doesn't need the i8254 timecounter >> on >> the alpha actually, because we make it so that only the boot CPU actually >> messes with the timecounters, so a non-i8254 timecounter should work fine on >> SMP systems just fine right now. The reason I think dfr used hte i8254 >> before >> was that in pre-SMPng we did need to handle clock interrupts on whatever CPU >> owned the kernel lock, but now we don't have that same restriction. > > Are you saying that no code in the kernel calls nanotime(9) unless its > running on the boot cpu? If so, then we can use the alpha timecounter. If > not, then we need to find a decent clock somewhere in the tlaser hardware. > I'd loke to do the same for rawhide too since the i8254 really sucks. Argh. I forgot about that. I was thinking about clock interrupt issues. Turning off clock interrupts for slave CPU's won't fix that. :( -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 10:38:58 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 67C3B37B403; Wed, 13 Jun 2001 10:38:56 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f5DHcK139923; Wed, 13 Jun 2001 10:38:20 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 13 Jun 2001 10:38:23 -0700 (PDT) From: John Baldwin To: Matthew Jacob Subject: Re: followup on 8 way SMP pani Cc: Andrew Gallatin , wilko@FreeBSD.org, freebsd-alpha@FreeBSD.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 13-Jun-01 Matthew Jacob wrote: > > On Wed, 13 Jun 2001, John Baldwin wrote: > >> >> On 13-Jun-01 Matthew Jacob wrote: >> > >> > >> > What I needed to fix for turbolaser is to clear the timer interrupt for >> > all >> > CPUs but the primary CPU- this is the TLINTRMASK{0,1} registers. But, >> > stupid >> > me, I upgraded my source first. >> >> Ok, then we will need to change how platform.clockintr works slightly. (It >> will need to do more) and then forward_*clock in sys/i386/i386/mp_machdep.c >> will need to be moved to sys/kern/subr_smp.c, and a few tweaks need to made >> to >> smp_handle_ipis() in alpha/alpha/mp_machdep.c, and the tlsb will need a >> custom >> platform.clockintr that handles clock interrupts the way x86 does by IPI'ing >> all other processses to go handle clock interrupts. Hmmm. Actually. > > Now I'm confused. I guess I should go look at the code. Are you saying you > would like all CPUs to receive clock interrupts? Yes. > It was my belief/speculation that we ran into problems because all CPUs were > getting a clock interrupt. Maybe that's not right? No. We only adjust the timecounters on the primary CPU's clock interrupt, so that isn't a problem. The problem that Doug pointed out with nanotime(9) is that if two different CPU's try to read the time at the same time, they need to get the same value. This is not guaranteed if we use the pcc. This can become more problematic if a process migrates from one CPU to another and as a result time "goes backwards" per se. What we need is a global timer. On an SMP system, we can't use the CPU cycle counter for this. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 10:42:36 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from internet.hilbrink.nl (ns.hilbrink.nl [212.136.135.66]) by hub.freebsd.org (Postfix) with ESMTP id C485E37B408 for ; Wed, 13 Jun 2001 10:42:13 -0700 (PDT) (envelope-from cor@hilbrink.nl) Received: from cpqpc (cpqpc.hilbrink.nl [212.136.135.151]) by internet.hilbrink.nl (8.8.8/8.8.8) with SMTP id TAA03001; Wed, 13 Jun 2001 19:50:12 +0200 (CEST) (envelope-from cor@hilbrink.nl) Message-ID: <008501c0f42f$c01f7060$978788d4@hilbrink.nl> Reply-To: "Cor Hilbrink" From: "Cor Hilbrink" To: "Andrew Gallatin" Cc: References: <007f01c0f426$bc9b41c0$978788d4@hilbrink.nl> <15143.39027.877073.655469@grasshopper.cs.duke.edu> Subject: Re: Graphical card Alpha DS10l supported under X11?? Date: Wed, 13 Jun 2001 19:39:08 +0200 Organization: Hilbrink IT Solutions MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello Andrew, Thanks for your quick response... I did use the CDrom kit version 4.1 for Alpha, i don't have newer versions here available yet. I will give it another try ofcourse. Regards, Cor Hilbrink. ----- Original Message ----- From: Andrew Gallatin To: Cor Hilbrink Cc: Sent: Wednesday, June 13, 2001 6:44 PM Subject: Re: Graphical card Alpha DS10l supported under X11?? > > Cor Hilbrink writes: > > Hello. > > > > For the moment we are trying to install a DS10L with FreeBSD for Alpha. > > This machine contains a Elsa Gloria Synergy-8 video adapter, does anyone know how to configure X? > > We tried several cardtypes, but thusfar we didn't suceed to get XWindows running properly. > > > > I hope that anyone can tell us a bit more how this can be solved. > > > > You failed to mention what version of FreeBSD you're using, what > version of the XFree86 distro you're using & what the trouble is. > Without this informaiton, there's not a lot anybody here can do to > help you, other than to make general suggestion. > > If you're using XFree86 3.x, note that (as David O'Brien pointed out): > > The "graphical" XFree86 configuration program -- XF86Setup program > *requires* the VGA16 server. This server does NOT build on the > Alpha. Not just FreeBSD/alpha, but AlphaLinux and Tru86 also. > > The issue with using the text-only xf86config is that it does not > know about moused's sysmouse. Thus you either cannot use moused, > or you must hack the /etc/XF86Config file xf86config creates to > specify sysmouse. > > Note that you'll want to use the XF86_3DLabs Xserver under XF86 3.x > > For what its worth, I just built XF86 4.1.0 from ports & the XServer > for the AGP Elsa Gloria Synergy card seems to work just fine > on my UP1000. I'm not sure what the trailing -8 of your card > signifies. > > I hope this random smattering of information is somewhat helpful. > > BTW, please don't post html on the freebsd mailing lists. > > Cheers, > > Drew > > -------------------------------------------------------------------------- ---- > Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin > Duke University Email: gallatin@cs.duke.edu > Department of Computer Science Phone: (919) 660-6590 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 10:48:43 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id E0C3137B405; Wed, 13 Jun 2001 10:48:37 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo (mjacob@beppo [192.67.166.79]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f5DHmbg41037; Wed, 13 Jun 2001 10:48:37 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Wed, 13 Jun 2001 10:48:33 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: Andrew Gallatin , wilko@FreeBSD.org, freebsd-alpha@FreeBSD.org Subject: Re: followup on 8 way SMP pani In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > > It was my belief/speculation that we ran into problems because all CPUs were > > getting a clock interrupt. Maybe that's not right? > > No. We only adjust the timecounters on the primary CPU's clock interrupt, so > that isn't a problem. The problem that Doug pointed out with nanotime(9) is > that if two different CPU's try to read the time at the same time, they need to > get the same value. This is not guaranteed if we use the pcc. This can become > more problematic if a process migrates from one CPU to another and as a result > time "goes backwards" per se. What we need is a global timer. On an SMP > system, we can't use the CPU cycle counter for this. Well, right. There are a number of possible sources for this on each platform. But it can't possibly be correct to assume that N different interval timer interrupts are anywhere within an aeon of each other. I can't believe that allowing clock interrupts on all cpus can be considered correct. Even if there is only one interrupt source (i.e., one hirez clock) there are quantization errors that would always make time different if maintained differently in each CPU. I think it's true that *system* time should only be adjusted by one CPU. But if you don't have a safe mechanism for getting nanotime offsets to system that is guaranteed to be monotonically increasing in hardware, you can always fall back to to the 'add one nanosecond under a lock' mechanism, right? I'm still trying to get it to work period for turbolaser. I think I tracked down the panic and can move ahead I believe. This other issue has to really be slightly orthogonal. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 10:52:51 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id CAC3237B401 for ; Wed, 13 Jun 2001 10:52:48 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id NAA11784; Wed, 13 Jun 2001 13:52:48 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f5DHqIl18983; Wed, 13 Jun 2001 13:52:18 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15143.43090.209114.613107@grasshopper.cs.duke.edu> Date: Wed, 13 Jun 2001 13:52:18 -0400 (EDT) To: "Cor Hilbrink" Cc: Subject: Re: Graphical card Alpha DS10l supported under X11?? In-Reply-To: <008501c0f42f$c01f7060$978788d4@hilbrink.nl> References: <007f01c0f426$bc9b41c0$978788d4@hilbrink.nl> <15143.39027.877073.655469@grasshopper.cs.duke.edu> <008501c0f42f$c01f7060$978788d4@hilbrink.nl> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Cor Hilbrink writes: > Hello Andrew, > > Thanks for your quick response... > I did use the CDrom kit version 4.1 for Alpha, i don't have newer versions 4.1 what?? XFree86 4.1, or FreeBSD 4.1?? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 11: 0:50 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 28B6237B401; Wed, 13 Jun 2001 11:00:47 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f5DI0X140289; Wed, 13 Jun 2001 11:00:33 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 13 Jun 2001 11:00:37 -0700 (PDT) From: John Baldwin To: Matthew Jacob Subject: Re: followup on 8 way SMP pani Cc: freebsd-alpha@FreeBSD.org, wilko@FreeBSD.org, Andrew Gallatin Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 13-Jun-01 Matthew Jacob wrote: >> >> > It was my belief/speculation that we ran into problems because all CPUs >> > were >> > getting a clock interrupt. Maybe that's not right? >> >> No. We only adjust the timecounters on the primary CPU's clock interrupt, >> so >> that isn't a problem. The problem that Doug pointed out with nanotime(9) is >> that if two different CPU's try to read the time at the same time, they need >> to >> get the same value. This is not guaranteed if we use the pcc. This can >> become >> more problematic if a process migrates from one CPU to another and as a >> result >> time "goes backwards" per se. What we need is a global timer. On an SMP >> system, we can't use the CPU cycle counter for this. > > Well, right. There are a number of possible sources for this on each > platform. > But it can't possibly be correct to assume that N different interval timer > interrupts are anywhere within an aeon of each other. I can't believe that > allowing clock interrupts on all cpus can be considered correct. Even if > there > is only one interrupt source (i.e., one hirez clock) there are quantization > errors that would always make time different if maintained differently in > each > CPU. Hang on a second. Clock interrupts are used for _two_ different things here, which is where you are getting confused I think. One is timekeeping, another is to handle things like per-process statclock, etc. All that per-process stuff we do on _all_ cpu's when we get a clock interrupt. Alpha is nice in that it broadcasts clock interrupts for this purpose. On x86, for example, we only have one clock interrupt and we have to IPI all the other CPU's to get this info. Now, the second purpose is for timekeeping, and that is what hte i8254 is used for on SMP systems, because it is a timer that is system wide and not per-CPU. Does that make sense? What tlsb needs is a non-per-CPU, system-wide timer to be used for the timecounter stuff. That's all. No changes to any of the other clock code is needed. In my first reply, (when you were going to disable clock interrupts on secondary cpu's) I was dealing with the first thing (per-process signals and stats) and noted that those should work fine as is. Doug then reminded me that I was a bit off track due to the way that nanotime, microtime, etc. all work. > I'm still trying to get it to work period for turbolaser. I think I tracked > down the panic and can move ahead I believe. This other issue has to really > be > slightly orthogonal. tlsb panics cause it has no timecounter on an SMP system. It needs a timecounter. That will fix the panic. So it's the same issue. :) -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 11:10: 6 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 2A86D37B403; Wed, 13 Jun 2001 11:09:57 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo (mjacob@beppo [192.67.166.79]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f5DI9ug41083; Wed, 13 Jun 2001 11:09:56 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Wed, 13 Jun 2001 11:09:55 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: freebsd-alpha@FreeBSD.org, wilko@FreeBSD.org, Andrew Gallatin Subject: Re: followup on 8 way SMP pani In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Hang on a second. Clock interrupts are used for _two_ different things > here, which is where you are getting confused I think. One is > timekeeping, another is to handle things like per-process statclock, etc. > All that per-process stuff we do on _all_ cpu's when we get a clock > interrupt. Alpha is nice in that it broadcasts clock interrupts for this > purpose. On x86, for example, we only have one clock interrupt and we > have to IPI all the other CPU's to get this info. But, in fact, in this case this is *not* a broadcast interrupt. Each TLSB CPU board can have up to two CPUs. Each TLSB CPU board has an interval timer and a Zilog duart. You use the TLINTRMASK{0,1} registers for each TLSB CPU board to control whether one or both CPUs get DUART or Interval Timer or IPI (or any other, for that matter) interrupt. > Now, the second purpose is for timekeeping, and that is what hte i8254 is > used for on SMP systems, because it is a timer that is system wide and not > per-CPU. Does that make sense? What tlsb needs is a non-per-CPU, > system-wide timer to be used for the timecounter stuff. That's all. No > changes to any of the other clock code is needed. And, to be safe, we should probably do the forward dance here as well- this would guarantee that at least all CPUs notion of statclock is monotonically delayed and ordered from the primary CPU. That is, it would be alway true that: CPU 0 - time tau CPU 1 - time tau + epsilon1 CPU 2 - time tau + epsilon1 + epsilon2 ... I still have trouble believing that it won't screw things up to have different (per cpu) time bases for statclock if you allow processes to move from one cpu to the other. But I'll freely admit I'm an ignorant twit about the current setup. > > In my first reply, (when you were going to disable clock interrupts on > secondary cpu's) I was dealing with the first thing (per-process signals and > stats) and noted that those should work fine as is. Doug then reminded me that > I was a bit off track due to the way that nanotime, microtime, etc. all work. > > > I'm still trying to get it to work period for turbolaser. I think I tracked > > down the panic and can move ahead I believe. This other issue has to really > > be > > slightly orthogonal. > > tlsb panics cause it has no timecounter on an SMP system. It needs a > timecounter. That will fix the panic. So it's the same issue. :) Well, I supposedly had *fixed* this lack of a timecounter issue some weeks back (by hacking around it). I guess I need to look at this again. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 11:21:37 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id CFF4B37B408; Wed, 13 Jun 2001 11:21:32 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f5DIKt140628; Wed, 13 Jun 2001 11:20:55 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 13 Jun 2001 11:20:59 -0700 (PDT) From: John Baldwin To: Matthew Jacob Subject: Re: followup on 8 way SMP pani Cc: Andrew Gallatin , wilko@FreeBSD.org, freebsd-alpha@FreeBSD.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 13-Jun-01 Matthew Jacob wrote: >> Hang on a second. Clock interrupts are used for _two_ different things >> here, which is where you are getting confused I think. One is >> timekeeping, another is to handle things like per-process statclock, etc. >> All that per-process stuff we do on _all_ cpu's when we get a clock >> interrupt. Alpha is nice in that it broadcasts clock interrupts for this >> purpose. On x86, for example, we only have one clock interrupt and we >> have to IPI all the other CPU's to get this info. > > But, in fact, in this case this is *not* a broadcast interrupt. Each TLSB CPU > board can have up to two CPUs. Each TLSB CPU board has an interval timer and > a > Zilog duart. You use the TLINTRMASK{0,1} registers for each TLSB CPU board to > control whether one or both CPUs get DUART or Interval Timer or IPI (or any > other, for that matter) interrupt. Does each CPU get a clock interrupt at a specified hz? I.e., do all CPU's get a X number of clock interrupts per second? That's all that statclock and hardclock need. The relave timing of these interrupts isn't all that important. Note that IPI's can suffer from delays as well, so we can't assume anything about how soon (or not soon) that an IPI is delivered. >> Now, the second purpose is for timekeeping, and that is what hte i8254 is >> used for on SMP systems, because it is a timer that is system wide and not >> per-CPU. Does that make sense? What tlsb needs is a non-per-CPU, >> system-wide timer to be used for the timecounter stuff. That's all. No >> changes to any of the other clock code is needed. > > And, to be safe, we should probably do the forward dance here as well- this > would guarantee that at least all CPUs notion of statclock is monotonically > delayed and ordered from the primary CPU. That is, it would be alway true > that: > > CPU 0 - time tau > CPU 1 - time tau + epsilon1 > CPU 2 - time tau + epsilon1 + epsilon2 > ... > > I still have trouble believing that it won't screw things up to have > different > (per cpu) time bases for statclock if you allow processes to move from one > cpu > to the other. But I'll freely admit I'm an ignorant twit about the current > setup. statclock doesn't care what time it is. It doesn't block, it runs with ints disabled so the process doesn't migrate, etc. All statclock does is bump a few stats. For hardclock all we do is possibly setup some pending signals. The only thing that actually cares what time it is is the timecounter code. Now, for clock interrupts, the timecounter is only updated on the boot CPU, so clock interrupts are already safe and could use the pcc or what have you. The problem is functions like nanotime(). (The non get* versions.) These functions actually poke the hardware to get more precise timing since the last timecounter update triggered by hardclock. Thus, if a secondary CPU tries to do that (which is _not_ in a clock interrupt context, the problem is completely unrelated to clock interrupts) then it needs to be able to get at the same hardware timer that the boot CPU sees. > Well, I supposedly had *fixed* this lack of a timecounter issue some weeks > back (by hacking around it). I guess I need to look at this again. No, this is only for SMP systems. We don't turn on the alpha timecounter on systems with more than one CPU. UP systems and UP kernels should work fine. > -matt -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 11:22:17 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from smtp7.xs4all.nl (smtp7.xs4all.nl [194.109.127.133]) by hub.freebsd.org (Postfix) with ESMTP id 9E66637B40C for ; Wed, 13 Jun 2001 11:22:11 -0700 (PDT) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp7.xs4all.nl (8.9.3/8.9.3) with ESMTP id UAA28859 for ; Wed, 13 Jun 2001 20:22:09 +0200 (CEST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.3/8.11.3) id f5DIKIE13056; Wed, 13 Jun 2001 20:20:18 +0200 (CEST) (envelope-from wkb) Date: Wed, 13 Jun 2001 20:20:18 +0200 From: Wilko Bulte To: Andrew Gallatin Cc: Cor Hilbrink , freebsd-alpha@freebsd.org Subject: Re: Graphical card Alpha DS10l supported under X11?? Message-ID: <20010613202018.C13012@freebie.xs4all.nl> Reply-To: wilko@freebsd.org References: <007f01c0f426$bc9b41c0$978788d4@hilbrink.nl> <15143.39027.877073.655469@grasshopper.cs.duke.edu> <008501c0f42f$c01f7060$978788d4@hilbrink.nl> <15143.43090.209114.613107@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <15143.43090.209114.613107@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Wed, Jun 13, 2001 at 01:52:18PM -0400 X-OS: FreeBSD 4.3-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Jun 13, 2001 at 01:52:18PM -0400, Andrew Gallatin wrote: > > Cor Hilbrink writes: > > Hello Andrew, > > > > Thanks for your quick response... > > I did use the CDrom kit version 4.1 for Alpha, i don't have newer versions > > 4.1 what?? XFree86 4.1, or FreeBSD 4.1?? FreeBSD 4.1. Most likely one of the promo CDs jkh/WC/BSDi sent over to the NLFUG ;-) -- | / o / / _ Arnhem, The Netherlands email: wilko@freebsd.org |/|/ / / /( (_) Bulte http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 11:22:49 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id F2FFE37B401; Wed, 13 Jun 2001 11:22:46 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id OAA12573; Wed, 13 Jun 2001 14:22:45 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f5DIMF319102; Wed, 13 Jun 2001 14:22:15 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15143.44887.290985.930683@grasshopper.cs.duke.edu> Date: Wed, 13 Jun 2001 14:22:15 -0400 (EDT) To: mjacob@feral.com Cc: John Baldwin , freebsd-alpha@FreeBSD.ORG, wilko@FreeBSD.ORG Subject: Re: followup on 8 way SMP pani In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Matthew Jacob writes: > > Hang on a second. Clock interrupts are used for _two_ different things > > here, which is where you are getting confused I think. One is > > timekeeping, another is to handle things like per-process statclock, etc. > > All that per-process stuff we do on _all_ cpu's when we get a clock > > interrupt. Alpha is nice in that it broadcasts clock interrupts for this > > purpose. On x86, for example, we only have one clock interrupt and we > > have to IPI all the other CPU's to get this info. > > But, in fact, in this case this is *not* a broadcast interrupt. Each TLSB CPU > board can have up to two CPUs. Each TLSB CPU board has an interval timer and a > Zilog duart. You use the TLINTRMASK{0,1} registers for each TLSB CPU board to > control whether one or both CPUs get DUART or Interval Timer or IPI (or any > other, for that matter) interrupt. > The Sable/Lynx family has a similar register (but per-cpu). It has bits which control if that cpu gets Interval Timer, IPI, etc interrupts. Also, from the docs & emperical evidence, it would appear that clock interrupts arrive at the same frequency, but cpu1 always interrupts 1/4 of a hz after cpu0, cpu2 is 1/2hz behind cpu0, etc. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 11:25:26 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id E54AD37B401; Wed, 13 Jun 2001 11:25:22 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id OAA12621; Wed, 13 Jun 2001 14:25:21 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f5DIOov19110; Wed, 13 Jun 2001 14:24:50 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15143.45042.791053.316270@grasshopper.cs.duke.edu> Date: Wed, 13 Jun 2001 14:24:50 -0400 (EDT) To: wilko@FreeBSD.ORG Cc: Cor Hilbrink , freebsd-alpha@FreeBSD.ORG Subject: Re: Graphical card Alpha DS10l supported under X11?? In-Reply-To: <20010613202018.C13012@freebie.xs4all.nl> References: <007f01c0f426$bc9b41c0$978788d4@hilbrink.nl> <15143.39027.877073.655469@grasshopper.cs.duke.edu> <008501c0f42f$c01f7060$978788d4@hilbrink.nl> <15143.43090.209114.613107@grasshopper.cs.duke.edu> <20010613202018.C13012@freebie.xs4all.nl> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Wilko Bulte writes: > On Wed, Jun 13, 2001 at 01:52:18PM -0400, Andrew Gallatin wrote: > > > > Cor Hilbrink writes: > > > Hello Andrew, > > > > > > Thanks for your quick response... > > > I did use the CDrom kit version 4.1 for Alpha, i don't have newer versions > > > > 4.1 what?? XFree86 4.1, or FreeBSD 4.1?? > > FreeBSD 4.1. Most likely one of the promo CDs jkh/WC/BSDi sent over to the > NLFUG ;-) Ah, in that case we're talking about XFree86 3.x. Make sure to use xf86config and select a Permedia-2 based card. You should end up using the XF86_3DLabs X server If the server doesn't start, post the output. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 12:18:24 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id ACF5537B401; Wed, 13 Jun 2001 12:18:14 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo (mjacob@beppo [192.67.166.79]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f5DJIBg41256; Wed, 13 Jun 2001 12:18:11 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Wed, 13 Jun 2001 12:18:10 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Andrew Gallatin Cc: John Baldwin , freebsd-alpha@FreeBSD.ORG, wilko@FreeBSD.ORG Subject: More followup... In-Reply-To: <15143.44887.290985.930683@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hmmm- it seems to me that this indicates that there's a general non-TurboLaser problem here- this is on a Rawhide: panic: blockable sleep lock (sleep mutex) Giant @ ../../vm/vm_fault.c:213 cpuid = 0; panic Stopped at Debugger+0x34: zapnot v0,#0xf,a0 db> t Debugger() at Debugger+0x34 panic() at panic+0x178 witness_lock() at witness_lock+0x240 vm_fault() at vm_fault+0x108 trap() at trap+0xf78 XentMM() at XentMM+0x2c --- memory management fault (from ipl 7) --- hardclock() at hardclock+0x308 handleclock() at handleclock+0x22c alpha_clock_interrupt() at alpha_clock_interrupt+0x68 interrupt() at interrupt+0xb8 XentInt() at XentInt+0x28 --- interrupt (from ipl 4) --- XentInt() at XentInt --- interrupt (from ipl 3) --- _end() at _end+0x9e58 The 'blockable sleep lock mutex' is bogus- what is clearly broken here is having a fault in hardclock. Oh- yeah- about TurboLaser? Somehow it got broken recently such that it no longer even boots UP for me past CAM. Working on FreeBSD (alpha) is like experiencing what the character in the first sentence in 100 Years of Solitude experienced. Only 3 times a week, 40 weeks a year. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 12:33:19 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 4FE7537B405; Wed, 13 Jun 2001 12:33:14 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id PAA14550; Wed, 13 Jun 2001 15:33:13 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f5DJWh019374; Wed, 13 Jun 2001 15:32:43 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15143.49115.393545.131197@grasshopper.cs.duke.edu> Date: Wed, 13 Jun 2001 15:32:43 -0400 (EDT) To: mjacob@feral.com Cc: John Baldwin , freebsd-alpha@FreeBSD.ORG, wilko@FreeBSD.ORG Subject: Re: More followup... In-Reply-To: References: <15143.44887.290985.930683@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Matthew Jacob writes: > > Hmmm- it seems to me that this indicates that there's a general non-TurboLaser > problem here- this is on a Rawhide: > > panic: blockable sleep lock (sleep mutex) Giant @ ../../vm/vm_fault.c:213 > cpuid = 0; panic > Stopped at Debugger+0x34: zapnot v0,#0xf,a0 > db> t > Debugger() at Debugger+0x34 > panic() at panic+0x178 > witness_lock() at witness_lock+0x240 > vm_fault() at vm_fault+0x108 > trap() at trap+0xf78 > XentMM() at XentMM+0x2c > --- memory management fault (from ipl 7) --- > hardclock() at hardclock+0x308 > handleclock() at handleclock+0x22c > alpha_clock_interrupt() at alpha_clock_interrupt+0x68 > interrupt() at interrupt+0xb8 > XentInt() at XentInt+0x28 > --- interrupt (from ipl 4) --- > XentInt() at XentInt > --- interrupt (from ipl 3) --- > _end() at _end+0x9e58 > > The 'blockable sleep lock mutex' is bogus- what is clearly broken here is > having a fault in hardclock. This is different than Wilko's panic. At least with my kernel, it maps to this: (gdb) l * hardclock+0x308 0xfffffc000043a608 is in hardclock (../../kern/kern_clock.c:215). 210 * Process callouts at a very low cpu priority, so we don't keep the 211 * relatively high clock interrupt priority any longer than necessary. 212 */ 213 mtx_lock_spin(&callout_lock); 214 ticks++; 215 if (TAILQ_FIRST(&callwheel[ticks & callwheelmask]) != NULL) { 216 need_softclock = 1; 217 } else if (softticks + 1 == ticks) 218 ++softticks; 219 mtx_unlock_spin(&callout_lock); This is well past Wilko's tlaser panic & looks like it could be a sign of the general pmap corruption brought on by the vm_mtx fiasco.... I'll have to push a machine here hard today an see where it blows up for me. > Oh- yeah- about TurboLaser? Somehow it got broken recently such that it no > longer even boots UP for me past CAM. > > Working on FreeBSD (alpha) is like experiencing what the character in the > first sentence in 100 Years of Solitude experienced. Only 3 times a week, 40 > weeks a year. I have to admit that I'm a literary slouch. It certainly sounds like a depressing novel.. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 12:54:53 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id B4F7237B401 for ; Wed, 13 Jun 2001 12:54:34 -0700 (PDT) (envelope-from phk@freebsd.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f5DJsS142226 for ; Wed, 13 Jun 2001 12:54:28 -0700 (PDT) (envelope-from phk@freebsd.org) X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-Sieve: cmu-sieve 2.0 Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by server.baldwin.cx (8.9.3/8.9.3) with ESMTP id MAA93507 for ; Wed, 13 Jun 2001 12:25:45 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by meow.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f5DJN1141516 for ; Wed, 13 Jun 2001 12:23:01 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 45E2555F87 for ; Wed, 13 Jun 2001 12:23:06 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: by hub.freebsd.org (Postfix) id 4345637B408; Wed, 13 Jun 2001 12:23:06 -0700 (PDT) Delivered-To: jhb@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 29A0237B401 for ; Wed, 13 Jun 2001 12:23:05 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f5DJMsr50507 for ; Wed, 13 Jun 2001 21:22:55 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) Date: Wed, 13 Jun 2001 12:54:33 -0700 (PDT) Message-ID: <50505.992460174@critter> From: Poul-Henning Kamp To: alpha@freebsd.org Subject: Re: followup on 8 way SMP pani Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [ bounced from phk - jhb ] John just pointed out this thread on timecounters to me and I want to clarify some things. The timecounter hardware needs to be global. You cannot use the PCC or TSC of any single CPU unless they are in sync. If you do, you will see time going forward, backwards and sideways. Even on a i386 SMP box you cannot do this because of the various dirty things the BIOS will do in SMM mode. The alphas PCC is useless for timekeeping as anything but a short term interpolator. The clock is created with a on-chip SAW device which has no redeeming qualities whatsoever when it comes to keeping a stable frequency. The ultimate fallback for a SMP machine without suitable hardware is to implement the timecounter in software and tick it once per hardclock from one designated CPU. Your clock resolution will suck but everything will work as advertised. This is probably what should be done for the hardware you guys are talking about. Most of what you need is already there in kern_tc: it's called "dummy_timecounter" and is presently used to cover our behinds until we find real hardware. It might be possible to make some code which uses that basic method but which is able to interpolate using the local CPU's PCC, but so far all my attempts at doing so have had unacceptable high overheads. I have a rewrite of the timecounter code in mind, if you have input to that let me know. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 12:55: 8 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 289E237B407; Wed, 13 Jun 2001 12:55:06 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f5DJsS142230; Wed, 13 Jun 2001 12:54:28 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <15143.49115.393545.131197@grasshopper.cs.duke.edu> Date: Wed, 13 Jun 2001 12:54:33 -0700 (PDT) From: John Baldwin To: Andrew Gallatin Subject: Re: More followup... Cc: wilko@FreeBSD.org, freebsd-alpha@FreeBSD.org, mjacob@feral.com Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 13-Jun-01 Andrew Gallatin wrote: > > This is different than Wilko's panic. At least with my kernel, it > maps to this: It would be helpful to know what the actual trap is. Sticking a 'printtrap' in at the top of trap to output the trap details would be very helpful. > (gdb) l * hardclock+0x308 > 0xfffffc000043a608 is in hardclock (../../kern/kern_clock.c:215). > 210 * Process callouts at a very low cpu priority, so we don't > keep the > 211 * relatively high clock interrupt priority any longer than > necessary. > 212 */ > 213 mtx_lock_spin(&callout_lock); > 214 ticks++; > 215 if (TAILQ_FIRST(&callwheel[ticks & callwheelmask]) != NULL) { > 216 need_softclock = 1; > 217 } else if (softticks + 1 == ticks) > 218 ++softticks; > 219 mtx_unlock_spin(&callout_lock); > > > This is well past Wilko's tlaser panic & looks like it could be a sign > of the general pmap corruption brought on by the vm_mtx fiasco.... > I'll have to push a machine here hard today an see where it blows up > for me. I don't think it's general pmap corruption, but I could be wrong. Almost everything is back under Giant that wasn't before. My current vm.patch moves pagedaemon and vmdaemon back under Giant, so the only thing that possibly should move back under Giant is the stuff in trap() that was under Giant before. I'll look at this in a bit. The thing is that if we still have these problems when all of vm is under Giant, then it's not a vm_mtx problem. :( -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 13:32: 9 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 6721E37B403; Wed, 13 Jun 2001 13:32:05 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id QAA16780; Wed, 13 Jun 2001 16:32:04 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f5DKVYn19624; Wed, 13 Jun 2001 16:31:34 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15143.52646.572807.462036@grasshopper.cs.duke.edu> Date: Wed, 13 Jun 2001 16:31:34 -0400 (EDT) To: John Baldwin Cc: freebsd-alpha@FreeBSD.org, mjacob@feral.com Subject: Re: More followup... In-Reply-To: References: <15143.49115.393545.131197@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John Baldwin writes: > > I don't think it's general pmap corruption, but I could be wrong. Almost > everything is back under Giant that wasn't before. My current vm.patch moves > pagedaemon and vmdaemon back under Giant, so the only thing that possibly > should move back under Giant is the stuff in trap() that was under Giant > before. I'll look at this in a bit. The thing is that if we still have these > problems when all of vm is under Giant, then it's not a vm_mtx problem. :( All I know is that I never used to get wierdo vm panics like the ones I've been getting since the vm_mtx went in... Circumstantial evidence, I realize. But its pretty compelling. Anyway, here's a panic I just got (linking a kernel on ffs, nothing else happening) login: panic: vm_page_remove(): page not found in hash cpuid = 0; panic Stopped at Debugger+0x34: zapnot v0,#0xf,a0 db> tr Debugger() at Debugger+0x34 panic() at panic+0x178 vm_page_remove() at vm_page_remove+0x134 vm_page_free_toq() at vm_page_free_toq+0x100 vm_page_alloc() at vm_page_alloc+0x270 vm_fault1() at vm_fault1+0x648 vm_fault() at vm_fault+0x204 trap() at trap+0xe20 XentMM() at XentMM+0x2c --- memory management fault (from ipl 0) --- --- user mode --- db> show pcpu cpuid = 0 ipis = 0 next ASN = 134 curproc = 0xfffffe00067dda00: pid 626 "ld" curpcb = 0x3b2a000 fpcurproc = 0xfffffe00067dda00: pid 626 "ld" idleproc = 0xfffffe000589f600: pid 10 "idle: cpu0" spin locks held: db> show locks exclusive (sleep mutex) vm (0xfffffc00007be3a8) locked @ ../../vm/vm_fault.c:301 exclusive (sleep mutex) Giant (0xfffffc00007bf040) locked @ ../../vm/vm_fault.c:213 db> This is a GENERIC kernel, minus IPV6, minus SOFTUPDATES, plus BREAK_TO_DEBUGGER. To add insult to injury, I can't even get a crashdump: db> c syncing disks... panic: mutex vm owned at ../../kern/vfs_bio.c:2990 cpuid = 0; panic Stopped at Debugger+0x34: zapnot v0,#0xf,a0 db> c Uptime: 23m50s dumping to dev ad0b, offset 2888928 dump ata0: resetting devices .. panic: witness_restore: lock (sleep mutex) Giant not locked cpuid = 0; panic Stopped at Debugger+0x34: zapnot v0,#0xf,a0 db> c Uptime: 23m52s Dump already in progress, bailing... Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... Maybe witness could check for panicstr & back off if it is set? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Jun 13 19:14:54 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from technokratis.com (modemcable052.174-202-24.mtl.mc.videotron.ca [24.202.174.52]) by hub.freebsd.org (Postfix) with ESMTP id 3367237B403; Wed, 13 Jun 2001 19:14:34 -0700 (PDT) (envelope-from bmilekic@technokratis.com) Received: (from bmilekic@localhost) by technokratis.com (8.11.3/8.11.3) id f5E2F2518703; Wed, 13 Jun 2001 22:15:02 -0400 (EDT) (envelope-from bmilekic) Date: Wed, 13 Jun 2001 22:15:01 -0400 From: Bosko Milekic To: freebsd-current@FreeBSD.ORG Cc: freebsd-alpha@FreeBSD.ORG, bde@FreeBSD.ORG Subject: Re: New SMP Mbuf Allocator (PATCH and TESTING request) Message-ID: <20010613221501.A16161@technokratis.com> References: <20010613010744.A4083@technokratis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010613010744.A4083@technokratis.com>; from bmilekic@technokratis.com on Wed, Jun 13, 2001 at 01:07:44AM -0400 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Folks, I have a new version of the patch for you to test. It's up: http://people.freebsd.org/~bmilekic/code/mb_slab/mb_alloc-LATEST.diff (same place as before). The difference is that I have removed the HUGE src/sys sweep for #include's and have removed the need to include before . This had the added effect of effectively nuking the allocation/deallocation macros in sys/mbuf.h, which is good because what was previously there was a pessimization. The reason it was a pessimization was because callers that used the macros would only pay the cost of one function call but callers that used the function equivalents would pay the cost of two function calls, even in the best case scenario. With these changes, all callers do one function call per allocation. Bruce: Would you please glance over these changes (particularily the mbuf.h and the bottom of subr_mbuf.c - m_get() and downward)? I think it fixes the problem you brought up to me earlier today. :-) Matt Jacob: If you have already started testing the other diff, that's okay, nothing much has changed functionally. However, if you haven't or if you have extra time, please consider backing it out and applying this one. Sorry for the inconvenience. Cheers, Bosko. On Wed, Jun 13, 2001 at 01:07:44AM -0400, Bosko Milekic wrote: > > Hi -current && -alpha, > > If you run -CURRENT on multiprocessor alpha, please > please please read this! :-) > > The final version (or next to final, depending on how > this final testing stage goes) of the new mbuf allocator which > I have been working on for the past 1.5 months and which I've > already mentionned on -arch is now ready. > I plan to commit the new bits within the next week. > However, as is usually the case with commits of this magnitude, > I'd like a few more tests to be run by a few more people. > I've been testing the allocator myself (in several different > ways, mainly resource exhaustion simulations) for the past > couple of weeks and have been able to catch and fix a couple > of bugs. > Also, jake, jlemon, and Silby (Mike Silbersack) have > provided me with some reviews, all of which have been integrated > into the latest version of the patch (below). > > The latest version of the "mb_alloc" code, applying > to -CURRENT as of 5 minutes ago can be found here: > > http://people.freebsd.org/~bmilekic/code/mb_slab/mb_alloc-LATEST.diff > > People who have the following hardware are needed to help > test the patch: > > 1- UP -CURRENT systems (Intel && Alpha) > 2- SMP -CURRENT systems (Intel) > 3- SMP -CURRENT systems (Alpha) *** Especially important *** > who are *not* using the if_vx.c driver [*] > > [*] The if_vx.c driver is broken for the Alpha, and is marked so > by this patch. Before committing this, I plan to first fix > the driver but, obviously, for now, if you are > using if_vx, you won't be able to help with testing. :-( > > To test the patch: apply, build, reboot, do network-related > things, check stats with `netstat -m', etc. > > For those looking at the code: > > Finally, a few things should be noted about the code > itself (if you're just helping test, feel free to skip this > part): > > - I disabled mbtypes[] related statistics _FOR NOW_. This is > because if I were to presently enable them, I wouldn't be > able to consistently update them (unless I do it atomic()ally, > which is not so good for overall performance). I plan to > re-enable them later on, but would prefer to wait and > go over them (perhaps clean them up - add/remove types as > needed - many are if 0'd anyway) rather than rush and waste > time doing it now. > > - The patch is big. sys/mbuf.h includes need to also #include > _BEFORE_ because sys/mbuf.h requires > MALLOC_DECLARE() to be defined. > > - counters for m_ext objects are now all malloc()ed. This will > likely eventually change for what concerns clusters (I am > looking at storing the cluster counter in the cluster 2 > region itself). For other object types, I plan to leave > malloc() as the standard allocator for the counters, seeing > as how the external objects are not allocated in a PCPU > fashion anyway. > > That's it! This patch also sets up the way to more > mbuf-related cleanups (i.e. obvious ones like merging uipc_mbuf.c > code with uipc_mbuf2.c code, and ridding ourselves of the latter, > etc.). It also moves a bundle of mbuf related things out of > sys/conf/param.c and into subr_mbuf.c, where they will now > belong. :-) > > Best Regards and PLEASE help test (especially if you have alpha > hardware!!!), > -- > Bosko Milekic > bmilekic@technokratis.com -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jun 14 1: 3: 9 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by hub.freebsd.org (Postfix) with ESMTP id 3DB2237B40A; Thu, 14 Jun 2001 01:02:47 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.247.142.175.Dial1.SanJose1.Level3.net [209.247.142.175]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id EAA30648; Thu, 14 Jun 2001 04:02:43 -0400 (EDT) Message-ID: <3B286FC1.5C112A5C@mindspring.com> Date: Thu, 14 Jun 2001 01:03:13 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bosko Milekic Cc: freebsd-current@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: New SMP Mbuf Allocator (PATCH and TESTING request) References: <20010613010744.A4083@technokratis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bosko Milekic wrote: > I plan to commit the new bits within the next week. > However, as is usually the case with commits of this magnitude, > I'd like a few more tests to be run by a few more people. > I've been testing the allocator myself (in several different > ways, mainly resource exhaustion simulations) for the past > couple of weeks and have been able to catch and fix a couple > of bugs. > Also, jake, jlemon, and Silby (Mike Silbersack) have > provided me with some reviews, all of which have been integrated > into the latest version of the patch (below). A general comment, and then a comment on the patch: I would like to see this code be optional, until such time as benchmarks have proven it to be better than the existing code, or have proben it to be worse. Diking out the existing code, and forcing it to be diked out by making unnecessary function name changes seems to me to be a problem. Overall, I like the idea of moving towards a Dynix allocator type model to support many processors (not just 4) well, but I'm leery of many of the changes, particularly in light of the claim that "It has been established that we do not benefit from different locks for different objects, so we use the same lock, regardless of object type". On to the specific comments... I have addressed them in patch order, so that they can be read side-by-side: -- The "npg" calculation has always been incorrect for large memory systems with non-sparse physical maps, and now it is much worse. I commented on this before in -arch. Consider the case of a machine with 4G of physical memory. -- Is the policy two line or 4 line license, these days? -- The MBALLOC_CPU stuff should be more dynamic; it appears that the real number of CPUs is known at the time the allocations take place. -- I think you should spin, and only block if you don't get the spin lock after several attempts. The Solaris tradeoff in this regard is 10 attempts. Direct blocking on the cv seems a little wasteful. -- I'm not sure why you mutex the per-CPU containers? Aren't they, by definition, per-CPU, and therefore immune from contention? -- You realize that there is a dependency on MAXFILES, right? Specifically, there is an mbuf allocated per open socket for the tcptmpl (even though it only needs 60 bytes). --- If you fix the tcptmpl allocation, a couple of additional issues arise: 1) Since the allocations are in page-units, you will end up with a lot of waste. 2) Allocation in page units will make it hard to give 60 byte allocations back to the system. 3) The allocator is not really general enough for this (or for things like TIME_WAIT zombie structs, etc.). 4) Yeah, this sort of also implies that mbuf cluster headers come from a seperate pool, instead of being 256 bytes as well... -- Why do you lock around things in mb_init()? It's never called twice, let alone reentrantly... the code will be done before an AP is allowed to run. Alpha has this same restriction, from what I can see from the code. -- Dropping the lock in mb_pop_cont() seems wrong; I guess you are avoiding sleeping with the lock held? I don't think you need to worry (per-CPU, again), unless you later attempt lazy repopulation; it seems to me that the lock that should be held is a global lock, to prevent reentrancy on the global memory pool, and the malloc() code does that. Perhaps I'm missing something here. -- The ability to specify a "how" that implies an unwillingness to block implies interrupt allocation; yet you can't support this, since you do not preallocate a kernel map (ala the zone allocator). The zone allocator is actually very misleading, in that some of it's code never has the values it implies that it might have; in particular, there are functions which are passed parameters which can't really be variant, as implied by the use of per zone variables as arguments. -- Ah. I see why all the locks: mb_alloc_wait attempts to be a primitive reclaimer. You would do much better with a per-CPU high-watermark reclaim at free(), I think, instead of doing this. Really, you are in a starvation condition because of your load, and not because someone is "hogging already free mbufs", I think. This is probably premature optimization. -- In the starvation case during a free, I don't think you really care, except perhaps to adjust the high/low watermarks. An interesting issue here is that the average TCP window size will end up being 16k, which comes out to 4 1-page buckets (2, on Alpha), where you end up with multiple buckets and many mbufs (64) per, so freeing isn't really an option, if you are sending lots of data (serving content). It would be different for a desktop system, since the receive interrupt might come to any idle CPU. -- I like the cleanup via the use of local macros. -- I think the m_getclr -> m_get_clrd change is gratuitous. -- I like the "only" comment claifications. -- I dislike the bloating of one line comments into three lines, with the first and last blank. -- You could resolve the statistics problems by keeping them on a per-CPU basis, and then agregating them under a general system lock, when necessary (when they were requested). -- Most of the header definition changes for function declarations are gratuitous. -- Don't really care about netstat stuff... -- -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jun 14 8:36:54 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 92FE337B403; Thu, 14 Jun 2001 08:36:30 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id LAA05700; Thu, 14 Jun 2001 11:36:30 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f5EFa0Y21659; Thu, 14 Jun 2001 11:36:00 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15144.55776.3763.28141@grasshopper.cs.duke.edu> Date: Thu, 14 Jun 2001 11:36:00 -0400 (EDT) To: jhb@freebsd.org Cc: alfred@freebsd.org, :freebsd-alpha@freebsd.org Subject: alpha pmap corruption continues X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John, With your http://people.freebsd.org/~jhb/patches/vm.patch and with rev 1.60 of alpha/trap.c reverted, I'm still seeing what looks like pmap corruption with a (mostly) GENERIC kernel on a UP alpha a few minutes into a -j32 buildworld. fatal kernel trap: trap entry = 0x2 (memory management fault) cpuid = 0 faulting va = 0xfffffffe00480210 type = access violation cause = load instructon pc = 0xfffffc000065bfe8 ra = 0xfffffc000065c13c sp = 0xfffffe0006a0dd68 usp = 0x11ffb2b0 curproc = 0xfffffe00069bff80 pid = 18853, comm = make Stopped at pmap_remove_pages+0xa8: ldl t0,0(t2) <0xfffffffe00480210> db> tr pmap_remove_pages() at pmap_remove_pages+0xa8 exit1() at exit1+0xab8 sys_exit() at sys_exit+0x24 syscall() at syscall+0x628 XentSys() at XentSys+0x64 --- syscall (1, FreeBSD ELF, sys_exit) --- --- user mode --- db> show locks exclusive (sleep mutex) vm (0xfffffc00007be0f8) locked @ ../../vm/vm_map.c:2617 exclusive (sleep mutex) Giant (0xfffffc00007bed90) locked @ ../../vm/vm_fault.c:213 db> show pcpu cpuid = 0 ipis = 0 next ASN = 148 curproc = 0xfffffe00069bff80: pid 18853 "make" curpcb = 0x66fc000 fpcurproc = none idleproc = 0xfffffe000589f600: pid 10 "idle: cpu0" spin locks held: db> e vm_faults_no_vm_mtx vm_faults_no_vm_mtx: b7c70 db> e vm_faults_no_giant vm_faults_no_giant: 0 db> So.. maybe this is a dumb question, but it looks like the vm_mtx was locked in vm_map_lookup as part of the vm fault path. But, it SHOULD have gotten locked in exit1(), around pmap_remove_pages, shouldn't it? So, shouldn't there have been a lock-recursion message in there? I don't understand. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jun 14 8:59:55 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from superconductor.rush.net (superconductor.rush.net [208.9.155.8]) by hub.freebsd.org (Postfix) with ESMTP id 007D837B401; Thu, 14 Jun 2001 08:59:45 -0700 (PDT) (envelope-from bright@superconductor.rush.net) Received: (from bright@localhost) by superconductor.rush.net (8.11.2/8.11.2) id f5EFxhc30578; Thu, 14 Jun 2001 11:59:43 -0400 (EDT) Date: Thu, 14 Jun 2001 11:59:42 -0400 From: Alfred Perlstein To: Andrew Gallatin Cc: jhb@freebsd.org;, freebsd-alpha@freebsd.org Subject: Re: alpha pmap corruption continues Message-ID: <20010614115942.B1832@superconductor.rush.net> References: <15144.55776.3763.28141@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <15144.55776.3763.28141@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Thu, Jun 14, 2001 at 11:36:00AM -0400 X-all-your-base: are belong to us. Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Andrew Gallatin [010614 11:36] wrote: > > John, > > With your http://people.freebsd.org/~jhb/patches/vm.patch and > with rev 1.60 of alpha/trap.c reverted, I'm still seeing what > looks like pmap corruption with a (mostly) GENERIC kernel on a UP > alpha a few minutes into a -j32 buildworld. [snip] > > db> e vm_faults_no_vm_mtx > vm_faults_no_vm_mtx: b7c70 > db> e vm_faults_no_giant > vm_faults_no_giant: 0 > db> > > > So.. maybe this is a dumb question, but it looks like the vm_mtx was > locked in vm_map_lookup as part of the vm fault path. But, it SHOULD > have gotten locked in exit1(), around pmap_remove_pages, shouldn't it? So, > shouldn't there have been a lock-recursion message in there? > > I don't understand. Since John has made giant required by all vm code again, the only panics you should see relating to vm_mtx are failed assertions, that is unless John missed a spot where giant was needed. -- -Alfred Perlstein [alfred@freebsd.org] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jun 14 10: 6:37 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from technokratis.com (modemcable052.174-202-24.mtl.mc.videotron.ca [24.202.174.52]) by hub.freebsd.org (Postfix) with ESMTP id 7052437B405; Thu, 14 Jun 2001 10:06:09 -0700 (PDT) (envelope-from bmilekic@technokratis.com) Received: (from bmilekic@localhost) by technokratis.com (8.11.3/8.11.3) id f5EH6sr24050; Thu, 14 Jun 2001 13:06:54 -0400 (EDT) (envelope-from bmilekic) Date: Thu, 14 Jun 2001 13:06:54 -0400 From: Bosko Milekic To: Terry Lambert Cc: freebsd-current@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: New SMP Mbuf Allocator (PATCH and TESTING request) Message-ID: <20010614130654.A23642@technokratis.com> References: <20010613010744.A4083@technokratis.com> <3B286FC1.5C112A5C@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B286FC1.5C112A5C@mindspring.com>; from tlambert2@mindspring.com on Thu, Jun 14, 2001 at 01:03:13AM -0700 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Terry, On Thu, Jun 14, 2001 at 01:03:13AM -0700, Terry Lambert wrote: > > A general comment, and then a comment on the patch: > > I would like to see this code be optional, until such time > as benchmarks have proven it to be better than the existing > code, or have proben it to be worse. Diking out the existing > code, and forcing it to be diked out by making unnecessary > function name changes seems to me to be a problem. This is going to be a very difficult thing to do. Hear me out. :-) The present code has been designed without any SMP in mind and without any concept of allowing for the possibility to have pages that were once wired-down and put to use by the mbuf subsystem to being freed when no longer used so that memory could be reclaimed. The new code attempts to offer both, but as with almost anything, sacrifices must be made. I'm hesitant to accept your `benchmark this' offer merely because it's difficult to accurately quantify overall performance while it will be easy for the benchmark to detect that the new code is in some ways slower than the old (because of additional complexity) and therefore rule: old allocator > new allocator, which is false given the ignorance of most benchmarks. I'll try my best to circle some of the Pros and Cons of each allocation technique and try to give you an overall picture of the tradeoffs and gains made. - The old allocator has one lock to protect all the free lists. As the number of CPUs grows, so does contention and, consequently, the mbuf allocator may become a significant bottleneck when several threads are servicing net-related requests. The new allocator has a lock per CPU thus allowing for more than one CPU to allocate mbufs and clusters at any one time, ultimately splitting contention in most cases. Additionally, the old allocator, in an SMP system, will likely have the lock (and list structure, etc.) ping-ponging from data cache to data cache whereas the new allocator, because of the separate lists and locks will minimize this effect. - The old allocator fragments memory and can never reclaim it and never easily determine if all the objects in one given page of data are free therefore if we were to ever decide that yes, it's now time to have the allocator free some pages back to the map, we won't be able to easily implement it (if at all). The new allocator has the "framework" for this type of thing so that if users continue requesting (as many have already done) to have FreeBSD free up resources it allocates for mbufs and clusters, we should be able to relatively easily implement freeing from a kproc, for example, and only do it, for example, when X number of bytes is in the pool but when only Y bytes are in use (where Y <<<< X). (Why from a kproc? Because freeing back to the map is relatively expensive for a thread that wants to merely free up an mbuf or cluster - this I *have* determined from previous profiling - results are probably archived somewhere on the lists). - The old allocator's macros MGET, MCLGET, MFREE, etc. could get away with making an allocation without performing a single function call. A function call was done only by those using the function equivalents m_get(), m_gethdr(), etc. The new allocator performs one function call in the common case for allocation. I don't foresee this to be a real problem - if it's any argument at all: NetBSD && OpenBSD have both been doing this for quite a long time (one function call per allocation) and in fact so have we before this allocator was introduced to replace calls to malloc() _and_ also as a result, the new allocator has shrunk those macros to effectively nothing in terms of size thus improving overall performance (less code cache pollution) whereas the old allocator has, needless to say, pretty large macros. - The common case of allocation and freeing in the new allocator is larger (although realistically, not significantly) than the common case for the old allocator. This is due to the added complexity in the new allocator and is expected. The increase in size of the common case is basically from `insignificant' to `insignificant + insignificant' when taking into account the fact that CPU speed is increasing incredibly quickly. Keep in mind that although it may take longer to execute the common case in the new allocator, the fact that there is less contention in the same common case may make it faster, overall. - The old allocator has all mbufs and clusters mixed in the same heap and there is no concept of `producer' and `consumer' in that although one thread may allocate an mbuf and write to it, and another thread may only free the mbuf, the second thread will, if the first thread is on another CPU, that CPU's data cache entries for the given mbuf because during freeing, the thread will write to the mbuf. Since in the new allocator mbufs are not written to when being freed and since they are always returned to the list from which they were obtained, cache invalidation is once again minimized. In conclusion, it is obvious that for strictly UP systems, the present allocator may turn out to be faster. But, if you look at it that way, then the mbuf allocator _BEFORE_ the whole SMPng thing started was EVEN better for UP systems (no lock code, etc.) On the other hand, the elimination of huge macros may even help improve overall performance even for UP systems. In the SMP case, the new allocator scales much much better. Both of these statements are obvious from the above points/comparisons. I hope this makes it clear that depending on the benchmark, we may see completely different results. Keep in mind though that the new allocator also offers the possibility of freeing back to the map, a significant advantage over the old one, especially for servers with exceptionally high network loads (for example, an IRC server may consume a lot of memory for mbufs and clusters at one point, only then to drop to normal amounts later again. However, the fact that the pages are never freed and are wired-down means that the system may start swapping simply due to wastage on the mbuf and cluster free lists). > Overall, I like the idea of moving towards a Dynix allocator > type model to support many processors (not just 4) well, but > I'm leery of many of the changes, particularly in light of > the claim that "It has been established that we do not benefit > from different locks for different objects, so we use the same > lock, regardless of object type". Well, if you'll note that not long ago, there used to be three different locks: one for mbufs, one for clusters, and one for counters. However, with three separate locks and the fact that callers often do: "get mbuf -> get counter -> get cluster" often resulted in one CPU doing: "cache first lock -> cache second lock -> cache third lock" and then another would have to invalidate the first CPUs cache three times (as opposed to only once with one lock). As a result, ping-ponging from CPU to CPU to CPU etc. often occured. With one lock, this is minimized. In the new allocator, having separate locks is not really useful since we have one lock per CPU anyway so that comment is not really an attempt at optimization but just a statement of the obvious. > On to the specific comments... I have addressed them in patch > order, so that they can be read side-by-side: > > -- > > The "npg" calculation has always been incorrect for large > memory systems with non-sparse physical maps, and now it > is much worse. I commented on this before in -arch. > > Consider the case of a machine with 4G of physical memory. Can you please clarify? > -- > > Is the policy two line or 4 line license, these days? > > -- I don't know. How is this important? > The MBALLOC_CPU stuff should be more dynamic; it appears > that the real number of CPUs is known at the time the > allocations take place. > > -- Yes, but some structures (notably statistics and the list manager structures) are statically allocated (the stats are exported via sysctl and need this) and so we need to know how many CPUs there are before compilation. It doesn't really matter if we don't, though, because then we'll just end up allocating slightly more than we need (we use MAXCPU in the default case) and we'll be on with it. Note that this does *not* mean that we'll also end up setting up MAXCPU CPU lists, as that setup is done at runtime when we know really how many CPUs we have. > I think you should spin, and only block if you don't get > the spin lock after several attempts. The Solaris tradeoff > in this regard is 10 attempts. Direct blocking on the cv > seems a little wasteful. In the common case, I shouldn't have to even block. These are per-CPU locks and blocking only happens when a different CPU is freeing an mbuf to a first CPUs list. I don't think I'm doing anything wrong with using the standard locking primitives provided by the OS. Spinlocks disable local interrupts and that seems more wasteful than blocking. I could be wrong, but these things are easy to change. > I'm not sure why you mutex the per-CPU containers? Aren't > they, by definition, per-CPU, and therefore immune from > contention? I mutex them for two reasons: 1- A thread on another CPU may be freeing to the first CPU if the mbuf it is freeing originated from the first CPU (this is a characteristic of the allocator model). 2- Preemption. > -- > > You realize that there is a dependency on MAXFILES, right? > > Specifically, there is an mbuf allocated per open socket > for the tcptmpl (even though it only needs 60 bytes). > > --- > > If you fix the tcptmpl allocation, a couple of additional > issues arise: > > 1) Since the allocations are in page-units, you will > end up with a lot of waste. > > 2) Allocation in page units will make it hard to give > 60 byte allocations back to the system. > > 3) The allocator is not really general enough for this > (or for things like TIME_WAIT zombie structs, etc.). > > 4) Yeah, this sort of also implies that mbuf cluster > headers come from a seperate pool, instead of being > 256 bytes as well... Huh? I haven't changed anything in terms of the sizes of allocations. The allocator only allocates mbufs and clusters, which are of fixed size in order to ease allocations of the same object in page units (it's much faster and simpler). I realize that some wastage occurs but that's just a fact of BSD (and has been forever). The new allocator doesn't make it worse. > -- > > Why do you lock around things in mb_init()? It's never > called twice, let alone reentrantly... the code will be > done before an AP is allowed to run. Alpha has this same > restriction, from what I can see from the code. > > -- Simply because mb_pop_cont() expects it and because it's a consistent thing to do with respect to the internal interface. > Dropping the lock in mb_pop_cont() seems wrong; I guess > you are avoiding sleeping with the lock held? > > I don't think you need to worry (per-CPU, again), unless > you later attempt lazy repopulation; it seems to me that > the lock that should be held is a global lock, to prevent > reentrancy on the global memory pool, and the malloc() > code does that. > > Perhaps I'm missing something here. Yeah. There have been some discussions as to why this is presently necessary. In the future, it may not be required. But, basically, right now, we can have Giant -> mbuf_related_lock and, if I don't drop the lock, then also mbuf_related_lock -> Giant, which would be a lock order reversal. > -- > > The ability to specify a "how" that implies an unwillingness > to block implies interrupt allocation; yet you can't support > this, since you do not preallocate a kernel map (ala the zone > allocator). The zone allocator is actually very misleading, > in that some of it's code never has the values it implies that > it might have; in particular, there are functions which are > passed parameters which can't really be variant, as implied by > the use of per zone variables as arguments. Although I don't quite understand everything you mention in this last paragraph, the `how' parameter implies more than just willingness to block in the new allocator. It also determines whether or not, during starvation, the system will call the protocol drain routines and whether or not it will attempt to "steal" from other CPU lists. Feel free to clarify, though, if it's still a concern. > -- > > Ah. I see why all the locks: mb_alloc_wait attempts to be > a primitive reclaimer. You would do much better with a per-CPU > high-watermark reclaim at free(), I think, instead of doing > this. Really, you are in a starvation condition because of > your load, and not because someone is "hogging already free > mbufs", I think. This is probably premature optimization. > > -- > > In the starvation case during a free, I don't think you > really care, except perhaps to adjust the high/low watermarks. > > An interesting issue here is that the average TCP window size > will end up being 16k, which comes out to 4 1-page buckets (2, > on Alpha), where you end up with multiple buckets and many > mbufs (64) per, so freeing isn't really an option, if you are > sending lots of data (serving content). It would be different > for a desktop system, since the receive interrupt might come > to any idle CPU. > > -- > > I like the cleanup via the use of local macros. Thanks. So do I. :-) > -- > > I think the m_getclr -> m_get_clrd change is gratuitous. m_getclr() isn't used at many places so it's not that big of a deal. The reason I changed it is because it's confusing: m_getclr() sounds like "m_get a cluster." > -- > > I like the "only" comment claifications. > > -- > > I dislike the bloating of one line comments into three lines, > with the first and last blank. It happens once or twice, as far as I could see (I could be missing some). It's to maintain consistency. The one-line comment likely should have been a three-line comment to begin with. > -- > > You could resolve the statistics problems by keeping them on > a per-CPU basis, and then agregating them under a general > system lock, when necessary (when they were requested). > > -- > > Most of the header definition changes for function declarations > are gratuitous. It's a question of alignment and style fix (to properly align the function declarations as per style(9), I'm allowed to insert a space for functions that do not return pointers). > -- > > Don't really care about netstat stuff... > > -- > > -- Terry -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jun 14 10:48:42 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 1CB1137B401; Thu, 14 Jun 2001 10:48:39 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f5EHm3165032; Thu, 14 Jun 2001 10:48:03 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <15144.55776.3763.28141@grasshopper.cs.duke.edu> Date: Thu, 14 Jun 2001 10:48:07 -0700 (PDT) From: John Baldwin To: Andrew Gallatin Subject: RE: alpha pmap corruption continues Cc: freebsd-alpha@FreeBSD.org, alfred@FreeBSD.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 14-Jun-01 Andrew Gallatin wrote: > > fatal kernel trap: > > trap entry = 0x2 (memory management fault) > cpuid = 0 > faulting va = 0xfffffffe00480210 Interesting faulting address. This is in K0SEG isn't it? :( > Stopped at pmap_remove_pages+0xa8: ldl t0,0(t2) <0xfffffffe00480210> > > db> tr > pmap_remove_pages() at pmap_remove_pages+0xa8 > exit1() at exit1+0xab8 > sys_exit() at sys_exit+0x24 > syscall() at syscall+0x628 > XentSys() at XentSys+0x64 > --- syscall (1, FreeBSD ELF, sys_exit) --- > --- user mode --- > > db> show locks > exclusive (sleep mutex) vm (0xfffffc00007be0f8) locked @ > ../../vm/vm_map.c:2617 > exclusive (sleep mutex) Giant (0xfffffc00007bed90) locked @ > ../../vm/vm_fault.c:213 > db> show pcpu > cpuid = 0 > ipis = 0 > next ASN = 148 > curproc = 0xfffffe00069bff80: pid 18853 "make" > curpcb = 0x66fc000 > fpcurproc = none > idleproc = 0xfffffe000589f600: pid 10 "idle: cpu0" > spin locks held: > db> e vm_faults_no_vm_mtx > vm_faults_no_vm_mtx: b7c70 > db> e vm_faults_no_giant > vm_faults_no_giant: 0 > db> > > > So.. maybe this is a dumb question, but it looks like the vm_mtx was > locked in vm_map_lookup as part of the vm fault path. But, it SHOULD > have gotten locked in exit1(), around pmap_remove_pages, shouldn't it? So, > shouldn't there have been a lock-recursion message in there? In vm_fault() we check to see if we already own the vm_mtx to prevent recursing on it. Look at the hadvmlock variable in vm_fault(). That means, though, that it shouldn't be reporting vm_map.c as it's last acquired line though. :( Oh. This is due to interlock ugliness. When we grab a vm_map lock, we temporarily release the vm lock during the lock acquisition adn then reacquire it. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jun 14 11: 2:17 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 0A2AD37B405; Thu, 14 Jun 2001 11:02:00 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id OAA10031; Thu, 14 Jun 2001 14:01:59 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f5EI1TU22008; Thu, 14 Jun 2001 14:01:29 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15144.64505.439116.166985@grasshopper.cs.duke.edu> Date: Thu, 14 Jun 2001 14:01:29 -0400 (EDT) To: John Baldwin Cc: freebsd-alpha@FreeBSD.org, alfred@FreeBSD.org Subject: RE: alpha pmap corruption continues In-Reply-To: References: <15144.55776.3763.28141@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John Baldwin writes: > > On 14-Jun-01 Andrew Gallatin wrote: > > > > fatal kernel trap: > > > > trap entry = 0x2 (memory management fault) > > cpuid = 0 > > faulting va = 0xfffffffe00480210 > > Interesting faulting address. This is in K0SEG isn't it? :( No, K0SEG goes from 0xfffffc0000000000LL to 0xfffffdffffffffffLL Anything with a 0xf..ffe00... is mapped (kernel) memory. <...> > In vm_fault() we check to see if we already own the vm_mtx to prevent recursing > on it. Look at the hadvmlock variable in vm_fault(). That means, though, that > it shouldn't be reporting vm_map.c as it's last acquired line though. :( Oh. > This is due to interlock ugliness. When we grab a vm_map lock, we temporarily > release the vm lock during the lock acquisition adn then reacquire it. So, what are the odds that there's a race somewhere in this releasing & reacquireing? We used to be at splvm throughout this code, right? Is this at a point where we used to sleep (or otherwise drop to ipl0?), or is this a new opportunity for a race? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jun 14 12:58:14 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 765E837B401 for ; Thu, 14 Jun 2001 12:58:07 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from wonky.feral.com (wonky.feral.com [192.67.166.7]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f5EJw6g43920 for ; Thu, 14 Jun 2001 12:58:06 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Thu, 14 Jun 2001 12:57:54 -0700 (PDT) From: Matthew Jacob Reply-To: To: Subject: rebooting, not... Message-ID: <20010614125716.F22077-100000@wonky.feral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 2 processor 4100: boot() called on cpu#0 Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... done Uptime: 2h44m24s Rebooting... isp1: Name Server Database Changed isp1: Firmware State Ready> isp1: Target 126 (Loop 0x7e) Port ID 0xfffffe (role (none)) Arrived Port WWN 0x200100c0dd008073 Node WWN 0x100000c0dd008073 isp1: Loop ID 0, AL_PA 0xef, Port ID 0x1001ef, Loop State 0x2, Topology 'FL Port' isp1: Target 0 (Loop 0x0) Port ID 0x1001ef (role Initiator) Arrived Port WWN 0x210000e08b016899 Node WWN 0x200000e08b016899 isp1: NL_Port @ 0x1007e1, Node 0x20000020370f847e Port 21000020370f847e isp1: NL_Port @ 0x1007e2, Node 0x20000020370fa077 Port 21000020370fa077 isp1: NL_Port @ 0x1007e4, Node 0x20000020370f83c0 Port 21000020370f83c0 isp1: NL_Port @ 0x1007e8, Node 0x20000020370f848e Port 21000020370f848e isp1: NL_Port @ 0x1001ef, Node 0x200000e08b016899 Port 210000e08b016899 isp1: Retaining Loop ID 0x7e for Target 126 (Port 0xfffffe) isp1: Target 129 (Loop 0x81) Port ID 0x10062a (role Initiator) Departed Port WWN 0x210000e08b003b1f Node WWN 0x200000e08b003b1f isp1: Retained login of Target 130 (Loop ID 0x82) Port 0x1007e1 isp1: Retained login of Target 131 (Loop ID 0x83) Port 0x1007e2 isp1: Retained login of Target 132 (Loop ID 0x84) Port 0x1007e4 isp1: Retained login of Target 133 (Loop ID 0x85) Port 0x1007e8 Note that we're still getting interrupts after the call to Reboot- which is wierd... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jun 14 13:25:16 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 5DD0D37B40D for ; Thu, 14 Jun 2001 13:24:59 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f5EKOd167730; Thu, 14 Jun 2001 13:24:39 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010614125716.F22077-100000@wonky.feral.com> Date: Thu, 14 Jun 2001 13:24:45 -0700 (PDT) From: John Baldwin To: Matthew Jacob Subject: RE: rebooting, not... Cc: alpha@FreeBSD.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 14-Jun-01 Matthew Jacob wrote: > > 2 processor 4100: > > boot() called on cpu#0 > Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped > Waiting (max 60 seconds) for system process `syncer' to stop...stopped > > syncing disks... > done > Uptime: 2h44m24s > Rebooting... > isp1: Name Server Database Changed > isp1: Firmware State Ready> > isp1: Target 126 (Loop 0x7e) Port ID 0xfffffe (role (none)) Arrived > Port WWN 0x200100c0dd008073 > Node WWN 0x100000c0dd008073 > isp1: Loop ID 0, AL_PA 0xef, Port ID 0x1001ef, Loop State 0x2, Topology 'FL > Port' > isp1: Target 0 (Loop 0x0) Port ID 0x1001ef (role Initiator) Arrived > Port WWN 0x210000e08b016899 > Node WWN 0x200000e08b016899 > isp1: NL_Port @ 0x1007e1, Node 0x20000020370f847e Port 21000020370f847e > isp1: NL_Port @ 0x1007e2, Node 0x20000020370fa077 Port 21000020370fa077 > isp1: NL_Port @ 0x1007e4, Node 0x20000020370f83c0 Port 21000020370f83c0 > isp1: NL_Port @ 0x1007e8, Node 0x20000020370f848e Port 21000020370f848e > isp1: NL_Port @ 0x1001ef, Node 0x200000e08b016899 Port 210000e08b016899 > isp1: Retaining Loop ID 0x7e for Target 126 (Port 0xfffffe) > isp1: Target 129 (Loop 0x81) Port ID 0x10062a (role Initiator) Departed > Port WWN 0x210000e08b003b1f > Node WWN 0x200000e08b003b1f > isp1: Retained login of Target 130 (Loop ID 0x82) Port 0x1007e1 > isp1: Retained login of Target 131 (Loop ID 0x83) Port 0x1007e2 > isp1: Retained login of Target 132 (Loop ID 0x84) Port 0x1007e4 > isp1: Retained login of Target 133 (Loop ID 0x85) Port 0x1007e8 > > > > Note that we're still getting interrupts after the call to Reboot- which is > wierd... Yes, we don't actually do anything to ensure that: 1) We halt on the boot CPU and 2) We halt the other CPU's before we halt. Thus, cpu1 is still running until SRM kills it. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jun 14 15:15:54 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 8E9AC37B401; Thu, 14 Jun 2001 15:15:50 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from wonky.feral.com (wonky.feral.com [192.67.166.7]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f5EMFlg44159; Thu, 14 Jun 2001 15:15:47 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Thu, 14 Jun 2001 15:15:34 -0700 (PDT) From: Matthew Jacob Reply-To: To: Bosko Milekic Cc: , Subject: Re: New SMP Mbuf Allocator (PATCH and TESTING request) In-Reply-To: <20010614130654.A23642@technokratis.com> Message-ID: <20010614151518.L22077-100000@wonky.feral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org FWIW- your patches appear to work fine for top of tree alpha. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jun 14 17: 0: 9 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 6D9FC37B403 for ; Thu, 14 Jun 2001 17:00:07 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f5ENxw171029 for ; Thu, 14 Jun 2001 16:59:58 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Thu, 14 Jun 2001 17:00:06 -0700 (PDT) From: John Baldwin To: alpha@FreeBSD.org Subject: A useful panic for a change Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Well, I've got another SMP panic, but this time it may be useful. It looks like zalloc may be returning w/o holding the vm lock if it is called with it held. Unfortunately, I'm not going to be making much progress on this as I'll be at BAFUG tonight, but we'll see. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jun 14 20:54:45 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from ashburn.skiltech.com (ashburn.skiltech.com [216.235.79.239]) by hub.freebsd.org (Postfix) with ESMTP id 6EFA737B406 for ; Thu, 14 Jun 2001 20:54:39 -0700 (PDT) (envelope-from minter@ashburn.skiltech.com) Received: (from minter@localhost) by ashburn.skiltech.com (8.11.3/8.11.1) id f5F0aCo34006; Thu, 14 Jun 2001 20:36:12 -0400 (EDT) (envelope-from minter) Date: Thu, 14 Jun 2001 20:36:12 -0400 (EDT) From: "H. Wade Minter" X-X-Sender: To: Subject: Wit's end (AS250 installation issues) Message-ID: <20010614203233.Y33392-100000@ashburn.skiltech.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm stuck on a problem, and hopefully some of the more-experienced Alpha folk here can help. I've come into an AlphaStation 250 4/266, and would like to run FreeBSD on it. It's got two SCSI disks in it, that show up as DKA0 and DKA300 in the SRM BIOS, and a CD at DKA400. With the 4.3-RELEASE Alpha ISO image, I can "boot DKA400" and get into the installer. The install goes great, I make my filesystem on the DKA300 disk, and install away. After the installer is finished, the system halts back to the >>> prompt. Here's where it gets frustrating. When I do "boot DKA300" from the SRM BIOS, it finds a valid boot block, loads it, tries to load /boot/loader, and then dies with a "can't find /boot/loader" error. What am I doing wrong here? Thanks, Wade To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Jun 15 3:10:56 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id E045C37B401 for ; Fri, 15 Jun 2001 03:10:52 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f5FA8CM89168 for ; Fri, 15 Jun 2001 03:08:12 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 9D43E380E for ; Fri, 15 Jun 2001 03:08:12 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: alpha@freebsd.org Subject: Can somebody please double check this change? Date: Fri, 15 Jun 2001 03:08:12 -0700 From: Peter Wemm Message-Id: <20010615100812.9D43E380E@overcee.netplex.com.au> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I was tempted to commit this blind (I'm not near a 5.x alpha box right now) as I'm 99.99% sure it cannot hurt. This is the alpha equivalent of a part of rev 1.136 (August 2000) of i386/locore.s. This is because of: mi_startup(void). It used to be used but no more. Can anybody quickly confirm that this doesn't break things [any more]? Index: locore.s =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/locore.s,v retrieving revision 1.16 diff -u -r1.16 locore.s --- locore.s 2001/06/15 09:59:25 1.16 +++ locore.s 2001/06/15 10:04:56 @@ -128,13 +128,6 @@ call_pal PAL_OSF1_tbi call_pal PAL_imb - /* - * Construct a fake trap frame, so execve() can work normally. - * Note that setregs() is responsible for setting its contents - * to 'reasonable' values. - */ - lda sp,-288(sp) /* space for struct trapframe */ - mov sp, a0 /* arg is frame ptr */ CALL(mi_startup) /* go to mi_startup()! */ /* NOTREACHED */ Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Jun 15 6:24:55 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 814EA37B408 for ; Fri, 15 Jun 2001 06:24:49 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id JAA28339; Fri, 15 Jun 2001 09:24:49 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f5FDOJ124294; Fri, 15 Jun 2001 09:24:19 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15146.3202.948501.336690@grasshopper.cs.duke.edu> Date: Fri, 15 Jun 2001 09:24:18 -0400 (EDT) To: "H. Wade Minter" Cc: Subject: Re: Wit's end (AS250 installation issues) In-Reply-To: <20010614203233.Y33392-100000@ashburn.skiltech.com> References: <20010614203233.Y33392-100000@ashburn.skiltech.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org H. Wade Minter writes: > I'm stuck on a problem, and hopefully some of the more-experienced Alpha > folk here can help. > > I've come into an AlphaStation 250 4/266, and would like to run FreeBSD on > it. It's got two SCSI disks in it, that show up as DKA0 and DKA300 in the > SRM BIOS, and a CD at DKA400. > > With the 4.3-RELEASE Alpha ISO image, I can "boot DKA400" and get into the > installer. The install goes great, I make my filesystem on the DKA300 > disk, and install away. After the installer is finished, the system halts > back to the >>> prompt. Here's where it gets frustrating. > > When I do "boot DKA300" from the SRM BIOS, it finds a valid boot block, > loads it, tries to load /boot/loader, and then dies with a "can't find > /boot/loader" error. > > What am I doing wrong here? You need to make the "a" partition the root parition and make sure that it appears first on the disk. If "a" is not first, our primary bootblocks will be unable to find the loader. Hope this helps, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Jun 15 6:53:21 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id C85BD37B405 for ; Fri, 15 Jun 2001 06:53:18 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id JAA28960; Fri, 15 Jun 2001 09:53:18 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f5FDqmJ24370; Fri, 15 Jun 2001 09:52:48 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15146.4912.304879.252934@grasshopper.cs.duke.edu> Date: Fri, 15 Jun 2001 09:52:48 -0400 (EDT) To: Peter Wemm Cc: alpha@FreeBSD.ORG Subject: Re: Can somebody please double check this change? In-Reply-To: <20010615100812.9D43E380E@overcee.netplex.com.au> References: <20010615100812.9D43E380E@overcee.netplex.com.au> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Peter Wemm writes: > This is because of: mi_startup(void). It used to be used but no more. > Can anybody quickly confirm that this doesn't break things [any more]? It works just fine here. Thanks for remember alpha in your cleanups! Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Jun 15 9:20:56 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from fl-mia01-m.stis.com (5935supra.020.popsite.net [64.24.149.213]) by hub.freebsd.org (Postfix) with ESMTP id 352CE37B401 for ; Fri, 15 Jun 2001 09:20:36 -0700 (PDT) (envelope-from IMCEAEX-_O=STIS_OU=STIS_CN=RECIPIENTS_CN=RCRESPO@STIS.com) Received: by fl-mia01-m.stis.com.10.in-addr.arpa with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 12:21:19 -0400 Message-ID: From: "Crespo, Ramon" To: "'freebsd-alpha@FreeBSD.org'" Subject: Date: Fri, 15 Jun 2001 12:21:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org subscribe freebsd-alpha To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Jun 15 11:20:16 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from fl-mia01-m.stis.com (5935supra.020.popsite.net [64.24.149.213]) by hub.freebsd.org (Postfix) with ESMTP id BE8F537B405 for ; Fri, 15 Jun 2001 11:20:12 -0700 (PDT) (envelope-from IMCEAEX-_O=STIS_OU=STIS_CN=RECIPIENTS_CN=RCRESPO@STIS.com) Received: by fl-mia01-m.stis.com.10.in-addr.arpa with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 14:21:04 -0400 Message-ID: From: "Crespo, Ramon" To: "'freebsd-alpha@freebsd.org'" Subject: aplogies / srm question. Date: Fri, 15 Jun 2001 14:19:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello All, Sorry for the empty message .. I didnt see a link to the Alpha subscription at the ports/alpha page on freebsd.org. I have now subscribed properly. Anyone have any luck installing 4.3-RELEASE on a Digital Personal Workstation 600a with AlphaBios 5.7 .. I will be converting it to SRM before my install .. but I also wanted to know if I had to convert it to Digital UNIX SRM or OpenVMS SRM. Thanks Ramon Crespo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Jun 15 11:37:22 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.127.132]) by hub.freebsd.org (Postfix) with ESMTP id B0A0537B403 for ; Fri, 15 Jun 2001 11:37:19 -0700 (PDT) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp3.xs4all.nl (8.9.3/8.9.3) with ESMTP id UAA18146; Fri, 15 Jun 2001 20:37:10 +0200 (CEST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.3/8.11.3) id f5FIX6420637; Fri, 15 Jun 2001 20:33:06 +0200 (CEST) (envelope-from wkb) Date: Fri, 15 Jun 2001 20:33:06 +0200 From: Wilko Bulte To: "Crespo, Ramon" Cc: "'freebsd-alpha@freebsd.org'" Subject: Re: aplogies / srm question. Message-ID: <20010615203306.A20623@freebie.xs4all.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from IMCEAEX-_O=STIS_OU=STIS_CN=RECIPIENTS_CN=RCRESPO@STIS.com on Fri, Jun 15, 2001 at 02:19:08PM -0400 X-OS: FreeBSD 4.3-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jun 15, 2001 at 02:19:08PM -0400, Crespo, Ramon wrote: > Hello All, > > Sorry for the empty message .. I didnt see a link to the Alpha subscription > at the ports/alpha page on freebsd.org. I have now subscribed properly. > Anyone have any luck installing 4.3-RELEASE on a Digital Personal > Workstation 600a with AlphaBios 5.7 .. I will be converting it to SRM before > my install .. but I also wanted to know if I had to convert it to Digital > UNIX SRM or OpenVMS SRM. I have a PWS600au here, works just fine. Unix SRM on mine. -- | / o / / _ Arnhem, The Netherlands email: wilko@FreeBSD.org |/|/ / / /( (_) Bulte http://www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Jun 15 15:12: 7 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from ashburn.skiltech.com (ashburn.skiltech.com [216.235.79.239]) by hub.freebsd.org (Postfix) with ESMTP id 0FAB837B403 for ; Fri, 15 Jun 2001 15:12:05 -0700 (PDT) (envelope-from minter@ashburn.skiltech.com) Received: (from minter@localhost) by ashburn.skiltech.com (8.11.3/8.11.1) id f5FMBxH42603; Fri, 15 Jun 2001 18:11:59 -0400 (EDT) (envelope-from minter) Date: Fri, 15 Jun 2001 18:11:59 -0400 (EDT) From: "H. Wade Minter" X-X-Sender: To: Andrew Gallatin Cc: Subject: Re: Wit's end (AS250 installation issues) In-Reply-To: <15146.3202.948501.336690@grasshopper.cs.duke.edu> Message-ID: <20010615181053.W42492-100000@ashburn.skiltech.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I ran through the installer again, and I set the disk up like so: /dev/da0a - / /dev/da0b - swap No other partitions. However, when I "boot dka0" from the SRM, it still dies with the failure to find /boot/loader Ideas? --Wade On Fri, 15 Jun 2001, Andrew Gallatin wrote: > > H. Wade Minter writes: > > I'm stuck on a problem, and hopefully some of the more-experienced Alpha > > folk here can help. > > > > I've come into an AlphaStation 250 4/266, and would like to run FreeBSD on > > it. It's got two SCSI disks in it, that show up as DKA0 and DKA300 in the > > SRM BIOS, and a CD at DKA400. > > > > With the 4.3-RELEASE Alpha ISO image, I can "boot DKA400" and get into the > > installer. The install goes great, I make my filesystem on the DKA300 > > disk, and install away. After the installer is finished, the system halts > > back to the >>> prompt. Here's where it gets frustrating. > > > > When I do "boot DKA300" from the SRM BIOS, it finds a valid boot block, > > loads it, tries to load /boot/loader, and then dies with a "can't find > > /boot/loader" error. > > > > What am I doing wrong here? > > You need to make the "a" partition the root parition and make sure > that it appears first on the disk. If "a" is not first, our primary > bootblocks will be unable to find the loader. > > Hope this helps, > > Drew > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Jun 15 15:31:14 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from ashburn.skiltech.com (ashburn.skiltech.com [216.235.79.239]) by hub.freebsd.org (Postfix) with ESMTP id 40DEA37B401 for ; Fri, 15 Jun 2001 15:31:11 -0700 (PDT) (envelope-from minter@ashburn.skiltech.com) Received: (from minter@localhost) by ashburn.skiltech.com (8.11.3/8.11.1) id f5FMVAG46081; Fri, 15 Jun 2001 18:31:10 -0400 (EDT) (envelope-from minter) Date: Fri, 15 Jun 2001 18:31:09 -0400 (EDT) From: "H. Wade Minter" X-X-Sender: To: Andrew Gallatin Cc: Subject: Re: Wit's end (AS250 installation issues) In-Reply-To: <20010615181053.W42492-100000@ashburn.skiltech.com> Message-ID: <20010615183014.X45884-100000@ashburn.skiltech.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Replying to my own message.... I let the installer "auto-partition" the disk, and it set up /, /var, /usr, and swap, with a 100M / on da0a, and guess what? It worked fine. The system booted right up. Any ideas as to what the difference was? --Wade On Fri, 15 Jun 2001, H. Wade Minter wrote: > I ran through the installer again, and I set the disk up like so: > > /dev/da0a - / > /dev/da0b - swap > > No other partitions. > > However, when I "boot dka0" from the SRM, it still dies with the failure > to find /boot/loader > > Ideas? > > --Wade > > On Fri, 15 Jun 2001, Andrew Gallatin wrote: > > > > > H. Wade Minter writes: > > > I'm stuck on a problem, and hopefully some of the more-experienced Alpha > > > folk here can help. > > > > > > I've come into an AlphaStation 250 4/266, and would like to run FreeBSD on > > > it. It's got two SCSI disks in it, that show up as DKA0 and DKA300 in the > > > SRM BIOS, and a CD at DKA400. > > > > > > With the 4.3-RELEASE Alpha ISO image, I can "boot DKA400" and get into the > > > installer. The install goes great, I make my filesystem on the DKA300 > > > disk, and install away. After the installer is finished, the system halts > > > back to the >>> prompt. Here's where it gets frustrating. > > > > > > When I do "boot DKA300" from the SRM BIOS, it finds a valid boot block, > > > loads it, tries to load /boot/loader, and then dies with a "can't find > > > /boot/loader" error. > > > > > > What am I doing wrong here? > > > > You need to make the "a" partition the root parition and make sure > > that it appears first on the disk. If "a" is not first, our primary > > bootblocks will be unable to find the loader. > > > > Hope this helps, > > > > Drew > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sat Jun 16 2:22:14 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [206.40.252.115]) by hub.freebsd.org (Postfix) with ESMTP id 312F137B407 for ; Sat, 16 Jun 2001 02:22:12 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f5G9Laf41066; Sat, 16 Jun 2001 02:21:36 -0700 (PDT) (envelope-from obrien) Date: Sat, 16 Jun 2001 02:21:36 -0700 From: "David O'Brien" To: "H. Wade Minter" Cc: Andrew Gallatin , alpha@FreeBSD.ORG Subject: Re: Wit's end (AS250 installation issues) Message-ID: <20010616022136.A41027@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <15146.3202.948501.336690@grasshopper.cs.duke.edu> <20010615181053.W42492-100000@ashburn.skiltech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010615181053.W42492-100000@ashburn.skiltech.com>; from minter@lunenburg.org on Fri, Jun 15, 2001 at 06:11:59PM -0400 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jun 15, 2001 at 06:11:59PM -0400, H. Wade Minter wrote: > I ran through the installer again, and I set the disk up like so: > > /dev/da0a - / > /dev/da0b - swap The order in which you assign them is important. Sysinstall knows that the swap partition must be `b'. Also that / must be `a'. However, if you first allocate swap and then /, you are telling Sysinstall to put the `b' partition before the `a' partition on your disk. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sat Jun 16 8:24:44 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from ashburn.skiltech.com (ashburn.skiltech.com [216.235.79.239]) by hub.freebsd.org (Postfix) with ESMTP id DC81A37B401; Sat, 16 Jun 2001 08:24:41 -0700 (PDT) (envelope-from minter@ashburn.skiltech.com) Received: (from minter@localhost) by ashburn.skiltech.com (8.11.3/8.11.1) id f5GCLcC25112; Sat, 16 Jun 2001 08:21:38 -0400 (EDT) (envelope-from minter) Date: Sat, 16 Jun 2001 08:21:38 -0400 (EDT) From: "H. Wade Minter" X-X-Sender: To: "David O'Brien" Cc: Andrew Gallatin , Subject: Re: Wit's end (AS250 installation issues) In-Reply-To: <20010616022136.A41027@dragon.nuxi.com> Message-ID: <20010616082123.S25057-100000@ashburn.skiltech.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Excellent. I think that was the missing piece. Thanks, Wade On Sat, 16 Jun 2001, David O'Brien wrote: > On Fri, Jun 15, 2001 at 06:11:59PM -0400, H. Wade Minter wrote: > > I ran through the installer again, and I set the disk up like so: > > > > /dev/da0a - / > > /dev/da0b - swap > > The order in which you assign them is important. Sysinstall knows that > the swap partition must be `b'. Also that / must be `a'. However, if > you first allocate swap and then /, you are telling Sysinstall to put the > `b' partition before the `a' partition on your disk. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sat Jun 16 8:43:34 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id 1752637B401; Sat, 16 Jun 2001 08:43:23 -0700 (PDT) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.3/8.11.3) id f5GFniv67417; Sat, 16 Jun 2001 17:49:44 +0200 (CEST) (envelope-from wkb) Date: Sat, 16 Jun 2001 17:49:44 +0200 From: Wilko Bulte To: "H. Wade Minter" Cc: "David O'Brien" , Andrew Gallatin , alpha@FreeBSD.ORG Subject: Re: Wit's end (AS250 installation issues) Message-ID: <20010616174944.A67403@freebie.xs4all.nl> References: <20010616022136.A41027@dragon.nuxi.com> <20010616082123.S25057-100000@ashburn.skiltech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20010616082123.S25057-100000@ashburn.skiltech.com>; from minter@lunenburg.org on Sat, Jun 16, 2001 at 08:21:38AM -0400 X-OS: FreeBSD 4.3-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Jun 16, 2001 at 08:21:38AM -0400, H. Wade Minter wrote: Seems I need to re-phrase the -alpha docs a bit to make this clearer to the innocent ;-) Wilko > Excellent. I think that was the missing piece. > > Thanks, > Wade > > On Sat, 16 Jun 2001, David O'Brien wrote: > > > On Fri, Jun 15, 2001 at 06:11:59PM -0400, H. Wade Minter wrote: > > > I ran through the installer again, and I set the disk up like so: > > > > > > /dev/da0a - / > > > /dev/da0b - swap > > > > The order in which you assign them is important. Sysinstall knows that > > the swap partition must be `b'. Also that / must be `a'. However, if > > you first allocate swap and then /, you are telling Sysinstall to put the > > `b' partition before the `a' partition on your disk. > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message ---end of quoted text--- -- | / o / / _ Arnhem, The Netherlands email: wilko@FreeBSD.org |/|/ / / /( (_) Bulte http://www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message