From owner-freebsd-current Sun Jul 4 9:40:36 1999 Delivered-To: freebsd-current@freebsd.org Received: from hawaii.conterra.com (hawaii.conterra.com [209.12.164.32]) by hub.freebsd.org (Postfix) with ESMTP id 9CBD014C3F for ; Sun, 4 Jul 1999 09:40:31 -0700 (PDT) (envelope-from myself@conterra.com) Received: from dmaddox.conterra.com (myself@dmaddox.conterra.com [209.12.169.48]) by hawaii.conterra.com (8.9.3/8.9.3) with ESMTP id MAA29354 for ; Sun, 4 Jul 1999 12:40:30 -0400 (EDT) Received: (from myself@localhost) by dmaddox.conterra.com (8.9.3/8.9.1) id MAA00712 for current@FreeBSD.ORG; Sun, 4 Jul 1999 12:40:29 -0400 (EDT) (envelope-from myself) Date: Sun, 4 Jul 1999 12:40:29 -0400 From: "Donald J . Maddox" To: current@FreeBSD.ORG Subject: Interesting new warnings in boot msgs from -current kernel Message-ID: <19990704124029.A669@dmaddox.conterra.com> Reply-To: dmaddox@conterra.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG After last night's new kernel and 'make world', I find I am seeing some interesting new warnings at boot time: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Sun Jul 4 00:13:56 EDT 1999 root@dmaddox.conterra.com:/usr/src/sys/compile/RHIANNON Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 166194077 Hz CPU: Pentium/P54C (166.19-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 Features=0x1bf real memory = 67108864 (65536K bytes) config> pnp 1 0 os enable port0 0x220 irq0 5 drq0 1 drq1 5 port1 0x330 port2 0x388 config> pnp 1 1 os enable port0 0x201 config> pnp 1 2 os enable port0 0x620 port1 0xa20 port2 0xe20 avail memory = 61652992 (60208K bytes) Preloaded elf kernel "kernel" at 0xc02fb000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc02fb09c. Preloaded elf module "vesa.ko" at 0xc02fb0ec. Preloaded elf module "cd9660.ko" at 0xc02fb188. Preloaded elf module "msdos.ko" at 0xc02fb228. Preloaded elf module "procfs.ko" at 0xc02fb2c8. Preloaded elf module "linux.ko" at 0xc02fb368. Intel Pentium detected, installing workaround for F00F bug VESA: v3.0, 16320k memory, flags:0x1, mode table:0xc02c8102 (1000022) VESA: STB Systems, Inc WARNING: "streams" is usurping "streams"'s cdevsw[] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Probing for PnP devices: CSN 1 Vendor ID: CTL009e [0x9e008c0e] Serial 0x09f665ec Comp ID: PNPb02f [0x2fb0d041] npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 chip0: at device 0.0 on pci0 isab0: at device 7.0 on pci0 ide_pci0: at device 7.1 on pci0 ahc0: irq 10 at device 10.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs vga-pci0: irq 11 at device 12.0 on pci0 isa0: on motherboard atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 sc0: on isa0 sc0: VGA <32 virtual consoles, flags=0x200> vga0: at port 0x3b0-0x3df iomem 0xa0000-0xbffff on isa0 wdc0 at port 0x1f0-0x1f7 irq 14 flags 0xb0ffb0ff on isa0 wdc0: unit 0 (wd0): , LBA, DMA, 32-bit, multi-block-32 wd0: 1277MB (2616240 sectors), 648 cyls, 64 heads, 63 S/T, 512 B/S wdc0: unit 1 (wd1): , LBA, DMA, 32-bit, multi-block-16 wd1: 5009MB (10259160 sectors), 638 cyls, 255 heads, 63 S/T, 512 B/S fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> at fdc0 drive 0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2 at port 0x3e8-0x3ef irq 12 flags 0x20020000 on isa0 sio2: type ST16650A sio3 at port 0x2e8-0x2ef irq 9 on isa0 sio3: type 16550A sb0 at port 0x220 irq 5 drq 1 on isa0 snd0: sbxvi0 at port 0xffffffff drq 5 on isa0 isa_compat: didn't get ports for sbxvi snd0: WARNING: "snd" is usurping "snd"'s cdevsw[] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ sbmidi0 at port 0x330 on isa0 snd0: WARNING: "snd" is usurping "snd"'s cdevsw[] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ awe0 at port 0x620 on isa0 awe0: WARNING: "snd" is usurping "snd"'s cdevsw[] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ opl0 at port 0x388 on isa0 snd0: WARNING: "snd" is usurping "snd"'s cdevsw[] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ pca0 at port 0x40 on isa0 pca0: PC speaker audio driver joy0 at port 0x201 on isa0 joy0: joystick ds0 XXX: driver didn't set ifq_maxlen da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15) da0: 507MB (1039329 512 byte sectors: 64H 32S/T 507C) changing root device to wd1s1a cd0 at ahc0 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present ?!?! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 9:45:44 1999 Delivered-To: freebsd-current@freebsd.org Received: from megadodo.segNET.COM (megadodo.segNET.COM [206.34.181.3]) by hub.freebsd.org (Postfix) with ESMTP id F158314C3F for ; Sun, 4 Jul 1999 09:45:40 -0700 (PDT) (envelope-from adams@digitalspark.net) Received: from arc0a179.bf.sover.net (adams@arc0a179.bf.sover.net [209.198.85.179]) by megadodo.segNET.COM (8.9.1a/8.8.5) with ESMTP id MAA21690; Sun, 4 Jul 1999 12:45:37 -0400 (EDT) Date: Sun, 4 Jul 1999 12:47:56 +0000 (GMT) From: Adam Strohl To: "Donald J . Maddox" Cc: current@FreeBSD.ORG Subject: Re: Interesting new warnings in boot msgs from -current kernel In-Reply-To: <19990704124029.A669@dmaddox.conterra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I too get those exact messages with my bktr, and my sound drivers. pcib0: on motherboard pci0: on pcib0 WARNING: "bktr" is usurping "bktr"'s cdevsw[] - cut - snd0: WARNING: "snd" is usurping "snd"'s cdevsw[] sbmidi0 at port 0x330 on isa0 snd0: WARNING: "snd" is usurping "snd"'s cdevsw[] The devices all work fine, though. - ----( Adam Strohl )------------------------------------------------ - - UNIX Operations/Systems http://www.digitalspark.net - - adams (at) digitalspark.net xxx.xxx.xxxx xxxxx - - ----------------------------------------( DigitalSpark.NET )------- - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 9:48:19 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 1D60C14C3F for ; Sun, 4 Jul 1999 09:48:16 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id SAA12554; Sun, 4 Jul 1999 18:47:39 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: dmaddox@conterra.com Cc: current@FreeBSD.ORG Subject: Re: Interesting new warnings in boot msgs from -current kernel In-reply-to: Your message of "Sun, 04 Jul 1999 12:40:29 EDT." <19990704124029.A669@dmaddox.conterra.com> Date: Sun, 04 Jul 1999 18:47:38 +0200 Message-ID: <12552.931106858@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Non fatal, but should be fixed by the respective owners. cdevsw_add() is getting called multiple times. >WARNING: "streams" is usurping "streams"'s cdevsw[] >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >WARNING: "snd" is usurping "snd"'s cdevsw[] >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >WARNING: "snd" is usurping "snd"'s cdevsw[] >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >WARNING: "snd" is usurping "snd"'s cdevsw[] >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >WARNING: "snd" is usurping "snd"'s cdevsw[] >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 10:27:46 1999 Delivered-To: freebsd-current@freebsd.org Received: from mu.egroups.com (mu.egroups.com [207.138.41.151]) by hub.freebsd.org (Postfix) with SMTP id A7AA114BEF for ; Sun, 4 Jul 1999 10:27:45 -0700 (PDT) (envelope-from sams@virtualtek.com) Received: from [10.1.2.15] by mu.egroups.com with NNFMP; 04 Jul 1999 18:27:45 -0000 Date: Sun, 04 Jul 1999 10:27:36 -0700 From: sams@virtualtek.com To: freebsd-current@freebsd.org Subject: freebsd web based groupware Message-ID: <7lo5i8$d0nb@eGroups.com> User-Agent: eGroups-EW/0.73 Content-Length: 352 X-Mailer: www.eGroups.com Message Poster Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, We're looking for sites who may want to integrate customizable web based groupware (email, message board, calendar and address book)onto their sites. Joydesk 2.1 runs on NT, Linux and FreeBSD. When you have an opportunity, please visit http://joydesk.com, open free account and play with the features. Let me know what you think. Cheers, Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 11:29:59 1999 Delivered-To: freebsd-current@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 9108614CA7 for ; Sun, 4 Jul 1999 11:29:55 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id UAA24131 for freebsd-current@freebsd.org; Sun, 4 Jul 1999 20:26:46 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id UAA03332 for freebsd-current@freebsd.org; Sun, 4 Jul 1999 20:06:39 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199907041806.UAA03332@yedi.iaf.nl> Subject: loads of SetAttrs in cvsup of cvs repo To: freebsd-current@freebsd.org (FreeBSD_current mailing list) Date: Sun, 4 Jul 1999 20:06:39 +0200 (CEST) X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Maybe this is a stupid question and/or FAQ but: I'm currently cvsupping updates on the CVS repository. Most of the times that is a couple of minutes, but today it is already 1 hour busy. Mainly with: SetAttr (loads and loads of these). What gives? -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 11:40: 4 1999 Delivered-To: freebsd-current@freebsd.org Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194]) by hub.freebsd.org (Postfix) with ESMTP id 0DA9914C01 for ; Sun, 4 Jul 1999 11:40:02 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.3/8.8.8) with ESMTP id LAA18621; Sun, 4 Jul 1999 11:39:38 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199907041839.LAA18621@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Wilko Bulte Cc: freebsd-current@FreeBSD.ORG (FreeBSD_current mailing list) Subject: Re: loads of SetAttrs in cvsup of cvs repo In-reply-to: Your message of "Sun, 04 Jul 1999 20:06:39 +0200." <199907041806.UAA03332@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 04 Jul 1999 11:39:38 -0700 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Curious why are you cvsupping every couple of minutes ? -- Amancio Hasty ahasty@mindspring.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 11:53:51 1999 Delivered-To: freebsd-current@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id 8900114DF2 for ; Sun, 4 Jul 1999 11:53:49 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: (qmail 56490 invoked from network); 4 Jul 1999 18:53:49 -0000 Received: from shell-1.enteract.com (dscheidt@207.229.143.40) by pop3-3.enteract.com with SMTP; 4 Jul 1999 18:53:49 -0000 Date: Sun, 4 Jul 1999 13:53:49 -0500 (CDT) From: David Scheidt To: Amancio Hasty Cc: Wilko Bulte , FreeBSD_current mailing list Subject: Re: loads of SetAttrs in cvsup of cvs repo In-Reply-To: <199907041839.LAA18621@rah.star-gate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 4 Jul 1999, Amancio Hasty wrote: > > Curious why are you cvsupping every couple of minutes ? I think you have a language problem here. I think he meant it normally takes a couple of minutes, not that he cvsups every couple of minutes. David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 11:54:57 1999 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 991B314EA2 for ; Sun, 4 Jul 1999 11:54:55 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id UAA92111; Sun, 4 Jul 1999 20:54:52 +0200 (CEST) (envelope-from des) To: Richard Tobin Cc: phk@critter.freebsd.dk, freebsd-current@FreeBSD.ORG Subject: Re: IBM-DJNA drives on FreeBSD References: <20376.199907020054@doyle.cogsci.ed.ac.uk> From: Dag-Erling Smorgrav Date: 04 Jul 1999 20:54:52 +0200 In-Reply-To: Richard Tobin's message of "Fri, 2 Jul 1999 01:54:06 +0100" Message-ID: Lines: 13 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Richard Tobin writes: > Is that relevant for 3.2 as well as current? And by "disabling ultra > DMA" did you mean "disabling UDMA66" or "disabling UDMA completely"? > (You can permanently disable UDMA66 with a DOS utility available > from IBM, and it will then act as a plain UDMA33 drive.) Depends on your motherboard. Try to just disable UDMA66 first. If that doesn't help, or if you have a "known bad" chipset (e.g. AcerLabs Aladdin), disable UDMA completely in the BIOS setup utility. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 11:55:55 1999 Delivered-To: freebsd-current@freebsd.org Received: from zippy.dyn.ml.org (pm3-2.ppp.wenet.net [206.15.85.2]) by hub.freebsd.org (Postfix) with ESMTP id 7E7D114DF2 for ; Sun, 4 Jul 1999 11:55:53 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.9.3/8.9.1) with ESMTP id LAA03351; Sun, 4 Jul 1999 11:55:38 -0700 (PDT) (envelope-from garbanzo@hooked.net) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Sun, 4 Jul 1999 11:55:38 -0700 (PDT) From: Alex Zepeda To: Amancio Hasty Cc: Wilko Bulte , FreeBSD_current mailing list Subject: Re: loads of SetAttrs in cvsup of cvs repo In-Reply-To: <199907041839.LAA18621@rah.star-gate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 4 Jul 1999, Amancio Hasty wrote: > Curious why are you cvsupping every couple of minutes ? I think what was meant was that the CVSup process takes a few minutes usually, but has taken over an hour now. - alex I thought felt your touch In my car, on my clutch But I guess it's just someone who felt a lot like I remember you. - Translator To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 11:56:48 1999 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 7537F14EA2 for ; Sun, 4 Jul 1999 11:56:46 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.1) with ESMTP id LAA28408; Sun, 4 Jul 1999 11:56:45 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id LAA08300; Sun, 4 Jul 1999 11:56:45 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Sun, 4 Jul 1999 11:56:45 -0700 (PDT) Message-Id: <199907041856.LAA08300@vashon.polstra.com> To: wilko@yedi.iaf.nl Subject: Re: loads of SetAttrs in cvsup of cvs repo In-Reply-To: <199907041806.UAA03332@yedi.iaf.nl> Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199907041806.UAA03332@yedi.iaf.nl>, Wilko Bulte wrote: > Maybe this is a stupid question and/or FAQ but: You probably should have written to cvsup-bugs@polstra.com instead of the -current list. > I'm currently cvsupping updates on the CVS repository. Most of the > times that is a couple of minutes, but today it is already 1 hour busy. > > Mainly with: > > SetAttr > > (loads and loads of these). > > What gives? Several things can cause this: - You are running cvsup with a different umask than usual. To guard against this, you can add a "umask=022" setting in your supfile (CVSup-16.0 and later). - You are running cvsup under a different user-id than usual. This probably has no effect unless you have "preserve" in your supfile. That's almost always a bad idea except for special situations. - You've accidentally touched all the files in your repository in some way (changed their modtimes, changed their permissions, changed their owners, etc.). John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 11:59:10 1999 Delivered-To: freebsd-current@freebsd.org Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194]) by hub.freebsd.org (Postfix) with ESMTP id 88C2A14FC7 for ; Sun, 4 Jul 1999 11:59:08 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.3/8.8.8) with ESMTP id LAA18822; Sun, 4 Jul 1999 11:58:44 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199907041858.LAA18822@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Alex Zepeda Cc: Wilko Bulte , FreeBSD_current mailing list Subject: Re: loads of SetAttrs in cvsup of cvs repo In-reply-to: Your message of "Sun, 04 Jul 1999 11:55:38 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 04 Jul 1999 11:58:44 -0700 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Arghh... Yeap, upon reading the original message again it reads as you have stated . I need more sleep ... 8) Tnks > On Sun, 4 Jul 1999, Amancio Hasty wrote: > > > Curious why are you cvsupping every couple of minutes ? > > I think what was meant was that the CVSup process takes a few minutes > usually, but has taken over an hour now. > > - alex > > I thought felt your touch > In my car, on my clutch > But I guess it's just someone who felt a lot like I remember you. > - Translator > -- Amancio Hasty ahasty@mindspring.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 12: 1:13 1999 Delivered-To: freebsd-current@freebsd.org Received: from zippy.dyn.ml.org (pm3-2.ppp.wenet.net [206.15.85.2]) by hub.freebsd.org (Postfix) with ESMTP id 179F214EA2 for ; Sun, 4 Jul 1999 12:01:10 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.9.3/8.9.1) with ESMTP id MAA03442; Sun, 4 Jul 1999 12:01:02 -0700 (PDT) (envelope-from garbanzo@hooked.net) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Sun, 4 Jul 1999 12:01:01 -0700 (PDT) From: Alex Zepeda To: Amancio Hasty Cc: Wilko Bulte , FreeBSD_current mailing list Subject: Re: loads of SetAttrs in cvsup of cvs repo In-Reply-To: <199907041858.LAA18822@rah.star-gate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 4 Jul 1999, Amancio Hasty wrote: > > Arghh... Yeap, upon reading the original message again it reads > as you have stated . > > I need more sleep ... 8) Nahh.. caffinated daemon candies OTOH... - alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 12: 3: 5 1999 Delivered-To: freebsd-current@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id F339614EA2 for ; Sun, 4 Jul 1999 12:03:02 -0700 (PDT) (envelope-from hibma@skylink.it) Received: from heidi.plazza.it (va-165.skylink.it [194.185.55.165]) by ns.skylink.it (8.9.3/8.8.8) with ESMTP id VAA00742; Sun, 4 Jul 1999 21:02:42 +0200 Received: from localhost (localhost.plazza.it [127.0.0.1]) by heidi.plazza.it (8.8.8/8.8.5) with SMTP id VAA12131; Sun, 4 Jul 1999 21:02:40 +0200 (CEST) Date: Sun, 4 Jul 1999 21:02:40 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@heidi.plazza.it Reply-To: Nick Hibma To: Wilko Bulte Cc: FreeBSD_current mailing list Subject: Re: loads of SetAttrs in cvsup of cvs repo In-Reply-To: <199907041806.UAA03332@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Maybe, your machine's date is wrong? Did you change cvsup server lately? Did it upgrade it's version of cvsup? I once changed from de to nl and saw similar results. Cheers, Nick On Sun, 4 Jul 1999, Wilko Bulte wrote: > Maybe this is a stupid question and/or FAQ but: > > I'm currently cvsupping updates on the CVS repository. Most of the > times that is a couple of minutes, but today it is already 1 hour busy. > > Mainly with: > > SetAttr > > (loads and loads of these). > > What gives? > > -- > | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - > |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > -- e-Mail: hibma@skylink.it To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 12: 9:30 1999 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 8FA5015046 for ; Sun, 4 Jul 1999 12:09:24 -0700 (PDT) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.9.1/8.9.1) id VAA52179; Sun, 4 Jul 1999 21:09:18 +0200 (CEST) (envelope-from sos) From: Soren Schmidt Message-Id: <199907041909.VAA52179@freebsd.dk> Subject: Re: IBM-DJNA drives on FreeBSD In-Reply-To: from Dag-Erling Smorgrav at "Jul 4, 1999 8:54:52 pm" To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Date: Sun, 4 Jul 1999 21:09:18 +0200 (CEST) Cc: richard@cogsci.ed.ac.uk, phk@critter.freebsd.dk, freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Dag-Erling Smorgrav wrote: > Richard Tobin writes: > > Is that relevant for 3.2 as well as current? And by "disabling ultra > > DMA" did you mean "disabling UDMA66" or "disabling UDMA completely"? > > (You can permanently disable UDMA66 with a DOS utility available > > from IBM, and it will then act as a plain UDMA33 drive.) > > Depends on your motherboard. Try to just disable UDMA66 first. If that > doesn't help, or if you have a "known bad" chipset (e.g. AcerLabs > Aladdin), disable UDMA completely in the BIOS setup utility. BZZST! The Aladdin isn't bad, the support in the old wd based driver is :) I use a DJNA drive on an Aladdin board, with the ATA driver, and it works just dandy no matter how I set the BIOS (and I always get UDMA33 btw, the Alladin wont do any higher than that)... -SØren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 12:22:37 1999 Delivered-To: freebsd-current@freebsd.org Received: from ozz.etrust.ru (ozz.etrust.ru [195.2.84.116]) by hub.freebsd.org (Postfix) with ESMTP id BDDE914EA2 for ; Sun, 4 Jul 1999 12:22:32 -0700 (PDT) (envelope-from osa@etrust.ru) Received: from localhost (localhost [127.0.0.1]) by ozz.etrust.ru (Postfix) with ESMTP id 90362C7; Sun, 4 Jul 1999 23:22:29 +0400 (MSD) Date: Sun, 4 Jul 1999 23:22:29 +0400 (MSD) From: Osokin Sergey To: current@FreeBSD.org Cc: imp@village.org Subject: patch 4 UPDATING... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=KOI8-R Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello. Little patch for UPDATING: --- UPDATING.orig Sun Jul 4 23:21:21 1999 +++ UPDATING Sun Jul 4 23:21:34 1999 @@ -5,7 +5,7 @@ 19990704: src/contrib/sys/softupdates is moving to - src/sy/contrib/softupdates. Update your symbolic links/etc. + src/sys/contrib/softupdates. Update your symbolic links/etc. 19990702: Major changes have been made to vinum and its interface. See Rgdz, ïÓÏËÉÎ óÅÒÇÅÊ aka oZZ, osa@etrust.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 12:25:45 1999 Delivered-To: freebsd-current@freebsd.org Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194]) by hub.freebsd.org (Postfix) with ESMTP id 37DC014EA2 for ; Sun, 4 Jul 1999 12:25:44 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.3/8.8.8) with ESMTP id MAA18980 for ; Sun, 4 Jul 1999 12:25:22 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199907041925.MAA18980@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-current@FreeBSD.ORG Subject: LDAPed FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 04 Jul 1999 12:25:22 -0700 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am playing around with configuring the system and providing a CLI , programmatic interface and a html interface . Floating in my mind is to present a uniform configuration repository similar to windows registery however the information repository is implemented with LDAP. See http://www.openldap.org for info on LDAP. The tough part is creating the LDAP schemas for the various daemons or services. Got lucky and found an IETF draft : An LDAP Schema for Dynamic Host Configuration Protocol Service http://www.ietf.org/internet-drafts/draft-gu-dhcp-ldap-schema-00.txt I am using the above draft to explore configuring dhcpd. My first cut at configuring dhcpd via LDAP is to extract all the configuration information from the LDAP server and writing the information to dhcpd's configuration file and then have dhcpd parse the configuration file. This approach minimizes the changes to dhcpd and provides persistent configuration information for dhcpd. The start of my html interface is at: http://www.star-gate.com/dhcpd.html Thats just a dummy front end . The real interface is being implemented as a servlet and will provide a more rich presentation --- help files , How To, etc... The CLI interface can be as easy as using the existing ldap shell tools. The programmatic interface is simply the LDAP C and Java interface available from : http://www.mozilla.org/directory So far I have a simple ldap schema based upon the IETF draft which I can manage from my servlet and query from dhcpd. What do you guys think? -- Amancio Hasty ahasty@mindspring.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 12:34:22 1999 Delivered-To: freebsd-current@freebsd.org Received: from mpp.pro-ns.net (mpp.pro-ns.net [208.200.182.72]) by hub.freebsd.org (Postfix) with ESMTP id E0F331510B for ; Sun, 4 Jul 1999 12:34:04 -0700 (PDT) (envelope-from mpp@mpp.pro-ns.net) Received: (from mpp@localhost) by mpp.pro-ns.net (8.9.3/8.9.3) id OAA36387; Sun, 4 Jul 1999 14:33:10 -0500 (CDT) (envelope-from mpp) From: Mike Pritchard Message-Id: <199907041933.OAA36387@mpp.pro-ns.net> Subject: Re: loads of SetAttrs in cvsup of cvs repo In-Reply-To: <199907041856.LAA08300@vashon.polstra.com> from John Polstra at "Jul 4, 1999 11:56:45 am" To: jdp@polstra.com (John Polstra) Date: Sun, 4 Jul 1999 14:33:10 -0500 (CDT) Cc: wilko@yedi.iaf.nl, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In article <199907041806.UAA03332@yedi.iaf.nl>, > > - You are running cvsup with a different umask than usual. To guard > against this, you can add a "umask=022" setting in your supfile > (CVSup-16.0 and later). Speaking of CVSup-16.0, I can't get the port in /usr/ports/net/cvsup to link. I get the following error message: -> linking cvspasswd /usr/lib/crt0.o: file not recognize: File format not recognized Fatal Error: program "ld" failed, exit status = 256 It does this for the link of cvsup, cvsupd and cvpasswd. I'm running about a 2 week old -current system. I'm supping a new -current right now and will try doing a new "make world" to see if this helps, but this is the only port I've had any trouble getting to build. -- Mike Pritchard mpp@FreeBSD.ORG or mpp@mpp.pro-ns.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 12:37:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 4376615117 for ; Sun, 4 Jul 1999 12:37:24 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.1) with ESMTP id MAA28646; Sun, 4 Jul 1999 12:37:23 -0700 (PDT) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id MAA08411; Sun, 4 Jul 1999 12:37:23 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199907041933.OAA36387@mpp.pro-ns.net> Date: Sun, 04 Jul 1999 12:37:23 -0700 (PDT) Organization: Polstra & Co., Inc. From: John Polstra To: Mike Pritchard Subject: Re: loads of SetAttrs in cvsup of cvs repo Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Pritchard wrote: >> In article <199907041806.UAA03332@yedi.iaf.nl>, >> >> - You are running cvsup with a different umask than usual. To guard >> against this, you can add a "umask=022" setting in your supfile >> (CVSup-16.0 and later). > > Speaking of CVSup-16.0, I can't get the port in /usr/ports/net/cvsup to > link. I get the following error message: > > -> linking cvspasswd > /usr/lib/crt0.o: file not recognize: File format not recognized It looks like you have an old (a.out) Modula-3 installation. Pkg_delete modula-3 and modula-3-lib and then try again. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 12:38:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from freja.webgiro.com (freja.webgiro.com [212.209.29.10]) by hub.freebsd.org (Postfix) with ESMTP id 1EE4C15117 for ; Sun, 4 Jul 1999 12:38:26 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by freja.webgiro.com (Postfix, from userid 1001) id C918618FB; Sun, 4 Jul 1999 21:38:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by freja.webgiro.com (Postfix) with ESMTP id BE0E049DD; Sun, 4 Jul 1999 21:38:44 +0200 (CEST) Date: Sun, 4 Jul 1999 21:38:44 +0200 (CEST) From: Andrzej Bialecki To: Peter Wemm Cc: freebsd-current@freebsd.org Subject: Panic in vm_page_free_toq (Re: Panic in vm_page_zero_idle) In-Reply-To: <19990629171306.122DB82@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1006722631-931117124=:67827" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1006722631-931117124=:67827 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 30 Jun 1999, Peter Wemm wrote: > Andrzej Bialecki wrote: > > Hi, > > > > Sources are from yesterday, machine is Toshiba Portege 7020CT. During make > > -j24 buildworld machine dies with the following panic mesage (notice > > absence of register dump): > > > > kernel: type 12 trap, code=0 > > Stopped at vm_page_zero_idle+0xc9: movl %eax,0x4(%edx) > > > > db> tr > > vm_page_zero_idle(e,66a,2,183f9ff,756e6547) at vm_page_zero_idle+0xc9 > > idle_loop() at idle_loop+0x2d > > That's because there is no process context at this point, and nowhere the > registers are saved for the idle ``context''. > > Trap 12 is a page fault. Do a 'show registers' to see what's up. I > would like to know what %edx is. > > It's trapping here: > m = vm_page_list_find(PQ_FREE, free_rover, FALSE); > if (m != NULL && (m->flags & PG_ZERO) == 0) { > --(*vm_page_queues[m->queue].lcnt); > TAILQ_REMOVE(vm_page_queues[m->queue].pl, m, pageq); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > m->queue = PQ_NONE; > splx(s); > > Specifically, vm_page_queues[m->queue].pl is invalid or the tailq corrupt > or something evil along those lines. Or, m->queue is bogus and causing > an out of bounds array lookup. Hmm, do a show registers and record %eax > at this point too. I could only use gdb, and I didn't have kernel.debug. I went some frames up to reach the vm_page_zero_idle, and did "info registers". Both %eax and %edx were 0x0. But this time I was (a little bit) wiser. Here's another panic - this time I got the core file and a kernel with symbols, and I did what I could with gdb, but finally ran out of ideas... ;-) Additionally, the core file is on a laptop, and I have only modem connection at the moment, but I will be able to put it om freefall (or wherever) at the end of next week. Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- --0-1006722631-931117124=:67827 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; name="crash.scr" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="crash.scr" U2NyaXB0IHN0YXJ0ZWQgb24gU3VuIEp1bCAgNCAyMDo1NDozNiAxOTk5DQoj IGdkYiAtayAvc3lzL2NvbXBpbGUvVFVORS9rZXJuZWwuZGVidWcgdm1jb3Jl LjINDQpHTlUgZ2RiIDQuMTgNDQpDb3B5cmlnaHQgMTk5OCBGcmVlIFNvZnR3 YXJlIEZvdW5kYXRpb24sIEluYy4NDQpHREIgaXMgZnJlZSBzb2Z0d2FyZSwg Y292ZXJlZCBieSB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UsIGFu ZCB5b3UgYXJlDQ0Kd2VsY29tZSB0byBjaGFuZ2UgaXQgYW5kL29yIGRpc3Ry aWJ1dGUgY29waWVzIG9mIGl0IHVuZGVyIGNlcnRhaW4gY29uZGl0aW9ucy4N DQpUeXBlICJzaG93IGNvcHlpbmciIHRvIHNlZSB0aGUgY29uZGl0aW9ucy4N DQpUaGVyZSBpcyBhYnNvbHV0ZWx5IG5vIHdhcnJhbnR5IGZvciBHREIuICBU eXBlICJzaG93IHdhcnJhbnR5IiBmb3IgZGV0YWlscy4NDQpUaGlzIEdEQiB3 YXMgY29uZmlndXJlZCBhcyAiaTM4Ni11bmtub3duLWZyZWVic2QiLi4uDQ0K SWRsZVBURCAyODIyMTQ0DQ0KaW5pdGlhbCBwY2IgYXQgMjQwNjgwDQ0KcGFu aWNzdHI6IHZtX3BhZ2VfZnJlZTogZnJlZWluZyBmcmVlIHBhZ2UNDQpwYW5p YyBtZXNzYWdlczoNDQotLS0NDQpwYW5pYzogdm1fcGFnZV9mcmVlOiBmcmVl aW5nIGZyZWUgcGFnZQ0NCg0NCnN5bmNpbmcgZGlza3MuLi4gZG9uZQ0NCg0N CmR1bXBpbmcgdG8gZGV2ICgwLDE5NjYwOSksIG9mZnNldCAxMzEzMjgNDQpk dW1wIDEyNyAxMjYgMTI1IDEyNCAxMjMgMTIyIDEyMSAxMjAgMTE5IDExOCAx MTcgMTE2IDExNSAxMTQgMTEzIDExMiAxMTEgMTEwIDEwOSAxMDggMTA3IDEw NiAxMDUgMTA0IDEwMyAxMDIgMTAxIDEwMCA5OSA5OCA5NyA5NiA5NSA5NCA5 MyA5MiA5MSA5MCA4OSA4OCA4NyA4NiA4NSA4NCA4MyA4MiA4MSA4MCA3OSA3 OCA3NyA3NiA3NSA3NCA3MyA3MiA3MSA3MCA2OSA2OCA2NyA2NiA2NSA2NCA2 MyA2MiA2MSA2MCA1OSA1OCA1NyA1NiA1NSA1NCA1MyA1MiA1MSA1MCA0OSA0 OCA0NyA0NiA0NSA0NCA0MyA0MiA0MSA0MCAzOSAzOCAzNyAzNiAzNSAzNCAz MyAzMiAzMSAzMCAyOSAyOCAyNyAyNiAyNSAyNCAyMyAyMiAyMSAyMCAxOSAx OCAxNyAxNiAxNSAxNCAxMyAxMiAxMSAxMCA5IDggNyA2IDUgNCAzIDIgMSAw IA0NCi0tLQ0NCiMwICBib290IChob3d0bz0yNTYpIGF0IC4uLy4uL2tlcm4v a2Vybl9zaHV0ZG93bi5jOjI4OQ0NCjI4OQkJCWR1bXBwY2IucGNiX2NyMyA9 IHJjcjMoKTsNDQooa2dkYikgd2hlcmUNDQojMCAgYm9vdCAoaG93dG89MjU2 KSBhdCAuLi8uLi9rZXJuL2tlcm5fc2h1dGRvd24uYzoyODkNDQojMSAgMHhj MDEzNTg1MSBpbiBwYW5pYyAoZm10PTB4YzAyMGVjZTAgInZtX3BhZ2VfZnJl ZTogZnJlZWluZyBmcmVlIHBhZ2UiKQ0NCiAgICBhdCAuLi8uLi9rZXJuL2tl cm5fc2h1dGRvd24uYzo0NTINDQojMiAgMHhjMDFhN2YzZCBpbiB2bV9wYWdl X2ZyZWVfdG9xIChtPTB4YzA0NWYzZTApIGF0IC4uLy4uL3ZtL3ZtX3BhZ2Uu YzoxMDk1DQ0KIzMgIDB4YzAxYTVlMzkgaW4gdm1fb2JqZWN0X3Rlcm1pbmF0 ZSAob2JqZWN0PTB4YzZiNDBiZDApDQ0KICAgIGF0IC4uLy4uL3ZtL3ZtX3Bh Z2UuaDo1MDANDQojNCAgMHhjMDFhNWQ1NSBpbiB2bV9vYmplY3RfZGVhbGxv Y2F0ZSAob2JqZWN0PTB4YzZiNDBiZDApDQ0KICAgIGF0IC4uLy4uL3ZtL3Zt X29iamVjdC5jOjM4Mg0NCiM1ICAweGMwMWEzMjYzIGluIHZtX21hcF9lbnRy eV9kZWxldGUgKG1hcD0weGM2ODgwNzQwLCBlbnRyeT0weGM2Y2I2Zjc4KQ0N CiAgICBhdCAuLi8uLi92bS92bV9tYXAuYzoxNjgwDQ0KIzYgIDB4YzAxYTM0 MjEgaW4gdm1fbWFwX2RlbGV0ZSAobWFwPTB4YzY4ODA3NDAsIHN0YXJ0PTAs IGVuZD0zMjE3MDIyOTc2KQ0NCiAgICBhdCAuLi8uLi92bS92bV9tYXAuYzox NzgzDQ0KIzcgIDB4YzAxYTM0YTUgaW4gdm1fbWFwX3JlbW92ZSAobWFwPTB4 YzY4ODA3NDAsIHN0YXJ0PTAsIGVuZD0zMjE3MDIyOTc2KQ0NCiAgICBhdCAu Li8uLi92bS92bV9tYXAuYzoxODA4DQ0KIzggIDB4YzAxMmYzMTAgaW4gZXhp dDEgKHA9MHhjNmQxYWQ2MCwgcnY9MTEpIGF0IC4uLy4uL2tlcm4va2Vybl9l eGl0LmM6MjIwDQ0KIzkgIDB4YzAxMzZiZmUgaW4gc2lnZXhpdCAocD0weGM2 ZDFhZDYwLCBzaWdudW09MTEpDQ0KICAgIGF0IC4uLy4uL2tlcm4va2Vybl9z aWcuYzoxMjUxDQ0KIzEwIDB4YzAxMzZhNDEgaW4gcG9zdHNpZyAoc2lnbnVt PTExKSBhdCAuLi8uLi9rZXJuL2tlcm5fc2lnLmM6MTE1Nw0NCiMxMSAweGMw MWQwYjdlIGluIHRyYXAgKGZyYW1lPXt0Zl9mcyA9IDQ3LCB0Zl9lcyA9IC0x MDYzMTkwNDgxLCANDQogICAgICB0Zl9kcyA9IC0xMDc4MDAxNjE3LCB0Zl9l ZGkgPSAwLCB0Zl9lc2kgPSA2NzE1MzMxMjEsIA0NCiAgICAgIHRmX2VicCA9 IC0xMDc3OTQ1NTEyLCB0Zl9pc3AgPSAtOTU4ODA4MTA4LCB0Zl9lYnggPSA2 NzE1MzEzMTIsIA0NCiAgICAgIHRmX2VkeCA9IDI3LCB0Zl9lY3ggPSAxMzQ1 Mjk4ODgsIHRmX2VheCA9IDEzNDI5MTgwOCwgdGZfdHJhcG5vID0gMTIsIA0N CiAgICAgIHRmX2VyciA9IDEzNDI5MTgwOCwgdGZfZWlwID0gMTM0NTI5OTI2 LCB0Zl9jcyA9IDMxLCB0Zl9lZmxhZ3MgPSA2NjA3MCwgDQ0KICAgICAgdGZf ZXNwID0gLTEwNzc5NDU1MTIsIHRmX3NzID0gNDd9KSBhdCAuLi8uLi9pMzg2 L2kzODYvdHJhcC5jOjE2Mg0NCi0tLVR5cGUgPHJldHVybj4gdG8gY29udGlu dWUsIG9yIHEgPHJldHVybj4gdG8gcXVpdC0tLQ0NCiMxMiAweDgwNGMzODYg aW4gPz8gKCkNDQpDYW5ub3QgYWNjZXNzIG1lbW9yeSBhdCBhZGRyZXNzIDB4 YmZiZmRiNTguDQ0KKGtnZGIpIHVwDQ0KIzEgIDB4YzAxMzU4NTEgaW4gcGFu aWMgKGZtdD0weGMwMjBlY2UwICJ2bV9wYWdlX2ZyZWU6IGZyZWVpbmcgZnJl ZSBwYWdlIikNDQogICAgYXQgLi4vLi4va2Vybi9rZXJuX3NodXRkb3duLmM6 NDUyDQ0KNDUyCQlib290KGJvb3RvcHQpOw0NCihrZ2RiKSB1cA0NCiMyICAw eGMwMWE3ZjNkIGluIHZtX3BhZ2VfZnJlZV90b3EgKG09MHhjMDQ1ZjNlMCkg YXQgLi4vLi4vdm0vdm1fcGFnZS5jOjEwOTUNDQoxMDk1CQkJCXBhbmljKCJ2 bV9wYWdlX2ZyZWU6IGZyZWVpbmcgZnJlZSBwYWdlIik7DQ0KKGtnZGIpIGxp c3QNDQoxMDkwCQkJcHJpbnRmKA0NCjEwOTEJCQkidm1fcGFnZV9mcmVlOiBw aW5kZXgoJWx1KSwgYnVzeSglZCksIFBHX0JVU1koJWQpLCBob2xkKCVkKVxu IiwNDQoxMDkyCQkJICAgICh1X2xvbmcpbS0+cGluZGV4LCBtLT5idXN5LCAo bS0+ZmxhZ3MgJiBQR19CVVNZKSA/IDEgOiAwLA0NCjEwOTMJCQkgICAgbS0+ aG9sZF9jb3VudCk7DQ0KMTA5NAkJCWlmICgobS0+cXVldWUgLSBtLT5wYykg PT0gUFFfRlJFRSkNDQoxMDk1CQkJCXBhbmljKCJ2bV9wYWdlX2ZyZWU6IGZy ZWVpbmcgZnJlZSBwYWdlIik7DQ0KMTA5NgkJCWVsc2UNDQoxMDk3CQkJCXBh bmljKCJ2bV9wYWdlX2ZyZWU6IGZyZWVpbmcgYnVzeSBwYWdlIik7DQ0KMTA5 OAkJfQ0NCjEwOTkJI2VuZGlmDQ0KKGtnZGIpIHByaW50ICptDQ0KJDEgPSB7 cGFnZXEgPSB7dHFlX25leHQgPSAweGMwNGNhN2UwLCB0cWVfcHJldiA9IDB4 YzAyMzBlOTh9LCBobmV4dCA9IDB4MCwgDQ0KICBsaXN0cSA9IHt0cWVfbmV4 dCA9IDB4YzA1N2E1ODAsIHRxZV9wcmV2ID0gMHhjNmIwMGJlOH0sIG9iamVj dCA9IDB4MCwgDQ0KICBwaW5kZXggPSAzMSwgcGh5c19hZGRyID0gODgyNjg4 MCwgcXVldWUgPSA0NCwgZmxhZ3MgPSAxMjksIHBjID0gNDMsIA0NCiAgd2ly ZV9jb3VudCA9IDAsIGhvbGRfY291bnQgPSAwLCBhY3RfY291bnQgPSA1ICdc MDA1JywgYnVzeSA9IDAgJ1wwMDAnLCANDQogIHZhbGlkID0gMCAnXDAwMCcs IGRpcnR5ID0gMjU1ICf/J30NDQooa2dkYikgcHJpbnQgKihtLT5wYWdlcS50 cWVfbmV4dCkNDQokMiA9IHtwYWdlcSA9IHt0cWVfbmV4dCA9IDB4YzA1M2Ez ZTAsIHRxZV9wcmV2ID0gMHhjMDQ1ZjNlMH0sIGhuZXh0ID0gMHgwLCANDQog IGxpc3RxID0ge3RxZV9uZXh0ID0gMHhjMDU3MWI4MCwgdHFlX3ByZXYgPSAw eGM2OTBjMmEwfSwgb2JqZWN0ID0gMHgwLCANDQogIHBpbmRleCA9IDUsIHBo eXNfYWRkciA9IDQ2MzEzNDcyLCBxdWV1ZSA9IDQ0LCBmbGFncyA9IDEyOCwg cGMgPSA0MywgDQ0KICB3aXJlX2NvdW50ID0gMCwgaG9sZF9jb3VudCA9IDAs IGFjdF9jb3VudCA9IDUgJ1wwMDUnLCBidXN5ID0gMCAnXDAwMCcsIA0NCiAg dmFsaWQgPSAwICdcMDAwJywgZGlydHkgPSAyNTUgJ/8nfQ0NCihrZ2RiKSBw cmludCAqKihtLT5wYWdlcS50cWVfcHJldikNDQokNCA9IHtwYWdlcSA9IHt0 cWVfbmV4dCA9IDB4YzA0Y2E3ZTAsIHRxZV9wcmV2ID0gMHhjMDIzMGU5OH0s IGhuZXh0ID0gMHgwLCANDQogIGxpc3RxID0ge3RxZV9uZXh0ID0gMHhjMDU3 YTU4MCwgdHFlX3ByZXYgPSAweGM2YjAwYmU4fSwgb2JqZWN0ID0gMHgwLCAN DQogIHBpbmRleCA9IDMxLCBwaHlzX2FkZHIgPSA4ODI2ODgwLCBxdWV1ZSA9 IDQ0LCBmbGFncyA9IDEyOSwgcGMgPSA0MywgDQ0KICB3aXJlX2NvdW50ID0g MCwgaG9sZF9jb3VudCA9IDAsIGFjdF9jb3VudCA9IDUgJ1wwMDUnLCBidXN5 ID0gMCAnXDAwMCcsIA0NCiAgdmFsaWQgPSAwICdcMDAwJywgZGlydHkgPSAy NTUgJ/8nfQ0NCihrZ2RiKSBwcmludCAqKChtLT5wYWdlcS50cWVfbmV4dCkt PnBhZ2VxLnRxZV9uZXh0KQ0NCiQ1ID0ge3BhZ2VxID0ge3RxZV9uZXh0ID0g MHhjMDRhYWZlMCwgdHFlX3ByZXYgPSAweGMwNGNhN2UwfSwgaG5leHQgPSAw eDAsIA0NCiAgbGlzdHEgPSB7dHFlX25leHQgPSAweDAsIHRxZV9wcmV2ID0g MHhjNjk2ODE1Y30sIG9iamVjdCA9IDB4MCwgcGluZGV4ID0gOSwgDQ0KICBw aHlzX2FkZHIgPSA4NTM3MjkyOCwgcXVldWUgPSA0NCwgZmxhZ3MgPSAxMjgs IHBjID0gNDMsIHdpcmVfY291bnQgPSAwLCANDQogIGhvbGRfY291bnQgPSAw LCBhY3RfY291bnQgPSA1ICdcMDA1JywgYnVzeSA9IDAgJ1wwMDAnLCB2YWxp ZCA9IDAgJ1wwMDAnLCANDQogIGRpcnR5ID0gMjU1ICf/J30NDQooa2dkYikg dXANDQojMyAgMHhjMDFhNWUzOSBpbiB2bV9vYmplY3RfdGVybWluYXRlIChv YmplY3Q9MHhjNmI0MGJkMCkNDQogICAgYXQgLi4vLi4vdm0vdm1fcGFnZS5o OjUwMA0NCjUwMAkJdm1fcGFnZV9mcmVlX3RvcShtKTsNDQooa2dkYikgcHJp bnQgKm9iamVjdA0NCiQ2ID0ge29iamVjdF9saXN0ID0ge3RxZV9uZXh0ID0g MHhjNmUwYzgwNCwgdHFlX3ByZXYgPSAweGM2YWExYjY0fSwgDQ0KICBzaGFk b3dfaGVhZCA9IHt0cWhfZmlyc3QgPSAweDAsIHRxaF9sYXN0ID0gMHhjNmI0 MGJkOH0sIHNoYWRvd19saXN0ID0gew0NCiAgICB0cWVfbmV4dCA9IDB4MCwg dHFlX3ByZXYgPSAweGM2YjdjMWI4fSwgbWVtcSA9IHt0cWhfZmlyc3QgPSAw eGMwNDVmM2UwLCANDQogICAgdHFoX2xhc3QgPSAweGMwNTZmMGZjfSwgZ2Vu ZXJhdGlvbiA9IDgwMCwgdHlwZSA9IE9CSlRfREVGQVVMVCwgc2l6ZSA9IDMy LCANDQogIHJlZl9jb3VudCA9IDAsIHNoYWRvd19jb3VudCA9IDAsIHBnX2Nv bG9yID0gMTIsIGhhc2hfcmFuZCA9IC0yMDYzNDQxNDMsIA0NCiAgZmxhZ3Mg PSA4NTg0LCBwYWdpbmdfaW5fcHJvZ3Jlc3MgPSAwLCBiZWhhdmlvciA9IDAs IHJlc2lkZW50X3BhZ2VfY291bnQgPSAyLCANDQogIGJhY2tpbmdfb2JqZWN0 ID0gMHgwLCBiYWNraW5nX29iamVjdF9vZmZzZXQgPSAwLCBsYXN0X3JlYWQg PSAwLCANDQogIHBhZ2VyX29iamVjdF9saXN0ID0ge3RxZV9uZXh0ID0gMHgw LCB0cWVfcHJldiA9IDB4MH0sIGhhbmRsZSA9IDB4MCwgDQ0KICB1bl9wYWdl ciA9IHt2bnAgPSB7dm5wX3NpemUgPSAwfSwgZGV2cCA9IHtkZXZwX3BnbGlz dCA9IHt0cWhfZmlyc3QgPSAweDAsIA0NCiAgICAgICAgdHFoX2xhc3QgPSAw eDB9fSwgc3dwID0ge3N3cF9iY291bnQgPSAwfX19DQ0KKGtnZGIpIHF1aXQN DQojIGV4aXQNDQoNClNjcmlwdCBkb25lIG9uIFN1biBKdWwgIDQgMjE6MTg6 MzIgMTk5OQ0K --0-1006722631-931117124=:67827 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=TUNE Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=TUNE Iw0KIyBHRU5FUklDIC0tIEdlbmVyaWMgbWFjaGluZSB3aXRoIFdEL0FIeC9O Q1IvQlR4IGZhbWlseSBkaXNrcw0KIw0KIyBGb3IgbW9yZSBpbmZvcm1hdGlv biByZWFkIHRoZSBoYW5kYm9vayBwYXJ0IFN5c3RlbSBBZG1pbmlzdHJhdGlv biAtPiANCiMgQ29uZmlndXJpbmcgdGhlIEZyZWVCU0QgS2VybmVsIC0+IFRo ZSBDb25maWd1cmF0aW9uIEZpbGUuIA0KIyBUaGUgaGFuZGJvb2sgaXMgYXZh aWxhYmxlIGluIC91c3Ivc2hhcmUvZG9jL2hhbmRib29rIG9yIG9ubGluZSBh cw0KIyBsYXRlc3QgdmVyc2lvbiBmcm9tIHRoZSBGcmVlQlNEIFdvcmxkIFdp ZGUgV2ViIHNlcnZlciANCiMgPFVSTDpodHRwOi8vd3d3LkZyZWVCU0QuT1JH Lz4NCiMNCiMgQW4gZXhoYXVzdGl2ZSBsaXN0IG9mIG9wdGlvbnMgYW5kIG1v cmUgZGV0YWlsZWQgZXhwbGFuYXRpb25zIG9mIHRoZSANCiMgZGV2aWNlIGxp bmVzIGlzIHByZXNlbnQgaW4gdGhlIC4vTElOVCBjb25maWd1cmF0aW9uIGZp bGUuIElmIHlvdSBhcmUgDQojIGluIGRvdWJ0IGFzIHRvIHRoZSBwdXJwb3Nl IG9yIG5lY2Vzc2l0eSBvZiBhIGxpbmUsIGNoZWNrIGZpcnN0IGluIExJTlQu DQojDQojCSRJZDogR0VORVJJQyx2IDEuMTQzLjIuMTEgMTk5OS8wNS8wNCAw MDoxNTo1NSBtc21pdGggRXhwICQNCg0KbWFjaGluZQkJImkzODYiDQpjcHUJ CSJJNjg2X0NQVSINCmlkZW50CQlUVU5FDQptYXh1c2VycwkzMg0KDQpvcHRp b25zCQlJTkVUCQkJI0ludGVyTkVUd29ya2luZw0Kb3B0aW9ucwkJRkZTCQkJ I0JlcmtlbGV5IEZhc3QgRmlsZXN5c3RlbQ0Kb3B0aW9ucwkJRkZTX1JPT1QJ CSNGRlMgdXNhYmxlIGFzIHJvb3QgZGV2aWNlIFtrZWVwIHRoaXMhXQ0Kb3B0 aW9ucwkJTVNET1NGUwkJCSNNU0RPUyBGaWxlc3lzdGVtDQpvcHRpb25zCQki Q0Q5NjYwIgkJI0lTTyA5NjYwIEZpbGVzeXN0ZW0NCm9wdGlvbnMJCSJDRDk2 NjBfUk9PVCIJCSNDRC1ST00gdXNhYmxlIGFzIHJvb3QuICJDRDk2NjAiIHJl cSdlZA0Kb3B0aW9ucwkJUFJPQ0ZTCQkJI1Byb2Nlc3MgZmlsZXN5c3RlbQ0K b3B0aW9ucwkJIkNPTVBBVF80MyIJCSNDb21wYXRpYmxlIHdpdGggQlNEIDQu MyBbS0VFUCBUSElTIV0NCm9wdGlvbnMJCVVDT05TT0xFCQkjQWxsb3cgdXNl cnMgdG8gZ3JhYiB0aGUgY29uc29sZQ0Kb3B0aW9ucwkJVVNFUkNPTkZJRwkJ I2Jvb3QgLWMgZWRpdG9yDQpvcHRpb25zCQlWSVNVQUxfVVNFUkNPTkZJRwkj dmlzdWFsIGJvb3QgLWMgZWRpdG9yDQpvcHRpb25zCQlEREINCg0KI2NvbmZp ZwkJa2VybmVsCXJvb3Qgb24gd2QwDQoNCiMgVG8gbWFrZSBhbiBTTVAga2Vy bmVsLCB0aGUgbmV4dCB0d28gYXJlIG5lZWRlZA0KI29wdGlvbnMJU01QCQkJ IyBTeW1tZXRyaWMgTXVsdGlQcm9jZXNzb3IgS2VybmVsDQojb3B0aW9ucwlB UElDX0lPCQkJIyBTeW1tZXRyaWMgKEFQSUMpIEkvTw0KIyBPcHRpb25hbGx5 IHRoZXNlIG1heSBuZWVkIHR3ZWFrZWQsIChkZWZhdWx0cyBzaG93bik6DQoj b3B0aW9ucwlOQ1BVPTIJCQkjIG51bWJlciBvZiBDUFVzDQojb3B0aW9ucwlO QlVTPTQJCQkjIG51bWJlciBvZiBidXNzZXMNCiNvcHRpb25zCU5BUElDPTEJ CQkjIG51bWJlciBvZiBJTyBBUElDcw0KI29wdGlvbnMJTklOVFI9MjQJCSMg bnVtYmVyIG9mIElOVHMNCg0KY29udHJvbGxlcglpc2EwDQpjb250cm9sbGVy CXBjaTANCmNvbnRyb2xsZXIJcG5wMA0KDQpkZXZpY2UgcGNtMCBhdCBpc2E/ IHBvcnQgMHgyMjAgaXJxIDUgZHJxIDEgZmxhZ3MgMHgwDQoNCmNvbnRyb2xs ZXIJZmRjMAlhdCBpc2E/IHBvcnQgIklPX0ZEMSIgaXJxIDYgZHJxIDINCmRp c2sJCWZkMAlhdCBmZGMwIGRyaXZlIDANCg0KI2NvbnRyb2xsZXIJd2RjMAlh dCBpc2E/IHBvcnQgIklPX1dEMSIgaXJxIDE0DQojZGlzawkJd2QwCWF0IHdk YzAgZHJpdmUgMA0KI2Rpc2sJCXdkMQlhdCB3ZGMwIGRyaXZlIDENCg0KI2Nv bnRyb2xsZXIJd2RjMQlhdCBpc2E/IHBvcnQgIklPX1dEMiIgaXJxIDE1DQoj ZGlzawkJd2QyCWF0IHdkYzEgZHJpdmUgMA0KI2Rpc2sJCXdkMwlhdCB3ZGMx IGRyaXZlIDENCg0KI2RldmljZQkJd2NkMAkJI0lERSBDRC1ST00NCg0KY29u dHJvbGxlcglhdGEwDQpkZXZpY2UJCWF0YWRpc2swDQpkZXZpY2UJCWF0YXBp Y2QwDQoNCiMgYXRrYmRjMCBjb250cm9sbHMgYm90aCB0aGUga2V5Ym9hcmQg YW5kIHRoZSBQUy8yIG1vdXNlDQpjb250cm9sbGVyCWF0a2JkYzAJYXQgaXNh PyBwb3J0IElPX0tCRA0KZGV2aWNlCQlhdGtiZDAJYXQgYXRrYmRjPyBpcnEg MQ0KZGV2aWNlCQlwc20wCWF0IGF0a2JkYz8gaXJxIDEyDQoNCmRldmljZQkJ dmdhMAlhdCBpc2E/IHBvcnQgPyBjb25mbGljdHMNCg0KIyBzcGxhc2ggc2Ny ZWVuL3NjcmVlbiBzYXZlcg0KcHNldWRvLWRldmljZQlzcGxhc2gNCg0KIyBz eXNjb25zIGlzIHRoZSBkZWZhdWx0IGNvbnNvbGUgZHJpdmVyLCByZXNlbWJs aW5nIGFuIFNDTyBjb25zb2xlDQpkZXZpY2UJCXNjMAlhdCBpc2E/IA0KDQpk ZXZpY2UJCW5weDAJYXQgaXNhPyBwb3J0IElPX05QWCBpcnEgMTMNCg0KIw0K IyBMYXB0b3Agc3VwcG9ydCAoc2VlIExJTlQgZm9yIG1vcmUgb3B0aW9ucykN CiMNCmRldmljZQkJYXBtMCAgICBhdCBpc2E/CWZsYWdzIDB4MzEgIyBBZHZh bmNlZCBQb3dlciBNYW5hZ2VtZW50DQoNCiMgUENDQVJEIChQQ01DSUEpIHN1 cHBvcnQNCmNvbnRyb2xsZXIJY2FyZDANCmRldmljZQkJcGNpYzAJYXQgY2Fy ZD8NCmRldmljZQkJcGNpYzEJYXQgY2FyZD8NCg0KZGV2aWNlCQlzaW8wCWF0 IGlzYT8gcG9ydCAiSU9fQ09NMSIgZmxhZ3MgMHgxMCBpcnEgNA0KZGV2aWNl CQlzaW8xCWF0IGlzYT8gcG9ydCAiSU9fQ09NMiIgaXJxIDMNCmRldmljZQkJ c2lvMglhdCBpc2E/IGRpc2FibGUgcG9ydCAiSU9fQ09NMyIgaXJxIDUNCmRl dmljZQkJc2lvMwlhdCBpc2E/IGRpc2FibGUgcG9ydCAiSU9fQ09NNCIgaXJx IDkNCg0KIyBQYXJhbGxlbCBwb3J0DQpkZXZpY2UJCXBwYzAJYXQgaXNhPyBw b3J0PyBmbGFncyAweDQwIGlycSA3DQpjb250cm9sbGVyCXBwYnVzMA0KZGV2 aWNlCQlscHQwCWF0IHBwYnVzPw0KZGV2aWNlCQlwbGlwMAlhdCBwcGJ1cz8N CmRldmljZQkJcHBpMAlhdCBwcGJ1cz8NCg0KIw0KIyBUaGUgZm9sbG93aW5n IEV0aGVybmV0IE5JQ3MgYXJlIGFsbCBQQ0kgZGV2aWNlcy4NCiMNCiNkZXZp Y2UgYXgwCQkjIEFTSVggQVg4ODE0MEENCiNkZXZpY2UgZGUwCQkjIERFQy9J bnRlbCBEQzIxeDR4IChgYFR1bGlwJycpDQpkZXZpY2UgZnhwMAkJIyBJbnRl bCBFdGhlckV4cHJlc3MgUFJPLzEwMEIgKDgyNTU3LCA4MjU1OCkNCiNkZXZp Y2UgbXgwCQkjIE1hY3Jvbml4IDk4NzEzLzk4NzE1Lzk4NzI1IChgYFBNQUMn JykNCiNkZXZpY2UgcG4wCQkjIExpdGUtT24gODJjMTY4LzgyYzE2OSAoYGBQ TklDJycpDQojZGV2aWNlIHJsMAkJIyBSZWFsVGVrIDgxMjkvODEzOQ0KI2Rl dmljZSB0bDAJCSMgVGV4YXMgSW5zdHJ1bWVudHMgVGh1bmRlckxBTg0KI2Rl dmljZSB0eDAJCSMgU01DIDk0MzJUWCAoODNjMTcwIGBgRVBJQycnKQ0KI2Rl dmljZSB2cjAJCSMgVklBIFJoaW5lLCBSaGluZSBJSQ0KI2RldmljZSB2eDAJ CSMgM0NvbSAzYzU5MCwgM2M1OTUgKGBgVm9ydGV4JycpDQojZGV2aWNlIHdi MAkJIyBXaW5ib25kIFc4OUM4NDBGDQojZGV2aWNlIHhsMAkJIyAzQ29tIDNj OTB4IChgYEJvb21lcmFuZycnLCBgYEN5Y2xvbmUnJykNCg0KIyBPcmRlciBp cyBpbXBvcnRhbnQgaGVyZSBkdWUgdG8gaW50cnVzaXZlIHByb2JlcywgZG8g Km5vdCogYWxwaGFiZXRpemUNCiMgdGhpcyBsaXN0IG9mIG5ldHdvcmsgaW50 ZXJmYWNlcyB1bnRpbCB0aGUgcHJvYmVzIGhhdmUgYmVlbiBmaXhlZC4NCiMg UmlnaHQgbm93IGl0IGFwcGVhcnMgdGhhdCB0aGUgaWUwIG11c3QgYmUgcHJv YmVkIGJlZm9yZSBlcDAuIFNlZQ0KIyByZXZpc2lvbiAxLjIwIG9mIHRoaXMg ZmlsZS4NCg0KZGV2aWNlIGVkMCBhdCBpc2E/IHBvcnQgMHgyODAgaXJxIDEw IGlvbWVtIDB4ZDgwMDANCmRldmljZSBpZTAgYXQgaXNhPyBwb3J0IDB4MzAw IGlycSAxMCBpb21lbSAweGQwMDAwDQpkZXZpY2UgZXAwIGF0IGlzYT8gcG9y dCAweDMwMCBpcnEgMTANCmRldmljZSBleDAgYXQgaXNhPyBwb3J0PyBpcnE/ DQpkZXZpY2UgZmUwIGF0IGlzYT8gcG9ydCAweDMwMCBpcnEgPw0KZGV2aWNl IGxlMCBhdCBpc2E/IHBvcnQgMHgzMDAgaXJxIDUgaW9tZW0gMHhkMDAwMA0K ZGV2aWNlIGxuYzAgYXQgaXNhPyBwb3J0IDB4MjgwIGlycSAxMCBkcnEgMA0K ZGV2aWNlIGNzMCBhdCBpc2E/IHBvcnQgMHgzMDAgaXJxID8NCg0KcHNldWRv LWRldmljZQlsb29wDQpwc2V1ZG8tZGV2aWNlCWV0aGVyDQpwc2V1ZG8tZGV2 aWNlCXNsCTENCnBzZXVkby1kZXZpY2UJcHBwCTENCnBzZXVkby1kZXZpY2UJ dHVuCTINCnBzZXVkby1kZXZpY2UJdm4JNA0KcHNldWRvLWRldmljZQlwdHkJ MTYNCnBzZXVkby1kZXZpY2UJZ3ppcAkJIyBFeGVjIGd6aXBwZWQgYS5vdXQn cw0KDQojIEtUUkFDRSBlbmFibGVzIHRoZSBzeXN0ZW0tY2FsbCB0cmFjaW5n IGZhY2lsaXR5IGt0cmFjZSgyKS4NCiMgVGhpcyBhZGRzIDQgS0IgYmxvYXQg dG8geW91ciBrZXJuZWwsIGFuZCBzbGlnaHRseSBpbmNyZWFzZXMNCiMgdGhl IGNvc3RzIG9mIGVhY2ggc3lzY2FsbC4NCm9wdGlvbnMJCUtUUkFDRQkJI2tl cm5lbCB0cmFjaW5nDQoNCiMgVGhpcyBwcm92aWRlcyBzdXBwb3J0IGZvciBT eXN0ZW0gViBzaGFyZWQgbWVtb3J5IGFuZCBtZXNzYWdlIHF1ZXVlcy4NCiMN Cm9wdGlvbnMJCVNZU1ZTSE0NCm9wdGlvbnMJCVNZU1ZNU0cNCm9wdGlvbnMJ CVNZU1ZTRU0NCg0KIyAgVGhlIGBicGZpbHRlcicgcHNldWRvLWRldmljZSBl bmFibGVzIHRoZSBCZXJrZWxleSBQYWNrZXQgRmlsdGVyLiAgQmUNCiMgIGF3 YXJlIG9mIHRoZSBsZWdhbCBhbmQgYWRtaW5pc3RyYXRpdmUgY29uc2VxdWVu Y2VzIG9mIGVuYWJsaW5nIHRoaXMNCiMgIG9wdGlvbi4gIFRoZSBudW1iZXIg b2YgZGV2aWNlcyBkZXRlcm1pbmVzIHRoZSBtYXhpbXVtIG51bWJlciBvZg0K IyAgc2ltdWx0YW5lb3VzIEJQRiBjbGllbnRzIHByb2dyYW1zIHJ1bm5hYmxl Lg0KcHNldWRvLWRldmljZQlicGZpbHRlciA0CSNCZXJrZWxleSBwYWNrZXQg ZmlsdGVyDQoNCg0K --0-1006722631-931117124=:67827-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 12:44:43 1999 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id B98F014D07 for ; Sun, 4 Jul 1999 12:44:40 -0700 (PDT) (envelope-from imp@harmony.village.org) 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 NAA16139; Sun, 4 Jul 1999 13:44:39 -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 NAA43615; Sun, 4 Jul 1999 13:42:39 -0600 (MDT) Message-Id: <199907041942.NAA43615@harmony.village.org> To: Osokin Sergey Subject: Re: patch 4 UPDATING... Cc: current@FreeBSD.org In-reply-to: Your message of "Sun, 04 Jul 1999 23:22:29 +0400." References: Date: Sun, 04 Jul 1999 13:42:39 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Osokin Sergey writes: : Little patch for UPDATING: Thanks! Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 12:45:23 1999 Delivered-To: freebsd-current@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id B5CD514D07 for ; Sun, 4 Jul 1999 12:45:16 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id VAA16145 for current@FreeBSD.ORG; Sun, 4 Jul 1999 21:45:14 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id C2219885F; Sun, 4 Jul 1999 21:41:04 +0200 (CEST) (envelope-from roberto) Date: Sun, 4 Jul 1999 21:41:04 +0200 From: Ollivier Robert To: current@FreeBSD.ORG Subject: Re: loads of SetAttrs in cvsup of cvs repo Message-ID: <19990704214104.A67930@keltia.freenix.fr> Mail-Followup-To: current@FreeBSD.ORG References: <199907041856.LAA08300@vashon.polstra.com> <199907041933.OAA36387@mpp.pro-ns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.5i In-Reply-To: <199907041933.OAA36387@mpp.pro-ns.net>; from Mike Pritchard on Sun, Jul 04, 1999 at 02:33:10PM -0500 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5443 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Mike Pritchard: > -> linking cvspasswd > /usr/lib/crt0.o: file not recognize: File format not recognized Why is it trying to link the old a.out run-time code ? -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #71: Sun May 9 20:16:32 CEST 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 13:27:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id 3108414CAE for ; Sun, 4 Jul 1999 13:27:27 -0700 (PDT) (envelope-from ben@scientia.demon.co.uk) Received: from rainbow5.scientia.demon.co.uk ([192.168.1.2] ident=exim) by scientia.demon.co.uk with esmtp (Exim 3.02 #1) id 110sLS-000F7e-00; Sun, 04 Jul 1999 20:54:34 +0100 (envelope-from ben@rainbow5.scientia.demon.co.uk) Received: from rainbow5.scientia.demon.co.uk (ident=ben) by rainbow5.scientia.demon.co.uk with local (Exim 3.02 #1) id 110sLT-0007AG-00; Sun, 04 Jul 1999 20:54:35 +0100 (envelope-from ben@rainbow5.scientia.demon.co.uk) Date: Sun, 4 Jul 1999 20:54:35 +0100 From: Ben Smithurst To: Amancio Hasty Cc: Wilko Bulte , FreeBSD_current mailing list Subject: Re: loads of SetAttrs in cvsup of cvs repo Message-ID: <19990704205435.A27536@rainbow5.scientia.demon.co.uk> References: <199907041806.UAA03332@yedi.iaf.nl> <199907041839.LAA18621@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199907041839.LAA18621@rah.star-gate.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Amancio Hasty wrote: > Curious why are you cvsupping every couple of minutes ? He isn't. He's saying normally when he cvsups, it only takes a couple of minutes, not that he does it every couple of minutes. At least that's the way I read it. -- Ben Smithurst | PGP: 0x99392F7D ben@scientia.demon.co.uk | key available from keyservers and | ben+pgp@scientia.demon.co.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 13:29:59 1999 Delivered-To: freebsd-current@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 4023814CAE for ; Sun, 4 Jul 1999 13:29:55 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id WAA28399; Sun, 4 Jul 1999 22:19:24 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id WAA05110; Sun, 4 Jul 1999 22:16:46 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199907042016.WAA05110@yedi.iaf.nl> Subject: Re: loads of SetAttrs in cvsup of cvs repo In-Reply-To: from Nick Hibma at "Jul 4, 1999 9: 2:40 pm" To: hibma@skylink.it Date: Sun, 4 Jul 1999 22:16:46 +0200 (CEST) Cc: freebsd-current@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Nick Hibma wrote ... > > Maybe, your machine's date is wrong? Did you change cvsup server lately? > Did it upgrade it's version of cvsup? I once changed from de to nl and > saw similar results. Date is OK: yedi#date Sun Jul 4 22:13:55 CEST 1999 yedi# cvsup version has not been changed. I did change the cvsup server some time ago, but I'm now back at cvsup.nl.FreeBSD.org -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 13:30: 7 1999 Delivered-To: freebsd-current@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 19537150AC for ; Sun, 4 Jul 1999 13:29:55 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id WAA28400; Sun, 4 Jul 1999 22:19:24 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id WAA05028; Sun, 4 Jul 1999 22:12:45 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199907042012.WAA05028@yedi.iaf.nl> Subject: Re: loads of SetAttrs in cvsup of cvs repo In-Reply-To: <199907041856.LAA08300@vashon.polstra.com> from John Polstra at "Jul 4, 1999 11:56:45 am" To: jdp@polstra.com (John Polstra) Date: Sun, 4 Jul 1999 22:12:44 +0200 (CEST) Cc: current@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As John Polstra wrote ... > In article <199907041806.UAA03332@yedi.iaf.nl>, > Wilko Bulte wrote: > > Maybe this is a stupid question and/or FAQ but: > > You probably should have written to cvsup-bugs@polstra.com instead > of the -current list. Well, I was not exactly claiming this is a cvsup bug of some sorts. > > I'm currently cvsupping updates on the CVS repository. Most of the > > times that is a couple of minutes, but today it is already 1 hour busy. > > > > Mainly with: > > > > SetAttr > > > > (loads and loads of these). > > > > What gives? > > Several things can cause this: > > - You are running cvsup with a different umask than usual. To guard > against this, you can add a "umask=022" setting in your supfile > (CVSup-16.0 and later). I ran cvsup as root, umask set to 022. But I added the umask line to the supfile just to make sure. > - You are running cvsup under a different user-id than usual. This > probably has no effect unless you have "preserve" in your supfile. > That's almost always a bad idea except for special situations. I run it as root, and have always done so. Is this a bad idea maybe? > - You've accidentally touched all the files in your repository in > some way (changed their modtimes, changed their permissions, changed > their owners, etc.). Not that I recall having done so. But I'll keep a close eye on this. I just gave cvsup another try and it only took a few minutes updating some files in the repository. Which looked just fine. Thank you for your help, Wilko -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 13:47:59 1999 Delivered-To: freebsd-current@freebsd.org Received: from esmeralda.xaa.iae.nl (esmeralda.xaa.iae.nl [194.151.75.9]) by hub.freebsd.org (Postfix) with ESMTP id E0B3514F6E for ; Sun, 4 Jul 1999 13:47:54 -0700 (PDT) (envelope-from freebsd@xaa.iae.nl) Received: from ariel.xaa.iae.nl (ariel.xaa.iae.nl [194.151.75.10]) by esmeralda.xaa.iae.nl (Postfix) with ESMTP id 7E8D05E; Sun, 4 Jul 1999 22:47:53 +0200 (MET DST) Received: by ariel.xaa.iae.nl (Postfix, from userid 1008) id 09496196B; Sun, 4 Jul 1999 22:47:31 +0200 (CEST) Date: Sun, 4 Jul 1999 22:47:31 +0200 From: Mark Huizer To: Wilko Bulte Cc: hibma@skylink.it, freebsd-current@FreeBSD.ORG Subject: Re: loads of SetAttrs in cvsup of cvs repo Message-ID: <19990704224731.A1330@ariel.xaa.iae.nl> References: <199907042016.WAA05110@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <199907042016.WAA05110@yedi.iaf.nl>; from Wilko Bulte on Sun, Jul 04, 1999 at 10:16:46PM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Sun Jul 4 22:13:55 CEST 1999 > yedi# > > cvsup version has not been changed. > > I did change the cvsup server some time ago, but I'm now back at > cvsup.nl.FreeBSD.org > hey! that's my queue! when did it start to happen? If it was last week, then there might have been some cause in the upgrading of the machine to 3.2, or it might involve softupdates. Mark -- Nice testing in little China... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 14:14:23 1999 Delivered-To: freebsd-current@freebsd.org Received: from gateway.cybernet.com (gateway.cybernet.com [192.245.33.1]) by hub.freebsd.org (Postfix) with ESMTP id CDA9A1514F for ; Sun, 4 Jul 1999 14:14:07 -0700 (PDT) (envelope-from mtaylor@cybernet.com) Received: from spiffy.cybernet.com (spiffy.cybernet.com [192.245.33.55]) by gateway.cybernet.com (8.8.8/8.8.8) with ESMTP id RAA24170; Sun, 4 Jul 1999 17:13:36 -0400 (EDT) (envelope-from mtaylor@cybernet.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199907041925.MAA18980@rah.star-gate.com> Date: Sun, 04 Jul 1999 17:16:56 -0400 (EDT) Reply-To: mtaylor@cybernet.com Organization: Cybernet Systems From: "Mark J. Taylor" To: Amancio Hasty Subject: RE: LDAPed FreeBSD Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Are you trying to configure your entire system using LDAP as the database backend, or are you trying to serve current system info? If you are trying *configure* the system using LDAP as a database, then good luck. Our company, Cybernet Systems, has spent over ten man-years developing a HTML-based front-end for just such a purpose. When we (I) first started this project (NetMAX, http://www.netmax.com/), we evaluated LDAP as a backend. I found it too buggy (at the time) for our purposes. Does it implement record locking on read/write? Does it allow you to "batch" your changes? Does it provide for server start/restart when appropriate? Can you do cross-validation of data, for example, can you make sure that you give the DHCP server an IP address that is not already taken, or make sure that it is in one of your subnets? There are lots and lots (gobs!) of these kinds of checks that need to be done for a "complete" system configuration service. If it doesn't daemon restarts, batch-mode changes, and system checking/cross- validation, then you'll probably end up with something similar to webmin (http://www.webmin.com/). You could easily spend years making a complete interface to setup your server, or you could purchase the NetMAX software (about $500, see http://www.netmax.com/). A FreeBSD 3.2 version is in-the-works (a 2.2.7-system/2.2.8-kernel is currently available). Also, a Linux version (based on RedHat 5.2 with a 2.0.37 kernel) is currently in beta (the distributed beta is a 2.0.36 kernel, though). -Mark Taylor NetMAX Developer mtaylor@cybernet.com http://www.netmax.com/ On 04-Jul-99 Amancio Hasty wrote: > > I am playing around with configuring the system and providing a CLI , > programmatic interface and a html interface . > > > Floating in my mind is to present a uniform configuration repository similar > to windows registery however the information repository is implemented > with LDAP. See http://www.openldap.org for info on LDAP. > > The tough part is creating the LDAP schemas for the various daemons > or services. > > Got lucky and found an IETF draft : > > An LDAP Schema for Dynamic Host Configuration Protocol Service > http://www.ietf.org/internet-drafts/draft-gu-dhcp-ldap-schema-00.txt > > I am using the above draft to explore configuring dhcpd. My first cut at > configuring dhcpd via LDAP is to extract all the configuration information > from the LDAP server and writing the information to dhcpd's configuration > file and then have dhcpd parse the configuration file. This approach > minimizes the changes to dhcpd and provides persistent configuration > information for dhcpd. > > The start of my html interface is at: > > http://www.star-gate.com/dhcpd.html > > Thats just a dummy front end . The real interface is being implemented as a > servlet > and will provide a more rich presentation --- help files , How To, etc... > > The CLI interface can be as easy as using the existing ldap shell tools. > > The programmatic interface is simply the LDAP C and Java interface available > from : http://www.mozilla.org/directory > > So far I have a simple ldap schema based upon the IETF draft which I can > manage from my servlet and query from dhcpd. > > > What do you guys think? > > > -- > > Amancio Hasty > ahasty@mindspring.com > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 14:16:13 1999 Delivered-To: freebsd-current@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 95E7014BFF for ; Sun, 4 Jul 1999 14:16:07 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id RAA00834 for ; Sun, 4 Jul 1999 17:16:06 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <199907042116.RAA00834@whizzo.transsys.com> X-Mailer: exmh version 2.0.2 2/24/98 To: current@freebsd.org From: "Louis A. Mamakos" Subject: AMD K6-III CPU and Tyan S1590S at 450MHz Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 04 Jul 1999 17:16:06 -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG FYI, I just upgraded from a Pentium/P54C at 133MHz on a Tyan Titan-III motherboard to an AMD K6-III CPU at 450Mhz (100MHz bus speed) on a Tyan S1590S "Trinity 100" AT-form factor motherboard. Runs really good! I previously built a machine with a K6-2 at 350MHz on an FIC VA-503+ motherboard for FreeBSD testing and as the Windoze 98 platform for Total Annihilation game playing, and was very happy at how that worked out. So, when it came time to upgrade the old Pentium, I did the AMD thing again. The on-board 256K L2 cache and 100MHz bus really makes this machine quite spritely. Even with the crummy old SCSI fast (non wide, non ultra) disk, there's a very noticable improvement. At boot: CPU: AMD-K6(tm) 3D+ Processor (450.92-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x591 Stepping=1 Features=0x8021bf AMD Extended Features=0x808029bf Data TLB: 128 entries, 2-way associative Instruction TLB: 64 entries, 1-way associative L1 data cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative L1 instruction cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative L2 (on-CPU) cache: 256 kbytes, 32 bytes/line, 2 lines/tag, 4-way associative ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Write Allocate Enable Limit: 128M bytes Write Allocate 15-16M bytes: Enable The Tyan has a 1MB cache (now L3) of it's own. This combination is recommended (by me, at least). After doing computer surgery to swap motherboards it came right up with no problems at all. I was surprised. I've submitted a PR with a patch to add support for the L2 cache display above for -CURRENT. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 14:23:23 1999 Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 608) id 3C41C14D91; Sun, 4 Jul 1999 14:23:22 -0700 (PDT) From: "Jonathan M. Bresler" To: sams@virtualtek.com Cc: freebsd-current@freebsd.org In-reply-to: <7lo5i8$d0nb@eGroups.com> (sams@virtualtek.com) Subject: Re: freebsd web based groupware Message-Id: <19990704212322.3C41C14D91@hub.freebsd.org> Date: Sun, 4 Jul 1999 14:23:22 -0700 (PDT) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sam, Your email sounds good. the web site looks fine. but sending this message to three different lists (so far, i hope there are not others) is very near to spamming us. i sincerely hope that you have not sent this message to additional lists. jmb -- Jonathan M. Bresler FreeBSD Core Team, Postmaster jmb@FreeBSD.ORG FreeBSD--The Power to Serve JMB193 http://www.freebsd.org/ PGP 2.6.2 Fingerprint: 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 14:30: 3 1999 Delivered-To: freebsd-current@freebsd.org Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194]) by hub.freebsd.org (Postfix) with ESMTP id 9D11C14C1B for ; Sun, 4 Jul 1999 14:29:55 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.3/8.8.8) with ESMTP id OAA19892; Sun, 4 Jul 1999 14:29:32 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199907042129.OAA19892@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: mtaylor@cybernet.com Cc: freebsd-current@FreeBSD.ORG Subject: Re: LDAPed FreeBSD In-reply-to: Your message of "Sun, 04 Jul 1999 17:16:56 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 04 Jul 1999 14:29:31 -0700 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yes, I am trying to configure my entire system using LDAP as a backend. If there any bugs in the ldap server I will probably fix them or better yet the people working on openldap will fix them. I know about the issues that you are describing which is why I am targetting one daemon dhcpd and hopefully I will solve them. cross-validation of data should be easy to implement for instance I can locate all the ip assigned addresses: /usr/local/openldap/bin/ldapsearch "objectclass=DHCPRange" DHCPRange=star-gate.com, o=star-gate.com, c=us objectclass=top objectclass=DHCPRange startipaddress=172.16.0.2 endipaddress=172.16.0.255 scopetype=DHCP Record locking and batch requests is a bit more difficult to solve perhaps someone in the list can shed light into this problem for instance does LDAPv3 provide such mechanism? Tnks! > > Are you trying to configure your entire system using LDAP as the database > backend, or are you trying to serve current system info? > > If you are trying *configure* the system using LDAP as a database, then > good luck. Our company, Cybernet Systems, has spent over ten man-years > developing a HTML-based front-end for just such a purpose. When we (I) > first started this project (NetMAX, http://www.netmax.com/), we evaluated > LDAP as a backend. I found it too buggy (at the time) for our purposes. > Does it implement record locking on read/write? Does it allow you to > "batch" your changes? Does it provide for server start/restart when > appropriate? Can you do cross-validation of data, for example, can you > make sure that you give the DHCP server an IP address that is not already > taken, or make sure that it is in one of your subnets? > > There are lots and lots (gobs!) of these kinds of checks that need to > be done for a "complete" system configuration service. > If it doesn't daemon restarts, batch-mode changes, and system checking/cross- > validation, then you'll probably end up with something similar to > webmin (http://www.webmin.com/). > > > > You could easily spend years making a complete interface to setup your > server, or you could purchase the NetMAX software (about $500, see > http://www.netmax.com/). A FreeBSD 3.2 version is in-the-works (a > 2.2.7-system/2.2.8-kernel is currently available). Also, a Linux version > (based on RedHat 5.2 with a 2.0.37 kernel) is currently in beta (the > distributed beta is a 2.0.36 kernel, though). > > > > > -Mark Taylor > NetMAX Developer > mtaylor@cybernet.com > http://www.netmax.com/ > > > > On 04-Jul-99 Amancio Hasty wrote: > > > > I am playing around with configuring the system and providing a CLI , > > programmatic interface and a html interface . > > > > > > Floating in my mind is to present a uniform configuration repository similar > > to windows registery however the information repository is implemented > > with LDAP. See http://www.openldap.org for info on LDAP. > > > > The tough part is creating the LDAP schemas for the various daemons > > or services. > > > > Got lucky and found an IETF draft : > > > > An LDAP Schema for Dynamic Host Configuration Protocol Service > > http://www.ietf.org/internet-drafts/draft-gu-dhcp-ldap-schema-00.txt > > > > I am using the above draft to explore configuring dhcpd. My first cut at > > configuring dhcpd via LDAP is to extract all the configuration information > > from the LDAP server and writing the information to dhcpd's configuration > > file and then have dhcpd parse the configuration file. This approach > > minimizes the changes to dhcpd and provides persistent configuration > > information for dhcpd. > > > > The start of my html interface is at: > > > > http://www.star-gate.com/dhcpd.html > > > > Thats just a dummy front end . The real interface is being implemented as a > > servlet > > and will provide a more rich presentation --- help files , How To, etc... > > > > The CLI interface can be as easy as using the existing ldap shell tools. > > > > The programmatic interface is simply the LDAP C and Java interface available > > from : http://www.mozilla.org/directory > > > > So far I have a simple ldap schema based upon the IETF draft which I can > > manage from my servlet and query from dhcpd. > > > > > > What do you guys think? > > > > > > -- > > > > Amancio Hasty > > ahasty@mindspring.com > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > -- Amancio Hasty ahasty@mindspring.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 15:26:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id CB20C14FB3 for ; Sun, 4 Jul 1999 15:26:31 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id SAA62902; Sun, 4 Jul 1999 18:26:11 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Sun, 4 Jul 1999 18:26:11 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Dag-Erling Smorgrav Cc: Richard Tobin , phk@critter.freebsd.dk, freebsd-current@FreeBSD.org Subject: Re: IBM-DJNA drives on FreeBSD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 4 Jul 1999, Dag-Erling Smorgrav wrote: > Richard Tobin writes: > > Is that relevant for 3.2 as well as current? And by "disabling ultra > > DMA" did you mean "disabling UDMA66" or "disabling UDMA completely"? > > (You can permanently disable UDMA66 with a DOS utility available > > from IBM, and it will then act as a plain UDMA33 drive.) > > Depends on your motherboard. Try to just disable UDMA66 first. If that > doesn't help, or if you have a "known bad" chipset (e.g. AcerLabs > Aladdin), disable UDMA completely in the BIOS setup utility. What do you mean, "known bad" ALi? I've had this mobo since the beginning of the year or so, and it's given me no trouble. Ultra DMA always worked right with Soren's ATA drivers. The only problem is that UDMA can't be disabled in the BIOS, but that's due more to the BIOS brand. > > DES > -- > Dag-Erling Smorgrav - des@flood.ping.uio.no > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 15:30:45 1999 Delivered-To: freebsd-current@freebsd.org Received: from tron.flex.net (mail.flex.net [207.70.185.245]) by hub.freebsd.org (Postfix) with ESMTP id A098815140 for ; Sun, 4 Jul 1999 15:30:42 -0700 (PDT) (envelope-from marco@flex.net) Received: from flex.net (207-18-135-157.flex.net [207.18.135.157]) by tron.flex.net (8.9.3/8.9.3) with ESMTP id RAA28176 for ; Sun, 4 Jul 1999 17:28:29 -0500 Message-ID: <377FE120.C9AB7DFD@flex.net> Date: Sun, 04 Jul 1999 17:33:04 -0500 From: gene Reply-To: marco@flex.net X-Mailer: Mozilla 4.07 [en] (X11; I; FreeBSD 4.0-CURRENT i386) MIME-Version: 1.0 To: "freebsd-current@FreeBSD.ORG" Subject: Perl stops make world Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG For several months my cvsup/make world has ended with: ******************************************** ===> sys/modules/fxp @ -> /usr/src/sys machine -> /usr/src/sys/i386/include echo "#define NFXP 1" > fxp.h echo "#define NBPFILTER 0" > bpfilter.h touch opt_bdg.h perl /usr/src/sys/modules/fxp/../../kern/makedevops.pl -h /usr/src/sys/modules/fxp/../../kern/device_if.m perl: not found *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 *********************************** To make a world I can hack /usr/src/sys/modules/fxp/makefile and make perl read /usr/bin/perl but now compiling ports (any) dies with : Error: you don't have the right version of perl in /usr/bin. *** Error code 1 Stop. ****************************************** perl -v This is perl, version 5.005_02 built for i386-freebsd This sounds old, I know zip about Perl, I think the latest is like 5.005_04, but make in the /usr/ports/lang/perl5 directory gives me: make ===> perl-5.00502 is forbidden: perl is in system. ********************************************** A clue would be greatly appreciated. I have run out of things I know to try. Gene To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 15:53:38 1999 Delivered-To: freebsd-current@freebsd.org Received: from stevenson.cogsci.ed.ac.uk (stevenson144.cogsci.ed.ac.uk [129.215.144.1]) by hub.freebsd.org (Postfix) with ESMTP id ED7CF14D72 for ; Sun, 4 Jul 1999 15:53:29 -0700 (PDT) (envelope-from richard@cogsci.ed.ac.uk) Received: from doyle.cogsci.ed.ac.uk (richard@doyle [129.215.110.29]) by stevenson.cogsci.ed.ac.uk (8.8.7/8.8.7) with SMTP id XAA05419; Sun, 4 Jul 1999 23:53:26 +0100 (BST) Date: Sun, 4 Jul 1999 23:53:24 +0100 Message-Id: <4909.199907042253@doyle.cogsci.ed.ac.uk> From: Richard Tobin Subject: Re: IBM-DJNA drives on FreeBSD To: Dag-Erling Smorgrav , Richard Tobin In-Reply-To: Dag-Erling Smorgrav's message of 04 Jul 1999 20:54:52 +0200 Organization: just say no Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Depends on your motherboard. Try to just disable UDMA66 first. Thanks, that's what I did. It works fine (I'm using a SOYO 5EHM motherboard with an AMD K6-2/200). Performance is excellent; bonnie gives: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU svax32if 100 10336 95.5 14246 57.3 5733 35.9 11372 95.4 17128 57.0 147.9 3.3 that's 17MB/s for block reads (this varies quite a bit depending on the physical position on the disk). Not bad for a disk costing £165 for 13.5GB. On the other hand the system really grinds to a halt while the benchmark is running. Incidentally, I tried bonnie on an MSDOS partition (just because it's at the outside of the disk) and the result was: svax32im 100 8940 89.2 12984 76.1 473 2.8 9108 92.1 15584 86.4 76.3 48.8 Note the abysmal rewrite speed! -- Richard To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 16: 8:27 1999 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 510BD1515D for ; Sun, 4 Jul 1999 16:08:23 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.1) with ESMTP id QAA00105; Sun, 4 Jul 1999 16:08:22 -0700 (PDT) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id QAA09043; Sun, 4 Jul 1999 16:08:22 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199907042012.WAA05028@yedi.iaf.nl> Date: Sun, 04 Jul 1999 16:08:22 -0700 (PDT) Organization: Polstra & Co., Inc. From: John Polstra To: Wilko Bulte Subject: Re: loads of SetAttrs in cvsup of cvs repo Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wilko Bulte wrote: >> Several things can cause this: >> >> - You are running cvsup with a different umask than usual. To guard >> against this, you can add a "umask=022" setting in your supfile >> (CVSup-16.0 and later). > > I ran cvsup as root, umask set to 022. OK, that must not have been the problem. >> - You are running cvsup under a different user-id than usual. This >> probably has no effect unless you have "preserve" in your supfile. >> That's almost always a bad idea except for special situations. > > I run it as root, and have always done so. Is this a bad idea maybe? No, that's fine. >> - You've accidentally touched all the files in your repository in >> some way (changed their modtimes, changed their permissions, changed >> their owners, etc.). > > Not that I recall having done so. But I'll keep a close eye on this. Other possibilities: - You lost your "checkouts.cvs" file somehow. It's supposed to be underneath your cvsup "base" directory somewhere. Don't bother looking for it, because cvsup will have recreated it for you by now. - You changed your supfile in some way. - Your friendly mirror site maintainer accidentally touched his copies of the files. And of course there's always the possibility that it was caused by a plain old bug in CVSup. > I just gave cvsup another try and it only took a few minutes updating > some files in the repository. Which looked just fine. Good. I'm glad it's OK again. John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 21:48:52 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id 6B78315263 for ; Sun, 4 Jul 1999 21:48:49 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id VAA18435; Sun, 4 Jul 1999 21:48:43 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <3780392A.9596ECEA@gorean.org> Date: Sun, 04 Jul 1999 21:48:42 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: marco@flex.net Cc: "freebsd-current@FreeBSD.ORG" Subject: Re: Perl stops make world References: <377FE120.C9AB7DFD@flex.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG gene wrote: > > For several months my cvsup/make world has ended with: We have some problems in freebsd, but never problems with make world that last for months. :) Have you tried deleting /usr/obj/*, /usr/src/*, then starting with just a plain 'make -DNOCLEAN world'? Also, what are your make.conf options? Make sure that you don't have NOPERL defined in there. Good luck, Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 22:34: 2 1999 Delivered-To: freebsd-current@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id D112914D20; Sun, 4 Jul 1999 22:33:58 -0700 (PDT) (envelope-from sprice@hiwaay.net) Received: from localhost (sprice@localhost) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id AAA00518; Mon, 5 Jul 1999 00:33:57 -0500 (CDT) Date: Mon, 5 Jul 1999 00:33:57 -0500 (CDT) From: Steve Price To: freebsd-alpha@freebsd.org Cc: freebsd-current@freebsd.org Subject: alpha kernel build failure (w/patch) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Anyone object to me fixing the wb driver so kernel builds on the Alpha don't fall over anymore? The patch was gleened from the similar changes to the al driver. Thanks. -steve Index: if_wb.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_wb.c,v retrieving revision 1.11 diff -u -r1.11 if_wb.c --- if_wb.c 1999/07/02 04:17:16 1.11 +++ if_wb.c 1999/07/05 05:29:15 @@ -1096,7 +1096,12 @@ printf ("wb%d: couldn't map ports\n", unit); goto fail; } +#ifdef __i386__ sc->wb_btag = I386_BUS_SPACE_IO; +#endif +#ifdef __alpha__ + sc->wb_btag = ALPHA_BUS_SPACE_IO; +#endif #else if (!(command & PCIM_CMD_MEMEN)) { printf("wb%d: failed to enable memory mapping!\n", unit); @@ -1107,7 +1112,12 @@ printf ("wb%d: couldn't map memory\n", unit); goto fail; } +#ifdef __i386__ sc->wb_btag = I386_BUS_SPACE_MEM; +#endif +#ifdef __alpha__ + sc->wb_btag = ALPHA_BUS_SPACE_MEM; +#endif sc->wb_bhandle = vbase; #endif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 4 23:46:25 1999 Delivered-To: freebsd-current@freebsd.org Received: from smtp02.wxs.nl (smtp02.wxs.nl [195.121.6.60]) by hub.freebsd.org (Postfix) with ESMTP id C4C4714C40 for ; Sun, 4 Jul 1999 23:46:23 -0700 (PDT) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.55.128]) by smtp02.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAA5BD5; Mon, 5 Jul 1999 08:46:22 +0200 Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id IAA15787; Mon, 5 Jul 1999 08:42:19 +0200 (CEST) (envelope-from asmodai) Date: Mon, 5 Jul 1999 08:42:18 +0200 From: Jeroen Ruigrok/Asmodai To: Mark Huizer Cc: Wilko Bulte , hibma@skylink.it, freebsd-current@FreeBSD.ORG Subject: Re: loads of SetAttrs in cvsup of cvs repo Message-ID: <19990705084218.A15386@daemon.ninth-circle.org> References: <199907042016.WAA05110@yedi.iaf.nl> <19990704224731.A1330@ariel.xaa.iae.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: <19990704224731.A1330@ariel.xaa.iae.nl>; from Mark Huizer on Sun, Jul 04, 1999 at 10:47:31PM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Mark Huizer (freebsd@xaa.iae.nl) [990705 02:47]: > > > > I did change the cvsup server some time ago, but I'm now back at > > cvsup.nl.FreeBSD.org > > > hey! that's my queue! when did it start to happen? > If it was last week, then there might have been some cause in the > upgrading of the machine to 3.2, or it might involve softupdates. That was once last week, which made sense to me after you told me you upgraded cvsup.nl. I think Wilko must have suffered from the same `problem'. regards, -- Jeroen Ruigrok van der Werven asmodai(at)wxs.nl The BSD Programmer's Documentation Project Network/Security Specialist BSD: Technical excellence at its best Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 0: 0:32 1999 Delivered-To: freebsd-current@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id DAAC9152CD for ; Mon, 5 Jul 1999 00:00:26 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id IAA19296; Mon, 5 Jul 1999 08:59:05 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id XAA05933; Sun, 4 Jul 1999 23:19:13 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199907042119.XAA05933@yedi.iaf.nl> Subject: Re: loads of SetAttrs in cvsup of cvs repo In-Reply-To: <19990704205435.A27536@rainbow5.scientia.demon.co.uk> from Ben Smithurst at "Jul 4, 1999 8:54:35 pm" To: ben@scientia.demon.co.uk (Ben Smithurst) Date: Sun, 4 Jul 1999 23:19:13 +0200 (CEST) Cc: hasty@rah.star-gate.com, freebsd-current@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Ben Smithurst wrote ... > Amancio Hasty wrote: > > > Curious why are you cvsupping every couple of minutes ? > > He isn't. He's saying normally when he cvsups, it only takes a couple of > minutes, not that he does it every couple of minutes. At least that's the > way I read it. Right, that is what I meant. Sorry, should've been more precise in my original post. Would not make a lot of sense to run cvsup every few minutes ;-) -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 0: 0:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id B8DF515315 for ; Mon, 5 Jul 1999 00:00:26 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id IAA19297; Mon, 5 Jul 1999 08:59:06 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id XAA05995; Sun, 4 Jul 1999 23:22:19 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199907042122.XAA05995@yedi.iaf.nl> Subject: Re: loads of SetAttrs in cvsup of cvs repo In-Reply-To: <19990704224731.A1330@ariel.xaa.iae.nl> from Mark Huizer at "Jul 4, 1999 10:47:31 pm" To: freebsd@xaa.iae.nl (Mark Huizer) Date: Sun, 4 Jul 1999 23:22:19 +0200 (CEST) Cc: hibma@skylink.it, freebsd-current@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Mark Huizer wrote ... > > Sun Jul 4 22:13:55 CEST 1999 > > yedi# > > > > cvsup version has not been changed. > > > > I did change the cvsup server some time ago, but I'm now back at > > cvsup.nl.FreeBSD.org > > > hey! that's my queue! when did it start to happen? > If it was last week, then there might have been some cause in the > upgrading of the machine to 3.2, or it might involve softupdates. Don't worry, I checked my logs and I also saw it on June 4. But unfortunately I can't tell from the log from which server it was cvsupping. So whatever it is, it is not something that started last week. -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 0:46:59 1999 Delivered-To: freebsd-current@freebsd.org Received: from main.avias.com (avias-gw.corbina.net [195.14.40.4]) by hub.freebsd.org (Postfix) with ESMTP id A1B9F14CBF for ; Mon, 5 Jul 1999 00:46:50 -0700 (PDT) (envelope-from camel@avias.com) Received: from camel.avias.com (camel.avias.com [195.14.38.87]) by main.avias.com (8.9.3/8.9.2) with SMTP id LAA72129; Mon, 5 Jul 1999 11:46:17 +0400 (MSD) (envelope-from camel@avias.com) From: Ilya Naumov Reply-To: camel@avias.com To: Alex Zepeda Subject: Re: cvs commit: src/sys/i386/i386 identcpu.c Date: Mon, 5 Jul 1999 11:45:39 +0400 X-Mailer: KMail [version 1.0.17] Content-Type: text/plain References: Cc: current@freebsd.org MIME-Version: 1.0 Message-Id: <99070511464601.21914@camel.avias.com> Content-Transfer-Encoding: 8bit X-KMail-Mark: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ÐÎ , 05 ÉÀÌ 1999, ÷Ù ÎÁÐÉÓÁÌÉ: > On Sun, 4 Jul 1999, Brian Feldman wrote: > > > CPU: AMD-K6(tm) 3D processor (350.81-MHz 586-class CPU) > > Origin = "AuthenticAMD" Id = 0x58c Stepping=12 > > Features=0x8021bf > > AMD Features=0x808029bf > > I thought the K6-* only did 3DNow, and not MMX? no, K6-* supports MMX instruction set as well as 3DNow. -- sincerely, ilya naumov (at work) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 1:34:36 1999 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id B4BF914CAF; Mon, 5 Jul 1999 01:34:27 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id KAA10982; Mon, 5 Jul 1999 10:34:24 +0200 (CEST) (envelope-from des) To: "Brian F. Feldman" Cc: Dag-Erling Smorgrav , Richard Tobin , phk@critter.freebsd.dk, freebsd-current@FreeBSD.org Subject: Re: IBM-DJNA drives on FreeBSD References: From: Dag-Erling Smorgrav Date: 05 Jul 1999 10:34:23 +0200 In-Reply-To: "Brian F. Feldman"'s message of "Sun, 4 Jul 1999 18:26:11 -0400 (EDT)" Message-ID: Lines: 16 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Brian F. Feldman" writes: > On 4 Jul 1999, Dag-Erling Smorgrav wrote: > > Depends on your motherboard. Try to just disable UDMA66 first. If that > > doesn't help, or if you have a "known bad" chipset (e.g. AcerLabs > > Aladdin), disable UDMA completely in the BIOS setup utility. > What do you mean, "known bad" ALi? I should have said "known bad configuration". I know Søren's ATA driver supports UDMA on the Aladdin, but I don't have the luxury of expendable file systems, so I don't use it. I also think it's the wrong direction to go off in; if we're going to totally rewrite our IDE driver, we should do it within the CAM framework. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 1:43:45 1999 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 0863514EBD; Mon, 5 Jul 1999 01:43:41 -0700 (PDT) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.9.1/8.9.1) id KAA54290; Mon, 5 Jul 1999 10:43:39 +0200 (CEST) (envelope-from sos) From: Soren Schmidt Message-Id: <199907050843.KAA54290@freebsd.dk> Subject: Re: IBM-DJNA drives on FreeBSD In-Reply-To: from Dag-Erling Smorgrav at "Jul 5, 1999 10:34:23 am" To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Date: Mon, 5 Jul 1999 10:43:39 +0200 (CEST) Cc: green@FreeBSD.ORG, des@flood.ping.uio.no, richard@cogsci.ed.ac.uk, phk@critter.freebsd.dk, freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Dag-Erling Smorgrav wrote: > "Brian F. Feldman" writes: > > On 4 Jul 1999, Dag-Erling Smorgrav wrote: > > > Depends on your motherboard. Try to just disable UDMA66 first. If that > > > doesn't help, or if you have a "known bad" chipset (e.g. AcerLabs > > > Aladdin), disable UDMA completely in the BIOS setup utility. > > What do you mean, "known bad" ALi? > > I should have said "known bad configuration". I know Søren's ATA > driver supports UDMA on the Aladdin, but I don't have the luxury of > expendable file systems, so I don't use it. I also think it's the > wrong direction to go off in; if we're going to totally rewrite our > IDE driver, we should do it within the CAM framework. Do I hear a volounteer here ?? What the new ATA/ATAPI driver is all about is mostly a rewrite of all the low level code, and that is still needed if you want to go the CAM way. The higher levels of the new ATA driver is simply a port of my allready done ATAPI drivers. There is nothing in the way of screwing a CAM interface ontop of that lowlevel code instead of/in parallel to the current highlvel code.... Oh and besides that I still have to loose a filesystem to the ATA driver :) -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 2: 3:18 1999 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id C9BF615150 for ; Mon, 5 Jul 1999 02:03:13 -0700 (PDT) (envelope-from imp@harmony.village.org) 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 DAA18080; Mon, 5 Jul 1999 03:03:11 -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 DAA52096; Mon, 5 Jul 1999 03:01:18 -0600 (MDT) Message-Id: <199907050901.DAA52096@harmony.village.org> To: marco@flex.net Subject: Re: Perl stops make world Cc: "freebsd-current@FreeBSD.ORG" In-reply-to: Your message of "Sun, 04 Jul 1999 17:33:04 CDT." <377FE120.C9AB7DFD@flex.net> References: <377FE120.C9AB7DFD@flex.net> Date: Mon, 05 Jul 1999 03:01:18 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <377FE120.C9AB7DFD@flex.net> gene writes: : This sounds old, I know zip about Perl, I think the latest is like : 5.005_04, but make in the /usr/ports/lang/perl5 directory gives me: You might want to try removing the perl port you have installed on your system, and then trying the make world again. I'd bet a couple of beers that you need to remove the NOPERL line from your /etc/make.conf file, since that is usually what causes this. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 2:30: 9 1999 Delivered-To: freebsd-current@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id 17E55152C0; Mon, 5 Jul 1999 02:30:01 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5692) with ESMTP id LAA02563; Mon, 5 Jul 1999 11:29:53 +0200 (MET DST) Date: Mon, 5 Jul 1999 11:29:50 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: Soren Schmidt Cc: Dag-Erling Smorgrav , green@FreeBSD.ORG, richard@cogsci.ed.ac.uk, phk@critter.freebsd.dk, freebsd-current@FreeBSD.ORG Subject: Re: IBM-DJNA drives on FreeBSD In-Reply-To: <199907050843.KAA54290@freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I should have said "known bad configuration". I know Søren's ATA > > driver supports UDMA on the Aladdin, but I don't have the luxury of > > expendable file systems, so I don't use it. I also think it's the > > wrong direction to go off in; if we're going to totally rewrite our > > IDE driver, we should do it within the CAM framework. > > Do I hear a volounteer here ?? > What the new ATA/ATAPI driver is all about is mostly a rewrite of all > the low level code, and that is still needed if you want to go the CAM way. > The higher levels of the new ATA driver is simply a port of my allready > done ATAPI drivers. > There is nothing in the way of screwing a CAM interface ontop of that > lowlevel code instead of/in parallel to the current highlvel code.... Yes yes yes! CAM on top of ATAPI. If we keep the command creation/conversion layer in CAM and make CCB come out at the lower end, we could instantly screw it on top of the USB Mass Storage driver (that supports SCSI through CAM at the moment). On a related edge: Would it make sense to create a UFI command layer (USB floppies use it, don't know what else) on top of CAM? Or am fundamentally wrong in assuming that one can stack any command layer on top of CAM and abuse it as a layer that provides common services, command queueing, error handling? It would like this: SCSI UFI_da ATAPI \ | / CAM layer | USB Mass Storage Driver / | \ Bulk CB CBI Cheers, Nick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 2:49:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id A24C014E55; Mon, 5 Jul 1999 02:49:26 -0700 (PDT) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.9.1/8.9.1) id LAA54481; Mon, 5 Jul 1999 11:49:05 +0200 (CEST) (envelope-from sos) From: Soren Schmidt Message-Id: <199907050949.LAA54481@freebsd.dk> Subject: Re: IBM-DJNA drives on FreeBSD In-Reply-To: from Nick Hibma at "Jul 5, 1999 11:29:50 am" To: nick.hibma@jrc.it Date: Mon, 5 Jul 1999 11:49:05 +0200 (CEST) Cc: des@flood.ping.uio.no, green@FreeBSD.ORG, richard@cogsci.ed.ac.uk, phk@critter.freebsd.dk, freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Nick Hibma wrote: > > > I should have said "known bad configuration". I know Søren's ATA > > > driver supports UDMA on the Aladdin, but I don't have the luxury of > > > expendable file systems, so I don't use it. I also think it's the > > > wrong direction to go off in; if we're going to totally rewrite our > > > IDE driver, we should do it within the CAM framework. > > > > Do I hear a volounteer here ?? > > What the new ATA/ATAPI driver is all about is mostly a rewrite of all > > the low level code, and that is still needed if you want to go the CAM way. > > The higher levels of the new ATA driver is simply a port of my allready > > done ATAPI drivers. > > There is nothing in the way of screwing a CAM interface ontop of that > > lowlevel code instead of/in parallel to the current highlvel code.... > > Yes yes yes! CAM on top of ATAPI. If we keep the command > creation/conversion layer in CAM and make CCB come out at the lower end, > we could instantly screw it on top of the USB Mass Storage driver (that > supports SCSI through CAM at the moment). > Well, CAM & ATAPI is "fairly" easy, the only problem being all the little details that are different enough to make it non-trivial to maintain. I once sat down and tried to get all the details on how the CCB's where different, and decided that I wouldn't want to engage in that. Another story is ATA disks, there you either have to teach CAM about a new lowlevel protocol, or write a SCSI<>ATA translator, which I also decided I didn't want to do... Having CAM & ATAPI without the ATA part is real clumsy if you ask me, so.... There are also subtle differences in the way errors & timeouts, not to speak about tagged cmds are handlede by the HW, that probably requieres changes to the way CAM works, or non-trivial translation mechanisems, but I havn't looked too deeply into that (yet).. Besides I can live without the CAM overhead (both speed and size wise). That all boils down to that if somebody is willing to do the job, I'm sure we can integrate it into the ATA driver so that both worlds can be made happy, I just dont have the motivation to do it... > On a related edge: > > Would it make sense to create a UFI command layer (USB floppies use it, > don't know what else) on top of CAM? Or am fundamentally wrong in > assuming that one can stack any command layer on top of CAM and abuse > it as a layer that provides common services, command queueing, error > handling? > > It would like this: > > SCSI UFI_da ATAPI > \ | / > CAM layer > | > USB Mass Storage Driver > / | \ > Bulk CB CBI You better ask Justin that... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 6:53:17 1999 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 5B1CE14CAC; Mon, 5 Jul 1999 06:53:11 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id E857D78; Mon, 5 Jul 1999 21:53:09 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Soren Schmidt Cc: nick.hibma@jrc.it, des@flood.ping.uio.no, green@FreeBSD.ORG, richard@cogsci.ed.ac.uk, phk@critter.freebsd.dk, freebsd-current@FreeBSD.ORG Subject: Re: IBM-DJNA drives on FreeBSD In-reply-to: Your message of "Mon, 05 Jul 1999 11:49:05 +0200." <199907050949.LAA54481@freebsd.dk> Content-Transfer-Encoding: 8bit Date: Mon, 05 Jul 1999 21:53:09 +0800 From: Peter Wemm Message-Id: <19990705135309.E857D78@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Soren Schmidt wrote: > It seems Nick Hibma wrote: > > > > I should have said "known bad configuration". I know Søren's ATA > > > > driver supports UDMA on the Aladdin, but I don't have the luxury of > > > > expendable file systems, so I don't use it. I also think it's the > > > > wrong direction to go off in; if we're going to totally rewrite our > > > > IDE driver, we should do it within the CAM framework. > > > > > > Do I hear a volounteer here ?? > > > What the new ATA/ATAPI driver is all about is mostly a rewrite of all > > > the low level code, and that is still needed if you want to go the CAM w ay. > > > The higher levels of the new ATA driver is simply a port of my allready > > > done ATAPI drivers. > > > There is nothing in the way of screwing a CAM interface ontop of that > > > lowlevel code instead of/in parallel to the current highlvel code.... > > > > Yes yes yes! CAM on top of ATAPI. If we keep the command > > creation/conversion layer in CAM and make CCB come out at the lower end, > > we could instantly screw it on top of the USB Mass Storage driver (that > > supports SCSI through CAM at the moment). > > > > Well, CAM & ATAPI is "fairly" easy, the only problem being all the > little details that are different enough to make it non-trivial to > maintain. I once sat down and tried to get all the details on how > the CCB's where different, and decided that I wouldn't want to engage > in that. > Another story is ATA disks, there you either have to teach CAM about > a new lowlevel protocol, or write a SCSI<>ATA translator, which I > also decided I didn't want to do... Well, that's assuming you use scsi ccb's... you could use atapi ccb's. We have cam/* which is the generic transport handler. cam/scsi/* which is the scsi peripheral drivers that use scsi ccbs, and then we could have cam/ata/* which uses atapi ccb's and ata disk info. Then you have cam/ata/ata_ad.c, cam/ata/atapi_cd.c etc. Your backend ata controller code then gets requests sent to it in atapi format and/or something suitable for ata disks. This approach is quite efficient and you get to use the common queueing, error recovery, etc etc stuff. You don't have to do ccb translation or anything. You get your own disk, tape, cd etc driver with their own names and major numbers. They would look *very* similar to the scsi counterparts but would be seperate as they use different ccbs, different backend-specific hooks, etc. Things like umass, vpo etc have it easy since they basically bulk send the scsi ccb's to the device as they use the scsi protocol directly. The ATAPI protocol is similar but would require translation if it used the common top end drivers. So, it either requires different top end drivers or has to do translation. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 7: 8:41 1999 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 76F7C14CAC; Mon, 5 Jul 1999 07:08:31 -0700 (PDT) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.9.1/8.9.1) id QAA54893; Mon, 5 Jul 1999 16:07:58 +0200 (CEST) (envelope-from sos) From: Soren Schmidt Message-Id: <199907051407.QAA54893@freebsd.dk> Subject: Re: IBM-DJNA drives on FreeBSD In-Reply-To: <19990705135309.E857D78@overcee.netplex.com.au> from Peter Wemm at "Jul 5, 1999 9:53: 9 pm" To: peter@netplex.com.au (Peter Wemm) Date: Mon, 5 Jul 1999 16:07:58 +0200 (CEST) Cc: nick.hibma@jrc.it, des@flood.ping.uio.no, green@FreeBSD.ORG, richard@cogsci.ed.ac.uk, phk@critter.freebsd.dk, freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Peter Wemm wrote: > > Well, CAM & ATAPI is "fairly" easy, the only problem being all the > > little details that are different enough to make it non-trivial to > > maintain. I once sat down and tried to get all the details on how > > the CCB's where different, and decided that I wouldn't want to engage > > in that. > > Another story is ATA disks, there you either have to teach CAM about > > a new lowlevel protocol, or write a SCSI<>ATA translator, which I > > also decided I didn't want to do... > > Well, that's assuming you use scsi ccb's... you could use atapi ccb's. > We have cam/* which is the generic transport handler. cam/scsi/* which > is the scsi peripheral drivers that use scsi ccbs, and then we could > have cam/ata/* which uses atapi ccb's and ata disk info. Then you have > cam/ata/ata_ad.c, cam/ata/atapi_cd.c etc. Your backend ata controller code > then gets requests sent to it in atapi format and/or something suitable for > ata disks. > > This approach is quite efficient and you get to use the common queueing, error > recovery, etc etc stuff. You don't have to do ccb translation or anything. > You get your own disk, tape, cd etc driver with their own names and major > numbers. They would look *very* similar to the scsi counterparts but would > be seperate as they use different ccbs, different backend-specific hooks, etc. Uhm, yes, agreed, but it defies some of the gains (ie common highlevel drivers) but would probably keep the performance of the current approach. It would make life a wee bit less complicated, but one would still have to do all the lowlevel code to deal with queing etc, but the higherlevel stuff could probably be shared, maybe CAM would have to be modified a bit but it should be possible... > Things like umass, vpo etc have it easy since they basically bulk send the > scsi ccb's to the device as they use the scsi protocol directly. The ATAPI > protocol is similar but would require translation if it used the common top > end drivers. So, it either requires different top end drivers or has to do > translation. So its basically a choice between added complexity or added complexity :) When I get all the lowlevel stuff done (this has to be done no matter what approach is chosen) I'll take a look at it again, but if anybody feels like doing anything about it, let me know, so we can get things coordinated.... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 9:50: 5 1999 Delivered-To: freebsd-current@freebsd.org Received: from cantor.boolean.net (cantor.boolean.net [209.133.111.73]) by hub.freebsd.org (Postfix) with ESMTP id D2AD915020 for ; Mon, 5 Jul 1999 09:49:50 -0700 (PDT) (envelope-from Kurt@OpenLDAP.Org) Received: from gypsy (localhost [127.0.0.1]) by cantor.boolean.net (8.9.2/8.9.1) with SMTP id QAA90941; Mon, 5 Jul 1999 16:54:07 GMT (envelope-from Kurt@OpenLDAP.Org) Message-Id: <3.0.5.32.19990705094001.009f9c00@localhost> X-Sender: guru@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 05 Jul 1999 09:40:01 -0700 To: Amancio Hasty From: "Kurt D. Zeilenga" Subject: Re: LDAPed FreeBSD Cc: mtaylor@cybernet.com, freebsd-current@FreeBSD.ORG In-Reply-To: <199907042129.OAA19892@rah.star-gate.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 02:29 PM 7/4/99 -0700, Amancio Hasty wrote: >Record locking and batch requests is a bit more difficult to solve perhaps >someone in the list can shed light into this problem for instance does >LDAPv3 provide such mechanism? LDAP (v2 or v3) does not provide record locking, client/server transactions, nor any specific batching requests. The "L" in LDAP means lightweight. I think LDAP-based directory service could be used to manage a wide variety of system information including configuration information for various other network services. However, using LDAP directory services to manage network-services state information is likely not appropriate application of LDAP. For example, while it may make sense to use an LDAP directory service to manage the configuration and master zone information for a Domain Name Service, it would not be wise to use an LDAP directory service to maintain state information (such records created due to DHCP operations) of Domain Name Service. >If there any bugs in the ldap server I will probably fix them or >better yet the people working on openldap will fix them. OpenLDAP, like FreeBSD, is user maintained and developed. All users are encouraged to contribute to the project. We can surely use your help! Kurt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 10:11:37 1999 Delivered-To: freebsd-current@freebsd.org Received: from ipt2.iptelecom.net.ua (ipt2.iptelecom.net.ua [212.42.68.2]) by hub.freebsd.org (Postfix) with ESMTP id EC1E714DB6 for ; Mon, 5 Jul 1999 10:11:25 -0700 (PDT) (envelope-from sobomax@altavista.net) Received: from altavista.net (dialup1-56.iptelecom.net.ua [212.42.68.183]) by ipt2.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id UAA03825 for ; Mon, 5 Jul 1999 20:15:13 +0300 (EEST) Message-ID: <3780E7D5.45486B2B@altavista.net> Date: Mon, 05 Jul 1999 20:13:57 +0300 From: Maxim Sobolev X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org Subject: Strange CPU name reported on my k6-II system Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG When I take a closer look at dmesg output I discovered that my k6-II reported as "\^M". Maybe it is because I have an very first stepping (I bought my CPU shortly after k6-II appeared on market). Maserboard used - Tyan Trinity 100AT (VIA MP3 chipset). Any ideas? Timecounter "i8254" frequency 1193026 Hz CPU: \^E (300.64-MHz 586-class CPU) ^^^^^^^^ Origin = "AuthenticAMD" Id = 0x580 Stepping=0 Features=0x8001bf AMD Features=0x808009bf Data TLB: 128 entries, 2-way associative Instruction TLB: 64 entries, 1-way associative L1 data cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative L1 instruction cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative Write Allocate Enable Limit: 64M bytes Write Allocate 15-16M bytes: Enable Regards, Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 10:43:17 1999 Delivered-To: freebsd-current@freebsd.org Received: from ipt2.iptelecom.net.ua (ipt2.iptelecom.net.ua [212.42.68.2]) by hub.freebsd.org (Postfix) with ESMTP id 1016514C37 for ; Mon, 5 Jul 1999 10:43:01 -0700 (PDT) (envelope-from sobomax@altavista.net) Received: from altavista.net (dialup1-38.iptelecom.net.ua [212.42.68.165]) by ipt2.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id UAA05732; Mon, 5 Jul 1999 20:46:39 +0300 (EEST) Message-ID: <3780EDDF.DDD296F8@altavista.net> Date: Mon, 05 Jul 1999 20:39:43 +0300 From: Maxim Sobolev X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "Mark J. Taylor" , current@freebsd.org Subject: Re: Strange CPU name reported on my k6-II system References: <3780E7D5.45486B2B@altavista.net> <3780EA7E.75F9380F@cybernet.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Mark J. Taylor" wrote: > You didn't include the FreeBSD version in your email. I'd bet that > it is earlier than 3.2. Get the 3.2 boot floppy and see what it > indicates (ftp://ftp.freebsd.org/pub/FreeBSD/3.2-RELEASE/floppies/kern.flp). > > This buglet was supposedly corrected in January. Unfortunately you are wrong here. When I writing in the -current list it is mean that I'm running -current on my box (cvsup'ed and builded hour ago). > Maxim Sobolev wrote: > > > > When I take a closer look at dmesg output I discovered that my k6-II > > reported as "\^M". Maybe it is because I have an very first stepping (I > > bought my CPU shortly after k6-II appeared on market). Maserboard used - > > Tyan Trinity 100AT (VIA MP3 chipset). > > > > Any ideas? > > > > Timecounter "i8254" frequency 1193026 Hz > > CPU: \^E (300.64-MHz 586-class CPU) > > ^^^^^^^^ > > Origin = "AuthenticAMD" Id = 0x580 Stepping=0 > > Features=0x8001bf > > AMD > > Features=0x808009bf > > Data TLB: 128 entries, 2-way associative > > Instruction TLB: 64 entries, 1-way associative > > L1 data cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative > > L1 instruction cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way > > associative > > Write Allocate Enable Limit: 64M bytes > > Write Allocate 15-16M bytes: Enable To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 10:59:44 1999 Delivered-To: freebsd-current@freebsd.org Received: from pinhead.parag.codegen.com (207-44-235-154.CodeGen.COM [207.44.235.154]) by hub.freebsd.org (Postfix) with ESMTP id 749551515B; Mon, 5 Jul 1999 10:59:41 -0700 (PDT) (envelope-from parag@pinhead.parag.codegen.com) Received: from pinhead.parag.codegen.com (parag@localhost.parag.codegen.com [127.0.0.1]) by pinhead.parag.codegen.com (8.9.3/8.9.3) with ESMTP id KAA64811; Mon, 5 Jul 1999 10:59:37 -0700 (PDT) (envelope-from parag@pinhead.parag.codegen.com) To: Steve Price Cc: freebsd-alpha@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: alpha kernel build failure (w/patch) In-Reply-To: Message from Steve Price of "Mon, 05 Jul 1999 00:33:57 CDT." X-Face: =O'Kj74icvU|oS*<7gS/8'\Pbpm}okVj*@UC!IgkmZQAO!W[|iBiMs*|)n*`X ]pW%m>Oz_mK^Gdazsr.Z0/JsFS1uF8gBVIoChGwOy{EK=<6g?aHE`[\S]C]T0Wm X-URL: http://www.codegen.com Date: Mon, 05 Jul 1999 10:59:37 -0700 Message-ID: <64807.931197577@pinhead.parag.codegen.com> From: Parag Patel Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 05 Jul 1999 00:33:57 CDT, Steve Price wrote: >+#ifdef __i386__ > sc->wb_btag = I386_BUS_SPACE_IO; >+#endif >+#ifdef __alpha__ >+ sc->wb_btag = ALPHA_BUS_SPACE_IO; >+#endif Just curious, but is there a reason that these lines aren't simply sc->wb_btag = BUS_SPACE_IO; with this macro being set to the correct machine-specific one in some appropriate header file? I'm sure I'm missing something... Thanks! -- Parag Patel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 11:12:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id BE75E14C3D for ; Mon, 5 Jul 1999 11:12:31 -0700 (PDT) (envelope-from sprice@hiwaay.net) Received: from localhost (sprice@localhost) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id NAA21481; Mon, 5 Jul 1999 13:12:29 -0500 (CDT) Date: Mon, 5 Jul 1999 13:12:28 -0500 (CDT) From: Steve Price To: Parag Patel Cc: freebsd-current@FreeBSD.ORG Subject: Re: alpha kernel build failure (w/patch) In-Reply-To: <64807.931197577@pinhead.parag.codegen.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [trimmed -alpha from cc: list to keep the cross posting police from coming after me :)] On Mon, 5 Jul 1999, Parag Patel wrote: # On Mon, 05 Jul 1999 00:33:57 CDT, Steve Price wrote: # >+#ifdef __i386__ # > sc->wb_btag = I386_BUS_SPACE_IO; # >+#endif # >+#ifdef __alpha__ # >+ sc->wb_btag = ALPHA_BUS_SPACE_IO; # >+#endif # # Just curious, but is there a reason that these lines aren't simply # # sc->wb_btag = BUS_SPACE_IO; # # with this macro being set to the correct machine-specific one in some # appropriate header file? I'm sure I'm missing something... I wondered that as well. For both the i386 and alpha port the definitions end up in /usr/include/machine/bus.h and stripping off the arch-specific prefix shows that their value is the same. In fact they appear to be the only #define in bus.h with the arch-specific prefix besides the multiple-inclusion #defines. I think they could be combined, but defer the decision (commit) to the folks working on the new bus code as they know their way around this code much better than I do. -steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 11:24: 0 1999 Delivered-To: freebsd-current@freebsd.org Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (Postfix) with SMTP id 152C915093 for ; Mon, 5 Jul 1999 11:23:53 -0700 (PDT) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id OAA21013; Mon, 5 Jul 1999 14:25:41 -0400 From: Bill Paul Message-Id: <199907051825.OAA21013@skynet.ctr.columbia.edu> Subject: Re: alpha kernel build failure (w/patch) To: sprice@hiwaay.net (Steve Price) Date: Mon, 5 Jul 1999 14:25:40 -0400 (EDT) Cc: freebsd-current@FreeBSD.ORG, parag@cgt.com In-Reply-To: from "Steve Price" at Jul 5, 99 01:12:28 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2564 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Of all the gin joints in all the towns in all the world, Steve Price had to walk into mine and say: > [trimmed -alpha from cc: list to keep the cross posting > police from coming after me :)] > > On Mon, 5 Jul 1999, Parag Patel wrote: > > # On Mon, 05 Jul 1999 00:33:57 CDT, Steve Price wrote: > # >+#ifdef __i386__ > # > sc->wb_btag = I386_BUS_SPACE_IO; > # >+#endif > # >+#ifdef __alpha__ > # >+ sc->wb_btag = ALPHA_BUS_SPACE_IO; > # >+#endif > # > # Just curious, but is there a reason that these lines aren't simply > # > # sc->wb_btag = BUS_SPACE_IO; > # > # with this macro being set to the correct machine-specific one in some > # appropriate header file? I'm sure I'm missing something... > > I wondered that as well. For both the i386 and alpha port > the definitions end up in /usr/include/machine/bus.h and > stripping off the arch-specific prefix shows that their value > is the same. In fact they appear to be the only #define in > bus.h with the arch-specific prefix besides the multiple-inclusion > #defines. I think they could be combined, but defer the > decision (commit) to the folks working on the new bus code > as they know their way around this code much better than I > do. The reason it's not done that way is because the bus_space code is incomplete. The NetBSD code from which it was taken has a routine that sets up the bus tag for you (and I think the handle too) based on the actual bus type. In other words, you're supposed to be passed a handle to the bus on which your device resides, and you pass that to bus_space_create() or whatever, and it figures out all the right machine specific details for you. Why don't we have this routine? Because we don't have the NetBSD bus architecture and at the time we only ran on the i386 arch, so we took a shortcut and fiddled with the bus space handle and bus space tag directly. If we're really lucky then some day this will get fixed correctly, by somebody who is not me, as I have plenty of other things to keep me busy. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 11:37:38 1999 Delivered-To: freebsd-current@freebsd.org Received: from solaris.matti.ee (solaris.matti.ee [194.126.98.135]) by hub.freebsd.org (Postfix) with ESMTP id 6CD89151D9 for ; Mon, 5 Jul 1999 11:37:32 -0700 (PDT) (envelope-from vallo@matti.ee) Received: from myhakas.matti.ee (myhakas.matti.ee [194.126.114.87]) by solaris.matti.ee (8.8.8/8.8.8.s) with ESMTP id VAA07049 for ; Mon, 5 Jul 1999 21:37:19 +0300 (EET DST) Received: by myhakas.matti.ee (Postfix, from userid 1000) id A5D3E1F8E; Mon, 5 Jul 1999 21:37:30 +0300 (EEST) Date: Mon, 5 Jul 1999 21:37:30 +0300 From: Vallo Kallaste To: freebsd-current@freebsd.org Subject: Recent current misreports scsi disk size Message-ID: <19990705213730.A353@myhakas.matti.ee> Reply-To: vallo@matti.ee Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Organization: =?iso-8859-1?Q?AS_Matti_B=FCrootehnika?= Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello I just cvsupped the src-all, built the world, kernel and noticed that: changing root device to da0s1a da0 at ncr0 bus 0 target 5 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da0: 254MB (8910423 512 byte sectors: 255H 63S/T 554C) da1 at ncr0 bus 0 target 6 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da1: 254MB (8910423 512 byte sectors: 255H 63S/T 554C) ^^^^^ Actually the size is around 4GB. -- Vallo Kallaste vallo@matti.ee To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 11:45:49 1999 Delivered-To: freebsd-current@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 20CC814C4F for ; Mon, 5 Jul 1999 11:45:45 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id UAA23436; Mon, 5 Jul 1999 20:42:53 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id UAA00508; Mon, 5 Jul 1999 20:28:55 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199907051828.UAA00508@yedi.iaf.nl> Subject: Re: loads of SetAttrs in cvsup of cvs repo In-Reply-To: <19990705084218.A15386@daemon.ninth-circle.org> from Jeroen Ruigrok/Asmodai at "Jul 5, 1999 8:42:18 am" To: asmodai@wxs.nl (Jeroen Ruigrok/Asmodai) Date: Mon, 5 Jul 1999 20:28:54 +0200 (CEST) Cc: freebsd@xaa.iae.nl, hibma@skylink.it, freebsd-current@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Jeroen Ruigrok/Asmodai wrote ... > * Mark Huizer (freebsd@xaa.iae.nl) [990705 02:47]: > > > > > > I did change the cvsup server some time ago, but I'm now back at > > > cvsup.nl.FreeBSD.org > > > > > hey! that's my queue! when did it start to happen? > > If it was last week, then there might have been some cause in the > > upgrading of the machine to 3.2, or it might involve softupdates. > > That was once last week, which made sense to me after you told me you > upgraded cvsup.nl. I think Wilko must have suffered from the same `problem'. Hmm. Well, I'm not sure, but I'll watch my cvsups a bit more. -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 12:20: 6 1999 Delivered-To: freebsd-current@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 0A8C714DCB for ; Mon, 5 Jul 1999 12:20:03 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id NAA77943; Mon, 5 Jul 1999 13:19:48 -0600 (MDT) (envelope-from ken) Message-Id: <199907051919.NAA77943@panzer.kdm.org> Subject: Re: Recent current misreports scsi disk size In-Reply-To: <19990705213730.A353@myhakas.matti.ee> from Vallo Kallaste at "Jul 5, 1999 09:37:30 pm" To: vallo@matti.ee Date: Mon, 5 Jul 1999 13:19:48 -0600 (MDT) Cc: freebsd-current@FreeBSD.ORG, mjacob@feral.com From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Vallo Kallaste wrote... > Hello > > I just cvsupped the src-all, built the world, kernel and noticed that: > > changing root device to da0s1a > da0 at ncr0 bus 0 target 5 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled > da0: 254MB (8910423 512 byte sectors: 255H 63S/T 554C) > da1 at ncr0 bus 0 target 6 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled > da1: 254MB (8910423 512 byte sectors: 255H 63S/T 554C) > ^^^^^ > Actually the size is around 4GB. The change made to scsi_da.c in revision 1.28 doesn't quite work right for disks over 2G on 32 bit machines. You can probably revert back to scsi_da.c version 1.27 and fix the problem. Instead of this: (((unsigned long) dp->secsize) * ((unsigned long) dp->sectors)) >> 20ul, The calculation might work better as something like this: (((u_int64_t)dp->secsize) * ((u_int64_t) dp->sectors)) >> 20 That'll probably cause a printf format warning, though. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 12:57:28 1999 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id BF4B914F61 for ; Mon, 5 Jul 1999 12:57:26 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id MAA09857; Mon, 5 Jul 1999 12:57:20 -0700 Date: Mon, 5 Jul 1999 12:56:24 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Kenneth D. Merry" Cc: vallo@matti.ee, freebsd-current@FreeBSD.ORG Subject: Re: Recent current misreports scsi disk size In-Reply-To: <199907051919.NAA77943@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry, I pooched it. I'll fix. On Mon, 5 Jul 1999, Kenneth D. Merry wrote: > Vallo Kallaste wrote... > > Hello > > > > I just cvsupped the src-all, built the world, kernel and noticed that: > > > > changing root device to da0s1a > > da0 at ncr0 bus 0 target 5 lun 0 > > da0: Fixed Direct Access SCSI-2 device > > da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled > > da0: 254MB (8910423 512 byte sectors: 255H 63S/T 554C) > > da1 at ncr0 bus 0 target 6 lun 0 > > da1: Fixed Direct Access SCSI-2 device > > da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled > > da1: 254MB (8910423 512 byte sectors: 255H 63S/T 554C) > > ^^^^^ > > Actually the size is around 4GB. > > The change made to scsi_da.c in revision 1.28 doesn't quite work right for > disks over 2G on 32 bit machines. > > You can probably revert back to scsi_da.c version 1.27 and fix the problem. > > Instead of this: > > (((unsigned long) dp->secsize) * ((unsigned long) dp->sectors)) >> 20ul, > > The calculation might work better as something like this: > > (((u_int64_t)dp->secsize) * ((u_int64_t) dp->sectors)) >> 20 > > That'll probably cause a printf format warning, though. > > Ken > -- > Kenneth Merry > ken@plutotech.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 13: 0:19 1999 Delivered-To: freebsd-current@freebsd.org Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194]) by hub.freebsd.org (Postfix) with ESMTP id C476514F1A for ; Mon, 5 Jul 1999 13:00:17 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.3/8.8.8) with ESMTP id MAA27212; Mon, 5 Jul 1999 12:59:45 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199907051959.MAA27212@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Kurt D. Zeilenga" Cc: mtaylor@cybernet.com, freebsd-current@FreeBSD.ORG, Mark Wilcox Subject: Re: LDAPed FreeBSD In-reply-to: Your message of "Mon, 05 Jul 1999 09:40:01 PDT." <3.0.5.32.19990705094001.009f9c00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Jul 1999 12:59:45 -0700 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Again, I think it is appropiate to use LDAP for configuring network services such as DHCPD , DNS , PPP, etc and to a limited extend sendmail -- see sendmail's modification to support user's delivery address : http://www.stanford.edu/~bbense/Inst.html and actually We can ask the Standford team about some of the problems mentioned on this list to see what they think about it ;specially, if their LDAP service is deployed ... True LDAP (v2 or v3) does not provide record locking . Now the question is does Novell's NDS 8 -- a native LDAP v3 -- , Oracle's Directory Server or Microsoft Active Directory does if they do then how ? Mantaining state information such as DNS is not a good idea as Kurt has stated . Again my emphasis is on configuring network services or other system services if appropiate and to provide a HTML interface which is sufficiently rich to be user friendly. My little test bed project is coming along fine . My servlet which implements my dummy html interfface, http://www.star-gate.com/dhcpd.html, is fully operational and it was not hard to wirite whats left is to provide error checking and cross data validation . The mods to dhcpd to support ldap are already in place. Searching the LDAP database for existing DHCPD entries is also fairly straight forward and I do have a servlet to locate dhcpd servers which accepts regular expressions as suppported by LDAP --- search : www* will locate all the dhcdp servers starting with www 8) Regards > At 02:29 PM 7/4/99 -0700, Amancio Hasty wrote: > >Record locking and batch requests is a bit more difficult to solve perhaps > >someone in the list can shed light into this problem for instance does > >LDAPv3 provide such mechanism? > > LDAP (v2 or v3) does not provide record locking, client/server > transactions, nor any specific batching requests. The "L" in LDAP > means lightweight. > > I think LDAP-based directory service could be used to manage > a wide variety of system information including configuration > information for various other network services. However, using > LDAP directory services to manage network-services state information > is likely not appropriate application of LDAP. > > For example, while it may make sense to use an LDAP directory > service to manage the configuration and master zone information > for a Domain Name Service, it would not be wise to use an LDAP > directory service to maintain state information (such records > created due to DHCP operations) of Domain Name Service. > > >If there any bugs in the ldap server I will probably fix them or > >better yet the people working on openldap will fix them. > > OpenLDAP, like FreeBSD, is user maintained and developed. All > users are encouraged to contribute to the project. We can > surely use your help! > > Kurt > -- Amancio Hasty ahasty@mindspring.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 13: 4:22 1999 Delivered-To: freebsd-current@freebsd.org Received: from franz.videotron.net (franz.videotron.net [205.151.222.14]) by hub.freebsd.org (Postfix) with ESMTP id F267B14F1A for ; Mon, 5 Jul 1999 13:04:20 -0700 (PDT) (envelope-from nicblais@videotron.ca) Received: from videotron.ca (ppp095.84.mque.videotron.net [207.253.84.95]) by franz.videotron.net (8.9.2/8.9.2) with ESMTP id QAA12311 for ; Mon, 5 Jul 1999 16:04:18 -0400 (EDT) Message-ID: <37810FDD.C1321FE7@videotron.ca> Date: Mon, 05 Jul 1999 16:04:46 -0400 From: Nicolas Blais X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-19990702-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: HELP!!! -CURRENT libtool problem. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi. I've finally installed FreeBSD 4.0 and to tell you the truth, I'm not very impressed. I was expecting some bugs but not like that... Most of my stuff compiles great with EGCS except all my shared libraries that uses libtool like jpeglib and giflib. They both use libtool which for some odd reason was not installed on my system. I downloaded it from the package directory and installed it with pkg_add but now, both configure says that libtool does not support shared libraries. So anything that uses configure won't compile shared libraries but programs that have their own installation scripts (like libpng and xpm-3.4k) compile fine. I REALLY need those shared libraries and I can't use the one from the port because I need to compile windowmaker with it. Also, before I removed 3.2 from my system, I made a little cpp hello world program and with GCC the binary was 8k. That same program was 40k with EGCS. Anyone know why? Please help. I'm really desperate. -- Nicolas Blais nicblais@videotron.ca Powered by FreeBSD http://www.freebsd.org My current running version : FreeBSD 4.0-CURRENT http://pages.infinit.net/primary/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 13:28: 6 1999 Delivered-To: freebsd-current@freebsd.org Received: from cantor.boolean.net (cantor.boolean.net [209.133.111.73]) by hub.freebsd.org (Postfix) with ESMTP id DEC9D15041 for ; Mon, 5 Jul 1999 13:27:32 -0700 (PDT) (envelope-from Kurt@OpenLDAP.Org) Received: from OpenLDAP.Org (localhost [127.0.0.1]) by cantor.boolean.net (8.9.2/8.9.1) with ESMTP id UAA92712; Mon, 5 Jul 1999 20:31:52 GMT (envelope-from Kurt@OpenLDAP.Org) Message-ID: <378112E3.A1E8635@OpenLDAP.Org> Date: Mon, 05 Jul 1999 13:17:39 -0700 From: "Kurt D. Zeilenga" Organization: OpenLDAP X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en-GB,en-US,en,de-DE,de MIME-Version: 1.0 To: Amancio Hasty Cc: mtaylor@cybernet.com, freebsd-current@FreeBSD.ORG, Mark Wilcox Subject: Re: LDAPed FreeBSD References: <199907051959.MAA27212@rah.star-gate.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This discussion is diverging a bit from this list's charter. Hence, I'll be brief. Amancio Hasty wrote: > True LDAP (v2 or v3) does not provide record locking . Now the question is > does Novell's NDS 8 -- a native LDAP v3 -- , Oracle's Directory > Server or Microsoft Active Directory does if they do then how ? Commonly through other directory (or database) access mechanisms. Or, possibly, though some private or experimental LDAPv3 control or extended op they added to their client/servers (LDAPv3 is an extensible protocol). > Again my emphasis is on configuring network services or other system services > if appropiate and to provide a HTML interface which is sufficiently rich to be > user friendly. I think this would be a fine use of LDAP. Kurt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 13:43:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 4AC9F1544D for ; Mon, 5 Jul 1999 13:43:47 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id NAA66061; Mon, 5 Jul 1999 13:42:39 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Nicolas Blais Cc: freebsd-current@FreeBSD.ORG Subject: Re: HELP!!! -CURRENT libtool problem. In-reply-to: Your message of "Mon, 05 Jul 1999 16:04:46 EDT." <37810FDD.C1321FE7@videotron.ca> Date: Mon, 05 Jul 1999 13:42:39 -0700 Message-ID: <66021.931207359@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi. I've finally installed FreeBSD 4.0 and to tell you the truth, I'm > not very impressed. I was expecting some bugs but not like that... I don't see a problem with FreeBSD 4.0 so much as a problem with someone jumping beyond their abilities. :) Please, go back to 3.2-STABLE. 4.0-CURRENT is a *development* version and you're expected to understand how to deal with things like applications breakage (including how to recompile libtool and any other components you may need) before doing anything as rash as running 4.0-current. I'm also sure this response will probably scare a few people off and garner stern rebukes from the newbie hand-holding folks, but it's honestly always been the case that -current is NOT for anyone but the advanced class students and we like it that way because we'd otherwise spend more time coaching people over the bumps than we did in actually working on -current and evolving FreeBSD significantly at all. Think of -current as an operating room where surgeons are actively working on a patient under anaesthesia - do you really want just anybody wandering in there to ask the doctors random questions while they work or do you maybe want to limit participation to only those with some prior medical training? I also make this point now and with such force because various signs and portents indicate that -current is about to become a dangerous place again for awhile, and a lot of people who really don't have the cojones to run -current are going to find this out rather abruptly and painfully. :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 14: 1:45 1999 Delivered-To: freebsd-current@freebsd.org Received: from taciturn.tcac.net (s057-cdm55.amar.tcac.net [207.50.55.57]) by hub.freebsd.org (Postfix) with SMTP id CF2F7151AC for ; Mon, 5 Jul 1999 14:01:29 -0700 (PDT) (envelope-from bhughes@tcac.net) Received: (qmail 44647 invoked by uid 1000); 5 Jul 1999 21:01:23 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Jul 1999 21:01:23 -0000 Date: Mon, 5 Jul 1999 16:01:23 -0500 (CDT) From: "Bradley T. Hughes" To: Nicolas Blais Cc: freebsd-current@FreeBSD.ORG Subject: Re: HELP!!! -CURRENT libtool problem. In-Reply-To: <37810FDD.C1321FE7@videotron.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 5 Jul 1999, Nicolas Blais wrote: [snip] > Also, before I removed 3.2 from my system, I made a little cpp hello > world > program and with GCC the binary was 8k. That same program was 40k with > EGCS. Anyone know why? this is probably caused by the exception handling that is included with egcs (and not int gcc 2.7.2.1 used in 3.2)...add -fno-exceptions to your CFLAGS and the binary should reduce in size > Please help. I'm really desperate. > > -- > Nicolas Blais nicblais@videotron.ca > Powered by FreeBSD http://www.freebsd.org > My current running version : FreeBSD 4.0-CURRENT > http://pages.infinit.net/primary/ > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > Blackbox - An X11R6 Window Manager http://blackbox.wiw.org/ __________________________________ Bradley T. Hughes To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 14:20:44 1999 Delivered-To: freebsd-current@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 9AD2814D15 for ; Mon, 5 Jul 1999 14:20:38 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 111GA6-000JTT-00; Mon, 05 Jul 1999 23:20:26 +0200 From: Sheldon Hearn To: "Jordan K. Hubbard" Cc: freebsd-current@FreeBSD.ORG Subject: Re: HELP!!! -CURRENT libtool problem. In-reply-to: Your message of "Mon, 05 Jul 1999 13:42:39 MST." <66021.931207359@zippy.cdrom.com> Date: Mon, 05 Jul 1999 23:20:26 +0200 Message-ID: <74862.931209626@axl.noc.iafrica.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 05 Jul 1999 13:42:39 MST, "Jordan K. Hubbard" wrote: > I also make this point now and with such force because various signs > and portents indicate that -current is about to become a dangerous > place again for awhile, and a lot of people who really don't have the > cojones to run -current are going to find this out rather abruptly and > painfully. :-) Haha! The secret to surviving CURRENT without big cojones is to watch cvs commit mail very closely. The stuff I've been seeing for the last couple of weeks has kept my hands off the trigger as far as rebuilding kernel or the world have been concerned. :-P Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 15:22: 9 1999 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 4424315206; Mon, 5 Jul 1999 15:22:02 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 3666F64; Tue, 6 Jul 1999 06:22:01 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Parag Patel Cc: Steve Price , freebsd-alpha@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: alpha kernel build failure (w/patch) In-reply-to: Your message of "Mon, 05 Jul 1999 10:59:37 MST." <64807.931197577@pinhead.parag.codegen.com> Date: Tue, 06 Jul 1999 06:22:01 +0800 From: Peter Wemm Message-Id: <19990705222201.3666F64@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Parag Patel wrote: > On Mon, 05 Jul 1999 00:33:57 CDT, Steve Price wrote: > >+#ifdef __i386__ > > sc->wb_btag = I386_BUS_SPACE_IO; > >+#endif > >+#ifdef __alpha__ > >+ sc->wb_btag = ALPHA_BUS_SPACE_IO; > >+#endif > > Just curious, but is there a reason that these lines aren't simply > > sc->wb_btag = BUS_SPACE_IO; > > with this macro being set to the correct machine-specific one in some > appropriate header file? I'm sure I'm missing something... > > Thanks! The really annoying thing is that this is handled in the bus configuration system already. The driver only has to ask for the handle and tags for the resource it's activated and can then use that directly for the bus_space calls. But, old style drivers don't have access to that as the information is not available across the compatability shims. > -- Parag Patel Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 15:42:26 1999 Delivered-To: freebsd-current@freebsd.org Received: from serv05.slac.stanford.edu (SERV05.SLAC.Stanford.EDU [134.79.16.135]) by hub.freebsd.org (Postfix) with ESMTP id 840A015355 for ; Mon, 5 Jul 1999 15:42:17 -0700 (PDT) (envelope-from pavel@SLAC.Stanford.EDU) Received: from mailbox.SLAC.Stanford.EDU ("port 39734"@[134.79.18.29]) by SERV05.SLAC.STANFORD.EDU (PMDF V5.2-27 #34067) with ESMTP id <01JD7LC3JFAO000VZD@SERV05.SLAC.STANFORD.EDU> for freebsd-current@FreeBSD.ORG; Mon, 5 Jul 1999 15:42:14 PDT Received: from mach1.SLAC.Stanford.EDU ([134.79.128.63]) by mailbox.slac.stanford.edu (PMDF V5.2-27 #34068) with ESMTP id <0FEF008IY5QDMA@mailbox.slac.stanford.edu> for freebsd-current@FreeBSD.ORG; Mon, 05 Jul 1999 15:42:13 -0700 (PDT) Date: Mon, 05 Jul 1999 15:42:13 -0700 From: Tom Pavel Subject: Kernel versions and kld modules [WAS: this of interest to anyone?] In-reply-to: "Your message of Sat, 03 Jul 1999 00:40:08 +0800." <19990702164008.2619E64@overcee.netplex.com.au> To: freebsd-current@FreeBSD.ORG Reply-To: pavel@SLAC.Stanford.EDU Message-id: <0FEF008IZ5QDMA@mailbox.slac.stanford.edu> X-Organization: Stanford Linear Accelerator Center Content-transfer-encoding: 7BIT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> On Sat, 3 Jul 1999, Peter Wemm writes: > A few key suggestions for people still along for the ride: > > 1: When you've got a good running kernel that you're happy with, do yourself > a big favour and copy it from /kernel to /kernel.ok or something like that. > So, when you manage to get a bad /kernel and /kernel.old, you've still got > a fallback that doesn't mean resorting to a fixit disk boot. This reminds me of something I wanted to ask about. A little while back I made the typical junior mistake of building/installing a new kernel without doing the make install of the related modules. In my case, the crash came from kernfs and it was easy to boot single-user and comment out a line in fstab. But my question is with the trend towards more module-ization of the kernel, does saving a /kernel.old make sense without saving a /modules.old? Should the config-generated Makefile for the kernel have a target to build and install the new modules as well (as opposed to installing them with make world)? Should we install modules into some path identified by a kernel version (whatever that means exactly)? The extreme end of this line of logic is the Linux module hashing mechanism, which I've never fully understood. My experience with it is that it can prevent you from using a binary-only module (AFS is the one I'm thinking of) even if the interfaces haven't really changed. It seems like a poor substitute for proper management and versioning of kernel interfaces. I suppose much of this becomes a non-issue outside of -current, and maybe that's why no one has seemed worried about it. Even in -stable, though, I suppose you could have incompatible kernel interfaces introduced that might break modules. It just seems to me that one should consider /kernel plus /modules/* to be more of unit. Thanks for any insights. Tom Pavel Stanford Linear Accelerator Center pavel@slac.stanford.edu http://www.slac.stanford.edu/~pavel/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 16:16:22 1999 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id A8B7014E95; Mon, 5 Jul 1999 16:16:12 -0700 (PDT) (envelope-from imp@harmony.village.org) 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 RAA20334; Mon, 5 Jul 1999 17:16:11 -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 RAA59341; Mon, 5 Jul 1999 17:14:25 -0600 (MDT) Message-Id: <199907052314.RAA59341@harmony.village.org> To: Parag Patel Subject: Re: alpha kernel build failure (w/patch) Cc: Steve Price , freebsd-alpha@FreeBSD.ORG, freebsd-current@FreeBSD.ORG In-reply-to: Your message of "Mon, 05 Jul 1999 10:59:37 PDT." <64807.931197577@pinhead.parag.codegen.com> References: <64807.931197577@pinhead.parag.codegen.com> Date: Mon, 05 Jul 1999 17:14:25 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <64807.931197577@pinhead.parag.codegen.com> Parag Patel writes: : Just curious, but is there a reason that these lines aren't simply : : sc->wb_btag = BUS_SPACE_IO; : : with this macro being set to the correct machine-specific one in some : appropriate header file? I'm sure I'm missing something... Yes. The bus tag should be obtained from new-bus's functions rather than it being hard coded. Also, the bus space on more complicated machines might be different than just I/O. In fact, even on Pccard machines one can make a good case for it being a different bus tag... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 16:19:13 1999 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 0549314BDE for ; Mon, 5 Jul 1999 16:18:45 -0700 (PDT) (envelope-from imp@harmony.village.org) 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 RAA20350; Mon, 5 Jul 1999 17:18:44 -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 RAA59400; Mon, 5 Jul 1999 17:16:59 -0600 (MDT) Message-Id: <199907052316.RAA59400@harmony.village.org> To: Steve Price Subject: Re: alpha kernel build failure (w/patch) Cc: Parag Patel , freebsd-current@FreeBSD.ORG In-reply-to: Your message of "Mon, 05 Jul 1999 13:12:28 CDT." References: Date: Mon, 05 Jul 1999 17:16:59 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Steve Price writes: : I wondered that as well. For both the i386 and alpha port : the definitions end up in /usr/include/machine/bus.h and : stripping off the arch-specific prefix shows that their value : is the same. Because the bus tag isn't guarnateed to be a constant. On some machines it matters what kind of bus you are on as to what you use. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 16:20:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id A0BC414C40 for ; Mon, 5 Jul 1999 16:20:20 -0700 (PDT) (envelope-from imp@harmony.village.org) 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 RAA20360; Mon, 5 Jul 1999 17:20:13 -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 RAA59420; Mon, 5 Jul 1999 17:18:28 -0600 (MDT) Message-Id: <199907052318.RAA59420@harmony.village.org> To: Bill Paul Subject: Re: alpha kernel build failure (w/patch) Cc: sprice@hiwaay.net (Steve Price), freebsd-current@FreeBSD.ORG, parag@cgt.com In-reply-to: Your message of "Mon, 05 Jul 1999 14:25:40 EDT." <199907051825.OAA21013@skynet.ctr.columbia.edu> References: <199907051825.OAA21013@skynet.ctr.columbia.edu> Date: Mon, 05 Jul 1999 17:18:28 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199907051825.OAA21013@skynet.ctr.columbia.edu> Bill Paul writes: : If we're really lucky then some day this will get fixed correctly, : by somebody who is not me, as I have plenty of other things to keep : me busy. I'm working on moderizing the bus space implementation right now. It will make writing the newconfig shims for new-bus easier. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 16:22: 6 1999 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 755E915107 for ; Mon, 5 Jul 1999 16:22:02 -0700 (PDT) (envelope-from imp@harmony.village.org) 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 RAA20367; Mon, 5 Jul 1999 17:22:00 -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 RAA59443; Mon, 5 Jul 1999 17:20:14 -0600 (MDT) Message-Id: <199907052320.RAA59443@harmony.village.org> To: Sheldon Hearn Subject: Re: HELP!!! -CURRENT libtool problem. Cc: "Jordan K. Hubbard" , freebsd-current@FreeBSD.ORG In-reply-to: Your message of "Mon, 05 Jul 1999 23:20:26 +0200." <74862.931209626@axl.noc.iafrica.com> References: <74862.931209626@axl.noc.iafrica.com> Date: Mon, 05 Jul 1999 17:20:14 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <74862.931209626@axl.noc.iafrica.com> Sheldon Hearn writes: : Haha! The secret to surviving CURRENT without big cojones is to watch : cvs commit mail very closely. When one has big cojones, they are a bigger target so it winds up not helping much :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 16:51:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from bubba.whistle.com (s205m7.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id C3FEC14BCD; Mon, 5 Jul 1999 16:51:44 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id QAA27061; Mon, 5 Jul 1999 16:51:43 -0700 (PDT) From: Archie Cobbs Message-Id: <199907052351.QAA27061@bubba.whistle.com> Subject: Re: alpha kernel build failure (w/patch) In-Reply-To: from Steve Price at "Jul 5, 99 00:33:57 am" To: sprice@hiwaay.net (Steve Price) Date: Mon, 5 Jul 1999 16:51:43 -0700 (PDT) Cc: freebsd-alpha@FreeBSD.ORG, freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Steve Price writes: > } > +#ifdef __i386__ > sc->wb_btag = I386_BUS_SPACE_IO; > +#endif > +#ifdef __alpha__ > + sc->wb_btag = ALPHA_BUS_SPACE_IO; > +#endif > #else > if (!(command & PCIM_CMD_MEMEN)) { Just a minor comment.. anytime you have something like this, it's always nice to do it this way instead: #if defined(__i386__) sc->wb_btag = I386_BUS_SPACE_IO; #elif defined(__alpha__) sc->wb_btag = ALPHA_BUS_SPACE_IO; #else #error Machine architecture unsupported #endif That way when somebody wants to add M68K support or whatever they are alerted that they need to implement the new flag at compile time instead of at panic time :-) -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 18:44:45 1999 Delivered-To: freebsd-current@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id D0F441508F for ; Mon, 5 Jul 1999 18:43:02 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id LAA29280; Tue, 6 Jul 1999 11:13:01 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id LAA77414; Tue, 6 Jul 1999 11:13:00 +0930 (CST) Date: Tue, 6 Jul 1999 11:13:00 +0930 From: Greg Lehey To: Maxim Sobolev Cc: current@FreeBSD.ORG, green@freebie.lemis.com Subject: Re: Strange CPU name reported on my k6-II system Message-ID: <19990706111300.C451@freebie.lemis.com> References: <3780E7D5.45486B2B@altavista.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <3780E7D5.45486B2B@altavista.net>; from Maxim Sobolev on Mon, Jul 05, 1999 at 08:13:57PM +0300 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 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 5 July 1999 at 20:13:57 +0300, Maxim Sobolev wrote: > When I take a closer look at dmesg output I discovered that my k6-II > reported as "\^M". Maybe it is because I have an very first stepping (I > bought my CPU shortly after k6-II appeared on market). Maserboard used - > Tyan Trinity 100AT (VIA MP3 chipset). > > Any ideas? > > Timecounter "i8254" frequency 1193026 Hz > CPU: \^E (300.64-MHz 586-class CPU) > ^^^^^^^^ > Origin = "AuthenticAMD" Id = 0x580 Stepping=0 > Features=0x8001bf > AMD > Features=0x808009bf > Data TLB: 128 entries, 2-way associative > Instruction TLB: 64 entries, 1-way associative > L1 data cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative > L1 instruction cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way > associative > Write Allocate Enable Limit: 64M bytes > Write Allocate 15-16M bytes: Enable I believe green was doing some work in this area in the last day or two. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 19: 7:32 1999 Delivered-To: freebsd-current@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 9C9AA15281 for ; Mon, 5 Jul 1999 19:07:26 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id LAA29395; Tue, 6 Jul 1999 11:37:24 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id LAA77620; Tue, 6 Jul 1999 11:37:23 +0930 (CST) Date: Tue, 6 Jul 1999 11:37:23 +0930 From: Greg Lehey To: Tom Pavel Cc: freebsd-current@FreeBSD.ORG Subject: Re: Kernel versions and kld modules [WAS: this of interest to anyone?] Message-ID: <19990706113723.H451@freebie.lemis.com> References: <19990702164008.2619E64@overcee.netplex.com.au> <0FEF008IZ5QDMA@mailbox.slac.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <0FEF008IZ5QDMA@mailbox.slac.stanford.edu>; from Tom Pavel on Mon, Jul 05, 1999 at 03:42:13PM -0700 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 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 5 July 1999 at 15:42:13 -0700, Tom Pavel wrote: > >>>>>> On Sat, 3 Jul 1999, Peter Wemm writes: > >> A few key suggestions for people still along for the ride: >> >> 1: When you've got a good running kernel that you're happy with, do yourself >> a big favour and copy it from /kernel to /kernel.ok or something like that. >> So, when you manage to get a bad /kernel and /kernel.old, you've still got >> a fallback that doesn't mean resorting to a fixit disk boot. > > This reminds me of something I wanted to ask about. A little while > back I made the typical junior mistake of building/installing a new > kernel without doing the make install of the related modules. In my > case, the crash came from kernfs and it was easy to boot single-user > and comment out a line in fstab. > > But my question is with the trend towards more module-ization of the > kernel, does saving a /kernel.old make sense without saving a > /modules.old? Should the config-generated Makefile for the kernel > have a target to build and install the new modules as well (as opposed > to installing them with make world)? Should we install modules into > some path identified by a kernel version (whatever that means > exactly)? You've come up with a point I've been wanting to make for some time. The kernel build should really build the modules as well, and the install should change things as you suggest. Of course, that takes up more space, but I believe it's necessary. > I suppose much of this becomes a non-issue outside of -current, Not really. Less of an issue, yes, but it's still there. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 21:18:30 1999 Delivered-To: freebsd-current@freebsd.org Received: from luckyscasino.com (unknown [207.124.92.105]) by hub.freebsd.org (Postfix) with SMTP id EBC6A153A5 for ; Mon, 5 Jul 1999 21:17:27 -0700 (PDT) (envelope-from affiliate@luckyscasino.com) To: freebsd-current@freebsd.org Date: Mon, 05 Jul 1999 22:15:29 -0600 Subject: Earn Cash X-Mailer: CyberCreek Avalanche 98 Demo; RSR Build:33666 Content-Type: text/plain; charset="us-ascii" From: affiliate@luckyscasino.com Message-Id: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear Webmaster, We are a business conducting business and this is not unsolicited bulk email. We have purchased your email address from an Internet marketing center. If you do not wish to receive further notices from Lucky's Casino, please reply to this e-mail and type "UNSUBSCRIBE" in the subject field. Want to earn extra cash? Join the Lucky's Casino affiliate program to earn revenues from your website. By participating in this mutually beneficial program, webmasters like your-self will get the opportunity to earn extra cash and become a part of the fastest growing industry in the world. Need more Info? If you are interested in becoming an affiliate of Lucky's Casino, and would like to find out more about this program, please visit: http://207.236.72.231/TrackA.asp Please let us know if you have any comments or questions by e-mailing us at affiliate@luckyscasino.com Regards, The Staff at Lucky's We hope you have a great day! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 21:19:30 1999 Delivered-To: freebsd-current@freebsd.org Received: from luckyscasino.com (unknown [207.124.92.105]) by hub.freebsd.org (Postfix) with SMTP id 9F973153A7 for ; Mon, 5 Jul 1999 21:17:27 -0700 (PDT) (envelope-from affiliate@luckyscasino.com) X-Mailer: CyberCreek Avalanche 98 Demo; RSR Build:33666 Message-Id: Date: Mon, 05 Jul 1999 22:16:28 -0600 To: freebsd-current@freebsd.org From: affiliate@luckyscasino.com Subject: Earn Cash Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear Webmaster, We are a business conducting business and this is not unsolicited bulk email. We have purchased your email address from an Internet marketing center. If you do not wish to receive further notices from Lucky's Casino, please reply to this e-mail and type "UNSUBSCRIBE" in the subject field. Want to earn extra cash? Join the Lucky's Casino affiliate program to earn revenues from your website. By participating in this mutually beneficial program, webmasters like your-self will get the opportunity to earn extra cash and become a part of the fastest growing industry in the world. Need more Info? If you are interested in becoming an affiliate of Lucky's Casino, and would like to find out more about this program, please visit: http://207.236.72.231/TrackA.asp Please let us know if you have any comments or questions by e-mailing us at affiliate@luckyscasino.com Regards, The Staff at Lucky's We hope you have a great day! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 21:55:52 1999 Delivered-To: freebsd-current@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id D14B114EF5 for ; Mon, 5 Jul 1999 21:55:43 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id VAA77942; Mon, 5 Jul 1999 21:54:12 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: postmaster@luckyscasino.com Cc: freebsd-current@FreeBSD.ORG Subject: Re: Earn Cash In-reply-to: Your message of "Mon, 05 Jul 1999 22:16:28 MDT." Date: Mon, 05 Jul 1999 21:54:11 -0700 Message-ID: <77938.931236851@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Luckycasino.com now blocked by spam filters. Sorry, as always, for the interruption. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 23:15: 8 1999 Delivered-To: freebsd-current@freebsd.org Received: from rnocserv.urc.ac.ru (rnocserv.urc.ac.ru [193.233.85.48]) by hub.freebsd.org (Postfix) with ESMTP id 4749C153D1 for ; Mon, 5 Jul 1999 23:14:23 -0700 (PDT) (envelope-from joy@urc.ac.ru) Received: from urc.ac.ru (y.RNOC-dialup.urc.ac.ru [193.233.85.127]) by rnocserv.urc.ac.ru (8.9.3/8.9.2) with ESMTP id MAA83329; Tue, 6 Jul 1999 12:12:28 +0600 (ESS) (envelope-from joy@urc.ac.ru) Message-ID: <37819E79.6E806AE5@urc.ac.ru> Date: Tue, 06 Jul 1999 12:13:14 +0600 From: Konstantin Chuguev Organization: Southern Ural Regional Center of FREEnet X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.1-STABLE i386) X-Accept-Language: ru, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Cc: Amancio Hasty , mtaylor@cybernet.com, freebsd-current@FreeBSD.ORG, Mark Wilcox Subject: SQLed FreeBSD [Was: Re: LDAPed FreeBSD] References: <199907051959.MAA27212@rah.star-gate.com> <378112E3.A1E8635@OpenLDAP.Org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Kurt D. Zeilenga" wrote: > This discussion is diverging a bit from this list's charter. Hence, > I'll be brief. > > Amancio Hasty wrote: > > True LDAP (v2 or v3) does not provide record locking . Now the question is > > does Novell's NDS 8 -- a native LDAP v3 -- , Oracle's Directory > > Server or Microsoft Active Directory does if they do then how ? > > Commonly through other directory (or database) access mechanisms. Or, What about using SQL: system services as SQL clients? SQL's advantages are locking, transactions, views, relative portability and extensibility. One can use MySQL server as a directory, another - Oracle or Postgres etc. Of course, there are some disadvantages (please, point out some...) > > possibly, though some private or experimental LDAPv3 control or extended > op they added to their client/servers (LDAPv3 is an extensible protocol). > > > Again my emphasis is on configuring network services or other system services > > if appropiate and to provide a HTML interface which is sufficiently rich to be > > user friendly. > OK. Then PHP comes to mind (again with SQL :-) -- Konstantin V. Chuguev. System administrator of Southern http://www.urc.ac.ru/~joy/ Ural Regional Center of FREEnet, mailto:joy@urc.ac.ru Chelyabinsk, Russia. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 23:18:13 1999 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 99B0014DB1 for ; Mon, 5 Jul 1999 23:18:11 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (iras-4-85.ucdavis.edu [169.237.17.213]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id XAA44820; Mon, 5 Jul 1999 23:18:09 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id GAA01254; Tue, 6 Jul 1999 06:18:06 GMT (envelope-from obrien) Date: Mon, 5 Jul 1999 23:18:05 -0700 From: "David O'Brien" To: Nicolas Blais Cc: freebsd-current@freebsd.org Subject: Re: HELP!!! -CURRENT libtool problem. Message-ID: <19990705231805.A1233@dragon.nuxi.com> Reply-To: obrien@NUXI.com References: <37810FDD.C1321FE7@videotron.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <37810FDD.C1321FE7@videotron.ca>; from Nicolas Blais on Mon, Jul 05, 1999 at 04:04:46PM -0400 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Also, before I removed 3.2 from my system, I made a little cpp hello > world program and with GCC the binary was 8k. That same program was > 40k with EGCS. Anyone know why? Look at the ``ldd'' output. libstdc++ is statically linked if you used the egcs port (which if you did this on 3.2 you must have). -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 23:31:53 1999 Delivered-To: freebsd-current@freebsd.org Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194]) by hub.freebsd.org (Postfix) with ESMTP id 4D53F14C0C for ; Mon, 5 Jul 1999 23:31:50 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.3/8.8.8) with ESMTP id XAA30176; Mon, 5 Jul 1999 23:30:54 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199907060630.XAA30176@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Konstantin Chuguev Cc: "Kurt D. Zeilenga" , mtaylor@cybernet.com, freebsd-current@FreeBSD.ORG, Mark Wilcox Subject: Re: SQLed FreeBSD [Was: Re: LDAPed FreeBSD] In-reply-to: Your message of "Tue, 06 Jul 1999 12:13:14 +0600." <37819E79.6E806AE5@urc.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Jul 1999 23:30:53 -0700 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Guys, Lets pick up this discussion on http://www.openldap.org and the mailing list : Tnks! -- Amancio Hasty ahasty@mindspring.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 5 23:38:15 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id D5B9C14C0C for ; Mon, 5 Jul 1999 23:38:08 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id CAA93970 for ; Tue, 6 Jul 1999 02:38:16 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 6 Jul 1999 02:38:16 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: current@FreeBSD.org Subject: Re: Strange CPU name reported on my k6-II system (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks. Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ ---------- Forwarded message ---------- Date: Tue, 06 Jul 1999 09:35:18 +0300 From: Maxim Sobolev To: Brian F. Feldman Subject: Re: Strange CPU name reported on my k6-II system You are probably forget to send this reply to current@freebsd.org -Maxim "Brian F. Feldman" wrote: > On Tue, 6 Jul 1999, Greg Lehey wrote: > > > On Monday, 5 July 1999 at 20:13:57 +0300, Maxim Sobolev wrote: > > > When I take a closer look at dmesg output I discovered that my k6-II > > > reported as "\^M". Maybe it is because I have an very first stepping (I > > > bought my CPU shortly after k6-II appeared on market). Maserboard used - > > > Tyan Trinity 100AT (VIA MP3 chipset). > > > > > > Any ideas? > > > > > > Timecounter "i8254" frequency 1193026 Hz > > > CPU: \^E (300.64-MHz 586-class CPU) > > > ^^^^^^^^ > > > Origin = "AuthenticAMD" Id = 0x580 Stepping=0 > > > Features=0x8001bf > > > AMD > > > Features=0x808009bf > > > Data TLB: 128 entries, 2-way associative > > > Instruction TLB: 64 entries, 1-way associative > > > L1 data cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative > > > L1 instruction cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way > > > associative > > > Write Allocate Enable Limit: 64M bytes > > > Write Allocate 15-16M bytes: Enable > > > > I believe green was doing some work in this area in the last day or > > two. > > Yes, I committed some K6-related things. See that AMD Features line? Closed > a PR while I was at it, since that was the commit. The code is pretty much > just how I would have done it, although MAYBE I'd move it into the default. > Anyway, here's the thing: this has been reported before. I need to know > if it's the same person. If not, then it seems Stepping 0 has this bug. > I don't know why the CPU is doing this, but I know what it's doing. AMDs > of a certain stepping and greater will name themselves. i.e. > CPU: AMD-K6(tm) 3D processor (350.81-MHz 586-class CPU) > That's my K6-2, a K6-(tm) 3D. Now, we're getting this from the CPU's registers > after a specific call. If I can find out a specific stepping of this CPU > exhibits this behavior, perhaps it's a bug that was fixed later on. Would > those of you with K6-2's that are either: > 1. Stepping=0 (Id = 0x580) > or > 2. Noticing strange CPU names > please contact me? > > > > > Greg > > -- > > See complete headers for address, home page and phone numbers > > finger grog@lemis.com for PGP public key > > > > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ > green@FreeBSD.org _ __ ___ | _ ) __| \ > FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | > http://www.FreeBSD.org/ _ |___/___/___/ -- "We believe in the Power and the Might!" (Manowar, 1996) ---------------------------------------- Maxim V. Sobolev, Financial Analyst, Vega International Capital Phone: +380-(44)-246-6396 Fax: +380-(44)-220-8715 E-mail: sobomax@altavista.net ICQ: #42290709 ---------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 6 0:46:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from ren.detir.qld.gov.au (ns.detir.qld.gov.au [203.46.81.66]) by hub.freebsd.org (Postfix) with ESMTP id BA1DE14C37 for ; Tue, 6 Jul 1999 00:46:46 -0700 (PDT) (envelope-from syssgm@detir.qld.gov.au) Received: by ren.detir.qld.gov.au; id RAA08638; Tue, 6 Jul 1999 17:45:50 +1000 (EST) Received: from ogre.detir.qld.gov.au(167.123.8.3) by ren.detir.qld.gov.au via smap (3.2) id xma008633; Tue, 6 Jul 99 17:45:30 +1000 Received: from atlas.detir.qld.gov.au (atlas.detir.qld.gov.au [167.123.8.9]) by ogre.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id RAA19257 for ; Tue, 6 Jul 1999 17:45:24 +1000 (EST) Received: from nymph.detir.qld.gov.au (nymph.detir.qld.gov.au [167.123.10.10]) by atlas.detir.qld.gov.au (8.8.5/8.8.5) with ESMTP id RAA19183 for ; Tue, 6 Jul 1999 17:45:12 +1000 (EST) Received: from nymph.detir.qld.gov.au (localhost.detir.qld.gov.au [127.0.0.1]) by nymph.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id RAA12161; Tue, 6 Jul 1999 17:45:11 +1000 (EST) (envelope-from syssgm@nymph.detir.qld.gov.au) Message-Id: <199907060745.RAA12161@nymph.detir.qld.gov.au> To: freebsd-current@freebsd.org Cc: syssgm@detir.qld.gov.au Subject: Re: Stuck in "objtrm" References: <199907021200.WAA06282@nymph.detir.qld.gov.au> In-Reply-To: <199907021200.WAA06282@nymph.detir.qld.gov.au> from Stephen McKay at "Fri, 02 Jul 1999 22:00:04 +1000" Date: Tue, 06 Jul 1999 17:45:11 +1000 From: Stephen McKay Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Friday, 2nd July 1999, Stephen McKay wrote: >I have an old 486 here that I thrash to death occasionally. Well, at least >I try to get it to page to death. I started a make world last week and >forgot about it. > >Today I noticed that it's been stuck for most of the week. Almost everything >is fine, but one cc1 process is stuck in "objtrm". Oh, and I hung a "cat >/proc/31624/map", too, trying to get some details (now stuck in "thrd_sleep"). > >So, am I just tripping over some old long-fixed bug? Or is this a new one >worth investigating? The kernel is from 1999/06/16 (just before the >vfs_cluster.c commit). Well, it's happened again, but this time it is a recent -current, less than a day old. After a couple hours of heavy paging (yes, this is a slow box), the make world hangs with cc1 in "objtrm". All the other processes seem to be waiting for it to exit. It's the only cc1 around, by the way, even though it was a -j5 parallel compile. All other machine functions are fine. ps, top, vmstat, et al show normal looking values. Does anybody have any hints on how to debug this? I know that "objtrm" implies that paging is in progress on some object, even though there's no paging happening, and so it's probably an accounting error with object->paging_in_progress. But other than that, I'm not sure where to look. Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 6 3:46:20 1999 Delivered-To: freebsd-current@freebsd.org Received: from ren.detir.qld.gov.au (ns.detir.qld.gov.au [203.46.81.66]) by hub.freebsd.org (Postfix) with ESMTP id A923514BCC for ; Tue, 6 Jul 1999 03:46:14 -0700 (PDT) (envelope-from syssgm@detir.qld.gov.au) Received: by ren.detir.qld.gov.au; id UAA14415; Tue, 6 Jul 1999 20:45:21 +1000 (EST) Received: from ogre.detir.qld.gov.au(167.123.8.3) by ren.detir.qld.gov.au via smap (3.2) id xma014401; Tue, 6 Jul 99 20:44:56 +1000 Received: from atlas.detir.qld.gov.au (atlas.detir.qld.gov.au [167.123.8.9]) by ogre.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id UAA21767 for ; Tue, 6 Jul 1999 20:44:24 +1000 (EST) Received: from nymph.detir.qld.gov.au (nymph.detir.qld.gov.au [167.123.10.10]) by atlas.detir.qld.gov.au (8.8.5/8.8.5) with ESMTP id UAA23345 for ; Tue, 6 Jul 1999 20:44:20 +1000 (EST) Received: from nymph.detir.qld.gov.au (localhost.detir.qld.gov.au [127.0.0.1]) by nymph.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id UAA14043; Tue, 6 Jul 1999 20:44:20 +1000 (EST) (envelope-from syssgm@nymph.detir.qld.gov.au) Message-Id: <199907061044.UAA14043@nymph.detir.qld.gov.au> To: freebsd-current@freebsd.org Cc: syssgm@detir.qld.gov.au Subject: Re: Stuck in "objtrm" References: <199907021200.WAA06282@nymph.detir.qld.gov.au> <199907060745.RAA12161@nymph.detir.qld.gov.au> In-Reply-To: <199907060745.RAA12161@nymph.detir.qld.gov.au> from Stephen McKay at "Tue, 06 Jul 1999 17:45:11 +1000" Date: Tue, 06 Jul 1999 20:44:19 +1000 From: Stephen McKay Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 6th July 1999, Stephen McKay wrote: >the make world hangs with cc1 in "objtrm"... I'm having a fun old conversation with myself here! ;-) Here's some concrete info: (kgdb) p/x *(struct vm_object*) 0xc32ea21c $13 = {object_list = {tqe_next = 0xc3389e58, tqe_prev = 0xc323fdec}, shadow_head = {tqh_first = 0x0, tqh_last = 0xc32ea224}, shadow_list = { tqe_next = 0xc327b8dc, tqe_prev = 0xc32cb734}, memq = { tqh_first = 0xc0308e80, tqh_last = 0xc03046ec}, generation = 0x3004, type = 0x1, size = 0x2a7, ref_count = 0x0, shadow_count = 0x0, pg_color = 0x5, hash_rand = 0xfd9a69d7, flags = 0x21c8, paging_in_progress = 0x1, behavior = 0x0, resident_page_count = 0x9, backing_object = 0x0, backing_object_offset = 0x0, last_read = 0x14, pager_object_list = {tqe_next = 0xc323c438, tqe_prev = 0xc323a424}, handle = 0x0, un_pager = {vnp = {vnp_size = 0x16}, devp = {devp_pglist = { tqh_first = 0x16, tqh_last = 0x0}}, swp = {swp_bcount = 0x16}}} The high points: ref_count=0 shadow_count=0 type=1 (OBJT_SWAP) paging_in_progress=1 resident_page_count=9 flags=0x21c8 (onemapping, mightbedirty, writeable, pipwnt, dead) A typical memory page from this object: (kgdb) p/x *(struct vm_page*) 0xc02ffd90 $14 = {pageq = {tqe_next = 0xc0317dc0, tqe_prev = 0xc02f1960}, hnext = 0x0, listq = {tqe_next = 0xc0317dc0, tqe_prev = 0xc02f196c}, object = 0xc32ea21c, pindex = 0x2f, phys_addr = 0x4f4000, queue = 0x41, flags = 0x0, pc = 0x34, wire_count = 0x0, hold_count = 0x0, act_count = 0x8, busy = 0x0, valid = 0xff, dirty = 0xff} The high points: queue=inactive flags=0 wire_count=0 hold_count=0 busy=0 valid=ff dirty=ff All 9 of them are like that. So, no busy or PG_BUSY or anything. No paging really in progress after all. So the object's paging_in_progress count is out. Who was watching what code changed recently? Remember I had this problem on a kernel from 1999/06/16 too. So it's an "old" problem. Off to research the next installment... Stephen. PS I haven't worked out yet how to find the stack of the errant process. Any hints? The stack trace should be helpful. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 6 3:56:52 1999 Delivered-To: freebsd-current@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 2806815405 for ; Tue, 6 Jul 1999 03:56:42 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id DAA11064; Tue, 6 Jul 1999 03:56:07 -0700 (PDT) Message-Id: <199907061056.DAA11064@implode.root.com> To: Stephen McKay Cc: freebsd-current@FreeBSD.ORG Subject: Re: Stuck in "objtrm" In-reply-to: Your message of "Tue, 06 Jul 1999 20:44:19 +1000." <199907061044.UAA14043@nymph.detir.qld.gov.au> From: David Greenman Reply-To: dg@root.com Date: Tue, 06 Jul 1999 03:56:07 -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You'll want to look primarily in the swap_pager code since it messes with that (at least it used to - I don't recall what Matt's new code does with it). There should be various calls to vm_object_pip_* that manipulate the paging_in_progress number. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com >On Tuesday, 6th July 1999, Stephen McKay wrote: > >>the make world hangs with cc1 in "objtrm"... > >I'm having a fun old conversation with myself here! ;-) > >Here's some concrete info: > >(kgdb) p/x *(struct vm_object*) 0xc32ea21c >$13 = {object_list = {tqe_next = 0xc3389e58, tqe_prev = 0xc323fdec}, > shadow_head = {tqh_first = 0x0, tqh_last = 0xc32ea224}, shadow_list = { > tqe_next = 0xc327b8dc, tqe_prev = 0xc32cb734}, memq = { > tqh_first = 0xc0308e80, tqh_last = 0xc03046ec}, generation = 0x3004, > type = 0x1, size = 0x2a7, ref_count = 0x0, shadow_count = 0x0, > pg_color = 0x5, hash_rand = 0xfd9a69d7, flags = 0x21c8, > paging_in_progress = 0x1, behavior = 0x0, resident_page_count = 0x9, > backing_object = 0x0, backing_object_offset = 0x0, last_read = 0x14, > pager_object_list = {tqe_next = 0xc323c438, tqe_prev = 0xc323a424}, > handle = 0x0, un_pager = {vnp = {vnp_size = 0x16}, devp = {devp_pglist = { > tqh_first = 0x16, tqh_last = 0x0}}, swp = {swp_bcount = 0x16}}} > >The high points: > ref_count=0 > shadow_count=0 > type=1 (OBJT_SWAP) > paging_in_progress=1 > resident_page_count=9 > flags=0x21c8 (onemapping, mightbedirty, writeable, pipwnt, dead) > >A typical memory page from this object: > >(kgdb) p/x *(struct vm_page*) 0xc02ffd90 >$14 = {pageq = {tqe_next = 0xc0317dc0, tqe_prev = 0xc02f1960}, hnext = 0x0, > listq = {tqe_next = 0xc0317dc0, tqe_prev = 0xc02f196c}, object = 0xc32ea21c, > pindex = 0x2f, phys_addr = 0x4f4000, queue = 0x41, flags = 0x0, pc = 0x34, > wire_count = 0x0, hold_count = 0x0, act_count = 0x8, busy = 0x0, > valid = 0xff, dirty = 0xff} > >The high points: > queue=inactive > flags=0 > wire_count=0 > hold_count=0 > busy=0 > valid=ff > dirty=ff > >All 9 of them are like that. So, no busy or PG_BUSY or anything. No paging >really in progress after all. So the object's paging_in_progress count is >out. > >Who was watching what code changed recently? Remember I had this problem >on a kernel from 1999/06/16 too. So it's an "old" problem. > >Off to research the next installment... > >Stephen. > >PS I haven't worked out yet how to find the stack of the errant process. >Any hints? The stack trace should be helpful. > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 6 4:55:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from shale.csir.co.za (shale.csir.co.za [146.64.46.5]) by hub.freebsd.org (Postfix) with ESMTP id AABC9153A0 for ; Tue, 6 Jul 1999 04:55:10 -0700 (PDT) (envelope-from reg@shale.csir.co.za) Received: (from reg@localhost) by shale.csir.co.za (8.9.3/8.9.3) id NAA37138; Tue, 6 Jul 1999 13:54:31 +0200 (SAT) (envelope-from reg) Date: Tue, 6 Jul 1999 13:54:30 +0200 From: Jeremy Lea To: Nicolas Blais Cc: freebsd-current@FreeBSD.ORG Subject: Re: HELP!!! -CURRENT libtool problem. Message-ID: <19990706135429.A37112@shale.csir.co.za> References: <37810FDD.C1321FE7@videotron.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <37810FDD.C1321FE7@videotron.ca>; from Nicolas Blais on Mon, Jul 05, 1999 at 04:04:46PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, On Mon, Jul 05, 1999 at 04:04:46PM -0400, Nicolas Blais wrote: > Hi. I've finally installed FreeBSD 4.0 and to tell you the truth, I'm > not very impressed. I was expecting some bugs but not like that... Not the best way to start a message if you want to get responses. Also, the wrapping on your e-mail editor is broken. > Most of my stuff compiles great with EGCS except all my shared libraries > that uses libtool like jpeglib and giflib. > They both use libtool which for some odd reason was not installed on my > system. If you had actually provided some useful information then maybe the problem could be determined, but I'd guess that your system is broken... The ports all work (although there is a problem for old libtool installations - which you don't have), and libtool will be installed by ports which need it. The same ports work on both -STABLE and -CURRENT, so I'd also guess that you messed up during the upgrade. Maybe an old bsd.port.mk somewhere? I also assume that if you fetched the package, then you are building from ports? If not, then don't fetch the package, go fetch libtool from a GNU mirror and build it manually (and do whatever patching is needed for 4.0). If you're not using ports, then you'll get even less help than if you have a problem with -CURRENT. > Please help. I'm really desperate. Stick with -STABLE and packages. -Jeremy -- | "In this world of temptation, I will stand for what is right. --+-- With a heart of salvation, I will hold up the light. | If I live or if I die, if I laugh or if I cry, | in this world of temptation, I will stand." -Pam Thum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 6 7:28:44 1999 Delivered-To: freebsd-current@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id F02C014C83 for ; Tue, 6 Jul 1999 07:28:40 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id KAA14259; Tue, 6 Jul 1999 10:28:34 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id KAA77387; Tue, 6 Jul 1999 10:28:34 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 6 Jul 1999 10:28:33 -0400 (EDT) To: Stephen McKay Cc: freebsd-current@freebsd.org, alc@cs.rice.edu, dillon@apollo.backplane.com Subject: Re: Stuck in "objtrm" In-Reply-To: <199907061044.UAA14043@nymph.detir.qld.gov.au> References: <199907021200.WAA06282@nymph.detir.qld.gov.au> <199907060745.RAA12161@nymph.detir.qld.gov.au> <199907061044.UAA14043@nymph.detir.qld.gov.au> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14210.4262.296904.751060@grasshopper.cs.duke.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've occasionally seen systems wedged in a similar state. I reported my sighting of this on May 24th. Haven't seen it since. The one bit of useful info I've learned since my report was that from a talk with the program's author, I suspect the object in question may have been created with mmap(MAP_ANON,...). I'm not sure if cc1 also does this, but that may be some common ground.. Stephen McKay writes: > > The high points: > ref_count=0 > shadow_count=0 > type=1 (OBJT_SWAP) > paging_in_progress=1 > resident_page_count=9 > flags=0x21c8 (onemapping, mightbedirty, writeable, pipwnt, dead) > <...> Similar to mine: $5 = { object_list = { tqe_next = 0xca234244, tqe_prev = 0xca2ee488 }, shadow_head = { tqh_first = 0x0, tqh_last = 0xca1e7a00 }, shadow_list = { tqe_next = 0x0, tqe_prev = 0xca29c24c }, memq = { tqh_first = 0xc04ff370, tqh_last = 0xc04e65fc }, generation = 26962387, type = OBJT_SWAP, size = 165, ref_count = 0, shadow_count = 0, pg_color = 60, hash_rand = -71709939, flags = 8652, paging_in_progress = 1, behavior = 0, resident_page_count = 51, cache_count = 0, wire_count = 0, backing_object = 0x0, backing_object_offset = 0, last_read = 63, pager_object_list = { tqe_next = 0xca234244, tqe_prev = 0xca175970 }, handle = 0x0, un_pager = { vnp = { vnp_size = 5 }, devp = { devp_pglist = { tqh_first = 0x5, tqh_last = 0x0 } }, swp = { swp_bcount = 5 } } } > > Who was watching what code changed recently? Remember I had this problem > on a kernel from 1999/06/16 too. So it's an "old" problem. > > Off to research the next installment... > > Stephen. > > PS I haven't worked out yet how to find the stack of the errant process. > Any hints? The stack trace should be helpful. Yes. say 'proc pidhashtbl[PID & pidhash]->lh_first' in kgdb. I suspect that it will be in exit() also.. (kgdb) proc pidhashtbl[22207 & pidhash]->lh_first (kgdb) bt #0 mi_switch () at ../../kern/kern_synch.c:827 #1 0xc0152cd9 in tsleep (ident=0xca1e79f8, priority=4, wmesg=0xc024bbca "objtrm", timo=0) at ../../kern/kern_synch.c:443 #2 0xc01f6249 in vm_object_terminate (object=0xca1e79f8) at ../../vm/vm_object.h:235 #3 0xc01f61f9 in vm_object_deallocate (object=0xca1e79f8) at ../../vm/vm_object.c:384 #4 0xc01f3ae7 in vm_map_entry_delete (map=0xca1c0380, entry=0xca2b65f0) at ../../vm/vm_map.c:1887 #5 0xc01f3ca5 in vm_map_delete (map=0xca1c0380, start=0, end=3217022976) at ../../vm/vm_map.c:1990 #6 0xc01f3d29 in vm_map_remove (map=0xca1c0380, start=0, end=3217022976) at ../../vm/vm_map.c:2015 #7 0xc014a615 in exit1 (p=0xca2465a0, rv=0) at ../../kern/kern_exit.c:223 #8 0xc014a434 in exit1 (p=0xca2465a0, rv=-904133760) at ../../kern/kern_exit.c:106 #9 0xc0210dd6 in syscall (frame={tf_fs = 135004207, tf_es = 1209466927, tf_ds = -1078001617, tf_edi = 0, tf_esi = -1, tf_ebp = -1077947172, tf_isp = -903335964, tf_ebx = 1209464980, tf_edx = 0, tf_ecx = 0, tf_eax = 1, tf_trapno = 7, tf_err = 2, tf_eip = 1209204908, tf_cs = 31, tf_eflags = 582, tf_esp = -1077947196, tf_ss = 47}) at ../../i386/i386/trap.c:1069 #10 0xc0206aa0 in Xint0x80_syscall () Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 6 7:29:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from majordomo2.umd.edu (majordomo2.umd.edu [128.8.10.7]) by hub.freebsd.org (Postfix) with ESMTP id F351715436 for ; Tue, 6 Jul 1999 07:29:25 -0700 (PDT) (envelope-from culverk@wam.umd.edu) Received: from rac1.wam.umd.edu (root@rac1.wam.umd.edu [128.8.10.141]) by majordomo2.umd.edu (8.9.3/8.9.3) with ESMTP id KAA09731; Tue, 6 Jul 1999 10:29:18 -0400 (EDT) Received: from rac1.wam.umd.edu (sendmail@localhost [127.0.0.1]) by rac1.wam.umd.edu (8.9.3/8.9.3) with SMTP id KAA22913; Tue, 6 Jul 1999 10:29:18 -0400 (EDT) Received: from localhost by rac1.wam.umd.edu (8.9.3/8.9.3) with ESMTP id KAA22909; Tue, 6 Jul 1999 10:29:17 -0400 (EDT) X-Authentication-Warning: rac1.wam.umd.edu: culverk owned process doing -bs Date: Tue, 6 Jul 1999 10:29:17 -0400 (EDT) From: Kenneth Wayne Culver To: Bill Fumerola Cc: freebsd-current@freebsd.org Subject: Re: cvs commit: src/sys/i386/linux linux_misc.c In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Speaking of which, I'm also of the opinion that we should add a "Do > > you want to run Linux binaries?" query to sysinstall which results in > > linux emulation being enabled by default and the linux_lib package > > being loaded. This would make it even more transparent to the > > user. Any objections? > > Speaking as one who experiences excess stupidity of people who don't read > the FAQ on #FreeBSD, I can only say "hell yes, add that.". > > I gladly third that one.... I'm tired of answering "Linux emulation problems" questions on the questions list... Kenneth Culver To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 6 8:38:37 1999 Delivered-To: freebsd-current@freebsd.org Received: from lox2.loxinfo.co.th (lox2.loxinfo.co.th [203.146.30.20]) by hub.freebsd.org (Postfix) with ESMTP id A6DF815414 for ; Tue, 6 Jul 1999 08:38:34 -0700 (PDT) (envelope-from system@hottransactions.com) Received: from tobi (loxppp70-usr.suapha.loxinfo.net [203.146.13.70]) by lox2.loxinfo.co.th (8.8.8/) with SMTP id XAA16133 for ; Tue, 6 Jul 1999 23:39:52 +0700 Date: Tue, 6 Jul 1999 23:39:52 +0700 From: system@hottransactions.com To: freebsd-current@freebsd.org Subject: FREE Placement for http://freebsd.rrze.uni-erlangen.de/news/newsflash.html Organization: Hottransactions Ltd. Message-Id: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear Furniture Website Owner We have found your Site The FreeBSD Project through the GoTo searchengine. Here is our free offer: We are a new and exiting shopping mall. We offer you to take advantage of our system and place all your products located at: http://freebsd.rrze.uni-erlangen.de/news/newsflash.html into our shopping mall for FREE. Yes, no obligations, it is totally free. No hassle to deal with us. Just hit the reply button to contact our management directly Best Regards The Management Hottransactions Ltd. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 6 9:29:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 3614315421 for ; Tue, 6 Jul 1999 09:29:29 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 111Y63-000419-00 for freebsd-current@FreeBSD.ORG; Tue, 06 Jul 1999 18:29:27 +0200 From: Sheldon Hearn To: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/linux linux_misc.c Date: Tue, 06 Jul 1999 18:29:27 +0200 Message-ID: <15446.931278567@axl.noc.iafrica.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think you folks are in for a big surprise if you think that the proposed rtfm(1) tool will save you any heartache. Most of the times that people come to you for help, it's because they lack one or more of the time and inclination to help themselves. The proposed tool's inappropriate name reinforces that it will serve as nothing more than a BOFH plushie. Know that this has _not_ been met with unanimous acceptance. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 6 10: 8:52 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id 21BA014ECC for ; Tue, 6 Jul 1999 10:08:50 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id KAA05075; Tue, 6 Jul 1999 10:08:48 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Tue, 6 Jul 1999 10:08:48 -0700 (PDT) From: Doug X-Sender: doug@dt054n86.san.rr.com To: "Jordan K. Hubbard" Cc: freebsd-current@FreeBSD.ORG Subject: Re: HELP!!! -CURRENT libtool problem. In-Reply-To: <66021.931207359@zippy.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 5 Jul 1999, Jordan K. Hubbard wrote: > I'm also sure this response will probably scare a few people off and > garner stern rebukes from the newbie hand-holding folks, As one of the "newbie hand-holding folks" I would say that the kindest thing you can do for a new user who's wandered into -current is to slap their hand and send them back to mommy. :) > I also make this point now and with such force because various signs > and portents indicate that -current is about to become a dangerous > place again for awhile, Woo hoo... I love a parade. Happy with my appropriately sized cojones, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 6 10:59:35 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 11E3E14DDD for ; Tue, 6 Jul 1999 10:59:27 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id NAA05185; Tue, 6 Jul 1999 13:59:06 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 6 Jul 1999 13:59:06 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Andrew Gallatin Cc: Stephen McKay , freebsd-current@FreeBSD.org, alc@cs.rice.edu, dillon@apollo.backplane.com Subject: Re: Stuck in "objtrm" In-Reply-To: <14210.4262.296904.751060@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 6 Jul 1999, Andrew Gallatin wrote: > > > I've occasionally seen systems wedged in a similar state. I reported > my sighting of this on May 24th. Haven't seen it since. > > The one bit of useful info I've learned since my report was that from > a talk with the program's author, I suspect the object in question may > have been created with mmap(MAP_ANON,...). I'm not sure if cc1 also > does this, but that may be some common ground.. For what it's worth, our RTLD and malloc() both use mmap(,,,MAP_ANON,,);. > > > Stephen McKay writes: > > > > The high points: > > ref_count=0 > > shadow_count=0 > > type=1 (OBJT_SWAP) > > paging_in_progress=1 > > resident_page_count=9 > > flags=0x21c8 (onemapping, mightbedirty, writeable, pipwnt, dead) > > > > <...> > > Similar to mine: > > $5 = { > object_list = { > tqe_next = 0xca234244, > tqe_prev = 0xca2ee488 > }, > shadow_head = { > tqh_first = 0x0, > tqh_last = 0xca1e7a00 > }, > shadow_list = { > tqe_next = 0x0, > tqe_prev = 0xca29c24c > }, > memq = { > tqh_first = 0xc04ff370, > tqh_last = 0xc04e65fc > }, > generation = 26962387, > type = OBJT_SWAP, > size = 165, > ref_count = 0, > shadow_count = 0, > pg_color = 60, > hash_rand = -71709939, > flags = 8652, > paging_in_progress = 1, > behavior = 0, > resident_page_count = 51, > cache_count = 0, > wire_count = 0, > backing_object = 0x0, > backing_object_offset = 0, > last_read = 63, > pager_object_list = { > tqe_next = 0xca234244, > tqe_prev = 0xca175970 > }, > handle = 0x0, > un_pager = { > vnp = { > vnp_size = 5 > }, > devp = { > devp_pglist = { > tqh_first = 0x5, > tqh_last = 0x0 > } > }, > swp = { > swp_bcount = 5 > } > } > } > > > > > > Who was watching what code changed recently? Remember I had this problem > > on a kernel from 1999/06/16 too. So it's an "old" problem. > > > > Off to research the next installment... > > > > Stephen. > > > > PS I haven't worked out yet how to find the stack of the errant process. > > Any hints? The stack trace should be helpful. > > Yes. say 'proc pidhashtbl[PID & pidhash]->lh_first' in kgdb. > I suspect that it will be in exit() also.. > > > (kgdb) proc pidhashtbl[22207 & pidhash]->lh_first > (kgdb) bt > #0 mi_switch () at ../../kern/kern_synch.c:827 > #1 0xc0152cd9 in tsleep (ident=0xca1e79f8, priority=4, > wmesg=0xc024bbca "objtrm", timo=0) at ../../kern/kern_synch.c:443 > #2 0xc01f6249 in vm_object_terminate (object=0xca1e79f8) > at ../../vm/vm_object.h:235 > #3 0xc01f61f9 in vm_object_deallocate (object=0xca1e79f8) > at ../../vm/vm_object.c:384 > #4 0xc01f3ae7 in vm_map_entry_delete (map=0xca1c0380, entry=0xca2b65f0) > at ../../vm/vm_map.c:1887 > #5 0xc01f3ca5 in vm_map_delete (map=0xca1c0380, start=0, end=3217022976) > at ../../vm/vm_map.c:1990 > #6 0xc01f3d29 in vm_map_remove (map=0xca1c0380, start=0, end=3217022976) > at ../../vm/vm_map.c:2015 > #7 0xc014a615 in exit1 (p=0xca2465a0, rv=0) at ../../kern/kern_exit.c:223 > #8 0xc014a434 in exit1 (p=0xca2465a0, rv=-904133760) > at ../../kern/kern_exit.c:106 > #9 0xc0210dd6 in syscall (frame={tf_fs = 135004207, tf_es = 1209466927, > tf_ds = -1078001617, tf_edi = 0, tf_esi = -1, tf_ebp = -1077947172, > tf_isp = -903335964, tf_ebx = 1209464980, tf_edx = 0, tf_ecx = 0, > tf_eax = 1, tf_trapno = 7, tf_err = 2, tf_eip = 1209204908, tf_cs = 31, > tf_eflags = 582, tf_esp = -1077947196, tf_ss = 47}) > at ../../i386/i386/trap.c:1069 > #10 0xc0206aa0 in Xint0x80_syscall () > > > Drew > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 6 15: 4:28 1999 Delivered-To: freebsd-current@freebsd.org Received: from peedub.muc.de (newpc.muc.ditec.de [194.120.126.33]) by hub.freebsd.org (Postfix) with ESMTP id A4BE7153DF for ; Tue, 6 Jul 1999 15:04:21 -0700 (PDT) (envelope-from garyj@peedub.muc.de) Received: from peedub.muc.de (localhost [127.0.0.1]) by peedub.muc.de (8.9.3/8.6.9) with ESMTP id XAA00862 for ; Tue, 6 Jul 1999 23:47:44 +0200 (CEST) Message-Id: <199907062147.XAA00862@peedub.muc.de> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-current@FreeBSD.ORG Subject: Re: Stuck in "objtrm" Reply-To: Gary Jennejohn In-reply-to: Your message of "Tue, 06 Jul 1999 10:28:33 EDT." <14210.4262.296904.751060@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Jul 1999 23:47:44 +0200 From: Gary Jennejohn Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Andrew Gallatin writes: >Stephen McKay writes: > > PS I haven't worked out yet how to find the stack of the errant process. > > Any hints? The stack trace should be helpful. > >Yes. say 'proc pidhashtbl[PID & pidhash]->lh_first' in kgdb. > it should also work to do ``ps -M -N '' and pick out the pid of the process, then `proc ' in kgdb. I think that still works in the ELF world. --- Gary Jennejohn Home - garyj@muc.de Work - garyj@fkr.dec.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 6 22: 2:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id D643D14CA4 for ; Tue, 6 Jul 1999 22:02:21 -0700 (PDT) (envelope-from imp@harmony.village.org) 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 XAA24244 for ; Tue, 6 Jul 1999 23:02:20 -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 XAA67516 for ; Tue, 6 Jul 1999 23:00:49 -0600 (MDT) Message-Id: <199907070500.XAA67516@harmony.village.org> To: current@freebsd.org Subject: How to cross build Date: Tue, 06 Jul 1999 23:00:48 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OK. Per many requests from the community, I've committed my cross compilation changes. To build you just say make buildworld TARGET=hpcmips TARGET_ARCH=mipsel or make buildworld TARGET=m68k TARGET_ARCH=m68k Right now you must specify both TARGET and TARGET_ARCH. You will want to do this with a clean /usr/obj. Please send comments to me. The one time I tried it, I was unable to build alpha binaries on i386 due to bugs in the gnu tools. That was before egcs, however. Building i386 binaries on the alpha may work, but I don't have access to my Alpha lately to try. This is a work in progress. Since I've been using this on MIPS, whose kernel includes aren't yet complete enough for make world, I don't know if it will work completely or not. The goal is to have a buildworld complete and then do an installworld in the native environment, or with a DESTDIR=xxxx to put the files in, say, an NFS mounted root partition. I did try to make this work with by redefining BINFORMAT, but I found too many problems with doing this because cc1 isn't dependent on BINFORMAT. It was easier to build explicit cross tools to make this happen. I've been using the cross binaries for a variety of purposes, so I have good confidence in at least that part of the commit. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 6 22:14:45 1999 Delivered-To: freebsd-current@freebsd.org Received: from zippy.dyn.ml.org (pm3-46.ppp.wenet.net [206.15.85.46]) by hub.freebsd.org (Postfix) with ESMTP id 40C7514CA4 for ; Tue, 6 Jul 1999 22:14:41 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.9.3/8.9.1) with ESMTP id WAA25401 for ; Tue, 6 Jul 1999 22:14:12 -0700 (PDT) (envelope-from garbanzo@hooked.net) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Tue, 6 Jul 1999 22:14:12 -0700 (PDT) From: Alex Zepeda To: current Subject: buildworld dies in kdump.. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've been seeing this for a while now, even with sources CVSup'd recently. I've run make clean, and make cleandir many many times, yet if I run make buildworld, I see this: ===> usr.bin/kdump cc -nostdinc -O -pipe -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/kdump/kdump.c /bin/sh /usr/src/usr.bin/kdump/mkioctls > ioctl.c In file included from :54: /usr/obj/usr/src/tmp/usr/include/sys/memrange.h:16: warning: `MDF_ACTIVE' redefined /usr/obj/usr/src/tmp/usr/include/pccard/cardinfo.h:77: warning: this is the location of the previous definition cc -nostdinc -O -pipe -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/tmp/usr/include -c ioctl.c In file included from ioctl.c:82: /usr/obj/usr/src/tmp/usr/include/sys/memrange.h:16: warning: `MDF_ACTIVE' redefined /usr/obj/usr/src/tmp/usr/include/pccard/cardinfo.h:77: warning: this is the location of the previous definition In file included from ioctl.c:60: /usr/obj/usr/src/tmp/usr/include/netinet/altq_afmap.h:39: field `af_flowinfo' has incomplete type *** Error code 1 Stop. - alex I thought felt your touch In my car, on my clutch But I guess it's just someone who felt a lot like I remember you. - Translator To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 6 22:18:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from ren.detir.qld.gov.au (ns.detir.qld.gov.au [203.46.81.66]) by hub.freebsd.org (Postfix) with ESMTP id 0217414D5A for ; Tue, 6 Jul 1999 22:18:35 -0700 (PDT) (envelope-from syssgm@detir.qld.gov.au) Received: by ren.detir.qld.gov.au; id PAA15112; Wed, 7 Jul 1999 15:12:26 +1000 (EST) Received: from ogre.detir.qld.gov.au(167.123.8.3) by ren.detir.qld.gov.au via smap (3.2) id xmab15058; Wed, 7 Jul 99 15:11:57 +1000 Received: from atlas.detir.qld.gov.au (atlas.detir.qld.gov.au [167.123.8.9]) by ogre.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id NAA26940; Wed, 7 Jul 1999 13:49:53 +1000 (EST) Received: from nymph.detir.qld.gov.au (nymph.detir.qld.gov.au [167.123.10.10]) by atlas.detir.qld.gov.au (8.8.5/8.8.5) with ESMTP id NAA10832; Wed, 7 Jul 1999 13:49:52 +1000 (EST) Received: from nymph.detir.qld.gov.au (localhost.detir.qld.gov.au [127.0.0.1]) by nymph.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id NAA13375; Wed, 7 Jul 1999 13:49:52 +1000 (EST) (envelope-from syssgm@nymph.detir.qld.gov.au) Message-Id: <199907070349.NAA13375@nymph.detir.qld.gov.au> To: Andrew Gallatin Cc: Stephen McKay , freebsd-current@freebsd.org, alc@cs.rice.edu, dillon@apollo.backplane.com Subject: Re: Stuck in "objtrm" References: <199907021200.WAA06282@nymph.detir.qld.gov.au> <199907060745.RAA12161@nymph.detir.qld.gov.au> <199907061044.UAA14043@nymph.detir.qld.gov.au> <14210.4262.296904.751060@grasshopper.cs.duke.edu> In-Reply-To: <14210.4262.296904.751060@grasshopper.cs.duke.edu> from Andrew Gallatin at "Tue, 06 Jul 1999 10:28:33 -0400" Date: Wed, 07 Jul 1999 13:49:51 +1000 From: Stephen McKay Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 6th July 1999, Andrew Gallatin wrote: >Yes. say 'proc pidhashtbl[PID & pidhash]->lh_first' in kgdb. >I suspect that it will be in exit() also.. Magic! It looks like a plain old exit() to me. (kgdb) proc pidhashtbl[27157&pidhash]->lh_first (kgdb) bt #0 mi_switch () at ../../kern/kern_synch.c:827 #1 0xc014a5bd in tsleep (ident=0xc32ea21c, priority=4, wmesg=0xc023db84 "objtrm", timo=0) at ../../kern/kern_synch.c:443 #2 0xc01e9741 in vm_object_terminate (object=0xc32ea21c) at ../../vm/vm_object.h:230 #3 0xc01e96f1 in vm_object_deallocate (object=0xc32ea21c) at ../../vm/vm_object.c:382 #4 0xc01e6acb in vm_map_entry_delete (map=0xc3047440, entry=0xc3240190) at ../../vm/vm_map.c:1680 #5 0xc01e6c89 in vm_map_delete (map=0xc3047440, start=0, end=3217022976) at ../../vm/vm_map.c:1783 #6 0xc01e6d1d in vm_map_remove (map=0xc3047440, start=0, end=3217022976) at ../../vm/vm_map.c:1808 #7 0xc0141d20 in exit1 (p=0xc322f0a0, rv=0) at ../../kern/kern_exit.c:220 #8 0xc0141b24 in exit1 (p=0xc322f0a0, rv=-1021614488) at ../../kern/kern_exit.c:106 #9 0xc020e41a in syscall (frame={tf_fs = 47, tf_es = 137297967, tf_ds = -1078001617, tf_edi = 136021320, tf_esi = 0, tf_ebp = -1077947348, tf_isp = -1020915756, tf_ebx = -1, tf_edx = 135690384, tf_ecx = 136200192, tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = 135656524, tf_cs = 31, tf_eflags = 582, tf_esp = -1077947368, tf_ss = 47}) at ../../i386/i386/trap.c:1056 #10 0xc0202cc0 in Xint0x80_syscall () error reading /proc/27157/mem To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 6 22:36:10 1999 Delivered-To: freebsd-current@freebsd.org Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (Postfix) with ESMTP id 8CA621511C for ; Tue, 6 Jul 1999 22:36:03 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.3/8.9.1) id PAA49736; Wed, 7 Jul 1999 15:37:46 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199907070537.PAA49736@cimlogic.com.au> Subject: Re: How to cross build In-Reply-To: <199907070500.XAA67516@harmony.village.org> from Warner Losh at "Jul 6, 1999 11:00:48 pm" To: imp@village.org (Warner Losh) Date: Wed, 7 Jul 1999 15:37:45 +1000 (EST) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > OK. Per many requests from the community, I've committed my cross > compilation changes. Thanks. > To build you just say > make buildworld TARGET=hpcmips TARGET_ARCH=mipsel > or > make buildworld TARGET=m68k TARGET_ARCH=m68k > Right now you must specify both TARGET and TARGET_ARCH. You will want > to do this with a clean /usr/obj. Please send comments to me. > > The one time I tried it, I was unable to build alpha binaries on i386 > due to bugs in the gnu tools. That was before egcs, however. > Building i386 binaries on the alpha may work, but I don't have access > to my Alpha lately to try. binutils on i386 won't build 64-bit stuff due to bit shift code that wants to shift more than 32 bits. At runtime the code strikes asserts due to BFD64 not being defined at compile time. The sources hint at using "long long" if using gcc, but it appears to require some hacking. There is a Cygnus doc for configuring gcc 2.8.1 as a cross compiler which says that building 32-bit code on a 64-bit machine doesn't quite work. egcs might work though. > This is a work in progress. Since I've been using this on MIPS, whose > kernel includes aren't yet complete enough for make world, I don't > know if it will work completely or not. The goal is to have a > buildworld complete and then do an installworld in the native > environment, or with a DESTDIR=xxxx to put the files in, say, an NFS > mounted root partition. > > I did try to make this work with by redefining BINFORMAT, but I found > too many problems with doing this because cc1 isn't dependent on > BINFORMAT. It was easier to build explicit cross tools to make this > happen. I was aiming to build a set of cross tools as (an optional) part of the i386 build like binutils. When building the cross-compiler, defining CROSS_COMPILE and setting the execution path will avoid the native compiler. Then in the mk files, set CC etc to be the cross compiler based on the TARGET definition. The current install directory for the extra gas versions should change to be the execution path that egcs is configured for. I agree that BINFORMAT is inadequate. Since ld can be shared between target formats, I guess a link to the host ld is all that is required. We can't rely on the setting of MACHINE_ARCH to twiddle the different egcs build because that is a host setting, not a target one. We need to set aside different directories and build the egcs code as many times as the targets we want (like we do for gas). I've been using /usr/libexec/${TARGET} where TARGET is a name quite close to that which binutils knows. Using the environment variable "TARGET" is a little problematic for me because it is easily confused (at least by my brain 8-) with .TARGET. > I've been using the cross binaries for a variety of purposes, so I > have good confidence in at least that part of the commit. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 6 23:22:56 1999 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id CBCEC14CB4 for ; Tue, 6 Jul 1999 23:22:52 -0700 (PDT) (envelope-from imp@harmony.village.org) 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 AAA24384; Wed, 7 Jul 1999 00:22:49 -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 AAA67977; Wed, 7 Jul 1999 00:21:19 -0600 (MDT) Message-Id: <199907070621.AAA67977@harmony.village.org> To: John Birrell Subject: Re: How to cross build Cc: current@FreeBSD.ORG In-reply-to: Your message of "Wed, 07 Jul 1999 15:37:45 +1000." <199907070537.PAA49736@cimlogic.com.au> References: <199907070537.PAA49736@cimlogic.com.au> Date: Wed, 07 Jul 1999 00:21:19 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199907070537.PAA49736@cimlogic.com.au> John Birrell writes: : I was aiming to build a set of cross tools as (an optional) part of the : i386 build like binutils. When building the cross-compiler, defining : CROSS_COMPILE and setting the execution path will avoid the native : compiler. Then in the mk files, set CC etc to be the cross compiler : based on the TARGET definition. The current install directory for the : extra gas versions should change to be the execution path that egcs is : configured for. I agree that BINFORMAT is inadequate. Since ld can be : shared between target formats, I guess a link to the host ld is all : that is required. That might be better, but it still has problems that I wasn't up to solving just yet. You need more than just as, ld and cc1 to successfully build the world. You will also need make, strip, install and likely a few others as well that are slipping my mind. You will also need different include files and different libraries (since the machine link will be wrong in /usr/include, for example) if you are building anything outside of the kernel. : We can't rely on the setting of MACHINE_ARCH to twiddle the different : egcs build because that is a host setting, not a target one. That's why I build a make with MACHINE_ARCH set to TARGET_ARCH so that those assumptions in the tree work. It seemed easier to have to fix all the places in the tree that weren't quite up to building cross tools, and it appears to work in practice. Once that make is running, it will report the correct MACHINE_ARCH for the target environment so binutils and egcs work without major changes for the cross compilation case (the minor changes I think are already in the tree). : We need : to set aside different directories and build the egcs code as many times : as the targets we want (like we do for gas). You'll need to do this for all binutils as well. I've also found that I've needed to build make as well as libraries and include files to have things work right. There may be others (install which uses the other programs was a problem when I was working on the OpenBSD cross build proceedure a while ago). : I've been using : /usr/libexec/${TARGET} where TARGET is a name quite close to that which : binutils knows. That would preclude us from porting to an architecture named "ftpd" or any other program that is in /usr/libexec. I think you want to put a /arch/ before the ${TARGET}, if you go down this path... : Using the environment variable "TARGET" is a little : problematic for me because it is easily confused (at least by my : brain 8-) with .TARGET. It never even dawned on me that this would be confused, to be honest. OpenBSD, at least, uses TARGET and TARGET_ARCH, but has a different way of setting them up than is in what I checked in. Also, I think that your notion of running make world INCLUDE_THESE_OTHER_TARGETS="mips m68k" and then building the world (somehow) with these cross tools differs from my world view. In my world view (which may be wrong, but was what I arrived at after many false starts down other paths), one would build the entire system with make buildworld. I do see the utility in being able to do it other ways. But it would require more than just programs to make it work. I suspect that /usr/libexec/${TARGET} will prove to be too limited to work in practice, especially for an entire buildworld (although I can see how it could be made to work for kernel builds). I think we'd need to have a /usr/cross/${TARGET}-${TARGET_ARCH}/ tree where the libraries needed for linking, the include files that are specific to each port, etc live. Then one could just set one's path to have /usr/cross/${TARGET}-${TARGET_ARCH}/bin in your path and then make from there anything you'd like. That would also allow us to have as many different binaries as we need to build the world and we'd be decoupled from any hacks to make binutils work. While this approach would work well for kernel development, I don't see how it would work well for development where libc is linked in. Warner P.S. /usr/cross is what OpenBSD uses, but I'm not married to that name. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 6 23:50:22 1999 Delivered-To: freebsd-current@freebsd.org Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (Postfix) with ESMTP id 76D8A14E1D for ; Tue, 6 Jul 1999 23:50:02 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.3/8.9.1) id QAA49900; Wed, 7 Jul 1999 16:52:53 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199907070652.QAA49900@cimlogic.com.au> Subject: Re: How to cross build In-Reply-To: <199907070621.AAA67977@harmony.village.org> from Warner Losh at "Jul 7, 1999 00:21:19 am" To: imp@village.org (Warner Losh) Date: Wed, 7 Jul 1999 16:52:53 +1000 (EST) Cc: jb@cimlogic.com.au (John Birrell), current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > You'll need to do this for all binutils as well. I already build binutils with multi-architecture support. On alpha, I have "CROSS_TOOLS= i386 m68k" in my /etc/make.conf and at the end of a make world I have one ld that knows all the formats. Only gas is a special case, so I have "as" (the alpha ELF one), as_i386 (the cross ELF assembler) and as_m68k. At the moment the FreeBSD build drops the extra two in /usr/libexec/elf, which is wrong for egcs. > That would preclude us from porting to an architecture named "ftpd" or > any other program that is in /usr/libexec. I think you want to put a > /arch/ before the ${TARGET}, if you go down this path... Ah, yes, point taken. > Also, I think that your notion of running > make world INCLUDE_THESE_OTHER_TARGETS="mips m68k" > and then building the world (somehow) with these cross tools differs > from my world view. In my world view (which may be wrong, but was > what I arrived at after many false starts down other paths), one would > build the entire system with make buildworld. I do see the utility in > being able to do it other ways. But it would require more than just > programs to make it work. You're concentrating on porting FreeBSD. I'm trying to improve my cross-compilation environment for my third-party code. In particular, I still use VxWorks targeted to m68k (and also alpha). I will get a faster build if I do it on i386 rather than my slower Alpha OSF/1 machine. To build VxWorks stuff cross compiled under OSF/1, I set: GCC_EXEC_PREFIX=/usr/opt/VXW310/bin/gnu/lib/ CPU=MC68020 AR=ar68k CC=cc68k LD=ld68k and include /usr/opt/VXW310/bin/gnu in PATH. These are the names and paths that DEC and Wind River use for the VxWorks product that DEC sells (or did before being absorbed into Compaq). To cross build FreeBSD code one one architecture for another should be no more difficult once the Makefiles have been massaged. > I suspect that /usr/libexec/${TARGET} will prove to be too limited to > work in practice, especially for an entire buildworld (although I can > see how it could be made to work for kernel builds). I think we'd > need to have a /usr/cross/${TARGET}-${TARGET_ARCH}/ tree where the > libraries needed for linking, the include files that are specific to > each port, etc live. Then one could just set one's path to have > /usr/cross/${TARGET}-${TARGET_ARCH}/bin in your path and then make > from there anything you'd like. That would also allow us to have as > many different binaries as we need to build the world and we'd be > decoupled from any hacks to make binutils work. While this approach > would work well for kernel development, I don't see how it would work > well for development where libc is linked in. I was referring to TARGET=elf32-i386, for example. In a cross build mode, setting DESTDIR would be required rather than optional, but that path can't be in PATH because it contains only files in the target format, not tools that run on the host. > P.S. /usr/cross is what OpenBSD uses, but I'm not married to that > name. Does OpenBSD use /usr/cross for the location of the cross _tools_, or as the root of the target specific DESTDIR? I guess it is for the tools. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 0:22:31 1999 Delivered-To: freebsd-current@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id 9E0E5150C4 for ; Wed, 7 Jul 1999 00:22:18 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id DAA07867 for ; Wed, 7 Jul 1999 03:28:45 -0400 (EDT) Date: Wed, 7 Jul 1999 02:28:43 -0500 (EST) From: Alfred Perlstein To: current@freebsd.org Subject: nfs ick in -current Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just cvsup'd today hoping that all the NFS fixes that went in recently would have alleviated (sp?) the hangs I've been getting while building things in ports for the last couple of months. It used to be that just NFS would hang, now it seems to crash the entire box. server:/vol/extra/ports /usr/ports nfs rw,noauto,bg,intr,nfsv3,tcp,-r=3 2768,-w=32768 0 0 server:/vol/extra/ncvs /home/ncvs nfs rw,noauto,bg,intr,nfsv3,tcp,-r=3 2768,-w=32768 0 0 server:/vol/wd0 /vol/wd0 nfs rw,noauto,bg,intr,nfsv3,tcp,-r=3 2768,-w=32768 0 0 are the mount points. attempting to compile xscreensaver has triggered it twice in a row /usr/ports is mounted off "server" (a freebsd -current box) and doing the make will kill the machine. Once I figure out where the heck I have the console redirected I'll have something more substantial. thanks for the patience, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 2:37:54 1999 Delivered-To: freebsd-current@freebsd.org Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (Postfix) with ESMTP id 3CDB114C8F for ; Wed, 7 Jul 1999 02:37:50 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.2/8.8.8) id KAA38376; Wed, 7 Jul 1999 10:37:47 +0100 (BST) (envelope-from joe) Date: Wed, 7 Jul 1999 10:37:46 +0100 From: Josef Karthauser To: Brian Somers Cc: Mark Thomas , freebsd-current@FreeBSD.org, Wayne Self Subject: Re: userland ppp - startup Message-ID: <19990707103746.A30024@pavilion.net> References: <3.0.6.32.19990704161654.00921c20@pop3.clark.net> <199907051959.UAA36719@dev.lan.awfulhak.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=a8Wt8u1KmwUX3Y2C X-Mailer: Mutt 0.95.4i In-Reply-To: <199907051959.UAA36719@dev.lan.awfulhak.org>; from Brian Somers on Mon, Jul 05, 1999 at 08:59:41PM +0100 X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, 24 The Old Steine, Brighton, BN1 1EL, England Phone: +44-845-333-5000 Fax: +44-845-333-5001 Mobile: +44-403-596893 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii On Mon, Jul 05, 1999 at 08:59:41PM +0100, Brian Somers wrote: > [-current cc'd - please don't make this a big thread !] > /etc/start_if.tun0 with an ``exec ppp ...''. This starts things up > at the correct point. > > However, maybe it's time for a knob in rc.conf ? Something like > > ppp_enable="NO" # Start user-ppp > ppp_alias="YES" # Packet aliasing (NAT/masquerading) > ppp_mode="auto" # Usually auto or ddial > ppp_profile="papchap" # Which profile to read from /etc/ppp/ppp.conf > > We'd also need a default /etc/ppp/ppp.conf that contains a papchap > profile as this seems to be what most ISPs give you these days. I'd > also include a commented-out ``set login'' with an appropriate > comment. Sysinstall may need to be adjusted too... > > Suggestions/objections ? If not, I'll commit soon (unless you want > to do the work Joe ;*) Something like this should do it. It may be nice to also allow the authname/authkey to be specified on the command line so that they can easily be set in rc.conf, by hand or by sysinstall. Joe -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="rc.conf-patch" --- /etc/defaults/rc.conf Wed Jun 30 22:02:32 1999 +++ rc.conf Tue Jul 6 23:39:13 1999 @@ -50,6 +50,13 @@ #sppp_interfaces="isp0" # example: sppp over ISDN #spppconfig_isp0="authproto=chap myauthname=foo myauthsecret='top secret' hisauthname=some-gw hisauthsecret='another secret'" +# Use ppp configuration. +ppp_enable="NO" # Start user-ppp (or NO). +ppp_mode="auto" # Choice of "auto", "ddial", "direct" or "dedicated". + # For details see man page for ppp(8). Default is auto. +ppp_alias="YES" # Packet aliasing (NAT/masquerading) or NO. +ppp_profile="papchap" # Which profile to use from /etc/ppp/ppp.conf. + ### Network daemon (miscellaneous) & NFS options: ### syslogd_enable="YES" # Run syslog daemon (or NO). syslogd_flags="" # Flags to syslogd (if enabled). --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="rc.network-patch" --- rc.network-orig Tue Jul 6 20:19:26 1999 +++ rc.network Tue Jul 6 22:24:50 1999 @@ -128,6 +128,23 @@ fi fi + # Warm up user ppp if required. + if [ "X$ppp_enable" = X"YES" ]; then + # Establish ppp mode. + if [ "X$ppp_mode" != X"ddial" -a "X$ppp_mode" != X"direct" \ + -a "X$ppp_mode" != X"dedicated" ]; then \ + ppp_mode="auto"; + fi + ppp_command="-${ppp_mode} "; + + # Switch on alias mode? + if [ "X$ppp_alias" = "YES" ]; then + ppp_command="${ppp_command} -alias"; + fi + + echo -n 'Starting ppp: '; ppp ${ppp_command} ${ppp_profile} + fi + # Additional ATM interface configuration if [ -n "${atm_pass1_done}" ]; then atm_pass2 --a8Wt8u1KmwUX3Y2C-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 2:49:39 1999 Delivered-To: freebsd-current@freebsd.org Received: from titan.metropolitan.at (mail.metropolitan.at [195.212.98.131]) by hub.freebsd.org (Postfix) with ESMTP id 019FC15003 for ; Wed, 7 Jul 1999 02:49:30 -0700 (PDT) (envelope-from mladavac@metropolitan.at) Received: by TITAN with Internet Mail Service (5.0.1458.49) id ; Wed, 7 Jul 1999 11:52:33 +0200 Message-ID: <55586E7391ACD211B9730000C11002761796D9@r-lmh-wi-100.corpnet.at> From: Ladavac Marino To: 'Josef Karthauser' , Brian Somers Cc: Mark Thomas , freebsd-current@FreeBSD.org, Wayne Self Subject: RE: userland ppp - startup Date: Wed, 7 Jul 1999 11:46:27 +0200 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > -----Original Message----- > From: Josef Karthauser [SMTP:joe@pavilion.net] > Sent: Wednesday, July 07, 1999 11:38 AM > To: Brian Somers > Cc: Mark Thomas; freebsd-current@FreeBSD.org; Wayne Self > Subject: Re: userland ppp - startup > > Something like this should do it. It may be nice to also allow the > authname/authkey to be specified on the command line so that they > can easily be set in rc.conf, by hand or by sysinstall. > [ML] You do not really want these on the command line for everyone to see with ps. (nor in rc.conf for everyone to see with e.g. cat) /Marino > Joe > -- > Josef Karthauser FreeBSD: How many times have you booted today? > Technical Manager Viagra for your server > (http://www.uk.freebsd.org) > Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, > joe@tao.org.uk] << File: rc.conf-patch.txt >> << File: > rc.network-patch.txt >> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 2:52:51 1999 Delivered-To: freebsd-current@freebsd.org Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (Postfix) with ESMTP id 3109214CAA for ; Wed, 7 Jul 1999 02:52:48 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.2/8.8.8) id KAA42482; Wed, 7 Jul 1999 10:52:39 +0100 (BST) (envelope-from joe) Date: Wed, 7 Jul 1999 10:52:39 +0100 From: Josef Karthauser To: Ladavac Marino Cc: Brian Somers , Mark Thomas , freebsd-current@FreeBSD.org, Wayne Self Subject: Re: userland ppp - startup Message-ID: <19990707105239.D30024@pavilion.net> References: <55586E7391ACD211B9730000C11002761796D9@r-lmh-wi-100.corpnet.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <55586E7391ACD211B9730000C11002761796D9@r-lmh-wi-100.corpnet.at>; from Ladavac Marino on Wed, Jul 07, 1999 at 11:46:27AM +0200 X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, 24 The Old Steine, Brighton, BN1 1EL, England Phone: +44-845-333-5000 Fax: +44-845-333-5001 Mobile: +44-403-596893 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 07, 1999 at 11:46:27AM +0200, Ladavac Marino wrote: > > > Something like this should do it. It may be nice to also allow the > > authname/authkey to be specified on the command line so that they > > can easily be set in rc.conf, by hand or by sysinstall. > > > [ML] You do not really want these on the command line for > everyone to see with ps. (nor in rc.conf for everyone to see with e.g. > cat) Hmm... how to do this then? The sppp setup code in rc.* allows username/password to be specified. Can it be done in the environment then? (If rc.conf is visable then the sppp config gives usernames and passwords away as it stands today.) Joe -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 3:23:38 1999 Delivered-To: freebsd-current@freebsd.org Received: from titan.metropolitan.at (mail.metropolitan.at [195.212.98.131]) by hub.freebsd.org (Postfix) with ESMTP id 21FCB14C8D for ; Wed, 7 Jul 1999 03:23:34 -0700 (PDT) (envelope-from mladavac@metropolitan.at) Received: by TITAN with Internet Mail Service (5.0.1458.49) id ; Wed, 7 Jul 1999 12:26:40 +0200 Message-ID: <55586E7391ACD211B9730000C11002761796DA@r-lmh-wi-100.corpnet.at> From: Ladavac Marino To: 'Josef Karthauser' , Ladavac Marino Cc: Brian Somers , Mark Thomas , freebsd-current@FreeBSD.org, Wayne Self Subject: RE: userland ppp - startup Date: Wed, 7 Jul 1999 12:20:35 +0200 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > -----Original Message----- > From: Josef Karthauser [SMTP:joe@pavilion.net] > Sent: Wednesday, July 07, 1999 11:53 AM > To: Ladavac Marino > Cc: Brian Somers; Mark Thomas; freebsd-current@FreeBSD.org; Wayne > Self > Subject: Re: userland ppp - startup > > On Wed, Jul 07, 1999 at 11:46:27AM +0200, Ladavac Marino wrote: > > > > > Something like this should do it. It may be nice to also allow > the > > > authname/authkey to be specified on the command line so that they > > > can easily be set in rc.conf, by hand or by sysinstall. > > > > > [ML] You do not really want these on the command line for > > everyone to see with ps. (nor in rc.conf for everyone to see with > e.g. > > cat) > > Hmm... how to do this then? The sppp setup code in rc.* allows > username/password > to be specified. Can it be done in the environment then? (If rc.conf > is visable > then the sppp config gives usernames and passwords away as it stands > today.) [ML] Don't know about sppp, but the only halfway secure way to keep this sensitive data is in a file readable by root, and having the program which needs it setuid root. Sounds a lot like /etc/ppp/ppp.conf, doesn't it? The secure way would be not keeping the info at all :) /Marino > Joe > -- > Josef Karthauser FreeBSD: How many times have you booted today? > Technical Manager Viagra for your server > (http://www.uk.freebsd.org) > Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, > joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 4:22:24 1999 Delivered-To: freebsd-current@freebsd.org Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (Postfix) with ESMTP id 3008A14C2E for ; Wed, 7 Jul 1999 04:22:13 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.2/8.8.8) id MAA70081; Wed, 7 Jul 1999 12:21:58 +0100 (BST) (envelope-from joe) Date: Wed, 7 Jul 1999 12:21:57 +0100 From: Josef Karthauser To: Ladavac Marino Cc: Brian Somers , Mark Thomas , freebsd-current@FreeBSD.org, Wayne Self Subject: Re: userland ppp - startup Message-ID: <19990707122157.I30024@pavilion.net> References: <55586E7391ACD211B9730000C11002761796DA@r-lmh-wi-100.corpnet.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <55586E7391ACD211B9730000C11002761796DA@r-lmh-wi-100.corpnet.at>; from Ladavac Marino on Wed, Jul 07, 1999 at 12:20:35PM +0200 X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, 24 The Old Steine, Brighton, BN1 1EL, England Phone: +44-845-333-5000 Fax: +44-845-333-5001 Mobile: +44-403-596893 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 07, 1999 at 12:20:35PM +0200, Ladavac Marino wrote: > [ML] Don't know about sppp, but the only halfway secure way to > keep this sensitive data is in a file readable by root, and having the > program which needs it setuid root. Sounds a lot like > /etc/ppp/ppp.conf, doesn't it? > > The secure way would be not keeping the info at all :) It does :) That said doesn't sysinstall using ppp to do a net install? How does it setup username/password, etc. Joe -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 4:28:22 1999 Delivered-To: freebsd-current@freebsd.org Received: from titan.metropolitan.at (mail.metropolitan.at [195.212.98.131]) by hub.freebsd.org (Postfix) with ESMTP id CA8C014C2E for ; Wed, 7 Jul 1999 04:27:18 -0700 (PDT) (envelope-from mladavac@metropolitan.at) Received: by TITAN with Internet Mail Service (5.0.1458.49) id ; Wed, 7 Jul 1999 13:30:20 +0200 Message-ID: <55586E7391ACD211B9730000C11002761796DB@r-lmh-wi-100.corpnet.at> From: Ladavac Marino To: 'Josef Karthauser' , Ladavac Marino Cc: Brian Somers , Mark Thomas , freebsd-current@FreeBSD.org, Wayne Self Subject: RE: userland ppp - startup Date: Wed, 7 Jul 1999 13:24:16 +0200 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > -----Original Message----- > From: Josef Karthauser [SMTP:joe@pavilion.net] > Sent: Wednesday, July 07, 1999 1:22 PM > To: Ladavac Marino > Cc: Brian Somers; Mark Thomas; freebsd-current@FreeBSD.org; Wayne > Self > Subject: Re: userland ppp - startup > > On Wed, Jul 07, 1999 at 12:20:35PM +0200, Ladavac Marino wrote: > > [ML] Don't know about sppp, but the only halfway secure way to > > keep this sensitive data is in a file readable by root, and having > the > > program which needs it setuid root. Sounds a lot like > > /etc/ppp/ppp.conf, doesn't it? > > > > The secure way would be not keeping the info at all :) > > It does :) That said doesn't sysinstall using ppp to do a net > install? > How does it setup username/password, etc. [ML] It asks for it in a dialog box, IIRC (never having used it :) /Marino > Joe > -- > Josef Karthauser FreeBSD: How many times have you booted today? > Technical Manager Viagra for your server > (http://www.uk.freebsd.org) > Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, > joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 5:11:41 1999 Delivered-To: freebsd-current@freebsd.org Received: from pooh.elsevier.nl (pooh.elsevier.nl [145.36.9.32]) by hub.freebsd.org (Postfix) with ESMTP id E577915268 for ; Wed, 7 Jul 1999 05:11:26 -0700 (PDT) (envelope-from steveo@iol.ie) Received: from pooh.elsevier.nl (localhost [127.0.0.1]) by pooh.elsevier.nl (8.9.3/8.9.3) with ESMTP id NAA11777; Wed, 7 Jul 1999 13:00:47 +0100 (IST) (envelope-from steveo@iol.ie) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <55586E7391ACD211B9730000C11002761796DB@r-lmh-wi-100.corpnet.at> Date: Wed, 07 Jul 1999 13:00:46 +0100 (IST) From: "Steve O'Hara-Smith" To: Ladavac Marino Subject: RE: userland ppp - startup Cc: Wayne Self , freebsd-current@FreeBSD.ORG, Mark Thomas , Brian Somers , Josef Karthauser Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 07-Jul-99 Ladavac Marino wrote: >> It does :) That said doesn't sysinstall using ppp to do a net >> install? >> How does it setup username/password, etc. > [ML] It asks for it in a dialog box, IIRC (never having used it >:) sysinstall drops you into ppp and you have to use the term command to log in manually. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 7:50:28 1999 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 159D414C99 for ; Wed, 7 Jul 1999 07:50:23 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 6829E78; Wed, 7 Jul 1999 22:50:22 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Alfred Perlstein Cc: current@freebsd.org Subject: Re: nfs ick in -current In-reply-to: Your message of "Wed, 07 Jul 1999 02:28:43 EST." Date: Wed, 07 Jul 1999 22:50:22 +0800 From: Peter Wemm Message-Id: <19990707145022.6829E78@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > > I just cvsup'd today hoping that all the NFS fixes that went in > recently would have alleviated (sp?) the hangs I've been getting > while building things in ports for the last couple of months. > > It used to be that just NFS would hang, now it seems to crash the > entire box. > > server:/vol/extra/ports /usr/ports nfs rw,noauto,bg,intr,nfsv3,tcp,- r=3 > 2768,-w=32768 0 0 > server:/vol/extra/ncvs /home/ncvs nfs rw,noauto,bg,intr,nfsv3,tcp,- r=3 > 2768,-w=32768 0 0 > server:/vol/wd0 /vol/wd0 nfs rw,noauto,bg,intr,nfsv3,tcp,- r=3 > 2768,-w=32768 0 0 > > are the mount points. > > attempting to compile xscreensaver has triggered it twice in a row > /usr/ports is mounted off "server" (a freebsd -current box) and > doing the make will kill the machine. > > Once I figure out where the heck I have the console redirected > I'll have something more substantial. You have a block size of 32K, I'll bet it's 'Bad nfs svc reply' in nfs_syscalls.c. This is triggered when the READDIRPLUS op generates an oversized reply and it triggers the sanity check. Change it to 16K and I think it'll work. Otherwise change the panic to a printf(), but that is sweeping the problem under the carpet and might just give the client indigestion. It does stop the server crashing though. > thanks for the patience, > -Alfred Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 8:40:32 1999 Delivered-To: freebsd-current@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id ADE0514E76 for ; Wed, 7 Jul 1999 08:40:18 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id LAA29553; Wed, 7 Jul 1999 11:46:13 -0400 (EDT) Date: Wed, 7 Jul 1999 10:46:12 -0500 (EST) From: Alfred Perlstein To: Peter Wemm Cc: current@FreeBSD.ORG Subject: Re: nfs ick in -current In-Reply-To: <19990707145022.6829E78@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 7 Jul 1999, Peter Wemm wrote: > Alfred Perlstein wrote: > > > > I just cvsup'd today hoping that all the NFS fixes that went in > > recently would have alleviated (sp?) the hangs I've been getting > > while building things in ports for the last couple of months. > > > > It used to be that just NFS would hang, now it seems to crash the > > entire box. > > > > server:/vol/extra/ports /usr/ports nfs rw,noauto,bg,intr,nfsv3,tcp,- > r=3 > > 2768,-w=32768 0 0 > > server:/vol/extra/ncvs /home/ncvs nfs rw,noauto,bg,intr,nfsv3,tcp,- > r=3 > > 2768,-w=32768 0 0 > > server:/vol/wd0 /vol/wd0 nfs rw,noauto,bg,intr,nfsv3,tcp,- > r=3 > > 2768,-w=32768 0 0 > > > > are the mount points. > > > > attempting to compile xscreensaver has triggered it twice in a row > > /usr/ports is mounted off "server" (a freebsd -current box) and > > doing the make will kill the machine. > > > > Once I figure out where the heck I have the console redirected > > I'll have something more substantial. > > You have a block size of 32K, I'll bet it's 'Bad nfs svc reply' in > nfs_syscalls.c. This is triggered when the READDIRPLUS op generates > an oversized reply and it triggers the sanity check. odd, shouldn't it know not to violate its own sanity checks? Just throttle down the requests, or spit out an error? > Change it to 16K and I think it'll work. Otherwise change the panic to a > printf(), but that is sweeping the problem under the carpet and might just > give the client indigestion. It does stop the server crashing though. I'll try that, thanks, set my -r and -w to 16k. Um something odd though, from the code: if (siz <= 0 || siz > NFS_MAXPACKET) { printf("mbuf siz=%d\n",siz); panic("Bad nfs svc reply"); } then earlier: nfsproto.h:#define NFS_MAXPKTHDR 404 nfsproto.h:#define NFS_MAXPACKET (NFS_MAXPKTHDR + NFS_MAXDATA) nfsproto.h:#define NFS_MAXDATA 32768 isn't 32k within the safe limits, or sometimes when building the RPC reply it can just get too big? Oh, one more thing, I'm getting "device busy" even when using -f during my unmount of wedged nfs mounts, all I needed to do was kill -9 a shell sitting in that dir, but shouldn't that be unnessesary? thanks for your patience, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 9: 7:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id A6A0914E8E for ; Wed, 7 Jul 1999 09:07:42 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id E151878; Thu, 8 Jul 1999 00:07:36 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Alfred Perlstein Cc: current@FreeBSD.ORG Subject: Re: nfs ick in -current In-reply-to: Your message of "Wed, 07 Jul 1999 10:46:12 EST." Date: Thu, 08 Jul 1999 00:07:36 +0800 From: Peter Wemm Message-Id: <19990707160736.E151878@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > On Wed, 7 Jul 1999, Peter Wemm wrote: > > > Alfred Perlstein wrote: > > > > > > I just cvsup'd today hoping that all the NFS fixes that went in > > > recently would have alleviated (sp?) the hangs I've been getting > > > while building things in ports for the last couple of months. > > > > > > It used to be that just NFS would hang, now it seems to crash the > > > entire box. > > > > > > server:/vol/extra/ports /usr/ports nfs rw,noauto,bg,intr,nfsv3,t cp,- > > r=3 > > > 2768,-w=32768 0 0 > > > server:/vol/extra/ncvs /home/ncvs nfs rw,noauto,bg,intr,nfsv3,t cp,- > > r=3 > > > 2768,-w=32768 0 0 > > > server:/vol/wd0 /vol/wd0 nfs rw,noauto,bg,intr,nfsv3,t cp,- > > r=3 > > > 2768,-w=32768 0 0 > > > > > > are the mount points. > > > > > > attempting to compile xscreensaver has triggered it twice in a row > > > /usr/ports is mounted off "server" (a freebsd -current box) and > > > doing the make will kill the machine. > > > > > > Once I figure out where the heck I have the console redirected > > > I'll have something more substantial. > > > > You have a block size of 32K, I'll bet it's 'Bad nfs svc reply' in > > nfs_syscalls.c. This is triggered when the READDIRPLUS op generates > > an oversized reply and it triggers the sanity check. > > odd, shouldn't it know not to violate its own sanity checks? Just > throttle down the requests, or spit out an error? Well, I still am having trouble getting my head around what's going on. In a nutshell, the code goes to a fair bit of trouble to not generate a packet that violates the protocols, and yet it still does, by a long shot. I'm setting up to try and reproduce this so I can catch it live rather than long afterwards. > > Change it to 16K and I think it'll work. Otherwise change the panic to a > > printf(), but that is sweeping the problem under the carpet and might just > > give the client indigestion. It does stop the server crashing though. > > I'll try that, thanks, set my -r and -w to 16k. Um something odd > though, from the code: > > if (siz <= 0 || siz > NFS_MAXPACKET) { > printf("mbuf siz=%d\n",siz); > panic("Bad nfs svc reply"); > } > > then earlier: > nfsproto.h:#define NFS_MAXPKTHDR 404 > nfsproto.h:#define NFS_MAXPACKET (NFS_MAXPKTHDR + NFS_MAXDATA) > nfsproto.h:#define NFS_MAXDATA 32768 > > isn't 32k within the safe limits, or sometimes when building the RPC > reply it can just get too big? It's running over by at least 250 bytes or so. ie: 32K + 680, which is more than 32K + 404. I have not got the protocol maps handy so I'm not yet sure if the limits are wrong, or the request is wrong, or the readdirplus code is wrong. In any case, *something* is wrong. :-) > Oh, one more thing, I'm getting "device busy" even when using -f > during my unmount of wedged nfs mounts, all I needed to do was > kill -9 a shell sitting in that dir, but shouldn't that be > unnessesary? Umm.. what were you unmounting? server:/mount or the /localmount? There are some well known problems with trying to unmount /localmount for a wedged mount - the damn code stat's it and hangs itself. Trying to fix this and yet accomodate all the other tweaks for handling symlinks (ie: /dev/cdrom -> /dev/cd0a) etc style hacks got me rather confused last time. Also, the VM has changed a bit over the last few months, deadfs may not be finding all the hooks into the VFS that might be still there. > thanks for your patience, > -Alfred Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 10:31:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id AB43D14CDE for ; Wed, 7 Jul 1999 10:31:29 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id NAA12545; Wed, 7 Jul 1999 13:37:42 -0400 (EDT) Date: Wed, 7 Jul 1999 12:37:40 -0500 (EST) From: Alfred Perlstein To: Peter Wemm Cc: current@FreeBSD.ORG Subject: Re: nfs ick in -current In-Reply-To: <19990707160736.E151878@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 8 Jul 1999, Peter Wemm wrote: > Alfred Perlstein wrote: > > On Wed, 7 Jul 1999, Peter Wemm wrote: > > > > > > attempting to compile xscreensaver has triggered it twice in a row > > > > /usr/ports is mounted off "server" (a freebsd -current box) and > > > > doing the make will kill the machine. > > > > > > > > Once I figure out where the heck I have the console redirected > > > > I'll have something more substantial. > > > > > > You have a block size of 32K, I'll bet it's 'Bad nfs svc reply' in > > > nfs_syscalls.c. This is triggered when the READDIRPLUS op generates > > > an oversized reply and it triggers the sanity check. > > > > odd, shouldn't it know not to violate its own sanity checks? Just > > throttle down the requests, or spit out an error? > > Well, I still am having trouble getting my head around what's going on. > In a nutshell, the code goes to a fair bit of trouble to not generate a > packet that violates the protocols, and yet it still does, by a long shot. > I'm setting up to try and reproduce this so I can catch it live rather than > long afterwards. odd. > > > Change it to 16K and I think it'll work. Otherwise change the panic to a > > > printf(), but that is sweeping the problem under the carpet and might just > > > give the client indigestion. It does stop the server crashing though. > > > > I'll try that, thanks, set my -r and -w to 16k. Um something odd > > though, from the code: > > > > if (siz <= 0 || siz > NFS_MAXPACKET) { > > printf("mbuf siz=%d\n",siz); > > panic("Bad nfs svc reply"); > > } > > > > then earlier: > > nfsproto.h:#define NFS_MAXPKTHDR 404 > > nfsproto.h:#define NFS_MAXPACKET (NFS_MAXPKTHDR + NFS_MAXDATA) > > nfsproto.h:#define NFS_MAXDATA 32768 > > > > isn't 32k within the safe limits, or sometimes when building the RPC > > reply it can just get too big? > > It's running over by at least 250 bytes or so. ie: 32K + 680, which is > more than 32K + 404. I have not got the protocol maps handy so I'm not yet > sure if the limits are wrong, or the request is wrong, or the readdirplus > code is wrong. In any case, *something* is wrong. :-) oy vey. :) > > > Oh, one more thing, I'm getting "device busy" even when using -f > > during my unmount of wedged nfs mounts, all I needed to do was > > kill -9 a shell sitting in that dir, but shouldn't that be > > unnessesary? > > Umm.. what were you unmounting? server:/mount or the /localmount? There > are some well known problems with trying to unmount /localmount for a > wedged mount - the damn code stat's it and hangs itself. Trying to fix > this and yet accomodate all the other tweaks for handling symlinks > (ie: /dev/cdrom -> /dev/cd0a) etc style hacks got me rather confused last > time. > > Also, the VM has changed a bit over the last few months, deadfs may not be > finding all the hooks into the VFS that might be still there. unmounting a hung nfs mount: client% mount /dev/da0s1a on / (local, soft-updates, writes: sync 10 async 9392) ... server:/vol/extra/ports on /usr/ports server:/vol/extra/ncvs on /home/ncvs client% umount -f /home/ncvs Device busy. client% -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 11:32:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (Postfix) with ESMTP id 30E7414D7D; Wed, 7 Jul 1999 11:32:08 -0700 (PDT) (envelope-from brdean@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.9.3/8.9.1) with SMTP id OAA19760; Wed, 7 Jul 1999 14:32:00 -0400 (EDT) Received: from dean.pc.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA22096; Wed, 7 Jul 1999 14:31:29 -0400 Received: (from brdean@localhost) by dean.pc.sas.com (8.9.3/8.9.3) id OAA16835; Wed, 7 Jul 1999 14:31:29 -0400 (EDT) (envelope-from brdean) From: Brian Dean Message-Id: <199907071831.OAA16835@dean.pc.sas.com> Subject: Re: support for i386 hardware debug watch points In-Reply-To: <19990706142523.38487@right.PCS> from Jonathan Lemon at "Jul 6, 1999 02:25:23 pm" To: freebsd-hackers@freebsd.org Date: Wed, 7 Jul 1999 14:31:29 -0400 (EDT) Cc: jlemon@americantv.com, peter@netplex.com.au, freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, (I've CC'd -current because of the implications there ...) Here are my patches for hardware debug register support for the i386 port. I think this is ready to be reviewed and hopefully committed. It consists of modifications to 13 files and the addition of 1 new file. The new file is listed out at the bottom of this message. My implementation consists of: * saving and restoring the debug registers at context switch time if necessary * procfs modifications to support reading/writing to the 'dbregs' file of the process, which works in an identical manner as the interface to 'regs' and 'fpregs'. * two additional request implementations for the 'ptrace()' call: PT_GETDBREGS and PT_SETDBREGS. The only thing that it does not do right now that might be useful (that I'm aware of) is include the state of the debug registers in a core dump. This was more than I wanted to get into at the moment, and would require modification of any tools that read a core dump image. Also, I've made a first pass attempt at security by denying a process the ability to set a debug watch or breakpoint outside of his address space, unless the process is owned by root. It can certainly be useful to use these registers for kernel debugging, but I thought that should be limited to the root user. I haven't done anything with the Alpha, though some of the procfs mods will affect the Alpha port, at least to the point of possibly needing to include a couple of stub functions in MD code to avoid unresolved references for 'procfs_read_dbregs()' and 'procfs_write_dbregs()'. Also, I have not included anything for 'gdb' because I just have not had time to figure it out yet. I'm hoping that someone else, who knows the gdb code better than I, can make the required modifications there for hardware debug support. Essentially, you would need to make a call like this: { struct dbreg dbregs ptrace ( PT_GETDBREGS, pid, &dbregs, 0 ); dbregs.dr7 |= 0x000d0002; dbregs.dr0 = watch_addr; ptrace ( PT_SETDBREGS, pid, &dbregs, 0 ); } This would enable the first watch address and would break whenever the 4 bytes at watch_addr were written to. An Intel ix86 systems programming manual will have detailed information on how to set up the registers for various breakpoint and watchpoint conditions. The manuals can be downloaded in pdf format from http://developer.intel.com if anyone is interested. If no one wants to take this on, I will give it a try, but I can't commit to it being done within the next week or so. Here is the patch set, generated against a current tree about 4 hours or so old. The new file that is required is listed out after the patches. Please let me know if anything else is needed or if anything needs to be changed (style or feature). Thanks to Jonathan Lemon, Peter Wemm, and others for answering my questions. Thanks, -- Brian Dean SAS Institute Inc brdean@unx.sas.com Index: conf/files =================================================================== RCS file: /usr/mirror/ncvs/src/sys/conf/files,v retrieving revision 1.228 diff -r1.228 files 364a365 > miscfs/procfs/procfs_dbregs.c standard Index: i386/i386/genassym.c =================================================================== RCS file: /usr/mirror/ncvs/src/sys/i386/i386/genassym.c,v retrieving revision 1.72 diff -r1.72 genassym.c 130a131,137 > printf("#define\tPCB_DR0 %#x\n", OS(pcb, pcb_dr0)); > printf("#define\tPCB_DR1 %#x\n", OS(pcb, pcb_dr1)); > printf("#define\tPCB_DR2 %#x\n", OS(pcb, pcb_dr2)); > printf("#define\tPCB_DR3 %#x\n", OS(pcb, pcb_dr3)); > printf("#define\tPCB_DR6 %#x\n", OS(pcb, pcb_dr6)); > printf("#define\tPCB_DR7 %#x\n", OS(pcb, pcb_dr7)); > printf("#define\tPCB_DBREGS %#x\n", PCB_DBREGS ); Index: i386/i386/machdep.c =================================================================== RCS file: /usr/mirror/ncvs/src/sys/i386/i386/machdep.c,v retrieving revision 1.353 diff -r1.353 machdep.c 1929a1930,2010 > int > fill_dbregs(p, dbregs) > struct proc *p; > struct dbreg *dbregs; > { > struct pcb *pcb; > > pcb = &p->p_addr->u_pcb; > dbregs->dr0 = pcb->pcb_dr0; > dbregs->dr1 = pcb->pcb_dr1; > dbregs->dr2 = pcb->pcb_dr2; > dbregs->dr3 = pcb->pcb_dr3; > dbregs->dr4 = 0; > dbregs->dr5 = 0; > dbregs->dr6 = pcb->pcb_dr6; > dbregs->dr7 = pcb->pcb_dr7; > return (0); > } > > int > set_dbregs(p, dbregs) > struct proc *p; > struct dbreg *dbregs; > { > struct pcb *pcb; > > pcb = &p->p_addr->u_pcb; > > /* > * Don't let a process set a breakpoint that is not within the > * process's address space. If a process could do this, it > * could halt the system by setting a breakpoint in the kernel > * (if ddb was enabled). Thus, we need to check to make sure > * that no breakpoints are being enabled for addresses outside > * process's address space, unless, perhaps, we were called by > * uid 0. > * > * XXX - what about when the watched area of the user's > * address space is written into from within the kernel > * ... wouldn't that still cause a breakpoint to be generated > * from within kernel mode? > */ > > if (p->p_cred->pc_ucred->cr_uid != 0) { > if (dbregs->dr7 & 0x3) { > /* dr0 is enabled */ > if (dbregs->dr0 >= VM_MAXUSER_ADDRESS) > return (EINVAL); > } > > if (dbregs->dr7 & (0x3<<2)) { > /* dr1 is enabled */ > if (dbregs->dr1 >= VM_MAXUSER_ADDRESS) > return (EINVAL); > } > > if (dbregs->dr7 & (0x3<<4)) { > /* dr2 is enabled */ > if (dbregs->dr2 >= VM_MAXUSER_ADDRESS) > return (EINVAL); > } > > if (dbregs->dr7 & (0x3<<6)) { > /* dr3 is enabled */ > if (dbregs->dr3 >= VM_MAXUSER_ADDRESS) > return (EINVAL); > } > } > > pcb->pcb_dr0 = dbregs->dr0; > pcb->pcb_dr1 = dbregs->dr1; > pcb->pcb_dr2 = dbregs->dr2; > pcb->pcb_dr3 = dbregs->dr3; > pcb->pcb_dr6 = dbregs->dr6; > pcb->pcb_dr7 = dbregs->dr7; > > pcb->pcb_flags |= PCB_DBREGS; > > return (0); > } > Index: i386/i386/procfs_machdep.c =================================================================== RCS file: /usr/mirror/ncvs/src/sys/i386/i386/procfs_machdep.c,v retrieving revision 1.11 diff -r1.11 procfs_machdep.c 61a62,64 > * procfs_read_dbregs, procfs_write_dbregs > * deal with the processor debug register set, otherwise as above. > * 100a104,123 > } > > int > procfs_read_dbregs(p, dbregs) > struct proc *p; > struct dbreg *dbregs; > { > if ((p->p_flag & P_INMEM) == 0) > return (EIO); > return (fill_dbregs(p, dbregs)); > } > > int > procfs_write_dbregs(p, dbregs) > struct proc *p; > struct dbreg *dbregs; > { > if ((p->p_flag & P_INMEM) == 0) > return (EIO); > return (set_dbregs(p, dbregs)); Index: i386/i386/swtch.s =================================================================== RCS file: /usr/mirror/ncvs/src/sys/i386/i386/swtch.s,v retrieving revision 1.83 diff -r1.83 swtch.s 482a483,502 > /* test if debug regisers should be saved */ > movb PCB_FLAGS(%edx),%al > andb $PCB_DBREGS,%al > jz 1f /* no, skip over */ > movl %dr7,%eax /* yes, do the save */ > movl %eax,PCB_DR7(%edx) > andl $0x0000ff00, %eax /* disable all watchpoints */ > movl %eax,%dr7 > movl %dr6,%eax > movl %eax,PCB_DR6(%edx) > movl %dr3,%eax > movl %eax,PCB_DR3(%edx) > movl %dr2,%eax > movl %eax,PCB_DR2(%edx) > movl %dr1,%eax > movl %eax,PCB_DR1(%edx) > movl %dr0,%eax > movl %eax,PCB_DR0(%edx) > 1: > 719a740,757 > > /* test if debug regisers should be restored */ > movb PCB_FLAGS(%edx),%al > andb $PCB_DBREGS,%al > jz 1f /* no, skip over */ > movl PCB_DR6(%edx),%eax /* yes, do the restore */ > movl %eax,%dr6 > movl PCB_DR3(%edx),%eax > movl %eax,%dr3 > movl PCB_DR2(%edx),%eax > movl %eax,%dr2 > movl PCB_DR1(%edx),%eax > movl %eax,%dr1 > movl PCB_DR0(%edx),%eax > movl %eax,%dr0 > movl PCB_DR7(%edx),%eax > movl %eax,%dr7 > 1: Index: i386/include/md_var.h =================================================================== RCS file: /usr/mirror/ncvs/src/sys/i386/include/md_var.h,v retrieving revision 1.29 diff -r1.29 md_var.h 66a67 > struct dbreg; 82a84 > int fill_dbregs __P((struct proc *p, struct dbreg *dbregs)); Index: i386/include/pcb.h =================================================================== RCS file: /usr/mirror/ncvs/src/sys/i386/include/pcb.h,v retrieving revision 1.28 diff -r1.28 pcb.h 56a57,64 > > int pcb_dr0; > int pcb_dr1; > int pcb_dr2; > int pcb_dr3; > int pcb_dr6; > int pcb_dr7; > 61a70 > #define PCB_DBREGS 0x02 /* process using debug registers */ Index: i386/include/ptrace.h =================================================================== RCS file: /usr/mirror/ncvs/src/sys/i386/include/ptrace.h,v retrieving revision 1.6 diff -r1.6 ptrace.h 46a47,48 > #define PT_GETDBREGS (PT_FIRSTMACH + 5) > #define PT_SETDBREGS (PT_FIRSTMACH + 6) Index: i386/include/reg.h =================================================================== RCS file: /usr/mirror/ncvs/src/sys/i386/include/reg.h,v retrieving revision 1.18 diff -r1.18 reg.h 120a121,132 > struct dbreg { > unsigned int dr0; /* debug address register 0 */ > unsigned int dr1; /* debug address register 1 */ > unsigned int dr2; /* debug address register 2 */ > unsigned int dr3; /* debug address register 3 */ > unsigned int dr4; /* reserved */ > unsigned int dr5; /* reserved */ > unsigned int dr6; /* debug status register */ > unsigned int dr7; /* debug control register */ > }; > > 127a140 > int set_dbregs __P((struct proc *p, struct dbreg *dbregs)); Index: kern/sys_process.c =================================================================== RCS file: /usr/mirror/ncvs/src/sys/kern/sys_process.c,v retrieving revision 1.46 diff -r1.46 sys_process.c 277a278,283 > #ifdef PT_GETDBREGS > case PT_GETDBREGS: > #endif > #ifdef PT_SETDBREGS > case PT_SETDBREGS: > #endif 503a510,535 > > #ifdef PT_SETDBREGS > case PT_SETDBREGS: > write = 1; > /* fallthrough */ > #endif /* PT_SETDBREGS */ > #ifdef PT_GETDBREGS > case PT_GETDBREGS: > /* write = 0 above */ > #endif /* PT_SETDBREGS */ > #if defined(PT_SETDBREGS) || defined(PT_GETDBREGS) > if (!procfs_validdbregs(p)) /* no P_SYSTEM procs please */ > return EINVAL; > else { > iov.iov_base = uap->addr; > iov.iov_len = sizeof(struct dbreg); > uio.uio_iov = &iov; > uio.uio_iovcnt = 1; > uio.uio_offset = 0; > uio.uio_resid = sizeof(struct dbreg); > uio.uio_segflg = UIO_USERSPACE; > uio.uio_rw = write ? UIO_WRITE : UIO_READ; > uio.uio_procp = curp; > return (procfs_dodbregs(curp, p, NULL, &uio)); > } > #endif /* defined(PT_SETDBREGS) || defined(PT_GETDBREGS) */ Index: miscfs/procfs/procfs.h =================================================================== RCS file: /usr/mirror/ncvs/src/sys/miscfs/procfs/procfs.h,v retrieving revision 1.26 diff -r1.26 procfs.h 53a54 > Pdbregs, /* the process's debug register set */ 126a128 > struct dbreg; 139a142,143 > int procfs_read_dbregs __P((struct proc *, struct dbreg *)); > int procfs_write_dbregs __P((struct proc *, struct dbreg *)); 142a147 > int procfs_dodbregs __P((struct proc *, struct proc *, struct pfsnode *pfsp, struct uio *uio)); 157a163 > int procfs_validdbregs __P((struct proc *)); Index: miscfs/procfs/procfs_subr.c =================================================================== RCS file: /usr/mirror/ncvs/src/sys/miscfs/procfs/procfs_subr.c,v retrieving revision 1.24 diff -r1.24 procfs_subr.c 169a170 > case Pdbregs: 265a267,270 > > case Pdbregs: > rtval = procfs_dodbregs(curp, p, pfs, uio); > break; Index: miscfs/procfs/procfs_vnops.c =================================================================== RCS file: /usr/mirror/ncvs/src/sys/miscfs/procfs/procfs_vnops.c,v retrieving revision 1.69 diff -r1.69 procfs_vnops.c 97a98 > { DT_REG, N("dbregs"), Pdbregs, procfs_validdbregs }, 493a495 > case Pdbregs: 572a575,578 > > case Pdbregs: > vap->va_bytes = vap->va_size = sizeof(struct dbreg); > break; ---------------------------------------------------------------------- And here is the new file: /* * Copyright (c) 1999 Brian Scott Dean, brdean@unx.sas.com. * All rights reserved. * * This code is derived from software contributed to Berkeley by * Jan-Simon Pendry under the following copyrights and conditions: * * Copyright (c) 1993 Jan-Simon Pendry * Copyright (c) 1993 * The Regents of the University of California. All rights reserved. * * This code is derived from software contributed to Berkeley by * Jan-Simon Pendry. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by the University of * California, Berkeley and its contributors. * 4. Neither the name of the University nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * */ #include #include #include #include #include #include #include int procfs_dodbregs(curp, p, pfs, uio) struct proc *curp; struct proc *p; struct pfsnode *pfs; struct uio *uio; { int error; struct dbreg r; char *kv; int kl; if (!CHECKIO(curp, p)) return EPERM; kl = sizeof(r); kv = (char *) &r; kv += uio->uio_offset; kl -= uio->uio_offset; if (kl > uio->uio_resid) kl = uio->uio_resid; PHOLD(p); if (kl < 0) error = EINVAL; else error = procfs_read_dbregs(p, &r); if (error == 0) error = uiomove(kv, kl, uio); if (error == 0 && uio->uio_rw == UIO_WRITE) { if (p->p_stat != SSTOP) error = EBUSY; else error = procfs_write_dbregs(p, &r); } PRELE(p); uio->uio_offset = 0; return (error); } int procfs_validdbregs(p) struct proc *p; { return ((p->p_flag & P_SYSTEM) == 0); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 11:43:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id DE6DD14D7D; Wed, 7 Jul 1999 11:43:44 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA92954; Wed, 7 Jul 1999 11:43:44 -0700 (PDT) (envelope-from dillon) Date: Wed, 7 Jul 1999 11:43:44 -0700 (PDT) From: Matthew Dillon Message-Id: <199907071843.LAA92954@apollo.backplane.com> To: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Heh heh, humorous lockup Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, but for a kernel hacker this *should* be funny. My system locked up because it had too much memory. Specifically, there is a contrived limit to the size of the kernel malloc pool of 40MB, and 80MB for the entire pool based on VM_KMEM_SIZE_MAX. Unfortunately, if you have a lot of memory the vnode cache can actually wind up *using* 40MB, because the system isn't throwing away active VM objects and so isn't throwing away vnodes. Result: lockup. Since we have increased the hard page table allocation for the kernel to 1G (?) we should be able to safely increase VM_KMEM_SIZE_MAX. I was thinking of increasing it to 512MB. This increase only effects large-memory systems. It keeps them from locking up :-) Anyone have any objections? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 13:19:18 1999 Delivered-To: freebsd-current@freebsd.org Received: from zippy.dyn.ml.org (pm3-29.ppp.wenet.net [206.15.85.29]) by hub.freebsd.org (Postfix) with ESMTP id 19FAD14D06 for ; Wed, 7 Jul 1999 13:19:11 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.9.3/8.9.1) with ESMTP id NAA02027; Wed, 7 Jul 1999 13:18:19 -0700 (PDT) (envelope-from garbanzo@hooked.net) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Wed, 7 Jul 1999 13:18:17 -0700 (PDT) From: Alex Zepeda To: Josef Karthauser Cc: Ladavac Marino , Brian Somers , Mark Thomas , freebsd-current@FreeBSD.ORG, Wayne Self Subject: Re: userland ppp - startup In-Reply-To: <19990707105239.D30024@pavilion.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 7 Jul 1999, Josef Karthauser wrote: > Hmm... how to do this then? The sppp setup code in rc.* allows > username/password to be specified. Can it be done in the environment > then? (If rc.conf is visable then the sppp config gives usernames and > passwords away as it stands today.) Everyone can see the environment too, so that's not secure at all. In fact the best place would probably be the ppp configuration file, which should only be readable by root and group ppp (or is it network?). - alex I thought felt your touch In my car, on my clutch But I guess it's just someone who felt a lot like I remember you. - Translator To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 13:19:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from zippy.dyn.ml.org (pm3-29.ppp.wenet.net [206.15.85.29]) by hub.freebsd.org (Postfix) with ESMTP id E8DB0154A5 for ; Wed, 7 Jul 1999 13:19:29 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.9.3/8.9.1) with ESMTP id NAA02040; Wed, 7 Jul 1999 13:19:03 -0700 (PDT) (envelope-from garbanzo@hooked.net) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Wed, 7 Jul 1999 13:19:02 -0700 (PDT) From: Alex Zepeda To: Ladavac Marino Cc: "'Josef Karthauser'" , Brian Somers , Mark Thomas , freebsd-current@FreeBSD.ORG, Wayne Self Subject: RE: userland ppp - startup In-Reply-To: <55586E7391ACD211B9730000C11002761796D9@r-lmh-wi-100.corpnet.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 7 Jul 1999, Ladavac Marino wrote: > [ML] You do not really want these on the command line for > everyone to see with ps. (nor in rc.conf for everyone to see with e.g. > cat) Why is rc.conf readable by world?! - alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 13:36:37 1999 Delivered-To: freebsd-current@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id 5C941154A9 for ; Wed, 7 Jul 1999 13:36:22 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id QAA13305; Wed, 7 Jul 1999 16:42:38 -0400 (EDT) Date: Wed, 7 Jul 1999 15:42:37 -0500 (EST) From: Alfred Perlstein To: Peter Wemm Cc: current@FreeBSD.ORG Subject: sorry, dead drive == Re: nfs ick in -current In-Reply-To: <19990707160736.E151878@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 8 Jul 1999, Peter Wemm wrote: > Alfred Perlstein wrote: > > On Wed, 7 Jul 1999, Peter Wemm wrote: > > > > > Alfred Perlstein wrote: > > > > > > > > I just cvsup'd today hoping that all the NFS fixes that went in > > > > recently would have alleviated (sp?) the hangs I've been getting > > > > while building things in ports for the last couple of months. > > > > > > > > It used to be that just NFS would hang, now it seems to crash the > > > > entire box. ugh, sorry everyone, dying drive was causing it, tons of SCB errors and timeouts, at least it's under warrantee. sorry for the wild goose chase. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 13:36:48 1999 Delivered-To: freebsd-current@freebsd.org Received: from unix2.it-datacntr.louisville.edu (unix2.it-datacntr.louisville.edu [136.165.4.28]) by hub.freebsd.org (Postfix) with ESMTP id 3FB2115482 for ; Wed, 7 Jul 1999 13:36:41 -0700 (PDT) (envelope-from k.stevenson@louisville.edu) Received: from homer.louisville.edu (ktstev01@homer.louisville.edu [136.165.1.20]) by unix2.it-datacntr.louisville.edu (8.8.8/8.8.8) with ESMTP id QAA31300 for ; Wed, 7 Jul 1999 16:36:00 -0400 Received: (from ktstev01@localhost) by homer.louisville.edu (8.8.8/8.8.8) id QAA02618 for freebsd-current@freebsd.org; Wed, 7 Jul 1999 16:36:39 -0400 (EDT) Message-ID: <19990707163639.B27955@homer.louisville.edu> Date: Wed, 7 Jul 1999 16:36:39 -0400 From: Keith Stevenson To: freebsd-current@freebsd.org Subject: Re: userland ppp - startup References: <55586E7391ACD211B9730000C11002761796D9@r-lmh-wi-100.corpnet.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Alex Zepeda on Wed, Jul 07, 1999 at 01:19:02PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 07, 1999 at 01:19:02PM -0700, Alex Zepeda wrote: > On Wed, 7 Jul 1999, Ladavac Marino wrote: > > > [ML] You do not really want these on the command line for > > everyone to see with ps. (nor in rc.conf for everyone to see with e.g. > > cat) > > Why is rc.conf readable by world?! Why not? Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.stevenson@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 14:13: 3 1999 Delivered-To: freebsd-current@freebsd.org Received: from trinity.radio-do.de (trinity.Radio-do.de [193.101.164.3]) by hub.freebsd.org (Postfix) with ESMTP id 86FDD14BFC for ; Wed, 7 Jul 1999 14:12:57 -0700 (PDT) (envelope-from fn@trinity.radio-do.de) Received: (from fn@localhost) by trinity.radio-do.de (8.9.3/8.9.1) id XAA62617 for current@freebsd.org; Wed, 7 Jul 1999 23:12:57 +0200 (CEST) (envelope-from fn) Message-ID: <19990707231257.A62612@radio-do.de> Date: Wed, 7 Jul 1999 23:12:57 +0200 From: Frank Nobis To: current@freebsd.org Subject: Break of today current and patch Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, todays current breaks in build of libgcc ===> gnu/lib/libgcc c++ -O2 -mpentium -fpcc-struct-return -ffast-math -fno-strength-reduce -malign-jumps=4 -malign-loops=4 -malign-functions=4 -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/cp/inc -nostdinc++ -c /usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/cp/exception.cc -o exception.o /usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/cp/exception.cc:33: eh-common.h: No such file or directory *** gnu/lib/libgcc/Makefile.orig Wed Jul 7 22:07:37 1999 --- gnu/lib/libgcc/Makefile Wed Jul 7 22:07:48 1999 *************** *** 59,65 **** CFLAGS+= -I${GCCDIR}/config -I${GCCDIR} -I. CFLAGS+= -fexceptions CFLAGS+= -DIN_GCC ! CXXFLAGS+= -I${GCCDIR}/cp/inc CXXFLAGS+= -nostdinc++ COMMONHDRS= config.h tconfig.h tm.h --- 59,65 ---- CFLAGS+= -I${GCCDIR}/config -I${GCCDIR} -I. CFLAGS+= -fexceptions CFLAGS+= -DIN_GCC ! CXXFLAGS+= -I${GCCDIR}/cp/inc -I${GCCDIR} CXXFLAGS+= -nostdinc++ COMMONHDRS= config.h tconfig.h tm.h -- Frank Nobis Email: PGP AVAILABLE Landgrafenstr. 130 dg3dcn http://www.radio-do.de/~fn/ 44139 Dortmund Powered by SMP FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 14:17:10 1999 Delivered-To: freebsd-current@freebsd.org Received: from awfulhak.org (dynamic-38.max1-du-ws.dialnetwork.pavilion.co.uk [212.74.8.38]) by hub.freebsd.org (Postfix) with ESMTP id A0EC514DAA for ; Wed, 7 Jul 1999 14:17:03 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from dev.lan.awfulhak.org (dev.lan.awfulhak.org [172.16.0.5]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id WAA02969; Wed, 7 Jul 1999 22:02:44 +0100 (BST) (envelope-from brian@lan.awfulhak.org) Received: from dev.lan.awfulhak.org (localhost [127.0.0.1]) by dev.lan.awfulhak.org (8.9.3/8.9.3) with ESMTP id WAA19958; Wed, 7 Jul 1999 22:02:44 +0100 (BST) (envelope-from brian@dev.lan.awfulhak.org) Message-Id: <199907072102.WAA19958@dev.lan.awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Josef Karthauser Cc: Brian Somers , Mark Thomas , freebsd-current@FreeBSD.org, Wayne Self Subject: Re: userland ppp - startup In-reply-to: Your message of "Wed, 07 Jul 1999 10:37:46 BST." <19990707103746.A30024@pavilion.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Jul 1999 22:02:44 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, Jul 05, 1999 at 08:59:41PM +0100, Brian Somers wrote: > > [-current cc'd - please don't make this a big thread !] > > /etc/start_if.tun0 with an ``exec ppp ...''. This starts things up > > at the correct point. > > > > However, maybe it's time for a knob in rc.conf ? Something like > > > > ppp_enable="NO" # Start user-ppp > > ppp_alias="YES" # Packet aliasing (NAT/masquerading) > > ppp_mode="auto" # Usually auto or ddial > > ppp_profile="papchap" # Which profile to read from /etc/ppp/ppp.conf > > > > We'd also need a default /etc/ppp/ppp.conf that contains a papchap > > profile as this seems to be what most ISPs give you these days. I'd > > also include a commented-out ``set login'' with an appropriate > > comment. Sysinstall may need to be adjusted too... > > > > Suggestions/objections ? If not, I'll commit soon (unless you want > > to do the work Joe ;*) > > Something like this should do it. It may be nice to also allow the > authname/authkey to be specified on the command line so that they > can easily be set in rc.conf, by hand or by sysinstall. WRT the authname/authkey stuff, with sppp, you do something like spppcontrol isp0 myauthproto=chap myauthname=fred myauthsecret=guess This is pretty safe as spppcontrol passes the info into the kernel and exits. As this is at startup, we're safe except for the fact that everyone's probably going to leave rc.conf readable. It would be possible to start ppp then use pppctl to set the authname and authkey, but this would be a bit of a PITA IMHO as you'd have to muck around with ``set server'' etc. Of course you can ``set title'' in ppp, but that's not entirely safe as you can unset it too - restoring the original argv contents. This aside, I think there are more bits required for the patches :*1 rc.conf.5 needs to be updated - that's the easy bit. I think we also need a src/etc/ppp/ppp.conf that installs with 0600 permissions at installation time. This file would have a default and a papchap entry in it - that's where the url for Waynes ppp.conf comes in - its contents are probably what we're after. Older versions of src/etc/Makefile installed ppp.conf, so it should be easy to do that side of things. Sysinstall however is also capable of writing ppp.conf. It would need to be smart enough to update the default one with the lines that it wants to use (just appending an ``install'' label with the necessary bits is probably the best thing to do). This answers your other question..... src/release/sysinstall/network.c - search for ppp.conf. That's how sysinstall does it :-) Ha, and you thought it'd be straight forward ;^P > Joe > -- > Josef Karthauser FreeBSD: How many times have you booted today? > Technical Manager Viagra for your server (http://www.uk.freebsd.org) > Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] [.....] -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 14:34:51 1999 Delivered-To: freebsd-current@freebsd.org Received: from zippy.dyn.ml.org (pm3-3.ppp.wenet.net [206.15.85.3]) by hub.freebsd.org (Postfix) with ESMTP id 0779E15483 for ; Wed, 7 Jul 1999 14:34:43 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.9.3/8.9.1) with ESMTP id OAA08373; Wed, 7 Jul 1999 14:34:21 -0700 (PDT) (envelope-from garbanzo@hooked.net) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Wed, 7 Jul 1999 14:34:21 -0700 (PDT) From: Alex Zepeda To: Keith Stevenson Cc: freebsd-current@FreeBSD.ORG Subject: Re: userland ppp - startup In-Reply-To: <19990707163639.B27955@homer.louisville.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 7 Jul 1999, Keith Stevenson wrote: > On Wed, Jul 07, 1999 at 01:19:02PM -0700, Alex Zepeda wrote: > > On Wed, 7 Jul 1999, Ladavac Marino wrote: > > > > > [ML] You do not really want these on the command line for > > > everyone to see with ps. (nor in rc.conf for everyone to see with e.g. > > > cat) > > > > Why is rc.conf readable by world?! > > Why not? What reason would the rest of the "world" have to read rc.conf? It could only create a possible security risk. - alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 15:13:35 1999 Delivered-To: freebsd-current@freebsd.org Received: from bellnetworks.net (www.bellnetworks.net [216.214.153.70]) by hub.freebsd.org (Postfix) with ESMTP id C285414E32 for ; Wed, 7 Jul 1999 15:13:28 -0700 (PDT) (envelope-from jerry@bellnetworks.net) Received: from bellnetworks.net (alice.bellnetworks.net [216.214.153.74]) by bellnetworks.net (8.9.3/8.9.3) with ESMTP id SAA26282 for ; Wed, 7 Jul 1999 18:13:26 -0400 (EDT) (envelope-from jerry@bellnetworks.net) Message-ID: <3783CFC5.38D2F103@bellnetworks.net> Date: Wed, 07 Jul 1999 18:08:05 -0400 From: Jerry Bell X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Stuck in "objtrm" References: <199907021200.WAA06282@nymph.detir.qld.gov.au> <199907060745.RAA12161@nymph.detir.qld.gov.au> <199907061044.UAA14043@nymph.detir.qld.gov.au> <14210.4262.296904.751060@grasshopper.cs.duke.edu> <199907070349.NAA13375@nymph.detir.qld.gov.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I can very reliable reproduce a process getting stuck in this state. The box it is running on is a k6-2 400 with 128MB of ram and 500MB of swap. When compiling mysql322-server with the compiler option of '-O2' or '-O3', the build gets up to sql_yacc.cc. It churns on this file and goes into the objtrm state after about 4 minutes of cpu time pass. Watching the memory usage of this compile is pretty interesting: it starts out using about 30M of memory, then jumps to about 105MB. It bounces around between 100MB and 130MB, then jumps to 200MB, at which point is starts swapping in and out pretty frequently. The compile runs, every now and then going into swread state. After a while of this, with about 170MB of swap taken up, the process goes into the objtrm state, and drops to about 3MB in size. This is happening on a build from last friday (7/2). If I can provide any further information, please let me know. I can get this to happen every time I try. Jerry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 15:19:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from mail.vr.IN-Berlin.DE (gnu.in-berlin.de [192.109.42.4]) by hub.freebsd.org (Postfix) with ESMTP id C4C1C14E32 for ; Wed, 7 Jul 1999 15:19:43 -0700 (PDT) (envelope-from dva.in-berlin.de!balu@hirsch.in-berlin.de) Received: from hirsch.in-berlin.de (root@hirsch.in-berlin.de [192.109.42.6]) by mail.vr.IN-Berlin.DE (8.9.1a/8.9.1) with ESMTP id AAA25364 for ; Thu, 8 Jul 1999 00:19:43 +0200 (CEST) (envelope-from dva.in-berlin.de!balu@hirsch.in-berlin.de) Received: by hirsch.in-berlin.de (Smail3.2) id ; Thu, 8 Jul 1999 00:19:38 +0200 (CEST) Received: (from balu@localhost) by dva.in-berlin.de (8.9.3/8.9.1) id AAA35104 for freebsd-current@FreeBSD.ORG; Thu, 8 Jul 1999 00:17:38 +0200 (CEST) (envelope-from balu) Date: Thu, 8 Jul 1999 00:17:34 +0200 From: Boris Staeblow To: freebsd-current@FreeBSD.ORG Subject: Re: userland ppp - startup Message-ID: <19990708001733.A34785@dva.in-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 7 Jul 1999 Keith Stevenson wrote: >> Why is rc.conf readable by world?! > > >Why not? What about that: spppconfig_isp0="authproto=chap myauthname=foo myauthsecret='top secret' hisauthname=some-gw hisauthsecret='another secret'" Boris -- balu@dva.in-berlin.de Boris Staeblow To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 15:23:22 1999 Delivered-To: freebsd-current@freebsd.org Received: from bellnetworks.net (www.bellnetworks.net [216.214.153.70]) by hub.freebsd.org (Postfix) with ESMTP id AC41615569 for ; Wed, 7 Jul 1999 15:23:07 -0700 (PDT) (envelope-from jerry@bellnetworks.net) Received: from bellnetworks.net (alice.bellnetworks.net [216.214.153.74]) by bellnetworks.net (8.9.3/8.9.3) with ESMTP id SAA26355; Wed, 7 Jul 1999 18:21:42 -0400 (EDT) (envelope-from jerry@bellnetworks.net) Message-ID: <3783D1B5.C1A09139@bellnetworks.net> Date: Wed, 07 Jul 1999 18:16:21 -0400 From: Jerry Bell X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Alexander Langer Cc: Matthew Jacob , freebsd-current@FreeBSD.ORG Subject: Re: this of interest to anyone? References: <19990812100720.B707@cichlids.cichlids.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I got this a few days ago. Apparently there was some form of problem with the vm subsystem (I'm speculating here). What I did to fix it was to re-cvsup the source tree (after killing non-essential processes) and rebuilding only the kernel. After compiling and installing the new kernel, I rebooted and reran a full make world. Everything seems to be working well, now. Jerry Alexander Langer wrote: > > Thus spake Matthew Jacob (mjacob@feral.com): > > > panic: lockmgr: pid 3344, not exclusive lock holder 3341 unlocking > > I got this very often the last days, too. > > Actually I try do downgrade to 3.2, because my machines reboots 3 > times a day because of either this error or other things. -CURRENT > actually is VERY unstable here. > > Alex > -- > ************** I doubt, therefore I might be. ************** > *** Send email to to get PGP-Key *** > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 15:50:58 1999 Delivered-To: freebsd-current@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id CC7041549F; Wed, 7 Jul 1999 15:50:53 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id PAA23598; Wed, 7 Jul 1999 15:49:39 -0700 (PDT) Message-Id: <199907072249.PAA23598@implode.root.com> To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup In-reply-to: Your message of "Wed, 07 Jul 1999 11:43:44 PDT." <199907071843.LAA92954@apollo.backplane.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 07 Jul 1999 15:49:39 -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Since we have increased the hard page table allocation for the kernel to > 1G (?) we should be able to safely increase VM_KMEM_SIZE_MAX. I was > thinking of increasing it to 512MB. This increase only effects > large-memory systems. It keeps them from locking up :-) > > Anyone have any objections? Yes, I do - at least with the 512MB figure. That would be half of the 1GB KVA space and large systems really need that space for things like network buffers and other map regions. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 15:56:23 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C982F14E2A; Wed, 7 Jul 1999 15:56:19 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA94642; Wed, 7 Jul 1999 15:56:12 -0700 (PDT) (envelope-from dillon) Date: Wed, 7 Jul 1999 15:56:12 -0700 (PDT) From: Matthew Dillon Message-Id: <199907072256.PAA94642@apollo.backplane.com> To: David Greenman Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup References: <199907072249.PAA23598@implode.root.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : : Yes, I do - at least with the 512MB figure. That would be half of the 1GB :KVA space and large systems really need that space for things like network :buffers and other map regions. : :-DG : :David Greenman :Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org :Creator of high-performance Internet servers - http://www.terasolutions.com What would be an acceptable upper limit? 256MB? 128MB? The test I ran (Kirk's news test) ate around 60MB for the "FFS Node" memory area before the number of vnodes stabilized, on a 1GB machine. I would say that a 128MB upper limit would be too small for a 4G machine. A 256MB limit ought to work for a 4G machine Since most of those news files were small, I think Kirk's news test code is pretty much the worse case scenario as far as vnode allocation goes. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 16:11: 0 1999 Delivered-To: freebsd-current@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 57E3D154BC; Wed, 7 Jul 1999 16:10:55 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id QAA23725; Wed, 7 Jul 1999 16:09:46 -0700 (PDT) Message-Id: <199907072309.QAA23725@implode.root.com> To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup In-reply-to: Your message of "Wed, 07 Jul 1999 15:56:12 PDT." <199907072256.PAA94642@apollo.backplane.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 07 Jul 1999 16:09:46 -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >: Yes, I do - at least with the 512MB figure. That would be half of the 1GB >:KVA space and large systems really need that space for things like network >:buffers and other map regions. >: >:-DG >: >:David Greenman >:Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org >:Creator of high-performance Internet servers - http://www.terasolutions.com > > What would be an acceptable upper limit? 256MB? 128MB? The test > I ran (Kirk's news test) ate around 60MB for the "FFS Node" memory area > before the number of vnodes stabilized, on a 1GB machine. I would say > that a 128MB upper limit would be too small for a 4G machine. A 256MB > limit ought to work for a 4G machine > > Since most of those news files were small, I think Kirk's news test code > is pretty much the worse case scenario as far as vnode allocation goes. Well, I could possibly live with 256MB, but the vnode/fsnode consumption seems to be getting a bit silly in the memory overhead department, even for machines with 4GB of RAM. It seems like there needs to be fewer of them and/or they need to go on a diet. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 16:23:38 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 8A3DD14D34; Wed, 7 Jul 1999 16:23:33 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA94794; Wed, 7 Jul 1999 16:23:29 -0700 (PDT) (envelope-from dillon) Date: Wed, 7 Jul 1999 16:23:29 -0700 (PDT) From: Matthew Dillon Message-Id: <199907072323.QAA94794@apollo.backplane.com> To: David Greenman Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup References: <199907072309.QAA23725@implode.root.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> limit ought to work for a 4G machine :> :> Since most of those news files were small, I think Kirk's news test code :> is pretty much the worse case scenario as far as vnode allocation goes. : : Well, I could possibly live with 256MB, but the vnode/fsnode consumption :seems to be getting a bit silly in the memory overhead department, even for :machines with 4GB of RAM. It seems like there needs to be fewer of them :and/or they need to go on a diet. : :-DG : :David Greenman Well, the problem occurs because the system has sufficient memory to keep the underlying VM object around. The current vnode code will not place a vnode on the free list until the underlying VM object goes away. The 60MB worth of KVM being used to hold vnodes is supporting 1GB worth of cached VM pages ( associated with small files, that is ). So even though the numbers look strange, it does seem to scale. In order to turn the maxvnodes sysctl into a harder limit, the vnode allocation & freeing code would have to be reworked some. Right now vnodes are not placed back onto the free list until their underlying VM objects go away. We would need to make the vnode lists (which are headed by mount table entries) LRU and then attempt to reuse the vnodes that way, destroying the underlying VM object when necessary. Alternatively we can try to make the vnode structure smaller, or we could try to decouple the vnode from the VM object and instead reference the VM object by inode. All I can say to that: Yuch. I'd rather just bump up the KVM. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 16:26:37 1999 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 1FBBB14D34; Wed, 7 Jul 1999 16:26:17 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40363>; Thu, 8 Jul 1999 09:08:30 +1000 Date: Thu, 8 Jul 1999 09:26:09 +1000 From: Peter Jeremy Subject: Re: Heh heh, humorous lockup To: freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Message-Id: <99Jul8.090830est.40363@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Greenman wrote: > Yes, I do - at least with the 512MB figure. That would be half of the 1GB >KVA space and large systems really need that space for things like network >buffers and other map regions. Matthew Dillon wrote: > What would be an acceptable upper limit? 256MB? 128MB? The test > I ran (Kirk's news test) ate around 60MB for the "FFS Node" memory area > before the number of vnodes stabilized, on a 1GB machine. I would say > that a 128MB upper limit would be too small for a 4G machine. A 256MB > limit ought to work for a 4G machine It appears we're rapidly approaching the point where 32-bits isn't enough. We could increase KVA - but that cuts into process VM space (and a large machine is likely to have large processes). The other option is moving away from a flat memory model: How about putting some of the larger kernel-only data-structures into another segment? The downside is that unless we want to start passing `far' pointers around (which is both ugly and inefficient), we need to make the pointer address space transparent to the compiler. Of course, with proper data-hiding, this exercise is fairly trivial - only the functions that physically reference the object need to know where it is. But I don't think the kernel is structured in this way (for good and valid reasons - CS theoreticians notwithstanding). And any bugs (like `cheating' by not accessing data through the approved mechanisms) will lead to fairly obscure panics (the address is perfectly valid - it's just the wrong segment). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 16:35:15 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 69C1A14CCB; Wed, 7 Jul 1999 16:35:08 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA94883; Wed, 7 Jul 1999 16:34:02 -0700 (PDT) (envelope-from dillon) Date: Wed, 7 Jul 1999 16:34:02 -0700 (PDT) From: Matthew Dillon Message-Id: <199907072334.QAA94883@apollo.backplane.com> To: Peter Jeremy Cc: freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup References: <99Jul8.090830est.40363@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :It appears we're rapidly approaching the point where 32-bits isn't :enough. We could increase KVA - but that cuts into process VM space :(and a large machine is likely to have large processes). True, though what we are talking about here is scaling issue with main memory. We should be able to fit everything necessary to support 4GB of ram into a 1GB of KVM. That we aren't means we are doing something wrong somewhere. :The other option is moving away from a flat memory model: How about :putting some of the larger kernel-only data-structures into another :segment? The downside is that unless we want to start passing `far' :pointers around (which is both ugly and inefficient), we need to :make the pointer address space transparent to the compiler. I don't think it is worth it. We would then have to switch the MMU context just going from user to supervisor mode. It would not be too hard to do that since all data movement from the user address space is encapsulated, but it just wouldn't be worth the overhead. The biggest thorn in our side is the filesystem buffer cache. If we could somehow make the KVA mappings apply only to I/O in progress and actively retrieved buffers (getblk()), we would have plenty of KVA space left over for other things. Right now it is fairly expensive to KVA map and unmap the filesystem buffer's b_data pointer. I'm not sure why. :Of course, with proper data-hiding, this exercise is fairly trivial - :only the functions that physically reference the object need to know :where it is. But I don't think the kernel is structured in this way :(for good and valid reasons - CS theoreticians notwithstanding). And :any bugs (like `cheating' by not accessing data through the approved :mechanisms) will lead to fairly obscure panics (the address is :perfectly valid - it's just the wrong segment). : :Peter -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 16:36:24 1999 Delivered-To: freebsd-current@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id AA5AC15106; Wed, 7 Jul 1999 16:36:10 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id QAA23809; Wed, 7 Jul 1999 16:34:59 -0700 (PDT) Message-Id: <199907072334.QAA23809@implode.root.com> To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup In-reply-to: Your message of "Wed, 07 Jul 1999 16:23:29 PDT." <199907072323.QAA94794@apollo.backplane.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 07 Jul 1999 16:34:59 -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >:> limit ought to work for a 4G machine >:> >:> Since most of those news files were small, I think Kirk's news test code >:> is pretty much the worse case scenario as far as vnode allocation goes. >: >: Well, I could possibly live with 256MB, but the vnode/fsnode consumption >:seems to be getting a bit silly in the memory overhead department, even for >:machines with 4GB of RAM. It seems like there needs to be fewer of them >:and/or they need to go on a diet. > > Well, the problem occurs because the system has sufficient memory to keep > the underlying VM object around. The current vnode code will not place > a vnode on the free list until the underlying VM object goes away. The > 60MB worth of KVM being used to hold vnodes is supporting 1GB worth > of cached VM pages ( associated with small files, that is ). So even > though the numbers look strange, it does seem to scale. > > In order to turn the maxvnodes sysctl into a harder limit, the vnode > allocation & freeing code would have to be reworked some. Right now > vnodes are not placed back onto the free list until their underlying > VM objects go away. We would need to make the vnode lists (which are > headed by mount table entries) LRU and then attempt to reuse the vnodes > that way, destroying the underlying VM object when necessary. > > Alternatively we can try to make the vnode structure smaller, or we > could try to decouple the vnode from the VM object and instead reference > the VM object by inode. All I can say to that: Yuch. I'd rather just > bump up the KVM. We've been here before, a couple of times. This started to become an issue when the limits were removed and has gotten worse as the vnode and fsnode structs have grown over time. We're running into some limits on how much space we can give to the kernel since there are a number of folks which think that 3GB of process VA space is a minimum. I tend to think that the 2GB/2GB split that I use on wcarchive is probably more appropriate as a default, but like I say, others disagree. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 16:55:49 1999 Delivered-To: freebsd-current@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 8C7BF14E9D; Wed, 7 Jul 1999 16:55:37 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id QAA25930; Wed, 7 Jul 1999 16:55:29 -0700 (PDT) Date: Wed, 7 Jul 1999 16:55:28 -0700 (PDT) From: Julian Elischer To: Matthew Dillon Cc: David Greenman , freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup In-Reply-To: <199907072323.QAA94794@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 7 Jul 1999, Matthew Dillon wrote: > :> limit ought to work for a 4G machine > :> > :> Since most of those news files were small, I think Kirk's news test code > :> is pretty much the worse case scenario as far as vnode allocation goes. > : > : Well, I could possibly live with 256MB, but the vnode/fsnode consumption > :seems to be getting a bit silly in the memory overhead department, even for > :machines with 4GB of RAM. It seems like there needs to be fewer of them > :and/or they need to go on a diet. > : > :-DG > : > :David Greenman > > Well, the problem occurs because the system has sufficient memory to keep > the underlying VM object around. The current vnode code will not place > a vnode on the free list until the underlying VM object goes away. The > 60MB worth of KVM being used to hold vnodes is supporting 1GB worth > of cached VM pages ( associated with small files, that is ). So even > though the numbers look strange, it does seem to scale. > > In order to turn the maxvnodes sysctl into a harder limit, the vnode > allocation & freeing code would have to be reworked some. Right now > vnodes are not placed back onto the free list until their underlying > VM objects go away. We would need to make the vnode lists (which are > headed by mount table entries) LRU and then attempt to reuse the vnodes > that way, destroying the underlying VM object when necessary. > > Alternatively we can try to make the vnode structure smaller, or we > could try to decouple the vnode from the VM object and instead reference > the VM object by inode. All I can say to that: Yuch. I'd rather just > bump up the KVM. or do what Kirk wants to do and merge the VM and Vnode structures I belive the UVM does a bit in this direction due to kirk's influence. julian > > -Matt > Matthew Dillon > > > > > To Unsubscribe: send mail to majordomo@FreeBSD..org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 17: 1:18 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id BC14D1510E; Wed, 7 Jul 1999 17:01:05 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA95104; Wed, 7 Jul 1999 17:01:02 -0700 (PDT) (envelope-from dillon) Date: Wed, 7 Jul 1999 17:01:02 -0700 (PDT) From: Matthew Dillon Message-Id: <199907080001.RAA95104@apollo.backplane.com> To: David Greenman Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup References: <199907072334.QAA23809@implode.root.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : We've been here before, a couple of times. This started to become an issue :when the limits were removed and has gotten worse as the vnode and fsnode :structs have grown over time. We're running into some limits on how much :space we can give to the kernel since there are a number of folks which :think that 3GB of process VA space is a minimum. I tend to think that the :2GB/2GB split that I use on wcarchive is probably more appropriate as a :default, but like I say, others disagree. : :-DG : :David Greenman If we added the capability to the buffer cache to delete B_DELWRI B_VMIO buffers (leaving dirty VM pages behind), we could reduce the size of the filesystem buffer cache considerably while at the same time improve our ability to cache dirty data - assuming all the other problems related to doing that sort of thing get fixed, that is. I am heading this way already as are others -- the filesystem buffer cache really needs to be relegated to handling active I/O and filesystem mappings, not holding onto dirty data for dear life. This would require keeping track of most dirty pages, which isn't too hard to do - we split the vm_object page list into a clean and a dirty list, and we keep the notion of clean and dirty vnodes so the update daemon doesn't change. If we can reduce the size of the filesystem buffer cache to something reasonable, more KVA space will be available for other kernel things. -- The biggest stumbling block to doing this is the reconstitution overhead of the buffer cache, as demonstrated by this simple test. As you can see by this test, the cost of reconstituting a filesystem buffer on a pentium-Pro 200 is roughly equivalent to 27 MBytes/sec worth of bandwidth. Create a big file: dd if=/dev/zero of=test bs=32k count=4096 DD back in (several times) a block big enough to fit in the VM page cache but not big enough to fit into the filesystem buffer cache. No actual disk I/O occurs: dd if=test of=/dev/null bs=32k count=256 8388608 bytes transferred in 0.146539 secs (57244848 bytes/sec) DD back in (several times) a block big enough to fit in the VM page cache *AND* the filesystem buffer cache. No actual disk I/O occurs: apollo:/usr/obj# dd if=test of=/dev/null bs=32k count=64 2097152 bytes transferred in 0.024780 secs (84630712 bytes/sec) -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 17: 3: 2 1999 Delivered-To: freebsd-current@freebsd.org Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (Postfix) with ESMTP id E19B01506C for ; Wed, 7 Jul 1999 17:02:54 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.2/8.8.8) id BAA08642; Thu, 8 Jul 1999 01:02:52 +0100 (BST) (envelope-from joe) Date: Thu, 8 Jul 1999 01:02:52 +0100 From: Josef Karthauser To: Brian Somers Cc: freebsd-current@FreeBSD.org, Wayne Self Subject: Re: userland ppp - startup Message-ID: <19990708010252.A7999@pavilion.net> References: <19990707103746.A30024@pavilion.net> <199907072102.WAA19958@dev.lan.awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199907072102.WAA19958@dev.lan.awfulhak.org>; from Brian Somers on Wed, Jul 07, 1999 at 10:02:44PM +0100 X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, 24 The Old Steine, Brighton, BN1 1EL, England Phone: +44-845-333-5000 Fax: +44-845-333-5001 Mobile: +44-403-596893 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 07, 1999 at 10:02:44PM +0100, Brian Somers wrote: > > Ha, and you thought it'd be straight forward ;^P > ;b just time mate :) I'm off on holiday on Saturday, until the next Sunday. Day off work on the Monday. If I don't get it tied up before I go I'll finish it on my return. Joe -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 17: 3:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C24EE154D5; Wed, 7 Jul 1999 17:03:21 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA95132; Wed, 7 Jul 1999 17:03:16 -0700 (PDT) (envelope-from dillon) Date: Wed, 7 Jul 1999 17:03:16 -0700 (PDT) From: Matthew Dillon Message-Id: <199907080003.RAA95132@apollo.backplane.com> To: Julian Elischer Cc: David Greenman , freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :or do what Kirk wants to do and merge the VM and Vnode structures :I belive the UVM does a bit in this direction due to kirk's influence. : :julian If this could result in a smaller overall structure, it may be worth it. To really make the combined structure smaller we would also have to pair-down the fields in both structures. For example, the vnode structure contains a lot of temporary clustering fields that could be removed entirely if clustering operations are done at the time of the actual I/O rather then before hand ( which leads to other problems related to low-memory deadlocks :-(... but assuming that could be fixed... ). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 17:13:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 5669C14FAC; Wed, 7 Jul 1999 17:13:17 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id RAA19187; Wed, 7 Jul 1999 17:12:54 -0700 (PDT) Message-Id: <199907080012.RAA19187@lestat.nas.nasa.gov> To: Julian Elischer Cc: Matthew Dillon , David Greenman , freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup Reply-To: Jason Thorpe From: Jason Thorpe Date: Wed, 07 Jul 1999 17:12:53 -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 7 Jul 1999 16:55:28 -0700 (PDT) Julian Elischer wrote: > or do what Kirk wants to do and merge the VM and Vnode structures > I belive the UVM does a bit in this direction due to kirk's influence. A uvm_object is not a standalone thing in UVM. Every thing that's mappable in UVM has a uvm_object embedded in it. In the case of vnodes, a vnode contains a uvm_vnode, which in turn contains a uvm_object. This has direct performance benefits as described in both Chuck's thesis and in his USENIX paper. Now, in the case of the chs-ubc2 branch of the NetBSD source tree, which is where the unified buffer cache work is happening, there is almost no distinction between a vnode and an object. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 17:16:10 1999 Delivered-To: freebsd-current@freebsd.org Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (Postfix) with ESMTP id 6268A14C88 for ; Wed, 7 Jul 1999 17:16:01 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.2/8.8.8) id BAA09624; Thu, 8 Jul 1999 01:15:47 +0100 (BST) (envelope-from joe) Date: Thu, 8 Jul 1999 01:15:47 +0100 From: Josef Karthauser To: "Steve O'Hara-Smith" Cc: Ladavac Marino , Wayne Self , freebsd-current@FreeBSD.ORG, Mark Thomas , Brian Somers Subject: Re: userland ppp - startup Message-ID: <19990708011546.A9459@pavilion.net> References: <55586E7391ACD211B9730000C11002761796DB@r-lmh-wi-100.corpnet.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Steve O'Hara-Smith on Wed, Jul 07, 1999 at 01:00:46PM +0100 X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, 24 The Old Steine, Brighton, BN1 1EL, England Phone: +44-845-333-5000 Fax: +44-845-333-5001 Mobile: +44-403-596893 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 07, 1999 at 01:00:46PM +0100, Steve O'Hara-Smith wrote: > > On 07-Jul-99 Ladavac Marino wrote: > > sysinstall drops you into ppp and you have to use the term > command to log in manually. Ahha, it's not quite as bad as that. sysinstall asks you some questions and writes a ppp.conf by hand. I was envisaging that you needed to know ppp terminal commands - Doh! Joe -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 17:21:19 1999 Delivered-To: freebsd-current@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 7B582154D7; Wed, 7 Jul 1999 17:21:04 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id RAA26717; Wed, 7 Jul 1999 17:20:55 -0700 (PDT) Date: Wed, 7 Jul 1999 17:20:54 -0700 (PDT) From: Julian Elischer To: Jason Thorpe Cc: Matthew Dillon , David Greenman , freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup In-Reply-To: <199907080012.RAA19187@lestat.nas.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 7 Jul 1999, Jason Thorpe wrote: > On Wed, 7 Jul 1999 16:55:28 -0700 (PDT) > Julian Elischer wrote: > > > or do what Kirk wants to do and merge the VM and Vnode structures > > I belive the UVM does a bit in this direction due to kirk's influence. > > A uvm_object is not a standalone thing in UVM. Every thing that's > mappable in UVM has a uvm_object embedded in it. > > In the case of vnodes, a vnode contains a uvm_vnode, which in turn contains > a uvm_object. This has direct performance benefits as described in both > Chuck's thesis and in his USENIX paper. > > Now, in the case of the chs-ubc2 branch of the NetBSD source tree, which is > where the unified buffer cache work is happening, there is almost no > distinction between a vnode and an object. Yes, I understand... I was simplifying :-) > > -- Jason R. Thorpe > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 17:24:12 1999 Delivered-To: freebsd-current@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 225A314C88; Wed, 7 Jul 1999 17:24:02 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id RAA19330; Wed, 7 Jul 1999 17:23:57 -0700 (PDT) Message-Id: <199907080023.RAA19330@lestat.nas.nasa.gov> To: Matthew Dillon Cc: Julian Elischer , David Greenman , freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup Reply-To: Jason Thorpe From: Jason Thorpe Date: Wed, 07 Jul 1999 17:23:57 -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 7 Jul 1999 17:03:16 -0700 (PDT) Matthew Dillon wrote: > If this could result in a smaller overall structure, it may be worth it. > To really make the combined structure smaller we would also have to > pair-down the fields in both structures. For example, the vnode structure > contains a lot of temporary clustering fields that could be removed > entirely if clustering operations are done at the time of the actual I/O > rather then before hand ( which leads to other problems related to > low-memory deadlocks :-(... but assuming that could be fixed... ). The way this is done in the still-in-development branch of NetBSD's unified buffer cache is to basically elimiate the old buffer cache interface for vnode read/write completely. When you want to do that sort of I/O to a vnode, you simply map a window of the object into KVA space (via ubc_alloc()), do the uiomove (lettings the pages fault in as necessary, getting added to the vnode's memq), and release the window (via ubc_release()). The actual window mappings themselves can persist, as well (although those mappings are nuked immediately if the vnode is marked VTEXT on VAC machines, to eliminate bad cache interactions). Clustering is done by the same clustered pagein/pageout that already exists in UVM. In addition, as described in the UVM paper at USENIX, placing the object directly in the vnode (which requires a somewhat fundamental change in the objects, at least nuking the concept of object chains) allows a mapped file's pages to persist in the page cache as long as the vnode itself is not recycled, as opposed to they annoying limit on persisting vnode objects that used to exist in NetBSD's Mach VM. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 17:36:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 9A59F14C4A; Wed, 7 Jul 1999 17:36:21 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 7032B79; Thu, 8 Jul 1999 08:36:19 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Jason Thorpe Cc: Matthew Dillon , Julian Elischer , David Greenman , freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup In-reply-to: Your message of "Wed, 07 Jul 1999 17:23:57 MST." <199907080023.RAA19330@lestat.nas.nasa.gov> Date: Thu, 08 Jul 1999 08:36:19 +0800 From: Peter Wemm Message-Id: <19990708003619.7032B79@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jason Thorpe wrote: > On Wed, 7 Jul 1999 17:03:16 -0700 (PDT) > Matthew Dillon wrote: > > > If this could result in a smaller overall structure, it may be worth i t. > > To really make the combined structure smaller we would also have to > > pair-down the fields in both structures. For example, the vnode struc ture > > contains a lot of temporary clustering fields that could be removed > > entirely if clustering operations are done at the time of the actual I /O > > rather then before hand ( which leads to other problems related to > > low-memory deadlocks :-(... but assuming that could be fixed... ). > > The way this is done in the still-in-development branch of NetBSD's > unified buffer cache is to basically elimiate the old buffer cache > interface for vnode read/write completely. When you want to do that > sort of I/O to a vnode, you simply map a window of the object into > KVA space (via ubc_alloc()), do the uiomove (lettings the pages fault > in as necessary, getting added to the vnode's memq), and release the > window (via ubc_release()). The actual window mappings themselves can > persist, as well (although those mappings are nuked immediately if the > vnode is marked VTEXT on VAC machines, to eliminate bad cache interactions). Out of curiosity, how does it handle the problem of small 512 byte directories? Does it consume a whole page or does it do something smarter? Or does the ubc work apply to read/write only and the filesystem itself continues to use the buffer cache interfaces for metadata and directories still? Does the caching part of the bio system still exist? Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 17:43:56 1999 Delivered-To: freebsd-current@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 2267714C4A; Wed, 7 Jul 1999 17:43:44 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id RAA19553; Wed, 7 Jul 1999 17:43:28 -0700 (PDT) Message-Id: <199907080043.RAA19553@lestat.nas.nasa.gov> To: Peter Wemm Cc: Matthew Dillon , Julian Elischer , David Greenman , freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup Reply-To: Jason Thorpe From: Jason Thorpe Date: Wed, 07 Jul 1999 17:43:27 -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 08 Jul 1999 08:36:19 +0800 Peter Wemm wrote: > Out of curiosity, how does it handle the problem of small 512 byte > directories? Does it consume a whole page or does it do something smarter? > Or does the ubc work apply to read/write only and the filesystem itself > continues to use the buffer cache interfaces for metadata and directories > still? Does the caching part of the bio system still exist? At the moment, only VREG is handled w/ UBC. We plan on addressing that in the future. In the case of file system blocks smaller than a page size, multiple blocks are read into the page. In the case of small directories, "we'll burn that bridge when we come to it" (i.e. when we attempt to deal with non-VREG). So, the caching part of the bio interface still exists for now (in part, this helps us to use file systems which haven't yet been converted to the UBC interface). -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 18:21:17 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 2214714D75; Wed, 7 Jul 1999 18:21:06 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA95641; Wed, 7 Jul 1999 18:21:03 -0700 (PDT) (envelope-from dillon) Date: Wed, 7 Jul 1999 18:21:03 -0700 (PDT) From: Matthew Dillon Message-Id: <199907080121.SAA95641@apollo.backplane.com> To: Jason Thorpe Cc: Julian Elischer , David Greenman , freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup References: <199907080023.RAA19330@lestat.nas.nasa.gov> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :The way this is done in the still-in-development branch of NetBSD's :unified buffer cache is to basically elimiate the old buffer cache :interface for vnode read/write completely. When you want to do that :sort of I/O to a vnode, you simply map a window of the object into :KVA space (via ubc_alloc()), do the uiomove (lettings the pages fault :in as necessary, getting added to the vnode's memq), and release the :window (via ubc_release()). The actual window mappings themselves can :persist, as well (although those mappings are nuked immediately if the :vnode is marked VTEXT on VAC machines, to eliminate bad cache interactions). Effectively this is what a piece of our buffer cache code does now. The problem is the other 60% of the buffer cache code that does the more complex stuff. I'd like to see our buffer cache devolve into just the I/O and mapping piece. Now, I also believe that when UVM maps those pages, it makes them copy-on-write so I/O can be initiated on the data without having to stall anyone attempting to make further modifications to the VM object. Is this correct? This is something I would like to throw into FreeBSD at some point. It would get rid of all the freeze/bogus-page hacks already in there and avoid a number of I/O blocking conditions that we currently face. However, I do not like the idea of taking page faults in kernel mode, which I believe UVM also does -- but I think the above could be implemented in FreeBSD without taking page faults. :In addition, as described in the UVM paper at USENIX, placing the :object directly in the vnode (which requires a somewhat fundamental :change in the objects, at least nuking the concept of object chains) Well, I do not like the "nuke the object chains" part of UVM. From what I can tell UVM is doing a considerable amount of extra work to avoid the object chain stuff, but only saving a small amount of overhead on vm_fault's ( though, compared to the original Mach stuff the UVM stuff is much, much better ). We've made a considerable number of improvements to our vm_object's in the last few months. But I do like the idea of a VM-specific substructure for vnodes and I do agree that embedding the master VM object in the vnode is a good idea. -Matt Matthew Dillon :allows a mapped file's pages to persist in the page cache as long as :the vnode itself is not recycled, as opposed to they annoying limit :on persisting vnode objects that used to exist in NetBSD's Mach VM. : : -- Jason R. Thorpe : : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 18:27:40 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C6A2D14D75; Wed, 7 Jul 1999 18:27:26 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA95703; Wed, 7 Jul 1999 18:27:23 -0700 (PDT) (envelope-from dillon) Date: Wed, 7 Jul 1999 18:27:23 -0700 (PDT) From: Matthew Dillon Message-Id: <199907080127.SAA95703@apollo.backplane.com> To: Jason Thorpe Cc: Peter Wemm , Julian Elischer , David Greenman , freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup References: <199907080043.RAA19553@lestat.nas.nasa.gov> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Thu, 08 Jul 1999 08:36:19 +0800 : Peter Wemm wrote: : : > Out of curiosity, how does it handle the problem of small 512 byte : > directories? Does it consume a whole page or does it do something smarter? : > Or does the ubc work apply to read/write only and the filesystem itself : > continues to use the buffer cache interfaces for metadata and directories : > still? Does the caching part of the bio system still exist? : :At the moment, only VREG is handled w/ UBC. We plan on addressing that :in the future. : :In the case of file system blocks smaller than a page size, multiple :blocks are read into the page. In the case of small directories, :"we'll burn that bridge when we come to it" (i.e. when we attempt to :deal with non-VREG). : :So, the caching part of the bio interface still exists for now (in part, :this helps us to use file systems which haven't yet been converted to :the UBC interface). : : -- Jason R. Thorpe I would also like to add that FreeBSD's current method of handling small directories does not work very well. It saves memory, sure, but it is based on specialized B_MALLOC buffers in the buffer cache and is unable to use the wider-ranging VM page cache. Since we do not keep buffers around for very long and non-VMIO-backed memory goes away with the buffer, the result is that FreeBSD does a terrible job caching directories. DG and I have experimented with turning on VMIO backing for directories. It works except for a bug in softupdates which I am going to get Kirk interested in (so hopefully it will get fixed). John Dyson is against it due to the waste in memory but I am of the opinion that the waste will not be that bad - and, in anycase, the worst that can happen is that we will throw pages containing directory data away that would have long since been thrown away with the old buffer cache mechanism anyway. For FreeBSD, the changes are so simple that we can add a sysctl to turn the capability on and off. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 18:35: 1 1999 Delivered-To: freebsd-current@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 735EB150DF; Wed, 7 Jul 1999 18:34:50 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id LAA11251; Thu, 8 Jul 1999 11:04:49 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id LAA04756; Thu, 8 Jul 1999 11:04:47 +0930 (CST) Date: Thu, 8 Jul 1999 11:04:47 +0930 From: Greg Lehey To: Peter Jeremy Cc: freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Bursting at the seams (was: Heh heh, humorous lockup) Message-ID: <19990708110446.P2340@freebie.lemis.com> References: <99Jul8.090830est.40363@border.alcanet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <99Jul8.090830est.40363@border.alcanet.com.au>; from Peter Jeremy on Thu, Jul 08, 1999 at 09:26:09AM +1000 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 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thursday, 8 July 1999 at 9:26:09 +1000, Peter Jeremy wrote: > David Greenman wrote: >> Yes, I do - at least with the 512MB figure. That would be half of the 1GB >> KVA space and large systems really need that space for things like network >> buffers and other map regions. > > Matthew Dillon wrote: >> What would be an acceptable upper limit? 256MB? 128MB? The test >> I ran (Kirk's news test) ate around 60MB for the "FFS Node" memory area >> before the number of vnodes stabilized, on a 1GB machine. I would say >> that a 128MB upper limit would be too small for a 4G machine. A 256MB >> limit ought to work for a 4G machine > > It appears we're rapidly approaching the point where 32-bits isn't > enough. We could increase KVA - but that cuts into process VM space > (and a large machine is likely to have large processes). > > The other option is moving away from a flat memory model: How about > putting some of the larger kernel-only data-structures into another > segment? The downside is that unless we want to start passing `far' > pointers around (which is both ugly and inefficient), we need to > make the pointer address space transparent to the compiler. Why not put the kernel in a different address space? IIRC there's no absolute requirement for the kernel and userland to be in the same address space, and that way we would have 4 GB for each. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 18:37:59 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 0989114D75; Wed, 7 Jul 1999 18:37:49 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA95818; Wed, 7 Jul 1999 18:37:35 -0700 (PDT) (envelope-from dillon) Date: Wed, 7 Jul 1999 18:37:35 -0700 (PDT) From: Matthew Dillon Message-Id: <199907080137.SAA95818@apollo.backplane.com> To: Greg Lehey Cc: Peter Jeremy , freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Bursting at the seams (was: Heh heh, humorous lockup) References: <99Jul8.090830est.40363@border.alcanet.com.au> <19990708110446.P2340@freebie.lemis.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Why not put the kernel in a different address space? IIRC there's no :absolute requirement for the kernel and userland to be in the same :address space, and that way we would have 4 GB for each. : :Greg No, the syscall overhead is way too high if we have to mess with MMU context. This would work fine on certain cpus with hardware PID support, such as the MIPS, but the entire TLB is wiped when you change the mmu context on an Intel cpu. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 19: 0: 7 1999 Delivered-To: freebsd-current@freebsd.org Received: from rina.naklab.dnj.ynu.ac.jp (rina.naklab.dnj.ynu.ac.jp [133.34.17.16]) by hub.freebsd.org (Postfix) with ESMTP id 574F414EF1; Wed, 7 Jul 1999 19:00:00 -0700 (PDT) (envelope-from tanimura@naklab.dnj.ynu.ac.jp) Received: from rina.naklab.dnj.ynu.ac.jp (localhost [127.0.0.1]) by rina.naklab.dnj.ynu.ac.jp (8.9.1a/3.7W-Naklab-2.1-19981120) with ESMTP id KAA20622; Thu, 8 Jul 1999 10:59:58 +0900 (JST) Message-Id: <199907080159.KAA20622@rina.naklab.dnj.ynu.ac.jp> To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Cc: Seigo Tanimura Subject: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) From: Seigo Tanimura In-Reply-To: Your message of "Tue, 06 Jul 1999 18:59:23 +0900" References: <199907060959.SAA05637@rina.naklab.dnj.ynu.ac.jp> X-Mailer: Mew version 1.70 on Emacs 19.34.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 08 Jul 1999 10:59:58 +0900 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Another idea has come to my mind... pca(4) currently uses acquire_timer0(), which changes the timer frequency directly, breaking finetimer(9). I am considering to move acquire_timer0()s in pca(4) to finetimer(9), so that pca(4) comes to work again. Furthermore, we can get rid of acquire_timer0() and the related stuff in clkintr() to be much more simple than now. Any comments? Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 19: 5:12 1999 Delivered-To: freebsd-current@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 69EFA14BCD; Wed, 7 Jul 1999 19:04:46 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id TAA32439; Wed, 7 Jul 1999 19:04:27 -0700 (PDT) Date: Wed, 7 Jul 1999 19:04:26 -0700 (PDT) From: Julian Elischer To: Matthew Dillon Cc: Greg Lehey , Peter Jeremy , freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Bursting at the seams (was: Heh heh, humorous lockup) In-Reply-To: <199907080137.SAA95818@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG we already use the gs register for SMP now.. what about the fs register? I vaguely remember that the different segments could be used to achieve this.... (%fs points to user space or something) julian On Wed, 7 Jul 1999, Matthew Dillon wrote: > :Why not put the kernel in a different address space? IIRC there's no > :absolute requirement for the kernel and userland to be in the same > :address space, and that way we would have 4 GB for each. > : > :Greg > > No, the syscall overhead is way too high if we have to mess with MMU > context. This would work fine on certain cpus with hardware PID support, > such as the MIPS, but the entire TLB is wiped when you change the mmu > context on an Intel cpu. > > -Matt > Matthew Dillon > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 19: 7: 4 1999 Delivered-To: freebsd-current@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id B791B14BCF; Wed, 7 Jul 1999 19:06:54 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id TAA32652; Wed, 7 Jul 1999 19:06:49 -0700 (PDT) Date: Wed, 7 Jul 1999 19:06:48 -0700 (PDT) From: Julian Elischer To: Seigo Tanimura Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) In-Reply-To: <199907080159.KAA20622@rina.naklab.dnj.ynu.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG uh... [phaser.whistle.com] 536 man 9 finetimer No entry for finetimer in section 9 of the manual On Thu, 8 Jul 1999, Seigo Tanimura wrote: > Another idea has come to my mind... > > > pca(4) currently uses acquire_timer0(), which changes the timer > frequency directly, breaking finetimer(9). I am considering to > move acquire_timer0()s in pca(4) to finetimer(9), so that pca(4) > comes to work again. Furthermore, we can get rid of acquire_timer0() > and the related stuff in clkintr() to be much more simple than now. > > > Any comments? > > > Seigo Tanimura > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 19:16: 1 1999 Delivered-To: freebsd-current@freebsd.org Received: from rina.naklab.dnj.ynu.ac.jp (rina.naklab.dnj.ynu.ac.jp [133.34.17.16]) by hub.freebsd.org (Postfix) with ESMTP id 0460514BCD; Wed, 7 Jul 1999 19:15:56 -0700 (PDT) (envelope-from tanimura@naklab.dnj.ynu.ac.jp) Received: from rina.naklab.dnj.ynu.ac.jp (localhost [127.0.0.1]) by rina.naklab.dnj.ynu.ac.jp (8.9.1a/3.7W-Naklab-2.1-19981120) with ESMTP id LAA20789; Thu, 8 Jul 1999 11:15:45 +0900 (JST) Message-Id: <199907080215.LAA20789@rina.naklab.dnj.ynu.ac.jp> To: julian@whistle.com Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Cc: Seigo Tanimura Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) From: Seigo Tanimura In-Reply-To: Your message of "Wed, 7 Jul 1999 19:06:48 -0700 (PDT)" References: X-Mailer: Mew version 1.70 on Emacs 19.34.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 08 Jul 1999 11:15:45 +0900 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 7 Jul 1999 19:06:48 -0700 (PDT), Julian Elischer said: julian> uh... julian> [phaser.whistle.com] 536 man 9 finetimer julian> No entry for finetimer in section 9 of the manual Sorry, finetimer(9) is the new timer implemented in my latest midi driver. You can read the short paper describing the feature and principle in: Message-Id: <199907060959.SAA05637@rina.naklab.dnj.ynu.ac.jp> finetimer(9) has the same interface functions as timeout(9), so it should be easy to use it. Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 19:16:27 1999 Delivered-To: freebsd-current@freebsd.org Received: from mailman.cs.ucla.edu (Mailman.CS.UCLA.EDU [131.179.128.30]) by hub.freebsd.org (Postfix) with ESMTP id 5A96615493 for ; Wed, 7 Jul 1999 19:16:21 -0700 (PDT) (envelope-from scottm@mordred.cs.ucla.edu) Received: from mordred.cs.ucla.edu (mordred.cs.ucla.edu [131.179.192.128]) by mailman.cs.ucla.edu (8.9.1/UCLACS-5.0) with ESMTP id TAA06645 for ; Wed, 7 Jul 1999 19:16:15 -0700 (PDT) Received: from mordred.cs.ucla.edu (localhost [127.0.0.1]) by mordred.cs.ucla.edu (8.9.3/8.9.3) with ESMTP id TAA00329 for ; Wed, 7 Jul 1999 19:16:18 -0700 (PDT) (envelope-from scottm@mordred.cs.ucla.edu) Message-Id: <199907080216.TAA00329@mordred.cs.ucla.edu> To: freebsd-current@freebsd.org Subject: Panic in spec_strategy() MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <326.931400177.1@mordred.cs.ucla.edu> Date: Wed, 07 Jul 1999 19:16:18 -0700 From: Scott Michel Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -current kernel as of 1700 PST (or thereabouts): spec_strategy+0x31: movl 0x28(%eax), eax Note: %eax = 0 Traceback: -------------------------------------------------------------------------- spec_strategy(c3d27dd0,c3d27dac,c01cbe1,c3d27dd0,c3d27ddc) at spec_strategy+0x31 spec_vnoperate(c3d27dd0,c3d27ddc,c01d84bb,c3d27dd0,c1b24160) at spec_vnoperate+0x15 ufs_vnoperate(c3d27dd0,c1b24160,12,2,c00e0c40) at ufs_vnoperate+0x15 swstrategy(c1b241b0,e500,c0475c70,c3d27e2c,c01cc872) at swstrategy+0x14f spec_strategy(c3d27e20) at spec_strategy+0x36 swap_pager_putpages(c4340c3c,c3d273ed8,2,0,c3d27e64) at swap_pager_putpages+0x03de default_pager_putpages(c4340c3c,c3d273ed8,2,0,c3d27e64) at default_pager_putpages+0x17 vm_pageout_flush(c3d27ed8,2,0,c014aacd,ffffffff) at vm_pageout_flush+0x93 vm_pageout_clean(c046ccc40,80000000,c01d7868,a000,0) at vm_pageout_clean+0x1e5 vm_pageout_scan(80000000,0,0,c0331ff4,c01f5ebc) at vm_pageout_scan+0x44e vm_pageout(0) fork_trampoline... My current config: -------------------------------------------------------------------------- machine "i386" ident MORDRED maxusers 10 cpu "I586_CPU" # aka Pentium(tm) options PQ_HUGECACHE options CPU_WT_ALLOC options "NO_F00F_HACK" options "COMPAT_43" options USER_LDT options SYSVSHM options SYSVSEM options SYSVMSG options "MD5" options DDB options KTRACE #kernel tracing options PERFMON options UCONSOLE options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options INET #Internet communications protocols pseudo-device ether #Generic Ethernet pseudo-device loop #Network loopback device pseudo-device bpf 4 #Berkeley packet filter pseudo-device disc #Discard device options TCP_COMPAT_42 #emulate 4.2BSD TCP bugs options MROUTING # Multicast routing options FFS #Fast filesystem options MFS #Memory File System options NFS #Network File System options NFS_NOSERVER options CD9660 #ISO 9660 filesystem options MSDOSFS #MS DOS File System options PROCFS #Process filesystem options FFS_ROOT #FFS usable as root device options SOFTUPDATES options NSWAPDEV=2 options QUOTA #enable disk quotas options CD9660_ROOTDELAY=20 options NFS_MINATTRTIMO=3 # VREG attrib cache timeout in sec options NFS_MAXATTRTIMO=60 options NFS_MINDIRATTRTIMO=30 # VDIR attrib cache timeout in sec options NFS_MAXDIRATTRTIMO=60 options NFS_GATHERDELAY=10 # Default write gather delay (msec) options NFS_UIDHASHSIZ=29 # Tune the size of nfssvc_sock with this options NFS_WDELAYHASHSIZ=16 # and with this options NFS_MUIDHASHSIZ=63 # Tune the size of nfsmount with this options "P1003_1B" options "_KPOSIX_PRIORITY_SCHEDULING" options _KPOSIX_VERSION=199309L controller scbus0 #base SCSI code device da0 #SCSI direct access devices (aka disks) device da1 device cd0 #SCSI CD-ROMs device pass0 #CAM passthrough driver device pt0 at scbus? options SCSI_DELAY=8000 # Be pessimistic about Joe SCSI device options CHANGER_MIN_BUSY_SECONDS=2 options CHANGER_MAX_BUSY_SECONDS=10 pseudo-device pty 16 #Pseudo ttys - can go as high as 256 pseudo-device speaker #Play IBM BASIC-style noises out your speaker pseudo-device gzip #Exec gzipped a.out's options MSGBUF_SIZE=40960 controller isa0 controller pnp0 options VESA pseudo-device splash device sc0 at isa? options MAXCONS=8 # number of virtual consoles options SC_HISTORY_SIZE=200 # number of history buffer lines device npx0 at nexus? port IO_NPX iosiz 0x0 flags 0x0 irq 13 controller fdc0 at isa? port "IO_FD1" irq 6 drq 2 disk fd0 at fdc0 drive 0 controller atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device psm0 at atkbdc? port IO_KBD conflicts irq 12 device sio0 at isa? port "IO_COM1" flags 0x10 irq 4 device sio1 at isa? port "IO_COM2" flags 0x10 irq 3 device vga0 at isa? port ? conflicts device ed0 at isa? port 0x240 irq 10 iomem 0xcc000 controller snd0 device sb0 at isa? port 0x220 irq 5 drq 3 device sbxvi0 at isa? drq 7 device sbmidi0 at isa? port 0x330 controller pci0 controller ncr0 controller ppbus0 device lpt0 at ppbus? controller ppc0 at isa? port ? irq 7 options CLK_CALIBRATION_LOOP options CLK_USE_TSC_CALIBRATION options COMPAT_LINUX options NBUF=512 options NMBCLUSTERS=512 options PANIC_REBOOT_WAIT_TIME=16 options SHOW_BUSYBUFS # List buffers that prevent root unmount controller uhci0 controller usb0 device ukbd0 device ugen0 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 19:19:16 1999 Delivered-To: freebsd-current@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 2CB8F15104; Wed, 7 Jul 1999 19:19:03 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id TAA33562; Wed, 7 Jul 1999 19:18:58 -0700 (PDT) Date: Wed, 7 Jul 1999 19:18:57 -0700 (PDT) From: Julian Elischer To: Seigo Tanimura Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) In-Reply-To: <199907080215.LAA20789@rina.naklab.dnj.ynu.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 8 Jul 1999, Seigo Tanimura wrote: > On Wed, 7 Jul 1999 19:06:48 -0700 (PDT), > Julian Elischer said: > > julian> uh... > julian> [phaser.whistle.com] 536 man 9 finetimer > julian> No entry for finetimer in section 9 of the manual > > > Sorry, finetimer(9) is the new timer implemented in my latest midi driver. > You can read the short paper describing the feature and principle in: > > Message-Id: <199907060959.SAA05637@rina.naklab.dnj.ynu.ac.jp> how do I read that? > > finetimer(9) has the same interface functions as timeout(9), so it should > be easy to use it. > > > Seigo Tanimura > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 19:24:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from rina.naklab.dnj.ynu.ac.jp (rina.naklab.dnj.ynu.ac.jp [133.34.17.16]) by hub.freebsd.org (Postfix) with ESMTP id 0DC5214BCD; Wed, 7 Jul 1999 19:24:17 -0700 (PDT) (envelope-from tanimura@naklab.dnj.ynu.ac.jp) Received: from rina.naklab.dnj.ynu.ac.jp (localhost [127.0.0.1]) by rina.naklab.dnj.ynu.ac.jp (8.9.1a/3.7W-Naklab-2.1-19981120) with ESMTP id LAA20834; Thu, 8 Jul 1999 11:24:15 +0900 (JST) Message-Id: <199907080224.LAA20834@rina.naklab.dnj.ynu.ac.jp> To: julian@whistle.com Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Cc: Seigo Tanimura Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) From: Seigo Tanimura In-Reply-To: Your message of "Wed, 7 Jul 1999 19:18:57 -0700 (PDT)" References: X-Mailer: Mew version 1.70 on Emacs 19.34.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 08 Jul 1999 11:24:15 +0900 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 7 Jul 1999 19:18:57 -0700 (PDT), Julian Elischer said: >> Sorry, finetimer(9) is the new timer implemented in my latest midi driver. >> You can read the short paper describing the feature and principle in: >> >> Message-Id: <199907060959.SAA05637@rina.naklab.dnj.ynu.ac.jp> julian> how do I read that? Ow, I thought it was in the mailing list archive, turned out not. I will attach the paper below. Sorry for a long mail. --- v --- cut here --- v --- Unlike 16550, MPU401 does not generate an interrupt on TX-ready. So we have to choose one of the following two options to drive MPU401: A. polling the status to wait until TX-ready, B. emulating a TX-ready interrupt by a timer. The option A, used by VoxWare(sys/i386/isa/sound/sb16_midi.c:sb16midi_out()), consumes most of syscall time to wait for MPU401 to come TX-ready. One byte of midi message takes 0.32ms to transmit. Some certain midi sequences contain continuous long sysexes summed up to 200 bytes or more, leaving a latency of 0.32 * 200 = 60ms or something like that. This latency results in an unstable tempo. I have chosen the option B to eliminate the latency on message transmission. In this case, the timer needs to be capable of a period less than 0.32ms. The conventional timeout(9) has a period of 1/hz[s], which is generally 10ms. (hz = 100) While raising hz to, eg 3000 seems to shorten the period of timeout(9) enough, many parts of the kernel would be affected by this change, likely to end up with poor stability. To solve this problem, I propose a new *fine* callout mechanism. The realtime clock interrupt is at (hz * (1 << hzmul))[Hz], where (1 << hzmul) is the mutiplication ratio of hz. Although the ratio can be any natural number in theory, I have chosen the power of two to reduce the computational cost of the clock divider. (discussed later) As desceribed above, (for i386) clkintr() is called at (hz * (1 << hzmul))[Hz], calling hardclock() at the same frequency. hardclock() has two elements in it: a callout detector and a clock divider. A callout detector traverses the callout list and makes a callout, as in softclock(), except that the IPL stays at splclock. A clock divider reduces the frequency to hz[Hz], to process the conventional hardclock(), which is now renamed to hardclock1(), and softclock(). Although dividing a clock tick generally involves a costing division operation of the dividor counter by (1 << hzmul), a ratio of 2^n allows us to replace the operation with a simple shift of (clkdiv >> hzmul), where clkdiv is the dividor counter incremented one by one on a hardclock(). Fig 1 shows the frequency and the IPL of the new timer handlers. Frequency IPL Timer ^ ^ Generator | | | | | v (hz * (1 << hzmul))[Hz] splclock clkintr() | | | | | v v v hardclock() -> Fine ________________________________________ | Callouts ^ ^ v | | hardclock1() | | | hz[Hz] splsoftclock v | | softclock() -> Conventional | | Callouts v v Fig 1: Call Frequency and IPL under New Timer Handling I have implemented the new fine callout system discussed above in the latest patch of my midi driver. hzmul is 6, to multiply the timer frequency to 6400Hz. The usage of the fine callout is the same as timeout(9), except for the prefix of fine-, and that the granularity of the ticks is (1/(hz * (1 << hzmul)))[s]. Although I have not done any quantitative evaluation yet, I played some midi sequences with sysex messages to show a picture on the LCD of my SC-88, recognizing no latency like VoxWare. This result states the effectiveness of my proposing fine callout system. The future works include porting to alpha and PC98, and tuning hzmul. --- ^ --- cut here --- ^ --- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 19:36:26 1999 Delivered-To: freebsd-current@freebsd.org Received: from mycenae.ilion.eu.org (mycenae.ilion.eu.org [203.35.206.129]) by hub.freebsd.org (Postfix) with ESMTP id E839814BD8; Wed, 7 Jul 1999 19:36:15 -0700 (PDT) (envelope-from patrykz@mycenae.ilion.eu.org) Received: from mycenae.ilion.eu.org (patrykz@localhost [127.0.0.1]) by mycenae.ilion.eu.org (8.9.2/8.9.2) with ESMTP id MAA16726; Thu, 8 Jul 1999 12:36:01 +1000 (EST) (envelope-from patrykz@mycenae.ilion.eu.org) Message-Id: <199907080236.MAA16726@mycenae.ilion.eu.org> To: Greg Lehey Cc: Peter Jeremy , freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Bursting at the seams (was: Heh heh, humorous lockup) In-reply-to: Your message of "Thu, 08 Jul 1999 11:04:47 +0930." <19990708110446.P2340@freebie.lemis.com> Date: Thu, 08 Jul 1999 12:36:01 +1000 From: Patryk Zadarnowski Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Why not put the kernel in a different address space? IIRC there's no > absolute requirement for the kernel and userland to be in the same > address space, and that way we would have 4 GB for each. Wouldn't that make system calls that need to share data between kernel and user spaces hopelessly inefficient? Things like sysctl() would need to introduce (temporary) memory mappings, and someone would have to keep track of these mappings and remove them as required, or the kernel would probably run out of address space in no time, given even with 4GB to spare. On top of that, every mapping established requires some messing arround with the TLB, which, at least on pentium, is rather expensive. Incidentally, someone already experimented with such "dual" address spaces on Linux, and the result was a 30% or so slow down. If you're interested, I can give you the relevant references (the scenario was somewhat different, but the source of the performance hit was the "dual" address space.) patryk. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 19:46:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from mycenae.ilion.eu.org (mycenae.ilion.eu.org [203.35.206.129]) by hub.freebsd.org (Postfix) with ESMTP id 97D7614BD8; Wed, 7 Jul 1999 19:46:40 -0700 (PDT) (envelope-from patrykz@mycenae.ilion.eu.org) Received: from mycenae.ilion.eu.org (patrykz@localhost [127.0.0.1]) by mycenae.ilion.eu.org (8.9.2/8.9.2) with ESMTP id MAA16744; Thu, 8 Jul 1999 12:46:20 +1000 (EST) (envelope-from patrykz@mycenae.ilion.eu.org) Message-Id: <199907080246.MAA16744@mycenae.ilion.eu.org> To: Julian Elischer Cc: Matthew Dillon , Greg Lehey , Peter Jeremy , freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Bursting at the seams (was: Heh heh, humorous lockup) In-reply-to: Your message of "Wed, 07 Jul 1999 19:04:26 MST." Date: Thu, 08 Jul 1999 12:46:20 +1000 From: Patryk Zadarnowski Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > we already use the gs register for SMP now.. > what about the fs register? > I vaguely remember that the different segments could be used to achieve > this.... (%fs points to user space or something) ... as I've suggested a few days ago, and was told to shut up with a (rather irrelevant) reference to SASOS's. It can be done, in fact, it's already been done, with 50%+ performance improvement for tasks that rely heavily on IPC. (think client/server; email me for references.) However, it would involve a rather major redesign of the MMU and some redesign of the syscall stack. Further, one ends up restricting the size of the address space, which is fine until you start loading dynamic libraries. With something like libc, the working set may be small if all you need is a few system call stubs, but you end up with an extremely sparse address space which cannot be handled well with segmentation. Incidentally, you don't need to use FS to implement a tagged TLB using Liedtke's small address spaces. All you need is to modify CS, DS and SS; noone in the unix world relies on the values of ES and FS anyway; if they do, a quick-and-easy segmentation fault will teach them a lesson preaty fast. ;) patryk. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 19:46:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 9E17315132; Wed, 7 Jul 1999 19:46:42 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id TAA36196; Wed, 7 Jul 1999 19:46:40 -0700 (PDT) Date: Wed, 7 Jul 1999 19:46:38 -0700 (PDT) From: Julian Elischer To: Seigo Tanimura Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) In-Reply-To: <199907080224.LAA20834@rina.naklab.dnj.ynu.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 8 Jul 1999, Seigo Tanimura wrote: > > Ow, I thought it was in the mailing list archive, turned out not. > I will attach the paper below. Sorry for a long mail. > > > --- v --- cut here --- v --- > Unlike 16550, MPU401 does not generate an interrupt on TX-ready. > So we have to choose one of the following two options to drive [...] > alpha and PC98, and tuning hzmul. > --- ^ --- cut here --- ^ --- > > > Seigo Tanimura This is both more general and less general than aquire_timer0() aquiretimer0 assumes that there will only be one user of an elevated clock speed and produces a clock multiple of exactly the period that user requires. This allows us to generate a frequency of (for example) 16KHz. (not a power of 2) When it is not used it is turned off and there is no overhead. With your scheme the clock needs to be always running at elevated speed. Possibly you might have a startup routine that turns on the elevated frequency, (basically does an 'aquire_timer0()' ) I would say that you would have more success in implementing your finetimer() by using "aquiretimer0" than the other way around. a finetimer running at 16KHz (using aquire_timer0()) could allow the use of pca as well. (assuming we allowed 'reference counts on the timer to allow multiple clients that can use the same frequency.) Many people have thought about this. there are people who have run the system with Hz set to 1000 or more without great problems. We have always assumed in writing the code that hz may change so the code should be insulated from that change. The scheduling quantum is even done in uSecs and calculated against Hz. julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 20: 6:57 1999 Delivered-To: freebsd-current@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id F2441151BE; Wed, 7 Jul 1999 20:06:53 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id UAA21280; Wed, 7 Jul 1999 20:06:33 -0700 (PDT) Message-Id: <199907080306.UAA21280@lestat.nas.nasa.gov> To: Matthew Dillon Cc: Julian Elischer , David Greenman , freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup Reply-To: Jason Thorpe From: Jason Thorpe Date: Wed, 07 Jul 1999 20:06:33 -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 7 Jul 1999 18:21:03 -0700 (PDT) Matthew Dillon wrote: > Now, I also believe that when UVM maps those pages, it makes them > copy-on-write so I/O can be initiated on the data without having to > stall anyone attempting to make further modifications to the VM object. > Is this correct? This is something I would like to throw into FreeBSD > at some point. It would get rid of all the freeze/bogus-page hacks > already in there and avoid a number of I/O blocking conditions that we > currently face. Um... In UVM+UBC, VOP_GETPAGES() and VOP_PUTPAGES() operate on pages marked w/ PG_BUSY. In the case of faulting a page in, the mapping isn't yet entered into the VA at which it will be accessed, and in the case of a page being paged out, the page has been deactivated (and thus has had all mappings removed) and marked PG_BUSY. Thus, if a fault which would reactivate the page occurs, the fault handler waits for PG_BUSY to clear before reentering the mapping at the VA where the page will be accessed. Now, while the fault handler is waiting for PG_BUSY to clear, something else can certainly modify the object... But in the case of faulting on the same page, the second thread will wait for PG_BUSY to clear, too, since the page has already been inserted into the object. The pager's KVA for the page is read/write, for obvious reasons[*]. [*] Mapping a faulting page *at all* is suboptimal, of course. You'd prefer to see if the device can handle a physical address (or a uio with physical addresses), and if so, use that. This is faster, and eliminates bad cache interactions on VAC systems. You really only want to map the page if you have to do PIO to/from it. This is all handled via the ubc_pager (which has a special fault routine, part of UVM's basic infrastructure). VOP_GETPAGES() and VOP_PUTPAGES() are basically helper routines for the ubc_pager (effectively turning the file systems themselves into "pagers"). > However, I do not like the idea of taking page faults in kernel mode, > which I believe UVM also does -- but I think the above could be > implemented in FreeBSD without taking page faults. Taking page faults in kernel mode is a perfectly reasonable thing to do, if you don't need to access those addresses in interrupt context. What is the reason for your aversion to pageable mappings in the kernel? > Well, I do not like the "nuke the object chains" part of UVM. From what > I can tell UVM is doing a considerable amount of extra work to avoid the > object chain stuff, but only saving a small amount of overhead on > vm_fault's ( though, compared to the original Mach stuff the UVM stuff is > much, much better ). We've made a considerable number of improvements > to our vm_object's in the last few months. But I do like the idea > of a VM-specific substructure for vnodes and I do agree that embedding > the master VM object in the vnode is a good idea. Nuking object chains actually made things *simpler*. The locking protocol, in the face of object chains, is nighmareish. With amap-on-top-object-on- bottom, it's simple, makes fault handling quite fast, and eliminates all the complexity otherwise necessary in collasping those nasty object chains (where the various objects in the chain may be referenced by more than one map entry). ...and, in some cases, it's NOT a "small amount of overhead". Whereas the Mach object chains may be of arbitrary length (think about a program which forks often), involving a potentially hash computation for each object in the chain, the UVM case is always, at the most, two layers (in the current amap implementation, the lookup is always a direct index into an array, and the object underneath is a hash lookup). -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 20:10:54 1999 Delivered-To: freebsd-current@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id C4CFA14BD0; Wed, 7 Jul 1999 20:10:48 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id UAA37956; Wed, 7 Jul 1999 20:10:31 -0700 (PDT) Date: Wed, 7 Jul 1999 20:10:30 -0700 (PDT) From: Julian Elischer To: Patryk Zadarnowski Cc: Greg Lehey , Peter Jeremy , freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Bursting at the seams (was: Heh heh, humorous lockup) In-Reply-To: <199907080236.MAA16726@mycenae.ilion.eu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 8 Jul 1999, Patryk Zadarnowski wrote: > > > Why not put the kernel in a different address space? IIRC there's no > > absolute requirement for the kernel and userland to be in the same > > address space, and that way we would have 4 GB for each. > > Wouldn't that make system calls that need to share data between kernel > and user spaces hopelessly inefficient? Things like sysctl() would > need to introduce (temporary) memory mappings, and someone would have > to keep track of these mappings and remove them as required, or the > kernel would probably run out of address space in no time, given even > with 4GB to spare. On top of that, every mapping established requires > some messing arround with the TLB, which, at least on pentium, is > rather expensive. All user data is imported and exported to the kernel using special calls anyhow, as we've always thought that we may want to go back to the separate address spaces that we asarted out with on the 11-40 and 11-45 (etc.) so technically it wouldn't make too much work as far as altering the kernel. I guess however, having thought about it, that we'd have to reload CR3 on a syscall and that'd flush the TLBs which would be a pain.. > > Incidentally, someone already experimented with such "dual" address > spaces on Linux, and the result was a 30% or so slow down. If you're > interested, I can give you the relevant references (the scenario was > somewhat different, but the source of the performance hit was the > "dual" address space.) > > patryk. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 21:32:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from taciturn.tcac.net (s108-cdm55.amar.tcac.net [207.50.55.108]) by hub.freebsd.org (Postfix) with SMTP id AC42514D2A for ; Wed, 7 Jul 1999 21:32:22 -0700 (PDT) (envelope-from bhughes@tcac.net) Received: (qmail 503 invoked by uid 1000); 8 Jul 1999 04:33:44 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Jul 1999 04:33:44 -0000 Date: Wed, 7 Jul 1999 23:33:44 -0500 (CDT) From: "Bradley T. Hughes" To: current@freebsd.org Subject: question regarding CMD640 chipsets Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG this is my first bout with -current... and i have a question about the cmd640 workaround code... upon booting -current (from 7/6/99) i noticed that the kernel didn't report that the work around was enabled... so i began searching through the code looking for where the workaround actually was... i found it in src/sys/i386/isa/wd.c (line 282), but the wdc_pci() function only sets static int eide_quirks wd.c... looking into src/sys/pci/ide_pci.c in wdattach() i can see a case statement (line 1457) where wdc_pci is supposed to be called... but it never gets called (verified by putting a printf into wdc_pci and recompiling/installing/booting kernel) i've searched through -current, -hackers and -committers archives looking for some indication as to where/what has happened wrt the cmd640 workaround code... but have come up with nothing... perhaps someone could provide some insight or a possible link to some more information? thanks in advance Blackbox - An X11R6 Window Manager http://blackbox.wiw.org/ __________________________________ Bradley T. Hughes To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 23:17:21 1999 Delivered-To: freebsd-current@freebsd.org Received: from rina.naklab.dnj.ynu.ac.jp (rina.naklab.dnj.ynu.ac.jp [133.34.17.16]) by hub.freebsd.org (Postfix) with ESMTP id C0E0E14E3B; Wed, 7 Jul 1999 23:17:10 -0700 (PDT) (envelope-from tanimura@naklab.dnj.ynu.ac.jp) Received: from rina.naklab.dnj.ynu.ac.jp (localhost [127.0.0.1]) by rina.naklab.dnj.ynu.ac.jp (8.9.1a/3.7W-Naklab-2.1-19981120) with ESMTP id PAA23884; Thu, 8 Jul 1999 15:17:08 +0900 (JST) Message-Id: <199907080617.PAA23884@rina.naklab.dnj.ynu.ac.jp> To: julian@whistle.com Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Cc: Seigo Tanimura Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) From: Seigo Tanimura In-Reply-To: Your message of "Wed, 7 Jul 1999 19:46:38 -0700 (PDT)" References: X-Mailer: Mew version 1.70 on Emacs 19.34.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 08 Jul 1999 15:17:07 +0900 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 7 Jul 1999 19:46:38 -0700 (PDT), Julian Elischer said: julian> With your scheme the clock needs to be always running at elevated speed. julian> Possibly you might have a startup routine that turns on the elevated julian> frequency, (basically does an 'aquire_timer0()' ) I would say that you julian> would have more success in implementing your finetimer() by using julian> "aquiretimer0" than the other way around. I agree that acquire_timer0() would give more freedom to the ticks to callout. Then I tried figuring out how to manage multiple callouts using acquire_timer0(), which is something like below. Let C the callout queue, and c_i a callout. (0 <= i < I) Next define f(c_i) as the callout function of c_i, and dt_rem(c_i) the time span between c_(i-1) and c_i. (dt_rem(c_-1) is defined as zero) We use the time span to avoid traversing though the queue to update the time tags on the callouts. (footnote: I'd better write in TeX :-<) Queueing a new callout c' to be made in t' involves a problem to find the maximum j (which is an integer, j >= 0) satisfying a constraint t' > \sum_(k=0)^(j) dt_rem(c_k) where the right hand side of the inequality is the time span after which the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). In clkintr(), we dequeue c_0 from C, and make a callout to f(c_0). Then acquire_timer0() is called once more with the new dt_rem(c_0). dt_rem(c_i) is the difference of callout times, so they need not be updated on every clkintr(). Although the computational cost in clkintr() is generaly O(1), the queueing cost is O(I). Not sure whether we can reduce it or not (will it really make a trouble?) How does it sound? Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 23:23:31 1999 Delivered-To: freebsd-current@freebsd.org Received: from dingo.cdrom.com (castles551.castles.com [208.214.165.115]) by hub.freebsd.org (Postfix) with ESMTP id 0DDF814E3B for ; Wed, 7 Jul 1999 23:23:29 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id XAA00867; Wed, 7 Jul 1999 23:19:43 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907080619.XAA00867@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Alex Zepeda Cc: Keith Stevenson , freebsd-current@FreeBSD.ORG Subject: Re: userland ppp - startup In-reply-to: Your message of "Wed, 07 Jul 1999 14:34:21 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Jul 1999 23:19:43 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Why is rc.conf readable by world?! > > > > Why not? > > What reason would the rest of the "world" have to read rc.conf? It could > only create a possible security risk. This is shabby reasoning. rc.conf contains public system configuration data, which may need to be consumed by non-root processes. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 7 23:27:14 1999 Delivered-To: freebsd-current@freebsd.org Received: from zippy.dyn.ml.org (korea-181.ppp.hooked.net [206.169.225.181]) by hub.freebsd.org (Postfix) with ESMTP id E01B214E3B for ; Wed, 7 Jul 1999 23:27:07 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.9.3/8.9.1) with ESMTP id XAA37789; Wed, 7 Jul 1999 23:26:55 -0700 (PDT) (envelope-from garbanzo@hooked.net) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Wed, 7 Jul 1999 23:26:53 -0700 (PDT) From: Alex Zepeda To: Mike Smith Cc: Keith Stevenson , freebsd-current@FreeBSD.ORG Subject: Re: userland ppp - startup In-Reply-To: <199907080619.XAA00867@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 7 Jul 1999, Mike Smith wrote: > > > > Why is rc.conf readable by world?! > > > > > > Why not? > > > > What reason would the rest of the "world" have to read rc.conf? It could > > only create a possible security risk. > > This is shabby reasoning. rc.conf contains public system configuration > data, which may need to be consumed by non-root processes. What kind of non-root program would need to consume rc.conf? - alex I thought felt your touch In my car, on my clutch But I guess it's just someone who felt a lot like I remember you. - Translator To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 0:18:30 1999 Delivered-To: freebsd-current@freebsd.org Received: from dingo.cdrom.com (castles551.castles.com [208.214.165.115]) by hub.freebsd.org (Postfix) with ESMTP id 0BE2914C01 for ; Thu, 8 Jul 1999 00:18:23 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id AAA01216; Thu, 8 Jul 1999 00:14:33 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907080714.AAA01216@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Alex Zepeda Cc: Mike Smith , Keith Stevenson , freebsd-current@FreeBSD.ORG Subject: Re: userland ppp - startup In-reply-to: Your message of "Wed, 07 Jul 1999 23:26:53 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 08 Jul 1999 00:14:32 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > What reason would the rest of the "world" have to read rc.conf? It could > > > only create a possible security risk. > > > > This is shabby reasoning. rc.conf contains public system configuration > > data, which may need to be consumed by non-root processes. > > What kind of non-root program would need to consume rc.conf? Anything that wants access to paramters stored there. Visualise eg. a generic system monitoring script that checks the health of enabled services; any daemon running in a sandbox. Even rc.pccard could be run as non-root (modulo some changes to the way that ifconfig works). The point being that rc.conf is currently a public database, and until we have a better mechanism for managing parameter storage, it needs to stay that way. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 0:31:58 1999 Delivered-To: freebsd-current@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id A728D14C01 for ; Thu, 8 Jul 1999 00:31:54 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id KAA18086; Thu, 8 Jul 1999 10:27:14 +0300 (EEST) (envelope-from will) To: Alex Zepeda Cc: current@freebsd.org Subject: Re: userland ppp - startup References: From: Ville-Pertti Keinonen Date: 08 Jul 1999 10:27:14 +0300 In-Reply-To: Alex Zepeda's message of "8 Jul 1999 00:35:25 +0300" Message-ID: <86k8sbr48d.fsf@not.demophon.com> Lines: 19 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alex Zepeda writes: > > > Why is rc.conf readable by world?! > > > > Why not? > > What reason would the rest of the "world" have to read rc.conf? It could > only create a possible security risk. Unix systems are typically designed the other way around - don't read-protect files unless they contain something that users must not see. Currently, FreeBSD conforms to this philosophy quite nicely, and I hope it continues to do so. Personally, I like being able to do as much as possible without having to su root unless I want to modify things. I also like being able to see how things are set up on systems where I don't have root privileges. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 1:55:11 1999 Delivered-To: freebsd-current@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id DE872151ED; Thu, 8 Jul 1999 01:55:02 -0700 (PDT) (envelope-from dfr@nlsystems.com) 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 JAA25055; Thu, 8 Jul 1999 09:54:42 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Thu, 8 Jul 1999 09:54:42 +0100 (BST) From: Doug Rabson To: Seigo Tanimura Cc: julian@whistle.com, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) In-Reply-To: <199907080617.PAA23884@rina.naklab.dnj.ynu.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 8 Jul 1999, Seigo Tanimura wrote: > On Wed, 7 Jul 1999 19:46:38 -0700 (PDT), > Julian Elischer said: > > julian> With your scheme the clock needs to be always running at elevated speed. > julian> Possibly you might have a startup routine that turns on the elevated > julian> frequency, (basically does an 'aquire_timer0()' ) I would say that you > julian> would have more success in implementing your finetimer() by using > julian> "aquiretimer0" than the other way around. > > I agree that acquire_timer0() would give more freedom to the ticks > to callout. Then I tried figuring out how to manage multiple > callouts using acquire_timer0(), which is something like below. > > > Let C the callout queue, and c_i a callout. (0 <= i < I) Next define f(c_i) as > the callout function of c_i, and dt_rem(c_i) the time span between c_(i-1) and > c_i. (dt_rem(c_-1) is defined as zero) We use the time span to avoid traversing > though the queue to update the time tags on the callouts. > > (footnote: I'd better write in TeX :-<) > > Queueing a new callout c' to be made in t' involves a problem to find the > maximum j (which is an integer, j >= 0) satisfying a constraint > > t' > \sum_(k=0)^(j) dt_rem(c_k) > > where the right hand side of the inequality is the time span after which > the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) > and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). > > In clkintr(), we dequeue c_0 from C, and make a callout to f(c_0). Then > acquire_timer0() is called once more with the new dt_rem(c_0). dt_rem(c_i) is > the difference of callout times, so they need not be updated on every clkintr(). > > > Although the computational cost in clkintr() is generaly O(1), the queueing cost > is O(I). Not sure whether we can reduce it or not (will it really make a trouble?) > > > How does it sound? If I understand this correctly, you are suggesting that we program timer0 so that we only take interrupts when a finetimer is due to fire? If so, then it sounds very good. The idea of taking 6000+ interrupts/sec made me uneasy, even though most would return without doing any work. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 2:40:46 1999 Delivered-To: freebsd-current@freebsd.org Received: from rina.naklab.dnj.ynu.ac.jp (rina.naklab.dnj.ynu.ac.jp [133.34.17.16]) by hub.freebsd.org (Postfix) with ESMTP id 36FD214C14; Thu, 8 Jul 1999 02:40:39 -0700 (PDT) (envelope-from tanimura@naklab.dnj.ynu.ac.jp) Received: from rina.naklab.dnj.ynu.ac.jp (localhost [127.0.0.1]) by rina.naklab.dnj.ynu.ac.jp (8.9.1a/3.7W-Naklab-2.1-19981120) with ESMTP id SAA26649; Thu, 8 Jul 1999 18:40:23 +0900 (JST) Message-Id: <199907080940.SAA26649@rina.naklab.dnj.ynu.ac.jp> To: dfr@nlsystems.com Cc: julian@whistle.com, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Cc: Seigo Tanimura Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer) From: Seigo Tanimura In-Reply-To: Your message of "Thu, 8 Jul 1999 09:54:42 +0100 (BST)" References: X-Mailer: Mew version 1.70 on Emacs 19.34.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 08 Jul 1999 18:40:23 +0900 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 8 Jul 1999 09:54:42 +0100 (BST), Doug Rabson said: dfr> If I understand this correctly, you are suggesting that we program timer0 dfr> so that we only take interrupts when a finetimer is due to fire? If so, dfr> then it sounds very good. The idea of taking 6000+ interrupts/sec made me dfr> uneasy, even though most would return without doing any work. Yes, that is what I am doing now. And some further discussion... > t' > \sum_(k=0)^(j) dt_rem(c_k) > > where the right hand side of the inequality is the time span after which > the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) > and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). If t' is less than dt_rem(c_0) then we have no feasible j. This is the case in which we must reaquire_timer0() using t'. Then, after interting c', dt_rem(c_1) is updated to be (dt_rem(c_1) - (time elapsed since the last aquire_timer0())), so that c_1 can be armed later. There is one problem in this method. acquire_timer0() is only implemented for i386. We would need to write something equivalent for alpha... Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 3: 1: 5 1999 Delivered-To: freebsd-current@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 4BD851514C; Thu, 8 Jul 1999 03:00:55 -0700 (PDT) (envelope-from dfr@nlsystems.com) 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 LAA88985; Thu, 8 Jul 1999 11:00:25 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Thu, 8 Jul 1999 11:00:24 +0100 (BST) From: Doug Rabson To: Seigo Tanimura Cc: julian@whistle.com, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer) In-Reply-To: <199907080940.SAA26649@rina.naklab.dnj.ynu.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 8 Jul 1999, Seigo Tanimura wrote: > On Thu, 8 Jul 1999 09:54:42 +0100 (BST), > Doug Rabson said: > > dfr> If I understand this correctly, you are suggesting that we program timer0 > dfr> so that we only take interrupts when a finetimer is due to fire? If so, > dfr> then it sounds very good. The idea of taking 6000+ interrupts/sec made me > dfr> uneasy, even though most would return without doing any work. > > > Yes, that is what I am doing now. And some further discussion... > > > t' > \sum_(k=0)^(j) dt_rem(c_k) > > > > where the right hand side of the inequality is the time span after which > > the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) > > and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). > > If t' is less than dt_rem(c_0) then we have no feasible j. This is the case > in which we must reaquire_timer0() using t'. Then, after interting c', dt_rem(c_1) > is updated to be (dt_rem(c_1) - (time elapsed since the last aquire_timer0())), > so that c_1 can be armed later. > > > There is one problem in this method. acquire_timer0() is only implemented > for i386. We would need to write something equivalent for alpha... The timer hardware on the alpha is essentially the same but the interrupts are wired up differently. I'm not sure how hard it would be to get timer0 working but I think it should be possible. The alphas tend to run the main clock quite fast (typically 1024hz) so the granularity of timing is better but probably not good enough for midi or pca. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 4:20:10 1999 Delivered-To: freebsd-current@freebsd.org Received: from rina.naklab.dnj.ynu.ac.jp (rina.naklab.dnj.ynu.ac.jp [133.34.17.16]) by hub.freebsd.org (Postfix) with ESMTP id E5CEE14D1C; Thu, 8 Jul 1999 04:20:06 -0700 (PDT) (envelope-from tanimura@naklab.dnj.ynu.ac.jp) Received: from rina.naklab.dnj.ynu.ac.jp (localhost [127.0.0.1]) by rina.naklab.dnj.ynu.ac.jp (8.9.1a/3.7W-Naklab-2.1-19981120) with ESMTP id UAA28709; Thu, 8 Jul 1999 20:19:18 +0900 (JST) Message-Id: <199907081119.UAA28709@rina.naklab.dnj.ynu.ac.jp> To: dfr@nlsystems.com Cc: julian@whistle.com, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Cc: Seigo Tanimura Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunderNew Midi Driver Framework with a Fine Timer) From: Seigo Tanimura In-Reply-To: Your message of "Thu, 8 Jul 1999 11:00:24 +0100 (BST)" References: X-Mailer: Mew version 1.70 on Emacs 19.34.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 08 Jul 1999 20:19:18 +0900 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 8 Jul 1999 11:00:24 +0100 (BST), Doug Rabson said: >> There is one problem in this method. acquire_timer0() is only implemented >> for i386. We would need to write something equivalent for alpha... dfr> The timer hardware on the alpha is essentially the same but the interrupts dfr> are wired up differently. I'm not sure how hard it would be to get timer0 dfr> working but I think it should be possible. I see. Then I can work on i386 first, and later on alpha. dfr> The alphas tend to run the main clock quite fast (typically 1024hz) so the dfr> granularity of timing is better but probably not good enough for midi or dfr> pca. I agree. Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 4:20:36 1999 Delivered-To: freebsd-current@freebsd.org Received: from thelab.hub.org (nat195.34.mpoweredpc.net [142.177.195.34]) by hub.freebsd.org (Postfix) with ESMTP id 623AE154F5; Thu, 8 Jul 1999 04:20:22 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id IAA28701; Thu, 8 Jul 1999 08:20:37 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Thu, 8 Jul 1999 08:20:37 -0300 (ADT) From: The Hermit Hacker To: freebsd-current@freebsd.org Cc: freebsd-stable@freebsd.org Subject: Known MMAP() race conditions ... ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Three weeks ago, I, and a few other INN administrators, posted about FreeBSD -STABLE's inability to run the newest INN code, due to MMAP() race conditions...essentially, after X hours of run time, on a heavily loaded INN server, the whole thing locks up solid. At that time, Matt pop'd up and stated that he knew of *at least* 6 MMAP() related race conditions that he was hoping to be able to get fixed "within a week"...that would have been two weeks ago. I've been watching the -commit messages closely, and CVSup'ng a new kernel almost daily, in the hopes of seeing some MMAP() related activity from someone, and haven't seen anything so far, so I'm curious as to whether or not anyone *but* Matt is aware of these race conditions, and/or is working on this? I'm trying to push moving some Solaris boxes at work over to FreeBSD, with our INN server being the 'safest' example to move over first, but there is no way I can do that with the current INN/FreeBSD interaction :( Thanks... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 5:26:55 1999 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 69BD814CED for ; Thu, 8 Jul 1999 05:26:53 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (iras-1-32.ucdavis.edu [169.237.16.32]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id FAA49446; Thu, 8 Jul 1999 05:26:51 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id MAA53074; Thu, 8 Jul 1999 12:26:45 GMT (envelope-from obrien) Date: Thu, 8 Jul 1999 05:26:44 -0700 From: "David O'Brien" To: Frank Nobis Cc: current@freebsd.org Subject: Re: Break of today current and patch Message-ID: <19990708052643.A52964@dragon.nuxi.com> Reply-To: obrien@NUXI.com References: <19990707231257.A62612@radio-do.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <19990707231257.A62612@radio-do.de>; from Frank Nobis on Wed, Jul 07, 1999 at 11:12:57PM +0200 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > todays current breaks in build of libgcc Since libgcc/Makefile hasn't been touched since April, me thinks something else is going on in your environment. > ===> gnu/lib/libgcc > c++ -O2 -mpentium -fpcc-struct-return -ffast-math -fno-strength-reduce ... What does adding "-v" to your CLFAGS in /etc/make.conf show? -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 5:41:40 1999 Delivered-To: freebsd-current@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id EA49F14C14 for ; Thu, 8 Jul 1999 05:41:30 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id WAA24705; Thu, 8 Jul 1999 22:41:23 +1000 Date: Thu, 8 Jul 1999 22:41:23 +1000 From: Bruce Evans Message-Id: <199907081241.WAA24705@godzilla.zeta.org.au> To: bhughes@tcac.net, current@FreeBSD.ORG Subject: Re: question regarding CMD640 chipsets Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >upon booting -current (from 7/6/99) i noticed that the kernel didn't report >that the work around was enabled... so i began searching through the code >looking for where the workaround actually was... i found it in >src/sys/i386/isa/wd.c (line 282), but the wdc_pci() function only sets >static int eide_quirks wd.c... looking into src/sys/pci/ide_pci.c in >wdattach() i can see a case statement (line 1457) where wdc_pci is supposed >to be called... but it never gets called (verified by putting a printf into >wdc_pci and recompiling/installing/booting kernel) Rev.1.31 of ide_pci.c put the call in a dubious place (after some early return statements) in ide_pci_attach(). Try putting it at the beginning of the function (after `type' is initialized). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 5:45: 8 1999 Delivered-To: freebsd-current@freebsd.org Received: from hcshh.hcs.de (hcshh.hcs.de [194.123.40.1]) by hub.freebsd.org (Postfix) with SMTP id 6FCD914E98 for ; Thu, 8 Jul 1999 05:44:56 -0700 (PDT) (envelope-from hm@hcs.de) Received: from hcswork.hcs.de([192.76.124.5]) (1981 bytes) by hcshh.hcs.de via sendmail with P:smtp/R:inet_hosts/T:smtp (sender: ) id for ; Thu, 8 Jul 1999 14:44:23 +0200 (CEST) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Dec-11) Received: by hcswork.hcs.de (Smail3.1.29.0 #13) id m112DXK-0001bzC; Thu, 8 Jul 99 14:44 METDST Message-Id: From: hm@hcs.de (Hellmuth Michaelis) Subject: Re: userland ppp - startup In-Reply-To: <19990708001733.A34785@dva.in-berlin.de> from Boris Staeblow at "Jul 8, 99 00:17:34 am" To: balu@dva.in-berlin.de (Boris Staeblow) Date: Thu, 8 Jul 1999 14:44:22 +0200 (METDST) Cc: freebsd-current@FreeBSD.ORG Reply-To: hm@hcs.de Organization: HCS Hanseatischer Computerservice GmbH X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1139 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From the keyboard of Boris Staeblow: > >> Why is rc.conf readable by world?! > > > >Why not? > > What about that: > > spppconfig_isp0="authproto=chap myauthname=foo myauthsecret='top secret' > hisauthname=some-gw hisauthsecret='another secret'" I'm not quite satisfied with the way the passwords are configured with spppcontrol. Not to talk about writing those passwords into rc.conf. At that time (and even now) Joerg and i put that into rc.conf, it was (and is) much better to have this in rc.conf than having nothing at all. A way might be to have those passwords (md5 ?) encrypted in a file, which is then handed via spppcontrol into the kernel and are decrypted and used only for the time they are actually needed ? Of course, i currently do not even have the time to think about how to implement this ... hellmuth -- Hellmuth Michaelis Tel +49 40 559747-70 HCS Hanseatischer Computerservice GmbH Fax +49 40 559747-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de 22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 5:55: 5 1999 Delivered-To: freebsd-current@freebsd.org Received: from enst.enst.fr (enst.enst.fr [137.194.2.16]) by hub.freebsd.org (Postfix) with ESMTP id 5B47A15116; Thu, 8 Jul 1999 05:55:00 -0700 (PDT) (envelope-from beyssac@enst.fr) Received: from bofh.enst.fr (bofh-2.enst.fr [137.194.2.37]) by enst.enst.fr (8.9.1a/8.9.1) with ESMTP id OAA16476; Thu, 8 Jul 1999 14:54:58 +0200 (MET DST) Received: by bofh.enst.fr (Postfix, from userid 12426) id 3DEB3D226; Thu, 8 Jul 1999 14:54:58 +0200 (CEST) Message-ID: <19990708145458.A10059@enst.fr> Date: Thu, 8 Jul 1999 14:54:58 +0200 From: Pierre Beyssac To: The Hermit Hacker , freebsd-current@FreeBSD.ORG Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Known MMAP() race conditions ... ? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from The Hermit Hacker on Thu, Jul 08, 1999 at 08:20:37AM -0300 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 08, 1999 at 08:20:37AM -0300, The Hermit Hacker wrote: > I'm trying to push moving some Solaris boxes at work over to FreeBSD, > with our INN server being the 'safest' example to move over first, but You'd better try to configure INN without mmap(); this doesn't induce much performance penalty and you avoid any problems with FreeBSD's mmap. Now there are other (and IMHO, better) ways to demonstrate FreeBSD stability on a production server: HTTP, POP/SMTP, DNS,... -- Pierre Beyssac pb@enst.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 6:18:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from thelab.hub.org (nat195.34.mpoweredpc.net [142.177.195.34]) by hub.freebsd.org (Postfix) with ESMTP id 437C2151E7; Thu, 8 Jul 1999 06:18:29 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id KAA29806; Thu, 8 Jul 1999 10:18:36 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Thu, 8 Jul 1999 10:18:35 -0300 (ADT) From: The Hermit Hacker To: Pierre Beyssac Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Known MMAP() race conditions ... ? In-Reply-To: <19990708145458.A10059@enst.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 8 Jul 1999, Pierre Beyssac wrote: > On Thu, Jul 08, 1999 at 08:20:37AM -0300, The Hermit Hacker wrote: > > I'm trying to push moving some Solaris boxes at work over to FreeBSD, > > with our INN server being the 'safest' example to move over first, but > > You'd better try to configure INN without mmap(); this doesn't > induce much performance penalty and you avoid any problems with > FreeBSD's mmap. The newest INN does not have this option, MMAP() is a requirement for it... > Now there are other (and IMHO, better) ways to demonstrate FreeBSD > stability on a production server: HTTP, POP/SMTP, DNS,... ah, okay, so you are saying that FreeBSD shouldn't be demonstrated using software that taxes/tweaks bugs in it? Boy, does that sound like a quick road to problems... Management: but, when you sold us on this operating system, it was perfectly stable. Me: ya, well, I picked and choose the software I ran for the demo, sorry... personal, sounds like something Microsoft would do, not something that *I'd* want to base a decision on. right now, at work, I'm enjoying a 4 way battle. Me, fighting to bring in FreeBSD to replace some of our Solaris boxes. A friend of mine, fighting to bring in Linux to replace some of our Solaris boxes. My boss fighting against both of us to keep Solaris "because its what we've always used". And another department fighting for NT/Novell solutions. Right now, my 'fight' is weak, since all my friend has to do is point out that 'the MMAP() issue isn't an issue under Linux'...and, as far as I'm concerned, the MMAP() issue is about the *only* issue that prevents me from being able to move forward. My opinion on the Linux vs *BSD issue is, and always has been, that *BSD makes the better *server*...we have very strong networking code, a very stable kernel and a sane development model...but this MMAP() issue really hurts :( IMHO, *BSD was designed around *loaded* machines, yet it can't handle a fully configured, loaded INN server without hanging :( If someone is working on this, and its just a matter of patience because the bugs, altho known, are obscure, great. If ppl think that the problem isn't serious enough, expect that once INN 2.3 is released, there is going to be a major outcry, since INN 2.3 *requires* MMAP() to be used, it isn't an option anymore :( Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 6:37:10 1999 Delivered-To: freebsd-current@freebsd.org Received: from fed-ef1.frb.gov (fed.frb.gov [132.200.32.32]) by hub.freebsd.org (Postfix) with ESMTP id C871714BF5; Thu, 8 Jul 1999 06:37:01 -0700 (PDT) (envelope-from seth@freebie.dp.ny.frb.org) Received: by fed-ef1.frb.gov; id JAA26763; Thu, 8 Jul 1999 09:36:52 -0400 (EDT) Received: from m1pmdf.frb.gov(192.168.3.38) by fed.frb.gov via smap (V4.2) id xma026487; Thu, 8 Jul 99 09:36:34 -0400 Date: Thu, 08 Jul 1999 09:36:25 -0400 (EDT) From: Seth Subject: Re: Known MMAP() race conditions ... ? In-reply-to: <19990708145458.A10059@enst.fr> To: Pierre Beyssac Cc: The Hermit Hacker , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is this the same problem that locks the machine up when two find's are performed (even by a user)? That problem was discussed a couple months ago in this group, but I haven't heard whether that's been resolved yet. SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 7:45:53 1999 Delivered-To: freebsd-current@freebsd.org Received: from enst.enst.fr (enst.enst.fr [137.194.2.16]) by hub.freebsd.org (Postfix) with ESMTP id 3613C14CED; Thu, 8 Jul 1999 07:45:45 -0700 (PDT) (envelope-from beyssac@enst.fr) Received: from bofh.enst.fr (bofh-2.enst.fr [137.194.2.37]) by enst.enst.fr (8.9.1a/8.9.1) with ESMTP id QAA21830; Thu, 8 Jul 1999 16:45:43 +0200 (MET DST) Received: by bofh.enst.fr (Postfix, from userid 12426) id BD9D5D226; Thu, 8 Jul 1999 15:50:02 +0200 (CEST) Message-ID: <19990708155002.H90983@enst.fr> Date: Thu, 8 Jul 1999 15:50:02 +0200 From: Pierre Beyssac To: The Hermit Hacker Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Known MMAP() race conditions ... ? References: <19990708145458.A10059@enst.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from The Hermit Hacker on Thu, Jul 08, 1999 at 10:18:35AM -0300 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 08, 1999 at 10:18:35AM -0300, The Hermit Hacker wrote: > The newest INN does not have this option, MMAP() is a requirement for > it... Sorry, I didn't know that. Too bad, then. > ah, okay, so you are saying that FreeBSD shouldn't be demonstrated using > software that taxes/tweaks bugs in it? Exactly. If you want to show the strengths of a system, it just doesn't make sense to rely on its weaker parts. > Boy, does that sound like a quick > road to problems... Management: but, when you sold us on this operating > system, it was perfectly stable. Me: ya, well, I picked and choose the > software I ran for the demo, sorry... I didn't say you have to lie about your choice. > Right now, my 'fight' is weak, since all my friend has to do is point out > that 'the MMAP() issue isn't an issue under Linux'...and, as far as I'm Linux has other -- IMHO more annoying -- issues, so I think your friend had better stop bragging. > My opinion on the Linux vs *BSD issue is, and always has been, that *BSD > makes the better *server*...we have very strong networking code, a very > stable kernel and a sane development model...but this MMAP() issue really > hurts :( I think everyone agrees. Now, the problem is that it's not an easy thing to fix, or it would already be fixed. -- Pierre Beyssac pb@enst.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 7:58:59 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 836CE1530B; Thu, 8 Jul 1999 07:58:52 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id HAA40125; Thu, 8 Jul 1999 07:58:49 -0700 (PDT) (envelope-from dillon) Date: Thu, 8 Jul 1999 07:58:49 -0700 (PDT) From: Matthew Dillon Message-Id: <199907081458.HAA40125@apollo.backplane.com> To: The Hermit Hacker Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Known MMAP() race conditions ... ? References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :At that time, Matt pop'd up and stated that he knew of *at least* 6 MMAP() :related race conditions that he was hoping to be able to get fixed "within :a week"...that would have been two weeks ago. I think I was talking about mmap w/ NFS. Under FreeBSD-current I know of two problems ( though I could be forgetting some ) - there is a problem when a lot of pages get dirtied that can cause a low-memory deadlock to occur, and I believe there is a problem when mlock() or madvise() is used though I haven't reproduced it yet. Under FreeBSD-stable there are a number of additional, but minor problems related to visibility of non-zero garbage after file EOF in an mmap(), but these would have no effect on INN. What we need to know is why the machines are locking up. The usual way to figure this out is to compile the kernel up with DDB and then when it locks up ctl-alt-esc on the console to get the DDB prompt, and do a 'ps' to see what the procsses are blocked in. If the problem is the dirty-page problem, there are ways around it (basically by syncing more often). -Matt Matthew Dillon :Thanks... : :Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy :Systems Administrator @ hub.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 8:28: 6 1999 Delivered-To: freebsd-current@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id E214E1530A; Thu, 8 Jul 1999 08:27:59 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id BAA04078; Fri, 9 Jul 1999 01:27:14 +1000 Date: Fri, 9 Jul 1999 01:27:14 +1000 From: Bruce Evans Message-Id: <199907081527.BAA04078@godzilla.zeta.org.au> To: dfr@nlsystems.com, tanimura@naklab.dnj.ynu.ac.jp Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer) Cc: freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG, julian@whistle.com Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >dfr> If I understand this correctly, you are suggesting that we program timer0 >dfr> so that we only take interrupts when a finetimer is due to fire? If so, >dfr> then it sounds very good. The idea of taking 6000+ interrupts/sec made me >dfr> uneasy, even though most would return without doing any work. 6000+ interrupts/sec is not many, unless it is done all the time. A 486/33 can handle about 50000 (16000 for pcaudio + 3 * 11520 for sio's). >There is one problem in this method. acquire_timer0() is only implemented >for i386. We would need to write something equivalent for alpha... This is a serious problem. acquire_timer0() is currently disabled even for i386's when the i8254 is used for timecounting. This is not hard to fix (the hooks into clkintr() work even better with timecounters since it is not necessary to resynchronise clock interrupts after a state change), but an i8254 interrupt frequency of 16000 Hz is too fast to be used routinely if the i8254 is being used for timecounting (even if the CPU can keep up with the interrupts, the overflow heuristics in i8254_get_timecount() may break down). Other systems may have even more limitations on the timecounters. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 8:33: 8 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (wandering-wizard.cybercity.dk [212.242.41.238]) by hub.freebsd.org (Postfix) with ESMTP id B9CDA14D4C; Thu, 8 Jul 1999 08:33:03 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id RAA02665; Thu, 8 Jul 1999 17:31:48 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Bruce Evans Cc: dfr@nlsystems.com, tanimura@naklab.dnj.ynu.ac.jp, freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG, julian@whistle.com Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer) In-reply-to: Your message of "Fri, 09 Jul 1999 01:27:14 +1000." <199907081527.BAA04078@godzilla.zeta.org.au> Date: Thu, 08 Jul 1999 17:31:48 +0200 Message-ID: <2663.931447908@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Somebody should study the abilities of the on-cpu APIC for this for pentium ff. machines. In message <199907081527.BAA04078@godzilla.zeta.org.au>, Bruce Evans writes: >>dfr> If I understand this correctly, you are suggesting that we program timer0 >>dfr> so that we only take interrupts when a finetimer is due to fire? If so, >>dfr> then it sounds very good. The idea of taking 6000+ interrupts/sec made me >>dfr> uneasy, even though most would return without doing any work. > >6000+ interrupts/sec is not many, unless it is done all the time. A >486/33 can handle about 50000 (16000 for pcaudio + 3 * 11520 for sio's). > >>There is one problem in this method. acquire_timer0() is only implemented >>for i386. We would need to write something equivalent for alpha... > >This is a serious problem. acquire_timer0() is currently disabled even >for i386's when the i8254 is used for timecounting. This is not hard >to fix (the hooks into clkintr() work even better with timecounters >since it is not necessary to resynchronise clock interrupts after a >state change), but an i8254 interrupt frequency of 16000 Hz is too fast >to be used routinely if the i8254 is being used for timecounting (even >if the CPU can keep up with the interrupts, the overflow heuristics in >i8254_get_timecount() may break down). Other systems may have even >more limitations on the timecounters. > >Bruce > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 8:55:59 1999 Delivered-To: freebsd-current@freebsd.org Received: from mx-1e-a.omnipoint.com (1cust019.tnt3.dfw2.gmbpt.com [204.132.199.19]) by hub.freebsd.org (Postfix) with ESMTP id 2933814EF7 for ; Thu, 8 Jul 1999 08:55:57 -0700 (PDT) (envelope-from sjha@omnipoint.com) Message-ID: <81F84374BF62D1118E6900805FBECF9C0167C2A5@omnipoint.com> From: sjha@omnipoint.com To: FreeBSD-current@FreeBSD.ORG Subject: subscribe Date: Thu, 8 Jul 1999 09:55:55 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="x-user-defined" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 8:56:13 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 5BBE315508 for ; Thu, 8 Jul 1999 08:56:12 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id IAA40569; Thu, 8 Jul 1999 08:56:11 -0700 (PDT) (envelope-from dillon) Date: Thu, 8 Jul 1999 08:56:11 -0700 (PDT) From: Matthew Dillon Message-Id: <199907081556.IAA40569@apollo.backplane.com> To: freebsd-current@FreeBSD.ORG Subject: current kernel build temporarily broken Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Just to head off complaints - we accidently made an incomplete commit last night updating some vfs/bio stuff. I have an email in to Kirk with the pieces that we forgot. CURRENT will not build (or if it does, it will crunch) at the moment. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 11:24:13 1999 Delivered-To: freebsd-current@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 8D6D914F1E; Thu, 8 Jul 1999 11:24:03 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id LAA70100; Thu, 8 Jul 1999 11:23:43 -0700 (PDT) Date: Thu, 8 Jul 1999 11:23:42 -0700 (PDT) From: Julian Elischer To: Doug Rabson Cc: Seigo Tanimura , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG this is problematic. you cannot add a new element before the pending firing because you can't tell how far into the present trigger you are. On Thu, 8 Jul 1999, Doug Rabson wrote: > On Thu, 8 Jul 1999, Seigo Tanimura wrote: > > > On Wed, 7 Jul 1999 19:46:38 -0700 (PDT), > > Julian Elischer said: > > > > julian> With your scheme the clock needs to be always running at elevated speed. > > julian> Possibly you might have a startup routine that turns on the elevated > > julian> frequency, (basically does an 'aquire_timer0()' ) I would say that you > > julian> would have more success in implementing your finetimer() by using > > julian> "aquiretimer0" than the other way around. > > > > I agree that acquire_timer0() would give more freedom to the ticks > > to callout. Then I tried figuring out how to manage multiple > > callouts using acquire_timer0(), which is something like below. > > > > > > Let C the callout queue, and c_i a callout. (0 <= i < I) Next define f(c_i) as > > the callout function of c_i, and dt_rem(c_i) the time span between c_(i-1) and > > c_i. (dt_rem(c_-1) is defined as zero) We use the time span to avoid traversing > > though the queue to update the time tags on the callouts. > > > > (footnote: I'd better write in TeX :-<) > > > > Queueing a new callout c' to be made in t' involves a problem to find the > > maximum j (which is an integer, j >= 0) satisfying a constraint > > > > t' > \sum_(k=0)^(j) dt_rem(c_k) > > > > where the right hand side of the inequality is the time span after which > > the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) > > and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). > > > > In clkintr(), we dequeue c_0 from C, and make a callout to f(c_0). Then > > acquire_timer0() is called once more with the new dt_rem(c_0). dt_rem(c_i) is > > the difference of callout times, so they need not be updated on every clkintr(). > > > > > > Although the computational cost in clkintr() is generaly O(1), the queueing cost > > is O(I). Not sure whether we can reduce it or not (will it really make a trouble?) > > > > > > How does it sound? > > If I understand this correctly, you are suggesting that we program timer0 > so that we only take interrupts when a finetimer is due to fire? If so, > then it sounds very good. The idea of taking 6000+ interrupts/sec made me > uneasy, even though most would return without doing any work. > > -- > Doug Rabson Mail: dfr@nlsystems.com > Nonlinear Systems Ltd. Phone: +44 181 442 9037 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 11:29:36 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 0B980152F9; Thu, 8 Jul 1999 11:29:26 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA41802; Thu, 8 Jul 1999 11:28:10 -0700 (PDT) (envelope-from dillon) Date: Thu, 8 Jul 1999 11:28:10 -0700 (PDT) From: Matthew Dillon Message-Id: <199907081828.LAA41802@apollo.backplane.com> To: Jerry Bell Cc: "Brian F. Feldman" , Andrew Gallatin , Stephen McKay , alc@cs.rice.edu, freebsd-current@FreeBSD.ORG Subject: Re: Stuck in "objtrm" - live kernel test to run Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, I've traced the code down and I think that there is a good chance that the OBJ_DEAD fix that Alan described may solve the problem. What I think is happening is that a process context is holding a PIP count on the object, then deallocating the object and creating an interlock situation. There is a way we can find out for sure. For any of you with processes stuck in objtrm, see if you can gdb the kernel and get a backtrace of that process to see if it might be in a state where a previous call context is holding a PIP count on the object. gdb -k /kernel /dev/mem ^^ works better if this is a debug kernel but it doesn't have to be. It does have to be the kernel that is currently running. proc (e.g. proc 222) ^^^^ gdb's default radix is 10, but sometimes people change it to 16 so if it complains, you may be typing the number in in the wrong radix. back Note: the process cannot be swapped out, so if you've had a process stuck in objtrm for a long time try doing as "ps axfl" to force it's upages in and then gdb should be able to backtrace it. The 'f' in the ps does that. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 11:32: 7 1999 Delivered-To: freebsd-current@freebsd.org Received: from thelab.hub.org (nat195.34.mpoweredpc.net [142.177.195.34]) by hub.freebsd.org (Postfix) with ESMTP id F03D115517; Thu, 8 Jul 1999 11:31:59 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id PAA36579; Thu, 8 Jul 1999 15:32:04 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Thu, 8 Jul 1999 15:32:04 -0300 (ADT) From: The Hermit Hacker To: Pierre Beyssac Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Known MMAP() race conditions ... ? In-Reply-To: <19990708155002.H90983@enst.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 8 Jul 1999, Pierre Beyssac wrote: > > Right now, my 'fight' is weak, since all my friend has to do is point out > > that 'the MMAP() issue isn't an issue under Linux'...and, as far as I'm > > Linux has other -- IMHO more annoying -- issues, so I think your > friend had better stop bragging. Linux has strenghts over *BSD, and vice versa... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 11:34:48 1999 Delivered-To: freebsd-current@freebsd.org Received: from thelab.hub.org (nat195.34.mpoweredpc.net [142.177.195.34]) by hub.freebsd.org (Postfix) with ESMTP id 8748615571; Thu, 8 Jul 1999 11:34:39 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id PAA36583; Thu, 8 Jul 1999 15:34:25 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Thu, 8 Jul 1999 15:34:25 -0300 (ADT) From: The Hermit Hacker To: Matthew Dillon Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Known MMAP() race conditions ... ? In-Reply-To: <199907081458.HAA40125@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 8 Jul 1999, Matthew Dillon wrote: > :At that time, Matt pop'd up and stated that he knew of *at least* 6 MMAP() > :related race conditions that he was hoping to be able to get fixed "within > :a week"...that would have been two weeks ago. > > I think I was talking about mmap w/ NFS. > > Under FreeBSD-current I know of two problems ( though I could be > forgetting some ) - there is a problem when a lot of pages get dirtied > that can cause a low-memory deadlock to occur, and I believe there is a > problem when mlock() or madvise() is used though I haven't reproduced > it yet. > > Under FreeBSD-stable there are a number of additional, but minor problems > related to visibility of non-zero garbage after file EOF in an mmap(), > but these would have no effect on INN. > > What we need to know is why the machines are locking up. The usual > way to figure this out is to compile the kernel up with DDB and then > when it locks up ctl-alt-esc on the console to get the DDB prompt, > and do a 'ps' to see what the procsses are blocked in. No matter how much I want to get this fixed, I don't haven't yet been able to get DDB to dump properly :( I've tried various things wiht the portmaster that the serial console is attached to, but its either an old ComOS on that machine, or they've "secured" it up against the various work arounds :( and...my server does this once a day, so would be a perfect candidate for debugging :( Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 11:43:11 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 2389E155E3; Thu, 8 Jul 1999 11:43:06 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA41965; Thu, 8 Jul 1999 11:43:04 -0700 (PDT) (envelope-from dillon) Date: Thu, 8 Jul 1999 11:43:04 -0700 (PDT) From: Matthew Dillon Message-Id: <199907081843.LAA41965@apollo.backplane.com> To: The Hermit Hacker Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Known MMAP() race conditions ... ? References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :No matter how much I want to get this fixed, I don't haven't yet been able :to get DDB to dump properly :( I've tried various things wiht the :portmaster that the serial console is attached to, but its either an old :ComOS on that machine, or they've "secured" it up against the various work :arounds :( : :and...my server does this once a day, so would be a perfect candidate for :debugging :( : :Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy You *might* be able to leave a 'top -S' running in a tall window. It is possible that it will still operate even when the rest of the system locks up. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 11:59: 9 1999 Delivered-To: freebsd-current@freebsd.org Received: from thelab.hub.org (nat195.34.mpoweredpc.net [142.177.195.34]) by hub.freebsd.org (Postfix) with ESMTP id 14C5E15091; Thu, 8 Jul 1999 11:59:01 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id PAA36990; Thu, 8 Jul 1999 15:59:04 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Thu, 8 Jul 1999 15:59:03 -0300 (ADT) From: The Hermit Hacker To: Matthew Dillon Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Known MMAP() race conditions ... ? In-Reply-To: <199907081843.LAA41965@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Running now, will send you the output tomorrow when I get back to the office :) On Thu, 8 Jul 1999, Matthew Dillon wrote: > :No matter how much I want to get this fixed, I don't haven't yet been able > :to get DDB to dump properly :( I've tried various things wiht the > :portmaster that the serial console is attached to, but its either an old > :ComOS on that machine, or they've "secured" it up against the various work > :arounds :( > : > :and...my server does this once a day, so would be a perfect candidate for > :debugging :( > : > :Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy > > You *might* be able to leave a 'top -S' running in a tall window. It > is possible that it will still operate even when the rest of the system > locks up. > > -Matt > Matthew Dillon > > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 12:58:30 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id 07D41150E6 for ; Thu, 8 Jul 1999 12:58:28 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id MAA27652; Thu, 8 Jul 1999 12:58:19 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Thu, 8 Jul 1999 12:58:19 -0700 (PDT) From: Doug X-Sender: doug@dt054n86.san.rr.com To: The Hermit Hacker Cc: freebsd-current@FreeBSD.ORG Subject: Re: Known MMAP() race conditions ... ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 8 Jul 1999, The Hermit Hacker wrote: > right now, at work, I'm enjoying a 4 way battle. Me, fighting to bring in > FreeBSD to replace some of our Solaris boxes. A friend of mine, fighting > to bring in Linux to replace some of our Solaris boxes. My boss fighting > against both of us to keep Solaris "because its what we've always used". If it makes you feel any better, I'm in exactly the same position and losing my battle because of NFS and SMP issues. We just got two more intel boxes to work with on this project, one is already set up for linux (making a total of two), when I asked my boss about the other one he said he's not sure yet what he wants to do with it. There was a similar thread to this one instigated by me a few weeks ago. I got the same, "well run stuff that runs good on freebsd instead" response. My problem is that my project parameters are set by my boss (and reality) and require smp and nfs that work at least as well as linux'. They don't, so I'm losing my battle. Doug (who has to go ktrace amd again because it just fell over while my boss was testing it) -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 14:14:59 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 7B0C914DA8 for ; Thu, 8 Jul 1999 14:14:55 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA42935; Thu, 8 Jul 1999 14:14:45 -0700 (PDT) (envelope-from dillon) Date: Thu, 8 Jul 1999 14:14:45 -0700 (PDT) From: Matthew Dillon Message-Id: <199907082114.OAA42935@apollo.backplane.com> To: Peter Wemm Cc: freebsd-current@freebsd.org Subject: Re: current kernel build temporarily broken References: <19990708194337.F02AE78@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> it will crunch) at the moment. :> :> -Matt : :Is there anything I can do? : :Cheers, :-Peter (CC'ing to current) Kirk committed the fix -- The sense of a KASSERT() had gotten reversed accidently. Everything is hunky dory - except for the fact that I'm not able to commit any of these things myself. The patches remaining in the current VFS/BIO set are relatively minor, which means I can shift my attention over to the VM/INN/MMAP problems. The INN problem is a stickier issue and the solution may wind up making -current slightly less efficient in the near term. Basically what we have to do is to map writeable pages read-only and then take a fault to detect the clean->dirty transition. We can then synchronously block in vm_fault (without holding any locks, I might add) when there are too many dirty pages in the system. The pageout daemon will be able to run earlier (before it becomes too late). Also, on the positive side, by accounting dirty pages earlier we can manage low-memory situations all that more easily, which means that we can shift the clustering code from the beginning (when queued) to the end (when I/O is physically initiated). This will have the side effect of removing a whole cartload of junk from the filesystem critical path as well as remove a bunch of fields from the vnode structure. It will also greatly reduce the amount of memory-related blocking that occurs deep within a call-stack which should help performance on loaded machines by reducing lock contention. So if people don't scream at me for the slightly less efficient page faulting I think we can make progress. Actually, I don't think the page faulting will be as bad as all that... the loss of efficiency occurs mostly in shared R+W mmaps, not so much with BSS extensions because those tend to take a fault anyway because they start out as zero-fill. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 14:49:45 1999 Delivered-To: freebsd-current@freebsd.org Received: from taciturn.tcac.net (s197-cdm55.amar.tcac.net [207.50.55.197]) by hub.freebsd.org (Postfix) with SMTP id 8C3BA15538 for ; Thu, 8 Jul 1999 14:49:34 -0700 (PDT) (envelope-from bhughes@tcac.net) Received: (qmail 934 invoked by uid 1000); 8 Jul 1999 21:49:27 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Jul 1999 21:49:27 -0000 Date: Thu, 8 Jul 1999 16:49:26 -0500 (CDT) From: "Bradley T. Hughes" To: Bruce Evans Cc: current@FreeBSD.ORG Subject: Re: question regarding CMD640 chipsets In-Reply-To: <199907081241.WAA24705@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 8 Jul 1999, Bruce Evans wrote: > Rev.1.31 of ide_pci.c put the call in a dubious place (after some early > return statements) in ide_pci_attach(). Try putting it at the beginning > of the function (after `type' is initialized). hmmm.... if i had looked the code above that switch()... i probably wouldn't have had to ask... thanks much > Bruce Blackbox - An X11R6 Window Manager http://blackbox.wiw.org/ __________________________________ Bradley T. Hughes To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 17:58:28 1999 Delivered-To: freebsd-current@freebsd.org Received: from thelab.hub.org (nat195.34.mpoweredpc.net [142.177.195.34]) by hub.freebsd.org (Postfix) with ESMTP id 72A931553C for ; Thu, 8 Jul 1999 17:58:15 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id VAA44191; Thu, 8 Jul 1999 21:58:29 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Thu, 8 Jul 1999 21:58:29 -0300 (ADT) From: The Hermit Hacker To: Doug Cc: freebsd-current@FreeBSD.ORG Subject: Re: Known MMAP() race conditions ... ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I wish to make one thing perfectly clear here, or, rather, a couple of things. None of this thread was started as a 'slam session' against *anyone* out there... To those that have responded privately that "they are experiencing the problem too", without a better way of saying it...that helps absolutely noone. If you are experiencing the same problem, voice it to the list. Right now, there are only a few of us that I know of, and, compared to the "grand scheme of things", that isn't even a pebble on a beach. Personally, I'm at a disadvantage to debug this, as my baby is 2.5k kilometers away from me :( She's on a serial console, through a portmaster, that doesn't appear to have any way of allow me to break into DDB...but, even so, I'm spending as much time as possible following directions from those that appear to want to do more then just tell me to run Linux for an INN server *sigh* A few weeks ago, one admin posted a quick C program that, if you ran and ctl-c'd from it several times, would cause the machine to hang...can someone resend that out? I'll use it on my machine at home to test 4.0-CURRENT, and I have a machine at the offiec running 3.2-STABLE to test on... On Thu, 8 Jul 1999, Doug wrote: > On Thu, 8 Jul 1999, The Hermit Hacker wrote: > > > right now, at work, I'm enjoying a 4 way battle. Me, fighting to bring in > > FreeBSD to replace some of our Solaris boxes. A friend of mine, fighting > > to bring in Linux to replace some of our Solaris boxes. My boss fighting > > against both of us to keep Solaris "because its what we've always used". > > If it makes you feel any better, I'm in exactly the same position > and losing my battle because of NFS and SMP issues. We just got two more > intel boxes to work with on this project, one is already set up for linux > (making a total of two), when I asked my boss about the other one he said > he's not sure yet what he wants to do with it. > > There was a similar thread to this one instigated by me a few > weeks ago. I got the same, "well run stuff that runs good on freebsd > instead" response. My problem is that my project parameters are set by my > boss (and reality) and require smp and nfs that work at least as well as > linux'. They don't, so I'm losing my battle. > > Doug (who has to go ktrace amd again because it just fell over while my > boss was testing it) > -- > On account of being a democracy and run by the people, we are the only > nation in the world that has to keep a government four years, no matter > what it does. > -- Will Rogers > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 18:26:55 1999 Delivered-To: freebsd-current@freebsd.org Received: from ftp.dns.ne.jp (ftp.dns.ne.jp [210.155.3.5]) by hub.freebsd.org (Postfix) with ESMTP id 6D07B14E02; Thu, 8 Jul 1999 18:26:45 -0700 (PDT) (envelope-from tanimura@sakuramail.com) Received: from silver.carrots (yksk0124.ppp.infoweb.ne.jp [210.131.91.88]) by ftp.dns.ne.jp (8.9.2/8.8.5) with ESMTP id KAA16514; Fri, 9 Jul 1999 10:26:41 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by silver.carrots (8.9.3+3.2W/3.7W) with ESMTP id KAA70669; Fri, 9 Jul 1999 10:26:15 +0900 (JST) To: julian@whistle.com Cc: dfr@nlsystems.com, tanimura@naklab.dnj.ynu.ac.jp, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Cc: Seigo Tanimura Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) From: Seigo Tanimura In-Reply-To: Your message of "Thu, 8 Jul 1999 11:23:42 -0700 (PDT)" References: X-Mailer: Mew version 1.93 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: <19990709102615A.tanimura@sakuramail.com> Date: Fri, 09 Jul 1999 10:26:15 +0900 X-Dispatcher: imput version 980905(IM100) Lines: 32 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From: Julian Elischer Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) Date: Thu, 8 Jul 1999 11:23:42 -0700 (PDT) Message-ID: julian> this is problematic. julian> you cannot add a new element before the pending firing because you can't julian> tell how far into the present trigger you are. The workaround below would help it. The time elapsed since the last aquire_timer0() can be determined by latching the timer counter. From: Seigo Tanimura Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer) Date: Thu, 08 Jul 1999 18:40:23 +0900 Message-ID: <199907080940.SAA26649@rina.naklab.dnj.ynu.ac.jp> tanimura> > t' > \sum_(k=0)^(j) dt_rem(c_k) tanimura> > tanimura> > where the right hand side of the inequality is the time span after which tanimura> > the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) tanimura> > and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). tanimura> tanimura> If t' is less than dt_rem(c_0) then we have no feasible j. This is the case tanimura> in which we must reaquire_timer0() using t'. Then, after interting c', dt_rem(c_1) tanimura> is updated to be (dt_rem(c_1) - (time elapsed since the last aquire_timer0())), tanimura> so that c_1 can be armed later. Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 19:32:55 1999 Delivered-To: freebsd-current@freebsd.org Received: from bilby.prth.tensor.pgs.com (bilby.prth.tensor.pgs.com [157.147.232.237]) by hub.freebsd.org (Postfix) with ESMTP id 8F71914D0C for ; Thu, 8 Jul 1999 19:32:43 -0700 (PDT) (envelope-from shocking@ariadne.prth.tensor.pgs.com) Received: from bandicoot.prth.tensor.pgs.com (bandicoot.prth.tensor.pgs.com [157.147.224.1]) by bilby.prth.tensor.pgs.com (8.9.3/8.8.8) with ESMTP id KAA15204 for ; Fri, 9 Jul 1999 10:31:28 +0800 (WST) Received: from ariadne.tensor.pgs.com (ariadne [157.147.227.36]) by bandicoot.prth.tensor.pgs.com (8.9.3/8.8.8) with SMTP id KAA28880 for ; Fri, 9 Jul 1999 10:32:38 +0800 (WST) Received: from ariadne by ariadne.tensor.pgs.com (SMI-8.6/SMI-SVR4) id KAA04002; Fri, 9 Jul 1999 10:32:37 +0800 Message-Id: <199907090232.KAA04002@ariadne.tensor.pgs.com> X-Mailer: exmh version 2.0.2 2/24/98 To: current@freebsd.org Subject: MTRR stuff Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 09 Jul 1999 10:32:37 +0800 From: Stephen Hocking-Senior Programmer PGS Tensor Perth Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG For some video cards (to wit, the voodoo stuff), the MTRRs should be set up as follows write-combining +----------------------------------------------------------+ +-------+ uncacheable i.e. the two regions have the same starting area, but the small chunk for the registers should be uncacheable. When I try to do this using memconf on my K6-2, it spits the dummy. Is there a work around for this? Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true." Robert Wilensky, University of California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 20:30:19 1999 Delivered-To: freebsd-current@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id 30A5914EBA for ; Thu, 8 Jul 1999 20:30:11 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id NAA02868; Fri, 9 Jul 1999 13:00:05 +0930 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA02085; Fri, 9 Jul 1999 12:59:51 +0930 Date: Fri, 9 Jul 1999 12:59:51 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: "David O'Brien" Cc: Frank Nobis , current@freebsd.org Subject: Re: Break of today current and patch In-Reply-To: <19990708052643.A52964@dragon.nuxi.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 8 Jul 1999, David O'Brien wrote: > > todays current breaks in build of libgcc > > Since libgcc/Makefile hasn't been touched since April, me thinks > something else is going on in your environment. > > > ===> gnu/lib/libgcc > > c++ -O2 -mpentium -fpcc-struct-return -ffast-math -fno-strength-reduce > ... You don't have CXXFLAGS set in your environment, do you? That will break several of the things under gnu/ Kris ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 20:40:55 1999 Delivered-To: freebsd-current@freebsd.org Received: from bilby.prth.tensor.pgs.com (bilby.prth.tensor.pgs.com [157.147.232.237]) by hub.freebsd.org (Postfix) with ESMTP id 98E0714F51 for ; Thu, 8 Jul 1999 20:40:49 -0700 (PDT) (envelope-from shocking@ariadne.prth.tensor.pgs.com) Received: from bandicoot.prth.tensor.pgs.com (bandicoot.prth.tensor.pgs.com [157.147.224.1]) by bilby.prth.tensor.pgs.com (8.9.3/8.8.8) with ESMTP id LAA15402 for ; Fri, 9 Jul 1999 11:39:36 +0800 (WST) Received: from ariadne.tensor.pgs.com (ariadne [157.147.227.36]) by bandicoot.prth.tensor.pgs.com (8.9.3/8.8.8) with SMTP id LAA28464 for ; Fri, 9 Jul 1999 11:40:46 +0800 (WST) Received: from ariadne by ariadne.tensor.pgs.com (SMI-8.6/SMI-SVR4) id LAA04093; Fri, 9 Jul 1999 11:40:46 +0800 Message-Id: <199907090340.LAA04093@ariadne.tensor.pgs.com> X-Mailer: exmh version 2.0.2 2/24/98 To: current@freebsd.org Subject: Dirty pages & low memory hangs with mmap Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 09 Jul 1999 11:40:45 +0800 From: Stephen Hocking-Senior Programmer PGS Tensor Perth Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've been seeing an interesting problem when doing a make installworld on a 486 with 16MB of memory. Immediately after installing libc.so.3, it will hang. DDB gives a backtrace to a mmap related call (sorry, the box is at home at the memoment and this email was prompted by something on freebsd-current). It's quite reproducible, but worked around by issuing a bunch of syncs every second. Outside of that, the box runs fine (it's my ppp NAT gateway, runs squid & nntpcached as well). Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true." Robert Wilensky, University of California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 8 20:56:10 1999 Delivered-To: freebsd-current@freebsd.org Received: from misha.cisco.com (misha.cisco.com [171.69.206.50]) by hub.freebsd.org (Postfix) with ESMTP id 0CDA514D5F for ; Thu, 8 Jul 1999 20:56:07 -0700 (PDT) (envelope-from mi@misha.cisco.com) Received: (from mi@localhost) by misha.cisco.com (8.9.3/8.9.1) id XAA52348 for current@freebsd.org; Thu, 8 Jul 1999 23:56:06 -0400 (EDT) (envelope-from mi) Message-Id: <199907090356.XAA52348@misha.cisco.com> Subject: Re: Dirty pages & low memory hangs with mmap In-Reply-To: <199907090340.LAA04093@ariadne.tensor.pgs.com> from Stephen Hocking-Senior Programmer PGS Tensor Perth at "Jul 9, 1999 11:40:45 am" To: current@freebsd.org Date: Thu, 8 Jul 1999 23:56:06 -0400 (EDT) Reply-To: mi@aldan.algebra.com From: Mikhail Teterin X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Stephen Hocking-Senior Programmer PGS Tensor Perth once wrote: > I've been seeing an interesting problem when doing a make installworld > on a 486 with 16MB of memory. Immediately after installing libc.so.3, > it will hang. Happened to me here today on Pentium 90 with 64Mb of RAM. It was installing world (with -j 3) from nfs mounted /usr/obj and /usr/src (mounted ro). It did not hang but rebooted (no backtraces, the kernel is built with -fomit-frame-pointer). I restarted the installworld and it completed fine, I guess, it did not have to reinstall libc.so.3 the second time, because of ``install -C''. This was not current either -- going from a 2 weeks old -stable to the most recent -stable. -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 9 2:13:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from trinity.radio-do.de (trinity.Radio-do.de [193.101.164.3]) by hub.freebsd.org (Postfix) with ESMTP id 255F31550A for ; Fri, 9 Jul 1999 02:13:41 -0700 (PDT) (envelope-from fn@trinity.radio-do.de) Received: (from fn@localhost) by trinity.radio-do.de (8.9.3/8.9.1) id LAA64843; Fri, 9 Jul 1999 11:13:23 +0200 (CEST) (envelope-from fn) Message-ID: <19990709111323.C64780@radio-do.de> Date: Fri, 9 Jul 1999 11:13:23 +0200 From: Frank Nobis To: Kris Kennaway , "David O'Brien" Cc: current@FreeBSD.ORG Subject: Re: Break of today current and patch References: <19990708052643.A52964@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Kris Kennaway on Fri, Jul 09, 1999 at 12:59:51PM +0930 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 09, 1999 at 12:59:51PM +0930, Kris Kennaway wrote: > On Thu, 8 Jul 1999, David O'Brien wrote: > > > > todays current breaks in build of libgcc > > > > Since libgcc/Makefile hasn't been touched since April, me thinks > > something else is going on in your environment. > > > > > ===> gnu/lib/libgcc > > > c++ -O2 -mpentium -fpcc-struct-return -ffast-math -fno-strength-reduce > > ... > > You don't have CXXFLAGS set in your environment, do you? That will break > several of the things under gnu/ I have set CFLAGS in my env, but never CXXFLAGS. I will give it a try with the -v flag added as David mentioned and alternativ without any CFLAGS defined. The /etc/make.conf is just plain regarding to this variables- Regards Frank -- Frank Nobis Email: PGP AVAILABLE Landgrafenstr. 130 dg3dcn http://www.radio-do.de/~fn/ 44139 Dortmund Powered by SMP FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 9 2:32:43 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id C862014C45 for ; Fri, 9 Jul 1999 02:32:41 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id FAA68019; Fri, 9 Jul 1999 05:32:40 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Fri, 9 Jul 1999 05:32:40 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Stephen Hocking-Senior Programmer PGS Tensor Perth Cc: current@FreeBSD.org Subject: Re: MTRR stuff In-Reply-To: <199907090232.KAA04002@ariadne.tensor.pgs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 9 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > For some video cards (to wit, the voodoo stuff), the MTRRs should be set up as > follows > > write-combining > +----------------------------------------------------------+ > +-------+ > uncacheable > > i.e. the two regions have the same starting area, but the small chunk for the > registers should be uncacheable. When I try to do this using memconf on my > K6-2, it spits the dummy. Is there a work around for this? Spits the dummy? And do you mean memcontrol? I have no idea what you mean by that. However, the natural thing to do would be this: +-------+ write-combine uncacheable +----------------------------------------------+ uncacheable > > > Stephen > -- > The views expressed above are not those of PGS Tensor. > > "We've heard that a million monkeys at a million keyboards could produce > the Complete Works of Shakespeare; now, thanks to the Internet, we know > this is not true." Robert Wilensky, University of California > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 9 3: 8:40 1999 Delivered-To: freebsd-current@freebsd.org Received: from bilby.prth.tensor.pgs.com (bilby.prth.tensor.pgs.com [157.147.232.237]) by hub.freebsd.org (Postfix) with ESMTP id 0458314E0A; Fri, 9 Jul 1999 03:08:34 -0700 (PDT) (envelope-from shocking@ariadne.prth.tensor.pgs.com) Received: from bandicoot.prth.tensor.pgs.com (bandicoot.prth.tensor.pgs.com [157.147.224.1]) by bilby.prth.tensor.pgs.com (8.9.3/8.8.8) with ESMTP id SAA16235; Fri, 9 Jul 1999 18:07:20 +0800 (WST) Received: from ariadne.tensor.pgs.com (ariadne [157.147.227.36]) by bandicoot.prth.tensor.pgs.com (8.9.3/8.8.8) with SMTP id SAA17170; Fri, 9 Jul 1999 18:08:32 +0800 (WST) Received: from ariadne by ariadne.tensor.pgs.com (SMI-8.6/SMI-SVR4) id SAA05586; Fri, 9 Jul 1999 18:08:31 +0800 Message-Id: <199907091008.SAA05586@ariadne.tensor.pgs.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Brian F. Feldman" Cc: current@freebsd.org Subject: Re: MTRR stuff In-reply-to: Your message of "Fri, 09 Jul 1999 05:32:40 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 09 Jul 1999 18:08:31 +0800 From: Stephen Hocking-Senior Programmer PGS Tensor Perth Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Spits the dummy? And do you mean memcontrol? It (memcontrol, I was typing the name from memory at work) complains. I was trying to set up the MTRRs like the Linux voodoo device driver does. I hadn't thought of doing it the way you suggest, as the documentation says that the size has to be a power of 2. > I have no idea what you mean by that. However, the natural thing to do would > be this: > +-------+ write-combine uncacheable > +----------------------------------------------+ uncacheable > -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true." Robert Wilensky, University of California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 9 3:35:26 1999 Delivered-To: freebsd-current@freebsd.org Received: from ren.detir.qld.gov.au (ns.detir.qld.gov.au [203.46.81.66]) by hub.freebsd.org (Postfix) with ESMTP id 0D86115234 for ; Fri, 9 Jul 1999 03:35:21 -0700 (PDT) (envelope-from syssgm@detir.qld.gov.au) Received: by ren.detir.qld.gov.au; id UAA02507; Fri, 9 Jul 1999 20:34:05 +1000 (EST) Received: from ogre.detir.qld.gov.au(167.123.8.3) by ren.detir.qld.gov.au via smap (3.2) id xma002503; Fri, 9 Jul 99 20:34:04 +1000 Received: from atlas.detir.qld.gov.au (atlas.detir.qld.gov.au [167.123.8.9]) by ogre.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id UAA09658; Fri, 9 Jul 1999 20:33:25 +1000 (EST) Received: from nymph.detir.qld.gov.au (nymph.detir.qld.gov.au [167.123.10.10]) by atlas.detir.qld.gov.au (8.8.5/8.8.5) with ESMTP id UAA24100; Fri, 9 Jul 1999 20:33:24 +1000 (EST) Received: from nymph.detir.qld.gov.au (localhost.detir.qld.gov.au [127.0.0.1]) by nymph.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id UAA03176; Fri, 9 Jul 1999 20:33:24 +1000 (EST) (envelope-from syssgm@nymph.detir.qld.gov.au) Message-Id: <199907091033.UAA03176@nymph.detir.qld.gov.au> To: Matthew Dillon Cc: freebsd-current@freebsd.org, syssgm@detir.qld.gov.au Subject: Re: Stuck in "objtrm" - live kernel test to run References: <199907081828.LAA41802@apollo.backplane.com> In-Reply-To: <199907081828.LAA41802@apollo.backplane.com> from Matthew Dillon at "Thu, 08 Jul 1999 11:28:10 -0700" Date: Fri, 09 Jul 1999 20:33:23 +1000 From: Stephen McKay Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thursday, 8th July 1999, Matthew Dillon wrote: > There is a way we can find out for sure. For any of you with processes > stuck in objtrm, see if you can gdb the kernel and get a backtrace > of that process to see if it might be in a state where a previous > call context is holding a PIP count on the object. Just for completeness, here's mine again, done with your ps trick: (kgdb) back #0 mi_switch () at ../../kern/kern_synch.c:827 #1 0xc014a5bd in tsleep (ident=0xc32ea21c, priority=4, wmesg=0xc023db84 "objtrm", timo=0) at ../../kern/kern_synch.c:443 #2 0xc01e9741 in vm_object_terminate (object=0xc32ea21c) at ../../vm/vm_object.h:230 #3 0xc01e96f1 in vm_object_deallocate (object=0xc32ea21c) at ../../vm/vm_object.c:382 #4 0xc01e6acb in vm_map_entry_delete (map=0xc3047440, entry=0xc3240190) at ../../vm/vm_map.c:1680 #5 0xc01e6c89 in vm_map_delete (map=0xc3047440, start=0, end=3217022976) at ../../vm/vm_map.c:1783 #6 0xc01e6d1d in vm_map_remove (map=0xc3047440, start=0, end=3217022976) at ../../vm/vm_map.c:1808 #7 0xc0141d20 in exit1 (p=0xc322f0a0, rv=0) at ../../kern/kern_exit.c:220 #8 0xc0141b24 in exit1 (p=0xc322f0a0, rv=-1021614488) at ../../kern/kern_exit.c:106 #9 0xc020e41a in syscall (frame={tf_fs = 47, tf_es = 137297967, tf_ds = -1078001617, tf_edi = 136021320, tf_esi = 0, tf_ebp = -1077947348, tf_isp = -1020915756, tf_ebx = -1, tf_edx = 135690384, tf_ecx = 136200192, tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = 135656524, tf_cs = 31, tf_eflags = 582, tf_esp = -1077947368, tf_ss = 47}) at ../../i386/i386/trap.c:1056 #10 0xc0202cc0 in Xint0x80_syscall () error reading /proc/27157/mem And for extra points: (kgdb) frame 4 #4 0xc01e6acb in vm_map_entry_delete (map=0xc3047440, entry=0xc3240190) at ../../vm/vm_map.c:1680 1680 vm_object_deallocate(entry->object.vm_object); (kgdb) p/x *entry $10 = {prev = 0xc3047460, next = 0xc3249e38, start = 0x81c6000, end = 0x8458000, avail_ssize = 0x0, object = {vm_object = 0xc32ea21c, sub_map = 0xc32ea21c}, offset = 0x15000, eflags = 0x0, protection = 0x7, max_protection = 0x7, inheritance = 0x1, wired_count = 0x0} I haven't made any clever conclusions from this, but you might do better. > Note: the process cannot be swapped out, so if you've had a process > stuck in objtrm for a long time try doing as "ps axfl" to force it's > upages in and then gdb should be able to backtrace it. The 'f' in the ps > does that. Cute. After the ps axlf, all the swapped out processes went from 0 to 8 KB resident. But the stuck process stayed at 0 KB resident. It wasn't swapped out anyway, according to the ps flags, so it should have had some resident pages. Seems like a contradiction to me. Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 9 4:29:10 1999 Delivered-To: freebsd-current@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 609DC14CC7 for ; Fri, 9 Jul 1999 04:29:02 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 112Ypx-000OIn-00 for current@freebsd.org; Fri, 09 Jul 1999 13:29:01 +0200 From: Sheldon Hearn To: current@freebsd.org Subject: HEADS UP: Inetd wrapping option syntax changed Date: Fri, 09 Jul 1999 13:29:01 +0200 Message-ID: <93420.931519741@axl.noc.iafrica.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, About a week ago, we made inetd's TCP Wrapper support a command-line option instead of a compile-time option. While this was met with unanimous approval, a number of people objected to the limited -w option. I've just committed a change that allows wrapping for each of internal and external services to be enabled independantly of the other. If you have inetd_flags="-w -w" in /etc/rc.conf, you'll need to change it to: inetd_flags="-w -W" or remove the option altogether, since this is the defaults/rc.conf behaviour anyway. As with the previous change, folks who don't mergemaster after a make world are going to experience problems with subsequent reboots. :-) Thanks to everyone who put effort into persuading me against the original command-line syntax. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 9 4:34:53 1999 Delivered-To: freebsd-current@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id 96293154DF; Fri, 9 Jul 1999 04:34:48 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id VAA14655; Fri, 9 Jul 1999 21:34:38 +1000 Date: Fri, 9 Jul 1999 21:34:38 +1000 From: Bruce Evans Message-Id: <199907091134.VAA14655@godzilla.zeta.org.au> To: dfr@nlsystems.com, julian@whistle.com Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) Cc: freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG, tanimura@naklab.dnj.ynu.ac.jp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >this is problematic. > >you cannot add a new element before the pending firing because you can't >tell how far into the present trigger you are. This is not a problem for readable counters like the i8254. The problem for the i8254 is that reading and writing it takes a long time (perhaps 5 usec each). Every write to it will decrease its accuracy (perhaps by 1 usec after careful calibration). Thus if the i8254 is used for generating non-periodic interrupts with an average period of 333 usec, it may take 15/333 of the CPU (estimate another 5 usec for interrupt handling), and if it is also used for timecounting then it may drift by 333 usec/second. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 9 6:49:21 1999 Delivered-To: freebsd-current@freebsd.org Received: from trinity.radio-do.de (trinity.Radio-do.de [193.101.164.3]) by hub.freebsd.org (Postfix) with ESMTP id B055414EE1 for ; Fri, 9 Jul 1999 06:49:17 -0700 (PDT) (envelope-from fn@trinity.radio-do.de) Received: (from fn@localhost) by trinity.radio-do.de (8.9.3/8.9.1) id PAA66452; Fri, 9 Jul 1999 15:48:58 +0200 (CEST) (envelope-from fn) To: Sheldon Hearn Cc: current@freebsd.org Subject: Re: Break of today current and patch References: <99131.931424475@axl.noc.iafrica.com> From: Frank Nobis Date: 09 Jul 1999 15:48:58 +0200 In-Reply-To: Sheldon Hearn's message of "Thu, 08 Jul 1999 11:01:15 +0200" Message-ID: Lines: 27 User-Agent: Gnus/5.070093 (Pterodactyl Gnus v0.93) XEmacs/21.1 (20 Minutes to Nikko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn writes: > On Wed, 07 Jul 1999 23:12:57 +0200, Frank Nobis wrote: > > > todays current breaks in build of libgcc > > > > ===> gnu/lib/libgcc > > c++ -O2 -mpentium -fpcc-struct-return -ffast-math -fno-strength-reduce -malig > > Hi Frank, > > You're sure the same breakage exists when you're using non-weird > optimizations? Try with just "-O -pipe". That made it. Without any C(XX)FLAGS the make just got over that point. Tha fancy flags come from the bashrc of a friend of mine. I have overseen it until now :-( Regards, Frank -- Frank Nobis Email: PGP AVAILABLE Landgrafenstr. 130 dg3dcn http://www.radio-do.de/~fn/ 44139 Dortmund Powered by SMP FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 9 7:33:49 1999 Delivered-To: freebsd-current@freebsd.org Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (Postfix) with ESMTP id A3DD1155F9 for ; Fri, 9 Jul 1999 07:33:35 -0700 (PDT) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.9.3/8.9.3/Kp) with ESMTP id OAA17233 for ; Fri, 9 Jul 1999 14:33:34 GMT Message-ID: <37860782.84886040@tdx.co.uk> Date: Fri, 09 Jul 1999 15:30:26 +0100 From: Karl Pielorz Organization: TDX - The Digital eXchange X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org Subject: Difference between building and running under -current vs. 3.2-Release? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi All, The combination of Apache + PHP + FreeTDS I use under 3.2-Release without problems, segfaults when it's built and run under -current (current as of about 2 weeks ago). i.e. I get "Segmentation fault - core dumped" when I try to run it. If I try to run gdb through the core file, that also segfaults as well, and dies... :( I'm no expert on debugging things, hence this email... By running httpd with gdb, I get the following output: " Program received signal SIGSEGV, Segmentation fault. 0x281c0177 in strncpy () from /usr/lib/libc.so.3 (gdb) bt #0 0x281c0177 in strncpy () from /usr/lib/libc.so.3 #1 0x2812de51 in tds_set_server (tds_login=0x6374652f, server=0x0) at login.c:57 #2 0x2812a3b9 in dbopen (login=0x281d894b, server=0x0) at dblib.c:398 #3 0x28199118 in endpwent () from /usr/lib/libc.so.3 #4 0x28198e83 in getpwnam () from /usr/lib/libc.so.3 #5 0x80c2185 in ap_uname2id (name=0x8101dc8 "nobody") at util.c:1799 #6 0x80ad4b1 in init_config_globals (p=0x815b00c) at http_config.c:1388 #7 0x80ad754 in ap_read_config (p=0x815b00c, ptemp=0x815e00c, confname=0x81575a0 "/usr/local/etc/apache/conf/httpd.conf") at http_config.c:1466 #8 0x80b6f26 in main (argc=3, argv=0xbfbfdba4) at http_main.c:4574 " Anyone got any suggestions as to why it builds and runs under 3.2, builds and faults under 4.0-current?. If I copy the httpd built on 3.2 and run that on -current, it also segfaults... Any suggestions where to go next? (i.e. who I should be talking to, the FreeBSD people, the Apache people, the PHP people, or the FreeTDS people?) The machine running this isn't production, but it does get very busy when it is used... It would have been nice to keep it as 4.0, but if I can't get it to build and run at all, I'll have to back it down to 3.2-Release... The machine is a P2-450, w/512mb RAM. The 3.2-Release box is a Pentium 233 with 64Mb of RAM. If it can't be fixed, or no one has any time I'll just back the box down to 3.2 - I just thought it would be nice to try :) Thanks, -Karl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 9 7:58:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from web130.yahoomail.com (web130.yahoomail.com [205.180.60.199]) by hub.freebsd.org (Postfix) with SMTP id AA56714F12 for ; Fri, 9 Jul 1999 07:58:49 -0700 (PDT) (envelope-from valsho@yahoo.com) Message-ID: <19990709145915.20367.rocketmail@web130.yahoomail.com> Received: from [147.226.112.101] by web130.yahoomail.com; Fri, 09 Jul 1999 07:59:15 PDT Date: Fri, 9 Jul 1999 07:59:15 -0700 (PDT) From: "Valentin S. Chopov" Subject: current.freebsd.org's 4.0-1999070[89]-CURRENT dir perm To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Permissions in ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386 are: drwx------ 19 root 0 1024 Jul 8 12:38 4.0-19990708-CURRENT drwx------ 19 root 0 1024 Jul 9 12:37 4.0-19990709-CURRENT Val _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 9 10:19:19 1999 Delivered-To: freebsd-current@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id DFB3C14E1C for ; Fri, 9 Jul 1999 10:19:17 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id KAA12237; Fri, 9 Jul 1999 10:19:26 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: "Valentin S. Chopov" Cc: current@FreeBSD.ORG Subject: Re: current.freebsd.org's 4.0-1999070[89]-CURRENT dir perm In-reply-to: Your message of "Fri, 09 Jul 1999 07:59:15 PDT." <19990709145915.20367.rocketmail@web130.yahoomail.com> Date: Fri, 09 Jul 1999 10:19:26 -0700 Message-ID: <12233.931540766@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Weird! Fixed. > Permissions in > ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386 > are: > > drwx------ 19 root 0 1024 Jul 8 12:38 > 4.0-19990708-CURRENT > drwx------ 19 root 0 1024 Jul 9 12:37 > 4.0-19990709-CURRENT > > Val > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 9 10:19:25 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id EFA3A15680 for ; Fri, 9 Jul 1999 10:19:20 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id NAA75582; Fri, 9 Jul 1999 13:19:15 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Fri, 9 Jul 1999 13:19:15 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Stephen Hocking-Senior Programmer PGS Tensor Perth Cc: current@FreeBSD.org Subject: Re: MTRR stuff In-Reply-To: <199907091008.SAA05586@ariadne.tensor.pgs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 9 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > > > > > Spits the dummy? And do you mean memcontrol? > > It (memcontrol, I was typing the name from memory at work) complains. I was > trying to set up the MTRRs like the Linux voodoo device driver does. I hadn't > thought of doing it the way you suggest, as the documentation says that the > size has to be a power of 2. What exactly are the ranges? You haven't given me enough info yet. I wrote the K6-* MTRR driver, so I'd like to help. > > > I have no idea what you mean by that. However, the natural thing to do would > > be this: > > +-------+ write-combine uncacheable > > +----------------------------------------------+ uncacheable > > > > -- > The views expressed above are not those of PGS Tensor. > > "We've heard that a million monkeys at a million keyboards could produce > the Complete Works of Shakespeare; now, thanks to the Internet, we know > this is not true." Robert Wilensky, University of California > > > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 9 13:14: 4 1999 Delivered-To: freebsd-current@freebsd.org Received: from dead-end.net (dead-end.net [216.15.131.2]) by hub.freebsd.org (Postfix) with ESMTP id C934514DC0 for ; Fri, 9 Jul 1999 13:13:50 -0700 (PDT) (envelope-from rock@dead-end.net) Received: from dead-end.net (p3E9C3739.dip.t-dialin.net [62.156.55.57]) by dead-end.net (8.9.3/DEAD-END/1999022000) with ESMTP id WAA01326 for ; Fri, 9 Jul 1999 22:13:47 +0200 (CEST) (envelope-from rock@dead-end.net) Message-ID: <37865812.DC1A235C@dead-end.net> Date: Fri, 09 Jul 1999 22:14:10 +0200 From: "D. Rock" Organization: ... X-Mailer: Mozilla 4.6 [de] (Win98; U) X-Accept-Language: de MIME-Version: 1.0 To: current@freebsd.org Subject: dev_t and system accounting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, the new dev_t stuff in the kernel keeps system accounting showing up the tty properly. After taking a look at the fix for the swap device, I propose the following equivalent fix: Index: kern/kern_acct.c =================================================================== RCS file: /data/cvs/src/sys/kern/kern_acct.c,v retrieving revision 1.20 diff -u -r1.20 kern_acct.c --- kern_acct.c 1999/04/27 11:15:53 1.20 +++ kern_acct.c 1999/07/09 19:57:38 @@ -221,7 +221,7 @@ /* (7) The terminal from which the process was started */ if ((p->p_flag & P_CONTROLT) && p->p_pgrp->pg_session->s_ttyp) - acct.ac_tty = p->p_pgrp->pg_session->s_ttyp->t_dev; + acct.ac_tty = dev2udev(p->p_pgrp->pg_session->s_ttyp->t_dev); else - acct.ac_tty = NODEV; + acct.ac_tty = dev2udev(NODEV); Index: sys/acct.h =================================================================== RCS file: /data/cvs/src/sys/sys/acct.h,v retrieving revision 1.9 diff -u -r1.9 acct.h --- acct.h 1998/02/01 20:08:35 1.9 +++ acct.h 1999/07/09 19:57:15 @@ -60,7 +60,7 @@ gid_t ac_gid; /* group id */ u_int16_t ac_mem; /* average memory usage */ comp_t ac_io; /* count of IO blocks */ - dev_t ac_tty; /* controlling tty */ + udev_t ac_tty; /* controlling tty */ #define AFORK 0x01 /* forked but not exec'ed */ #define ASU 0x02 /* used super-user permissions */ Daniel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 9 14:30:18 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 478AA14EE1 for ; Fri, 9 Jul 1999 14:30:13 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id XAA05193; Fri, 9 Jul 1999 23:29:33 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "D. Rock" Cc: current@FreeBSD.ORG Subject: Re: dev_t and system accounting In-reply-to: Your message of "Fri, 09 Jul 1999 22:14:10 +0200." <37865812.DC1A235C@dead-end.net> Date: Fri, 09 Jul 1999 23:29:33 +0200 Message-ID: <5191.931555773@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <37865812.DC1A235C@dead-end.net>, "D. Rock" writes: >Hi, > >the new dev_t stuff in the kernel keeps system accounting showing up >the tty properly. After taking a look at the fix for the swap device, >I propose the following equivalent fix: Looks good, could you try this version for me ? Index: sys/acct.h =================================================================== RCS file: /home/ncvs/src/sys/sys/acct.h,v retrieving revision 1.9 diff -u -r1.9 acct.h --- acct.h 1998/02/01 20:08:35 1.9 +++ acct.h 1999/07/09 21:27:49 @@ -49,6 +49,12 @@ */ typedef u_int16_t comp_t; +#ifdef KERNEL +#define __dev_t udev_t +#else +#define __dev_t dev_t +#endif + #define AC_COMM_LEN 16 struct acct { char ac_comm[AC_COMM_LEN]; /* command name */ @@ -60,7 +66,7 @@ gid_t ac_gid; /* group id */ u_int16_t ac_mem; /* average memory usage */ comp_t ac_io; /* count of IO blocks */ - dev_t ac_tty; /* controlling tty */ + __dev_t ac_tty; /* controlling tty */ #define AFORK 0x01 /* forked but not exec'ed */ #define ASU 0x02 /* used super-user permissions */ @@ -69,6 +75,7 @@ #define AXSIG 0x10 /* killed by a signal */ u_int8_t ac_flag; /* accounting flags */ }; +#undef __dev_t /* * 1/AHZ is the granularity of the data encoded in the comp_t fields. Index: kern/kern_acct.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_acct.c,v retrieving revision 1.20 diff -u -r1.20 kern_acct.c --- kern_acct.c 1999/04/27 11:15:53 1.20 +++ kern_acct.c 1999/07/09 21:26:44 @@ -221,9 +221,9 @@ /* (7) The terminal from which the process was started */ if ((p->p_flag & P_CONTROLT) && p->p_pgrp->pg_session->s_ttyp) - acct.ac_tty = p->p_pgrp->pg_session->s_ttyp->t_dev; + acct.ac_tty = dev2udev(p->p_pgrp->pg_session->s_ttyp->t_dev); else - acct.ac_tty = NODEV; + acct.ac_tty = NOUDEV; /* (8) The boolean flags that tell how the process terminated, etc. */ acct.ac_flag = p->p_acflag; -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 9 15:19:13 1999 Delivered-To: freebsd-current@freebsd.org Received: from server.rock (p3E9C3638.dip.t-dialin.net [62.156.54.56]) by hub.freebsd.org (Postfix) with ESMTP id A42AB14CC2 for ; Fri, 9 Jul 1999 15:19:05 -0700 (PDT) (envelope-from rock@dead-end.net) Received: (from rock@localhost) by server.rock (8.9.3/8.9.3/ROCK/1999053100) id AAA37023; Sat, 10 Jul 1999 00:19:00 +0200 (CEST) (envelope-from rock) Date: Sat, 10 Jul 1999 00:19:00 +0200 (CEST) From: "D. Rock" Message-Id: <199907092219.AAA37023@server.rock> To: phk@critter.freebsd.dk Cc: current@FreeBSD.ORG Subject: Re: dev_t and system accounting In-Reply-To: <5191.931555773@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >Hi, > > > >the new dev_t stuff in the kernel keeps system accounting showing up > >the tty properly. After taking a look at the fix for the swap device, > >I propose the following equivalent fix: > > Looks good, could you try this version for me ? [patch deleted] I recompiled a "make world" and also rebuild the kernel with this patch. No problems. lastcomm now again works as expected. I already ran with the modified kernel from my patch. But I didn't rebuilt world, so I didn't notice the userland problems for dev_t/udev_t Daniel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 9 16:46:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (Postfix) with ESMTP id D8F9D15053 for ; Fri, 9 Jul 1999 16:46:21 -0700 (PDT) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.9.3/8.9.3/Kp) with ESMTP id XAA01977 for ; Fri, 9 Jul 1999 23:46:18 GMT Message-ID: <3786890E.2F6CCE34@tdx.co.uk> Date: Sat, 10 Jul 1999 00:43:10 +0100 From: Karl Pielorz Organization: TDX - The Digital eXchange X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org Subject: Latest currents 'hang' on biord? [ Appears only on my system? :( ] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Any current's more recent than about a month ago on my main system seem to 'hang' on biord whenever they access the IDE drives... The system boots of SCSI, has a number of SCSI drives - but as soon as it either tries to mount, or fsck an IDE drive it just hangs... Breaking into DDB at the time and running PS shows either fsck, or mount in "biord" - even a simple DD results in the same hang... Hitting CTRL-C will quit the mount/fsck/dd command - but the system just doesn't seem to be able to access it's IDE drives? Has anyone got any suggestions? - I noticed this a while ago, and posted accordingly - but no one responded... If I boot an old kernel (like a month old) the system comes up OK, but any newer kernels and they just hang... I've tried rebuilding the kernel config from GENERIC, but it does the same :( System is an SMP dual P-Pro200, running on a SuperMicro P6DNF w/256Mb RAM, 3 x 2940's, and 4xIDE drives... Kernel config just says: controller wdc0 at isa? port IO_WD1 irq 14 disk wd0 at wdc0 drive 0 disk wd1 at wdc0 drive 1 controller wdc1 at isa? port IO_WD2 irq 15 disk wd2 at wdc1 drive 0 disk wd3 at wdc1 drive 1 dmesg for the above drives is below (I'd post the whole -v dmesg, but it's very long :( wdc0 at 0x1f0-0x1f7 irq 14 flags 0xff00ff on isa wdc0: unit 0 (wd0): , multi-block-16 wd0: 4110MB (8418816 sectors), 14848 cyls, 9 heads, 63 S/T, 512 B/S wd0: ATA INQUIRE valid = 0007, dmamword = 0407, apio = 0003, udma = 0007 wdc0: unit 1 (wd1): , multi-block-16 wd1: 2014MB (4124736 sectors), 4092 cyls, 16 heads, 63 S/T, 512 B/S wd1: ATA INQUIRE valid = 0007, dmamword = 0407, apio = 0003, udma = 0007 wdc1 at 0x170-0x177 irq 15 flags 0xff00ff on isa wdc1: unit 0 (wd2): , multi-block-16 wd2: 4110MB (8418816 sectors), 14848 cyls, 9 heads, 63 S/T, 512 B/S wd2: ATA INQUIRE valid = 0007, dmamword = 0407, apio = 0003, udma = 0007 wdc1: unit 1 (wd3): , multi-block-8 wd3: 2445MB (5008752 sectors), 4969 cyls, 16 heads, 63 S/T, 512 B/S wd3: ATA INQUIRE valid = 0003, dmamword = 0407, apio = 0003, udma = 0000 Any suggestions? - I'd guess it's not a very prolific problem, as no one else seems to have the same symptoms? :( -Karl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 9 17:12:45 1999 Delivered-To: freebsd-current@freebsd.org Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194]) by hub.freebsd.org (Postfix) with ESMTP id 5A17A15766 for ; Fri, 9 Jul 1999 17:12:37 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.3/8.8.8) with ESMTP id RAA05182; Fri, 9 Jul 1999 17:12:21 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199907100012.RAA05182@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Karl Pielorz Cc: current@FreeBSD.ORG Subject: Re: Latest currents 'hang' on biord? [ Appears only on my system? :( ] In-reply-to: Your message of "Sat, 10 Jul 1999 00:43:10 BST." <3786890E.2F6CCE34@tdx.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 09 Jul 1999 17:12:21 -0700 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Not sure if this will help .... My test / compile box : Pentium III 450 MHZ with 8 gig ide disk drive does not hang at all . FreeBSD-current is about a week old. Cheers -- Amancio Hasty hasty@rah.star-gate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 9 17:39:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from io.yi.org (24.66.174.118.bc.wave.home.com [24.66.174.118]) by hub.freebsd.org (Postfix) with ESMTP id F3B3714CC3 for ; Fri, 9 Jul 1999 17:39:18 -0700 (PDT) (envelope-from jake@checker.org) Received: from io.yi.org (localhost [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id 1B9F81F05; Fri, 9 Jul 1999 17:39:17 -0700 (PDT) X-Mailer: exmh version 2.0.2 2/24/98 To: Amancio Hasty Cc: Karl Pielorz , current@FreeBSD.ORG Subject: Re: Latest currents 'hang' on biord? [ Appears only on my system? :( ] In-reply-to: Your message of "Fri, 09 Jul 1999 17:12:21 PDT." <199907100012.RAA05182@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 09 Jul 1999 17:39:17 -0700 From: Jake Burkholder Message-Id: <19990710003918.1B9F81F05@io.yi.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> Any current's more recent than about a month ago on my main system seem to >> 'hang' on biord whenever they access the IDE drives... > My test / compile box : Pentium III 450 MHZ with 8 gig ide disk drive > does not hang at all . FreeBSD-current is about a week old. Same here; K6-233 with 2 4 gig IDE drives, no problems at all. I'm even using vinum. Since you're running current, you might try Soren's new ATA driver, its documented in LINT; I've been using it for several months with no problems. fwiw I booted the install disk today, it has the old wd driver, and that accessed my drives fine as well. -- we are but packets in the internet of life To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 9 22: 0:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from bilby.prth.tensor.pgs.com (bilby.prth.tensor.pgs.com [157.147.232.237]) by hub.freebsd.org (Postfix) with ESMTP id 7555F151C4; Fri, 9 Jul 1999 22:00:25 -0700 (PDT) (envelope-from shocking@ariadne.prth.tensor.pgs.com) Received: from bandicoot.prth.tensor.pgs.com (bandicoot.prth.tensor.pgs.com [157.147.224.1]) by bilby.prth.tensor.pgs.com (8.9.3/8.8.8) with ESMTP id MAA16685; Sat, 10 Jul 1999 12:59:10 +0800 (WST) Received: from ariadne.tensor.pgs.com (ariadne [157.147.227.36]) by bandicoot.prth.tensor.pgs.com (8.9.3/8.8.8) with SMTP id NAA07048; Sat, 10 Jul 1999 13:00:19 +0800 (WST) Received: from ariadne by ariadne.tensor.pgs.com (SMI-8.6/SMI-SVR4) id NAA05937; Sat, 10 Jul 1999 13:00:18 +0800 Message-Id: <199907100500.NAA05937@ariadne.tensor.pgs.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Brian F. Feldman" Cc: Stephen Hocking-Senior Programmer PGS Tensor Perth , current@freebsd.org Subject: Re: MTRR stuff In-reply-to: Your message of "Fri, 09 Jul 1999 13:19:15 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 10 Jul 1999 13:00:18 +0800 From: Stephen Hocking-Senior Programmer PGS Tensor Perth Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What exactly are the ranges? You haven't given me enough info yet. I wrote the > K6-* MTRR driver, so I'd like to help. > OK, the Linux 3dfx driver attempts to set up a write combining range starting at the card's base address and 0x400000 bytes long. After doing this it then sets up a range marked as uncacheable starting at the card's base address of length 0x1000. Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true." Robert Wilensky, University of California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 9 22:47:54 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C44B314E54 for ; Fri, 9 Jul 1999 22:47:51 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA51085; Fri, 9 Jul 1999 22:47:42 -0700 (PDT) (envelope-from dillon) Date: Fri, 9 Jul 1999 22:47:42 -0700 (PDT) From: Matthew Dillon Message-Id: <199907100547.WAA51085@apollo.backplane.com> To: Karl Pielorz Cc: current@FreeBSD.ORG Subject: Re: Latest currents 'hang' on biord? [ Appears only on my system? :( ] References: <3786890E.2F6CCE34@tdx.co.uk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Hi, : :Any current's more recent than about a month ago on my main system seem to :'hang' on biord whenever they access the IDE drives... :... Make sure you have the absolute latest CURRENT. There was a situation that broken current a week or so ago for 2 days that could result in processes getting stuck in biord on SMP boxes. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 9 23: 7:38 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 54FFD14F13 for ; Fri, 9 Jul 1999 23:07:36 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA52988; Fri, 9 Jul 1999 23:07:23 -0700 (PDT) (envelope-from dillon) Date: Fri, 9 Jul 1999 23:07:23 -0700 (PDT) From: Matthew Dillon Message-Id: <199907100607.XAA52988@apollo.backplane.com> To: Stephen Hocking-Senior Programmer PGS Tensor Perth Cc: current@FreeBSD.ORG Subject: Re: Dirty pages & low memory hangs with mmap References: <199907090340.LAA04093@ariadne.tensor.pgs.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I've been seeing an interesting problem when doing a make installworld on a :486 with 16MB of memory. Immediately after installing libc.so.3, it will hang. :DDB gives a backtrace to a mmap related call (sorry, the box is at home at the :memoment and this email was prompted by something on freebsd-current). It's :quite reproducible, but worked around by issuing a bunch of syncs every :second. Outside of that, the box runs fine (it's my ppp NAT gateway, runs :squid & nntpcached as well). : : : Stephen If you can run a kernel with DDB configured, you can break into DDB after the machine hangs with ctl-alt-esc and then do a 'ps' to see what all the processes are blocked in. One of two known low memory hang conditions was fixed in a commit a day or two ago. The remaining known low memory hang occurs when files are mmap()'d shared and pages are dirtied directly. I've been trying to track that one down along with another hang in 'objtrm' without much luck so far. But to figure out exactly why your machines is hanging I need the DDB ps output. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 9 23:21:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id E7A7415196 for ; Fri, 9 Jul 1999 23:21:27 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: (from alc@localhost) by cs.rice.edu (8.9.0/8.9.0) id BAA24899; Sat, 10 Jul 1999 01:21:11 -0500 (CDT) Date: Sat, 10 Jul 1999 01:21:10 -0500 From: Alan Cox To: Stephen McKay Cc: Andrew Gallatin , freebsd-current@freebsd.org, dillon@apollo.backplane.com Subject: Re: Stuck in "objtrm" Message-ID: <19990710012110.W10611@cs.rice.edu> References: <199907021200.WAA06282@nymph.detir.qld.gov.au> <199907060745.RAA12161@nymph.detir.qld.gov.au> <199907061044.UAA14043@nymph.detir.qld.gov.au> <14210.4262.296904.751060@grasshopper.cs.duke.edu> <199907070349.NAA13375@nymph.detir.qld.gov.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=oTHb8nViIGeoXxdp X-Mailer: Mutt 0.95.5us In-Reply-To: <199907070349.NAA13375@nymph.detir.qld.gov.au>; from Stephen McKay on Wed, Jul 07, 1999 at 01:49:51PM +1000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --oTHb8nViIGeoXxdp Content-Type: text/plain; charset=us-ascii Please try the attached patch. Alan --oTHb8nViIGeoXxdp Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="objhang.patch" Index: vm/vm_object.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_object.c,v retrieving revision 1.158 diff -c -r1.158 vm_object.c *** vm_object.c 1999/07/01 19:53:42 1.158 --- vm_object.c 1999/07/10 06:02:51 *************** *** 400,413 **** int s; /* ! * Make sure no one uses us. */ vm_object_set_flag(object, OBJ_DEAD); ! ! /* ! * wait for the pageout daemon to be done with the object ! */ ! vm_object_pip_wait(object, "objtrm"); KASSERT(!object->paging_in_progress, ("vm_object_terminate: pageout in progress")); --- 400,415 ---- int s; /* ! * Atomically wait for the pageout daemon to release the object ! * and mark the object dead. */ + s = splvm(); + while (object->paging_in_progress) { + vm_object_set_flag(object, OBJ_PIPWNT); + tsleep(object, PVM, "objtrm", 0); + } vm_object_set_flag(object, OBJ_DEAD); ! splx(s); KASSERT(!object->paging_in_progress, ("vm_object_terminate: pageout in progress")); --oTHb8nViIGeoXxdp-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 10 0:12: 2 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 7B2BE151AB for ; Sat, 10 Jul 1999 00:11:51 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id AAA53510; Sat, 10 Jul 1999 00:11:43 -0700 (PDT) (envelope-from dillon) Date: Sat, 10 Jul 1999 00:11:43 -0700 (PDT) From: Matthew Dillon Message-Id: <199907100711.AAA53510@apollo.backplane.com> To: Stephen McKay Cc: freebsd-current@FreeBSD.ORG, syssgm@detir.qld.gov.au Subject: Re: Stuck in "objtrm" - live kernel test to run References: <199907081828.LAA41802@apollo.backplane.com> <199907091033.UAA03176@nymph.detir.qld.gov.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Cute. After the ps axlf, all the swapped out processes went from 0 to 8 KB :resident. But the stuck process stayed at 0 KB resident. It wasn't :swapped out anyway, according to the ps flags, so it should have had some :resident pages. Seems like a contradiction to me. : :Stephen. Yah. the 'f' flag to ps is something I added a year or two ago. Previously ps was reading the process uareas by default, which would have the undesireable result of swapping every process in the system in. The default is now to avoid reading the uarea unless the 'f' flag is specified. I'm trying to simulate your 486 setup. You must love pain! A make -j5 buildworld on a 16MB-limited machine pages like hell (200-400 pageins/sec AND 200-400 pageouts/sec simultaniously, almost continuously). Are you using any special sysctls or special kernel config options? Also, try the latest -CURRENT and see if you can still get it stuck in objtrm. I haven't had any luck so far in my simulation. If you still get stuck in objtrm then try Alan's patch and see if that has an effect. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 10 1:47:53 1999 Delivered-To: freebsd-current@freebsd.org Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (Postfix) with ESMTP id 3A27014D6E for ; Sat, 10 Jul 1999 01:47:48 -0700 (PDT) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.9.3/8.9.3/Kp) with ESMTP id IAA60763; Sat, 10 Jul 1999 08:47:39 GMT Message-ID: <378707EE.9D80B2F8@tdx.co.uk> Date: Sat, 10 Jul 1999 09:44:30 +0100 From: Karl Pielorz Organization: TDX - The Digital eXchange X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: current@FreeBSD.ORG Subject: Re: Latest currents 'hang' on biord? [ Appears only on my system? :( ] References: <3786890E.2F6CCE34@tdx.co.uk> <199907100547.WAA51085@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > Make sure you have the absolute latest CURRENT. There was a situation > that broken current a week or so ago for 2 days that could result > in processes getting stuck in biord on SMP boxes. > > -Matt Matt, Like I thought - it doesn't seem to be affecting anyone else :( - I last cvsup'd and built the world on Friday 9th of July @ 22.10 - I had heard about the SMP machines getting stuck before, but was sure it was fixed by now... I'm re-cvsup'ing at the moment and running another buildworld to see if that works... Cheers, -Karl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 10 2:28:22 1999 Delivered-To: freebsd-current@freebsd.org Received: from kiwi.datasys.net (kiwi.datasys.net [209.119.145.2]) by hub.freebsd.org (Postfix) with ESMTP id 23B3414CF7 for ; Sat, 10 Jul 1999 02:28:19 -0700 (PDT) (envelope-from ayan@kiwi.datasys.net) Received: (from root@localhost) by kiwi.datasys.net (8.9.3/8.9.3) id FAA79011 for freebsd-current@freebsd.org; Sat, 10 Jul 1999 05:28:20 -0400 (EDT) (envelope-from ayan) Date: Sat, 10 Jul 1999 05:28:20 -0400 (EDT) From: Ayan George Message-Id: <199907100928.FAA79011@kiwi.datasys.net> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: freebsd-current@freebsd.org Subject: utmp & last Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Why do we store the utmp/wtmp and last logs in different data structures? What seems strange is that they use the different data types to store the same information (the time): struct lastlog { time_t ll_time; char ll_line[UT_LINESIZE]; char ll_host[UT_HOSTSIZE]; }; struct utmp { char ut_line[UT_LINESIZE]; char ut_name[UT_NAMESIZE]; char ut_host[UT_HOSTSIZE]; long ut_time; }; Not that there is any _real_ difference between long and time_t, but it would imagine we'd want to be as consistant as possable. Anyhow, IMHO the umtp filestructure should be used to store the last log. At the same time, I'm sure there is a reason for the way things are. Could someone clue me in? -Ayan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 10 5:24:48 1999 Delivered-To: freebsd-current@freebsd.org Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (Postfix) with ESMTP id B39B614D20 for ; Sat, 10 Jul 1999 05:24:40 -0700 (PDT) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.9.3/8.9.3/Kp) with ESMTP id MAA00860; Sat, 10 Jul 1999 12:24:28 GMT Message-ID: <37873ABF.9977CE9@tdx.co.uk> Date: Sat, 10 Jul 1999 13:21:19 +0100 From: Karl Pielorz Organization: TDX - The Digital eXchange X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon , current@FreeBSD.ORG Subject: Re: Hang on biord? [ Appears only on my system? :( ] - Update References: <3786890E.2F6CCE34@tdx.co.uk> <199907100547.WAA51085@apollo.backplane.com> <378707EE.9D80B2F8@tdx.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Karl Pielorz wrote: > > Matthew Dillon wrote: > > > Make sure you have the absolute latest CURRENT. There was a situation > > that broken current a week or so ago for 2 days that could result > > in processes getting stuck in biord on SMP boxes. OK, source as of 10/Jul/99, 11.20am (BST) - SMP kernel hangs on 'biord', non-SMP kernel boots fine.... Anything I can try to trace this further? -Kp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 10 10:43:51 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 157C71503A for ; Sat, 10 Jul 1999 10:43:49 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA57461; Sat, 10 Jul 1999 10:43:46 -0700 (PDT) (envelope-from dillon) Date: Sat, 10 Jul 1999 10:43:46 -0700 (PDT) From: Matthew Dillon Message-Id: <199907101743.KAA57461@apollo.backplane.com> To: Alan Cox Cc: Stephen McKay , Andrew Gallatin , freebsd-current@FreeBSD.ORG Subject: Re: Stuck in "objtrm" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yahhh. I was finally able to reproduce the problem - running Stephen's 16MB make -j5 buildworld test overnight. I haven't found the exact cause yet, and I suspect that Alan's patch will not fix it (but I'll try it if I exhaust other possibilities). There is plenty of free memory and only one process is blocked in a weird state (objtrm). No deadlock condition exists anywhere. Alan's patch will fix another potential low-memory deadlock (it allows pageouts to be performed on an exiting objecting), though. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 10 14:41:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id E4EB114C08 for ; Sat, 10 Jul 1999 14:41:27 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA58697; Sat, 10 Jul 1999 14:41:26 -0700 (PDT) (envelope-from dillon) Date: Sat, 10 Jul 1999 14:41:26 -0700 (PDT) From: Matthew Dillon Message-Id: <199907102141.OAA58697@apollo.backplane.com> To: Alan Cox , Stephen McKay , Andrew Gallatin , freebsd-current@FreeBSD.ORG Subject: "objtrm" problem probably found (was Re: Stuck in "objtrm") Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The supposedly atomic functions in i386/include/atomic.h are not as atomic as was previously thought :-): #define atomic_add_short(P, V) (*(u_short*)(P) += (V)) I looked at that kinda funny. But C doesn't guarentee a RMW opcode for a "+=" !!!. Alan found an example showing a load, add, and separate store by disassembling the kernel. An interrupt occuring in the middle of that sequence would lead to the reported problems. I'm pretty sure this is the problem causing the "objtrm" lockups. I've submitted a patch to Alan to make those atomic_*() functions inline assembly. There also appear to be a number of mistakes in some of the inline assembly already laying around -- some of it appears to specify output arguments for RMW instructions without also indicating to the compiler that those are input arguments as well, leading to bogus optimizations by the C compiler. The 'setbits' function is the one Alan found inadvertantly while we were trying to figure out why my first iteration didn't work. heh heh. Alan will fix the setbits inline. It wouldn't hurt if someone with more assembly experience could audit all of the inline assembly present in the source base. I am re-running the 16MB/make -j5 buildworld test to see if this has really fixed the problem. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message