From owner-freebsd-smp Sun Sep 10 2:15:42 2000 Delivered-To: freebsd-smp@freebsd.org Received: from darren2.lnk.telstra.net (darren2.lnk.telstra.net [139.130.53.33]) by hub.freebsd.org (Postfix) with ESMTP id C4CA337B422 for ; Sun, 10 Sep 2000 02:15:38 -0700 (PDT) Received: (from root@localhost) by darren2.lnk.telstra.net (8.9.1/8.8.7) id JAA27723 for ; Sun, 10 Sep 2000 09:15:35 GMT From: Darren Reed Message-Id: <200009100915.UAA03343@avalon.reed.wattle.id.au> Subject: atomic_{add,subtract} functions. To: smp@freebsd.org Date: Sun, 10 Sep 100 20:15:11 +1100 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Someone might want to expand that interface from being atomic_{add,subtract}_{char,short,int,long}() (what happened to quad?) to include these too: atomic_{add,subtract}_{8,16,32,64}() I (and others, I hope) aren't so much fussed with what you can do in half a dozen asm. instructions on architecture X as having an interface which can be used reliably. Afterall, what about {u_,}int{8,16,32,64}_t ? Personally, I don't care if the above macros turn out to be rather heavy on some architectures (386, 486), heck, I'd even support them being something like: #define atomic_add_foo(x, y) { mtx_enter(&mtx_foo, MTX_DEF); x += y; mtx_exit(&mtx_foo); } if that is what was required. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Sep 10 19: 5:28 2000 Delivered-To: freebsd-smp@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id 29C9337B422 for ; Sun, 10 Sep 2000 19:05:24 -0700 (PDT) Received: (qmail 11557 invoked from network); 11 Sep 2000 02:05:16 -0000 Received: from unknown (HELO bde.zeta.org.au) (203.2.228.102) by gidora.zeta.org.au with SMTP; 11 Sep 2000 02:05:16 -0000 Date: Mon, 11 Sep 2000 13:05:13 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Darren Reed Cc: smp@FreeBSD.ORG Subject: Re: atomic_{add,subtract} functions. In-Reply-To: <200009100915.UAA03343@avalon.reed.wattle.id.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 Sun, 10 Sep 100, Darren Reed wrote: > Someone might want to expand that interface from being > > atomic_{add,subtract}_{char,short,int,long}() > > (what happened to quad?) to include these too: > > atomic_{add,subtract}_{8,16,32,64}() > > I (and others, I hope) aren't so much fussed with what you can do in half > a dozen asm. instructions on architecture X as having an interface which > can be used reliably. Afterall, what about {u_,}int{8,16,32,64}_t ? > > Personally, I don't care if the above macros turn out to be rather heavy > on some architectures (386, 486), heck, I'd even support them being > something like: > > #define atomic_add_foo(x, y) { mtx_enter(&mtx_foo, MTX_DEF); x += y; > mtx_exit(&mtx_foo); } > > if that is what was required. I care, and plan to remove atomic_add_long(), since it should not be implementable at a non-heavy cost (longs should be twice as wide as registers). I hope to use atomic_op(lvalue) and generate an error at compile-time if `lvalue' is not inherently atomic. The current functions can't be used without knowing too much about the data type or writing spam like: if (sizeof(lvalue) == sizeof(char)) atomic_add_char(lvalue); else if (sizeof(lvalue) == sizeof(short)) atomic_add_short(lvalue); ... Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Sep 11 3: 6:15 2000 Delivered-To: freebsd-smp@freebsd.org Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (Postfix) with ESMTP id 8353837B422 for ; Mon, 11 Sep 2000 03:06:12 -0700 (PDT) Received: (from uucp@localhost) by isbalham.ist.co.uk (8.9.2/8.8.7) with UUCP id LAA24723 for smp@freebsd.org; Mon, 11 Sep 2000 11:06:06 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from [194.32.164.2] (eccles [194.32.164.2]) by seagoon.gid.co.uk (8.9.3/8.9.3) with ESMTP id KAA16575; Mon, 11 Sep 2000 10:39:46 +0100 (BST) (envelope-from rb@gid.co.uk) X-Sender: rb@194.32.164.1 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Sep 2000 10:39:46 +0100 To: smp@freebsd.org From: Bob Bishop Subject: SMPng box wedges repeatably Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Seems that I can repeatably wedge an MP box running SMPng (yesterday's -current) under the following conditions. It's doing a buildworld -j8 getting its sources via NFS from box B, its /usr/obj from box C and also NFS-serving /usr/obj for box C which is also buildworlding; so there's quite a lot of NFS activity. It's also running a couple of dnetcs. Symptoms are as if the scheduler is wedged: I can ping the box and get into DDB, but nothing is happening in userland. According to ps in DDB the dnetcs are runnable as are half a dozen shells presumably just spawned by make. Eveything else is waiting, a few in ffsvgt or inode, a bunch of shells in wait, a bunch of makes in select, ... DDB trace gives: (debugger) ^ | atkbd_isa_intr() ithd_loop(0) fork_trampoline() .. which doesn't seem very useful. Anyone want more information from this corpse before I turn off its life-support? -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Sep 11 4:26:14 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mx0.dircon.net (mx0.dircon.net [194.112.50.10]) by hub.freebsd.org (Postfix) with ESMTP id BC31037B423 for ; Mon, 11 Sep 2000 04:26:09 -0700 (PDT) Received: from diablo.dircon.net (desk108.ch.dircon.net [195.157.3.108]) by mx0.dircon.net (8.9.1.Dirconised/8.9.1) with ESMTP id MAA01541; Mon, 11 Sep 2000 12:25:59 +0100 (BST) Received: by diablo.dircon.net (Postfix, from userid 1000) id 877591B222; Mon, 11 Sep 2000 12:25:59 +0100 (BST) Date: Mon, 11 Sep 2000 12:25:59 +0100 From: Mark Blackman To: "Potter, Jeff" Cc: "'freebsd-smp@freebsd.org'" , sam.yeung@dircon.net Subject: Re: FreeBSD 4.0 Release SMP kernel stalls during bootup"SMP: CPU1 api c_initialize()" (See PR19338 for details) Message-ID: <20000911122559.A50097@diablo.dircon.net> References: <2D348570FE47D0118C3F00805FEA318104BC29FA@EXCHOU-CA0901> <20000908160222.A37468@diablo.dircon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000908160222.A37468@diablo.dircon.net>; from mark.blackman@dircon.net on Fri, Sep 08, 2000 at 04:02:22PM +0100 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org For the record, we cured this by setting "unixware" as the Primary Operating System in the SmartStart configuration utility. On Fri, Sep 08, 2000 at 04:02:22PM +0100, Mark Blackman wrote: > > We're having a bit of trouble with a Compaq DL380 here (with SMP). > hangs just after > > lint0: 0x00000700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff > > Could I persuade you to send a kernel config file that works > with DL380 SMP and/or any BIOS settings required, please. > This is for a big customer so speed will be gratefully appreciated. > > - Mark (Blackman) > > On Fri, Aug 04, 2000 at 07:39:29PM -0500, Potter, Jeff wrote: > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=19338 > > > > Does anyone have any advice or a patch that possibly could fix this issue? > > The SMP kernel works fine on the Compaq DL380, but fails on the Compaq > > DL360. The most obvious difference in the hardware of the two units is the > > BSP/AP APIC ID numbers are wired differently [per Intel spec]. MP Table for > > the Compaq DL360 is listed in PR 19338. We don't suspect ill behaved > > hardware because RedHat 6.2, and other SMP capable OSes work fine on both > > units. Copied 'most' of the boot message below from the customer issue > > report. If more information is needed for resolution, please let me know. > > Thanks in advance! > > > > Regards, > > JP > > > > > > Output from boot -hv DL360 > > -------------------------- > > connected > > Copyright (c) 1992-2000 The FreeBSD Project. > > Copyright (c) 1982, 1986, 1989, 1991, 1993 > > The Regents of the University of California. All rights reserved. > > FreeBSD 4.0-20000531-STABLE #0: Thu Jun 1 16:03:10 BST 2000 > > root@fubar.noc.demon.net:/usr/src/sys/compile/CPQ > > Calibrating clock(s) ... TSC clock: 797430926 Hz, i8254 clock: 1193118 Hz > > CLK_USE_I8254_CALIBRATION not specified - using default frequency > > Timecounter "i8254" frequency 1193182 Hz > > CLK_USE_TSC_CALIBRATION not specified - using old calibration method > > CPU: Pentium III/Pentium III Xeon (797.48-MHz 686-class CPU) > > Origin = "GenuineIntel" Id = 0x683 Stepping = 3 > > > > Features=0x383fbff > CMOV,PAT,PSE36,MMX,FXSR,XMM> > > real memory = 1207943168 (1179632K bytes) > > Physical memory chunk(s): > > 0x00001000 - 0x0009efff, 647168 bytes (158 pages) > > 0x002c3000 - 0x47ff3fff, 1205014528 bytes (294193 pages) > > avail memory = 1170939904 (1143496K bytes) > > Programming 35 pins in IOAPIC #0 > > IOAPIC #0 intpin 2 -> irq 0 > > IOAPIC #0 intpin 24 -> irq 2 > > SMP: CPU0 apic_initialize(): > > lint0: 0x00000700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff > > FreeBSD/SMP: Multiprocessor motherboard > > cpu0 (BSP): apic id: 3, version: 0x00040011, at 0xfee00000 > > cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 > > io0 (APIC): apic id: 8, version: 0x00220011, at 0xfec00000 > > bios32: Found BIOS32 Service Directory header at 0xc00ffee0 > > bios32: Entry = 0xf0000 (c00f0000) Rev = 0 Len = 1 > > pcibios: PCI BIOS entry at 0x94 > > Other BIOS signatures found: > > ACPI: 000f4f90 > > Preloaded elf kernel "kernel" at 0xc02a7000. > > Pentium Pro MTRR support enabled > > SMP: CPU0 bsp_apic_configure(): > > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000010 SVR: 0x000001ff > > ... > > ... "snip" > > ... > > Device configuration finished. > > APIC_IO: routing 8254 via IOAPIC #0 intpin 2 > > bpf: lo0 attached > > SMP: AP CPU #1 Launched! > > SMP: CPU1 apic_initialize(): > > lint0: 0x00010700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff > > > > --------- > > > > A three fingered salute then adds the following > > > > boot() called on cpu#1 > > Uptime: 0s > > Rebooting... > > cpu_reset called on cpu#1 > > cpu_reset: Stopping other CPUs > > cpu_reset: Restarting BSP > > pu_reset_proxy: Grabbed mp locck uf_orr sBeSP: > > BSP did not grab mp lock > > > > --------------------------------- > > > > > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-smp" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Sep 11 8: 0:31 2000 Delivered-To: freebsd-smp@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 34C2B37B423; Mon, 11 Sep 2000 08:00:27 -0700 (PDT) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id IAA10432; Mon, 11 Sep 2000 08:00:27 -0700 Date: Mon, 11 Sep 2000 08:00:04 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Device probing... In-Reply-To: <89354.968526601@critter> 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 The only theoretical problem with this is if you ever want to do a BOOT driver based autoload mechanism. Currently FreeBSD has the ability to load (preload) modules. If, in the future, you want to load modules after loading a primary kernel object but before configuring your root device's bus and driver stack, you need to do callbacks to a PROM driver. It's even harder to do this if you've enabled interrupts (or even changed MMU mappings, btw). So- if there's any chance you want to ever do a load as you go model, having interrupts enabled might make it more difficult. -matt p.s.: FWIW, I'm *for* you doing this. I *hate* having to support polled mode in drivers. On Sat, 9 Sep 2000, Poul-Henning Kamp wrote: > > I would really like to se us move all the device probe/attach code > to run in "normal context", ie enable interrupts before we probe > everything. > > The main argument for this is the drivers can then use the full > complement of kernel infrastructure and interrupts during probe > attach. > > Drivers needs to be able to function in this environment anyway > if they support removeable devices (pccard, usb, etc). > > Are there reasons to not do this I have overlooked ? > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD coreteam member | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Sep 11 8:27:13 2000 Delivered-To: freebsd-smp@freebsd.org Received: from fast.cs.utah.edu (fast.cs.utah.edu [155.99.212.1]) by hub.freebsd.org (Postfix) with ESMTP id 353F537B43C for ; Mon, 11 Sep 2000 08:27:09 -0700 (PDT) Received: (from vanmaren@localhost) by fast.cs.utah.edu (8.9.1/8.9.1) id JAA17010; Mon, 11 Sep 2000 09:26:44 -0600 (MDT) Date: Mon, 11 Sep 2000 09:26:44 -0600 (MDT) From: Kevin Van Maren Message-Id: <200009111526.JAA17010@fast.cs.utah.edu> To: bde@zeta.org.au, darrenr@reed.wattle.id.au Subject: Re: atomic_{add,subtract} functions. Cc: smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Sun, 10 Sep 100, Darren Reed wrote: > > > Someone might want to expand that interface from being > > > > atomic_{add,subtract}_{char,short,int,long}() > > > > (what happened to quad?) to include these too: > > > > atomic_{add,subtract}_{8,16,32,64}() > > > > I (and others, I hope) aren't so much fussed with what you can do in half > > a dozen asm. instructions on architecture X as having an interface which > > can be used reliably. Afterall, what about {u_,}int{8,16,32,64}_t ? > > > > Personally, I don't care if the above macros turn out to be rather heavy > > on some architectures (386, 486), heck, I'd even support them being > > something like: > > > > #define atomic_add_foo(x, y) { mtx_enter(&mtx_foo, MTX_DEF); x += y; > > mtx_exit(&mtx_foo); } > > > > if that is what was required. > > I care, and plan to remove atomic_add_long(), since it should not be > implementable at a non-heavy cost (longs should be twice as wide as > registers). I hope to use atomic_op(lvalue) and generate an error at No, that's a "long long". A long is 64-bits on the alpha, whereas an int is 32. Int and long are normally both 32 bits on x86. > compile-time if `lvalue' is not inherently atomic. The current functions > can't be used without knowing too much about the data type or writing > spam like: > > if (sizeof(lvalue) == sizeof(char)) > atomic_add_char(lvalue); > else if (sizeof(lvalue) == sizeof(short)) > atomic_add_short(lvalue); > ... > > Bruce Is it really a big deal to know what type the variable is you're manipulating? Perhaps if it is in a structure definition defined by the OS; but then maybe there is a better way to handle that. The big problem with using atomic operations on non-atomic data types is that all accesses to those data types must use atomic operations: if you use a mutex to protect a long long, you must acquire that mutex to *read* the value as well. So you are left with atomic_get/ atomic_set/atomic_inc/etc. Not a big deal: UnixWare uses macros like those for atomic variables, which are simply assignments for 8/16/32 bits. If datatypes are going to be defined as explicitly-sized ints, then operations on explicitly-sized ints should be provided,. Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Sep 11 11: 8:37 2000 Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id E3C9C37B424 for ; Mon, 11 Sep 2000 11:08:30 -0700 (PDT) Received: (from jhb@localhost) by pike.osd.bsdi.com (8.9.3/8.9.3) id LAA55794; Mon, 11 Sep 2000 11:07:55 -0700 (PDT) (envelope-from jhb) From: John Baldwin Message-Id: <200009111807.LAA55794@pike.osd.bsdi.com> Subject: Re: SMPng box wedges repeatably In-Reply-To: from Bob Bishop at "Sep 11, 2000 10:39:46 am" To: Bob Bishop Date: Mon, 11 Sep 2000 11:07:55 -0700 (PDT) Cc: smp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL68 (25)] 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 Bob Bishop wrote: > Hi, > > Seems that I can repeatably wedge an MP box running SMPng (yesterday's > -current) under the following conditions. It's doing a buildworld -j8 > getting its sources via NFS from box B, its /usr/obj from box C and also > NFS-serving /usr/obj for box C which is also buildworlding; so there's > quite a lot of NFS activity. It's also running a couple of dnetcs. > > Symptoms are as if the scheduler is wedged: I can ping the box and get > into DDB, but nothing is happening in userland. According to ps in DDB the > dnetcs are runnable as are half a dozen shells presumably just spawned by > make. Eveything else is waiting, a few in ffsvgt or inode, a bunch of > shells in wait, a bunch of makes in select, ... What disk controller do you have? This is a known problem, but when we looked at it, it so far has only happened with ahc SCSI controllers. When it hangs, it seems the ahc driver is waiting for an interrupt that never comes. As a result, any process that accesses the disk blocks forever. It is triggered by heavy load situations such as you describe. > Anyone want more information from this corpse before I turn off its > life-support? Check to see what wait channels processes are sleeping on. If a lot are sleeping on biowait, it is probably the same problem. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Sep 11 11:16:12 2000 Delivered-To: freebsd-smp@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id A0AF037B424 for ; Mon, 11 Sep 2000 11:16:06 -0700 (PDT) Received: (qmail 4282 invoked from network); 11 Sep 2000 18:16:02 -0000 Received: from unknown (HELO bde.zeta.org.au) (203.2.228.102) by gidora.zeta.org.au with SMTP; 11 Sep 2000 18:16:02 -0000 Date: Tue, 12 Sep 2000 05:15:59 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Kevin Van Maren Cc: darrenr@reed.wattle.id.au, smp@FreeBSD.ORG Subject: Re: atomic_{add,subtract} functions. In-Reply-To: <200009111526.JAA17010@fast.cs.utah.edu> 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, 11 Sep 2000, Kevin Van Maren wrote: > > I care, and plan to remove atomic_add_long(), since it should not be > > implementable at a non-heavy cost (longs should be twice as wide as > > registers). I hope to use atomic_op(lvalue) and generate an error at > > No, that's a "long long". A long is 64-bits on the alpha, whereas an > int is 32. Int and long are normally both 32 bits on x86. Long is abnormally 64 bits on x86-with-64-bit-longs :-). > > compile-time if `lvalue' is not inherently atomic. The current functions > > can't be used without knowing too much about the data type or writing > > spam like: > > > > if (sizeof(lvalue) == sizeof(char)) > > atomic_add_char(lvalue); > > else if (sizeof(lvalue) == sizeof(short)) > > atomic_add_short(lvalue); > > ... > Is it really a big deal to know what type the variable is you're > manipulating? Perhaps if it is in a structure definition defined by > the OS; but then maybe there is a better way to handle that. If it is a typedefed type then its underlying type is not obvious, and might be machine-dependent. > If datatypes are going to be defined as explicitly-sized ints, then > operations on explicitly-sized ints should be provided,. This can be handled by the same code that handles basic types. The details for both can be hidden in macro using a sizeof ladder like the above (except on exotic machines where the size of an integral type doesn't determine the type up to signedness). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Sep 11 12:36:23 2000 Delivered-To: freebsd-smp@freebsd.org Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (Postfix) with ESMTP id 3FAE037B423 for ; Mon, 11 Sep 2000 12:36:19 -0700 (PDT) Received: (from uucp@localhost) by isbalham.ist.co.uk (8.9.2/8.8.7) with UUCP id UAA38140; Mon, 11 Sep 2000 20:35:42 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from [194.32.164.2] (eccles [194.32.164.2]) by seagoon.gid.co.uk (8.9.3/8.9.3) with ESMTP id UAA17717; Mon, 11 Sep 2000 20:16:07 +0100 (BST) (envelope-from rb@gid.co.uk) X-Sender: rb@194.32.164.1 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Sep 2000 20:16:07 +0100 To: John Baldwin From: Bob Bishop Subject: Re: SMPng box wedges repeatably Cc: smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 11:07 -0700 11/9/00, John Baldwin wrote: >Bob Bishop wrote: >> Hi, >> >> Seems that I can repeatably wedge an MP box running SMPng (yesterday's >> -current) under the following conditions. It's doing a buildworld -j8 >> getting its sources via NFS from box B, its /usr/obj from box C and also >> NFS-serving /usr/obj for box C which is also buildworlding; so there's >> quite a lot of NFS activity. It's also running a couple of dnetcs. >> >> Symptoms are as if the scheduler is wedged: I can ping the box and get >> into DDB, but nothing is happening in userland. According to ps in DDB the >> dnetcs are runnable as are half a dozen shells presumably just spawned by >> make. Eveything else is waiting, a few in ffsvgt or inode, a bunch of >> shells in wait, a bunch of makes in select, ... > >What disk controller do you have? This is a known problem, but when we >looked at it, it so far has only happened with ahc SCSI controllers. When >it hangs, it seems the ahc driver is waiting for an interrupt that never >comes. As a result, any process that accesses the disk blocks forever. >It is triggered by heavy load situations such as you describe. It's a 2940UW, so yes, ahc. >> Anyone want more information from this corpse before I turn off its >> life-support? > >Check to see what wait channels processes are sleeping on. If a lot are >sleeping on biowait, it is probably the same problem. Not a one in biowait. Nearest I can offer is a couple of nfsd in biowr. As I said, I seem to have a repeatable scenario here so if you want anything else tried I can probably oblige. Can't offer you a crash dump this time around but I'll try next time. -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Sep 11 12:37:33 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-177-115.dsl.snfc21.pacbell.net [63.202.177.115]) by hub.freebsd.org (Postfix) with ESMTP id 5963937B423; Mon, 11 Sep 2000 12:37:27 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id MAA14055; Mon, 11 Sep 2000 12:36:41 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009111936.MAA14055@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: mjacob@feral.com Cc: Poul-Henning Kamp , arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Device probing... In-reply-to: Your message of "Mon, 11 Sep 2000 08:00:04 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Sep 2000 12:36:41 -0700 From: Mike Smith Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > The only theoretical problem with this is if you ever want to do a BOOT > driver based autoload mechanism. Currently FreeBSD has the ability to load > (preload) modules. If, in the future, you want to load modules after > loading a primary kernel object but before configuring your root device's > bus and driver stack, you need to do callbacks to a PROM driver. It's even > harder to do this if you've enabled interrupts (or even changed MMU > mappings, btw). Doing this on a PC is so problematic that the various PnP specifications that try to offload all of the resource management work onto the OS still talk about allocating resources for the "boot path". It's actually *extremely* difficult to do this, unless you have absolute knowledge of the mapping between "PROM device" and "kernel-space device". Consider the situation where you have initialised your disk driver, but want to use the "PROM driver" interface still to fetch another driver. Because (in the PC environment) you simply can't tell that the disk driver you've already initialised has taken over the hardware that the "PROM driver" path would use, you're stuck. In reality, this is less of an issue simply because most probing we do these days is entirely metainformation-based. How many of our probe routines actually do more than passive metainformation comparisons? > p.s.: FWIW, I'm *for* you doing this. I *hate* having to support polled mode > in drivers. I'm inclined to agree with this here. > On Sat, 9 Sep 2000, Poul-Henning Kamp wrote: > > > I would really like to se us move all the device probe/attach code > > to run in "normal context", ie enable interrupts before we probe > > everything. Most of the reasons for not doing this have gone away. We do need to re-order a few things though. Note that this will make it "interesting" if we want to support the interrupt hardware with "normal" drivers. > > The main argument for this is the drivers can then use the full > > complement of kernel infrastructure and interrupts during probe > > attach. > > > > Drivers needs to be able to function in this environment anyway > > if they support removeable devices (pccard, usb, etc). > > > > Are there reasons to not do this I have overlooked ? The biggest one that's left is that a lot of drivers will end up printing things in interrupt context, leading to *incredibly* messy console output. We'll need a cleaner way of presenting driver messages. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Sep 11 16:57:52 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id B96F237B42C; Mon, 11 Sep 2000 16:57:47 -0700 (PDT) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id BAA89671; Tue, 12 Sep 2000 01:57:45 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id BAA78528; Tue, 12 Sep 2000 01:57:45 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Tue, 12 Sep 2000 01:57:45 +0200 (CEST) From: Marius Bendiksen To: Mike Smith Cc: mjacob@feral.com, Poul-Henning Kamp , arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Device probing... In-Reply-To: <200009111936.MAA14055@mass.osd.bsdi.com> 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 > The biggest one that's left is that a lot of drivers will end up printing > things in interrupt context, leading to *incredibly* messy console > output. We'll need a cleaner way of presenting driver messages. Couldn't this be resolved by adding a console buffer which you could spool lines to, rather than printing them directly? The buffer would then sort a certain number of lines at a time, and print them grouped by driver. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Sep 11 16:59:22 2000 Delivered-To: freebsd-smp@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 9C9BB37B422; Mon, 11 Sep 2000 16:59:17 -0700 (PDT) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id QAA12781; Mon, 11 Sep 2000 16:59:12 -0700 Date: Mon, 11 Sep 2000 16:55:21 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Marius Bendiksen Cc: Mike Smith , Poul-Henning Kamp , arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Device probing... In-Reply-To: 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 Good idea, except it's hard to debug unless you have a working ddb or gdb or something (which is very rare these days for the machines I usually work on). > > The biggest one that's left is that a lot of drivers will end up printing > > things in interrupt context, leading to *incredibly* messy console > > output. We'll need a cleaner way of presenting driver messages. > > Couldn't this be resolved by adding a console buffer which you could spool > lines to, rather than printing them directly? The buffer would then sort a > certain number of lines at a time, and print them grouped by driver. > > > Marius > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Sep 12 3:34:44 2000 Delivered-To: freebsd-smp@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 443C837B423; Tue, 12 Sep 2000 03:34:38 -0700 (PDT) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id MAA21588; Tue, 12 Sep 2000 12:34:33 +0200 (CEST) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: mjacob@feral.com Cc: Marius Bendiksen , Mike Smith , Poul-Henning Kamp , arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Device probing... References: From: Dag-Erling Smorgrav Date: 12 Sep 2000 12:34:32 +0200 In-Reply-To: Matthew Jacob's message of "Mon, 11 Sep 2000 16:55:21 -0700 (PDT)" Message-ID: Lines: 9 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob writes: > Good idea, except it's hard to debug unless you have a working ddb or gdb or > something (which is very rare these days for the machines I usually work on). Make the message spooler conditional on DEBUG not being defined. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Sep 12 7:31: 9 2000 Delivered-To: freebsd-smp@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 42AA137B423; Tue, 12 Sep 2000 07:31:02 -0700 (PDT) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.0/8.9.3) with ESMTP id e8CEV1N78948; Tue, 12 Sep 2000 16:31:01 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: smp@freebsd.org, arch@freebsd.org Subject: system initialization order. From: Poul-Henning Kamp Date: Tue, 12 Sep 2000 16:31:01 +0200 Message-ID: <78946.968769061@critter> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org With SMPng I think we need to take a good hard stare at the order in which we initialize the system, a lot of the reasons behind the current order are invalid, and some new reasons for a new order are not honoured. Roughly speaking, I think we need something like this order: init console print copyright initialize VM/malloc(9) init other stuff needed for: setup proc0 setup proc1 (park it on a semaphore for now) setup idle procs enable scheduler init hardclock enable hardclock interrupt initialize timecounters This should now represent a sufficiently "normal" environment that the order of the rest doesn't really matter very much: init network protocols init pseudodrivers probe/attach real drivers ata/scsi delayed probing needs thought about here. locate & mount root let proc1 loose Comments ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Sep 12 8: 7:58 2000 Delivered-To: freebsd-smp@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id 6EC9137B424 for ; Tue, 12 Sep 2000 08:07:53 -0700 (PDT) Received: (qmail 24516 invoked from network); 12 Sep 2000 15:07:49 -0000 Received: from unknown (HELO bde.zeta.org.au) (203.2.228.102) by gidora.zeta.org.au with SMTP; 12 Sep 2000 15:07:49 -0000 Date: Wed, 13 Sep 2000 02:07:47 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Poul-Henning Kamp Cc: smp@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: system initialization order. In-Reply-To: <78946.968769061@critter> 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 Tue, 12 Sep 2000, Poul-Henning Kamp wrote: > With SMPng I think we need to take a good hard stare at the > order in which we initialize the system, a lot of the reasons > behind the current order are invalid, and some new reasons for > a new order are not honoured. > > Roughly speaking, I think we need something like this order: > > init console > print copyright > initialize VM/malloc(9) > init other stuff needed for: > setup proc0 > setup proc1 (park it on a semaphore for now) > setup idle procs > enable scheduler > init hardclock > enable hardclock interrupt Should be softclock (scheduler doesn't use hardclock). > initialize timecounters > > This should now represent a sufficiently "normal" environment that > the order of the rest doesn't really matter very much: I think this mainly moves clock initialization earlier. OK with me. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Sep 12 8: 8:27 2000 Delivered-To: freebsd-smp@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 5CC1A37B424; Tue, 12 Sep 2000 08:08:23 -0700 (PDT) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id IAA15394; Tue, 12 Sep 2000 08:08:16 -0700 Date: Tue, 12 Sep 2000 08:07:55 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Dag-Erling Smorgrav Cc: Marius Bendiksen , Mike Smith , Poul-Henning Kamp , arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Device probing... In-Reply-To: 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 One could do this. On 12 Sep 2000, Dag-Erling Smorgrav wrote: > Matthew Jacob writes: > > Good idea, except it's hard to debug unless you have a working ddb or gdb or > > something (which is very rare these days for the machines I usually work on). > > Make the message spooler conditional on DEBUG not being defined. > > DES > -- > Dag-Erling Smorgrav - des@ofug.org > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Sep 12 8:21:55 2000 Delivered-To: freebsd-smp@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 9491037B424; Tue, 12 Sep 2000 08:21:49 -0700 (PDT) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id IAA15455; Tue, 12 Sep 2000 08:21:49 -0700 Date: Tue, 12 Sep 2000 08:21:29 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Poul-Henning Kamp Cc: smp@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: system initialization order. In-Reply-To: <78946.968769061@critter> 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 > > With SMPng I think we need to take a good hard stare at the > order in which we initialize the system, a lot of the reasons > behind the current order are invalid, and some new reasons for > a new order are not honoured. > > Roughly speaking, I think we need something like this order: > > init console You can't init a real console w/o h/w. This has been the awful grotesque ugliness of the at least the alpha NetBSD && FreeBSD ports. Despite what Mike said in a different context, I have to say you will init a console early- using some kind of boot or throwaway driver- possibly even just a buffer to store output, until the real console can be initialized after, in *proper* order, the h/w for the real console is there. > print copyright > initialize VM/malloc(9) > init other stuff needed for: > setup proc0 > setup proc1 (park it on a semaphore for now) > setup idle procs > enable scheduler > init hardclock > enable hardclock interrupt > initialize timecounters > Fine, fine... > This should now represent a sufficiently "normal" environment that > the order of the rest doesn't really matter very much: > > init network protocols > init pseudodrivers In some cases pseudo drivers depend on real drivers, don't they? > probe/attach real drivers > > ata/scsi delayed probing needs thought about here. Yes. SCSI/FC more than ATA. Some thought might be given to avoiding complete evaluation here and doing what Solaris does instead which would allow you to parse a boot path and try and guess which specific device you need to get initialized. You don't to wait for 200 disks to probe if you can help it. > > locate & mount root > let proc1 loose > > Comments ? > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD coreteam member | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Sep 12 9:11:25 2000 Delivered-To: freebsd-smp@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id E810E37B43C for ; Tue, 12 Sep 2000 09:11:18 -0700 (PDT) Received: (qmail 29081 invoked from network); 12 Sep 2000 16:11:15 -0000 Received: from unknown (HELO bde.zeta.org.au) (203.2.228.102) by gidora.zeta.org.au with SMTP; 12 Sep 2000 16:11:15 -0000 Date: Wed, 13 Sep 2000 03:11:12 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Poul-Henning Kamp Cc: smp@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: system initialization order. In-Reply-To: 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 Wed, 13 Sep 2000, Bruce Evans wrote: > On Tue, 12 Sep 2000, Poul-Henning Kamp wrote: > >... > > init hardclock > > enable hardclock interrupt > > Should be softclock (scheduler doesn't use hardclock). Oops, statclock. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Sep 12 9:16:48 2000 Delivered-To: freebsd-smp@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 6E4B937B42C; Tue, 12 Sep 2000 09:16:44 -0700 (PDT) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.0/8.9.3) with ESMTP id e8CGGVN82449; Tue, 12 Sep 2000 18:16:31 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Bruce Evans Cc: smp@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: system initialization order. In-Reply-To: Your message of "Wed, 13 Sep 2000 03:11:12 +1100." Date: Tue, 12 Sep 2000 18:16:31 +0200 Message-ID: <82447.968775391@critter> From: Poul-Henning Kamp Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message , Bruce Evan s writes: >On Wed, 13 Sep 2000, Bruce Evans wrote: > >> On Tue, 12 Sep 2000, Poul-Henning Kamp wrote: >> >... >> > init hardclock >> > enable hardclock interrupt >> >> Should be softclock (scheduler doesn't use hardclock). > >Oops, statclock. Uhm, the point was to get the timeouts working, not to enable forced rescheduling... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Sep 12 9:37:22 2000 Delivered-To: freebsd-smp@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 1688A37B424 for ; Tue, 12 Sep 2000 09:37:20 -0700 (PDT) Received: (qmail 96725 invoked by uid 1142); 12 Sep 2000 16:37:14 -0000 Date: 12 Sep 2000 09:37:14 -0700 Date: Tue, 12 Sep 2000 09:37:06 -0700 From: Jason Evans To: smp@freebsd.org Subject: Recommended reading Message-ID: <20000912093706.E31089@blitz.canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org A number of people have voiced confusion about various threaded programming issues. I have a whole stack of books about threads programming, and one of those books sticks out as being quite good. Of course, it is concerned with pthreads, but the author is careful to explain the concepts before jumping into examples, so this book is useful even for kernel programmers who never set foot in user land. I didn't originally learn about threaded programming from this book, but I wish I had: Programming with POSIX Threads David R. Butenhof ISBN: 0-201-63392-2 Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Sep 12 13:29:14 2000 Delivered-To: freebsd-smp@freebsd.org Received: from irev.net (irev.net [63.101.244.233]) by hub.freebsd.org (Postfix) with ESMTP id 6E87137B423 for ; Tue, 12 Sep 2000 13:29:12 -0700 (PDT) Received: from netfinity (sherline.cts.com [204.216.163.132]) by irev.net (8.9.3/8.9.3) with SMTP id NAA32062; Tue, 12 Sep 2000 13:28:44 -0700 (PDT) (envelope-from jgowdy@home.com) Message-ID: <001101c01cf8$13555340$0100000a@netfinity> From: "Jeremiah Gowdy" To: "Jason Evans" , References: <20000912093706.E31089@blitz.canonware.com> Subject: Re: Recommended reading Date: Tue, 12 Sep 2000 13:28:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > A number of people have voiced confusion about various threaded programming > issues. I have a whole stack of books about threads programming, and one > of those books sticks out as being quite good. Of course, it is concerned > with pthreads, but the author is careful to explain the concepts before > jumping into examples, so this book is useful even for kernel programmers > who never set foot in user land. > > I didn't originally learn about threaded programming from this book, but I > wish I had: > > Programming with POSIX Threads > David R. Butenhof > ISBN: 0-201-63392-2 > > Jason Excellent, thank you. Book references are alway appriciated. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Sep 12 15:47: 6 2000 Delivered-To: freebsd-smp@freebsd.org Received: from brutus.conectiva.com.br (brutus.conectiva.com.br [200.250.58.146]) by hub.freebsd.org (Postfix) with ESMTP id AA36A37B424 for ; Tue, 12 Sep 2000 15:46:50 -0700 (PDT) Received: from localhost (riel@localhost) by brutus.conectiva.com.br (8.10.2/8.10.2) with ESMTP id e8CMkDH03552; Tue, 12 Sep 2000 19:46:13 -0300 X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs Date: Tue, 12 Sep 2000 19:46:13 -0300 (BRST) From: Rik van Riel X-Sender: riel@duckman.distro.conectiva To: The Hermit Hacker Cc: Samuka , freebsd-smp@FreeBSD.ORG Subject: Re: Old ALR-QSMP-Help In-Reply-To: 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 Thu, 7 Sep 2000, The Hermit Hacker wrote: > On Thu, 7 Sep 2000, Samuka wrote: > > > I have a ALR(Gateway today) QSMP w/ 4 processor pentium p54 166 Mhz, bus > > EISA/ISA, and I have try install FBsd r3.3 3.4 and 4.1 but it's failing > > every time when i enable the smp. The spec smp not is v1.4, maybe 1.1, i'm > > not sure.Somebody have some experience about this machine or could help me? > > I've got a bunch of dual's laying about at work that I'm running > FreeBSD/UP on right now ... would also be most interested in this ... Note that the ALR uses a custom (non-IMPS) bus. If only because that's the only way to keep 4 pentium CPUs in a cache-coherent state... The documentation for this glue logic seems to be very hard or impossible to find, some of the Linux SMP hackers I know have tried to get it and came up emptyhanded. (though I have no idea why they'd want to keep their old specs secret...) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Sep 12 16:31:28 2000 Delivered-To: freebsd-smp@freebsd.org Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by hub.freebsd.org (Postfix) with ESMTP id CEAA937B423 for ; Tue, 12 Sep 2000 16:31:24 -0700 (PDT) Received: from ahp (h006008cfc42a.ne.mediaone.net [24.128.185.247]) by chmls06.mediaone.net (8.8.7/8.8.7) with SMTP id TAA23462 for ; Tue, 12 Sep 2000 19:31:20 -0400 (EDT) From: "Allen Pulsifer" To: Subject: AOLserver's use of threads Date: Tue, 12 Sep 2000 19:31:16 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <001101c01cf8$13555340$0100000a@netfinity> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Enclosed FYI is a document written by Rob Mayoff, who has done a lot of work on AOLserver and is now employed by ArsDigita. I found it interested and thought I would pass it on. Allen ------------------------------------------------------------------------ ---- $Header: /cvsweb/aolserver/doc/threads.txt,v 1.1.1.1 2000/08/11 22:03:17 mayoff Exp $ Note On Thread Interfaces ------------------------- The implementation of the underlying thread interface can have a noticeable effect on the overall performance of AOLserver. While AOLserver runs on many platforms, not all platforms perform the same with the same hardware, e.g., the same Intel hardware provide very different throughput and latency on Linux and FreeBSD. A major influence on the overall performance is the scheduling scope of the thread library. Multithreading scope is often described as having a "1-1", "1-n", or "n-m" model. 1-1 means each thread is scheduled by the kernel along with all other threads. 1-n means one kernel thread is actually used by all process threads and thread context switching occurs in a user-level library. n-m means some number of kernel threads share the load of some larger number of process threads. The nature of the AOLserver workload (e.g., many simultaneous, I/O and system call bound threads) has shown that the 1-1 model generally works best. 1-n often does not provide enough concurrency and n-m introduces library overhead. In general the OS vendors go to great lengths to make sure the kernel scheduling algorithms perform very well under a variety of circumstance whereas library implementations are generally more simplistic in design, forced to share resources with many non-threaded processes, or require careful wrapping of many system calls with non-blocking I/O and signal handling. Heavily-loaded sites may realize better performance a change in configuration, e.g., upgrading to HP/11 from HP/10 or running SGI sproc-based nsd instead of the pthread-based nsd. However, this does not mean that 1-n or n-m platforms should be avoided or you should not run AOLserver unless your platform is 1-1. In general, if you experience reasonable performance you do not need to worry about the performance of the underlying thread library. In fact, there are cases where the 1-n or n-m model may outperform, e.g., code which is somewhat compute bound and subject to lock contention. The reason is a 1-n or n-m platform can switch threads when it encounters a held lock and continue to make progress whereas a 1-1 thread must have the kernel put the thread on a lower level wait queue, generally a more expensive operation. Another example is a large-scale hosting environment where many customers share a single machine. You may find better scalability with 1-n threads than 1-1 on the same hardware as each low-traffic customer would require a single Unix process instead of six or more for base operation. Listed below are the available and currently used threading models on each platform AOLserver runs on: Platform: Available: Used: Notes: Solaris, 1-1, n-m 1-1 1-1 appears to perform better. UnixWare Linux 1-1 1-1 clone()-based LinuxThreads. SGI pthread n-m n-m 1-1 currently cannot be enabled. SGI sproc 1-1 1-1 sproc-based custom interface often provides better performance then pthread-interface. HP/10 1-n 1-n Performs poorly under load. HP/11 1-1 1-1 n-m currently cannot be enabled. FreeBSD 1-n 1-n rfork()-based 1-1 interface may be available shortly. Apple OS/X ? ? Likely 1-1. DEC Unix 4.0 1-1, n-m n-m 1-1 can be enabled but blows up after many thread creates/exits. n-m model performs well. Windows NT 1-1 1-1 New Fiber() Win32 API may provide n-m in the future. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Sep 12 17:18: 8 2000 Delivered-To: freebsd-smp@freebsd.org Received: from adsl-63-192-211-186.dsl.snfc21.pacbell.net (adsl-63-192-211-186.dsl.snfc21.pacbell.net [63.192.211.186]) by hub.freebsd.org (Postfix) with ESMTP id 16E0237B424 for ; Tue, 12 Sep 2000 17:18:06 -0700 (PDT) Received: from localhost.minions.com (bifrost@localhost.minions.com [127.0.0.1]) by adsl-63-192-211-186.dsl.snfc21.pacbell.net (8.9.3/8.9.3) with ESMTP id RAA22373; Tue, 12 Sep 2000 17:16:06 -0700 (PDT) Date: Tue, 12 Sep 2000 17:16:06 -0700 (PDT) From: Tom To: Rik van Riel Cc: The Hermit Hacker , Samuka , freebsd-smp@FreeBSD.ORG Subject: Re: Old ALR-QSMP-Help In-Reply-To: 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 Tue, 12 Sep 2000, Rik van Riel wrote: > On Thu, 7 Sep 2000, The Hermit Hacker wrote: > > On Thu, 7 Sep 2000, Samuka wrote: > > > I have a ALR(Gateway today) QSMP w/ 4 processor pentium p54 166 Mhz, bus > > > EISA/ISA, and I have try install FBsd r3.3 3.4 and 4.1 but it's failing > > > every time when i enable the smp. The spec smp not is v1.4, maybe 1.1, i'm > > > not sure.Somebody have some experience about this machine or could help me? > Note that the ALR uses a custom (non-IMPS) bus. If > only because that's the only way to keep 4 pentium > CPUs in a cache-coherent state... How does BSD/OS support these puppies? While I realize that adding support just to support this machine would be illogical, maybe there's something easy that'll get imported from the BSD/OS codebase? Wasn't there something about P5's not being IMPS anyways? > The documentation for this glue logic seems to be > very hard or impossible to find, some of the Linux > SMP hackers I know have tried to get it and came > up emptyhanded. So you're saying Linux doesn't run on this box with SMP? --- Tom bifrost@minions.com "Where am I and why am I in this handbasket?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Sep 12 18: 8:20 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id 7255A37B43E; Tue, 12 Sep 2000 18:08:17 -0700 (PDT) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id DAA55937; Wed, 13 Sep 2000 03:08:15 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id DAA85526; Wed, 13 Sep 2000 03:08:15 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Wed, 13 Sep 2000 03:08:15 +0200 (CEST) From: Marius Bendiksen To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Device probing... In-Reply-To: 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 > > Good idea, except it's hard to debug unless you have a working ddb or gdb or > > something (which is very rare these days for the machines I usually work on). > Make the message spooler conditional on DEBUG not being defined. Rather, I think, make the buffering and sorting code conditional. Use the spooler anyway, but have it act mostly as a printf() passthrough when DEBUG is defined. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Sep 12 22:15:26 2000 Delivered-To: freebsd-smp@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id AFD0A37B422; Tue, 12 Sep 2000 22:15:22 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id XAA63052; Tue, 12 Sep 2000 23:15:21 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id XAA85122; Tue, 12 Sep 2000 23:14:54 -0600 (MDT) Message-Id: <200009130514.XAA85122@harmony.village.org> To: Poul-Henning Kamp Subject: Re: system initialization order. Cc: smp@FreeBSD.ORG, arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 12 Sep 2000 16:31:01 +0200." <78946.968769061@critter> References: <78946.968769061@critter> Date: Tue, 12 Sep 2000 23:14:54 -0600 From: Warner Losh Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <78946.968769061@critter> Poul-Henning Kamp writes: : probe/attach real drivers : : ata/scsi delayed probing needs thought about here. It would be highly desirable to allow for pccard/cardbus cards to become active here. : locate & mount root : let proc1 loose : : Comments ? It would be desirable if there's nothing to mount root on, that additional choices can become available. For example, if you are being prompted for the root device a card can be plugged in while you are waiting... It would be nice if the new system allows for this. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Sep 13 0:16:11 2000 Delivered-To: freebsd-smp@freebsd.org Received: from roaming.cacheboy.net (scorpio.arach.net.au [203.30.44.18]) by hub.freebsd.org (Postfix) with ESMTP id 9B18637B42C for ; Wed, 13 Sep 2000 00:16:07 -0700 (PDT) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.0/8.11.0) id eBE8CDI09947 for freebsd-smp@freebsd.org; Thu, 14 Dec 2000 09:12:13 +0100 (CET) (envelope-from adrian) Date: Thu, 14 Dec 2000 09:12:13 +0100 From: Adrian Chadd To: freebsd-smp@freebsd.org Subject: Re: Recommended reading Message-ID: <20001214091213.C4710@roaming.cacheboy.net> References: <20000912093706.E31089@blitz.canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20000912093706.E31089@blitz.canonware.com>; from jasone@canonware.com on Tue, Sep 12, 2000 at 09:37:06AM -0700 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Sep 12, 2000, Jason Evans wrote: > A number of people have voiced confusion about various threaded programming > issues. I have a whole stack of books about threads programming, and one > of those books sticks out as being quite good. Of course, it is concerned > with pthreads, but the author is careful to explain the concepts before > jumping into examples, so this book is useful even for kernel programmers > who never set foot in user land. > > I didn't originally learn about threaded programming from this book, but I > wish I had: > > Programming with POSIX Threads > David R. Butenhof > ISBN: 0-201-63392-2 .. which I have to say is an excellent book to learn threads from. Thanks for pointing this book out to me earlier Jason. Adrian -- Adrian Chadd "The main reason Santa is so jolly is because he knows where all the bad girls live." -- Random IRC quote To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Sep 13 5:52: 1 2000 Delivered-To: freebsd-smp@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 045F537B423 for ; Wed, 13 Sep 2000 05:51:56 -0700 (PDT) Received: from jules.elischer.org (reggae-12-112.nv.iinet.net.au [203.59.92.112]) by urban.iinet.net.au (8.8.7/8.8.7) with SMTP id UAA17470; Wed, 13 Sep 2000 20:51:46 +0800 Message-ID: <39BF785D.167EB0E7@elischer.org> Date: Wed, 13 Sep 2000 05:51:41 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Allen Pulsifer Cc: smp@FreeBSD.ORG Subject: Re: AOLserver's use of threads References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Allen Pulsifer wrote: > > Enclosed FYI is a document written by Rob Mayoff, who has done a lot of > work on AOLserver and is now employed by ArsDigita. I found it > interested and thought I would pass it on. several errors stand out.. > > Allen > > ------------------------------------------------------------------------ > ---- > $Header: /cvsweb/aolserver/doc/threads.txt,v 1.1.1.1 2000/08/11 22:03:17 > mayoff Exp $ > > > Platform: Available: Used: Notes: > > > FreeBSD 1-n 1-n rfork()-based 1-1 interface > may be available shortly. Obviously they COULD use the Linuxthreads port immediatly. > > Apple OS/X ? ? Likely 1-1. since it's based on MACH, it has n-m threads built in as a basic service. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Sep 13 10:33:23 2000 Delivered-To: freebsd-smp@freebsd.org Received: from digitalinet.com (digitalinet.com [216.65.124.130]) by hub.freebsd.org (Postfix) with SMTP id B555637B422 for ; Wed, 13 Sep 2000 10:33:17 -0700 (PDT) Received: (qmail 2571 invoked from network); 13 Sep 2000 17:33:12 -0000 Received: from unknown (HELO john) (24.96.19.19) by digitalinet.com with SMTP; 13 Sep 2000 17:33:12 -0000 Message-ID: <004e01c01da8$75d24680$03030303@john> From: "John" To: Subject: Smp instablility issues. Date: Wed, 13 Sep 2000 13:31:32 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01C01D86.EE3A5F80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_004B_01C01D86.EE3A5F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I am running the following hardware setup: Dual PIII 700E Tyan 1834 MB 3 128 dims & 1 258 dim all pc100 1 intel etherexpress pro nic 1 netgear fa310tx nic 1 ibm udma 66 7200 rpm hd 1 wd udma 66 7200 rpm hd When I try building a kernel when I am booted up on my custom kernel = with smp support I get signal 11's & or misc compiling errors like code = errors. When I boot a generic kernel which does not have smp support I = can compile a kernel. Also today my etherexpress pro signaled 11 & froze my machine. I then = had to turn it off & run fsck -y etc.. then reboot it. I dont know what to do. My smp settings are:=20 options SMP =20 options APIC_IO This is a real headache because this machine is a remote machine. When I = had the machine localy I had no problems that I can remember compiling a = kernel while being booted on a smp kernel. The thing that bothers me is the instability of the machine. Not the = fact that I cant compile a kernel. I would really apreatiate some help. Thanks, John ------=_NextPart_000_004B_01C01D86.EE3A5F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi I am running the following hardware=20 setup:
Dual PIII 700E
Tyan 1834 MB
3 128 dims & 1 258 dim all = pc100
1 intel etherexpress pro = nic
1 netgear fa310tx nic
1 ibm udma 66 7200 rpm hd
1 wd udma 66 7200 rpm hd
 
When I try building a kernel when = I am booted=20 up on my custom kernel with smp support I get signal 11's & or misc=20 compiling errors like code errors. When I boot a generic kernel which = does not=20 have smp support I can compile a kernel.
 
Also today my etherexpress pro signaled = 11 &=20 froze my machine. I then had to turn it off & run fsck -y etc.. = then=20 reboot it.
 
I dont know what to do. My smp settings = are:=20
options         = SMP =20
options        =20 APIC_IO
 
This is a real headache because this = machine is a=20 remote machine. When I had the machine localy I had no problems that I = can=20 remember compiling a kernel while being booted on a smp = kernel.
 
The thing that bothers me is the = instability of the=20 machine. Not the fact that I cant compile a kernel.
I would really apreatiate some = help.
 
Thanks,
John
------=_NextPart_000_004B_01C01D86.EE3A5F80-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Sep 13 10:37:26 2000 Delivered-To: freebsd-smp@freebsd.org Received: from isris.pair.com (isris.pair.com [209.68.2.39]) by hub.freebsd.org (Postfix) with ESMTP id 6025837B423 for ; Wed, 13 Sep 2000 10:37:24 -0700 (PDT) Received: (from rooneg@localhost) by isris.pair.com (8.9.1/8.6.12) id NAA21845; Wed, 13 Sep 2000 13:37:23 -0400 (EDT) X-Envelope-To: freebsd-smp@FreeBSD.ORG Message-ID: <20000913133723.A19690@electricjellyfish.net> Date: Wed, 13 Sep 2000 13:37:23 -0400 From: Garrett Rooney To: freebsd-smp@FreeBSD.ORG Subject: Re: Smp instablility issues. Mail-Followup-To: freebsd-smp@FreeBSD.ORG References: <004e01c01da8$75d24680$03030303@john> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <004e01c01da8$75d24680$03030303@john>; from John on Wed, Sep 13, 2000 at 01:31:32PM -0400 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Sep 13, 2000 at 01:31:32PM -0400, John wrote: > Hi I am running the following hardware setup: > Dual PIII 700E > Tyan 1834 MB > 3 128 dims & 1 258 dim all pc100 > 1 intel etherexpress pro nic > 1 netgear fa310tx nic > 1 ibm udma 66 7200 rpm hd > 1 wd udma 66 7200 rpm hd you might have better luck with responses if you mention what version of FreeBSD you are running. how you know your etherexpress card sig 11'd your system would be useful as well. the actual error messages are important. -- garrett rooney my pid is inigo montoya. rooneg@electricjellyfish.net you kill -9 my parent process. http://electricjellyfish.net/ prepare to vi. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Sep 13 10:37:45 2000 Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 5636237B422 for ; Wed, 13 Sep 2000 10:37:43 -0700 (PDT) Received: (from jhb@localhost) by pike.osd.bsdi.com (8.9.3/8.9.3) id KAA38755; Wed, 13 Sep 2000 10:37:35 -0700 (PDT) (envelope-from jhb) From: John Baldwin Message-Id: <200009131737.KAA38755@pike.osd.bsdi.com> Subject: Re: Smp instablility issues. In-Reply-To: <004e01c01da8$75d24680$03030303@john> from John at "Sep 13, 2000 01:31:32 pm" To: John Date: Wed, 13 Sep 2000 10:37:35 -0700 (PDT) Cc: freebsd-smp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL68 (25)] 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 John wrote: [Charset iso-8859-1 unsupported, filtering to ASCII...] > Hi I am running the following hardware setup: > Dual PIII 700E > Tyan 1834 MB > 3 128 dims & 1 258 dim all pc100 > 1 intel etherexpress pro nic > 1 netgear fa310tx nic > 1 ibm udma 66 7200 rpm hd > 1 wd udma 66 7200 rpm hd > > When I try building a kernel when I am booted up on my custom kernel with smp support I get signal 11's & or misc compiling errors like code errors. When I boot a generic kernel which does not have smp support I can compile a kernel. This is usually indicative of bad hardware. With SMP you are probably working some of your hardware just a bit more and/or generating a bit more heat in the machine, and apparently that is enough to cause your hardware to fail. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Sep 13 10:41:49 2000 Delivered-To: freebsd-smp@freebsd.org Received: from digitalinet.com (digitalinet.com [216.65.124.130]) by hub.freebsd.org (Postfix) with SMTP id F105337B42C for ; Wed, 13 Sep 2000 10:41:46 -0700 (PDT) Received: (qmail 3689 invoked from network); 13 Sep 2000 17:41:46 -0000 Received: from unknown (HELO john) (24.96.19.19) by digitalinet.com with SMTP; 13 Sep 2000 17:41:46 -0000 Message-ID: <000b01c01da9$a81e2400$03030303@john> From: "John" To: "Garrett Rooney" , References: <004e01c01da8$75d24680$03030303@john> <20000913133723.A19690@electricjellyfish.net> Subject: Re: Smp instablility issues. Date: Wed, 13 Sep 2000 13:40:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am running freebsd 4.0-RELEASE. I was not running syslogd when the intel card signaled 11 on me therefore I cant get the error. BTW: The machine runs fairly cold. The ram in it has been in a k62 server for around 5 months. Thanks for your help so far, John ----- Original Message ----- From: "Garrett Rooney" To: Sent: Wednesday, September 13, 2000 1:37 PM Subject: Re: Smp instablility issues. > On Wed, Sep 13, 2000 at 01:31:32PM -0400, John wrote: > > Hi I am running the following hardware setup: > > Dual PIII 700E > > Tyan 1834 MB > > 3 128 dims & 1 258 dim all pc100 > > 1 intel etherexpress pro nic > > 1 netgear fa310tx nic > > 1 ibm udma 66 7200 rpm hd > > 1 wd udma 66 7200 rpm hd > > you might have better luck with responses if you mention what version of > FreeBSD you are running. > > how you know your etherexpress card sig 11'd your system would be useful > as well. the actual error messages are important. > > -- > garrett rooney my pid is inigo montoya. > rooneg@electricjellyfish.net you kill -9 my parent process. > http://electricjellyfish.net/ prepare to vi. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Sep 13 10:46:29 2000 Delivered-To: freebsd-smp@freebsd.org Received: from theartofwar.org (adslppp17.tcsn.uswest.net [216.161.144.17]) by hub.freebsd.org (Postfix) with SMTP id B880237B424 for ; Wed, 13 Sep 2000 10:46:26 -0700 (PDT) Received: (qmail 26312 invoked from network); 13 Sep 2000 17:46:26 -0000 Received: from unknown (HELO theartofwar.org) (10.0.0.5) by 10.0.0.3 with SMTP; 13 Sep 2000 17:46:26 -0000 Message-ID: <39BFBD8B.74CF2257@theartofwar.org> Date: Wed, 13 Sep 2000 10:46:51 -0700 From: Hartoyo X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Smp instablility issues. References: <200009131737.KAA38755@pike.osd.bsdi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John Baldwin wrote: > John wrote: > [Charset iso-8859-1 unsupported, filtering to ASCII...] > > Hi I am running the following hardware setup: > > Dual PIII 700E > > Tyan 1834 MB > > 3 128 dims & 1 258 dim all pc100 > > 1 intel etherexpress pro nic > > 1 netgear fa310tx nic > > 1 ibm udma 66 7200 rpm hd > > 1 wd udma 66 7200 rpm hd > > > > When I try building a kernel when I am booted up on my custom kernel with smp support I get signal 11's & or misc compiling errors like code errors. When I boot a generic kernel which does not have smp support I can compile a kernel. > > This is usually indicative of bad hardware. With SMP you are probably working > some of your hardware just a bit more and/or generating a bit more heat in > the machine, and apparently that is enough to cause your hardware to fail. agree... got the same experience like this on my Dell Precision 410 (dual P3-550 under 4.0-RELEASE)... system crashed without any reason under SMP kernel (UP kernel seems more stable - but still crashed)... turn out to be a loose heat sink clip (cheap heat sink sucks!)... I changed the heat sink, works great without any problem now! =) Please check your hardware setup first, especially processor cooling device (fan, heat sink, etc)... good luck! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Sep 13 10:46:53 2000 Delivered-To: freebsd-smp@freebsd.org Received: from digitalinet.com (digitalinet.com [216.65.124.130]) by hub.freebsd.org (Postfix) with SMTP id 259D937B422 for ; Wed, 13 Sep 2000 10:46:50 -0700 (PDT) Received: (qmail 6022 invoked from network); 13 Sep 2000 17:46:49 -0000 Received: from unknown (HELO john) (24.96.19.19) by digitalinet.com with SMTP; 13 Sep 2000 17:46:49 -0000 Message-ID: <000501c01daa$5c921fe0$03030303@john> From: "John" To: References: <200009131737.KAA38755@pike.osd.bsdi.com> Subject: Re: Smp instablility issues. Date: Wed, 13 Sep 2000 13:45:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I did make after make depend for a kernel then got: In file included from machine/signal.h:48, from ../../sys/signal.h:171, from ../../sys/proc.h:50, from ../../vm/vm_map.c:73: machine/trap.h:37: syntax error before `*' In file included from ../../sys/signal.h:171, from ../../sys/proc.h:50, from ../../vm/vm_map.c:73: machine/signal.h:61: syntax error before `osigset_t' *** Error code 1 Then I did make again and got: In file included from ../../vm/vnode_pager.c:69: ../../vm/vm_extern.h:88: syntax error before `vm_offset_t' ../../vm/vm_extern.h:88: warning: function declaration isn't a prototype *** Error code 1 Then I did make again and got: make: don't know how to make \. Stop But the word "Stop" looked like asci or some wierd charicter. Then what ever I typed in my console would be like acsi/binary etc. I had to relogin. Thanks, John ----- Original Message ----- From: "John Baldwin" To: "John" Cc: Sent: Wednesday, September 13, 2000 1:37 PM Subject: Re: Smp instablility issues. > John wrote: > [Charset iso-8859-1 unsupported, filtering to ASCII...] > > Hi I am running the following hardware setup: > > Dual PIII 700E > > Tyan 1834 MB > > 3 128 dims & 1 258 dim all pc100 > > 1 intel etherexpress pro nic > > 1 netgear fa310tx nic > > 1 ibm udma 66 7200 rpm hd > > 1 wd udma 66 7200 rpm hd > > > > When I try building a kernel when I am booted up on my custom kernel with smp support I get signal 11's & or misc compiling errors like code errors. When I boot a generic kernel which does not have smp support I can compile a kernel. > > This is usually indicative of bad hardware. With SMP you are probably working > some of your hardware just a bit more and/or generating a bit more heat in > the machine, and apparently that is enough to cause your hardware to fail. > > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Sep 13 10:48:56 2000 Delivered-To: freebsd-smp@freebsd.org Received: from ricky.ssg.gunter.af.mil (RICKY.SSG.Gunter.AF.mil [143.158.254.14]) by hub.freebsd.org (Postfix) with ESMTP id 98DA737B422 for ; Wed, 13 Sep 2000 10:48:51 -0700 (PDT) Received: from ricky.ssg.gunter.af.mil (root@localhost) by ricky.ssg.gunter.af.mil with ESMTP id MAA23746 for ; Wed, 13 Sep 2000 12:49:07 -0500 (CDT) From: John.Hubbard@Gunter.AF.mil Received: from fsjubj02.ssg.gunter.af.mil (fsjubj02.ssg.gunter.af.mil [143.158.126.102]) by ricky.ssg.gunter.af.mil with ESMTP id MAA23740 for ; Wed, 13 Sep 2000 12:49:07 -0500 (CDT) Received: by fsjubj02.ssg.gunter.af.mil with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Sep 2000 12:48:40 -0500 Message-ID: To: john@digitalinet.com, rooneg@electricjellyfish.net, freebsd-smp@FreeBSD.ORG Subject: RE: Smp instablility issues. Date: Wed, 13 Sep 2000 12:48:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Just as a note, I have a Compaq Proliant 6500 (Dual Xeon, etc.,etc.) that always signal 11'd when I tried to boot an SMP kernel. I swapped the Intel NIC out for a 3com one and it worked fine. It was one of those 2 port cards though, and I think that was the problem. If you have a spare NIC lying around you might want to give it a try. -----Original Message----- From: John [mailto:john@digitalinet.com] Sent: Wednesday, September 13, 2000 12:40 PM To: Garrett Rooney; freebsd-smp@FreeBSD.ORG Subject: Re: Smp instablility issues. I am running freebsd 4.0-RELEASE. I was not running syslogd when the intel card signaled 11 on me therefore I cant get the error. BTW: The machine runs fairly cold. The ram in it has been in a k62 server for around 5 months. Thanks for your help so far, John ----- Original Message ----- From: "Garrett Rooney" To: Sent: Wednesday, September 13, 2000 1:37 PM Subject: Re: Smp instablility issues. > On Wed, Sep 13, 2000 at 01:31:32PM -0400, John wrote: > > Hi I am running the following hardware setup: > > Dual PIII 700E > > Tyan 1834 MB > > 3 128 dims & 1 258 dim all pc100 > > 1 intel etherexpress pro nic > > 1 netgear fa310tx nic > > 1 ibm udma 66 7200 rpm hd > > 1 wd udma 66 7200 rpm hd > > you might have better luck with responses if you mention what version of > FreeBSD you are running. > > how you know your etherexpress card sig 11'd your system would be useful > as well. the actual error messages are important. > > -- > garrett rooney my pid is inigo montoya. > rooneg@electricjellyfish.net you kill -9 my parent process. > http://electricjellyfish.net/ prepare to vi. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Sep 13 11:30:39 2000 Delivered-To: freebsd-smp@freebsd.org Received: from digitalinet.com (digitalinet.com [216.65.124.130]) by hub.freebsd.org (Postfix) with SMTP id 0706937B422 for ; Wed, 13 Sep 2000 11:30:35 -0700 (PDT) Received: (qmail 21057 invoked from network); 13 Sep 2000 18:30:30 -0000 Received: from unknown (HELO john) (24.96.19.19) by digitalinet.com with SMTP; 13 Sep 2000 18:30:30 -0000 Message-ID: <002701c01db0$77077180$03030303@john> From: "John" To: , , References: Subject: Re: Smp instablility issues. Date: Wed, 13 Sep 2000 14:28:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I removed the intel etherexpress. I will do some testing now. I have a dc netgear fa310tx in there which is a reliable card. Thanks, John ----- Original Message ----- From: To: ; ; Sent: Wednesday, September 13, 2000 1:48 PM Subject: RE: Smp instablility issues. > Just as a note, I have a Compaq Proliant 6500 (Dual Xeon, etc.,etc.) that > always signal 11'd when I tried to boot an SMP kernel. I swapped the Intel > NIC out for a 3com one and it worked fine. It was one of those 2 port cards > though, and I think that was the problem. If you have a spare NIC lying > around you might want to give it a try. > > -----Original Message----- > From: John [mailto:john@digitalinet.com] > Sent: Wednesday, September 13, 2000 12:40 PM > To: Garrett Rooney; freebsd-smp@FreeBSD.ORG > Subject: Re: Smp instablility issues. > > > I am running freebsd 4.0-RELEASE. > I was not running syslogd when the intel card signaled 11 on me therefore I > cant get the error. > > BTW: The machine runs fairly cold. > The ram in it has been in a k62 server for around 5 months. > > Thanks for your help so far, > John > ----- Original Message ----- > From: "Garrett Rooney" > To: > Sent: Wednesday, September 13, 2000 1:37 PM > Subject: Re: Smp instablility issues. > > > > On Wed, Sep 13, 2000 at 01:31:32PM -0400, John wrote: > > > Hi I am running the following hardware setup: > > > Dual PIII 700E > > > Tyan 1834 MB > > > 3 128 dims & 1 258 dim all pc100 > > > 1 intel etherexpress pro nic > > > 1 netgear fa310tx nic > > > 1 ibm udma 66 7200 rpm hd > > > 1 wd udma 66 7200 rpm hd > > > > you might have better luck with responses if you mention what version of > > FreeBSD you are running. > > > > how you know your etherexpress card sig 11'd your system would be useful > > as well. the actual error messages are important. > > > > -- > > garrett rooney my pid is inigo montoya. > > rooneg@electricjellyfish.net you kill -9 my parent process. > > http://electricjellyfish.net/ prepare to vi. > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-smp" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Sep 13 11:37:10 2000 Delivered-To: freebsd-smp@freebsd.org Received: from digitalinet.com (digitalinet.com [216.65.124.130]) by hub.freebsd.org (Postfix) with SMTP id 5214237B422 for ; Wed, 13 Sep 2000 11:37:06 -0700 (PDT) Received: (qmail 43753 invoked from network); 13 Sep 2000 18:37:05 -0000 Received: from unknown (HELO john) (24.96.19.19) by digitalinet.com with SMTP; 13 Sep 2000 18:37:05 -0000 Message-ID: <000b01c01db1$62b638a0$03030303@john> From: "John" To: References: Subject: Additional Smp instablility issues. Date: Wed, 13 Sep 2000 14:35:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org gcc: Internal compiler error: program as got fatal signal 11 /kernel: pid 43462 (as), uid 0: exited on signal 11 (core dumped) Thats when trying to compile php. About 5 minutes before getting that error I compiled it with no problems at all. I checked my cpu's for heat and they are cold. Hopefully some one can give me some input. Thanks, John ----- Original Message ----- From: To: ; ; Sent: Wednesday, September 13, 2000 1:48 PM Subject: RE: Smp instablility issues. > Just as a note, I have a Compaq Proliant 6500 (Dual Xeon, etc.,etc.) that > always signal 11'd when I tried to boot an SMP kernel. I swapped the Intel > NIC out for a 3com one and it worked fine. It was one of those 2 port cards > though, and I think that was the problem. If you have a spare NIC lying > around you might want to give it a try. > > -----Original Message----- > From: John [mailto:john@digitalinet.com] > Sent: Wednesday, September 13, 2000 12:40 PM > To: Garrett Rooney; freebsd-smp@FreeBSD.ORG > Subject: Re: Smp instablility issues. > > > I am running freebsd 4.0-RELEASE. > I was not running syslogd when the intel card signaled 11 on me therefore I > cant get the error. > > BTW: The machine runs fairly cold. > The ram in it has been in a k62 server for around 5 months. > > Thanks for your help so far, > John > ----- Original Message ----- > From: "Garrett Rooney" > To: > Sent: Wednesday, September 13, 2000 1:37 PM > Subject: Re: Smp instablility issues. > > > > On Wed, Sep 13, 2000 at 01:31:32PM -0400, John wrote: > > > Hi I am running the following hardware setup: > > > Dual PIII 700E > > > Tyan 1834 MB > > > 3 128 dims & 1 258 dim all pc100 > > > 1 intel etherexpress pro nic > > > 1 netgear fa310tx nic > > > 1 ibm udma 66 7200 rpm hd > > > 1 wd udma 66 7200 rpm hd > > > > you might have better luck with responses if you mention what version of > > FreeBSD you are running. > > > > how you know your etherexpress card sig 11'd your system would be useful > > as well. the actual error messages are important. > > > > -- > > garrett rooney my pid is inigo montoya. > > rooneg@electricjellyfish.net you kill -9 my parent process. > > http://electricjellyfish.net/ prepare to vi. > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-smp" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Sep 13 11:40:39 2000 Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id E20F637B424 for ; Wed, 13 Sep 2000 11:40:37 -0700 (PDT) Received: (from jhb@localhost) by pike.osd.bsdi.com (8.9.3/8.9.3) id LAA42013; Wed, 13 Sep 2000 11:40:16 -0700 (PDT) (envelope-from jhb) From: John Baldwin Message-Id: <200009131840.LAA42013@pike.osd.bsdi.com> Subject: Re: Additional Smp instablility issues. In-Reply-To: <000b01c01db1$62b638a0$03030303@john> from John at "Sep 13, 2000 02:35:25 pm" To: John Date: Wed, 13 Sep 2000 11:40:16 -0700 (PDT) Cc: freebsd-smp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL68 (25)] 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 John wrote: [Charset iso-8859-1 unsupported, filtering to ASCII...] > gcc: Internal compiler error: program as got fatal signal 11 > /kernel: pid 43462 (as), uid 0: exited on signal 11 (core dumped) Sig 11 means it referencing an invalid memory address. Since this isn't reproducible on anyone else's system, this is not a software bug. > Thats when trying to compile php. About 5 minutes before getting that error > I compiled it with no problems at all. > > I checked my cpu's for heat and they are cold. Hopefully some one can give > me some input. Try swapping in new memory for the old, and if that doesn't work try swapping in one CPU for the other. It could also be that your second CPU is marginal, and that you only see problems with SMP because you don't use it until then. > Thanks, > John -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Sep 13 13: 7:37 2000 Delivered-To: freebsd-smp@freebsd.org Received: from brutus.conectiva.com.br (brutus.conectiva.com.br [200.250.58.146]) by hub.freebsd.org (Postfix) with ESMTP id 883A537B422 for ; Wed, 13 Sep 2000 13:07:26 -0700 (PDT) Received: from localhost (riel@localhost) by brutus.conectiva.com.br (8.10.2/8.10.2) with ESMTP id e8DK6Am01121; Wed, 13 Sep 2000 17:06:13 -0300 X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs Date: Wed, 13 Sep 2000 17:06:10 -0300 (BRST) From: Rik van Riel X-Sender: riel@duckman.distro.conectiva To: Tom Cc: The Hermit Hacker , Samuka , freebsd-smp@FreeBSD.ORG Subject: Re: Old ALR-QSMP-Help In-Reply-To: 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 Tue, 12 Sep 2000, Tom wrote: > On Tue, 12 Sep 2000, Rik van Riel wrote: > > On Thu, 7 Sep 2000, The Hermit Hacker wrote: > > > On Thu, 7 Sep 2000, Samuka wrote: > > > > I have a ALR(Gateway today) QSMP w/ 4 processor pentium p54 166 Mhz, bus > > > > EISA/ISA, and I have try install FBsd r3.3 3.4 and 4.1 but it's failing > > > > every time when i enable the smp. The spec smp not is v1.4, maybe 1.1, i'm > > > > not sure.Somebody have some experience about this machine or could help me? > > > Note that the ALR uses a custom (non-IMPS) bus. If > > only because that's the only way to keep 4 pentium > > CPUs in a cache-coherent state... > > How does BSD/OS support these puppies? > While I realize that adding support just to support this machine > would be illogical, maybe there's something easy that'll get > imported from the BSD/OS codebase? Adding support for just those machines shouldn't be a problem as long as it doesn't bloat the normal code base. Linux has (well, had) support for SGI VisWS that didn't have any influence on the standard code base. [Had because nobody has bothered to maintain the code past the previous SMP changes] > Wasn't there something about P5's not being IMPS anyways? The DUAL ones definately seem to be IMPS. Unless I'm mistaken the one sitting next to me is ;) > > The documentation for this glue logic seems to be > > very hard or impossible to find, some of the Linux > > SMP hackers I know have tried to get it and came > > up emptyhanded. > > So you're saying Linux doesn't run on this box with SMP? Not that I know, no. But if BSDi can publish the code they're using for those machines, I guess the lack of documentation problem is solved ;) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Sep 13 14:49:53 2000 Delivered-To: freebsd-smp@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2800B37B424 for ; Wed, 13 Sep 2000 14:49:51 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id RAA37597; Wed, 13 Sep 2000 17:49:43 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 13 Sep 2000 17:49:42 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Jason Evans Cc: smp@freebsd.org Subject: Re: Recommended reading In-Reply-To: <20000912093706.E31089@blitz.canonware.com> 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 And for those interested who isn't subscribed to -arch but likes to search archives, I posted some paper references on -arch this morning which are fairly decent, especially the Birrell one. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Sep 13 17:14:44 2000 Delivered-To: freebsd-smp@freebsd.org Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by hub.freebsd.org (Postfix) with ESMTP id 8D09C37B424 for ; Wed, 13 Sep 2000 17:14:41 -0700 (PDT) Received: from cx443070b ([24.0.36.170]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20000914001401.QUKM2358.femail3.sdc1.sfba.home.com@cx443070b> for ; Wed, 13 Sep 2000 17:14:01 -0700 Message-ID: <001101c01de0$ee094a80$aa240018@cx443070b> From: "Jeremiah Gowdy" To: References: <200009131737.KAA38755@pike.osd.bsdi.com> <39BFBD8B.74CF2257@theartofwar.org> Subject: freebsdsmp.com Date: Wed, 13 Sep 2000 17:15:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Anyone who's actually coding for the SMP project interested in freebsdsmp.com ? I just registered it. I figure it would make a good page to summerize the SMP rewrite project and link to the programmer's pages. Anyone interested please contact me. Thanks :) oh, btw, I guess it may look like I'm some ass who wants to try to sell a domain name or something. Nothing of the sort. I'll either host the site, if I have enough bandwidth available, or set the nameserver to someone else's site. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Sep 14 0:57:50 2000 Delivered-To: freebsd-smp@freebsd.org Received: from charles.dircon.net (charles.dircon.net [195.157.2.129]) by hub.freebsd.org (Postfix) with ESMTP id 22DA637B43C for ; Thu, 14 Sep 2000 00:57:43 -0700 (PDT) Received: from diablo.dircon.net (desk108.ch.dircon.net [195.157.3.108]) by charles.dircon.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id RWA3QVPA; Thu, 14 Sep 2000 08:58:25 +0100 Received: from dircon.net (localhost [127.0.0.1]) by diablo.dircon.net (Postfix) with ESMTP id 38F9E1B222; Thu, 14 Sep 2000 08:57:36 +0100 (BST) From: "Mark Blackman" To: Todd Mortensen Cc: "'mark.blackman@dircon.net'" , "'freebsd-smp@freebsd.org'" Subject: Re: Compaq 360 with SMP In-Reply-To: Message from Todd Mortensen of "Wed, 13 Sep 2000 15:49:37 PDT." MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <62785.968918225.0@dircon.net> Date: Thu, 14 Sep 2000 08:57:36 +0100 Message-Id: <20000914075736.38F9E1B222@diablo.dircon.net> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <62785.968918225.1@dircon.net> I didn't actually do the configuration (a colleague did), but I'm pretty sure he chose "Unixware 7" and no re-install was required. I'll include the config file as well here. > I have been following your thread on freebsd-smp about your problems with > with smp hanging the machine. > > We have the same hardware as you and are haveing the exact same problem you > where having. > > You said you fixed this by Choosing Unixware for the primary operating > system in the SmartStart configuration utility, Did you choose unixware 7 > or 2.1 ?? > And was it necisarry for you to reinstall your os after choosing this ? > Any info would greatly be appreciated. > ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <62785.968918225.2@dircon.net> # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246.2.8 2000/07/20 02:51:02 msmith Exp $ machine i386 #cpu I386_CPU #cpu I486_CPU cpu I586_CPU cpu I686_CPU ident DL360 maxusers 128 #makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols #options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking #options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options MFS #Memory Filesystem #options MD_ROOT #MD is a potential root device #options NFS #Network Filesystem #options NFS_ROOT #NFS usable as root device, NFS required #options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem #options CD9660_ROOT #CD-ROM usable as root, CD9660 required options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000 #Delay (in ms) before probing SCSI options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B #Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM #Rate limit bad replies options KBD_INSTALL_CDEV # install a CDEV entry in /dev # To make an SMP kernel, the next two are needed options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Optionally these may need tweaked, (defaults shown): options NCPU=2 # number of CPUs #options NBUS=4 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=35 # number of INTs device isa device eisa device pci # Floppy drives device fdc0 at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 #device fd1 at fdc0 drive 1 # ATA and ATAPI devices device ata0 at isa? port IO_WD1 irq 14 device ata1 at isa? port IO_WD2 irq 15 device ata #device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering #options ATA_ENABLE_ATAPI_DMA #Enable DMA on ATAPI devices # SCSI Controllers #device ahb # EISA AHA1742 family #device ahc # AHA2940 and onboard AIC7xxx devices #device amd # AMD 53C974 (Teckram DC-390(T)) #device dpt # DPT Smartcache - See LINT for options! #device isp # Qlogic family #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets) #options SYM_SETUP_LP_PROBE_MAP=0x40 # Allow ncr to attach legacy NCR devices when # both sym and ncr are configured #device adv0 at isa? #device adw #device bt0 at isa? #device aha0 at isa? #device aic0 at isa? # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) # RAID controllers device ida # Compaq Smart RAID #device amr # AMI MegaRAID #device mlx # Mylex DAC960 family #device twe # 3ware Escalade # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 flags 0x1 device psm0 at atkbdc? irq 12 device vga0 at isa? # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? flags 0x100 # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines #options PCVT_SCANSET=2 # IBM keyboards are non-std # Floating point support - do not disable. device npx0 at nexus? port IO_NPX irq 13 # Power management support (see LINT for more options) #device apm0 at nexus? disable flags 0x20 # Advanced Power Management # PCCARD (PCMCIA) support #device card #device pcic0 at isa? irq 10 port 0x3e0 iomem 0xd0000 #device pcic1 at isa? irq 11 port 0x3e2 iomem 0xd4000 disable # Serial (COM) ports device sio0 at isa? port IO_COM1 flags 0x10 irq 4 device sio1 at isa? port IO_COM2 irq 3 #device sio2 at isa? disable port IO_COM3 irq 5 #device sio3 at isa? disable port IO_COM4 irq 9 # Parallel port #device ppc0 at isa? irq 7 #device ppbus # Parallel port bus (required) #device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device #device vpo # Requires scbus and da # PCI Ethernet NICs. #device de # DEC/Intel DC21x4x (``Tulip'') device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device tx # SMC 9432TX (83c170 ``EPIC'') #device vx # 3Com 3c590, 3c595 (``Vortex'') #device wx # Intel Gigabit Ethernet Card (``Wiseman'') # PCI Ethernet NICs that use the common MII bus controller code. #device miibus # MII bus support #device dc # DEC/Intel 21143 and various workalikes #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device ste # Sundance ST201 (D-Link DFE-550TX) #device tl # Texas Instruments ThunderLAN #device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F #device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. #device ed0 at isa? port 0x280 irq 10 iomem 0xd8000 #device ex #device ep # WaveLAN/IEEE 802.11 wireless NICs. Note: the WaveLAN/IEEE really # exists only as a PCMCIA device, so there is no ISA attatement needed # and resources will always be dynamically assigned by the pccard code. #device wi # Aironet 4500/4800 802.11 wireless NICs. Note: the declaration below will # work for PCMCIA and PCI cards, as well as ISA cards set to ISA PnP # mode (the factory default). If you set the switches on your ISA # card for a manually chosen I/O address and IRQ, you must specify # those paremeters here. #device an # Xircom Ethernet #device xe # The probe order of these is presently determined by i386/isa/isa_compat.c. #device ie0 at isa? port 0x300 irq 10 iomem 0xd0000 #device fe0 at isa? port 0x300 #device le0 at isa? port 0x300 irq 5 iomem 0xd0000 #device lnc0 at isa? port 0x280 irq 10 drq 0 #device cs0 at isa? port 0x300 #device sn0 at isa? port 0x300 irq 10 # Pseudo devices - the number indicates how many units to allocated. pseudo-device loop # Network loopback pseudo-device ether # Ethernet support #pseudo-device sl 1 # Kernel SLIP #pseudo-device ppp 1 # Kernel PPP #pseudo-device tun # Packet tunnel. pseudo-device pty # Pseudo-ttys (telnet etc) #pseudo-device md # Memory "disks" #pseudo-device gif 4 # IPv6 and IPv4 tunneling #pseudo-device faith 1 # IPv6-to-IPv4 relaying (translation) # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! pseudo-device bpf #Berkeley packet filter # USB support #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device usb # USB Bus (required) #device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse # USB Ethernet, requires mii #device aue # ADMtek USB ethernet #device cue # CATC USB ethernet #device kue # Kawasaki LSI USB ethernet ------- =_aaaaaaaaaa0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Sep 14 4:55: 9 2000 Delivered-To: freebsd-smp@freebsd.org Received: from charles.dircon.net (charles.dircon.net [195.157.2.129]) by hub.freebsd.org (Postfix) with ESMTP id 1E2E637B424 for ; Thu, 14 Sep 2000 04:55:02 -0700 (PDT) Received: from diablo.dircon.net (desk108.ch.dircon.net [195.157.3.108]) by charles.dircon.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id S7M58RP6; Thu, 14 Sep 2000 12:55:00 +0100 Received: by diablo.dircon.net (Postfix, from userid 1000) id 583671B222; Thu, 14 Sep 2000 12:54:57 +0100 (BST) Date: Thu, 14 Sep 2000 12:54:57 +0100 From: "'mark.blackman@dircon.net'" To: Todd Mortensen Cc: "'freebsd-smp@freebsd.org'" Subject: Re: Compaq 360 with SMP Message-ID: <20000914125457.A63806@diablo.dircon.net> References: <20000914075736.38F9E1B222@diablo.dircon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000914075736.38F9E1B222@diablo.dircon.net>; from mark.blackman@dircon.net on Thu, Sep 14, 2000 at 08:57:36AM +0100 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Actually, I think we have crossed wires here. We've succeeded with the proliant DL380. We don't have the DL360 and haven't tried it. You're having problems with the DL360 that I can't help with. On Thu, Sep 14, 2000 at 08:57:36AM +0100, Mark Blackman wrote: > I didn't actually do the configuration (a colleague did), but I'm pretty > sure he chose "Unixware 7" and no re-install was required. I'll include the > config file as well here. > > > I have been following your thread on freebsd-smp about your problems with > > with smp hanging the machine. > > > > We have the same hardware as you and are haveing the exact same problem you > > where having. > > > > You said you fixed this by Choosing Unixware for the primary operating > > system in the SmartStart configuration utility, Did you choose unixware 7 > > or 2.1 ?? > > And was it necisarry for you to reinstall your os after choosing this ? > > Any info would greatly be appreciated. > > > > # > # GENERIC -- Generic kernel configuration file for FreeBSD/i386 > # > # For more information on this file, please read the handbook section on > # Kernel Configuration Files: > # > # http://www.FreeBSD.org/handbook/kernelconfig-config.html > # > # The handbook is also available locally in /usr/share/doc/handbook > # if you've installed the doc distribution, otherwise always see the > # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the > # latest information. > # > # An exhaustive list of options and more detailed explanations of the > # device lines is also present in the ./LINT configuration file. If you are > # in doubt as to the purpose or necessity of a line, check first in LINT. > # > # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246.2.8 2000/07/20 02:51:02 msmith Exp $ > > machine i386 > #cpu I386_CPU > #cpu I486_CPU > cpu I586_CPU > cpu I686_CPU > ident DL360 > maxusers 128 > > #makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols > > #options MATH_EMULATE #Support for x87 emulation > options INET #InterNETworking > #options INET6 #IPv6 communications protocols > options FFS #Berkeley Fast Filesystem > options FFS_ROOT #FFS usable as root device [keep this!] > options SOFTUPDATES #Enable FFS soft updates support > options MFS #Memory Filesystem > #options MD_ROOT #MD is a potential root device > #options NFS #Network Filesystem > #options NFS_ROOT #NFS usable as root device, NFS required > #options MSDOSFS #MSDOS Filesystem > options CD9660 #ISO 9660 Filesystem > #options CD9660_ROOT #CD-ROM usable as root, CD9660 required > options PROCFS #Process filesystem > options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] > options SCSI_DELAY=15000 #Delay (in ms) before probing SCSI > options UCONSOLE #Allow users to grab the console > options USERCONFIG #boot -c editor > options VISUAL_USERCONFIG #visual boot -c editor > options KTRACE #ktrace(1) support > options SYSVSHM #SYSV-style shared memory > options SYSVMSG #SYSV-style message queues > options SYSVSEM #SYSV-style semaphores > options P1003_1B #Posix P1003_1B real-time extensions > options _KPOSIX_PRIORITY_SCHEDULING > options ICMP_BANDLIM #Rate limit bad replies > options KBD_INSTALL_CDEV # install a CDEV entry in /dev > > # To make an SMP kernel, the next two are needed > options SMP # Symmetric MultiProcessor Kernel > options APIC_IO # Symmetric (APIC) I/O > # Optionally these may need tweaked, (defaults shown): > options NCPU=2 # number of CPUs > #options NBUS=4 # number of busses > #options NAPIC=1 # number of IO APICs > #options NINTR=35 # number of INTs > > device isa > device eisa > device pci > > # Floppy drives > device fdc0 at isa? port IO_FD1 irq 6 drq 2 > device fd0 at fdc0 drive 0 > #device fd1 at fdc0 drive 1 > > # ATA and ATAPI devices > device ata0 at isa? port IO_WD1 irq 14 > device ata1 at isa? port IO_WD2 irq 15 > device ata > #device atadisk # ATA disk drives > device atapicd # ATAPI CDROM drives > #device atapifd # ATAPI floppy drives > #device atapist # ATAPI tape drives > options ATA_STATIC_ID #Static device numbering > #options ATA_ENABLE_ATAPI_DMA #Enable DMA on ATAPI devices > > # SCSI Controllers > #device ahb # EISA AHA1742 family > #device ahc # AHA2940 and onboard AIC7xxx devices > #device amd # AMD 53C974 (Teckram DC-390(T)) > #device dpt # DPT Smartcache - See LINT for options! > #device isp # Qlogic family > #device ncr # NCR/Symbios Logic > #device sym # NCR/Symbios Logic (newer chipsets) > #options SYM_SETUP_LP_PROBE_MAP=0x40 > # Allow ncr to attach legacy NCR devices when > # both sym and ncr are configured > > #device adv0 at isa? > #device adw > #device bt0 at isa? > #device aha0 at isa? > #device aic0 at isa? > > # SCSI peripherals > device scbus # SCSI bus (required) > device da # Direct Access (disks) > device sa # Sequential Access (tape etc) > device cd # CD > device pass # Passthrough device (direct SCSI access) > > # RAID controllers > device ida # Compaq Smart RAID > #device amr # AMI MegaRAID > #device mlx # Mylex DAC960 family > #device twe # 3ware Escalade > > # atkbdc0 controls both the keyboard and the PS/2 mouse > device atkbdc0 at isa? port IO_KBD > device atkbd0 at atkbdc? irq 1 flags 0x1 > device psm0 at atkbdc? irq 12 > > device vga0 at isa? > > # splash screen/screen saver > pseudo-device splash > > # syscons is the default console driver, resembling an SCO console > device sc0 at isa? flags 0x100 > > # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver > #device vt0 at isa? > #options XSERVER # support for X server on a vt console > #options FAT_CURSOR # start with block cursor > # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines > #options PCVT_SCANSET=2 # IBM keyboards are non-std > > # Floating point support - do not disable. > device npx0 at nexus? port IO_NPX irq 13 > > # Power management support (see LINT for more options) > #device apm0 at nexus? disable flags 0x20 # Advanced Power Management > > # PCCARD (PCMCIA) support > #device card > #device pcic0 at isa? irq 10 port 0x3e0 iomem 0xd0000 > #device pcic1 at isa? irq 11 port 0x3e2 iomem 0xd4000 disable > > # Serial (COM) ports > device sio0 at isa? port IO_COM1 flags 0x10 irq 4 > device sio1 at isa? port IO_COM2 irq 3 > #device sio2 at isa? disable port IO_COM3 irq 5 > #device sio3 at isa? disable port IO_COM4 irq 9 > > # Parallel port > #device ppc0 at isa? irq 7 > #device ppbus # Parallel port bus (required) > #device lpt # Printer > #device plip # TCP/IP over parallel > #device ppi # Parallel port interface device > #device vpo # Requires scbus and da > > > # PCI Ethernet NICs. > #device de # DEC/Intel DC21x4x (``Tulip'') > device fxp # Intel EtherExpress PRO/100B (82557, 82558) > #device tx # SMC 9432TX (83c170 ``EPIC'') > #device vx # 3Com 3c590, 3c595 (``Vortex'') > #device wx # Intel Gigabit Ethernet Card (``Wiseman'') > > # PCI Ethernet NICs that use the common MII bus controller code. > #device miibus # MII bus support > #device dc # DEC/Intel 21143 and various workalikes > #device rl # RealTek 8129/8139 > #device sf # Adaptec AIC-6915 (``Starfire'') > #device sis # Silicon Integrated Systems SiS 900/SiS 7016 > #device ste # Sundance ST201 (D-Link DFE-550TX) > #device tl # Texas Instruments ThunderLAN > #device vr # VIA Rhine, Rhine II > #device wb # Winbond W89C840F > #device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') > > # ISA Ethernet NICs. > #device ed0 at isa? port 0x280 irq 10 iomem 0xd8000 > #device ex > #device ep > # WaveLAN/IEEE 802.11 wireless NICs. Note: the WaveLAN/IEEE really > # exists only as a PCMCIA device, so there is no ISA attatement needed > # and resources will always be dynamically assigned by the pccard code. > #device wi > # Aironet 4500/4800 802.11 wireless NICs. Note: the declaration below will > # work for PCMCIA and PCI cards, as well as ISA cards set to ISA PnP > # mode (the factory default). If you set the switches on your ISA > # card for a manually chosen I/O address and IRQ, you must specify > # those paremeters here. > #device an > # Xircom Ethernet > #device xe > # The probe order of these is presently determined by i386/isa/isa_compat.c. > #device ie0 at isa? port 0x300 irq 10 iomem 0xd0000 > #device fe0 at isa? port 0x300 > #device le0 at isa? port 0x300 irq 5 iomem 0xd0000 > #device lnc0 at isa? port 0x280 irq 10 drq 0 > #device cs0 at isa? port 0x300 > #device sn0 at isa? port 0x300 irq 10 > > # Pseudo devices - the number indicates how many units to allocated. > pseudo-device loop # Network loopback > pseudo-device ether # Ethernet support > #pseudo-device sl 1 # Kernel SLIP > #pseudo-device ppp 1 # Kernel PPP > #pseudo-device tun # Packet tunnel. > pseudo-device pty # Pseudo-ttys (telnet etc) > #pseudo-device md # Memory "disks" > #pseudo-device gif 4 # IPv6 and IPv4 tunneling > #pseudo-device faith 1 # IPv6-to-IPv4 relaying (translation) > > # The `bpf' pseudo-device enables the Berkeley Packet Filter. > # Be aware of the administrative consequences of enabling this! > pseudo-device bpf #Berkeley packet filter > > # USB support > #device uhci # UHCI PCI->USB interface > #device ohci # OHCI PCI->USB interface > #device usb # USB Bus (required) > #device ugen # Generic > #device uhid # "Human Interface Devices" > #device ukbd # Keyboard > #device ulpt # Printer > #device umass # Disks/Mass storage - Requires scbus and da > #device ums # Mouse > # USB Ethernet, requires mii > #device aue # ADMtek USB ethernet > #device cue # CATC USB ethernet > #device kue # Kawasaki LSI USB ethernet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Sep 14 7:50:29 2000 Delivered-To: freebsd-smp@freebsd.org Received: from ipamzlx.physik.uni-mainz.de (ipamzlx.Physik.Uni-Mainz.DE [134.93.180.54]) by hub.freebsd.org (Postfix) with ESMTP id D9A6E37B422; Thu, 14 Sep 2000 07:50:22 -0700 (PDT) Received: from ipamzlx.Physik.Uni-Mainz.DE (ipamzlx.Physik.Uni-Mainz.DE [134.93.180.54]) by ipamzlx.physik.uni-mainz.de (8.11.0/8.9.3) with ESMTP id e8EEqvS11961; Thu, 14 Sep 2000 16:52:58 +0200 (CEST) (envelope-from ohartman@ipamzlx.physik.uni-mainz.de) Date: Thu, 14 Sep 2000 16:52:57 +0200 (CEST) From: "O. Hartmann" To: freebsd-hardware@freebsd.org, freebsd-smp@freebsd.org Subject: TYAN Thunder 2500-80 and FreeBSD 4.1 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 Dear Sirs. I need a little bit help and assistance in some hardware/smp questions. At the moment, one of our main servers is based on a dual-gigabyte intel 440BX chipset based mainboard. These days we change, we want to swapp over to a new mainboard and new CPUs. The mainboard has been choosen from TYAN, TYAN Thunder 2500-80. I watched out for compatibility reasons not to obtain the Symbios Logic 53C1010 (SCSI-3/160) based board, because SymbiosLogic 53C896 seems to be fully supported. I heard about many problems of using SMP kernel on ServerWorks III HE chipset based boards in spring this year, a lot about problems with i820 and i840 (Carmel) based SMP boards, but that was shortly after the change towards FreeBSD 4.0. Now we have much more ServerWorks III chipsets based mainboards on market as a replacement for the memory demanding server market because of the problems with i820/i840 and ECC RAM or due to the enormous costs of RIMM modules. It seems, that the TYAN Thunder 2500 is one of the best mainboards on market - but has anyone tested it using FBSD? Well, because we ordered such a mainboard and I never got an answer of my posted questions related to this hardware, it seems that I will be on my own when trying the first time to migrate from the old hardware to the new one. At the moment I try to configure a suitable kernel and because we do not already use hardware RAID 5 technology (I have an simple array of RAID 0 bundled drives using vinum, and thats in some cases really slow, maybe due the fact being a software solution), I use simply a main drive from which all bootsrap is done before starting vinum and the array. Well, that's besides that what makes me afraid of swapping over to the new hardware. I read a lot about failures of starting SMP kernel or kernel does not recognize all the hardware although these kind of mainboards all use standard and proofen hardware like intel ether 10/100+ Pro lan chip, LSI/SymbiosLogic 53C896 dual channel LVD SCSI controller, ES 3173 sound chip ... well, only the chipset seems to be the point of problems. Does anybody know, whether this chipset runs with FreeBSD 4.1? I think some PowerEdge solutions based on this chipset and also some Proliance systems. If there is anybody out here who's some experiences, especially in how to avaoid a non starting kernel, please contact me. I think, I will leave SMP facilities first time out to make myself sure, that the system will boot with one of booth 866EB Coppermines. Thanks in advance, Gruss O. Hartmann ------------------------------------------------------------------- ohartman@ipamzlx.physik.uni-mainz.de Klimadatenserver des IPA, Universitaet Mainz Netzwerk- und Systembetreuung To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Sep 14 9:53:42 2000 Delivered-To: freebsd-smp@freebsd.org Received: from ipamzlx.physik.uni-mainz.de (ipamzlx.Physik.Uni-Mainz.DE [134.93.180.54]) by hub.freebsd.org (Postfix) with ESMTP id DEAD537B424; Thu, 14 Sep 2000 09:53:37 -0700 (PDT) Received: from ipamzlx.Physik.Uni-Mainz.DE (ipamzlx.Physik.Uni-Mainz.DE [134.93.180.54]) by ipamzlx.physik.uni-mainz.de (8.11.0/8.9.3) with ESMTP id e8EGuBS13265; Thu, 14 Sep 2000 18:56:11 +0200 (CEST) (envelope-from ohartman@ipamzlx.physik.uni-mainz.de) Date: Thu, 14 Sep 2000 18:56:11 +0200 (CEST) From: "O. Hartmann" To: Ignacio Cristerna Cc: freebsd-hardware@freebsd.org, freebsd-smp@freebsd.org Subject: RE: TYAN Thunder 2500-80 and FreeBSD 4.1 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ascii Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 14 Sep 2000, Ignacio Cristerna wrote: Hello. Well, I think this problem is definitely concernig the SMP list AND hardware list, because both parts are involved. I think there are a lot out here which want to simply INSTALL a FreeBSD on a special box, not aware of the kind of hardware they are using. Maybe questions concerning a special combination of hardware, like SCSI controllers, RAID controllers or in conjunction with a special SMP able mainboard are special - or those, who have those combinations are not aware of these combinations. Well, sometimes I feel angry about this behavoiur, but I realized, that development runs much faster than we can obtain special answers and most out here tend to use the step in development. Watch out how many are asking for SMP-K7 systems based on AMDs 760 chipset ... Well, but you're right in pointing out some misbehaviours of the "list". In my special case, I will see how well FreeBSD will work with the ordered mainboard and I will post a little, stupid report how it works - or not. :>I´ve got the same feelings concerning the smp list. I mean, if this is not :>the proper place to ask about hardware compatibility list, then where can I :>ask this question. I ask about a certain motherboard/scsi card combination :>and never got an answer about that. If this is the policy of the list, then :>maybe we should be told so. :> :> :> Gruss O. Hartmann ------------------------------------------------------------------- ohartman@ipamzlx.physik.uni-mainz.de Klimadatenserver des IPA, Universitaet Mainz Netzwerk- und Systembetreuung To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Sep 14 14:54: 6 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-177-115.dsl.snfc21.pacbell.net [63.202.177.115]) by hub.freebsd.org (Postfix) with ESMTP id F067837B42C; Thu, 14 Sep 2000 14:54:01 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id OAA01453; Thu, 14 Sep 2000 14:52:39 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009142152.OAA01453@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "O. Hartmann" Cc: freebsd-hardware@freebsd.org, freebsd-smp@freebsd.org Subject: Re: TYAN Thunder 2500-80 and FreeBSD 4.1 In-reply-to: Your message of "Thu, 14 Sep 2000 16:52:57 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Sep 2000 14:52:39 -0700 From: Mike Smith Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I need a little bit help and assistance in some hardware/smp questions. > At the moment, one of our main servers is based on a dual-gigabyte intel > 440BX chipset based mainboard. These days we change, we want to swapp > over to a new mainboard and new CPUs. The mainboard has been choosen > from TYAN, TYAN Thunder 2500-80. I watched out for compatibility reasons > not to obtain the Symbios Logic 53C1010 (SCSI-3/160) based board, because > SymbiosLogic 53C896 seems to be fully supported. The 53c1010 is also very well supported. > It seems, that the > TYAN Thunder 2500 is one of the best mainboards on market - but has anyone > tested it using FBSD? Yes. We (FreeBSD Labs) evaluated a sample of this board about a month ago. I had no problems with it at all, and qualified it for FreeBSD 4.1 and above. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Sep 14 15:55:11 2000 Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 286A637B422; Thu, 14 Sep 2000 15:55:07 -0700 (PDT) Received: (from jhb@localhost) by pike.osd.bsdi.com (8.9.3/8.9.3) id PAA95214; Thu, 14 Sep 2000 15:54:58 -0700 (PDT) (envelope-from jhb) From: John Baldwin Message-Id: <200009142254.PAA95214@pike.osd.bsdi.com> Subject: Re: Prelimiary interrupt thread patches for alpha In-Reply-To: from Doug Rabson at "Sep 14, 2000 03:55:04 pm" To: Doug Rabson Date: Thu, 14 Sep 2000 15:54:58 -0700 (PDT) Cc: alpha@FreeBSD.org, smp@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] 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 Doug Rabson wrote: > On Wed, 13 Sep 2000, John Baldwin wrote: > > I've updated the alpha.ithreads.patch on my freefall webpage to work with > > the latest current, btw. > > I've been working on this today and I have a kernel which boots on my > miata and is happily chewing its way through a buildworld. I fixed the > device_get_nameunit() problem - it was just going wrong for ATA interrupts > which are handled quite strangely on alpha. I also changed the p_comm > string to include the whole vector number in hex since on some platforms > all bits are relavent, not just (vec-0x900)>>4. > > I've attached my modified version of your patch to this message. Its not > quite ready to commit yet since I didn't write the enable/disable hooks > for mcpcia or dwlpx. I have an mcpcia here (the AS4100) so I'll be able to > test that soon. After that last fix to trap.c to add an acquire/release of sched_lock, I am now happily running interrupt threads on my miata here with your patch. I've gone ahead and replaced my patch on freefall with yours, but hopefully we can commit this very soon when you get the other PCI chipsets finished. Thanks. :) I know have a buildworld going on my INVARIANTS kernel and it is running fine so far. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Sep 14 22:58:23 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id CD56537B42C; Thu, 14 Sep 2000 22:58:18 -0700 (PDT) Received: from mail.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e8F5wCV08120 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 15 Sep 2000 07:58:14 +0200 (MET DST) Received: from cicely5.cicely.de (cicely5.cicely.de [fec0::104:200:92ff:fe9b:20e7]) by mail.cicely.de (8.11.0.Beta1/8.11.0.Beta1) with ESMTP id e8F5wGI79635; Fri, 15 Sep 2000 07:58:17 +0200 (CEST) Received: (from ticso@localhost) by cicely5.cicely.de (8.11.0/8.9.2) id e8F5wCG60394; Fri, 15 Sep 2000 07:58:12 +0200 (CEST) (envelope-from ticso) Date: Fri, 15 Sep 2000 07:58:12 +0200 From: Bernd Walter To: John Baldwin Cc: Doug Rabson , alpha@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Prelimiary interrupt thread patches for alpha Message-ID: <20000915075812.B60348@cicely5.cicely.de> References: <200009142254.PAA95214@pike.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200009142254.PAA95214@pike.osd.bsdi.com>; from jhb@pike.osd.bsdi.com on Thu, Sep 14, 2000 at 03:54:58PM -0700 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Sep 14, 2000 at 03:54:58PM -0700, John Baldwin wrote: > After that last fix to trap.c to add an acquire/release of sched_lock, I > am now happily running interrupt threads on my miata here with your patch. > I've gone ahead and replaced my patch on freefall with yours, but hopefully > we can commit this very soon when you get the other PCI chipsets finished. > Thanks. :) I know have a buildworld going on my INVARIANTS kernel and it > is running fine so far. miata means that it should be testable on a PC164 - right? -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Sep 15 4: 4:35 2000 Delivered-To: freebsd-smp@freebsd.org Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by hub.freebsd.org (Postfix) with ESMTP id 5007E37B423; Fri, 15 Sep 2000 04:04:22 -0700 (PDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id NAA17993; Fri, 15 Sep 2000 13:03:44 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA07958; Fri, 15 Sep 2000 13:03:29 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Sep 2000 13:04:05 +0200 Message-ID: <67E0BE167008D31185F60008C7289DA0E12F0B@MCHH218E> From: Reifenberger Michael To: "'freebsd-current@FreeBSD.ORG'" , "'freebsd-smp@freebsd.org'" Subject: Partial success with current on Laptop. Date: Fri, 15 Sep 2000 12:03:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, with -current as of yesterday I get partial success. My configuration: - Tecra8000 - 256MB Ram - ad0: IBM DARA 25000 @ UDMA33 - ad1: IBM DARA 26480 @ UDMA33 - kernel and modules in sync, fresh buildworld, buildkernel... - Nonstandart-options: o enabled apm, acpi, usb, pcm, pcic. o all slices are mounted with noatime and sofdep. o sysctl -w vfs.vmiodirenable=1 o sysctl -w vfs.write_behind=0 o kern.vm.kmem.size=20971520 in loader.conf What seems to work: - buildkernel; (buildworld not testet) - linuxerator (testet staroffice, Oracle 8.1.5, SAP R/3 4.5B) - X - Wine - pcmcia (ep0, aic0 - insert/delete testet) - apm (suspend/resume not testet) What doesn't - Heavy (concurrent?) disk I/O locks up the system solid. Testet with "du -sk /usr/ports" or "tar cf - . | `cd /scratch; tar xvf -`" in multiuser mode... "tar cf /dev/null /usr/ports &; tar cf - /usr/ports | tar tvf -" in singleuser mode (disks mounted -oro ) o getting (after hanging with "du -sk /usr/ports" into ddb -> ps shows some processes in ffsvgt and du hanging in some FFS operation. o in singleuser mode -> ddb -> ps I see the 3 tar's in stat: 3, wmesg: piperd, inode, FFS node. - "panic" in ddb hangs in "syncing disks x x ...". Bye/2 ------ Michael Reifenberger - IT, UNIX, R/3-Basis Work: Michael.Reifenberger@plaut.de Proj: Michael.Reifenberger.gp@icn.siemens.de Pers: Michael@Reifenberger.com Webspace: http://www.reifenberger.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Sep 15 5:10:57 2000 Delivered-To: freebsd-smp@freebsd.org Received: from itesec.hsc.fr (itesec.hsc.fr [192.70.106.33]) by hub.freebsd.org (Postfix) with ESMTP id 9916937B424; Fri, 15 Sep 2000 05:10:53 -0700 (PDT) Received: from yoko.hsc.fr (yoko.hsc.fr [192.70.106.76]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "yoko.hsc.fr", Issuer CN "HSC CA" (verified OK)) by itesec.hsc.fr (Postfix) with ESMTP id BFC9510ED1; Fri, 15 Sep 2000 14:10:52 +0200 (CEST) Received: by yoko.hsc.fr (Postfix-TLS, from userid 1001) id BA18C9B206; Fri, 15 Sep 2000 14:10:49 +0200 (CEST) Date: Fri, 15 Sep 2000 14:10:49 +0200 From: Alain Thivillon To: Reifenberger Michael Cc: "'freebsd-current@FreeBSD.ORG'" , "'freebsd-smp@freebsd.org'" Subject: Re: Partial success with current on Laptop. Message-ID: <20000915141049.A695@yoko.hsc.fr> References: <67E0BE167008D31185F60008C7289DA0E12F0B@MCHH218E> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.2i In-Reply-To: <67E0BE167008D31185F60008C7289DA0E12F0B@MCHH218E>; from Michael.Reifenberger.gp@icn.siemens.de on Fri, Sep 15, 2000 at 12:03:36PM +0200 X-Organization: Herve Schauer Consultants X-Operating-System: FreeBSD 5.0-CURRENT Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Reifenberger Michael écrivait (wrote) : > My configuration: > - Tecra8000 I run the same, with only 64Mo. > - 256MB Ram > - ad0: IBM DARA 25000 @ UDMA33 > - ad1: IBM DARA 26480 @ UDMA33 I have only one disk, in DMA, with softupdates. I have tried some of the stress tests you mention, and ... no crashes. > - apm (suspend/resume not testet) Works for me. My only problem is that Fan is NEVER turned off (it seems that idle loop in kernel as become CPU intensive and energy hardware can not stop cooling). At this time, this is a minor annoyance. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Sep 15 7: 8:54 2000 Delivered-To: freebsd-smp@freebsd.org Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by hub.freebsd.org (Postfix) with ESMTP id 1F79737B423; Fri, 15 Sep 2000 07:08:47 -0700 (PDT) Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA17224; Fri, 15 Sep 2000 16:08:27 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA02703; Fri, 15 Sep 2000 16:05:14 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Sep 2000 16:08:39 +0200 Message-ID: <67E0BE167008D31185F60008C7289DA0E12F0D@MCHH218E> From: Reifenberger Michael To: "'Alain Thivillon'" Cc: "'freebsd-current@FreeBSD.ORG'" , "'freebsd-smp@freebsd.org'" Subject: AW: Partial success with current on Laptop. Date: Fri, 15 Sep 2000 15:25:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, sorry, it's easilly reproducable. I built a -current kernel supped today now without apm, acpi, usb. - "boot -s" for singleuser - "mount -oro /usr" - "cd /usr/ports" - "tar cf /dev/null . &" - "tar cf - . | tar tvf -" ...wait... ...freeze... ...why?... Could someone enlight me how to get some more usefull information after = getting into ddb? ddb(4) and the handbook is not really specific about. Esp. how do I inspect specific processes which I see in "ps". "trace" is of no help when manually breaking into ddb. Is there something like "bt" or "up", like in gdb? Bye/2 ------ Michael Reifenberger - IT, UNIX, R/3-Basis Work: Michael.Reifenberger@plaut.de Proj: = Michael.Reifenberger.gp@icn.siemens.de Pers: Michael@Reifenberger.com Webspace: http://www.reifenberger.com > -----Urspr> =FCngliche Nachricht----- > Von: Alain Thivillon [SMTP:Alain.Thivillon@hsc.fr] > Gesendet am: Freitag, 15. September 2000 14:11 > An: Reifenberger Michael > Cc: 'freebsd-current@FreeBSD.ORG'; 'freebsd-smp@freebsd.org' > Betreff: Re: Partial success with current on Laptop. >=20 > Reifenberger Michael = =E9crivait (wrote) : >=20 > > My configuration: > > - Tecra8000 >=20 > I run the same, with only 64Mo. >=20 > > - 256MB Ram > > - ad0: IBM DARA 25000 @ UDMA33 > > - ad1: IBM DARA 26480 @ UDMA33 >=20 > I have only one disk, in DMA, with softupdates. I have tried > some of the stress tests you mention, and ... no crashes. >=20 > > - apm (suspend/resume not testet) >=20 > Works for me. >=20 > My only problem is that Fan is NEVER turned off (it seems that > idle loop in kernel as become CPU intensive and energy hardware can = not > stop cooling). At this time, this is a minor annoyance. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Sep 15 9:18:41 2000 Delivered-To: freebsd-smp@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 100CC37B422; Fri, 15 Sep 2000 09:18:37 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id JAA72911; Fri, 15 Sep 2000 09:18:26 -0700 (PDT) (envelope-from obrien) Date: Fri, 15 Sep 2000 09:18:26 -0700 From: "David O'Brien" To: Bernd Walter Cc: alpha@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Prelimiary interrupt thread patches for alpha Message-ID: <20000915091826.A72881@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200009142254.PAA95214@pike.osd.bsdi.com> <20000915075812.B60348@cicely5.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000915075812.B60348@cicely5.cicely.de>; from ticso@cicely5.cicely.de on Fri, Sep 15, 2000 at 07:58:12AM +0200 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Sep 15, 2000 at 07:58:12AM +0200, Bernd Walter wrote: > > miata means that it should be testable on a PC164 - right? No. There are some differences in the chipsets used. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Sep 15 9:26:17 2000 Delivered-To: freebsd-smp@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 8C40237B423; Fri, 15 Sep 2000 09:26:14 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id JAA72956; Fri, 15 Sep 2000 09:26:09 -0700 (PDT) (envelope-from obrien) Date: Fri, 15 Sep 2000 09:26:09 -0700 From: "David O'Brien" To: Bernd Walter Cc: alpha@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Prelimiary interrupt thread patches for alpha Message-ID: <20000915092609.B72881@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200009142254.PAA95214@pike.osd.bsdi.com> <20000915075812.B60348@cicely5.cicely.de> <20000915091826.A72881@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000915091826.A72881@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Fri, Sep 15, 2000 at 09:18:26AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Sep 15, 2000 at 09:18:26AM -0700, David O'Brien wrote: > On Fri, Sep 15, 2000 at 07:58:12AM +0200, Bernd Walter wrote: > > > > miata means that it should be testable on a PC164 - right? > > No. There are some differences in the chipsets used. Let me expand on this answer -- just because something worked on a Miata does not mean it will work on a PC164. Of course something working (or not working) does mean it is worth testing to see if it works on a PC164. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Sep 15 10:25:10 2000 Delivered-To: freebsd-smp@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id EBD1837B422; Fri, 15 Sep 2000 10:25:06 -0700 (PDT) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.10.2+3.3W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id e8FHP3r40546; Sat, 16 Sep 2000 02:25:03 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: Alain.Thivillon@hsc.fr Cc: Michael.Reifenberger.gp@icn.siemens.de, freebsd-current@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: Partial success with current on Laptop. In-Reply-To: <20000915141049.A695@yoko.hsc.fr> References: <67E0BE167008D31185F60008C7289DA0E12F0B@MCHH218E> <20000915141049.A695@yoko.hsc.fr> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000916022422P.iwasaki@jp.FreeBSD.org> Date: Sat, 16 Sep 2000 02:24:22 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 13 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > - apm (suspend/resume not testet) > > Works for me. > > My only problem is that Fan is NEVER turned off (it seems that > idle loop in kernel as become CPU intensive and energy hardware can not > stop cooling). At this time, this is a minor annoyance. Do you have acpi enabled in your kernel? If so, it could be. Thermal and processor power management portion of acpi is not implemented yet. All of the power resource components such as fan are just turned on at booting for now :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Sep 15 10:32:45 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id AA17037B423; Fri, 15 Sep 2000 10:32:38 -0700 (PDT) Received: from mail.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e8FHWZB22377 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 15 Sep 2000 19:32:36 +0200 (MET DST) Received: from cicely5.cicely.de (cicely5.cicely.de [fec0::104:200:92ff:fe9b:20e7]) by mail.cicely.de (8.11.0.Beta1/8.11.0.Beta1) with ESMTP id e8FHWeI81531; Fri, 15 Sep 2000 19:32:40 +0200 (CEST) Received: (from ticso@localhost) by cicely5.cicely.de (8.11.0/8.9.2) id e8FHWaY61100; Fri, 15 Sep 2000 19:32:36 +0200 (CEST) (envelope-from ticso) Date: Fri, 15 Sep 2000 19:32:36 +0200 From: Bernd Walter To: "David O'Brien" Cc: alpha@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Prelimiary interrupt thread patches for alpha Message-ID: <20000915193236.B61065@cicely5.cicely.de> References: <200009142254.PAA95214@pike.osd.bsdi.com> <20000915075812.B60348@cicely5.cicely.de> <20000915091826.A72881@dragon.nuxi.com> <20000915092609.B72881@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000915092609.B72881@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Fri, Sep 15, 2000 at 09:26:09AM -0700 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Sep 15, 2000 at 09:26:09AM -0700, David O'Brien wrote: > On Fri, Sep 15, 2000 at 09:18:26AM -0700, David O'Brien wrote: > > On Fri, Sep 15, 2000 at 07:58:12AM +0200, Bernd Walter wrote: > > > > > > miata means that it should be testable on a PC164 - right? > > > > No. There are some differences in the chipsets used. > > Let me expand on this answer -- just because something worked on a Miata > does not mean it will work on a PC164. Of course something working (or > not working) does mean it is worth testing to see if it works on a PC164. I wanted to know if there are known show stoppers. "worth testing" is exactly what I tried to say with testable. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Sep 15 10:46:39 2000 Delivered-To: freebsd-smp@freebsd.org Received: from itesec.hsc.fr (itesec.hsc.fr [192.70.106.33]) by hub.freebsd.org (Postfix) with ESMTP id 7A04837B423; Fri, 15 Sep 2000 10:46:35 -0700 (PDT) Received: from yoko.hsc.fr (yoko.hsc.fr [192.70.106.76]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "yoko.hsc.fr", Issuer CN "HSC CA" (verified OK)) by itesec.hsc.fr (Postfix) with ESMTP id D25F91101F; Fri, 15 Sep 2000 19:46:33 +0200 (CEST) Received: by yoko.hsc.fr (Postfix-TLS, from userid 1001) id 8BFBD9B206; Fri, 15 Sep 2000 19:46:20 +0200 (CEST) Date: Fri, 15 Sep 2000 19:46:20 +0200 From: Alain Thivillon To: Mitsuru IWASAKI Cc: Michael.Reifenberger.gp@icn.siemens.de, freebsd-current@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: Partial success with current on Laptop. Message-ID: <20000915194620.E447@yoko.hsc.fr> References: <67E0BE167008D31185F60008C7289DA0E12F0B@MCHH218E> <20000915141049.A695@yoko.hsc.fr> <20000916022422P.iwasaki@jp.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.2i In-Reply-To: <20000916022422P.iwasaki@jp.FreeBSD.org>; from iwasaki@jp.FreeBSD.org on Sat, Sep 16, 2000 at 02:24:22AM +0900 X-Organization: Herve Schauer Consultants X-Operating-System: FreeBSD 5.0-CURRENT Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mitsuru IWASAKI écrivait (wrote) : > Do you have acpi enabled in your kernel? no. I have tried ACPI some days ago, but system boot becomes incredibly slow (for example, syslogd complained about something like 'child process timeout' after enabling ACPI). All system activity such as fork and so was affected. > and processor power management portion of acpi is not implemented yet. > All of the power resource components such as fan are just turned on at > booting for now :-) Other problem with -CURRENT and laptops is that system time is not reinitialised after suspend and resume :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Sep 15 11: 3:47 2000 Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id D73DE37B424; Fri, 15 Sep 2000 11:03:44 -0700 (PDT) Received: (from jhb@localhost) by pike.osd.bsdi.com (8.9.3/8.9.3) id LAA24561; Fri, 15 Sep 2000 11:03:31 -0700 (PDT) (envelope-from jhb) From: John Baldwin Message-Id: <200009151803.LAA24561@pike.osd.bsdi.com> Subject: Re: Prelimiary interrupt thread patches for alpha In-Reply-To: <20000915193236.B61065@cicely5.cicely.de> from Bernd Walter at "Sep 15, 2000 07:32:36 pm" To: Bernd Walter Date: Fri, 15 Sep 2000 11:03:31 -0700 (PDT) Cc: "David O'Brien" , alpha@FreeBSD.ORG, smp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL68 (25)] 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 Bernd Walter wrote: > On Fri, Sep 15, 2000 at 09:26:09AM -0700, David O'Brien wrote: > > On Fri, Sep 15, 2000 at 09:18:26AM -0700, David O'Brien wrote: > > > On Fri, Sep 15, 2000 at 07:58:12AM +0200, Bernd Walter wrote: > > > > > > > > miata means that it should be testable on a PC164 - right? > > > > > > No. There are some differences in the chipsets used. > > > > Let me expand on this answer -- just because something worked on a Miata > > does not mean it will work on a PC164. Of course something working (or > > not working) does mean it is worth testing to see if it works on a PC164. > > I wanted to know if there are known show stoppers. > "worth testing" is exactly what I tried to say with testable. I believe it should be worth testing as I know that the cia PCI bus driver is ok. In fact, most of the PCI bus drivers are fixed, so it should work on most alphas, AFAIK. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Sep 15 11: 4: 7 2000 Delivered-To: freebsd-smp@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id 4045937B43C; Fri, 15 Sep 2000 11:04:02 -0700 (PDT) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.10.2+3.3W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id e8FI3xr47413; Sat, 16 Sep 2000 03:03:59 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: Alain.Thivillon@hsc.fr Cc: iwasaki@jp.FreeBSD.org, Michael.Reifenberger.gp@icn.siemens.de, freebsd-current@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: Partial success with current on Laptop. In-Reply-To: <20000915194620.E447@yoko.hsc.fr> References: <20000915141049.A695@yoko.hsc.fr> <20000916022422P.iwasaki@jp.FreeBSD.org> <20000915194620.E447@yoko.hsc.fr> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000916030316Q.iwasaki@jp.FreeBSD.org> Date: Sat, 16 Sep 2000 03:03:16 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 22 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Do you have acpi enabled in your kernel? > > no. I have tried ACPI some days ago, but system boot becomes > incredibly slow (for example, syslogd complained about something like > 'child process timeout' after enabling ACPI). All system activity such > as fork and so was affected. It seems the same with my TOSHIBA POTEGE 3110CT because of lack of processor power management implementation I think. My short term solution is acpiconf -d to make CPU running in normal speed. > > and processor power management portion of acpi is not implemented yet. > > All of the power resource components such as fan are just turned on at > > booting for now :-) > > Other problem with -CURRENT and laptops is that system time is not > reinitialised after suspend and resume :) Ah, you probably need to have a `device pmtimer' in your kernel config and `hint.pmtimer.0.at="isa"' in your devce.hints. If you don't like to reinitialize system time (e.g. prefer running ntpdate), you don't need to have pmtimer. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Sep 15 14:36:37 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id 3149B37B422; Fri, 15 Sep 2000 14:36:28 -0700 (PDT) Received: from mail.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e8FLaLh09023 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 15 Sep 2000 23:36:23 +0200 (MET DST) Received: from cicely5.cicely.de (cicely5.cicely.de [fec0::104:200:92ff:fe9b:20e7]) by mail.cicely.de (8.11.0.Beta1/8.11.0.Beta1) with ESMTP id e8FLaRI82145; Fri, 15 Sep 2000 23:36:27 +0200 (CEST) Received: (from ticso@localhost) by cicely5.cicely.de (8.11.0/8.9.2) id e8FLaMv61464; Fri, 15 Sep 2000 23:36:22 +0200 (CEST) (envelope-from ticso) Date: Fri, 15 Sep 2000 23:36:22 +0200 From: Bernd Walter To: John Baldwin Cc: "David O'Brien" , alpha@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Prelimiary interrupt thread patches for alpha Message-ID: <20000915233621.A61424@cicely5.cicely.de> References: <20000915193236.B61065@cicely5.cicely.de> <200009151803.LAA24561@pike.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200009151803.LAA24561@pike.osd.bsdi.com>; from jhb@pike.osd.bsdi.com on Fri, Sep 15, 2000 at 11:03:31AM -0700 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Sep 15, 2000 at 11:03:31AM -0700, John Baldwin wrote: > I believe it should be worth testing as I know that the cia PCI bus driver > is ok. In fact, most of the PCI bus drivers are fixed, so it should work > on most alphas, AFAIK. OK. I took the Version from http://people.FreeBSD.org/~jhb/patches/alpha.ithreads.patch With boot -v it hangs here: [...] Creating DISK cd0 Creating DISK da0 Creating DISK da1 A none -v boot get's sometimes up to printing some or all SCSI-devices but never gets to mounting /. I'm using seriel console. The kernel is compiled with INVARIANTS. A working boot looks like this: Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Thu Sep 14 08:19:11 CEST 2000 ticso@cicely9.cicely.de:/var/d7/src-2000-09-13/src/sys/compile/CICELY9 EB164 Digital AlphaPC 164 500 MHz, 500MHz 8192 byte page size, 1 processor. CPU: EV56 (21164A) major=7 minor=2 extensions=0x1 OSF PAL rev: 0x1000800020117 real memory = 265904128 (259672K bytes) avail memory = 253460480 (247520K bytes) Preloaded elf kernel "kernel.ko" at 0xfffffc000061e000. cia0: <2117x Core Logic chipset> cia0: ALCOR/ALCOR2, pass 3 cia0: extended capabilities: 21 pcib0: <2117x PCI host bus adapter> on cia0 pci0: on pcib0 sym0: <895> port 0x10200-0x102ff mem 0x82030000-0x82030fff,0x82031200-0x820312ff irq 2 at device 5.0 on pci0 sym0: Symbios NVRAM, ID 7, Fast-40, LVD, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: interrupting at CIA irq 2 sym1: <810a> port 0x10100-0x101ff mem 0x82031100-0x820311ff irq 0 at device 6.0 on pci0 sym1: No NVRAM, ID 7, Fast-10, SE, parity checking sym1: interrupting at CIA irq 0 sym2: <810a> port 0x10000-0x100ff mem 0x82031000-0x820310ff irq 1 at device 7.0 on pci0 sym2: No NVRAM, ID 7, Fast-10, SE, parity checking sym2: interrupting at CIA irq 1 isab0: at device 8.0 on pci0 isa0: on isab0 xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0x10300-0x1037f mem 0x82031300-0x8203137f irq 3 at device 9.0 on pci0 xl0: interrupting at CIA irq 3 xl0: Ethernet address: 00:10:5a:30:1c:1a miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atapci0: port 0x10380-0x1038f irq 5 at device 11.0 on pci0 ata0: at 0x1f0 irq 14 on atapci0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: interrupting at ISA irq 6 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 mcclock0: at port 0x70-0x71 on isa0 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A, console sio0: interrupting at ISA irq 4 sio1: reserved for low-level i/o Timecounter "i8254" frequency 1193182 Hz Timecounter "alpha" frequency 500006831 Hz ad0: 1219MB [2477/16/63] at ata0-master using WDMA2 Waiting 15 seconds for SCSI devices to settle (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 1041MB (2131992 512 byte sectors: 255H 63S/T 132C) cd0 at sym2 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 4.237MB/s transfers (4.237MHz, offset 8) cd0: cd present [314602 x 2048 byte records] da1 at sym0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-CCS device da1: 3.300MB/s transfers da1: 638MB (1308087 512 byte sectors: 64H 32S/T 638C) da6 at sym1 bus 0 target 0 lun 0 da6: Fixed Direct Access SCSI-2 device da6: 5.000MB/s transfers (5.000MHz, offset 7) da6: 206MB (422912 512 byte sectors: 64H 32S/T 206C) da2 at sym0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 5.000MB/s transfers (5.000MHz, offset 7) da2: 103MB (210944 512 byte sectors: 64H 32S/T 103C) da13 at sym2 bus 0 target 2 lun 0 da13: Fixed Direct Access SCSI-CCS device da13: 3.300MB/s transfers da13: 316MB (649040 512 byte sectors: 64H 32S/T 316C) da7 at sym1 bus 0 target 1 lun 0 da7: Fixed Direct Access SCSI-2 device da7: 5.000MB/s transfers (5.000MHz, offset 7) da7: 206MB (422912 512 byte sectors: 64H 32S/T 206C) da15 at sym2 bus 0 target 5 lun 0 da15: Removable Direct Access SCSI-2 device da15: 10.000MB/s transfers (10.000MHz, offset 8) da15: 1243MB (1273011 1024 byte sectors: 255H 63S/T 79C) da3 at sym0 bus 0 target 4 lun 0 da3: Fixed Direct Access SCSI-CCS device da3: 3.300MB/s transfers da3: 405MB (830340 512 byte sectors: 64H 32S/T 405C) da4 at sym0 bus 0 target 9 lun 0 da4: Fixed Direct Access SCSI-2 device da4: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da4: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da5 at sym0 bus 0 target 10 lun 0 da5: Fixed Direct Access SCSI-2 device da5: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da5: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da8 at sym1 bus 0 target 2 lun 0 da8: Fixed Direct Access SCSI-2 device da8: 5.000MB/s transfers (5.000MHz, offset 7) da8: 206MB (422912 512 byte sectors: 64H 32S/T 206C) da9 at sym1 bus 0 target 3 lun 0 da9: Fixed Direct Access SCSI-2 device da9: 5.000MB/s transfers (5.000MHz, offset 7) da9: 206MB (422912 512 byte sectors: 64H 32S/T 206C) da10 at sym1 bus 0 target 4 lun 0 da10: Fixed Direct Access SCSI-2 device da10: 5.000MB/s transfers (5.000MHz, offset 7) da10: 206MB (422912 512 byte sectors: 64H 32S/T 206C) da11 at sym1 bus 0 target 5 lun 0 da11: Fixed Direct Access SCSI-2 device da11: 5.000MB/s transfers (5.000MHz, offset 7) da11: 206MB (422912 512 byte sectors: 64H 32S/T 206C) da12 at sym1 bus 0 target 6 lun 0 da12: Fixed Direct Access SCSI-2 device da12: 5.000MB/s transfers (5.000MHz, offset 7) da12: 206MB (422912 512 byte sectors: 64H 32S/T 206C) da14 at sym2 bus 0 target 3 lun 0 da14: Fixed Direct Access SCSI-CCS device da14: 3.300MB/s transfers da14: 170MB (349770 512 byte sectors: 64H 32S/T 170C) Mounting root from ufs:/dev/da0a [...] -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Sep 15 15:26:37 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id CE9F237B42C; Fri, 15 Sep 2000 15:26:29 -0700 (PDT) Received: from mail.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e8FMQNc12097 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Sat, 16 Sep 2000 00:26:25 +0200 (MET DST) Received: from cicely5.cicely.de (cicely5.cicely.de [fec0::104:200:92ff:fe9b:20e7]) by mail.cicely.de (8.11.0.Beta1/8.11.0.Beta1) with ESMTP id e8FMQPI82345; Sat, 16 Sep 2000 00:26:29 +0200 (CEST) Received: (from ticso@localhost) by cicely5.cicely.de (8.11.0/8.9.2) id e8FMQPl61567; Sat, 16 Sep 2000 00:26:25 +0200 (CEST) (envelope-from ticso) Date: Sat, 16 Sep 2000 00:26:24 +0200 From: Bernd Walter To: John Baldwin Cc: "David O'Brien" , alpha@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Prelimiary interrupt thread patches for alpha Message-ID: <20000916002624.B61424@cicely5.cicely.de> References: <20000915193236.B61065@cicely5.cicely.de> <200009151803.LAA24561@pike.osd.bsdi.com> <20000915233621.A61424@cicely5.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000915233621.A61424@cicely5.cicely.de>; from ticso@cicely5.cicely.de on Fri, Sep 15, 2000 at 11:36:22PM +0200 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Sep 15, 2000 at 11:36:22PM +0200, Bernd Walter wrote: > On Fri, Sep 15, 2000 at 11:03:31AM -0700, John Baldwin wrote: > > I believe it should be worth testing as I know that the cia PCI bus driver > > is ok. In fact, most of the PCI bus drivers are fixed, so it should work > > on most alphas, AFAIK. > > OK. I took the Version from > http://people.FreeBSD.org/~jhb/patches/alpha.ithreads.patch > > With boot -v it hangs here: > [...] > Creating DISK cd0 > Creating DISK da0 > Creating DISK da1 Sorry - I forgot to cvs update so I had an older trap.c. I will retry with the propper source. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Sep 16 5:35: 7 2000 Delivered-To: freebsd-smp@freebsd.org Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by hub.freebsd.org (Postfix) with ESMTP id EEF4737B424; Sat, 16 Sep 2000 05:35:02 -0700 (PDT) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 13aHBM-0007hE-0W; Sat, 16 Sep 2000 13:35:01 +0100 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id NAA27694; Sat, 16 Sep 2000 13:12:04 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sat, 16 Sep 2000 13:10:18 +0100 (BST) From: Doug Rabson To: John Baldwin Cc: alpha@FreeBSD.org, smp@FreeBSD.org Subject: Re: Prelimiary interrupt thread patches for alpha In-Reply-To: <200009142254.PAA95214@pike.osd.bsdi.com> 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 Thu, 14 Sep 2000, John Baldwin wrote: > Doug Rabson wrote: > > On Wed, 13 Sep 2000, John Baldwin wrote: > > > I've updated the alpha.ithreads.patch on my freefall webpage to work with > > > the latest current, btw. > > > > I've been working on this today and I have a kernel which boots on my > > miata and is happily chewing its way through a buildworld. I fixed the > > device_get_nameunit() problem - it was just going wrong for ATA interrupts > > which are handled quite strangely on alpha. I also changed the p_comm > > string to include the whole vector number in hex since on some platforms > > all bits are relavent, not just (vec-0x900)>>4. > > > > I've attached my modified version of your patch to this message. Its not > > quite ready to commit yet since I didn't write the enable/disable hooks > > for mcpcia or dwlpx. I have an mcpcia here (the AS4100) so I'll be able to > > test that soon. > > After that last fix to trap.c to add an acquire/release of sched_lock, I > am now happily running interrupt threads on my miata here with your patch. > I've gone ahead and replaced my patch on freefall with yours, but hopefully > we can commit this very soon when you get the other PCI chipsets finished. > Thanks. :) I know have a buildworld going on my INVARIANTS kernel and it > is running fine so far. Good. I'll try to deal with mcpcia and dwlpx today or tomorrow and we can get this thing committed. After that, I can get back to trying to get a secondary CPU into the scheduler without hard-locking the machine :-). -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8348 3944 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Sep 16 5:35:11 2000 Delivered-To: freebsd-smp@freebsd.org Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by hub.freebsd.org (Postfix) with ESMTP id C330A37B422; Sat, 16 Sep 2000 05:35:04 -0700 (PDT) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 13aHBP-0007hE-0W; Sat, 16 Sep 2000 13:35:03 +0100 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id NAA27717; Sat, 16 Sep 2000 13:27:21 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sat, 16 Sep 2000 13:25:36 +0100 (BST) From: Doug Rabson To: Bernd Walter Cc: John Baldwin , alpha@FreeBSD.org, smp@FreeBSD.org Subject: Re: Prelimiary interrupt thread patches for alpha In-Reply-To: <20000915075812.B60348@cicely5.cicely.de> 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 Fri, 15 Sep 2000, Bernd Walter wrote: > On Thu, Sep 14, 2000 at 03:54:58PM -0700, John Baldwin wrote: > > After that last fix to trap.c to add an acquire/release of sched_lock, I > > am now happily running interrupt threads on my miata here with your patch. > > I've gone ahead and replaced my patch on freefall with yours, but hopefully > > we can commit this very soon when you get the other PCI chipsets finished. > > Thanks. :) I know have a buildworld going on my INVARIANTS kernel and it > > is running fine so far. > > miata means that it should be testable on a PC164 - right? The patch should work on all except AS4100 and AS8200. I would like to get some testing on tsunami, apecs and lca based machines for a sanity check but it ought to work (crossed fingers). -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8348 3944 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Sep 16 11:21:28 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id 4AEB737B424; Sat, 16 Sep 2000 11:21:21 -0700 (PDT) Received: from mail.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e8GILEQ06813 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Sat, 16 Sep 2000 20:21:16 +0200 (MET DST) Received: from cicely5.cicely.de (cicely5.cicely.de [fec0::104:200:92ff:fe9b:20e7]) by mail.cicely.de (8.11.0.Beta1/8.11.0.Beta1) with ESMTP id e8GILLI90692; Sat, 16 Sep 2000 20:21:21 +0200 (CEST) Received: (from ticso@localhost) by cicely5.cicely.de (8.11.0/8.9.2) id e8GILHk66530; Sat, 16 Sep 2000 20:21:17 +0200 (CEST) (envelope-from ticso) Date: Sat, 16 Sep 2000 20:21:17 +0200 From: Bernd Walter To: Doug Rabson Cc: John Baldwin , alpha@FreeBSD.org, smp@FreeBSD.org Subject: Re: Prelimiary interrupt thread patches for alpha Message-ID: <20000916202117.C66455@cicely5.cicely.de> References: <20000915075812.B60348@cicely5.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from dfr@nlsystems.com on Sat, Sep 16, 2000 at 01:25:36PM +0100 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Sep 16, 2000 at 01:25:36PM +0100, Doug Rabson wrote: > On Fri, 15 Sep 2000, Bernd Walter wrote: > > > On Thu, Sep 14, 2000 at 03:54:58PM -0700, John Baldwin wrote: > > > After that last fix to trap.c to add an acquire/release of sched_lock, I > > > am now happily running interrupt threads on my miata here with your patch. > > > I've gone ahead and replaced my patch on freefall with yours, but hopefully > > > we can commit this very soon when you get the other PCI chipsets finished. > > > Thanks. :) I know have a buildworld going on my INVARIANTS kernel and it > > > is running fine so far. > > > > miata means that it should be testable on a PC164 - right? > > The patch should work on all except AS4100 and AS8200. I would like to get > some testing on tsunami, apecs and lca based machines for a sanity check > but it ought to work (crossed fingers). I have an AxpPCI running 4.1-RELEASE now which I want to update to current. But at this moment I'm more interested to get it running on my PC164 system. I updated the source yesterday and it still hangs while printing the SCSI devices when using the ithread patches :( -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Sep 16 11:53:42 2000 Delivered-To: freebsd-smp@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 8567E37B424; Sat, 16 Sep 2000 11:53:35 -0700 (PDT) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id LAA00866; Sat, 16 Sep 2000 11:53:28 -0700 Date: Sat, 16 Sep 2000 11:53:03 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Doug Rabson Cc: Bernd Walter , John Baldwin , alpha@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Prelimiary interrupt thread patches for alpha In-Reply-To: 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 I can look at Rawhide and TurboLaser next week when my temperature comes down (flu). Doug- you have a rawhide. I have the turbolaseers. Why don't y'all check the patch in so we have something same to work with? On Sat, 16 Sep 2000, Doug Rabson wrote: > On Fri, 15 Sep 2000, Bernd Walter wrote: > > > On Thu, Sep 14, 2000 at 03:54:58PM -0700, John Baldwin wrote: > > > After that last fix to trap.c to add an acquire/release of sched_lock, I > > > am now happily running interrupt threads on my miata here with your patch. > > > I've gone ahead and replaced my patch on freefall with yours, but hopefully > > > we can commit this very soon when you get the other PCI chipsets finished. > > > Thanks. :) I know have a buildworld going on my INVARIANTS kernel and it > > > is running fine so far. > > > > miata means that it should be testable on a PC164 - right? > > The patch should work on all except AS4100 and AS8200. I would like to get > some testing on tsunami, apecs and lca based machines for a sanity check > but it ought to work (crossed fingers). > > -- > Doug Rabson Mail: dfr@nlsystems.com > Nonlinear Systems Ltd. Phone: +44 20 8348 3944 > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Sep 16 14:32:36 2000 Delivered-To: freebsd-smp@freebsd.org Received: from ns.plaut.de (ns.plaut.de [194.99.75.166]) by hub.freebsd.org (Postfix) with ESMTP id A03E337B43E; Sat, 16 Sep 2000 14:32:21 -0700 (PDT) Received: (from uucp@localhost) by ns.plaut.de (8.9.3/8.9.3) with UUCP id XAA96156; Sat, 16 Sep 2000 23:32:19 +0200 (CEST) (envelope-from root@nihil.plaut.de) Received: from localhost (root@localhost) by nihil.plaut.de (8.11.0/8.8.8) with ESMTP id e8GMW6A00691; Sun, 17 Sep 2000 00:32:06 +0200 (CEST) (envelope-from root@nihil.plaut.de) Date: Sun, 17 Sep 2000 00:32:01 +0200 (CEST) From: Michael Reifenberger To: FreeBSD-Current Cc: FreeBSD-SMP Subject: Debugging -current SMPNG HANG on heavy disk-io 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 Hi, -current hangs reliable (as described in another mail) for me. For short: "tar cf /dev/null /usr/ports&; tar cf - /usr/ports | tar tf -" locks the system solid after a few minutes. The first tar itself seems to need some time longer before hang. This is verified to occure with 2 different disks (IDE). Now the questions how to debug this: - How do I get a backtrace of a specific process from within DDB? - How do I determine where the system hangs/loops fromm within DDB? - How do I get the process-list (like ps) from within gdb (postmortem) Below is a first try to debug postmortem with gdb Does this look reasonable? Something else to look? ... Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Sat Sep 16 19:32:53 CEST 2000 root@nihil.plaut.de:/usr/obj/usr/src/sys/nihil Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 266615847 Hz CPU: Pentium II/Pentium II Xeon/Celeron (266.62-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183f9ff real memory = 268369920 (262080K bytes) config> #flags wdc0 0xa0ffa0ff Invalid command or syntax. Type `?' for help. config> #flags wdc1 0xa0ffa0ff Invalid command or syntax. Type `?' for help. config> #iosiz npx0 196608 Invalid command or syntax. Type `?' for help. config> #irq pcic0 11 Invalid command or syntax. Type `?' for help. config> quit avail memory = 257589248 (251552K bytes) Preloaded elf kernel "kernel.ko" at 0xc03ad000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc03ad0ac. Preloaded elf module "linux.ko" at 0xc03ad0fc. Preloaded elf module "linprocfs.ko" at 0xc03ad19c. Pentium Pro MTRR support enabled VESA: v2.0, 2496k memory, flags:0x0, mode table:0xc031ee42 (1000022) VESA: MagicGraph 256 AV 44K PRELIMINARY npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pci0: at 4.0 irq 11 isab0: at device 5.0 on pci0 isa0: on isab0 atapci0: port 0xfe60-0xfe6f at device 5.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 5.2 irq 11 pci0: at 5.3 pci0: at 9.0 irq 11 pcic-pci0: at device 11.0 on pci0 pcic-pci1: at device 11.1 on pci0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model GlidePoint, device ID 0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 ppc0: at port 0x378-0x37f irq 7 flags 0x40 on isa0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 pps0: on ppbus0 pcic0: at port 0x3e0-0x3e1 on isa0 pcic0: Polling mode pccard0: on pcic0 pccard1: on pcic0 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources pcm0: at port 0x220-0x233,0x530-0x537,0x388-0x38f,0x330-0x333,0x538-0x539 irq 5 drq 1,0 on isa0 IP packet filtering initialized, divert enabled, rule-based forwarding disabled, default to deny, logging limited to 100 packets/entry by default IPsec: Initialized Security Association Processing. ad0: 24207MB [49184/16/63] at ata0-master using UDMA33 ad1: 6194MB [13424/15/63] at ata1-master using UDMA33 Mounting root from ufs:/dev/ad0s1a pccard: card inserted, slot 0 panic: from debugger syncing disks... done Uptime: 3h22m40s dumping to dev #ad/0x20001, offset 2547840 dump ata0: resetting devices .. done 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:475 475 dumppcb.pcb_cr3 = rcr3(); (kgdb) bt #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:475 #1 0xc017aeb3 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316 #2 0xc017b255 in panic (fmt=0xc02802b4 "from debugger") at /usr/src/sys/kern/kern_shutdown.c:568 #3 0xc013b2c9 in db_panic (addr=-1071295444, have_addr=0, count=-1, modif=0xc788bd88 "") at /usr/src/sys/ddb/db_command.c:433 #4 0xc013b269 in db_command (last_cmdp=0xc02bf5b4, cmd_table=0xc02bf414, aux_cmd_tablep=0xc03002fc) at /usr/src/sys/ddb/db_command.c:333 #5 0xc013b32e in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 #6 0xc013d4eb in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:71 #7 0xc02551ca in kdb_trap (type=3, code=0, regs=0xc788beac) at /usr/src/sys/i386/i386/db_interface.c:163 #8 0xc0260fdc in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = -1070530544, tf_edi = -1070468928, tf_esi = -1070491744, tf_ebp = -947339528, tf_isp = -947339560, tf_ebx = 582, tf_edx = -1072984320, tf_ecx = 32, tf_eax = 38, tf_trapno = 3, tf_err = 0, tf_eip = -1071295444, tf_cs = 8, tf_eflags = 70, tf_esp = -1070930945, tf_ss = -1070944311}) at /usr/src/sys/i386/i386/trap.c:584 #9 0xc025542c in Debugger (msg=0xc02aafc9 "manual escape to debugger") at machine/cpufunc.h:64 #10 0xc0251f36 in scgetc (sc=0xc031f0c0, flags=2) at /usr/src/sys/dev/syscons/syscons.c:3133 #11 0xc024ef59 in sckbdevent (thiskbd=0xc0317f60, event=0, arg=0xc031f0c0) at /usr/src/sys/dev/syscons/syscons.c:634 #12 0xc0246eae in atkbd_intr (kbd=0xc0317f60, arg=0x0) at /usr/src/sys/dev/kbd/atkbd.c:462 #13 0xc026c45c in atkbd_isa_intr (arg=0xc0317f60) at /usr/src/sys/isa/atkbd_isa.c:125 #14 0xc02681a4 in ithd_loop (dummy=0x0) at /usr/src/sys/i386/isa/ithread.c:239 (kgdb) proc 35 (kgdb) bt #0 mi_switch () at /usr/src/sys/kern/kern_synch.c:953 #1 0xc017e2f0 in msleep (ident=0xc1d2fa00, mtx=0x0, priority=8, wmesg=0xc02a2c62 "inode", timo=0) at /usr/src/sys/kern/kern_synch.c:506 #2 0xc01750f2 in acquire (lkp=0xc1d2fa00, extflags=16777280, wanted=1536) at /usr/src/sys/kern/kern_lock.c:147 #3 0xc017537c in lockmgr (lkp=0xc1d2fa00, flags=16842754, interlkp=0xc9b371ec, p=0xc7874d80) at /usr/src/sys/kern/kern_lock.c:354 #4 0xc01a8ba8 in vop_stdlock (ap=0xc9608d34) at /usr/src/sys/kern/vfs_default.c:243 #5 0xc0227bd1 in ufs_vnoperate (ap=0xc9608d34) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2263 #6 0xc01b35e3 in vn_lock (vp=0xc9b37180, flags=65538, p=0xc7874d80) at vnode_if.h:840 #7 0xc01abc8b in vget (vp=0xc9b37180, flags=2, p=0xc7874d80) at /usr/src/sys/kern/vfs_subr.c:1393 #8 0xc01a6d18 in vfs_cache_lookup (ap=0xc9608df0) at /usr/src/sys/kern/vfs_cache.c:470 #9 0xc0227bd1 in ufs_vnoperate (ap=0xc9608df0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2263 #10 0xc01a9f44 in lookup (ndp=0xc9608e6c) at vnode_if.h:52 #11 0xc01a9968 in namei (ndp=0xc9608e6c) at /usr/src/sys/kern/vfs_lookup.c:153 #12 0xc01afaa9 in lstat (p=0xc7874d80, uap=0xc9608f80) at /usr/src/sys/kern/vfs_syscalls.c:1787 #13 0xc0261aec in syscall2 (frame={tf_fs = -1071316945, tf_es = 47, tf_ds = 47, tf_edi = 134971440, tf_esi = 134971436, tf_ebp = -1077937556, tf_isp = -916418604, tf_ebx = 20, tf_edx = 134935040, tf_ecx = 134935040, tf_eax = 190, tf_trapno = 7, tf_err = 2, tf_eip = 134603604, tf_cs = 31, tf_eflags = 643, tf_esp = -1077937696, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1136 #14 0xc0255b0f in Xint0x80_syscall () #15 0x804b0cd in ?? () #16 0x804b0cd in ?? () #17 0x804b0cd in ?? () #18 0x804b0cd in ?? () #19 0x804a431 in ?? () #20 0x8052801 in ?? () #21 0x8048135 in ?? () (kgdb) up #1 0xc017e2f0 in msleep (ident=0xc1d2fa00, mtx=0x0, priority=8, wmesg=0xc02a2c62 "inode", timo=0) at /usr/src/sys/kern/kern_synch.c:506 506 mi_switch(); (kgdb) up #2 0xc01750f2 in acquire (lkp=0xc1d2fa00, extflags=16777280, wanted=1536) at /usr/src/sys/kern/kern_lock.c:147 147 error = tsleep(lkp, lkp->lk_prio, lkp->lk_wmesg, lkp->lk_timo); (kgdb) up #3 0xc017537c in lockmgr (lkp=0xc1d2fa00, flags=16842754, interlkp=0xc9b371ec, p=0xc7874d80) at /usr/src/sys/kern/kern_lock.c:354 354 error = acquire(lkp, extflags, (LK_HAVE_EXCL | LK_WANT_EXCL)); (kgdb) up #4 0xc01a8ba8 in vop_stdlock (ap=0xc9608d34) at /usr/src/sys/kern/vfs_default.c:243 243 return (lockmgr(l, ap->a_flags, &ap->a_vp->v_interlock, ap->a_p)); (kgdb) up #5 0xc0227bd1 in ufs_vnoperate (ap=0xc9608d34) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2263 2263 return (VOCALL(ufs_vnodeop_p, ap->a_desc->vdesc_offset, ap)); (kgdb) up #6 0xc01b35e3 in vn_lock (vp=0xc9b37180, flags=65538, p=0xc7874d80) at vnode_if.h:840 840 rc = VCALL(vp, VOFFSET(vop_lock), &a); (kgdb) up #7 0xc01abc8b in vget (vp=0xc9b37180, flags=2, p=0xc7874d80) at /usr/src/sys/kern/vfs_subr.c:1393 1393 if ((error = vn_lock(vp, flags | LK_INTERLOCK, p)) != 0) { (kgdb) up #8 0xc01a6d18 in vfs_cache_lookup (ap=0xc9608df0) at /usr/src/sys/kern/vfs_cache.c:470 470 error = vget(vp, LK_EXCLUSIVE, p); (kgdb) up #9 0xc0227bd1 in ufs_vnoperate (ap=0xc9608df0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2263 2263 return (VOCALL(ufs_vnodeop_p, ap->a_desc->vdesc_offset, ap)); (kgdb) Bye! ---- Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Sep 16 17:59:21 2000 Delivered-To: freebsd-smp@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 08A0237B422; Sat, 16 Sep 2000 17:58:37 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e8H0wOI90602; Sun, 17 Sep 2000 10:28:24 +0930 (CST) (envelope-from grog) Date: Sun, 17 Sep 2000 10:28:24 +0930 From: Greg Lehey To: Michael Reifenberger Cc: FreeBSD-Current , FreeBSD-SMP Subject: Re: Debugging -current SMPNG HANG on heavy disk-io Message-ID: <20000917102824.C42114@wantadilla.lemis.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="/04w6evG8XlLl3ft" X-Mailer: Mutt 1.0i In-Reply-To: ; from root@nihil.plaut.de on Sun, Sep 17, 2000 at 12:32:01AM +0200 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii On Sunday, 17 September 2000 at 0:32:01 +0200, Michael Reifenberger wrote: > Hi, > -current hangs reliable (as described in another mail) for me. > For short: > "tar cf /dev/null /usr/ports&; tar cf - /usr/ports | tar tf -" > locks the system solid after a few minutes. > The first tar itself seems to need some time longer before hang. > This is verified to occure with 2 different disks (IDE). I've seen this on NFS a few weeks back, but I haven't followed through. In my case, I couldn't even get to the debugger. > Now the questions how to debug this: > - How do I get a backtrace of a specific process from within DDB? > - How do I determine where the system hangs/loops fromm within DDB? I can't give you answers for ddb. > - How do I get the process-list (like ps) from within gdb (postmortem) I have a macro which does this. I should commit some of them, but they're in terrible shape. I'm attaching them to this message. You'll have to modify at least .gdbinit.paths. > Below is a first try to debug postmortem with gdb > Does this look reasonable? Something else to look? > > #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:475 > 475 dumppcb.pcb_cr3 = rcr3(); > (kgdb) bt > #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:475 > #1 0xc017aeb3 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316 > #2 0xc017b255 in panic (fmt=0xc02802b4 "from debugger") > at /usr/src/sys/kern/kern_shutdown.c:568 > #3 0xc013b2c9 in db_panic (addr=-1071295444, have_addr=0, count=-1, > modif=0xc788bd88 "") at /usr/src/sys/ddb/db_command.c:433 > #4 0xc013b269 in db_command (last_cmdp=0xc02bf5b4, cmd_table=0xc02bf414, > aux_cmd_tablep=0xc03002fc) at /usr/src/sys/ddb/db_command.c:333 > #5 0xc013b32e in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 > #6 0xc013d4eb in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:71 > #7 0xc02551ca in kdb_trap (type=3, code=0, regs=0xc788beac) > at /usr/src/sys/i386/i386/db_interface.c:163 > #8 0xc0260fdc in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = -1070530544, > tf_edi = -1070468928, tf_esi = -1070491744, tf_ebp = -947339528, > tf_isp = -947339560, tf_ebx = 582, tf_edx = -1072984320, tf_ecx = 32, > tf_eax = 38, tf_trapno = 3, tf_err = 0, tf_eip = -1071295444, tf_cs = 8, > tf_eflags = 70, tf_esp = -1070930945, tf_ss = -1070944311}) > at /usr/src/sys/i386/i386/trap.c:584 > #9 0xc025542c in Debugger (msg=0xc02aafc9 "manual escape to debugger") > at machine/cpufunc.h:64 The frames above are what the system went to as the result of your debugger request. I'd also be interested to see the output of the 'icnt' macro (if this is UP machine) or 'icnt1' (if it's SMP), and 'ps' (the macro I promised above). > #10 0xc0251f36 in scgetc (sc=0xc031f0c0, flags=2) > at /usr/src/sys/dev/syscons/syscons.c:3133 > #11 0xc024ef59 in sckbdevent (thiskbd=0xc0317f60, event=0, arg=0xc031f0c0) > at /usr/src/sys/dev/syscons/syscons.c:634 > #12 0xc0246eae in atkbd_intr (kbd=0xc0317f60, arg=0x0) > at /usr/src/sys/dev/kbd/atkbd.c:462 > #13 0xc026c45c in atkbd_isa_intr (arg=0xc0317f60) > at /usr/src/sys/isa/atkbd_isa.c:125 The ones above are the keyboard interrupt handler. > #14 0xc02681a4 in ithd_loop (dummy=0x0) at /usr/src/sys/i386/isa/ithread.c:239 This is the interesting one. We appear to be looping in an interrupt handler. At this point, it would be very interesting to see the value of p->p_comm, which is the process name at the end of the ps listing. > (kgdb) proc 35 Why are you interested in this process? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=".gdbinit" source .gdbinit.kernel source .gdbinit.paths tr --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=".gdbinit.paths" # GRRR # set remotebaud 115200 set remotebaud 9600 set remotetimeout 1 set complaints 1 set print pretty # dir /src/ZAPHOD/src/sys/modules/vinum # dir /src/ZAPHOD/src/sys/i386/conf # dir /src/ZAPHOD/src/sys dir src/sys/i386/conf dir src/sys file src/sys/compile/ZAPHODng/kernel.ko.debug define asf set $file = linker_files.tqh_first set $found = 0 while ($found == 0) if (*$file->filename == 'v') set $found = 1 else set $file = $file->link.tqe_next end end shell /usr/bin/objdump --section-headers sys/modules/vinum/vinum.ko | grep ' .text' | awk '{print "add-symbol-file sys/modules/vinum/vinum.ko \$file->address+0x" $4}' > .asf source .asf end document asf Find the load address of Vinum in the kernel and add the symbols at this address end --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=".gdbinit.kernel" define xi x/10i $eip end define xs x/12x $esp end define xb x/12x $ebp end define z ni x/1i $eip end define zs si x/1i $eip end define xp printf " esp: " output/x $esp echo ( output (((int)$ebp)-(int)$esp)/4-4 printf " words on stack)\n ebp: " output/x $ebp printf "\n eip: " x/1i $eip printf "Saved ebp: " output/x *(int*)$ebp printf " (maximum of " output ((*(int*)$ebp)-(int)$ebp)/4-4 printf " parameters possible)\nSaved eip: " x/1i *(int*)($ebp+4) printf "\nParm 1 at " output/x (int) ($ebp+8) printf ": " output (char*) *(int*)($ebp+8) printf "\nParm 2 at " output/x (int) ($ebp+12) printf ": " output (char*) *(int*)($ebp+12) printf "\nParm 3 at " output/x (int) ($ebp+16) printf ": " output (char*) *(int*)($ebp+16) printf "\nParm 4 at " output/x (int) ($ebp+20) printf ": " output (char*) *(int*)($ebp+20) echo \n end document xp Show the register contents and the first four parameter words of the current frame. end define xxp printf " esp: " output/x $esp printf "\n ebp: " output/x $ebp printf "\n eip: " x/1i $eip printf "Saved ebp: " output/x *(int*)$ebp printf " (maximum of " output ((*(int*)$ebp)-(int)$ebp)/4-4 printf " parameters possible)\nSaved eip: " x/1i *(int*)($ebp+4) printf "\nParm 1 at " output/x (int) ($ebp+8) printf ": " output (char*) *(int*)($ebp+8) printf "\nParm 2 at " output/x (int) ($ebp+12) printf ": " output (char*) *(int*)($ebp+12) printf "\nParm 3 at " output/x (int) ($ebp+16) printf ": " output (char*) *(int*)($ebp+16) printf "\nParm 4 at " output/x (int) ($ebp+20) printf ": " output (char*) *(int*)($ebp+20) printf "\nParm 5 at " output/x (int) ($ebp+24) printf ": " output (char*) *(int*)($ebp+24) printf "\nParm 6 at " output/x (int) ($ebp+28) printf ": " output (char*) *(int*)($ebp+28) printf "\nParm 7 at " output/x (int) ($ebp+32) printf ": " output (char*) *(int*)($ebp+32) printf "\nParm 8 at " output/x (int) ($ebp+36) printf ": " output (char*) *(int*)($ebp+36) printf "\nParm 9 at " output/x (int) ($ebp+40) printf ": " output (char*) *(int*)($ebp+40) printf "\nParm 10 at " output/x (int) ($ebp+44) printf ": " output (char*) *(int*)($ebp+44) echo \n end document xxp Show the register contents and the first ten parameter words of the current frame. end define xp0 x/12x *(int*)$esp p *(int*)$esp p (char*)*$esp end define xp1 x/12x *(int*)($ebp+4) p *(int*)($ebp+4) p (char**)($ebp+4) end define xp2 x/12x *(int*)($ebp+8) p *(int*)($ebp+8) p *(char**)($ebp+8) end define xp3 x/12x *(int*)($ebp+12) p *(int*)($ebp+12) p (char**)($ebp+12) end define xp4 x/12x *(int*)($ebp+16) p *(int*)($ebp+16) p (char**)($ebp+16) end document xp0 Show the first parameter of current stack frame in various formats end document xp1 Show the second parameter of current stack frame in various formats end document xp2 Show the third parameter of current stack frame in various formats end document xp3 Show the fourth parameter of current stack frame in various formats end document xp4 Show the fifth parameter of current stack frame in various formats end define f0 f 0 xp end define f1 f 1 xp end define f2 f 2 xp end define f3 f 3 xp end define f4 f 4 xp end define f5 f 5 xp end document f0 Select stack frame 0 and show assembler-level details end document f1 Select stack frame 1 and show assembler-level details end document f2 Select stack frame 2 and show assembler-level details end document f3 Select stack frame 3 and show assembler-level details end document f4 Select stack frame 4 and show assembler-level details end document f5 Select stack frame 5 and show assembler-level details end document z Single step 1 instruction (over calls) and show next instruction. end document zs Single step 1 instruction (through calls) and show next instruction. end document xi List the next 10 instructions from the current IP value end document xs Show the last 12 words on stack in hex end document xb Show 12 words starting at current BP value in hex end define tr target remote /dev/cuaa0 end document tr Attach to a remote kernel via /dev/cuaa0 end set output-radix 16 define pname p (char *)curproc->p_comm end document pname Print the command name of the current process end define bpp set $bp = (struct buf *) $arg0 if $bp->b_io.bio_dev printf " Buffer at 0x%x: dev 0x%x data 0x%x bcount 0x%x blkno 0x%x resid 0x%x\n", \ $bp, \ $bp->b_io.bio_dev->si_udev, \ $bp->b_io.bio_data, \ $bp->b_io.bio_bcount, \ $bp->b_io.bio_blkno, \ $bp->b_io.bio_resid else printf " Buffer at 0x%x: dev (none) data 0x%x bcount 0x%x blkno 0x%x resid 0x%x\n", \ $bp, \ $bp->b_io.bio_data, \ $bp->b_io.bio_bcount, \ $bp->b_io.bio_blkno, \ $bp->b_io.bio_resid end printf " Command: " if $bp->b_io->bio_cmd == 1 printf "Read, " end if $bp->b_io->bio_cmd == 2 printf "Write, " end if $bp->b_io->bio_cmd == 4 printf "Delete, " end if $bp->b_io->bio_cmd == 8 printf "Format, " end printf "flags 0x%x: ", $bp->b_flags if $bp->b_flags & 0x200 printf "done " end if $bp->b_flags & 0x800 printf "error " end if $bp->b_flags & 0x40000 printf "phys " end printf "\n" end define bpl set $bp = (struct buf *) $arg0 printf "b_proc: " output $bp->b_proc printf "\nb_flags: " output $bp->b_flags printf "\nb_qindex: " output $bp->b_qindex printf "\nb_usecount: " output $bp->b_usecount printf "\nb_error: " output $bp->b_error printf "\nb_bufsize: " output $bp->b_bufsize printf "\nb_io.bio_bcount: " output $bp->b_io.bio_bcount printf "\nb_io.bio_resid: " output $bp->b_io.bio_resid printf "\nb_io.bio_dev: " output $bp->b_io.bio_dev printf "\nb_io.bio_data: " output $bp->b_io.bio_data printf "\nb_kvasize: " output $bp->b_kvasize printf "\nb_lblkno: " output $bp->b_lblkno printf "\nb_io.bio_blkno: " output $bp->b_io.bio_blkno printf "\nb_iodone: " output $bp->b_iodone printf "\nb_vp: " output $bp->b_vp printf "\nb_dirtyoff: " output $bp->b_dirtyoff printf "\nb_dirtyend: " output $bp->b_dirtyend printf "\nb_generation: " output $bp->b_generation printf "\nb_rcred: " output $bp->b_rcred printf "\nb_wcred: " output $bp->b_wcred printf "\nb_validoff: " output $bp->b_validoff printf "\nb_validend: " output $bp->b_validend printf "\nb_pblkno: " output $bp->b_pblkno printf "\nb_saveaddr: " output $bp->b_saveaddr printf "\nb_savekva: " output $bp->b_savekva printf "\nb_driver1: " output $bp->b_driver1 printf "\nb_driver2: " output $bp->b_driver2 printf "\nb_spc: " output $bp->b_spc printf "\nb_npages: " output $bp->b_npages printf "\n" end define bp bpp bp end define bpd printf "Buffer data:\n%s", (char *) bp->b_io.bio_data end document bpd Show the contents (char*) of bp->data in the current frame. end document bp Show information about the buffer header pointed to by the variable bp in the current frame. end document bpp Show summary information about the buffer header (struct bp) pointed at by the parameter. end document bpl Show detailled information about the buffer header (struct bp) pointed at by the parameter. end document bpl Show detailled information about the buffer header (struct bp) pointed at by the local variable bp. end define bx printf "\n b_vnbufs " output/x bp->b_vnbufs printf "\n b_freelist " output/x bp->b_freelist printf "\n b_act " output/x bp->b_act printf "\n b_flags " output/x bp->b_flags printf "\n b_qindex " output/x bp->b_qindex printf "\n b_usecount " output/x bp->b_usecount printf "\n b_error " output/x bp->b_error printf "\n b_bufsize " output/x bp->b_bufsize printf "\n b_io.bio_bcount " output/x bp->b_io.bio_bcount printf "\n b_io.bio_resid " output/x bp->b_io.bio_resid printf "\n b_io.bio_dev " output/x bp->b_io.bio_dev printf "\n b_io.bio_data " output/x bp->b_io.bio_data printf "\n b_kvasize " output/x bp->b_kvasize printf "\n b_io.bio_blkno " output/x bp->b_io.bio_blkno printf "\n b_iodone_chain " output/x bp->b_iodone_chain printf "\n b_vp " output/x bp->b_vp printf "\n b_dirtyoff " output/x bp->b_dirtyoff printf "\n b_validoff " output/x bp->b_validoff echo \n end define ddb set boothowto=0x80000000 s end document ddb Switch back to ddb. end define ps set $nproc = nprocs set $aproc = allproc.lh_first set $proc = allproc.lh_first printf " pid proc addr uid pri ppid pgrp flag stat comm wchan\n" while (--$nproc >= 0) set $pptr = $proc.p_pptr if ($pptr == 0) set $pptr = $proc end if ($proc.p_stat) printf "%5d %08x %08x %4d ", \ $proc.p_pid, $aproc, \ $proc.p_addr, $proc.p_cred->p_ruid if ($proc.p_rtprio.type == 3) printf "%3d ", $pptr->p_priority else printf "%3d*", $proc.p_rtprio.prio end printf "%5d %5d %06x %d %-10s ", \ $pptr->p_pid, $proc.p_pgrp->pg_id, $proc.p_flag, $proc.p_stat, \ &$proc.p_comm[0] if ($proc.p_wchan) if ($proc.p_wmesg) printf "%s ", $proc.p_wmesg end printf "%x", $proc.p_wchan end printf "\n" end set $aproc = $proc.p_list.le_next if ($aproc == 0 && $nproc > 0) set $aproc = zombproc end set $proc = $aproc end end document ps "ps" -- when kernel debugging, type out a ps-like listing of active processes. end define pregs set $nproc = nprocs set $aproc = allproc.lh_first set $proc = allproc.lh_first while (--$nproc >= 0) set $pptr = $proc.p_pptr if ($proc->p_pid == $arg0) set $pcba = $pptr->p_addr->u_pcb printf "eax\t%d\t%x", $pcba->pcb_eax, $pcba->pcb_eax printf "ecx\t%d\t%x", $pcba->pcb_ecx, $pcba->pcb_ecx printf "edx\t%d\t%x", $pcba->pcb_edx, $pcba->pcb_edx printf "ebx\t%d\t%x", $pcba->pcb_ebx, $pcba->pcb_ebx printf "esp\t%d\t%x", $pcba->pcb_esp, $pcba->pcb_esp printf "ebp\t%d\t%x", $pcba->pcb_ebp, $pcba->pcb_ebp printf "esi\t%d\t%x", $pcba->pcb_esi, $pcba->pcb_esi printf "edi\t%d\t%x", $pcba->pcb_edi, $pcba->pcb_edi printf "eip\t%d\t%x", $pcba->pcb_eip, $pcba->pcb_eip printf "eflags\t%d\t%x", $pcba->pcb_eflags, $pcba->pcb_eflags printf "cs\t%d\t%x", $pcba->pcb_cs, $pcba->pcb_cs printf "ss\t%d\t%x", $pcba->pcb_ss, $pcba->pcb_ss printf "ds\t%d\t%x", $pcba->pcb_ds, $pcba->pcb_ds printf "es\t%d\t%x", $pcba->pcb_es, $pcba->pcb_es printf "fs\t%d\t%x", $pcba->pcb_fs, $pcba->pcb_fs printf "gs\t%d\t%x", $pcba->pcb_gs, $pcba->pcb_gs x/1i $pcba->pcb_eip set $nproc = 0 end set $aproc = $proc.p_list.le_next if ($aproc == 0 && $nproc > 0) set $aproc = zombproc end set $proc = $aproc end end document pregs Show some pcb contents of process whose pid is specified. end define btr set $frame = $arg0 set $fno = 0 while (*(int *) $frame > 0xc0000000) set $myebp = *(int *) $frame set $myeip = *(int *) ($frame + 4) printf " frame %d at %p: ebp %8x, eip ", $fno, $frame, $myebp x/1i $myeip set $frame = $myebp set $fno = $fno + 1 end end document btr Show a backtrace from the ebp address specified. This can be used to get a backtrace from any stack resident in memory. end define btp set $nproc = nprocs set $aproc = allproc.lh_first set $proc = allproc.lh_first while (--$nproc >= 0) if ($proc->p_pid == $arg0) btr $proc->p_addr->u_pcb->pcb_ebp set $nproc = 0 else set $aproc = $proc.p_list.le_next if ($aproc == 0 && $nproc > 0) set $aproc = zombproc end set $proc = $aproc end end end document btp Show a backtrace for the process whose pid is specified as a parameter. end define btpa set $nproc = nprocs set $aproc = allproc.lh_first set $proc = allproc.lh_first printf " pid proc addr uid ppid pgrp flag stat comm wchan\n" while (--$nproc >= 0) set $pptr = $proc.p_pptr if ($pptr == 0) set $pptr = $proc end if ($proc.p_stat) printf "%5d %08x %08x %4d %5d %5d %06x %d %-10s ", \ $proc.p_pid, $aproc, \ $proc.p_addr, $proc.p_cred->p_ruid, $pptr->p_pid, \ $proc.p_pgrp->pg_id, $proc.p_flag, $proc.p_stat, \ &$proc.p_comm[0] if ($proc.p_wchan) if ($proc.p_wmesg) printf "%s ", $proc.p_wmesg end printf "%x", $proc.p_wchan end printf "\n" if ($proc->p_flag & 4) btr $proc->p_addr->u_pcb->pcb_ebp else echo (not loaded)\n end end set $aproc = $proc.p_list.le_next if ($aproc == 0 && $nproc > 0) set $aproc = zombproc end set $proc = $aproc end end document btpa Show backtraces for all processes in the system. end define btpp if ($myvectorproc->p_flag & 4) btr $myvectorproc->p_addr->u_pcb->pcb_ebp else echo (not loaded)\n end end document btpp Show a backtrace for the process previously selected with 'defproc'. end define defproc set $nproc = nprocs set $aproc = allproc.lh_first set $proc = allproc.lh_first while (--$nproc >= 0) if ($proc->p_pid == $arg0) set $pptr = $proc.p_pptr if ($pptr == 0) set $pptr = $proc end set $myvectorproc = $proc if ($proc.p_stat) printf "%5d %08x %08x %4d %5d %5d %06x %d %-10s ", \ $proc.p_pid, $aproc, \ $proc.p_addr, $proc.p_cred->p_ruid, $pptr->p_pid, \ $proc.p_pgrp->pg_id, $proc.p_flag, $proc.p_stat, \ &$proc.p_comm[0] if ($proc.p_wchan) if ($proc.p_wmesg) printf "%s ", $proc.p_wmesg end printf "%x", $proc.p_wchan end printf "\n" end btpp set $nproc = 0 else set $proc = $proc.p_list.le_next end end end document defproc Specify a process for btpp and fr commands. end define fr set $fno = 0 set $searching = 1 if ($myvectorproc->p_flag & 4) set $frame = $myvectorproc->p_addr->u_pcb->pcb_ebp while (($searching == 1) && (*(int *) $frame > 0xc0000000)) set $myebp = *(int *) $frame set $myeip = *(int *) ($frame + 4) if ($fno == $arg0) printf " frame %d at %p: ebp %8x, eip ", $fno, $frame, $myebp x/1i $myeip printf "Called from %8x, stack frame at %8x\n", *(int *) ($myebp+4), *(int *) $myebp printf "last 20 local variables:\n" x/20x ($myebp-80) printf "call parameters:\n" x/8x ($myebp+8) set $searching = 0 else set $frame = $myebp set $fno = $fno + 1 end end if ($searching == 1) echo frame not found\n end else printf "process %d is not loaded in memory\n", $myvectorproc->p_pid end end document fr Show the frame of the stack of the process previously selected with 'defproc'. end set height 70 set width 120 define vdev if (vp->v_type == VBLK) p *vp->v_un.vu_spec.vu_specinfo printf "numoutput: %d\n", vp->v_numoutput else echo "Not a block device" end end document vdev Show some information of the vnode pointed to by the local variable vp. end define y echo Check your .gdbinit, it contains a y command\n end define kldstat set $file = linker_files.tqh_first printf "Id Refs Address Size Name\n" while ($file != 0) printf "%2d %4d 0x%8x %8x %s\n", \ $file->id, \ $file->refs, \ $file->address, \ $file->size, \ $file->filename set $file = $file->link.tqe_next end end document kldstat Equivalent of the kldstat(9) command, without options. end define msgbuf printf "%s", msgbufp->msg_ptr end document msgbuf Print the system message buffer (dmesg). This can take a long time due to the time it takes to transmit the data across a serial line. end define icnt set $irq = 0 set $mask = imen while ($irq < 23) if ($mask & 1) printf "%d*\t", *intr_countp [$irq] else printf "%d\t", *intr_countp [$irq] end if (($irq & 7) == 7) printf "\n" end set $irq = $irq + 1 set $mask = $mask >> 1 end printf "\nimen: %x\n", imen end document icnt Print the interrupt counts for the first 16 interrupts end set $last=75 set $seg=43 # kmem_hdr define kmemhdr printf "\tINUSE\tCALLS\tMEMUSED\tLIMBLK\tMAPBLK\tMAXUSED\t\tLIMIT\n" end # pkmem define pkmem set $kp=(struct kmemstats *)$arg0 set $n = (struct kmemstats *)$kp - (struct kmemstats *)kmemstats printf "%d:\t%d\t%d", $n, $kp->ks_inuse, $kp->ks_calls printf "\t0x%x\t%d", $kp->ks_memuse, $kp->ks_limblocks printf "\t%d\t0x%x\t\t%d\n", $kp->ks_mapblocks, $kp->ks_maxused, $kp->ks_limit end define kmemdump set $kp=(struct kmemstats *)(kmemstats + $arg0) kmemhdr pkmem $kp end define kdumpall set $i=0 kmemhdr set $kp = (struct kmemstats *)kmemstats while ($i < $last) pkmem $kp set $kp++ set $i++ end end define ktr set $idx = ktr_idx - 1 set $last = ktr_idx if ($idx == -1) set $idx = ktr_entries - 1 end if (($idx != 0) || (ktr_buf [0].ktr_tv.tv_nsec != 0)) while ($idx != $last) set $kent = &ktr_buf[$idx] set $time = $kent->ktr_tv.tv_nsec set $ts = $kent->ktr_tv.tv_sec set $desc = $kent->ktr_desc printf "%3d %d:%9.9d ", $idx, $ts, $time # printf $desc, $kent->ktr_parm1, $kent->ktr_parm2, $kent->ktr_parm3, $kent->ktr_parm4, $kent->ktr_parm5 if (ktr_extend) printf "cpu%d %s.%d\t%s\n", $kent->ktr_cpu, $kent->ktr_filename, $kent->ktr_line, $kent->ktr_desc else printf "%s %p %p %p %p %p\n", $desc, $kent->ktr_parm1, $kent->ktr_parm2, $kent->ktr_parm3, $kent->ktr_parm4, $kent->ktr_parm5 end set $idx = $idx - 1 if ($idx == -1) set $idx = ktr_entries - 1 end end end end define icnt1 set $irq = 0 set $mask = apic_imen while ($irq < 31) if ($mask & 1) printf "%d*\t", *intr_countp [$irq] else printf "%d\t", *intr_countp [$irq] end if (($irq & 7) == 7) printf "\n" end set $irq = $irq + 1 set $mask = $mask >> 1 end printf "\napic_imen: %x\n", apic_imen end document icnt1 Print the interrupt counts for the first 24 interrupts on an SMP machine. end --/04w6evG8XlLl3ft-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message