From owner-freebsd-smp Sun Apr 29 1:35:38 2001 Delivered-To: freebsd-smp@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id D00D337B422 for ; Sun, 29 Apr 2001 01:35:34 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3T8ZYV28975; Sun, 29 Apr 2001 01:35:34 -0700 (PDT) Date: Sun, 29 Apr 2001 01:35:33 -0700 From: Alfred Perlstein To: Jake Burkholder Cc: smp@FreeBSD.ORG Subject: Re: that vm diff now makes it into single user mode. Message-ID: <20010429013533.D18676@fw.wintelcom.net> References: <20010429061303.6B821223A@k7.rchrd1.on.wave.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010429061303.6B821223A@k7.rchrd1.on.wave.home.com>; from jburkholder0829@home.com on Sun, Apr 29, 2001 at 02:13:03AM -0400 X-all-your-base: are belong to us. Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Jake Burkholder [010428 23:10] wrote: > > * Alfred Perlstein [010427 04:26] wrote: > > > If you're booting diskless you get to mounting/using the md0 disk > > > and you panic because I haven't made ufs_readwrite safe. > > > > > > http://people.freebsd.org/~alfred/vm.diff > > > > I'm now building world on my p100 over NFS with the latest version > > of this patch. I'm pretty sure UFS isn't going to work all that > > well but the changes required to fix it should be minor. > > > > Review (of code and locking methods, but not style) and fixes would > > be appreciated. > > Ok. I've just looked at what you've changed by following the patch. > I started to point out what I thought were bugs, but I guess its > just stuff you haven't got to yet (sendfile). Yes, still making world over NFS here, p100 is slow. :) > i386/i386/vm_machdep.c: > > the mtx_trylock in vm_page_zero_idle is unnecessary, the lock is > already held. This whole thing needs to be non-blocking if its > going to be called from the idle loop, but I'm not sure that > that's still possible. Its currently commented out. Ok, should be fixed. I guess we now know where it could have been useful to be able to spin on a sleeplock, ie not worry about idle getting stuck on a runqueue/sleepqueue. > kern/sysv_shm.c: > > shm_deallocate_segment calls vm_object_deallocate and is called outside > of vm_mtx. Does vm_object_deallocate need vm_mtx? Noted, I'll take a look at that. Not fixed yet.. > vfs_bio.c: > > I don't see why vfs_vmio_release needs to unlock the vm_mtx, wakeup > doesn't reschedule and brelvp doesn't sleep. I'd rather it not > release the lock if it doesn't have to. That code can go several function levels deep, it was a minor optimization and I thought the comments would make it clear, however I've reverted it to not unlock and put the unlock in the caller. > > Should the second mtx_lock after vm_object_pip_wakeupn be an unlock? > Probably a typo. It is. > > vm_mmap.c: > > munmap will return with the vm_mtx held if the protection check fails. Fixed. > > vm_pageout.c: > > vm_daemon() needs an mtx_lock(vm_mtxp) at the bottom of the infinite loop. nod. > The following functions have a comment about needing the vm_mtx, but > don't have the corresponding assertions: > > MA_OWNED: vfs_page_set_valid, swp_pager_meta_build, swapout_procs > MA_NOTOWNED: brelse, vfs_unbusy_pages, vfs_busy_pages > > You might consider this style, but I'm not crazy about this kind of thing: > > gotlock = mtx_owned(vm_mtxp); > if (!gotlock) > mtx_lock(vm_mtxp); > ... > if (!gotlock) > mtx_unlock(vm_mtxp); These are for functions that can be called with or without the lock but if called with the lock must not release it, it looks like the code you have is for dealing with when code can be called without but may need to pick up Giant along the way. > I'd rather you just recurse on vm_mtx and make sure that the function > doesn't change the recursion level overall. I've been screwed more > then once by this same thing with the old got_mplock flag in > i386/i386/trap.c. Making the mutex recursive doesn't work well because of things like INTERLOCK and lockmgr. > About page faults not needing Giant, have you tried not acquiring > Giant in trap where the page faults come in? I've pushed Giant down > far enough in trap() for this to happe for i386 at least, I think Doug's > done the same for alpha. foo, i didn't see the Giant wrapper around trap_pfault, I thought I was already doing that. Thanks a ton for your input! -- -Alfred Perlstein - [alfred@freebsd.org] http://www.egr.unlv.edu/~slumos/on-netbsd.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Apr 29 3:17:25 2001 Delivered-To: freebsd-smp@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 5EBB437B424 for ; Sun, 29 Apr 2001 03:17:22 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3TAHL001521; Sun, 29 Apr 2001 03:17:21 -0700 (PDT) Date: Sun, 29 Apr 2001 03:17:21 -0700 From: Alfred Perlstein To: Jake Burkholder Cc: smp@FreeBSD.ORG Subject: Re: that vm diff now makes it into single user mode. Message-ID: <20010429031720.G18676@fw.wintelcom.net> References: <20010429061303.6B821223A@k7.rchrd1.on.wave.home.com> <20010429013533.D18676@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010429013533.D18676@fw.wintelcom.net>; from bright@wintelcom.net on Sun, Apr 29, 2001 at 01:35:33AM -0700 X-all-your-base: are belong to us. Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Alfred Perlstein [010429 01:35] wrote: > * Jake Burkholder [010428 23:10] wrote: > > > About page faults not needing Giant, have you tried not acquiring > > Giant in trap where the page faults come in? I've pushed Giant down > > far enough in trap() for this to happe for i386 at least, I think Doug's > > done the same for alpha. > > foo, i didn't see the Giant wrapper around trap_pfault, I thought > I was already doing that. ok, with the latest version: vm.vm_faults_no_vm_mtx: 118257 # in vm_fault without vm_mtx vm.vm_faults_no_giant: 109304 # in vm_fault without Giant vm.stats.vm.v_vm_faults: 133424 # in vm_fault total not bad. :) -- -Alfred Perlstein - [alfred@freebsd.org] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Apr 29 12:10:10 2001 Delivered-To: freebsd-smp@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 7C90037B424 for ; Sun, 29 Apr 2001 12:10:03 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.3/8.11.3) with ESMTP id f3TJ9up26517 for ; Sun, 29 Apr 2001 21:09:58 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200104291909.f3TJ9up26517@gratis.grondar.za> To: smp@freebsd.org Subject: sys/mutex.h sys/lock.h (and other) cleanups. Commit Candidate #2 Date: Sun, 29 Apr 2001 21:11:18 +0200 From: Mark Murray Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Please review http://people.freebsd.org/~markm/patches/sys.SYS_MUTEX.diff.3 Nothing has changed much since the last Commit Candidate; I have just merged in some big commits. Reminder - the primary purpose of these is to untangle the requirement that "major" system includes ( files) have on sys/lock.h and sys/mutex.h. Also included is a further deprecation of sys/lockmgr.h (by including it in sys/lock.h). Lesser purposes of this include sorting of the sys/*.h includes in affected files, and fixing of the problems that these sorts (may) create. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Apr 29 14:42:31 2001 Delivered-To: freebsd-smp@freebsd.org Received: from klima.physik.uni-mainz.de (klima.Physik.Uni-Mainz.DE [134.93.180.162]) by hub.freebsd.org (Postfix) with ESMTP id CFDA637B423; Sun, 29 Apr 2001 14:42:14 -0700 (PDT) (envelope-from ohartman@klima.physik.uni-mainz.de) Received: from klima.Physik.Uni-Mainz.DE (Linux@klima.Physik.Uni-Mainz.DE [134.93.180.162]) by klima.physik.uni-mainz.de (8.11.3/8.11.3) with ESMTP id f3TLgDw85926; Sun, 29 Apr 2001 23:42:14 +0200 (CEST) (envelope-from ohartman@klima.physik.uni-mainz.de) Date: Sun, 29 Apr 2001 23:42:13 +0200 (CEST) From: "Hartmann, O." To: Cc: Subject: Spontanous reboot of SMP system and FBSD 4.3 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. One of our server systems, a TYAN Thunder 2500 ServerWorks Set III HE based dual PIII based machine with AMI Enterprise 1600 RAID and 2GB RAM seems to reboot spontanously without any reason. This is the first time I realise this without having APM enabled into the kernel, which has been detected to be a reason for spontanous reboots on boards without APM to us. Well, in the time this machine rebooted itself there was no load, no extraordinary activity or heavy load. I realised this this morning checking the logs. Several days ago someone asked in the list for stability issues concerning SMP on several architectures and I responded that our TYAN Thunder 2500 based boards have run for a long time. I think I have to revise this statement. I hope it is a simple problem with the kernel config because the selected hardware, power supplies and UPS system we use is first choice for this system and showed no problems before. Does anyone know, whether the kernel options AUTO_EOI1 and AUTO_EOI2 do have serious impacts on stability? On this machine we configured kernel with both options "ON" and have had no problems within the last 9 months. I know that many system boards do not work with both options set, but the TYAN Thunder 2500 seems to do - but could this be the reason for spontanous reboots? Please help, all hints a tips are appreciated. I add the dmesg output of the system here: Copyright (c) 1992-2001 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 4.3-STABLE #74: Thu Apr 26 21:25:13 CEST 2001 root@atmos.physik.uni-mainz.de:/usr/obj/usr/src/sys/ATMOS Timecounter "i8254" frequency 1193094 Hz CPU: Pentium III/Pentium III Xeon/Celeron (868.57-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x387fbff real memory = 2147483648 (2097152K bytes) avail memory = 2087288832 (2038368K bytes) Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 Programming 16 pins in IOAPIC #1 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec00000 io1 (APIC): apic id: 3, version: 0x000f0011, at 0xfec01000 Preloaded elf kernel "kernel" at 0xc03d8000. Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard IOAPIC #1 intpin 13 -> irq 2 IOAPIC #1 intpin 12 -> irq 16 IOAPIC #1 intpin 14 -> irq 17 IOAPIC #1 intpin 7 -> irq 18 IOAPIC #1 intpin 0 -> irq 19 pci0: on pcib0 pcib3: at device 0.1 on pci0 IOAPIC #1 intpin 1 -> irq 20 pci1: on pcib3 pci1: at 0.0 irq 20 sym0: <896> port 0xf800-0xf8ff mem 0xfeafe000-0xfeafffff,0xfeafac00-0xfeafafff irq 2 at device 1.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: handling phase mismatch from SCRIPTS. sym1: <896> port 0xf400-0xf4ff mem 0xfeafc000-0xfeafdfff,0xfeafa800-0xfeafabff irq 16 at device 1.1 on pci0 sym1: Symbios NVRAM, ID 7, Fast-40, SE, parity checking sym1: open drain IRQ line driver, using on-chip SRAM sym1: using LOAD/STORE-based firmware. sym1: handling phase mismatch from SCRIPTS. pcm0: port 0xfcc0-0xfcff irq 17 at device 2.0 on pci0 pcib5: at device 3.0 on pci0 IOAPIC #1 intpin 2 -> irq 21 pci2: on pcib5 pcib6: at device 0.0 on pci2 pci3: on pcib6 amr0: mem 0xf4000000-0xf7ffffff irq 19 at device 0.0 on pci3 amr0: Firmware C158, BIOS 3.11, 64MB RAM pci2: (vendor=0x1077, dev=0x1216) at 1.0 irq 20 pci2: (vendor=0x1077, dev=0x1216) at 2.0 irq 21 fxp0: port 0xfc40-0xfc7f mem 0xfe900000-0xfe9fffff,0xfeaf9000-0xfeaf9fff irq 18 at device 7.0 on pci0 fxp0: Ethernet address 00:e0:81:00:f0:d7 isab0: at device 15.0 on pci0 isa0: on isab0 pci0: at 15.1 pci0: at 15.2 irq 19 pcib1: on motherboard pci4: on pcib1 pcib2: on motherboard pci5: on pcib2 pcib4: on motherboard pci6: on pcib4 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: on isa0 sc0: VGA <8 virtual consoles, flags=0x200> fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 flags 0x10 on isa0 sio1: type 16550A ppc0: at port 0x378-0x37f irq 7 drq 1 flags 0x8 on isa0 ppc0: SMC-like chipset (ECP-only) in ECP mode ppc0: FIFO with 16/16/8 bytes threshold lpt0: on ppbus0 lpt0: Interrupt-driven port APIC_IO: Testing 8254 interrupt delivery APIC_IO: Broken MP table detected: 8254 is not connected to IOAPIC #0 intpin 2 APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0 DUMMYNET initialized (010124) IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to deny, unlimited logging IPsec: Initialized Security Association Processing. Waiting 4 seconds for SCSI devices to settle (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. amrd0: on amr0 amrd0: 245014MB (501788672 sectors) RAID 5 (optimal) SMP: AP CPU #1 Launched! sa0 at sym1 bus 0 target 5 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit) no devsw (majdev=0 bootdev=0xa0200000) Mounting root from ufs:/dev/amrd0s1a cd0 at sym1 bus 0 target 3 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 16) cd0: cd present [329963 x 2048 byte records] ch0 at sym1 bus 0 target 5 lun 1 ch0: Removable Changer SCSI-2 device ch0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit) ch0: 6 slots, 1 drive, 0 pickers, 0 portals WARNING: / was not properly dismounted link_elf: symbol splash_register undefined fxp0: promiscuous mode enabled arp: runt packet arp: runt packet Thanks in advance, Oliver -- MfG O. Hartmann ohartman@klima.physik.uni-mainz.de ---------------------------------------------------------------- IT-Administration des Institut fuer Physik der Atmosphaere (IPA) ---------------------------------------------------------------- Johannes Gutenberg Universitaet Mainz Becherweg 21 55099 Mainz Tel: +496131/3924662 (Maschinensaal) Tel: +496131/3924144 FAX: +496131/3923532 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Apr 29 18:24:42 2001 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 46FEE37B424 for ; Sun, 29 Apr 2001 18:24:39 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id LAA32338; Mon, 30 Apr 2001 11:24:13 +1000 Date: Mon, 30 Apr 2001 11:23:08 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Mark Murray Cc: smp@FreeBSD.ORG Subject: Re: sys/mutex.h sys/lock.h (and other) cleanups. Commit Candidate #2 In-Reply-To: <200104291909.f3TJ9up26517@gratis.grondar.za> 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, 29 Apr 2001, Mark Murray wrote: > Please review > > http://people.freebsd.org/~markm/patches/sys.SYS_MUTEX.diff.3 > > Nothing has changed much since the last Commit Candidate; I have > just merged in some big commits. > > Reminder - the primary purpose of these is to untangle the requirement > that "major" system includes ( files) have on sys/lock.h > and sys/mutex.h. Also included is a further deprecation of > sys/lockmgr.h (by including it in sys/lock.h). Lesser purposes of Actually, the deprecation consists of including instead of in some headers that only need the former. is not such a header, but it still includes although this is more bogus than before. The verbose comment before this include has been copied to to many places (more than 0). > this include sorting of the sys/*.h includes in affected files, > and fixing of the problems that these sorts (may) create. Please use separate commit(s) to sort the files. Committing these first is best I guess. The differences between SYS_MUTEX.diff.2 and SYS_MUTEX.diff.3 are about half for moving around bogus includes of and . They were included recently to work around breakage of and only about 90% of them have been backed out so far. At the time they were included, they had to be included before and sorting them would been wrong. Now sorting them has no effect (except to clean things up) because including them has no effect (except to trigger bogometers). Have you tested this for alphas? Committing this is taking too long. At least we avoided - like spam (I hope). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Apr 29 23:28:19 2001 Delivered-To: freebsd-smp@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 147F937B423 for ; Sun, 29 Apr 2001 23:28:09 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.3/8.11.3) with ESMTP id f3U6Rdp31851; Mon, 30 Apr 2001 08:27:48 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200104300627.f3U6Rdp31851@gratis.grondar.za> To: Bruce Evans Cc: smp@FreeBSD.ORG Subject: Re: sys/mutex.h sys/lock.h (and other) cleanups. Commit Candidate #2 References: In-Reply-To: ; from Bruce Evans "Mon, 30 Apr 2001 11:23:08 +1000." Date: Mon, 30 Apr 2001 08:28:58 +0200 From: Mark Murray Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Sun, 29 Apr 2001, Mark Murray wrote: > > > Please review > > > > http://people.freebsd.org/~markm/patches/sys.SYS_MUTEX.diff.3 > > > > Nothing has changed much since the last Commit Candidate; I have > > just merged in some big commits. > > > > Reminder - the primary purpose of these is to untangle the requirement > > that "major" system includes ( files) have on sys/lock.h > > and sys/mutex.h. Also included is a further deprecation of > > sys/lockmgr.h (by including it in sys/lock.h). Lesser purposes of > > Actually, the deprecation consists of including instead > of in some headers that only need the former. > is not such a header, but it still includes although this > is more bogus than before. The verbose comment before this include has > been copied to to many places (more than 0). That is based on something you asked me to do? > > this include sorting of the sys/*.h includes in affected files, > > and fixing of the problems that these sorts (may) create. > > Please use separate commit(s) to sort the files. Committing these first > is best I guess. OK - I can do this, except that a) this lock/mutex dethreading is going to affect it (in some cases significantly), and b) its going to delay (perhaps by a month) the whole commit (due to other (social) pressures). > The differences between SYS_MUTEX.diff.2 and SYS_MUTEX.diff.3 are > about half for moving around bogus includes of and > . They were included recently to work around breakage > of and only about 90% of them have been backed out so > far. At the time they were included, they had to be included before > and sorting them would been wrong. Now sorting them > has no effect (except to clean things up) because including them has > no effect (except to trigger bogometers). OK - I'll clean them out too. > Have you tested this for alphas? Earlier I did. Before the commit, it will be. (Build, not run). > Committing this is taking too long. At least we avoided - > like spam (I hope). Agreed. :-( See above. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Apr 29 23:43:38 2001 Delivered-To: freebsd-smp@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 5252E37B423 for ; Sun, 29 Apr 2001 23:43:32 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.3/8.11.3) with ESMTP id f3U6hIp31951; Mon, 30 Apr 2001 08:43:20 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200104300643.f3U6hIp31951@gratis.grondar.za> To: Bruce Evans Cc: smp@FreeBSD.ORG Subject: Re: sys/mutex.h sys/lock.h (and other) cleanups. Commit Candidate #2 References: In-Reply-To: ; from Bruce Evans "Mon, 30 Apr 2001 11:23:08 +1000." Date: Mon, 30 Apr 2001 08:44:36 +0200 From: Mark Murray Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Said Bruce Evans : > Actually, the deprecation consists of including instead > of in some headers that only need the former. > is not such a header, but it still includes although this > is more bogus than before. The verbose comment before this include has > been copied to to many places (more than 0). Previously said BDE: > The mess for is much older and messier than for . > Now, is sort of an extension of , but most places > that include it are for its (intentional) side effect of including the > old lock interface, . The old lock interface will be going > away, so we shouldn't move the include of to *.c. OTOH, > the entanglement of makes it difficult to include > in the right places (if any). I think the next step should > be to include instead of in *.h. I'm confused. Does sys/lockmgr.h go into sys/lock.h for its intentional side effects or not? M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Apr 30 0:41:31 2001 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 6E40A37B423 for ; Mon, 30 Apr 2001 00:41:27 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id RAA09459; Mon, 30 Apr 2001 17:41:06 +1000 Date: Mon, 30 Apr 2001 17:40:00 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Mark Murray Cc: smp@FreeBSD.ORG Subject: Re: sys/mutex.h sys/lock.h (and other) cleanups. Commit Candidate #2 In-Reply-To: <200104300643.f3U6hIp31951@gratis.grondar.za> 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, 30 Apr 2001, Mark Murray wrote: > Said Bruce Evans : > > Actually, the deprecation consists of including instead > > of in some headers that only need the former. > > is not such a header, but it still includes although this > > is more bogus than before. The verbose comment before this include has > > been copied to to many places (more than 0). This says that the bogus include ing in is not new; it is just more bogus than before [since part (most?) of the work to remove it has been done]. > Previously said BDE: > > The mess for is much older and messier than for . > > Now, is sort of an extension of , but most places > > that include it are for its (intentional) side effect of including the > > old lock interface, . The old lock interface will be going > > away, so we shouldn't move the include of to *.c. OTOH, > > the entanglement of makes it difficult to include > > in the right places (if any). I think the next step should > > be to include instead of in *.h. > > I'm confused. Does sys/lockmgr.h go into sys/lock.h for its intentional > side effects or not? Not when the next step is completed. The intentional side effect was mostly to pollute other headers that include with also. I don't want to hold up the commit any more waiting for this. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Apr 30 0:54:52 2001 Delivered-To: freebsd-smp@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id CA73B37B424 for ; Mon, 30 Apr 2001 00:54:45 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.3/8.11.3) with ESMTP id f3U7sTp32513; Mon, 30 Apr 2001 09:54:31 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200104300754.f3U7sTp32513@gratis.grondar.za> To: Bruce Evans Cc: smp@FreeBSD.ORG Subject: Re: sys/mutex.h sys/lock.h (and other) cleanups. Commit Candidate #2 References: In-Reply-To: ; from Bruce Evans "Mon, 30 Apr 2001 17:40:00 +1000." Date: Mon, 30 Apr 2001 09:55:47 +0200 From: Mark Murray Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Not when the next step is completed. The intentional side effect was mostly > to pollute other headers that include with also. Aaaaah! OK. > I don't want to hold up the commit any more waiting for this. "GO" for commit and undo the bogosity later? :-) M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Apr 30 2:15:41 2001 Delivered-To: freebsd-smp@freebsd.org Received: from klima.physik.uni-mainz.de (klima.Physik.Uni-Mainz.DE [134.93.180.162]) by hub.freebsd.org (Postfix) with ESMTP id 5926A37B424; Mon, 30 Apr 2001 02:15:29 -0700 (PDT) (envelope-from ohartman@klima.physik.uni-mainz.de) Received: from klima.Physik.Uni-Mainz.DE (Sturm@klima.Physik.Uni-Mainz.DE [134.93.180.162]) by klima.physik.uni-mainz.de (8.11.3/8.11.3) with ESMTP id f3U9FSw89148; Mon, 30 Apr 2001 11:15:28 +0200 (CEST) (envelope-from ohartman@klima.physik.uni-mainz.de) Date: Mon, 30 Apr 2001 11:15:28 +0200 (CEST) From: "Hartmann, O." To: Cc: Subject: Unknown PCI device on TYAN Thunder 2500 w. AMI MegaRAID 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. Yesterday I posted a message about spontanous reboots on one of our TYAN 2500 based SMP machines. In one respind I was told that there is an unknown PCI device and I see, he was right. The unknown PCI device belongs to Q-Logic - and that is the vendor of the SCSI chipset on the AMI MegaRAID Enterprise 1600 we use. Here is the dmesg-output: opyright (c) 1992-2001 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 4.3-STABLE #76: Mon Apr 30 10:51:10 CEST 2001 root@atmos.physik.uni-mainz.de:/usr/obj/usr/src/sys/ATMOS Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (868.64-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x387fbff real memory = 2147483648 (2097152K bytes) avail memory = 2088067072 (2039128K bytes) Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 Programming 16 pins in IOAPIC #1 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec00000 io1 (APIC): apic id: 3, version: 0x000f0011, at 0xfec01000 Preloaded elf kernel "kernel" at 0xc0383000. Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard IOAPIC #1 intpin 13 -> irq 2 IOAPIC #1 intpin 12 -> irq 16 IOAPIC #1 intpin 7 -> irq 17 pci0: on pcib0 pcib3: at device 0.1 on pci0 IOAPIC #1 intpin 1 -> irq 18 pci1: on pcib3 pci1: at 0.0 irq 18 sym0: <896> port 0xf800-0xf8ff mem 0xfeafe000-0xfeafffff,0xfeafac00-0xfeafafff irq 2 at device 1.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: handling phase mismatch from SCRIPTS. sym1: <896> port 0xf400-0xf4ff mem 0xfeafc000-0xfeafdfff,0xfeafa800-0xfeafabff irq 16 at device 1.1 on pci0 sym1: Symbios NVRAM, ID 7, Fast-40, SE, parity checking sym1: open drain IRQ line driver, using on-chip SRAM sym1: using LOAD/STORE-based firmware. sym1: handling phase mismatch from SCRIPTS. pcib5: at device 3.0 on pci0 IOAPIC #1 intpin 2 -> irq 19 pci2: on pcib5 pcib6: at device 0.0 on pci2 IOAPIC #1 intpin 0 -> irq 20 pci3: on pcib6 amr0: mem 0xf4000000-0xf7ffffff irq 20 at device 0.0 on pci3 amr0: Firmware C158, BIOS 3.11, 64MB RAM ===>> pci2: (vendor=0x1077, dev=0x1216) at 1.0 irq 18 ===>> pci2: (vendor=0x1077, dev=0x1216) at 2.0 irq 19 fxp0: port 0xfcc0-0xfcff mem 0xfe900000-0xfe9fffff,0xfeaf9000-0xfeaf9fff irq 17 at device 7.0 on pci0 fxp0: Ethernet address 00:e0:81:00:f0:d7 isab0: at device 15.0 on pci0 isa0: on isab0 pci0: at 15.1 pcib1: on motherboard pci4: on pcib1 pcib2: on motherboard pci5: on pcib2 pcib4: on motherboard pci6: on pcib4 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: on isa0 sc0: VGA <8 virtual consoles, flags=0x200> fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 flags 0x10 on isa0 sio1: type 16550A ppc0: at port 0x378-0x37f irq 7 drq 1 flags 0x8 on isa0 ppc0: SMC-like chipset (ECP-only) in ECP mode ppc0: FIFO with 16/16/8 bytes threshold lpt0: on ppbus0 lpt0: Interrupt-driven port APIC_IO: Testing 8254 interrupt delivery APIC_IO: Broken MP table detected: 8254 is not connected to IOAPIC #0 intpin 2 APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0 DUMMYNET initialized (010124) IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to deny, unlimited logging IPsec: Initialized Security Association Processing. Waiting 4 seconds for SCSI devices to settle (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. amrd0: on amr0 amrd0: 245014MB (501788672 sectors) RAID 5 (optimal) SMP: AP CPU #1 Launched! sa0 at sym1 bus 0 target 5 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit) no devsw (majdev=0 bootdev=0xa0200000) Mounting root from ufs:/dev/amrd0s1a cd0 at sym1 bus 0 target 3 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 16) cd0: cd present [329963 x 2048 byte records] ch0 at sym1 bus 0 target 5 lun 1 ch0: Removable Changer SCSI-2 device ch0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit) ch0: 6 slots, 1 drive, 0 pickers, 0 portals link_elf: symbol splash_register undefined fxp0: promiscuous mode enabled What the heck is that? I was told that the AMI MegaRAID controllers are supported, what's up with this? On another SMP machine based on ASUS CUA4X-D, we use the AMI Elite 1600, and there is no 'unknown' device. On the TYAN based machine, ATA is diasabled as well as USB and sound. Can some help please? -- MfG O. Hartmann ohartman@klima.physik.uni-mainz.de ---------------------------------------------------------------- IT-Administration des Institut fuer Physik der Atmosphaere (IPA) ---------------------------------------------------------------- Johannes Gutenberg Universitaet Mainz Becherweg 21 55099 Mainz Tel: +496131/3924662 (Maschinensaal) Tel: +496131/3924144 FAX: +496131/3923532 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Apr 30 2:50:24 2001 Delivered-To: freebsd-smp@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id E480737B423; Mon, 30 Apr 2001 02:50:08 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.3/8.11.3) with ESMTP id f3U9t7808786; Mon, 30 Apr 2001 02:55:07 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200104300955.f3U9t7808786@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Hartmann, O." Cc: freebsd-smp@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Unknown PCI device on TYAN Thunder 2500 w. AMI MegaRAID In-reply-to: Your message of "Mon, 30 Apr 2001 11:15:28 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 Apr 2001 02:55:06 -0700 From: Mike Smith Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Dear Sirs. > > Yesterday I posted a message about spontanous reboots on one of our > TYAN 2500 based SMP machines. In one respind I was told that there is > an unknown PCI device and I see, he was right. > > The unknown PCI device belongs to Q-Logic - and that is the vendor > of the SCSI chipset on the AMI MegaRAID Enterprise 1600 we use. This is harmless; it's a feature of the transparent PCI bridge used on the Megaraid. Ignore the device; it's owned by the RAID controller. > Here is the dmesg-output: > > opyright (c) 1992-2001 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 4.3-STABLE #76: Mon Apr 30 10:51:10 CEST 2001 > root@atmos.physik.uni-mainz.de:/usr/obj/usr/src/sys/ATMOS > Timecounter "i8254" frequency 1193182 Hz > CPU: Pentium III/Pentium III Xeon/Celeron (868.64-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x683 Stepping = 3 > Features=0x387fbff > real memory = 2147483648 (2097152K bytes) > avail memory = 2088067072 (2039128K bytes) > Programming 16 pins in IOAPIC #0 > IOAPIC #0 intpin 2 -> irq 0 > Programming 16 pins in IOAPIC #1 > FreeBSD/SMP: Multiprocessor motherboard > cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 > cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 > io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec00000 > io1 (APIC): apic id: 3, version: 0x000f0011, at 0xfec01000 > Preloaded elf kernel "kernel" at 0xc0383000. > Pentium Pro MTRR support enabled > npx0: on motherboard > npx0: INT 16 interface > pcib0: on motherboard > IOAPIC #1 intpin 13 -> irq 2 > IOAPIC #1 intpin 12 -> irq 16 > IOAPIC #1 intpin 7 -> irq 17 > pci0: on pcib0 > pcib3: at device 0.1 on pci0 > IOAPIC #1 intpin 1 -> irq 18 > pci1: on pcib3 > pci1: at 0.0 irq 18 > sym0: <896> port 0xf800-0xf8ff mem 0xfeafe000-0xfeafffff,0xfeafac00-0xfeafafff irq 2 at device 1.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: handling phase mismatch from SCRIPTS. > sym1: <896> port 0xf400-0xf4ff mem 0xfeafc000-0xfeafdfff,0xfeafa800-0xfeafabff irq 16 at device 1.1 on pci0 > sym1: Symbios NVRAM, ID 7, Fast-40, SE, parity checking > sym1: open drain IRQ line driver, using on-chip SRAM > sym1: using LOAD/STORE-based firmware. > sym1: handling phase mismatch from SCRIPTS. > pcib5: at device 3.0 on pci0 > IOAPIC #1 intpin 2 -> irq 19 > pci2: on pcib5 > pcib6: at device 0.0 on pci2 > IOAPIC #1 intpin 0 -> irq 20 > pci3: on pcib6 > amr0: mem 0xf4000000-0xf7ffffff irq 20 at device 0.0 on pci3 > amr0: Firmware C158, BIOS 3.11, 64MB RAM > > ===>> pci2: (vendor=0x1077, dev=0x1216) at 1.0 irq 18 > ===>> pci2: (vendor=0x1077, dev=0x1216) at 2.0 irq 19 > > fxp0: port 0xfcc0-0xfcff mem 0xfe900000-0xfe9fffff,0xfeaf9000-0xfeaf9fff irq 17 at device 7.0 on pci0 > fxp0: Ethernet address 00:e0:81:00:f0:d7 > isab0: at device 15.0 on pci0 > isa0: on isab0 > pci0: at 15.1 > pcib1: on motherboard > pci4: on pcib1 > pcib2: on motherboard > pci5: on pcib2 > pcib4: on motherboard > pci6: on pcib4 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > psm0: irq 12 on atkbdc0 > psm0: model IntelliMouse, device ID 3 > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > sc0: on isa0 > sc0: VGA <8 virtual consoles, flags=0x200> > fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 > fdc0: FIFO enabled, 8 bytes threshold > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > sio1 at port 0x2f8-0x2ff irq 3 flags 0x10 on isa0 > sio1: type 16550A > ppc0: at port 0x378-0x37f irq 7 drq 1 flags 0x8 on isa0 > ppc0: SMC-like chipset (ECP-only) in ECP mode > ppc0: FIFO with 16/16/8 bytes threshold > lpt0: on ppbus0 > lpt0: Interrupt-driven port > APIC_IO: Testing 8254 interrupt delivery > APIC_IO: Broken MP table detected: 8254 is not connected to IOAPIC #0 intpin 2 > APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0 > DUMMYNET initialized (010124) > IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to deny, unlimited logging > IPsec: Initialized Security Association Processing. > Waiting 4 seconds for SCSI devices to settle > (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. > (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. > amrd0: on amr0 > amrd0: 245014MB (501788672 sectors) RAID 5 (optimal) > SMP: AP CPU #1 Launched! > sa0 at sym1 bus 0 target 5 lun 0 > sa0: Removable Sequential Access SCSI-2 device > sa0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit) > no devsw (majdev=0 bootdev=0xa0200000) > Mounting root from ufs:/dev/amrd0s1a > cd0 at sym1 bus 0 target 3 lun 0 > cd0: Removable CD-ROM SCSI-2 device > cd0: 20.000MB/s transfers (20.000MHz, offset 16) > cd0: cd present [329963 x 2048 byte records] > ch0 at sym1 bus 0 target 5 lun 1 > ch0: Removable Changer SCSI-2 device > ch0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit) > ch0: 6 slots, 1 drive, 0 pickers, 0 portals > link_elf: symbol splash_register undefined > fxp0: promiscuous mode enabled > > > What the heck is that? I was told that the AMI MegaRAID controllers > are supported, what's up with this? > > On another SMP machine based on ASUS CUA4X-D, we use the AMI Elite 1600, > and there is no 'unknown' device. > > On the TYAN based machine, ATA is diasabled as well as USB and sound. > > Can some help please? > > -- > MfG > O. Hartmann > > ohartman@klima.physik.uni-mainz.de > ---------------------------------------------------------------- > IT-Administration des Institut fuer Physik der Atmosphaere (IPA) > ---------------------------------------------------------------- > Johannes Gutenberg Universitaet Mainz > Becherweg 21 > 55099 Mainz > > Tel: +496131/3924662 (Maschinensaal) > Tel: +496131/3924144 > FAX: +496131/3923532 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Apr 30 11: 0:56 2001 Delivered-To: freebsd-smp@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 6DA2837B43F; Mon, 30 Apr 2001 11:00:43 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3UI0bk41212; Mon, 30 Apr 2001 11:00:37 -0700 (PDT) (envelope-from dillon) Date: Mon, 30 Apr 2001 11:00:37 -0700 (PDT) From: Matt Dillon Message-Id: <200104301800.f3UI0bk41212@earth.backplane.com> To: Alfred Perlstein Cc: smp@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: that vm diff now makes it into single user mode. References: <20010427042619.W18676@fw.wintelcom.net> <200104271757.f3RHvDW09866@earth.backplane.com> <20010427124743.E18676@fw.wintelcom.net> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :Yes, this is what I was going for, the points you made above really :clarify a lot of things, I had the general idea that this is how :things worked but wasn't sure about several more points, perhaps :you have the time to answer: : :When do vm related changes propogate to struct buf? The propogation can go in either direction but generally speaking you only have to worry about buffer cache manipulation propogating to the VM system. A buffer cache buffer (struct buf) may exist with or without its backing store attached. If the backing store is attached then the underlying VM pages are wired. If the backing store is not attached then the underlying VM pages are independant of the buffer. The buffer cache attaches and detaches backing store regularly, and much of the complexity of the buffer cache revolves around edge cases that occur due to this activity. For example, if the buffer cache detaches its backing store the paging system may then piecemeal-free the underlying pages. When the buffer cache re-attaches the backing store there may be missing pages which it must then allocate, attach, and issue I/O on. The wiring of the backing store is *NOT* a lock on the backing VM pages but does prevent them from being freed out from under you. VM pages have two notions of 'busy'. There is PG_BUSY, which is a real honest to god lock on a VM page, and there is m->busy, which is a 'soft busy' hold on the page during I/O. You will not be able to convert either of these notions into a mutex - definitely do not try to add a mutex to the vm_page structure itself. : Can is happen at interrupt time? : Is it done when asking for access/lock to a buf? (that would be ideal) : Or will I need to do locking under vfs_bio to make sure that : b->b_flags and b->b_pages are in sync wrt to vm? : :I am going for that giant vm lock. I've also removed the atomic ops :from vm_object and vm_page flags/refcounting. My guess is that this :may gain us some performance, but I'll have to see, right now anything :is better than giant and so far some cool stuff runs without the Giant :lock: I think a VM object mutex you can safely remove the atomic ops from vm_object, but I don't think you can safely remove the atomic ops from vm_page unless you intend to disable interrupts permanently (or as a permanent side effect of mutex operation) for the duration of any VM operation. Most of the vm_page related code already assumes interrupt preemption and should mostly work with SMP, perhaps with just a few tweaks. : obreak getpagesize sbrk sstk mmap ovadvise munmap mprotect madvise : mincore mmap mlock munlock minherit msync mlockall munlockall : :and.. : : vm_fault : :Using a combination of your and Doug Ambrisko's diskless stuff as :well a dusty old p100 I've got a box here that boots in under 20 :seconds, really makes the compile/test cycle amazingly tolerable. : :-- :-Alfred Perlstein - [alfred@freebsd.org] :http://www.egr.unlv.edu/~slumos/on-netbsd.html That sounds like good progress to me. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Apr 30 12: 2:16 2001 Delivered-To: freebsd-smp@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 0903537B423 for ; Mon, 30 Apr 2001 12:02:14 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3UJ1xG74775; Mon, 30 Apr 2001 12:02:00 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010429013533.D18676@fw.wintelcom.net> Date: Mon, 30 Apr 2001 12:01:19 -0700 (PDT) From: John Baldwin To: Alfred Perlstein Subject: Re: that vm diff now makes it into single user mode. Cc: smp@FreeBSD.org, Jake Burkholder Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 29-Apr-01 Alfred Perlstein wrote: > * Jake Burkholder [010428 23:10] wrote: >> >> i386/i386/vm_machdep.c: >> >> the mtx_trylock in vm_page_zero_idle is unnecessary, the lock is >> already held. This whole thing needs to be non-blocking if its >> going to be called from the idle loop, but I'm not sure that >> that's still possible. Its currently commented out. > > Ok, should be fixed. I guess we now know where it could have been > useful to be able to spin on a sleeplock, ie not worry about > idle getting stuck on a runqueue/sleepqueue. Having the idle process hold locks that other threads block on can really start wreaking havoc when you throw priority propagation into the mix. It would be best to push the page zeroing off into a very low priority kernel thread or something. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Apr 30 15: 9:53 2001 Delivered-To: freebsd-smp@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id A694437B424; Mon, 30 Apr 2001 15:09:47 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id PAA19883; Mon, 30 Apr 2001 15:09:46 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp04.primenet.com, id smtpdAAAW7aWXM; Mon Apr 30 15:09:44 2001 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id PAA12613; Mon, 30 Apr 2001 15:10:35 -0700 (MST) From: Terry Lambert Message-Id: <200104302210.PAA12613@usr01.primenet.com> Subject: Re: Spontanous reboot of SMP system and FBSD 4.3 To: ohartman@klima.physik.uni-mainz.de (Hartmann, O.) Date: Mon, 30 Apr 2001 22:10:30 +0000 (GMT) Cc: freebsd-stable@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG In-Reply-To: from "Hartmann, O." at Apr 29, 2001 11:42:13 PM X-Mailer: ELM [version 2.5 PL2] 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 > One of our server systems, a TYAN Thunder 2500 ServerWorks Set III HE > based dual PIII based machine with AMI Enterprise 1600 RAID and 2GB > RAM seems to reboot spontanously without any reason. This is the first > time I realise this without having APM enabled into the kernel, which > has been detected to be a reason for spontanous reboots on boards > without APM to us. > > Well, in the time this machine rebooted itself there was no load, no > extraordinary activity or heavy load. I realised this this morning > checking the logs. > > Several days ago someone asked in the list for stability issues concerning > SMP on several architectures and I responded that our TYAN Thunder 2500 > based boards have run for a long time. I think I have to revise this > statement. I hope it is a simple problem with the kernel config because > the selected hardware, power supplies and UPS system we use is first > choice for this system and showed no problems before. > > Does anyone know, whether the kernel options AUTO_EOI1 and AUTO_EOI2 > do have serious impacts on stability? On this machine we configured kernel > with both options "ON" and have had no problems within the last 9 > months. I know that many system boards do not work with both options > set, but the TYAN Thunder 2500 seems to do - but could this be the reason > for spontanous reboots? I have seen a number of issues with Tyan motherboards, most recently, the Tyan Tiger. I suggest you rebuild your kernel with DDB and BREAK_TO_DEBUGGER options, and do a traceback next time there is a problem. If this is a true "spontaneous reboot", you may want to tell us the load you are placing on the system, and the exact version of FreeBSD you are using. In particular, bad things can happen if you use more than 32,767 sockets on 4.3-RELEASE (among other load related issues, such as running out of mbuf clusters). On some of the Tyan Tiger boards I've fought withm the system becomes extremely unstable because the invltlb() call after switching to 4M pages is not correctly communicated to the I/O APIC, and unless you have enough memory allocations to force all 8 4M entries out, it can lose its mind, relative to the TLB of one or more of the main CPUs. If this is the case, using the DISABLE_PSE option might help you as well (this seems to be a bug in the BIOS programming of the I/O APIC; I haven't tracked it past there). Changing the code to cause an "unnecessary" reload of control register 3 could help things for you, assuining you are mapping large (4M) device memory or something like that... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Apr 30 15:19:36 2001 Delivered-To: freebsd-smp@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 42A3837B422; Mon, 30 Apr 2001 15:19:33 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3UMJOG80255; Mon, 30 Apr 2001 15:19:24 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200104302210.PAA12613@usr01.primenet.com> Date: Mon, 30 Apr 2001 15:18:46 -0700 (PDT) From: John Baldwin To: Terry Lambert Subject: Re: Spontanous reboot of SMP system and FBSD 4.3 Cc: freebsd-smp@FreeBSD.org, freebsd-stable@FreeBSD.org, (Hartmann, O.) Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 30-Apr-01 Terry Lambert wrote: > > On some of the Tyan Tiger boards I've fought withm the system > becomes extremely unstable because the invltlb() call after > switching to 4M pages is not correctly communicated to the I/O > APIC, and unless you have enough memory allocations to force all > 8 4M entries out, it can lose its mind, relative to the TLB of > one or more of the main CPUs. Ummm, what the heck are you talking about? The I/O APIC routes interrupts, it doesn't access memory. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Apr 30 15:31: 5 2001 Delivered-To: freebsd-smp@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id 32A0F37B43C; Mon, 30 Apr 2001 15:31:00 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id PAA23744; Mon, 30 Apr 2001 15:30:53 -0700 Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp10.phx.gblx.net, id smtpdLhwREa; Mon Apr 30 15:30:47 2001 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id PAA12638; Mon, 30 Apr 2001 15:31:39 -0700 (MST) From: Terry Lambert Message-Id: <200104302231.PAA12638@usr01.primenet.com> Subject: Re: Spontanous reboot of SMP system and FBSD 4.3 To: jhb@FreeBSD.ORG (John Baldwin) Date: Mon, 30 Apr 2001 22:31:34 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), freebsd-smp@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, ohartman@klima.physik.uni-mainz.de ((Hartmann O.)) In-Reply-To: from "John Baldwin" at Apr 30, 2001 03:18:46 PM X-Mailer: ELM [version 2.5 PL2] 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 > > On some of the Tyan Tiger boards I've fought withm the system > > becomes extremely unstable because the invltlb() call after > > switching to 4M pages is not correctly communicated to the I/O > > APIC, and unless you have enough memory allocations to force all > > 8 4M entries out, it can lose its mind, relative to the TLB of > > one or more of the main CPUs. > > Ummm, what the heck are you talking about? The I/O APIC routes interrupts, it > doesn't access memory. I thought all APICs participated in the MESI coherency protocol, and all had the TLB caches? The system I fought with was "SMP capable", but did not have a second CPU installed. The only things that could get out of date would be the TLB contents in the cache lines. If I grab enough resources to cause age-based TLB shootdown, I don't have the problem. Otherwise I fault in the I/O path, when paging in. Supermicro motherboards don't have the problem. Setting the "DISABLE_PSE" option makes everything happy again; I suspect forcing a shootdown via a reload of CR3, or explicitly invalidating the GDT, would fix my problem. Right now, I just up my initial resource consumption and ignore it. Without this, I get similar symptoms to what he's reporting. Oh... he will probably want to turn on INVARIANTS, too, and then convert the printf() in kern/kern_malloc.c in malloc() to actually panic for "Data modified on freelist", instead of continuing to run to a cascade failure resulting in a spontaneous reboot... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Apr 30 15:58:27 2001 Delivered-To: freebsd-smp@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id BDACD37B423; Mon, 30 Apr 2001 15:58:17 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3UMw1G81213; Mon, 30 Apr 2001 15:58:01 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200104302231.PAA12638@usr01.primenet.com> Date: Mon, 30 Apr 2001 15:57:23 -0700 (PDT) From: John Baldwin To: Terry Lambert Subject: Re: Spontanous reboot of SMP system and FBSD 4.3 Cc: ((Hartmann O.)) Cc: ((Hartmann O.)) , freebsd-stable@FreeBSD.org, freebsd-smp@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 30-Apr-01 Terry Lambert wrote: >> > On some of the Tyan Tiger boards I've fought withm the system >> > becomes extremely unstable because the invltlb() call after >> > switching to 4M pages is not correctly communicated to the I/O >> > APIC, and unless you have enough memory allocations to force all >> > 8 4M entries out, it can lose its mind, relative to the TLB of >> > one or more of the main CPUs. >> >> Ummm, what the heck are you talking about? The I/O APIC routes interrupts, >> it >> doesn't access memory. > > I thought all APICs participated in the MESI coherency protocol, > and all had the TLB caches? APIC != cache. APIC routes interrupts including device interrupts from the 8259 (in virtual wire mode) or from the I/O APIC (symmetric I/O mode used with MP) as well as IPI's. It communicates over a separate ICC bus. It does not use the same bus that the CPU cache's use. > The system I fought with was "SMP capable", but did not have a > second CPU installed. The only things that could get out of > date would be the TLB contents in the cache lines. If I grab > enough resources to cause age-based TLB shootdown, I don't have > the problem. Otherwise I fault in the I/O path, when paging in. > > Supermicro motherboards don't have the problem. > > Setting the "DISABLE_PSE" option makes everything happy again; I > suspect forcing a shootdown via a reload of CR3, or explicitly > invalidating the GDT, would fix my problem. Right now, I just up > my initial resource consumption and ignore it. > > Without this, I get similar symptoms to what he's reporting. I'm not sure why you are having a problem with this. The AP's all sit in a holding pen until the page tables have more or less stabilized at which point they flush their local TLB in ap_init() just before their first context switch. %cr3 is then reloaded on subsequent context switches. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Apr 30 19:58:57 2001 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 19EC337B423; Mon, 30 Apr 2001 19:58:54 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id MAA09241; Tue, 1 May 2001 12:58:50 +1000 Date: Tue, 1 May 2001 12:57:44 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: Alfred Perlstein , smp@FreeBSD.ORG, Jake Burkholder Subject: Re: that vm diff now makes it into single user mode. 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 Mon, 30 Apr 2001, John Baldwin wrote: > On 29-Apr-01 Alfred Perlstein wrote: > > * Jake Burkholder [010428 23:10] wrote: > >> > >> i386/i386/vm_machdep.c: > >> > >> the mtx_trylock in vm_page_zero_idle is unnecessary, the lock is > >> already held. This whole thing needs to be non-blocking if its > >> going to be called from the idle loop, but I'm not sure that > >> that's still possible. Its currently commented out. > > > > Ok, should be fixed. I guess we now know where it could have been > > useful to be able to spin on a sleeplock, ie not worry about > > idle getting stuck on a runqueue/sleepqueue. > > Having the idle process hold locks that other threads block on can really start > wreaking havoc when you throw priority propagation into the mix. It would be > best to push the page zeroing off into a very low priority kernel thread or > something. Why would that do more than move the problem (if any)? Priority propagation should allow the low-priority idle process to become high prority so that it can release its locks as necessary just as well as it allows this for any other low-priority process. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Apr 30 21: 6:27 2001 Delivered-To: freebsd-smp@freebsd.org Received: from cr66388-a.rchrd1.on.wave.home.com (cr66388-a.rchrd1.on.wave.home.com [24.114.165.24]) by hub.freebsd.org (Postfix) with ESMTP id 0A40237B422; Mon, 30 Apr 2001 21:06:23 -0700 (PDT) (envelope-from jburkholder0829@home.com) Received: from k7.rchrd1.on.wave.home.com (k7.rchrd1.on.wave.home.com [10.0.0.253]) by cr66388-a.rchrd1.on.wave.home.com (Postfix) with ESMTP id 3336B196; Tue, 1 May 2001 00:06:33 -0400 (EDT) Received: from k7.rchrd1.on.wave.home.com (localhost [127.0.0.1]) by k7.rchrd1.on.wave.home.com (Postfix) with ESMTP id 5C10F22A5; Tue, 1 May 2001 00:09:03 -0400 (EDT) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Bruce Evans Cc: John Baldwin , Alfred Perlstein , smp@FreeBSD.ORG, Jake Burkholder Subject: Re: that vm diff now makes it into single user mode. In-Reply-To: Message from Bruce Evans of "Tue, 01 May 2001 12:57:44 +1000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 May 2001 00:09:03 -0400 From: Jake Burkholder Message-Id: <20010501040903.5C10F22A5@k7.rchrd1.on.wave.home.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Mon, 30 Apr 2001, John Baldwin wrote: > > > On 29-Apr-01 Alfred Perlstein wrote: > > > * Jake Burkholder [010428 23:10] wrote: > > >> > > >> i386/i386/vm_machdep.c: > > >> > > >> the mtx_trylock in vm_page_zero_idle is unnecessary, the lock is > > >> already held. This whole thing needs to be non-blocking if its > > >> going to be called from the idle loop, but I'm not sure that > > >> that's still possible. Its currently commented out. > > > > > > Ok, should be fixed. I guess we now know where it could have been > > > useful to be able to spin on a sleeplock, ie not worry about > > > idle getting stuck on a runqueue/sleepqueue. > > > > Having the idle process hold locks that other threads block on can really start > > wreaking havoc when you throw priority propagation into the mix. It would be > > best to push the page zeroing off into a very low priority kernel thread or > > something. > > Why would that do more than move the problem (if any)? Priority > propagation should allow the low-priority idle process to become high > prority so that it can release its locks as necessary just as well as > it allows this for any other low-priority process. > Because the idle process is special. It has low priority but is never placed on a run queue like other processes. Usually what happens is propogate_priority derefences a NULL pointer when it tries to remove the idle proc from the run queue and place it on a higher priority one. Using a normal low priority kernel thread should solve the problem. However, I'm concerned that it would consume too much cpu time due to hardclock not being to force a reschedule while it is running. Interrupt threads would preempt it and allow other processes to run when they "return", but asts would not happen due to it being in kernel mode all the time. I suppose that the old idle loop would have had the same effect. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Apr 30 22:21:26 2001 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 823AB37B422; Mon, 30 Apr 2001 22:21:22 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id PAA25438; Tue, 1 May 2001 15:21:17 +1000 Date: Tue, 1 May 2001 15:20:11 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Jake Burkholder Cc: John Baldwin , Alfred Perlstein , smp@FreeBSD.ORG Subject: Re: that vm diff now makes it into single user mode. In-Reply-To: <20010501040903.5C10F22A5@k7.rchrd1.on.wave.home.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 Tue, 1 May 2001, Jake Burkholder wrote: > [bde wrote] > > On Mon, 30 Apr 2001, John Baldwin wrote: > > > Having the idle process hold locks that other threads block on can really start > > > wreaking havoc when you throw priority propagation into the mix. It would be > > > best to push the page zeroing off into a very low priority kernel thread or > > > something. > > > > Why would that do more than move the problem (if any)? Priority > > propagation should allow the low-priority idle process to become high > > prority so that it can release its locks as necessary just as well as > > it allows this for any other low-priority process. > > Because the idle process is special. It has low priority but is > never placed on a run queue like other processes. Usually what > happens is propogate_priority derefences a NULL pointer when it > tries to remove the idle proc from the run queue and place it on > a higher priority one. I think it shouldn't exist then. If it can't do much except loop, then it can be reduced to a loop like the old idle loop. The loop can't even have an APM call like some versions of the old idle loop, since APM might need a sleep mutex. > Using a normal low priority kernel thread should solve the problem. > However, I'm concerned that it would consume too much cpu time due > to hardclock not being to force a reschedule while it is running. > Interrupt threads would preempt it and allow other processes to run > when they "return", but asts would not happen due to it being in > kernel mode all the time. I suppose that the old idle loop would > have had the same effect. The old idle loop handled this by zeroing at most one page per iteration. A separate thread could limit itself similarly by giving up control if cnt.v_intr increases while one page is being zeroed. However, I think the watermarks make the efficiency issues moot if they (the watermarks) actually work. vm_page_zero_idle() (better: the idle loop itself) can just check the watermarks and wake up the process if there is enough to do. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue May 1 7:49:19 2001 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 44B6F37B424 for ; Tue, 1 May 2001 07:49:16 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f41En1K20514; Tue, 1 May 2001 07:49:01 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f41EkIN47396; Tue, 1 May 2001 07:46:18 -0700 (PDT) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 01 May 2001 07:46:18 -0700 (PDT) Organization: BSD, Inc. From: John Baldwin To: Bruce Evans Subject: Re: that vm diff now makes it into single user mode. Cc: Jake Burkholder , smp@FreeBSD.ORG, Alfred Perlstein Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 01-May-01 Bruce Evans wrote: > On Mon, 30 Apr 2001, John Baldwin wrote: > >> On 29-Apr-01 Alfred Perlstein wrote: >> > * Jake Burkholder [010428 23:10] wrote: >> >> >> >> i386/i386/vm_machdep.c: >> >> >> >> the mtx_trylock in vm_page_zero_idle is unnecessary, the lock is >> >> already held. This whole thing needs to be non-blocking if its >> >> going to be called from the idle loop, but I'm not sure that >> >> that's still possible. Its currently commented out. >> > >> > Ok, should be fixed. I guess we now know where it could have been >> > useful to be able to spin on a sleeplock, ie not worry about >> > idle getting stuck on a runqueue/sleepqueue. >> >> Having the idle process hold locks that other threads block on can really >> start >> wreaking havoc when you throw priority propagation into the mix. It would >> be >> best to push the page zeroing off into a very low priority kernel thread or >> something. > > Why would that do more than move the problem (if any)? Priority > propagation should allow the low-priority idle process to become high > prority so that it can release its locks as necessary just as well as > it allows this for any other low-priority process. That doesn't work because idle processes aren't on the run queue. They are simply a hold context chosen when there is no context to move to. Thus, priority propagation doesn't affect them since by this principle, every other process has higher priority than the idle process, regardless of the actual value of p_pri. > Bruce -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue May 1 13:12: 6 2001 Delivered-To: freebsd-smp@freebsd.org Received: from kobra.efd.lth.se (kobra.efd.lth.se [130.235.34.36]) by hub.freebsd.org (Postfix) with ESMTP id 71A8B37B422 for ; Tue, 1 May 2001 13:11:55 -0700 (PDT) (envelope-from jonas@palsson.net) Received: from batch-3.efd.lth.se (d98jpa@batch-3 [130.235.34.55]) by kobra.efd.lth.se (8.10.1/8.10.1) with ESMTP id f41KBre06558 for ; Tue, 1 May 2001 22:11:53 +0200 (MET DST) Received: from localhost (d98jpa@localhost) by batch-3.efd.lth.se (8.8.8/8.8.8) with ESMTP id WAA25117 for ; Tue, 1 May 2001 22:11:48 +0200 (MET DST) X-Authentication-Warning: batch-3.efd.lth.se: d98jpa owned process doing -bs Date: Tue, 1 May 2001 22:11:47 +0200 (MET DST) From: Jonas Palsson X-Sender: d98jpa@batch-3.efd.lth.se To: smp@FreeBSD.org Subject: interrupt problem 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, msmith told me to send a mail here with my problem. I have a dual Pentium 200 with an old Tyan Tomcat III motherboard and i have some problems with interrupts (I think that is the problem). You removed the NINTR option in the kernel and defaults to 24 interrupts and i only have 15 interrupts on my motherboard. My nics get irq 16 and 17 and i can upload to the nics with full speed but when i download from them i get really croppy speed like 20kb/s. I hope you guys can help me out. //Jonas Here follows information from dmesg and mptable: -------------------------------------------------------------------------- Copyright (c) 1992-2001 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 4.3-RELEASE #0: Thu Apr 26 21:13:02 CEST 2001 root@zorg.palsson.net:/usr/src/sys/compile/ZORGKERNEL Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P54C (199.43-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping = 12 Features=0x3bf real memory = 134217728 (131072K bytes) config> di sn0 No such device: sn0 Invalid command or syntax. Type `?' for help. config> di lnc0 No such device: lnc0 Invalid command or syntax. Type `?' for help. config> di ie0 No such device: ie0 Invalid command or syntax. Type `?' for help. config> di fe0 No such device: fe0 Invalid command or syntax. Type `?' for help. config> di ed0 No such device: ed0 Invalid command or syntax. Type `?' for help. config> di cs0 No such device: cs0 Invalid command or syntax. Type `?' for help. config> q avail memory = 127643648 (124652K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00030010, at 0xfee00000 cpu1 (AP): apic id: 1, version: 0x00030010, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc02f2000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc02f209c. Intel Pentium detected, installing workaround for F00F bug md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard IOAPIC #0 intpin 19 -> irq 2 IOAPIC #0 intpin 18 -> irq 16 pci0: on pcib0 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x9000-0x900f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 17.0 irq 2 xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0x6000-0x607f mem 0xe4000000-0xe400007f irq 16 at device 18.0 on pci0 xl0: Ethernet address: 00:10:5a:10:5c:6b miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: port 0x6100-0x61ff mem 0xe4001000-0xe40010ff irq 17 at device 19.0 on pci0 rl0: Ethernet address: 00:00:e8:73:4d:c6 miibus1: on rl0 rlphy0: on miibus1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 ppc0: parallel port not found. APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to accept, logging limited to 10 packets/entry by default DUMMYNET initialized (010124) IP Filter: v3.4.16 initialized. Default = pass all, Logging = enabled SMP: AP CPU #1 Launched! ad0: 17206MB [34960/16/63] at ata0-master WDMA2 Mounting root from ufs:/dev/ad0s1a ------------------------------------------------------------------------ =============================================================================== MPTable, version 2.0.15 mptable: mem open: Permission denied jonas@zorg:~$ su Password: Sorry jonas@zorg:~$ su Password: root@zorg:/home/jonas# mptable =============================================================================== MPTable, version 2.0.15 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f0c80 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0xf4 mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000f0c94 signature: 'PCMP' base table length: 292 version: 1.1 checksum: 0xa5 OEM ID: 'OEM00000' Product ID: 'PROD00000000' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 28 local APIC address: 0xfee00000 extended table length: 0 extended table checksum: 0 ------------------------------------------------------------------------------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 0 0x11 BSP, usable 5 2 1 0x07bf 1 0x11 AP, usable 5 2 1 0x07bf -- Bus: Bus ID Type 0 ISA 1 PCI -- I/O APICs: APIC ID Version State Address 2 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT conforms conforms 0 0 2 0 INT conforms conforms 0 1 2 1 INT conforms conforms 0 0 2 2 INT conforms conforms 0 3 2 3 INT conforms conforms 0 4 2 4 INT conforms conforms 0 5 2 5 INT conforms conforms 0 6 2 6 INT conforms conforms 0 7 2 7 INT conforms conforms 0 8 2 8 INT conforms conforms 0 9 2 9 INT conforms conforms 0 10 2 10 INT conforms conforms 0 11 2 11 INT conforms conforms 0 12 2 12 INT conforms conforms 0 13 2 13 INT conforms conforms 0 14 2 14 INT conforms conforms 0 15 2 15 INT active-lo level 1 20:A 2 16 INT active-lo level 1 19:A 2 17 INT active-lo level 1 18:A 2 18 INT active-lo level 1 17:A 2 19 SMI conforms conforms 0 0 2 23 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT active-hi edge 0 0 255 0 NMI active-hi edge 0 0 255 1 =============================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu May 3 17:23:44 2001 Delivered-To: freebsd-smp@freebsd.org Received: from dns1.ahaza.com (maitai.ahaza.com [209.180.220.98]) by hub.freebsd.org (Postfix) with ESMTP id E733437B422 for ; Thu, 3 May 2001 17:23:41 -0700 (PDT) (envelope-from twiess@ahaza.com) Received: from relay.ux.ahaza.com ([209.180.221.130]) by dns1.ahaza.com (8.11.1/8.11.1) with ESMTP id f440NUF39123 for ; Thu, 3 May 2001 17:23:31 -0700 (PDT) (envelope-from twiess@ahaza.com) Received: from eunice.camelot.ahaza.com (eunice.camelot.ahaza.com [172.16.30.18]) by relay.ux.ahaza.com (8.11.1/8.11.1) with ESMTP id f440NUq45328 for ; Thu, 3 May 2001 17:23:30 -0700 (PDT) (envelope-from twiess@ahaza.com) Received: from akira.ahaza.com ([172.16.30.230]) by eunice.camelot.ahaza.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 3 May 2001 17:21:40 -0700 Date: Thu, 3 May 2001 05:24:06 +0000 (GMT) From: Tim Wiess X-X-Sender: To: Subject: KSE Message-ID: <20010503050959.U314-100000@akira.ahaza.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 04 May 2001 00:21:41.0021 (UTC) FILETIME=[30E50CD0:01C0D430] Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, Lately I have been reading about the work that is being done to support kernel scheduled entities in FreeBSD. I am very anxious to look at the code for this and see if I might be able to contribute anything to the project. Although it doesn't look like the code has been merged into CURRENT yet. Is this true? If so, does anyone know where the current development for this is being done? Thanks. tim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message