From owner-freebsd-smp Sun Nov 8 10:36:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA05773 for freebsd-smp-outgoing; Sun, 8 Nov 1998 10:36:01 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from wrath.cs.utah.edu (wrath.cs.utah.edu [155.99.198.100]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA05710 for ; Sun, 8 Nov 1998 10:35:57 -0800 (PST) (envelope-from danderse@cs.utah.edu) Received: from lal.cs.utah.edu (lal.cs.utah.edu [155.99.192.110]) by wrath.cs.utah.edu (8.8.8/8.8.8) with ESMTP id LAA13318; Sun, 8 Nov 1998 11:35:39 -0700 (MST) From: David G Andersen Received: (from danderse@localhost) by lal.cs.utah.edu (8.8.8/8.8.8) id LAA16723; Sun, 8 Nov 1998 11:35:53 -0700 (MST) Message-Id: <199811081835.LAA16723@lal.cs.utah.edu> Subject: Re: disk-wait problems/hangs To: vanmaren@fast.cs.utah.edu (Kevin Van Maren) Date: Sun, 8 Nov 1998 11:35:53 -0700 (MST) Cc: bgrayson@marvin.ece.utexas.edu, freebsd-smp@FreeBSD.ORG In-Reply-To: <199811080638.XAA21120@fast.cs.utah.edu> from "Kevin Van Maren" at Nov 7, 98 11:38:48 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org We've been experiencing the same problems; on this end, it looked like the problem was possibly related to amd/nfs. We're running in a NIS environment with heavy AMD and NFS usage; disabling things like SMP didn't solve the problem, but disabling AMD did. Our solution was to back AMD out to the pre-aug-23 integration of the a16 version; another person has upgraded theirs to the latest b1 release. (We tried the upgrade, but it didn't solve the problem). We're trying to get a crashdump of the hang, but after the AMD backout, it's become difficult to reproduce. Interestingly enough, the a.out netscape is _exactly_ how we reproduce the problem. :) We don't see things stuck in 'D', but it may be that they're going downhill so quickly that the entire machine hangs before we catch it. (I'm not on -smp, so please CC: responses to me; a colleague forwarded me the message). -Dave Lo and behold, Kevin Van Maren once said: > > > From: "Brian C. Grayson" > > Date: Sat, 7 Nov 1998 23:36:40 -0600 > > To: freebsd-smp@FreeBSD.ORG > > Subject: disk-wait problems/hangs > > > > We're running 3.0-RELEASE on a few dual P-II boxes. > > Occasionally, processes will start getting hung in 'D' > > (disk-wait, IIRC), even on an otherwise-idle machine. They > > never come out, they aren't kill -9'able. Once the system gets > > into this state, commands like 'df' and 'ls' are likely to go into > > disk-wait. Eventually (on the order of minutes/hours), > > something crucial like nfsd, ypbind, or sshd gets stuck in D, > > and the machine requires a reboot. > > > > I can reproducibly force the cascade of D problems by running > > an a.out Netscape -- it gets hung after <2 CPU seconds, and > > things go downhill quickly. But I believe the problems have > > occurred before without the use of any a.out executables. > > > > Has anyone else seen this? > > > > Brian > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-smp" in the body of the message > > > -- work: danderse@cs.utah.edu me: angio@pobox.com University of Utah http://www.angio.net/ Department of Computer Science To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Nov 8 10:59:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA07924 for freebsd-smp-outgoing; Sun, 8 Nov 1998 10:59:07 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from marvin.ece.utexas.edu (marvin.ece.utexas.edu [128.83.52.151]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA07919 for ; Sun, 8 Nov 1998 10:59:05 -0800 (PST) (envelope-from bgrayson@marvin.ece.utexas.edu) Received: (from bgrayson@localhost) by marvin.ece.utexas.edu (8.8.8/8.8.8) id MAA04500; Sun, 8 Nov 1998 12:58:50 -0600 (CST) Message-ID: <19981108125850.B4167@marvin.ece.utexas.edu> Date: Sun, 8 Nov 1998 12:58:50 -0600 From: "Brian C. Grayson" To: David G Andersen , Kevin Van Maren Cc: freebsd-smp@FreeBSD.ORG Subject: Re: disk-wait problems/hangs References: <199811080638.XAA21120@fast.cs.utah.edu> <199811081835.LAA16723@lal.cs.utah.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: <199811081835.LAA16723@lal.cs.utah.edu>; from David G Andersen on Sun, Nov 08, 1998 at 11:35:53AM -0700 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Nov 08, 1998 at 11:35:53AM -0700, David G Andersen wrote: > We've been experiencing the same problems; on this end, it looked like the > problem was possibly related to amd/nfs. We're running in a NIS > environment with heavy AMD and NFS usage; disabling things like SMP didn't > solve the problem, but disabling AMD did. Our solution was to back AMD > out to the pre-aug-23 integration of the a16 version; another person has > upgraded theirs to the latest b1 release. (We tried the upgrade, but it > didn't solve the problem). We are not running amd on these machines -- only NFS and NIS. FWIW, I've noticed that on other machines running NetBSD, amd-6.0a16 misbehaves (or just plain doesn't work!), so it's not just FreeBSD (not surprising), and it's not just SMP. 6.0a13 works fine for us, and NetBSD skipped over a14 and a15, I believe. > We're trying to get a crashdump of the hang, but after the AMD backout, > it's become difficult to reproduce. Are you sure it's a real hang? Once, ypbind got stuck in 'D', which meant that just about everything was impossible to do (no more logins, "ls" hangs, etc.). To verify, log in as root on another tty before initiating the netscape. Also, never run any command without backgrounding it, otherwise if that command gets hung in 'D', your tty is unusable, as things in 'D' don't catch signals. In other words, "ls &", "df &", "ps -ax &". The output is messy, but that's the price for keeping the tty alive! Our machine doesn't really hang, it's just that more and more processes go into 'D' and stay there. Eventually one runs out of ttys, and a critical daemon gets stuck in 'D'. Maybe if we were doing something more intensive than a single interactive shell, it would cause a hang! Brian -- Student: "How is Q(x,0) defined at x = 0?" Ken Richardson: "Just blow off 0." (about a function in Math 381 that is 0 for x<0, 1 for x>0) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Nov 8 11:20:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA10105 for freebsd-smp-outgoing; Sun, 8 Nov 1998 11:20:24 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from dingo.cdrom.com (castles209.castles.com [208.214.165.209]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA10100 for ; Sun, 8 Nov 1998 11:20:22 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id LAA03047; Sun, 8 Nov 1998 11:18:19 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199811081918.LAA03047@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Brian C. Grayson" cc: freebsd-smp@FreeBSD.ORG Subject: Re: disk-wait problems/hangs In-reply-to: Your message of "Sat, 07 Nov 1998 23:36:40 CST." <19981107233640.A17996@marvin.ece.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Nov 1998 11:18:18 -0800 From: Mike Smith Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The 'D' state isn't actually very useful; can you add 'l' to your ps args and report the WCHAN value? The latter makes it possible to narrow down where exactly things are waiting... > We're running 3.0-RELEASE on a few dual P-II boxes. > Occasionally, processes will start getting hung in 'D' > (disk-wait, IIRC), even on an otherwise-idle machine. They > never come out, they aren't kill -9'able. Once the system gets > into this state, commands like 'df' and 'ls' are likely to go into > disk-wait. Eventually (on the order of minutes/hours), > something crucial like nfsd, ypbind, or sshd gets stuck in D, > and the machine requires a reboot. > > I can reproducibly force the cascade of D problems by running > an a.out Netscape -- it gets hung after <2 CPU seconds, and > things go downhill quickly. But I believe the problems have > occurred before without the use of any a.out executables. > > Has anyone else seen this? > > Brian > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Nov 8 19:09:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA28997 for freebsd-smp-outgoing; Sun, 8 Nov 1998 19:09:56 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from farm.farm.sperry-sun.com ([32.97.92.188]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA28992 for ; Sun, 8 Nov 1998 19:09:54 -0800 (PST) (envelope-from rich@FreeBSD.org) Received: from rich.farm.sperry-sun.com (rich@rich.farm.sperry-sun.com [10.216.65.2]) by farm.farm.sperry-sun.com (8.9.1/8.9.1) with ESMTP id VAA12808 for ; Sun, 8 Nov 1998 21:09:40 -0600 (CST) (envelope-from rich@FreeBSD.org) Received: (from rich@localhost) by rich.farm.sperry-sun.com (8.9.1/8.9.1) id VAA02033; Sun, 8 Nov 1998 21:08:18 -0600 (CST) (envelope-from rich@rich.farm.sperry-sun.com) Date: Sun, 8 Nov 1998 21:08:18 -0600 (CST) Message-Id: <199811090308.VAA02033@rich.farm.sperry-sun.com> X-Authentication-Warning: rich.farm.sperry-sun.com: rich set sender to rich@rich.farm.sperry-sun.com using -f From: Murphey To: FreeBSD-smp@FreeBSD.ORG Subject: Asus P2B-DS Reply-to: rich@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is anyone here running 3.0-RELEASE on an Asus P2B-DS? I'd like to compare notes if so. Thanks, Rich To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Nov 8 19:55:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA03079 for freebsd-smp-outgoing; Sun, 8 Nov 1998 19:55:49 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from cyclone.waterspout.com (cyclone.waterspout.com [206.230.5.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA03066; Sun, 8 Nov 1998 19:55:46 -0800 (PST) (envelope-from csg@waterspout.com) Received: from tsunami.waterspout.com (tsunami.waterspout.com [199.233.104.138]) by cyclone.waterspout.com (8.9.1/8.9.1) with ESMTP id WAA04540; Sun, 8 Nov 1998 22:55:31 -0500 (EST) Received: from tsunami.waterspout.com (localhost [127.0.0.1]) by tsunami.waterspout.com (8.9.1/8.9.1) with ESMTP id WAA25005; Sun, 8 Nov 1998 22:55:31 -0500 (EST) Message-Id: <199811090355.WAA25005@tsunami.waterspout.com> To: rich@FreeBSD.ORG cc: FreeBSD-smp@FreeBSD.ORG Subject: Re: Asus P2B-DS In-reply-to: Your message of "Sun, 08 Nov 1998 21:08:18 CST." <199811090308.VAA02033@rich.farm.sperry-sun.com> Date: Sun, 08 Nov 1998 22:55:31 -0500 From: "C. Stephen Gunn" Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199811090308.VAA02033@rich.farm.sperry-sun.com>, Murphey writes: >Is anyone here running 3.0-RELEASE on an Asus P2B-DS? > >I'd like to compare notes if so. tesla.physics.purdue.edu is a Dual Pentium II 450 on a P2B-DS. What do you want to know? - Steve -- WaterSpout Communications, Inc. Email: csg@waterspout.com 1291 Cumberland Ave, Suite C Phone: (765) 775-4512 West Lafayette, IN 47906 Fax: (765) 463-7004 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 9 00:49:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA00280 for freebsd-smp-outgoing; Mon, 9 Nov 1998 00:49:04 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA00271; Mon, 9 Nov 1998 00:49:00 -0800 (PST) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id TAA14661; Mon, 9 Nov 1998 19:48:32 +1100 Date: Mon, 9 Nov 1998 19:48:32 +1100 From: Bruce Evans Message-Id: <199811090848.TAA14661@godzilla.zeta.org.au> To: bde@zeta.org.au, peter@netplex.com.au Subject: Re: Dog Sloooow SMP Cc: current@FreeBSD.ORG, jc@irbs.com, mike@smith.net.au, smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> It's only OK for MII's because of various `#if 0's and `#ifdef SMP's >> that prevent non-OK code from running on MII's. > >I think it should be CPU specific, not cpu class specific. The >model-specific-registers are very specific to the Intel family. I'd be a >lot happier if it was 'if (cpu == CPU_686 || cpu == CPU_PII) ...' Of >course, feature tests would be better. 'if (cpu_features & CF_PPRO_MSR)...' >The problem is that there is a 'cpu_feature' already for the CPUID. We >need more general flags than what Intel choose to tell us. FreeBSD should use its own bitmap of capabilities and not test the Intel flags except once to translate them. 32 general flags might even be enough. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 9 01:38:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA05826 for freebsd-smp-outgoing; Mon, 9 Nov 1998 01:38:30 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA05819; Mon, 9 Nov 1998 01:38:26 -0800 (PST) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (haldjas.folklore.ee [172.17.2.1] (may be forged)) by haldjas.folklore.ee (8.8.8/8.8.4) with SMTP id LAA26286; Mon, 9 Nov 1998 11:36:52 +0200 (EET) Date: Mon, 9 Nov 1998 11:36:51 +0200 (EET) From: Narvi To: Bruce Evans cc: peter@netplex.com.au, current@FreeBSD.ORG, jc@irbs.com, mike@smith.net.au, smp@FreeBSD.ORG Subject: Re: Dog Sloooow SMP In-Reply-To: <199811090848.TAA14661@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 9 Nov 1998, Bruce Evans wrote: > >> It's only OK for MII's because of various `#if 0's and `#ifdef SMP's > >> that prevent non-OK code from running on MII's. > > > >I think it should be CPU specific, not cpu class specific. The > >model-specific-registers are very specific to the Intel family. I'd be a > >lot happier if it was 'if (cpu == CPU_686 || cpu == CPU_PII) ...' Of > >course, feature tests would be better. 'if (cpu_features & CF_PPRO_MSR)...' > >The problem is that there is a 'cpu_feature' already for the CPUID. We > >need more general flags than what Intel choose to tell us. > > FreeBSD should use its own bitmap of capabilities and not test the Intel > flags except once to translate them. 32 general flags might even be > enough. > How about 64 for the odd case that K7 actually materialises as promised and people start putting them in dual motherboards? Or will that (SMP support for EV7 like systems) resolved with support for SMP Alpha? > Bruce Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 9 02:22:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA10253 for freebsd-smp-outgoing; Mon, 9 Nov 1998 02:22:52 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA10247; Mon, 9 Nov 1998 02:22:47 -0800 (PST) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id VAA22031; Mon, 9 Nov 1998 21:22:30 +1100 Date: Mon, 9 Nov 1998 21:22:30 +1100 From: Bruce Evans Message-Id: <199811091022.VAA22031@godzilla.zeta.org.au> To: bde@zeta.org.au, narvi@haldjas.folklore.ee Subject: Re: Dog Sloooow SMP Cc: current@FreeBSD.ORG, jc@irbs.com, mike@smith.net.au, peter@netplex.com.au, smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> FreeBSD should use its own bitmap of capabilities and not test the Intel >> flags except once to translate them. 32 general flags might even be >> enough. >> > >How about 64 for the odd case that K7 actually materialises as promised >and people start putting them in dual motherboards? That would be almost twice as slow for CC=gcc. CC=egcs handles 64-bit bit tests better, especially for the low 32 bits. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 9 03:24:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA16514 for freebsd-smp-outgoing; Mon, 9 Nov 1998 03:24:47 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA16501; Mon, 9 Nov 1998 03:24:43 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.1/8.9.1/Spinner) with ESMTP id TAA29164; Mon, 9 Nov 1998 19:21:41 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199811091121.TAA29164@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Bruce Evans cc: narvi@haldjas.folklore.ee, current@FreeBSD.ORG, jc@irbs.com, mike@smith.net.au, smp@FreeBSD.ORG Subject: Re: Dog Sloooow SMP In-reply-to: Your message of "Mon, 09 Nov 1998 21:22:30 +1100." <199811091022.VAA22031@godzilla.zeta.org.au> Date: Mon, 09 Nov 1998 19:21:40 +0800 From: Peter Wemm Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bruce Evans wrote: > >> FreeBSD should use its own bitmap of capabilities and not test the Intel > >> flags except once to translate them. 32 general flags might even be > >> enough. > >> > > > >How about 64 for the odd case that K7 actually materialises as promised > >and people start putting them in dual motherboards? > > That would be almost twice as slow for CC=gcc. CC=egcs handles 64-bit > bit tests better, especially for the low 32 bits. 32 vs. 64 is almost irrelevant.. There's no limit to the number of 32 bit variables that we can use with flags in them, so there's no reason why we'd use a 64 bit variable in the first place. However.. One thing that bugs me is that we presently can optimize out code and tests for a runtime boost when compiled for a specific cpu. eg: if we support 386 cpus, we test for whether we have an invlpg instruction or not - but if we are not compiling with a 386 option then this code and the test for >= 486 goes away. > Bruce Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 9 09:50:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA28981 for freebsd-smp-outgoing; Mon, 9 Nov 1998 09:50:15 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from marvin.ece.utexas.edu (marvin.ece.utexas.edu [128.83.52.151]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA28976 for ; Mon, 9 Nov 1998 09:50:14 -0800 (PST) (envelope-from bgrayson@marvin.ece.utexas.edu) Received: (from bgrayson@localhost) by marvin.ece.utexas.edu (8.8.8/8.8.8) id LAA07044; Mon, 9 Nov 1998 11:49:47 -0600 (CST) Message-ID: <19981109114946.C5782@marvin.ece.utexas.edu> Date: Mon, 9 Nov 1998 11:49:46 -0600 From: "Brian C. Grayson" To: Mike Smith Cc: freebsd-smp@FreeBSD.ORG Subject: Re: disk-wait problems/hangs References: <19981107233640.A17996@marvin.ece.utexas.edu> <199811081918.LAA03047@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: <199811081918.LAA03047@dingo.cdrom.com>; from Mike Smith on Sun, Nov 08, 1998 at 11:18:18AM -0800 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Nov 08, 1998 at 11:18:18AM -0800, Mike Smith wrote: > > The 'D' state isn't actually very useful; can you add 'l' to your ps > args and report the WCHAN value? The latter makes it possible to > narrow down where exactly things are waiting... I started up netscape 4.5, and it got stuck in getblk. df still works, but ls gets stuck in nfsrcv. One nfsiod is stuck in nfsrcv, another in sbwait (both in 'D'), while the other two are nfsidl. All executables are local (this is the FreeBSD master machine), and home directories are mounted from a NetBSD box. I disabled nfsiod/nfs_client via /etc/rc.conf and rebooted. No help -- now the process itself gets hung, in sbwait. I ran a ktrace of netscape when it hangs, which turned out to be pretty disturbing -- the kdump output has garbage characters in it, and not just in the data fields of reads or writes! Anyway, the ktrace and kdump files are available at http://lore.ece.utexas.edu/~bgrayson/freebsd/netscape.kdump.out http://lore.ece.utexas.edu/~bgrayson/freebsd/netscape.ktrace.out Note that the kdump.out file has those garbage characters, so it may do weird stuff to your terminal. I've had much better luck with 3.0-199808xx-BETA (only three or four hangs for no reason in three months of hard work) -- is this still available anywhere via FTP? I'm getting significant pressure to get these machines usable, and may have to revert to that or to NetBSD (which has no SMP (yet)! :( ), if no one is able to help us with this NFS stuff. Brian -- "If I may be allowed a small analogy, Hammers are old & simple, and there are frequently more efficient tools for the job, But I've never met a carpenter who was ashamed to use one." -Steve Kleiser To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 9 12:43:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA18983 for freebsd-smp-outgoing; Mon, 9 Nov 1998 12:43:37 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA18975 for ; Mon, 9 Nov 1998 12:43:34 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id MAA00753; Mon, 9 Nov 1998 12:41:12 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199811092041.MAA00753@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Brian C. Grayson" cc: Mike Smith , freebsd-smp@FreeBSD.ORG Subject: Re: disk-wait problems/hangs In-reply-to: Your message of "Mon, 09 Nov 1998 11:49:46 CST." <19981109114946.C5782@marvin.ece.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 09 Nov 1998 12:41:12 -0800 From: Mike Smith Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Sun, Nov 08, 1998 at 11:18:18AM -0800, Mike Smith wrote: > > > > The 'D' state isn't actually very useful; can you add 'l' to your ps > > args and report the WCHAN value? The latter makes it possible to > > narrow down where exactly things are waiting... > > I started up netscape 4.5, and it got stuck in getblk. df > still works, but ls gets stuck in nfsrcv. One nfsiod is stuck > in nfsrcv, another in sbwait (both in 'D'), while the other two > are nfsidl. All executables are local (this is the FreeBSD > master machine), and home directories are mounted from a NetBSD > box. Can you try this without the NFS mounts? These all look like NFS problems. It'd be interesting to see your results against a more complete NFS server (eg. Solaris, NetApp) as well. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 9 13:07:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA22214 for freebsd-smp-outgoing; Mon, 9 Nov 1998 13:07:24 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from liquid.tpb.net (drum-n-bass.party-animals.com [194.134.94.34]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA22206 for ; Mon, 9 Nov 1998 13:07:22 -0800 (PST) (envelope-from niels@bakker.net) Received: from localhost (niels@localhost) by liquid.tpb.net (8.9.1a/8.8.8/Debian/GNU) with SMTP id WAA02394 for ; Mon, 9 Nov 1998 22:06:40 +0100 Date: Mon, 9 Nov 1998 22:06:40 +0100 (CET) From: N To: FreeBSD-smp@FreeBSD.ORG Subject: Re: Asus P2B-DS In-Reply-To: <199811090308.VAA02033@rich.farm.sperry-sun.com> Message-ID: <981109220448.897A-100000@liquid.tpb.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Quoth Murphey: > Is anyone here running 3.0-RELEASE on an Asus P2B-DS? Yes. Also, I might add, quite successfully (so far) on P2B-LS boards. > I'd like to compare notes if so. What's the problem? The only real problem I encountered was the adding of options FFS_ROOT which made me shoot myself in the foot. (cvsweb is your friend in this case, even though www.freebsd.org experienced massive downtimes throughout right this timeframe.) -- Niels. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 9 14:55:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA02774 for freebsd-smp-outgoing; Mon, 9 Nov 1998 14:55:20 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from l2gdevel.links2go.com (l2gdevel.continuumsi.com [209.6.116.90]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA02769 for ; Mon, 9 Nov 1998 14:55:19 -0800 (PST) (envelope-from awards@links2go.com) From: awards@links2go.com Received: (from root@localhost) by l2gdevel.links2go.com (8.8.5/8.8.5) id RAA20802 for freebsd-smp@freebsd.org; Mon, 9 Nov 1998 17:59:49 -0500 Date: Mon, 9 Nov 1998 17:59:49 -0500 Message-Id: <199811092259.RAA20802@l2gdevel.links2go.com> Subject: Links2Go Key Resource Award To: undisclosed-recipients:; Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Congratulations! Your page: http://www.freebsd.org/~fsmp/SMP/SMP.html has been selected to receive a Links2Go Key Resource award in the FreeBSD topic! The Links2Go Key Resource award is both exclusive and objective. Fewer than one page in one thousand will ever be selected for inclusion. Further, unlike most awards that rely on the subjective opinion of "experts," many of whom have only looked at tens or hundreds of thousands of pages in bestowing their awards, the Links2Go Key Resource award is completely objective and is based on an analysis of millions of web pages. During the course of our analysis, we identify which links are most representative of each of the thousands of topics in Links2Go, based on how actual page authors, like yourself, index and organize links on their pages. In fact, the Key Resource award is so exclusive, even we don't qualify for it (yet ;)! Please visit: http://www.links2go.com/award/FreeBSD to find out more about this award, and to download graphics if you wish to display this award on your page. Once again, congratulations on your award! Links2Go Awards awards@links2go.com P.S. If you are not the author or maintainer of this page, please accept our appologies. We would appreciate it if you would forward this email to the appropriate person. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Nov 10 01:09:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA29410 for freebsd-smp-outgoing; Tue, 10 Nov 1998 01:09:17 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA29401; Tue, 10 Nov 1998 01:09:13 -0800 (PST) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id UAA23868; Tue, 10 Nov 1998 20:08:50 +1100 Date: Tue, 10 Nov 1998 20:08:50 +1100 From: Bruce Evans Message-Id: <199811100908.UAA23868@godzilla.zeta.org.au> To: bde@zeta.org.au, peter@netplex.com.au Subject: Re: Dog Sloooow SMP Cc: current@FreeBSD.ORG, jc@irbs.com, mike@smith.net.au, narvi@haldjas.folklore.ee, smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> >How about 64 for the odd case that K7 actually materialises as promised >> >and people start putting them in dual motherboards? >> >> That would be almost twice as slow for CC=gcc. CC=egcs handles 64-bit >> bit tests better, especially for the low 32 bits. > >32 vs. 64 is almost irrelevant.. There's no limit to the number of 32 bit >variables that we can use with flags in them, so there's no reason why >we'd use a 64 bit variable in the first place. It's easier and potentially faster to keep all the flags in a single (scalar) variable. >However.. One thing that bugs me is that we presently can optimize out >code and tests for a runtime boost when compiled for a specific cpu. eg: >if we support 386 cpus, we test for whether we have an invlpg instruction >or not - but if we are not compiling with a 386 option then this code and >the test for >= 486 goes away. Attempt to keep compile-time options and tests when they make a difference. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Nov 10 01:26:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA00991 for freebsd-smp-outgoing; Tue, 10 Nov 1998 01:26:46 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from dingo.cdrom.com (castles162.castles.com [208.214.165.162]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA00986; Tue, 10 Nov 1998 01:26:44 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id BAA01418; Tue, 10 Nov 1998 01:24:34 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199811100924.BAA01418@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Bruce Evans cc: peter@netplex.com.au, current@FreeBSD.ORG, jc@irbs.com, mike@smith.net.au, narvi@haldjas.folklore.ee, smp@FreeBSD.ORG Subject: Re: Dog Sloooow SMP In-reply-to: Your message of "Tue, 10 Nov 1998 20:08:50 +1100." <199811100908.UAA23868@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Nov 1998 01:24:33 -0800 From: Mike Smith Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >However.. One thing that bugs me is that we presently can optimize out > >code and tests for a runtime boost when compiled for a specific cpu. eg: > >if we support 386 cpus, we test for whether we have an invlpg instruction > >or not - but if we are not compiling with a 386 option then this code and > >the test for >= 486 goes away. > > Attempt to keep compile-time options and tests when they make a difference. It occurred to me that we could probably build a header somewhere full of defines like this: #if defined(CPU_686) && !defined(CPU_586) && !defined.... # define CPU_686_ONLY #endif ... #ifdef CPU_686_ONLY # define CPU_CAP_FOOBAR (1) #else # define CPU_CAP_FOOBAR ((cpu == CPU_686) || (cpu == CPU_PII)) #endif ... of course, you can customise the "slow mode" definition to suit, but this is pretty clean. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Nov 12 14:03:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA28158 for freebsd-smp-outgoing; Thu, 12 Nov 1998 14:03:27 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from bfc.dk ([194.192.110.140]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA28144 for ; Thu, 12 Nov 1998 14:03:19 -0800 (PST) (envelope-from npe@bfc.dk) From: npe@bfc.dk Received: by bfc.dk(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997)) id 412566BA.0078BAFE ; Thu, 12 Nov 1998 22:58:41 +0100 X-Lotus-FromDomain: BFC-DATA@BFC To: smp@FreeBSD.ORG Message-ID: <412566BA.007821E7.00@bfc.dk> Date: Thu, 12 Nov 1998 22:59:37 +0100 Subject: Problems with Compaq Proliant 1600 Dual P2 - 350 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org When booting GENERIC-SMP kernel my system panics with the following : --------------------------------------------- .... avail memory = 258138112 (252088K bytes) panic assign_apic_irq: inconsistent table mp_lock = 00000001; cpuid = 0; lapic.id = 01000000 Debugger("Panic") Stopped at _Debugger+0x35: movb $0,_in_Debugger.98 .... ------------cut--------------------------------- Help ! Regards, Nicolai Petri WM-Data BFC - Denmark -------------------------------------------------- DMESG : Copyright (c) 1992-1998 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-RELEASE #0: Sat Oct 17 17:45:06 GMT 1998 jkh@kickme.freebsd.org:/usr/src/sys/compile/GENERIC Timecounter "i8254" frequency 1193182 Hz cost 3031 ns Timecounter "TSC" frequency 349436359 Hz cost 140 ns CPU: Pentium II (quarter-micron) (349.44-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x651 Stepping=1 Features=0x183fbff> real memory = 16777216 (16384K bytes) avail memory = 13918208 (13592K bytes) eisa0: Probing for devices on the EISA bus Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 vga0: rev 0x45 on pci0.11.0 chip1: rev 0x03 on pci0.13.0 chip2: rev 0x07 on pci0.16.0 chip3: rev 0x02 on pci0.20.0 ide_pci0: rev 0x01 on pci0.20.1 chip4: rev 0x01 int d irq 0 on pci0.20.2 chip5: rev 0x02 on pci0.20.3 Probing for devices on PCI bus 1: tl0: rev 0x10 int a irq 5 on pci1.7.0 tl0: Ethernet address: 00:80:5f:c7:e1:95 tl0: autoneg complete, link status good (half-duplex, 100Mbps) ncr0: rev 0x14 int a irq 9 on pci1.9.0 ncr1: rev 0x14 int b irq 10 on pci1.9.1 chip6: rev 0x03 on pci1.13.0 Probing for devices on PCI bus 2: fxp0: rev 0x05 int a irq 11 on pci2.4.0 fxp0: Ethernet address 00:08:c7:d2:1d:bf fxp1: rev 0x05 int a irq 15 on pci2.5.0 fxp1: Ethernet address 00:08:c7:d2:1d:c0 Probing for devices on PCI bus 3: Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed0 not found at 0x280 fe0 not found at 0x300 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x3bc-0x3c3 irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface psm0 not found at 0x60 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (atapi): , removable, accel, dma, iordis wcd0: 171/4125Kb/sec, 128Kb cache, audio play, 255 volume levels, ejectable tray wcd0: door open, unlocked, lock protected wdc1 not found at 0x170 wt0 not found at 0x300 mcd0 not found at 0x300 matcdc0 not found at 0x230 scd0 not found at 0x230 ie0: unknown board_id: f000 ie0 not found at 0x300 ep0 not found at 0x300 ex0 not found le0 not found at 0x300 lnc0 not found at 0x280 ze0 not found at 0x300 zp0 not found at 0x300 cs0 not found at 0x300 adv0 not found at 0x330 bt0 not found at 0x134 aha0 not found at 0x134 npx0 on motherboard npx0: INT 16 interface Waiting 15 seconds for SCSI devices to settle changing root device to da0s1a da0 at ncr1 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI2 device da0: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4094MB (8386000 512 byte sectors: 255H 63S/T 522C) =========================================================================== ==== MPTable, version 2.0.15 --------------------------------------------------------------------------- ---- MP Floating Pointer Structure: location: BIOS physical address: 0x000f4ff0 signature: '_MP_' length: 16 bytes version: 1.4 checksum: 0xcd mode: Virtual Wire --------------------------------------------------------------------------- ---- MP Config Table Header: physical address: 0x000fc400 signature: 'PCMP' base table length: 436 version: 1.4 checksum: 0x6d OEM ID: 'COMPAQ ' Product ID: 'PROLIANT ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 46 local APIC address: 0xfee00000 extended table length: 76 extended table checksum: 86 --------------------------------------------------------------------------- ---- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 1 0x10 BSP, usable 6 5 1 0x183fbff 0 0x10 AP, usable 6 5 1 0x183fbff -- Bus: Bus ID Type 0 PCI 1 PCI 9 ISA -- I/O APICs: APIC ID Version State Address 8 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# INT active-lo level 1 9:A 8 23 INT active-lo level 1 9:B 8 22 INT active-lo level 1 7:A 8 30 INT active-lo level 1 13:A 8 18 INT active-lo level 1 13:C 8 18 INT active-lo level 1 13:B 8 26 INT active-lo level 1 13:D 8 26 INT active-lo level 1 11:A 8 17 INT active-lo level 1 11:C 8 17 INT active-lo level 1 11:B 8 25 INT active-lo level 1 11:D 8 25 INT active-lo level 1 10:A 8 16 INT active-lo level 1 10:C 8 16 INT active-lo level 1 10:B 8 24 INT active-lo level 1 10:D 8 24 INT active-lo level 0 18:A 8 21 INT active-lo level 0 18:C 8 21 INT active-lo level 0 18:B 8 29 INT active-lo level 0 18:D 8 29 INT active-lo level 0 16:A 8 20 INT active-lo level 0 16:C 8 20 INT active-lo level 0 16:B 8 28 INT active-lo level 0 16:D 8 28 INT active-lo level 0 15:A 8 19 INT active-lo level 0 15:C 8 19 INT active-lo level 0 15:B 8 27 INT active-lo level 0 15:D 8 27 INT active-hi edge 9 1 8 1 INT active-hi edge 9 0 8 2 INT active-hi edge 9 3 8 3 INT active-hi edge 9 4 8 4 INT active-hi edge 9 6 8 6 INT active-hi edge 9 7 8 7 INT active-hi edge 9 8 8 8 INT active-hi edge 9 12 8 12 INT active-lo edge 9 13 8 13 INT active-hi edge 9 14 8 14 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT conforms conforms 9 0 255 0 NMI conforms conforms 9 0 255 1 --------------------------------------------------------------------------- ---- MP Config Extended Table Entries: Extended Table HOSED! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Nov 12 14:08:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA29014 for freebsd-smp-outgoing; Thu, 12 Nov 1998 14:08:14 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from bfc.dk ([194.192.110.140]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA29009 for ; Thu, 12 Nov 1998 14:08:11 -0800 (PST) (envelope-from npe@bfc.dk) From: npe@bfc.dk Received: by bfc.dk(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997)) id 412566BA.0079311D ; Thu, 12 Nov 1998 23:03:44 +0100 X-Lotus-FromDomain: BFC-DATA@BFC To: freebsd-smp@FreeBSD.ORG Message-ID: <412566BA.007919FB.00@bfc.dk> Date: Thu, 12 Nov 1998 23:04:41 +0100 Subject: Panic while booting SMP on a Compaq Proliant 1600 Dual P2 - 350 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org When booting GENERIC-SMP kernel my system panics with the following : --------------------------------------------- .... avail memory = 258138112 (252088K bytes) panic assign_apic_irq: inconsistent table mp_lock = 00000001; cpuid = 0; lapic.id = 01000000 Debugger("Panic") Stopped at _Debugger+0x35: movb $0,_in_Debugger.98 .... ------------cut--------------------------------- Help ! Regards, Nicolai Petri WM-Data BFC - Denmark -------------------------------------------------- DMESG : Copyright (c) 1992-1998 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-RELEASE #0: Sat Oct 17 17:45:06 GMT 1998 jkh@kickme.freebsd.org:/usr/src/sys/compile/GENERIC Timecounter "i8254" frequency 1193182 Hz cost 3031 ns Timecounter "TSC" frequency 349436359 Hz cost 140 ns CPU: Pentium II (quarter-micron) (349.44-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x651 Stepping=1 Features=0x183fbff> real memory = 16777216 (16384K bytes) avail memory = 13918208 (13592K bytes) eisa0: Probing for devices on the EISA bus Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 vga0: rev 0x45 on pci0.11.0 chip1: rev 0x03 on pci0.13.0 chip2: rev 0x07 on pci0.16.0 chip3: rev 0x02 on pci0.20.0 ide_pci0: rev 0x01 on pci0.20.1 chip4: rev 0x01 int d irq 0 on pci0.20.2 chip5: rev 0x02 on pci0.20.3 Probing for devices on PCI bus 1: tl0: rev 0x10 int a irq 5 on pci1.7.0 tl0: Ethernet address: 00:80:5f:c7:e1:95 tl0: autoneg complete, link status good (half-duplex, 100Mbps) ncr0: rev 0x14 int a irq 9 on pci1.9.0 ncr1: rev 0x14 int b irq 10 on pci1.9.1 chip6: rev 0x03 on pci1.13.0 Probing for devices on PCI bus 2: fxp0: rev 0x05 int a irq 11 on pci2.4.0 fxp0: Ethernet address 00:08:c7:d2:1d:bf fxp1: rev 0x05 int a irq 15 on pci2.5.0 fxp1: Ethernet address 00:08:c7:d2:1d:c0 Probing for devices on PCI bus 3: Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed0 not found at 0x280 fe0 not found at 0x300 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x3bc-0x3c3 irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface psm0 not found at 0x60 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (atapi): , removable, accel, dma, iordis wcd0: 171/4125Kb/sec, 128Kb cache, audio play, 255 volume levels, ejectable tray wcd0: door open, unlocked, lock protected wdc1 not found at 0x170 wt0 not found at 0x300 mcd0 not found at 0x300 matcdc0 not found at 0x230 scd0 not found at 0x230 ie0: unknown board_id: f000 ie0 not found at 0x300 ep0 not found at 0x300 ex0 not found le0 not found at 0x300 lnc0 not found at 0x280 ze0 not found at 0x300 zp0 not found at 0x300 cs0 not found at 0x300 adv0 not found at 0x330 bt0 not found at 0x134 aha0 not found at 0x134 npx0 on motherboard npx0: INT 16 interface Waiting 15 seconds for SCSI devices to settle changing root device to da0s1a da0 at ncr1 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI2 device da0: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4094MB (8386000 512 byte sectors: 255H 63S/T 522C) =========================================================================== ==== MPTable, version 2.0.15 --------------------------------------------------------------------------- ---- MP Floating Pointer Structure: location: BIOS physical address: 0x000f4ff0 signature: '_MP_' length: 16 bytes version: 1.4 checksum: 0xcd mode: Virtual Wire --------------------------------------------------------------------------- ---- MP Config Table Header: physical address: 0x000fc400 signature: 'PCMP' base table length: 436 version: 1.4 checksum: 0x6d OEM ID: 'COMPAQ ' Product ID: 'PROLIANT ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 46 local APIC address: 0xfee00000 extended table length: 76 extended table checksum: 86 --------------------------------------------------------------------------- ---- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 1 0x10 BSP, usable 6 5 1 0x183fbff 0 0x10 AP, usable 6 5 1 0x183fbff -- Bus: Bus ID Type 0 PCI 1 PCI 9 ISA -- I/O APICs: APIC ID Version State Address 8 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# INT active-lo level 1 9:A 8 23 INT active-lo level 1 9:B 8 22 INT active-lo level 1 7:A 8 30 INT active-lo level 1 13:A 8 18 INT active-lo level 1 13:C 8 18 INT active-lo level 1 13:B 8 26 INT active-lo level 1 13:D 8 26 INT active-lo level 1 11:A 8 17 INT active-lo level 1 11:C 8 17 INT active-lo level 1 11:B 8 25 INT active-lo level 1 11:D 8 25 INT active-lo level 1 10:A 8 16 INT active-lo level 1 10:C 8 16 INT active-lo level 1 10:B 8 24 INT active-lo level 1 10:D 8 24 INT active-lo level 0 18:A 8 21 INT active-lo level 0 18:C 8 21 INT active-lo level 0 18:B 8 29 INT active-lo level 0 18:D 8 29 INT active-lo level 0 16:A 8 20 INT active-lo level 0 16:C 8 20 INT active-lo level 0 16:B 8 28 INT active-lo level 0 16:D 8 28 INT active-lo level 0 15:A 8 19 INT active-lo level 0 15:C 8 19 INT active-lo level 0 15:B 8 27 INT active-lo level 0 15:D 8 27 INT active-hi edge 9 1 8 1 INT active-hi edge 9 0 8 2 INT active-hi edge 9 3 8 3 INT active-hi edge 9 4 8 4 INT active-hi edge 9 6 8 6 INT active-hi edge 9 7 8 7 INT active-hi edge 9 8 8 8 INT active-hi edge 9 12 8 12 INT active-lo edge 9 13 8 13 INT active-hi edge 9 14 8 14 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT conforms conforms 9 0 255 0 NMI conforms conforms 9 0 255 1 --------------------------------------------------------------------------- ---- MP Config Extended Table Entries: Extended Table HOSED! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Nov 13 07:43:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA21574 for freebsd-smp-outgoing; Fri, 13 Nov 1998 07:43:31 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from midten.fast.no (midten.fast.no [195.139.251.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA21569 for ; Fri, 13 Nov 1998 07:43:29 -0800 (PST) (envelope-from tegge@fast.no) Received: from fast.no (IDENT:tegge@midten.fast.no [195.139.251.11]) by midten.fast.no (8.9.1/8.9.1) with ESMTP id QAA01578; Fri, 13 Nov 1998 16:42:33 +0100 (CET) Message-Id: <199811131542.QAA01578@midten.fast.no> To: npe@bfc.dk Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Panic while booting SMP on a Compaq Proliant 1600 Dual P2 - 350 From: Tor.Egge@fast.no In-Reply-To: Your message of "Thu, 12 Nov 1998 23:04:41 +0100" References: <412566BA.007919FB.00@bfc.dk> X-Mailer: Mew version 1.70 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 13 Nov 1998 16:42:32 +0100 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > When booting GENERIC-SMP kernel my system panics with the following : > --------------------------------------------- > .... > avail memory = 258138112 (252088K bytes) > panic assign_apic_irq: inconsistent table > mp_lock = 00000001; cpuid = 0; lapic.id = 01000000 > Debugger("Panic") > Stopped at _Debugger+0x35: movb $0,_in_Debugger.98 > .... Your mp table describes 25 interrupt pins, but FreeBSD currently only supports 24 active interrupt pins when using APIC_IO. The panic message could have been better. Some possible workarounds: - ignore some of the entries in the mp table, e.g. based upon a pci bus scan. - map several interrupt pins to the same interrupt. low level interrupt routines must know how to block several iterrupt sources at once. - let each bit in _cpl block an interrupt class instead of a single interrupt. If any of the classes associated with an interrupt is blocked, the interrupt is blocked. - eliminate spl*() and _cpl. - Tor Egge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message