From owner-freebsd-smp Mon Aug 4 12:01:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA20545 for smp-outgoing; Mon, 4 Aug 1997 12:01:11 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA20524; Mon, 4 Aug 1997 12:01:03 -0700 (PDT) From: Steve Passe Received: (from fsmp@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id LAA02222; Mon, 4 Aug 1997 11:59:20 -0700 (PDT) Date: Mon, 4 Aug 1997 11:59:20 -0700 (PDT) Message-Id: <199708041859.LAA02222@freefall.freebsd.org> To: steve@visint.co.uk, fsmp@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: docs/3951 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: Missing smp(4) manpage. State-Changed-From-To: open-analyzed State-Changed-By: fsmp State-Changed-When: Mon Aug 4 11:56:50 PDT 1997 State-Changed-Why: Assigned to responsible party. Responsible-Changed-From-To: freebsd-bugs->smp@freebsd.org Responsible-Changed-By: fsmp Responsible-Changed-When: Mon Aug 4 11:56:50 PDT 1997 Responsible-Changed-Why: From owner-freebsd-smp Mon Aug 4 14:06:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA27755 for smp-outgoing; Mon, 4 Aug 1997 14:06:37 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA27735; Mon, 4 Aug 1997 14:06:25 -0700 (PDT) From: Steve Passe Received: (from fsmp@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id OAA02965; Mon, 4 Aug 1997 14:04:41 -0700 (PDT) Date: Mon, 4 Aug 1997 14:04:41 -0700 (PDT) Message-Id: <199708042104.OAA02965@freefall.freebsd.org> To: steve@visint.co.uk, fsmp@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: docs/3951 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: Missing smp(4) manpage. State-Changed-From-To: analyzed-closed State-Changed-By: fsmp State-Changed-When: Mon Aug 4 14:02:33 PDT 1997 State-Changed-Why: Added the missing smp(4) manpage. From owner-freebsd-smp Mon Aug 4 15:32:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA02131 for smp-outgoing; Mon, 4 Aug 1997 15:32:34 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA02125 for ; Mon, 4 Aug 1997 15:32:25 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id QAA11808 for ; Mon, 4 Aug 1997 16:32:12 -0600 (MDT) Message-Id: <199708042232.QAA11808@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: smp@freebsd.org Subject: HEADS UP: silo overflows Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Aug 1997 16:32:12 -0600 Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I just committed code that should reduce the occurrance of silo overflows to at least the pre-970729 levels (ie b4 I removed the TEST_LOPRIO code). Let me know if this noticably helps or hurts things as reguards silo overflows or INTerrupt latency in general. Thanx to dave adkins for doing the grunt work to track this bug down! -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Mon Aug 4 16:05:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA04270 for smp-outgoing; Mon, 4 Aug 1997 16:05:35 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA04241 for ; Mon, 4 Aug 1997 16:05:14 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id RAA12088 for ; Mon, 4 Aug 1997 17:03:41 -0600 (MDT) Message-Id: <199708042303.RAA12088@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: smp@freebsd.org Subject: HEADS UP: send-pr reports. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Aug 1997 17:03:40 -0600 Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I just closed 3 of the 4 reports concerning SMP in the GNATS database: kern/3723 docs/3951 kern/3491 The 4th, kern/3835, is still being analyzed. I found these 4 by scanning the subject lines (found in the periodic summarys). If you have filed a formal PR other than 1 of the above 4 please bring it to my attention. When using send-pr, always remember to include the token "SMP" in the subject line to insure it catches our attention. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Mon Aug 4 17:31:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA08370 for smp-outgoing; Mon, 4 Aug 1997 17:31:44 -0700 (PDT) Received: from egyptian.microxp.com (egyptian.microxp.com [207.227.65.14]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA08364 for ; Mon, 4 Aug 1997 17:31:38 -0700 (PDT) Received: from localhost (randy@localhost) by egyptian.microxp.com (8.8.6/8.8.5) with SMTP id TAA03078 for ; Mon, 4 Aug 1997 19:37:19 -0500 (CDT) Date: Mon, 4 Aug 1997 19:37:19 -0500 (CDT) From: Randall D DuCharme To: smp@freebsd.org Subject: Re: HEADS UP (silo overflow problem) fixed! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk All is much better on my machines! :) --- Randall D DuCharme Systems Engineer Novell, Microsoft, and UNIX Networking Support Computer Specialists BSDI Internet Success Partners 414-253-9998 414-253-9919 (fax) BSD/OS Authorized Resellers From owner-freebsd-smp Tue Aug 5 13:43:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA03948 for smp-outgoing; Tue, 5 Aug 1997 13:43:21 -0700 (PDT) Received: from lamb.sas.com (daemon@lamb.sas.com [192.35.83.8]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA03939 for ; Tue, 5 Aug 1997 13:43:14 -0700 (PDT) Received: from mozart by lamb.sas.com (5.65c/SAS/Gateway/01-23-95) id AA22419; Tue, 5 Aug 1997 16:43:05 -0400 Received: from iluvatar.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA08319; Tue, 5 Aug 1997 16:42:56 -0400 From: "John W. DeBoskey" Received: by iluvatar.unx.sas.com (5.65c/SAS/Generic 9.01/3-26-93) id AA16914; Tue, 5 Aug 1997 16:42:56 -0400 Message-Id: <199708052042.AA16914@iluvatar.unx.sas.com> Subject: Boot failure - 3.0-970731-SNAP To: freebsd-smp@freebsd.org Date: Tue, 5 Aug 1997 16:42:55 -0400 (EDT) Cc: jwd@unx.sas.com (John W. DeBoskey) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I've just installed 3.0-970731-SNAP on a Dell PowerEdge 6100/200 server. This is a 4-way PPro machine. After I've built an SMP kernel, when I boot it, it freezes after printing out the following info about memory: real memory = 67108864 (65536K bytes) avail memory = 63619072 (62128K bytes) The GENERIC kernel boots up just fine. (it's been about 4 months since I last had a SMP kernel running on this machine). The following is the output of 'mptable -dmesg' from the GENERIC kernel. Note that some of the dmesg info is lost due to the number of probe msgs being printed out for the PCI bus. Is there an easy way to expand the buffer space used by dmesg? (or get rid of the msg) Any hints on where to go look are greatly appreciated. Thanks for any info, John =============================================================================== MPTable, version 2.0.13 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f75a0 signature: '_MP_' length: 16 bytes version: 1.4 checksum: 0x6c mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000f75b0 signature: 'PCMP' base table length: 292 version: 1.4 checksum: 0xe3 OEM ID: 'INTEL ' Product ID: 'ALDER ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 25 local APIC address: 0xfec08000 extended table length: 240 extended table checksum: 87 ------------------------------------------------------------------------------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 0 0x11 BSP, usable 6 1 9 0xfbff 4 0x11 AP, usable 6 1 9 0xfbff 1 0x11 AP, usable 6 1 9 0xfbff 2 0x11 AP, usable 6 1 9 0xfbff -- Bus: Bus ID Type 0 PCI 1 PCI 18 EISA -- I/O APICs: APIC ID Version State Address 14 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# INT active-hi edge 18 1 14 1 INT active-hi edge 18 0 14 2 INT active-hi edge 18 3 14 3 INT active-hi edge 18 4 14 4 INT active-hi edge 18 5 14 5 INT active-hi edge 18 6 14 6 INT active-hi edge 18 7 14 7 INT active-hi edge 18 8 14 8 INT active-hi edge 18 9 14 9 INT active-hi level 18 10 14 10 INT active-hi level 18 11 14 11 INT active-hi edge 18 12 14 12 INT active-hi edge 18 13 14 13 INT active-hi edge 18 14 14 14 INT active-hi edge 18 15 14 15 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT active-hi edge 18 0 255 0 NMI active-hi edge 0 0:A 255 1 ------------------------------------------------------------------------------- MP Config Extended Table Entries: -- bus ID: 0 address type: memory address address base: 0xa0000 address range: 0x20000 -- bus ID: 0 address type: prefetch address address base: 0xfc300000 address range: 0x2000000 -- bus ID: 0 address type: memory address address base: 0xfe300000 address range: 0x800000 -- bus ID: 0 address type: I/O address address base: 0xf000 address range: 0x1000 -- bus ID: 1 address type: prefetch address address base: 0xfc100000 address range: 0x100000 -- bus ID: 1 address type: memory address address base: 0xfc200000 address range: 0x100000 -- bus ID: 1 address type: I/O address address base: 0xe000 address range: 0x1000 -- bus ID: 0 address type: memory address address base: 0x80000000 address range: 0x7c100000 -- bus ID: 0 address type: memory address address base: 0xfeb00000 address range: 0x1500000 -- bus ID: 0 address type: I/O address address base: 0x0 address range: 0xe000 -- bus ID: 18 bus info: 0x01 parent bus ID: 0-- bus ID: 0 address modifier: add predefined range: 0x00000000-- bus ID: 0 address modifier: add predefined range: 0x00000001-- bus ID: 1 address modifier: subtract predefined range: 0x00000000-- bus ID: 1 address modifier: subtract predefined range: 0x00000001 ------------------------------------------------------------------------------- # SMP kernel config file options: # Required: options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Useful: #options SMP_AUTOSTART # start the additional CPUs during boot # Optional (built-in defaults will work in most cases): #options NCPU=4 # number of CPUs #options NBUS=3 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs ------------------------------------------------------------------------------- dmesg output: 61: Probing for devices on PCI bus 62: Probing for devices on PCI bus 63: Probing for devices on PCI bus 64: Probing for devices on PCI bus 65: Probing for devices on PCI bus 66: Probing for devices on PCI bus 67: Probing for devices on PCI bus 68: Probing for devices on PCI bus 69: Probing for devices on PCI bus 70: Probing for devices on PCI bus 71: Probing for devices on PCI bus 72: Probing for devices on PCI bus 73: Probing for devices on PCI bus 74: Probing for devices on PCI bus 75: Probing for devices on PCI bus 76: Probing for devices on PCI bus 77: Probing for devices on PCI bus 78: Probing for devices on PCI bus 79: Probing for devices on PCI bus 80: Probing for devices on PCI bus 81: Probing for devices on PCI bus 82: Probing for devices on PCI bus 83: Probing for devices on PCI bus 84: Probing for devices on PCI bus 85: Probing for devices on PCI bus 86: Probing for devices on PCI bus 87: Probing for devices on PCI bus 88: Probing for devices on PCI bus 89: Probing for devices on PCI bus 90: Probing for devices on PCI bus 91: Probing for devices on PCI bus 92: Probing for devices on PCI bus 93: Probing for devices on PCI bus 94: Probing for devices on PCI bus 95: Probing for devices on PCI bus 96: Probing for devices on PCI bus 97: Probing for devices on PCI bus 98: Probing for devices on PCI bus 99: Probing for devices on PCI bus 100: Probing for devices on PCI bus 101: Probing for devices on PCI bus 102: Probing for devices on PCI bus 103: Probing for devices on PCI bus 104: Probing for devices on PCI bus 105: Probing for devices on PCI bus 106: Probing for devices on PCI bus 107: Probing for devices on PCI bus 108: Probing for devices on PCI bus 109: Probing for devices on PCI bus 110: Probing for devices on PCI bus 111: Probing for devices on PCI bus 112: Probing for devices on PCI bus 113: Probing for devices on PCI bus 114: Probing for devices on PCI bus 115: Probing for devices on PCI bus 116: Probing for devices on PCI bus 117: Probing for devices on PCI bus 118: Probing for devices on PCI bus 119: Probing for devices on PCI bus 120: Probing for devices on PCI bus 121: Probing for devices on PCI bus 122: Probing for devices on PCI bus 123: Probing for devices on PCI bus 124: Probing for devices on PCI bus 125: Probing for devices on PCI bus 126: Probing for devices on PCI bus 127: Probing for devices on PCI bus 128: Probing for devices on PCI bus 129: Probing for devices on PCI bus 130: Probing for devices on PCI bus 131: Probing for devices on PCI bus 132: Probing for devices on PCI bus 133: Probing for devices on PCI bus 134: Probing for devices on PCI bus 135: Probing for devices on PCI bus 136: Probing for devices on PCI bus 137: Probing for devices on PCI bus 138: Probing for devices on PCI bus 139: Probing for devices on PCI bus 140: Probing for devices on PCI bus 141: Probing for devices on PCI bus 142: Probing for devices on PCI bus 143: Probing for devices on PCI bus 144: Probing for devices on PCI bus 145: Probing for devices on PCI bus 146: Probing for devices on PCI bus 147: Probing for devices on PCI bus 148: Probing for devices on PCI bus 149: Probing for devices on PCI bus 150: Probing for devices on PCI bus 151: Probing for devices on PCI bus 152: Probing for devices on PCI bus 153: Probing for devices on PCI bus 154: Probing for devices on PCI bus 155: Probing for devices on PCI bus 156: Probing for devices on PCI bus 157: Probing for devices on PCI bus 158: Probing for devices on PCI bus 159: Probing for devices on PCI bus 160: Probing for devices on PCI bus 161: Probing for devices on PCI bus 162: Probing for devices on PCI bus 163: Probing for devices on PCI bus 164: Probing for devices on PCI bus 165: Probing for devices on PCI bus 166: Probing for devices on PCI bus 167: Probing for devices on PCI bus 168: Probing for devices on PCI bus 169: Probing for devices on PCI bus 170: Probing for devices on PCI bus 171: Probing for devices on PCI bus 172: Probing for devices on PCI bus 173: Probing for devices on PCI bus 174: Probing for devices on PCI bus 175: Probing for devices on PCI bus 176: Probing for devices on PCI bus 177: Probing for devices on PCI bus 178: Probing for devices on PCI bus 179: Probing for devices on PCI bus 180: Probing for devices on PCI bus 181: Probing for devices on PCI bus 182: Probing for devices on PCI bus 183: Probing for devices on PCI bus 184: Probing for devices on PCI bus 185: Probing for devices on PCI bus 186: Probing for devices on PCI bus 187: Probing for devices on PCI bus 188: Probing for devices on PCI bus 189: Probing for devices on PCI bus 190: Probing for devices on PCI bus 191: Probing for devices on PCI bus 192: Probing for devices on PCI bus 193: Probing for devices on PCI bus 194: Probing for devices on PCI bus 195: Probing for devices on PCI bus 196: Probing for devices on PCI bus 197: Probing for devices on PCI bus 198: Probing for devices on PCI bus 199: Probing for devices on PCI bus 200: Probing for devices on PCI bus 201: Probing for devices on PCI bus 202: Probing for devices on PCI bus 203: Probing for devices on PCI bus 204: Probing for devices on PCI bus 205: Probing for devices on PCI bus 206: Probing for devices on PCI bus 207: Probing for devices on PCI bus 208: Probing for devices on PCI bus 209: Probing for devices on PCI bus 210: Probing for devices on PCI bus 211: Probing for devices on PCI bus 212: Probing for devices on PCI bus 213: Probing for devices on PCI bus 214: Probing for devices on PCI bus 215: Probing for devices on PCI bus 216: Probing for devices on PCI bus 217: Probing for devices on PCI bus 218: Probing for devices on PCI bus 219: Probing for devices on PCI bus 220: Probing for devices on PCI bus 221: Probing for devices on PCI bus 222: Probing for devices on PCI bus 223: Probing for devices on PCI bus 224: Probing for devices on PCI bus 225: Probing for devices on PCI bus 226: Probing for devices on PCI bus 227: Probing for devices on PCI bus 228: Probing for devices on PCI bus 229: Probing for devices on PCI bus 230: Probing for devices on PCI bus 231: Probing for devices on PCI bus 232: Probing for devices on PCI bus 233: Probing for devices on PCI bus 234: Probing for devices on PCI bus 235: Probing for devices on PCI bus 236: Probing for devices on PCI bus 237: Probing for devices on PCI bus 238: Probing for devices on PCI bus 239: Probing for devices on PCI bus 240: Probing for devices on PCI bus 241: Probing for devices on PCI bus 242: Probing for devices on PCI bus 243: Probing for devices on PCI bus 244: Probing for devices on PCI bus 245: Probing for devices on PCI bus 246: Probing for devices on PCI bus 247: Probing for devices on PCI bus 248: Probing for devices on PCI bus 249: Probing for devices on PCI bus 250: Probing for devices on PCI bus 251: Probing for devices on PCI bus 252: Probing for devices on PCI bus 253: Probing for devices on PCI bus 254: Probing for devices on PCI bus 255: 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 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2: disabled, not probed. sio3: disabled, not probed. lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface lpt1 at 0x378-0x37f on isa lpt1 not probed due to I/O address conflict with lpt0 at 0x378 mse0 not found at 0x23c psm0: disabled, not probed. fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in wdc0 not found at 0x1f0 wdc1 not found at 0x170 bt0 not found at 0x330 uha0 not found at 0x330 aha0 not found at 0x330 aic0 not found at 0x340 nca0 not found at 0x1f88 nca1 not found at 0x350 sea0 not found at 0xffff 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 npx0 on motherboard npx0: INT 16 interface apm0: disabled, not probed. changing root device to sd0a =============================================================================== -- jwd@unx.sas.com (w) John W. De Boskey (919) 677-8000 x6915 From owner-freebsd-smp Wed Aug 6 00:21:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA05387 for smp-outgoing; Wed, 6 Aug 1997 00:21:57 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA05381 for ; Wed, 6 Aug 1997 00:21:53 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id BAA18964; Wed, 6 Aug 1997 01:21:45 -0600 (MDT) Message-Id: <199708060721.BAA18964@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: "John W. DeBoskey" cc: freebsd-smp@FreeBSD.ORG Subject: Re: Boot failure - 3.0-970731-SNAP In-reply-to: Your message of "Tue, 05 Aug 1997 16:42:55 EDT." <199708052042.AA16914@iluvatar.unx.sas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Aug 1997 01:21:45 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > I've just installed 3.0-970731-SNAP on a Dell PowerEdge 6100/200 > server. This is a 4-way PPro machine. After I've built an SMP > kernel, when I boot it, it freezes after printing out the following > info about memory: > > real memory = 67108864 (65536K bytes) > avail memory = 63619072 (62128K bytes) this is right befor propbing for SMP hardware. --- > The GENERIC kernel boots up just fine. (it's been about 4 months > since I last had a SMP kernel running on this machine). did you install the COMPLETE SNAP, or just the kernel src? did anything change: BIOS settings, hardware, SMP kernel config file ??? can you boot a kernel built with SMP-GENERIC? -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Aug 6 14:15:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA20324 for smp-outgoing; Wed, 6 Aug 1997 14:15:34 -0700 (PDT) Received: from lamb.sas.com (uucp@lamb.sas.com [192.35.83.8]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA20315 for ; Wed, 6 Aug 1997 14:15:25 -0700 (PDT) Received: from mozart by lamb.sas.com (5.65c/SAS/Gateway/01-23-95) id AA17896; Wed, 6 Aug 1997 17:15:17 -0400 Received: from iluvatar.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA06414; Wed, 6 Aug 1997 17:14:53 -0400 From: "John W. DeBoskey" Received: by iluvatar.unx.sas.com (5.65c/SAS/Generic 9.01/3-26-93) id AA21265; Wed, 6 Aug 1997 17:14:52 -0400 Message-Id: <199708062114.AA21265@iluvatar.unx.sas.com> Subject: Re: Boot failure - 3.0-970731-SNAP To: smp@csn.net (Steve Passe) Date: Wed, 6 Aug 1997 17:14:51 -0400 (EDT) Cc: freebsd-smp@freebsd.org In-Reply-To: <199708060721.BAA18964@Ilsa.StevesCafe.com> from "Steve Passe" at Aug 6, 97 01:21:45 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Your questions, in order: 1. Yes, a complete install from scratch was done of all srcs. 2. No, I did not change the kernel config from my previous settings. No, the hardware has not changed (to the absolute best of my knowlege). 3. I built the SMP-GENERIC kernel and it fails in an identical fashion. I increased MSG_BSIZE used by the kernel and dmesg. here's the info that was lost from dmesg before: Why does the code think I have 255 pci busses? Also, this is similar to a problem I had with another DELL system that had more than 24 interupt levels. The system seemed to know the problem existed, but the panic call wasn't printing out the error msg for some reason. Thanks, John Copyright (c) 1992-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-970731-SNAP #0: Wed Aug 6 12:05:02 EDT 1997 jwd@bb01.pc.sas.com:/usr/src/sys/compile/ONEWAY CPU: Pentium Pro (198.95-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping=9 Features=0xfbff real memory = 67108864 (65536K bytes) avail memory = 63643648 (62152K bytes) eisa0: Probing for devices on the EISA bus Probing for devices on PCI bus 0: fxp0: rev 0x02 int a irq 10 on pci0.11.0 fxp0: Ethernet address 00:a0:c9:69:d4:de vga0: rev 0x01 int a irq 11 on pci0.12.0 chip0: rev 0x15 on pci0.14.0 chip2: rev 0x05 on pci0.20.0 chip3: rev 0x06 on pci0.25.0 chip4: rev 0x06 on pci0.26.0 Probing for devices on PCI bus 1: ahc0: rev 0x00 int a irq 10 on pci1.10.0 ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs ahc0: waiting for scsi devices to settle scbus0 at ahc0 bus 0 sd0 at scbus0 target 0 lun 0 sd0: type 0 fixed SCSI 2 sd0: Direct-Access 2061MB (4222640 512 byte sectors) ahc1: rev 0x00 int a irq 11 on pci1.11.0 ahc1: Using left over BIOS settings ahc1: aic7880 Wide Channel, SCSI Id=7, 16 SCBs ahc1: waiting for scsi devices to settle scbus1 at ahc1 bus 0 ahc2: rev 0x00 int a irq 10 on pci1.12.0 ahc2: Using left over BIOS settings ahc2: aic7880 Wide Channel, SCSI Id=7, 16 SCBs ahc2: waiting for scsi devices to settle scbus2 at ahc2 bus 0 Probing for devices on PCI bus 2: Probing for devices on PCI bus 3: Probing for devices on PCI bus 4: Probing for devices on PCI bus 5: ... Probing for devices on PCI bus 254: Probing for devices on PCI bus 255: Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface psm0 at 0x60-0x64 irq 12 on motherboard psm0: device ID 0 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in bt0 not found at 0x330 uha0 not found at 0x330 aha0 not found at 0x330 aic0 not found at 0x340 nca0 not found at 0x1f88 nca1 not found at 0x350 sea0 not found npx0 on motherboard npx0: INT 16 interface changing root device to sd0a > > Hi, > > > I've just installed 3.0-970731-SNAP on a Dell PowerEdge 6100/200 > > server. This is a 4-way PPro machine. After I've built an SMP > > kernel, when I boot it, it freezes after printing out the following > > info about memory: > > > > real memory = 67108864 (65536K bytes) > > avail memory = 63619072 (62128K bytes) > > this is right befor propbing for SMP hardware. > > --- > > The GENERIC kernel boots up just fine. (it's been about 4 months > > since I last had a SMP kernel running on this machine). > > did you install the COMPLETE SNAP, or just the kernel src? > > did anything change: BIOS settings, hardware, SMP kernel config file ??? > > can you boot a kernel built with SMP-GENERIC? > > -- > Steve Passe | powered by > smp@csn.net | Symmetric MultiProcessor FreeBSD > > > -- jwd@unx.sas.com (w) John W. De Boskey (919) 677-8000 x6915 jwd@baggins.ral.nc.us (h) (919) 781-0607 From owner-freebsd-smp Wed Aug 6 19:33:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA10800 for smp-outgoing; Wed, 6 Aug 1997 19:33:26 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA10785 for ; Wed, 6 Aug 1997 19:33:06 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id UAA22112; Wed, 6 Aug 1997 20:32:22 -0600 (MDT) Message-Id: <199708070232.UAA22112@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: "John W. DeBoskey" cc: freebsd-smp@freebsd.org Subject: Re: Boot failure - 3.0-970731-SNAP In-reply-to: Your message of "Wed, 06 Aug 1997 17:14:51 EDT." <199708062114.AA21265@iluvatar.unx.sas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Aug 1997 20:32:22 -0600 Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, First try a kernel with NEW_STRATEGY undefed in i386/include/samptests.h. If that fails uncomment the SMP_TIMER_NC define as well. Boot verbose and look for all "SMP" andd "APIC_IO" comments in the boot mesg. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Thu Aug 7 16:08:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA06033 for smp-outgoing; Thu, 7 Aug 1997 16:08:44 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA06015; Thu, 7 Aug 1997 16:08:33 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id RAA25847; Thu, 7 Aug 1997 17:08:17 -0600 (MDT) Message-Id: <199708072308.RAA25847@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: smp@freebsd.org cc: current@freebsd.org Subject: HEADS UP: programming the SMP kernel Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Aug 1997 17:08:17 -0600 Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, This posting describes important issues for the ongoing coding effort of the SMP kernel. If you expect to be participating in this effort, or maintain kernel code that may be touched by it (every major sub-system: VFS, VM, net, etc.) then you should at least monitor this thread. Please trim 'current@freebsd.org' from replys, I want to keep the traffic limited to the smp list, both to eliminate redundancy and to spare those in current with no interest in it. ----------------------------------------------------------------------------- We need to agree on the set of primatives available for coding SMP specific kernel code. Along with this we need a concise document describing the dos and donts of SMP conforming code. --- The lock primitives: It is expected that the lite2 locks will be the primary locking mechanism for SMP. A description can be found in: http://www.freebsd.org/~fsmp/SMP/Locking.html The simplelock functions are implimented and working, but the higher level lock manager cannot yet be enabled. It is expected that this will be fixed by next week. --- Deadlock management: I am leaning towards deadlock prevention, using the "resource ordering method", as oppossed to deadlock detection or avoidance. In the "resource ordering method" all resources are uniquely ordered in ascending order. A process can only compete for resources higher in precedence than the highest it currently holds. This prevents 'circular wait' or 'deadly embrace' deadlocks. Its good points are simplicity and reliability. Its bad points are the enforced discipline in writting code, ie a fair amount of work will be necessary to produce the properly ordered list. --- The existing spl code: We will most likely have to introduce some form of queueing mutex to order the access of CPUs inside the kernel. This is more or less the equivilant of spl/cpl in the UP kernel. spl is ineffective for SMP and redundant in purpose to mutexs for the SMP case. Stated another way, SMP mutexs make spl obsolete. So the issue before the house is how to accommidate both in one source tree. The 'proper' method is probably to eliminate spl entirely for both UP and SMP, replacing it with a system of mutex calls. There would probably be minor differences in the coding for each(UP & SMP), but that detail would be localized to the implimentation file for mutex itself. I know this one is a biggie, and will probaly generate a lot of comment. But its the gate we stand at, and its time to enter... -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Fri Aug 8 05:09:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA10114 for smp-outgoing; Fri, 8 Aug 1997 05:09:07 -0700 (PDT) Received: from lamb.sas.com (daemon@lamb.sas.com [192.35.83.8]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id FAA10107; Fri, 8 Aug 1997 05:09:03 -0700 (PDT) Received: from mozart by lamb.sas.com (5.65c/SAS/Gateway/01-23-95) id AA27523; Fri, 8 Aug 1997 08:08:59 -0400 Received: from iluvatar.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA10651; Fri, 8 Aug 1997 08:08:51 -0400 From: "John W. DeBoskey" Received: by iluvatar.unx.sas.com (5.65c/SAS/Generic 9.01/3-26-93) id AA04989; Fri, 8 Aug 1997 08:08:50 -0400 Message-Id: <199708081208.AA04989@iluvatar.unx.sas.com> Subject: scsi time-out & lockup under smp To: freebsd-current@freebsd.org, freebsd-smp@freebsd.org Date: Fri, 8 Aug 1997 08:08:50 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, I'm wondering if anyone might have some information relating to the following problem. I have the 3.0-970731-SNAP installed on a Dell PowerEdge 6100/200, four processor machine. The problem occurs on either of the two aic7880 onboard scsi devices, or a 2940 adapter board, when in multi-proccessor mode. Anywhere from 5 to 60 minutes after booting the machine, it freezes with the following messages on the console: sd0: SCB 0x1 - timed out in command pahse, SCSISIGI == 0x86 SEQADDR = 0x8c SCSISEQ = 0x12 SSTAT0 = 0x7 SSTAT1 = 0x3 sd0: abort message in message buffer sd0: SCB 1 - Abort Completed. sd0: no longer in timeout sd0: SCB 0x1 - timed our while idle, LASTPHASE == 0x1, SCSISIGI = 0x0 SEQADDR = 0xb SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0x2 sd0: Queueing an Abort SCB It only seems to occur when I start to initiate heavy disk io. It does not happen in the uni-proccesor situation. The complete output from dmesg is appended to this mail. If anyone can help me track this down, I'd really appreciate it. Thanks, John Copyright (c) 1992-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-970731-SNAP #0: Thu Aug 7 12:18:00 EDT 1997 root@bb01.pc.sas.com:/usr/src/sys/compile/ONEWAY CPU: Pentium Pro (198.95-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping=9 Features=0xfbff real memory = 67108864 (65536K bytes) avail memory = 63643648 (62152K bytes) eisa0: Probing for devices on the EISA bus Probing for devices on PCI bus 0: fxp0: rev 0x02 int a irq 10 on pci0.11.0 fxp0: Ethernet address 00:a0:c9:69:d4:de vga0: rev 0x01 int a irq 11 on pci0.12.0 chip0: rev 0x15 on pci0.14.0 chip2: rev 0x05 on pci0.20.0 chip3: rev 0x06 on pci0.25.0 chip4: rev 0x06 on pci0.26.0 Probing for devices on PCI bus 1: ahc0: rev 0x00 int a irq 10 on pci1.10.0 ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs ahc0: waiting for scsi devices to settle scbus0 at ahc0 bus 0 sd0 at scbus0 target 0 lun 0 sd0: type 0 fixed SCSI 2 sd0: Direct-Access 2061MB (4222640 512 byte sectors) ahc1: rev 0x00 int a irq 11 on pci1.11.0 ahc1: aic7880 Wide Channel, SCSI Id=7, 16 SCBs ahc1: Host Adapter Bios disabled. Using default SCSI device parameters ahc1: waiting for scsi devices to settle scbus1 at ahc1 bus 0 ahc2: rev 0x00 int a irq 10 on pci1.12.0 ahc2: aic7880 Wide Channel, SCSI Id=7, 16 SCBs ahc2: Host Adapter Bios disabled. Using default SCSI device parameters ahc2: waiting for scsi devices to settle scbus2 at ahc2 bus 0 Probing for devices on PCI bus 2: Probing for devices on PCI bus 3: Probing for devices on PCI bus 4: Probing for devices on PCI bus 5: Probing for devices on PCI bus 6: Probing for devices on PCI bus 7: Probing for devices on PCI bus 8: Probing for devices on PCI bus 9: Probing for devices on PCI bus 10: Probing for devices on PCI bus 11: Probing for devices on PCI bus 12: Probing for devices on PCI bus 13: Probing for devices on PCI bus 14: Probing for devices on PCI bus 15: Probing for devices on PCI bus 16: Probing for devices on PCI bus 17: Probing for devices on PCI bus 18: Probing for devices on PCI bus 19: Probing for devices on PCI bus 20: Probing for devices on PCI bus 21: Probing for devices on PCI bus 22: Probing for devices on PCI bus 23: Probing for devices on PCI bus 24: Probing for devices on PCI bus 25: Probing for devices on PCI bus 26: Probing for devices on PCI bus 27: Probing for devices on PCI bus 28: Probing for devices on PCI bus 29: Probing for devices on PCI bus 30: Probing for devices on PCI bus 31: Probing for devices on PCI bus 32: Probing for devices on PCI bus 33: Probing for devices on PCI bus 34: Probing for devices on PCI bus 35: Probing for devices on PCI bus 36: Probing for devices on PCI bus 37: Probing for devices on PCI bus 38: Probing for devices on PCI bus 39: Probing for devices on PCI bus 40: Probing for devices on PCI bus 41: Probing for devices on PCI bus 42: Probing for devices on PCI bus 43: Probing for devices on PCI bus 44: Probing for devices on PCI bus 45: Probing for devices on PCI bus 46: Probing for devices on PCI bus 47: Probing for devices on PCI bus 48: Probing for devices on PCI bus 49: Probing for devices on PCI bus 50: Probing for devices on PCI bus 51: Probing for devices on PCI bus 52: Probing for devices on PCI bus 53: Probing for devices on PCI bus 54: Probing for devices on PCI bus 55: Probing for devices on PCI bus 56: Probing for devices on PCI bus 57: Probing for devices on PCI bus 58: Probing for devices on PCI bus 59: Probing for devices on PCI bus 60: Probing for devices on PCI bus 61: Probing for devices on PCI bus 62: Probing for devices on PCI bus 63: Probing for devices on PCI bus 64: Probing for devices on PCI bus 65: Probing for devices on PCI bus 66: Probing for devices on PCI bus 67: Probing for devices on PCI bus 68: Probing for devices on PCI bus 69: Probing for devices on PCI bus 70: Probing for devices on PCI bus 71: Probing for devices on PCI bus 72: Probing for devices on PCI bus 73: Probing for devices on PCI bus 74: Probing for devices on PCI bus 75: Probing for devices on PCI bus 76: Probing for devices on PCI bus 77: Probing for devices on PCI bus 78: Probing for devices on PCI bus 79: Probing for devices on PCI bus 80: Probing for devices on PCI bus 81: Probing for devices on PCI bus 82: Probing for devices on PCI bus 83: Probing for devices on PCI bus 84: Probing for devices on PCI bus 85: Probing for devices on PCI bus 86: Probing for devices on PCI bus 87: Probing for devices on PCI bus 88: Probing for devices on PCI bus 89: Probing for devices on PCI bus 90: Probing for devices on PCI bus 91: Probing for devices on PCI bus 92: Probing for devices on PCI bus 93: Probing for devices on PCI bus 94: Probing for devices on PCI bus 95: Probing for devices on PCI bus 96: Probing for devices on PCI bus 97: Probing for devices on PCI bus 98: Probing for devices on PCI bus 99: Probing for devices on PCI bus 100: Probing for devices on PCI bus 101: Probing for devices on PCI bus 102: Probing for devices on PCI bus 103: Probing for devices on PCI bus 104: Probing for devices on PCI bus 105: Probing for devices on PCI bus 106: Probing for devices on PCI bus 107: Probing for devices on PCI bus 108: Probing for devices on PCI bus 109: Probing for devices on PCI bus 110: Probing for devices on PCI bus 111: Probing for devices on PCI bus 112: Probing for devices on PCI bus 113: Probing for devices on PCI bus 114: Probing for devices on PCI bus 115: Probing for devices on PCI bus 116: Probing for devices on PCI bus 117: Probing for devices on PCI bus 118: Probing for devices on PCI bus 119: Probing for devices on PCI bus 120: Probing for devices on PCI bus 121: Probing for devices on PCI bus 122: Probing for devices on PCI bus 123: Probing for devices on PCI bus 124: Probing for devices on PCI bus 125: Probing for devices on PCI bus 126: Probing for devices on PCI bus 127: Probing for devices on PCI bus 128: Probing for devices on PCI bus 129: Probing for devices on PCI bus 130: Probing for devices on PCI bus 131: Probing for devices on PCI bus 132: Probing for devices on PCI bus 133: Probing for devices on PCI bus 134: Probing for devices on PCI bus 135: Probing for devices on PCI bus 136: Probing for devices on PCI bus 137: Probing for devices on PCI bus 138: Probing for devices on PCI bus 139: Probing for devices on PCI bus 140: Probing for devices on PCI bus 141: Probing for devices on PCI bus 142: Probing for devices on PCI bus 143: Probing for devices on PCI bus 144: Probing for devices on PCI bus 145: Probing for devices on PCI bus 146: Probing for devices on PCI bus 147: Probing for devices on PCI bus 148: Probing for devices on PCI bus 149: Probing for devices on PCI bus 150: Probing for devices on PCI bus 151: Probing for devices on PCI bus 152: Probing for devices on PCI bus 153: Probing for devices on PCI bus 154: Probing for devices on PCI bus 155: Probing for devices on PCI bus 156: Probing for devices on PCI bus 157: Probing for devices on PCI bus 158: Probing for devices on PCI bus 159: Probing for devices on PCI bus 160: Probing for devices on PCI bus 161: Probing for devices on PCI bus 162: Probing for devices on PCI bus 163: Probing for devices on PCI bus 164: Probing for devices on PCI bus 165: Probing for devices on PCI bus 166: Probing for devices on PCI bus 167: Probing for devices on PCI bus 168: Probing for devices on PCI bus 169: Probing for devices on PCI bus 170: Probing for devices on PCI bus 171: Probing for devices on PCI bus 172: Probing for devices on PCI bus 173: Probing for devices on PCI bus 174: Probing for devices on PCI bus 175: Probing for devices on PCI bus 176: Probing for devices on PCI bus 177: Probing for devices on PCI bus 178: Probing for devices on PCI bus 179: Probing for devices on PCI bus 180: Probing for devices on PCI bus 181: Probing for devices on PCI bus 182: Probing for devices on PCI bus 183: Probing for devices on PCI bus 184: Probing for devices on PCI bus 185: Probing for devices on PCI bus 186: Probing for devices on PCI bus 187: Probing for devices on PCI bus 188: Probing for devices on PCI bus 189: Probing for devices on PCI bus 190: Probing for devices on PCI bus 191: Probing for devices on PCI bus 192: Probing for devices on PCI bus 193: Probing for devices on PCI bus 194: Probing for devices on PCI bus 195: Probing for devices on PCI bus 196: Probing for devices on PCI bus 197: Probing for devices on PCI bus 198: Probing for devices on PCI bus 199: Probing for devices on PCI bus 200: Probing for devices on PCI bus 201: Probing for devices on PCI bus 202: Probing for devices on PCI bus 203: Probing for devices on PCI bus 204: Probing for devices on PCI bus 205: Probing for devices on PCI bus 206: Probing for devices on PCI bus 207: Probing for devices on PCI bus 208: Probing for devices on PCI bus 209: Probing for devices on PCI bus 210: Probing for devices on PCI bus 211: Probing for devices on PCI bus 212: Probing for devices on PCI bus 213: Probing for devices on PCI bus 214: Probing for devices on PCI bus 215: Probing for devices on PCI bus 216: Probing for devices on PCI bus 217: Probing for devices on PCI bus 218: Probing for devices on PCI bus 219: Probing for devices on PCI bus 220: Probing for devices on PCI bus 221: Probing for devices on PCI bus 222: Probing for devices on PCI bus 223: Probing for devices on PCI bus 224: Probing for devices on PCI bus 225: Probing for devices on PCI bus 226: Probing for devices on PCI bus 227: Probing for devices on PCI bus 228: Probing for devices on PCI bus 229: Probing for devices on PCI bus 230: Probing for devices on PCI bus 231: Probing for devices on PCI bus 232: Probing for devices on PCI bus 233: Probing for devices on PCI bus 234: Probing for devices on PCI bus 235: Probing for devices on PCI bus 236: Probing for devices on PCI bus 237: Probing for devices on PCI bus 238: Probing for devices on PCI bus 239: Probing for devices on PCI bus 240: Probing for devices on PCI bus 241: Probing for devices on PCI bus 242: Probing for devices on PCI bus 243: Probing for devices on PCI bus 244: Probing for devices on PCI bus 245: Probing for devices on PCI bus 246: Probing for devices on PCI bus 247: Probing for devices on PCI bus 248: Probing for devices on PCI bus 249: Probing for devices on PCI bus 250: Probing for devices on PCI bus 251: Probing for devices on PCI bus 252: Probing for devices on PCI bus 253: Probing for devices on PCI bus 254: Probing for devices on PCI bus 255: Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface psm0 at 0x60-0x64 irq 12 on motherboard psm0: device ID 0 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in bt0 not found at 0x330 uha0 not found at 0x330 aha0 not found at 0x330 aic0 not found at 0x340 nca0 not found at 0x1f88 nca1 not found at 0x350 sea0 not found npx0 on motherboard npx0: INT 16 interface changing root device to sd0a WARNING: / was not properly dismounted. -- jwd@unx.sas.com (w) John W. De Boskey (919) 677-8000 x6915 From owner-freebsd-smp Fri Aug 8 05:31:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA11303 for smp-outgoing; Fri, 8 Aug 1997 05:31:54 -0700 (PDT) Received: from groa.uct.ac.za (groa.uct.ac.za [137.158.128.7]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id FAA11270; Fri, 8 Aug 1997 05:31:41 -0700 (PDT) Received: from rv by groa.uct.ac.za with local (Exim 1.653 #1) id 0wwoAG-0006sF-00; Fri, 8 Aug 1997 14:29:08 +0200 Subject: Re: scsi time-out & lockup under smp To: jwd@unx.sas.com (John W. DeBoskey) Date: Fri, 8 Aug 1997 14:29:08 +0200 (SAT) Cc: freebsd-current@freebsd.org, freebsd-smp@freebsd.org In-Reply-To: <199708081208.AA04989@iluvatar.unx.sas.com> from "John W. DeBoskey" at Aug 8, 97 08:08:50 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Message-Id: From: Russell Vincent Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk John W. DeBoskey wrote: > I have the 3.0-970731-SNAP installed on a Dell PowerEdge 6100/200, > four processor machine. The problem occurs on either of the two > aic7880 onboard scsi devices, or a 2940 adapter board, when in > multi-proccessor mode. Anywhere from 5 to 60 minutes after booting > the machine, it freezes with the following messages on the console: I was just about to report the exact same problem. A kernel from before mid-July (sorry, don't have the exact date) works fine. Kernels in the last week have all exhibited the same problem - I have tried various up until yesterday. The disk errors only start after some time (30 minutes to a few hours) and with heavy disk and CPU usage. My dmesg appended. -Russell --------------------------------------------------------------- Copyright (c) 1992-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-CURRENT #0: Tue Jul 22 10:43:10 SAT 1997 root@disa.uni.net.za:/usr/src/sys/compile/UNINET CPU: Pentium (586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 Features=0x3bf real memory = 268435456 (262144K bytes) avail memory = 261255168 (255132K bytes) FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00030010, at 0xfee00000 cpu1 (AP): apic id: 1, version: 0x00030010, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec00000 eisa0: Probing for devices on the EISA bus Probing for devices on PCI bus 0: chip0: rev 0x01 on pci0.0.0 chip1: rev 0x05 on pci0.7.0 de0: rev 0x11 int a irq 9 on pci0.9.0 de0: SMC 21041 [10Mb/s] pass 1.1 de0: address 00:00:c0:35:5e:d6 ahc0: rev 0x00 int a irq 12 on pci0.10.0 ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs ahc0: waiting for scsi devices to settle scbus0 at ahc0 bus 0 sd0 at scbus0 target 0 lun 0 sd0: type 0 fixed SCSI 2 sd0: Direct-Access 2050MB (4199760 512 byte sectors) sd0: with 3907 cyls, 10 heads, and an average 107 sectors/track sd1 at scbus0 target 1 lun 0 sd1: type 0 fixed SCSI 2 sd1: Direct-Access 4101MB (8399520 512 byte sectors) sd1: with 3907 cyls, 20 heads, and an average 107 sectors/track sd2 at scbus0 target 2 lun 0 sd2: type 0 fixed SCSI 2 sd2: Direct-Access 4101MB (8399520 512 byte sectors) sd2: with 3907 cyls, 20 heads, and an average 107 sectors/track ahc1: rev 0x00 int a irq 10 on pci0.11.0 ahc1: aic7880 Wide Channel, SCSI Id=7, 16 SCBs ahc1: waiting for scsi devices to settle scbus1 at ahc1 bus 0 sd3 at scbus1 target 0 lun 0 sd3: type 0 fixed SCSI 2 sd3: Direct-Access 4303MB (8813920 512 byte sectors) sd3: with 3907 cyls, 20 heads, and an average 112 sectors/track sd4 at scbus1 target 1 lun 0 sd4: type 0 fixed SCSI 2 sd4: Direct-Access 4101MB (8399520 512 byte sectors) sd4: with 3907 cyls, 20 heads, and an average 107 sectors/track ahc2: rev 0x00 int a irq 11 on pci0.12.0 ahc2: aic7880 Wide Channel, SCSI Id=7, 16 SCBs ahc2: waiting for scsi devices to settle scbus2 at ahc2 bus 0 sd5 at scbus2 target 0 lun 0 sd5: type 0 fixed SCSI 2 sd5: Direct-Access 4101MB (8399520 512 byte sectors) sd5: with 3907 cyls, 20 heads, and an average 107 sectors/track sd6 at scbus2 target 1 lun 0 sd6: type 0 fixed SCSI 2 sd6: Direct-Access 4101MB (8399520 512 byte sectors) sd6: with 3907 cyls, 20 heads, and an average 107 sectors/track Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in npx0 on motherboard npx0: INT 16 interface stray irq 7 de0: enabling 10baseT port ccd0-3: Concatenated disk drivers SMP: All idle procs online. SMP: *** AUTO *** starting 1st AP! SMP: AP CPU #1 LAUNCHED!! Starting Scheduling... SMP: TADA! CPU #1 made it into the scheduler!. SMP: All 2 CPU's are online! de0: enabling 10baseT port From owner-freebsd-smp Fri Aug 8 06:33:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA14546 for smp-outgoing; Fri, 8 Aug 1997 06:33:44 -0700 (PDT) Received: from pagh.umd.edu (pagh.umd.edu [128.8.202.77]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id GAA14531 for ; Fri, 8 Aug 1997 06:33:38 -0700 (PDT) Received: by pagh.umd.edu (940816.SGI.8.6.9/940406.SGI) for smp@FreeBSD.ORG id JAA01965; Fri, 8 Aug 1997 09:35:13 -0400 From: "Jean-Marc Henriette" Message-Id: <9708080935.ZM1963@pagh.umd.edu> Date: Fri, 8 Aug 1997 09:35:13 -0400 In-Reply-To: Steve Passe "HEADS UP: programming the SMP kernel" (Aug 7, 17:08) References: <199708072308.RAA25847@Ilsa.StevesCafe.com> X-Mailer: Z-Mail (3.2.1 6apr95 MediaMail) To: smp@FreeBSD.ORG Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk unsubscribe From owner-freebsd-smp Fri Aug 8 09:32:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA27263 for smp-outgoing; Fri, 8 Aug 1997 09:32:26 -0700 (PDT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.54]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA27254; Fri, 8 Aug 1997 09:32:21 -0700 (PDT) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.8.6/8.8.5) id JAA03485; Fri, 8 Aug 1997 09:34:30 GMT From: Steve Kargl Message-Id: <199708080934.JAA03485@troutmask.apl.washington.edu> Subject: Re: scsi time-out & lockup under smp In-Reply-To: <199708081208.AA04989@iluvatar.unx.sas.com> from "John W. DeBoskey" at "Aug 8, 97 08:08:50 am" To: jwd@unx.sas.com (John W. DeBoskey) Date: Fri, 8 Aug 1997 09:34:30 +0000 (GMT) Cc: freebsd-current@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to John W. DeBoskey: > Hello, > > I'm wondering if anyone might have some information relating to the > following problem. > > I have the 3.0-970731-SNAP installed on a Dell PowerEdge 6100/200, > four processor machine. The problem occurs on either of the two > aic7880 onboard scsi devices, or a 2940 adapter board, when in > multi-proccessor mode. Anywhere from 5 to 60 minutes after booting > the machine, it freezes with the following messages on the console: > > sd0: SCB 0x1 - timed out in command pahse, SCSISIGI == 0x86 > SEQADDR = 0x8c SCSISEQ = 0x12 SSTAT0 = 0x7 SSTAT1 = 0x3 > sd0: abort message in message buffer > sd0: SCB 1 - Abort Completed. > sd0: no longer in timeout > sd0: SCB 0x1 - timed our while idle, LASTPHASE == 0x1, SCSISIGI = 0x0 > SEQADDR = 0xb SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0x2 > sd0: Queueing an Abort SCB > > > It only seems to occur when I start to initiate heavy disk io. It > does not happen in the uni-proccesor situation. The complete output > from dmesg is appended to this mail. If anyone can help me track this > down, I'd really appreciate it. > > Thanks, > John > It occurs on uni-processor system, too. If I use dump(1) to backup my system, I eventually get the following: st0(ahc0:2:0): SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 SEQADDR = 0x5 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa st0(ahc0:2:0): Queueing an Abort SCB st0(ahc0:2:0): Abort Message Sent st0(ahc0:2:0): SCB 0 - Abort Completed. st0(ahc0:2:0): no longer in timeout st0(ahc0:2:0): SCB 0x0 - timed out in dataout phase, SCSISIGI == 0xc6 SEQADDR = 0x42 SCSISEQ = 0x12 SSTAT0 = 0x7 SSTAT1 = 0x13 sd0(ahc0:0:0): abort message in message buffer sd0(ahc0:0:0): SCB 3 - Abort Completed. sd0(ahc0:0:0): no longer in timeout st0(ahc0:2:0): SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 SEQADDR = 0x5 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa st0(ahc0:2:0): SCB 0: Immediate reset. Flags = 0x1 ahc0: Issued Channel A Bus Reset. 3 SCBs aborted Clearing bus reset Clearing 'in-reset' flag st0(ahc0:2:0): no longer in timeout sd0(ahc0:0:0): UNIT ATTENTION asc:29,0 sd0(ahc0:0:0): Power on, reset, or bus device reset occurred, retries:3 sd1(ahc0:1:0): UNIT ATTENTION asc:29,0 sd1(ahc0:1:0): Power on, reset, or bus device reset occurred, retries:4 >From dmesg: ahc0: rev 0x03 int a irq 11 on pci0.12.0 ahc0: aic7870 Single Channel, SCSI Id=7, 16 SCBs ahc0: waiting for scsi devices to settle scbus0 at ahc0 bus 0 sd0 at scbus0 target 0 lun 0 sd0: type 0 fixed SCSI 2 sd0: Direct-Access 1030MB (2109840 512 byte sectors) st0 at scbus0 target 2 lun 0 st0: type 1 removable SCSI 2 st0: Sequential-Access density code 0x13, drive empty -- Steve finger kargl@troutmask.apl.washington.edu http://troutmask.apl.washington.edu/~kargl/sgk.html From owner-freebsd-smp Fri Aug 8 09:52:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA28445 for smp-outgoing; Fri, 8 Aug 1997 09:52:33 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA28431 for ; Fri, 8 Aug 1997 09:52:28 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id KAA28980; Fri, 8 Aug 1997 10:52:09 -0600 (MDT) Message-Id: <199708081652.KAA28980@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Russell Vincent cc: jwd@unx.sas.com (John W. DeBoskey), freebsd-smp@FreeBSD.ORG Subject: Re: scsi time-out & lockup under smp In-reply-to: Your message of "Sat, 08 Aug 1997 14:29:08 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Aug 1997 10:52:08 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > John W. DeBoskey wrote: > > I have the 3.0-970731-SNAP installed on a Dell PowerEdge 6100/200, > > four processor machine. The problem occurs on either of the two > > aic7880 onboard scsi devices, or a 2940 adapter board, when in > > multi-proccessor mode. Anywhere from 5 to 60 minutes after booting > > the machine, it freezes with the following messages on the console: > > I was just about to report the exact same problem. A kernel > from before mid-July (sorry, don't have the exact date) works > fine. Kernels in the last week have all exhibited the same > problem - I have tried various up until yesterday. > > The disk errors only start after some time (30 minutes > to a few hours) and with heavy disk and CPU usage. > try undefining PEND_INTS in i386/include/smptests.h -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Fri Aug 8 10:02:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA28977 for smp-outgoing; Fri, 8 Aug 1997 10:02:26 -0700 (PDT) Received: from zippy.dyn.ml.org (garbanzo@nepal-10.ppp.hooked.net [206.80.8.202]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA28972; Fri, 8 Aug 1997 10:02:22 -0700 (PDT) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.8.7/8.8.7) with SMTP id KAA27660; Fri, 8 Aug 1997 10:01:47 -0700 (PDT) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Fri, 8 Aug 1997 10:01:42 -0700 (PDT) From: Alex X-Sender: garbanzo@zippy.dyn.ml.org To: "John W. DeBoskey" cc: freebsd-current@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: scsi time-out & lockup under smp In-Reply-To: <199708081208.AA04989@iluvatar.unx.sas.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 8 Aug 1997, John W. DeBoskey wrote: > sd0: SCB 0x1 - timed out in command pahse, SCSISIGI == 0x86 > SEQADDR = 0x8c SCSISEQ = 0x12 SSTAT0 = 0x7 SSTAT1 = 0x3 > sd0: abort message in message buffer > sd0: SCB 1 - Abort Completed. > sd0: no longer in timeout > sd0: SCB 0x1 - timed our while idle, LASTPHASE == 0x1, SCSISIGI = 0x0 > SEQADDR = 0xb SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0x2 > sd0: Queueing an Abort SCB > > > It only seems to occur when I start to initiate heavy disk io. It > does not happen in the uni-proccesor situation. The complete output > from dmesg is appended to this mail. If anyone can help me track this > down, I'd really appreciate it. > > Thanks, > John This is a fairly well known problem with the 2940U/UW, and probably anything else based on the 7880. All I can say is that for heavy disk io, don't use that controller, two controllers might be causing some of those problems too. However I'd also suggest that you take the number of busses down a notch, unless you have devices on bus 255, and that you cvsup the most recent FreeBSD sources,as I think some improvments have been made to this driver, and many improvments have been made to the smp code. - alex From owner-freebsd-smp Fri Aug 8 10:20:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA29844 for smp-outgoing; Fri, 8 Aug 1997 10:20:43 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA29839; Fri, 8 Aug 1997 10:20:39 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id LAA06615; Fri, 8 Aug 1997 11:20:20 -0600 (MDT) Message-Id: <199708081720.LAA06615@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Steve Kargl cc: jwd@unx.sas.com (John W. DeBoskey), freebsd-current@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: scsi time-out & lockup under smp In-reply-to: Your message of "Fri, 08 Aug 1997 09:34:30 GMT." <199708080934.JAA03485@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Aug 1997 17:20:12 +0000 From: "Justin T. Gibbs" Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >It occurs on uni-processor system, too. If I use dump(1) to backup >my system, I eventually get the following: > >st0(ahc0:2:0): SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 >SEQADDR = 0x5 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Do you know if this occurs during the rewind or during some other operation during the backup. These types of problems, at least when a tape drive is the culprit, are almost always caused by one of the timeouts in the driver being too short. For instance, you may have hit a bad tape block and the timeout for reading a tape block is simply too short to deal with the drives attempts to retry the read. >-- >Steve > >finger kargl@troutmask.apl.washington.edu >http://troutmask.apl.washington.edu/~kargl/sgk.html -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-smp Fri Aug 8 13:36:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA11819 for smp-outgoing; Fri, 8 Aug 1997 13:36:38 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA11811 for ; Fri, 8 Aug 1997 13:36:35 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id OAA00152 for ; Fri, 8 Aug 1997 14:36:34 -0600 (MDT) Message-Id: <199708082036.OAA00152@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: freebsd-smp@FreeBSD.ORG Subject: new TODO list Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Aug 1997 14:36:34 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, I've been going thru the SMP web page trying to update it a little. Of particular interest would be an up-to-date 'TODO' list: http://www.freebsd.org/~fsmp/SMP/TODO.html -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Fri Aug 8 14:03:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA13629 for smp-outgoing; Fri, 8 Aug 1997 14:03:24 -0700 (PDT) Received: from critter.dk.tfs.com (critter.phk.freebsd.dk [195.8.133.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA13580 for ; Fri, 8 Aug 1997 14:02:51 -0700 (PDT) Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.6/8.8.5) with ESMTP id QAA26064; Fri, 8 Aug 1997 16:27:42 +0200 (CEST) To: Steve Passe cc: smp@freebsd.org From: Poul-Henning Kamp Subject: Re: HEADS UP: programming the SMP kernel In-reply-to: Your message of "Thu, 07 Aug 1997 17:08:17 MDT." <199708072308.RAA25847@Ilsa.StevesCafe.com> Date: Fri, 08 Aug 1997 16:27:41 +0200 Message-ID: <26062.871050461@critter.dk.tfs.com> Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >We need to agree on the set of primatives available for coding SMP >specific kernel code. Along with this we need a concise document describing >the dos and donts of SMP conforming code. I think the right thing to do, is to stand firm on only the documentation part. There are a multitude of locking primitives, and I don't think we should needlessly limit ourselves to one type, if there are better ones available for certain purposes. Certain operations can be done atomically (twiddle a bit in a word for instance) and I think we should leave the doors wide open for that kind of mechanisms too. The important thing is to get documented clearly what locking is used where, what hierarchies of objects&locks exists and some implementations of the locking primitives that will check this (#ifdef SMP_ANAL_RETENTIVE). -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-smp Fri Aug 8 15:03:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA17600 for smp-outgoing; Fri, 8 Aug 1997 15:03:30 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA17591 for ; Fri, 8 Aug 1997 15:03:23 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id QAA00511; Fri, 8 Aug 1997 16:03:19 -0600 (MDT) Message-Id: <199708082203.QAA00511@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Poul-Henning Kamp cc: smp@freebsd.org Subject: Re: HEADS UP: programming the SMP kernel In-reply-to: Your message of "Fri, 08 Aug 1997 16:27:41 +0200." <26062.871050461@critter.dk.tfs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Aug 1997 16:03:19 -0600 Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > > >We need to agree on the set of primatives available for coding SMP > >specific kernel code. Along with this we need a concise document describing > >the dos and donts of SMP conforming code. > > I think the right thing to do, is to stand firm on only the documentation > part. > > There are a multitude of locking primitives, and I don't think we should > needlessly limit ourselves to one type, if there are better ones available > for certain purposes. I agree with this in the abstract. But we need to introduce them in an orderly way. If we don't we will have endless grief trying to find deadlocks, etc. Perhaps this is better expressed as: We should start with the locks provided by the lite2 lock manager, and add others as the need becomes obvious. I am much more concerned with expanding to fine-grained locks in a manner that maintains kernel stability than getting the greatest efficiency in the first pass. Once we have gotten to the point where we have pushed the locking down to the granularity we want, we can then evaluate the locking types to see if alternatives make sense. If someone can point out glaring deficiencies in the lite2 lock manager then this is a different matter... --- > Certain operations can be done atomically (twiddle a bit in a word for > instance) and I think we should leave the doors wide open for that kind > of mechanisms too. agreed, atomic data operations where then can be done are great, and I am not suggesting that you do: push $_foolock call _simple_lock add $1, _foodata call _simple_unlock add $4, %esp when: lock inc _foodata will work. This is a topic to the "how-to" document, describing where each would be appropriate. --- > The important thing is to get documented clearly what locking is used > where, what hierarchies of objects&locks exists and some implementations > of the locking primitives that will check this (#ifdef SMP_ANAL_RETENTIVE). agreed. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Fri Aug 8 15:09:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA17867 for smp-outgoing; Fri, 8 Aug 1997 15:09:31 -0700 (PDT) Received: from pimin.rockhead.com (root@pimin.rockhead.com [209.38.77.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA17851 for ; Fri, 8 Aug 1997 15:09:25 -0700 (PDT) Received: (from newhouse@localhost) by pimin.rockhead.com (8.8.5/8.6.12) id PAA02834; Fri, 8 Aug 1997 15:09:22 -0700 (PDT) Date: Fri, 8 Aug 1997 15:09:22 -0700 (PDT) From: "Paul M. Newhouse" Message-Id: <199708082209.PAA02834@pimin.rockhead.com> To: smp@FreeBSD.ORG Subject: unsubscribe Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk unsubscribe From owner-freebsd-smp Fri Aug 8 17:21:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA25222 for smp-outgoing; Fri, 8 Aug 1997 17:21:04 -0700 (PDT) Received: from shell.uniserve.com (tom@shell.uniserve.com [204.244.210.252]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA25202; Fri, 8 Aug 1997 17:20:59 -0700 (PDT) Received: from localhost (tom@localhost) by shell.uniserve.com (8.8.5/8.8.5) with SMTP id RAA28240; Fri, 8 Aug 1997 17:17:36 -0700 (PDT) X-Authentication-Warning: shell.uniserve.com: tom owned process doing -bs Date: Fri, 8 Aug 1997 17:17:36 -0700 (PDT) From: Tom To: Steve Kargl cc: "John W. DeBoskey" , freebsd-current@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: scsi time-out & lockup under smp In-Reply-To: <199708080934.JAA03485@troutmask.apl.washington.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 8 Aug 1997, Steve Kargl wrote: ... > sd1(ahc0:1:0): UNIT ATTENTION asc:29,0 > sd1(ahc0:1:0): Power on, reset, or bus device reset occurred, retries:4 ... > ahc0: waiting for scsi devices to settle > scbus0 at ahc0 bus 0 > sd0 at scbus0 target 0 lun 0 > sd0: type 0 fixed SCSI 2 > sd0: Direct-Access 1030MB (2109840 512 byte sectors) > st0 at scbus0 target 2 lun 0 > st0: type 1 removable SCSI 2 > st0: Sequential-Access density code 0x13, drive empty What is sd1? Also, are you sure you aren't having cable problems? The fact that all the devices go wacko at the same time is strange. Also, check your power supply. Heavy disk io will draw more power, is your PS cutting out causing the timeouts? > -- > Steve > > finger kargl@troutmask.apl.washington.edu > http://troutmask.apl.washington.edu/~kargl/sgk.html > Tom From owner-freebsd-smp Fri Aug 8 20:44:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA04818 for smp-outgoing; Fri, 8 Aug 1997 20:44:24 -0700 (PDT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.54]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA04811; Fri, 8 Aug 1997 20:44:20 -0700 (PDT) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.8.6/8.8.5) id UAA18785; Fri, 8 Aug 1997 20:45:49 GMT From: Steve Kargl Message-Id: <199708082045.UAA18785@troutmask.apl.washington.edu> Subject: Re: scsi time-out & lockup under smp In-Reply-To: from Tom at "Aug 8, 97 05:17:36 pm" To: tom@uniserve.com (Tom) Date: Fri, 8 Aug 1997 20:45:48 +0000 (GMT) Cc: jwd@unx.sas.com, freebsd-current@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Tom: > > On Fri, 8 Aug 1997, Steve Kargl wrote: > > ... > > sd1(ahc0:1:0): UNIT ATTENTION asc:29,0 > > sd1(ahc0:1:0): Power on, reset, or bus device reset occurred, retries:4 > > ... > > ahc0: waiting for scsi devices to settle > > scbus0 at ahc0 bus 0 > > sd0 at scbus0 target 0 lun 0 > > sd0: type 0 fixed SCSI 2 > > sd0: Direct-Access 1030MB (2109840 512 byte sectors) > > st0 at scbus0 target 2 lun 0 > > st0: type 1 removable SCSI 2 > > st0: Sequential-Access density code 0x13, drive empty > > What is sd1? Whoops, cut and paste problem. sd1 is a Quantum Lightning 730E. st0 and sd1 are external drives with active termination on sd1. Termination is known to be correct (first thing I checked). > Also, are you sure you aren't having cable problems? The fact that all > the devices go wacko at the same time is strange. Same cables I've been using for 2 years. They could go bad (I guess). No. st0 goes south, then the SCSI bus locks up during the reset, and sd0 and sd1 sieze up. Never sd0 nor sd1 suffer any damage. > Also, check your power supply. Heavy disk io will draw more power, is > your PS cutting out causing the timeouts? sd0 is on the internal main PS. sd0 and st0 each have their own PS. -- Steve finger kargl@troutmask.apl.washington.edu http://troutmask.apl.washington.edu/~kargl/sgk.html From owner-freebsd-smp Sat Aug 9 09:18:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA00446 for smp-outgoing; Sat, 9 Aug 1997 09:18:28 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA00440; Sat, 9 Aug 1997 09:18:22 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id KAA06802; Sat, 9 Aug 1997 10:18:00 -0600 (MDT) Message-Id: <199708091618.KAA06802@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Russell Vincent cc: jwd@unx.sas.com (John W. DeBoskey), freebsd-current@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: scsi time-out & lockup under smp In-reply-to: Your message of "Sat, 08 Aug 1997 14:29:08 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Aug 1997 10:18:00 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, Has anyone tried undefining PEND_INTS to fix this yet? We REALLY need to determine if this is being caused by the SMP code! Another thing I see that is a possible leak is in apic_vector.s: *** apic_vector.s.orig 1997/07/30 22:46:49 1.18 --- apic_vector.s 1997/08/09 05:55:31 *************** *** 45,50 **** --- 45,51 ---- orl $IOART_INTMASK,%eax ; /* set the mask */ \ movl %eax,IOAPIC_WINDOW(%ecx) ; /* new value */ \ 7: ; \ + lock ; \ orl $IRQ_BIT(irq_num), _ipending ; /* set _ipending bit */ \ IMASK_UNLOCK ; /* exit critical reg */ \ movl $0, lapic_eoi ; /* do the EOI */ \ -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD